Open-sourcing Nameless Credential Service

  • Meta has open-sourced Anonymous Credential Service (ACS), a extremely obtainable multitenant service that enables shoppers to authenticate in a de-identified method.
  • ACS enhances privateness and safety whereas additionally being compute-conscious.
  • By open-sourcing and fostering a neighborhood for ACS, we imagine we will speed up the tempo of innovation in de-identified authentication.

Information minimization — amassing the minimal quantity of information required to assist our companies — is certainly one of our core rules at Meta as we develop new privacy-enhancing technologies to guard consumer knowledge on our household of merchandise. The objective is to ship precious consumer experiences whereas amassing and utilizing much less knowledge. 

Our method to logging is one vital instance of this observe. Logging helps our engineers and builders consider efficiency and reliability, enhance product options, and generate experiences.

Consumer identities aren’t essential in most logging use circumstances and must be excluded from logging knowledge. Eradicating authentication is one option to take away identifiers. However doing so makes the system weak to numerous assaults, together with knowledge injection

At Meta, we’ve constructed a greater method for shoppers to authenticate in a de-identified method: Nameless Credential Service (ACS). At a excessive stage, ACS helps de-identified authentication by splitting authentication into two phases, token issuance and token redemption. Within the token issuance section, shoppers contact the server via an authenticated channel to ship a token. The server indicators the token and sends it again. Then, within the de-identified authentication (or token redemption) section, shoppers use a de-identified channel to submit knowledge and authenticate it using a mutated type of the token quite than a consumer ID.

ACS has performed an vital function in how we do de-identified authentication at scale. Now we’ve open-sourced it so the bigger neighborhood can each profit from ACS and assist speed up innovation in de-identified authentication.

Right here’s how we developed ACS, and how one can get began utilizing it.

An summary of the nameless credential protocol

The anonymous credential protocol is constructed on high of verifiable oblivious pseudorandom capabilities (VOPRFs) and blind signatures. 

Taking logging for instance once more, we clear up the issue of de-identified logging by splitting the workflow into two steps: First, shoppers use an authenticated connection to the server to acquire an nameless credential upfront. Then, each time the shoppers have to add logs, they ship the nameless credential together with the logs in an unauthenticated connection to the server. The nameless credential serves as proof that the shopper is genuine.

de-identified authentication anonymous credential service

Right here’s how the method performs out:

Step 1 (token issuance):

  1. The shopper generates a token.
  2. The shopper blinds the token.
  3. The shopper sends the blinded_token to the server, together with authentication knowledge.
  4. The server indicators the blinded_token after which sends the signed_blinded_token again to the shopper.
  5. The shopper unblinds the acquired token, leading to a signed_unblinded_token.

Step 2 (token redemption):

  1. The shopper sends the unique token, signed_unblinded_token, together with the enterprise knowledge it wants for the use case (e.g., logging occasions) to the server.
  2. The server validates the request with tokens. If the shopper is genuine and licensed to entry, the server will course of the enterprise knowledge.

This protocol is efficient as a result of:

  • The enterprise knowledge and authentication knowledge are separated.
    • The enterprise knowledge is distributed with unblinded tokens, and authentication knowledge is distributed with a blinded token. It’s noteworthy that the token issuance step and token redemption step don’t occur on the similar time — the shopper can retailer tokens for a number of hours and even a number of days. If the shopper needs to log knowledge however is out of tokens, they’ll fetch a token and redeem it instantly. However these two steps are put into separate requests to assist stop an id from being inferred from the information.
  • The token, along with signed_unblinded_token, serves because the legitimation of the shopper. The token issuance server makes use of a secret key to signal tokens, and that secret key can’t be inferred from client-side observations (see: decisional Diffie–Hellman assumption). 

Challenges of the nameless credential protocol

To make the protocol work in real-life, large-scale techniques, there are extra challenges to be solved.

Token redemption counting

