U-Proove

U-Prove ist eine Technologie, zum Schutz der Privatsphäre durch Verschlüsselung und minimale Datenübermittlung. Durch den Einsatz von kryptographischen Verfahren wird die Abstraktion von signierten Daten möglich. Dabei ist trotzdem die zweifelsfreie Identifizierung möglich und es werden überprüfbare und akkurate Informationen geliefert. Die Technologie wurde von Credentica entwickelt und durch Microsoft veröffentlicht.

U-Prove Logo <ref>http://informationcard.net/sites/default/files/U_Prove_RGB.jpg - U-Prove Logo</ref>

Grundlagen

Beispiel: Bezahlt man heutzutage mit einer Kreditkarte liefert man dem Kreditkartenprovider mehr oder weniger freiwillig viele Informationen. Beispielsweise was man wo, bei wem und wann kauft. Das vermindert für den Dienstleister (oder Warenanbieter) und den Käufer zwar verschiedene Risiken, öffnet aber auch alle Türen zu unseren Daten und unserer Privatsphäre. Es besteht deshalb ein Gegensatz zwischen dem für die Abwicklung einer Transaktion nötigen Vertrauen und der Wahrung der Privatsphäre, dem Datenschutz und dem Wunsch nach Anonymität. Außerdem müssen um dieses Vertrauensverhältnis aufzubauen detaillierte, überprüfbare, zweifelsfreie, vertrauenswürdige und akkurate Informationen bereitgestellt werden können. U-Prove macht es möglich nur so viel wie nötig aber so wenig wie möglich preiszugeben. Hier wird die Privatsphäre durch Verschlüsselung und minimale Offenlegung geschaffen.

Geschichte, Hintergrund

Credentica ist eine kanadische Firma mit Ihrem Sitz in Montreal. Gründer der Firma ist Stefan Brands, der zuvor Systeme wie DigiCash und Zero-Knowledge auf den Weg gebracht hat.<ref>http://en.wikipedia.org/wiki/Stefan_Brands - Informationen zu Stefan Brands</ref> Die Schwerpunkte von Credentica liegen in den Bereichen Sicherheitssoftware, kryptografische Technologien und Identitätsmanagement im Internet, auf mobilen Endgeräten und auf Smart-Cards.

Am 08. März 2004 verkündet die Firma Credentica auf Ihrer Webseite, dass die Alphaversion von Ihrer U-Prove Java SDK fertiggestellt wurde. Im April 2005 wird dann bereits die Betaversion von U-Prove herausgegeben, gefolgt vom Release-Kandidaten im Oktober 2006. Wenige Monate später, im Februar 2007, gibt Credentica dann ihr abgeschlossenes U-Prove Produkt heraus.

Am 06. März 2008 kauft Microsoft die U-Prove Technologie von Credentica, um diese in Microsoft eigene Authentifizierungs- und Identitätsplattformen zu integrieren. Außerdem soll U-Prove durch Microsoft der Öffentlichkeit als frei zugängliche Spezifikation zugänglich gemacht werden.<ref>http://www.credentica.com/ - Webseite von Credentica</ref>

Im März 2010 gibt Microsoft dann die erwartete freie Spezifikation unter dem OSP (Open Specification Promise) heraus. Unter OSP werden Spezifikationen von verschiedenen Datenformaten und Protokollen veröffentlicht. Diese Art Lizenz räumt jedem Nutzer das Recht ein, die Spezifikationen von Microsoft in eigener nicht kommerzieller Software zu implementieren ohne auf mögliche Kosten oder Patentrechte zu achten.<ref>http://www.heise.de/developer/artikel/Kennzeichen-S-icherheit-U-Prove-Microsofts-Technik-fuer-Datensicherheit-955744.html - Felix Gaehtgens (heise): Kennzeichen S(icherheit): U-Prove - Microsofts Technik für Datensicherheit</ref> Neben einem SDK in C# hat Microsoft auch eine Java Variante der Implementierung beibehalten. Zuletzt wird durch Microsoft im Februar 2011 eine neue U-Prove CTP (Community Technology Preview) herausgegeben. Hierbei handelt es sich um eine Art Microsoft-Software-Vorabversion und kann im Entwicklungsstadium als eine Beta-Version verstanden werden.

