This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
U-Prove
U-Prove

Version management

Difference between version and

At line 1 added 83 lines
!!! Overview[1]
[{$pagename}] is a digital [credential] technology for [claims]-based identity management invented by Stefan Brands and developed by Credentica.[1]
[{$pagename}] simultaneously provides for strong [security], scalability, and [privacy] (including [anonymity]), and allows for [claims] to be efficiently tied to the use of [smart Cards]. In 2008, [Microsoft] acquired the technology, including all of the underlying patents, with the stated goal of opening it up.[1]
In March 2010, [Microsoft] announced the release of a [cryptographic] specification and [Open Source] [API] implementation code for part of the [{$pagename}] technologies as a Community Technology Preview under Microsoft's Open Specification Promise.[3]
[{$pagename}] is an innovative [cryptographic] technology that allows users to __minimally__ disclose certified information about themselves when interacting with online [Service Providers]. [{$pagename}] provides a superset of the security features of [Public Key Infrastructure] ([PKI]), and also provide strong [privacy] protections by offering superior user control and preventing unwanted user tracking.
A [{$pagename}] [token] is a type of [credential] similar to [PKI] [certificate] that can encode [attributes] of any type, but with two important differences:[2]
* The issuance and presentation of a [token] is unlinkable due to the special type of [Public Key] and [signature|Digital Signature] encoded in the token; the [cryptographic] "wrapping" of the attributes contain no correlation handles. This prevents unwanted tracking of users when they use their [{$pagename}] [tokens], even by colluding insiders.
* Users can minimally disclose information about what attributes are encoded in a [token] in response to dynamic verifier policies. As an example, a user may choose to only disclose a subset of the encoded attributes, prove that her undisclosed name does not appear on a blacklist, or prove that she is of age without disclosing her actual birthdate.
These user-centric aspects make the [{$pagename}] technology ideally suited to creating the digital equivalent of paper-based [credentials] and the plastic ID cards in one's wallet.
[{$pagename}] compiles with the [Law of User Control and Consent].
Microsoft has made available the foundational features of the technology by releasing the core U-Prove specifications under the Open Specification Promise.
!! Actors within [{$pagename}][3]
* [Issuer|Attribute Provider] - the [Attribute Provider] typically [Identity Provider (IDP)]
* [Prover] - the [end-user|user-agent] or a type of [Resource Owner]
* [Verifier] - typically a [Relying Party]
!! [{$pagename}] technology basics[3]
At the heart of the U-Prove technology is the notion of a [U-Prove token]. A [{$pagename}] [token] is a cryptographically protected collection of information of any kind (referred to as attributes).
[U-Prove token] is issued by an [Issuer|Attribute Provider] to a [Prover] via an issuance protocol, and subsequently presented by the [Prover] to a [Relying Party] via a presentation protocol.
Because a [U-Prove token] is just a binary string it can be issued and presented over any electronic network. To perform the U-Prove [protocols], all participants require computing devices that function on their behalf.
!! Issuing a U-Prove token[3]
In order for a [Prover] to retrieve a [U-Prove token] from an [Issuer|Attribute Provider] (authoritative source), the two parties must engage in an instance of the U-Prove issuance protocol. This is a cryptographic protocol that takes as its inputs, among others, any attributes to be encoded into the token.
The innovative features of the U-Prove technology derive from the [cryptographic] design of the issuance protocol, which is based on advances in modern cryptography. For the purposes of this overview it suffices to know that the [Issuer|Attribute Provider]’s signature is not a conventional RSA or DSA signature, and that issuance is a three-leg interactive protocol enabling the [Prover] to hide certain token elements from the [Issuer|Attribute Provider] (authoritative source).
Prior to issuing a [U-Prove token] to a [Prover], its [Issuer|Attribute Provider] (authoritative source) may assess the [Prover]’s eligibility to receive a token. In addition, the [Issuer|Attribute Provider] (authoritative source) may want to ascertain that the statements it will encode into the token pertain to the right [Prover]. These objectives may require the [Issuer|Attribute Provider] (authoritative source) to authenticate Provers (end-users) within its own domain or to verify other statements; nothing prevents the [Issuer|Attribute Provider] from relying on U-Prove tokens issued by other [Issuer|Attribute Provider]s.
%%information
All of these considerations are outside the scope of the U-Prove technology.
%%
The U-Prove issuance protocol enables the [Issuer|Attribute Provider] to protect U-Prove tokens against unauthorized manipulations, in accordance with application-specific requirements. The following basic protections are always in place:
* [Integrity] and [Non-Repudiation]:
** Each issued [U-Prove token] contains an unforgeable digital signature of its [Issuer|Attribute Provider] on the entire contents, created by the [Issuer|Attribute Provider] by applying its private key.
** The [Issuer|Attribute Provider]’s signature serves as its authenticity mark on the U-Prove token enables anyone to verify that the [U-Prove token] was issued by the [Issuer|Attribute Provider] and that its contents have not been altered.
* Replay attack prevention: Each issued [U-Prove token] also contains a token-specific public key that is known only to the Prover. The [Prover] randomly generates it during the issuance protocol, together with a corresponding private key for the U-Prove token. In contrast to the token’s public key, this private key is not part of the U-Prove token; the [Prover] never discloses it when using the U-Prove token.
In the next section we will explain how this prevents Verifiers from replaying presented U-Prove tokens.
Beyond these basic protections, U-Prove tokens can be protected using various optional security measures.
The [Issuer|Attribute Provider] (authoritative source) may issue arbitrarily many U-Prove tokens by using the same private key, without any loss of security. The [Issuer|Attribute Provider]’s corresponding public key is part of the [Issuer|Attribute Provider] parameters; this public information should be available to anyone interested in verifying issued and presented U-Prove tokens. Conceptually, the [Issuer|Attribute Provider] (authoritative source) parameters are equivalent to the certificate of a [Certificate Authority] in a [Public Key Infrastructure].
!! Presenting a U-Prove token[3]
To present a [U-Prove token] to a [Verifier|Relying Party], the [Prover] and the [Verifier|Relying Party] engage in an instance of the U-Prove presentation protocol. The [Prover] provides the token attributes (or, as we will see in Section 4.3, only a subset of the attributes), the [Issuer|Attribute Provider]’s signature, and the token-specific public key. The [Prover] also sends a response to the [Verifier|Relying Party]. To compute this response the [Prover] applies the private key for the U-Prove token to a presentation challenge of the [Verifier|Relying Party]. This presentation challenge must include a:
* [nonce] - a unique number that is never reused;
* timestamp or a counter appended to a unique Verifier identifier
We refer to the [Prover]-computed response as the presentation proof; it is a cryptographic proof of possession of the [private Key] corresponding to the presented U-Prove token. It proves that the [private Key] has been applied to the presentation challenge but the private key itself remains secret; this security guarantee holds even if all [Verifiers|Relying Party] and the [Issuer|Attribute Provider] participate in [collusion], examine arbitrarily many presentation proofs created with the same U-Prove token, and deviate from the issuance and the presentation protocols. As a result, [Verifiers|Relying Party] cannot replay the U-Prove tokens presented to them.
The verification of a presented [U-Prove token] does not require any secret information, special-purpose hardware, or real-time communication with the [Issuer|Attribute Provider] or any other party; all that is needed is an authentic copy of the [Issuer|Attribute Provider] parameters under which the [U-Prove token] was issued.
Upon verification of a presented U-Prove token, the rest of the session between the [Prover] and the Verifier may be securely tied to the initial authentication event.
%%information
how this is accomplished is outside the scope of the U-Prove technology.
%%
By reusing the same [U-Prove token] in subsequent visits to the same Verifier, the [Prover] can establish a relationship with the Verifier that spans multiple sessions. By using different U-Prove tokens on different occasions, on the other hand, the [Prover]'s activities can be segmented in a manner that protects the [Prover]'s privacy (even in the face of [collusions] involving the [Issuer|Attribute Provider]) and minimizes the risk of identity theft.
A [Prover] can create arbitrarily many presentation proofs with the same U-Prove token, within and across sessions with Verifiers, unless reuse limitations prevent such. This enables [Prover]s to securely re-authenticate to Verifiers using the same U-Prove token; see Section 3.5 for more information.
While [U-Prove tokens] do not require encryption over the wire to prevent replay attacks, [encryption] may nonetheless be desirable for message [confidentiality]. Depending on application requirements, [encryption] may
be applied to a token in its entirety or to selected token contents.
%%information
[Encryption] is outside the scope of the U-Prove technology.
%%!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [U-Prove-Wikipedia|Wikipedia:U-Prove|target='_blank'] - based on information obtained 2015-11-07
* [#2] - [U-Prove|http://research.microsoft.com/en-us/projects/u-prove/|target='_blank'] - based on information obtained 2015-11-07
* [#3] - [U-Prove Technology Overview V1.1|http://research.microsoft.com/pubs/166980/U-Prove%20Technology%20Overview%20V1.1%20Revision%202.pdf|target='_blank'] - based on information obtained 2015-11-07
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop