U-Prove Technology
Home U-Prove Technology Unique Features


Unique Features

At the heart of the U-Prove technology is the notion of U-Prove Tokens. These are basic cryptographic constructs for data protection, much like X.509 certificates:

  • U-Prove Tokens are issued by Issuers to Users by means of an issuing protocol, presented by Users to Verifiers by means of a presentation protocol, and (optionally) forwarded by Verifiers to third parties.

  • Each U-Prove Token consists of one or more attributes (which can represent any kind of information), a unique public key for the User of the token, and a digital signature of the Issuer on the token contents.

  • Each U-Prove Token public key corresponds to a private key that is known only to the token's User; it must be applied in order to perform the presentation protocol.

We now list the unique features of U-Prove Tokens over and above the standard security features of X.509 certificates (i.e., digital signing, message encryption, message integrity, and source authentication). All unique features derive from the underlying innovative cryptographic techniques used to issue, present, and forward U-Prove Tokens. These features can be mixed and matched in any combination in accordance with application requirements.

Multi-party privacy features

The following privacy features for (honest) Users cannot be violated even if Verifiers and Issuers would have unlimited computing time and resources at their disposal in a coordinated attempt to (1) build cryptographic backdoors into the Issuer’s system parameters, (2) strategically deviate from the U-Prove Token protocols, and (3) analyze the resulting protocol data flows.

Selective disclosure.

In the presentation protocol, Users can selectively disclose any property of the attributes wrapped inside one or more of the U-Prove Tokens that have been issued to them, while unconditionally hiding any other information about the attributes. Properties can be proven not only for attributes within a single U-Prove Token but also across U-Prove Tokens (of the same and even of multiple Users). When used in combination with the next feature, Users are guaranteed fine-grained privacy control not only vis-à-vis Verifiers but also vis-à-vis Issuers.

Untraceability and unlinkability.

U-Prove Tokens can be issued in such a manner that not even collusions of Verifiers and Issuers can trace the presentation of an U-Prove Token to its issuing event, or determine whether or not two presented U-Prove Tokens were issued to the same User. When used in combination with the selective disclosure feature, Verifiers and Issuers can infer no more than what can be inferred from the attribute properties that Users expressly disclose to Verifiers.


A User can present an U-Prove Token in such a manner that (1) the Verifier is left with no non-repudiable transaction evidence at all (much like showing a paper-based certificate without letting the other party make a photocopy), or (2) the Verifier is left with non-repudiable transaction evidence of only a User-designated part of the User-disclosed attribute property (much like allowing a verifier to make a photocopy of a paper-based certificate after crossing out some of the information).

Censoring of User-authenticated audit trails.

A Verifier can verify an U-Prove Token in such a manner that the Verifier is left with non-repudiable transaction evidence of only a portion of the User-disclosed attribute property. This allows the Verifier to forward User-authenticated audit trail data to a central party (e.g., to enable status validation, fraud detection, and data flow analysis) while preserving the Verifier’s privacy interests vis-à-vis the central party. In case of a dispute, the Verifier can retroactively disclose the hidden portion of the User-disclosed attribute property, or any part of it.

Privacy-friendly collaborative issuing.

An Issuer can issue an U-Prove Token containing attributes that it never sees and that it is unable to learn. More generally, the User or any other party can contribute attributes to U-Prove Tokens in such a manner that the Issuer will only learn a property of the contributed attributes.

Privacy-friendly recertification and updating.

In a similar fashion, an Issuer can issue a new U-Prove Token on the basis of one or more previously issued U-Prove Tokens presented to it, without needing to know the attributes contained within them. In the process, the Issuer can increment or otherwise update any of the attributes, without knowing them.

Cryptographic security features

While honest Users enjoy privacy, the following cryptographic security safeguards ensure that misuse of U-Prove Tokens is protected against with even greater force than with X.509 certificates (which offer no privacy):

Lending protection.

It is not possible to present an U-Prove Token without knowing (and applying) all the attributes encoded within it, even though the selective disclosure property enables Users to hide attributes. Thus, an Issuer can discourage a User from fraudulently transferring an U-Prove Token (or copies thereof) by encoding a User-confidential attribute into the U-Prove Token.

Pooling protection.

Different Users can be prevented from pooling their U-Prove Tokens. Hereto Issuers encode a User identifier into each issued U-Prove Token, and Verifiers require multiple U-Prove Tokens presented in combination to be accompanied by a proof that they all contain the same encoded identifier. Owing to the selective disclosure property, an honest U-Prove Token holder can demonstrate this without disclosing the encoded identifier, but colluding U-Prove Token holders cannot pass the inspection.

Discarding protection.