Im Hause Microsoft werden Identitätstechnicken in zwei Sparten unterteilt. Auf der einen Seite gibt es die Windows Identity Foundation die als Framework zu verstehen ist, welches zur Entwicklung von Anwendungen dient, die identitätsabhängig sind. Zum Anderen gibt es die Microsoft Active Directory Federation Services. Hierbei handelt es sich um ein webbasiertes System, mit dessen Hilfe Benutzer authentifiziert werden können, die sich außerhalb der Active Directory Umgebung befinden. Kopf der Identitätssparte von Microsoft ist Kim Cameron. Dieser ist Chief Architect von Micrisoft Access sowie der Entwicklung von InfoCard und CardSpace.<ref>http://msdn.microsoft.com/en-us/library/aa480189.aspx - Microsoft: Introducing Windows CardSpace</ref><ref>http://en.wikipedia.org/wiki/Kim_Cameron_(computer_scientist) - Informationen zu Kim Cameron</ref> Auch an der Umsetzung von U-Prove war Kim Cameron beteiligt.

Technik

Durch das Prinzip der Multi-Party-Security wird ein Schutz vor Falschaussagen hergestellt. Die Nutzung eines Private Keys, der für jeden User einzigartig sein sollte, schafft weitere Absicherung. In der Verschlüsselung werden das Challenge Response und das Zero-Knowledge Prinzip verwendet. Außerdem wird ein Abstraktionsprinzip bereitgestellt, das es sogar zulässt nur mittzuteilen ob jemand volljährig ist aber nicht wann die Person geboren ist. Desweiteren erlaubt dieses Abstraktionsprinzip nur die für die jeweilige Transaktion wichtigen Attribute einer Person (Name, Alter, Adresse, Rolle in der Firma etc.) an die Relying Party weiterzugeben.

Anwendungsgebiete

E-government

Citizen to government
Government to citizen
Company to government
Employee to government
Government to government

DisconnectedFederation

Häufig mit bereits bestehenden Techniken wie VPN-Netzwerken oder Der Anmeldung per RSA-Token gelöst, ist auch eine Kombination dieser Techniken mit der U-Prove Technologie denkbar.

Online Einkäufe

Wenn man online einkauft muss man oft eine große Menge persönlicher Informationen übermitteln um das benötigte Vertrauensverhältnis herzustellen.

Ein typisches Protokoll

