Datenschutz

Kapitel der Vorlesung Datenschutz und Informationelle Selbstbestimmung Datenschutzgesetze Digitale Identifikation und Authentifizierung Privatheit und Privacy Enhancing Technologies Datenschutz im E-Commerce Identitätsmanagement Ubiquitous Computing und RFIDs

E-Business Mythen … (nach Roger Clarke) Mythos Identifikation ist normal Anonymität ist ein Sonderfall Sichere Authentifizierung von Identität ist eine Notwendigkeit Identitätsdiebstahl ist ein neues Phänomen, es ist ein schreckliches Verbrechen und rechtfertigt harte Maßnahmen Realität Anonymität ist normal Identifikation ist die Ausnahme, nicht die Regel Authentifizierung von Identität ist nur manchmal wichtig; die notwendige Sicherheit hängt von der Anwendung ab Identitätsdiebstahl hat es immer gegeben und wird auch immer möglich sein

E-Business Mythen … (Forts.) Anonymität wird nur von Kriminellen genutzt Anonymität schließt Verantwortung aus Authentifizierung in der realen Welt ist sicher Authentifizierung in der digitalen Welt muss noch sicherer sein Realität Anonymität wird von vielen Personen aus verschiedenen Gründen benutzt Identifizierung ist nur ein Mittel zu Verantwortlichkeit Authentifizierung in der realen Welt ist unsicher Die digitale Welt kann und wird nicht sicherer sein

E-Business Mythen … (Forts.) Privatheit ist nur etwas für Personen, die etwas zu verbergen haben Personen, die etwas zu verbergen haben sind nur Kriminelle Realität Privatheit ist nur etwas für Personen, die etwas zu verbergen haben Jeder hat das Recht etwas zu verbergen (Informationelle Selbstbestimmung …)

E-Business Mythen … (Forts.) Biometrische Identifizierung ist unbestreitbar Biometrische Datenbanken sind ein Mittel alle Authentifizierungsprobleme zu lösen Realität Biometrische Verfahren hängen von Toleranzen ab um falsche Positive und falsche Positive im Gleichgewicht zu halten Biometrische Eigenschaften stellen nur eine unveränderbare PIN dar; gespeicherte Werte können benutzt werden um Artefakte zu erzeugen, die Maskierung erlauben

Was ist Electronic Commerce? bisher keine eindeutige und allgemein akzeptierte Definition allgemeine Perspektive: „alle Formen der elektronischen Geschäftsabwicklung über öffentliche oder private Computernetzwerke“ [Hermanns1999, S.14] Geschäftsabwicklung (das beinhaltet nicht nur Bestellung, sondern auch andere Prozesse, wie z.B. die Abwicklung der Bezahlung) über Computernetzwerke häufig aber nur Aspekte, die den Bereich des Electronic-Shopping oder Online-Shopping betreffen To build some common ground first some words about what communites and community support are. For us a community is a collection of people who share something – which usually is a common interest in a topic which makes them communities of interest or a common context like the belonging to the same department or the involvement in the same work processes which makes them communities of practice. Networked computers can either support existing communities in better exchanging information or even lay the ground for new communities that would no exist without this support. Basic support concepts are: 1) provide medium, 2) support exchange/flow, 3) help finding people Applications for community support are well known, both under the label of Knowledge Management and others (e.g. CSCW): document repositories with notification features, buddy list applications, online communies in different flavours The problem with all theses systems is that they are not able to exchange information with each other or to reuse information, they additionally offer different access protocols (mainly interactive) which makes it hard to submit information to more than one of them or to request information from more than one of them

Bandbreite von Electronic Commerce Reisebüros Reservations- und Buchungssysteme der Fluglinien Automobilhersteller Zusammenarbeit mit Zulieferern über Electronic Data Interchange (EDI) Banken Wertpapiergeschäfte über Internet Internet Shops

E-Business (yet another overview) Supply Chain Management Customer Relationship Management E-Business E-Procurement E-Commerce Geschäfts- partner Kunden Extranet Internet Mein Unternehmen Intranet Verwaltung und Behörden Bürger und Unternehmen E-Government Quelle: Schubert, Wölfle 2000

Klassifizierungsmöglichkeiten E-Commerce „Rechnernetzbasierte Geschäftsabwicklung“ nach beteiligten Partnern Business, Consumer Administration, ... nach unterstützten Phasen der Geschäftsabwicklung Informationsphase Vereinbarungsphase Abwicklungsphase After-Sales-Phase

Beteiligte Partner E-Procurement

Beteiligte Partner Endkunde Partner Lieferanten Dienstleister (Staat) Privatkunden Firmenkunden Partner Lieferanten Dienstleister Spediteure Banken (Staat)

ABC-Klassifizierung Klassifizierung von Electronic Commerce Szenarien nach den Nachfrager- und Anbietertypen Nachfrager/Anbieter - Rollen B – Business C – Consumer A/G – Administration / Government A C B

ABC-Klassifizierung ... B2* B2B (Business to Business) Bestellung eines Unternehmens bei Zulieferer (E-Procurement) B2C (Business to Consumer) Online-Shops (Buch/Musik, Computer(-Software), Finanz- und Versicherungsbereich, Reisen, ...) B2A (Business to Administration) Steuerabwicklung von Unternehmen, Umsatzsteuer, Körperschaftssteuer

ABC-Klassifizierung ... C2* C2C (Consumer to Consumer, Peer to Peer) Internet-Kleinanzeigenmarkt, Online-Auktionen C2A z.B. Steuerabwicklung von Privatpersonen – Einkommensteuer C2B Jobbörsen mit Anzeigen von Arbeitssuchenden

ABC-Klassifizierung ... A2* Ausschreibungen öffentlicher Institutionen im Internet A2C Abwicklung von Unterstützungsleistungen – Sozialhilfe, Arbeitslosenhilfe A2A Transaktionen zwischen öffentlichen Institutionen im In- und Ausland

Phasen bei Geschäftsabwicklung

Phasen bei Geschäftsabwicklung Elektronische Produktkataloge Information Anbieter Nachfrager Selektion - Unternehmen (Business) - Konsumenten (Consumer) - Öffentliche Institutionen (Administration) z.T. auch über Händler und Intermediäre (z.B. Broker, Market Maker) - Unternehmen (Business) - Konsumenten (Consumer) - Öffentliche Institutionen (Administration) Online-Bestellsysteme Angebot / Verhandlung Auftrag Online-Bezahl und -Distributionssysteme Bezahlung Lieferung Elektronische After-Sales-Systeme Service

Herausforderung an Datenschutz Information / Empfehlungen Vertrauen in empfehlenden Benutzer, Händler (Reputationsindikatoren) Anzeige von (aggregierter) Transaktionsinformation gegenüber anderen Kunden Nutzung der gesammelten Information für Personalisierung auf verschiedenen Kanälen (E-Mail, Telefon-Marketing) Geschäftsabwicklung Verbindlichkeit Lieferadresse Bezahlung

Produktempfehlungen auf Online-Meinungsbörsen

Dooyoo - Reputationsindikatoren

Zahlungssysteme im E-Commerce Bezahlung als ein Bestandteil der Transaktionsbeziehung Es existieren eine Reihe verschiedener Zahlungssysteme bzw. Zahlungsansätze für den eCommerce, die sich ständig weiterentwickeln Kriterien zur Klassifikation von Zahlungssystemen die Transaktionshöhe (Micropayments, Small Payments, Macropayments), der Zeitpunkt der Geldübertragung (pre-paid, pay-now und pay-later) Zahlungsform (traditionelle Methoden wie Homebanking, Übermittlung von Kreditkartendaten, kontenbasiertes Cybermoney, die spezielle Kredit- oder Debitkonten verwenden), digitale Münzen, wie E-Cash, elektronische Geldbörsen, z.b.wiederaufladbare Geldkarten).

Zahlungssysteme – Pre-Paid zeichnen sich dadurch aus, dass der Kunde vor dem Einkauf im Internet bereits einen bestimmten Geldbetrag aufgewendet haben muss Sie können hard- oder software-basiert sein Hardware-basierte Zahlungssysteme sind z.B. Geldkarten wie Smart Cards Beim Kauf wird der entsprechende Betrag abgebucht

