5.3 Zahlungsverkehr. - gebührenbehaftete Dokumenteneinsicht - gebührenbehaftete Netzdienste - elektronischen Einkaufen im Laden - etc.

Transkript

1 5.3 Zahlungsverkehr z.b. beim - Einkaufen im WWW - gebührenbehaftete Dokumenteneinsicht - gebührenbehaftete Netzdienste - elektronischen Einkaufen im Laden - etc. Kreditkartenbasierte Systeme Kontenbasierte Systeme Elektronisches Bargeld NS-5.3 1

2 5.3.1 Kreditkartenbasierte Systeme Kreditkarten haben viele Sicherheitsmängel, im Netz kommen neue hinzu, es sei denn, man versucht bei der Übertragung aufs Netz möglichst viele dieser Mängel zu beheben WWW: HTTPS über SSL ist schön und gut - aber: keine starke Klienten-Authentisierung (Kreditkartennummer) Händler erfährt Kreditkartennummer Händler kann Zahlbetrag verändern ferner: ungeeignet für kleine Summen (micropayments) NS-5.3 2

3 SET - Secure Electronic Transactions (Visa, Microsoft, Mastercard, IBM,...) Kreditkartenbasiertes elektronisches Zahlungssystem mit eigener Sicherungstechnik (d.h. ohne SSL). Kryptographische Verfahren fest eingebaut: DES, RSA, SHA-1. Protokoll mit 3 Partnern: Kunde, Händler, Kartenaussteller*. Jeder Partner hat zwei RSA-Schlüsselpaare, eins zum Signieren und eins zum Verschlüsseln. X.509-Zertifikate kommen zum Einsatz. Die Zertifikate des Kunden werden von seiner Bank ausgestellt, die Zertifikate der Bank und des Händlers werden vom Kreditkartenaussteller ausgestellt (und dieser zertifiziert sich womöglich selbst, siehe VISA). * vereinfacht NS-5.3 3

4 Kunde Händler Aussteller Bestellwunsch Bestätigung Bestellung+Bezahlung Anfrage Quittung Bestätigung NS-5.3 4

5 Bestellung+Bezahlung unter Verwendung einer dualen Signatur: bestellung = (text, tid) h 1 = H[bestellung] bezahlung = (karte, betrag, tid) h 2 = H[bezahlung] h 3 = H[h 1, h 2 ] sig = D K [h 3 ] tid = Transaktions-Id, H = Hashing, D = Signieren NS-5.3 5

6 Kunde Händler Aussteller N K, id, A D H [N K, N H, tid], Z H, Z A (bestellung, sig, H[bezahlung], Z K ), (E A [K], K[bezahlung, sig, H[bestellung]]) N = nonce, D = Signieren, Z = Zertifikat, id = Anfrage-Id, tid = Transaktions-Id, E = Verschlüsseln, K = Sitzungsschlüssel (zuf.) NS-5.3 6

7 Kunde Händler Aussteller N K, id, A D H [N K, N H, tid], Z H, Z A (bestellung, sig, H[bezahlung], Z K ), (E A [K], K[bezahlung, sig, H[bestellung]]) (E A [K], K[bezahlung, sig, H[bestellung]]), E A [K], K[D H [tid]], Z K, Z H E H [K], K[D A [answer]], capturetoken N = nonce, D = Signieren, Z = Zertifikat, id = Anfrage-Id, tid = Transaktions-Id, E = Verschlüsseln, K = Sitzungsschlüssel (zuf.) NS-5.3 7

8 Die tatsächliche Abbuchung des Kaufbetrags kann (muss aber nicht) separat stattfinden, z.b. am Ende des Tages gesammelt für alle Transaktionen; dazu dient das capturetoken = E H [K], K[D A [info]] Kunde Händler Aussteller E A [K], K[D H [betrag,tid]], capturetoken NS-5.3 8

9 Verbleibende Probleme: relativ hohe Transaktionskosten Händler müssen von Kreditkarten-Unternehmen autorisiert sein. Auch wird die gegenüber HTTPS wesentlich größere Sicherheit nicht stark nachgefragt, so dass SET sich bisher nicht richtig durchgesetzt hat. NS-5.3 9

10 5.3.2 Kontenbasierte Systeme ohne Kreditkarten, auch für Micropayments geeignet: Betreiber eine Kontensystems ersetzt Kreditkartenaussteller Vielzahl konkurriender (teilweise kurzlebiger) Systeme: Paypal (international, wird z.b. von ebay eingesetzt) Paybox (seit 2003 nur noch in Österreich) T-pay (T-Com)... NS

11 Beispiel Paybox: Kunde meldet sich beim Betreiber an mit Kundendaten einschließlich Telefonnummer, evtl. "Pseudonym-Telefonnummer" Bank und Kontonummer, Einzugsermächtigung und erhält eine PIN. Ware kann bestellt/bezahlt werden - direkt beim Händler - übers Netz - per SMS NS

