Don t Don t Trust Satellite Phones

Transcription

1 Don t Don t Trust Satellite Phones Digital HGI Kolloquium, Voodoo Forensics Workshop 0x7db Benedikt Driessen, Ralf Hund, Carsten Willems, Thorsten Christof Holz Paar, and Christof Thorsten Paar Holz Horst Görtz Institute for IT-Security, Chair for Systems Security / Embedded Security

2 Mobile Satellite Telephony Why it is needed Cellphone communication not available in very remote places Crew on oil rig or ships on open sea Airplanes Research trips (desert/poles) Adventurers or extreme sportsmen Also many military applications Satellite telephony has been around since the 90s Direct communication between phones and satellites 2

3 Satellite Phones How they look like 3

4 Communication Overview Phone communicates with satellite on L-band Satellite coverage area separated into several circular spotbeams Data is forwarded to/from gateway station on C-band, which is attached to wired telephone network 4

5 Inmarsat Spotbeam Coverage 5

6 Standards and Specifications Satellite phone systems were standardized by ETSI Two major standards coexist: GMR-1: based on GSM, de-facto standard used by most providers GMR-2 (aka GMR-2+): based on GSM, used by Inmarsat (and ACeS) Specifications are publically available from ETSI Both standards are very close to GSM Cover signaling, encoding, etc. 6

7 Security Aspects Encryption only discussed as a black box: only frame size and key length given Actual algorithms (A5-GMR-1 / A5-GMR-2) are kept secret Algorithm names suggest resemblance to A5 in GSM Basically, GSM algorithms have been broken Are the GMR algorithms vulnerable to similar attacks? Our task: identify/extract the A5-GMR algorithms from the phones and perform crypto analysis 7

8 GMR-1

9 Choosing a Victim Several GMR-1 phones on the market Our victim: Thuraya SO-2510 (for no specific reason) Firmware update publically available We didn't (have to) look at any other GMR- 1 firmware Analysis was done statically only, we had no real phone at our disposal! 9

10 Phone Hardware Architecture Some General Notes Hardware has two processors: Main processor (almost always ARM) Digital signal processing (DSP) processor (many different architectures exist) Phone needs to perform a lot of speech processing, signaling, possibly encryption, etc. ARM CPU is rather inappropriate for such tasks Dedicated DSP can handle this much more efficiently ARM CPU still makes up the heart of the system Takes control in boot process and runs (most of) the OS Initializes and starts the DSP when needed 10

11 General Procedure 1) Dump firmware image from firmware updater 2) Obtain information on the phone s actual hardware architecture 3) Dump DSP code from firmware image 4) Find cipher code 5) Perform cryptanalysis 11

12 Firmware and Hardware Firmware provided unencrypted/unpacked, need to strip some meta data Thuraya SO-2510 runs on Texas Instruments OMAP1510 (aka OMAP5910): ARM + TI C55X DSP Pretty well documented platform OS is VxWorks 12

13 Memory Mappings Need correct memory addresses for correct disassembly No 1:1 mapping of firmware image in memory Find MMU initialization routine After that, we can readily disassemble the full ARM code in IDA In our case, MMU init is at the very beginning of the image Page tables are stored statically in the image 13

14

15 Strings Surpisingly, firmware image contains plenty of assertion/log strings Allows to deduce the name of some functions 15

16 Dump the DSP Code Encryption/decryption probably not implemented in ARM code for performance reasons Need to find DSP initialization Some good hints: Assertion/log strings Specific memory areas: DSP memory mapped into ARM address space Both approaches work fine 16

17 Dump the DSP Code DSP init routine Copies DSP code blocks from firmware into DSP memory Different kind of blocks exist Takes some effort to reverse We don t really need to understand it completely, just extract the resulting DSP image Use IDA + QEMU ARM emulator to run the routine and dump the extracting DSP code 17

18 Find Cipher Code Yields 240kb of DSP code TI C55x assembler Looks kind of weird Needs some initial training No strings, symbols, whatsoever How do we find the cipher code conveniently? A5-GSM relies heavily on linear feedback shift registers (LFSRs) Probably requires a lot of xor and shift operations 18

