Sicherheitsstandards in Kommunikationssystemen

Sicherheitsstandards in Kommunikationssystemen
OSI und X.400 / X.500
Internet ( IPsec, SSL )
ISDN
Anwender-Standards:
Sichere Mail-Systeme ( PGP u. a. , Spam-Filter )
Electronic Commerce ( HBCI , E-Cash , Paybox , SET )
Kabellose Kommunikation
OSI und X.400 / X.500
OSI (offene Systeme):
Sicherheitsfunktionen im OSI-Modell: OSI 7498, X.200
Standard: Sicherungs/Verbindungsschicht (2):
Fehlererkennung/behebung mit HDLC-Prozedur (high level data link control),
Sicherheitsdienste für Netzwerk/Vermittlungsschicht (3)
(alles nur physische Sicherheit).
Keine Maßnahmen gegen Zugriffsrisiken!
Zusätzlich OSI-Sicherheitsarchitektur (security architecture):
OSI 7498-2 als Zusatz zum OSI-Modell: 14 Funktionen, zunächst keine Implementierungsvorschriften
("security frameworks", "security models"); Anhang verweist auf Gefahren/Angriffsmöglichkeiten.
Empfehlungen X.400 (MHS = message handling system), X.500 (The Directory: Auskunft/Verzeichnissystem):
(CCITT bzw. ITU = international telecommunication union)
X.400 seit 1988 mit Sicherheitsdiensten für Kommunikation und Speicherung von Nachrichten (detaillierter als bei OSI),
enthält 10 Bedrohungen und 13 Sicherheitsfunktionen (2 zum Schutz von Verbindungen, 11 für Einzelmeldungen.
Inhalt (content) und Umschlag (envelope) jeder Meldung (Umschlag mit Informationen für message transfer system)
Implementierungen (EU): PASSWORD = piloting authentic.and security services within OSI applications for research
and development,
TESI = trans european service infrastructure.
X.509 "Rahmen für Authentikationen" analog ISO 9594-8: asymmetrische Chiffrierverfahren,
öffentliche Schlüssel in DIB (directory information base),
Regeln für Schlüssel-Zertifikate,
Handshake-Protokolle zur Teilnehmer-Authentikation durch unterschriebene Nachrichten (Token): one/two/three-wayhandshake
one:
Sender- u. Nachrichten-Authentikation
two:
Sender-, Empfänger- u. Nachrichten-Authentikation
three: zusätzlich Zeitstempel (A sendet Zufallszahl, die B im 2. Schritt mit eigener Zufallszahl
zurücksendet, A sendet Zufallszahl von B im 3. Schritt zurück) gegen replay
(wichtig bei nichtsynchronisierten Uhren)
[viele Varianten]
CA-Hierarchie!, evtl. außerhalb des Netzes, jede CA bildet einen Vertrauensbereich: zugehörige Nutzer benutzen denselben public key,
Nutzer unterschiedlicher Bereiche benötigen zusätzlich die anderen public keys
mit Zertifikat einer übergeordneten CA , d. h.: Authentikationsserver als Auskunftssystem wichtig.
Implementierungen in Deutschland (VERDI) und EU (PARADISE = piloting a researchers directory service in europe)
Internet (TCP/IP)
Standard-Protokoll-Suite IPsec der IETF (internet engineering task force), war für IPv4 vorgesehen, dann IPv6;
jetzt separat, da die v6-Einführung noch unklar ist (wegen dynamischer IP-Adressen):
SA (security association) der Partner mit SPI (security parameter index: Algorithmen zur Verschlüsselung und Authentikation, die Schlüssel,
Initialvektor der Verschlüsselung, Gültigkeitszeitraum, Senderadresse)
1) AH (authentication header) im IP-Datagramm, Authentikation und zugleich Integrität durch HMAC gesichert:
HMAC-MD5-96 oder HMAC-SHA1-96
2) ESP (encapsulation security payload) zur Verschlüsselung/Authentikation der gekapselten Daten
(kryptographische Verfahren nicht fest vorgeschrieben, aber mindestens DES und CBC-Modus)
AH + ESP : Anti-Replay-Service (ARS): 32-bit-Feld mit monoton steigender Sequenz-Nr.
3) IKE (internet key exchange, entspricht ISAKMP/Oakley) zur Schlüssel-Verwaltung und zum Aufbau eines sicheren
Tunnels,
speziell Signaturen nach RSA oder DSS, public-key-Zertifikate, pre-shared-keys (vorher verteilt), Schlüssel-Austausch nach Diffie-Hellman
Verschlüsselung in Routern oder bei Providern (ISP)
Transport- oder Tunnel-Modus: nur Daten-Verschlüsselung oder zusätzlich Verschlüsselung des IP-Headers;
im Tunnel-Modus laufen alle Daten auf Ebene 3 über IPsec-Gateway, das die Daten kapselt, verschlüsselt und weiterleitet. Zentrale Datenbasis: DOI (domain of interpretation)
Linux-Implementierung: FreeS / WAN
IPv6 mit 2 zusätzlichen IP-Headern:
Authentication Header mit symmetrisch verschlüsselter kryptographischer Prüfsumme nach "Keyed MD5" (auch anders möglich).
Probleme: nicht in allen Ländern erlaubt; key management protocol muß noch definiert werden;
sichert nur die Verbindung, ersetzt nicht Firewalls, da durch Implementierungs-/Administartions-/Benutzer-fehler
Eindringen möglich werden kann.
Browser-Schutz (nicht sicher): Sandbox, Datenausführungsverhinderung (DEP = data execution prevention, Windows,
schützt Daten im Arbeitsspeicher),
ASLR = address space layout randomization (gegen buffer overflow, Windows)
sftp (secure FTP) unter SSH, ebenso Tunneln von X11 und TCP möglich,
secure SNMP (SNMP II, SNMPv2).
NAT (network address translation): RFC 1631, modifiziert IP-Adressen (eine Adresse für Netzwerk),
d. h. Struktur nicht mehr erkennbar, speziell bei Firewalls.
Z. Zt. 70 RFC (requests for comments: TCP/IP-Implementationsstandard) zur Sicherheit, die Hälfte davon seit 1995,
z. B. RFC 1825 - 1829 für IPsec, RFC 1421 – 1424 (PEM), RFC 1422 (CA-Hierarchie nach X.509), RFC 1424 (Interface Teilnehmer - CA).
TCP-Wrapper und IP-Filter (Proxy-Programme) geben Verbindung zum Server erst nach Prüfung frei (aber Fälschungen
mit Trojanern bekannt!).
ITU-Standards für sichere IP-Multipoint-Verbindungen: H.323
(H.320 für ISDN, H.243/5 für Kennwörter).
Internet-Telefonie (VoIP) wird verschlüsselt .
Arbeitsgruppen für sichere Protokolle:
CIPSO (commercial IP security option working group)
IPSEC (IP security protocol working group)
Sicherheitsservice im Internet: WWW, teilweise signierte Patches, z. B. Sun.
Anonymisierer geben dem Web-Server statt der Client-IP-Adresse nur ihre Proxy-Server-Adresse bekannt.
Meist wird ein Anonymisierungsnetzwerk mit einem Endknoten (Exit Node) aufgebaut .
Beispiele:
o JAP (Java Anon Proxy) in TU Dresden: Proxy-Ketten (eMails und Web-Zugriffe werden in viele „Umschläge“ gesteckt
und so über viele Server/Router geleitet, die jeweils nur einen Umschlag öffnen dürfen;
analoge Software für Android-Smartphones in Arbeit.
o InPrivate-Filter (Microsoft, verbirgt Surfspuren)
o Stealther
o Multi Proxy
Tracking Protection blockiert Cookies zur Analyse des Nutzerverhaltens.
SSL (secure socket layer) von Netscape (ab Netscape 2 und Explorer 3, meist Grundlage von e-commerce):
zwei Schichten (zwischen HTTP und TCP):
SSL Record Protokoll und
SSL RSA -Handshake-Protocol zum Schlüssel-Austausch, ebenfalls optional, ohne Änderungen an Nachbarschichten
einbaubar (128-bit-IDEA, 1024-bit-RSA).
1) Durch https://www . . . wird vom angesprochenen Server sein öffentlicher Schlüssel mit Zertifikat abgefordert,
der wird zusammen mit Prüfsumme und ID (= Zertifikat) an den Browser zurückgemeldet.
Zertifikate von Zertifizierungsfirmen (z. B. VeriSign) mit ID der Zertifizierungsstelle;
jeder virtuelle Webserver benötigt ein eigenes Schlüsselpaar, weil in ID der Domain-Name einfließt.
2) Der Browser (Client) prüft das Server-Zertifikat und weiß somit, ob er wirklich mit dem gewünschten,
in der URL angegebenen Server verbunden ist: dann schließt sich beim Internet Explorer das
Bügelschloß bzw. der sonst gebrochene Schlüssel wird intakt (beim Navigator/Communicator).
3) Client übergibt sein Zertifikat an den Server (optional, da z. Z. noch zu wenige Nutzer über ein Zertifikat verfügen).
4) Erzeugung des session key (symmetrisch, „secret master“):
Der Client erzeugt mittels Zufallszahlengenerator Bitfolge (48 Byte lang, pre-master-secret);
Austausch mittels public key des Servers; Hash-Wert davon (bei Client und Server gebildet) ist der master key.
Der Client erzeugt jeweils einen neuen Sitzungsschlüssel (wird spätestens nach 24 Stunden gelöscht).
Der Client (Browser) schickt dem Server vor Beginn des eigentlichen Datenaustausches einige Testnachrichten,
die der Server nur beantworten kann, wenn er wirklich der Server ist, der er zu sein vorgibt.
5) authentische Verbindung läuft.
(ein Hintergrundprozess prüft durch periodischen Datenaustausch, ob die Verbindung noch besteht:
„Heartbeat“ = Herzschlag)
SSL kann leicht auf einem Apache-Web-Server installiert werden: OpenSSL (kostenlos, weit verbreitet),
mod_ssl, apache_ssl; evtl. auch LDAP.
Ein Directory-Server sammelt die Zertifikate.
2012 passiert bei Verbesserungsarbeiten an OpenSSL ein Fehler beim Heartbeat, der das Einchleusen von Malware
ermöglicht: „Heartbleed“ (Herzblut).
SSL-Nachfolger ist TLS (transport layer security)!
Sichere Sites übertragen Teile (z. B. Kreditkartennummern) RSA-codiert.
Zusätzlich Authentikation von Server und Browser über zertifizierte digitale ID ("Personalausweis") möglich. - Dann
kein Kennwort mehr nötig!
Sichere Server mit Zugriffsschutz sind z. B. UNIX-Apache (von NCSA) oder NCSA-Supercomputer.
Einrichtung eines Web-Servers, z. B. IIS (internet information server, Windows):
1) Zertifikat installieren, 2) SSL aktivieren.
Protokoll HTTPS seit 1994: Secure-HTTP, in Schicht 7, sichert also nur Nachricht, Port 443/tcp, Firmen-Konsortium,
mit allen aktuellen Krypto-Standards (Verfahren nicht vorgeschrieben),
z. B. PKCS (public key crypto standard) von RSA (digitale Umschläge, in gekapselten HTTP-Nachrichten).
Funktionen optional (wegen Kompatibilität zum gewöhnlichen HTTP).
Viele weitere Sicherheitsfunktionen.
Phishing-Filter
o vergleichen mit Liste bekannter Phishing-Sites
o prüfen auf verdächtige Signale und senden ggf. in Pop-ups Warnungen
o enthalten Smart-Screen-Filter
ISDN (integrated services digital network): praktische Bedeutung nur bis zur endgültigen Etablierung von DSL
Spezielle ISDN-Karten mit Sicherheitsmechanismen (DES, RSA; unterstützen auch SNMP)
CLID = calling line identification: Anrufer-Nr. im D-Kanal kann durch Router mit Access-Liste verglichen werden
PAP (password authentication protocol): 2-Wege-Handshake-Protokoll:
1) Kennwort im Klartext
2) Zustimmung/Ablehnung nach Vergleich mit Benutzerregister
CHAP (challenge handshake authentication protocol): 3-Wege-Handshake-Protokoll:
1) B an A: challenge (Zufallscode zur Kennwort-Modifikation)
2) A an B: modifiziertes Kennwort
3) B an A: Zustimmung/Ablehnung nach Vergleich mit selbst modifiziertem Kennwort
Zusätzlich periodisch Authentikation auch während der Sitzung.
System "Babylon" verschlüsselte transparent B-Kanal nach DES
(Schlüssel wurde jedesmal neu erzeugt und mit RSA ausgetauscht).
RADIUS (remote authentication dial-in user service): zentrale Datenbank.
DCE-Security: Kerberos
ECMA-Sicherheitsarchitektur (european computer manufacturers association)
(Implementierung im EU-Projekt SESAME = secure european system for applications in a multi-vendor environment,
Kerberos-Erweiterung)
Kompatibilität ECMA - DCE wurde angestrebt.
Weitere Möglichkeiten:
Java: Security-Manager schirmt mit bestimmter Sicherheitspolitik lokale Maschine gegen unerlaubte Applet-Aktivitäten ab
(Applets können nicht aus Java-VM heraus, böswillige Software darin aber nicht völlig auszuschließen).
ActiveX: „Authenticode“ ermöglicht Authentikation des Servers mittels digitaler Signatur.
Captchas: Sicherheitsabfragen zur Authentikation (von Webseite vorgegebene Zeichenfolge, die leider oft schwer lesbar
ist, muss eingegeben werden); digitale Barriere.
Anwender-Standards
Sichere Mail-Systeme
Rechtswirksam nur, wenn die Identität des Absenders nachgewiesen werden kann;
Identitätssicherheit schafft eine digitale Signatur (Sendeprotokoll oder Zeugen reichen nicht, aber ggf. eine Eingangsbestätigung).
De-Mail: Deutsche Post AG, seit 2010, sichert Identität des Absenders und verschlüsselte Übertragung.
2012 vier Zulassungen durch das BSI: Telekom, T-Systems, Mentana Claimsoft, United Internet (GMX, web.de, 1&1);
Mail-Adressen haben die Form „…@anbieter.de-mail.de“
PEM (privacy enhanced mail): Internet-Standard von 1988, 4 RFCs), X.509v1,
erstmals Verschlüsselung und Signieren, DES, RSA für Schlüssel-Austausch, Format-Informationen werden nicht verschlüsselt,
auch für Dateien geeignet, nicht MIME-kompatibel,
kein Produkt (da PGP populärer wurde und Export-Verbot bestand).
PGP (pretty good privacy): von „Krypto-Rebell“ Philip Zimmermann, Volksnorm, Rechte dann bei Network Associates
[ohne den Autor], dann PGP Corporation;
im Internet: PGPi = PGP international, Oberfläche: OpenPGP, GP (engl.) als Freeware, G[NU]PGP .
Im Dez. 1999 wurde das Exportverbot aufgehoben, OpenPGP Standard (RFC 2440), GnuPG, Windows Privacy Tray
von Ordix (frei).
PGP ist ein komplettes Paket aus:
- IDEA/Triple-DES/CAST-128 bzw. RSA/DSS (dann bis 4096 bit): Hybridverfahren!, kein Hand-shake für Sitzungsschlüssel, da Einmalschlüssel,
- MD5 (128 bit langer Hash-Wert),
- Schlüssel-Generierung und -Verwaltung, Vertrauensbildung für öffentliche Schlüssel. (Web of Trust statt CA-Hierarchie!), aber auch X.509 über CA möglich,
- ZIP (standardmäßig Kompression!)
- Radix-64-Umwandlung binär zu ASCII (3 Oktette zu 4 ASCII-Zeichen + CRC)
Plug-ins für Mail-Systeme, nicht MIME-kompatibel.
PGP-Begrüßungstext: "No configuration file found.
Pretty Good Privacy(tm) 2.6.3i - Public-key encryption for the masses.
(c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18
International version - not for use in the USA. Does not use RSAREF.
Current time: 1996/11/26 16:44 GMT" usw.
Schlüsselverwaltung: z. B.
Schlüssel-Generierung:
pgp -kg
(3 Sicherheitsstufen: privat mit 384 bit, kommerziell mit 512 bit, militärisch mit 1024 bit)
Aufnahme fremder Schlüssel other.asc (im ASCII-Code!) in den eigenen Schlüsselring:
pgp -ka other.asc
(dabei muß der Schlüssel bewertet werden: nein / weiß nicht / eingeschränkt ja / ja )
Anzeigen aller Schlüssel im Ring: pgp -kc oder -kv (kürzer)
Extrahieren von Schlüsseln:
pgp -kx uid
Löschen:
pgp -kr uid
Signieren:
pgp -ks uid (zeigt auch Fingerprint an)
Prüfen der Signatur:
pgp -kc [uid]
PGP ist inzwischen in viele mail-Systeme integriert, spezielles mail-System: pgpsendmail
PGP 9 verschlüsselt ganze Festplatten / Nachrichten.
MOSS (MIME object security service): RFC 1848, kryptographische Verfahren nicht vorgegeben, hat sich nicht durchgesetzt.
S/MIME (secure multipurpose internet mail extensions): Fa. RSA mit Unterstützung von Microsoft / Netscape u. a.,
PKCS-Mechanismen (public key crypto standard von RSA), versteht auch PEM, RC2 zur Verschlüsselung (Schlüssellänge 40 bit, wegen Exportfähigkeit),
aber DES / Triple-DES optional, X.509v3 (flexibler) ohne CA-Hierarchie.
PGP oft als Zusatz:
PGP/MIME: von IETF als Internet-Standard favorisiert.
MSP (message security protocol): OSI-gerecht, X.400 (nicht Bedingung), X.509, kryptographische Verfahren nicht vorgegeben.
MailTrusT von TeleTrusT (65 Firmen/Einrichtungen):
SigG-konform (deutsche Insellösung?), PEM (erweitert, bessere Krypto-Verfahren), S/MIME vorgesehen (wegen Internationalisierung),
X.509v1 (später v3), Teilmenge der PKCS-Mechanismen (public key crypto standard) mit Schnittstelle zu sicherem
PSE-Bereich (private secure environment,
meist Smartcards nach PKCS#11), Protokolle, Datenaustauschformate (z. B. PKCS-CMS), Schlüsselverwaltung API.
Spam-Filter:
- „Teergruben“ (absichtlich offene Gateways) lassen Spams kleben
- DNSBL (domain name service blackhole list): schwarze Listen von Spam-Versendern
- Inhalt (Zeichenketten) im Betreff
- P2P (peer to peer): Prüfsummen von Mails in Listen sammeln, oft auftretende Prüfsummen gehören zu Spams
- Wegwerf(Einweg)-Mailadressen (sind für Spam-Sender wertlos)
- Bayes-Filter: Wahrscheinlichkeit für das Auftreten bestimmter Wörte in Spams (langer Lernprozess)
- Registrierung der Sender-ID bei DNS und Prüfung, ob IP-Adresse dem Absender entspricht
- Nash-Filter (Spieltheoretiker Nash strebt Nash-Gleichgewicht an: starker Schutz gegen starken Angriff)
Mailprovider heute meist mit Virencheck, z. B. GMX.
Remailer anonymisieren Mails durch Leitung über Gateway-Kaskaden.
Electronic Commerce
Ein Kaufvorgang besteht aus Bestellung und Bezahlung
Forderungen an Verträge (auch elektronische):
Ordnungsmäßigkeit + Vollständigkeit
Schutz vor Veränderungen/Verfälschungen
Sicherung vor Verlust
Einhaltung einer Aufbewahrungsfrist
sichere Übertragung
(schriftliche bzw. fernmündliche) Bestätigung
Dokumentation des Ablaufs
Anonymität (speziell bei digitalem Bargeld)
Bestellsystem-Ablauf: 1) Händler-Angebot Händler → Kunden (WWW)
2) Bestellung mit Zahlungsart Kunde → Händler
3) Preisnennung Händler → Kunde
4) Zahlungsobjekt (Bargeld/Einzugermächtigung) Kunde → Händler
5) Quittung Händler → Kunde , Lieferung (nicht elektronisch)
Risiken: Echtheit der Nachrichten und Teilnehmer, Falschgeld, Vertraulichkeit (Kreditkartennummer, Kundenprofile)
Zahlungssysteme (speziell E-Payment): Rechnung, Nachnahme, Telefonrechnung (über Internet oder 0190 , . . .),
Einzugsermächtigung / Lastschrift, Kreditkarte (z. B. CyberCash, SET), Scheck (möglichst digital signiert!),
digitales Bargeld (elektronische Geldbörse, anonym über Hardware in Form von Chipkarten:
„Wallets“, "white cards", z. B. eCash, oder kryptographisch gesichert),
Kundenkonto, Treuhandsysteme, Online-Shopping,
Handy / WAP-Handy (evtl. heikel: WAP-Gateway zur Umsetzung WTLS = wireless transport layer security protocol,
führt zu SSL, d. h. keine end-to-end-Verschlüsselung:
Prozesse müssen so gekapselt werden, dass keine Übertragung im Netz erfolgt und nicht auf Klartext zugegriffen werden kann), z. B. Paybox.
Anforderungen: gleiche Sicherheit wie bei Bargeld (d. h. fälschungssicheres Geld!), jeder muss Echtheit nachprüfen können (Bank signiert),
Anonymität (kein Rückschluss auf bezahlende Person: Blindsignatur),
Geld darf nicht mehrfach ausgegeben werden können (d. h. speziell Geheimnisteilungsverfahren: bei Mehrfachausgabe Zuordnung zum Besitzer möglich),
Verifikation ohne Bank muss möglich sein.
Noch offenes Problem: Wechselgeld.
Beispiele: eBay-Bezahlung mittels PayPal bzw.
ab 2012 direkt bei eBay in 4 Schritten: 1) Käufer bezahlt an eBay; 2) eBay informiert den Verkäufer; 3) der Verkäufer
verschickt den Artikel; 4) eBay bezahlt den Verkäufer.
„click & buy“ (Firstgate), „net900“ (in medias res),
„infin Micropayment“ (Ingenieurgesellschaft für Informationstechnologien)
für kleinere Beträge ohne persönliche Daten.
Bei etwaiger Übertragung der Kreditkartennummer auf SSH / https achten!
Ecash / E-Cash (David Chaum, DB): digitales Bargeld,
Doppelunterschrift, virtuelles/anonymes Geld durch "blinding" und "secret sharing",
von BSI als „ausreichend sicher" eingeschätzt, holländische Fa. DigiCash von David Chaum;
blinding: Kunde erzeugt Seriennummer des Geldes (zur Kontrolle wegen Fälschung) und
rechnet sie mit Blind-Faktor um (Bank signiert Geld + Seriennummer, ohne sie dem Kunden zuordnen zu können!
Später kann die signierte Seriennummer ohne Blindfaktor kontrolliert werden.
Problem: alle eingereichten Münzen müssen archiviert werden.)
Cyber Cash (Fa., Dresdner Bank u. a.): Kreditkartenzahlung mit virtuellem Geld
[wegen fehlender Akzeptanz eingestellt]
HBCI (home banking computer interface, zentraler Kreditausschuß, seit 1996):
128-bit-Schlüssel, Chipkarten-Authentikation (ec-Karte mit HBCI-Funktion, spezielles Lesegerät nötig!),
private PIN (selbst gewählt: Paßwort, nicht PIN/TAN)
Initialisierung:
- Übergabe des RSA-Privatschlüssels auf Chipkarte / USB-Stick (PIN-geschützt)
- öffentlichen Bankschlüssel über Internet holen und mit übergebenem/gesendetem Schlüssel mittels Hash vergleichen
- eigenen public key über Internet an Bank geben
- Bank schickt Initialisierungsbrief, der unterschrieben an Bank zurückgeschickt wird
- temporärer Sitzungschlüssel nach Triple-DES
HBCI+ : HBCI mit PIN/TAN, FinTS-Standard (financial transaction service);
ggf. SSL-Zertifikat der Bank prüfen!
ggf. mTAN (mobile TAN) per SMS;
Beispiele: BfG, Software StarMoney / S-Connect der Sparkassen.
BCS (banking communication standard), inkl. Schlüssel-Generierung / Austausch.
Paybox: Bezahlung per Handy (m-commerce) nach einmaliger Anmeldung (Geheimnummer),
Kunde gibt Handy-Nr. an Händler, Händler leitet weiter an Fa. Paybox (die hat Einzugsermächtigung),
Paybox ruft Kunden an und nennt Zahlungsempfänger + Betrag, Kunde bestätigt mit PIN.
SET (secure electronic transaction)
Entstanden in den USA: Visa/Mastercard/IBM/Microsoft (Win2000) u. a., teuer;
vollständiges Bestell/Zahlungssystem (seit 1997, aber noch wenig benutzt);
Protokoll (verschlüsselte Kreditkartendaten gehen über das Kaufhaus zur Bank, nur dort Entschlüsselung möglich);
DES (zufällige 56-bit-Schlüssel) für Nachrichten, 2 x RSA (1024-bit-Schlüssel): 1) s / p sender-E für DES-Schlüssel und Konto-Nummern;
2) s / p sender-S für Signaturen, d. h. jeder hat 2 Schlüssel-Paare;
public-key-Zertifikate für Händler analog Aufkleber "VISA" o. ä. (für Kunden optional);
public-key-Versendung grundsätzlich mit Zertifikat cert(pubkey);
Hierarchie mit "root key/signature" und "replacement key" (bei Schlüssel-Austausch);
weltweit abgesicherte Transaktionsserver (internationales Bankennetz);
weitere Nachrichtentypen, z. B. bezüglich Kredit;
Voraussetzung: sicheres mailing, z. B. mit PGP, S/MIME, sowie SSL;
Auch für virtuelle Kreditkarten geeignet (Anforderung über PIN und geheimem Schlüssel, dann Download auf PC mit
Ikon, Bezahlung über SET);
Tendenz: Verschmelzung mit Chip/Geldkarten (PC-Lesegeräte)?
SET-Ablauf [etwas vereinfacht]:
(1) Bestellung
(purchase request)
K → H:
Anfrage (formlos)
(initiate request)
H → K:
m(cert(pH-S) || cert(pBH-E)) || sign(m))
(initiate response)
K:
veri(m) , veri(pH) , veri(pBH)
(Verifikation)
K → H:
mB || E(mZ)Ĵ kS1 || E(kS 1||Knr)Ĵ pBH-E || dsign(mB,mZ) [||cert(pK)]
(Bestellung + Zahlungsanweisung im Umschlag: dual signature)
H:
veri(dsign(mB,mZ)), [veri(pK)]
H → BK:
E(mZ)Ĵ kS1 || E(kS 1||Knr)Ĵ pBH-E || dsign(mB,mZ)
H → K:
Q || sign(Q) || cert(pH-S)
(Quittung!)
K:
veri(Q) , veri(pH) , Q ® Ablage
(2) Autorisierung
(payment authorisation)
H → BH:
E(mZ)Ĵ kS1 || E(kS 1||Knr)Ĵ pBH-E || dsign(mB,mZ) [||cert(pK)] ||
E(AH)Ĵ kS2 || (cert(pH-E) || (cert(pH-S) [ || cert(pK) ] || E(kS2)Ĵ pBH-E
BH:
Entschlüsselung + Verifikation, Vergleich mZ - AH
BH → BK: Anfrage (über Bankennetzwerk)
BK → BH: Antwort (über Bankennetzwerk)
BH → H:
E(Antwort)Ĵ kS3 || sign(Antwort) || E(kS3 || KnrK)Ĵ pH-E ||
E(Token)Ĵ kS4 || E(kS4 || Knr)Ĵ pBK-E
(capture token im Umschlag)
H:
Entschlüsselung (teilweise) + Verifikation, Antwort + Token ablegen,
Lieferung bzw. Dienstleistung ausführen
(3) Abrechnung
(payment capture)
H → BH:
E(Betrag || Rechnungsnr || TAN)Ĵ kS5 + E(kS5 || Token)Ĵ pBK-E ||
cert(pH-E) || cert(pH-S)
(capture request im Umschlag)
BH:
Entschlüsselung, Verifikation, Token-Auswertung
BH → BK: Überweisungsauftrag (über Bankennetzwerk)
BH → H:
E(Antwort)Ĵ kS5 + E(kS5)Ĵ pH-E
H:
Entschlüsselung + Verifikation
H → BH:
Bestätigung
(capture response)
Legende:
||
Vereinigung
[...]
E, D
Ĵk
CA
K, H
BH, BK
Knr
mB, mZ
A
Q
optional
Verschlüsselung (encryption), Entschlüsselung (decryption)
Verschlüsselung mit Schlüssel k
certification authority
Kunde, Händler
Bank für Händler bzw. Kunde
Kreditkartennummer des Kunden
Bestellung, Zahlungsanweisung
Anfrage
Quittung
p, s
kS
h
public key, secret key
zufälliger Sitzungsschlüssel für DES
Hash-Funktion
cert(p) = p || sign(p)Ĵ sCA
(Zertifikat eines public key)
sign(m)Ĵ sSender = E(h(m))Ĵ sSender-S
(digitale Signatur)
dsign(m1,m2) = E(h(h(m1)||h(m2))Ĵ sSender-S
(duale Signatur)
veri(m) : h(m) = D(sign)Ĵ pSender-E ?
(Verifikation einer Nachricht)
veri(p) : pSender = D(cert(pSender))Ĵ pCA ?
(Verifikation eines Zertifikats)
Security-Suiten aus Firewall, Virenscanner, Internet-Sicherheit (Werbeblocker, Kindersicherung, Löschen von Surfspuren),
meist mit Wizards, Updates, bootfähiger CD, Angreifer-Lokalisation.
Beispiele: Norton Internet Security 2003 (Symantec), McAfee Internet Security 5.0, Steganos Internet Security,
Kaspersky (Russland).
Handy-Bezahlung an Kassen mittels NFC (Nahfeld-Kommunikation) über NFC-Chips bzw. -Etiketten oder
mittels Pixel-Codes, in denen die Identifikationsdaten versteckt sind (z. B. von Fa. „Secupay“ in Pulsnitz).
Sicherheit durch die Nähe zwischen Kasse und Kunden und wegen mehrerer getrennter PIN-geschützter Kanäle
(Handy, App und Überweisungsbestätigung) gegeben .
Zukünftig evtl. auch mittels virtuellem Geld / open-source-Geld (System ISIS in USA).
Chipkarten als Sicherheitswerkzeug
Anwendungen: Telefonkarte, Krankenkasse, Scheckkarte, elektronische Geldbörse.
Anzustreben: 1 Karte für alle Branchen (IEP = intersector electronic purse).
Kabellose Kommunikation
Mobilfunk:
Standard GSM (group special mobile, weiterentwickelt zu global system for mobilcommunication),
enthält gute Verschlüsselung für D-Netz (Standard vorher: Verschlüsselung nur bis Basisstation, d. h. erster Funkmast).
Forderungen: Authentikation der Teilnehmer (speziell zur Abrechnung),
Geheimhaltung der Kunden-Identität sowie der Verkehrs- und Nutzdaten.
1) Authentikation mit challenge-response
SIM = subsriber identify module = Chipkarte
AUC = authentication center
VLR = visitor location register
MSR = mobile station register
RAND = challenge
KI = token
2) Erzeugung des Chiffrierschlüssels KC
TMSI = temporary subscriber identification number (wird von Zeit zu Zeit von Zentrale an Mobilstation gesendet, um
Identität nicht preiszugeben)
BSS = Betreiber-Station
3) Verschlüsselung (durchgängig bei Siemens-Krypto-Handy)
W-LAN / Wave-LAN (wireless = kabellos): Basis-Sicherheit WEP (wired equivalent privacy) im Standard IEEE 802.11:
Klartext + Prüfsumme ICV
XOR
Schlüssel = RC4 (Initialisierungsvektor IV + shared key)
-------------------------------------------------------------------------------------------------Schlüsseltext
problematische Schlüsselverwaltung (vorher nur verschleierte Netznamen, Verschlüsselung des Netzverkehrs auf
MAC-Ebene:
media access control: OSI-Schicht 2A) und weitere Schwächen (Schlüssel kann u.U. rekonstruiert werden).
Authentikation durch gemeinsame Schlüssel oder offene Authentikation
Verbesserungen: WEP2 mit 128-bit-Informationsverarbeitung, WEPplus (Agere Systems, lässt keine schwachen
Schlüssel zu),
Fast Packet Keying (RSA Data Security), Port Bases Access Control (IEEE 802.IX)
WEP gilt aber insgesamt als unsicher.
WPA = WiFi protected access (IEEE 802.11i) [Wifi = wireless fidelity]:
WEP mit dynamischem Schlüssel (TKIP-Verfahren);
aber zu knacken mit Beck-Tews-Methode und Ohigashi-Morii-Variante (einzelne Pakete werden entschlüsselt
und manipuliert wieder eingeschleust); deshalb jetzt aktuell:
WPA2 (seit 2004): Verschlüsselung nach AES, TKIP oder CCMP (counter mode / CBC-MAC protocol auf AES-Basis)
Zusätzlich wichtig:
1) gutes Passwort;
2) verschleiernder WLAN-Netzwerkname (SSID = service set identifier), Sichtbarkeit abschalten;
3) nur bestimmten Rechnern Zugriff erlauben (über MAC-Liste),
Gerätesperre für neue (unbekannte) Geräte im WLAN-Router einstellen;
4) VPN einsetzen
WLAN-Schutz-Varianten:
- ungeschützt (kein Kennwort): volle Haftbarkeit bei Missbrauch
- schwacher Schutz (kurzes WPA2-Kennwort)
- ungenügender Schutz (WEP-Schlüssel, MC-Filter, SSID-Schleier): angreifbar (PTW-Attacke, FMS/Korek-Methode)
- ausreichender Schutz (langer WPA2-Schlüssel mit 8 – 16 Stellen und nicht nur Buchstaben;
Gast-Zugang, um gelegentlich ohne Bedenken Gästen den eigenen Internet-Zugang zur Verfügung stellen zu können)
Bluetooth:
Verschlüsselung: 128-bit-Initialisierungsschlüssel aus 16-stelliger PIN + Geräteadresse + Zufallszahl,
damit wird link key für jede Verbindung ausgetauscht;
damit wird encryption key generiert (8 – 128 bit);
Authentikation mit challenge-response.
© kd rieck
febr. 2015