Trust Architectures in IoT

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.
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.
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.
58. Garbage in, Garbage out.
59. 5. The ”trust in hardcoded passwords/tokens” architecture.
60. Sometimes there are hardcoded admin credentials
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