Zahlungssysteme – Pre-Paid Software-basierte Zahlungssysteme sind z.B. E-Cash, CyberCoin, PaysafeCard Installation einer speziellen Software erforderlich Beispiel E-Cash: münzbasiertes Verfahren, bei dem der Gegenwert der Münzen bei einer Bank hinterlegt wird Versand der Münzen erfolgt über ein spezielles Protokoll Beim Bestellvorgang wird der betreffende Münzbetrag vom Käufer eingeholt, der den Zahlungsvorgang bestätigen muss und damit den Münztransfer auslöst. Der Verkäufer kann die Münzen dann beim Bankserver einlösen. Dieser verifiziert die Echtheit und die Gültigkeit. Die Ware kann ausgeliefert werden

Zahlungssysteme – Pre-Paid Beispiel paysafeCard: Geldkarte mit einem bestimmten Wert Der Einkauf erfolgt unter Angabe eines 16-stelligen PIN-Codes und Passwortes Ein paysafeCard-Server prüft das Guthaben, die Karte wird gemäß des Kaufpreises belastet und die Zahlung an den Verkäuer erfolgt

Zahlungssysteme – Pay-Now (Debit) Bei diesen Zahlungssystemen wird das Konto des Kunden in dem Moment belastet, zu dem er tatsächlich etwas kauft bzw. die Ware erhält. Mobile Payments: die Zahlung erfolgt hierbei über Handy Bsp.: Paybox: Idee ist die, dass jedes Handy über den persönlichen PINCode einer bestimmten Person zugeordnet ist. Die Kunden erhalten einen vertrauliche Paybox-PIN. Der Kunde erteilt paybox eine Einzugsermächtigung. Diese stellt die Identität des Kunden fest und prüft seine Bonität. Ablauf: Der Konsument gibt auf der Bezahlseite des Händlers seine Mobilfunknummer an. Der Händler gibt die Nummer und den Betrag an Paybox weiter. Paybox fragt den Kunden via Handy, ob er die Bezahlung bestätigen will. Der Kunde autorisiert die Zahlung durch Eingabe seiiner Paybox-PIN. Die Ware wird geliefert und Paybox zieht den entsprechenden Betrag per Lastschrift ein und überweist ihn auf das Händlerkonto.

Zahlungssysteme – Pay-Now (Debit) Auch Lastschriftverfahren oder Nachnahme können unter pay-now-Systeme subsumiert werden

Zahlungssysteme – per E-Mail Versenden von Geld per E-Mail Beispiel PayPal: amerikanischer Finanzdienstleister, der Geldtransfers zwischen beliebigen Personen ermöglicht (www.paypal.com) Voraussetzungen sind ein e-Mail-Account und eine Kreditkarte zur Identifikation sowie Sicherstellung, dass die Zahlungen über die Kreditkarte auf das normale Girokonto überwiesen werden können. Anmeldung bei PayPal erforderlich. Ablauf: Login auf der PayPal-Website Eingabe des Mail-Adresse des Empfängers, des Betrags und des Grundes der geplanten Zahlung Abbuchung von Kreditkarte Empfänger und Sender erhalten eine Benachrichtigung Einbuchung der Summe beim Empfänger bzw. auf dem PayPal-Konto

Zahlungssysteme – Pay-Later Kredit-Zahlungssysteme hier wird der Geldbetrag für den Einkauf erst einige Zeit nach dem Kauf fällig Zahlung per Kreditkarte: Die Zahlung kann unverschlüsselt oder mittels spezieller Verschlüsselungsverfahren (z.B. SET) erfolgen In Deutschland nur geringfügig genutzt

Zahlungssysteme – Pay-Later Zahlung per Rechnung: vielfach genutzte Zahlungsmöglichkeit, die eine problemlose, da bekannte Zahlungsabwicklung gewährleistet Nachteile liegen für den Verkäufer in den Vorleistungen sowie möglichen Nachleistungen, wie Mahnungen, Eingangskontrolle etc. Iclear: bietet eine Rechnungsvariante, die die Nachteile für den Verkäufer reduzieren soll Der Kunde kann auf Rechnung kaufen. Iclear übernimmt als Trusted Party das mögliche Ausfallrisiko für den Händler Dazu sendet der Kunde beim Bestellen den per mail erhaltenen iclear-Namen an iclear, der Händler erhält lediglich die Lieferadresse Iclear bucht den entsprechenden Betrag dann per Lastschriftermächtigung ab

