Newly Released Papers from NSA Journals
The papers are old, but they have just been released under FOIA.
Comments
kiwano • January 5, 2012 9:45 AM
@I like to LOL!
I think that Bruce would be more impressed by a cpu-register-only implementation of twofish 😉
jammit • January 5, 2012 10:49 AM
@ LOL and @kiwano
Here’s an idea. Make a small chunk of RAM on a board that goes between the CPU and its socket. The CPU heat and the difficulty plus time of removing the heatsink might be effective.
NobodySpecial • January 5, 2012 11:47 AM
@jammit – you can use the CPU cache for the crypt data but the only way to be sure is to disable access to the cache for anything else see http://frozencache.blogspot.com/
phred14 • January 5, 2012 12:03 PM
@NobodySpecial – In the old days when Intel introduced the 486, it was the first mass-market processor chip that included a cache – 8 kBytes to be exact. It turns out that the Dhrystone code could just fit into 8kB, and it was a relevant benchmark at the time. The processor had a “benchmark mode” that would simply hard-map the cache into the address space. Their code would load Dhrystone into that spot and then “start” the benchmark, giving them fantastic (for the time) performance on the first runthrough, no cache effects, etc.
Anyone know how big current encryption kernels are? Now that I think of it, the ability to hard-map a small amount of on-CPU RAM into the address space could these days be sold as a security initiative, instead of a way of cheating on benchmarks, like it was with the i486.
Kai Howells • January 5, 2012 2:50 PM
@I like to LOL! – this is similar to how the PS3 hypervisor does it’s decryption of the OS in order to boot.
In the Cell processor that it uses, there’s one small processing element (of the 7 or so that it has alongside the “main” CPU) that purely handles the decryption of the boot image. This processing element has the necessary keys and at no time do they leave this one processor, they never go to shared RAM and no other (more readily accessible) processor ever sees them.
posedge clock • January 5, 2012 6:47 PM
@LOL:
Some (all?) x86 processors have debug modes accessible from the JTAG port. Using these debug modes you can single-step and read machine registers.
So TRESOR isn’t all that much more secure.
Jony Rosenne • January 6, 2012 7:59 AM
Regarding the Pearl Harbor paper, it makes you wonder what will be published fifty years hence on 9/11.
MikeA • January 6, 2012 12:49 PM
Back when I was evaluating embedded processors (Late 1980s), the ability to map on-chip RAM to either cache or dedicated address-space was pretty common, for about the reason mentioned. Many tasks have a small “kernel” (in the more general than OS sense) that can benefit greatly from being “locked in cache”.
This only applies, naturally, to systems and programming teams that don’t think loading a couple gigs of shared libraries to put up a smiley face is OK.
moz • January 7, 2012 2:13 PM
“If we overclassify, we develop in people’s minds a contempt for the classification rules, for if some items which are not secret at all are classified, it means that the whole system is nonsense”. (Security in an Open Society; page 10 as numbered)
And that is the reason why a bunch of people from recent US administrations should be on trial together with Manning.
Subscribe to comments on this entry
Leave a comment
Sidebar photo of Bruce Schneier by Joe MacInnis.
I like to LOL! It's fuuuuuuuuuuuunny. • January 5, 2012 7:23 AM
Brucey, whatcha think about this?
“TRESOR Runs Encryption Securely Outside RAM
TRESOR is a secure implementation of AES which is resistant against cold boot attacks and other attacks on main memory. The basic idea behind this implementation is to store the secret key inside CPU registers rather than in RAM. All computations take place only on registers, no AES state is ever going to RAM. In particular, the x86 debug registers are misused as secure key storage.
TRESOR is a secure implementation of AES which is resistant against cold boot attacks and other attacks on main memory. The basic idea behind this implementation is to store the secret key inside CPU registers rather than in RAM. All computations take place only on registers, no AES state is ever going to RAM. In particular, the x86 debug registers are misused as secure key storage.”
http://www1.informatik.uni-erlangen.de/tresorfiles/tresor.pdf
http://linux.slashdot.org/story/11/08/26/2033226/protecting-a-laptop-from-sophisticated-attacks
http://citp.princeton.edu/pub/coldboot.pdf
http://freedom-to-tinker.com/blog/felten/new-research-result-cold-boot-attacks-disk-encryption
http://citp.princeton.edu/memory/exp/
Alternative: A similar project to TRESOR is Loop-Amnesia (AES-128 for 64-bit CPUs without AES-NI support):
http://linuxrocks123.livejournal.com/93919.html