Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Why IoT needs Secure Messaging

Mrinal Wadhwa
January 23, 2020

Why IoT needs Secure Messaging

Security & Privacy should be primary concerns in the design of how data flows within IoT. However, current IoT communication protocols are lacking. This talk explores how secure messaging, decoupled from from the transport layer, removes complexity, minimizes the attack surface and can enable us to build better end-to-end secure and private systems.

Mrinal Wadhwa

January 23, 2020
Tweet

More Decks by Mrinal Wadhwa

Other Decks in Technology

Transcript

  1. Heart Rate Monitor Heart Rate Application Lets imagine that you’re

    designing a heart rate monitoring device and an accompanying phone application to track heart rate history …
  2. You want the monitor to be usable without having to

    also carry a phone, so you’ve designed the device to include a cellular modem and it has direct access to the internet … Heart Rate Monitor Heart Rate Application
  3. Typically you would setup a web service to deliver heart

    rate readings to a phone. Since there is no direct route from the device to the phone. Heart Rate Monitor Heart Rate Application Heart Rate Service
  4. The monitor would send data to the service … Heart

    Rate Monitor Heart Rate Application Heart Rate Service 80 bpm
  5. The service would route the data to the phone …

    Heart Rate Monitor Heart Rate Application Heart Rate Service 80 bpm
  6. The phone may not be online all the time so

    the service also caches this data to deliver it later … Heart Rate Monitor Heart Rate Application Heart Rate Service 80 bpm
  7. To maximize this degree of resistance, we need to understand

    the possible set of unfortunate events, the threat model. Security.
  8. THREAT DESIRED PROPERTY S Spoofing identity Identification, Authentication T Tampering

    with data Integrity R Repudiation Non-repudiability (some applications desire the opposite) I Information disclosure Confidentiality D Denial of service Availability E Elevation of privilege Authorization The STRIDE threat model can help us evaluate every message. Note that this model is very high level, there is massive amounts of nuance in dealing with each of the rows.
  9. THREAT DESIRED PROPERTY S Spoofing identity Identification, Authentication T Tampering

    with data Integrity R Repudiation Non-repudiability (some applications desire the opposite) I Information disclosure Confidentiality D Denial of service Availability E Elevation of privilege Authorization Could someone spoof the sender field of a message? This often means they can also create fake messages. The STRIDE threat model can help us evaluate every message.
  10. THREAT DESIRED PROPERTY S Spoofing identity Identification, Authentication T Tampering

    with data Integrity R Repudiation Non-repudiability (some applications desire the opposite) I Information disclosure Confidentiality D Denial of service Availability E Elevation of privilege Authorization Could someone change the message on-route? The STRIDE threat model can help us evaluate every message.
  11. THREAT DESIRED PROPERTY S Spoofing identity Identification, Authentication T Tampering

    with data Integrity R Repudiation Non-repudiability (some applications desire the opposite) I Information disclosure Confidentiality D Denial of service Availability E Elevation of privilege Authorization Could someone deny sending a messages they had previously sent? The STRIDE threat model can help us evaluate every message.
  12. THREAT DESIRED PROPERTY S Spoofing identity Identification, Authentication T Tampering

    with data Integrity R Repudiation Non-repudiability (some applications desire the opposite) I Information disclosure Confidentiality D Denial of service Availability E Elevation of privilege Authorization Could someone see the metadata or contents of a message on-route? The STRIDE threat model can help us evaluate every message.
  13. THREAT DESIRED PROPERTY S Spoofing identity Identification, Authentication T Tampering

    with data Integrity R Repudiation Non-repudiability (some applications desire the opposite) I Information disclosure Confidentiality D Denial of service Availability E Elevation of privilege Authorization Could someone stop messages from being delivered? Maybe only from a subset of senders. The STRIDE threat model can help us evaluate every message.
  14. THREAT DESIRED PROPERTY S Spoofing identity Identification, Authentication T Tampering

    with data Integrity R Repudiation Non-repudiability (some applications desire the opposite) I Information disclosure Confidentiality D Denial of service Availability E Elevation of privilege Authorization Could someone do something more than what we authorized them to do? The STRIDE threat model can help us evaluate every message.
  15. THREAT DESIRED PROPERTY S Spoofing identity Identification, Authentication T Tampering

    with data Integrity R Repudiation Non-repudiability (some applications desire the opposite) I Information disclosure Confidentiality D Denial of service Availability E Elevation of privilege Authorization Note that this model is very high level, there is massive amounts of nuance in dealing with each of the rows. The STRIDE threat model can help us evaluate every message.
  16. Secure Channels. Initiator Responder Shared Secret Shared Secret M1 M2

    M3 The typical approach used to achieve these desired properties.
  17. Initiator Responder Shared Secret Shared Secret M1 M2 M3 The

    entities involved use Public Key Cryptography to authenticate each other and agree on a shared secret. Authenticated Key Exchange
  18. Initiator Responder Shared Secret Shared Secret M1 M2 M3 The

    shared secret is then used as a key in Symmetric Key Cryptography to maintain confidentiality and integrity of application data. Application Data - Authenticated Encryption The entities involved use Public Key Cryptography to authenticate each other and agree on a shared secret. Authenticated Key Exchange D
  19. THREAT DESIRED PROPERTY S Spoofing identity Identification, Authentication T Tampering

    with data Integrity R Repudiation Non-repudiability (some applications desire the opposite) I Information disclosure Confidentiality D Denial of service Availability E Elevation of privilege Authorization Even when information disclosure is not in a system’s threat model, all of the other rows must be, else that system has no security or reliability. You still need secure channels even when you aren’t looking for confidentiality/encryption. The STRIDE threat model.
  20. Implementing secure channels correctly is hard: 1. RSA or Elliptic

    Curves? 2. Which Curve to use? P256, P512, Brainpool, Kolbitz, Curve25519, Curve448 … 3. Which HASH algorithm to use? SHA1, SHA2, SHA3, Blake2 … 4. Which MAC algorithm to use? HMAC, GMAC, CMAC, PMAC … 5. Which AEAD? AES_GCM, ChaChaPoly … 6. Which Key derivation function? 7. Nonces, uniqueness, nonce length? 8. Which AES mode? AES CTR, CBC, GCM, GCM-SIV, SIV, CCM … 9. Authenticated Key Exchange? Diffie-Helmann only or Signatures + Diffie-Helmann 10. How to protect against downgrade attacks? 11. How to guarantee Forward Secrecy? 12. How to resist Key Compromise Impersonation attacks? 13. How to protect identities?
  21. Many transport protocols, that are commonly used within IoT systems,

    provide some notion of a secure channel. However, configuring them correctly is hard and their security guarantees can vary in many subtle ways based on how the channel protocol was designed (all the choices from the previous slide) This complexity makes it very challenging for system architects to reason about the overall of security of our systems.
  22. Coming back to our heart rate solution, for secure communication

    … Heart Rate Monitor Heart Rate Application Heart Rate Service
  23. Heart Rate Monitor Heart Rate Application Heart Rate Service Secure

    Channel We setup a secure channel between the monitor and the service.
  24. Heart Rate Monitor Heart Rate Application Heart Rate Service Secure

    Channel Secure Channel And another secure channel between the phone and the service.
  25. Heart Rate Monitor Heart Rate Application Heart Rate Service Transport

    Layer Security Transport Layer Security Since these devices have direct access to the internet, with TLS …
  26. Heart Rate Monitor Heart Rate Application Heart Rate Service 80

    bpm Transport Layer Security Transport Layer Security
  27. Heart Rate Monitor Heart Rate Application Heart Rate Service 80

    bpm 0x217c5111… Transport Layer Security Transport Layer Security
  28. Heart Rate Monitor Heart Rate Application Heart Rate Service 80

    bpm 0x217c5111… 80 bpm Transport Layer Security Transport Layer Security
  29. Heart Rate Monitor Heart Rate Application Heart Rate Service 80

    bpm 0x217c5111… 80 bpm 0x8621f842… Transport Layer Security Transport Layer Security
  30. Heart Rate Monitor Heart Rate Application Heart Rate Service 80

    bpm 0x217c5111… 80 bpm 0x8621f842… 80 bpm This type of setup is industry best practice. Transport Layer Security Transport Layer Security
  31. Heart Rate Monitor Heart Rate Application Heart Rate Service 80

    bpm 0x217c5111… 80 bpm 0x8621f842… 80 bpm But even when we manage to setup the channels correctly the data is still exposed to the service. The service doesn’t need to know the contents of the message to route and cache messages (its primary job). Transport Layer Security Transport Layer Security
  32. Least Privilege. Principle of Every program and every privileged user

    of the system should operate using the least amount of privilege necessary to complete the job.” — Jerome Saltzer, Communications of the ACM, 1974 “
  33. Exposing the data to the service increases the attack surface

    of the system, creates a honeypot of data and exposes the service operator to liability, risk, and compliance challenges (HIPPA, GDPR, CCPA …).
  34. Privacy. The ability of an individual or group to control

    the flow of information about themselves.
  35. The data being exposed to the service also takes away

    the end user’s control on their data. This could be private data of an individual or proprietary data of a business.
  36. Heart Rate Monitor Heart Rate Application Heart Rate Service 80

    bpm 0x217c5111… 80 bpm 0x217c5111… 0x217c5111… If, instead, we decouple the secure channel protocol from the transport protocol, we could have an end-to-end secure and private channel.
  37. Decoupling the secure channel protocol from the transport layer protocols

    removes complexity, minimizes the attack surface and can enable us to build end-to-end secure and private systems.
  38. Route/Cache sensor data, alerts and videos. Camera Door Bell Camera

    Door Bell Application Camera Door Bell Service
  39. Many, many more … all of which can be built

    without exposing user/application data to the Internet (including the operator of the system).
  40. Decoupling the secure channel protocol also helps when there are

    multiple transport protocols involved in one data flow, which is very common in IoT systems …
  41. Gateway Flood Warning Sensor Multiple transport protocols in the path

    of one message. TCP TCP Flood Monitoring System Sensors Vendor’s Service LPWAN
  42. Gateway Flood Warning Sensor Flood Monitoring System Sensors Vendor’s Service

    Various protocols have various different secure channel designs. TLS TLS LPWAN
  43. Gateway Flood Warning Sensor Flood Monitoring System Sensors Vendor’s Service

    LPWAN TCP TCP Usually has different security properties, compared to TLS, often not as well designed. Various protocols have various different secure channel designs.
  44. Gateway Flood Warning Sensor A secure channel that is decoupled

    from the transport layer connections. The gateway and sensor vendor shouldn’t be exposed to application data. Flood Monitoring System Sensors Vendor’s Service
  45. D D D … Devices … … Gateways … Lighting

    HVAC Water Monitoring Elevators Access Control Fire Safety Waste Parking … Vendor IoT Backends … System Integrator 1 Building Management System … SI IoT Backends … System Integrator 2 G G D D D D D D D D D D D D D D D D D D D D D G G G G G G G G G G G G G G Several transport protocols, transport layer connections & IoT “platforms” are in the path of one message.
  46. D D D … Devices … … Gateways … Lighting

    HVAC Water Monitoring Elevators Access Control Fire Safety Waste Parking … Vendor IoT Backends … System Integrator 1 Building Management System … SI IoT Backends … System Integrator 2 G G D D D D D D D D D D D D D D D D D D D D D G G G G G G G G G G G G G G Complexity & attack surfaces grow to be unmanageable. Proprietary data is leaked. Security becomes untenable.
  47. D D D … Devices … … Gateways … Lighting

    HVAC Water Monitoring Elevators Access Control Fire Safety Waste Parking … Vendor IoT Backends … System Integrator 1 Building Management System … SI IoT Backends … System Integrator 2 G G D D D D D D D D D D D D D D D D D D D D D G G G G G G G G G G G G G G End-to-end secure channels can bring control back in the hands of the end customer.
  48. Control on what data is visible where, in our systems,

    allows us to be deliberate about who can see our business proprietary data which, in turn, enables new business models. This is much better than our current game of whack-a-mole, trying to endlessly thwart security bugs, on a wide open surface.
  49. Secure Channels Authenticated Key Exchange, Authenticated Encryption, Proof of possession

    of secret key, Session Management, Key Ratcheting, Message Ordering, Delivery Guarantees … Secure Messaging.
  50. Secure Channels Authenticated Key Exchange, Authenticated Encryption, Proof of possession

    of secret key, Session Management, Key Ratcheting, Message Ordering, Delivery Guarantees … Identity and Trust Key Rotation, Key Lineage, Key Endorsements, Endorsement Revocation, Credentials, Credential Revocation, Anonymous Credentials, Delegation … Secure Messaging.
  51. Secure Channels Authenticated Key Exchange, Authenticated Encryption, Proof of possession

    of secret key, Session Management, Key Ratcheting, Message Ordering, Delivery Guarantees … Identity and Trust Key Rotation, Key Lineage, Key Endorsements, Endorsement Revocation, Credentials, Credential Revocation, Anonymous Credentials, Delegation … Routing, Caching, Prioritized Ordering, Encrypted Group Messaging, Publish/Subscribe … Secure Messaging.
  52. Secure Messaging features like routing, caching, prioritized ordering can be

    generalized and don’t have to be use case specific, this further improves security and privacy …
  53. This reveals metadata about which device spoke to which other

    device. Connected Outlet Connected Outlet Application Connected Outlet Service
  54. Connected Outlet Application Routing & Caching Service A Connected Outlet

    Routing & Caching Service B Lots of home devices from lots of customers are talking to Service A Lots of phones from lots of customers are talking to Service B Service A and Service B are exchanging lots of messages. Fire Alarm Camera Door Bell Becomes much harder to tell which devices are talking to which phones at what times?
  55. Edge computing, security enhancing and privacy preserving technologies of the

    near future will need this foundation of secure messaging …
  56. New Protocols. Apple’s Find My - when a device goes

    missing, it begins periodically broadcasting a derived public key, the surrounding devices can then help in the finding of the offline device by encrypting their location to the public key. A shared foundation of secure messaging would allow us to have similar features in lots of IoT devices
  57. Federated Learning. Google Keyboard learns out-of-vocabulary words on mobile phones

    without exposing sensitive text to servers. Connected sensors could similarly learn to improve accuracy while preserving privacy.
  58. Zero Knowledge Proofs. Mozilla is using Non-Interactive Zero Knowledge Proofs

    to collect telemetry from the Firefox browser without collecting any private browser usage. A large subset of IoT use cases is telemetry collection.
  59. Decoupling the secure channel protocol from the transport layer protocols

    removes complexity, minimizes the attack surface and can enable us to build better end-to-end secure and private systems.
  60. THREAT DESIRED PROPERTY S Spoofing identity Identification, Authentication T Tampering

    with data Integrity R Repudiation Non-repudiability (some applications desire the opposite) I Information disclosure Confidentiality D Denial of service Availability E Elevation of privilege Authorization And, confidentiality is not the only reason we need secure encrypted messaging in IoT systems. The STRIDE threat model can help us evaluate every message.
  61. We’re building a multi-language open source library that makes it

    easy to add secure messaging to IoT systems. github.com/ockam-network ockam.io Mrinal Wadhwa CTO, Ockam twitter.com/mrinal