Why IoT needs Secure Messaging

by Mrinal Wadhwa

Slide 1

Slide 1 text

Secure Messaging. The Internet of Things needs: Mrinal Wadhwa Ockam

Slide 2

Slide 2 text

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 …

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

The monitor would send data to the service … Heart Rate Monitor Heart Rate Application Heart Rate Service 80 bpm

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Security. The degree of resistance to encountering an unfortunate event.

Slide 9

Slide 9 text

To maximize this degree of resistance, we need to understand the possible set of unfortunate events, the threat model. Security.

Slide 10

Slide 10 text

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.

Slide 11

Slide 11 text

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.

Slide 12

Slide 12 text

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.

Slide 13

Slide 13 text

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.

Slide 14

Slide 14 text

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.

Slide 15

Slide 15 text

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.

Slide 16

Slide 16 text

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.

Slide 17

Slide 17 text

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.

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Initiator Responder Shared Secret Shared Secret M1 M2 M3 The shared secret is then used as a key in Symmetric Key Cryptography to maintain conﬁdentiality 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

Slide 21

Slide 21 text

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.

Slide 22

Slide 22 text

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? Difﬁe-Helmann only or Signatures + Difﬁe-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?

Slide 23

Slide 23 text

Many transport protocols, that are commonly used within IoT systems, provide some notion of a secure channel. However, conﬁguring 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.

Slide 24

Slide 24 text

Coming back to our heart rate solution, for secure communication … Heart Rate Monitor Heart Rate Application Heart Rate Service

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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 …

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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 “

Slide 35

Slide 35 text

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 …).

Slide 36

Slide 36 text

Privacy. The ability of an individual or group to control the ﬂow of information about themselves.

Slide 37

Slide 37 text

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.

Slide 38

Slide 38 text

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.

Slide 39

Slide 39 text

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.

Slide 40

Slide 40 text

Lots of connected devices only need an internet service for routing and caching …

Slide 41

Slide 41 text

Route on/off instructions. Connected Outlet Connected Outlet Application Connected Outlet Service

Slide 42

Slide 42 text

Route open/close instructions. Connected Lock Connected Lock Application Connected Lock Service

Slide 43

Slide 43 text

Route/Cache sensor data, alerts and videos. Camera Door Bell Camera Door Bell Application Camera Door Bell Service

Slide 44

Slide 44 text

Route Sensor Alerts Fire Alarm Application Fire Alarm Service Fire Alarm

Slide 45

Slide 45 text

Many, many more … all of which can be built without exposing user/application data to the Internet (including the operator of the system).

Slide 46

Slide 46 text

Decoupling the secure channel protocol also helps when there are multiple transport protocols involved in one data ﬂow, which is very common in IoT systems …

Slide 47

Slide 47 text

Gateway Flood Warning Sensor Multiple transport protocols in the path of one message. TCP TCP Flood Monitoring System Sensors Vendor’s Service LPWAN

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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.

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

In enterprise settings the problems get worse …

Slide 52

Slide 52 text

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.

Slide 53

Slide 53 text

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.

Slide 54

Slide 54 text

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.

Slide 55

Slide 55 text

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.

Slide 56

Slide 56 text

Secure Messaging. Communication using messages traveling over end-to-end encrypted, transport agnostic secure and private channels.

Slide 57

Slide 57 text

Slide 58

Slide 58 text

The willingness of one party to rely on the actions of another party. Trust.

Slide 59

Slide 59 text

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.

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Secure Messaging features like routing, caching, prioritized ordering can be generalized and don’t have to be use case speciﬁc, this further improves security and privacy …

Slide 62

Slide 62 text

This reveals metadata about which device spoke to which other device. Connected Outlet Connected Outlet Application Connected Outlet Service

Slide 63

Slide 63 text

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?

Slide 64

Slide 64 text

Edge computing, security enhancing and privacy preserving technologies of the near future will need this foundation of secure messaging …

Slide 65

Slide 65 text

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 ﬁnding of the ofﬂine 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

Slide 66

Slide 66 text

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.

Slide 67

Slide 67 text

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.

Slide 68

Slide 68 text

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.

Slide 69

Slide 69 text

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.

Slide 70

Slide 70 text

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