|
@@ -6,7 +6,7 @@ data: 17.02.22
|
|
|
|
|
|
# Agenda
|
|
# Agenda
|
|
|
|
|
|
-* Speck Schiffre
|
|
|
|
|
|
+* Speck Chiffre
|
|
* CPA Angriffe
|
|
* CPA Angriffe
|
|
* CPA auf Speck
|
|
* CPA auf Speck
|
|
* Gegenmaßnahmen
|
|
* Gegenmaßnahmen
|
|
@@ -17,9 +17,10 @@ data: 17.02.22
|
|
|
|
|
|
# Speck
|
|
# Speck
|
|
|
|
|
|
-* Symmentrische ARX Schiffre
|
|
|
|
|
|
+* Symmentrische ARX Chiffre
|
|
* Add/Rotate/XOR
|
|
* Add/Rotate/XOR
|
|
-* Entworfen von der NSA (Zusammen mit der Schiffre Simon)
|
|
|
|
|
|
+ * Effizient und einfach umzusetzen
|
|
|
|
+* Entworfen von der NSA (Zusammen mit der Chiffre Simon)
|
|
* Performant in Hard-/Software
|
|
* Performant in Hard-/Software
|
|
* Speck bietet mehrere mögliche Modis
|
|
* Speck bietet mehrere mögliche Modis
|
|
- Anzahl Runden, Schlüssellänge, Blocklänge
|
|
- Anzahl Runden, Schlüssellänge, Blocklänge
|
|
@@ -49,8 +50,9 @@ data: 17.02.22
|
|
|
|
|
|
![](img/rundenfunktion.png){width=400px}
|
|
![](img/rundenfunktion.png){width=400px}
|
|
|
|
|
|
-* Wird während der Key Schedule aufgerufen
|
|
|
|
-* Wird beim der Verschlüsselung aufgerufen
|
|
|
|
|
|
+* Wird für die Generierung des Rundenschlüssels aufgerufen
|
|
|
|
+* Wird bei der Verschlüsselung des Klartextes aufgerufen
|
|
|
|
+* Arbeitet auf zwei geteiltem Input
|
|
|
|
|
|
---
|
|
---
|
|
|
|
|
|
@@ -133,7 +135,7 @@ void FuncER16(u16 *x, u16 *y, u16 k)
|
|
|
|
|
|
* Passendes Modell zum 'bewerten' des Stromverbrauchs
|
|
* Passendes Modell zum 'bewerten' des Stromverbrauchs
|
|
* Chip hat ein gewissen Basisverbrauch (IDLE)
|
|
* Chip hat ein gewissen Basisverbrauch (IDLE)
|
|
-* Werden Bytes im Chip verändert ($0 \rightarrow 1 ; 1 \rightarrow 0$) wird Strom benötigt
|
|
|
|
|
|
+* Werden Bytes im Chip verändert ($0 \rightarrow 1 ; 1 \rightarrow 0$), wird Strom benötigt
|
|
* Verhalten kann durch die Hamming-Distanz simuliert werden
|
|
* Verhalten kann durch die Hamming-Distanz simuliert werden
|
|
* **Hamming Distanz:** Anzahl der Veränderter Bits:
|
|
* **Hamming Distanz:** Anzahl der Veränderter Bits:
|
|
|
|
|
|
@@ -183,14 +185,14 @@ $\rightarrow$ Das korrekte Keybyte ist: 0x68
|
|
|
|
|
|
# T-Test
|
|
# T-Test
|
|
|
|
|
|
-* Wird verwendet um _Leakage_ zu erkennen
|
|
|
|
|
|
+* Kann verwendet werden, um _Leakage_ zu erkennen
|
|
- Gibt das Berechnen einer Chiffre mehr Information zurück als geplant: Leakage
|
|
- Gibt das Berechnen einer Chiffre mehr Information zurück als geplant: Leakage
|
|
- Ausnutzbar z.B. durch die Power Traces
|
|
- Ausnutzbar z.B. durch die Power Traces
|
|
* Berechnet durch:
|
|
* Berechnet durch:
|
|
|
|
|
|
![](img/ttest_calc.png)
|
|
![](img/ttest_calc.png)
|
|
|
|
|
|
-* Vergleicht zwei unabhängige Stichproben miteinander, und vergleicht Mittelwerte
|
|
|
|
|
|
+* Vergleicht zwei unabhängige Stichproben miteinander
|
|
* Je unterschiedlicher die Mittelwerte $\rightarrow$ desto weniger Leakage
|
|
* Je unterschiedlicher die Mittelwerte $\rightarrow$ desto weniger Leakage
|
|
|
|
|
|
---
|
|
---
|
|
@@ -201,7 +203,7 @@ $\rightarrow$ Das korrekte Keybyte ist: 0x68
|
|
|
|
|
|
![](img/t_test_original.png)
|
|
![](img/t_test_original.png)
|
|
|
|
|
|
-
|
|
|
|
|
|
+* Erkennbar, dass Leakage vorhanden sein muss
|
|
---
|
|
---
|
|
|
|
|
|
# Angriff - Hardware
|
|
# Angriff - Hardware
|
|
@@ -218,7 +220,7 @@ $\rightarrow$ Das korrekte Keybyte ist: 0x68
|
|
|
|
|
|
# Korrelationen des ersten Keybytes
|
|
# Korrelationen des ersten Keybytes
|
|
|
|
|
|
-* Correlationen des ersten Keybytes
|
|
|
|
|
|
+* Korrelationen des ersten Keybytes
|
|
* Korrelation fällt höher aus als im Modell
|
|
* Korrelation fällt höher aus als im Modell
|
|
* Deutliches Maximum der Korrelation bei 0x22 (Korrektes Keybyte)
|
|
* Deutliches Maximum der Korrelation bei 0x22 (Korrektes Keybyte)
|
|
|
|
|
|
@@ -229,10 +231,10 @@ $\rightarrow$ Das korrekte Keybyte ist: 0x68
|
|
|
|
|
|
# Problem: Blocksize
|
|
# Problem: Blocksize
|
|
|
|
|
|
-* Bei **Speck1632:** Operationen nicht auf Byte sondern auf 16-Bit Ebene
|
|
|
|
|
|
+* Bei **Speck3264:** Operationen nicht auf Byte, sondern auf 16-Bit Ebene
|
|
* Erste Idee: Modell und Korrelation auf $2^16$ Keys
|
|
* Erste Idee: Modell und Korrelation auf $2^16$ Keys
|
|
* $\rightarrow$ Keyspace ist abdeckbar (65536 Keys)
|
|
* $\rightarrow$ Keyspace ist abdeckbar (65536 Keys)
|
|
-* $\rightarrow$ Zu langsam, Unschön
|
|
|
|
|
|
+* $\rightarrow$ Zu langsam
|
|
* $\rightarrow$ Nicht möglich für andere Modis von Speck (32 Bit Subkeys)
|
|
* $\rightarrow$ Nicht möglich für andere Modis von Speck (32 Bit Subkeys)
|
|
* **Lösung:** Modell funktioniert auch auf allen Teilbytes per Shift:
|
|
* **Lösung:** Modell funktioniert auch auf allen Teilbytes per Shift:
|
|
|
|
|
|
@@ -258,7 +260,7 @@ for i in 0..<22
|
|
ER16(Ct[1], Ct[0], rk[i++])
|
|
ER16(Ct[1], Ct[0], rk[i++])
|
|
```
|
|
```
|
|
|
|
|
|
-* Die (bereits bekannten) Rundenkeys müssen miteingeschlossen werden
|
|
|
|
|
|
+* Die bereits bekannten Rundenschlüssel müssen mit eingeschlossen werden
|
|
* Muss an der richtigen Stelle passieren ($\oplus$-Operation)
|
|
* Muss an der richtigen Stelle passieren ($\oplus$-Operation)
|
|
|
|
|
|
---
|
|
---
|
|
@@ -319,7 +321,7 @@ for i in 0..<22
|
|
* **Ansatz:** Korrelation kommt von `ER16()`
|
|
* **Ansatz:** Korrelation kommt von `ER16()`
|
|
* Add/XOR/Rotate
|
|
* Add/XOR/Rotate
|
|
* Hinzufügen weitere AXR Operationen um noise zu erhöhen
|
|
* Hinzufügen weitere AXR Operationen um noise zu erhöhen
|
|
-* Ersetzen von jeder XOR Operatione mit folgender:
|
|
|
|
|
|
+* Ersetzen von jeder XOR Operation mit folgender Implementierung:
|
|
|
|
|
|
```C
|
|
```C
|
|
uint16_t XOR(uint16_t a, uint16_t b, int random) {
|
|
uint16_t XOR(uint16_t a, uint16_t b, int random) {
|
|
@@ -343,15 +345,15 @@ uint16_t XOR(uint16_t a, uint16_t b, int random) {
|
|
|
|
|
|
![](img/t_test_hiding_random.png)
|
|
![](img/t_test_hiding_random.png)
|
|
|
|
|
|
-* Bedarf weitere Analysen, Unterschied der beiden T-Tests sind nur Minimal
|
|
|
|
-* **Keine** Indikation dass Hiding funktioniert laut T-Test
|
|
|
|
|
|
+* Bedarf weiterer Analysen, denn Unterschiede der beiden T-Tests sind nur minimal
|
|
|
|
+* Laut T-Test **keine** Indikation dass Hiding funktioniert
|
|
|
|
|
|
---
|
|
---
|
|
|
|
|
|
|
|
|
|
# Korrelationen des ersten Keybytes
|
|
# Korrelationen des ersten Keybytes
|
|
|
|
|
|
-* Besseres Ergbniss der Korrelationen bis 5000 Traces
|
|
|
|
|
|
+* Besseres Ergebnis der Korrelationen bis 5000 Traces
|
|
* Korrelationen flachen ab ~800 drastisch ab
|
|
* Korrelationen flachen ab ~800 drastisch ab
|
|
* Keine Korrelation sticht heraus
|
|
* Keine Korrelation sticht heraus
|
|
|
|
|
|
@@ -360,14 +362,15 @@ uint16_t XOR(uint16_t a, uint16_t b, int random) {
|
|
|
|
|
|
- Es war nicht möglich den Angriff erneut durchzuführen
|
|
- Es war nicht möglich den Angriff erneut durchzuführen
|
|
- Neue Korrelationen nach einigen Test lediglich bei ~0.18 mit falschem Keybyte
|
|
- Neue Korrelationen nach einigen Test lediglich bei ~0.18 mit falschem Keybyte
|
|
|
|
+- $\rightarrow$ Maßnahme ist erfolgreich
|
|
|
|
|
|
---
|
|
---
|
|
|
|
|
|
-# Hiding (Potentieller) Bypass
|
|
|
|
|
|
+# Hiding (potentieller) Bypass
|
|
|
|
|
|
-* Korrelation sollte weiterhin möglich sein wenn man die Operationen in Betracht zieht
|
|
|
|
|
|
+* Korrelation sollte weiterhin möglich sein, wenn die Operationen in Betracht gezogen werden
|
|
* Schwierigkeit hängt am Zufallszahlengenerator
|
|
* Schwierigkeit hängt am Zufallszahlengenerator
|
|
-* **Problem:** Sichere Zufallszahlen auf Embedded Chips ist nicht trivial
|
|
|
|
|
|
+* **Problem:** Sichere Zufallszahlen auf Embedded Chips sind nicht trivial
|
|
|
|
|
|
$\rightarrow$ Bypass konnte **nicht** realisiert werden
|
|
$\rightarrow$ Bypass konnte **nicht** realisiert werden
|
|
|
|
|