When it comes to IoT, it is paramount to distinguish between authentication and authorisation. Typically, there are long discussions centred around device identities – authentication – while managing their access rights waved by one sentence such as “the portal will take care of the access management”. In real life, the most natural place to authorisation is right where authentication is: IAM is not called Identity and Access Management without a reason.

The IAM field is huge, and here I am concentrating on the authentication half, and more precisely the device corner of it.

IoT is finally descending from the hype clouds up in the sky to the offices of us mere mortals. Just look around and see how many people around you carry an activity bracelet, periodically synchronised to a cloud backend via the small computer we carry in our pockets.

This will be a long journey, so it is better to equip ourselves well beforehand. Before starting to build arguments for and against of different device identity solutions, one should have a deep and critical look at the planned architecture.

The architecture should be built from the business case. Basic questions should include “What does an attacker gain from breaching our system?” and “Are the device identities there to make device management easier or to differentiate between product segments?”. Besides direct monetary gain, (re-)selling stolen Personally Identifiable Information (PII) can be very lucrative.

Strong device identities

Device identity security tiers

 

Looking at the figure above, we see that increasing levels of transport layer security often needs to go hand-in-hand with increasing strength of device identities. If you happen to be an app developer, please, please remember to demand robust transport layer security for your app. I currently have three mobile banking apps for iOS, and every single one of them is trivially vulnerable to man-in-the-middle (MITM) attacks due to lack of basic hardening.

The bottom layer of device identities consists of a visible string, serial number or other identifier, transferred over a plain-text connection like HTTP. This is a surprisingly common approach even when the device identity acts as a product line differentiator (like car navigation systems) and leads to technically trivially cloneable identities. This however can be a simple cost-benefit trade-off: The x% of end users that can now more easily use unlicensed maps would most likely just switch to a different navigator if a more robust security system would be built, generating no extra income.

On the other end of the scale, utilising custom non-documented hardware (e.g. set-top boxes with Conax) have historically proven resistant, but not immune, against attacks. However, it should be noted that building layers upon layers of security both increases the attack surface and is clearly counter-productive if the layers are dependent on each other. This kind of “Wall of security” did not slow down but actually aided the hackers who revealed the PlayStation 3’s master key.

 

Strong device identities

Examples of use cases/tier

When picking a suitable device identity, the first choice is to whether to utilise shared secrets as device identities or use certificates. For more resource-constrained devices, public-key cryptography might simply be unattainable, and sadly SoC (System-On-Chip) manufacturers sell security at a premium.

Personal identities vs device identities

A couple of days ago I visited the post office to pick up a package. In order to get my package, I had to present my national ID card. That card has some important properties:

  1. It was issued by an organisation that is trusted by the service provider (the government)
  2. It is backed by legislation (the law says you must accept it as an identification method)
  3. It contains an unique identifier that can be recorded as a proof I was present (my SSN – Social Security Number)
  4. It has security features that help to validate its authenticity (e.g. my photo, microprinting)

Now all went fine and dandy, but this approach breaks when moving to digitalised services, where the service provider never physically sees my ID card or me in person.

Over the Internet, I can’t prove that I possess the card (invalidating point #1) and the other party has no way to validate the authenticity of the SSN that I provide (invalidating point #4). What is even worse is that if I send my SSN over the Internet and the other party decides to accept the transaction based on it, what would stop them to utilise the exact same method to do dozens of transactions – using my SSN?

Clearly, these traditional immutable symmetric secrets are unsuitable for electronic transactions and by extension device identities.

  1. There is no way to prove that I possess the secret (like SSN) without divulging it
  2. There is no way or it is very painstaking to revoke it
  3. All the trust is based on a single number
  4. Due to the above two points, multiple parties can conspire to build a much more detailed profile of my transactions without my consent
  5. There is no forward secrecy: any party with the possession of the key can view and modify all past transactions
  6. The only way past #1 is to let all service providers have lists of all the secrets that the devices have. If any one of them is ever breached, it’s game over.

Now, being domiciled in Finland, a good question is how about using the Finnish eID smart card then? Answering just “no” comes off as terribly rude, so please let me elaborate a bit:

  1. Getting the Finnish eID costs time and money. End users do not want to (directly) pay for strong identification.
  2. It does not replace a driver’s license or a passport, both which I need in any case.
  3. Any wide-spread smart card-based eID system generates a homogenous ecosystem vulnerable both to card issues (see Estonia and Infineon) and sweet Ring 0 exploits (see DreamBay).
  4. …and without wide-spread usage, places which accept such eIDs are as scarce as hen’s teeth and their implementations likely untested and buggy.
  5. Plugging a smart card into a smartphone or tablet is problematic unless one is already brave enough to carry half a dozen dongles at all times.
  6. No vendors outside Finland would accept it anyway.

Needless to say, I feel more than a little awkward when hearing news about proposed national eID rollouts…with smart cards. Anyway, to move on from this small pit for a man to a giant leap for devicekind, we’ll first have to acknowledge what similarities and differences exist between personal identities and device identities.

If I had to condense this entire post to a single phrase, it would be this: Devices are not little people. They do not have intrinsic identities backed by a trusted central authority and the only functionality they are guaranteed to have is one that they had built in when they left the factory.

Despite the obvious limitations, in real life there are plenty of examples where the device identity is a secret key or even just a string buried somewhere inside the device. Without naming names, many car navigators work this way, even though their business model is close to the classical razor-and-blades model, as the map updates will cost more over the lifetime of the device than the device itself. While using unlicensed maps is not hard for a technically competent individual, the simple encryption/pairing stops automated mass piracy and in some countries provides an additional legal leg to lean to against copyright infringers.

I often see recommendations to make device identities as immutable as physically possible. Even at the risk of drawing some flak, I’d like to speak for the opposite: Allowing the end user to change the device identity visible to the outside world (not the root of trust!) by default. Even in relatively simple industrial applications, where the machine in question transfers maintenance-related telemetry data, allowing the device identity to be changed when the machine is moved to a different facility or resold will avoid polluting the data store by keeping data from different sites separate. This might be able to be done console-style, where a single device can have multiple users differentiated by their private credentials or the device identity itself has to be mutable. Now the train of thought arrives back to where we started: What is the business case and the threats it faces? How likely it is that the end user is also a potential attacker and what harm could he achieve by being able to change the device identity?

Stay tuned for the next part of this series that dives into cryptography.

Contact Us to learn how IAM can help secure your IoT solution or environment.