[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[cryptography] Which encryption chips are compromised?

On Thu, Dec 12, 2013 at 1:24 PM, Andy Isaacson <[email protected]> wrote:
> ...
> In reply to Declan tweeting about this discussion (shame on you, Declan,
> if you're reading this and trying to take the discussion to the public),

the worst kind of xpost of all?

every day without RDRAW is another day of my life with provably less
information theoretic meaning.  ;)

> Kevin Poulsen points out
> https://twitter.com/kpoulsen/status/411226939547222016
> that the Times' comment on this redaction appears to imply that the
> redacted text names two chips:
> http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?_r=0
>     Large Internet companies use dedicated hardware to scramble traffic
>     before it is sent. In 2013, the agency planned to be able to decode
>     traffic that was encoded by one of these two encryption chips,
>     either by working with the manufacturers of the chips to insert back
>     doors or by exploiting a security flaw in the chips' design.

two chips or two families or two architectures or ...
is this a game of twenty questions? can we do a reddit AMA for the
leakers with their stash at the ready?

> "Complete Enablement" is jargon

you know, if we had more documents providing context,

> Suppose a NSA chip backdoor receives its triggering command by a
> specific sequence of TCP retransmits (dropped packets) and after being
> triggered, leaks the key by varying the timing or ordering of outbound
> packets.  By my reading, this would count as "complete enablement" even
> though a session which was not triggered would not be eavesdroppable.

past experience tells us they like attacks universally effective,
unidirectional, silent/random-looking (without secret knowledge), and
don't mind expending custom hardware and algorithms to do it.
Dual_EC_DRBG doesn't count - that was a "jeezus, everyone asleep at
the wheel.  i bet we could get this approved!" moment.

triggering is active, observable (potentially), and usually
re-playable.  the only "delivered payloads", ala
EGOTISTICAL*/ERRONEOUS*, appear to be for confirmation pinging or
identification, and memory resident forensic/exfiltration run locally
on the host.  even the slides you link to note the OPSEC concerns of
"adversarial actors" (i think that's us on this list?)

> To specifically respond to your point, "Complete enablement" is also
> time dependent.  Productionizing a timing side channel attack could
> result in complete enablement only for new flows and would still be
> complete even though there was no enablement before the attack was
> available.

sure.  note how this is also more complicated, with higher risk?  if
there was a better way i bet they'd choose it!

> "Intel and AMD" is about the right length...

also, Intel and ARM, Apple and ARM, Apple and VIA, etc.
  you're not helping my pleading and cajoling for RDRAW sir.

on a related note, if Intel were to decide to include RDRAW in next
CPU line design, how long would it be to retail channels? >3yrs?