Demo: Securing IoT with Trusted Computing

Transcription

1 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

2 Agenda Introduction, problem statement and use case Description of the Demo Demo 2015 Trusted Computing Group 2

3 Introduction, problem statement and use case 2015 Trusted Computing Group 3

4 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

5 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

6 Description of the Demo 2015 Trusted Computing Group 6

7 The Demo Equipment & Layout Raspberry Pi Cisco CGR 1120 Our IoT deployment Our network gear Cisco UCS 240 Server Our management server

8 Authentication Flow Between rpi and CGR Raspberry Pi Cisco CGR 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 2015 Trusted Computing Group 8

9 Authentication Flow Between Server and CGR Cisco UCS 240 Server Cisco CGR 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 5. Open SSL session to rpi through CGR 2015 Trusted Computing Group 9

10 Authentication Architecture for TNC Raspberry Pi Cisco CGR 1120 Integrity Measurement Collector TNC IF-M (RFC 5792) (Application layer) Integrity Measurement Verifier TNC Client TNC IF-TNCCS (RFC 5793) (Message Flow layer) TNC Server Network Access Requestor TNC IF-M (RFC 5792) (Packet flow layer) Network Access Authority 2015 Trusted Computing Group 10

11 IoT Devices Raspi 1 Demo Network Topology Cisco CGR1120 UCS 7 http TNC Client HW TPM IMA PT-TLS Policy DB PT-TLS TNC Client SW TPM TBOOT TNC 1-Way Attestation TNC Server TNC Mutual Attestation Raspi 6 UCS 9 TNC Client Fake endpoint IMA PT-TLS TNC Client SW TPM TBOOT PT-TLS http TNC Client HW TPM TBOOT

12 OK, Fine. Enough slides. SHOW IT! 2015 Trusted Computing Group 12

13 Sample Log Entries Showing System Start 2015 Trusted Computing Group 13

14 Linux IMA to measure the OS 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 2015 Trusted Computing Group 14

15 TNC Client Authentication Certificate Exchange Snippet of normal TLS certificate processing at session start, raspberry Pi requesting session with a CGR. Integrity validation follows certificate validation Trusted Computing Group 15

16 Authentication continues with validation of integrity report 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 Trusted Computing Group 16

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 2015 Trusted Computing Group 17

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 Trusted Computing Group 18

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 Trusted Computing Group 19

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 20

21 General report for Raspi 2 Click here to see details of the last session 2015 Trusted Computing Group 21

22 Connection attempt by Raspi 2 was allowed 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. 22

23 What a server connection looks like on the CGR 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 2015 Trusted Computing Group 23

24 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