U-Proove - Revision history

141.20.192.212: /* Stärken */

2013-01-24T14:28:46Z

Stärken

← Older revision		Revision as of 14:28, 24 January 2013
Line 149:		Line 149:
	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 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 ~~von öffentlichem Schlüssel, Signatur und Daten im Token~~.		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“.		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“.

141.20.192.212: /* Der U-Prove Token */

2013-01-24T14:27:50Z

Der U-Prove Token

← Older revision		Revision as of 14:27, 24 January 2013
Line 128:		Line 128:
	Es gibt sowohl software-Token als auch auf Smartcards gespeicherte Token.		Es gibt sowohl software-Token als auch auf Smartcards gespeicherte Token.
	Zwei Arten von Token bieten mehr Flexibilität im Gebrauch der Technologie:		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 ~~Real Time~~ abgefragt d.h. der Id-Provider muss online sein. Diese Methode schützt z.B. vor Replay-Angriffen. {{#tag:ref\|https://abc4trust.eu/index.php/press/2011-11-08-14-42-18 abc4trust - abc4trust: U-Prove}}		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. {{#tag:ref\|https://abc4trust.eu/index.php/press/2011-11-08-14-42-18 abc4trust - abc4trust: U-Prove}}

	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 ~~private~~ ~~Schlüssel~~ unter Zuhilfenahme des Public Keys verifiziert werden.		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 ~~selectiveDisclosure~~. Damit dabei die Gültigkeit und Integrität des Tokens erhalten bleiben wird alles übertragen aber nur der Teil ~~entschlüsselt~~, 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.		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.

	[[File:U-Prove Hash.jpg\|center]]		[[File:U-Prove Hash.jpg\|center]]

141.20.192.212: /* Das U-Prove Protokoll */

2013-01-24T14:24:29Z

Das U-Prove Protokoll

← Older revision		Revision as of 14:24, 24 January 2013
Line 79:		Line 79:
	== Das U-Prove Protokoll ==		== Das U-Prove Protokoll ==

	Das Protokoll von U-Prove basiert im Gegensatz zu typischen Protokollen auf zwei ~~unterschiedlichen~~ 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.		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.“{{#tag: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.}}.		„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.“{{#tag: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.}}.

141.20.192.212: /* Mögliche Probleme eines typischen Protokolls */

2013-01-24T14:23:28Z

Mögliche Probleme eines typischen Protokolls

← Older revision		Revision as of 14:23, 24 January 2013
Line 71:		Line 71:
	== Mögliche Probleme eines typischen Protokolls ==		== 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.		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.{{#tag:ref\|http://channel9.msdn.com/shows/Identity/Deep-Dive-into-U-Prove-Cryptographic-protocols/ - Stefan Brands: Deep Dive into U-Prove Cryptographic protocols}}		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.{{#tag:ref\|http://channel9.msdn.com/shows/Identity/Deep-Dive-into-U-Prove-Cryptographic-protocols/ - Stefan Brands: Deep Dive into U-Prove Cryptographic protocols}}

	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.		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.

141.20.192.212: /* Ein typisches Protokoll */

2013-01-24T14:22:36Z

Ein typisches Protokoll

← Older revision		Revision as of 14:22, 24 January 2013
Line 55:		Line 55:
	== Ein typisches Protokoll ==		== 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 ~~Ausgaben~~ 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{{#tag:ref\|http://de.wikipedia.org/wiki/Public-Key-Infrastruktur - Wikipedia: PKI(Public-Key-Infrastruktur)}}).		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{{#tag:ref\|http://de.wikipedia.org/wiki/Public-Key-Infrastruktur - Wikipedia: PKI(Public-Key-Infrastruktur)}}).

	Das Typische Protokoll in solchen Szenarien umfasst die 3 Teilnehmer		Das Typische Protokoll in solchen Szenarien umfasst die 3 Teilnehmer
Line 65:		Line 65:

	# Der User versucht Zugriff auf einen Service oder auf Ressourcen der Relying Party zu bekommen.		# Der User versucht Zugriff auf einen Service oder auf Ressourcen der Relying Party zu bekommen.
	# Die Relying Party verlangt einen Beweis, dass sie ~~dem~~ ~~User~~ vertrauen kann und teilt außerdem mit, ~~dass sie dem~~ Identity Provider vertraut. Es erfolgt eine Weiterleitung des Users von der Relying Paty zum Identity Provider.		# 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.		# 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.		# 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.

141.20.192.212: /* Geschichte, Hintergrund */

2013-01-24T14:20:38Z

Geschichte, Hintergrund

← Older revision		Revision as of 14:20, 24 January 2013
Line 19:		Line 19:
	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.{{#tag:ref\|http://www.credentica.com/ - Webseite von Credentica}}		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.{{#tag:ref\|http://www.credentica.com/ - Webseite von Credentica}}

	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.{{#tag: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}} Neben einem SDK in C# hat Microsoft auch eine Java Variante der ~~Spezifikation~~ beibehalten.		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.{{#tag: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}} 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.		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.

141.20.192.212: /* Geschichte, Hintergrund */

2013-01-24T14:19:54Z

Geschichte, Hintergrund

← Older revision		Revision as of 14:19, 24 January 2013
Line 13:		Line 13:
	== Geschichte, Hintergrund ==		== 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~~-Systeme~~ auf den Weg gebracht hat.{{#tag:ref\|http://en.wikipedia.org/wiki/Stefan_Brands - Informationen zu Stefan Brands}} Die Schwerpunkte von Credentica liegen in den Bereichen Sicherheitssoftware, kryptografische Technologien und Identitätsmanagement im Internet, auf mobilen Endgeräten und auf Smart-Cards.		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.{{#tag:ref\|http://en.wikipedia.org/wiki/Stefan_Brands - Informationen zu Stefan Brands}} 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 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.

141.20.192.212: /* Grundlagen */

2013-01-24T14:19:25Z

Grundlagen

← Older revision		Revision as of 14:19, 24 January 2013
Line 7:		Line 7:
	== Grundlagen ==		== Grundlagen ==

	Beispiel: Bezahlt man heutzutage mit einer Kreditkarte liefert man dem Kreditkartenprovider mehr oder weniger freiwillig ~~alle möglichen~~ 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.		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.		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 ~~Datenübermittlung~~ geschaffen.		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 ==		== Geschichte, Hintergrund ==

141.20.192.212: /* Mögliche Probleme eines typischen Protokolls */

2013-01-24T14:18:34Z

Mögliche Probleme eines typischen Protokolls

← Older revision		Revision as of 14:18, 24 January 2013
Line 74:		Line 74:
	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.		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.{{#tag:ref\|http://channel9.msdn.com/shows/Identity/Deep-Dive-into-U-Prove-Cryptographic-protocols/ - Stefan Brands: Deep Dive into U-Prove Cryptographic protocols}}		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.{{#tag:ref\|http://channel9.msdn.com/shows/Identity/Deep-Dive-into-U-Prove-Cryptographic-protocols/ - Stefan Brands: Deep Dive into U-Prove Cryptographic protocols}}

	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.		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.

C.mundhenk: /* Der U-Prove Token */

2013-01-22T14:22:10Z

Der U-Prove Token

← Older revision		Revision as of 14:22, 22 January 2013
Line 124:		Line 124:
	Der Token enthält Informationsfelder, die oben bereits genannten Attribute und Identifikationsfelder.		Der Token enthält Informationsfelder, die oben bereits genannten Attribute und Identifikationsfelder.

	[[File:U-Prove Token Aufbau.jpg]]		[[File:U-Prove Token Aufbau.jpg\|center]]

	Außerdem enthält der Token ein Zertifikat das die Echtheit und Unversehrtheit des Token gewährleistet. Token sind unveränderbar.		Außerdem enthält der Token ein Zertifikat das die Echtheit und Unversehrtheit des Token gewährleistet. Token sind unveränderbar.
Line 135:		Line 135:
	Das Prinzip bestimmte Daten zu verbergen bzw. nur bestimmte Daten preiszugeben nennt man selectiveDisclosure. Damit dabei die Gültigkeit und Integrität des Tokens erhalten bleiben wird alles übertragen aber nur der Teil entschlüsselt, 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.		Das Prinzip bestimmte Daten zu verbergen bzw. nur bestimmte Daten preiszugeben nennt man selectiveDisclosure. Damit dabei die Gültigkeit und Integrität des Tokens erhalten bleiben wird alles übertragen aber nur der Teil entschlüsselt, 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.

	[[File:U-Prove Hash.jpg]]		[[File:U-Prove Hash.jpg\|center]]

	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.{{#tag:ref\|http://channel9.msdn.com/shows/Identity/Deep-Dive-into-U-Prove-Cryptographic-protocols/ - Stefan Brands: Deep Dive into U-Prove Cryptographic protocols}}		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.{{#tag:ref\|http://channel9.msdn.com/shows/Identity/Deep-Dive-into-U-Prove-Cryptographic-protocols/ - Stefan Brands: Deep Dive into U-Prove Cryptographic protocols}}

	[[File:U-Prove Function.jpg]]		[[File:U-Prove Function.jpg\|center]]

	== Stärken ==		== Stärken ==