Re: [Cryptography] Points of compromise

[Jerry Leichter]

On Sep 8, 2013, at 1:53 PM, Phillip Hallam-Baker wrote:

 I was asked to provide a list of potential points of compromise by a 
 concerned party. I list the following so far as possible/likely:
It's not clear to me what kinds of compromises you're considering.  You've 
produced a list of a number of possibilities, but not even mentioned whole 
classes of them - e.g., back doors in ECC.

I've expanded, however, on one element of your list.
 2) Covert channel in Cryptographic accelerator hardware.
 
 It is possible that cryptographic accelerators have covert channels leaking 
 the private key through TLS (packet alignment, field ordering, timing, etc.) 
 or in key generation (kleptography of the RSA modulus a la Motti Young). 
There are two sides to a compromise in accelerator hardware:  Grabbing the 
information, and exfiltrating it.  The examples you give - and much discussion, 
because its fun to consider such stuff - look at clever ways to exfiltrate 
stolen information along with the data it refers to.

However, to a patient attacker with large resources, a different approach is 
easier:  Have the planted hardware gather up keys and exfiltrate them when it 
can.  The attacker builds up a large database of possible keys - many millions, 
even billions, of keys - but still even an exhaustive search against that 
database is many orders of magnitude easier than an exhaustive search on an 
entire keyspace, and quite plausible - consider Venona.  In addition, the 
database can be searched intelligently based on spatial/temporal/organizational 
closeness to the message being attacked.

An attack of this sort means you need local memory in the device - pretty cheap 
these days, though of course it depends on the device - and some way of 
exfiltrating that data later.  There are many ways one might do that, from the 
high tech (when asked to encrypt a message with a particular key, or bound to a 
particular target, instead encrypt - with some other key - and send - to some 
other target - the data to be exfiltrated) to low (pay someone with physical 
access to plug a USB stick into the device periodically).

-- Jerry

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] Points of compromise

[John Gilmore]

Phillip Hallam-Baker hal...@gmail.com wrote:
 5) Protocol vulnerability that IETF might have fixed but was discouraged
 from fixing.

By the way, it was a very interesting exercise to actually write out
on graph paper the bytes that would be sent in a TLS exchange.  I did
this with Paul Wouters while working on how to embed raw keys in TLS
(that would be authenticated from outside TLS, such as via DNSSEC).

Or, print out a captured TLS packet exchange, and try to sketch around
it what each bit/byte is for.  The TLS RFCs, unlike most Jon Postel
style RFCs, never show you the bytes -- they use a high level
description with separate rules for encoding those descriptions on
the wire.

There is a LOT of known plaintext in every exchange!

Known plaintext isn't the end of the world.  But it makes a great crib
for cryptanalysts who have some other angle to attack the system with.
Systems with more known plaintext are easier to exploit than those
with less.  Is that why TLS has more known plaintext than average?
Only the NSA knows for sure.

John


___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography