Secure linux boot and encrypted root/initramfs

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Secure linux boot and encrypted root/initramfs

2,374 Views
Felix1z
Contributor I

Did anyone successfully implemented HW accelerated AES encrypted initramfs boot? I thought about implementing encrypted mmcblk device -- it will create /dev/smmcblk, that will encrypt/decrypt sectors on the fly using onboard HW, and /dev/mmcblk for RAW access.

My ideas are:

* during  boot stage (booting from encrypted uSD with keys already in OTP) :

   ** load encrypted linux.sb off boot partition, with bootcmd set to root=/dev/smmcblk0p4 -- where smmcblk will be secured/encrypted uSD partition. 

   ** any r/w access to /dev/smmcblk will be encrypted/decrypted on the fly

* during production -- initial boot.

 ** the uSD is formated as following : partition 1 -- boot (0x53), with plaintext linux.sb, 

                                                       partition 2 -- plaintext ext3 rootfs with setup script (same

                                                       partition 3 -- plaintext ext3 fs, with target encrypted linux.sb and encrypted fs, encrypted recovery.sb

                                                       partition 4 -- free space

 ** setup script talks to the server, programs the OTP key and serial number , dd'ing encrypted linux.sb to partition 1, encrypted rootfs to partition 4, encrypted recovery.sb to i2c onboard eeprom. after successful dd, blows security fuses and serial number to OTP, and issues reset.

at this moment chip is secured.

** upon startup with target fs, if partition 2 is present and mountable through raw mmcblk, the init script will fill partition 2 from /dev/urandom and reformat it using /dev/smmcblk0p2 access, leaving no traces of key.

Did i miss anything? Any known issues with OTP/crypto HW?  

Labels (1)
0 Kudos
1 Reply

883 Views
Felix1z
Contributor I

small correction -- by saying plaintext linux.sb -- i meant encrypted with default freescale keys; by blowing security fuses -- i meant -- permanently selecting user cryptokey (cryptokey_top fuse)

0 Kudos