Zahlungssysteme – Pay-Later BillingSysteme: zeichnen sich dadurch aus, dass die Bezahlung in zwei Bereiche unterteilt wird: einen Kontenbuchungsvorgang bei einem Betreiber und einem Abbuchungsvorgang beim Kunden Bsp.: Net900, MilliCent

SET – Secure Electronic Transaction wurde von VISA und Mastercard etabliert asymmetrisches Public Key Verfahren mit digitalen Zertifikaten Kreditkartendaten werden dem Händler nicht übermittelt Voraussetzungen sind eine spezielle Software, die Registrierung der Kreditkarte für SET, die Erstellung eines SET-Zertifikates, welches auf dem Client gespeichert wird Ablauf: Übermittlung der Bestellung (für den Händler lesbar) und der Kreditkartendaten (verschlüsselt) Übergabe der Kreditkartendaten an das Payment-Gateway, das die Daten entschlüsseln kann Kontrolle durch das PG und ggf. Bestätigung an den Händler Einspeisung in das Kreditkartensystem (verzögert) Quittung an den Kunden

SET - Motivation Kunden: Mißbrauchsängste Keine Kontrolle, was Händler mit den Kreditkartendaten macht Aufwand wegen Stornierung ungerechtfertigter Belastungen Kreditkartenfirmen und Händler: Reklamationsproblem 1 % der Kreditkartenanwendungen über das Internet aber 50 % der Reklamationen Kreditkartenanwendung im Internet ansteigend MOTO-Kreditkartenverwendung Mail Order/Telephon Order erfordert besonderen Händlervertrag Händler bezahlt höhere Gebühren als bei POS-Transaktionen Händler erhält keine Zahlungsgarantie

SET - Szenario Issuer Acquirer Certification Authority (CA) Payment Bank, die dem Kunden eine Kreditkarte ausstellt Bank, die Zahlungs- nachrichten vom Händlers annimmt und verarbeitet (Kundenbank) (Händlerbank) Issuer Acquirer Kunden- beziehung Kunden- beziehung Betreiber Secure financial network Certification Authority (CA) Payment Gateway (PG) Internet Institution, die Schlüssel beglaubigt und Zertifikate ausstellt Verarbeitet Zahlungsnach- richten, betrie- ben von Acquirer oder TTP Verkauft Waren übers Internet, akzeptiert digitale Zahlungen Besitzt eine Kreditkarte und kauft und zahlt digital Cardholder Merchant Übertragung von Geldwert (Kunde) (Händler)

SET - Nachrichtenaufbau SET – Zahlungsvorgang: Internet Kunde Händler Bank

1. Welche Informationen ? 1 2 Internet Kunde Händler Bank OI PI PI OI: Order Information PI: Purchase Information PI 2 OI = Order Information (Artikel-Nr., Anzahl, ...) PI = Purchase Information - OI nicht an die Bank !!!

2. Eindeutigkeit der Zahlung Verwenden einer Transaktions-ID T_ID muss pro Händler eindeutig sein Händler OI 1 PI OI: Order Information PI: Purchase Information PI 2 T_ID Kunde OI‘ = OI + T_ID PI‘ = PI + T_ID - „Init – Runde“ vorschieben : T_ID Bank

3. PI nur von der Bank lesbar Verschlüsseln PI mit “Public Key“ der Bank PI 2 Kunde Händler Bank OI 1 OI: Order Information PI: Purchase Information T_ID Eigentlich Komb. Symmetrisch / asymmetrisch : PI‘‘ = Crypt(Key1) (Pi‘) + CryptPub(Bank) (Key1) Woher weiß der Client den PubKey der Bank ?  Init-Res.

4. Integrität der Daten Signaturen einfügen: Duale Signaturen ! 2 1 OI PI 2 Kunde Händler Bank OI 1 OI: Order Information PI: Purchase Information T_ID Warum reichen separate Signaturen nicht aus ? ... Zum Prüfen: Hashes müssen separat gesendet werden !

