Re: [cryptography] Which encryption chips are compromised?
On Thu, Dec 12, 2013 at 08:04:00AM -0800, Steve Weis wrote:
On Dec 12, 2013 6:08 AM, "coderman" <coderman@gmail.com> wrote:
i see your skepticism, and i raise you a retort! ;)
i even have a list of candidates you can experiment with to confirm Intel Ivy Bridge as best fit. [0]
I think this is a weak guess.
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), 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-campai... 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.
The document is talking about FY2013. IVB already shipped in 2012. I'd guess it was fabricated for testing in 2009-2010 and designed for a few years prior.
What enablement would be "complete" in 2013 for something that has been on the market a year and is already being phased out?
VPN gear lasts in the field for 2-5 years post roll-out. Design wins into large provider's hardware will often see the same chip being manufactured for 2-5 years after it ceases being available at retail. (ark.intel.com has an "embedded option available?" field to denote the chips they support this for.) "Complete Enablement" is jargon with a specific meaning. I'm not certain I understand it, but I *think* it means "we have plaintext access on any targeted session". I don't think it means "we can get plaintext for an arbitrary previously recorded session" and I don't think it means "we automatically get plaintext for every session we can hear". 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. 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.
By 2013, Intel had already started shipping Haswell. They did launch new IVB E5v2 Xeon server processors this fall, but future CPUs will be Haswell and Broadwell.
Intel already has the next, next generation Skylake with SGX fabricated for testing.
I still think the document is talking about a dedicated crypto chip for VPN and SSL acceleration devices, just like it says.
Especially taking the NYT commentary into account, I'm even more convinced you're right. "Intel and AMD" is about the right length... -andy
On Thu, Dec 12, 2013 at 1:24 PM, Andy Isaacson <adi@hexapodia.org> 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-campai...
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?
On Thu, Dec 12, 2013 at 5:17 PM, coderman <coderman@gmail.com> wrote:
... 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?)
correction: persistence after reboot also has been stated to be performed, though optional. per Bruce's write up[0], 1. target identified (at endpoint or observable mid-point) 2. QUANTUM INSERT redirect to FoxAcid server 3. FoxAcid picks loader exploit according to: target value, exploit value, target skill, other factors. 4. Loader exploit delivered to target 5. confirm success? if no, abort. 6. With loader active, run two basic first pass payloads: 7. Collect configuration information (apps, registry, settings, etc.) 8. Collect location information 9. Escalate to persistent infection, run arbitrary other plugins, etc. in any case, this is more consumer endpoint focused. not applicable to embedded VPN/HTTPS devices. 0. Bruce Schneier's attacking Tor article for the Guardian: http://www.theguardian.com/world/2013/oct/04/tor-attacks-nsa-users-online-an...
participants (2)
-
Andy Isaacson -
coderman