Kapitel 2: Chipkarten

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)

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)

SmartCards 8/16 Bit CPU 32K ROM 16 64K EEPROM 0,5 4K RAM 5 Mhz clock 1024 Bit RSA/3-DES 9600 55800 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)

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)

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

ISO7816 1: Physical characteristics Schutz gegen UV Licht/Röntgenstrahlen Schutz vor (statischer) Elektrizität/Magnetfeld Breite 85.47mm - 85.72mm, Höhe 53.92mm - 54.03mm, Dicke 0.76mm + 0.08mm 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)

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

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)

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)

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 102 190: Near Field Communication Interface and Protocol (NFC)... Software- und Systemsicherheit, Kap. 2 (10/17)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

// 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)

// 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)

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)

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)

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)

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)

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)

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

Kapitel 4: Kommunikation mit der Karte Relevanter Standard: ISO 7816-4 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)

Command APDU: CLA INS P1 P2 Lc 90 02 00 00 02 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 SW2 90 00 Software- und Systemsicherheit, Kap. 4 (2/14)

Statuswort SW = SW1+SW2 ISO: SW1 = 90 (ok), SW1 = 6x (Fehler), SW1 = 60 (Wait Extension) 90 00 No Error SW NO ERROR, SW OK 67 00 Wrong length SW WRONG LENGTH 69 82 Security condition not satisfied SW PIN REQUIRED 69 84 Data invalid SW DATA INVALID 69 85 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)

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

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

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)

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

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

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)

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)

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 A4 04 00 Lc AID SW = 0x9000 ok, SW = 0x6XYY, X 0: Fehler Eigene Fehler: 0x62YY, 0x63YY, 0x64YY, 0x65YY Software- und Systemsicherheit, Kap. 4 (11/14)

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)

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 A4 04 00 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)

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)

Kapitel 5: Die JavaCard API Relevante Spezifikation: JavaCard 2.2.1 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)

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)

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 2.0.1 Syntax Software- und Systemsicherheit, Kap. 5 (3/17)

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)

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)

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

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)

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)

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)

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)

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)

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)

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)

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 = 9000. Oder: Exception werfen: ISOException.throwIt(sw) Antwort = sw. Eigene Statusworte: 0x6xxx Software- und Systemsicherheit, Kap. 5 (14/17)

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)

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)

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)

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

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)

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

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

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

Wertebereiche in Java Typ Länge Minimaler Wert Maximaler Wert byte 8 Bit -128 127 short 16 Bit -32768 32767 int 32 Bit -2147483648 2147483647 long 64 Bit -9223372036854775808 9223372036854775807 Software- und Systemsicherheit, Kap. 6 (3/21)

Arithmetik in Java: Java Language Specification 4.2.2 (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)

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) 1.000.000 1.000.000 = 727.379.968 (Overflow) (Bem.: Ein Argument long: Berechnung/Ergebnis long, analog für float, double) Software- und Systemsicherheit, Kap. 6 (5/21)

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)

Arithmetik in Java: Java Language Specification 5.1.2 (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 5.1.3 (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)

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

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

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

2er-Komplement: 1. Schritt: bilde Bitdarstellung des Betrags 34 0010 0010 2. Schritt: bitweise Invertierung 1101 1101 3. Schritt: addiere 1 1101 1110 = -34 +34 = -34 = 0010 0010 (byte) 0000 0000 0010 0010 (short) 0000 0000 0000 0000 0000 0000 0010 0010 (int) 1101 1110 (byte) 1111 1111 1101 1110 (short) 1111 1111 1111 1111 1111 1111 1101 1110 (int) Software- und Systemsicherheit, Kap. 6 (8/21)

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

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

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

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

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

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

Eigenschaften Führendes Bit ist Vorzeichen: 0 ˆ= positive, 1 ˆ= negative Zahl größte Byte-Zahl: 0111 1111 = 0x7F = 127 kleinste Byte-Zahl: 1000 0000 = 0x80 = -128 Cast schneidet obere Bits ab: 0000 1000 1111 1111 1111 1111 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)

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

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

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

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

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

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)

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

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)

