Przeglądaj źródła

Dateien hochladen nach ''

rdi 2 lat temu
rodzic
commit
7d59bd6a83
1 zmienionych plików z 23 dodań i 20 usunięć
  1. 23 20
      slides.md

+ 23 - 20
slides.md

@@ -6,7 +6,7 @@ data: 17.02.22
 
 # Agenda
 
-* Speck Schiffre
+* Speck Chiffre
 * CPA Angriffe
 * CPA auf Speck
 * Gegenmaßnahmen
@@ -17,9 +17,10 @@ data: 17.02.22
 
 # Speck
 
-* Symmentrische ARX Schiffre
+* Symmentrische ARX Chiffre
 	* 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
 * Speck bietet mehrere mögliche Modis
     - Anzahl Runden, Schlüssellänge, Blocklänge
@@ -49,8 +50,9 @@ data: 17.02.22
 
 ![](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
 * 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
 * **Hamming Distanz:**  Anzahl der Veränderter Bits:
 
@@ -183,14 +185,14 @@ $\rightarrow$ Das korrekte Keybyte ist: 0x68
 
 # 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
 	- Ausnutzbar z.B. durch die Power Traces
 * Berechnet durch:
 
 ![](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
 
 ---
@@ -201,7 +203,7 @@ $\rightarrow$ Das korrekte Keybyte ist: 0x68
 
 ![](img/t_test_original.png)
 
-
+* Erkennbar, dass Leakage vorhanden sein muss
 ---
 
 # Angriff - Hardware
@@ -218,7 +220,7 @@ $\rightarrow$ Das korrekte Keybyte ist: 0x68
 
 # Korrelationen des ersten Keybytes
 
-* Correlationen des ersten Keybytes
+* Korrelationen des ersten Keybytes
 * Korrelation fällt höher aus als im Modell
 * Deutliches Maximum der Korrelation bei 0x22 (Korrektes Keybyte)
 
@@ -229,10 +231,10 @@ $\rightarrow$ Das korrekte Keybyte ist: 0x68
 
 # 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
 * $\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)
 * **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++])
 ```
 
-* 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)
 
 ---
@@ -319,7 +321,7 @@ for i in 0..<22
 * **Ansatz:** Korrelation kommt von `ER16()`
 	* Add/XOR/Rotate
 * 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
 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)
 
-* 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
 
-* Besseres Ergbniss der Korrelationen bis 5000 Traces
+* Besseres Ergebnis der Korrelationen bis 5000 Traces
 * Korrelationen flachen ab ~800 drastisch ab
 * 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
 - 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
-* **Problem:** Sichere Zufallszahlen auf Embedded Chips ist nicht trivial
+* **Problem:** Sichere Zufallszahlen auf Embedded Chips sind nicht trivial
 
 $\rightarrow$ Bypass konnte **nicht** realisiert werden