Ideally, one credential will be redeemed solely as soon as. However in observe, it’s acceptable to permit a credential to be redeemed a number of instances (as outlined by the use case) to cut back server load. We utilized a real-time, dependable, and secured counting service to restrict the variety of token redemption instances.

Key rotation

The nameless credential protocol requires a key pair. The server makes use of a secret key to signal the token (step 1.4) and validate the redemption request (step 2.2). The shopper wants a corresponding public key to unblind the token (step 1.5).

Given this, key administration — particularly, rotating keys regularly and discarding experiences from previous keys — performs an important function in making certain that we will mitigate the impression of shoppers if they’re compromised after they’re issued a credential. These key rotations need to be deployed throughout the fleet in a constant  and environment friendly method. The important thing administration service interacts with the configuration administration system to mutate key supplies for ACS tenants based on the cipher suites and key rotation schedules specified of their configuration recordsdata. 

There are additionally challenges round distributing new verification keys to shoppers that wish to confirm credentials.

Key transparency and attribute-based VOPRFs

The design of our attribute-based VOPRFs is motivated by our want for an environment friendly and clear technique round key rotation.

Frequent key rotations present a safety measure for ACS. Nevertheless, a malicious server can establish customers by signing every one with a user-specific key that may be tied again to them throughout credential redemption. 

Key transparency makes it doable for customers to find out about all of the obtainable public keys, stopping the server from assigning user-specific key pairs. Furthermore, at Meta we have to handle many keys for every ACS use case, and sustaining naively generated keys will not be scalable.

We solved this drawback by introducing key derivation capabilities (KDFs). At a excessive stage, given any attributes (e.g., a bunch of strings), new secret keys will be derived from public keys, which may additional be derived from a single public key. By setting the attributes to consult with the time epoch for which the keys are legitimate, shoppers will be verified simply with out the necessity to fetch new public keys.

Consequently, we will lengthen the transparency of the first public key — which will be shipped with shopper code or posted to a trusted location — to those derived public keys with none further effort.

Deploying nameless credential protocol at scale

With these issues in thoughts, a typical ACS deployment appears to be like extra like:

Setup (step 0):

  1. The shopper obtains the server’s main public key and different public parameters.
  2. The server generates a key pair utilizing given attributes (use case title, time epoch, identified to shoppers) after which sends the general public key to the shopper.
  3. The shopper validates the general public key with the first public key and attributes.

Step 1 (token issuance):

  1. The shopper generates a token.
  2. The shopper blinds the token.
  3. The shopper sends the blinded_token to the server, together with authentication knowledge.
  4. The server checks the token issuance price for the precise consumer. It then indicators the blinded_token and sends the signed_blinded_token again to the shopper.
  5. The shopper unblinds the acquired token, leading to a signed_unblinded_token. 

Step 2 (token redemption):

  1. The shopper sends the unique token, signed_unblinded_token, together with the enterprise knowledge it wants for the use case (e.g., logging occasions) to the server.
  2. The server validates the request and checks the redemption instances for the precise token. If the shopper is genuine and licensed to entry, the server will and course of the enterprise knowledge. 

Step 0.3 performs an vital function in sustaining key transparency. If a malicious server is assigning public keys that correlate to consumer authentication knowledge, the validation step would fail and the shopper might refuse to make use of the general public key acquired.

Learn the paper “DIT: De-identified authenticated telemetry at scale” for extra mathematical particulars for the protocol.

The ACS library

The ACS repo offers a portal and extensible C library (within the /lib/ folder), whose major parts embody:

  • The VOPRF protocol: This consists of client-side token blinding, unblinding, and producing a shared secret for token redemption. For servers, the protocol consists of signing the blinded token and producing a server-side shared secret for token redemption. There are two variations of the blinding technique supplied within the library.
  • An attribute-based key derivation operate: This can be a key rotation answer. If the attributes are set to a standard identified worth (e.g., time epoch), shoppers can confirm the authenticity of the server simply. There are a number of KDFs supplied within the library. We advocate Sturdy Diffie–Hellman Inversion (SDHI) or Naor-Reingold for higher key transparency.
  • Discrete log proof: That is used to show the authenticity of the server. It’s used twice within the protocol — first, to confirm the general public key derived from attributes within the setup step, and second, to confirm the signed token in token issuance step
  • Elliptic curves: The ACS library is modular, and customers can select most popular elliptic curves. Ed25519 and Ristretto are presently supplied.     