To prevent Users from discarding U-Prove Tokens that contain unfavorable attributes, Issuers can wrap these attributes into U-Prove Tokens that must always be revealed. For example, a mark for drunk driving can be tied into a driver’s license U-Prove Token. Owing to the selective disclosure property, Users can hide negative attributes if they do not need to be disclosed.

Limited-use protection.

Issuers can issue limited-use U-Prove Tokens that are untraceable only when used no more times than allowed. In the case of a fraud all the attributes wrapped in the U-Prove Token can be efficiently computed from the presentation protocol transcripts. Thus, by encoding in each limited-use U-Prove Token a User identifier attribute, which need never be revealed, Issuers can trace fraudulent Users. At the same time, even a collusion of Verifiers and Issuers cannot frame an honest User.

Community-based User tracing.

U-Prove Tokens can be issued in such a manner that the Issuer in collaboration with its entire community of Users can trace which User presented a particular U-Prove Token. This works on the basis of the principle of exclusion: Users of U-Prove Tokens can prove that they are not the originator of a transaction with a Verifier (on the basis of the presentation protocol transcript) if and only if they indeed did not originate the transaction.

User-designated escrowing of a tracing key.

In the presentation protocol, a User can attach a verifiable encryption (under the public key of a designated escrow agency) of an identifier encoded into the U-Prove Token that the User presents. This will enable the escrow agency to retroactively trace the User who conducted that presentation protocol by decrypting the encrypted identifier. We stress that this is not systemic key escrow. The tracing power of escrow agencies is limited to exactly those U-Prove Tokens to which Users choose to attach encrypted identifiers.

Blacklisting U-Prove Tokens of a known User.

When presenting an U-Prove Token, the User can efficiently demonstrate that an encoded User identifier is not listed on a blacklist, without disclosing any information about the identifier. This enables Issuers to “un-enroll” Users to whom they have issued U-Prove Tokens that have not yet expired, without violating the privacy of Users who pass the blacklist verification process. This lock-out technique is not based on key escrow: User lock-out is possible only for Users who consent to the encoding of certain attributes into their U-Prove Tokens at issuing time, and actively cooperate at presentation time. Additionally, lock-out does not imply traceability.

Blacklisting U-Prove Tokens of an unknown User.

All of a User’s U-Prove Tokens can be blacklisted on the basis of any single one of the User’s U-Prove Tokens, without anyone needing to know the User to whom the U-Prove Token has been issued. This allows the blacklisting of Users who abuse Verifier services under one U-Prove Token and attempt to continue using services on the basis of other U-Prove Tokens. The technique works even when all U-Prove Tokens are unconditionally unlinkable and untraceable, and does not violate the privacy of Users who pass the blacklist verification process. This lock-out technique is not based on key escrow: User lock-out is possible only for Users who consent to the encoding of certain attributes into their U-Prove Tokens at issuing time, and actively cooperate at presentation time. Additionally, lock-out does not imply traceability.

Hardware security features for User devices

Over and above the cryptographic security features, trusted modules (such as tamper-resistant smartcards or Trusted Computing chips) can be handed to Users in order to further protect the security interests of Issuers and/or Verifiers.

Multi-factor security.

The U-Prove Token protocols are such that Users cannot bypass the security logic of their trusted module without a physical device attack aimed at extracting a module’s private key. Any kind of security logic can be programmed into these trusted modules to provide (1) a layer of hardware protection on top of any of the cryptographic security protections, and (2) hardware protection against any unauthorized behavior by Users that cryptographic security techniques cannot address. This allows for two-factor security as well as three-factor security (whereby the User must unlock the trusted module using a biometric).

Privacy-friendly multi-factor security.

Users can interpose any computer of their own choice in between their trusted modules and Verifiers, in such a manner that their trusted module cannot bypass any of the above privacy guarantees, even in collusion attacks involving Issuers and Verifiers. The User’s interposed device can inspect and sanction any message flow into and out of the User’s trusted module.

Highly constrained trusted modules.

Virtually all U-Prove Token handling can be off-loaded securely from the User’s trusted module to the User’s interposed device. This allows for literally millions of U-Prove Tokens to be issued in such a manner that they all leverage the private key of the same constrained trusted module, such as an 8-bit smartcard; the security logic protections programmed in the trusted module will apply with full force, while the trusted module cannot compromise the privacy and security interests of its User.

Shared trusted modules.

Different Issuers can all leverage the same trusted module to independently derive the security benefits of that module, without knowing the private key of the trusted module. Issuers do not need to trust anyone else (including the trusted module supplier or anyone who manages to physically break into the trusted module) with regard to any of the above cryptographic security protections for the U-Prove Tokens they issue.


  Unique Features
  Introductory Video
  The MIT Press Book









Copyright © 2004–2012 Credentica Inc. All rights reserved.
Privacy Statement | Terms & Conditions