Presentation is loading. Please wait.

Presentation is loading. Please wait.

Applying ‘Trusted Brokered IO’ as trust boundary and policy enforcement point in Hardware for IoT devices For the Trusted Computing.

Similar presentations


Presentation on theme: "Applying ‘Trusted Brokered IO’ as trust boundary and policy enforcement point in Hardware for IoT devices For the Trusted Computing."— Presentation transcript:

1 Applying ‘Trusted Brokered IO’ as trust boundary and policy enforcement point in Hardware for IoT devices Stefan.Thom@Microsoft.com For the Trusted Computing Group

2 …and now that your buzzword Bingo card is already half full, the more pragmatic title: How to prevent your device from becoming a ‘Brain in a Jar’

3 IoT devices are all the rave today! 3

4 The unavoidable hangover is looming 4 Our life is filled with myriads of devices Devices are deployed in hard to reach places Everyone single one needs special attention Which ones are really mine? Yesterday it worked today it doesn’t – What happened? How do I replace or dispose a device? Which device has access to what? Cloud consumes huge amounts of questionable data Who else lives on my devices?

5 What does it take? 5 Isolated execution – Either by time or physical isolation Strong Device Identity – Cryptographic Endorsement Key Sealed Storage – Encrypted and bound to separate trust boundaries Attestation – Allows 3 rd parties to form trust relationships Policy Bound Operation – Device and user policies are enforced

6 Divide and Conquer 6 Security starts in the platform hardware Apply principle of least privilege to your device Enforce defined parameters of operation Trust nobody, especially not your own code The design process starts with security and cannot be added with a firmware update  Create strong defendable trust boundaries inside your device

7 What does it take? 7 Isolated execution – Either by time or physical isolation Strong Device Identity – Cryptographic Endorsement Key Sealed Storage – Encrypted and bound to separate trust boundaries Attestation – Allows 3 rd parties to form trust relationships Policy Bound Operation – Device and user policies are enforced

8 Who the hell are you?!? 8 No, a MAC address is not a good device identity and some GUID in flash memory is also useless A secret seed inaccessible to software Only accessible by policy restricted hardware Can never be read directly or indirectly Is used as a key in a cryptographic algorithm Can be used to re-establish trust after a break-in Backed by manufacturer identity service or certificate  Employ Cryptographic Endorsement Key

9 What does it take? 9 Isolated execution – Either by time or physical isolation Strong Device Identity – Cryptographic Endorsement Key Sealed Storage – Encrypted and bound to separate trust boundaries Attestation – Allows 3 rd parties to form trust relationships Policy Bound Operation – Device and user policies are enforced

10 Keeping the lid on things 10 How to protect data at rest against offline attacks? Differentiating between using keys and reading them Controlled object migration in and out of the device Immutable persisted storage with individual read, write and lockout policies  Sealed and Protected Storage

11 What does it take? 11 Isolated execution – Either by time or physical isolation Strong Device Identity – Cryptographic Endorsement Key Sealed Storage – Encrypted and bound to separate trust boundaries Attestation – Allows 3 rd parties to form trust relationships Policy Bound Operation – Device and user policies are enforced

12 Mom said to always tell the truth 12 Only device reset, resets security posture Secure logging facility to measure device state Attestation of objects, persisted storage and state with trusted identities  Trusted Reporting and Attestation

13 What does it take? 13 Isolated execution – Either by time or physical isolation Strong Device Identity – Cryptographic Endorsement Key Sealed Storage – Encrypted and bound to separate trust boundaries Attestation – Allows 3 rd parties to form trust relationships Policy Bound Operation – Device and user policies are enforced

14 Having a reality check 14 Ensure linear forward progression of time Dictionary attack protection Secure monotonic counting BitFields that behave like fuses Algorithm and usage restrictions on keys Flexible object authorization policies  Policy bound operation

15 …and what else? 15 A good entropy source is also a nice thing.

16 What can a TPM do for a modern MCU? 16 Immutable boot loader (CRTM) Secure seeding of an internal PRNG Manufacturer authenticated platform boot Measured boot as tamperproof record of code and data Establishing ownership and device identity generation Attestation client to report device state Confidential storage of device configuration Secure identity and data protection key import Firmware rollback protection Secure forward migration of configuration data There is actually a lot more down here but unfortunately the slide cut that off…

17 …so it looks something like this 17 MCU TPM CRTM Physically and cryptographically bound Device Firmware aka Payload Device Firmware aka Payload Bootloader IO control Service hookup

18 Now, what is this Trusted Brokered IO thing? 18 If you are still sitting in the audience I assume that at least to some degree you bought into the 5 bullets of the “What does it take” slide. - Good, and let me thank you at this point already - Now we are going off the deep end: So far we created a MCU that adheres to the TCG software platform – This means we are done, right? Everything is secure, right? In a perfect world where software ships free of bugs, processors can interpret the developers intentions and nobody hacks devices on the internet, then by all means yes absolutely! Lets go home early today.

19 Let’s look at that picture again… 19 MCU TPM CRTM Device Firmware aka Payload Device Firmware aka Payload Bootloader Trustboundary

20 Let’s look at that picture again… 20 MCU TPM CRTM Device Firmware aka Payload Device Firmware aka Payload Bootloader Trustboundary Turn on gas, wait 30 minutes, ignite.

21 Let’s look at that picture again… 21 MCU TPM CRTM Device Firmware aka Payload Device Firmware aka Payload Bootloader Trustboundary

22 Why can’t we apply policies to IO? 22 If it is good for software why not also apply it to the hardware? Apply hard formulated policies on IO operations that the MCU cannot override Revoke MCU access from critical IO if the MCU is in an unknown state Provide IO override policy for authorized entities Provide data attestation on data that the MCU reads IoT device data with attached attestation meta data provides trust level Reduction of attack surface for high integrity IO devices  The TPM library specification defines GPIO pins for this purpose

23 Trusted Brokered IO 23 Trustboundary MCU TPM CRTM Device Firmware aka Payload Device Firmware aka Payload Bootloader PrivilegedIO: Igniter and fuel control Display, knobs and oven light PEP AttestedIO: Oven State

24 Demo: Trusted Door 24

25 Questions? 25


Download ppt "Applying ‘Trusted Brokered IO’ as trust boundary and policy enforcement point in Hardware for IoT devices For the Trusted Computing."

Similar presentations


Ads by Google