Die U-Prove Technologie ist sehr eng an typische, bereits bekannte Protokolle angelehnt. Hierzu zählen konventionelle 3 Parteien Authentifizierungstechnologien für die Ausgabe und Präsentation von Sicherheitstoken wie zum Beispiel Zertifikate der Public-Key-Infrastruktur (PKI wird dazu genutzt digitale Zertifikate auszustellen, zu verteilen und zu prüfen<ref>http://de.wikipedia.org/wiki/Public-Key-Infrastruktur - Wikipedia: PKI(Public-Key-Infrastruktur)</ref>).

Das Typische Protokoll in solchen Szenarien umfasst die 3 Teilnehmer

Identity Provider (Issuer: Ausstellende Behörde oder Instanz)
Relying Party (Verifier: Dienstanbieter bzw. die Instanz bei der man sich authentisieren möchte)
User (Proofer: Der Kunde oder die Person die sich authentisieren möchte)

Der User versucht Zugriff auf einen Service oder auf Ressourcen der Relying Party zu bekommen.
Die Relying Party verlangt einen Beweis, dass sie den Angaben des Users vertrauen kann und teilt außerdem mit, welchem Identity Provider Sie vertraut. Es erfolgt eine Weiterleitung des Users von der Relying Paty zum Identity Provider.
Für gewöhnlich muss beim Identity Provider ein Login durch den User erfolgen. Daraufhin gibt dieser dem User einen signierten Token aus. Der Token wird wieder zurück an die Relying Party geleitet.
Die Relying Party prüft den Token und stellt fest, dass der User vertrauenswürdig ist. Daraufhin erhält der User den gewünschten Zugriff.

Mögliche Probleme eines typischen Protokolls

Bei der Tokenabfrage auf Verlangen (on Demand) muss der IdentityProvider immer online sein und in der Lage sein auch Spitzenaufkommen zu verarbeiten. Auch seitens der Relying Party, kann durch verlängerte Wartezeiten (der ID-Provider kann nicht schnell genug verifizieren) eine Art Flaschenhals entstehen. Denial-of-Service Attacken sind denkbar.

Ein Problem mit der Privatsphäre könnte entstehen wenn das Nutzverhalten eines Users durch den ID-Provider gespeichert wird oder Transaktionen nachverfolgt werden. Möglich wäre auch anhand von Matching-Tabellen zwischen ID-Provider und Relying Party verschiedene Bewegungsprofile aufzustellen.<ref>http://channel9.msdn.com/shows/Identity/Deep-Dive-into-U-Prove-Cryptographic-protocols/ - Stefan Brands: Deep Dive into U-Prove Cryptographic protocols</ref>

Die von U-Prove ausgestellten Token müssen geschützt werden, auch hier ist die Sicherheit nur so hoch wie das schwächste Passwort. Legt ein User beispielsweise eine bestimmte Menge Token auf seinem Laptop ab und schützt diesen nicht mit einem ausreichenden Passwort oder Verschlüsselung der Festplatte, können Diebe oder Finder auf einfache Weise die Token entwenden.

Das U-Prove Protokoll

Das Protokoll von U-Prove basiert im Gegensatz zu typischen Protokollen auf zwei separaten Protokollen. Dem Ausgabeprotokoll, zum Ausstellen eines Tokens für den User und dem Vorlageprotokoll, zur Vorlage eines Tokens bei dem Geschäft. Als Grundlage hierfür muss der „Verifier“ dem „Issuer“ immer vertrauen.

„Am einfachsten lässt sich dies am Beispiel eines Personalausweises erläutern. Dieser wird durch eine Behörde ausgegeben („Issuer“) und vom Inhaber („Prover“) eingesetzt, der sich bei einem Dritten („Verifier“) damit ausweist.“<ref>Gaethgens, Felix "Schattenspiel, Microsoft bringt U-Prove-API als Open Source". In: Heise Zeitschriften Verlag GmbH & Co. KG (Hg.): iX – Magazin für professionelle Informationstechnik. 5/2010. Seite 35.</ref>.

Bei U-Prove handelt es sich im Grunde um eine kryptografische Technologie und den Einsatz einer neuen Art von Security-Token. Der Token enthält einen User-Public-Key, der einzigartig für jeden Token ist. Außerdem wird der Token im Protokoll mit dem „Issuer“ ausgehandelt. Der Datenaustausch erfolgt somit über gesicherte Tokens.<ref>http://channel9.msdn.com/Shows/Identity/U-Prove-CTP-A-Developers-Perspective - Christian Paquin and Greg Thompson: U-Prove CTP A Developers Perspective</ref> Der Einsatz des Tokens verläuft folgendermaßen:

Ausgabeprotokoll	Vorlageprotokoll
	1) Der Prover versucht Zugriff auf einen Service oder auf Ressourcen des Verifier zu bekommen.
	2) Der Verifier verlangt einen Beweis, dass er dem Prover vertrauen kann.
