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
- 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.
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.
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.
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.
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).
of User-authenticated audit trails.
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.
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
recertification and updating.
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.
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
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
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.
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.
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.
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.
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.
escrowing of a tracing key.
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.
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.
U-Prove Tokens of an
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.
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.
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).
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.
constrained trusted modules.
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.
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