IoT needs Secure Messaging and How Rust Can Help

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. 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.
10. Secure Channels. Initiator Responder Shared Secret Shared Secret M1 M2 M3 The typical approach used to achieve these desired properties.
11. 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
12. 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. Authenticated Encryption with Authenticated Data The entities involved use Public Key Cryptography to authenticate each other and agree on a shared secret. Authenticated Key Exchange D
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 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. We need Secure Channels even when we aren’t looking for confidentiality/encryption.
14. 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? 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, GCM, GCM-SIV … 9. Authenticated Key Exchange? SigMa like or Noise like? 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?
15. •Tightly coupled with transport layer protocol connections. •Hard to configure correctly. •Inefficient in resource usage (code size, memory, compute, network). •Poorly implemented black boxes that cannot be audited. •Quality of their design can vary in many subtle ways (cryptographic choices from previous slide) •Require expensive licenses. … Many transport protocols, that are commonly used within IoT systems, provide some notion of a secure channel. However, such secure channels implementations are usually:
16. Coming back to our heart rate solution, for secure communication … Heart Rate Monitor Heart Rate Application Heart Rate Service
17. Heart Rate Monitor Heart Rate Application Heart Rate Service Secure Channel We setup a secure channel between the monitor and the service.
18. Heart Rate Monitor Heart Rate Application Heart Rate Service Secure Channel Secure Channel And another secure channel between the phone and the service.
19. 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 …
20. 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
21. 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
22. 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 “
23. 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 …).
24. Privacy. The ability of an individual or group to control the flow of information about themselves.
25. 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 connections, we could have an end-to-end secure and private channel.
26. Lots of connected devices only need an internet service for routing and caching …
27. Route on/off instructions. Connected Outlet Connected Outlet Application Connected Outlet Service
28. Route open/close instructions. Connected Lock Connected Lock Application Connected Lock Service
29. Route/Cache sensor data, alerts and videos. Camera Door Bell Camera Door Bell Application Camera Door Bell Service
30. Route Sensor Alerts Fire Alarm Application Fire Alarm Service Fire Alarm
31. Many, many more … all of which can be built without exposing user/application data to the Internet (including the operator of the system).
32. Gateway Flood Warning Sensor Flood Monitoring System Sensors Vendor’s Service LPWAN TLS TLS Usually has different security properties, compared to TLS, often not as well designed. Various protocols have various different secure channel designs.
33. 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
34. 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.
35. 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.
36. 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 of ambient authority.
37. Secure Messaging. The Internet of Things needs: Communication using messages traveling over end-to-end authenticated, encrypted, transport agnostic, secure, and private channels.
38. 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 … We’re building multi-language, open source, libraries and tools that makes it easy to add secure messaging to IoT systems. github.com/ockam-network
39. Zero Cost Abstractions Vault, an abstraction over cryptographic hardware that provides a common set of sane building blocks that we can use to design secure channels and other higher level protocols. Transport, an abstraction over various transport layer protocols that exposes consistent behavior that we can rely on for secure channels and protocols like routing.
40. C Interoperability Ease of calling C libraries from Rust. Ease of integrating with external build tools. Ease of calling Rust libraries from C Ease of shipping libraries that can be seamlessly called from C code and used by proprietary toolchains
41. Erlang/Elixir Interoperability Our Messaging and Routing infrastructure is being built in Erlang/Elixir. Rust integrates nicely with the BEAM virtual machine, this will allow us implement our core cryptographic code once and share between embedded systems and cloud servers. Rust NIFs (via rustler) can never crash the BEAM.
42. Cryptography Rust Crypto, Dalek-Cryptography etc. are already really good and maturing fast. They give us small, simple, well designed building blocks for our protocols.
43. Portability embedded-hal and growing hardware support.
44. twitter.com/mrinal https://www.behance.net/gallery/42774743/Rustacean https://www.rustacean.net/ Image Credits Mrinal Wadhwa