Embedded System Security

Transcription

1 Assignments for the Course Embedded System Security Prof. Dr.-Ing. Ahmad-Reza Sadeghi Last updated: May 10, 2012 Authors: Sven Bugiel Based on ETISS 10 MobileLab of Kurt Dietrich (TU Graz) and Jan-Erik Ekberg (Nokia Research Center)

2

3 3 Exercise (30 points): Mobile Trusted Platform (MTM) Contents 3.1 Theoretical Assignments (30 Points) Practical Assignments Initialization of the SD card image Secure Boot RIM Certificates Compromised Boot Image Monotonic Counter Binding The Stakeholder Model Motivation and goals: Goal of this exercise is to give you basic practical skills for working with the Mobile Trusted Module (MTM). In particular, the purpose and usage of RIM certificates in the context of secure boot and the MTM stakeholder model is explained. Procedure: The exercise is split into two parts: theoretical and practical. The theoretical exercises have to be solved until Friday, 24 May 2012, and be handed in at that date (either during the lecture or via to sven.bugiel@trust.cased.de). The practical exercises will take place in the System Security Lab at CASED (Room ). You will do practical exercises under supervision and questions will be solved together. Note that the questions discussed in the practical exercises are also relevant for the exam! 1

4 3.1 Theoretical Assignments (30 Points) Differences between TPM and MTM (9 Points) 1. Name three major differences between the design of the Trusted Platform Module (TPM) and the Mobile Trusted Module (MTM). For each explain briefly the motivation for this difference. Stakeholder Model and Trusted Engines (13Points) 1. What are the two defined profiles for an MTM? Explain briefly their differences. 2. List the principle stakeholders on a mobile platform, the domain of their engine and the MTM profile their engine must have. 3. Illustrate how the Trusted Engines of the different stakeholders relate to each other and how the services/mtm within each domain build on each other. 4. What is the difference between an trusted and a measured resource? How can they be used to build allocated and dedicated Roots-of-Trust? RIM Certificates and Secure Boot (8 Points) 1. List the contents of a RIM certificate and explain very briefly their respective purpose. 2. How can RIM certificates be used to implement a secure boot with MTM? (Hint: An illustration suffices) 3. Explain briefly why for certain stakeholders a secure boot is mandatory and an authenticated boot is not permitted. 2

5 3.2 Practical Assignments This practical assignment is based on the ETISS 2010 Mobile Trusted Platform Lab by Kurt Dietrich and Johannes Winter (TU Graz) and Jan-Erik Ekberg (Nokia Resaerch Center) Initialization of the SD card image In this task you will become familiar with the environment, the tools and the basic knowledge for starting the emulation. Moreover, you will see how the secure boot concepts works. First, configure your shell to provide the required commands. Remember to first perform these two commands in all new shells you need during this lab! $ cd mobilelab $ source s e t t i n g s. sh Before starting with the lab exercises you need to create the SD card image used to hold the root filesystem of the simulated mobile platform: $ mobilelab buildimage Secure Boot 1. Get familiar with the environment. All tasks are performed in the mobilelab directory. This directory contains the following subdirectories that are relevant for the exercise: /images/ /base/ contains the boot images (u-boot.signed, u-boot.unsigned) /hello/ contains demo application (hello) /stake/ contains demo applications (app-a,..., app-c) /keys/ contains the system keys (base.priv.pem, incbootstrap.priv.pem, etc.) /rims/ contains the increment bootstrap counter certificates /settings.sh contains the environment variables setup 2. Start the image provided and see what s happening during the secure boot. First, start the MTM emulation via $ cd mobilelab && s ource s e t t i n g s. sh $ mtm s t a r t d The bootup can take some time and may sometimes seem to be hanging, so please be patient and don t abort prematurely! 3

