After weeks of work, I finally was able to boot my iMX233 ARM processor from a fully encrypted linux partition… and most importantly, I was able to use the hardware-stored encryption key for this purpose. What a pleasure!
iMX233 features a hardware engine (known as DCP) which can perform 128-bit AES encryption using either a software-provided or the hardware-stored key. The latter key is burnt into the CPU’s OTP ROM and can be made totally hidden from software. This adds extra security: cryptography without any chance of revealling the encryption key.
To me, an ultimate disk encryption method for protecting an embedded application is one whose boot procedure does not include any non-encrypted stage. Otherwise, a malicious user can use her own modified version of that non-encrypted stage in order to boot her own code and try to break the encryption key by generating lot of plain/cipher patterns. The first boot stage of iMX233 (booting kernel from first SD partition) can be encrypted using the same OTP key (see elftosb -k parameter). Then the next stage of booting an encrypted Linux from the second partition was what I was looking for.
I had several obstacles to overcome:
- First of all, I had to write my own version of kernel crypto module that can use the OTP hard-key instead of always expecting a soft-key to be provided [see this quesion].
- Second, the original dm-crypt essiv IV method was not possible without modification in my case. Why? because it relies on the explicit value of the key for IV generation, and as I said, the key value is burried into hardware fuses and unknown to software.
- Finally, I needed to add my custom initramfs into my compiled Freescale’s kernel. It is responsible to cryptsetup, mount the encrypted root partition, and switch_root to it.
Hamid Fadishei's Blog 
I am also trying to do same thing on iMX233 board, I didnt thought to use OTP keys but from your post i think i should use it, Can you please provide me some information on the init script you created for initramfs image and about kernel module, means how to get OTP keys
Thanks in advance
Bruce
Comment by Bruce — October 28, 2013 @ 12:54 pm |
Bruce,
Regarding the init script you should follow the general process of building initramfs with a difference that you need to copy cryptsetup utility and its dependencies to your initramfs, and use it to mount and then switch_root to the mounted encrypted root. When building the kernel, specify this initramfs.tar.gz in menuconfig.
Regarding the kernel module, all I can say is that I had to develop my own kernel module that uses OTP hardware for encryption/decryption. Unfortunately I am not allowed to provide any code as it belongs to the company I work with.
I hope that helps!
Comment by fadishei — November 1, 2013 @ 2:05 pm |
I understand that, i already did the initramfs part.
Answer one question, DCP driver is enabled in my kernel but after bootup i am not able to see /dev/dcpboot, so how were you using dcpboot device file through that tool you created otpcrypt?
Comment by Bruce Warner — November 12, 2013 @ 4:12 pm
I can not guess what the problem is. Please compare your environment with mine to see whether you’ve missed something:
root@arm:~# uname -r
2.6.35-9-ARCH
root@arm:~# ls -l /dev/dcpboot
crw——- 1 root root 10, 60 Jan 1 00:00 /dev/dcpboot
root@arm:~# dmesg | grep DCP
dcp dcp.0: DCP crypto enabled.!
root@arm:~# zcat /proc/config.gz | grep DCP
CONFIG_CRYPTO_DEV_DCP=y
Comment by fadishei — November 15, 2013 @ 9:49 am
I was looking for this solution too. Update kernel (3.13.10), change initramfs and now I can boot encrypted root partition. The key is stored in plantext in the initramfs, but since initramfs is in the encrypted bootstream there is none non-encrypted stage in booting. I guess that this solution adds security risk in a way that the key can be read from memory. I am not sure is it worth to go further and reprogram dm-crypt or in another words is it more likely that someone investigate device memory or to decrypt AES CBC used by the OTP hardware.
Comment by Darko — April 29, 2014 @ 5:59 am |