3. Casts: A0 = 1010 0000 - führendes 1-Bit byte int: A0 FF FF FF A0 int byte: 00 00 00 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) = 160 5. 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)

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

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

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

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

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

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

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

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

Short- vs. Integer-Arithmetik 1. Beispiel: short x1 = 20000, x2 = (short)((x1 * 5) / 10); Integer-Arithmetik: x2 = 10000 Short-Arithmetik: x2 = 3107 2. Beispiel: short x1 = 20000, x2 = 30000, x3 = (short)((x1 + x2) - x2); Integer-Arithmetik: x3 = 20000 Short-Arithmetik: x3 = 20000 3. 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)

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)

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)

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)

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)

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)

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)

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)

Prinzip short-arithmetik = int-arithmetik, wenn... 1. 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; 32768 < b * (x % c) < 32767 Software- und Systemsicherheit, Kap. 6 (15/21)

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)

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)

Rechengesetze (3): Im Allgemeinen (auch für Varianten): 1. (short)(s / t) (short)((short)s / (short)t) Beispiel: s = 2 16,t = 2 15 2. (short)(s % t) (short)((short)s % (short)t) Beispiel: s = 2 2 16 1,t = 2 16 1 3. (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)

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)

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 + 127 passt Ok! (x + y) == z kein Cast notwendig. Ebenso für -, * 4. byte x,y,z x + y + z, x + 128 passt Fehler! Software- und Systemsicherheit, Kap. 6 (20/21)

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)

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

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

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)

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)

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)

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)

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. 12345 32451 (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)

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)

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)

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)

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

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

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

00 00 00 00 00 00 18 0F 10 45 41 57 18 1C 55 0F...EAW..U. 47 50 00 14 09 1B 45 1D 46 46 20 06 0A 41 60 45 GP...E.FF..A E 3E 0F 07 0C 7B 38 0C 0A 00 00 08 07 48 50 0D 55 >...{8...HP.U 1E 0F 00 02 02 00 07 07 53 41 4D 15 00 03 45 10...SAM...E. 42 00 20 00 00 59 53 17 04 58 55 21 0F 0C 00 00 B...YS..XU!... 15 1A 0A 41 00 53 38 09 45 13 1A 01 45 53 23 06...A.S8.E...ES#. 04 48 50 18 1D 08 42 05 0F 03 55 00 20 4E 07 01.HP...B...U. N.. 0D 0B 47 00 32 01 09 45 1B 06 00 07 00 4D 0A 03..G.2..E...M.. 08 49 01 09 01 53 48 36 41 0F 05 43 0D 45 43 46.I...SH6A..C.ECF 07 2D 0D 16 0C 54 05 08 13 17 02 00 69 00 4B 4E.-...T...i.KN 4F 57 00 54 48 41 54 0C 00 49 54 07 53 00 4D 45 OW.THAT..IT.S.ME 0E 07.. Software- und Systemsicherheit, Kap. 7 (13/13)

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

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)

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)

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: 00 00 00 00 00 00 00 00 Chiffre: B0 73 DC 3F B2 09 53 6D 11111000 11000100 00001000 00001101 01101110 01110110 11101010 01110110 10110000 01110011 11011100 00111111 10110010 00001001 01010011 01101101 Software- und Systemsicherheit, Kap. 8 (4/20)

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

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

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)

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)

Schlüssel: F8 C4 08 0D 6E 76 EA 76 Klartext: 00 00 00 00 00 00 00 00 Chiffre: B0 73 DC 3F B2 09 53 6D 11111000 11000100 00001000 00001101 01101110 01110110 11101010 01110110 10110000 01110011 11011100 00111111 10110010 00001001 01010011 01101101 Software- und Systemsicherheit, Kap. 8 (8/20)

