“Some features such as revocation or de-anonymization even require the combination of several cryptographic protocols.” (Camenisch et al., 2014, p. 26) “. In this paper, we aim to overcome these issues and simplify both the design and deployment of privacy-friendly authentication mechanisms.” (Camenisch et al., 2014, p. 26) “the identity provider can impersonate its users and can track a user's moves online.” (Camenisch et al., 2014, p. 27) “user to reveal more attributes than strictly needed (as otherwise the issuer's signature cannot be verified) and make her online transactions linkable across different websites.” (Camenisch et al., 2014, p. 27) “anonymous credentials, minimal disclosure tokens, self-blindable credentials, or group signatures (Chaum, 1981; Brands, 2000; Camenisch and Lysyanskaya, 2001, 2004; Belenkiy et al., 2009; Verheul, 2001).” (Camenisch et al., 2014, p. 27) (Camenisch et al., 2014, p. 27) ABC - 1. Obtain Credentials for the attributes (Credential Issuer Protocol) 2. Without further assistance from the Issuer, derive as many as required unlinkable tokens (Presentation Tokens) -- if you want to make sure that the tokens for particular scope are unique, then use scope-specific pseudonyms 3. Verifier can validate tokens and revoke entire credential if malicious user is found. This can be done by proving revokation authority in the verification token “Our work builds on the credential-based authentication requirements language (CARL) recently proposed by Camenisch et al. (2010a)” (Camenisch et al., 2014, p. 27) “Compared to our work, CARL defines only a small part of a Privacy-ABC system, namely the presentation policy, but does not consider how these attributes are transmitted nor how credentials are issued or revoked.” (Camenisch et al., 2014, p. 27) “Recent work (Kirkpatrick et al., 2011) extended RBAC with privacy-preserving authentication for the particular case of role and location attributes.” (Camenisch et al., 2014, p. 27) (Camenisch et al., 2014, p. 27) Problem: Verfying identities online without compromising on anonimity Threats: Impersonation, Linkability Objectives: Unlinkabilility, Non-collusion and Attribute Anonimity Mechanism: Privacy ABC (Camenisch et al., 2014, p. 28) In case of Complaint Resolution System(CRS): Users: Complainants, Respondants, Ombuds Office Issuers: Ombuds Office, CRS system Verifiers: Ombuds Office Inspectors: External Trusted Authorities Revokation: External Trusted Authorities “Each issuer generates a secret issuance key and publishes the issuer parameters that include the corresponding public verification key. Similarly, each inspector generates a private decryption key and publishes the inspector parameters that include the corresponding public encryption key, and each revocation authority generates and publishes its revocation authority parameters.” (Camenisch et al., 2014, p. 28) “Using her credentials, a user can form a presentation token that contains a subset of the certified attributes, provided that the corresponding credentials have not been revoked.” (Camenisch et al., 2014, p. 28) “Additionally, some of the attributes can be encoded in the presentation token so that they can only be retrieved by an inspector.” (Camenisch et al., 2014, p. 28) “Receiving a presentation token from a user, a verifier checks whether the presentation token is valid with respect to the relevant issuer parameters and inspector parameters and the latest revocation information (thus, the verifier will interact with the revocation authority).” (Camenisch et al., 2014, p. 28) “(1) users can only generate a valid presentation token if they were indeed issued the corresponding credentials that have not been revoked, (2) that attributes encoded in the presentation token for an inspector can indeed be retrieved by that inspector, and (3) that the presentation tokens do not reveal any further information about the users other than the attributes contained in them.” (Camenisch et al., 2014, p. 29) “However, unlike traditional public-key authentication schemes, there is no single public key corresponding to the secret key. Rather, the user can generate as many public keys as she wishes.” (Camenisch et al., 2014, p. 29) “Pseudonyms (Chaum, 1981; Lysyanskaya et al., 1999) are cryptographically unlinkable, meaning that given two different pseudonyms, one cannot tell whether they were generated from the same or from different secret keys.” (Camenisch et al., 2014, p. 29) “For example, in an online opinion poll, users should not be able to bias the result by entering multiple votes under different pseudonyms. In such situations, the verifier can request a special pseudonym called a scope-exclusive pseudonym, which is unique for a given user secret key and a given scope string (IBM Research Zurich Security Team, 2010).” (Camenisch et al., 2014, p. 29) “A credential is a certified container of attributes issued by an issuer to a user” (Camenisch et al., 2014, p. 29) “Optionally, a credential can be bound to a user's secret key, i.e., it cannot be used without knowing the secret key (Lysyanskaya et al., 1999). We call this option key binding” (Camenisch et al., 2014, p. 29) “To authenticate to a verifier, the user first obtains the presentation policy that describes which credentials the user must present and which information from these credentials she must reveal.” (Camenisch et al., 2014, p. 30) “Moreover, presentation tokens are cryptographically unlinkable (meaning no collusion of issuers and verifiers can tell whether two presentation tokens were generated by the same user or by different users) and untraceable (meaning that no such collusion can correlate a presentation token to the issuance of the underlying credentials).” (Camenisch et al., 2014, p. 30) “Privacy-ABCs provide the option to add accountability for misbehaving users through a feature called inspection (Chaum and van Heyst, 1991; Camenisch and Shoup, 2003).” (Camenisch et al., 2014, p. 30) “The verifier can check that the correct attribute values were encrypted, but cannot see their actual values. The inspection grounds describe the circumstances under which the verifier may call upon the inspector to recover the actual attribute values. The inspector is trusted to collaborate only when the inspection grounds have been met; verifiers cannot change the inspection grounds after receiving a presentation token, as the grounds are cryptographically tied to the token.” (Camenisch et al., 2014, p. 30) “Credentials may need to be revoked for several reasons: the credential and the related user secrets may have been compromised, the user may have lost her right to carry a credential, or some of her attribute values may have changed. In such cases, credentials need to be revoked globally and we call this issuer-driven revocation. The Utopian identity cards fall under this category.” (Camenisch et al., 2014, p. 30) “Sometimes credentials may be revoked only for specific contexts. For example, a hooligan may see his digital identity card revoked for accessing sport stadiums, but may still use it for all other purposes; or the Utopian state library may wish to deny lending paper book to borrowers who fail to properly return their books. We call this verifier-driven revocation.” (Camenisch et al., 2014, p. 30) “Revocation for Privacy-ABCs is cryptographically more complicated than for classical certificates, but many mechanisms with varying efficiency (Lapon et al., 2011) exist journal of information security and applications 19 (2014) 25e44 2” (Camenisch et al., 2014, p. 30) “(Camenisch and Lysyanskaya, 2002a; Nguyen, 2005; Brands et al., 2007; Camenisch et al., 2009a; Nakanishi et al., 2009). Bar a few exceptions, all of them can be used for both issuerdriven and verifier-driven revocation.” (Camenisch et al., 2014, p. 31) “First, users cannot simply reveal the signature to a verifier as part of a presentation token, because then different presentations become linkable. Instead, the user will perform a zero-knowledge proof of knowledge of a valid signature so that the privacy properties of a Privacy-ABC system can be achieved.” (Camenisch et al., 2014, p. 31) “Fortunately, there exist a few signature schemes that allow for efficient issuance and prove protocols. These include the CamenischeLysyanskaya (Camenisch and Lysyanskaya, 2002b) and the Brands (Brands, 2000) signature schemes, on which Identity Mixer and U-Prove are built on, respectively, and some schemes that employ bilinear maps (Camenisch and Lysyanskaya, 2004; Au et al., 2006).” (Camenisch et al., 2014, p. 31) “scope-exclusive pseudonyms can be realized as the output of a verifiable random function (Dodis and Yampolskiy, 2005; Camenisch et al., 2006)” (Camenisch et al., 2014, p. 31) “As mentioned above, key binding can be realized by designating one attribute as a user secret key (which of course must never be revealed). Inspection can be obtained through verifiable encryption (Camenisch and Shoup, 2003) of the inspectable attributes.” (Camenisch et al., 2014, p. 31) “The ‘‘glue’’ binding all primitives together in a presentation token is provided by zero-knowledge proofs of knowledge of discrete logarithms (Schnorr, 1991; Camenisch et al., 2009b) made non-interactive through the FiateShamir transform (Fiat and Shamir, 1986)” (Camenisch et al., 2014, p. 31) “For instance group signatures (Chaum and van Heyst, 1991) and identity escrow schemes (Killian and Petrank, 1998) can be seen as attribute-less credentials with inspection and key binding.” (Camenisch et al., 2014, p. 31) “Similarly, direct anonymous attestation (Brickell et al., 2004) can also be seen as attribute-less credentials with key-binding and revocation” (Camenisch et al., 2014, p. 31) (Camenisch et al., 2014, p. 32) https://app.swaggerhub.com/apis-docs/MEGHANABHANGE13/ABCSpecifications/1.0.0#/