Machine Identities

Machine Identifiers (DID, VC, Attributes…???)

Tuesday 2H

Convener: Mrinal Wadhwa

Notes-taker(s): Rich Smith

Tags for the session - technology discussed/ideas considered:

Secure hardware, DIDs, trust anchors, IoT

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Goal of topic: [Mrinal] Development of an open source set of tools to help people build secure connected devices, specifically IoT devices that have not had the best security track record

• [Mrinal] Devices often do many things on our behalf often without our direct or real-time involvement. An easy example would be a building’s HVAC system
  • How can we help people build secure network connected HVACs
• [Mrinal] Recent developments in the identity and technology space look like they could help make some significant progress on some longstanding problems in the space
• Can we start by defining security?
  • We have been approaching defining security through the use of the STRIDE model (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) and applying that to the datagrams that are being transferred between systems and not worrying about the transport layers security properties. If we can derive trust in the message from the message itself rather than having to rely on underlying systems and transports then many things get easier. Especially when thinking about IoT devices as there are so many different transports used, each of which come with their own security properties that can be hard to rationalize about.
    1. Would it be fair to say you are applying some ‘Zero Trust’ like principles to the problem and you are looking to secure the messaging layer and assume the transport provides no security properties?
       • Yes there are some similarities there for sure
• The mantra of ‘use TLS’ can bite us when working on message level security/encryption as they don’t need to rely on TLS for security properties but people cry foul if they don’t see devices use TLS and so inevitably double encryption is often done to satisfy peoples misplaced concerns.
  • Outside of the browser/web world this is less of an issue, lots of IoT devices already transmit their data in the clear!
  • Shall we just say ‘end to end’ encryption even though the ‘ends’ may not be TLS?
    1. <general agreement that that makes sense>
• ‘Identity’ should be defined as being ‘identifier’ + ‘attributes’
  • Trust is hard to bootstrap in a device without an identity
    1. There is web of attestations that relate to and provide confidence in a manufacturers chosen identifier for a device
    2. A user pairing with a device essentially adds another attribute to that devices which allows it to act with the authorization/authority of the user
    3. e.g. A lightbulb may have multiple identifiers. One is a manufacturer identifier that enables updates to be delivered, another may be an identifier used by a light switch that allows it to turn the specified bulb on/off. We don’t want a manufacturer to know when you turn your light on or off, they don’t need that info and lots of potential privacy issues.
       • We need to separate the bootstrapping of trust in a device from the usability requirements of the device.
       • Much more like linking ‘roles’ not identifiers
• We need to separate physical and network security and think about them differently. Devices that were traditionally not networked and had a good physical security model can fall vulnerable when they are put on the network.
  • As soon as you disconnect a crypto based root of trust from network security then things fall to pieces fast
    1. A crypto key is a ‘trust anchor’
    2. The only decentralized root of trust we have is a public/private keypair
    3. For crypto based roots of trust in a device you have to chain all the way back to the manufacturers of the components
    4. We need a mechanism by which we can rationalise about the security of a given device
• Q: How trustworthy is your root of trust?
  • The lightbulb doesn’t need to know which light switch turned it on, just that that the request to turn on is authorized
    1. This approach makes it easier to handle 5K devices in a building
  • Requests with verifiable authorization
  • TV’s use an OAuth device flow that allows you to easily pair the TV to an account through a short numeric code. This is seen as problematic as once the TV has the OAuth tokens/bearer tokens it can do what it likes with it.
• Q: How important is chained delegation to all of this? (e.g. TV -> Fridge -> Thermostat)
  • Prior to DIDs identifiers in most IoT devices were just MAC addresses.
  • A MAC address attached to a message alone doesn’t prove the message came from the device that corresponds to the MAC.
  • So now we need message signing so we need a public/private keypair
  • Which means you now need to maintain a table that maps MAC address to public key.
  • DIDs mean you don’t have to do this
  • DIDs enable identifiers to be cryptographically provable
• There is a key agreement phase that proceeds any message exchange
  • mTLS is an example of key agreement
  • NIST has some great key agreement papers – people should look them up and have a read
  • In signal(?) there is a pre-keying approach taken
  • Most HSM’s don’t support double ratcheting
  • P-256 is the only elliptic curve that works across ‘all’ hardware in reality when we looked at real world devices and their capabilities. This is problematic as some cryptographers don’t like that curve and think it may have specific weaknesses built in to enable government bypass
    • That said P-256 based crypto is better than no crypto at all or keys being kept in the filing system so it’s always a trade off
    • Don’t let perfect get in the way of progress
  • Sign then encrypt - The signing of encrypted messages carries some benefits in terms of resilience against attacks against an encryption algorithm as if the encryption is broken the signature won’t match
    • In some jurisdictions the signing of encrypted messages carries consequences legally (or is not enforceable) as the signatory cannot see what it is they are signing, they are instead signing an opaque representation that does not hold up in court
    • Q: Why would you not just sign the hash of the encrypted message?
    • <discussion on merits and drawbacks on sign after encrypt and other schemes that went too fast for good notes to be captured>
• Q: What are the attributes that describe the exposure level of a device?
  • For any hardware the reality is there will be many attributes and signals form multiple parties who created the hardware/components – all the way back to manufacture
  • Q: Can this web of attributes be used to better trust messages originating from that device?
  • Q: What is the ability to compromise the software in such devices?
    • <references made back to the earlier discussions on physical and network security being different>
    • Secure/trusted/measured boot can all help and bind some measure of current state against a known good
    • There would be a real benefit if public keys were replaced by DIDs in such IoT devices as it would help if keys were compromised
• Q: Does anyone have a good answer for post-quantum crypto for IoT devices?
  • Nope!
  • In general the closer you can put IoT devices ‘controllers’ to them (e.g. local ‘hub’ device vs cloud service) the better as the attack targets are more distributed and need to be targeting individually. Additionally the capabilities of that hub are more under your control to adjust and add compensating controls to as the threat landscape continues to evolve (whether than be quantum computing or anything else)
• Cost of IoT devices and controllers is something that needs to be kept in mind, many of the constraints in the capabilities of IoT devices (and the subsequent security properties) come as a direct result of needing a device to sell for $50 rather than $500. We could achieve many of the discussed properties already with current technology but it is cost prohibitive and therefore not done
  • Yes, but isn’t the goal to make the technology to improve the situation widely available and thus drive down costs?
  • You can do much of this on a raspberry pi and they are low cost
    • But they you have the problems of trusting and securing a general purpose computing device and whole software stack from multiple different vendors/projects – doesn’t this just kick the can on the problems that have been discussed?
  • A good way to balance the costs is to have cheap devices and more intelligence / cost in the controllers / hubs <see prior discussion on post-quantum>
  • Providing ways for IoT devices to interoperate across vendors / transports is a way to lower costs for all