Trust Architectures in IoT

Slide 1

Slide 1 text

Trust Architectures in the Internet of Things Mrinal Wadhwa CTO, Ockam mrinal

Slide 2

Slide 2 text

Dependable Systems Customers of IoT — individuals as well as businesses — want their connected systems to be dependable.

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

But everyday there is news about how risky and insecure IoT can be.

Slide 5

Slide 5 text

Even the most well funded teams seem to repeatedly fail at making IoT systems safe, private and reliable.

Slide 6

Slide 6 text

Insecure IoT systems can hurt reputation, disrupt operations, cause monitory losses, leak personal/proprietary data and even cause physical damage.

Slide 7

Slide 7 text

Our customers don’t want to rely on systems that expose them to such signi f i cant risks.

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Trust The willingness of our customers to rely on the information provided by and the automated actions taken by IoT systems.

Slide 10

Slide 10 text

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.

Slide 11

Slide 11 text

Over the years, I’ve come across many technical design choices that IoT system architects make to ensure their systems are trustworthy …

Slide 12

Slide 12 text

Some of these architectural choices are effective, but many are not …

Slide 13

Slide 13 text

Trust Architectures Architectural choices that ensure that various parts of a system can rely on each other.

Slide 14

Slide 14 text

All IoT systems, at a high level …

Slide 15

Slide 15 text

Sense One or many sensors capture some information from the physical world

Slide 16

Slide 16 text

Sense Communicate We communicate this information, as messages, to some location that has more compute power or more contextual data.

Slide 17

Slide 17 text

Sense Communicate Infer We then try to infer some meaning from the sensed data, that we’re receiving, combined with other contextual/historical data.

Slide 18

Slide 18 text

Sense Communicate Infer And use all of that information to make some decisions about what to do next.

Slide 19

Slide 19 text

Sense Communicate Infer Output In the process, we may display some derived information to end users.

Slide 20

Slide 20 text

Sense Communicate Infer Output Input Optionally, wait for some user input.

Slide 21

Slide 21 text

Sense Communicate Infer Output Input Then communicate the actions we want to take, as messages back to machines that can actuate our decision.

Slide 22

Slide 22 text

Sense Communicate Infer Act Output Input

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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.

Slide 25

Slide 25 text

Sense Communicate Infer Act Output Input All of these things are happening across a distributed system of connected machines.

Slide 26

Slide 26 text

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.

Slide 27

Slide 27 text

Trust Architectures Architectural choices that ensure that various parts of a system can rely on each other.

Slide 28

Slide 28 text

1. The “who cares” trust architecture.

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Instructions to take actions can be spoofed.

Slide 32

Slide 32 text

Acknowledgments of actions taken can be spoofed.

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

2. The ”trust in network boundaries” architecture.

Slide 37

Slide 37 text

The assumption that all systems and traffic within a network boundary can be trusted is flawed.

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Instructions to take actions can be spoofed.

Slide 43

Slide 43 text

Acknowledgments of actions taken can be spoofed.

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

• 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:

Slide 46

Slide 46 text

3. The ”trust in HTTPS” architecture.

Slide 47

Slide 47 text

Only cloud services are authenticated.

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Software update messages are harder to spoof, because devices authenticate cloud services.

Slide 50

Slide 50 text

Instructions to take actions are harder to spoof.

Slide 51

Slide 51 text

Acknowledgments of actions taken can be spoofed.

Slide 52

Slide 52 text

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.

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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.

Slide 55

Slide 55 text

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.

Slide 56

Slide 56 text

4. The ”trust in one-way authenticated TLS” architecture.

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

Garbage in, Garbage out.

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

Sometimes there are hardcoded admin credentials

Slide 61

Slide 61 text

No content

Slide 62

Slide 62 text

At other times there are hardcoded device authentication secrets.

Slide 63

Slide 63 text

Because all devices have the same secret, if one device is compromised, the situation becomes as bad as no device authentication.

Slide 64

Slide 64 text

5. The ”trust in OAuth” architecture.

Slide 65

Slide 65 text

OAuth 2.0 doesn’t provide authentication, it is a protocol for delegation of access.

Slide 66

Slide 66 text

5. The ”trust in network intermediaries” architecture.

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

Connected Outlet Connected Outlet Application Connected Outlet Service

Slide 69

Slide 69 text

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.

Slide 70

Slide 70 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 71

Slide 71 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 72

Slide 72 text

Heart Rate Monitor Heart Rate Application Heart Rate

Slide 73

Slide 73 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 74

Slide 74 text

D D D … Devices … … Gateways … Lighting HVAC Water Monitoring Elevators Access

Slide 75

Slide 75 text

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.