Actually, when I would design such a backdoor, I wouldn't go for the item
getting highest attention and most difficult to crack. And because the crypto
stuff is getting most attention, it's highly likely it'll be replaced every now
and then with something "better": Backdoor gone.
I would do a "social engineering". Challenge the IPSec stack to tell me what I
want to know.
How:
- Try to setup a connection with the server you want to have the keys from.
- Make a "failure" with this connection.
- This failure would use an additional parameter in the setup payload and answer
with the info I want to have.
So where to look:
In the state machine to initiate/setup the IPSec connection, especially the
error/declines it sends out. Things like: "setup failure, invalid key:
&(Yourkey+"additional parameter")".
That'll be something very difficult to find in reviews (who does look at the
error notices, reviews are in general looking after the main functionality)
Stack state machines tend to be related to the protocol basics and these don't
change, so it's very unlikely a backdoor like this is overruled by a "better"
implementation, especially if the original implementation is decent and robust.
This mechanism would need a handfull of connection setup attempts to get
everything you need to decompose a recorded stream. No intrusions will be
detected ever, unless logging is at debug level and who does wade through that
amount of logging .......
In some situations, you might need to be able to spoof the originating IP,
though having access to the network infrastructure itself, will be enough.
Easy, hardly any code required, very difficult to detect and very likely to
survive for a long period.