19 Find Cipher Code Idea: Rate each function by the percentage of xor/shift instructions This yields some interesting results Top 4 hits adjacent to each other Function % relevant instr. 0001D038 43% 0001CFC8 41% 0001D000 41% 0001D064 37% 00014C9C 25% 00014CAC 25% Let s have a short look at the code 19

20 Find Cipher Code Four of these functions exist Each function does exactly one LFSR clock operation 20

21 Cryptanalysis Looks familiar A5-GMR-1 is basically A5/2-GSM Feedback polynomials changed Position of output-taps changed Initialization process changed slightly 21

22 Cryptanalysis Encryption in GMR-1 Data is organized in frames of different length Frames belong to sessions Frames have a frame-number FN (19-bit) For some sessions, a key K is established to encrypt frames K is derived from a nonce and a SIM-specific secret A5-GMR-1 is re-initialized for each frame IV = K XOR FN used as initialization vector The first 250 bits are discarded 22

23 Cryptanalysis Known-Plaintext Attack 1/2 A known-plaintext attack is possible Based on ideas of Petrovic et. Al., 2000 Key Observations R4 determines the clocking behavior of the cipher completely The M-functions operate on each LFSR separately Describe the generation of keystream bits by quadratic equations The unknowns of the equations represent the initial state of R1, R2 and R3 Quadratic equations with 64 unknowns are easy to linearize 23

24 Cryptanalysis Known-Plaintext Attack 2/2 The basic attack Guess R4 and clock the cipher to obtain quadratic equations Linearize the equations to obtain A * x = z Solve x = A -1 * z to obtain a state candidate Use the candidate to generate keystream and compare it Result: For approx. 655 bits of successive keystream we need 2 16 steps on average to obtain K To be honest: one step is quite involved Generate equations Solve system in 655 unknowns Compute and the resulting keystream However, precomputations still make this attack fast (1 min) 24

25 Cryptanalysis Ciphertext-Only Attack 1/2 A ciphertext-only attack is possible Based on ideas of Barkan et. Al., 2003 Additional Observations Frames are encoded in order to add redundancy Encoding/decoding is linear in GF(2) Encoding is applied prior to encryption Consider the generator-matrix G and parity-check matrix H Encode + Encrypt: m = (d * G) and m = m + z Decrypt + Decode : r = m + z and r = H * r Due to the construction of H we have H * m = 0 iff m was received without errors H * m = H * (m + z) = H * m + H * z = H * z = H * (A * x) = S * x 25

26 Cryptanalysis Ciphertext-Only Attack 2/2 S * x = H * m is in variables of the initial state Plaintext is canceled out due to encoding Adapt attack to GMR-1 Guess parts of R1, R2 and R3 to reduce variables and equations Increases the number of guesses Result: Attack on the FACCH9 channel requires one FACCH9 frame and 2 32 steps Sadly, real-world data shows that FACCH9 is actually never used However, we can adapt this attack to the frequently used TCH3 channel.. 26

27 New results as of a photo 27

28 New results as of a screenshot 28

29 GMR-2

30 GMR-2 Next Victim GMR-2 implemented by Inmarsat Use Inmarsat IsatPhonePro (again, no specific reason) Pure static analysis only 30

31 Detecting the Phone's Hardware Firmware contains plenty of assertion/log strings again Contains some strings refering to LeMans AD6900 platform (by Analog Devices) Combines ARM CPU with Blackfin DSP Phone runs on AMX AOS Some proprietary OS, no documentationa available 31

32 Blackfin Disassembler Blackfin code is interleaved in image IDA does not support Blackfin assembler language Need to create our own tools Developed own Blackfin disassembler Recursive traversal Basic functionality to resolve string / function references and annotate the disassembly 32

33 Find Cipher Code Where do we start? Blackfin Image has some interesting strings! This seems to be a good place to begin with ;) 33

