The hardest contract I've taken
2024-08-10 03:14 by Ian
This is a description of the most difficult contract I've ever taken: Building a pirate cellphone tower to crack GSM's weakest deployed stream cipher, and ultimately recover an entire recorded phone call.
I was contracted to build a demonstration piece based on this work, which was presented at DEF CON in 2010. It was to be used as a trade-show demonstration piece to highlight the need for application-level encryption for SMS and voice data.
This was auspicious, and I took the job cheap. I was just reading-up on CUDA and OpenCL for some numerical analysis problems I was having at school last year, and now I have a far more interesting problem to eat with my GPU knowledge: cryptanalysis.
The job that was to last a few months and I had a $8,000 budget for hardware. Following the DEF CON work, I prepared this BoM. I was told many years later that filling this purchase request precipitated contact with the FBI.
Radio duties were handled by a USRP2 from Ettus Research, with a transceiver board appropriate for the band. It was so badly bandwidth-constrained that I could only manage to run a tower with a handful of channels. Recording calls from someone else's tower would require writing code and flow-graphs to monitor the traffic on the tower's beacon channel (BCCH), and then silently hop with the targeted handset to the negotiated ARFCN (where I would begin recording). This wasn't too terribly difficult in 2010 with OpenBTS as a model to learn from, and GNUradio had some good tools, even back then.
I used an application on my Android phone to give me the information about its presently-bound tower, and then forced use of GSM2 on my handset so that my cryptographic stream would be vulnerable. After a few minutes of watching the tower's activity on the waterfall graph, I started placing calls on the public network. This took lots of effort, but I managed to record and decrypt a number of my own calls in this manner.
Satisfied with the recording and cryptanalysis pieces, I turned to the MitM step, and set up a local installation of Asterisk behind OpenBTS (in no auth mode) and a small pile of other packages to tie it together into a self-contained cellphone network. Unexpectedly, the hardest part about doing this was making it run without SIM provisioning. But after a few weeks of eroding the problem with Red Bull, it yielded.
Demonstration
My customer had the equipment and expertise to be able to bridge this machine into the broader telecom network, and perform an actual MitM against naive targets, but that was always off-the-table. It was sketchy enough that I was going to operate a transmitter on commercial frequencies for which I wasn't licensed (however quietly) without then also telling the broader telecom network about it under my customer's IMEI.
This constraint made the demo much less compelling, but as it turns out, performing a cellular man-in-the-middle attack (no matter how consensual) pisses off a lot of people.
So I did the demo in two parts. I showed up at their office and fired up OpenBTS, and fulfilled point 1 of the contract: Replicate the work presented at DEF CON 19, and demonstrate interception of a naive cellphone, which is then forced into A5/1 (vulnerable) operation.
I then let them watch Kraken in operation on my recorded phone calls, and outlined the capture process (and the difficulties). If I were to run an actual MitM attack, I'd have twice forked the GSM data stream for the call in Asterisk. One fork into Kraken, and the other into a recorder/tap where the output could be rendered without the target's knowledge.
They were impressed with what I had delivered to this point, and decided to abandon the remainder of the contract and hire me full-time to build their encrypted VoIP product. They were personally-convinced, and didn't want the legal complication associated with their original plan of publicly running this perversion of engineering for the sake of proving a point.
Things that never got finished that would have been really neat and legally damning
- I hadn't gotten to the point of embedding elements of GSM into the FPGA for the sake of conserving USB bandwidth and CPU load incurred by GNURadio. I figured I would have needed to do this in order to run live recording and Kraken concurrently. It would have also solved a worse problem: (Raw samples over USB) and (GNURadio being in the loop for demodulation) meant that the handset almost always arrived at the ARFCN before the USRP2, and my recording would be missing the preamble due to the latency. This caused much early frustration when writing the channel-hopping capability, even with one RX-only radio devoted to monitoring the BCCH.
- I was never able to decrypt an SMS. There wasn't enough transmission to prune back the A5/1 tree to arrive at a key (if the aforementioned ARFCN latency allowed me to get it at all). It took about 31 seconds on my rig to crack a phone call. So if the call lasted longer than that, I could have potentially heard everything after key discovery in real-time.
- Call boundaries and filtering for specific handsets while monitoring the BCCH. As it was, my crude channel-hopping arrangement was indiscriminate, and would simply follow the first negotiation that it witnessed once the tower was acquired, and record on that ARFCN until manually stopped.
- I had plans to tie this together into the audio hardware upon successful decryption so that the call would just start playing over the speaker once the key was available.
Previous: Linux distributions I've worked with
Next: Scuttlebutt