3) Der User kann einen Token aus seinem Token-Store (eine Ablage von bereits generierten Token) nutzen. Liegt kein passender Token vor, fordert er einen Token beim Issuer an.
4) Der Token wird zwischen Prover und Issuer ausgehandelt. Daraufhin gibt der Issuer dem Prover einen signierten Token aus, in dem sich die Daten und ein korrespondierender User-Key, zu dem geheimen Key des Provers, befinden.
	5) Der Prover legt den signierten Token beim Verifier vor.
	6) Der Verifier verlangt einen Beweis darüber, dass der Prover den korrespondierenden Schlüssel zu dem Key im Token kennt. Über ein Challenge-Response Verfahren beweist der Prover dem Verifier, dass er den Key kennt.
	7) Der Verifier stellt fest, dass der Prover vertrauenswürdig ist. Daraufhin erhält der Prover den gewünschten Zugriff.

Der U-Prove Token

Die zentrale Einheit dieses Systems ist ein Token, in dem die zu übertragenden Informationen gespeichert sind. Der Token enthält Informationsfelder, die oben bereits genannten Attribute und Identifikationsfelder.

Außerdem enthält der Token ein Zertifikat das die Echtheit und Unversehrtheit des Token gewährleistet. Token sind unveränderbar. Es gibt sowohl software-Token als auch auf Smartcards gespeicherte Token. Zwei Arten von Token bieten mehr Flexibilität im Gebrauch der Technologie: Die Long-Lived-Tokens können auf Vorrat gespeichert werden und bei Bedarf benutzt werden, dabei muss der Id-Provider zur Zeit der Benutzung nicht online sein. Die On-Demand-Tokens werden in Echtzeit abgefragt d.h. der Id-Provider muss online sein. Diese Methode schützt z.B. vor Replay-Angriffen. <ref>https://abc4trust.eu/index.php/press/2011-11-08-14-42-18 abc4trust - abc4trust: U-Prove</ref>

Der User besitzt einen privaten Schlüssel oder auch „Private Key“, den nur er kennt und den er niemals preisgibt. Auf Basis dieses Private Keys wird der Public Unique User Key erzeugt. Mittels eines Zero-Knowledge Verfahrens kann der Besitz des privaten Schlüssels unter Zuhilfenahme des Public Keys verifiziert werden.

Das Prinzip bestimmte Daten zu verbergen bzw. nur bestimmte Daten preiszugeben nennt man "selective disclosure". Damit dabei die Gültigkeit und Integrität des Tokens erhalten bleiben wird alles übertragen aber nur der Teil offengelegt, der für die aktuelle Transaktion notwendig ist. In einem Standartverfahren würde man Die Attribute mit einem Salt versehen und hashen (um Brute-Foce-Attacken zu erschweren) und das ganze danach signieren.

Bei UProve sorgt eine besondere Funktion dafür, dass die Attribute sicher aufgehoben sind, der Public Key aber noch lesbar ist, da dieser zur Verifizierung des Tokens gebraucht wird. Und erst danach wird das Packet signiert.<ref>http://channel9.msdn.com/shows/Identity/Deep-Dive-into-U-Prove-Cryptographic-protocols/ - Stefan Brands: Deep Dive into U-Prove Cryptographic protocols</ref>

Stärken

Die Verwendung des Token ohne die Zustimmung des Benutzers ist nicht möglich, da die Fälschungssicherheit des Token durch die kryptografische Technik gewährleistet wird.

Das Ausspähen eines Tokens oder das Mitschneiden des Datenaustauschs liefert keine Informationen über die Identität des Benutzers, denn die Daten sind entweder verborgen oder abstrahiert.

Die böswillige Nutzung eines langlebigen Token kann zum Einen dadurch verhindert werden, dass der Issuer den Token wiederrufen kann und zum anderen besteht ein Dieb das Challenge-Response Verfahren nicht.

Die Verfolgung des Nutzers durch die Absprache zwischen beteiligten Parteien ist aufgrund des Einsatzes von zwei Protokollen, für Ausstellung und Verwendung, nicht möglich. Zusätzliche Sicherheit bietet außerdem die besondere Verschlüsselung.

