Kapitel 2: Chipkarten - Institut für Informatik

Transcription

Kapitel 2: Chipkarten
Chip card technologies hold great promise as the replacement for
”
magnetic stripe card technology. However, the adoption of chip cards
on a mass scale has been slow to develop. One significant reason for this
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. Prägedruck
3. Magnetstreifen
4. Identification Card with Integrated Circuit (Patent 1968)
5. Speicherkarte (Memory Card)
6. SmartCard (Integrated Circuit Card, ICC)
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
C1
C2
C3
C5
C6
C7
⊢ 1, 1 ⊣
•
⊢ 1, 25 ⊣
C1
C2
C3
C5
C6
C7
:
:
:
:
:
:
Vcc = 5V
Reset
Clock
Ground
Vpp
I/O
SmartCards
32 Bit CPU
•
240 K ROM
•
400 K EEPROM
•
16 K RAM
•
66 Mhz clock
•
2048 Bit RSA/EC
C1
C2
C3
C5
C6
C7
⊢ 1, 1 ⊣
•
⊢ 1, 25 ⊣
C1
C2
C3
C5
C6
C7
:
:
:
:
:
:
Vcc = 5V
Reset
Clock
Ground
Vpp
I/O
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 für globalen Masseneinsatz
ISO7816 1: Physical characteristics
•
Schutz gegen UV Licht/Röntgenstrahlen
•
Schutz vor (statischer) Elektrizität/Magnetfeld
•
Breite 85.47mm - 85.72mm, Höhe 53.92mm - 54.03mm,
Dicke 0.76mm + 0.08mm
•
Höhe der Kontakte: < 0.1 mm Differenz zur Karte
•
Schutz gegen Druck auf die Oberfläche
•
Verbiegen: 2cm längs, 1cm quer (30× pro sec., 1000 Mal)
•
Verdrehen: 15 Grad (30× pro sec., 1000 Mal)
Spezifikation der Kontakte
ISO7816-3: Signale
I/O : (C 7) serielle Datenübertragung
VPP : (C 6) Programmierspannung (fü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
Weitere Spezifikationen
•
EMV 4.1: Integrated Circuit Card Specification for Payment Systems
Erweiterungen fü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
•
ETSI (European Telecommunications Standards Institute):
GSM, UMTS
•
EN 726 (Europäische Norm): Anforderungen an Chipkarten und
Endgeräte fü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)
•
...
Mitspieler
Chiphersteller: Philips, Infineon, Hitachi, Siemens, Toshiba, . . .
Betriebssysteme: JavaCard (SUN), MULTOS (Mondex),
viele proprietäre
JavaCard Kartenherausgeber: Gemplus/Gemalto, Schlumberger,
Gieseke & Devriant, IBM
Anwendungsspezifikationen: Visa, MasterCard, ZKA (Zentraler Kreditausschuss), gematik (Gesellschaft für Telematikanwendungen
der Gesundheitskarte mbH), ICAO (International Civil Aviation
Organization)
Anwendungen
•
Authentifizierung
•
Speicher für PINs und
geheime Schlüssel
•
Reisepass,
Studentenausweis,
Führerschein, . . .
•
SIM
•
Elektronische Geldbörse
•
Elektronische Fahrkarten
Anwendungen
•
Authentifizierung
•
Speicher für PINs und
geheime Schlüssel
•
Reisepass,
Studentenausweis,
Führerschein, . . .
•
SIM
•
Elektronische Geldbörse
•
Elektronische Fahrkarten
Sicherheit
Kein Speicher-Auslesen
(tamper-proof, physikalisch)
+ starke Kryptographie
(digitale Signaturen)
+ kryptographische Protokolle
(anwendungsspezifisch)
⇒ Kein unauthorisierter Zugriff
(kein Lesen, kein Schreiben)
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 Schlüsseln
3. Personalisierung der Karte
(Anwendungsanbieter, application provider )
Laden der Anwendung, geheimer Schlüssel, PINs etc.
4.
Benutzung der Karte (Inhaber, card holder )
5. Beendigung der Benutzung
Löschen der Anwendung, Sperren der Karte
Multiapplikative Karten/Global Platform
Cardmanager
•
gehört Card Issuer
•
verwaltet Schlüssel
•
lädt/löscht Anwendungen während der Benutzungsphase
•
ist selbst Applikation mit Registry
Security Domain
•
gehört Application Provider
•
verwaltet Schlüssel
•
Delegated Management Privilege: darf selbst Anwendungen laden
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, gelöscht
Eine Card Session
•
Power – Karte in Kartenleser
•
Reset – ATR, Answer to Reset
•
Aushandeln Protokoll, Takt
•
Cardmanager empfä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 ⇒ Rücksetzen von Authorisierungen bei select
JavaCard Architektur
Applet 1
Applet 1
Applet 1
Card
Manager
JavaCard API
JCRE
Java Card VM
Card specific Operating System
Kapitel 3: JavaCard
Java für spezielle Geräte
Designentscheidungen:
•
Weglassen unsinniger Klassen/Hinzufügen nützlicher Klassen
•
Berücksichtigung von Ressourcenbeschränkungen
Anpassungen:
•
JavaCard 2.x für Chipkarten (wir: 2.2.1)
•
Mitte 2008: JavaCard 3, classic vs. connected edition
•
Java 2 Micro Edition für Handhelds
•
JavaTV für digitales TV (Settop Box)
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)
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)
API: Zusä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-/Entschlüsseln
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 möglich, aber nur ein Package
4. Vorher: Offline byte code verifier
Prüft, dass keine Strings, Integers, nicht unterstützte Klassen benutzt werden.
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
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, gelöscht
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;
// 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])
// 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);
}
}
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);
}
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;
}
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
Speichermanagement
•
EEPROM: electrically erasable programmable read-only memory,
persistent
Appletcode + Heap (Felder + Objekte + Arrays)
•
RAM: random access memory, transient, flüchtig
Lokale Variablen + transiente Arrays
•
Stromausfall
⇒ Transaktionen (für Zuweisungen)
⇒ kein deselect ⇒ Initialisierung in select
Programmierrichtlinien
Keine Garbage-Collection, langsames EEPROM
•
So einfach wie mö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
•
Möglichst nichts statisch (außer Konstanten)
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(...)
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
Command APDU:
CLA
INS
P1
P2
Lc
90
02
00
00
02
Daten
01
2C
Le
8
CLA. Class-Byte: ISO/proprietär/verschlüsselt
INS. Instruction-Byte: Was tun? (gerade, 6= 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
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
Das Protokoll (1)
1. Kein Input, kein Output
CLA
INS
P1
P2
0
SW1
SW2
Das Protokoll (2)
2. Kein Input, aber Output bekannter Lä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
Das Protokoll (3)
3. Input, kein Output
CLA
INS
P1
P2
Lc
Lc = Anzahl Datenbytes
Ack
Daten
SW1
SW2
SW1
SW2
oder
CLA
INS
P1
P2
Lc
Das Protokoll (4)
4. Input und Output
CLA
INS
P1
P2
Lc
Ack
Daten
Le
Daten
90
00
Das Protokoll (4’)
4’. Input und Output (= Input/kein Output, kein Input/Output)
CLA
INS
P1
P2
Lc
Ack
Daten
61
00
C0
00
00
xx
xx
Ack
Daten
90
00
Ack und Timeout
•
Ack = Ins ⇒ Alle Daten auf einmal übertragen
•
Ack = ! Ins ⇒ Daten einzeln übertragen
•
Ack für Programmierer transparent, aber:
setIncomingAndReceive() in JavaCard!
•
Spezialfall: Wait Extension 0x60 statt Ack oder SW
•
Timeout: Abhängig von (berechnet aus) ATR und Taktrate
•
Behandlung Le und Fehler: Abhängig von Middleware
Bei uns: Le wird nicht an die Karte geschickt!
Das Class-Byte
•
CLA = 0x0X (APDU-Struktur und Bedeutung laut ISO)
•
CLA = 0x8X, 0x9X (Struktur wie ISO, Bedeutung proprietär)
•
CLA = 0xAX: Wie ISO, wenn nicht anders definiert
•
CLA = 0xB0 – 0xCF: ISO, 0xD0 – 0xFE: Proprietär
•
CLA = 0xFF: Wahl des Protokolls (T=0, T=1)
•
X = b4 b3 b2 b1 :
00xx:
01xx:
10xx:
11xx:
keine Security
proprietäre Security
secure messaging, ohne Header
secure messaging, mit Header
•
xx: Logischer Kanal/Art des SM: MAC, Verschlüsselt, . . .
•
Wir: CLA = 0x90
INS-Byte und SW
•
Einschränkungen an INS: 6= 00, 6= 6x, 6= 9x, nicht ungerade!
•
ISO definiert 18 Instruktionen, z.B.
0x82: External Authenticate
0xA4: Select File, P1 = 04: Selection by name
0xC0: Get Response
Andere für Daten: put/get data/binary/record . . .
•
Select APDU: 00
•
SW = 0x9000 ok, SW = 0x6XYY, X 6= 0: Fehler
•
Eigene Fehler: 0x62YY, 0x63YY, 0x64YY, 0x65YY
A4
04
00
Lc
AID
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 möglich: Direkte Benutzung der PC/SC API
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: Vollständiges Command-APDU als Byte Array
(≥ 5 Byte, nicht zu lang!)
Ausgabe: Response-APDU als Byte Array (genauso lang wie
Antwort, mind. 2 Bytes)
Umgang mit Stromunterbrechungen
•
Einlegen/Herausziehen der Karte wird nicht automatisch bemerkt.
•
Exception beim nächsten transmit.
•
Nach Exception: Verhalten abhä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: Statuswörter
Kapitel 5: Die JavaCard API
Relevante Spezifikation: JavaCard 2.2.1 API
Packages
javacard.framework (5 Interfaces, 6 Klassen, 8 Exceptions) grundlegende Funktionalität
javacard.security (15 Interfaces, 7 Klassen, 1 Exception)
javacardx.crypto (1 Interface, 1 Klasse) Kryptographie
javacard.framework.service (3 Interfaces, 4 Klassen) rudimentäre
RMI Unterstützung
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
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.
Trägt Applet in Registry des Cardmanagers ein.
•
protected final void register(byte bArray[], short bOffset,
byte bLength)
Version für erweiterte Openplatform 2.0.1’ Syntax
•
public boolean select()
Wird aufgerufen, wenn Applet selektiert wird
Typischer Code: Rü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.
Erhält auch das select-Kommando
•
public void deselect()
Wird bei weiterem select-Kommando aufgerufen.
Wird nicht bei reset oder Stromunterbrechung aufgerufen!
•
protected final boolean selectingApplet()
true falls APDU ist select
•
public Shareable getShareableInterfaceObject(AID clientAID,
byte parameter)
Für Kommunikation zwischen Applets.
Eigene Applets
public class MyApplet extends Applet . . .
Das eigene Applet sollte folgende Methoden überschreiben:
•
install
•
select
•
process
Interface javacard.framework.ISO7816
Definition von Indizes und Statuswörtern: CLA
INS
P1
P2
Lc
package javacard.framework;
public interface ISO7816 {
public
public
public
public
public
public
final
final
final
final
final
final
static
static
static
static
static
static
byte
byte
byte
byte
byte
byte
OFFSET_CLA
OFFSET_INS
OFFSET_P1
OFFSET_P2
OFFSET_LC
OFFSET_CDATA
=
=
=
=
=
=
0;
1;
2;
3;
4;
5;
public final static byte INS_SELECT = (byte)0xA4;
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
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
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
Lä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
Class javacard.framework.APDU (2)
Spezielle Methoden fü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
Daten verschicken
•
public void setOutgoingAndSend(short bOff, short len)
Vorher: Daten in APDU Buffer schreiben von Offset bOff mit
Lä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!
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)
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 hängt 9000 an.
Oder: Nichts tun ⇒ Antwort = 9000.
Oder: Exception werfen: ISOException.throwIt(sw) ⇒ Antwort = sw.
Eigene Statusworte: 0x6xxx
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 (unnötig!)
Nur ein Exception-Object, das mit throwIt wiederverwendet wird.
Ansonsten: Error-handling wie in Java.
Nicht behandelte Fehler ⇒ Karte antwortet mit 6F 00.
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)
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 möglich, aber meistens sinnlos
•
Object[] ist möglich, Object kann wieder Arrays enthalten
Kapitel 6: Arithmetik in JavaCard
Problem: Keine Integers in JavaCard
ToDo: Rechnen mit Bytes und Shorts
Hex-Notation
1 Byte = 8 Bit, b7 b6 b5 b4 b3 b2 b1 b0
Hex-Notation
0101
| {z }
| {z } 1110
Hex-Notation
7
6
5
4
1110
=
0
∗
2
+
1
∗
2
+
0
∗
2
+
1
∗
2
+
0101
| {z } | {z }
1 ∗ 23 + 1 ∗ 22 + 1 ∗ 21 + 0 ∗ 20 = 94
Hex-Notation
7
6
5
4
1110
=
0
∗
2
+
1
∗
2
+
0
∗
2
+
1
∗
2
+
0101
| {z } | {z }
1 ∗ 23 + 1 ∗ 22 + 1 ∗ 21 + 0 ∗ 20 = 94
5
E
= 0x5E = 5 ∗ 16 + 14 = 94
Hex: 0. . . 9, 10 = A, 11 = B, 12 = C, 13 = D, 14 = E, 15 = F
Wertebereiche in Java
Typ
Länge
Minimaler Wert
byte
8 Bit
-128
short
16 Bit
-32768
int
32 Bit
-2147483648
long
64 Bit
-9223372036854775808
Maximaler Wert
127
32767
2147483647
9223372036854775807
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.
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 für float, double)
Arithmetik in Java:
•
Automatische Konvertierung byte → short → int
•
Umgekehrt ist expliziter Cast notwendig!
•
•
Cast: überzä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
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.
2er-Komplement:
1. Schritt:
bilde Bitdarstellung des Betrags
34 ⇒ 0010 0010
2er-Komplement:
1. Schritt:
2. Schritt:
bitweise Invertierung
34 ⇒ 0010 0010
⇒ 1101 1101
2er-Komplement:
1. Schritt:
34 ⇒ 0010 0010
2. Schritt:
⇒ 1101 1101
3. Schritt:
addiere 1
⇒ 1101 1110 = -34
2er-Komplement:
1. Schritt:
34 ⇒ 0010 0010
2. Schritt:
⇒ 1101 1101
3. Schritt:
addiere 1
⇒ 1101 1110 = -34
0010 0010
+34
=
0000 0000 0010 0010
0000 0000 0000 0000 0000 0000 0010 0010
1101 1110
-34
=
1111 1111 1101 1110
1111 1111 1111 1111 1111 1111 1101 1110
(byte)
(short)
(int)
(byte)
(short)
(int)
Eigenschaften
Eigenschaften
•
Führendes Bit ist Vorzeichen: 0 =
ˆ positive, 1 =
ˆ negative Zahl
Eigenschaften
•
ˆ positive, 1 =
ˆ negative Zahl
•
⇒ größte Byte-Zahl: 0111 1111 = 0x7F = 127
Eigenschaften
•
ˆ positive, 1 =
ˆ negative Zahl
•
•
⇒ kleinste Byte-Zahl: 1000 0000 = 0x80 = -128
Eigenschaften
•
ˆ positive, 1 =
ˆ negative Zahl
•
•
•
Cast schneidet obere Bits ab: 0000 1000 1111 1111 ⇒ 1111 1111
Eigenschaften
•
ˆ positive, 1 =
ˆ negative Zahl
•
•
•
Beobachtung: Cast hat etwas mit Modulo 256 zu tun.
Eigenschaften
•
ˆ positive, 1 =
ˆ negative Zahl
•
•
•
Beobachtung: Cast hat etwas mit Modulo 256 zu tun.
Frage: Lässt sich Cast als einfache mathematische Formel darstellen?
Cast und Rest
•
Rest: 5 % 3 =
Cast und Rest
•
Rest: 5 % 3 = 2, -5 % 3 =
Cast und Rest
•
Rest: 5 % 3 = 2, -5 % 3 = -2, 5 % -3 =
Cast und Rest
•
Rest: 5 % 3 = 2, -5 % 3 = -2, 5 % -3 = 2, -5 % -3 =
Cast und Rest
•
Rest: 5 % 3 = 2, -5 % 3 = -2, 5 % -3 = 2, -5 % -3 = -2
Cast und Rest
•
Rest: 5 % 3 = 2, -5 % 3 = -2, 5 % -3 = 2, -5 % -3 = -2
•
int i; (byte)i = ?
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
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 ausgefü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)
3. Casts: A0 = 1010 0000 - fü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
Short- vs. Integer-Arithmetik
1. Beispiel: short x1 = 20000, x2 = (short)((x1 * 5) / 10);
Integer-Arithmetik:
Integer-Arithmetik: x2 = 10000
Short-Arithmetik:
Short-Arithmetik:
x2 = –3107
Short-Arithmetik:
x2 = –3107
2. Beispiel: short x1 = 20000, x2 = 30000,
x3 = (short)((x1 + x2) - x2);
Integer-Arithmetik:
Short-Arithmetik:
x2 = –3107
x3 = (short)((x1 + x2) - x2);
Short-Arithmetik:
Short-Arithmetik:
x2 = –3107
x3 = (short)((x1 + x2) - x2);
Short-Arithmetik:
x3 = 20000
Short-Arithmetik:
x2 = –3107
x3 = (short)((x1 + x2) - x2);
Short-Arithmetik:
x3 = 20000
3. Beispiel: short x1 = 20000, x2 = 30000;
boolean res = (x1 < x1 + x2);
Integer-Arithmetik:
Short-Arithmetik:
x2 = –3107
x3 = (short)((x1 + x2) - x2);
Short-Arithmetik:
x3 = 20000
Integer-Arithmetik: res = true;
Short-Arithmetik:
Short-Arithmetik:
x2 = –3107
x3 = (short)((x1 + x2) - x2);
Short-Arithmetik:
x3 = 20000
Integer-Arithmetik: res = true;
Short-Arithmetik:
res = false;
Der cap-Converter:
•
prüft, dass kein int, long, . . . benutzt wird.
•
prüft, dass short-Arithmetik = int-Arithmetik
⇒ Rechengesetze
Beispiele:
Der cap-Converter:
•
•
⇒ Rechengesetze
Beispiele:
1.
(short)((x * y) - z)
Der cap-Converter:
•
•
⇒ Rechengesetze
Beispiele:
1.
Ok
Der cap-Converter:
•
•
⇒ Rechengesetze
Beispiele:
1.
2.
x + y < z
Ok
Der cap-Converter:
•
•
⇒ Rechengesetze
Beispiele:
1.
Ok
2.
x + y < z
Fehler!
Der cap-Converter:
•
•
⇒ Rechengesetze
Beispiele:
1.
Ok
2.
x + y < z
Fehler!
3.
(x + y) / 1000
Der cap-Converter:
•
•
⇒ Rechengesetze
Beispiele:
1.
Ok
2.
x + y < z
Fehler!
3.
(x + y) / 1000
Fehler!
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 Größe her in ein short passt:
byte b, c; ⇒ −32768 < b * (x % c) < 32767
Rechengesetze (1):
s, t: bel. Ausdrücke mit Ergebnistyp int, z. B. s = (x * y) * z
1.
Unäres Minus:
(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)
= (short)(- (short)s)
und sämtliche Varianten.
Bem.: 1. wird vom cap converter nicht akzeptiert.
Rechengesetze (2):
1.
Komplement:
Bitweises Und:
(short)(~s)
(short)(s & t)
= (short)(~(short)s)
= (short)((short)s & t)
2.
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 sämtliche Varianten.
Rechengesetze (3):
Im Allgemeinen (auch für Varianten):
1. (short)(s / t) 6= (short)((short)s / (short)t)
Beispiel: s = 216 , t = 215
2. (short)(s % t) 6= (short)((short)s % (short)t)
Beispiel: s = 2 ∗ 216 − 1, t = 216 − 1
3. (short)(s >> n) 6= (short)((short)s >> n)
Beispiel: s = 215 , n = 1
4. (short)(s >>> n) 6= (short)((short)s >>> n)
Beispiel: s = 215 , n = 1
gilt natürlich, wenn s und t in ein short passen.
Rechengesetze (4):
Im Allgemeinen (auch für Varianten):
1. s < t 6⇔ (short)s < (short)t
2. (short)s == (short)t 6⇒ s == t
aber natürlich s == t ⇒ (short)s == (short)t
⇒ (short)(x + y) == z Cast ist notwendig!
gilt natürlich, wenn s und t in ein short passen.
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 für |, ^ , ~, >>, >>>
2. short x,y,z ⇒ x % y “passt” – Ok!
⇒ (x % y) == z kein Cast notwendig.
Ebenso für /
3. byte x,y ⇒ x + y, x + 127 “passt” – Ok!
⇒ (x + y) == z kein Cast notwendig.
Ebenso für -, *
4. byte x,y,z ⇒ x + y + z, x + 128 “passt” – Fehler!
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)
Kapitel 7: Kryptographie: Grundlagen
•
Nicht: Wie funktioniert Verfahren xyz?
•
Nicht: Warum ist Verfahren xyz sicher?
•
Nicht: Wie funktioniert Verfahren xyz?
•
Nicht: Warum ist Verfahren xyz sicher?
•
Dafür: Wie benutze ich Verfahren xyz?
•
Dafür: Wie kombiniere ich Verfahren zu Protokollen?
Basisoperationen: mathematische Verfahren
Standardkombinationen: Signatur, MAC, blinde Signatur etc.
Eigenschaften: Authentifizierung, Nichtrückweisbarkeit etc.
Kombination: kryptographische Protokolle
Eigenschaften: Fälschungssicher, nicht kopierbar etc.
Unser Interesse: logische (abstrakte) Eigenschaften
Grundbegriffe
•
Cryptography: Lehre“ vom Verschlüsseln
”
Cryptanalysis: Lehre“ vom Code-Knacken
”
Plaintext/Klartext: unverschlüsselter Text
•
Cipher/Chiffre: verschlüsselter Text
•
Alice, Bob: ehrliche Kommunikationsteilnehmer
•
Eve, Mallory: Bösewichte
•
•
Ziele:
1. confidentiality/Vertraulichkeit
Niemand (sonst) kann die Nachricht lesen.
2. authentication/Authentisierung
Der Absender der Nachricht ist der richtige.
3. integrity/Unveränderbarkeit
Die Nachricht wurde nicht modifiziert.
4. nonrepudiation/Nichtrückweisbarkeit
Der Absender kann nicht abstreiten, die Nachricht geschickt zu
haben.
Theorie der Verschlü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 verschlüsselt wird
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/Schlüssel immer Folgen von Bits (Bytes)
Gutes Kryptoverfahren
•
Problem bei ROT13: Wenn Verfahren bekannt:
Jede Nachricht kann entschlüsselt werden.
•
⇒ Verfahren mit einem Schlüssel parametrisieren
•
Die Sicherheit eines Verschlüsselungs- (Krypto-)verfahrens sollte
nur im Schlüssel liegen. (Kerckhoffs)
⇒ Der Algorithmus ist öffentlich.
aber: siehe Geschichte der Enigma in WWII
Gutes Verschlüsselungsverfahren:
Aufgabe: Gegeben Klartext und Chiffre: Finde Schlüssel.
Das effizienteste bekannte Verfahren ist, alle Schlüssel
durchzuprobieren.
Angriffe (1)
•
Entschlüsseln einer Nachricht
⇒ einmaliger Erfolg
•
Finden eines Schlüssels
⇒ potentiell viele Nachrichten entschlüsselbar
•
Fälschen einer digitalen Signatur
Kollisionen bei Hashverfahren finden
u.v.m.
•
Knacken eines Verschlüsselungsverfahrens
Effiziente Möglichkeit, Schlüssel/Klartext zu finden
Angriffe (2)
Angriffe (2)
1. Ciphertext-only attack: Nur verschlüsselte Nachrichten verfügbar.
Angriffe (2)
2. Known-plaintext attack: verschlüsselte Nachrichten und Klartext
verfügbar.
Angriffe (2)
verfügbar.
3. Chosen-plaintext attack: Wie 2., aber Angreifer kann Klartexte
wählen. (Orakel/Blackbox)
Angriffe (2)
verfügbar.
4. Adaptive-chosen-plaintext attack: Wie 3., aber nächster Klartext
kann nach Analyse der vorherigen Ergebnisse gewählt werden.
Angriffe (2)
verfügbar.
5. Chosen-ciphertext attack: verschlüsselte Nachrichten wählbar.
Angriffe (2)
verfügbar.
5. Chosen-ciphertext attack: verschlüsselte Nachrichten wählbar.
6. Rubber-hose cryptanalysis – Bestechung, Erpressung, Überredung,. . .
... Kryptographie allein reicht nicht ...
From: Support webmail
To: [email protected]
Subject: Virus Alert
Fill the columns
below
and send back.
USERNAME:
PASSWORD:
PHONE NUMBER:
BIRTHDAY:
USER ID:
One-time Pads
Gegeben: Plaintext P , #P = n Bytes,
geheimer zufälliger Schlüssel K mit #K = n.
Verschlüsseln: C = EK (P ) = P ⊕ K (XOR)
Entschlüsseln: P = C ⊕ K (C Ciphertext/Chiffre)
One-time Pads
Als einziges Krypto-System absolut sicher
(sofern Schlüssel wirklich zufällig)
One-time Pads
Wichtig: K darf nur einmal verwendet werden!!!
One-time Pads
Wichtig: K darf nur einmal verwendet werden!!!
Sonst: C1 ⊕C2 = (P1 ⊕K)⊕(P2 ⊕K) = (P1 ⊕P2 )⊕(K ⊕K) = P1 ⊕P2
00
47
3E
1E
42
15
04
0D
08
07
4F
0E
00
50
0F
0F
00
1A
48
0B
49
2D
57
07
00
00
07
00
20
0A
50
47
01
0D
00
00
14
0C
02
00
41
18
00
09
16
54
00
09
7B
02
00
00
1D
32
01
0C
48
00
1B
38
00
59
53
08
01
53
54
41
18
45
0C
07
53
38
42
09
48
05
54
0F
1D
0A
07
17
09
05
45
36
08
0C
10
46
00
53
04
45
0F
1B
41
13
00
45
46
00
41
58
13
03
06
0F
17
49
41
20
08
4D
55
1A
55
00
05
02
54
57
06
07
15
21
01
00
07
43
00
07
18
0A
48
00
0F
45
20
00
0D
69
53
1C
41
50
03
0C
53
4E
4D
45
00
00
55
60
0D
45
00
23
07
0A
43
4B
4D
0F
45
55
10
00
06
01
03
46
4E
45
.........EAW..U.
GP....E.FF ..A‘E
>...{8......HP.U
........SAM...E.
B. ..YS..XU!....
...A.S8.E...ES#.
.HP...B...U. N..
..G.2..E.....M..
.I...SH6A..C.ECF
.-...T......i.KN
OW.THAT..IT.S.ME
..
Kapitel 8: Kryptographie: DES
Symmetrische Verschlüsselung (Secret key)
•
Verfahren: DES, Triple-DES, AES, IDEA, Blowfish, . . .
•
1 Schlüssel K für Ver-/Entschlüsselung C = EK (P ), DK (C) = P
•
Meistens: Schlüssellänge = Blocklänge (8, 16, 24, 32, . . . Bytes)
•
Eigenschaften:
Sicherheit liegt nur im Schlüssel
Schlüssel nicht erratbar (auch wenn P und C bekannt sind!)
Verschlüsselung nicht erratbar
Entschlüsselung mit falschem Schlüssel ergibt Unsinn
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 Schlüssellänge, 56 Bit echter Schlüssel ⇒ Blockgröße 8 Byte
•
Eine Runde: Substitution (XOR) + Permutation, 16 Runden
•
Ein Designziel: Jedes Bit der Ausgabe basiert auf jedem Bit der
Eingabe und jedem Schlüsselbit
•
8 magische“ S-Boxen für Substitution
”
Inzwischen unsicher, aber nie geknackt“
”
•
Nie geknackt“: Gegeben: Klartext und Chiffre, gesucht: der Schlüssel.
”
Es ist kein Verfahren bekannt, mit dem man den Schlüssel schneller
findet, als durch systematisches Testen aller Schlüssel.
Schlü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
DES – Eine Runde
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]
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: 214 chosen plaintexts, 29 Verschlüsselungen.
DES mit 16 Runden: 247 chosen plaintexts, 237 Verschlüsselungen.
Schlü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
Schlü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 Schlüsseltests pro Sekunde auf 4 Milliarden
Rechnern = 264 Tests pro Sekunde, 1 Jahr ≈ 225 Sekunden
Schlü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
56 Bit Länge ⇒ 256 Schlüssel
⇒ 4 Millisekunden
Schlü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
⇒ 4 Millisekunden
2112 Schlüssel probieren
⇒ 8388608 Jahre
Schlü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
⇒ 4 Millisekunden
2112 Schlüssel probieren
⇒ 8388608 Jahre
256 Bit Schlüssellänge (AES)
⇒ 1050 Jahre
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
45 bc de 82
07 c6 e6 95
88 a9 f0 2f
52 fd 8a 25
99
01
99
8b
eb
60
ab
9c
e5
d0
b8
53
96
48
7d
8a
4d
46
20
96
47
6f
5a
d2
83
9c
1c
95
a8
ee
b1
b4
70
a0
a4
5c
30
02
6b
2d
23
63
02
bf
c8
7b
3c
70
93
8d
81
ee
98
de
1b
18
cd
bd
89
71
99
96
41
f6
05
2e
c2
e2
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
45 bc de 82
07 c6 e6 95
88 a9 f0 2f
52 fd 8a 25
99
01
99
8b
eb
60
ab
9c
e5
d0
b8
53
96
48
7d
8a
4d
46
20
96
47
6f
5a
d2
83
9c
1c
95
a8
ee
b1
b4
70
a0
a4
5c
30
02
6b
2d
23
63
02
bf
c8
7b
3c
70
93
8d
81
ee
98
de
1b
18
cd
bd
89
71
99
96
41
f6
05
2e
c2
e2
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.“
distributed.net – ca. 100.000 PCs:
At the end of the contest, over 250 billion keys (possible codes
”
for decrypting the encrypted message) were being checked each
second.“
”
second.“
Deep Crack – Spezialrechner für DES (Öffentlich, 250.000 $)
”
second.“
1536 ASICs, 36864 search units, 40 MHz, 16 Takte pro Schlüssel
”
second.“
⇒ 2.5 Millionen Tests pro unit/Sekunde
”
second.“
⇒ 92 Milliarden Tests/Sekunde
”
second.“
⇒ Maximal 9.05 Tage um DES zu knacken!
”
second.“
2010: 68 Stunden (292 Mrd. Tests/Sekunde) mit 128 FPGAs
”
second.“
2010: 68 Stunden (292 Mrd. Tests/Sekunde) mit 128 FPGAs
3DES: 1049229366788527530565065435109369569680144061811429 Jahre!
3DES, DESede
•
Problem bei DES: Schlüssellänge fest
•
3 verschiedene DES Schlüssel K1 , K2 , K3
•
C = EK3 (DK2 (EK1 (P )))
•
•
Doppelt“ so sicher wie DES (22n statt 2n Versuche)
”
Für DES gilt nicht:
Zu K1 , K2 existiert immer K3 mit EK2 (EK1 (P )) = EK3 (P )
•
Variante: Nur 2 Schlüssel ⇒ C = EK1 (DK2 (EK1 (P )))
•
Blocklänge 8 Byte
•
Nachfolger: AES (128, 196 oder 256 Bit Schlüssellänge), FIPS 197
Modes
Was tun, wenn mehr als ein Block verschlüsselt werden soll?
ECB: Electronic Codebook Mode
Jeder Block Text wird separat verschlüsselt
⇒ Gleicher Text mit gleichem Schlüssel gibt gleiche Chiffre
CBC: Cipher Block Chaining
nächsten Block mit vorherigem Verknüpfen:
Ci = EK (Pi ⊕ Ci−1 ), Pi = Ci−1 ⊕ DK (Ci )
Erster Block C0 (IV = initialization vector) beliebig, nicht geheim,
sollte zufällig sein.
Weitere Modes: Cipher Feedback (CFB), Output Feedback (OFB)
⇒ ALG DES ECB NOPAD, ALG DES CBC NOPAD
Padding
Standards zum Auffüllen des Textes auf Vielfache der Blocklänge.
1. NoPadding: Text muss Vielfaches der Blocklänge sein.
2. X9.23, ISO10126-2: Mit Zufallszahlen oder Nullen auffüllen,
letztes Byte enthält Anzahl der Padding-Bytes
3. RFC 1423, PKCS 5: Paddingbyte = # Paddingbytes
4. 0x80 + Null-Bytes
Bei 2./3./4. mindestens 1 Padding-Byte
Angriff auf CBC und PKCS 5
September 2010: New Attack Against ASP.NET: It’s serious“
”
⇒ Auslesen von web.config, Entschlüsseln von Cookies u.a.
Problem: Was tun, wenn Padding nicht stimmt? Fehlermeldung?
”
Gegeben C = EK (P ). Sei r = r1 ..(r8 ⊕ i) zufälliger Block. Teste rC.
”
Falls kein Paddingfehler: P ⊕ r hat korrektes Padding. (1, 22, 333, ...)
”
Teste r1 ..(rj ⊕ 1)..(r8 ⊕ i)C für (j = 1..7).
Alle fehlerhaft: letztes Byte P8 = r8 ⊕ 1, sonst r8 ⊕ j
”
Teste r1 ..(rj ⊕ 1)..(r8 ⊕ i)C für (j = 1..7).
Alle fehlerhaft: letztes Byte P8 = r8 ⊕ 1, sonst r8 ⊕ j
Byte 7: Teste r1 ..r6 (r7 ⊕ i)(P8 ⊕ 2)
usw.
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 Schlüssels:
javax.crypto.KeyGenerator keygen
= javax.crypto.KeyGenerator.getInstance("DESede",
cryptProvider);
keygen.init(192);
cryptProvider);
keygen.init(192);
cryptProvider);
javax.crypto.SecretKey key = keygen.generateKey();
keygen.init(192);
cryptProvider);
javax.crypto.SecretKey key = keygen.generateKey();
3. Ausdrucken“ des Schlüssels:
”
swt.util.HexString.printReadable(key.getEncoded());
Kodierung: RAW (Bytearray = Schlüssel)
4 Einlesen“ des Schlüssels:
”
private final static byte[] desede key = {...};
”
javax.crypto.SecretKeyFactory sessionkf
= javax.crypto.SecretKeyFactory.getInstance("DESede",
cryptProvider);
”
javax.crypto.SecretKeyFactory sessionkf
= javax.crypto.SecretKeyFactory.getInstance("DESede",
cryptProvider);
javax.crypto.SecretKey the key
= sessionkf.generateSecret(
new javax.crypto.spec.DESedeKeySpec(desede key));
1. Verschlü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. Entschlüsseln:
cip.init(javax.crypto.Cipher.DECRYPT MODE, the key);
byte[] dec = cip.doFinal(enc);
Kryptographie in JavaCard: DESede (1)
1. Imports:
import javacard.security.*;
import javacardx.crypto.*;
2. Initialisieren des Schlüssels:
DESKey key = (DESKey)KeyBuilder.buildKey(
KeyBuilder.TYPE DES,
KeyBuilder.LENGTH DES3 3KEY,
false);
key.setKey(desede key, (short)0);
Cipher cip =
Cipher.getInstance(Cipher.ALG DES ECB NOPAD,false);
Allokiert Speicher ⇒ nur im Konstruktor!
3. Verschlüsseln:
cip.init(key, Cipher.MODE ENCRYPT);
cip.doFinal(buffer, ISO7816.OFFSET CDATA, (short)8,
buffer, ISO7816.OFFSET CDATA);
4. Entschlü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)
•
doFinal gibt Länge des verschlüsselten Text zurück
•
No padding: Länge muss Vielfaches der Blockgröße sein
⇒ Ausgabelänge = Eingabelä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)
Kapitel 9: Nonces und Hashes
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)
•
In ME poetry used as a metrical tag or stop-gap, with no special
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
Zufallszahlen (1)
•
Nonces, random numbers
•
Echte (physikalische) Generatoren (indeterministisch)(?)
teuer, groß, problematisch
Zufallszahlen (1)
•
Nonces, random numbers
•
Echte (physikalische) Generatoren (indeterministisch)(?)
teuer, groß, problematisch
Zufallszahlen (2)
•
In Software: Pseudo-Zufallszahlengeneratoren (PRNGs)
zufällige/geheime Initialisierung (seed), dann deterministisch
•
für Kryptographie: zusätzliche Anforderungen
•
z. B. auf DES + MD5 basierend mit geheimem Schlüssel
•
FIPS 186-2, ANSI X9.31, ANSI X9.62-1998
Zufallszahlen (3)
Eigenschaften:
•
sieht zufällig aus
Gleichverteilung der Werte
statistische Analyse zeigt keine Korrelation
•
nicht vorhersagbar
Nächster Wert nicht vorhersagbar, auch wenn alle bisherigen Werte
bekannt
Zufallszahlen (4)
Wenn lang genug (z.B. ≥ 8 Byte, 264 = 18446744073709551616 Werte)
⇒ Zahl nicht erratbar
⇒ Wä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 Schlüssel bekannt wird.
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 215 Seed-Werte für OpenSSL PRNG
Mai 2008: Problem wird entdeckt
Ergebnis: Alle so erzeugten (SSL/SSH host) keys sind erratbar, d. h.
der private key bekannt!
Kryptographische Hashfunktionen
•
Verfahren: MD5, SHA-1, RIPEMD, SHA-512, . . .
•
Hashfunktion H (bel. lange Eingabe, Hashwert 128 Bit, 160 Bit)
•
Einwegfunktion, kein effizientes Verfahren für H −1 (bekannt)
•
Ähnliche Texte ⇒ unähnliche Hashwerte
(1 Bit in M ändern ⇒ > 64 Bit in h(M ) geändert)
•
Eigenschaften:
h = H(M ) leicht berechenbar, H −1 schwierig (unmöglich)
Gegeben M : Schwierig M ′ mit H(M ) = H(M ′ ) zu finden
Schwierig, M, M ′ mit H(M ) = H(M ′ ) zu finden
•
Symmetrische Verschlüsselung mit CBC nicht gut genug
•
Bruce Schneier (1996): I am wary of using MD5“
”
MD5 - Kollision
d1
12
83
80
dd
0f
96
31
46
e4
37
53
57
f9
dd
7e
88
3c
e2
7e
65
02
ab
83
5b
b4
e8
2b
c5
40
25
d8
87
ce
6f
e6
04
71
82
da
54
f7
ee
58
41
3e
03
b6
2a
c4
3e
5a
31
fd
70
70
69
b8
08
56
02
80
3d
fb
51
34
39
a8
9a
7f
25
8f
63
0d
06
89
e8
5b
06
1e
98
55
f7
ae
d2
c6
af
ad
cd
6d
48
98
f9
34
c9
ac
cd
21
5c
06
9f
d4
a0
bc
2f
09
d9
36
e9
b6
ca
f4
1d
c9
9f
a8
b5
b3
bd
19
33
83
87
02
f2
c6
42
93
d1
12
83
80
dd
0f
96
31
46
e4
37
53
57
f9
dd
7e
88
3c
e2
7e
65
02
ab
83
5b
34
e8
ab
c5
40
25
d8
87
ce
6f
e6
04
f1
82
da
54
f7
ee
58
41
3e
03
b6
2a
c4
3e
5a
31
fd
70
70
69
b8
08
56
02
80
3d
fb
51
34
39
28
9a
7f
25
8f
63
0d
06
89
e8
5b
06
1e
98
55
f7
ae
d2
c6
af
ad
cd
6d
48
98
f9
34
c9
ac
cd
21
5c
06
9f
d4
a0
bc
2f
09
d9
36
e9
b6
ca
f4
1d
c9
9f
a8
b5
b3
bd
19
33
83
07
02
72
c6
42
93
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
Anhängen von Bytes am Ende der Dateien).
2008: Alexander Sotirov, Marc Stevens und Jacob Appelbaum: Fälschen
von Zertifikaten (einer Zertifizierungsstelle)
15 Februar 2005: Bruce Schneier
SHA-1 has been broken. Not a reduced-round version. Not a simplified
”
version. The real thing.“
•
Findet Kollisionen mit 263 statt 280 Versuchen.
•
Keine Hashfunktion hat 10 Jahre gehalten . . . “
”
15 Februar 2005: Bruce Schneier
SHA-1 has been broken. Not a reduced-round version. Not a simplified
”
version. The real thing.“
•
Findet Kollisionen mit 263 statt 280 Versuchen.
Keine Hashfunktion hat 10 Jahre gehalten . . . “
”
November 2007: NIST schreibt SHA-3 Wettbewerb aus
•
31.10.2008: 64 Einreichungen
2010: noch 14 übrig
Entscheidung 2012 geplant
Hashwerte: Anwendungen
•
als Einwegfunktion:
speichere Hash(Passwort) statt Passwort (Unix)
•
als Schutz vor trojanischen Pferden:
speichere Hash(file) separat von file (CD-RO),
prüfe täglich (tripwire)
Hashwerte bei Kommunikation
•
als Schutz vor Übertragungsfehlern: sende Daten + Hash(Daten)
•
als Schutz vor bö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))
Message Authentication Code (MAC)
•
Zwei Parteien, beide kennen gemeinsamen Secret Key K
•
MAC = EK (H(P )), verschickt wird P + MAC, oder
•
Verschlüssele P mit 3DES im CBC Mode, MAC ist letzter Block
(ALG DES MAC8 NOPAD), oder fü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 während der Übertragung nicht modifiziert.
Nur wer K kennt, kann MAC überprüfen.
Zufallszahlen und Hashen in Java
class java.security.SecureRandom
•
rand = new java.security.SecureRandom();
•
rand.nextBytes(byte array);
Füllt byte array mit zufälligen Werten.
class MessageDigest
•
md = MessageDigest.getInstance("SHA1",cryptProvider);
•
Hashwert berechnen:
byte[] digest(byte[] input)
Zufallszahlen und Hashen in JavaCard
class RandomData
•
rand = RandomData.getInstance(RandomData.ALG SECURE RANDOM);
•
setSeed: Initialisierung des Generators – unnö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)
Kapitel 10: Kopierkarte – Protokolle
Aufgabe: Design einer Karte, die Punkte speichert
Anforderungen:
1. Schutz vor gefälschten Karten
2. Schutz vor unauthorisiertem Laden von Punkten
3. kein Schutz vor technischem Equipment (zweiter Chip, Signalleitungen, . . . ) – oder doch?
4. nur symmetrische Verschlüsselung
Wie sehen Protokolle aus?
Lösung Nr. 1
Laden
Abbuchen
T→C
load + n
C→T
ok
T→C
pay + n
C→T
ok
Lösung Nr. 1
Laden
Abbuchen
T→C
load + n
C→T
ok
T→C
pay + n
C→T
ok
Unsicher!
Lösung Nr. 1
Laden
Abbuchen
T→C
load + n
C→T
ok
T→C
pay + n
C→T
ok
Unsicher!
Jeder kann Punkte auf eine echte Karte laden!
Lösung Nr. 1
Laden
Abbuchen
T→C
load + n
C→T
ok
T→C
pay + n
C→T
ok
Unsicher!
Jeder kann Punkte auf eine echte Karte laden!
Man kann mit einer gefälschten Karte bezahlen!
Lösung Nr. 2
Laden
Abbuchen
T→C
load + Passphrase1 + n
C→T
ok
T→C
pay + n
C→T
hash(Passphrase2)
Lösung Nr. 2
Laden
Abbuchen
T→C
C→T
ok
T→C
pay + n
C→T
hash(Passphrase2)
Unsicher!
Lösung Nr. 2
Laden
Abbuchen
T→C
C→T
ok
T→C
pay + n
C→T
hash(Passphrase2)
Unsicher!
Passphrase1 kann mit gefälschter Karte protokolliert werden!
Lösung Nr. 2
Laden
Abbuchen
T→C
C→T
ok
T→C
pay + n
C→T
hash(Passphrase2)
Unsicher!
Passphrase1 kann mit gefälschter Karte protokolliert werden!
hash(Passphrase2) kann ausgelesen werden!
Gefordert: Authentisierung von Terminal und Karte
Situation: Alice will wissen, dass Bob echt ist.
⇒ Bob muss beweisen, dass er ein Geheimnis (jetzt) kennt.
⇒ Bob muss beweisen, dass er ein Geheimnis (jetzt) kennt.
⇒ Das Geheimnis muss dabei geheim bleiben.
Lösung Nr. 3
T und C kennen geheimen Schlüssel K
Laden
Abbuchen
T→C
load + ES (K)[Passphrase1] + n
C→T
ok
T→C
pay + n
C→T
ES (K)[hash(Passphrase2)]
Lösung Nr. 3
Laden
Abbuchen
T→C
C→T
ok
T→C
pay + n
C→T
Unsicher! – Replayattacke!
Lösung Nr. 3
Laden
Abbuchen
T→C
C→T
ok
T→C
pay + n
C→T
ES (K)[Passphrase1] kann protokolliert werden!
Lösung Nr. 3
Laden
Abbuchen
T→C
C→T
ok
T→C
pay + n
C→T
ES (K)[Passphrase1] kann protokolliert werden!
ES (K)[hash(Passphrase2)] kann ausgelesen werden!
Lösung Nr. 4
T und C kennen geheimen Schlüssel K, N1 , N2 sind Zufallszahlen
(Random numbers, nonces)
Laden
Abbuchen
T→C
load + ES (K)[Passphrase1 + N1 ] + n
C→T
ok
T→C
pay + n
C→T
ES (K)[hash(Passphrase2 + N2 )]
Lösung Nr. 4
Laden
Abbuchen
T→C
C→T
ok
T→C
pay + n
C→T
Lösung Nr. 4
Laden
Abbuchen
T→C
C→T
ok
T→C
pay + n
C→T
ES (K)[Passphrase1 + N1 ] kann protokolliert werden!
Lösung Nr. 4
Laden
Abbuchen
T→C
C→T
ok
T→C
pay + n
C→T
ES (K)[Passphrase1 + N1 ] kann protokolliert werden!
ES (K)[hash(Passphrase2 + N2 )] kann ausgelesen werden!
Prinzip: Challenge – Response
T und C kennen geheimen Schlüssel K, N ist eine Zufallszahl
Challenge
T→C
N
Response
C→T
ES (K)[N ]
Terminal entschlüsselt Antwort mit K und vergleicht mit N .
Wenn N neu ist (noch nie verwendet wurde), wird Replay verhindert.
Kapitel 11: Authentisierungsprotokolle
Wide-Mouth Frog (Burrows)
S: (Authentisierungs-)Server, Ta , Ts Zeitstempel
Kas , Kbs geheime Schlüssel (zwischen A und S bzw. B und S),
Kab Sessionkey
1.
A → S:
A, {Ta , B, Kab }Kas
2.
S → B:
{Ts , A, Kab }Kbs
Otway-Rees Protokoll (1987)
S: (Authentisierungs-)Server, M, Na , Nb Nonces
Kab Sessionkey
1.
A → B:
M, A, B, {Na , M, A, B}Kas
2.
B → S:
M, A, B, {Na , M, A, B}Kas , {Nb , M, A, B}Kbs
3.
S → B:
M, {Na , Kab }Kas , {Nb , Kab }Kbs
4.
B → A:
M, {Na , Kab }Kas
Yahalom Protokoll (1988)
S: (Authentisierungs-)Server, Na , Nb Nonces
Kab Sessionkey
1.
A → B:
A, Na
2.
B → S:
B, {A, Na , Nb }Kbs
3.
S → A:
{B, Kab , Na , Nb }Kas , {A, Kab }Kbs
4.
A → B:
{A, Kab }Kbs , {Nb }Kab
Needham-Schroeder (1978)
mit geheimen (symmetrischen) Schlüsseln
1.
A → S:
A, B, Na
2.
S → A:
{Na , B, Kab , {Kab , A}Kbs }Kas
3.
A → B:
{Kab , A}Kbs
4.
B → A:
{Nb }Kab
5.
A → B:
{Nb − 1}Kab
Problem: Nachricht 3 könnte ein Replay sein.
Kerberos
vom MIT (Miller et. al. 1987)
Ts , Ta Zeitstempel, L Lebensdauer
1.
A → S:
A, B
2.
S → A:
{Ts , L, Kab , B, {Ts , L, Kab , A}Kbs }Kas
3.
A → B:
{Ts , L, Kab , A}Kbs , {A, Ta }Kab
4.
B → A:
{Ta + 1}Kab
SmartCard Anwendungen
Bequemlichkeit
Authentisierung
Krankenkassendaten
Kreditkarte
Geheimnisse
E-Cash
SIM (Handy)
D-Box (Pay-TV)
Geldkarte
Unveränderbar
Personalausweis
Schutz vor Mißbrauch
Studentenausweis
Digitale Signatur
Führerschein
Konzentration auf Anwendungsanbieter und Kartenhalter:
Mehrseitige Sicherheit
gleiche / unterschiedliche / widersprechende Interessen
Spezialität von Smartcard-Anwendungen:
•
Kartenhalter ist potenziell feindlich
•
Karte hat Geheimnisse, die Halter nicht kennen/manipulieren darf
•
Beschränkte Ressourcen!
Besonderheiten bei Smartcards
1. Beschränkte Ressourcen: Oft nur 3DES und Zufallszahlen
2. langsame Datenübertragung
3. Kartenhalter als Angreifer: Unbeschränkter Zugriff auf die Karte
4. Kommunikation Karte/Leser kann physikalisch geschü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
Angreifermöglichkeiten berücksichtigen
Sichere Kommunikation mit der Smart Card
Grundlage: ISO 7816-4, EMV, Openplatform, etc.
1. Gegenseitige Authentisierung (mutual authentication)
2. Integritä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 für Command APDU spezifiziert.
Mutual Authentication (Prinzip)
Terminal
Generate host
Karte
→ Initialize Update →
challenge
Generate card challenge
Generate session keys
← answer ←
Calculate card cryptogram
Generate session keys
Verify card cryptogram
Calculate host
cryptogram
→ External
Authenticate →
Verify host cryptogram
← answer ←
Smard Card Schlüssel
1. Globaler Master-Schlüssel MK
2. statischer Kartenschlüssel für gegenseitige Authentisierung und
Verschlüsselung (von MK abgeleitet)
3. statischer Kartenschlüssel für MAC (von MK abgeleitet)
4. statischer Kartenschlüssel für key encryption (von MK abgeleitet)
5. Pro Session: MAC-Schlüssel (aus Challenges abgeleitet)
6. Pro Session: Encryption Schlüssel (aus Challenges abgeleitet)
Alle Schlüssel 16 Byte (3DES mit 2 Schlüsseln)
Mutual Authentication (APDUs)
1. Initialize Update: Schlüsselnr. + Zufallszahl N1
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 verfügbarer)
Antwort:
43 4D
61 FF 21 57 F4 07 17 11
0D 01
F5 2D 82 9E AA CA E9 BB
3B 34 BD 49 BA 6C 8C 2F
90
(diversification data)
(Schlüsselnummer)
(Kartenzufallszahl N2 )
(card cryptogram)
00
2. External Authenticate
84
82
00
00
10
B9 B0 40 11 79 C7 07 10
A1 35 A7 21 C6 10 D7 C7
(Sicherheitsstufe)
(host cryptogram)
(APDU MAC)
P1: Security Level
00 = no secure messaging
01 = MAC
03 = encryption and MAC
Kryptogramme
1. D = N1 + N2 + 0x80 00 00 00 00 00 00 00
2. verschlüssele D mit 3DES/CBC, IV = 0x00 00 00 00 00 00 00 00
3. cryptogram = letzter Block (letzten 8 Byte)
card cryptogram: N1 = host challenge, N2 = card challenge
host cryptogram: N1 = card challenge, N2 = host challenge
APDU MAC:
Bilde MAC über APDU-Header + Daten, hänge MAC an Daten an.
⇒ Nachricht unverändert (Message Integrity)
Für nächste Nachricht: alte MAC ist IV (CBC mode!) für neue MAC
⇒ Reihenfolge ok, keine Nachricht fehlt
Cryptogram: Im Prinzip eine MAC
APDU Verschlüsselung
Daten verschlüsseln ⇒ Message Data Confidentiality
(APDU-Header und MAC nicht verschlüsselt)
Schlüssel: werden bei Authentisierung erzeugt.
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
Schlüssel
Key Diversification: Berechne Schlüssel fü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 (enthält Seriennummer)
n
⇒ D1,2,3
(aus D n generiert)
Statische Kartenschlüssel
⇒ K1n für Authentisierung/Verschlüsselung
⇒ K2n für APDU MACs
⇒ K3n für key encryption
Kin = EncM K (Di L) + EncM K (Di R), Di = Di L + Di 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, SKi = EncKi (DD)
Neuer Reisepass (1)
Protokoll:
1. Optischer Scan des Passes ⇒ secret master key Kp
2. T → C: Get Nonce
3. C → T: N1
4. T → C: {N1 , N2 , SL }Kp (N2 eigene Nonce, SL halber Session key)
5. C → T: {N2 , N1 , SR }Kp
6. Session key (MAC und Encryption): SL + SR
Neuer Reisepass (2)
Sicherheit:
•
Session key: 3DES mit zwei Schlüsseln
•
Kp = Hash(Passnummer, Geburtsdatum, Ablaufdatum Pass)
•
⇒ 109 ∗ (365 ∗ 102) ∗ (365 ∗ 10) ≈ 2 ∗ 256 Schlüssel
•
⇒ entspricht einfachem DES(!)
•
Mit Fingerabdrücken: Public-Key-Kryptographie
Kapitel 12: Kryptographie: RSA
Asymmetrische Verschlüsselung (Public key)
•
Verfahren: RSA, Elliptische Kurven, (ElGamal)
•
1 öffentlicher Schlüssel P u (public key)
•
1 privater Schlüssel P r (private key)
•
blockorientiert (1024 Bit, . . . )
•
Eigenschaften:
DP r (EP u (P )) = P, DP u (EP r (P )) = P
P r nicht erratbar, P u darf jeder kennen
Entschlüsselung mit falschem Schlüssel ergibt Unsinn
RSA (Rivest, Shamir, Adleman) 1978
Wähle große Primzahlen p, q(p 6= q), sei n = pq.
Wähle e mit ggT(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
Schlüssel-/Blocklänge: # bits von n, 1024 Bits = 128 Byte
Verschlüsseln: C = P e mod n, Entschlüsseln: P = C d mod n
In Java: n BigInteger
Sicherheit: Faktorisierung großer Zahlen (unbewiesene Vermutung)
Anzahl Primzahlen der Länge 1024 Bit
12651307410331561612287515175386710353237098956273445646466036883594
00015944240673886333579519658615644189346781192373999743611737189907
91007698881506790641087948193858955233664549746019822494536141699553
95044903323238520381291863113009513502941611543079003335131774527967
6977211484011404917064419380394375
12651307410331561612287515175386710353237098956273445646466036883594
00015944240673886333579519658615644189346781192373999743611737189907
91007698881506790641087948193858955233664549746019822494536141699553
95044903323238520381291863113009513502941611543079003335131774527967
6977211484011404917064419380394375
(ca.)
RSA Challenges (inzwischen zurückgezogen)
Name:
RSA-576
Prize:
$10000
Digits:
174
Digit Sum:
785
1881988129206079638386972394616504398071635633794173827007\
6335642298885971523466548531906060650474304531738801130339\
6716199692321205734031879550656996221305168759307650257059
Veröffentlicht 2001, gelöst am 3.12.2003: The factors are
3980750864240649373971255005503864911990643623425267084063\
85189575946388957261768583317
and
4727721461074353025362230719730482246329146953020971164598\
52171130520711256363590397527
Name:
RSA-2048
Prize:
$200000
Digits:
617
Digit Sum:
2738
2519590847565789349402718324004839857142928212620403202777\
7137836043662020707595556264018525880784406918290641249515\
0821892985591491761845028084891200728449926873928072877767\
3597141834727026189637501497182469116507761337985909570009\
7330459748808428401797429100642458691817195118746121515172\
6546322822168699875491824224336372590851418654620435767984\
2338718477444792073993423658482382428119816381501067481045\
1660377306056201619676256133844143603833904414952634432190\
1146575444541784240209246165157233507787077498171257724679\
6292638635637328991215483143816789988504044536402352738195\
1378636564391212010397122822120720357
12.12.2009: RSA-768 gelö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 Signaturge”
setz und der Signaturverordnung“ vom 6.1.2010: Minimale Schlüssellängen:
Zeitraum
Länge
bis Ende
bis Ende
bis Ende
bis Ende
bis Ende
2007
2008
2009
2010
2016
1024
1280
1536
1728
1976
Eigenschaften von RSA
RSA hat erwünschte und unerwünschte mathematische Eigenschaften.
Beispiel:
•
17.3.2003: Timing-Angriff (Analyse der Rechenzeit) auf OpenSSL,
um geheimen RSA server key zu finden.
Lösung: RSA blinding:
Berechne x = r e ∗ C mod n (r Zufallszahl)
P = xd /r mod n
Da r zufällig: Rechenzeit zufällig.
Angriff auf RSA:
1. Eve hört C (mit public key von Alice verschlüsselt), und möchte
den Klartext P = C d .
2. Vorgehen: Eve wählt r < n zufä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 erhält u = y d mod n ⇒ t ∗ u mod n = r −1 y d mod n =
r −1 ∗ C d ∗ xd mod n = P (da x = r e mod n ⇒ r = xd mod n)
Moral: Never use RSA to sign a random document presented to you
”
by a stranger.“ ⇒ Richtige Verwendung wichtig!
RSA-Verschlüsselung: PKCS#1
Problem: ALG RSA NOPAD – unsicher
⇒ ALG RSA PKCS1 oder Padding selbst programmieren
⇒ ALG RSA PKCS1 oder Padding selbst programmieren
PKCS#1: RSA Encryption Standard (RSA Data Security, 1993)
1. Sei D die zu verschlüsselnde Bytefolge, #D ≤ k−11, k Schlüssellänge
2. Bilde encryption block: EB = 0x00 + BT + PS + 0x00 + D
BT: block type, 0x02 für public key encryption
PS: padding string, Pseudozufallszahlen 6= 0x00
3. Wandle EB in Zahl x, berechne y = xd mod n,
wandle y in Bytefolge ⇒ verschlüsselte Daten
Anmerkungen
•
Führendes 0-Byte garantiert EB < n
•
Block type 0x00, 0x01 für private key encryption (Signatur)
•
Darstellung ist eindeutig, da 0x00 6∈ PS
•
PS sollte jedesmal neu generiert werden
•
Security Condition: # PS ≥ 8 (Durchprobieren aller EBs unmöglich)
•
Problem: Es ist mit akzeptabler Wahrscheinlichkeit möglich, Texte
zu generieren, die sich ordentlich entschlüsseln lassen.
⇒ chosen-ciphertext attack möglich.
•
Version 1.5 von 1993, aktuell Version 2.1 vom 14.6.2002, OAEP:
Optimal Asymmetric Encryption Padding
OAEP: Optimal Asymmetric Encryption Padding
Sicher gegen adaptive chosen-ciphertext attacks.
P Plaintext, Bilde initiales Padding D = 0x00k + 0x01 + P
Verschlüssele: (D ⊕ G(r)) + (r ⊕ H(D ⊕ G(r)))
r Zufallszahl, H Hashfunktion, G Generatorfunktion
Generatorfunktion: Hashfunktion, die eine Eingabe auf eine bestimmte
Länge aufbläht, z. B: G(r) = H(r1 ) + H(r2 ) + . . . + H(rn ), ri = r + i
Nach Entschlü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).
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
RSA Schlü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"
Schlüssellänge: 1024 Bit ⇒ Modulus hat genau 128 Bytes
Schlü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.
•
Schlüssel können so ausgetausch werden.
•
Schlüssel können nicht per serialize abgespeichert werden.
•
Richtig wäre: Verwendung eines KeyStore (oder einer SmartCard,)
•
Für JavaCard: gebraucht werden Modulus und Exponent
RSA Schlüssel für JavaCard
Ausgangspunkt: RSA Schlü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
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
•
Länge mod array = 129 ⇒ führendes 0x00-Byte abschneiden!
•
Länge private exponent ≤ 128 Bytes
•
Länge priv exp = 129 ⇒ führendes 0x00-Byte abschneiden!
Schlü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));
RSA Verschlüsselung in Java
Cipher cip = Cipher.getInstance("RSA/NONE/PKCS1PADDING",bcp);
Verschlüsselung:
PublicKey pub_key;
cip.init(javax.crypto.Cipher.ENCRYPT_MODE,pub_key);
cip.doFinal ...
Entschlüsselung:
PrivateKey priv_key;
cip.init(javax.crypto.Cipher.DECRYPT_MODE,priv_key);
cip.doFinal ...
Achtung:
•
Immer nur mit dem public key verschlüsseln
•
Immer nur mit dem private key entschlüsseln
RSA Schlü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);
RSA Verschlüsselung in JavaCard
Cipher rsacip = Cipher.getInstance(Cipher.ALG RSA NOPAD,false);
Cipher rsacip = Cipher.getInstance(Cipher.ALG RSA PKCS1,false);
Verschlüsselung:
rsacip.init(rsa_pub_key, Cipher.MODE_ENCRYPT);
rsacip.doFinal(...);
Entschlüsselung:
rsacip.init(rsa_priv_key, Cipher.MODE_DECRYPT);
rsacip.doFinal(...);
RSA Schlü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.
Kapitel 13: Die elektronische Bahnfahrkarte
Aufgabe: Bau eines Demonstrator
Ziel: Demonstration, dass eine elektronische Fahrkarte
•
keine Nachteile gegenüber einer Papierfahrkarte hat,
•
geringe Investitionskosten erfordert,
•
zur Kostenreduktion beitragen kann,
•
Vorteile für den Kunden bringt.
Realisierung: mit anonymer/multiapplikativer SmartCard
Anforderungen
1. Kauf der Fahrkarte per Internet und per Automat
2. Fahrkarte ist anonym, nicht an einen Zug/Platz gebunden
3. Kontrolle offline möglich
4. Rückgabe von Fahrkarten per Internet/Automat
5. Übertragen von Tickets
Nachteile Online-Ticket (Papier)
1. Kontrolle sehr aufwendig
2. Personengebunden (Kreditkarte oder Bahncard)
3. Mehrfachbenutzung wird erst nachträglich erkannt
Anforderungen Heim-PC
1. Anzeige der auf der Karte befindlichen Tickets
2. Löschen von Tickets
3. Kauf eines Tickets über das Internet
4. Schutz vor Verbindungsabbruch ⇒ Kauf wiederaufsetzbar
5. Rückgabe eines Tickets über das Internet
6. Übertragen des Tickets auf eine andere Karte
Anforderungen Kontrolle im Zug
1. Schaffner mit Lesegerä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. Hinzufügen einer Kontrollmarkierung. Mehrfachkontrolle soll möglich sein.
5. Kontrolle offline, d. h. ohne Zugriff auf irgendeinen Server
6. Mehrfachbenutzung, falsche Benutzung (falsche Strecke, nach Ablauf der Gültigkeit) wird erkannt.
Anforderungen allgemein
1. Fälschen, Manipulieren, Kopieren von Tickets unmöglich.
Designprinzip: Ticket auf der Smartcard ist echt, nicht kopierbar,
nicht manipulierbar.
2. Ist eine Karte kompromittiert, so dürfen nicht alle Karten betroffen
sein.
3. Sicherheit des Karteninhabers wichtig fü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 abhören,
manipulieren, unterdrücken, umleiten, gleichzeitig mehrere Sessions parallel betreiben . . .
5. einfache Fahrt, Rückfahrticket, Dauerticket
6. Maximal 10 Tickets speicherbar
7. Tickets nicht an einen Zug oder einen Platz gebunden
8. möglichst wenig personenbezogenen Daten speichern (außer zur
Abwicklung der Bezahlung/Erstattung).
Ihre Entscheidungen
1. Tarifsystem, Gültigkeit der Tickets
2. Seriennummern SmartCard/Ticket?
3. Wieviel Schutz des Kunden vor Dummheit/Bösartigkeit (Dritter)?
Frage: Wird ein symmetrisches Verschlüsselungsverfahren ausreichen?
Antwort: Nein. Die Anforderungen sind nur mit einem asymmetrischen
Verfahren erfüllbar. Verwenden Sie verschiedene Schlüssel + Zertifikate.
Frage: Wie kann das Terminal kontrollieren, ob ein Ticket für diese
Fahrt gültig ist?
Antwort: Es ist völlig ausreichend das Ticket auf dem Terminal darzustellen. Der Schaffner entscheidet dann, ob das Ticket fü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 . . .
Kapitel 14: Weitere kryptographische
Verfahren
Schlüsselaustausch
•
Verfahren: Diffie-Hellman (1976)
•
Pr(A) und Pu(B) ⇒ symmetrischer Schlüssel K
•
Pr(B) und Pu(A) ⇒ symmetrischer Schlüssel K
•
Pr(A) = x, Pr(B) = y, Pu(A) = g x mod n, Pu(B) = g y mod n
⇒ K = P u(A)y mod n = P u(B)x mod n
•
Für jedes Paar ergibt sich anderes K
•
Sicherheit: diskreter Logarithmus (n große Primzahl, g Generator)
•
Auch mit elliptischen Kurven
Symmetrische Stromverschlüsselung (Secret key)
•
Verfahren: RC4, A5, . . .
•
1 (initialer) Schlüssel K für Ver-/Entschlüsselung
•
stromorientiert:
Datenstrom d1 , d2 , d3 , . . .
separater Schlüsselstrom k1 , k2 , k3 , . . .
Verschlüsselung: d1 ⊕ k1 , d2 ⊕ k2 , d3 ⊕ d3 , . . .
•
schneller und einfacher als Blockchiffren
•
Anwendung: GSM, WLAN, . . .
RC4
•
1987 von Ron Rivest für RSA entwickelt
RC4
•
•
7 Jahre lang geheim, 1994 anonym im Internet
RC4
•
•
Aktueller Schlüssel: 256 Byte S0 , . . . , S255 , nächstes Schlüsselbyte kn :
i = (i + 1) mod 256; j = (j + Si ) mod 256;
swap Si and Sj ; t = (Si + Sj ) mod 256; kn = St
RC4
•
•
Aktueller Schlüssel: 256 Byte S0 , . . . , S255 , nächstes Schlüsselbyte kn :
i = (i + 1) mod 256; j = (j + Si ) mod 256;
swap Si and Sj ; t = (Si + Sj ) mod 256; kn = St
Initialisierung:
1. S0 = 0, S1 = 1, . . . , S255 = 255
2. Array K0 , . . . , K255 mit (initialem) Schlüssel (evtl. wiederholen)
3. j = 0; for i = 0 to 255:
{ j = (j + Si + Ki ) mod 256; swap Si and Sj ; }
Digitale Signatur
•
Verfahren: RSA, DSA (digital signature algorithm)
•
Gegeben: Text P , privater Schlüssel P r, Hashfunktion H
•
signieren: SigP r (P ) = EP r (H(P )), verschickt wird: P + SigP r (P )
•
verifizieren: DP u (SigP r (P )) = H(P )
•
ALG RSA SHA PKCS1
•
Eigenschaften:
?
Signatur muss von einer Person stammen, die P r kennt.
⇒ Nichtrückweisbarkeit
Jeder kann Signatur verifizieren (überprüfen), da P u öffentlich.
Digitale Signatur mit RSA
M zu signierende Message beliebiger Lä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)
Signaturprüfung:
1. Berechne D wie oben
2. Berechne D ′ = S e mod n (e public key)
3. Prüfe D = D ′
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.
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
Signaturprüfung:
1. Berechne w = s−1 mod q, u1 = (D ∗ w) mod p, u2 = (r ∗ w) mod q
2. Berechne v = ((g u1 ∗ y u2 ) mod p) mod q
3. Prüfe v = r?
Message Authentication Code (MAC)
•
Zwei Parteien, beide kennen gemeinsamen Secret Key K
•
MAC = EK (H(P )), oder
•
Verschlüssele P mit 3DES im CBC Mode, MAC ist letzter Block,
oder
•
MAC(text) = HMAC(K, text) = H((K0 ⊕opad)||H((K0 ⊕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.
Nur wer K kennt, kann MAC überprüfen.
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)
Signaturen in JavaCard
class Signature
•
digitale Signatur: ALG RSA SHA PKCS1
1. Berechne Hashwert mit SHA-1 (Eingabe beliebig lang)
2. Fülle Hashwert mit PKCS1 Padding auf
3. Verschlüssele mit privatem RSA Schlüssel
•
MAC: ALG DES MAC4 NOPAD, ALG DES MAC8 NOPAD
1. Verschlü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);
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)
Challenge/Response (Authentisierung)
•
A → B: N Challenge (N Nonce)
•
B → A: SigP r (N ) Response, oder
B → A: EK (N ), oder
B → A: EK (H(N ))
•
Eigenschaften:
B kennt ein Geheimnis (P r oder K)
B kennt das Geheimnis jetzt (N ist neu)
•
Risiko: N könnte verschlüsselter Text sein!
Zertifikate
Problem: Woher weiß man, dass P uA auch A gehört?
•
Zuordnung Person zu Public Key P u
•
trusted third party mit privatem Schlüssel T P r
•
Jeder kennt T P u
•
Zertifikat = SigT P r (A + P uA )
•
Bei Smartcards: Jede Karte mit eigenem Schlüssel, vom Anwendungsanbieter zertifiziert.
Zertifikathierarchie
R
zz
z
|z
z
DD
DD
D"
A1
zz
z
z
}z
B1
zz
z
z
}z
C1
DD
DD
DD
DD
!
...
Am
DD
zz
DD
z
z
DD
D! }zzz
...
DD
DD
D!
Bn
zz
z
zz
z
z
}z
DD
DD
D!
...
Cx
Wissen der Teilnehmer
•
R : P rR , P u R
•
A1 : P rA1 , P uA1 , SigR (A1 + P uA1 ), P uR
•
B1 : P rB1 , P uB1 , SigA1 (B1 +P uB1 ), P uA1 , SigR (A1 +P uA1 ), P uR
•
C1 : P rC1 , P uC1 , SigB1 (C1 + P uC1 ), P uB1 , SigA1 (B1 + P uB1 ),
P uA1 , SigR (A1 + P uA1 ), P uR
⇒ Zertifikatliste
[P uC1 , SigB1 (C1 + P uC1 )], [P uB1 , SigA1 (B1 + P uB1 )], [P uA1 , SigR (A1 + P uA1 )]
Überprüfung der Zertifikate
Kommunikation C1 ↔ Cx :
C1 → Cx : [P uC1 , SigB1 (C1 + P uC1 )], [P uB1 , SigA1 (B1 + P uB1 )],
[P uA1 , SigR (A1 + P uA1 )]
Cx kennt: [P uCx , SigBn (Cx + P uCx )], [P uBn , SigAm (Bn + P uBn )],
[P uAm , SigR (Am + P uAm )], P uR
Vor Benutzung von P uC1 prüft Cx :
•
SigB1 (C1 + P uC1 ) mit P uB1
•
SigA1 (B1 + P uB1 ) mit P uA1
•
SigR (A1 + P uA1 ) mit P uR (Cx kennt P uR )
Zertifikate bei Eticket (Beispiele)
DB O
n
?? OOO
nn{{
n
?? OOO
n
{
n
n
{
?? OO
n {{
n
n
OOO
??
n
n
{
n
{
}
OOO
n
n
n
'
n
Server vnn Automat
Schaffner
Card
Heim PC
1. . . x
1. . . y
1. . . z
1. . . n
1. . . m
DB O
n
?? OOO
nn{{
n
?? OOO
n
{
n
n
{
?? OO
n {{
n
n
OOO
??
n
n
{
n
{
}
OOO
n
n
n
'
n
Server vnn Automat
Schaffner
Card
Heim PC
1. . . x
1. . . y
1. . . z
1. . . n
1. . . m
X
DB O
n
?? OOO
nn{{
n
?? OOO
n
{
n
n
{
?? OO
n {{
n
n
OOO
??
n
n
{
n
{
}
OOO
n
n
n
'
n
Server vnn Automat
Schaffner
Card
Heim PC
1. . . x
1. . . y
1. . . z
1. . . n
1. . . m
X
DB=Server
AA
y
AA
y
y
AA
y
y
AA
y
A
|yy
Automat
Schaffner
Card
1. . . y
1. . . z
1. . . n
DB O
n
?? OOO
nn{{
n
?? OOO
n
{
n
n
{
?? OO
n {{
n
n
OOO
??
n
n
{
n
{
}
OOO
n
n
n
'
n
Server vnn Automat
Schaffner
Card
Heim PC
1. . . x
1. . . y
1. . . z
1. . . n
1. . . m
X
DB=Server
AA
y
AA
y
y
AA
y
y
AA
y
A
|yy
Automat
Schaffner
Card
1. . . y
1. . . z
1. . . n
DB=Server
Card
1. . . n
Angriffe
•
Replay-Attacke: Angreifer hört Nachricht mit, verwendet sie später
•
Man in the middle-Attacke: A will mit B kommunizieren
Angreifer gibt sich gegenüber A als B und gegenüber B als A aus.
•
Orakel-Attacke: Angreifer bringt A dazu, unbeabsichtigt etwas zu
entschlüsseln/signieren
Angreifermodelle
•
Einschränkungen: Kann keine Schlüssel/Zufallszahlen/Hashwerte
erraten
•
Netzwerk/Funk: Kann in Echtzeit alle Nachrichten mithören, analysieren und manipulieren (Dolev-Yao Angreifer)
•
SmartCards: Kann Kommunikation Karte/Terminal mithören, analysieren, manipulieren (oder auch nicht)
Besonderheiten bei Smartcards
1. Beschränkte Ressourcen: Oft keine asymmetrische Kryptographie
2. langsame Datenübertragung
3. Kartenhalter als Angreifer: Unbeschränkter Zugriff auf die Karte
4. Kommunikation Karte/Leser kann physikalisch geschü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
Angreifermöglichkeiten berücksichtigen
Kryptographische Protokolle: Laden eines Ticket
1.
S→C:
N1
2.
S←C:
Sign(P r(C))[Enc(P u(DB))[N1]] + Sign(P r(DB))[P u(C)] ?
3.
S→C:
Enc(P u(C))[Sign(P r(DB))[T]]
1.
S→C:
N1
2.
S←C:
Sig(P r(C))[N1 ] + Enc(P u(DB))[N2 ] + Sign(P r(DB))[P u(C)]
3.
S→C:
Sig(P r(DB))[N2 ] + Enc(P u(C))[Sign(P r(DB))[T]]
1.
S→C:
N1
2.
S←C:
Sign(P r(C))[N2 + N1 ] + Sign(P r(DB))[P u(C)]
3.
S→C:
Enc(P u(C))[Sign(P r(DB))[T + N2 ]]
Kapitel 15: Weitere Protokolle
Needham-Schroeder Protokoll (1978)
Ziel: Gegenseitige Authentisierung in Netzwerken
Message 1
A → B:
A, B, {Na , A}P u(B)
Message 2
B → A:
B, A, {Na , Nb }P u(A)
Message 3
A → B:
A, B, {Nb }P u(B)
P u(A) Public Key von A, Na , Nb Nonces, {.}K verschlüsseln mit K
Message 2
B → A:
B, A, {Na , Nb , B}P u(A)
Man-in-the-Middle Angriff
A ⇔
I ⇔
Message 1
A → B:
Message 2
B → A:
Message 3
A → B:
A, B, {Nb }P u(B)
B
Message α.1
A → I:
A, I, {Na , A}P u(I)
Message β.1
I(A) → B:
Message β.2
B → I(A):
Message α.2
I → A:
I, A, {Na , Nb }P u(A)
Message α.3
A → I:
A, I, {Nb }P u(I)
Message β.3
I(A) → B:
A, B, {Nb }P u(B)
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)
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 zurück
•
Gibt den Hash vom Client dem Client zurück
⇒ Angreifer hat Zugriff auf Client
Entdeckt 1996 (Dominique Brezinski), wiederentdeckt 2001, gepatched
2008.
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
Static Data Authentication (SDA)
Ziel: Erkennen unauthorisierter Änderung von (statischen) Daten nach
Personalisierung der Karte.
Offline Dynamic Data Authentication (DDA)
Ziel: Terminal erkennt gefälschte Karte
PIN Verschlüsselung
PIN in sicherem PIN Pad eingeben, zusammen mit Karten-Challenge
mit Public Key der Karte verschlüsseln, an Karte schicken.
Issuer Authentication
Kryptogramme und MACs wie bei Openplatform.
Digitaler Reisepass
Für das Auslesen der Fingerabdrücke: extended access control
1. basic access control (Symmetrisch, DES) weak encryption
2. Chip Authentication (Diffie-Hellman Key Exchange)
⇒ strong encryption
3. Passive Authentication (Prüfung Zertifikat des Passes)
4. Terminal Authentication (Challenge-Response)
statischer Schlüssel im Pass, jeweils neuer Schlüssel erzeugt im Terminal, Zertifikate, Public Key Infrastructure, . . .
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 zufällige Diffie-Hellman Schlüssel, Algorithmenparameter werden aus N generiert
5. T und C: Diffie-Hellman Schlüsselaustausch ⇒ session key K
6. T und C: KMAC = KDFMAC (K), KEnc = KDFEnc (K)
7. T → C: MACKMAC (Pu(T)), C → T: MACKMAC (Pu(C))
SSL 3.0
Ziel: sichere Kommunikation im Internet (Client/Server)
1. handshake protocol: Authentisierung, Schlüsselgenerierung
2. record layer: eigentlicher Datenaustausch
parametrisiert mit den eigentlichen kryptographischen Verfahren
schließt mehrere Sicherheitslücken in SSL 2.0
SSL 3.0: Handshake
C → S: client hello: protocol version + session ID + cipher suite +
compression method + NC (28 byte)
C ← S: server hello: . . . + NS (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
SSL 3.0: Schlüsselgenerierung
master secret
key block
=
MD5(pms + SHA(’A’
+ pms + NC + NS ))
+
MD5(pms + SHA(’BB’
+ pms + NC + NS ))
+
MD5(pms + SHA(’CCC’
+ pms + NC + NS ))
=
MD5(ms + SHA(’A’
+ ms + NS + NC ))
+
MD5(ms + SHA(’BB’
+ ms + NS + NC ))
+
...
Aufteilen in:
client MAC key, server MAC key, client ENC key, server ENC key, . . .
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 Schlüssel pro Richtung
•
Unterschiedliche Schlüssel pro Session
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 + SEQNUM + L + N′ ))
•
verschickt wird: M := t + v + L + Enc(P + MAC)
SEQNUM: Sequenznummer (gegen Replays)
L: Länge von Enc(P + MAC)
Schwächen in SSL 2.0
•
Schlüssellänge für Export nur 40 Bit
•
MAC nicht über alles
•
ciphersuite rollback attack: Angreifer ändert hello Nachrichten
⇒ Schwaches Verfahren wird verwendet
⇒ finished in SSL 3.0
•
version rollback attack . . .
Daumenregeln für Protokolldesign (1)
1. Signaturen/MACs: Auf dem gesamten Klartext
•
nicht: den verschlüsselten Text signieren
•
nicht: nur einen Teil des Klartexts signieren
2. Genügend Redundanz: Im (zu signierenden und zu verschlüsselndem) Klartext zusätzlich . . .
•
den Namen des Principals wiederholen
•
die Instruction wiederholen
3. Auf die Reihenfolge der Schritte achten:
Bei mehreren Schritten muss man sorgfältig ü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 gerät, bei dem kein Kommando mehr
akzeptiert wird.
5. Verschiedene Protokollabläufe unterscheiden:
Darauf achten, dass parallele Protokollabläufe mit 2 SmartCards
nicht gemischt werden können.
6. Replays vermeiden.
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
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.
Kapitel 16: Security?
1993: How to rob a bank the cashcard way“
”
1993/95–2008: ‘Kentucky Fried Chip’ hack u.a.
1999: DVD-Verschlüsselung, 2000: ebook-Verschlüsselung
2001: WLAN (Un-)Sicherheit, 2001: CCC klont D2 Kundenkarte“
”
Januar 2005: RFID Chips im Autoschlüssel geknackt
Dezember 2006: Word/Excel Passwörter, XBox, HD DVD
2005-2008: Klonen des ePass, Fälschen der Daten
2008: Mifare Classic Crack, Premiere Kartentausch, IPhone entsperren
2001-2008: SMB reflection attack November 2009: TLS Renegotiation Lü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 für PS3 gefunden
How to rob a bank the cashcard way“: ATMs
”
1993 in Großbritannien – Geldautomaten
Situation: Nachts ATMs offline (wegen batch processing)
Lösung: PIN verschlüsselt auf Magnetstreifen speichern
Problem:
How to rob a bank the cashcard way“: ATMs
”
1993 in Großbritannien – Geldautomaten
Situation: Nachts ATMs offline (wegen batch processing)
Lösung: PIN verschlüsselt auf Magnetstreifen speichern
Problem:
•
Kontonummer unabhängig von PIN
•
Kontonummer kann verändert werden
•
⇒ anderes Konto wird belastet
Geldautomaten in Großbritannien
•
Problem: Phantomabhebungen
•
Banken sagen: betrügerische Kunden
•
Kunden klagen
Ergebnis
1. Keinerlei Qualitätskontrolle bei der Softwareentwicklung
2. Es gab Betrugsmö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
‘Kentucky Fried Chip’ hack
Digitales (Pay-)Satelliten TV – 2 Beispiele:
1. Abschaltkommando unverschlüsselt ⇒ kann blockiert werden.
2. Alle Karten mit gleichem Schlüssel, der bekannt wurde
⇒ Reaktivierung abgeschalteter Karten
‘Kentucky Fried Chip’ hack
Digitales (Pay-)Satelliten TV – 2 Beispiele:
1. Abschaltkommando unverschlüsselt ⇒ kann blockiert werden.
2. Alle Karten mit gleichem Schlü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.
2001: CCC klont D2 Kundenkarte“
”
GSM – (europäischer) Mobilfunkstandard
•
Algorithmus A5 für Sprachverschlüsselung: 1994 im Internet
54 Bit Schlüsselmaterial ⇒ potentiell schwach, nie geknackt
A5/1 etc.: kürzere Schlüssel (Export in mittleren Osten)
•
A3, A8: Authentisierung, Schlüsselgenerierung: COMP128
1997 im Internet (geheime Studie von 1988)
Schwachstelle: 150.000 Anfragen ⇒ geheimer Schlüssel
•
30.7.2010: Karsten Nohl: A5/1 in 30 Sekunden entschlüsseln (Rainbow tables, brute force)
•
DefCon 2010: IMSI-Catcher für 1500 Dollar, die (falsche) Basisstation weist das Handy an, keine Verschlüsselung zu benutzen (so
in der GSM 2 Spec vorgesehen)
•
27C3 (Dezember 2010): GSM entschlüsseln in 20 Sekunden, Hardware: Wegwerfhandy + Laptop
2005: RFID Chips im Autoschlüssel
Digital Signature Transponder von Texas Instruments für:
•
Wegfahrsperre: Benzineinspritzung nur dann, wenn Challenge-Response
mit RFID im Autoschlüssel (im Zündschloss) erfolgreich – z. B.
Ford 2005
insgesamt 150 Mio. Schlü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
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.
Tamper-Proof
•
Auslesen des Speichers unmöglich
•
Abhören“ der Signalleitungen unmöglich
”
Verändern des Speichers unmöglich
•
⇒ Datenfälschung unmöglich
⇒ Geheimnisse (Schlüssel, PINs) bleiben geheim
Tamper-Proof ?
•
1990: Ablösen der Plastikhülle, Inspektion mit Mikroskop
•
1991: Löschen des EEPROM mit UV-Licht
•
1992: PIN-Angriff: Stromunterbrechung
•
1993: Reduzieren/Stoppen des Takts
•
1993: Ändern des ROM durch Laser-Schneider
•
1995: Erhöhen des Takts, Reduzieren der Spannung
•
1995: Timing Attacks
•
1995: Abhören der Busse mit Mikro-Nadeln, Ändern des EEPROM
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
Die PIN-Attacke
for(byte i=0; i<4; i++)
if (buf[i] != PIN[i]) {
remaining tries--;
ISOException.throwIt(...);
}
Die PIN-Attacke
if (buf[i] != PIN[i]) {
remaining tries--;
ISOException.throwIt(...);
}
Problem: remaining tries steht im EEPROM
⇒ Bei Update erhöhter Stromverbrauch, Dauer ca. 5 msec.
⇒ Messbar, dass Zähler verändert wird
⇒ Änderung kann durch Stromunterbrechung verhindert werden
Die PIN-Attacke: Lösung
remaining_tries--;
boolean bad = false;
if (buf[i] != PIN[i]) bad = true;
if (bad) ISOException.throwIt(...);
remaining_tries++;
Timing Attack/Simple Power Analysis
RSA-Signatur: c = md mod n. Oft: Square and multiply Algorithmus:
c = 1; s
while (d
if (d
s = s
e = e
}
=
>
%
*
/
m;
0) do {
2 == 1) c = c * z mod n;
s mod n;
2;
Timing Attack/Simple Power Analysis
RSA-Signatur: c = md mod n. Oft: Square and multiply Algorithmus:
c = 1; s
while (d
if (d
s = s
e = e
}
=
>
%
*
/
m;
0) do {
2 == 1) c = c * z mod n;
s mod n;
2;
Probleme:
1. Laufzeit abhängig von # 1-Bits in d
2. Messung des Stromverbrauchs zeigt, in welchen Iterationen
c = c ∗ z mod n stattfindet.
3. ⇒ private key
Originale Meßkurve
Transformierte Kurve
Multiplikationskurve
Vergrößerung
Erzeugen von Fehlern
Ein extremes Beispiel:
RSA Signieren: s = md mod (p ∗ q).
Effizienter ist s1 = md mod p, s2 = md mod q, s = f (s1 , s2 )
(RSA im CRT Modus)
Annahme: 1. Berechnung korrekt, 2. falsch ⇒ p = gcd(p ∗ q, sef − m).
⇒ Schlüssel geknackt
Differential Fault Analysis
Idee:
•
Eine Anfrage (Signieren/Ver-/Entschlü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 Schlüssel
Differential Power Analysis
Idee:
•
Viele (1000-10000) unterschiedliche Anfragen
(Signieren/Ver-/Entschlüsseln) stellen
Klartext muss nicht bekannt sein
•
Stromverbrauch messen
•
Messungen mit Ergebnissen statistisch korrelieren
⇒ geheimer Schlüssel
Gegenmaßnahmen
Hardware:
•
Besonderes Schaltungslayout
(Optische Analyse)
•
Aktiver Schutzschild
•
Sensoren
•
Dual rail logic
•
Bus/Speicher-Verschlüsselung
•
Rauschen“ im Stromverbrauch
”
(Nadeln/Messsonden)
(Takt-/Strom-Manipulation, Licht)
(Fehler erzeugen)
Gegenmaßnahmen
Software:
•
Zähler für (Fehl-)versuche (DFA/DPA)
•
Laufzeit unabhängig von Daten (Timing)
•
Berechnung zufällig machen (Timing/DPA)
•
Prüfsummen (Fehler)
•
Berechnungen zweimal ausführen (Fehler)
•
Ergebnisse überprüfen (Fehler)
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?: . . . nächster Angriff . . .
•
(2007: Analyse Mifare RFID Schaltung)
Die Mifare Classic
•
Dezember 2007: Vortrag CCC’07: Karsten Nohl, Starbug, Henryk
Plötz: Mifare Security
Rekonstruktion der Schaltung aus Fotos ⇒ Karte geknackt
•
März 2008: Hack wird bestä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 Plötz (HU Berlin) enthä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 veröffentlicht
Einsatz der Mifare Classic
Entwickelt Mitte der 90er, bessere Versionen existieren
200 Mio Karten im Umlauf (Stand 2008)
Öffentlicher Nahverkehr: Boston, London, Niederlande, Minneapolis, Südkorea, Hong Kong, China, Madrid, Rio de Janeiro, Neu Dehli,
Bangkok, ...
Mensakarte, Zugangskontrolle, ...
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 Abhören:
•
1. Attacke: Schwäche bei Initialisierung der Chiffre
2. Attacke: Zugriff auf internen Zustand der Chiffre
•
Ergebnis: Entschlüsseln der gesamten Kommunikation, Klonen von
Karten, Ändern des Zustands echter Karten
Struktur der Mifare Classic
Authentisierung
•
Power up, Senden der UID
•
T → C: AuthRequest, C → T: N1 (32 Bit), T → C: Enc(N2 +
A1 ), C → T: Enc(A2 )
Probleme
1. PRNG in der Karte ist deterministisch, Nonce hängt ab von Zeit
seit Power up.
2. PRNG im Terminal ist deterministisch, gleiche Nonces nach Neustart.
3. PRNG hat nur 16 Bit Seed, Algorithmus ist x16 +x14 +x13 +x11 +1
⇒ A1 , A2 aus N1 , N2 berechenbar
Verschlüsselung
•
Stromchiffre: Daten ⊕ Schlüsselstrom
•
Enc(N2 + A1 ) = (N2 ⊕ ks1 ) + (A1 ⊕ ks2 ), Enc(A2 ) = A2 ⊕ ks3
•
Abhören der Kommunikation ergibt ks2 , ks3
•
Algorithmus ist ebenfalls Polynom (48 Bit linear feedback shift
register)
•
Senden von 0 als UID und Nonce bestimmt Zustand der Chiffre
•
Ähnliche Eingaben ⇒ ähnliche Ausgaben ⇒ Filterfunktion (48 Bit
> 32 Bit) reverse engineered
•
ks2 , ks3 ⇒ secret key (in 0.1 Sekunden)

Kapitel 2: Chipkarten - Institut für Informatik

Transcription

Similar documents

Bericht über Bremstests mit einem Eigenbau

Kapitel 9: Kryptographie: DES

Statistisches Jahrbuch 1950/1955

Tarifbestimmungen – Anlage 9 - Münsterland

Agentensysteme - MarcoPiroth.de

Einführung in Pragmatik und Diskurs Anaphoric Reference Today`s

dnssec - IT SeCX