Schlüssel: F8 C4 08 0D 6E 76 EA 76 Klartext: 00 00 00 00 00 00 00 00 Chiffre: B0 73 DC 3F B2 09 53 6D 11111000 11000100 00001000 00001101 01101110 01110110 11101010 01110110 10110000 01110011 11011100 00111111 10110010 00001001 01010011 01101101 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)

Schlüssel: F8 C4 08 0D 6E 76 EA 76 Klartext: 00 00 00 00 00 00 00 00 Chiffre: B0 73 DC 3F B2 09 53 6D 11111000 11000100 00001000 00001101 01101110 01110110 11101010 01110110 10110000 01110011 11011100 00111111 10110010 00001001 01010011 01101101 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)

Schlüssel: F8 C4 08 0D 6E 76 EA 76 Klartext: 00 00 00 00 00 00 00 00 Chiffre: B0 73 DC 3F B2 09 53 6D 11111000 11000100 00001000 00001101 01101110 01110110 11101010 01110110 10110000 01110011 11011100 00111111 10110010 00001001 01010011 01101101 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 2 112 Schlüssel probieren 8388608 Jahre Software- und Systemsicherheit, Kap. 8 (8/20)

Schlüssel: F8 C4 08 0D 6E 76 EA 76 Klartext: 00 00 00 00 00 00 00 00 Chiffre: B0 73 DC 3F B2 09 53 6D 11111000 11000100 00001000 00001101 01101110 01110110 11101010 01110110 10110000 01110011 11011100 00111111 10110010 00001001 01010011 01101101 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 2 112 Schlüssel probieren 8388608 Jahre 256 Bit Schlüssellänge (AES) 10 50 Jahre Software- und Systemsicherheit, Kap. 8 (8/20)

RSA s DES Challenge III Start: January 18, 1999 9: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 91 99 60 b8 8a 47 9c b1 5c 23 7b 81 18 99 05 45 bc de 82 01 ab 53 4d 6f 1c b4 30 63 3c ee cd 96 2e 07 c6 e6 95 99 9c 96 46 5a 95 70 02 02 70 98 bd 41 c2 88 a9 f0 2f 8b e5 48 20 d2 a8 a0 6b bf 93 de 89 f6 e2 52 fd 8a 25 eb d0 7d 96 83 ee a4 2d c8 8d 1b 71 Software- und Systemsicherheit, Kap. 8 (9/20)

RSA s DES Challenge III is solved in record time Start: January 18, 1999 9: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 91 99 60 b8 8a 47 9c b1 5c 23 7b 81 18 99 05 45 bc de 82 01 ab 53 4d 6f 1c b4 30 63 3c ee cd 96 2e 07 c6 e6 95 99 9c 96 46 5a 95 70 02 02 70 98 bd 41 c2 88 a9 f0 2f 8b e5 48 20 d2 a8 a0 6b bf 93 de 89 f6 e2 52 fd 8a 25 eb d0 7d 96 83 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)

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

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

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

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

distributed.net ca. 100.000 PCs: At theendofthecontest,over250billionkeys(possiblecodes for decrypting the encrypted message) were being checked each second. Deep Crack Spezialrechner für DES (Öffentlich, 250.000 $) 1536 ASICs, 36864 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)

distributed.net ca. 100.000 PCs: At theendofthecontest,over250billionkeys(possiblecodes for decrypting the encrypted message) were being checked each second. Deep Crack Spezialrechner für DES (Öffentlich, 250.000 $) 1536 ASICs, 36864 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)

distributed.net ca. 100.000 PCs: At theendofthecontest,over250billionkeys(possiblecodes for decrypting the encrypted message) were being checked each second. Deep Crack Spezialrechner für DES (Öffentlich, 250.000 $) 1536 ASICs, 36864 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)

