Re: [Cryptography] AES [was NSA and cryptanalysis]
> >> Such a backdoor would be feasible. > > It might be feasible in theory (and see the Illinois Malicious > > Processor as an example) but I think it would be hard to pull off > > well -- too hard to account for changes in future code, too hard to > > avoid detection of what you've done. > Not sure this is true. If instead of leaking via the RNG, you leak via > the cryptographic libraries *and* the windows socket libraries, then > while there are probably two different teams involved, there is only one > manufacturer - Microsoft. > > Ok that would exclude non-windows systems, which in this world of BYOD > means an increasing number of ios or android devices - but the odds of > one end or the other of any given exchange being a MS platform are > good. Provided the cryptographic libraries are queried in a specific > manner for tcp sequence numbers (which can be enforced) the winsock team > never need know how those are generated, leaving just the cryptographic > library holding both the input and output. > I think you are over estimating how entrenched Windows is. First, its not widely used on server side. Most of the server side is Linux based so if you are on android or IOS, there is high chance you are not using Windows on both ends. Then they also are not as dominant as they were in the 90s and early 2000s. Apparently, if you consider mobile devices, they make 30% of the computers out there. So, for this to work, it got to be done across vendors. > > William > > > > On the other hand, we know from the press reports that several > > hardware crypto accelerators have been either backdoored or > > exploited. In those, leaking key material to observers in things like > > IVs or choices of nonces might be quite feasible. Such devices are > > built to be tamper resistant so no one will even notice if you add > > features to try to conceal the "extra functionality" of the device. > > > > For the Intel chips, I suspect that if they've been gimmicked, it > > will be more subtle, like a skew in the RNG that could be explained > > away as a manufacturing or design error. That said, things like the ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] AES [was NSA and cryptanalysis]
On 16/09/2013 23:39, Perry E. Metzger wrote: > On Mon, 16 Sep 2013 11:54:13 -1000 Tim Newsham > wrote: >> - A backdoor that leaks cryptographic secrets >> >> consider for example applications using an intel chip with >> hardware-assist for AES. You're feeding your AES keys >> directly into the cpu. Any attacker controlling the cpu has >> direct access and doesn't have to do any fancy pattern matching >> to discover the keys. Now if that CPU had a way to export >> some or all of the bits through some channel that would also >> be passively observable, the attacker could pull off an offline >> passive attack. >> >> What about RNG output? What if some bits were redundantly >> encoded in some of the RNG output bits which where then >> used directly for tcp initial sequence numbers? >> >> Such a backdoor would be feasible. > It might be feasible in theory (and see the Illinois Malicious > Processor as an example) but I think it would be hard to pull off > well -- too hard to account for changes in future code, too hard to > avoid detection of what you've done. Not sure this is true. If instead of leaking via the RNG, you leak via the cryptographic libraries *and* the windows socket libraries, then while there are probably two different teams involved, there is only one manufacturer - Microsoft. Ok that would exclude non-windows systems, which in this world of BYOD means an increasing number of ios or android devices - but the odds of one end or the other of any given exchange being a MS platform are good. Provided the cryptographic libraries are queried in a specific manner for tcp sequence numbers (which can be enforced) the winsock team never need know how those are generated, leaving just the cryptographic library holding both the input and output. > > On the other hand, we know from the press reports that several > hardware crypto accelerators have been either backdoored or > exploited. In those, leaking key material to observers in things like > IVs or choices of nonces might be quite feasible. Such devices are > built to be tamper resistant so no one will even notice if you add > features to try to conceal the "extra functionality" of the device. > > For the Intel chips, I suspect that if they've been gimmicked, it > will be more subtle, like a skew in the RNG that could be explained > away as a manufacturing or design error. That said, things like the > IMP do give one pause. And *that* said, if you're willing to go as > far as what the IMP does, you no longer need to simply try to leak > information via the RNG or other crypto hardware, you can do far far > worse. > > (For those not familiar with the Illinois Malicious Processor: > https://www.usenix.org/legacy/event/leet08/tech/full_papers/king/king_html/ > ) > > Perry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] AES [was NSA and cryptanalysis]
On Mon, 16 Sep 2013 11:54:13 -1000 Tim Newsham wrote: > - A backdoor that leaks cryptographic secrets > > consider for example applications using an intel chip with > hardware-assist for AES. You're feeding your AES keys > directly into the cpu. Any attacker controlling the cpu has > direct access and doesn't have to do any fancy pattern matching > to discover the keys. Now if that CPU had a way to export > some or all of the bits through some channel that would also > be passively observable, the attacker could pull off an offline > passive attack. > > What about RNG output? What if some bits were redundantly > encoded in some of the RNG output bits which where then > used directly for tcp initial sequence numbers? > > Such a backdoor would be feasible. It might be feasible in theory (and see the Illinois Malicious Processor as an example) but I think it would be hard to pull off well -- too hard to account for changes in future code, too hard to avoid detection of what you've done. On the other hand, we know from the press reports that several hardware crypto accelerators have been either backdoored or exploited. In those, leaking key material to observers in things like IVs or choices of nonces might be quite feasible. Such devices are built to be tamper resistant so no one will even notice if you add features to try to conceal the "extra functionality" of the device. For the Intel chips, I suspect that if they've been gimmicked, it will be more subtle, like a skew in the RNG that could be explained away as a manufacturing or design error. That said, things like the IMP do give one pause. And *that* said, if you're willing to go as far as what the IMP does, you no longer need to simply try to leak information via the RNG or other crypto hardware, you can do far far worse. (For those not familiar with the Illinois Malicious Processor: https://www.usenix.org/legacy/event/leet08/tech/full_papers/king/king_html/ ) Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] AES [was NSA and cryptanalysis]
> What I think we are worried about here are very widespread > automated attacks, and they're passive (data is collected and > then attacks are run offline). All that constrains what attacks > make sense in this context. John Kelsey discusses several attacks that might fit this profile but one he did not consider was: - A backdoor that leaks cryptographic secrets consider for example applications using an intel chip with hardware-assist for AES. You're feeding your AES keys directly into the cpu. Any attacker controlling the cpu has direct access and doesn't have to do any fancy pattern matching to discover the keys. Now if that CPU had a way to export some or all of the bits through some channel that would also be passively observable, the attacker could pull off an offline passive attack. What about RNG output? What if some bits were redundantly encoded in some of the RNG output bits which where then used directly for tcp initial sequence numbers? Such a backdoor would be feasible. -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
