[Cryptography] On Security Architecture, The Panopticon, And "The Law"

Jerry Leichter leichter at lrw.com
Thu Dec 26 00:06:02 EST 2013


On Dec 25, 2013, at 10:05 PM, Bill Frantz wrote:
> ...General purpose hardware manufacturers are as rare as Unicorns, making them a logical target for black coercion. A possible solution to hardware compromise is to run crypto code through one or more layers of interpretation, so it will be hard for the hardware to detect what computations are being performed.
I think "detecting that encryption is being performed" is an unlikely attack. Let's assume we're talking just AES.  There are so many implementations out there, with some many little tweaks, unless you're targeting a particular implementations, you'd pretty much have to do an input-output analysis to know it was AES you were looking at.  And that assumes you can recognize the inputs and outputs.

And suppose hardware *did* recognize an AES encryption under way.  Then what.  AES is a deterministic operation - you can't modify the output without it being easily detectable - and it's not like the hardware can tell that someone is checking its output, as you can do that easily off-chip.  (In fact, unless the attacker consistently modifies the implementations at both ends of the link, a modification of the output will just cause the data to fail to decrypt - a pretty good indication that something is wrong!)  So what you'd need to do is leak the key.  (You could leak the cleartext, but that's orders of magnitude more data.)  But how is a CPU chip supposed to do that?  Extra data coming out of the CPU is going to get detected.

Interestingly, the same arguments apply to hardware AES accelerators.  The fundamental difference here from hardware RNG's is that every operation is deterministic and has results that can be readily verified - and by their nature, are effectively *being* verified during normal operation.  This channels plausible attacks in one direction:  Leaking keys.  And it's not easy to come up with a good way to do that undetectably.  (At least *I* haven't come up with a mechanism.  The best I can think of on contemporary CPU's is for the system management subsystem to use its private access to the Ethernet to sneak out some extra packets.  But how long can you do this without someone noticing?  There are all kinds of normal operations that look closely at network traffic.  If you have an idea for a better attack, I'd like to know about it.)

Now, there are certainly special cases where attacks are possible.  For example, if you can arrange to have regular physical access to the machine, you can store the grabbed keys in some kind of non-volatile removable storage.  But if you can do that, there are plenty of much simpler, cheaper, low-tech attacks you can mount.

And that, I think, is the case for hardware attacks on encryption code in general:  Given the level of access and effort they would require, they would always be dominated by other attacks.  Attacks that do things like notice a particular bit pattern in a received Ethernet packet and jump into the code in the rest of the packet while in a privileged state have actually been built and shown to work.  Much more flexible, gains you all the access you want, and extremely difficult to detect.  If you can load code into a system - *after* determining exactly what it's running - any crypto has no chance.

                                                        -- Jerry

PS  I once proposed (never actually implemented) a version of what you describe to solve a different problem:  Embedding a key in a program to which an adversary had access in such a way as to make extracting the key as challenging as possible.  I happened to have handy code I'd written for a compiler course I taught long before:  A simulator for a CPU I'd designed (a simple if slightly odd RISC that was just a nice target for a compiler) and a somewhat-optimizing Modula-2 compiler.  (Students were asked to extend the incomplete compiler I gave them.)  So what I was going to do was expand out the entire key schedule and write out all the steps of the encryption in Modula-2, compile it, and then run that under the simulator - probably piecewise, with other operations interspersed.  Yes, a sufficiently patient attacker could figure it out eventually, but it would be a royal pain to do so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131226/0b27caf2/attachment.html>


More information about the cryptography mailing list