distributed.net ca. 100.000 PCs: At theendofthecontest,over250billionkeys(possiblecodes for decrypting the encrypted message) were being checked each second. Deep Crack Spezialrechner für DES (Öffentlich, 250.000 $) 1536 ASICs, 36864 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: 1049229366788527530565065435109369569680144061811429 Jahre! Software- und Systemsicherheit, Kap. 8 (10/20)

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)

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)

Padding Standards zum Auffüllen des Textes auf Vielfache der Blocklänge. 1. NoPadding: Text muss Vielfaches der Blocklänge sein. 2. X9.23, ISO10126-2: 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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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

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)

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

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

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 X9.62-1998 Software- und Systemsicherheit, Kap. 9 (4/16)

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)

Zufallszahlen (4) Wenn lang genug (z.b. 8 Byte, 2 64 = 18446744073709551616 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)

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)

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)

MD5 - Kollision d1 31 dd 02 c5 e6 ee c4 69 3d 9a 06 98 af f9 5c 2f ca b5 87 12 46 7e ab 40 04 58 3e b8 fb 7f 89 55 ad 34 06 09 f4 b3 02 83 e4 88 83 25 71 41 5a 08 51 25 e8 f7 cd c9 9f d9 1d bd f2 80 37 3c 5b d8 82 3e 31 56 34 8f 5b ae 6d ac d4 36 c9 19 c6 dd 53 e2 b4 87 da 03 fd 02 39 63 06 d2 48 cd a0 e9 9f 33 42 0f 57 7e e8 ce 54 b6 70 80 a8 0d 1e c6 98 21 bc b6 a8 83 93 96 f9 65 2b 6f f7 2a 70 d1 31 dd 02 c5 e6 ee c4 69 3d 9a 06 98 af f9 5c 2f ca b5 07 12 46 7e ab 40 04 58 3e b8 fb 7f 89 55 ad 34 06 09 f4 b3 02 83 e4 88 83 25 f1 41 5a 08 51 25 e8 f7 cd c9 9f d9 1d bd 72 80 37 3c 5b d8 82 3e 31 56 34 8f 5b ae 6d ac d4 36 c9 19 c6 dd 53 e2 34 87 da 03 fd 02 39 63 06 d2 48 cd a0 e9 9f 33 42 0f 57 7e e8 ce 54 b6 70 80 28 0d 1e c6 98 21 bc b6 a8 83 93 96 f9 65 ab 6f f7 2a 70 Software- und Systemsicherheit, Kap. 9 (9/16)

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)

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)

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 31.10.2008: 64 Einreichungen 2010: noch 14 übrig Entscheidung 2012 geplant Software- und Systemsicherheit, Kap. 9 (11/16)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

Sichere Kommunikation mit der Smart Card Grundlage: ISO 7816-4, 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)

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)

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)

Mutual Authentication (APDUs) 1. Initialize Update: Schlüsselnr. + Zufallszahl N 1 80 50 0D 00 08 00 00 00 00 00 00 00 00 1C P1 = 0D: Key set version P2 = 00: Key index (00: erster verfügbarer) Antwort: 43 4D 61 FF 21 57 F4 07 17 11 (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) 90 00 Software- und Systemsicherheit, Kap. 11 (13/21)

2. External Authenticate 84 82 00 00 10 (Sicherheitsstufe) B9 B0 40 11 79 C7 07 10 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)

Kryptogramme 1. D = N 1 +N 2 + 0x80 00 00 00 00 00 00 00 2. verschlüssele D mit 3DES/CBC, IV = 0x00 00 00 00 00 00 00 00 3. 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)

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)

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)

Schlüssel Key Diversification: Berechne Schlüssel für jede Karte n Ausgangspunkt: 2DES Mother key MK = 47 45 4D 58 50 52 45 53 53 4F 53 41 4D 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)

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)

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)

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

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

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)

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)

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

