]> Apple, Inc.

cathieyun@gmail.com

Apple, Inc.

caw@heapingbits.net

Google

marianar@google.com

Google

sgschlesinger@gmail.com

IRTF Crypto Forum anonymous credentials hidden metadata fraud prevention zero-knowledge proofs This document specifies the Anonymous Tokens with Hidden Metadata (ATHM) protocol, a protocol for constructing Privacy Pass like tokens with hidden metadata embedded within it unknown to the client. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Crypto Forum Research Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document presents a construction for Anonymous Tokens with Hidden Metadata (ATHM). ATHM is a cryptographic primitive that enables an issuer to issue an authentication token to a client in a way that the token carries no information about the client identity except a hidden metadata value the issuer sets during issuance. The value of the hidden metadata comes from a fixed domain and the client can verify this property of the hidden metadata of the token it receives. The metadata value remains hidden with respect to any party which does not have the secret key for the ATHM construction, including the client. Only the issuer who has the secret for the construction can verify the token and read the hidden metadata value. Similarly to public metadata proposed in the context of existing anonymous tokens schemes, the hidden metadata enables the issuer to partition clients into a number of groups proportional to the domain of the hidden metadata. During token redemption the issuer can identify which group the client belongs to based on the metadata value. The difference from public metadata is that this value of hidden metadata is only readable by the issuer who has the ATHM secret key, while public metadata embedded in the token is visible to everyone. Anonymous tokens are used for client authentication and their meaning is to convey trust in the client. In most cases the trust assigned to a client is determined based on the outcome of fraud and spam detection processes. It is often crucial that the signals used to obtain the verdict and the verdict itself remain hidden from the adversary, who can adapt its behavior to avoid detection if it knows when and why its behavior has been identified as fraudulent. ATHM can provide the means to issue authentication tokens that provide limited hidden fraud signals while preserving strong anonymity guarantees.

Conventions and Definitions

Notation and Terminology The following functions and notation are used throughout the document.

• For any object x, we write len(x) to denote its length in bytes.
• For two byte arrays x and y, write x || y to denote their concatenation.
• I2OSP(x, xLen): Converts a non-negative integer x into a byte array of specified length xLen as described in . Note that this function returns a byte array in big-endian byte order.
• The notation T U[N] refers to an array called U containing N items of type T. The type opaque means one single byte of uninterpreted data. Items of the array are zero-indexed and referred as U[j] such that 0 <= j < N.

All algorithms and procedures described in this document are laid out in a Python-like pseudocode. Each function takes a set of inputs and parameters and produces a set of output values. Parameters become constant values once the protocol variant and the ciphersuite are fixed. String values such as "CredentialRequest", "CredentialResponse", and "Presentation" are ASCII string literals. The PrivateInput data type refers to inputs that are known only to the client in the protocol, whereas the PublicInput data type refers to inputs that are known to both client and server in the protocol. The following terms are used throughout this document.

• Client: Protocol initiator. Creates an encrypted request, and uses the corresponding server encrypted issuance to make a presentation.
• Server: Computes an encrypted issuance for an encrypted request, with its server private keys. Later the server can verify the client's presentations with its private keys. Learns nothing about the client's secret attributes, and cannot link a client's issuance and presentation steps.

Preliminaries The construction in this document has two primary dependencies:

• Group: A prime-order group implementing the API described below in . See for specific instances of groups.
• Hash: A cryptographic hash function whose output length is Nh bytes.

specifies ciphersuites as combinations of Group and Hash.

