[148735] in cryptography@c2.net mail archive
Re: [Cryptography] On Security Architecture, The Panopticon,
daemon@ATHENA.MIT.EDU (Jerry Leichter)
Thu Dec 26 13:43:47 2013
X-Original-To: cryptography@metzdowd.com
From: Jerry Leichter <leichter@lrw.com>
In-Reply-To: <r422Ps-1075i-12AB55E09C3243B6BF9019FDBD82D6B0@Williams-MacBook-Pro.local>
Date: Thu, 26 Dec 2013 00:06:02 -0500
To: Bill Frantz <frantz@pwpconsult.com>
Cc: cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============9170320028604388037==
Content-Type: multipart/alternative; boundary="Apple-Mail=_C714BEB5-4EA8-4E4B-8D2A-7136E7640DFF"
--Apple-Mail=_C714BEB5-4EA8-4E4B-8D2A-7136E7640DFF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
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.=
--Apple-Mail=_C714BEB5-4EA8-4E4B-8D2A-7136E7640DFF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><div>On Dec 25, 2013, at 10:05 PM, Bill Frantz =
wrote:</div><blockquote type=3D"cite"><div><font =
class=3D"Apple-style-span" color=3D"#000000">...</font>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.<br></div></blockquote></div>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.<div><br></div><div>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.<div><br></div><div>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.)</div><div><br></div><div>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.</div></div><div><br></div><div>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.</div><div><br></div><div><div> =
=
=
-- =
Jerry</div></div><div><br></div><div>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.</div></body></html>=
--Apple-Mail=_C714BEB5-4EA8-4E4B-8D2A-7136E7640DFF--
--===============9170320028604388037==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============9170320028604388037==--