12 Kunde Händler Betreiber Bestellung, Telefonnummer (oder Pseudonym) Transaktion, Telefonnummer (bzw. Pseudonym) (z.b. über SSL) [Telefon!] Transaktion "bestätigen"! PIN Bestätigung Überweisung NS

13 Bewertung: einfache Lösung des Problems der Kunden-Authentisierung ohne Einsatz von Kryptographie für den Kunden etwas umständlicher, aber durchaus akzeptabel (z.b. mit Mobiltelefon beim Einkauf; aber dort ist natürlich Eurocheque-Karte praktischer) deutlich weniger professionelle Sicherheit als bei SET NS

14 5.3.3 Digitales/elektronisches Bargeld electronic cash, "cybermoney" kommt dem Anonymitätscharakter von echtem Bargeld am nächsten! Kunde besitzt digitales Portemonnaie, welches digitale Münzen/Scheine enthält Echtheit eines digitalen Scheins: Signatur! Kopierschutz: entweder eine Zentrale beteiligen oder Smartcard einsetzen NS

15 Ecash [D. Chaum 1983] mit Beteiligung einer Zentralbank, bei der man digitales Geld abheben kann und die beim Ausgeben des Geldes miteingeschaltet wird, um das mehrfache Ausgeben eines Scheins bzw. einer Münze erkennen und verhindern zu können. "Cyberwallet" Software verwaltet die digitalen Münzen/Scheine auf den Rechnern der Beteiligten NS

16 Zahlender Empfänger Bank Bestellung Bestellung "bezahlen!" Bezahlung mit digitalem Geld digitales Geld "prüfen!" ok? ok ok NS

17 Grundlage von Ecash: blindes Unterschreiben (blind signatures) Verschlossener Umschlag ist innen mit Kohlepapier ausgeschlagen und enthält ein Dokument. Wenn ich auf dem Umschlag unterschreibe, habe ich das Dokument unterschrieben, ohne es zu kennen. Ist das sinnvoll? Jedenfalls kann der Empfänger verifizieren, dass ich es unterschrieben habe. Blindes Unterschreiben ist jedenfalls dann sinnvoll, wenn ich sicher bin, dass ich das ich das Dokument auch bei Einsicht unterschrieben hätte. (Beispiel Unterschriftenmappe!) NS

18 digital mit RSA (mit Werten n, e, d): [Systemsicherheit 9.6.2] Verbergen von Text x: wähle Zufallszahl z aus (1..n) und bilde mit öffentlichem Schlüssel e des Unterzeichners c = x z e mod n Blind unterschreiben: bilde mit privatem Schlüssel d c d = (x z e ) d mod n = x d z mod n (*) Signierten Text x enthüllen mit Kenntnis von z: (*) nach x d auflösen (erweiterter Euklidischer Algorithmus); das geht, weil z und n teilerfremd sind! Dann x = x de mod n erhalten! NS

19 Abheben eines digitalen 100-Euro-Scheins durch einen Bankkunden: Kunde druckt zehn 100-Euro-Rohlinge mit zufällig gewählten Seriennummern und "verschlüsselt" sie wie oben angegeben mit verschiedenen z i 10 Scheine "habe Schein i signiert" [z 0, z 1,..., z i,..., z 9 ] Schein i Bank wählt einen Schein i und signiert ihn (blind) 9 Scheine entschlüsseln und prüfen, ob alle den gleichen Nennwert n tragen, n vom Konto abbuchen NS

20 Effekt: Der Kunde ist im Besitz eines identifizierbaren (wegen der Seriennummern), gültigen (wegen der Signatur) 100-Euro-Scheins. Die Bank kann die Echtheit eines Scheins verifizieren, kann aus der Seriennummer des Scheins nicht auf den Kunden schließen, von dessen Konto das Geld stammt! NS

21 Achtung: Beim Abheben kann der Kunde eine 1000-Euro-Note einschmuggeln in der Hoffnung, dass die Bank bei der Zufallsauswahl gerade diesen Schein trifft: die Chance ist zwar nur 10%..... Abhilfe: 100 Rohlinge fordern statt oder (besser) Strafe so hoch ansetzen, dass sich der Betrugsversuch nicht lohnt (stochastisch!), hier z.b. 100 Euro Strafe. NS

22 Bezahlen mit einem digitalen 100-Euro-Schein: Zahlender Empfänger Bank 100-Euro-Schein ok echt? 100-Euro-Schein echt? Seriennummer sperren Gutschrift auf Konto des Empfängers ok NS

23 Praktikabler Einsatz erfordert Klärung vieler technischer Details: - Wechselgeld - Sichere Kommunikation - u.a. Chaum's Firma Digicash hat nicht überlebt... NS

