Kapitel 2: Chipkarten

Transkript

1 Kapitel 2: Chipkarten Chip card technologies hold great promise as the replacement for magnetic stripe card technology. However, the adoption of chip cards onamassscalehasbeenslowtodevelop.onesignificantreasonforthis slow adoption is the lack of standards among many different vendor implementations of chip cards. The world s leading financial institutions that make up the membership of the Visa International Service Association have identified multiapplication chip cards as the strategic technology for future banking cards. Software- und Systemsicherheit, Kap. 2 (1/17)

2 Plastikkarten 1. Diners Club Kreditkarte (50er Jahre) mit Aufdruck des Karteninhabers 2. Prägedruck 3. Magnetstreifen 4. Identification Card with Integrated Circuit (Patent 1968) 5. Speicherkarte (Memory Card) 6. SmartCard (Integrated Circuit Card, ICC) Software- und Systemsicherheit, Kap. 2 (2/17)

3 SmartCards 8/16 Bit CPU 32K ROM 16 64K EEPROM 0,5 4K RAM 5 Mhz clock 1024 Bit RSA/3-DES Bit/sec C 1 C 2 C 3 C 5 C 6 C 7 1,25 1,1 C 1 : Vcc = 5V C 2 : Reset C 3 : Clock C 5 : Ground C 6 : Vpp C 7 : I/O Software- und Systemsicherheit, Kap. 2 (3/17)

4 SmartCards 32 Bit CPU 240 K ROM 400 K EEPROM 16 K RAM 66 Mhz clock 2048 Bit RSA/EC C 1 C 2 C 3 C 5 C 6 C 7 1,25 1,1 C 1 : Vcc = 5V C 2 : Reset C 3 : Clock C 5 : Ground C 6 : Vpp C 7 : I/O Software- und Systemsicherheit, Kap. 2 (4/17)

5 Normierung: ISO ( ) ISO Physical characteristics ISO Dimensions and location of the contacts ISO Electronic signals and transmission protocols ISO Inter-industry commands for interchange ISO Personal verification through biometric methods Normierung essentiell für globalen Masseneinsatz Software- und Systemsicherheit, Kap. 2 (5/17)

6 ISO7816 1: Physical characteristics Schutz gegen UV Licht/Röntgenstrahlen Schutz vor (statischer) Elektrizität/Magnetfeld Breite 85.47mm mm, Höhe 53.92mm mm, Dicke 0.76mm mm Höhe der Kontakte: < 0.1 mm Differenz zur Karte Schutz gegen Druck auf die Oberfläche Verbiegen: 2cm längs, 1cm quer (30 pro sec., 1000 Mal) Verdrehen: 15 Grad (30 pro sec., 1000 Mal) Software- und Systemsicherheit, Kap. 2 (6/17)

7 Spezifikation der Kontakte Software- und Systemsicherheit, Kap. 2 (7/17)

8 ISO7816-3: Signale I/O : (C 7) serielle Datenübertragung VPP : (C 6) Programmierspannung (für EEPROM) GND : (C 5) Erdung CLK : (C 3) Takt (5 Mhz) wird ausgehandelt RST : (C 2) Reset VCC : (C 1) Stromversorgung: 4,75 V 5,25, 200 ma (C 4, C 8) unbenutzt Software- und Systemsicherheit, Kap. 2 (8/17)

9 Weitere Spezifikationen EMV 4.1: Integrated Circuit Card Specification for Payment Systems Erweiterungen für Kreditkarten (PINs, authenticate) Europay, MasterCard, Visa Global Platform Card Specification life cycle, Card manager, security domains Global Platform, Visa PC/SC: Interoperability Specification for ICCs and Personal Computer Systems Kommunikation mit Kartenleser Bull, Gemplus/Gemalto, HP, IBM, Microsoft, Schlumberger, Siemens, Sun, Toshiba, VeriFone Software- und Systemsicherheit, Kap. 2 (9/17)

10 ETSI (European Telecommunications Standards Institute): GSM, UMTS EN 726 (Europäische Norm): Anforderungen an Chipkarten und Endgeräte für Telekommunikationszwecke ISO 10202: Bankkarten ISO 14443: Identification cards Contactless integrated circuit(s) cards Proximity cards (= RFIDs) ISO 18092, ECMA 340, ETSI TS : Near Field Communication Interface and Protocol (NFC)... Software- und Systemsicherheit, Kap. 2 (10/17)

11 Mitspieler Chiphersteller: Philips, Infineon, Hitachi, Siemens, Toshiba,... Betriebssysteme: JavaCard (SUN), MULTOS (Mondex), viele proprietäre JavaCard Kartenherausgeber: Gemplus/Gemalto, Schlumberger, Gieseke & Devriant, IBM Anwendungsspezifikationen: Visa, MasterCard, ZKA(Zentraler Kreditausschuss), gematik (Gesellschaft für Telematikanwendungen der Gesundheitskarte mbh), ICAO (International Civil Aviation Organization) Software- und Systemsicherheit, Kap. 2 (11/17)

12 Anwendungen Authentifizierung Speicher für PINs und geheime Schlüssel Reisepass, Studentenausweis, Führerschein,... SIM Elektronische Geldbörse Elektronische Fahrkarten Software- und Systemsicherheit, Kap. 2 (12/17)

13 Anwendungen Authentifizierung Speicher für PINs und geheime Schlüssel Reisepass, Studentenausweis, Führerschein,... SIM Elektronische Geldbörse Sicherheit Kein Speicher-Auslesen (tamper-proof, physikalisch) + starke Kryptographie (digitale Signaturen) + kryptographische Protokolle (anwendungsspezifisch) Kein unauthorisierter Zugriff (kein Lesen, kein Schreiben) Elektronische Fahrkarten Software- und Systemsicherheit, Kap. 2 (12/17)

14 Lebenszyklus einer SmartCard (EN 726) 1. Herstellung IC und Karte (Hersteller) Chip- und Modulherstellung, Einsetzen in Karte 2. Initialisierung der Karte (Kartenherausgeber, card issuer) Laden von Betriebssystem, geheimen Schlüsseln 3. Personalisierung der Karte (Anwendungsanbieter, application provider) Laden der Anwendung, geheimer Schlüssel, PINs etc. 4. Benutzung der Karte (Inhaber, card holder) 5. Beendigung der Benutzung Löschen der Anwendung, Sperren der Karte Software- und Systemsicherheit, Kap. 2 (13/17)

15 Multiapplikative Karten/Global Platform Cardmanager gehört Card Issuer verwaltet Schlüssel lädt/löscht Anwendungen während der Benutzungsphase ist selbst Applikation mit Registry Security Domain gehört Application Provider verwaltet Schlüssel Delegated Management Privilege: darf selbst Anwendungen laden Software- und Systemsicherheit, Kap. 2 (14/17)

16 Application Life Cycle Multiapplikative Karten: Mehrere Anwendungen dynamisch (in der Benutzungsphase) ladbar 1. Laden des(digital signierten) Anwendungscodes(Executable Load File) AID (application identifier) in registry 2. Installieren der Anwendung: installed Ressourcenallokation, Linking, AID, Initialisierung 3. Personalisieren der Anwendung: selectable/personalized 4. Beenden der Anwendung: blocked, locked, gelöscht Software- und Systemsicherheit, Kap. 2 (15/17)

17 Eine Card Session Power Karte in Kartenleser Reset ATR, Answer to Reset Aushandeln Protokoll, Takt Cardmanager empfängt Kommandos Abfrage Applikationen (optional) select AID Auswahl Applikation Cardmanager schickt select + alle weiteren Kommandos (außer neuem select) an Applikation deselect (nicht garantiert!) Bei power off/reset kein deselect Rücksetzen von Authorisierungen bei select Software- und Systemsicherheit, Kap. 2 (16/17)

18 JavaCard Architektur Applet 1 Applet 1 Applet 1 Card Manager JavaCard API Java Card VM JCRE Card specific Operating System Software- und Systemsicherheit, Kap. 2 (17/17)

19 Kapitel 3: JavaCard Java für spezielle Geräte Designentscheidungen: Weglassen unsinniger Klassen/Hinzufügen nützlicher Klassen Berücksichtigung von Ressourcenbeschränkungen Anpassungen: JavaCard 2.x für Chipkarten (wir: 2.2.1) Mitte 2008: JavaCard 3, classic vs. connected edition Java 2 Micro Edition für Handhelds JavaTV für digitales TV (Settop Box) Software- und Systemsicherheit, Kap. 3 (1/16)

20 Kurze Auffrischung: Java Primitive Typen: boolean, byte, short, int, long, char, float, double Referenztypen: Objekte, Arrays, (Strings) Exceptions, dynamischer Methoden-Lookup Packages, Klassen, Interfaces, statische Initialisierung Applets, Threads, Garbage Collection vordefinierte Klassen: Class loader, security manager, Streams Erweiterungen: GUI (awt, swing), JCA (Java Cryptographic Architecture) Software- und Systemsicherheit, Kap. 3 (2/16)

21 JavaCard Primitive Typen: boolean, byte, short, int, long, char, float, double Referenztypen: Objekte, Arrays, (Strings) Exceptions, dynamischer Methoden-Lookup Packages, Klassen, Interfaces, statische Initialisierung Applets, Threads, Garbage Collection vordefinierte Klassen: Class loader, security manager, Streams Erweiterungen: GUI (awt, swing), J CA (Java Cryptographic Architecture) Software- und Systemsicherheit, Kap. 3 (3/16)

22 API: Zusätzliche Klassen APDU Kommunikation mit dem Terminal Applet Installieren und Starten der Anwendung JCSystem Transaktionen, Speicherverwaltung OwnerPIN Zugriff auf Karten-PIN ISO7816 Statusworte, Konstanten ISOException Exceptions Util Hilfsfunktionen KeyBuilder Kryptographie Cipher Ver-/Entschlüsseln Software- und Systemsicherheit, Kap. 3 (4/16)

23 Ein Applet auf die Karte laden 1. MyApplet.java programmieren 2. Mit (Standard) JDK Compiler (1.2/1.3) kompilieren (mit richtigem Classpath!) MyApplet.class 3. CAP Konverter: MyApplet.class MyApplet.cap bzw. MyApplet.jar CAP (= converted applet): ByteCode, besser codiert z.b.: Byte basiert, kein constant pool,... CAP Konverter konvertiert immer ein ganzes Package mehrere Klassen möglich, aber nur ein Package 4. Vorher: Offline byte code verifier Prüft, dass keine Strings, Integers, nicht unterstützte Klassen benutzt werden. Software- und Systemsicherheit, Kap. 3 (5/16)

24 Lebenszyklus eines Applets Nach Laden des.jar-files mit JCardManager: JCRE load install register Applet select process delete reset deselect Abgeleitet von Applet Methoden install, register, select, process, deselect Software- und Systemsicherheit, Kap. 3 (6/16)

25 Application Life Cycle Multiapplikative Karten: Mehrere Anwendungen dynamisch (in der Benutzungsphase) ladbar 1. Laden des(digital signierten) Anwendungscodes(Executable Load File) AID (application identifier) in registry 2. Installieren der Anwendung: installed Ressourcenallokation, Linking, AID, Initialisierung 3. Personalisieren der Anwendung: selectable/personalized 4. Beenden der Anwendung: blocked, locked, gelöscht Software- und Systemsicherheit, Kap. 3 (7/16)

26 import javacard.framework.*; class CopyCardSimple extends Applet { final static byte BALANCE = 0x02 ; final static byte LOAD = 0x04; final static byte PAY = 0x06; short value = 0; Software- und Systemsicherheit, Kap. 3 (8/16)

27 // called once by JCVM public static void install(byte[] barray, short boffset, byte blength) { new CopyCardSimple(); } CopyCardSimple() { register(); } oder register(barray, (short)(boffset+1),(byte)barray[boffset]) Software- und Systemsicherheit, Kap. 3 (9/16)

28 // called when applet is selected public boolean select() { return true; } // called for every APDU public void process(apdu apdu) throws ISOException { } switch (apdu.getbuffer()[iso7816.offset_ins]) { case LOAD: load(apdu) ; return; case PAY: pay(apdu) ; return; case BALANCE: balance(apdu) ; return; case ISO7816.INS_SELECT: return; default: ISOException.throwIt (ISO7816.SW_INS_NOT_SUPPORTED); } Software- und Systemsicherheit, Kap. 3 (10/16)

29 private void balance(apdu apdu) throws ISOException { byte expected = apdu.getbuffer()[iso7816.offset_lc]; if (expected!= 2) ISOException.throwIt(ISO7816.SW_WRONG_LENGTH); Util.setShort(apdu.getBuffer(), ISO7816.OFFSET_CDATA, value); apdu.setoutgoingandsend(iso7816.offset_cdata, (short) 2); } Software- und Systemsicherheit, Kap. 3 (11/16)

30 private void load(apdu apdu) throws ISOException { byte[] buf = apdu.getbuffer(); if (buf[4]!= 2) ISOException.throwIt(ISO7816.SW_WRONG_LENGTH); short len = apdu.setincomingandreceive(); if (len!= 2) ISOException.throwIt(ISO7816.SW_WRONG_LENGTH); short val = Util.getShort(buf, ISO7816.OFFSET_CDATA); if (val <= 0 (short)(val + value) > (short)1000 ) ISOException.throwIt(ISO7816.SW_DATA_INVALID); value += val; } Software- und Systemsicherheit, Kap. 3 (12/16)

31 private void pay(apdu apdu) throws ISOException { short len = apdu.setincomingandreceive(); if (len!= 2) ISOException.throwIt(ISO7816.SW_WRONG_LENGTH); byte[] buf = apdu.getbuffer(); short val = Util.getShort(buf, ISO7816.OFFSET_CDATA); if (val <= 0 (short)(value - val) < 0) ISOException.throwIt(ISO7816.SW_DATA_INVALID); value -= val; ISOException.throwIt(ISO7816.SW_NO_ERROR); } } // end of class CopyCardSimple Software- und Systemsicherheit, Kap. 3 (13/16)

32 Speichermanagement EEPROM: electrically erasable programmable read-only memory, persistent Appletcode + Heap (Felder + Objekte + Arrays) RAM: random access memory, transient, flüchtig Lokale Variablen + transiente Arrays Stromausfall Transaktionen (für Zuweisungen) kein deselect Initialisierung in select Software- und Systemsicherheit, Kap. 3 (14/16)

33 Programmierrichtlinien Keine Garbage-Collection, langsames EEPROM So einfach wie möglich programmieren Alle Objekte/Arrays beim Installieren anlegen (bzw. beim ersten select) Lokale Variablen liegen im RAM Laufvariablen lokal! (wesentlich schneller, schont EEPROM) Lokale Variablendeklaration byte[] nonce = new byte[8]; allokiert Array im Heap (EEPROM) Keine rekursiven Methoden Möglichst nichts statisch (außer Konstanten) Software- und Systemsicherheit, Kap. 3 (15/16)

34 Speicher wird allokiert bei new AnyObject(); 2. new byte[25] 3. byte[] ar = {0,0,0,0}; 4. jeder javacard...getinstance() Methode Speicher wird nicht allokiert bei apdu.getbuffer() 2. Util.arrayCopy(...) 3. DESKey.setKey(...) 4. Cipher.init(...) Software- und Systemsicherheit, Kap. 3 (16/16)

35 Kapitel 4: Kommunikation mit der Karte Relevanter Standard: ISO Kartenleser/Terminal: Master, Smartcard: Slave APDU = Application Protocol Data Unit: Folge von Bytes Terminal Karte: Command APDU Karte Terminal: Response APDU Protokolle: T=0 asynchronous half duplex character transmission protocol T=1 asynchronous half duplex block transmission protocol direkte/inverse Konvention Software- und Systemsicherheit, Kap. 4 (1/14)

36 Command APDU: CLA INS P1 P2 Lc Daten 01 2C Le 8 CLA. Class-Byte: ISO/proprietär/verschlüsselt INS. Instruction-Byte: Was tun? (gerade, 6x, 9x) P1, P2. 2 beliebige Parameter-Bytes Lc. Length-Byte: Anzahl Datenbytes Le. Length-Byte: Anzahl erwartete Antwortbytes Response APDU: Daten 01 2C SW1 SW Software- und Systemsicherheit, Kap. 4 (2/14)

37 Statuswort SW = SW1+SW2 ISO: SW1 = 90 (ok), SW1 = 6x (Fehler), SW1 = 60 (Wait Extension) No Error SW NO ERROR, SW OK Wrong length SW WRONG LENGTH Security condition not satisfied SW PIN REQUIRED Data invalid SW DATA INVALID Conditions not satisfied SW CONDITIONS NOT... 6A 82 File not found SW FILE NOT FOUND 6D 00 INS value not supported SW INS NOT SUPPORTED 6E 00 CLA value not supported SW CLA NOT SUPPORTED 6F 00 No precise diagnosis SW UNKNOWN Software- und Systemsicherheit, Kap. 4 (3/14)

38 Das Protokoll (1) 1. Kein Input, kein Output CLA INS P1 P2 0 SW1 SW2 Software- und Systemsicherheit, Kap. 4 (4/14)

39 Das Protokoll (2) 2. Kein Input, aber Output bekannter Länge CLA INS P1 P2 Le Ack Daten Le = Anzahl erwartete Antwort-Bytes, 0 = 256! oder CLA INS P1 P2 Le SW1 SW2 Software- und Systemsicherheit, Kap. 4 (5/14)

40 Das Protokoll (3) 3. Input, kein Output CLA INS P1 P2 Lc Lc = Anzahl Datenbytes Ack Daten oder CLA INS P1 P2 Lc SW1 SW2 SW1 SW2 Software- und Systemsicherheit, Kap. 4 (6/14)

41 Das Protokoll (4) 4. Input und Output CLA INS P1 P2 Lc Ack Daten Le Daten Software- und Systemsicherheit, Kap. 4 (7/14)

42 Das Protokoll (4 ) 4. Input und Output (= Input/kein Output, kein Input/Output) CLA INS P1 P2 Lc Ack Daten 61 xx 00 C xx Ack Daten Software- und Systemsicherheit, Kap. 4 (8/14)

43 Ack und Timeout Ack = Ins Alle Daten auf einmal übertragen Ack =! Ins Daten einzeln übertragen Ack für Programmierer transparent, aber: setincomingandreceive() in JavaCard! Spezialfall: Wait Extension 0x60 statt Ack oder SW Timeout: Abhängig von (berechnet aus) ATR und Taktrate Behandlung Le und Fehler: Abhängig von Middleware Bei uns: Le wird nicht an die Karte geschickt! Software- und Systemsicherheit, Kap. 4 (9/14)

44 Das Class-Byte CLA = 0x0X (APDU-Struktur und Bedeutung laut ISO) CLA = 0x8X, 0x9X (Struktur wie ISO, Bedeutung proprietär) CLA = 0xAX: Wie ISO, wenn nicht anders definiert CLA = 0xB0 0xCF: ISO, 0xD0 0xFE: Proprietär CLA = 0xFF: Wahl des Protokolls (T=0, T=1) X = b 4 b 3 b 2 b 1 : 00xx: keine Security 01xx: proprietäre Security 10xx: secure messaging, ohne Header 11xx: secure messaging, mit Header xx: Logischer Kanal/Art des SM: MAC, Verschlüsselt,... Wir: CLA = 0x90 Software- und Systemsicherheit, Kap. 4 (10/14)

