At a previous employer we evaluated a few of these devices so that executives could make "secure" calls form their homes to the office, but we ended up instead deploying an VoIP over IPSec solution. I ended up with these after the eval and always thought that they were cool, but never did anything with them.
Their marketing literature is filled with all sorts of exciting phrases like:
The Sectéra Wireline Terminal is NSA certified to protect information classified Top Secret and below using Type 1 encryption algorithms.
For users not requiring Type 1 encryption, an interoperable AES solution is available. The terminal is available with multiple key-sets to
support U.S. government sponsored interoperability (e.g., NATO and coalition).
When I was looking for something with a largish FPGA that I could re-purpose for password cracking I suddenly thought of these again and figured that they probably used an FPGA for the encryption bit, so I decided to open one up and have a look. I assumed that they probably had some sort of cool tricks built in so that opening the case would trip some sort of tamper switch and the device would instantly zero its keystore, or do something else to makes the device inoperable. Seeing as I didn't really think I'd use if as a voice encryption device anyway and was about to break the warantee sticker I decided to see if I could defeat the tamper switch, so I plugged the device in, generated a new public / private key pair and then very carefully drilled a hole through the back of the case. After much poking around with a probe, careful peering with a fiber scope, etc I decided to just risk it and undo the screws... Turns out that hte devices don't have any sort of tamper prevention, and it carried on running just fine, with no loss of keying material, etc.
The only security for the keystore seems to be the odd mounting bits that the FPGA sits on, but it seems that:
- that can be easily bypassed
- there is enough space to install additional circuitry to copy the date stream before encryption and transmit it later
- the flash is accessible to reprogram it and get it to expose the session keys somehow during call setup
- all of the FPGA pins are nicely broken out and can be probed with a logic analyzer.
I intend trying all of the above sometime, but ran out of time. For now here is a picture of the inside of the device with the FPGA visible.
Link to Xilinx data sheet -- its got 128k gates and 81k of block RAM -- about perfect to be converted into an MD5 brute-force unit... And there is some poetic justice in converting an encryption device into a crypto breaker
Getting users to choose secure passwords is really, really hard... No matter how much you try and impress upon them the fact that both their and the companies security relies upon the passwords they choose, they still insit on choosing something like "chocolate" or "bob". With enough training, cajoling and threats you can probably train them to get to something like "P@ssw0rd!", but that seems to be about the best you can hope for.
One solution to this is to regularly audit users passwords -- this basically involves taking the password file (with the encrypted passwords) and performing a modified dictionary attack or just a brute-force attack against the passwords and emailing the users with poor choices.
There are other reasons that it is sometimes necessary to break passwords -- for example I recently ended up with a bunch of Sun Enterprise servers. I mounted the drives under Linux, but wanted to be able to recover the root password so that I could login to the others without having to pull drives, etc.
Password hashes are specifically designed to be computationally infeasible to brute-force, so I started looking into doing this in hardware.
In order to actually get a start on the project I needed an FPGA, power, a method to program the FPGA, etc. Getting a board made for this takes time (and money), and I just wanted to get going, so I looked around for a device that already had an FPGA, microprocessor, glue logic, etc. After a while I thought of reusing a Proxmark3 -- I didn't want to (potentially) destroy an already working unit, so (3 days before I was scheduled to leave for IETF 71) I decided to quickly build a partial unit, with just the FPGA, processor, USB glue and JTAG stuff.
Unfortunately the FPGA on the Proxamrk3 is much too small to actually implement any hash algorithms, but it did allow me to work in the general principles while sitting in some of the more boring working groups.
What I came up with was a system where the PC pushes general parameters down to the Atmel processor on the unit -- basically a list of candidate hashes, a device ID and where in the key-space to start. The microprocessor loads the FPGA bit image into memory and writes the following:
| Salt | Hash |
Start | End |
into the relevant bits of the image. It then programs the (modified) image into the FPGA and signals it to start -- this somewhat kludgey system was chosen because I a: had only a limited number of (connected) pins and B: didn't want to develop and implement a whole protocol for communication.
The FPGA initializes a counter with Start, concatenates that with the salt and then calculates the hash. If compares this with Hash and, if they match it signals that it found the result within this work unit. If they don't match, it increments the counter and rechecks until End is reached. If End is reached without finding the correct input, the FPGA signals this, the processor builds a new image and restarts the FPGA. In order to keep the communication between the FPGA and the microprocessor as simple as possible, the FPGA does not actually return what the IV to the hash function is, but only that it lies within the current work unit -- this means that the host computer still has perform some brute-force work, but only has to perform End - Start hashes. I chose a work unit of 222 which provides a reasonable trade-off between restarting the FPGA and search time on the PC.
After I returned from the IETF I found my Xilinx development kit waiting for me -- unfortunately I haven't had much time recently, but hope to soon rework the communications bit and will then post some results.