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
