Demonstration of the use of strong authentication between embedded systems and traditional endpoints on a network using Trusted Computing Group standards and technology. Presented by Stacy Cannady at Security of Things Forum, Sept. 10 2015.

1. Demo: Securing IoT with
Trustworthy Computing
l
© 2015 Trusted Computing Group 1

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

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

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. © 2015 Trusted Computing Group 6
Description of the Demo

7. What the Demo Shows
• Strong authentication in Machine to Machine
(M2M) communications
– Uses certificate and integrity validation
• M2M authentication is point to point across a
network, including auth of routers to end points
– No implicit trust is required in this demo
• Authentication is policy-based, locally enforced
© 2015 Trusted Computing Group 7

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

9. Authentication Flow Between rPi and CGR
© 2015 Trusted Computing Group 9
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

10. Authentication Flow Between Server and CGR
© 2015 Trusted Computing Group 10
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

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

12. 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 Client
PT-TLS
PT-TLS
http
http
IoT Devices
TNC Mutual Attestation
Policy
DB
TNC 1-Way Attestation
Fake endpoint

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

14. Sample Log Entries Showing System Start
© 2015 Trusted Computing Group 14

15. Linux IMA to measure the OS
© 2015 Trusted Computing Group 15
• 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.

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

17. Authentication continues with validation
of integrity report
© 2015 Trusted Computing Group 17
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.

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

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

20. © 2015 Trusted Computing Group 20
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.

21. 21
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

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

23. 23
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

24. Whoops! What happened here?
Here we are. One IMA
generated hash was found to be
different. Under the policy for
this device, that is not
acceptable.

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

26. 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 26