Daten können nur bedingt durch Datensammler gespeichert werden, denn die Daten können versteckt oder abstrahiert werden. Außerdem können Null-Daten-Aussagen getroffen werden, wie „Ich bin keiner der Prover, die auf deiner Black List stehen“.

Schwächen

Es gibt keine Garantie dass Microsoft auch zukünftige Versionen unter dem OSP<ref>http://msdn.microsoft.com/de-de/library/bb979152.aspx: Microsoft Open Specification Promise</ref> veröffentlicht, d.h. jeder Programmierer, der eine Microsoft-Spezifikation unter OSP implementiert, läuft theoretisch Gefahr, mit deren nächsten Version kein Recht mehr zu haben die von Microsoft adaptierten Technologien weiter benutzen zu dürfen.

Der Code darf nur zur Umsetzung der Spezifikation und zu keinem anderen Zweck eingesetzt werden, daraus folgt, dass der Microsoft Code nicht weiterverwendet werden kann um z.B. die Kommunikation zwischen Spaceshuttles zu erleichtern.

Der kommerzielle Vertrieb ist nicht gestattet. Was die folgende Frage aufwirft: Was passiert wenn ein Open Source Entwickler zu seinem kostenlosen Open Source Projekt, einen kostenpflichtigen Support verkaufen möchte?<ref>http://www.heise.de/open/artikel/Die-Woche-Offen-genug-fuer-die-GPL-221490.html - Dr. Oliver Diedrich (heise) Offen genug für die GPL? Microsofts neue Offenheit und die GPL</ref>

Die Zukunft

Es existiert ein Projekt mit dem Namen „Attribute Based Credentials for Trust (ABC4Trust)“, welches im Pilotversuch den Fokus auf Datenschutz fördernde Techniken setzt. An dem Pilotversuch nehmen Schüler einer schwedischen Schule und Studenten der Patras-Universität in Griechenland teil. Das Projekt startete im Herbst 2010 und soll im Herbst 2013 abgeschlossen werden. Ziel ist es Stellungnahmen aus der Sicht des Nutzers zu datenschutzfördernden Techniken zu erhalten, wobei besonders die Meinungen bezüglich Benutzerfreundlichkeit und Handhabung berücksichtigt werden sollen. Geprüft werden neben Technologien wie U-Prove auch der IBM Identity Mixer. Die Ergebnisse werden durch das ABC4Trust Konsortium genutzt, um Anregungen zur Verbesserungen der Referenzimplementierung weiterzugeben.<ref>https://abc4trust.eu/index.php/news/archived-news/151-patraslaunch/ - abc4trust: U-Prove News</ref>

Fazit

Es handelt sich bei U-Prove um eine beeindruckende Technologie, die den großen Wunsch der User nach Anonymität und Privatsphäre erfüllen könnte. Es wäre schön wenn dieses Verfahren öfter Einsatz finden würde, doch leider scheint U-Prove in den letzten Monaten aus den Medien verschwunden zu sein. Außerdem steht im Gegensatz zur Anonymität natürlich das bestreben vieler Firmen Datamining im Sinne einer besseren Marketing Strategie und höherer Gewinnspannen einzusetzen.

Literatur

Gaethgens, Felix "Schattenspiel, Microsoft bringt U-Prove-API als Open Source". In: Heise Zeitschriften Verlag GmbH & Co. KG (Hg.): iX – Magazin für professionelle Informationstechnik. 5/2010. Seite 35.

Brands, Stefan "Rethinking Public Key Infrastructures and Digital Certificates: Building in Privacy". The MIT Press; 1st edition (August 28, 2000). ISBN-13: 978-0262024914. Inahlt In diesem Buch schlägt Stefan Brands kryptographische Bausteine für das Design von digitalen Zertifikaten vor, die die Privatsphäre ohne Abstriche bei der Sicherheit, bewahren.