6 Second, open a second shell and start the image. We assume to boot the mobile platform from an SD card. The boot image can be found in the file sdcard.bin, so use $ source s e t t i n g s. sh $ qemu s t a r t sd sdcard. bin to start the image. 3. What can be observed in the MTM emulator output during bootup of the image? 4. Login ( root, no password). 5. Shutdown the image ( halt, wait for System halted message) and the emulation (Ctrl+a c. enter quit into the qemu console). Note that is is required to restart the MTM emulator before every new task, thus manually resetting the MTM state as would have been done by hardware/software for a real MTM RIM Certificates The boot images in this exercise are delivered together with a Reference Integrity Metric (RIM) certificate. In the section previous, we have seen how this certificates are used for secure boot. In this section, you will learn how to create your own RIM certificate, thereby signing a specific boot image. 1. Launch the image as described in Task (Do not forget to restart the MTM emulator before starting the image!) 2. Open new a shell and copy the hello application to the mobile platform via logging into the running platform (execute the following in the mobilelab directory don t forget source settings.sh) $ s f t p qemu and then executing $ put images / h e l l o / h e l l o in order to upload the application to the platform. 3. Log into the mobile platform and try to start the hello application located in the /home/root directory. What is the result and why? 4. Create a new RIM certificate for the application (use the system s base key located in /keys/base.priv.prm for the signature on the certificate). Open a new shell on the PC (remember to run source settings.sh) and create the certificate by using the RIM tool: 4

7 $ r i m t o o l r i m c r e a t e o myhello. rim k keys / base. p r i v. pem t \ images / h e l l o / h e l l o p 1 5. Copy the RIM certificate to the mobile platform (with sftp-qemu). Execute./hello in order to find out the correct name for the RIM file (i.e., the hash value of the binary) and copy the myhello.rim file to the /rim/certs/ while renaming it to the correct name. $ cp myhello. rim /rim/ c e r t s / c3c f 3 6. Launch./hello again and test if the certificate and binary are validated correctly Compromised Boot Image In this task, the effects on the boot process are demonstrated, when one of the boot images is (maliciously) modified. 1. Shutdown the emulation, restart the MTM daemon and make a copy of the boot image. Execute $ cp images / base /u boot. s i gned. to copy the boot image to the current location. Also, restart the MTM emulator. 2. Modify the boot image to simulate a malicious boot image. Execute $ ghex2 u boot. s igned and alter some bytes from the bootloader and $ mcopy u boot. s igned a : u boot. bin to copy the modified bootloader to the SD card image (press o to overwrite the old loader). 3. Reboot the image. What is the result of the boot and why? 4. Install a new good bootloader and create a RIM certificate for this bootloader. Moreover, the bootloader should print out a customized message to show that it is your bootloader that is running. Execute $ cp images / base /u boot. unsigned. to copy the bootimage to the current location and edit it with $ ghex2 u boot. unsigned 5

