On Wed, 15 Dec 2010 07:48:46 +0100
Otto Moerbeek <o...@drijf.net> wrote:
> On Tue, Dec 14, 2010 at 10:26:44PM -0500, Brandon Mercer wrote:
>
> > If this type of thing really did happen and this actually is going
> > on something as simple as systrace or dtrace would have found it
> > correct? Surely folks have monitored and audited the actual
> > function and traffic that goes across the wire... conversely amd
> > has a "debugger" that'll get you access to more goodies than you
> > could imagine and just recently I discovered a similar "debugger"
> > on the wifi chip on my phone. Guess its better it doesn't work
> > anyhow ;)
>
> It's generally impossible to see from a datastream if it leaks key
> data. It can be pretty damn hard to verify code to show it does not
> leak key data
I think if it leaks data, it must leak data somewhere, i.e. there must
be a server somewhere, and this server must have an ip.
so if you look at your traffic, and you will find an ip other then ip
of your server, you will know where the leak goes.
just my 0.5 cents
> -Otto
>
> > Brandon
> > On Dec 14, 2010 8:33 PM, "Damien Miller" <d...@mindrot.org> wrote:
> > > On Tue, 14 Dec 2010, Bob Beck wrote:
> > >
> > >> I wonder a lot about the motives of the original sender sending
> > >> that
> > message.
> > >
> > > Ignoring motive, and looking at opportunity:
> > >
> > > We have never allowed US citizens or foreign citizens working in
> > > the US to hack on crypto code (Niels Provos used to make trips to
> > > Canada to develop OpenSSH for this reason), so direct
> > > interference in the crypto code is unlikely. It would also be
> > > fairly obvious - the crypto code works as pretty basic block
> > > transform API, and there aren't many places where one could
> > > smuggle key bytes out. We always used arcrandom() for generating
> > > random numbers when we needed them, so deliberate biases of key
> > > material, etc would be quite visible.
> > >
> > > So a subverted developer would probably need to work on the
> > > network stack. I can think of a few obvious ways that they could
> > > leak plaintext or key material:
> > >
> > > 1. Ensure that key bytes somehow wind up as padding. This would
> > > be pretty obvious, since current IPsec standards require
> > > deterministic padding. Our legacy random padding uses
> > > arc4random_buf().
> > >
> > > 2. Arrange for particular structures to be adjacent to
> > > interesting data, like raw or scheduled keys and "accidentally"
> > > copy too much.
> > >
> > > 3. Arrange for mbufs that previously contained plaintext or other
> > > interesting material to be "accidentally" reused. This seems to
> > > me the most likely avenue, and there have been bugs of this type
> > > found before. It's a pretty common mistake, so it is attractive
> > > for deniability, but it seems difficult to make this a reliable
> > > exploit. If I was doing it, I'd try to make the reuse happen on
> > > something like ICMP errors, so I could send error-inducing probe
> > > packets at times I thought were interesting :)
> > >
> > > 4. Introduce timing side-channel leaks. These weren't widely
> > > talked about back in 2000 (at least not in the public domain),
> > > but have been well researched in the years since then. We have
> > > already introduced countermeasures against the obvious memcmp()
> > > leaks using timingsafe_bcmp(), but more subtle leaks could still
> > > remain.
> > >
> > > If anyone is concerned that a backdoor may exist and is keen to
> > > audit the network stack, then these are the places I'd recommend
> > > starting from.
> > >
> > > -d
>
--
With best regards,
Gregory Edigarov
