Re: [cryptography] Which encryption chips are compromised?

On Thu, Dec 12, 2013 at 8:04 AM, Steve Weis <steveweis@gmail.com> wrote:
the bulk of 2012 was consume user hardware. the endpoint is a totally solved problem (read: trivial to exploit in many ways, all day, every day, per the docs) only server Ivy Bridge: Xeon E3 in mid-2012. the cores pushed in the SDN initiatives above came out not so many months ago... high capacity crypto aggregation points like this are an ideal target, with backdoor keying of VPN/SSL the ideal (passive) attack with their view of target's long haul fiber.
but not released, and "enabling" means tied into X-KEYSCORE, TRAFFICTHIEF, whatever else gets draped off UPSTREAM...
I still think the document is talking about a dedicated crypto chip for VPN and SSL acceleration devices, just like it says.
the backdoors for all the other vendor hardware happened in years prior. HSMs and crypto accelerator gear is not exactly a vibrant or competitive market. in fact, these companies never seem to die, just carry on with decent margins riding on incremental design upgrades until they're bought out by a larger/growing competitor. ;) of course, this could be because companies like Sun charge $9,999 for an HSM/accelerator that is at best a reasonable cost at $1,499...

On Thu, Dec 12, 2013 at 8:42 AM, coderman <coderman@gmail.com> wrote:
IVB already shipped in 2012... only server Ivy Bridge: Xeon E3 in mid-2012.
this does bring up an interesting point: while it may be more efficient to use the same "key" for the DRBG output across all processor lines, it would be more secure to use a different key per line. this implies that each iteration of Sandy Bridge -> Ivy Bridge -> Haswell needs to be "enabled" by CCP, with Xeon E5 debut in 2013 as discussed. for Sandy Bridge, this would have shown in 2010? and unless in network equipment described simply as "enabling decryption for Sandy Bridge used by $operating systems and $applications." sadly we'll have to wait a while to confirm this conjecture for Haswell. and we'll have to wait forever for more leaks apparently, as the continuing decline of details demonstrates... best regards,
participants (1)
-
coderman