45 INS-Byte und SW Einschränkungen an INS: 00, 6x, 9x, nicht ungerade! ISO definiert 18 Instruktionen, z.b. 0x82: External Authenticate 0xA4: Select File, P1 = 04: Selection by name 0xC0: Get Response Andere für Daten: put/get data/binary/record... Select APDU: 00 A Lc AID SW = 0x9000 ok, SW = 0x6XYY, X 0: Fehler Eigene Fehler: 0x62YY, 0x63YY, 0x64YY, 0x65YY Software- und Systemsicherheit, Kap. 4 (11/14)

46 Der Kartenleser Quasi-Standard: PC/SC De-Facto: Beliebig viele Implementierungsunterschiede Unsere Schnittstelle: swt = new SWTTerminalInterface() String[] swt.getreadernames() SWTReader swt.getreader(string readername) class SWTReader: void connect() boolean ispresent() byte[] transmit(byte[] data) Auch möglich: Direkte Benutzung der PC/SC API Software- und Systemsicherheit, Kap. 4 (12/14)

47 Zugriff auf den Kartenleser 1. Kartenleser-Objekt holen: r = swt.getreader(name); 2. Verbindung herstellen: r.connect(); (Exception, falls keine Karte im Leser) 3. Selektion des Applet per select-apdu: 00 A Lc Applet-AID 4. Kommunikation mit der Karte: byte[] transmit(byte[] to send) Eingabe: Vollständiges Command-APDU als Byte Array ( 5 Byte, nicht zu lang!) Ausgabe: Response-APDU als Byte Array (genauso lang wie Antwort, mind. 2 Bytes) Software- und Systemsicherheit, Kap. 4 (13/14)

48 Umgang mit Stromunterbrechungen Einlegen/Herausziehen der Karte wird nicht automatisch bemerkt. Exception beim nächsten transmit. Nach Exception: Verhalten abhängig von Kartenleser Einlegen/Herausziehen der Karte durch Aufforderung des Benutzers, oder: separater Thread mit ispresent(). Hilfsklassen swt.util.bytearray: Umgang mit Byte Arrays: setshort, getshort, append, subarray,... swt.util.hexstring: Pretty-printing von Byte Arrays in Hex-Format: dump, hexify, printreadable, hex to byte... swt.util.iso7816: Statuswörter Software- und Systemsicherheit, Kap. 4 (14/14)

49 Kapitel 5: Die JavaCard API Relevante Spezifikation: JavaCard API Packages javacard.framework (5 Interfaces, 6 Klassen, 8 Exceptions) grundlegende Funktionalität javacard.security (15 Interfaces, 7 Klassen, 1 Exception) javacardx.crypto (1 Interface, 1 Klasse) Kryptographie javacard.framework.service (3 Interfaces, 4 Klassen) rudimentäre RMI Unterstützung Software- und Systemsicherheit, Kap. 5 (1/17)

50 Relevante Klassen interface javacard.framework.iso7816 class javacard.framework.apdu class javacard.framework.applet class javacard.framework.util class javacard.framework.isoexception Krypto interfaces: DESKey, RSAPrivateKey, RSAPublicKey Krypto Klassen: KeyBuilder, MessageDigest, RandomData, Signature, Cipher Software- und Systemsicherheit, Kap. 5 (2/17)

51 public abstract class javacard.framework.applet public static void install(byte barray[], short boffset, byte blength) Wird einmal beim Installieren des Applet aufgerufen. Sollte Konstruktor und register aufrufen. Danach ist das Applet selektierbar. protected Applet(): Konstruktor protected final void register() Muss einmal in install aufgerufen werden. Trägt Applet in Registry des Cardmanagers ein. protected final void register(byte barray[], short boffset, byte blength) Version für erweiterte Openplatform Syntax Software- und Systemsicherheit, Kap. 5 (3/17)

52 public boolean select() Wird aufgerufen, wenn Applet selektiert wird Typischer Code: Rücksetzen von Flags etc. Sollte true liefern public abstract void process(apdu apdu) Wird nach select aufgerufen, wenn ein Kommando an die Karte geschickt werden. Erhält auch das select-kommando public void deselect() Wird bei weiterem select-kommando aufgerufen. Wird nicht bei reset oder Stromunterbrechung aufgerufen! Software- und Systemsicherheit, Kap. 5 (4/17)

53 protected final boolean selectingapplet() true falls APDU ist select public Shareable getshareableinterfaceobject(aid clientaid, byte parameter) Für Kommunikation zwischen Applets. Software- und Systemsicherheit, Kap. 5 (5/17)

54 Eigene Applets public class MyApplet extends Applet... Das eigene Applet sollte folgende Methoden überschreiben: install select process Software- und Systemsicherheit, Kap. 5 (6/17)