5. Authentifizierung Signatur vom Händler erforderlich 1 2 OI Händler PI 2 Kunde Händler Bank OI 1 OI: Order Information PI: Purchase Information T_ID Auth. des Clients ist bereits sichergestellt. Auth. Des Händlers: „Init“ wird signiert ! Visualisierung ????

6. Sicherheit des Händlers Händler kann PI nicht prüfen Prüfung übernimmt die Bank PI 2 Internet Kunde Händler Bank OI 1 OI: Order Information PI: Purchase Information Separates senden von „Amount“ und T_ID erforderlich

7. Bestätigungen senden Bank sendet verschlüsseltes “Capture Token“ 1 PI 2 Internet Kunde Händler Bank OI 1 OI: Order Information PI: Purchase Information Capture Token erläutern ...

SET - Bezahlungsablauf Clearing Issuer Acquirer Capture Abrechnung 6.) Autorisierungsantwort 5.) Autorisierungsanfrage Secure financial network Payment Gateway Internet SET Payment Capture Response 7.) SET Authori- zation Response 4.) SET Authorization Request SET Payment Capture Request 1.) Invoice 3.) SET Purchase Request 2.) Duale Signatur Cardholder Merchant 8.) SET Purchase Response 9.) Goods delivery

SET aus Sicht des Benutzers Vorbereitung: Installieren der “SET-Wallet“ (die Client-Applikation) Karteninformationen eintragen und lokal speichern Anfordern der notwendigen Zertifikate

SET aus Sicht des Benutzers Verwendung:

Stärken von SET Hohes Sicherheitsniveau (höher als bei der traditionellen Kreditkarte) Integration in vorhandene Infrastruktur Verbreitung der Kreditkarte Verwendung der Bankennetze Keine Hardware für den Kunden erforderlich Offener Standard Plattform unabhängig Unabhängig von Sicherheitsprotokollen Unterstützung durch “Big Players“

Schwächen von SET Mangelnde Verbreitung Hohe Komplexität Erhöhter Aufwand für den Benutzer Investitionskosten für den Händler Kosten der Zertifizierungsinfrastruktur Hohe Komplexität Mangelnde Kompatibilität Ungeeignet für Kleinstbeträgen Keine Anonymität

Mögliche Kompromisse SET Lite (certless SET) Verzichtet auf digitale Zertifikate der Kunden Und damit auf die Authentifizierung des Clients MO-SET (merchant-only SET) Verzichtet auf die Installation einer “Wallet“ Client verwendet SSL zum Senden der Kreditkarteninformationen zum Server Zwischen Händler und Bank (Payment Gateway) wird SET verwendet

Duale Unterschrift Verknüpfung der Bestelldaten mit den Kreditkartendaten Nachweisbarkeit einer zweckgebundenen Zahlung ohne überflüssige Informationspreisgabe Bank soll Bestelldaten (Kaufgegenstand) nicht sehen Händler soll Zahlungsautorisierung (Kreditkartendaten) nicht sehen

Duale Unterschrift Duale Unterschrift Payment Gateway Kunde Händler S² = Sign (MD (MD (Zahlungsautorisierung) ° MD (Bestelldaten))) + das jeweils zu verbergende Teildokument als MD Zahlungsautorisierung in Umschlag für PG stecken Payment Gateway S², MD(Bestelldaten), UmschlagPG(Aut.) S², MD(Aut.), UmschlagPG(Aut.) Kunde Händler

Geldkarte im Internet Erste internationale Versuche seit Q3/1999 Anforderungen nur Geldkarte und Smart Card Leser Privatheit / Datenschutz Nicht anonym und nachvollziehbar (“Shadow Accounts”) Online-Shop sieht nur Geldkartennummer

Geldkarte im Internet Issuer Acquirer Customer Merchant Customer c. Load Settlement Issuer Acquirer iii. Clearing Request d. Load Customer Evidence Center Merchant Evidence Center Shadow Account ii. Clearing Request Loading Center Shadow Account i. Deposit Batch of Payments b. Load Loading Machine Customer Geldkarte a. PIN Insert Card To Pay Customer Merchant Merchant Geldkarte

Geldkarte im Internet Issuer Acquirer Customer Merchant Settlement Periodical Deposit Secure financial network Internet 3. Store Payment 1.) Invoice Customer Merchant 2.) Payment message 4.) Goods delivery