U-Prove features (Re: announce: credlib library with brands and chaum credentials

[Christian Paquin]

Adam Back wrote:
> About flexibility and generality I mean Brands has a huge list of
> features, like a very efficient observer setting, with cheap
> operations suitable for an 8 bit smartcard, limited multi-show (though
> linkable, there is an online credential refresh phase if unlinkable is
> desired), single show, ability to show formulae, ability to show and
> combine formulae across credentials from different issuers etc.  And
> also prove negatives involving attributes, and related technique for
> testing a black list of revoked credentials blindly.
> [...]
> The u-prove library does a lot more things, I think

It may be difficult to understand what's implemented in U-Prove by
reading the press release and data sheet, so here it is in more
technical terms.

U-Prove implements what we call ID Tokens: a credential with three
attributes. The goal of these credentials is to act, as the name
implies, as identity tokens.

ID Tokens have three fields. The first field contains public token
attributes, which are always disclosed (e.g., an expiry date, token
usage info, semantics of the other fields, etc.). The second field can
contain any data and can be selectively disclosed; not disclosing the
field gives _no_ information about its value to a verifier. The third
field contains data committed by the user at issuance time but unseen by
the issuer (e.g., contact information, an encryption key).

ID Tokens are untraceable and unlinkable among themselves. Care must of
course be taken when encoding data into them. Traceability of the tokens
depends only on the encoded data. Reuse of a same token allows you to
build a pseudonymous relation with a verifier (like a random 
username/password).

Presentation of an ID Token results in a user-authenticated transcript
suitable for audit logs. Furthermore, verifiers can censor the
information relative to the disclosure of the selectively-disclosable
token field; auditors do not learn if the user disclosed the second
field and if so, its value.

Each ID Token specifies a unique identifier (hash of the token contents
+ other protocol data). This identifier is not under the control of any
party and is therefore suitable to index user accounts (a rogue issuer
could not generate an ID Token with the same identifier as another token
issued by another issuer).

ID Tokens can be revoked individually by their identifiers (à la X.509).
The SDK offers a more powerful revocation technique. A user can prove
that the value of the second field is not on a blacklist without
disclosing the field's value. By encoding a user identifier in this 
field, an issuer could revoke all of a user's unlinkable tokens.

ID Tokens can be issued as one-use. Reuse of such tokens allows an
auditor to compute the token's private key including the attributes. If
identifying data (e.g. an account number) is encoded in the
never-disclosed field, the auditor learning this value can trace the
malicious user. This value can then be blacklisted to prevent the user
from using any of her tokens.

ID Tokens may be protected by a "device" (a smart card, a Trusted
Computing chip, a remote server, etc.) Devices hold part of the token's
private key and must collaborate with the user in the presentation
protocol in order for the token to be usable. The secret in the device
can be shared by an unlimited number of tokens. The device's computation
is very efficient (no modexp at presentation time). Useful to protect 
the user against local malware or to enforce the issuer's security policies.

As you mentioned, Brands's credential system has a lot of features. We
did not implement everything for one good reason. This stuff is still
quite esoteric, even for the crypto community, and we wanted the SDK to
be identity-centric, with clear use cases. The SDK abstracts all the
crypto so it should be simple for security developers to use it.

Some use cases documented in the SDK include:
  * strong user authentication (privacy-friendly PKI)
  * digital signatures
  * protecting attribute assertions (e.g., I'm over 18, I live in
    Quebec). Could be integrated in frameworks such as SAML, WS-Trust,
    Liberty ID-WSF)
  * one-use e-tickets, these may contain attributes (similar to e-coins)

Regards,

  - Christian

--

Christian Paquin
Chief Security Engineer @ Credentica
1010 Sherbrooke West Suite 1800
Montreal, QC, Canada H3A 2R7
Tel: +1 (514) 866.6000
www.credentica.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com