8 Go to line 0x00027AAx and modify the content. You can modify all characters fo the following line U-Boot rc1-drty (Aug :14:26 (see man ascii for character hex codes). Do not delete any characters! If you did so, run this step again! 5. Create a new RIM certifcate and embed it in the bootloader. Execute $ r i m t o o l r i m c r e a t e o u boot. rim k keys / base. p r i v. pem t \ u boot. unsigned p 1 x u boot. unsigned to create the certificate using the system s base key. Embed the certificate in the image via $ embedrim i u boot. unsigned o u boot. bin r u boot. rim v \ keys / base. vkey What is the MTM key type of base.vkey? (Hint: Use the help message of the embedrim command) 6. Install the new bootloader in sdcard.bin via $ mcopy u boot. bin a : u boot. bin and boot the image. Confirm that you see your new boot message! It should be at the beginning of the output, just before the OMAP messages. Then shutdown the mobile platform and restart the MTM emulator Monotonic Counter Binding The binding of RIM certificates to monotonic counters provides an elegant way to revoke RIM certificates and with them specific software images. In this task you learn how to create RIM certificates that are bound to such a counter and see what happens if this counter is increased. 1. Issue a new RIM certificate for hello including counter binding. Use $ r i m t o o l r i m c r e a t e o h e l l o. rim k keys / base. p r i v. pem t \ images / h e l l o / h e l l o p 1 s 1 c 1 to create a certificate. What is the name of the bound counter and which value must this counter have at most? (Hint: Use the help message of the rimtool command) 2. Upload the RIM certificate, the increment-counter-certificate-verification-key, and the increment-counter-certificate on the platform (with sftp-qemu): $ put h e l l o. rim $ put keys / i n c b o o t s t r a p. vkey $ put rims / i n c b o o t s t r a p 2. rim 6

9 Start the MTM software stack on the mobile platform (login as root and run the command), so that user applications can access the MTM. $ tcsd 3. Load the verification key for the RIM certificate that is bound to the counter. Copy the new RIM certificate over the old certificate in /rim/certs $ cp h e l l o. rim /rim/ c e r t s / c3c f 3 Clear the RIM cache of the system via $ echo 1 > / sys / k e r n e l /mtm/ drop rim cache Load the verification key for the increase counter RIM certificate: $ mtmtool loadvkey k i n c b o o t s t r a p. vkey 4. Execute hello to check if it still works and the increase the counter: $ mtmtool i n c r p 3 i i n c b o o t s t r a p 2. rim 5. Execute hello once more to confirm that it fails. 6. Shutdown the mobile platform and restart the MTM emulator The Stakeholder Model In this task you will focus on the stakeholder model. Different parties might want to install images on the platform. These images might depend on each other or they might exclude each other, meaning that a certain image from one vendor will not boot if a certain image from another vendor was loaded. 1. Create RIM certificates for app-a, app-b, app-b-star, app-c try to find a solution so that app-c requires app-a and app-b to be started first. Use $ r i m t o o l rimc o app a. rim k keys / base. p r i v. pem p 0 x i 1 \ m 0 xabe4fe5b20ce385fe b50fc9e7de222df x \ images / s t a k e / app a 1 : 0 x to create a new certificate that requires PCR1 to have 0x (40 zeros!) so that app-a can be launched. Next, create a RIM certificate for app-b: $ r i m t o o l rimc o app b. rim k keys / base. p r i v. pem p 0 x i 2 \ m 0 xbfdab9f1d39aaef4bb40fdb23ba ad703 x \ images / stake /app b \ 1 : 0 x8dd840f ee93f3dfeba247f c293 \ 2 : 0 x

10 that requires PCR1 to have the content of SHA-1( app-a ) and PCR2 to have the content 0x Once again for app-c: $ r i m t o o l rimc o app c. rim k keys / base. p r i v. pem p 0 x i 5 \ t images / stake /app c \ 1 : 0 x8dd840f ee93f3dfeba247f c293 \ 2 : 0 x1e0c4a5d2ccec f2b Copy the key, the binaries from images/stake/ and certificates to the platform. Copy the RIM certificates to /rim/certs/ with the appropriate file name, i.e., hash of the corresponding binary, e.g. $ cp app a. rim / rim/ c e r t s / cb feead 3. Execute app-a, app-b, app-c in this sequence. Afterwards, how many times can you execute app-a, app-b, app-c again? 4. Reboot the mobile platform and restart the MTM emulator and try to execute the three apps in arbitrary order. (Don t forget the tcsd!) Does it work and why/why not? 5. Create a new stakeholder key: $ o p e n s s l genrsa out stake. p r i v. pem 2048 $ r i m t o o l vkeyc o stake. vkey p keys / boot. p r i v. pem a 0 x \ u 0x01 i 0 x0000cafe k stake. p r i v. pem 6. Sign app-b-star with this new key $ r i m t o o l rimc o app b s t a r. rim k stake. p r i v. pem p 0 x0000cafe i 2 \ m 0 xbfdab9f1d39aaef4bb40fdb23ba ad703 x \ images / stake /app b s t a r \ 1 : 0 x8dd840f ee93f3dfeba247f c293 \ 2 : 0 x Copy app-b-star.rim to /rim/certs/ on the mobile platform as done before (remember: name of the file is the hash of app-b-star!) 8. Start the MTM software stack (tcsd) and then load the stakehoder s verification key $ mtmtool loadvkey k stake. vkey Execute app-a, app-b-star, app-c exactly in this sequence. Can you still run app-b and why/why not? (Compare the RIM certs of app-b and app-b-star) 8