Embedded Trusted Computing on ARM-based systems

Transcription

1 1 / 26 Embedded Trusted Computing on ARM-based systems Martin Schramm, M.Eng

2 Agenda 2 of 26 martin.schramm@th-deg.de

3 Embedded computing platforms have become omnipresent intend to alleviate everyday life up and running in a 24/7 manner applications with high requirements for safety, security and privacy industrial automation medical automotive well-defined hardware and software components cost pressure ease of development arising problems regarding system security attacker effort is considerably reduced tremendous financial damage physical injury loss of human lives 3 of 26 martin.schramm@th-deg.de

4 Trusted Platform Module usually connected via LPC Bus Roots of Trust (RTS, RTR and RTM) CRTM implemented in BIOS Well-defined 4 of 26 martin.schramm@th-deg.de

5 PCR: PCR usage: 0 CRTM, BIOS and Platform Extensions 1 Platform Configuration 2 Option ROM Code 3 Option ROM Configuration and Data 4 IPL Code (usually the MBR) 5 IPL Configuration and Data (for use by the IPL Code) 6 State Transition and Wake Events 7 Host Platform Manufacturer Control 8-15 Defined for use by the Static Operating System 16 Debug Defined for use by the Dynamic Operating System BIOS part often poorly implemented User often has no insight of what is going on 5 of 26 martin.schramm@th-deg.de

6 TPM connected via embedded interface (e.g. I 2 C) Unique identification possible Lack of BIOS on ARM-based systems Root of Trust for Measurement must be redefined New Core Root of Trust for Measurement concept needed must be guaranteed 6 of 26 martin.schramm@th-deg.de

7 Freescale High Assurance Boot Implemented in Boot ROM Based on signed code execution Validation of efuses Reset Subsystem Security Bootloader CSF HAB Library i.mx Boot Rom Boot Device Driver Device Driver Boot Stages First Second Third Bootloader TPM Boot Device Driver OS Policy OS 7 of 26 martin.schramm@th-deg.de

8 Freescale High Assurance Boot Secure Boot capability HAB Library in Boot ROM is CRTM RTM comprised by enhanced Bootloader RTS and RTR located inside of the TPM Manufacturer has to be trusted 8 of 26 martin.schramm@th-deg.de

9 U-Boot Verified Boot Uses Flattened uimage Tree (FIT) images { kernel@1 { data = <data for kernel1 > signature@1 { algo = " sha1, rsa2048 " ; value = <... k e r n e l s i g n a t u r e 1... > } ; } ; fdt@1 { data = <data for fdt1 >; signature@1 { algo = " sha1, rsa2048 " ; vaue = <... f d t s i g n a t u r e 1... > } ; } ; } ; Sign images in FIT Hash an image in the FIT Sign the hash Store resulting signature in the FIT Verify the images Read the FIT and obtain public key Extract the signature from FIT and hash image Verify the signature 9 of 26 martin.schramm@th-deg.de

10 U-Boot Verified Boot Public key must be trusted Stored in U-Boot s control Flattened Device Tree (FDT) Secure field-upgrades are possible U-Boot must be loaded from read-only memory (CRTM) Chaining images possible Signed configurations possible c o n f i g u r a t i o n s { default = " conf@1 " ; conf@1 { kernel = " kernel@1 " ; f d t = " fdt@1 " ; signature@1 { algo = " sha1, rsa2048 " ; key name hint = " dev " ; sign images = " f d t ", " k ernel " ; } ; } ; } ; 10 of 26 martin.schramm@th-deg.de

11 libsboot libsboot, libtlcl and TPM drivers Secure Boot example for pre-os boot environment U-Boot binary loaded by a Second Phase Loader (SPL) EEPROM defining platform indentification and configuration Environment data read from an initial external source Environment variables set via the U-Boot console Flattened Device Tree files Initial Ram Disks An OS kernel Initialization of libsboot occurs from ROM code Initialization of TPM in SPL Verification that PCRs are reset Asserts Physical Presence 11 of 26 martin.schramm@th-deg.de

12 libsboot Sealed data stored in TPM NVRAM Pre-execution of U-Boot OS kernel System only boots after successfull unseal operation Extend PCRs with random data after measurements/error Trustworthy modifications of U-Boot are difficult Signature based approach possible 12 of 26

13 I HAB + TPM 13 of 26 martin.schramm@th-deg.de

14 I U-Boot verified Boot 14 of 26

15 libsboot 15 of 26

16 PCR: Possible PCR usage: 0 U-Boot image 1 U-Boot environment variables 2 U-Boot typed in commands 3 Kernel FDT 4 Initial RAM Disk 5 OS kernel image 6 reserved for further use 7 reserved for further use 8-15 Defined for use by the Static Operating System 16 Debug Defined for use by the Dynamic Operating System 16 of 26 martin.schramm@th-deg.de

17 Embedded devices might be uniquely identified Endorsement Key certificate Hash of public Endorsement Key Barcode of public EK Hash Easy exchange of Trustworthy devices 17 of 26

18 What if signed image gets compromised? TPM chip features monotonic counters Can be used to implement rollback counters Rolling back an older signed firmware can be mitigated 18 of 26

19 I requires authentic AIK key I I PrivacyCA (online verification) AIK direct proof (offline verification) 19 of 26 martin.schramm@th-deg.de

20 via TPM_QUOTE 20 of 26

21 Possibility to certify any key in the TPM key hierarchy 21 of 26

22 Prevent compromise of the hosts that connect to a network Based on extended attributes such as platform authentication, endpoint compliance or software state information Policy for assessment, isolation and remediation needed Common three party model: Access Requester (AR), Policy Decision Point (PDP) and Policy Enforcement Point (PEP) AR might be a VPN Client or IEEE 802.1X Supplicant AR s request processed by PDP which might be a software component or a RADIUS server PDP reports its decision (access granted or denied) to a PEP PEP might be a VPN gateway, switch, firewall or IEEE 802.1X Access Point 22 of 26 martin.schramm@th-deg.de

23 23 of 26

24 24 of 26

25 Manifold application areas of embedded devices Urgent need for sophisticated security solutions must be guaranteed Unique identification and anti-rollback possible Well-defined policies are of great importance Security versus Usability! 25 of 26

26 Thank you for your attention! 26 of 26