 |
| Taking security seriously |
He wanted to know about privacy and how A&A do things. I'll leave him to make an article on that - I have done many before.
But I did like the question on equipment - how do we know that the equipment in our network does not have back doors, do we audit the code somehow or what?
I explained, "we build them", as in PCB design, code from first line of boot, and operating system and Ethernet drivers, and TCP stack and BGP and IPsec and LNS and everything with hardware made in UK (Newbury), so we know... I even explained that the team is small enough that we know we have no NSA/GCHQ moles. He asked if I was one, and I re-assured him that I am not! Good question!
As usual, I think it blew his mind slightly. That, or it made us sound like a bunch of tin foil hat wearers. But FireBrick does take things seriously...
So will there be a new generation of firebrick soon in order to support the fact that higher speed connectivity is starting to get more affordable?
ReplyDeleteI'm hoping there'll one day be a "smaller capacity" variant of the
Deletehttp://www.firebrick.co.uk/fb6000/fb6102.php
..because we'd like to run some pretty extensive ping tests, but not in the 100,000 endpoints range, more like 1,000-2,000 range...
There is a next generation hardware, mainly just a general upgrade that will replace the FB2700 at some point. It does have a hardware TRNG though :-)
DeleteSo we could buy one and use it as a pingbox? That would interest me if the price wasn't ridiculous.
DeleteA FB2500 seems to run ~900 cqm ping tests just fine.. Not sure what its limit is.
DeleteIt would be nice to have some rack ears available for the 2500/2700 series units BTW.
DeleteRe the ping tests, can you not just do that with a PC?
Delete@Will ... yes we could in theory, but it would be neater to have a box, and the graphing that's already designed etc - it's the "buy box, have the requirement met" thing rather than "build this, fiddle with that, tinker with the other..."
DeleteAlso, one of the reasons we made a ping box FireBrick is because we tried this on a PC (linux) originally and found that it is not as easy as it sounds to get accurate timing and data on a large scale.
DeleteWhat the FireBrick needs is a cheaper model. If I could have got one that does channel bonding for a few hundred quid then I would probably have one by now, but the near 900 quid price is prohibitive (FB2700 fully loaded, the FB2500 is no longer available and the low end software doesn't support bonding).
DeleteYou have the perfect cover for a GCHQ mole... ;)
ReplyDelete> He asked if I was [an NSA/GCHQ mole], and I re-assured him that I am not!
ReplyDeleteWell that's okay then. As long as he has your word for it... I mean, spies and moles are well known for telling the truth in such circumstances.
Of course, it's hard to be sure what your processor does when it boots before it starts running your code... And that's a bit that wasn't made in Newbury/Thatcham...
ReplyDeleteYes and no. It is an ARM core, and we have JTAG, but in theory something could happen before our code runs. It would have no access to Ethernet or RAM until we I initialise those and wipe the RAM, so I am curious as to what you think it could usefully do.
DeleteIf you use an off the shelf SOC then it almost certainly has it's own internal boot ROM to allow it to boot by various means eg. NAND Flash (no execute in place), download by serial or SPI, and some SOCs will do USB boot.
DeleteNot in this case, but there are processors that have them, and may be used in due course. As I say, there is very little that such a boot system can actually do if it was malicious.
DeleteThis was x86 rather than ARM, but I did simulate an ABI-level backdoor last year which booted a fresh unmodified copy of Windows, encrypted a file using OpenSSL then browsed a web page - at which point the AES key OpenSSL had used popped up in my Inbox, courtesy of a bit of Javascript triggering the CPU backdoor. Not directly applicable to a Firebrick, but somewhere at the back of my mind is an adaptation of the technique which would work there...
DeleteTo my mind, a distinction between the boot rom code (or not) and the bazillion lines of Verilog/VHDL which make up the MAC and PHY components of every Ethernet system is entirely arbitrary - both MACs and PHYs are now generally capable of constructing/modifying TCP/IP package (MACs for acceleration, PHYs for PTP timestamping, so clearly contain all the 'code' you would need to mess around with the network.
ReplyDeleteI can't currently see how a standalone PHY would use this for evil, but a MAC embedded in a processor or on a multi-master bus like PCI has access to the system's RAM, has access to the network and has the code to modify/generate TCP/IP packets. It's just a matter of trust that it's not using these capabilities to form some kind of side-channel to, for example, leak key material to government-grade bad-guys via some high-traffic third party.
Let's assume that Intel and MS are both bent to the will of the US government in some way, then it's not very hard to see how part of the endless flow of opaque hashes and signatures involved in something like Windows Update could be carrying stolen information from within networked devices. It would be flipping difficult to detect by a network operator, and you could fetch the entire memory of a networked device back over a little time, and then look for keys, etc within it.
My guess is that it's probably not happening in a big way, but that isn't because of any technical challenge.