[cryptography] Is it possible to protect against malicious hw accelerators?

Jonathan Thornburg jthorn at astro.indiana.edu
Sun Jun 19 18:19:52 EDT 2011


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 <linux-ipsec at clinet.fi>
     * Subject: Re: linux-ipsec: Intel IPSEC accelerator gives 3DES
       protected 100Mbit Ethernet
     * From: Henry Spencer <henry at spsystems.net>
     * From: linux-ipsec at clinet.fi
     * Date: Thu, 16 Sep 1999 10:48:52 -0400 (EDT)
     * In-Reply-To: <199909161411.KAA02388 at tonga.xedia.com>
     * Reply-To: linux-ipsec at clinet.fi
     * Sender: owner-linux-ipsec-local at sandelman.ottawa.on.ca
     _________________________________________________________________
   
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
                                                       henry at spsystems.net
                                                     (henry at zoo.toronto.edu)


-
This is the linux-ipsec-local at sandelman.ottawa.on.ca mailing list. It is a
restrict-Post filtered version of linux-ipsec at clinet.fi.
     _________________________________________________________________
--- end old mailing-list message ---

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jthorn at astro.indiana-zebra.edu>
   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



More information about the cryptography mailing list