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
Tweet

More Decks by Mrinal Wadhwa

Other Decks in Technology

Transcript

  1. Trust Architectures in the Internet of Things Mrinal Wadhwa CTO,

    Ockam mrinal
  2. Dependable Systems Customers of IoT — individuals as well as

    businesses — want their connected systems to be dependable.
  3. 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
  4. But everyday there is news about how risky and insecure

    IoT can be.
  5. Even the most well funded teams seem to repeatedly fail

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

    losses, leak personal/proprietary data and even cause physical damage.
  7. Our customers don’t want to rely on systems that expose

    them to such signi f i cant risks.
  8. Trust The willingness of one party to rely on the

    actions of another party.
  9. Trust The willingness of our customers to rely on the

    information provided by and the automated actions taken by IoT systems.
  10. 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.
  11. Over the years, I’ve come across many technical design choices

    that IoT system architects make to ensure their systems are trustworthy …
  12. Some of these architectural choices are effective, but many are

    not …
  13. Trust Architectures Architectural choices that ensure that various parts of

    a system can rely on each other.
  14. All IoT systems, at a high level …

  15. Sense One or many sensors capture some information from the

    physical world
  16. Sense Communicate We communicate this information, as messages, to some

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

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

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

    some derived information to end users.
  20. Sense Communicate Infer Output Input Optionally, wait for some user

    input.
  21. Sense Communicate Infer Output Input Then communicate the actions we

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

  23. Sense Communicate Infer Act Output Input Acknowledge the action was

    taken.
  24. 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.
  25. Sense Communicate Infer Act Output Input All of these things

    are happening across a distributed system of connected machines.
  26. 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.
  27. Trust Architectures Architectural choices that ensure that various parts of

    a system can rely on each other.
  28. 1. The “who cares” trust architecture.

  29. There is no authentication o sensors, sensed data can be

    spoofed.
  30. Software update messages can be spoofed, because devices cannot authenticate

    cloud services.
  31. Instructions to take actions can be spoofed.

  32. Acknowledgments of actions taken can be spoofed.

  33. No authentication, no data integrity, no con f i dentiality.

  34. None
  35. None
  36. 2. The ”trust in network boundaries” architecture.

  37. The assumption that all systems and traffic within a network

    boundary can be trusted is flawed.
  38. 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
  39. No authentication, no data integrity, no con f i dentiality.

  40. There is no authentication o sensors, sensed data can be

    spoofed.
  41. Software update messages can be spoofed, because devices cannot authenticate

    cloud services.
  42. Instructions to take actions can be spoofed.

  43. Acknowledgments of actions taken can be spoofed.

  44. None
  45. • 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:
  46. 3. The ”trust in HTTPS” architecture.

  47. Only cloud services are authenticated.

  48. There is no authentication of sensors, sensed data can be

    spoofed.
  49. Software update messages are harder to spoof, because devices authenticate

    cloud services.
  50. Instructions to take actions are harder to spoof.

  51. Acknowledgments of actions taken can be spoofed.

  52. 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.
  53. 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
  54. 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.
  55. 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.
  56. 4. The ”trust in one-way authenticated TLS” architecture.

  57. None
  58. Garbage in, Garbage out.

  59. 5. The ”trust in hardcoded passwords/tokens” architecture.

  60. Sometimes there are hardcoded admin credentials

  61. None
  62. At other times there are hardcoded device authentication secrets.

  63. Because all devices have the same secret, if one device

    is compromised, the situation becomes as bad as no device authentication.
  64. 5. The ”trust in OAuth” architecture.

  65. OAuth 2.0 doesn’t provide authentication, it is a protocol for

    delegation of access.
  66. 5. The ”trust in network intermediaries” architecture.

  67. Heart Rate Monitor Heart Rate Application Heart Rate Service 80

    bpm 0x217c5111… 80 bpm 0x8621f842… 80 bpm Transport Layer Security Transport Layer Security
  68. Connected Outlet Connected Outlet Application Connected Outlet Service

  69. 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.
  70. 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.
  71. 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 “
  72. Heart Rate Monitor Heart Rate Application Heart Rate

  73. 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
  74. D D D … Devices … … Gateways … Lighting

    HVAC Water Monitoring Elevators Access
  75. 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.
  76. Security, Privacy and Trust are application layer concerns.

  77. Ockam Ockam

  78. Mrinal Wadhwa CTO, Ockam mrinal github.com/ockam-network/ockam