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

Trust Architectures in IoT

Mrinal Wadhwa
December 02, 2020

Trust Architectures in IoT

Mrinal Wadhwa

December 02, 2020

More Decks by Mrinal Wadhwa

Other Decks in Technology


  1. Dependable Systems Customers of IoT — individuals as well as

    businesses — want their connected systems to be dependable.
  2. They want to depend on these systems for use cases

    that are critical for their business, health and safety. IoT will have an economic impact between $4 trillion and $11 trillion, by 2025. Source: McKinsey & Company
  3. Even the most well funded teams seem to repeatedly fail

    at making IoT systems safe, private and reliable.
  4. Insecure IoT systems can hurt reputation, disrupt operations, cause monitory

    losses, leak personal/proprietary data and even cause physical damage.
  5. Trust The willingness of our customers to rely on the

    information provided by and the automated actions taken by IoT systems.
  6. To have an IoT system that is dependable, as a

    whole, we have to ensure that various distributed parts of our system can depend on each other.
  7. Over the years, I’ve come across many technical design choices

    that IoT system architects make to ensure their systems are trustworthy …
  8. Sense Communicate We communicate this information, as messages, to some

    location that has more compute power or more contextual data.
  9. Sense Communicate Infer We then try to infer some meaning

    from the sensed data, that we’re receiving, combined with other contextual/historical data.
  10. Sense Communicate Infer And use all of that information to

    make some decisions about what to do next.
  11. Sense Communicate Infer Output In the process, we may display

    some derived information to end users.
  12. Sense Communicate Infer Output Input Then communicate the actions we

    want to take, as messages back to machines that can actuate our decision.
  13. Sense Communicate Infer Act Output Input Sensing machines also need

    con f i guration and software updates, the data f l ow is usually bi-directional.
  14. Sense Communicate Infer Act Output Input All of these things

    are happening across a distributed system of connected machines.
  15. For the system, as a whole, to be dependable, various

    machines that sense, infer and act in the system must be able to rely on information provided by and actions taken by other machines in the system.
  16. A lot of people say their Industrial Control Systems are

    air-gapped but what they mean is they think they are air-gapped. – Andrew Tierney: Pwning an oil rig, DEF CON 27 creativecommons.org/licenses/by/3.0/legalcode youtube.com/watch?v=JoJ6uzIsQNs
  17. • The network is always assumed to be hostile. •

    External and internal threats exist on the network at all times. • Network locality is not sufficient for deciding trust in a network. • Every device, user, and network flow is authenticated and authorized. • Policies must be dynamic & calculated from as many sources of data as possible. Zero Trust in network perimeters. A zero trust network is built upon five fundamental assertions:
  18. Let’s dig into how this trust in the server’s identity

    is established: A device has a root trust store. Typically, on Linux machines, this is the Mozilla Firefox browsers root store. This has 148 trusted parties. These 148 parties are free to create subordinate trusted parties, there are 1000s of trusted parties.
  19. If the defaults are followed any one of these 1000s

    of parties could issue a seemingly valid certificate that a device would believe is about the intended server. Major certificate authority breaches happen. Spoofed Server Identity feistyduck.com/ssl-tls-and-pki-history
  20. This trust model is okay for web browsers because they

    have to trust lots of websites and they run complex infrastructure to identify breaches and manage revocation.
  21. IoT devices shouldn’t rely on the WebPKI. There should instead

    be an application controlled public key infrastructure that manages key lifecycle, revocation and pinned chains of trust.
  22. Because all devices have the same secret, if one device

    is compromised, the situation becomes as bad as no device authentication.
  23. Heart Rate Monitor Heart Rate Application Heart Rate Service 80

    bpm 0x217c5111… 80 bpm 0x8621f842… 80 bpm Transport Layer Security Transport Layer Security
  24. 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.
  25. 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.
  26. 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 “
  27. 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
  28. D D D … Devices … … Gateways … Lighting

    HVAC Water Monitoring Elevators Access
  29. To build dependable systems: 1. Unique keys in every machine.

    2. Keys safely provisioned, stored, rotated, revoked. 3. End-to-end mutual authentication at the application layer. 4. End-to-end guarantee of data integrity. 5. End-to-end guarantee of data con f i dentiality. 6. Granular management of credentials, enforcement of policies.