Prime-Order Group In this document, we assume the construction of an additive, prime-order group Group for performing all mathematical operations. In prime-order groups, any element (other than the identity) can generate the other elements of the group. Usually, one element is fixed and defined as the group generator. In the KVAC setting, there are two fixed generator elements (generatorG, generatorH). Such groups are uniquely determined by the choice of the prime p that defines the order of the group. (There may, however, exist different representations of the group for a single p. lists specific groups which indicate both order and representation.) The fundamental group operation is addition + with identity element I. For any elements A and B of the group, A + B = B + A is also a member of the group. Also, for any A in the group, there exists an element -A such that A + (-A) = (-A) + A = I. Scalar multiplication by r is equivalent to the repeated application of the group operation on an element A with itself r-1 times, this is denoted as r*A = A + ... + A. For any element A, p*A=I. The case when the scalar multiplication is performed on the group generator is denoted as ScalarMultGen(r). Given two elements A and B, the discrete logarithm problem is to find an integer k such that B = k*A. Thus, k is the discrete logarithm of B with respect to the base A. The set of scalars corresponds to GF(p), a prime field of order p, and are represented as the set of integers defined by {0, 1, ..., p-1}. This document uses types Element and Scalar to denote elements of the group and its set of scalars, respectively. We now detail a number of member functions that can be invoked on a prime-order group.

• Order(): Outputs the order of the group (i.e. p).
• Identity(): Outputs the identity element of the group (i.e. I).
• Generators(): Outputs the generator elements of the group, (generatorG, generatorH) generatorG = Group.generator generatorH = HashToGroup(SerializeElement(generatorG), "generatorH"). The group member functions GeneratorG() and GeneratorH() are shorthand for returning generatorG and generatorH, respectively.
• HashToGroup(x, info): Deterministically maps an array of bytes x with domain separation value info to an element of Group. The map must ensure that, for any adversary receiving R = HashToGroup(x, info), it is computationally difficult to reverse the mapping. Security properties of this function are described in .
• HashToScalar(x, info): Deterministically maps an array of bytes x with domain separation value info to an element in GF(p). Security properties of this function are described in .
• RandomScalar(): Chooses at random a non-zero element in GF(p).
• ScalarInverse(s): Returns the inverse of input Scalar s on GF(p).
• SerializeElement(A): Maps an Element A to a canonical byte array buf of fixed length Ne.
• DeserializeElement(buf): Attempts to map a byte array buf to an Element A, and fails if the input is not the valid canonical byte representation of an element of the group. This function can raise a DeserializeError if deserialization fails or A is the identity element of the group; see for group-specific input validation steps.
• SerializeScalar(s): Maps a Scalar s to a canonical byte array buf of fixed length Ns.
• DeserializeScalar(buf): Attempts to map a byte array buf to a Scalar s. This function can raise a DeserializeError if deserialization fails; see for group-specific input validation steps.

contains details for the implementation of this interface for different prime-order groups instantiated over elliptic curves. In particular, for some choices of elliptic curves, e.g., those detailed in , which require accounting for cofactors, describes required steps necessary to ensure the resulting group is of prime order.

Ciphersuites A ciphersuite (also referred to as 'suite' in this document) for the protocol wraps the functionality required for the protocol to take place. The ciphersuite should be available to both the client and server, and agreement on the specific instantiation is assumed throughout. A ciphersuite contains instantiations of the following functionalities:

• Group: A prime-order Group exposing the API detailed in , with the generator element defined in the corresponding reference for each group. Each group also specifies HashToGroup, HashToScalar, and serialization functionalities. For HashToGroup, the domain separation tag (DST) is constructed in accordance with the recommendations in . For HashToScalar, each group specifies an integer order that is used in reducing integer values to a member of the corresponding scalar field.
• Hash: A cryptographic hash function whose output length is Nh bytes long.

This section includes an initial set of ciphersuites with supported groups and hash functions. It also includes implementation details for each ciphersuite, focusing on input validation. For each ciphersuite, contextString is that which is computed in the Setup functions. Applications should take caution in using ciphersuites targeting P-256 and ristretto255.

ATHM(P-256) This ciphersuite uses P-256 for the Group. The value of the ciphersuite identifier is "P256".

