--- title: CPA Angriff auf Speck author: Robin Dietrich & Marius Schwarz data: 17.02.22 --- # Agenda * Speck Chiffre * CPA Angriffe * CPA auf Speck * Gegenmaßnahmen * Hiding --- # Speck * Symmentrische ARX Chiffre * Add/Rotate/XOR * Effizient und einfach umzusetzen * Entworfen von der NSA (Zusammen mit der Chiffre Simon) * Performant in Hard-/Software * Speck bietet mehrere mögliche Modis - Anzahl Runden, Schlüssellänge, Blocklänge * Paper: [Simon and Speck: Block Ciphers for the Internet of Things](https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf) --- # Speck - Setups | Speck | Blocklänge | Schlüssellänge | Runden | | ------------------------------------------------ | --------------------------------------------- | --------------------------------------------- | ----------------------------------------- | | **Speck3264** | **32 Bit** | **64 Bit** | **22** | | Speck4872 | 48 Bit | 72 Bit | 22 | | Speck4896 | 48 Bit | 96 Bit | 23 | | Speck6496 | 64 Bit | 96 Bit | 26 | | Speck64128 | 64 Bit | 128 Bit | 27 | | Speck9696 | 96 Bit | 96 Bit | 28 | | Speck96144 | 96 Bit | 144 Bit | 29 | | Speck128128 | 128 Bit | 128 Bit | 32 | | Speck128192 | 128 Bit | 192 Bit | 33 | | Speck1281256 | 128 Bit | 256 Bit | 34 | --- # Speck - Rundenfunktion ![](img/rundenfunktion.png){width=400px} * Wird für die Generierung des Rundenschlüssels aufgerufen * Wird bei der Verschlüsselung des Klartextes aufgerufen * Arbeitet auf zwei geteiltem Input --- # Speck - Pseudocode ```C pt = Plaintext Bytes Pt = Plaintext as 16 Bit Words ct = Ciphertext Bytes Ct = Ciphertext as 16 Bit Words k = Key as Bytes K = Key as 16 Bit Words // Key Schedule D=K[3], C=K[2], B=K[1], A=K[0] for i in 0..<22 rk[i]=A ER16(B, A, i++) rk[i]=A ER16(C, A, i++) rk[i]=A ER16(D, A, i++) // Encryption Ct[0]=Pt[0]; Ct[1]=Pt[1]; for i in 0..<22 ER16(Ct[1], Ct[0], rk[i++]) ``` --- # Speck - Möglicher Angriff * Angriff der Rundenfunktion * ADD/XOR/ROT Operationen ```C void FuncER16(u16 *x, u16 *y, u16 k) { u16 tmp_x = *x; u16 tmp_y = *y; *x = (((tmp_x)>>(7)) | ((tmp_x)<<(16-(7)))); // ROR(7) *x += *y; *x = *x ^ k; *y = (((tmp_y)<<(2)) | (tmp_y>>(16-(2)))); // ROL(2) *y = *y ^ *x; } ``` --- # Speck - Möglicher Angriff * Der Rundenschlüssel steckt in der XOR Operation: ![](img/er16_enc_rk.png) ![](img/er16_annot.png) --- # Correlation Power Analysis * Variante von Differential Power Analysis (DPA) * Nutzt Pearson Correlation Coefficient (PCC) * **Bei Speck:** Korrelation zwischen Power-Trace und Rundenschlüssel * Vorgehen: - Modell erstellen - Finden der Korrelationen im Modell - Anwenden auf Hardware Implementierung --- # Hamming Weight * Passendes Modell zum 'bewerten' des Stromverbrauchs * Chip hat ein gewissen Basisverbrauch (IDLE) * Werden Bytes im Chip verändert ($0 \rightarrow 1 ; 1 \rightarrow 0$), wird Strom benötigt * Verhalten kann durch die Hamming-Distanz simuliert werden * **Hamming Distanz:** Anzahl der veränderten Bits: $$HD(0100101, 0010101) = 2$$ Der Unterschied zweier per XOR verknüpfter Daten, wird als Hamming-Gewicht bezeichnet: $$HammingDistance(0100101, 0010101) = HammingWeight(0100101 \oplus 0010101)$$ --- # Speck - Modell * Einfaches Modell der Speck Verschlüsselung * Kann für die ersten 2 Byte des Rundenschlüssels genutzt werden: ```Python def simple_speck(plaintext, key): Ct_0 = (int(plaintext[1]) << 8) + int(plaintext[0]) # RIGHT Key Ct_1 = (int(plaintext[3]) << 8) + int(plaintext[2]) # LEFT Key Ct_1, Ct_0 = ER16(Ct_1, Ct_0, key) # Calculate Roundfunction return popcount((Ct_1 << 8) + Ct_0) # Return Hamming Weight (aka Popcount) ``` --- # Speck - Simulation 1) Simulation anhand des Modells mit $n$ traces 2) Generieren von $n$ zufälligen Klartexten mit **fixem** Keybyte (+ noise) 3) Simulation aller möglichen Keybytes per Hamming Weight 4) Berechnen des PCC aller Keys über alle traces ![](img/simulation_corr.png) $\rightarrow$ Das korrekte Keybyte ist: 0x68 --- # Angriff - Hardware 1) Implementierung von Speck auf CW 2) Aufzeichnen von $n$ Power Traces 3) Leakage Test 4) Berechnung des Software Modells 5) Berechnen der Korrelationen zwischen Modell/Powertraces - Keybyte für Keybyte - Rückrechnen des Rundenschlüssels --- # T-Test * Kann verwendet werden, um _Leakage_ zu erkennen - Gibt das Berechnen einer Chiffre mehr Information zurück als geplant: Leakage - Ausnutzbar z.B. durch die Power Traces * Berechnet durch: ![](img/ttest_calc.png) * Vergleicht zwei unabhängige Stichproben miteinander * Je unterschiedlicher die Mittelwerte $\rightarrow$ desto mehr Leakage --- # T-Test * T-Test der aufgezeichneten Power-Traces: ![](img/t_test_original.png) * Erkennbar, dass Leakage vorhanden sein muss --- # Korrelationen des ersten Keybytes * Korrelationen des ersten Keybytes * Korrelation fällt höher aus als im Modell * Deutliches Maximum der Korrelation bei 0x22 (Korrektes Keybyte) ![](img/correlation_first_keybyte.png){width=550px} --- # Problem: Blocksize * Bei **Speck3264:** Operationen nicht auf Byte, sondern auf 16-Bit Ebene * Erste Idee: Modell und Korrelation auf $2^16$ Keys * $\rightarrow$ Keyspace ist abdeckbar (65536 Keys) * $\rightarrow$ Zu langsam * $\rightarrow$ Nicht möglich für andere Modis von Speck (32 Bit Subkeys) * **Lösung:** Modell funktioniert auch auf allen Teilbytes per Shift: ```Python rightkey = 0x00 for guess_key in range(256): leftkey = model( (guess_key << 8) + righkey ) for guess_key in range(256): rightkey = model( (leftkey << 8) + guess_key ) ``` * Auch umsetzbar auf Speck mit Blocksize > 16 Bit --- # Problem: $n^{th}$ Keybytes * Modell kann nur für die ersten zwei Keybytes genutzt werden, da: ```C for i in 0..<22 ER16(Ct[1], Ct[0], rk[i++]) ``` * Die bereits bekannten Rundenschlüssel müssen mit eingeschlossen werden * Muss an der richtigen Stelle passieren ($\oplus$-Operation) --- # Problem: $n^{th}$ Keybytes * Anpassung des Modells: ```Python # -------------- for one key -----------------# x = ((x << (16 - ALPHA)) + (x >> ALPHA)) & mod_mask # x = ROR(x, 7) x = (x + y) & mod_mask # x = ADD(x, y) x = x ^ knownkey[0] # -------------- for second key -----------------# y = ((y >> (16 - BETA)) + (y << BETA)) & mod_mask # y = ROL(y, 2) y = y ^ x # y = XOR(y, x) x = ((x << (16 - ALPHA)) + (x >> ALPHA)) & mod_mask # x = ROR(x, 7) x = (x + y) & mod_mask # x = ADD(x, y) x = x ^ knownkey[1] # x = XOR(x, k) # -------------- for third key -----------------# # [...] ``` --- # Korrelationen des ersten Keybytes * Graph zeigt die Korrelationen des ersten Keybytes bis 5000 traces * Ab ~800 Traces hebt sich die Korrelation deutlich hervor ![](img/traces.png){width=550px} --- # Gegenmaßnahmen --- # Hiding * Verstecken des eigentlichen "Leakages" in Rauschen * $\rightarrow$ Erhöhung des vorhandenen Rauschens während der Berechnung * Mehrere Möglichkeiten * Mischen der Instruction-Order * **Hinzufügen von "Dummy Instructionen"** * Clock Jitter --- # Hiding - Code * **Ansatz:** Korrelation kommt von `ER16()` * Add/XOR/Rotate * Hinzufügen weitere AXR Operationen um noise zu erhöhen * Ersetzen von jeder XOR Operation mit folgender Implementierung: ```C uint16_t XOR(uint16_t a, uint16_t b, int random) { uint8_t tmp = random ^ 0x5F; tmp ^= (random ^ a); tmp ^= (tmp ^ b); tmp &= (tmp & a); tmp &= (tmp & b); return a ^ b; } ``` * `Random` wird bei jeder Verschlüsslung erneut generiert --- # Hiding - T-Test * Ergebnisse des T-Tests mit implementierter Hiding Maßnahmen: ![](img/t_test_hiding_random.png) * Bedarf weiterer Analysen, denn Unterschiede der beiden T-Tests sind nur minimal * Laut T-Test **keine** Indikation dass Hiding funktioniert --- # Korrelationen des ersten Keybytes * Besseres Ergebnis der Korrelationen bis 5000 Traces * Korrelationen flachen ab ~800 drastisch ab * Keine Korrelation sticht heraus ![](img/corr_traces_hiding_5k.png){width=550px} - Es war nicht möglich den Angriff erneut durchzuführen - Neue Korrelationen nach einigen Tests lediglich bei ~0.18 mit falschem Keybyte - $\rightarrow$ Maßnahme ist erfolgreich --- # Hiding (potentieller) Bypass * Korrelation sollte weiterhin möglich sein, wenn die Operationen in Betracht gezogen werden * Schwierigkeit hängt am Zufallszahlengenerator * **Problem:** Sichere Zufallszahlen auf Embedded Chips sind nicht trivial $\rightarrow$ Bypass konnte **nicht** realisiert werden --- # Referenzen * [Improved Differential Cryptanalysis of Round-Reduced Speck](Improved Differential Cryptanalysis of Round-Reduced Speck) * [Breaking Speck cryptosystem using correlation power analysis attack](Breaking Speck cryptosystem using correlation power analysis attack) * [Speck-R: An ultra light-weight cryptographic scheme for Internet of Things]({Speck-R: An ultra light-weight cryptographic scheme for Internet of Things)