55 Interface javacard.framework.iso7816 Definition von Indizes und Statuswörtern: CLA INS P1 P2 Lc package javacard.framework; public interface ISO7816 { public final static byte OFFSET_CLA = 0; public final static byte OFFSET_INS = 1; public final static byte OFFSET_P1 = 2; public final static byte OFFSET_P2 = 3; public final static byte OFFSET_LC = 4; public final static byte OFFSET_CDATA = 5; public final static byte INS_SELECT = (byte)0xa4; Software- und Systemsicherheit, Kap. 5 (7/17)

56 ISO Statusworte: public static final short SW NO ERROR 0x9000 SW BYTES REMAINING 00 0x6100 SW WRONG LENGTH 0x6700 SW SECURITY STATUS NOT SATISFIED 0x6982 SW FILE INVALID 0x6983 SW DATA INVALID 0x6984 SW CONDITIONS NOT SATISFIED 0x6985 SW COMMAND NOT ALLOWED 0x6986 SW WRONG DATA 0x6A80 SW FUNC NOT SUPPORTED 0x6A81 SW FILE NOT FOUND 0x6A82 Software- und Systemsicherheit, Kap. 5 (8/17)

57 SW RECORD NOT FOUND 0x6A83 SW FILE FULL 0x6A84 SW INCORRECT P1P2 0x6A86 SW WRONG P1P2 0x6B00 SW CORRECT LENGTH 00 0x6C00 SW INS NOT SUPPORTED 0x6D00 SW CLA NOT SUPPORTED 0x6E00 SW UNKNOWN 0x6F00 Software- und Systemsicherheit, Kap. 5 (9/17)

58 Class javacard.framework.apdu Kapselt eine APDU, steuert die Kommunikation public byte[] getbuffer() selektiert den APDU Buffer Dient zur Eingabe und Ausgabe Initial von der JVM mit Nullen beschrieben APDU Header wird hineinkopiert Länge: hier 262 Bytes, kann zwischen JCREs variieren Darf nicht an ein Feld zugewiesen werden(!) (Security) public short setincomingandreceive() Liest die Datenbytes einer APDU Ergebnis ist Anzahl gelesener Bytes Software- und Systemsicherheit, Kap. 5 (10/17)

59 Class javacard.framework.apdu (2) Spezielle Methoden für T = 1: public static short getinblocksize() public static short getoutblocksize() public static byte getprotocol() public byte getnad() public short receivebytes(short boff) Hier: T = 0 nur setincomingandreceive Software- und Systemsicherheit, Kap. 5 (11/17)

60 Class javacard.framework.apdu (3) Daten verschicken public void setoutgoingandsend(short boff, short len) Vorher: Daten in APDU Buffer schreiben von Offset boff mit Länge len (max. 256) setoutgoingandsend aufrufen Danach APDU Buffer nicht mehr modifizieren Keine andere send Methode aufrufen public void waitextension() Fordert mehr Rechenzeit vom Terminal (falls Timeout auftritt) Aber: Nicht bei install! Software- und Systemsicherheit, Kap. 5 (12/17)

61 Class javacard.framework.apdu (4) Daten verschicken (low level Methoden nicht verwenden!) public short setoutgoing() Ergebnis ist laut API das Le-Byte Achtung: Le wird evtl. nicht an die Karte geschickt! nicht verwenden! public short setoutgoingnochaining() public void setoutgoinglength(short len) public void sendbytes(short boff, short len) public void sendbyteslong(byte outdata[], short boff, short len) Software- und Systemsicherheit, Kap. 5 (13/17)

62 Zusammenfassung: APDUs in JavaCard byte[] getbuffer() short setincomingandreceive() Daten empfangen void waitextension() void setoutgoingandsend(short offset, short len) Antwort Wichtig: genau so viele Bytes schicken wie erwartet werden, len = le. APDU-Buffer wiederverwenden, max. 256 Byte schicken. JVM hängt 9000 an. Oder: Nichts tun Antwort = Oder: Exception werfen: ISOException.throwIt(sw) Antwort = sw. Eigene Statusworte: 0x6xxx Software- und Systemsicherheit, Kap. 5 (14/17)

63 javacard.framework.isoexception extends javacard.framework.cardruntimeexception extends java.lang.runtimeexception public static void throwit(short sw) Wirft eine ISOException sw: Statuswort, das ans Terminal geschickt wird. public short getreason(), public void setreason(short reason) Lesen/setzen des Statuswort (unnötig!) Nur ein Exception-Object, das mit throwit wiederverwendet wird. Ansonsten: Error-handling wie in Java. Nicht behandelte Fehler Karte antwortet mit 6F 00. Software- und Systemsicherheit, Kap. 5 (15/17)

64 class javacard.framework.util (1) public static byte arraycompare(byte[] src, short srcoff, byte[] dest, short destoff, short length) Ergebnis: 0 falls gleich, -1 oder 1 sonst public static short arraycopy(byte[] src, short srcoff, byte[] dest, short destoff, short length) Funktioniert auch, wenn src == dest Ergebnis: (short)(destoff + length) public static short arraycopynonatomic(byte[] src, short srcoff, byte[] dest, short destoff, short length) public static void arrayfillnonatomic(byte[] barray, short boff, short slen, byte bvalue) Software- und Systemsicherheit, Kap. 5 (16/17)

65 class javacard.framework.util (2) public static short setshort(byte[] barray, short boff, short svalue) Schreibt einen short-wert in zwei Byte public static short getshort(byte[] barray, short boff) Liest einen short-wert aus zwei Byte public static short makeshort(byte b1, byte b2) Anmerkungen zu Arrays Multidimensionale Arrays sind verboten short[] ist möglich, aber meistens sinnlos Object[] ist möglich, Object kann wieder Arrays enthalten Software- und Systemsicherheit, Kap. 5 (17/17)

66 Kapitel 6: Arithmetik in JavaCard Problem: Keine Integers in JavaCard ToDo: Rechnen mit Bytes und Shorts Software- und Systemsicherheit, Kap. 6 (1/21)

67 Hex-Notation 1 Byte = 8 Bit, b 7 b 6 b 5 b 4 b 3 b 2 b 1 b 0 Software- und Systemsicherheit, Kap. 6 (2/21)

68 Hex-Notation 1 Byte = 8 Bit, b 7 b 6 b 5 b 4 b 3 b 2 b 1 b }{{} 1110 }{{} Software- und Systemsicherheit, Kap. 6 (2/21)

69 Hex-Notation 1 Byte = 8 Bit, b 7 b 6 b 5 b 4 b 3 b 2 b 1 b }{{} 1110 }{{} = = 94 Software- und Systemsicherheit, Kap. 6 (2/21)

70 Hex-Notation 1 Byte = 8 Bit, b 7 b 6 b 5 b 4 b 3 b 2 b 1 b }{{} 1110 }{{} = = 94 5 E = 0x5E = = 94 Hex: 0...9, 10 = A, 11 = B, 12 = C, 13 = D, 14 = E, 15 = F Software- und Systemsicherheit, Kap. 6 (2/21)

71 Wertebereiche in Java Typ Länge Minimaler Wert Maximaler Wert byte 8 Bit short 16 Bit int 32 Bit long 64 Bit Software- und Systemsicherheit, Kap. 6 (3/21)

72 Arithmetik in Java: Java Language Specification (Integer Operations): If an integer other than a shift operator has at least one operand of type long, then the operation is carried out using 64-bit precision, and the result of the numerical operator is of type long. If the other operand is not long, it is first widened ( 5.1.4) to type long by numeric promotion ( 5.6). Otherwise, the operation is carried out using 32-bit precision, and the result of the numerical operator is of type int. If either operand is not an int, it is first widened to type int by numeric promotion. Software- und Systemsicherheit, Kap. 6 (4/21)

73 Arithmetik in Java: Argumente werden automatisch nach int konvertiert Berechnung mit Integers Ergebnis ist int Kein Check auf Over-/Underflow short x, y;...short z = (short)(x * y); (Cast notwendig) = (Overflow) (Bem.: Ein Argument long: Berechnung/Ergebnis long, analog für float, double) Software- und Systemsicherheit, Kap. 6 (5/21)

74 Arithmetik in Java: Automatische Konvertierung byte short int Umgekehrt ist expliziter Cast notwendig! Cast: überzählige Bits abschneiden Ergebnis von Arithmetikoperationen ist immer vom Typ int. Arithmetikoperationen: +, -, *, /, % und Bitoperationen: & (And), (Or), ^ (Xor), ~ (Komplement) links-shift <<, rechts-shift >> (mit Vorzeichen), >>> (mit Nullen) Negative Zahlen: 2er-Komplement Software- und Systemsicherheit, Kap. 6 (6/21)

75 Arithmetik in Java: Java Language Specification (Widening Primitive Conversion): A widening conversion of a signed integer value to an integral type T simply sign-extends the two s-complement representation of the integer value to fill the wider format. Java Language Specification (Narrowing Primitive Conversion): A narrowing conversion of a signed integer to an integral type T simply discards all but the n lowest bits, where n is the number of bits used to represent type T. In addition to a possible loss of information about the magnitude of the numeric value, this may cause the sign of the resulting value to differ from the sign of the input value. Software- und Systemsicherheit, Kap. 6 (7/21)

76 2er-Komplement: 1. Schritt: bilde Bitdarstellung des Betrags Software- und Systemsicherheit, Kap. 6 (8/21)

77 2er-Komplement: 1. Schritt: bilde Bitdarstellung des Betrags Schritt: bitweise Invertierung Software- und Systemsicherheit, Kap. 6 (8/21)

78 2er-Komplement: 1. Schritt: bilde Bitdarstellung des Betrags Schritt: bitweise Invertierung Schritt: addiere = -34 Software- und Systemsicherheit, Kap. 6 (8/21)

79 2er-Komplement: 1. Schritt: bilde Bitdarstellung des Betrags Schritt: bitweise Invertierung Schritt: addiere = = -34 = (byte) (short) (int) (byte) (short) (int) Software- und Systemsicherheit, Kap. 6 (8/21)

80 Eigenschaften Software- und Systemsicherheit, Kap. 6 (9/21)

81 Eigenschaften Führendes Bit ist Vorzeichen: 0 ˆ= positive, 1 ˆ= negative Zahl Software- und Systemsicherheit, Kap. 6 (9/21)

82 Eigenschaften Führendes Bit ist Vorzeichen: 0 ˆ= positive, 1 ˆ= negative Zahl größte Byte-Zahl: = 0x7F = 127 Software- und Systemsicherheit, Kap. 6 (9/21)

83 Eigenschaften Führendes Bit ist Vorzeichen: 0 ˆ= positive, 1 ˆ= negative Zahl größte Byte-Zahl: = 0x7F = 127 kleinste Byte-Zahl: = 0x80 = -128 Software- und Systemsicherheit, Kap. 6 (9/21)

84 Eigenschaften Führendes Bit ist Vorzeichen: 0 ˆ= positive, 1 ˆ= negative Zahl größte Byte-Zahl: = 0x7F = 127 kleinste Byte-Zahl: = 0x80 = -128 Cast schneidet obere Bits ab: Software- und Systemsicherheit, Kap. 6 (9/21)

85 Eigenschaften Führendes Bit ist Vorzeichen: 0 ˆ= positive, 1 ˆ= negative Zahl größte Byte-Zahl: = 0x7F = 127 kleinste Byte-Zahl: = 0x80 = -128 Cast schneidet obere Bits ab: Beobachtung: Cast hat etwas mit Modulo 256 zu tun. Software- und Systemsicherheit, Kap. 6 (9/21)

86 Eigenschaften Führendes Bit ist Vorzeichen: 0 ˆ= positive, 1 ˆ= negative Zahl größte Byte-Zahl: = 0x7F = 127 kleinste Byte-Zahl: = 0x80 = -128 Cast schneidet obere Bits ab: Beobachtung: Cast hat etwas mit Modulo 256 zu tun. Frage: Lässt sich Cast als einfache mathematische Formel darstellen? Software- und Systemsicherheit, Kap. 6 (9/21)

87 Cast und Rest Rest: 5 % 3 = Software- und Systemsicherheit, Kap. 6 (10/21)

88 Cast und Rest Rest: 5 % 3 = 2, -5 % 3 = Software- und Systemsicherheit, Kap. 6 (10/21)

89 Cast und Rest Rest: 5 % 3 = 2, -5 % 3 = -2, 5 % -3 = Software- und Systemsicherheit, Kap. 6 (10/21)

90 Cast und Rest Rest: 5 % 3 = 2, -5 % 3 = -2, 5 % -3 = 2, -5 % -3 = Software- und Systemsicherheit, Kap. 6 (10/21)

91 Cast und Rest Rest: 5 % 3 = 2, -5 % 3 = -2, 5 % -3 = 2, -5 % -3 = -2 Software- und Systemsicherheit, Kap. 6 (10/21)

92 Cast und Rest Rest: 5 % 3 = 2, -5 % 3 = -2, 5 % -3 = 2, -5 % -3 = -2 int i; (byte)i =? Software- und Systemsicherheit, Kap. 6 (10/21)

93 Cast und Rest Rest: 5 % 3 = 2, -5 % 3 = -2, 5 % -3 = 2, -5 % -3 = -2 int i; (byte)i =? 0 i i % (byte)i = i % i 127 < i % 256 (byte)i = (i % 256) 256 i < 0 i % 256 < 128 (byte)i = (i % 256)+256 i < i % 256 (byte)i = i % 256 Software- und Systemsicherheit, Kap. 6 (10/21)

94 6 weitere Bemerkungen dazu: 1. Arithmetik ist vom Typ int: byte b = (byte)(x + y); (x, y Bytes) byte b = (byte)(x & 0x7F); (x Byte) Beide Argumente werden in Integers umgewandelt die Rechenoperation wird auf Integers ausgeführt das Ergebnis ist ein Integer Cast notwendig. (Auch wenn Ergebnis in ein Byte passt.) 2. Integer Literale: Konstanten sind immer vom Typ Integer byte b = 0x20; (narrowing primitive conversion) byte b = (byte)0xa0; (kein signed Byte) f((short)0)(bei Methoden keine narrowing primitive conversion) Software- und Systemsicherheit, Kap. 6 (11/21)

95 3. Casts: A0 = führendes 1-Bit byte int: A0 FF FF FF A0 int byte: A0 A0 4. Signed vs. Unsigned Bytes: (int)0xa0 = 160, aber (int)(byte)0xa0 = 96. unsigned byte int: (b & 0xFF) da (int)((byte)0xa0 & 0xFF) = int High-Byte, Low-Byte: (i >> 8) & 0xFF und i & 0xFF (vgl. setshort) High-Byte, Low-Byte int: (b1 << 8) (b2 & 0xFF) (vgl. getshort) 6. (short)(-1 >>> 15) == -1 Software- und Systemsicherheit, Kap. 6 (12/21)

96 Short- vs. Integer-Arithmetik 1. Beispiel: short x1 = 20000, x2 = (short)((x1 * 5) / 10); Integer-Arithmetik: Software- und Systemsicherheit, Kap. 6 (13/21)

97 Short- vs. Integer-Arithmetik 1. Beispiel: short x1 = 20000, x2 = (short)((x1 * 5) / 10); Integer-Arithmetik: x2 = Short-Arithmetik: Software- und Systemsicherheit, Kap. 6 (13/21)

98 Short- vs. Integer-Arithmetik 1. Beispiel: short x1 = 20000, x2 = (short)((x1 * 5) / 10); Integer-Arithmetik: x2 = Short-Arithmetik: x2 = 3107 Software- und Systemsicherheit, Kap. 6 (13/21)

99 Short- vs. Integer-Arithmetik 1. Beispiel: short x1 = 20000, x2 = (short)((x1 * 5) / 10); Integer-Arithmetik: x2 = Short-Arithmetik: x2 = Beispiel: short x1 = 20000, x2 = 30000, x3 = (short)((x1 + x2) - x2); Integer-Arithmetik: Software- und Systemsicherheit, Kap. 6 (13/21)

100 Short- vs. Integer-Arithmetik 1. Beispiel: short x1 = 20000, x2 = (short)((x1 * 5) / 10); Integer-Arithmetik: x2 = Short-Arithmetik: x2 = Beispiel: short x1 = 20000, x2 = 30000, x3 = (short)((x1 + x2) - x2); Integer-Arithmetik: x3 = Short-Arithmetik: Software- und Systemsicherheit, Kap. 6 (13/21)

101 Short- vs. Integer-Arithmetik 1. Beispiel: short x1 = 20000, x2 = (short)((x1 * 5) / 10); Integer-Arithmetik: x2 = Short-Arithmetik: x2 = Beispiel: short x1 = 20000, x2 = 30000, x3 = (short)((x1 + x2) - x2); Integer-Arithmetik: x3 = Short-Arithmetik: x3 = Software- und Systemsicherheit, Kap. 6 (13/21)

102 Short- vs. Integer-Arithmetik 1. Beispiel: short x1 = 20000, x2 = (short)((x1 * 5) / 10); Integer-Arithmetik: x2 = Short-Arithmetik: x2 = Beispiel: short x1 = 20000, x2 = 30000, x3 = (short)((x1 + x2) - x2); Integer-Arithmetik: x3 = Short-Arithmetik: x3 = Beispiel: short x1 = 20000, x2 = 30000; boolean res = (x1 < x1 + x2); Integer-Arithmetik: Software- und Systemsicherheit, Kap. 6 (13/21)

103 Short- vs. Integer-Arithmetik 1. Beispiel: short x1 = 20000, x2 = (short)((x1 * 5) / 10); Integer-Arithmetik: x2 = Short-Arithmetik: x2 = Beispiel: short x1 = 20000, x2 = 30000, x3 = (short)((x1 + x2) - x2); Integer-Arithmetik: x3 = Short-Arithmetik: x3 = Beispiel: short x1 = 20000, x2 = 30000; boolean res = (x1 < x1 + x2); Integer-Arithmetik: res = true; Short-Arithmetik: Software- und Systemsicherheit, Kap. 6 (13/21)

104 Short- vs. Integer-Arithmetik 1. Beispiel: short x1 = 20000, x2 = (short)((x1 * 5) / 10); Integer-Arithmetik: x2 = Short-Arithmetik: x2 = Beispiel: short x1 = 20000, x2 = 30000, x3 = (short)((x1 + x2) - x2); Integer-Arithmetik: x3 = Short-Arithmetik: x3 = Beispiel: short x1 = 20000, x2 = 30000; boolean res = (x1 < x1 + x2); Integer-Arithmetik: res = true; Short-Arithmetik: res = false; Software- und Systemsicherheit, Kap. 6 (13/21)

105 Der cap-converter: prüft, dass kein int, long,...benutzt wird. prüft, dass short-arithmetik = int-arithmetik Rechengesetze Beispiele: Software- und Systemsicherheit, Kap. 6 (14/21)

106 Der cap-converter: prüft, dass kein int, long,...benutzt wird. prüft, dass short-arithmetik = int-arithmetik Rechengesetze Beispiele: 1. (short)((x * y) - z) Software- und Systemsicherheit, Kap. 6 (14/21)

107 Der cap-converter: prüft, dass kein int, long,...benutzt wird. prüft, dass short-arithmetik = int-arithmetik Rechengesetze Beispiele: 1. (short)((x * y) - z) Ok Software- und Systemsicherheit, Kap. 6 (14/21)

108 Der cap-converter: prüft, dass kein int, long,...benutzt wird. prüft, dass short-arithmetik = int-arithmetik Rechengesetze Beispiele: 1. (short)((x * y) - z) Ok 2. x + y < z Software- und Systemsicherheit, Kap. 6 (14/21)

109 Der cap-converter: prüft, dass kein int, long,...benutzt wird. prüft, dass short-arithmetik = int-arithmetik Rechengesetze Beispiele: 1. (short)((x * y) - z) Ok 2. x + y < z Fehler! Software- und Systemsicherheit, Kap. 6 (14/21)

110 Der cap-converter: prüft, dass kein int, long,...benutzt wird. prüft, dass short-arithmetik = int-arithmetik Rechengesetze Beispiele: 1. (short)((x * y) - z) Ok 2. x + y < z Fehler! 3. (x + y) / 1000 Software- und Systemsicherheit, Kap. 6 (14/21)

111 Der cap-converter: prüft, dass kein int, long,...benutzt wird. prüft, dass short-arithmetik = int-arithmetik Rechengesetze Beispiele: 1. (short)((x * y) - z) Ok 2. x + y < z Fehler! 3. (x + y) / 1000 Fehler! Software- und Systemsicherheit, Kap. 6 (14/21)

112 Prinzip short-arithmetik = int-arithmetik, wenn das Ergebnis einer Operation (sofort) nach (short) oder (byte) gecastet wird: (short)(x y) 2. oder die Operation innerhalb eines Casts stattfindet und bestimmte Rechenregeln gelten: (short)(a 1 ((b 2 c) 3 d)) 3. oder das Ergebnis von der Größe her in ein short passt: byte b, c; < b * (x % c) < Software- und Systemsicherheit, Kap. 6 (15/21)

113 Rechengesetze (1): s,t: bel. Ausdrücke mit Ergebnistyp int, z. B. s = (x * y) * z 1. Unäres Minus: (short)(- s) = (short)(- (short)s) 2. Addition: (short)(s + t) = (short)((short)s + t) 3. Subtraktion: (short)(s - t) = (short)(s - (short)t) 4. Multiplikation: (short)(s * t) = (short)((short)s * t) und sämtliche Varianten. Bem.: 1. wird vom cap converter nicht akzeptiert. Software- und Systemsicherheit, Kap. 6 (16/21)

114 Rechengesetze (2): 1. Komplement: (short)( ~ s) = (short)( ~ (short)s) 2. Bitweises Und: (short)(s & t) = (short)((short)s & t) 3. Bitweises Oder: (short)(s t) = (short)((short)s t) 4. Bitweises Xor: (short)(s ^ t) = (short)((short)s ^ t) 5. Links-Shift: (short)(s << n) = (short)((short)s << n) und sämtliche Varianten. Software- und Systemsicherheit, Kap. 6 (17/21)

115 Rechengesetze (3): Im Allgemeinen (auch für Varianten): 1. (short)(s / t) (short)((short)s / (short)t) Beispiel: s = 2 16,t = (short)(s % t) (short)((short)s % (short)t) Beispiel: s = ,t = (short)(s >> n) (short)((short)s >> n) Beispiel: s = 2 15,n = 1 4. (short)(s >>> n) (short)((short)s >>> n) Beispiel: s = 2 15,n = 1 gilt natürlich, wenn s und t in ein short passen. Software- und Systemsicherheit, Kap. 6 (18/21)

116 Rechengesetze (4): Im Allgemeinen (auch für Varianten): 1. s < t (short)s < (short)t 2. (short)s == (short)t s == t aber natürlich s == t (short)s == (short)t (short)(x + y) == z Cast ist notwendig! gilt natürlich, wenn s und t in ein short passen. Software- und Systemsicherheit, Kap. 6 (19/21)

117 Rechengesetze (5):...gilt, wenn s und t in ein short passen? 1. short x,y,z x & y passt Ok! (x & y) == z kein Cast notwendig. Ebenso für, ^, ~, >>, >>> 2. short x,y,z x % y passt Ok! (x % y) == z kein Cast notwendig. Ebenso für / 3. byte x,y x + y, x passt Ok! (x + y) == z kein Cast notwendig. Ebenso für -, * 4. byte x,y,z x + y + z, x passt Fehler! Software- und Systemsicherheit, Kap. 6 (20/21)

118 Spezielle Konstrukte: 1. Bei Compound assignment impliziter cast: short x; x += y + z; ok, x = (short)(x + (y + z)) x /= y + z; nicht ok, x = (short)(x / (y + z)) 2. Bei Shift wird 2. Argument n implizit zu (n & 31): x >> n x >> (n & 31) Software- und Systemsicherheit, Kap. 6 (21/21)

119 Kapitel 7: Kryptographie: Grundlagen Software- und Systemsicherheit, Kap. 7 (1/13)

120 Nicht: Wie funktioniert Verfahren xyz? Nicht: Warum ist Verfahren xyz sicher? Software- und Systemsicherheit, Kap. 7 (2/13)

121 Nicht: Wie funktioniert Verfahren xyz? Nicht: Warum ist Verfahren xyz sicher? Dafür: Wie benutze ich Verfahren xyz? Dafür: Wie kombiniere ich Verfahren zu Protokollen? Software- und Systemsicherheit, Kap. 7 (2/13)

122 Basisoperationen: mathematische Verfahren Standardkombinationen: Signatur, MAC, blinde Signatur etc. Eigenschaften: Authentifizierung, Nichtrückweisbarkeit etc. Kombination: kryptographische Protokolle Eigenschaften: Fälschungssicher, nicht kopierbar etc. Unser Interesse: logische (abstrakte) Eigenschaften Software- und Systemsicherheit, Kap. 7 (3/13)

123 Grundbegriffe Cryptography: Lehre vom Verschlüsseln Cryptanalysis: Lehre vom Code-Knacken Plaintext/Klartext: unverschlüsselter Text Cipher/Chiffre: verschlüsselter Text Alice, Bob: ehrliche Kommunikationsteilnehmer Eve, Mallory: Bösewichte Software- und Systemsicherheit, Kap. 7 (4/13)

124 Ziele: 1. confidentiality/vertraulichkeit Niemand (sonst) kann die Nachricht lesen. 2. authentication/authentisierung Der Absender der Nachricht ist der richtige. 3. integrity/unveränderbarkeit Die Nachricht wurde nicht modifiziert. 4. nonrepudiation/nichtrückweisbarkeit Der Absender kann nicht abstreiten, die Nachricht geschickt zu haben. Software- und Systemsicherheit, Kap. 7 (5/13)

125 Theorie der Verschlüsselung Prinzipien: Confusion: Verschleiern des Zusammenhangs zwischen Plaintext und Cipher, z. B. durch Substitution. Caesar-Chiffre: Buchstabe := Buchstabe + 3: Jdoold hvw rpqlv glylvd lq sduwhv wuhv Gallia est omnis divisa in partes tres Diffusion: Verschleiert Redundanzen, indem sie im Text verteilt werden, z. B. durch Transposition/Permutation (Position 1 5, 2 2, 3 1, 4 3, 5 4) Blockchiffren: confusion und diffusion Stromchiffren: nur confusion, da nur ein Byte/Bit auf einmal verschlüsselt wird Software- und Systemsicherheit, Kap. 7 (6/13)

126 ROT13 (Substitutionschiffre) Ersetze A durch N, B durch O,...x durch x+13 Gurer jnf n lbhat ynql bs Evtn, Jub ebqr jvgu n fzvyr ba n gvtre; Gurl erghearq sebz gur evqr Jvgu gur ynql vafvqr, Naq gur fzvyr ba gur snpr bs gur gvtre. Heute: Text/Schlüssel immer Folgen von Bits (Bytes) Software- und Systemsicherheit, Kap. 7 (7/13)

127 Gutes Kryptoverfahren Problem bei ROT13: Wenn Verfahren bekannt: Jede Nachricht kann entschlüsselt werden. Verfahren mit einem Schlüssel parametrisieren Die Sicherheit eines Verschlüsselungs- (Krypto-)verfahrens sollte nur im Schlüssel liegen. (Kerckhoffs) Der Algorithmus ist öffentlich. aber: siehe Geschichte der Enigma in WWII Gutes Verschlüsselungsverfahren: Aufgabe: Gegeben Klartext und Chiffre: Finde Schlüssel. Das effizienteste bekannte Verfahren ist, alle Schlüssel durchzuprobieren. Software- und Systemsicherheit, Kap. 7 (8/13)

128 Angriffe (1) Entschlüsseln einer Nachricht einmaliger Erfolg Finden eines Schlüssels potentiell viele Nachrichten entschlüsselbar Fälschen einer digitalen Signatur Kollisionen bei Hashverfahren finden u.v.m. Knacken eines Verschlüsselungsverfahrens Effiziente Möglichkeit, Schlüssel/Klartext zu finden Software- und Systemsicherheit, Kap. 7 (9/13)

129 Angriffe (2) Software- und Systemsicherheit, Kap. 7 (10/13)

130 Angriffe (2) 1. Ciphertext-only attack: Nur verschlüsselte Nachrichten verfügbar. Software- und Systemsicherheit, Kap. 7 (10/13)

131 Angriffe (2) 1. Ciphertext-only attack: Nur verschlüsselte Nachrichten verfügbar. 2. Known-plaintext attack: verschlüsselte Nachrichten und Klartext verfügbar. Software- und Systemsicherheit, Kap. 7 (10/13)

132 Angriffe (2) 1. Ciphertext-only attack: Nur verschlüsselte Nachrichten verfügbar. 2. Known-plaintext attack: verschlüsselte Nachrichten und Klartext verfügbar. 3. Chosen-plaintext attack: Wie 2., aber Angreifer kann Klartexte wählen. (Orakel/Blackbox) Software- und Systemsicherheit, Kap. 7 (10/13)

133 Angriffe (2) 1. Ciphertext-only attack: Nur verschlüsselte Nachrichten verfügbar. 2. Known-plaintext attack: verschlüsselte Nachrichten und Klartext verfügbar. 3. Chosen-plaintext attack: Wie 2., aber Angreifer kann Klartexte wählen. (Orakel/Blackbox) 4. Adaptive-chosen-plaintext attack: Wie 3., aber nächster Klartext kann nach Analyse der vorherigen Ergebnisse gewählt werden. Software- und Systemsicherheit, Kap. 7 (10/13)

134 Angriffe (2) 1. Ciphertext-only attack: Nur verschlüsselte Nachrichten verfügbar. 2. Known-plaintext attack: verschlüsselte Nachrichten und Klartext verfügbar. 3. Chosen-plaintext attack: Wie 2., aber Angreifer kann Klartexte wählen. (Orakel/Blackbox) 4. Adaptive-chosen-plaintext attack: Wie 3., aber nächster Klartext kann nach Analyse der vorherigen Ergebnisse gewählt werden. 5. Chosen-ciphertext attack: verschlüsselte Nachrichten wählbar. Software- und Systemsicherheit, Kap. 7 (10/13)

135 Angriffe (2) 1. Ciphertext-only attack: Nur verschlüsselte Nachrichten verfügbar. 2. Known-plaintext attack: verschlüsselte Nachrichten und Klartext verfügbar. 3. Chosen-plaintext attack: Wie 2., aber Angreifer kann Klartexte wählen. (Orakel/Blackbox) 4. Adaptive-chosen-plaintext attack: Wie 3., aber nächster Klartext kann nach Analyse der vorherigen Ergebnisse gewählt werden. 5. Chosen-ciphertext attack: verschlüsselte Nachrichten wählbar. 6. Rubber-hose cryptanalysis Bestechung, Erpressung, Überredung,... Software- und Systemsicherheit, Kap. 7 (10/13)

136 ... Kryptographie allein reicht nicht... From: Support webmail To: Subject: Virus Alert Fill the columns below and send back. USERNAME: PASSWORD: PHONE NUMBER: BIRTHDAY: USER ID: Software- und Systemsicherheit, Kap. 7 (11/13)

137 One-time Pads Gegeben: Plaintext P, #P = n Bytes, geheimer zufälliger Schlüssel K mit #K = n. Verschlüsseln: C = E K (P) = P K (XOR) Entschlüsseln: P = C K (C Ciphertext/Chiffre) Software- und Systemsicherheit, Kap. 7 (12/13)

138 One-time Pads Gegeben: Plaintext P, #P = n Bytes, geheimer zufälliger Schlüssel K mit #K = n. Verschlüsseln: C = E K (P) = P K (XOR) Entschlüsseln: P = C K (C Ciphertext/Chiffre) Als einziges Krypto-System absolut sicher (sofern Schlüssel wirklich zufällig) Software- und Systemsicherheit, Kap. 7 (12/13)

139 One-time Pads Gegeben: Plaintext P, #P = n Bytes, geheimer zufälliger Schlüssel K mit #K = n. Verschlüsseln: C = E K (P) = P K (XOR) Entschlüsseln: P = C K (C Ciphertext/Chiffre) Als einziges Krypto-System absolut sicher (sofern Schlüssel wirklich zufällig) Wichtig: K darf nur einmal verwendet werden!!! Software- und Systemsicherheit, Kap. 7 (12/13)

140 One-time Pads Gegeben: Plaintext P, #P = n Bytes, geheimer zufälliger Schlüssel K mit #K = n. Verschlüsseln: C = E K (P) = P K (XOR) Entschlüsseln: P = C K (C Ciphertext/Chiffre) Als einziges Krypto-System absolut sicher (sofern Schlüssel wirklich zufällig) Wichtig: K darf nur einmal verwendet werden!!! Sonst: C 1 C 2 = (P 1 K) (P 2 K) = (P 1 P 2 ) (K K) = P 1 P 2 Software- und Systemsicherheit, Kap. 7 (12/13)

141 F C 55 0F...EAW..U B 45 1D A GP...E.FF..A E 3E 0F 07 0C 7B 38 0C 0A D 55 >...{8...HP.U 1E 0F D SAM...E F 0C B...YS..XU! A 0A A A.S8.E...ES# D F E HP...B...U. N.. 0D 0B B D 0A 03..G.2..E...M F D I...SH6A..C.ECF 07 2D 0D 16 0C B 4E.-...T...i.KN 4F C D 45 OW.THAT..IT.S.ME 0E 07.. Software- und Systemsicherheit, Kap. 7 (13/13)

142 Kapitel 8: Kryptographie: DES Software- und Systemsicherheit, Kap. 8 (1/20)

143 Symmetrische Verschlüsselung (Secret key) Verfahren: DES, Triple-DES, AES, IDEA, Blowfish,... 1 Schlüssel K für Ver-/Entschlüsselung C = E K (P),D K (C) = P Meistens: Schlüssellänge = Blocklänge (8, 16, 24, 32,...Bytes) Eigenschaften: Sicherheit liegt nur im Schlüssel Schlüssel nicht erratbar (auch wenn P und C bekannt sind!) Verschlüsselung nicht erratbar Entschlüsselung mit falschem Schlüssel ergibt Unsinn Software- und Systemsicherheit, Kap. 8 (2/20)

144 Data Encryption Standard (DES) 1976 als Standard akzeptiert, IBM Entwicklung (Anfang 70er), von NSA modifiziert freigegeben, FIPS 46-3 gut in Hardware realisierbar 64 Bit Schlüssellänge, 56 Bit echter Schlüssel Blockgröße 8 Byte Eine Runde: Substitution (XOR) + Permutation, 16 Runden Ein Designziel: Jedes Bit der Ausgabe basiert auf jedem Bit der Eingabe und jedem Schlüsselbit 8 magische S-Boxen für Substitution Inzwischen unsicher, aber nie geknackt Software- und Systemsicherheit, Kap. 8 (3/20)

145 Nie geknackt : Gegeben: Klartext und Chiffre, gesucht: der Schlüssel. Es ist kein Verfahren bekannt, mit dem man den Schlüssel schneller findet, als durch systematisches Testen aller Schlüssel. Schlüssel: F8 C4 08 0D 6E 76 EA 76 Klartext: Chiffre: B0 73 DC 3F B D Software- und Systemsicherheit, Kap. 8 (4/20)

146 Software- und Systemsicherheit, Kap. 8 (5/20)

147 DES Eine Runde Software- und Systemsicherheit, Kap. 8 (6/20)

148 Differential Cryptanalysis The design took advantage of certain cryptanalytic techniques, most prominently the technique of differential cryptanalysis, which were not known in the published literature. After discussions with NSA, it was decided that disclosure of the design considerations would reveal the technique of differential cryptanalysis, a powerful technique that can be used against many ciphers. This in turn would weaken the competitive advantage the United States enjoyed over other countries in the field of cryptography. [Don Coppersmith IBM 1992] Software- und Systemsicherheit, Kap. 8 (7/20)

149 Differential Cryptanalysis The design took advantage of certain cryptanalytic techniques, most prominently the technique of differential cryptanalysis, which were not known in the published literature. After discussions with NSA, it was decided that disclosure of the design considerations would reveal the technique of differential cryptanalysis, a powerful technique that can be used against many ciphers. This in turn would weaken the competitive advantage the United States enjoyed over other countries in the field of cryptography. [Don Coppersmith IBM 1992] (Wieder-)Entdeckt 1990 von Eli Biham und Adi Shamir. DES mit 8 Runden: 2 14 chosen plaintexts, 2 9 Verschlüsselungen. DES mit 16 Runden: 2 47 chosen plaintexts, 2 37 Verschlüsselungen. Software- und Systemsicherheit, Kap. 8 (7/20)

150 Schlüssel: F8 C4 08 0D 6E 76 EA 76 Klartext: Chiffre: B0 73 DC 3F B D Software- und Systemsicherheit, Kap. 8 (8/20)

151 Schlüssel: F8 C4 08 0D 6E 76 EA 76 Klartext: Chiffre: B0 73 DC 3F B D Rechendauer: 4 Milliarden Schlüsseltests pro Sekunde auf 4 Milliarden Rechnern = 2 64 Tests pro Sekunde, 1 Jahr 2 25 Sekunden Software- und Systemsicherheit, Kap. 8 (8/20)

152 Schlüssel: F8 C4 08 0D 6E 76 EA 76 Klartext: Chiffre: B0 73 DC 3F B D Rechendauer: 4 Milliarden Schlüsseltests pro Sekunde auf 4 Milliarden Rechnern = 2 64 Tests pro Sekunde, 1 Jahr 2 25 Sekunden 56 Bit Länge 2 56 Schlüssel 4 Millisekunden Software- und Systemsicherheit, Kap. 8 (8/20)

153 Schlüssel: F8 C4 08 0D 6E 76 EA 76 Klartext: Chiffre: B0 73 DC 3F B D Rechendauer: 4 Milliarden Schlüsseltests pro Sekunde auf 4 Milliarden Rechnern = 2 64 Tests pro Sekunde, 1 Jahr 2 25 Sekunden 56 Bit Länge 2 56 Schlüssel 4 Millisekunden Schlüssel probieren Jahre Software- und Systemsicherheit, Kap. 8 (8/20)

154 Schlüssel: F8 C4 08 0D 6E 76 EA 76 Klartext: Chiffre: B0 73 DC 3F B D Rechendauer: 4 Milliarden Schlüsseltests pro Sekunde auf 4 Milliarden Rechnern = 2 64 Tests pro Sekunde, 1 Jahr 2 25 Sekunden 56 Bit Länge 2 56 Schlüssel 4 Millisekunden Schlüssel probieren Jahre 256 Bit Schlüssellänge (AES) Jahre Software- und Systemsicherheit, Kap. 8 (8/20)

155 RSA s DES Challenge III Start: January 18, :00 AM PST Prize: $10,000 IV: da 4b be f1 6b 6e 98 3d Plaintext:See you in Rome (second AES Conference, March 22-23, 1999) Ciphertext: bd 0d de b8 8a 47 9c b1 5c 23 7b bc de ab 53 4d 6f 1c b c ee cd 96 2e 07 c6 e c a bd 41 c2 88 a9 f0 2f 8b e d2 a8 a0 6b bf 93 de 89 f6 e2 52 fd 8a 25 eb d0 7d ee a4 2d c8 8d 1b 71 Software- und Systemsicherheit, Kap. 8 (9/20)

156 RSA s DES Challenge III is solved in record time Start: January 18, :00 AM PST Prize: $10,000 IV: da 4b be f1 6b 6e 98 3d Plaintext:See you in Rome (second AES Conference, March 22-23, 1999) Ciphertext: bd 0d de b8 8a 47 9c b1 5c 23 7b bc de ab 53 4d 6f 1c b c ee cd 96 2e 07 c6 e c a bd 41 c2 88 a9 f0 2f 8b e d2 a8 a0 6b bf 93 de 89 f6 e2 52 fd 8a 25 eb d0 7d ee a4 2d c8 8d 1b 71 Coming in at 22 hours 15 minutes, the DES Challenge III was solved by the Electronic Frontier Foundation s Deep Crack in a combined effort with distributed.net. Software- und Systemsicherheit, Kap. 8 (9/20)

157 distributed.net ca PCs: At theendofthecontest,over250billionkeys(possiblecodes for decrypting the encrypted message) were being checked each second. Software- und Systemsicherheit, Kap. 8 (10/20)

158 distributed.net ca PCs: At theendofthecontest,over250billionkeys(possiblecodes for decrypting the encrypted message) were being checked each second. Deep Crack Spezialrechner für DES (Öffentlich, $) Software- und Systemsicherheit, Kap. 8 (10/20)

159 distributed.net ca PCs: At theendofthecontest,over250billionkeys(possiblecodes for decrypting the encrypted message) were being checked each second. Deep Crack Spezialrechner für DES (Öffentlich, $) 1536 ASICs, search units, 40 MHz, 16 Takte pro Schlüssel Software- und Systemsicherheit, Kap. 8 (10/20)

160 distributed.net ca PCs: At theendofthecontest,over250billionkeys(possiblecodes for decrypting the encrypted message) were being checked each second. Deep Crack Spezialrechner für DES (Öffentlich, $) 1536 ASICs, search units, 40 MHz, 16 Takte pro Schlüssel 2.5 Millionen Tests pro unit/sekunde Software- und Systemsicherheit, Kap. 8 (10/20)

161 distributed.net ca PCs: At theendofthecontest,over250billionkeys(possiblecodes for decrypting the encrypted message) were being checked each second. Deep Crack Spezialrechner für DES (Öffentlich, $) 1536 ASICs, search units, 40 MHz, 16 Takte pro Schlüssel 2.5 Millionen Tests pro unit/sekunde 92 Milliarden Tests/Sekunde Software- und Systemsicherheit, Kap. 8 (10/20)

162 distributed.net ca PCs: At theendofthecontest,over250billionkeys(possiblecodes for decrypting the encrypted message) were being checked each second. Deep Crack Spezialrechner für DES (Öffentlich, $) 1536 ASICs, search units, 40 MHz, 16 Takte pro Schlüssel 2.5 Millionen Tests pro unit/sekunde 92 Milliarden Tests/Sekunde Maximal 9.05 Tage um DES zu knacken! Software- und Systemsicherheit, Kap. 8 (10/20)

163 distributed.net ca PCs: At theendofthecontest,over250billionkeys(possiblecodes for decrypting the encrypted message) were being checked each second. Deep Crack Spezialrechner für DES (Öffentlich, $) 1536 ASICs, search units, 40 MHz, 16 Takte pro Schlüssel 2.5 Millionen Tests pro unit/sekunde 92 Milliarden Tests/Sekunde Maximal 9.05 Tage um DES zu knacken! 2010: 68 Stunden (292 Mrd. Tests/Sekunde) mit 128 FPGAs Software- und Systemsicherheit, Kap. 8 (10/20)

164 distributed.net ca PCs: At theendofthecontest,over250billionkeys(possiblecodes for decrypting the encrypted message) were being checked each second. Deep Crack Spezialrechner für DES (Öffentlich, $) 1536 ASICs, search units, 40 MHz, 16 Takte pro Schlüssel 2.5 Millionen Tests pro unit/sekunde 92 Milliarden Tests/Sekunde Maximal 9.05 Tage um DES zu knacken! 2010: 68 Stunden (292 Mrd. Tests/Sekunde) mit 128 FPGAs 3DES: Jahre! Software- und Systemsicherheit, Kap. 8 (10/20)

165 3DES, DESede Problem bei DES: Schlüssellänge fest 3 verschiedene DES Schlüssel K 1,K 2,K 3 C = E K3 (D K2 (E K1 (P))) Doppelt so sicher wie DES (2 2n statt 2 n Versuche) Für DES gilt nicht: Zu K 1,K 2 existiert immer K 3 mit E K2 (E K1 (P)) = E K3 (P) Variante: Nur 2 Schlüssel C = E K1 (D K2 (E K1 (P))) Blocklänge 8 Byte Nachfolger: AES (128, 196 oder 256 Bit Schlüssellänge), FIPS 197 Software- und Systemsicherheit, Kap. 8 (11/20)

166 Modes Was tun, wenn mehr als ein Block verschlüsselt werden soll? ECB: Electronic Codebook Mode Jeder Block Text wird separat verschlüsselt Gleicher Text mit gleichem Schlüssel gibt gleiche Chiffre CBC: Cipher Block Chaining nächsten Block mit vorherigem Verknüpfen: C i = E K (P i C i 1 ), P i = C i 1 D K (C i ) Erster Block C 0 (IV = initialization vector) beliebig,nicht geheim, sollte zufällig sein. Weitere Modes: Cipher Feedback (CFB), Output Feedback (OFB) ALG DES ECB NOPAD, ALG DES CBC NOPAD Software- und Systemsicherheit, Kap. 8 (12/20)

167 Padding Standards zum Auffüllen des Textes auf Vielfache der Blocklänge. 1. NoPadding: Text muss Vielfaches der Blocklänge sein. 2. X9.23, ISO : Mit Zufallszahlen oder Nullen auffüllen, letztes Byte enthält Anzahl der Padding-Bytes 3. RFC 1423, PKCS 5: Paddingbyte = # Paddingbytes 4. 0x80 + Null-Bytes Bei 2./3./4. mindestens 1 Padding-Byte Software- und Systemsicherheit, Kap. 8 (13/20)

168 Angriff auf CBC und PKCS 5 September 2010: New Attack Against ASP.NET: It s serious Auslesen von web.config, Entschlüsseln von Cookies u.a. Problem: Was tun, wenn Padding nicht stimmt? Fehlermeldung? Software- und Systemsicherheit, Kap. 8 (14/20)

169 Angriff auf CBC und PKCS 5 September 2010: New Attack Against ASP.NET: It s serious Auslesen von web.config, Entschlüsseln von Cookies u.a. Problem: Was tun, wenn Padding nicht stimmt? Fehlermeldung? Gegeben C = E K (P). Sei r = r 1..(r 8 i) zufälliger Block. Teste rc. Software- und Systemsicherheit, Kap. 8 (14/20)

170 Angriff auf CBC und PKCS 5 September 2010: New Attack Against ASP.NET: It s serious Auslesen von web.config, Entschlüsseln von Cookies u.a. Problem: Was tun, wenn Padding nicht stimmt? Fehlermeldung? Gegeben C = E K (P). Sei r = r 1..(r 8 i) zufälliger Block. Teste rc. Falls kein Paddingfehler: P r hat korrektes Padding. (1, 22, 333,...) Software- und Systemsicherheit, Kap. 8 (14/20)

171 Angriff auf CBC und PKCS 5 September 2010: New Attack Against ASP.NET: It s serious Auslesen von web.config, Entschlüsseln von Cookies u.a. Problem: Was tun, wenn Padding nicht stimmt? Fehlermeldung? Gegeben C = E K (P). Sei r = r 1..(r 8 i) zufälliger Block. Teste rc. Falls kein Paddingfehler: P r hat korrektes Padding. (1, 22, 333,...) Teste r 1..(r j 1)..(r 8 i)c für (j = 1..7). Alle fehlerhaft: letztes Byte P 8 = r 8 1, sonst r 8 j Software- und Systemsicherheit, Kap. 8 (14/20)

172 Angriff auf CBC und PKCS 5 September 2010: New Attack Against ASP.NET: It s serious Auslesen von web.config, Entschlüsseln von Cookies u.a. Problem: Was tun, wenn Padding nicht stimmt? Fehlermeldung? Gegeben C = E K (P). Sei r = r 1..(r 8 i) zufälliger Block. Teste rc. Falls kein Paddingfehler: P r hat korrektes Padding. (1, 22, 333,...) Teste r 1..(r j 1)..(r 8 i)c für (j = 1..7). Alle fehlerhaft: letztes Byte P 8 = r 8 1, sonst r 8 j Byte 7: Teste r 1..r 6 (r 7 i)(p 8 2) usw. Software- und Systemsicherheit, Kap. 8 (14/20)

173 Kryptographie in Java: DESede (1) 1. Initialisierung eines Providers: private final static String cryptprovider = "BC"; java.security.security.addprovider( new org.bouncycastle.jce.provider.bouncycastleprovider()); Software- und Systemsicherheit, Kap. 8 (15/20)

174 Kryptographie in Java: DESede (1) 1. Initialisierung eines Providers: private final static String cryptprovider = "BC"; java.security.security.addprovider( new org.bouncycastle.jce.provider.bouncycastleprovider()); 2. Generierung eines Schlüssels: Software- und Systemsicherheit, Kap. 8 (15/20)

175 Kryptographie in Java: DESede (1) 1. Initialisierung eines Providers: private final static String cryptprovider = "BC"; java.security.security.addprovider( new org.bouncycastle.jce.provider.bouncycastleprovider()); 2. Generierung eines Schlüssels: javax.crypto.keygenerator keygen = javax.crypto.keygenerator.getinstance("desede", cryptprovider); Software- und Systemsicherheit, Kap. 8 (15/20)

176 Kryptographie in Java: DESede (1) 1. Initialisierung eines Providers: private final static String cryptprovider = "BC"; java.security.security.addprovider( new org.bouncycastle.jce.provider.bouncycastleprovider()); 2. Generierung eines Schlüssels: javax.crypto.keygenerator keygen = javax.crypto.keygenerator.getinstance("desede", keygen.init(192); cryptprovider); Software- und Systemsicherheit, Kap. 8 (15/20)

177 Kryptographie in Java: DESede (1) 1. Initialisierung eines Providers: private final static String cryptprovider = "BC"; java.security.security.addprovider( new org.bouncycastle.jce.provider.bouncycastleprovider()); 2. Generierung eines Schlüssels: javax.crypto.keygenerator keygen = javax.crypto.keygenerator.getinstance("desede", keygen.init(192); cryptprovider); javax.crypto.secretkey key = keygen.generatekey(); Software- und Systemsicherheit, Kap. 8 (15/20)

178 Kryptographie in Java: DESede (1) 1. Initialisierung eines Providers: private final static String cryptprovider = "BC"; java.security.security.addprovider( new org.bouncycastle.jce.provider.bouncycastleprovider()); 2. Generierung eines Schlüssels: javax.crypto.keygenerator keygen = javax.crypto.keygenerator.getinstance("desede", keygen.init(192); cryptprovider); javax.crypto.secretkey key = keygen.generatekey(); 3. Ausdrucken des Schlüssels: swt.util.hexstring.printreadable(key.getencoded()); Kodierung: RAW (Bytearray = Schlüssel) Software- und Systemsicherheit, Kap. 8 (15/20)

179 Kryptographie in Java: DESede (2) 4 Einlesen des Schlüssels: private final static byte[] desede key = {...}; Software- und Systemsicherheit, Kap. 8 (16/20)

180 Kryptographie in Java: DESede (2) 4 Einlesen des Schlüssels: private final static byte[] desede key = {...}; javax.crypto.secretkeyfactory sessionkf = javax.crypto.secretkeyfactory.getinstance("desede", cryptprovider); Software- und Systemsicherheit, Kap. 8 (16/20)

181 Kryptographie in Java: DESede (2) 4 Einlesen des Schlüssels: private final static byte[] desede key = {...}; javax.crypto.secretkeyfactory sessionkf = javax.crypto.secretkeyfactory.getinstance("desede", cryptprovider); javax.crypto.secretkey the key = sessionkf.generatesecret( new javax.crypto.spec.desedekeyspec(desede key)); Software- und Systemsicherheit, Kap. 8 (16/20)

182 Kryptographie in Java: DESede (3) 1. Verschlüsseln: javax.crypto.cipher cip = javax.crypto.cipher.getinstance("desede/ecb/nopadding", cryptprovider); cip.init(javax.crypto.cipher.encrypt MODE, the key); byte[] to enc = {1, 2, 3, 4, 5, 6, 7, 8 }; byte[] enc = cip.dofinal(to enc); 2. Entschlüsseln: cip.init(javax.crypto.cipher.decrypt MODE, the key); byte[] dec = cip.dofinal(enc); Software- und Systemsicherheit, Kap. 8 (17/20)

183 Kryptographie in JavaCard: DESede (1) 1. Imports: import javacard.security.*; import javacardx.crypto.*; 2. Initialisieren des Schlüssels: DESKey key = (DESKey)KeyBuilder.buildKey( KeyBuilder.TYPE DES, key.setkey(desede key, (short)0); KeyBuilder.LENGTH DES3 3KEY, false); Cipher cip = Cipher.getInstance(Cipher.ALG DES ECB NOPAD,false); Allokiert Speicher nur im Konstruktor! Software- und Systemsicherheit, Kap. 8 (18/20)

184 Kryptographie in JavaCard: DESede (2) 3. Verschlüsseln: cip.init(key, Cipher.MODE ENCRYPT); cip.dofinal(buffer, ISO7816.OFFSET CDATA, (short)8, buffer, ISO7816.OFFSET CDATA); 4. Entschlüsseln: cip.init(key, Cipher.MODE DECRYPT); cip.dofinal(buffer, ISO7816.OFFSET CDATA, (short)8, buffer, ISO7816.OFFSET CDATA); short dofinal(byte[] inbuff, short inoffset, short inlength, byte[] outbuff, short outoffset) Software- und Systemsicherheit, Kap. 8 (19/20)

185 Kryptographie in JavaCard: DESede (3) dofinal gibt Länge des verschlüsselten Text zurück No padding: Länge muss Vielfaches der Blockgröße sein Ausgabelänge = Eingabelänge Bei Cipher block chaining kann Initialisierungsvektor IV verwendet werden: Cipher cip = Cipher.getInstance(Cipher.ALG DES CBC NOPAD,false); cip.init(key, Cipher.MODE ENCRYPT); IV = {0,0,0,0,0,0,0,0} oder cip.init(key, mode, array, offset, (short)8) Software- und Systemsicherheit, Kap. 8 (20/20)

186 Kapitel 9: Nonces und Hashes Software- und Systemsicherheit, Kap. 9 (1/16)

187 Nonce Leo: for the nonce = einstweilen (for the time being) OED: pan anes = for or with a view to the one (thing, occasion) (ane/anes analog zu ene/enes = once) InMEpoetryusedasametricaltagorstop-gap,withnospecial meaning, often rhyming with bones and stones for the time being; temporarily nonce-word: the term used in this dictionary to describe a word which is apparently used only for the nonce Criminal slang: one convicted of a sexual offence, esp. childmolesting Software- und Systemsicherheit, Kap. 9 (2/16)

188 Zufallszahlen (1) Nonces, random numbers Echte (physikalische) Generatoren (indeterministisch)(?) teuer, groß, problematisch Software- und Systemsicherheit, Kap. 9 (3/16)

189 Zufallszahlen (1) Nonces, random numbers Echte (physikalische) Generatoren (indeterministisch)(?) teuer, groß, problematisch Software- und Systemsicherheit, Kap. 9 (3/16)

190 Zufallszahlen (2) In Software: Pseudo-Zufallszahlengeneratoren (PRNGs) zufällige/geheime Initialisierung (seed), dann deterministisch für Kryptographie: zusätzliche Anforderungen z. B. auf DES + MD5 basierend mit geheimem Schlüssel FIPS 186-2, ANSI X9.31, ANSI X Software- und Systemsicherheit, Kap. 9 (4/16)

191 Zufallszahlen (3) Eigenschaften: sieht zufällig aus Gleichverteilung der Werte statistische Analyse zeigt keine Korrelation nicht vorhersagbar Nächster Wert nicht vorhersagbar, auch wenn alle bisherigen Werte bekannt Software- und Systemsicherheit, Kap. 9 (5/16)

192 Zufallszahlen (4) Wenn lang genug (z.b. 8 Byte, 2 64 = Werte) Zahl nicht erratbar Während der Lebenszeit der Anwendung wird die gleiche Zahl nicht zweimal erzeugt Verwendung: nur ein einziges Mal (= Nonce) In einer Nachricht: Schutz vor Replay Als Sessionkey: Schadensbegrenzung, wenn Schlüssel bekannt wird. Software- und Systemsicherheit, Kap. 9 (6/16)

193 Debian OpenSSL-Debakel September 2006: Debian-Maintainer Kurt Roeckx modifiziert ssleay rand add(), um Warnmeldungen von Memorydebuggern (statischen Checkern) zu vermeiden. (Zugriff auf nicht initalisierten Speicher) /* * Don t add uninitialised data. MD_Update(&m,buf,j); */ nur 2 15 Seed-Werte für OpenSSL PRNG Mai 2008: Problem wird entdeckt Ergebnis: Alle so erzeugten (SSL/SSH host) keys sind erratbar, d. h. der private key bekannt! Software- und Systemsicherheit, Kap. 9 (7/16)

194 Kryptographische Hashfunktionen Verfahren: MD5, SHA-1, RIPEMD, SHA-512,... Hashfunktion H (bel. lange Eingabe, Hashwert 128 Bit, 160 Bit) Einwegfunktion, kein effizientes Verfahren für H 1 (bekannt) Ähnliche Texte unähnliche Hashwerte (1 Bit in M ändern > 64 Bit in h(m) geändert) Eigenschaften: h = H(M) leicht berechenbar, H 1 schwierig (unmöglich) Gegeben M: Schwierig M mit H(M) = H(M ) zu finden Schwierig, M,M mit H(M) = H(M ) zu finden Symmetrische Verschlüsselung mit CBC nicht gut genug Bruce Schneier (1996): I am wary of using MD5 Software- und Systemsicherheit, Kap. 9 (8/16)

195 MD5 - Kollision d1 31 dd 02 c5 e6 ee c4 69 3d 9a af f9 5c 2f ca b e ab e b8 fb 7f ad f4 b e a e8 f7 cd c9 9f d9 1d bd f c 5b d8 82 3e f 5b ae 6d ac d4 36 c9 19 c6 dd 53 e2 b4 87 da 03 fd d2 48 cd a0 e9 9f f 57 7e e8 ce 54 b a8 0d 1e c bc b6 a f9 65 2b 6f f7 2a 70 d1 31 dd 02 c5 e6 ee c4 69 3d 9a af f9 5c 2f ca b e ab e b8 fb 7f ad f4 b e f1 41 5a e8 f7 cd c9 9f d9 1d bd c 5b d8 82 3e f 5b ae 6d ac d4 36 c9 19 c6 dd 53 e da 03 fd d2 48 cd a0 e9 9f f 57 7e e8 ce 54 b d 1e c bc b6 a f9 65 ab 6f f7 2a 70 Software- und Systemsicherheit, Kap. 9 (9/16)

196 August 2004: Xiaoyun Wang, Dengguo Feng, Xuejia Lai, Hongbo Yu: Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD...it takes about one hour to find... zwei Nachrichten mit gleichem Hashwert 2007: Marc Stevens, Arjen K. Lenstra, and Benne de Weger: Erzeugung von beliebigen Executables mit gleichem MD5 Wert (durch Anhängen von Bytes am Ende der Dateien). 2008: Alexander Sotirov, Marc Stevens und Jacob Appelbaum: Fälschen von Zertifikaten (einer Zertifizierungsstelle) Software- und Systemsicherheit, Kap. 9 (10/16)

197 15 Februar 2005: Bruce Schneier SHA-1hasbeenbroken.Notareduced-roundversion.Notasimplified version. The real thing. Findet Kollisionen mit 2 63 statt 2 80 Versuchen. Keine Hashfunktion hat 10 Jahre gehalten... Software- und Systemsicherheit, Kap. 9 (11/16)

198 15 Februar 2005: Bruce Schneier SHA-1hasbeenbroken.Notareduced-roundversion.Notasimplified version. The real thing. Findet Kollisionen mit 2 63 statt 2 80 Versuchen. Keine Hashfunktion hat 10 Jahre gehalten... November 2007: NIST schreibt SHA-3 Wettbewerb aus : 64 Einreichungen 2010: noch 14 übrig Entscheidung 2012 geplant Software- und Systemsicherheit, Kap. 9 (11/16)

199 Hashwerte: Anwendungen als Einwegfunktion: speichere Hash(Passwort) statt Passwort (Unix) als Schutz vor trojanischen Pferden: speichere Hash(file) separat von file (CD-RO), prüfe täglich (tripwire) Software- und Systemsicherheit, Kap. 9 (12/16)

200 Hashwerte bei Kommunikation als Schutz vor Übertragungsfehlern: sende Daten + Hash(Daten) als Schutz vor böswilliger Manipulation: Daten + Hash(Daten) - nicht gut genug Enc(Daten) - nicht gut genug Enc(Daten + JAVACARD ) - CBC-Mode Enc(Daten) + Hash(Daten) Daten + Enc(Hash(Daten)) Software- und Systemsicherheit, Kap. 9 (13/16)

201 Message Authentication Code (MAC) Zwei Parteien, beide kennen gemeinsamen Secret Key K MAC = E K (H(P)), verschickt wird P + MAC, oder Verschlüssele P mit 3DES im CBC Mode, MAC ist letzter Block (ALG DES MAC8 NOPAD), oder führende 4 Byte des letzten Blocks (ALG DES MAC4 NOPAD). HMAC: H(K opad + H(K ipad + Message)) Eigenschaften: Nachricht muss von einer Person stammen, die K kennt. P wurde während der Übertragung nicht modifiziert. Nur wer K kennt, kann MAC überprüfen. Software- und Systemsicherheit, Kap. 9 (14/16)

202 Zufallszahlen und Hashen in Java class java.security.securerandom rand = new java.security.securerandom(); rand.nextbytes(byte array); Füllt byte array mit zufälligen Werten. class MessageDigest md = MessageDigest.getInstance("SHA1",cryptProvider); Hashwert berechnen: byte[] digest(byte[] input) Software- und Systemsicherheit, Kap. 9 (15/16)

203 Zufallszahlen und Hashen in JavaCard class RandomData rand = RandomData.getInstance(RandomData.ALG SECURE RANDOM); setseed: Initialisierung des Generators unnötig! generatedata(barray, offset, howmany); class MessageDigest md = MessageDigest.getInstance(MessageDigest.ALG SHA, false); Verfahren: ALG SHA(-1) (20 Bytes), ALG MD5 (16 Bytes) Hashwert berechnen: short dofinal(byte[] inbuff, short inoffset, short inlength, byte[] outbuff, short outoffset) Software- und Systemsicherheit, Kap. 9 (16/16)

204 Kapitel 10: Kopierkarte Protokolle Aufgabe: Design einer Karte, die Punkte speichert Anforderungen: 1. Schutz vor gefälschten Karten 2. Schutz vor unauthorisiertem Laden von Punkten 3. kein Schutz vor technischem Equipment (zweiter Chip, Signalleitungen,...) oder doch? 4. nur symmetrische Verschlüsselung Wie sehen Protokolle aus? Software- und Systemsicherheit, Kap. 10 (1/7)

205 Lösung Nr. 1 Laden T C load + n C T ok Abbuchen T C pay + n C T ok Software- und Systemsicherheit, Kap. 10 (2/7)

206 Lösung Nr. 1 Laden T C load + n C T ok Abbuchen T C pay + n C T ok Unsicher! Software- und Systemsicherheit, Kap. 10 (2/7)

207 Lösung Nr. 1 Laden T C load + n C T ok Abbuchen T C pay + n C T ok Unsicher! Jeder kann Punkte auf eine echte Karte laden! Software- und Systemsicherheit, Kap. 10 (2/7)

208 Lösung Nr. 1 Laden T C load + n C T ok Abbuchen T C pay + n C T ok Unsicher! Jeder kann Punkte auf eine echte Karte laden! Man kann mit einer gefälschten Karte bezahlen! Software- und Systemsicherheit, Kap. 10 (2/7)

209 Lösung Nr. 2 Laden T C load + Passphrase1 + n C T ok Abbuchen T C pay + n C T hash(passphrase2) Software- und Systemsicherheit, Kap. 10 (3/7)

210 Lösung Nr. 2 Laden T C load + Passphrase1 + n C T ok Abbuchen T C pay + n C T hash(passphrase2) Unsicher! Software- und Systemsicherheit, Kap. 10 (3/7)

211 Lösung Nr. 2 Laden T C load + Passphrase1 + n C T ok Abbuchen T C pay + n C T hash(passphrase2) Unsicher! Passphrase1 kann mit gefälschter Karte protokolliert werden! Software- und Systemsicherheit, Kap. 10 (3/7)

212 Lösung Nr. 2 Laden T C load + Passphrase1 + n C T ok Abbuchen T C pay + n C T hash(passphrase2) Unsicher! Passphrase1 kann mit gefälschter Karte protokolliert werden! hash(passphrase2) kann ausgelesen werden! Software- und Systemsicherheit, Kap. 10 (3/7)

213 Gefordert: Authentisierung von Terminal und Karte Software- und Systemsicherheit, Kap. 10 (4/7)

214 Gefordert: Authentisierung von Terminal und Karte Situation: Alice will wissen, dass Bob echt ist. Software- und Systemsicherheit, Kap. 10 (4/7)

215 Gefordert: Authentisierung von Terminal und Karte Situation: Alice will wissen, dass Bob echt ist. Bob muss beweisen, dass er ein Geheimnis (jetzt) kennt. Software- und Systemsicherheit, Kap. 10 (4/7)

216 Gefordert: Authentisierung von Terminal und Karte Situation: Alice will wissen, dass Bob echt ist. Bob muss beweisen, dass er ein Geheimnis (jetzt) kennt. Das Geheimnis muss dabei geheim bleiben. Software- und Systemsicherheit, Kap. 10 (4/7)

217 Lösung Nr. 3 T und C kennen geheimen Schlüssel K Laden T C load + E S (K)[Passphrase1] + n C T ok Abbuchen T C pay + n C T E S (K)[hash(Passphrase2)] Software- und Systemsicherheit, Kap. 10 (5/7)

218 Lösung Nr. 3 T und C kennen geheimen Schlüssel K Laden T C load + E S (K)[Passphrase1] + n C T ok Abbuchen T C pay + n C T E S (K)[hash(Passphrase2)] Unsicher! Replayattacke! Software- und Systemsicherheit, Kap. 10 (5/7)

219 Lösung Nr. 3 T und C kennen geheimen Schlüssel K Laden T C load + E S (K)[Passphrase1] + n C T ok Abbuchen T C pay + n C T E S (K)[hash(Passphrase2)] Unsicher! Replayattacke! E S (K)[Passphrase1] kann protokolliert werden! Software- und Systemsicherheit, Kap. 10 (5/7)

220 Lösung Nr. 3 T und C kennen geheimen Schlüssel K Laden T C load + E S (K)[Passphrase1] + n C T ok Abbuchen T C pay + n C T E S (K)[hash(Passphrase2)] Unsicher! Replayattacke! E S (K)[Passphrase1] kann protokolliert werden! E S (K)[hash(Passphrase2)] kann ausgelesen werden! Software- und Systemsicherheit, Kap. 10 (5/7)

221 Lösung Nr. 4 T und C kennen geheimen Schlüssel K, N 1, N 2 sind Zufallszahlen (Random numbers, nonces) Laden T C load + E S (K)[Passphrase1 + N 1 ] + n C T ok Abbuchen T C pay + n C T E S (K)[hash(Passphrase2 + N 2 )] Software- und Systemsicherheit, Kap. 10 (6/7)

222 Lösung Nr. 4 T und C kennen geheimen Schlüssel K, N 1, N 2 sind Zufallszahlen (Random numbers, nonces) Laden T C load + E S (K)[Passphrase1 + N 1 ] + n C T ok Abbuchen T C pay + n C T E S (K)[hash(Passphrase2 + N 2 )] Unsicher! Replayattacke! Software- und Systemsicherheit, Kap. 10 (6/7)

223 Lösung Nr. 4 T und C kennen geheimen Schlüssel K, N 1, N 2 sind Zufallszahlen (Random numbers, nonces) Laden T C load + E S (K)[Passphrase1 + N 1 ] + n C T ok Abbuchen T C pay + n C T E S (K)[hash(Passphrase2 + N 2 )] Unsicher! Replayattacke! E S (K)[Passphrase1 + N 1 ] kann protokolliert werden! Software- und Systemsicherheit, Kap. 10 (6/7)

224 Lösung Nr. 4 T und C kennen geheimen Schlüssel K, N 1, N 2 sind Zufallszahlen (Random numbers, nonces) Laden T C load + E S (K)[Passphrase1 + N 1 ] + n C T ok Abbuchen T C pay + n C T E S (K)[hash(Passphrase2 + N 2 )] Unsicher! Replayattacke! E S (K)[Passphrase1 + N 1 ] kann protokolliert werden! E S (K)[hash(Passphrase2 + N 2 )] kann ausgelesen werden! Software- und Systemsicherheit, Kap. 10 (6/7)

225 Prinzip: Challenge Response T und C kennen geheimen Schlüssel K, N ist eine Zufallszahl Challenge T C N Response C T E S (K)[N] Terminal entschlüsselt Antwort mit K und vergleicht mit N. Wenn N neu ist (noch nie verwendet wurde), wird Replay verhindert. Software- und Systemsicherheit, Kap. 10 (7/7)

226 Kapitel 11: Authentisierungsprotokolle Software- und Systemsicherheit, Kap. 11 (1/21)

227 Wide-Mouth Frog (Burrows) S: (Authentisierungs-)Server, T a,t s Zeitstempel K as,k bs geheime Schlüssel (zwischen A und S bzw. B und S), K ab Sessionkey 1. A S: A,{T a,b,k ab } Kas 2. S B: {T s,a,k ab } Kbs Software- und Systemsicherheit, Kap. 11 (2/21)

228 Otway-Rees Protokoll (1987) S: (Authentisierungs-)Server, M,N a,n b Nonces K as,k bs geheime Schlüssel (zwischen A und S bzw. B und S), K ab Sessionkey 1. A B: M,A,B,{N a,m,a,b} Kas 2. B S: M,A,B,{N a,m,a,b} Kas,{N b,m,a,b} Kbs 3. S B: M,{N a,k ab } Kas,{N b,k ab } Kbs 4. B A: M,{N a,k ab } Kas Software- und Systemsicherheit, Kap. 11 (3/21)

229 Yahalom Protokoll (1988) S: (Authentisierungs-)Server, N a,n b Nonces K as,k bs geheime Schlüssel (zwischen A und S bzw. B und S), K ab Sessionkey 1. A B: A,N a 2. B S: B,{A,N a,n b } Kbs 3. S A: {B,K ab,n a,n b } Kas,{A,K ab } Kbs 4. A B: {A,K ab } Kbs,{N b } Kab Software- und Systemsicherheit, Kap. 11 (4/21)

230 Needham-Schroeder (1978) mit geheimen (symmetrischen) Schlüsseln 1. A S: A,B,N a 2. S A: {N a,b,k ab,{k ab,a} Kbs } Kas 3. A B: {K ab,a} Kbs 4. B A: {N b } Kab 5. A B: {N b 1} Kab Problem: Nachricht 3 könnte ein Replay sein. Software- und Systemsicherheit, Kap. 11 (5/21)

231 Kerberos vom MIT (Miller et. al. 1987) T s,t a Zeitstempel, L Lebensdauer 1. A S: A,B 2. S A: {T s,l,k ab,b,{t s,l,k ab,a} Kbs } Kas 3. A B: {T s,l,k ab,a} Kbs,{A,T a } Kab 4. B A: {T a +1} Kab Software- und Systemsicherheit, Kap. 11 (6/21)

232 SmartCard Anwendungen Bequemlichkeit Authentisierung Krankenkassendaten Kreditkarte Geheimnisse E-Cash SIM (Handy) D-Box (Pay-TV) Geldkarte Unveränderbar Personalausweis Studentenausweis Führerschein Schutz vor Mißbrauch Digitale Signatur Software- und Systemsicherheit, Kap. 11 (7/21)

233 Konzentration auf Anwendungsanbieter und Kartenhalter: Mehrseitige Sicherheit gleiche / unterschiedliche / widersprechende Interessen Spezialität von Smartcard-Anwendungen: Kartenhalter ist potenziell feindlich Karte hat Geheimnisse, die Halter nicht kennen/manipulieren darf Beschränkte Ressourcen! Software- und Systemsicherheit, Kap. 11 (8/21)

234 Besonderheiten bei Smartcards 1. Beschränkte Ressourcen: Oft nur 3DES und Zufallszahlen 2. langsame Datenübertragung 3. Kartenhalter als Angreifer: Unbeschränkter Zugriff auf die Karte 4. Kommunikation Karte/Leser kann physikalisch geschützt werden aber: hilft nicht gegen zweiten Chip auf der Karte(?) 5. Kombination mit Infrastruktur (z. B. vernetzte Server) 6. Risiko: Eine Karte geknackt, alle geknackt? Protokolldesign muss Schutzziele, Ressourcen und Angreifermöglichkeiten berücksichtigen Software- und Systemsicherheit, Kap. 11 (9/21)

235 Sichere Kommunikation mit der Smart Card Grundlage: ISO , EMV, Openplatform, etc. 1. Gegenseitige Authentisierung (mutual authentication) 2. Integrität der Nachrichten (Message Integrity): APDU MACs Auch/speziell: DAPs (Data Authentication Patterns) zum Laden von Applikationen 3. Vertraulichkeit der Nachrichten (Message Data Confidentiality) Aber: Nur für Command APDU spezifiziert. Software- und Systemsicherheit, Kap. 11 (10/21)

236 Mutual Authentication (Prinzip) Terminal Generate host challenge Karte Initialize Update Generate card challenge Generate session keys answer Calculate card cryptogram Generate session keys Verify card cryptogram Calculate host cryptogram External Authenticate answer Verify host cryptogram Software- und Systemsicherheit, Kap. 11 (11/21)

237 Smard Card Schlüssel 1. Globaler Master-Schlüssel MK 2. statischer Kartenschlüssel für gegenseitige Authentisierung und Verschlüsselung (von MK abgeleitet) 3. statischer Kartenschlüssel für MAC (von MK abgeleitet) 4. statischer Kartenschlüssel für key encryption (von MK abgeleitet) 5. Pro Session: MAC-Schlüssel (aus Challenges abgeleitet) 6. Pro Session: Encryption Schlüssel (aus Challenges abgeleitet) Alle Schlüssel 16 Byte (3DES mit 2 Schlüsseln) Software- und Systemsicherheit, Kap. 11 (12/21)

238 Mutual Authentication (APDUs) 1. Initialize Update: Schlüsselnr. + Zufallszahl N D C P1 = 0D: Key set version P2 = 00: Key index (00: erster verfügbarer) Antwort: 43 4D 61 FF F (diversification data) 0D 01 (Schlüsselnummer) F5 2D 82 9E AA CA E9 BB (Kartenzufallszahl N 2 ) 3B 34 BD 49 BA 6C 8C 2F (card cryptogram) Software- und Systemsicherheit, Kap. 11 (13/21)

239 2. External Authenticate (Sicherheitsstufe) B9 B C A1 35 A7 21 C6 10 D7 C7 (host cryptogram) (APDU MAC) P1: Security Level 00 = no secure messaging 01 = MAC 03 = encryption and MAC Software- und Systemsicherheit, Kap. 11 (14/21)

240 Kryptogramme 1. D = N 1 +N 2 + 0x verschlüssele D mit 3DES/CBC, IV = 0x cryptogram = letzter Block (letzten 8 Byte) card cryptogram: N 1 = host challenge, N 2 = card challenge host cryptogram: N 1 = card challenge, N 2 = host challenge Software- und Systemsicherheit, Kap. 11 (15/21)

241 APDU MAC: Bilde MAC über APDU-Header + Daten, hänge MAC an Daten an. Nachricht unverändert (Message Integrity) Für nächste Nachricht: alte MAC ist IV (CBC mode!) für neue MAC Reihenfolge ok, keine Nachricht fehlt Cryptogram: Im Prinzip eine MAC APDU Verschlüsselung Daten verschlüsseln Message Data Confidentiality (APDU-Header und MAC nicht verschlüsselt) Schlüssel: werden bei Authentisierung erzeugt. Software- und Systemsicherheit, Kap. 11 (16/21)

242 APDU MAC (Berechnung) 1. Lc := Lc + 8 (da MAC mitgeschickt werden wird) 2. Cla 0x04 (ISO: 0x84) 3. D := neuer APDU-Header + Daten (ohne Le) 4. D := D + 0x80 + n 0x00 (Padding, Vielfaches von 8) 5. E := Enc(D) (3DES/CBC, IV = 0 oder letzte MAC) 6. MAC := letzten 8 Byte von E 7. APDU = neuer APDU-Header + Daten + MAC Software- und Systemsicherheit, Kap. 11 (17/21)

243 Schlüssel Key Diversification: Berechne Schlüssel für jede Karte n Ausgangspunkt: 2DES Mother key MK = D F D 50 4C 45 + Diversification Data D n (16 Byte) Verschieden pro Karte (enthält Seriennummer) D n 1,2,3 (aus D n generiert) Software- und Systemsicherheit, Kap. 11 (18/21)

244 Statische Kartenschlüssel K1 n für Authentisierung/Verschlüsselung K2 n für APDU MACs K3 n für key encryption Ki n = Enc MK (D i L)+Enc MK (D i R), D i = D i L+D i R Session key derivation encryption session key und MAC session key Card Challenge CC = CC L + CC R (jeweils 4 Byte) Host Challenge HC = HC L + HC R (jeweils 4 Byte) DD = CC R + HC L + CC L + HC R, SK i = Enc Ki (DD) Software- und Systemsicherheit, Kap. 11 (19/21)

245 Neuer Reisepass (1) Protokoll: 1. Optischer Scan des Passes secret master key K p 2. T C: Get Nonce 3. C T: N 1 4. T C: {N 1,N 2,S L } Kp (N 2 eigene Nonce, S L halber Session key) 5. C T: {N 2,N 1,S R } Kp 6. Session key (MAC und Encryption): S L +S R Software- und Systemsicherheit, Kap. 11 (20/21)

246 Neuer Reisepass (2) Sicherheit: Session key: 3DES mit zwei Schlüsseln K p = Hash(Passnummer, Geburtsdatum, Ablaufdatum Pass) 10 9 ( ) (365 10) Schlüssel entspricht einfachem DES(!) Mit Fingerabdrücken: Public-Key-Kryptographie Software- und Systemsicherheit, Kap. 11 (21/21)

247 Kapitel 12: Kryptographie: RSA Software- und Systemsicherheit, Kap. 12 (1/22)

248 Asymmetrische Verschlüsselung (Public key) Verfahren: RSA, Elliptische Kurven, (ElGamal) 1 öffentlicher Schlüssel Pu (public key) 1 privater Schlüssel Pr (private key) blockorientiert (1024 Bit,...) Eigenschaften: D Pr (E Pu (P)) = P, D Pu (E Pr (P)) = P Pr nicht erratbar, Pu darf jeder kennen Entschlüsselung mit falschem Schlüssel ergibt Unsinn Software- und Systemsicherheit, Kap. 12 (2/22)

249 RSA (Rivest, Shamir, Adleman) 1978 Wähle große Primzahlen p,q(p q), sei n = pq. WähleemitggT(e,(p 1)(q 1)) = 1,z.B.e = 3,e =0x01,0x00,0x01 Berechne d mit ed 1 mod (p 1)(q 1). Public key: e,n, e public exponent, n modulus Private key d,n, d private exponent, n modulus Schlüssel-/Blocklänge: # bits von n, 1024 Bits = 128 Byte Verschlüsseln: C = P e mod n, Entschlüsseln: P = C d mod n In Java: n BigInteger Sicherheit: Faktorisierung großer Zahlen (unbewiesene Vermutung) Software- und Systemsicherheit, Kap. 12 (3/22)

250 Anzahl Primzahlen der Länge 1024 Bit Software- und Systemsicherheit, Kap. 12 (4/22)

251 Anzahl Primzahlen der Länge 1024 Bit Software- und Systemsicherheit, Kap. 12 (4/22)

252 Anzahl Primzahlen der Länge 1024 Bit (ca.) Software- und Systemsicherheit, Kap. 12 (4/22)

253 RSA Challenges (inzwischen zurückgezogen) Name: RSA-576 Prize: $10000 Digits: 174 Digit Sum: \ \ Veröffentlicht 2001, gelöst am : The factors are \ and \ Software- und Systemsicherheit, Kap. 12 (5/22)

254 Name: RSA-2048 Prize: $ Digits: 617 Digit Sum: \ \ \ \ \ \ \ \ \ \ Software- und Systemsicherheit, Kap. 12 (6/22)

255 : RSA-768 gelöst. Faktoren: und Rechendauer: 2,5 Jahre (ca. 80 Rechner) Factoring a 1024-bit RSA would be... a thousand times harder Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung vom : Minimale Schlüssellängen: Zeitraum bis Ende bis Ende bis Ende bis Ende bis Ende Länge Software- und Systemsicherheit, Kap. 12 (7/22)

256 Eigenschaften von RSA RSA hat erwünschte und unerwünschte mathematische Eigenschaften. Beispiel: : Timing-Angriff (Analyse der Rechenzeit) auf OpenSSL, um geheimen RSA server key zu finden. Lösung: RSA blinding: Berechne x = r e C mod n (r Zufallszahl) P = x d /r mod n Da r zufällig: Rechenzeit zufällig. Software- und Systemsicherheit, Kap. 12 (8/22)

257 Angriff auf RSA: 1. Eve hört C (mit public key von Alice verschlüsselt), und möchte den Klartext P = C d. 2. Vorgehen: Eve wählt r < n zufällig und berechnet x = r e mod n,t = r 1 mod n,y = C x mod n 3. Eve bringt Alice dazu, y zu signieren (y direkt, nicht einen Hashwert) 4. Eve erhält u = y d mod n t u mod n = r 1 y d mod n = r 1 C d x d mod n = P (da x = r e mod n r = x d mod n) Moral: Never use RSA to sign a random document presented to you by a stranger. Richtige Verwendung wichtig! Software- und Systemsicherheit, Kap. 12 (9/22)

258 RSA-Verschlüsselung: PKCS#1 Problem: ALG RSA NOPAD unsicher Software- und Systemsicherheit, Kap. 12 (10/22)

259 RSA-Verschlüsselung: PKCS#1 Problem: ALG RSA NOPAD unsicher ALG RSA PKCS1 oder Padding selbst programmieren Software- und Systemsicherheit, Kap. 12 (10/22)

260 RSA-Verschlüsselung: PKCS#1 Problem: ALG RSA NOPAD unsicher ALG RSA PKCS1 oder Padding selbst programmieren PKCS#1: RSA Encryption Standard (RSA Data Security, 1993) 1. Sei D die zu verschlüsselnde Bytefolge,#D k 11, k Schlüssellänge 2. Bilde encryption block: EB = 0x00 + BT + PS + 0x00 + D BT: block type, 0x02 für public key encryption PS: padding string, Pseudozufallszahlen 0x00 3. Wandle EB in Zahl x, berechne y = x d mod n, wandle y in Bytefolge verschlüsselte Daten Software- und Systemsicherheit, Kap. 12 (10/22)

261 Anmerkungen Führendes 0-Byte garantiert EB < n Block type 0x00, 0x01 für private key encryption (Signatur) Darstellung ist eindeutig, da 0x00 PS PS sollte jedesmal neu generiert werden Security Condition:# PS 8(Durchprobieren aller EBs unmöglich) Problem: Es ist mit akzeptabler Wahrscheinlichkeit möglich, Texte zu generieren, die sich ordentlich entschlüsseln lassen. chosen-ciphertext attack möglich. Version 1.5 von 1993, aktuell Version 2.1 vom , OAEP: Optimal Asymmetric Encryption Padding Software- und Systemsicherheit, Kap. 12 (11/22)

262 OAEP: Optimal Asymmetric Encryption Padding Sicher gegen adaptive chosen-ciphertext attacks. P Plaintext, Bilde initiales Padding D = 0x00 k +0x01+P Verschlüssele: (D G(r))+(r H(D G(r))) r Zufallszahl, H Hashfunktion, G Generatorfunktion Generatorfunktion: Hashfunktion, die eine Eingabe auf eine bestimmte Länge aufbläht, z. B: G(r) = H(r 1 )+H(r 2 )+...+H(r n ), r i = r +i Nach Entschlüsseln: A = (D G(r)),B = (r H(D G(r))) x = H(A) = H(D G(r)) r = x B = x (r x) D = A G(r) = (D G(r)) G(r). Software- und Systemsicherheit, Kap. 12 (12/22)

263 Public Key Cryptographic Standards PKCS #1: RSA Cryptography Standard PKCS #3: Diffie-Hellman Key Agreement Standard PKCS #5: Password-Based Cryptography Standard PKCS #6: Extended-Certificate Syntax Standard PKCS #7: Cryptographic Message Syntax Standard PKCS #8: Private-Key Information Syntax Standard PKCS #9: Selected Attribute Types PKCS #10: Certification Request Syntax Standard PKCS #11: Cryptographic Token Interface Standard PKCS #12: Personal Information Exchange Syntax Standard PKCS #13: Elliptic Curve Cryptography Standard PKCS #15: Cryptographic Token Information Format Standard Software- und Systemsicherheit, Kap. 12 (13/22)

264 RSA Schlüsselgenerierung in Java SecureRandom rand = new SecureRandom(); java.security.keypairgenerator keygen = KeyPairGenerator.getInstance("RSA",cryptProvider); keygen.initialize(1024,rand); java.security.keypair keypair = keygen.generatekeypair(); Cipher: "RSA/NONE/PKCS1PADDING" Schlüssellänge: 1024 Bit Modulus hat genau 128 Bytes Software- und Systemsicherheit, Kap. 12 (14/22)

265 Schlüssel in Java key.getformat(): Name der Kodierung: RAW, X509, PKCS#8 keypair.getpublic().getencoded(): X509 keypair.getprivate().getencoded(): PKCS#8 Kodierung kann kompliziert sein. Schlüssel können so ausgetausch werden. Schlüssel können nicht per serialize abgespeichert werden. Richtig wäre: Verwendung eines KeyStore(oder einer SmartCard ) Für JavaCard: gebraucht werden Modulus und Exponent Software- und Systemsicherheit, Kap. 12 (15/22)

266 RSA Schlüssel für JavaCard Ausgangspunkt: RSA Schlüsselpaar java.security.keypair kp java.security.interfaces.rsaprivatekey priv = (java.security.interfaces.rsaprivatekey)kp.getprivate(); BigInteger mod_priv_bi = priv.getmodulus(); BigInteger pre_bi = priv.getprivateexponent(); java.security.interfaces.rsapublickey pub = (java.security.interfaces.rsapublickey)kp.getpublic(); BigInteger mod_pub_bi = priv.getmodulus(); BigInteger pue_bi = pub.getpublicexponent(); es gilt: mod priv bi = mod pub bi, Modulus ist der gleiche bei uns (BouncyCastle): public exponent = 0x01, 0x00, 0x01 Software- und Systemsicherheit, Kap. 12 (16/22)

267 BigInteger in Java byte[] pub_exp = pue_bi.tobytearray(); byte[] mod_array = mod_pub_bi.tobytearray(); byte[] priv_exp = pre_bi.tobytearray(); Dann: HexString.printReadable von modulus, priv exp, pub exp Achtung: Modulus muss genau 128 Byte haben Länge mod array = 129 führendes 0x00-Byte abschneiden! Länge private exponent 128 Bytes Länge priv exp = 129 führendes 0x00-Byte abschneiden! Software- und Systemsicherheit, Kap. 12 (17/22)

268 Schlüssel einlesen in Java KeyFactory rsakf = KeyFactory.getInstance("RSA", cryptprovider); BigInteger mod = new BigInteger(1, mod_array); BigInteger pub = new BigInteger(1, pub_exp); BigInteger priv = new BigInteger(1, priv_exp); PublicKey pub_key = rsakf.generatepublic( new java.security.spec.rsapublickeyspec(mod, pub)); PrivateKey priv_key = rsakf.generateprivate( new java.security.spec.rsaprivatekeyspec(mod, priv)); Software- und Systemsicherheit, Kap. 12 (18/22)

269 RSA Verschlüsselung in Java Cipher cip = Cipher.getInstance("RSA/NONE/PKCS1PADDING",bcp); Verschlüsselung: PublicKey pub_key; cip.init(javax.crypto.cipher.encrypt_mode,pub_key); cip.dofinal... Entschlüsselung: PrivateKey priv_key; cip.init(javax.crypto.cipher.decrypt_mode,priv_key); cip.dofinal... Achtung: Immer nur mit dem public key verschlüsseln Immer nur mit dem private key entschlüsseln Software- und Systemsicherheit, Kap. 12 (19/22)

270 RSA Schlüssel in JavaCard Ausgangspunkt: Modulus mod, private exponent priv, public exponent pub als Byte Arrays (alle 128 Bytes!) RSAPrivateKey rsa_priv_key=(rsaprivatekey)keybuilder.buildkey( KeyBuilder.TYPE_RSA_PRIVATE,KeyBuilder.LENGTH_RSA_1024,false); RSAPublicKey rsa_pub_key=(rsapublickey)keybuilder.buildkey( KeyBuilder.TYPE_RSA_PUBLIC,KeyBuilder.LENGTH_RSA_1024,false); rsa_priv_key.setmodulus(mod,(short)0,(short)mod.length); rsa_priv_key.setexponent(priv,(short)0,(short)priv.length); rsa_pub_key.setmodulus(mod,(short)0,(short)mod.length); rsa_pub_key.setexponent(pub,(short)0,(short)pub.length); Software- und Systemsicherheit, Kap. 12 (20/22)

271 RSA Verschlüsselung in JavaCard Cipher rsacip = Cipher.getInstance(Cipher.ALG RSA NOPAD,false); Cipher rsacip = Cipher.getInstance(Cipher.ALG RSA PKCS1,false); Verschlüsselung: rsacip.init(rsa_pub_key, Cipher.MODE_ENCRYPT); rsacip.dofinal(...); Entschlüsselung: rsacip.init(rsa_priv_key, Cipher.MODE_DECRYPT); rsacip.dofinal(...); Software- und Systemsicherheit, Kap. 12 (21/22)

272 RSA Schlüsselgenerierung in JavaCard Klasse KeyPair: kp = new KeyPair(ALG RSA, LENGTH RSA 1024); kp.genkeypair(); kp.getpublic(); kp.getprivate(); Dauert lange, sollte nur einmal gemacht werden. Software- und Systemsicherheit, Kap. 12 (22/22)

273 Kapitel 13: Die elektronische Bahnfahrkarte Aufgabe: Bau eines Demonstrator Ziel: Demonstration, dass eine elektronische Fahrkarte keine Nachteile gegenüber einer Papierfahrkarte hat, geringe Investitionskosten erfordert, zur Kostenreduktion beitragen kann, Vorteile für den Kunden bringt. Realisierung: mit anonymer/multiapplikativer SmartCard Software- und Systemsicherheit, Kap. 13 (1/9)

274 Anforderungen 1. Kauf der Fahrkarte per Internet und per Automat 2. Fahrkarte ist anonym, nicht an einen Zug/Platz gebunden 3. Kontrolle offline möglich 4. Rückgabe von Fahrkarten per Internet/Automat 5. Übertragen von Tickets Software- und Systemsicherheit, Kap. 13 (2/9)

275 Nachteile Online-Ticket (Papier) 1. Kontrolle sehr aufwendig 2. Personengebunden (Kreditkarte oder Bahncard) 3. Mehrfachbenutzung wird erst nachträglich erkannt Software- und Systemsicherheit, Kap. 13 (3/9)

276 Anforderungen Heim-PC 1. Anzeige der auf der Karte befindlichen Tickets 2. Löschen von Tickets 3. Kauf eines Tickets über das Internet 4. Schutz vor Verbindungsabbruch Kauf wiederaufsetzbar 5. Rückgabe eines Tickets über das Internet 6. Übertragen des Tickets auf eine andere Karte Software- und Systemsicherheit, Kap. 13 (4/9)

277 Anforderungen Kontrolle im Zug 1. Schaffner mit Lesegerät, Display 240x320 Pixel. Tastatur? 2. Anzeige des Tickets (garantiert echt!) 3. Anzeige nicht aller Tickets (Freigabe durch Kunde) 4. Entwertung eines Ticket, d. h. Hinzufügen einer Kontrollmarkierung. Mehrfachkontrolle soll möglich sein. 5. Kontrolle offline, d. h. ohne Zugriff auf irgendeinen Server 6. Mehrfachbenutzung, falsche Benutzung (falsche Strecke, nach Ablauf der Gültigkeit) wird erkannt. Software- und Systemsicherheit, Kap. 13 (5/9)

278 Anforderungen allgemein 1. Fälschen, Manipulieren, Kopieren von Tickets unmöglich. Designprinzip: Ticket auf der Smartcard ist echt, nicht kopierbar, nicht manipulierbar. 2. Ist eine Karte kompromittiert, so dürfen nicht alle Karten betroffen sein. 3. Sicherheit des Karteninhabers wichtig für die Akzeptanz! Benutzung durch Unbefugte? Tickets gehen nicht verloren (auch bei PC-Crash) Karte blockiert nicht 4. Dolev-Yao Angreifer im Internet: Kann alle Nachrichten abhören, manipulieren, unterdrücken, umleiten, gleichzeitig mehrere Sessions parallel betreiben... Software- und Systemsicherheit, Kap. 13 (6/9)

279 5. einfache Fahrt, Rückfahrticket, Dauerticket 6. Maximal 10 Tickets speicherbar 7. Tickets nicht an einen Zug oder einen Platz gebunden 8. möglichst wenig personenbezogenen Daten speichern (außer zur Abwicklung der Bezahlung/Erstattung). Software- und Systemsicherheit, Kap. 13 (7/9)

280 Ihre Entscheidungen 1. Tarifsystem, Gültigkeit der Tickets 2. Seriennummern SmartCard/Ticket? 3. Wieviel Schutz des Kunden vor Dummheit/Bösartigkeit (Dritter)? Software- und Systemsicherheit, Kap. 13 (8/9)

281 Frage: Wird ein symmetrisches Verschlüsselungsverfahren ausreichen? Antwort: Nein. Die Anforderungen sind nur mit einem asymmetrischen Verfahren erfüllbar. Verwenden Sie verschiedene Schlüssel + Zertifikate. Frage: Wie kann das Terminal kontrollieren, ob ein Ticket für diese Fahrt gültig ist? Antwort: Es ist völlig ausreichend das Ticket auf dem Terminal darzustellen. Der Schaffner entscheidet dann, ob das Ticket für diese Fahrt verwendet werden kann und stempelt es ab. Frage: Was kann ich tun, um zu verhindern, dass die Deutsche Bahn den Kunden benachteiligt? Antwort: Der Bahn kann man vertrauen. Die Bahn kann es sich nicht leisten, absichtlich ein Protokoll anzugreifen. Schließlich kann sich die Bahn nicht ins Ausland absetzen... Software- und Systemsicherheit, Kap. 13 (9/9)

282 Kapitel 14: Weitere kryptographische Verfahren Software- und Systemsicherheit, Kap. 14 (1/21)

283 Schlüsselaustausch Verfahren: Diffie-Hellman (1976) Pr(A) und Pu(B) symmetrischer Schlüssel K Pr(B) und Pu(A) symmetrischer Schlüssel K Pr(A) = x, Pr(B) = y, Pu(A) = g x mod n, Pu(B) = g y mod n K = Pu(A) y mod n = Pu(B) x mod n Für jedes Paar ergibt sich anderes K Sicherheit: diskreter Logarithmus (n große Primzahl, g Generator) Auch mit elliptischen Kurven Software- und Systemsicherheit, Kap. 14 (2/21)

284 Symmetrische Stromverschlüsselung (Secret key) Verfahren: RC4, A5,... 1 (initialer) Schlüssel K für Ver-/Entschlüsselung stromorientiert: Datenstrom d 1,d 2,d 3,... separater Schlüsselstrom k 1,k 2,k 3,... Verschlüsselung: d 1 k 1,d 2 k 2,d 3 d 3,... schneller und einfacher als Blockchiffren Anwendung: GSM, WLAN,... Software- und Systemsicherheit, Kap. 14 (3/21)

285 RC von Ron Rivest für RSA entwickelt Software- und Systemsicherheit, Kap. 14 (4/21)

286 RC von Ron Rivest für RSA entwickelt 7 Jahre lang geheim, 1994 anonym im Internet Software- und Systemsicherheit, Kap. 14 (4/21)

287 RC von Ron Rivest für RSA entwickelt 7 Jahre lang geheim, 1994 anonym im Internet Aktueller Schlüssel: 256 Byte S 0,...,S 255, nächstes Schlüsselbyte k n : i = (i+1) mod 256; j = (j +S i ) mod 256; swap S i and S j ; t = (S i +S j ) mod 256; k n = S t Software- und Systemsicherheit, Kap. 14 (4/21)

288 RC von Ron Rivest für RSA entwickelt 7 Jahre lang geheim, 1994 anonym im Internet Aktueller Schlüssel: 256 Byte S 0,...,S 255, nächstes Schlüsselbyte k n : i = (i+1) mod 256; j = (j +S i ) mod 256; swap S i and S j ; t = (S i +S j ) mod 256; k n = S t Initialisierung: 1. S 0 = 0,S 1 = 1,...,S 255 = Array K 0,...,K 255 mit (initialem) Schlüssel (evtl. wiederholen) 3. j = 0; for i = 0 to 255: { j = (j +S i +K i ) mod 256; swap S i and S j ; } Software- und Systemsicherheit, Kap. 14 (4/21)

289 Digitale Signatur Verfahren: RSA, DSA (digital signature algorithm) Gegeben: Text P, privater Schlüssel Pr, Hashfunktion H signieren: Sig Pr (P) = E Pr (H(P)), verschickt wird: P +Sig Pr (P) verifizieren: D Pu (Sig Pr (P))? = H(P) ALG RSA SHA PKCS1 Eigenschaften: Signatur muss von einer Person stammen, die Pr kennt. Nichtrückweisbarkeit P wurde während der Übertragung nicht modifiziert. Jeder kann Signatur verifizieren (überprüfen), da P u öffentlich. Software- und Systemsicherheit, Kap. 14 (5/21)

290 Digitale Signatur mit RSA M zu signierende Message beliebiger Länge. Signaturerzeugung: 1. Berechne H(M) (H Hashfunktion, z.b. SHA-1) 2. Berechne D = Padding + H(M) (Padding: PKCS1v5 oder OAEP) 3. Signatur S = D d mod n (d private key, n Modulus) Signaturprüfung: 1. Berechne D wie oben 2. Berechne D = S e mod n (e public key) 3. Prüfe D = D Software- und Systemsicherheit, Kap. 14 (6/21)

291 Digitale Signatur mit DSA DSA (= digital signature algorithm, FIPS 186-2). Standardisiert Allgemeine Parameter: p, q, g p Primzahl, q Primzahl und Teiler von p 1, g = h (p 1)/q mod p h beliebig mit: 1 < h < p 1 und h (p 1)/q mod p > 1 p Bit q 160 Bit Private key x: Zufallszahl 0 < x < q (Verwende große Zufallszahl r und x = r mod q) Public key y: y = g x mod p Sicherheit: Schwierigkeit, einen diskreten Logarithmus zu berechnen. Software- und Systemsicherheit, Kap. 14 (7/21)

292 Digitale Signatur mit DSA Signaturerzeugung: 1. Berechne D = H(M) und k Zufallszahl (k muss geheim bleiben!) 2. Berechne r = (g k mod p) mod q, s = (k 1 (D +x r)) mod q 3. Signatur S ist Paar aus r und s Signaturprüfung: 1. Berechne w = s 1 mod q, u 1 = (D w) mod p, u 2 = (r w) mod q 2. Berechne v = ((g u 1 y u 2 ) mod p) mod q 3. Prüfe v = r? Software- und Systemsicherheit, Kap. 14 (8/21)

293 Message Authentication Code (MAC) Zwei Parteien, beide kennen gemeinsamen Secret Key K MAC = E K (H(P)), oder Verschlüssele P mit 3DES im CBC Mode, MAC ist letzter Block, oder MAC(text)=HMAC(K,text)=H((K 0 opad) H((K 0 ipad) text)) opad = B 0x5c, ipad = B 0x36 (HMAC, fips 198) verschickt wird P + MAC Eigenschaften: Nachricht muß von einer Person stammen, die K kennt. P wurde während der Übertragung nicht modifiziert. Nur wer K kennt, kann MAC überprüfen. Software- und Systemsicherheit, Kap. 14 (9/21)

294 Signaturen in Java Signaturobjekt erzeugen: sig = Signature.getInstance("SHA1withRSA", cryptprovider); Signieren: void initsign(privatekey thekey) void update(byte[] data) byte[] sign() Verifizieren: void initverify(publickey thekey) void update(byte[] data) boolean verify(byte[] signature) Software- und Systemsicherheit, Kap. 14 (10/21)

295 Signaturen in JavaCard class Signature digitale Signatur: ALG RSA SHA PKCS1 1. Berechne Hashwert mit SHA-1 (Eingabe beliebig lang) 2. Fülle Hashwert mit PKCS1 Padding auf 3. Verschlüssele mit privatem RSA Schlüssel MAC: ALG DES MAC4 NOPAD, ALG DES MAC8 NOPAD 1. Verschlüssele Text mit DES/CBC bzw. 3DES/CBC 2. die ersten 4 bzw. alle 8 Bytes des letzten Block sind der MAC Signaturobjekt erzeugen: sig = Signature.getInstance(Signature.ALG RSA SHA PKCS1,false); Software- und Systemsicherheit, Kap. 14 (11/21)

296 Signaturen in JavaCard (2) Initialisieren: void init(key thekey, byte themode) themode: Signature.MODE SIGN, Signature.MODE VERIFY Signieren: short sign(byte[] inbuff, short inoffset, short inlength, byte[] sigbuff, short sigoffset) Verifizieren: boolean verify(byte[] inbuff, short inoffset, short inlength, byte[] sigbuff, short sigoffset, short siglength) Software- und Systemsicherheit, Kap. 14 (12/21)

297 Challenge/Response (Authentisierung) A B: N Challenge (N Nonce) B A: Sig Pr (N) Response, oder B A: E K (N), oder B A: E K (H(N)) Eigenschaften: B kennt ein Geheimnis (Pr oder K) B kennt das Geheimnis jetzt (N ist neu) Risiko: N könnte verschlüsselter Text sein! Software- und Systemsicherheit, Kap. 14 (13/21)

298 Zertifikate Problem: Woher weiß man, dass Pu A auch A gehört? Zuordnung Person zu Public Key Pu trusted third party mit privatem Schlüssel TPr Jeder kennt TPu Zertifikat = Sig TPr (A+Pu A ) Bei Smartcards: Jede Karte mit eigenem Schlüssel, vom Anwendungsanbieter zertifiziert. Software- und Systemsicherheit, Kap. 14 (14/21)

299 Zertifikathierarchie R A 1 A m B 1... B n C C x Software- und Systemsicherheit, Kap. 14 (15/21)

300 Wissen der Teilnehmer R : Pr R,Pu R A 1 : Pr A1,Pu A1,Sig R (A 1 +Pu A1 ),Pu R B 1 : Pr B1,Pu B1,Sig A1 (B 1 +Pu B1 ),Pu A1,Sig R (A 1 +Pu A1 ),Pu R C 1 : Pr C1,Pu C1,Sig B1 (C 1 +Pu C1 ),Pu B1,Sig A1 (B 1 +Pu B1 ), Pu A1,Sig R (A 1 +Pu A1 ),Pu R Zertifikatliste [Pu C1,Sig B1 (C 1 +Pu C1 )],[Pu B1,Sig A1 (B 1 +Pu B1 )],[Pu A1,Sig R (A 1 +Pu A1 )] Software- und Systemsicherheit, Kap. 14 (16/21)

301 Überprüfung der Zertifikate Kommunikation C 1 C x : C 1 C x : [Pu C1,Sig B1 (C 1 +Pu C1 )],[Pu B1,Sig A1 (B 1 +Pu B1 )], [Pu A1,Sig R (A 1 +Pu A1 )] C x kennt: [Pu Cx,Sig Bn (C x +Pu Cx )],[Pu Bn,Sig Am (B n +Pu Bn )], [Pu Am,Sig R (A m +Pu Am )],Pu R Vor Benutzung von Pu C1 prüft C x : Sig B1 (C 1 +Pu C1 ) mit Pu B1 Sig A1 (B 1 +Pu B1 ) mit Pu A1 Sig R (A 1 +Pu A1 ) mit Pu R (C x kennt Pu R ) Software- und Systemsicherheit, Kap. 14 (17/21)

302 Zertifikate bei Eticket (Beispiele) Software- und Systemsicherheit, Kap. 14 (18/21)

303 Zertifikate bei Eticket (Beispiele) Server 1...x Automat 1...y DB Card 1...n Schaffner 1...z Heim PC 1...m Software- und Systemsicherheit, Kap. 14 (18/21)

304 Zertifikate bei Eticket (Beispiele) Server 1...x Automat 1...y DB Card 1...n Schaffner 1...z X Heim PC 1...m Software- und Systemsicherheit, Kap. 14 (18/21)

305 Zertifikate bei Eticket (Beispiele) Server 1...x Automat 1...y DB=Server DB Card 1...n Schaffner 1...z X Heim PC 1...m Automat 1...y Schaffner 1...z Card 1...n Software- und Systemsicherheit, Kap. 14 (18/21)

306 Zertifikate bei Eticket (Beispiele) Server 1...x Automat 1...y DB=Server DB Card 1...n Schaffner 1...z X Heim PC 1...m Automat 1...y Schaffner 1...z DB=Server Card 1...n Card 1...n Software- und Systemsicherheit, Kap. 14 (18/21)

307 Angriffe Replay-Attacke: Angreifer hört Nachricht mit, verwendet sie später Man in the middle-attacke: A will mit B kommunizieren Angreifer gibt sich gegenüber A als B und gegenüber B als A aus. Orakel-Attacke: Angreifer bringt A dazu, unbeabsichtigt etwas zu entschlüsseln/signieren Angreifermodelle Einschränkungen: Kann keine Schlüssel/Zufallszahlen/Hashwerte erraten Netzwerk/Funk: Kann in Echtzeit alle Nachrichten mithören, analysieren und manipulieren (Dolev-Yao Angreifer) SmartCards: Kann Kommunikation Karte/Terminal mithören, analysieren, manipulieren (oder auch nicht) Software- und Systemsicherheit, Kap. 14 (19/21)

308 Besonderheiten bei Smartcards 1. Beschränkte Ressourcen: Oft keine asymmetrische Kryptographie 2. langsame Datenübertragung 3. Kartenhalter als Angreifer: Unbeschränkter Zugriff auf die Karte 4. Kommunikation Karte/Leser kann physikalisch geschützt werden aber: hilft nicht gegen zweiten Chip auf der Karte(?) 5. Kombination mit Infrastruktur (z. B. vernetzte Server) 6. Risiko: Eine Karte geknackt, alle geknackt? Protokolldesign muß Schutzziele, Ressourcen und Angreifermöglichkeiten berücksichtigen Software- und Systemsicherheit, Kap. 14 (20/21)

309 Kryptographische Protokolle: Laden eines Ticket 1. S C : N 1 2. S C : Sign(Pr(C))[Enc(Pu(DB))[N 1 ]] + Sign(Pr(DB))[Pu(C)]? 3. S C : Enc(Pu(C))[Sign(Pr(DB))[T]] 1. S C : N 1 2. S C : Sig(Pr(C))[N 1 ] + Enc(Pu(DB))[N 2 ] + Sign(Pr(DB))[Pu(C)] 3. S C : Sig(Pr(DB))[N 2 ] + Enc(Pu(C))[Sign(Pr(DB))[T]] 1. S C : N 1 2. S C : Sign(Pr(C))[N 2 + N 1 ] + Sign(Pr(DB))[Pu(C)] 3. S C : Enc(Pu(C))[Sign(Pr(DB))[T + N 2 ]] Software- und Systemsicherheit, Kap. 14 (21/21)

310 Kapitel 15: Weitere Protokolle Software- und Systemsicherheit, Kap. 15 (1/22)

311 Needham-Schroeder Protokoll (1978) Ziel: Gegenseitige Authentisierung in Netzwerken Message 1 A B: A,B,{N a,a} Pu(B) Message 2 B A: B,A,{N a,n b } Pu(A) Message 3 A B: A,B,{N b } Pu(B) Pu(A) Public Key von A, N a,n b Nonces, {.} K verschlüsseln mit K Message 2 B A: B,A,{N a,n b,b} Pu(A) Software- und Systemsicherheit, Kap. 15 (2/22)

312 Man-in-the-Middle Angriff Message 1 A B: A,B,{N a,a} Pu(B) Message 2 B A: B,A,{N a,n b } Pu(A) Message 3 A B: A,B,{N b } Pu(B) A I B Message α.1 A I: A,I,{N a,a} Pu(I) Message β.1 I(A) B: A,B,{N a,a} Pu(B) Message β.2 B I(A): B,A,{N a,n b } Pu(A) Message α.2 I A: I,A,{N a,n b } Pu(A) Message α.3 A I: A,I,{N b } Pu(I) Message β.3 I(A) B: A,B,{N b } Pu(B) Software- und Systemsicherheit, Kap. 15 (3/22)

313 SMB Reflection Attack SMB (Server Message Block): Protokoll von Microsoft (1992) zum Zugriff auf Services (Drucker, Dateisystem,...) 1. C S: Hello 2. S C: N (Challenge) 3. C S: Hash(N + Passwort) Software- und Systemsicherheit, Kap. 15 (4/22)

314 Problem: Angreifer gibt sich als Server aus Bringt den Client dazu, den Angreifer zu kontaktieren: <img src="\\attacker\share\pic.jpg"> Kontaktiert den SMB-Port des Client Holt sich die Challenge vom Client und gibt sie dem Client zurück Gibt den Hash vom Client dem Client zurück Angreifer hat Zugriff auf Client Entdeckt 1996 (Dominique Brezinski), wiederentdeckt 2001, gepatched Software- und Systemsicherheit, Kap. 15 (5/22)

315 EMV 4.1: Integrated Circuit Card Specifications for Payment Systems EMV = Europay, MasterCard, Visa Book 1: Application Independent ICC to Terminal Interface Requirements Book 2: Security and Key Management Book 3: Application Specification Book 4: Cardholder, Attendant, and Acquirer Interface Requirements Software- und Systemsicherheit, Kap. 15 (6/22)

316 Static Data Authentication (SDA) Ziel: Erkennen unauthorisierter Änderung von (statischen) Daten nach Personalisierung der Karte. Software- und Systemsicherheit, Kap. 15 (7/22)

317 Offline Dynamic Data Authentication (DDA) Ziel: Terminal erkennt gefälschte Karte Software- und Systemsicherheit, Kap. 15 (8/22)

318 PIN Verschlüsselung PIN in sicherem PIN Pad eingeben, zusammen mit Karten-Challenge mit Public Key der Karte verschlüsseln, an Karte schicken. Issuer Authentication Kryptogramme und MACs wie bei Openplatform. Software- und Systemsicherheit, Kap. 15 (9/22)

319 Digitaler Reisepass Für das Auslesen der Fingerabdrücke: extended access control 1. basic access control (Symmetrisch, DES) weak encryption 2. Chip Authentication (Diffie-Hellman Key Exchange) strong encryption 3. Passive Authentication (Prüfung Zertifikat des Passes) 4. Terminal Authentication (Challenge-Response) statischer Schlüssel im Pass, jeweils neuer Schlüssel erzeugt im Terminal, Zertifikate, Public Key Infrastructure,... Software- und Systemsicherheit, Kap. 15 (10/22)

320 elektronischer Personalausweis Ziel: gegenseitige Authentisierung und sicherer Kanal zwischen epa und Terminal (vgl. Reisepass) Protokoll: PACE(Password Authenticated Connection Establishment) 1. shared key PK = KDF(password) (key derivation) 2. T C: Get Nonce 3. C T: {N} PK 4. T und C: Generieren zufällige Diffie-Hellman Schlüssel, Algorithmenparameter werden aus N generiert 5. T und C: Diffie-Hellman Schlüsselaustausch session key K 6. T und C: K MAC = KDF MAC (K),K Enc = KDF Enc (K) 7. T C: MAC KMAC (Pu(T)), C T: MAC KMAC (Pu(C)) Software- und Systemsicherheit, Kap. 15 (11/22)

321 SSL 3.0 Ziel: sichere Kommunikation im Internet (Client/Server) 1. handshake protocol: Authentisierung, Schlüsselgenerierung 2. record layer: eigentlicher Datenaustausch parametrisiert mit den eigentlichen kryptographischen Verfahren schließt mehrere Sicherheitslücken in SSL 2.0 Software- und Systemsicherheit, Kap. 15 (12/22)

322 SSL 3.0: Handshake C S: client hello: protocol version + session ID + cipher suite + compression method + N C (28 byte) C S: server hello:...+ N S (28 byte) C S: server certificate: X.509 in ASN.1 Kodierung (optional: C S: certificate request, key exchange) C S: server hello done (optional: C S: client certificate) C S: encrypted premaster secret: {pms} Pu(S) C S: change cipher specs, finished C S: change cipher specs, finished Software- und Systemsicherheit, Kap. 15 (13/22)

323 SSL 3.0: Schlüsselgenerierung master secret = MD5(pms + SHA( A + pms + N C + N S )) + MD5(pms + SHA( BB + pms + N C + N S )) + MD5(pms + SHA( CCC + pms + N C + N S )) key block = MD5(ms + SHA( A + ms + N S + N C )) + MD5(ms + SHA( BB + ms + N S + N C )) +... Aufteilen in: client MAC key, server MAC key, client ENC key, server ENC key,... Software- und Systemsicherheit, Kap. 15 (14/22)

324 SSL 3.0: Ende des Handshake finished Nachricht: MD5(ms + pad2 + MD5(messages + Sender + ms + pad1)) + SHA(ms + pad2 + SHA(messages + Sender + ms + pad1)) messages: Alle bisherigen Nachrichten Unterschiedliche Schlüssel pro Richtung Unterschiedliche Schlüssel pro Session Software- und Systemsicherheit, Kap. 15 (15/22)

325 SSL 3.0: Record Layer Nachricht N wird: (optional) fragmentiert (16K), komprimiert N P := type + version + length + N MAC := H(MAC key + pad2 + hash(mac key + pad1 + SEQ- NUM + L + N )) verschickt wird: M := t + v + L + Enc(P + MAC) SEQNUM: Sequenznummer (gegen Replays) L: Länge von Enc(P + MAC) Software- und Systemsicherheit, Kap. 15 (16/22)

326 Schwächen in SSL 2.0 Schlüssellänge für Export nur 40 Bit MAC nicht über alles ciphersuite rollback attack: Angreifer ändert hello Nachrichten Schwaches Verfahren wird verwendet finished in SSL 3.0 version rollback attack... Software- und Systemsicherheit, Kap. 15 (17/22)

327 Daumenregeln für Protokolldesign (1) 1. Signaturen/MACs: Auf dem gesamten Klartext nicht: den verschlüsselten Text signieren nicht: nur einen Teil des Klartexts signieren 2. Genügend Redundanz: Im (zu signierenden und zu verschlüsselndem) Klartext zusätzlich... den Namen des Principals wiederholen die Instruction wiederholen Software- und Systemsicherheit, Kap. 15 (18/22)

328 Daumenregeln für Protokolldesign (2) 3. Auf die Reihenfolge der Schritte achten: Bei mehreren Schritten muss man sorgfältig überlegen, wie man garantiert: (a) richtige Reihenfolge der Schritte (b) kein Schritt wird ausgelassen (c) keine anderen Schritte zwischendurch (Bzw. ob das wichtig ist.) 4. Nicht blockieren: Darauf achten, dass bei falscher Reihenfolge die SmartCard nicht in einen internen Zustand gerät, bei dem kein Kommando mehr akzeptiert wird. Software- und Systemsicherheit, Kap. 15 (19/22)

329 Daumenregeln für Protokolldesign (3) 5. Verschiedene Protokollabläufe unterscheiden: Darauf achten, dass parallele Protokollabläufe mit 2 SmartCards nicht gemischt werden können. 6. Replays vermeiden. Software- und Systemsicherheit, Kap. 15 (20/22)

330 Noch mehr Daumenregeln (aus Anderson/Needham, Programming Satan s Computer) Be very clear about the security goals and assumptions. Be clear about the purpose of encryption secrecy, authenticity, binding, or producing pseudorandom numbers. Do not assume that its use is synonymous with security. Be careful about how you ensure temporal succession and association. Where the identity of a principal is essential to the meaning of a message, it should be mentioned explicitly in the message. Make sure you include enough redundancy. Be careful that your protocol does not make some unexamined assumptions about the properties of the underlying cryptographic Software- und Systemsicherheit, Kap. 15 (21/22)

331 algorithms. If a signature is affixed to encrypted data, then one cannot assume that the signer has any knowledge of the data. A third party certainly cannot assume that the signature is authentic, so nonrepudiation is lost. Do not trust the secrecy of other people s secrets. Be careful, especially when signing or decrypting data, not to let yourself be used as an oracle by the opponent. Do not confuse decryption with signature. Be sure to distinguish different protocol runs from each other. Software- und Systemsicherheit, Kap. 15 (22/22)

332 Kapitel 16: Security? 1993: How to rob a bank the cashcard way 1993/ : Kentucky Fried Chip hack u.a. 1999: DVD-Verschlüsselung, 2000: ebook-verschlüsselung 2001: WLAN (Un-)Sicherheit, 2001: CCC klont D2 Kundenkarte Januar 2005: RFID Chips im Autoschlüssel geknackt Dezember 2006: Word/Excel Passwörter, XBox, HD DVD : Klonen des epass, Fälschen der Daten 2008: Mifare Classic Crack, Premiere Kartentausch, IPhone entsperren : SMB reflection attack November 2009: TLS Renegotiation Lücke, Chip and PIN is broken : EC-Karten Disaster September 2010: Attacke auf eperso,.net padding attack, HDCP, Dezember 2010: Private Key für PS3 gefunden Software- und Systemsicherheit, Kap. 16 (1/30)

333 How to rob a bank the cashcard way : ATMs 1993 in Großbritannien Geldautomaten Situation: Nachts ATMs offline (wegen batch processing) Lösung: PIN verschlüsselt auf Magnetstreifen speichern Problem: Software- und Systemsicherheit, Kap. 16 (2/30)

334 How to rob a bank the cashcard way : ATMs 1993 in Großbritannien Geldautomaten Situation: Nachts ATMs offline (wegen batch processing) Lösung: PIN verschlüsselt auf Magnetstreifen speichern Problem: Kontonummer unabhängig von PIN Kontonummer kann verändert werden anderes Konto wird belastet Software- und Systemsicherheit, Kap. 16 (2/30)

335 Geldautomaten in Großbritannien Problem: Phantomabhebungen Banken sagen: betrügerische Kunden Kunden klagen Ergebnis 1. Keinerlei Qualitätskontrolle bei der Softwareentwicklung 2. Es gab Betrugsmöglichkeiten (s.o.) 3. Oktober 2005 wurde bekannt: Ein IT-Zentrum war in großangelegten Betrug eingestiegen: PIN-Generierung wurde so manipuliert, dass nur 3 verschiedene PINs erzeugt wurden + Testkarten = beliebiges Abheben Software- und Systemsicherheit, Kap. 16 (3/30)

336 Kentucky Fried Chip hack Digitales (Pay-)Satelliten TV 2 Beispiele: 1. Abschaltkommando unverschlüsselt kann blockiert werden. 2. Alle Karten mit gleichem Schlüssel, der bekannt wurde Reaktivierung abgeschalteter Karten Software- und Systemsicherheit, Kap. 16 (4/30)

337 Kentucky Fried Chip hack Digitales (Pay-)Satelliten TV 2 Beispiele: 1. Abschaltkommando unverschlüsselt kann blockiert werden. 2. Alle Karten mit gleichem Schlüssel, der bekannt wurde Reaktivierung abgeschalteter Karten European Satellite-TV Pirate Card Encyclopaedia (1998): Channels - which can be viewed with pirate cards? - today, all Eurocrypt pirate cards decode all Eurocrypt channels (TV1000, Filmnet 1, Filmnet 2, TV3 Sweden, TV3 Denmark/Norway, TV2 Norge, Tv Plus, Z-TV, Tv6, Nickelodeon, VH-1, Filmnet 2, MTV, Eurosport, TCC, Discovery, CNN, TV1000 Cinema, DR2, Canal +, Cine Cinema, BBC Prime). The Videocrypt2 channels are also cracked. For the Sky channels, there are sometimes working pirate cards, but they are expensive. Software- und Systemsicherheit, Kap. 16 (4/30)

338 2001: CCC klont D2 Kundenkarte GSM (europäischer) Mobilfunkstandard Algorithmus A5 für Sprachverschlüsselung: 1994 im Internet 54 Bit Schlüsselmaterial potentiell schwach, nie geknackt A5/1 etc.: kürzere Schlüssel (Export in mittleren Osten) A3, A8: Authentisierung, Schlüsselgenerierung: COMP im Internet (geheime Studie von 1988) Schwachstelle: Anfragen geheimer Schlüssel Software- und Systemsicherheit, Kap. 16 (5/30)

339 : Karsten Nohl: A5/1 in 30 Sekunden entschlüsseln(rainbow tables, brute force) DefCon 2010: IMSI-Catcher für 1500 Dollar, die (falsche) Basisstation weist das Handy an, keine Verschlüsselung zu benutzen (so in der GSM 2 Spec vorgesehen) 27C3 (Dezember 2010): GSM entschlüsseln in 20 Sekunden, Hardware: Wegwerfhandy + Laptop Software- und Systemsicherheit, Kap. 16 (6/30)

340 2005: RFID Chips im Autoschlüssel Digital Signature Transponder von Texas Instruments für: Wegfahrsperre: Benzineinspritzung nur dann, wenn Challenge-Response mit RFID im Autoschlüssel (im Zündschloss) erfolgreich z. B. Ford 2005 insgesamt 150 Mio. Schlüssel (mit/ohne Kryptographie) Geldlose Bezahlung (Tanken etc.): ExxonMobil SpeedPass, 7 Mio. Exemplare geheimes Verfahren mit 40-bit Key, entwickelt Anfang der 90er geknackt mit brute-force re-engineering Quelle: Software- und Systemsicherheit, Kap. 16 (7/30)

341 Smart Card Protection Profile (von SCSUG): Attackers are assumed to have various levels of expertise, resources, and motivation. Relevant expertise may be in general semiconductor technology, software engineering, hacking techniques, or the specific TOE. Resources may range from personal computers and inexpensive card reading devices to very expensive and sophisticated engineering test and measurement devices. They may also include software routines, some of which are readily available on the internet. Motivation may include economic reward or the satisfication and notoriety of defeating expert security. It is assumed that given sufficient time and expertise, any smard card can be compromised. Software- und Systemsicherheit, Kap. 16 (8/30)

342 Tamper-Proof Auslesen des Speichers unmöglich Abhören der Signalleitungen unmöglich Verändern des Speichers unmöglich Datenfälschung unmöglich Geheimnisse (Schlüssel, PINs) bleiben geheim Software- und Systemsicherheit, Kap. 16 (9/30)

343 Tamper-Proof? 1990: Ablösen der Plastikhülle, Inspektion mit Mikroskop 1991: Löschen des EEPROM mit UV-Licht 1992: PIN-Angriff: Stromunterbrechung 1993: Reduzieren/Stoppen des Takts 1993: Ändern des ROM durch Laser-Schneider 1995: Erhöhen des Takts, Reduzieren der Spannung 1995: Timing Attacks 1995: Abhören der Busse mit Mikro-Nadeln, Ändern des EEPROM Software- und Systemsicherheit, Kap. 16 (10/30)

344 Tamper-Proof?? 1996: Differential Fault Analysis: Erzeugen transienter Fehler 1998: Simple Power Analysis: Messung des Stromverbrauchs 1998: Differential Power Analysis: Messung des Stromverbrauchs 2001: Messung der elektromagnetischen Abstrahlung 2002: Erzeugen von Fehlern durch Licht Software- und Systemsicherheit, Kap. 16 (11/30)

345 Die PIN-Attacke for(byte i=0; i<4; i++) if (buf[i]!= PIN[i]) { remaining tries--; ISOException.throwIt(...); } Software- und Systemsicherheit, Kap. 16 (12/30)

346 Die PIN-Attacke for(byte i=0; i<4; i++) if (buf[i]!= PIN[i]) { remaining tries--; ISOException.throwIt(...); } Problem: remaining tries steht im EEPROM Bei Update erhöhter Stromverbrauch, Dauer ca. 5 msec. Messbar, dass Zähler verändert wird Änderung kann durch Stromunterbrechung verhindert werden Software- und Systemsicherheit, Kap. 16 (12/30)

347 Die PIN-Attacke: Lösung remaining_tries--; boolean bad = false; for(byte i=0; i<4; i++) if (buf[i]!= PIN[i]) bad = true; if (bad) ISOException.throwIt(...); remaining_tries++; Software- und Systemsicherheit, Kap. 16 (13/30)

348 Timing Attack/Simple Power Analysis RSA-Signatur: c = m d mod n. Oft: Square and multiply Algorithmus: c = 1; s = m; while (d > 0) do { if (d % 2 == 1) c = c * z mod n; s = s * s mod n; e = e / 2; } Software- und Systemsicherheit, Kap. 16 (14/30)

349 Timing Attack/Simple Power Analysis RSA-Signatur: c = m d mod n. Oft: Square and multiply Algorithmus: c = 1; s = m; while (d > 0) do { if (d % 2 == 1) c = c * z mod n; s = s * s mod n; e = e / 2; } Probleme: 1. Laufzeit abhängig von # 1-Bits in d 2. Messung des Stromverbrauchs zeigt, in welchen Iterationen c = c z mod n stattfindet. 3. private key Software- und Systemsicherheit, Kap. 16 (14/30)

350 Originale Meßkurve Software- und Systemsicherheit, Kap. 16 (15/30)

351 Transformierte Kurve Software- und Systemsicherheit, Kap. 16 (16/30)

352 Multiplikationskurve Software- und Systemsicherheit, Kap. 16 (17/30)

353 Vergrößerung Software- und Systemsicherheit, Kap. 16 (18/30)

354 Erzeugen von Fehlern Ein extremes Beispiel: RSA Signieren: s = m d mod (p q). Effizienter ist s 1 = m d mod p,s 2 = m d mod q,s = f(s 1,s 2 ) (RSA im CRT Modus) Annahme: 1. Berechnung korrekt, 2. falsch p = gcd(p q,s e f m). Schlüssel geknackt Software- und Systemsicherheit, Kap. 16 (19/30)

355 Differential Fault Analysis Idee: Eine Anfrage (Signieren/Ver-/Entschlüsseln) oft ( mal) stellen Klartext muss nicht bekannt sein Fehler verursachen (bei DES etc. in den letzten Runden) die verschiedenen Ergebnisse statistisch analysieren geheimer Schlüssel Software- und Systemsicherheit, Kap. 16 (20/30)

356 Differential Power Analysis Idee: Viele ( ) unterschiedliche Anfragen (Signieren/Ver-/Entschlüsseln) stellen Klartext muss nicht bekannt sein Stromverbrauch messen Messungen mit Ergebnissen statistisch korrelieren geheimer Schlüssel Software- und Systemsicherheit, Kap. 16 (21/30)

357 Gegenmaßnahmen Hardware: Besonderes Schaltungslayout Aktiver Schutzschild Sensoren Dual rail logic (Optische Analyse) (Nadeln/Messsonden) (Takt-/Strom-Manipulation, Licht) (Fehler erzeugen) Bus/Speicher-Verschlüsselung Rauschen im Stromverbrauch Software- und Systemsicherheit, Kap. 16 (22/30)

358 Gegenmaßnahmen Software: Zähler für (Fehl-)versuche (DFA/DPA) Laufzeit unabhängig von Daten (Timing) Berechnung zufällig machen (Timing/DPA) Prüfsummen (Fehler) Berechnungen zweimal ausführen (Fehler) Ergebnisse überprüfen (Fehler) Software- und Systemsicherheit, Kap. 16 (23/30)

359 Tamper-Proof?? 1996: Differential Fault Analysis: Erzeugen transienter Fehler 1998: Simple Power Analysis: Messung des Stromverbrauchs 1998: Differential Power Analysis: Messung des Stromverbrauchs 2001: Messung der elektromagnetischen Abstrahlung 2002: Erzeugen von Fehlern durch Licht 200?:...nächster Angriff... (2007: Analyse Mifare RFID Schaltung) Software- und Systemsicherheit, Kap. 16 (24/30)

360 Die Mifare Classic Dezember 2007: Vortrag CCC 07: Karsten Nohl, Starbug, Henryk Plötz: Mifare Security Rekonstruktion der Schaltung aus Fotos Karte geknackt März 2008: Hack wird bestätigt (Uni Nijmegen) Juli 2008: Mifare-Hersteller NXP verklagt Uni Nijmegen August 2008: Boston U-Bahn verhindert per Gericht Vortrag auf der DefCon August 2008: Diplomarbeit(!) von Henryk Plötz(HU Berlin) enthält Krypto-Algorithmus im Detail Oktober 2008: Papier Uni Nijmeger erscheint auf der ESORICS Oktober 2008: Programmiertools(open source) zum Mifare-Cracken anonym im Internet veröffentlicht Software- und Systemsicherheit, Kap. 16 (25/30)

361 Einsatz der Mifare Classic Entwickelt Mitte der 90er, bessere Versionen existieren 200 Mio Karten im Umlauf (Stand 2008) Öffentlicher Nahverkehr: Boston, London, Niederlande, Minneapolis, Südkorea, Hong Kong, China, Madrid, Rio de Janeiro, Neu Dehli, Bangkok,... Mensakarte, Zugangskontrolle,... Software- und Systemsicherheit, Kap. 16 (26/30)

362 Security Team in Nijmegen Reverse Engineering durch Analyse Kommunikation Leser Karte Keine physikalische Attacke auf die Karte Aber: stimuliert durch CCC 07 Vortrag Extraktion des Secret Key aus dem Leser nur durch Abhören: 1. Attacke: Schwäche bei Initialisierung der Chiffre 2. Attacke: Zugriff auf internen Zustand der Chiffre Ergebnis: Entschlüsseln der gesamten Kommunikation, Klonen von Karten, Ändern des Zustands echter Karten Software- und Systemsicherheit, Kap. 16 (27/30)

363 Struktur der Mifare Classic Software- und Systemsicherheit, Kap. 16 (28/30)