Presumably at some point the kernel will have to do a context switch and subsequently store the contents of those registers in ram.
Perhaps the solution could be a small usb dongle containing an embedded arm soc with a kind of RAM that doesn't persist at all -- maybe even no RAM at all, just the cpu. The dongle would support just three commands: init, encrypt, decrypt. Init sets the key and algorithm, after which the device doesn't let you change them until the system is powered off. En/decrypt do block-level crypto.
No, the AES encryption key really never leaves the CPU, that is the whole point here.
TRESOR uses the four x86 debug registers to store a 128 or 256 bit key and then uses this key to calculate the AES round keys on-the-fly on each block of encryption using Intel AES-NI instructions. Also, they patched the kernel not to touch these registers at all. Therefore, after the initial loading of the encryption key, it never leaves the CPU again.
This approach also means you cannot use the ptrace(2) syscall anymore to attach to a program using a debugger such as gdb. However, if you don't want to debug a program, this proof-of-concept already works quite nice.
In a nutshell: the debug registers are not part of the set that ends up in the saved tss after a context switch, and accessing them is a privileged operation so after a cold boot (assuming the original source of the keys was wiped) there should be no trace of them in RAM.
Perhaps the solution could be a small usb dongle containing an embedded arm soc with a kind of RAM that doesn't persist at all -- maybe even no RAM at all, just the cpu. The dongle would support just three commands: init, encrypt, decrypt. Init sets the key and algorithm, after which the device doesn't let you change them until the system is powered off. En/decrypt do block-level crypto.