• Group: P-256 (secp256r1)
  • Order(): Return 0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551.
  • Identity(): As defined in .
  • Generator(): As defined in .
  • RandomScalar(): Implemented by returning a uniformly random Scalar in the range [1, G.Order() - 1]. Refer to for implementation guidance.
  • HashToGroup(x, info): Use hash_to_curve with suite P256_XMD:SHA-256_SSWU_RO_ , input x, and DST = "HashToGroup-" || contextString || info.
  • HashToScalar(x, info): Use hash_to_field from using L = 48, expand_message_xmd with SHA-256, input x and DST = "HashToScalar-" || contextString || info, and prime modulus equal to Group.Order().
  • ScalarInverse(s): Returns the multiplicative inverse of input Scalar s mod Group.Order().
  • SerializeElement(A): Implemented using the compressed Elliptic-Curve-Point-to-Octet-String method according to ; Ne = 33.
  • DeserializeElement(buf): Implemented by attempting to deserialize a 33-byte array to a public key using the compressed Octet-String-to-Elliptic-Curve-Point method according to , and then performs partial public-key validation as defined in section 5.6.2.3.4 of . This includes checking that the coordinates of the resulting point are in the correct range, that the point is on the curve, and that the point is not the point at infinity. Additionally, this function validates that the resulting element is not the group identity element. If these checks fail, deserialization returns an InputValidationError error.
  • SerializeScalar(s): Implemented using the Field-Element-to-Octet-String conversion according to ; Ns = 32.
  • DeserializeScalar(buf): Implemented by attempting to deserialize a Scalar from a 32-byte string using Octet-String-to-Field-Element from . This function can fail if the input does not represent a Scalar in the range [0, G.Order() - 1].

Random Scalar Generation Two popular algorithms for generating a random integer uniformly distributed in the range [0, G.Order() -1] are as follows:

Rejection Sampling Generate a random byte array with Ns bytes, and attempt to map to a Scalar by calling DeserializeScalar in constant time. If it succeeds, return the result. If it fails, try again with another random byte array, until the procedure succeeds. Failure to implement DeserializeScalar in constant time can leak information about the underlying corresponding Scalar. As an optimization, if the group order is very close to a power of 2, it is acceptable to omit the rejection test completely. In particular, if the group order is p, and there is an integer b such that |p - 2^b| is less than 2^(b/2), then RandomScalar can simply return a uniformly random integer of at most b bits.

Random Number Generation Using Extra Random Bits Generate a random byte array with L = ceil(((3 * ceil(log2(G.Order()))) / 2) / 8) bytes, and interpret it as an integer; reduce the integer modulo G.Order() and return the result. See for the underlying derivation of L.

Anonymous Token with Hidden Metadata Protocol TODO(caw): writeme

Key Generation and Context Setup In the offline phase, the server generates a public and private key using the KeyGen routine below. The type PublicKeyProof and the function CreatePublicKeyProof are specified in . Further, they must agree on a string deploymentId and a number of buckets nBuckets. The contextString as used in HashToGroup and HashToCurve is ATHMV1-<group-name>-<nBuckets>-<deploymentId>. An example of contextString is ATHMV1-P256-4-example_deployment_id. The output publicKey from this function is wire-encoded into publicKey = 3*Ne+2*Ns bytes as follows: The Z_enc, C_x_enc, and C_y_enc fields are the serialized representations of publicKey.Z, publicKey.C_x, and publicKey.C_y, respectively. The pi_enc field is the serialized PublicKeyProof, as defined below.

Public Key Proof The server public key carries with it a zero-knowledge proof of knowledge of the corresponding private key. Clients verify this proof before using the public key for token issuance. The procedures for creating and verifying this proof, CreatePublicKeyProof and VerifyPublicKeyProof, are detailed below. The output of CreatePublicKeyProof is a value of type PublicKeyProof, which is wire-encoded as the concatenation of the e and a_z values, both serialized using SerializeScalar, yielding the following format: The VerifyPublicKeyProof routine, which takes as input a server public key, is below. The output verifiedPublicKey from this function is wire-encoded into verifiedPublicKey = 3*Ne bytes as follows:

ATHM Protocol The ATHM Protocol is a two-party protocol between a client and server where they interact to compute where privateKey and publicKey contains the server's private and public keys, respectively (and generated as described in ), and hiddenMetadata is an application-specific value known only to the server. The protocol begins with the client making a token request using the verified server public key. The client then sends request to the server. If the request is well-formed, the server computes a token response with the server private keys and hidden metadata. The response includes a proof that the token response is valid with respect to the server keys, and a maximum number of buckets for the hidden metadata. The server sends the response to the client. The client processes the response by verifying the response proof. If the proof verifies correctly, the client computes a token from its context and the server response: When the client presents the token to the server for redemption, the server verifies it using its private keys, as follows: This process fails if the token is invalid, and otherwise returns the hidden metadata associated with the token during issuance. Shown graphically, the protocol runs as follows: response = TokenResponse(privateKey, publicKey, request, hiddenMetadata, nBuckets) response <--------------- token = FinalizeToken(context, verifiedPublicKey, request, response, nBuckets) .... token -------------------> hiddenMetadata = VerifyToken(privateKey, token, nBuckets) ]]> In the remainder of this section, we specify the TokenRequest, TokenResponse, FinalizeToken, and VerifyToken functions that are used in this protocol.

TokenRequest The TokenRequest function is defined below. The output request from this function is wire-encoded into Nrequest=Ne bytes as follows: The T_enc field is the serialized representation of request.T.

TokenResponse The TokenResponse function is defined below. The output response from this function is wire-encoded into Nresponse=Ne+Ne+Ns+Nproof bytes as follows: The U_enc, V_enc, and ts_enc fields are the serialized representations of response.U, response.V, and response.ts, respectively. The pi_enc field is the serialized IssuanceProof, as defined below. The CreateIssuanceProof function is defined below. The output pi from this function is wire-encoded into Nproof = Ne+(3+2*nBuckets)*Ns bytes as follows: The fields in this structure are the serialized representations of the contents of pi, e.g., C_enc is the serialized representation of pi.C and e_0_enc is the serialized representation of e[0].

FinalizeToken The FinalizeToken function is defined below. Internally, the client verifies the token response proof. FinalizeToken fails if this proof is invalid. The resulting token can be serialized as the concatenation of t, P, and Q serialized using their respective serialization functions, yielding the following struct: The VerifyIssuanceProof function is defined below.

VerifyToken The VerifyToken token is defined below.

Security Considerations The work of proves the following properties for the ATHM construction presented here: unforgeability, unlinkability and privacy of the metadata. Unforgeability guarantees that only an issuer with a valid secret key can generate new tokens. Unlinkability states that tokens with the same metadata are indistinguishable to the redeemer, i.e. the redeemer does not have any advatage in guessing which issuance session (among those assigned the same metadata) a paricular redeemed token comes from. Finally, privacy of the metadata guarantees that any party who does not know the secret verification key cannot learn any information about the hidden metadata of a token. The only place where the construction presented in this document differs from the ATHM construcion presented in is the fact that we generalize that construction to more than one bit for the hidden metadata. This requires that the ZK proof provided during issuance to the client proves a new bound on the number of embedded bits in the token. The proofs of unfogeability and the privacy of the hidden metadata bits do not depend on the range of the metadata. The unlinkability proof accounts for the fact that the issuer can partition the clients into a larger than two number of groups, since unlinkability only holds among tokens with the same metadata.

IANA Considerations This document has no IANA actions.

References Normative References This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. Cloudflare, Inc. Cornell Tech Cloudflare, Inc. Stanford University Cloudflare, Inc. This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. National Institute of Standards and Technology Informative References National Institute of Standards and Technology (U.S.) n.d. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.

Acknowledgments Thanks to Melissa Chase for discussion about the ATHM paper. Thanks also to Tommy Pauly, Phillipp Schoppmann and Ghous Amjad for collaboration on the ATHM specifications.

Test Vectors This section contains test vectors for the ATHM ciphersuites specified in this document. The test vectors were generated from the reference implementation located at https://github.com/google/anonymous-tokens/pull/45/commits/8701431d31c2f49774526fac23bf7a2d24864314. All byte strings, except deployment_id, are encoded in hexadecimal.

ATHM(P-256)