34 Find Cipher Code The Mysteries of ApplyCipher ApplyCipher takes plaintext + key as parameters and just XORs the plaintext with the key No key generation nearby But we can backtrack the parameters to see where the key memory area is actually filled Problem: This is non-trivial. Too much code involved Can only see where the key area is initialized with zeros Key generation must happen somewhere in between 34

35 Find Cipher Code Reverse Callgraph 10 different threads that eventually call ApplyCipher All threads implement a state machine at the top level Threads are large: plenty of work to reverse Can we further reduce the relevant code base? 35

36 Find Cipher Code Code Intersection Every thread must eventually call the key generation code Create (nested) call graph of each thread and intersect them: only keep functions which are called from all threads Result: 13 functions left. This looks more reasonable At first yielded function that includes the frame number in cipher key generation Also identified some generic div/rem/mul functions 36

37 Cryptanalysis Meet A5-GMR-2 Structure emerged after analysis *)!!!! The cipher operates on bytes 8-byte state array stores previous keystream* Three major function blocks F, G, H Clocking shifts register S, increments C and toggles T 37

38 Cryptanalysis Components of the cipher: F Characteristics of the F-function ( Key Schedule?) 8-byte array holding the session key K, read from two sides The lower side outputs K sequentially The upper output depends on the lower output, p and t T1 maps 4 bits to a 3-bit input for T2 (and the multiplexer) T2 determines the rotation 38

39 Cryptanalysis Components of the cipher: G Characteristics of the linear G-function ( Mixing Layer?) The inputs I 0, I 1 to G are F s outputs S 0 is one byte of the state array B1-B3 are tables implementing simple Boolean arithmetic 39

40 Cryptanalysis Components of the cipher: H Characteristics of the H-function ( Non-Linear XY??! ) The inputs I 0, I 1 to H are G s outputs S2 and S6 are (re-arranged) S-boxes from DES Z l represents one byte of keystream 40

41 Cryptanalysis Encryption in GMR-2 Frames have a fixed length of 120 bits See GMR-1 Session key K (from nonce and secret on SIM-card) Frame number FN (22-bit) A5-GMR-2 is re-initialized for each frame The key-array is loaded with K The state-array is initialized with FN The first 8 byte are discarded 41

42 Cryptanalysis Known-Plaintext Attack 1/4 An efficient known-plaintext attack is possible Observations The lower multiplexer outputs K 0, K 1, K 2.. Both multiplexers might select the same keybyte, we call this a (read) collision Sometimes, only the nibbles of the upper byte are swapped p is known keystream 42

43 Cryptanalysis Known-Plaintext Attack 2/4 Step 1: Detect read collisions in K 0 (and K 4 ) Examine keybytes Z 8,Z 16,Z 24 Output of lower multiplexer is known: K 0 for Z i*8, (K 4 for Z 4+i*8 ) Look at inputs/outputs of the S-Boxes independently Assume relations between bits of K 0 on the input-side Test for relations by mapping keybytes to potential S-Box inputs (i.e., invert S-Boxes) If relations hold, a collision may have happened Hypothesis for K 0 can be computed from keystream False-positives are possible Attempt detection for many keybytes and store hypotheses for K 0 Hypothesis which occurs most frequently is most likely correct 43

44 Cryptanalysis Known-Plaintext Attack 3/4 Step 2: Given K 0,K 4 brute-force the remaining bytes separately Examine keystream again.. Use positions for which the lower multiplexer selects a known keybyte (initially, K 0 and K 4 ) Determine which byte is selected by the upper multiplexer Avoid collisions with keybytes we already know Brute-force for the unknown keybyte Based on the known and the guessed byte, compute keystream If the keystream byte matches, our guess was correct 44

45 Cryptanalysis Known-Plaintext Attack 4/4 Result: bytes of keystream (5-6 frames) required, 2 18 steps on average to recover the full key Here, a step is guessing a byte and some XOR ing of bits easy and fast (1 second) Keystream/time tradeoff: frames, 2 10 single byte guesses From GMR-1 we know that some frames are predictable Might also apply to GMR-2?! 45

46 Thank you for your attention!