24 Geldkarte auch "Elektronisches Portemonnaie" (electronic wallet) für maximal 200,- realisiert durch spezielle Hardware: Chipkarte/Smartcard benötigt daher nicht unbedingt eine Zentrale! beste Annäherung an wirkliches Bargeld Zwei Arten von Karten: "Weiße Karte" wie Bargeld, nicht an Konto gebunden, ohne Zentrale "Börsenkarte" ähnelt Bargeld, an Konto gebunden, meist in EC/Maestro-Karte integriert (Akzeptanz und Internationalisierung kommen nur langsam voran.) NS

25 Kontogebundene Karte ("Börsenkarte") wird von Bank ausgegeben wird am Automaten aufgeladen, entweder mit Bargeld oder mit Abbuchung vom Konto (mit PIN-Eingabe) (auch Aufladen übers Netz ist vorgesehen) Bezahlen: - an entsprechendem Zahlungsterminal des Händlers - nur mit Karte, ohne weitere Authentisierung (d.h. ohne PIN, Belege, Unterschrift) - auch übers Netz (mit Kartenlesegerät "Klasse 3") - bei Kassenschluss Gutschrift auf Konto des Händlers NS

26 Wenn alles richtig gesichert ist (Hardware/Protokolle), bedarf es eigentlich keiner weiteren Infrastruktur - denn das elektronische Geld ist so gut wie echtes! Aber: - unbekannte Sicherheitslücken? - mangelnde Akzeptanz für eine undurchsichtige neue Technologie in einem hochsensiblen Bereich! Infrastruktur für zusätzliche Absicherung: Bank führt Börsenverrechnungskonto: Summe des Geldes auf allen von ihr herausgegebenen Geldkarten Ladezentrale führt Buch über Geldkarten und wird beim Ladevorgang eingeschaltet Evidenzzentrale führt für jede Geldkarte ein Schattenkonto, dessen Stand jeweils dem aktuellen Inhalt der Geldkarte entspricht NS

27 Aufladen: (wie Bargeld abheben) Automat wendet sich an zuständige Ladezentrale der Karte, die die notwendigen Prüfungen vornimmt; dann wird die Summe vom Konto abgebucht (nicht bei Bargeld) und auf das Börsenverrechnungskonto der Bank gebucht, und die Karte wird entsprechend aufgeladen. Außerdem wird bei der Evidenzzentrale das Schattenkonto der Karte erhöht. NS

28 Bezahlen und Abrechnen: Transaktionsdaten werden in Händlerkarte und Geldkarte festgehalten*. Bei Kassenschluss werden diese Daten von der Händlerkarte an die Evidenzzentrale übermittelt. Für jede Transaktion einer Karte passiert folgendes: - Verringerung des zugehörigen Schattenkontos, - Information der Bank des Kunden, führt zur Abbuchung vom dortigen Börsenverrechnungskonto, - Information der Bank des Händlers, führt zur Gutschrift auf dem Konto des Händlers. (Geringe Gebühren: 0,3%, mindestens 1 Cent) * z.b. Fahrschein! NS

29 (Quelle: NS

30 ... und beim Bezahlen übers Netz: Anstelle des Händlerterminals gibt es ein Kartenlesegerät beim Kunden und einen Händlerterminal-Betreiber (mit "virtuellen Händlerkarten"). NS

31 Beachte: Hier ist jegliche Kommunikation kryptographisch gesichert und authentisiert, auch die zwischen Karten und Geräten. Anonymität ähnlich wie bei Bargeld und wie bei SET (5.3.1) (Händler erfährt allenfalls meine Kartennummer) - aber aufhebbar, z.b. auf richterlichen Beschluss Vorteile: praktisch (kein Kleingeld), relative Anonymität; bei Kartenverlust evtl. Erstattung in Höhe des Kontostands des Schattenkontos Nachteil: Komplexität NS

32 Kontoungebundene Karte ("Weiße Karte") wird am Automaten aufgeladen, mit Bargeld oder von EC/Maestro-Karte (mit PIN); kein Schattenkonto bei Evidenzzentrale, somit bei Bargeld-Aufladung 100% Anonymität! Bezahlen und Abrechnen: wie bei Börsenkarte Nachteil: Karte weg - Geld weg Variante: betriebseigene Karte (Casino, Mensa,...) mit Buchführung über Ladestand NS

33 Details: (sehr gut!) NS

34 Epilog: was wurde in "Netzsicherheit" nicht behandelt? Middleware: keine prinzipiell neuen Mechanismen, aber komplexe Realisierung von "Zugriffsschutz übers Netz" [Hartman/Flinn/Beznosov: Enterprise Security with EJB and CORBA] Funknetze/Mobilkommunikation: betrifft Schicht 1 bis 3 [Schäfer, Teil III] [Eren/Detken: Mobile Security] RFIDs: werden vielfältige Sicherheitsprobleme verursachen - noch wenig erforscht [lasecwww.epfl.ch/~gavoine/rfid] lesenswert: M.R. Rieback et al.: Is your cat infected with a computer virus? Proc. PerCom 2006 NS

35 ... und was wäre noch wünschenswert? NS