When you’re a nation state, secure communications are key to protecting your sovereignty and keeping your best laid plans under wraps. For the USA, this requirement led to the development of a series of secure telephony networks over the years. John McMaster found himself interested in investigating the workings of the STU-III secure telephone, and set out to replicate the secure keys used with this system.
[John] had a particular affinity for the STU-III for its method of encrypting phone calls. A physical device known as a Crypto Ignition Key had to be inserted into the telephone, and turned with a satisfying clunk to enable encryption. This physical key contains digital encryption keys that, in combination with those in the telephone, are used to encrypt the call. The tactile interface gives very clear feedback to the user about securing the communication channel. Wishing to learn more, John began to research the system further and attempted to source some hardware to tinker with.
As John explains in his Hackaday Superconference talk embeded below, he was able to source a civilian-model STU-III handset but the keys proved difficult to find. As carriers of encryption keys, it’s likely that most were destroyed as per security protocol when reaching their expiry date. However, after laying his hands on a broken key, he was able to create a CAD model and produce a mechanically compatible prototype that would fit in the slot and turn correctly.
Due to the rarity of keys, destructive reverse engineering wasn’t practical, so other methods were used. Thanks to the use of the STU-III in military contexts, the keys have a National Stock Number that pointed towards parallel EEPROMs from AMD. Armed with the datasheet and X-rays of encryption keys from the Crypto Museum, it was possible to figure out a rough pinout for the key. With this information in hand, a circuit board was produced and combined with an EEPROM and a 3D print to produce a key that could replicate the functionality of the original.
Like most projects, it didn’t work first time. The printed key had issues with the quality of the teeth and flushing of the support material, which was solved by simply removing them entirely and relying on the circuit board to index to the relevant pins. Testing was performed using a PKS-703 key reader, which itself was an incredibly rare piece of hardware. In combination with a logic analyzer, it revealed that a couple of the write pins were lined up backwards. Once this was fixed, the key worked and could be programmed with a set of encryption keys. Once inserted into the STU-III and turned, the telephone sprung to life!
Despite this success, there’s still a long way to go before John can start making secured phone calls with the STU-III. Only having one phone, he’s limited to how much he can do — ideally, a pair is needed in order to experiment further. He is also trying to make it easier for others to tinker with this hardware which involves the development of a circuit board to allow keys to be read and reprogrammed with a standard EEPROM writer. He’s also begun reverse engineering of the STU-III’s internals. As a bit of fun, John went as far as to reproduce some promotional swag from the project that spawned the STU-III, showing off his Future Secure Voice System mug and T-shirt.
Reverse engineering national security devices certainly comes with its own unique set of challenges, but John has proven he’s more than up to the task. We look forward to seeing the crypto community hack deeper into this hardware, and can’t wait to see hackers making calls over the venerable STU-III!
Are there any audio samples available of what the encrypted output sounds like? (Can’t watch the video right now)
Entering secure mode establishes a data connection very similar to dialup modems. That’s part of what happens during the 15 second delay. If you recall what a 2400 baud modem sounds like, it’s basically that.
If I’ve understood it correctly, I think the OP is wondering what the voice output sounds like out of the encrypted line (e.g., whether it’s delayed and echo-y like early VoIP calls; clear like a good unencrypted line, or somewhere in between). Considering this technology was used by US Presidents and other world leaders I’m going to guess it’s pretty good?
My first STU-III was 2400 bps (white case), and then they replaced it with 9600 bps version (black case). The 9600 could do both speeds. It was basically just a digital modem (PSK full-duplex for 2400, and V32 QAM full-duplex for 9600). If you have an old 9600 bps modem from the 90’s laying around, it is a DSP chip no doubt. The modems had a training period, and were used to remove echo and match line conditions. We even used an Egyptian telephone line in the middle of the Desert, back to the USA.
2400 was more difficult to understand, as the vocoder was simplified. The 9600 was good quality voice. I think it was a MELP vocoder.
The nice thing, was a STU-III had a computer serial port, and you could hook up a computer, so we connected Unix 3B2 computers together and exchanged encrypted UUCP mail.
We also connected a FAX machine. Commanders liked the FAX machines, because they got more information transferred faster. FAX a filled-out form for example. I don’t remember how the FAX worked. Obviously it bypassed their built-in modem. Must have had a serial out.
oops, I was wrong. 2400 bps was LPC-10 vocoder and 9600 bps was CELP vocoder. Audio samples of the voice quality can be found on the Internet.
“I don’t remember how the FAX worked. Obviously it bypassed their built-in modem.”
That would be the obvious and sensible way to do it, but that doesn’t mean that’s how it was done.
I’ve worked with VoIP systems that used an adaptor to plug an analogue fax into the IP system. So that’s analogue paper, scanned to a digital signal by the fax machine, then modulated into an analogue phone signal, which is converted back to digital by the ATA, which is converted back to analogue when it hits the phone system (and probably switched digitally in the middle), then finally taken by the receiving fax, turned back into a digital signal which is finally sent to a printer. Honestly it’s a wonder it worked at all.
Ah, okay. I didn’t realize it was digitizing and compressing before encryption. I thought it was encrypting the analog audio somehow.
Those are generally called “scramblers” and there are very few uses of that in the military now. Back in my day, we had a scrambler called “Parkhill” that we used on shortwave. It only scrambled the audio. No digital data carrier. It was called a narrowband mode, and took time to train your ears. Operators would speak in a distinct steady voice, and not use a conversational telephone voice. Lot’s of phonetics on numbers, etc.
Quantum keys are the future.
Ok?
Yeah but once they start moving you can never tell where they are.
But if you did know where they were, you wouldn’t know how fast they were moving…
The best security protocol is STFU. Apologies in advance!
Sequential Temporal Fudging Units?
I believe that he means “Shut The F**** Up
Silence is the best security.
Nahh. Silence is WAY too conspicuous.
Blending into the background noise so no one ever looks twice is the best security.