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.

Transcript

1. Secure Messaging. The Internet of Things needs: Mrinal Wadhwa Ockam
2. 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 …
3. 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
4. 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
5. The monitor would send data to the service … Heart Rate Monitor Heart Rate Application Heart Rate Service 80 bpm
6. The service would route the data to the phone … Heart Rate Monitor Heart Rate Application Heart Rate Service 80 bpm
7. 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
8. Security. The degree of resistance to encountering an unfortunate event.
9. To maximize this degree of resistance, we need to understand the possible set of unfortunate events, the threat model. Security.
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 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.
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 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.
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 change the 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 deny sending a messages they had previously sent? 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 see the metadata or contents of a message on-route? 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 Could someone stop messages from being delivered? Maybe only from a subset of senders. The STRIDE threat model can help us evaluate every message.
16. 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.
17. 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.
18. Secure Channels. Initiator Responder Shared Secret Shared Secret M1 M2 M3 The typical approach used to achieve these desired properties.
19. 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
20. 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
21. 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.
22. 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?
23. 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.
24. Coming back to our heart rate solution, for secure communication … Heart Rate Monitor Heart Rate Application Heart Rate Service
25. Heart Rate Monitor Heart Rate Application Heart Rate Service Secure Channel We setup a secure channel between the monitor and the service.
26. Heart Rate Monitor Heart Rate Application Heart Rate Service Secure Channel Secure Channel And another secure channel between the phone and the service.
27. 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 …
28. Heart Rate Monitor Heart Rate Application Heart Rate Service 80 bpm Transport Layer Security Transport Layer Security
29. Heart Rate Monitor Heart Rate Application Heart Rate Service 80 bpm 0x217c5111… Transport Layer Security Transport Layer Security
30. Heart Rate Monitor Heart Rate Application Heart Rate Service 80 bpm 0x217c5111… 80 bpm Transport Layer Security Transport Layer Security
31. Heart Rate Monitor Heart Rate Application Heart Rate Service 80 bpm 0x217c5111… 80 bpm 0x8621f842… Transport Layer Security Transport Layer Security
32. 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
33. 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
34. 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 “
35. 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 …).
36. Privacy. The ability of an individual or group to control the flow of information about themselves.
37. 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.
38. 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.
39. 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.
40. Lots of connected devices only need an internet service for routing and caching …
41. Route on/off instructions. Connected Outlet Connected Outlet Application Connected Outlet Service
42. Route open/close instructions. Connected Lock Connected Lock Application Connected Lock Service
43. Route/Cache sensor data, alerts and videos. Camera Door Bell Camera Door Bell Application Camera Door Bell Service
44. Route Sensor Alerts Fire Alarm Application Fire Alarm Service Fire Alarm
45. Many, many more … all of which can be built without exposing user/application data to the Internet (including the operator of the system).
46. 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 …
47. Gateway Flood Warning Sensor Multiple transport protocols in the path of one message. TCP TCP Flood Monitoring System Sensors Vendor’s Service LPWAN
48. Gateway Flood Warning Sensor Flood Monitoring System Sensors Vendor’s Service Various protocols have various different secure channel designs. TLS TLS LPWAN
49. 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.
50. 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
51. In enterprise settings the problems get worse …
52. 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.
53. 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.
54. 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.
55. 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.
56. Secure Messaging. Communication using messages traveling over end-to-end encrypted, transport agnostic secure and private channels.
57. Secure Channels Authenticated Key Exchange, Authenticated Encryption, Proof of possession of secret key, Session Management, Key Ratcheting, Message Ordering, Delivery Guarantees … Secure Messaging.
58. The willingness of one party to rely on the actions of another party. Trust.
59. 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.
60. 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.
61. 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 …
62. This reveals metadata about which device spoke to which other device. Connected Outlet Connected Outlet Application Connected Outlet Service
63. 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?
64. Edge computing, security enhancing and privacy preserving technologies of the near future will need this foundation of secure messaging …
65. 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
66. 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.
67. 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.
68. 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.
69. 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.
70. 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