{"id":661,"date":"2022-12-12T11:00:07","date_gmt":"2022-12-12T11:00:07","guid":{"rendered":"https:\/\/fde.cat\/index.php\/2022\/12\/12\/open-sourcing-anonymous-credential-service\/"},"modified":"2022-12-12T11:00:07","modified_gmt":"2022-12-12T11:00:07","slug":"open-sourcing-anonymous-credential-service","status":"publish","type":"post","link":"https:\/\/fde.cat\/index.php\/2022\/12\/12\/open-sourcing-anonymous-credential-service\/","title":{"rendered":"Open-sourcing Anonymous Credential Service"},"content":{"rendered":"

Meta has open-sourced <\/span>Anonymous Credential Service (ACS)<\/span><\/a>, a highly available multitenant service that allows clients to authenticate in a de-identified manner.<\/span>
\nACS enhances privacy and security while also being compute-conscious.<\/span>
\nBy open-sourcing and fostering a community for ACS, we believe we can accelerate the pace of innovation in de-identified authentication.<\/span><\/p>\n

Data minimization \u2014 collecting the minimum amount of data required to support our services \u2014 is one of our core principles at Meta as we develop new <\/span>privacy-enhancing technologies<\/span><\/a> to protect user data on our family of products. The goal is to deliver valuable user experiences while collecting and using less data.\u00a0<\/span><\/p>\n

Our approach to logging is one important example of this practice. Logging helps our engineers and developers evaluate performance and reliability, improve product features, and generate reports.<\/span><\/p>\n

User identities aren\u2019t necessary in most logging use cases and should be excluded from logging data. Removing authentication is one way to remove identifiers. But doing so makes the system vulnerable to various attacks, including data injection<\/span>.\u00a0<\/span><\/p>\n

At Meta, we\u2019ve built a better way for clients to authenticate in a de-identified manner:<\/span> Anonymous Credential Service (ACS)<\/span><\/a>. At a high level, ACS supports de-identified authentication by splitting authentication into two phases, token issuance and token redemption. In the token issuance phase, clients contact the server through an authenticated channel to send a token. The server signs the token and sends it back. Then, in the de-identified authentication (or token redemption) phase, clients use a de-identified channel to submit data and authenticate it utilizing a mutated form of the token rather than a user ID.<\/span><\/p>\n

ACS has played an important role in how we do<\/span> de-identified authentication at scale<\/span><\/a>. Now we\u2019ve open-sourced it so the larger community can both benefit from ACS and help accelerate innovation in de-identified authentication.<\/span><\/p>\n

Here\u2019s how we developed ACS, and how you can get started using it.<\/span><\/p>\n

An overview of the anonymous credential protocol<\/span><\/h2>\n

The<\/span> anonymous credential protocol<\/span><\/a> is built on top of verifiable oblivious pseudorandom functions (VOPRFs) and blind signatures.\u00a0<\/span><\/p>\n

Taking logging as an example again, we solve the problem of de-identified logging by splitting the workflow into two steps: First, clients use an authenticated connection to the server to obtain an anonymous <\/span>credential<\/span> in advance. Then, whenever the clients need to upload logs, they send the anonymous <\/span>credential<\/span> along with the logs in an unauthenticated connection to the server. The anonymous <\/span>credential<\/span> serves as proof that the client is authentic.<\/span><\/p>\n

<\/span><\/p>\n

Here\u2019s how the process plays out:<\/span><\/p>\n

Step 1 (token issuance):<\/p>\n

The client generates a token.<\/span>
\nThe client blinds the token.<\/span>
\nThe client sends the blinded_token to the server, along with authentication data.<\/span>
\nThe server signs the blinded_token and then sends the signed_blinded_token back to the client.<\/span>
\nThe client unblinds the received token, resulting in a signed_unblinded_token.<\/span><\/p>\n

Step 2 (token redemption):<\/p>\n

The client sends the original token, signed_unblinded_token, along with the business data it needs for the use case (e.g., logging events) to the server.<\/span>
\nThe server validates the request with tokens. If the client is authentic and authorized to access, the server will process the business data.<\/span><\/p>\n

This protocol is effective because:<\/span><\/p>\n

The business data and authentication data are separated.<\/span><\/p>\n

The business data is sent with unblinded tokens, and authentication data is sent with a blinded token. It is noteworthy that the token issuance step and token redemption step do not happen at the same time \u2014 the client can store tokens for several hours or even several days. If the client wants to log data but is out of tokens, they can fetch a token and redeem it immediately. But these two steps are put into separate requests to help prevent an identity from being inferred from the data.<\/span><\/p>\n

The token, together with signed_unblinded_token, serves as the legitimation of the client. The token issuance server uses a secret key to sign tokens, and that secret key cannot be inferred from client-side observations (see:<\/span> decisional Diffie\u2013Hellman assumption<\/span><\/a>).\u00a0<\/span><\/p>\n

Challenges of the anonymous credential protocol<\/span><\/h2>\n

To make the protocol work in real-life, large-scale systems, there are more challenges to be solved.<\/span><\/p>\n

Token redemption counting<\/span><\/h3>\n

Ideally, one credential can be redeemed only once. But in practice, it is acceptable to allow a credential to be redeemed multiple times (as defined by the use case) to reduce server load. We utilized a real-time, reliable, and secured counting service to limit the number of token redemption times.<\/span><\/p>\n

Key rotation<\/span><\/h3>\n

The anonymous credential protocol requires a key pair. The server uses a secret key to sign the token (step 1.4) and validate the redemption request (step 2.2). The client needs a corresponding public key to unblind the token (step 1.5).<\/span><\/p>\n

Given this, key management \u2014 specifically, rotating keys frequently and discarding reports from old keys \u2014 plays a crucial role in ensuring that we can mitigate the impact of clients if they are compromised after they\u2019re issued a credential. These key rotations have to be deployed across the fleet in a consistent\u00a0 and efficient manner. The key management service interacts with the configuration management system to mutate key materials for ACS tenants according to the cipher suites and key rotation schedules specified in their configuration files.\u00a0<\/span><\/p>\n

There are also challenges around distributing new verification keys to clients that would like to verify credentials.<\/span><\/p>\n

Key transparency and attribute-based VOPRFs<\/span><\/h3>\n

The design of our attribute-based VOPRFs is motivated by our need for an efficient and transparent strategy around key rotation.<\/span><\/p>\n

Frequent key rotations provide a security measure for ACS. However, a malicious server can identify users by signing each one with a user-specific key that can be tied back to them during credential redemption.\u00a0<\/span><\/p>\n

Key transparency makes it possible for users to know about all the available public keys, preventing the server from assigning user-specific key pairs. Moreover, at Meta we need to manage many keys for each ACS use case, and maintaining naively generated keys is not scalable.<\/span><\/p>\n

We solved this problem by introducing key derivation functions (KDFs). At a high level, given any attributes (e.g., a group of strings), new secret keys can be derived from public keys, which can further be derived from a single public key. By setting the attributes to refer to the time epoch for which the keys are valid, clients can be verified easily without the need to fetch new public keys.<\/span><\/p>\n

As a result, we can extend the transparency of the primary public key \u2014 which can be shipped with client code or posted to a trusted location \u2014 to these derived public keys without any additional effort.<\/span><\/p>\n

Deploying anonymous credential protocol at scale<\/span><\/h2>\n

With these considerations in mind, a typical ACS deployment looks more like:<\/span><\/p>\n

Setup (step 0):<\/p>\n

The client obtains the server\u2019s primary public key and other public parameters.<\/span>
\nThe server generates a key pair using given attributes (use case name, time epoch, known to clients) and then sends the public key to the client.<\/span>
\nThe client validates the public key with the primary public key and attributes.<\/span><\/p>\n

Step 1 (token issuance):<\/p>\n

The client generates a token.<\/span>
\nThe client blinds the token.<\/span>
\nThe client sends the blinded_token to the server, along with authentication data.<\/span>
\nThe server checks the token issuance rate for the specific user. It then signs the blinded_token and sends the signed_blinded_token back to the client.<\/span>
\nThe client unblinds the received token, resulting in a signed_unblinded_token.<\/span>\u00a0<\/span><\/p>\n

Step 2 (token redemption):<\/p>\n

The client sends the original token, signed_unblinded_token, along with the business data it needs for the use case (e.g., logging events) to the server.<\/span>
\nThe server validates the request <\/span>and checks the redemption times for the specific token. If the client is authentic and authorized to access, the server will and process the business data.<\/span>\u00a0<\/span><\/p>\n

Step 0.3 plays an important role in maintaining key transparency. If a malicious server is assigning public keys that correlate to user authentication data, the validation step would fail and the client could refuse to use the public key received.<\/span><\/p>\n

Read the paper \u201c<\/span>DIT: De-identified authenticated telemetry at scale<\/span><\/a>\u201d for more mathematical details for the protocol.<\/span><\/p>\n

The ACS library<\/span><\/h2>\n

The ACS repo<\/span><\/a> provides a portal and extensible C library (in the \/lib\/ folder), whose main components include:<\/span><\/p>\n

The VOPRF protocol: This includes client-side token blinding, unblinding, and generating a shared secret for token redemption. For servers, the protocol includes signing the blinded token and generating a server-side shared secret for token redemption. There are two versions of the blinding method provided in the library.<\/span>
\nAn attribute-based key derivation function: This is a key rotation solution. If the attributes are set to a common known value (e.g., time epoch), clients can verify the authenticity of the server easily<\/span>. <\/span>There are multiple KDFs provided in the library. We recommend Strong Diffie\u2013Hellman Inversion (SDHI) or Naor-Reingold for better key transparency.<\/span>
\nDiscrete log proof: This is used to prove the authenticity of the server. It is used twice in the protocol \u2014 first, to verify the public key derived from attributes in the setup step, and second, to verify the signed token in token issuance step<\/span>
\nElliptic curves: The ACS library is modular, and users can choose preferred elliptic curves. Ed25519 and Ristretto are currently provided.\u00a0\u00a0\u00a0\u00a0\u00a0<\/span><\/p>\n

The library is supposed to be deployed on mobile devices, so we want to minimize external dependencies to keep the binary size small. Currently, libsodium is the only dependency for the ACS library.<\/span><\/p>\n

In addition to that, we have implemented a SimpleAnonCredService (server + client) in C++ for demonstration purposes. The service is built with Apache Thrift 0.16. (See the \/demo\/ folder in the repo.)<\/span><\/p>\n

How to use ACS in a real system<\/span><\/h2>\n

Let\u2019s use an example to demonstrate the workflow. Suppose we are maintaining a service that allows authenticated users to get weather reports. A naive system will look like this:<\/span><\/p>\n

# client
\nget_report(authentication_data)
\n# server
\nif check_authentication(request.authentication_data):
\n response.report = report_data<\/p>\n

The first step is to split the <\/span>authentication_data <\/span>from <\/span>report_data<\/span>, which is the main purpose of the ACS project.\u00a0<\/span><\/p>\n

# client – authentication
\ntoken = random_string()
\nblinded_token, blinding_factor = blind(token)
\nsigned_blinded_token = request_token_from_server(authentication_data, blinded_token)
\nsigned_unblinded_token = unblind(signed_blinded_token, blinding_factor)
\n# client – get data
\nclient_secret = client_finalize(token, signed_unblinded_token)
\nget_report(token, client_secret)
\n# token issuance server
\nif check_authentication(request.authentication_data):
\n signed_blinded_token = evaluate(blinded_token)
\n response.signed_blinded_token = signed_blinded_token
\n# token redemption server
\nserver_secret = server_finalize(request.token)
\nif server_secret == request.client_secret:
\n response.report = report_data<\/p>\n

After the client is authenticated and requests the data it needs, the client generates a token, blinds the token, and sends the token to the server. After an authentication check, the server signs the token and sends it back to the client. The client then unblinds the signed token, and then verifies it with the public key and proof.<\/span><\/p>\n

Finally, the client redeems the token. The server validates the secret key and proceeds to business logic if the validation succeeds. If the validation fails, the server rejects the request.<\/span><\/p>\n

When we introduced key rotation and KDF, it added two more steps in the beginning of the process:<\/span><\/p>\n

The client downloads the primary public key from the server. This primary public key is for validation of the public key in step 2.<\/span>
\nThe client gets a public key for provided attributes. The attributes can be any list of strings (e.g., use case names, dates) that are allowed by the server. KDFs allow for key transparency. After this step, the client will be confident that the server is not assigning a public key related to the authentication information. Later, the public key can be used in the verifiable_unblind <\/span>step to make sure the <\/span>signed_blinded_token <\/span>is signed with the private key corresponding to the verified public key.<\/span><\/p>\n

# client – setup
\nprimary_public_key = request_primary_public_key_from_server()
\n# client – authentication
\npublic_key, pk_proof = get_public_key_from_server(attribute)
\nif !dleqproof_verify(public_key, pk_proof, primary_public_key, attribute):
\n raise Exception(“malicious server!”)
\ntoken = random_string()
\nunblinded_token, blinding_factor = blind(token)
\nsigned_blinded_token, proof = request_token_from_server(authentication_data, blinded_token)
\nsigned_unblinded_token = verifiable_unblind(signed_blinded_token, blinding_factor, proof, public_key)<\/p>\n

With all these steps, we\u2019ve prevented a potentially malicious server from using these key rotations to segregate and identify users. This is a good prototype system and ready to use. But in a scalable system, there are more challenges to conquer, including client-side token storage and server-side rate limiting. These solutions are not included in ACS\u2019s open source repo.<\/span><\/p>\n

Future plans for ACS<\/span><\/h2>\n

Looking at the future, we believe the modular ACS is extensible and has the potential to be beneficial to industries that utilize anonymous credential solutions. We are planning to implement the <\/span>standard<\/span><\/a>.<\/span><\/p>\n

A light version without libsodium dependency will be beneficial to use cases where binary size is limited.\u00a0<\/span><\/p>\n

If you\u2019d like to contribute to the project, please visit the <\/span>ACS GitHub<\/span><\/a>.<\/span><\/p>\n

The post Open-sourcing Anonymous Credential Service<\/a> appeared first on Engineering at Meta<\/a>.<\/p>\n

Engineering at Meta<\/p>","protected":false},"excerpt":{"rendered":"

Meta has open-sourced Anonymous Credential Service (ACS), a highly available multitenant service that allows clients to authenticate in a de-identified manner. ACS enhances privacy and security while also being compute-conscious. By open-sourcing and fostering a community for ACS, we believe we can accelerate the pace of innovation in de-identified authentication. Data minimization \u2014 collecting the… Continue reading Open-sourcing Anonymous Credential Service<\/span><\/a><\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","footnotes":""},"categories":[7],"tags":[],"class_list":["post-661","post","type-post","status-publish","format-standard","hentry","category-technology","entry"],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":559,"url":"https:\/\/fde.cat\/index.php\/2022\/03\/30\/how-meta-enables-de-identified-authentication-at-scale\/","url_meta":{"origin":661,"position":0},"title":"How Meta enables de-identified authentication at scale","date":"March 30, 2022","format":false,"excerpt":"Data minimization \u2014 collecting the minimum amount of data required to support our services \u2014 is one of our core principles at Meta as we continue developing new privacy-enhancing technologies (PETs). We are constantly seeking ways to improve privacy and protect user data on our family of products. Previously, we\u2019ve\u2026","rel":"","context":"In "Technology"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":743,"url":"https:\/\/fde.cat\/index.php\/2023\/08\/08\/how-meta-is-improving-password-security-and-preserving-privacy\/","url_meta":{"origin":661,"position":1},"title":"How Meta is improving password security and preserving privacy","date":"August 8, 2023","format":false,"excerpt":"Meta is developing new privacy-enhancing technologies (PETs) to innovate and solve problems with less data. These technologies enable teams to build and launch privacy-enhanced products in a way that\u2019s verifiable and safeguards user data. Using state-of-the-art cryptographic techniques, we have developed Private Data Lookup (PDL) that allows users to privately\u2026","rel":"","context":"In "Technology"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":629,"url":"https:\/\/fde.cat\/index.php\/2022\/09\/07\/open-sourcing-taobench-an-end-to-end-social-network-benchmark\/","url_meta":{"origin":661,"position":2},"title":"Open-sourcing TAOBench: An end-to-end social network benchmark","date":"September 7, 2022","format":false,"excerpt":"What the research is: The continued emergence of large social network applications has introduced a scale of data and query volume that challenges the limits of existing data stores. However, few benchmarks accurately simulate these request patterns, leaving researchers in short supply of tools to evaluate and improve upon these\u2026","rel":"","context":"In "Technology"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":258,"url":"https:\/\/fde.cat\/index.php\/2021\/02\/07\/open-sourcing-thrift-for-haskell\/","url_meta":{"origin":661,"position":3},"title":"Open-sourcing Thrift for Haskell","date":"February 7, 2021","format":false,"excerpt":"What it is: Thrift is a serialization and remote procedure call (RPC) framework used for cross-service communication. Most services at Facebook communicate via Thrift because it provides a simple, language-agnostic protocol for communicating with structured data. Thrift can already be used in programming languages such as C++, Python, and Java\u2026","rel":"","context":"In "External"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":480,"url":"https:\/\/fde.cat\/index.php\/2021\/09\/29\/open-sourcing-mariana-trench-analyzing-android-and-java-app-security-in-depth\/","url_meta":{"origin":661,"position":4},"title":"Open-sourcing Mariana Trench: Analyzing Android and Java app security in depth","date":"September 29, 2021","format":false,"excerpt":"We\u2019re sharing details about Mariana Trench (MT), a tool we use to spot and prevent security and privacy bugs in Android and Java applications. As part of our effort to help scale security through building automation, we recently open-sourced MT to support security engineers at Facebook and across the industry.\u00a0\u2026","rel":"","context":"In "Technology"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":517,"url":"https:\/\/fde.cat\/index.php\/2021\/12\/16\/event-sourcing-for-an-inventory-availability-solution\/","url_meta":{"origin":661,"position":5},"title":"Event Sourcing for an Inventory Availability Solution","date":"December 16, 2021","format":false,"excerpt":"Co-author\u200a\u2014\u200aBalachandar Mariappan An Introduction to Terminology ATF\u200a\u2014\u200aAvailable to Fulfill inventoryOn-Hand\u200a\u2014\u200aPhysical amount of Inventory availableSKU\u200a\u2014\u200aStock Keeping Unit, which represents a distinct type of item for\u00a0sale.Location\u200a\u2014\u200aRepresentation of a physical location like a store or warehouse where SKU\u2019s are\u00a0presentLocation Group\u200a\u2014\u200aA Logical aggregation of typically one or more Locations.Reservation or Inventory Reservation\u200a\u2014\u200aReserving a quantity\u2026","rel":"","context":"In "Technology"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/posts\/661","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/comments?post=661"}],"version-history":[{"count":0,"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/posts\/661\/revisions"}],"wp:attachment":[{"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/media?parent=661"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/categories?post=661"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/tags?post=661"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}