On Sat, 18 Jun 2011, slinky wrote:
> suppose the following scenario: you're encrypting and decrypting using
> a device which provides hardware-accelerated cryptographical primitives
> (such as full 3DES) or their "component functions" (such as a single
> round of AES).
[[...]]
>
> Now, put on your tinfoil beanie and suppose the hw accelerator is a
> Mallory. Suppose there is some kind of a built-in weakness/backdoor,
> for instance as a persistent memory inside the chip, which stores the
> last N keys. Having physical access to the machine would yield the keys
> (thus subverting e.g. any disk encryption). And even more paranoidly, a
> proper instruction sequence could blurt the key cache out for convenient
> remote access by malware crafted by the People Who Know The Secrets.
>
> My questions:
> 1. How can one ensure this blackbox device really isn't a Mallory?
> 2. Are there techniques, such as encrypting a lot of useless junk
> before/after the real deal to flush out the real key, as a way to
> reduce the impact of untrusted hardware, while still being able to
> use the hw-accelerated capabilities?
1. You can't. :(
2. If you don't trust the hardware, then you shouldn't use it. Ever.
It's really that simple: there's simply no way for software to be
safe in the presence of malicious hardware. :(
Indeed, there's no way for software to *detect* malicious hardware. :(
See, for example, the classic paper
@inproceedings{1996-1849,
title={The Dark Side of "Black-Box" Cryptography, or: Should We Trust
Capstone?},
booktitle={CRYPTO},
pages={89-103},
authors={Adam Young and Moti Yung},
year=1996
url =
"http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.54.616&rank=1";
}
or the following brilliant rant by Henry Spencer from way back in the
20th century:
--- begin old mailing-list message ---
## http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/09/msg00240.html
_________________________________________________________________
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread
Index]
Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet
_________________________________________________________________
* To: Linux IPsec <[email protected]>
* Subject: Re: linux-ipsec: Intel IPSEC accelerator gives 3DES
protected 100Mbit Ethernet
* From: Henry Spencer <[email protected]>
* From: [email protected]
* Date: Thu, 16 Sep 1999 10:48:52 -0400 (EDT)
* In-Reply-To: <[email protected]>
* Reply-To: [email protected]
* Sender: [email protected]
_________________________________________________________________
William H Geiger writes:
> I don't know if you still follow the CP list but we have
> been having a long debate on the trustworthiness of Intel
> hardware, especially their RNG...
At first I thought this was pretty much a non-issue here. The problem
with the RNG is that it's so hard to decide whether its output is "really"
random. But 3DES is a deterministic transform which can be tested against
other implementations, so you can easily establish whether the chip is
really doing 3DES or not.
Alas, then I got to thinking. Suppose one built a 3DES accelerator chip
so that, if and only if:
(a) the chip is doing near-continuous encryptions at high speed, and
(b) the keys are changing every packet or two, and
(c) the chip detects -- via a simple mechanism like a little hash table --
a key which has appeared before, recently, and
(d) this key has not been marked "compromised" in the hash table, and
(e) an internal 16-bit packet counter is all-1s,
then
(!) mark the key compromised in the hash table, XOR the key with the
string "GOTCHA, YOU OPEN-SOURCE WEENIES -- NSA RULES!", prefix it with a
random-looking constant bit pattern, and sprinkle the resulting bits into
the encrypted data, in a haphazard but deterministic pattern.
This is, of course, an encryption error. But rules (a)-(e) make it
essentially irreproducible, so it won't happen a second time (and will be
quite difficult to reproduce even in a test setup). Almost certainly it
will get written off as a random error, and the affected packet will be
re-processed correctly and re-sent, and all will be well.
Except that an eavesdropper on the high-speed wire just looks for the
constant bit pattern in the right places in a packet, and (almost) every
time he sees it, he's nabbed an encryption key.
There's no limit to the complexity that can be added -- especially if
you're willing to consider active wiretapping, with the chip going into
this mode only if it sees (say) an ICMP ping with the right data in it --
to defeat attempts to find this sort of thing on the test bench.
I fear I agree with William; nothing short of peer review of the hardware
design makes such a device trustworthy.
Henry Spencer
[email protected]
([email protected])
-
This is the [email protected] mailing list. It is a
restrict-Post filtered version of [email protected].
_________________________________________________________________
--- end old mailing-list message ---
--
-- "Jonathan Thornburg [remove -animal to reply]"
<[email protected]>
Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
"Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
-- quote by Freire / poster by Oxfam
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
