Hamid Fadishei's Blog

March 20, 2013

Know The Hardware Crypto Engine of iMX23 ARM9 Platform Better!

Filed under: Uncategorized — fadishei @ 10:55 am
Tags: , , , ,

Introduction

The iMX233 ARM processor from Freescale comes with a Data Coprocessor (DCP) which contains a cryptography acceleration engine. It can offload some hashing/encryption/decryption algorithms from CPU core. Using my iMX233-Olinuxino-Micro board running Arch Linux ARM I am going to shed some light on this part of that processor.

Kernel Drivers

The iMX kernel tree well integrates the engine into standard linux crypto layer (see drivers/crypto/dcp.c, and drivers/crypto/dcp.h). Thus you can inspect what you have by issuing this command from shell and looking for dcp driver names:

> cat /proc/crypto
name         : sha1
driver       : sha1-dcp
module       : kernel
priority     : 300
refcnt       : 1
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 20

name         : cbc(aes)
driver       : dcp-cbc-aes
module       : kernel
priority     : 400
refcnt       : 1
selftest     : passed
type         : blkcipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        :

...

Judging from the priority values we can say that hardware accelerated dcp drivers take precedence over generic kernel implementations.

AES with Key in OTP ROM

One scarcely discussed feature that I am going to talk more about is the AES with OTP key. What’s that? iMX233 can perform hardware AES with the encryption key stored somewhere in its One-Time-Programmable (OTP) ROM. This key is not directly accessible by software running on the processor. Running software can only request encryption/decryption of their data without knowing what the key is. You can burn a key specific to each device into OTP and hide it totally by locking the key permanently. Security people know what treasure this feature is!

Manipulating the OTP key

In order to see what the key value of your device is, you’ll need to access the board in recovery mode by connecting your it via USB to a PC running the BitBurner software. The VCC pin of the USB cable needs to be disconnected (Only connect D+, D-, GND) and the SD card should be removed. Then power up the board and select HID device in BitBurner. You will see 4 32-bit ROM words CRYPTO0..CRYPTO3. You can see the current value of the key (the default key value is 0x00000000000000000000000000000000). You can also program your desired key value. But remember! It’s One-Time-Programmable! I haven’t dared enough to program a key myself yet! There are also lock bits that can be set in order to hide the key even from BitBurner. I have’nt dared to play with them either!

Kernel Drivers for AES with OTP Key

Unfortunately, AES with OTP key is not integrated into kernel crypto layer due to its different nature. See drivers/crypto/dcp_bootstream_ioctl.h. The name comes from the fact that Freescale uses this feature mainly for bootstream encryption. The driver provides an IOCTL for userspace programs. Some information on using this IOCTL is given in the Freescale iMX233 Evaluation Kit Reference Manual. I wrote a sample otpcrypt tool for demonstrating usage of AES with OTP key. Compile the code on your board and run it like this to encrypt/decrypt data:

> echo fadishei | otpcrypt | base64
oUP5IdEbv4RePVo7mF4hZw==
> echo oUP5IdEbv4RePVo7mF4hZw== | base64 -d | otpcrypt -d
fadishei

I used base64 coding for encrypted data above in order to make it possible to see it on terminal. In order to verify the correctness of the result, you can compare it with OpenSSL encryption results on any computer:

> echo fadishei | openssl enc -aes-128-ecb -K 00000000000000000000000000000000 | base64
oUP5IdEbv4RePVo7mF4hZw==
> echo oUP5IdEbv4RePVo7mF4hZw== | base64 -d | openssl enc -d -aes-128-ecb -K 00000000000000000000000000000000
fadishei

Notes on ECB mode and IV

iMX23 OTP AES is only capable of doing basic AES128 ECB mode on 128-bit data blocks. ECB is not quite secure. CBC is a more secure mode in which every data bloack is XORed with previous block result prior to encryption. A unique IV (Init Vector) is suggested to be used for each data item under encryption in order to have different ciphers for similar plaintexts. The OTP AES IOCTL does not feature CBC and IV. It should be implemented separately in software and needs some knowledge about AES algorithm and data padding. Refer to my otpcrypt tool to see how I managed to do that in a user-space applicaiton.

Request for Information

If you have further information on the DCP crypto engine of iMX233, specially the OTP AES, please comment!

Advertisements

Create a free website or blog at WordPress.com.