The library is meant to be deployed on cell units, so we need to decrease exterior dependencies to maintain the binary measurement small. At present, libsodium is the one dependency for the ACS library.

Along with that, now we have carried out a SimpleAnonCredService (server + shopper) in C++ for demonstration functions. The service is constructed with Apache Thrift 0.16. (See the /demo/ folder within the repo.)

Tips on how to use ACS in an actual system

Let’s use an instance to reveal the workflow. Suppose we’re sustaining a service that enables authenticated customers to get climate experiences. A naive system will appear to be this:

# shopper
# server
if check_authentication(request.authentication_data): = report_data

Step one is to separate the authentication_data from report_data, which is the principle objective of the ACS venture. 

# shopper - authentication
token = random_string()
blinded_token, blinding_factor = blind(token)
signed_blinded_token = request_token_from_server(authentication_data, blinded_token)
signed_unblinded_token = unblind(signed_blinded_token, blinding_factor)
# shopper - get knowledge
client_secret = client_finalize(token, signed_unblinded_token)
get_report(token, client_secret)
# token issuance server
if check_authentication(request.authentication_data):
    signed_blinded_token = consider(blinded_token)
    response.signed_blinded_token = signed_blinded_token
# token redemption server
server_secret = server_finalize(request.token)
if server_secret == request.client_secret: = report_data

After the shopper is authenticated and requests the information it wants, the shopper generates a token, blinds the token, and sends the token to the server. After an authentication examine, the server indicators the token and sends it again to the shopper. The shopper then unblinds the signed token, after which verifies it with the general public key and proof.

Lastly, the shopper redeems the token. The server validates the key key and proceeds to enterprise logic if the validation succeeds. If the validation fails, the server rejects the request.

Once we launched key rotation and KDF, it added two extra steps to start with of the method:

  1. The shopper downloads the first public key from the server. This main public key’s for validation of the general public key in step 2.
  2. The shopper will get a public key for supplied attributes. The attributes will be any listing of strings (e.g., use case names, dates) which can be allowed by the server. KDFs enable for key transparency. After this step, the shopper might be assured that the server will not be assigning a public key associated to the authentication data. Later, the general public key can be utilized within the verifiable_unblind step to verify the signed_blinded_token is signed with the non-public key akin to the verified public key.
# shopper - setup
primary_public_key = request_primary_public_key_from_server()
# shopper - authentication
public_key, pk_proof = get_public_key_from_server(attribute)
if !dleqproof_verify(public_key, pk_proof, primary_public_key, attribute):
    increase Exception("malicious server!")
token = random_string()
unblinded_token, blinding_factor = blind(token)
signed_blinded_token, proof = request_token_from_server(authentication_data, blinded_token)
signed_unblinded_token = verifiable_unblind(signed_blinded_token, blinding_factor, proof, public_key)

With all these steps, we’ve prevented a probably malicious server from utilizing these key rotations to segregate and establish customers. This can be a good prototype system and able to use. However in a scalable system, there are extra challenges to beat, together with client-side token storage and server-side price limiting. These options aren’t included in ACS’s open supply repo.

Future plans for ACS

Wanting on the future, we imagine the modular ACS is extensible and has the potential to be helpful to industries that make the most of nameless credential options. We’re planning to implement the standard.

A lightweight model with out libsodium dependency might be helpful to make use of circumstances the place binary measurement is proscribed. 

In case you’d wish to contribute to the venture, please go to the ACS GitHub.