How it works
Identity Mixer works in a similar way as client certificates in a classical public-key infrastructure (PKI), but with two important differences:
- Flexible public keys: Rather than being bound to a single public key, users can have many independent public keys, called pseudonyms, for the same secret key, so that they can use a different pseudonym for each verifier or even for each session.
- Flexible credentials: The credentials that certify the user's attributes can be transformed into valid tokens for any of the user's pseudonyms that contain only a subset of the attributes in the original credential. The transformed token remains verifiable under the issuer's public verification key.
Classical digital signatures cannot provide this sort of flexibility. Identity Mixer relies on the Camenisch–Lysyanskaya (CL) signature scheme that is specifically designed to have efficient zero-knowledge proofs, which are cryptographic mechanisms to prove that one knows a valid signature with certain properties, without having to reveal the signature itself.
A credential in Identity Mixer is a CL signature by the issuer on the user's secret key and on the attribute values. To transform a credential into a presentation token, the user creates a zero-knowledge proof showing that he knows a valid CL signature on the disclosed attribute values and on the same user secret that also underlies his pseudonym.
To create an inspectable token, the user encrypts an identifying credential attribute under the public key of the inspector, so that only the inspector can decrypt it. Of course, this is not a standard encryption scheme, because otherwise a cheating user could easily circumvent it by encrypting gibberish or encrypting someone else's identity. Rather, Identity Mixer uses verifiable encryption, which allows the user to prove that the encrypted attribute value is the same as in his certified credential, without revealing the value. The verifier can check this proof and thereby be convinced that inspection will point to the correct user if he ever needs to inspect the token.
Revocation of Privacy-ABCs can be performed in several ways. The easiest is to avoid revocation altogether by issuing short-lived credentials that the user must refresh on a regular basis. While easy to implement, this approach has the disadvantage that it involves the issuer more often, which we actually wanted to avoid.
Another approach is to use dynamic accumulators. These are essentially special cryptographic hash functions so that the issuer, or a dedicated revocation authority, can publish the hash of the serial numbers (called revocation handles in Privacy-ABCs) of all valid or revoked credentials, depending whether a white-list or black-list approach is taken. The user must then prove in zero knowledge that the revocation handle of his credential is (or is not) included in the published hash.
A third revocation technique is by means of set membership proofs. Here, the issuer signs the intervals that are bounded by the revoked revocation handles. The user proves that his revocation handle is strictly within one of those intervals.