Anzahl Primzahlen der Länge 1024 Bit 12651307410331561612287515175386710353237098956273445646466036883594 00015944240673886333579519658615644189346781192373999743611737189907 91007698881506790641087948193858955233664549746019822494536141699553 95044903323238520381291863113009513502941611543079003335131774527967 6977211484011404917064419380394375 Software- und Systemsicherheit, Kap. 12 (4/22)

Anzahl Primzahlen der Länge 1024 Bit 12651307410331561612287515175386710353237098956273445646466036883594 00015944240673886333579519658615644189346781192373999743611737189907 91007698881506790641087948193858955233664549746019822494536141699553 95044903323238520381291863113009513502941611543079003335131774527967 6977211484011404917064419380394375 (ca.) Software- und Systemsicherheit, Kap. 12 (4/22)

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

Name: RSA-2048 Prize: $200000 Digits: 617 Digit Sum: 2738 2519590847565789349402718324004839857142928212620403202777\ 7137836043662020707595556264018525880784406918290641249515\ 0821892985591491761845028084891200728449926873928072877767\ 3597141834727026189637501497182469116507761337985909570009\ 7330459748808428401797429100642458691817195118746121515172\ 6546322822168699875491824224336372590851418654620435767984\ 2338718477444792073993423658482382428119816381501067481045\ 1660377306056201619676256133844143603833904414952634432190\ 1146575444541784240209246165157233507787077498171257724679\ 6292638635637328991215483143816789988504044536402352738195\ 1378636564391212010397122822120720357 Software- und Systemsicherheit, Kap. 12 (6/22)

12.12.2009: RSA-768 gelöst. Faktoren: 3347807169895689878604416984821269081770479498371376856891 2431388982883793878002287614711652531743087737814467999489 und 3674604366679959042824463379962795263227915816434308764267 6032283815739666511279233373417143396810270092798736308917 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 6.1.2010: Minimale Schlüssellängen: Zeitraum bis Ende bis Ende bis Ende bis Ende bis Ende 2007 2008 2009 2010 2016 Länge 1024 1280 1536 1728 1976 Software- und Systemsicherheit, Kap. 12 (7/22)

Eigenschaften von RSA RSA hat erwünschte und unerwünschte mathematische Eigenschaften. Beispiel: 17.3.2003: 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)

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)

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

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

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)

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 14.6.2002, OAEP: Optimal Asymmetric Encryption Padding Software- und Systemsicherheit, Kap. 12 (11/22)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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

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

RC4 1987 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)

RC4 1987 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 = 255 2. 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)

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)

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)

Digitale Signatur mit DSA DSA (= digital signature algorithm, FIPS 186-2). Standardisiert 2000. 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 512 1024 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)

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)

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)

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)

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)

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)

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)

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)

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

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)

Ü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)

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

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

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

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

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

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)

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)

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)

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

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)

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)

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)

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 2008. Software- und Systemsicherheit, Kap. 15 (5/22)

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)

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

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

Kapitel 16: Security? 1993: How to rob a bank the cashcard way 1993/95 2008: 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 2005-2008: Klonen des epass, Fälschen der Daten 2008: Mifare Classic Crack, Premiere Kartentausch, IPhone entsperren 2001-2008: SMB reflection attack November 2009: TLS Renegotiation Lücke, Chip and PIN is broken 1.1.2010: 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)

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)

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)

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)

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)

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)

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: COMP128 1997 im Internet (geheime Studie von 1988) Schwachstelle: 150.000 Anfragen geheimer Schlüssel Software- und Systemsicherheit, Kap. 16 (5/30)

30.7.2010: 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)

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: www.rfidanalysis.org Software- und Systemsicherheit, Kap. 16 (7/30)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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

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

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

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)

Differential Fault Analysis Idee: Eine Anfrage (Signieren/Ver-/Entschlüsseln) oft (100-5000 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)

Differential Power Analysis Idee: Viele (1000-10000) 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)

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)

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)

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)

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)

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)

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)

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