NAME TRESOR for am335x tresor-3.14.0_arm_am335x-omap-xts128.patch SHA256SUM 74d9782d60a0d739908027a098ec6aa9d9e8309e94d90a50687f0d76af602091 SYNOPSIS TRESOR for am335x is an implementation of the TRESOR patch (a secure implementation of AES which is resistant against cold boot attacks) which utilizes the hardware crypto accelerator present on devices using the am335x series of processors. The patch implements the following: * AES 128bit in XTS mode using the hardware crypto accelerator built into am335x processors * The secret key is stored securely in memory that is erased when the device initializes by the ARM secure boot code (this occurs before any user supplied code is executed and before it is possible to debug the device using the JTAG port). * Provides additional IV modes for multidisk systems * Disables JTAG debugging HARDWARE This patch is for devices that have the am335x series of processors, however it has only been applied and tested as working with security expectations validated on the following hardware: * Beaglebone Black DESCRIPTION This is an implementation of the ARMORED linux kernel patch for ARM devices that utalize the am335x series of processors. In comparison to the original ARMORED patch, this patch does not store the AES key in the device debug registers as these registers are intentionally not cleared on a warm reset to preserve breakpoints on cortex-a8 based processors. This makes the debug registers unsuitable as a location to store secrets against an adversary with physical access. Instead the AES key is stored in a location of memory that the secure boot code (secure ROM) overwrites during initialization. This occurs before it is possible to attach to the device with a JTAG (and of course before execution of the primary bootloader supplied by the user of the device). Additionally as the am335x series of processors contains an AES hardware crypto accelerator, this is used instead of a software based AES such as the one implemented in ARMORED. This significantly increases the disk encryption speed (on the beaglebone black the disk is the bottleneck) and minimizes CPU overhead. Unfortunately this is to the detriment of the auditability of the AES implementation, as the hardware crypto accelerator is not open source and technical documentation is not widely available. However both the AES hardware crypto accelerator and the specialized software implementation in the ARMORED patch succeed to prevent sensitive AES state data being leaked into main memory. This patch currently only implements AES 128bit in XTS mode, as the currently identified locations in memory only provide enough space for either a 256bit key or in the case of XTS mode two 128bit keys. Other block cipher modes available on the hardware crypto accelerator such as CBC were decided against as they contain significant weaknesses which could allow an attacker who has obtained access to a turned on device to execute his own code. (specifically the malleability attack rules out CBC mode, see SECURITY CONSIDERATIONS for further discussion) In the case of a device with multiple disks which will use TRESOR for am335x, the key for both disks must be the same as it is not possible to switch out the keys as there is not enough space to store both securely. As pointed out in the XTS IEEE spec this is unsafe as blocks from one device would be valid when copy pasted to the other device: "An XTS-AES key shall not be associated with more than one key scope. The reason is that encrypting more than one block with the same key and the same index introduces security vulnerabilities that might potentially be used in an attack on the system. In particular, key reuse enables trivial cut-and-paste attacks." This would normally be solved by the container format where your password does not translate into a key, rather it just unlocks the key, and therefore you can use the same password without key reuse. However since this patch must work directly on raw devices to prevent the key entering main memory this has been addressed a different way. Instead additional IV generators are provided that must be used when there are several tresor encrypted disks on the same device (or the same password/key is used on a different device). These IV generators are equivalent to the plain64 IV generator (a generator that simply increments a 64bit sized integer) with the highest bits flipped depending on which generator is picked. This prevents the same IV being reused on the other disk which prevents blocks from being encrypted exactly the same way. Finally additional code was added to disable the entire debug system, to prevent an attacker attaching a JTAG to the device and running his own code on the system, which would result in the ability to view the mounted decrypted disk and extracting the key. USAGE Download kernel sources for your device and apply the patch: patch --directory /usr/src/kernel -p1 < tresor-3.14.0_arm_am335x-omap-xts128.patch Specifically for the beaglebone black the patch has been validated working on the 3.14 linux kernel branch at: https://github.com/beagleboard/linux It works correctly along with the grsecurity patch applied. The functionality is enabled when the AES hardware crypto accelerator driver is compiled into the kernel: Symbol: CRYPTO_DEV_OMAP_AES [=y] │ Prompt: Support for OMAP AES hw engine │ Location: │ -> Cryptographic API (CRYPTO [=y]) │ -> Hardware crypto devices (CRYPTO_HW [=y]) To use TRESOR you must enter your encryption key without leaving any traces in memory this can be achieved using the simple tresor_sysfs.c tool: http://www1.informatik.uni-erlangen.de/filepool/projects/tresor/tresor_sysfs.c By default this tool enters the key directly in hex format, for example a way to securely generate a key to enter in this format is: cat /dev/urandom | head -c32 | xxd -p -c32 7ae0ae0022c3ef89a4e3a5af0082d6528e8b83c848de58dc478813250056c93e This will be used directly as the AES key by TRESOR when entered into tresor_sysfs.c Alternatively modify tresor_sysfs.c so that TRESOR_SET_KEY points to the password sysfs device: #define TRESOR_SET_KEY "/sys/kernel/tresor/password" You can then use tresor_sysfs to enter a password and it will be hashed, currently there is a bug if you make your password longer than 50~ characters so ensure your password is less than 50 characters. A way to generate a password securely on linux would be as follows: < /dev/urandom tr -dc A-Za-z0-9 | head -c48; echo T3NPFI0mraDCk8OMNBSsy0rCoJ8Lp9IYUtfE8VZt2P9JjvI1 After entering the password into tresor_sysfs, you can now create the device using a command such as: cryptsetup create tresor /dev/mmcblk0p3 --cipher tresor-xts-device0 --key-size 256 cryptsetup create tresor /dev/mmcblk1p3 --cipher tresor-xts-device1 --key-size 256 cryptsetup create tresor /dev/mmcblk2p3 --cipher tresor-xts-device2 --key-size 256 The cipher argument specifies that we are going to use the tresor "cipher" in xts mode (this is the only implemented option), and "device0" is the IV we are using, device0 is equivalent to plain64. When encrypting multiple devices on the same machine you may run into a problem as you cannot securely use the same key and same IV generator. So there are also device1/device2/device3 IV options, which are equivalent to plain64 except they also modify the highest bits in the IV to make them unique. You must use a different device IV if you are using the same key, otherwise you will weaken the security of your system. The key-size argument is 256 which because XTS mode uses two keys, is equivalent to two 128 keys. After running the command your device will be at /dev/mapper/tresor. When mounting the device again after you have rebooted your machine, simply enter the same key/password with tresor_sysfs and run the same command you use to create the device: cryptsetup create tresor /dev/mmcblk0p3 --cipher tresor-xts-device0 --key-size 256 SECURITY CONSIDERATIONS Please think about your threat model first, this patch only addresses an extremely specific attack, and in most cases there are better ways to avoid it. For example, perhaps you can simply always turn your device off or dismount your encrypted volume when you are not using it. This patch and the design decisions have not been widely audited and is written by someone with only basic understanding of cryptography. The custom IV generators introduced are non-standard and may introduce vulnerabilities into the system. If possible avoid using the device1/2/3 IVs. The code does not contain any test cases to validate that it is working sanely. Currently we are unaware of any interfaces available on the board tested (beaglebone black), that can be used to obtain code execution on the device once the JTAG port is disabled. However there may be different interfaces available on any other board you may choose to use which you need to consider. The hardware crypto accelerator present on the am335x is not well documented, and could potentially be vulnerable to side channel attacks, such as power analysis attacks. So far we have not analyzed the cost and difficulty to attack the device using hardware based attacks, for example fault injection / microprobing. The choice to use AES 128bit in XTS mode was made as CBC mode is vulnerable to malleability attacks, this is where every 2nd plaintext block can be set to a value chosen by an attacker (this is particularly detrimental because it opens an attack vector to get code execution on the device when physical access is obtained, where otherwise on these ARM devices there does not appear to be any easy way to get code execution with physical access once JTAG is disabled). XTS mode is also vulnerable to attacks where any 16 byte block on the system can be corrupted which could potentially be used to gain code execution on the device, however it is likely to be more difficult to obtain code execution through scrambling a block than through the CBC malleability attack. Without better block cipher modes present on the device, a work around needs to be found. This is a point for more research, a possibility is to use a filesystem with built in compression that results in large portions of the file system becoming corrupted if even a single encrypted block is tampered with. If such a filesystem provides this quality, it may become a better choice to switch to CBC mode with 256bit AES keys. As then it becomes possible to use 256bit AES keys, and additionally it becomes possible to set the key once inside the hardware crypto accelerator and continue to encrypt using that key without needing to set it again, preventing the key from being extracted by the OS itself. AUTHORS Cameron Moree THANKS Johannes Goetzfried Matthijs van Duin