U-Prove

Overview[1]#

U-Prove is a digital credential technology for claims-based identity management invented by Stefan Brands and developed by Credentica.[1]

U-Prove 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 U-Prove technologies as a Community Technology Preview under Microsoft's Open Specification Promise.[3]

U-Prove is an innovative cryptographic technology that allows users to minimally disclose certified information about themselves when interacting with online Service Providers. U-Prove 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 U-Prove token is a type of credential similar to PKI certificate that can encode attributes of any type, but with two important differences:[2]

These user-centric aspects make the U-Prove technology ideally suited to creating the digital equivalent of paper-based credentials and the plastic ID cards in one's wallet.

U-Prove 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 U-Prove[3]#

U-Prove technology basics[3]#

At the heart of the U-Prove technology is the notion of a U-Prove token. A U-Prove token is a cryptographically protected collection of information of any kind (referred to as attributes).

U-Prove token is issued by an Issuer 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 (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’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 (authoritative source).

Prior to issuing a U-Prove token to a Prover, its Issuer (authoritative source) may assess the Prover’s eligibility to receive a token. In addition, the Issuer (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 (authoritative source) to authenticate Provers (end-users) within its own domain or to verify other statements; nothing prevents the Issuer from relying on U-Prove tokens issued by other Issuers.

All of these considerations are outside the scope of the U-Prove technology.

The U-Prove issuance protocol enables the Issuer to protect U-Prove tokens against unauthorized manipulations, in accordance with application-specific requirements. The following basic protections are always in place:

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 (authoritative source) may issue arbitrarily many U-Prove tokens by using the same private key, without any loss of security. The Issuer’s corresponding public key is part of the Issuer parameters; this public information should be available to anyone interested in verifying issued and presented U-Prove tokens. Conceptually, the Issuer (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, the Prover and the Verifier 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’s signature, and the token-specific public key. The Prover also sends a response to the Verifier. To compute this response the Prover applies the private key for the U-Prove token to a presentation challenge of the Verifier. This presentation challenge must include a:

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 and the Issuer 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 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 or any other party; all that is needed is an authentic copy of the Issuer 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.

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

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:
Please see our Copyright And Intellectual Property Page and Standard Disclaimer Pages!