24
Demo: Securing IoT with Trusted Computing Demo built by Cisco, Infineon and Intel, With the Assistance of HSR University of Applied Sciences, Rapperswil © 2015 Trusted Computing Group 1

Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

Embed Size (px)

Citation preview

Page 1: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

Demo: Securing IoT with Trusted

Computing

Demo built by Cisco, Infineon and Intel,

With the Assistance of

HSR University of Applied Sciences, Rapperswil

© 2015 Trusted Computing Group 1

Page 2: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

Agenda

• Introduction, problem statement and use case

• Description of the Demo

• Demo

© 2015 Trusted Computing Group 2

Page 3: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

© 2015 Trusted Computing Group 3

Introduction, problem statement and use case

Page 4: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

Introduction

• This demo is a proof of concept

• As a proof of concept, please let us know what you think of what you see

Problem Statement• Can we implement strong authentication between all

equipment in a network, not just of one endpoint to another?

• By definition, single factor authentication is weak, two or more factors of authentication is strong

© 2015 Trusted Computing Group 4

Page 5: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

Demo Use Case

• General Use Case: – A deployment of IoT devices (sensors and actuators)

– Central management for the IoT deployment is remote to the IoT devices, over an Internet

– Can we show that all equipment in the use case is owned by the customer and that the software on that equipment has not been changed?

• Specific example: Smart buildings– A smart building in Manhattan may have thousands of devices

like cameras, thermostats, HVAC actuators, etc.

– Central management for the building might be in a datacenter in Dallas.

– What can be done to enhance the security and trustworthiness of all of the devices, including network gear, in this example?

© 2015 Trusted Computing Group 5

Page 6: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

© 2015 Trusted Computing Group 6

Description of the Demo

Page 7: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

The Demo Equipment & Layout

Raspberry PiCisco CGR 1120

Cisco UCS 240 Server

Our IoT deploymentOur network gear

Our management server

Page 8: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

Authentication Flow Between rPi and CGR

© 2015 Trusted Computing Group 8

Raspberry Pi

Cisco CGR 1120

1. Start Session?2. Who are you? Can I

trust you?

3. Here are my identity

and TPM-signed integrity

information

4. Verify identity and

integrity (done locally)

6. Open SSL session to

Server through CGR 5. Session authorized

Page 9: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

Authentication Flow Between Server and CGR

© 2015 Trusted Computing Group 9

1. Start Session?

2. Who are you? Can I

trust you? Here are my

credentials

3. Verify identity and

integrity (done locally)

3. Verify identity and

integrity (done locally)

4. Session authorized 4. Session authorized

Cisco UCS 240 Server

Cisco CGR 1120

5. Open SSL session to rPi through CGR

Page 10: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

Authentication Architecture for TNC

© 2015 Trusted Computing Group 10

Raspberry Pi

Cisco CGR 1120

Integrity Measurement

CollectorIntegrity Measurement

Verifier

TNC IF-M (RFC 5792)

(Application layer)

TNC Client TNC ServerTNC IF-TNCCS (RFC 5793)

(Message Flow layer)

Network Access

RequestorNetwork Access

Authority

TNC IF-M (RFC 5792)

(Packet flow layer)

Page 11: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

Demo Network Topology

PT-TLS

Raspi 1

Raspi 6

Cisco CGR1120

UCS 7

UCS 9

HW TPM

IMA

PT-TLS

TNC Client

TNC Server

IMA

TNC Client

SW TPM

TBOOT

TNC Client

HW TPM

TBOOT

TNC Client

SW TPM

TBOOT

TNC ClientPT-TLS

PT-TLS

http

http

IoT Devices

TNC Mutual Attestation

Policy

DB

TNC 1-Way Attestation

Fake endpoint

Page 12: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

OK, Fine. Enough slides.

SHOW IT!

© 2015 Trusted Computing Group 12

Page 13: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

Sample Log Entries Showing System Start

© 2015 Trusted Computing Group 13

Page 14: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

Linux IMA to measure the OS

© 2015 Trusted Computing Group 14

• Prior to OS Load, the CRTM measures BIOS & boot loader into PCRs on the TPM

• Early in OS Load, Linux Integrity Management Architecture measures (hashes) a

policy-based list of files and directories.

• Each new hash is then extended into PCR 10

• The final aggregate hash in PCR 10 is the record of the state of the measured

files/directories at time of boot

• The quote of PCRs 0-7 and PCR 10 is the basis for TNC PDP to decide if the

supplicant OS is trusted

Snip of syslog showing IMA measuring file and extending measurements into PCR 10:

(easiest to follow the numbers, read right to left)

PCR used (10) New value stored in PCR 10 Hash of file Hashed File

3. 2. 1. 4.

Page 15: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

TNC Client Authentication – Certificate

Exchange

© 2015 Trusted Computing Group 15

Snippet of normal TLS certificate processing at session start, raspberry Pi

requesting session with a CGR.

Integrity validation follows certificate validation.

Page 16: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

Authentication continues with validation

of integrity report

© 2015 Trusted Computing Group 16

Snippet from syslog showing completion of integrity validation done by a

CGR against a raspberry Pi

TNC-based authentication of the rPi is now complete.

A normal TLS session can now be set up.

Page 17: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

© 2015 Trusted Computing Group 17

Done with syslog, now the GUI view.

This screen shows the policy-defined

list of directories and files that IMA will

measaure into PCR 10 on the rPi.

When the rPi authenticates to the

CGR, it provides a signed report of the

values in its PCRs, including PCR 10.

This list is also kept in the validation

server on the CGR, along with

expected values for each file and each

PCR.

The CGR only validates PCR

measurements, not individual file

measurements

Page 18: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

© 2015 Trusted Computing Group 18

Drill down on /bin directory, showing the files in /bin that are measured

into PCR 10.

The CGR will match the reported PCR 10 against the expected PCR to

decide if the CGR trusts the OS running on rPi.

Page 19: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

© 2015 Trusted Computing Group 19

Final drill down – the SHA1 and SHA256 hash values that the CGR uses as golden values

(customer selects which algorithm to use).

Remember that on the rPi, all these files are individually hashed (measured), then the hash

extended into PCR 10 with all other hashes.

The CGR has a golden measurement for each file. It also has a golden measurement that

represents the consolidated measurements of all the files consolidated in PCR 10.

At authentication, the CGR validates either each file measurement or only the consolidated

set reported in PCR 10 by the rPi.

Page 20: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

20

Next we look at the device report for devices currently connected to the CGR

This is a drill down on Raspi 2. Under Device Info, note the ID.

The ID is the SHA256 hash of Raspi 2’s AIK Public Key. The AIK private key is protected

within Raspi 2’s TPM.

This Proof of Concept uses the hash of the AIK public key as a unique, hardware protected

identity for Raspi 2.

Hash of Raspi 2’s AIK public key

Device report, next

Page 21: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

General report for Raspi 2

© 2015 Trusted Computing Group 21

Click here to see details

of the last session

Page 22: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

22

TPM IMA on the rPi reporting 299 measurements

Based on policy in the CGR,

The CGR is validating every file. It expects 288 and finds them to be correct

It finds 299 measurements and ignores the 11 unknown

“0 Failed” means that Raspi 2 is allowed to connect in this case

The “11 unknown” means there is a mismatch between what the Raspi 2 is reporting

and what the CGR is expecting. If CGR is matching only on PCR 10, this would have

been a “1 failed” condition and the session would not be allowed.

Connection attempt by Raspi

2 was allowed

Page 23: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

What a server connection looks like on the CGR

© 2015 Trusted Computing Group 23

Measurements of Linux follows TBOOT,

assuming that the TPM quote is obtained

through TXT running on the server

Server measurements are in PCRs 17

and 18 for Linux, therefore 2 evidence

measurements are evaluated

Page 24: Demo: Securing IoT with Trusted Computing · Demo: Securing IoT with Trusted Computing Demo built by Cisco, ... This Proof of Concept uses the hash of the AIK public key as a unique,

Done & Summary

• This demo addresses a broad current of convergence occurring between the IoT & Cloud markets.

• We’ve seen

– All devices in the demo employ multi-factor authentication to decide whether a device can join the network or not.

– That dedicated HW protects authentication credentials from end to end.

– Two implementations of this authentication –• One-way, the rPi to the CGR, the rPi implicitly trusts the CGR

• Two-way, the CGR & the server – no implicit trust is required.

– A policy based mechanism for the customer to specify what software on the devices must maintain integrity and what happens when integrity is lost.

• The result is that devices in this network organize themselves into a closed communication path based on validation of HW protected identity and integrity information

© 2015 Trusted Computing Group 24