Blocklistable Anonymous Credential for Circuits with Post-quantum Security

Abstract

A blocklistable anonymous credential system (BLAC) allows a service provider to decide if it would like to accept an anonymous user according to his historical behaviors. Security of such systems requires that 1) a user can be authenticated if and only if his historical behaviors satisfy a given policy and that 2) no additional information (besides the result of the authentication) is revealed to the service provider. Existing constructions of BLAC only consider very restricted access policies, e.g., blocking a user if he has an authentication record that is marked as misbehaved. Besides, most of them are constructed from number theoretical assumptions, which are vulnerable to the quantum attacks.

In this work, we advance the state-of-the-art for BLAC. First, we present the notion of BLAC for circuits, where the service provider can use general policies that are represented by any boolean circuits and admit a user if and only if his historical records satisfy the circuit. Then, we construct BLAC systems for arbitrary circuits from lattice assumptions, which offer post-quantum security. To obtain our constructions, we propose efficient lattice-based zero-knowledge arguments for various relations, which may be of independent interest. Besides, we demonstrate the practicality of our constructions by providing an estimation of the communication cost of our system.

A Construction of Dynamic BLAC and Decentralized BLAC

In this section, we give the constructions of lattice-based dynamic BLAC system and decentralized BLAC system.

1.1 A.1 Construction of Dynamic BLAC

In this section, we give the construction of dynamic BLAC system, where system users could dynamically join and leave (or being revoked from) the system. Despite it may seem useless to design a BLAC system with user revocation functionality, as it can be simply achieved by embedding the list of revocation users into the access policy. However, this will introduce additional increase to the size of policy circuit, especially in the case that the number of revocation users is huge. Consequently, the proof size generated in authentication protocol will get increased. While, the revocation method used in our construction avoids these disadvantages.

The construction of our dynamic BLAC works as follows:

• Setup. This protocol is nearly the same as the Setup algorithm in static BLAC system, except with the follows:

  • Sample a random matrix $\textbf{M} \in Z_{q}^{n \times nk_q}$, and a random string $\textbf{msk} \in \{0,1\}^{nk_q}$, then compute $\textbf{mpk} = \textbf{M} \cdot \textbf{msk} \mod q$.

  • GM maintains a table named as $S^{*} = (\boldsymbol{y}_1^{*},\boldsymbol{y}_2^{*}, \ldots , \boldsymbol{y}^{*}_{N} )$, where for $i \in [N]$, $\boldsymbol{y}^{*}_i= \textbf{0}^{nk_q}$. Here, $\boldsymbol{y}^{*}_{i}$ is used to store the information about the public-key of the legitimately registered users. Then build an updatable accumulator based on $S^{*}$, namely, the Merkle-tree is an all-zero tree at the current stage.

  • Counter of registered users $c=0$.

  Finally, it sets the group public key as $(N, \boldsymbol{A},\boldsymbol{D},\boldsymbol{P}, \textbf{M},\textbf{mpk})$, while the master secret key hold by group manager is $\textbf{msk}$.

• Registration. This protocol works nearly the same way as the Registration protocol in Sect. 4.1, except the way that GM enrolls user into the system. More precisely, for a user with public key $\boldsymbol{y}$, GM first issues a unique identifier to the user as $\textsf{bin}(c) \in \{0,1\}^{\ell }$, then calculate $\boldsymbol{y}^{*}$ from $\boldsymbol{y}$. Next, GM runs ${\textbf {ACC.Update}}(\textsf{bin}(c), \boldsymbol{y}^{*})$ to update the c-th leaf in the Merkle-tree to be $\boldsymbol{y}^{*}$ and get the new root value. Finally, GM increases the counter $c= c+1$. The user completes the registration process with private credential $\boldsymbol{s}$ and public key $(\textsf{bin}(c),\boldsymbol{y})$.

• Update. This protocol is run by GM to update the group information, namely, the witness for a user that he is enrolled in the system and advance the system time clock $\tau$.

  • 1. Let set $R = \{\boldsymbol{y}^{*}_{j_1}, \boldsymbol{y}^{*}_{j_2}, \ldots , \boldsymbol{y}^{*}_{j_{t}}\}$ be the set of revoked users. If R is empty, then go to Step 2 directly. Otherwise, for each ${j} \in \{j_1, j_2, \ldots , j_{t}\}$, GM updates the corresponding j-th element of the accumulated set $S^{*}$ to be $\boldsymbol{y}^{*}_j = {\textbf {0}}^{nk_{q}}$, and updates accumulator by running ${\textbf {ACC.Update}}(\textsf{bin}(j), \boldsymbol{y}^{*}_j)$. Note that only user with non-zero public key could authenticate himself to SP in the new epoch $\tau$.

  • 2. Next, GM broadcasts the system information of current system time clock $\tau$. In particular, the public system information is denoted as $\textsf{Info}_{\tau } = (\tau , \textbf{u}_{\tau }, \{\omega _j\}_{j \in [N]})$,i.e., the latest accumulator value and witness for each legitimated user. Note that, $\textsf{Info}_{\tau }$ is signed by GM to guarantee the integrity and the Merkle-tree based accumulator can only be modified by GM.

• Authentication. In this protocol, a user (with private credential $\boldsymbol{s}$ and public key $(\textsf{bin}(c), \boldsymbol{y})$) first checks the validity of the signature for $\textsf{Info}_{\tau }$ and whether $\textsf{Info}_{\tau }$ contains a witness for node indexed as $\textsf{bin}(c)$. If both yes, user proceeds in the same way as the Authentication protocol of static DBLC system. Otherwise, outputs $\perp$.

The security of our proposed dynamic BLAC system is guaranteed by the following theorem whose proof will be presented in the full version of the paper.

Theorem A.1

Assume the worst-case hardness of GapSVP$_{\gamma }$ (or SIVP$_{\gamma }$) for some polynomial $\gamma$, then the blocklistable anonymous credential system constructed above is a secure BLAC system in the random oracle model.

1.2 A.2 Construction of Decentralized BLAC

In this section, we give a construction of decentralized blocklistable anonymous credential system for circuits, where no trusted party is needed to register users. To achieve this, our construction employs a public append-only ledger $\mathcal {F}_{BB}^{*}$ (see [40] for its formal description), which can guarantee the integrity of data uploaded, provide a consistent view of the ledger and the latest data on the ledger for every party, and be instantiated by blockchain technology.

The construction of the system works as follows:

• Setup. This protocol proceeds in the same way as it in Sect. 4.1 and outputs public parameter as $(N,\boldsymbol{A}, \boldsymbol{D}, \boldsymbol{P})$.

• Registration. In this protocol, a user with auxiliary information $\textsf{aux}$ and attributes $\textsf{att}$ conducts some operations to register himself to the system. Here auxiliary information $\textsf{aux}$ and attributes $\textsf{att}$ are used to aid the service provider in deciding whether to accept the user as a valid candidate user for accessing their services. In particular, user generates his own public/privates keys and proof $\varPi _{RES}$ as before except that $\varPi _{RES}$ is on message $\textsf{aux}$ and $\textsf{att}$. Then user stores $(\textsf{Nym}, \boldsymbol{y}, \varPi _{RES},\textsf{aux},\textsf{att})$ to the public ledger and completes the registration.

• Authentication. Here, a user with private credential $\boldsymbol{s}$ and public key $(\boldsymbol{y}, \textsf{aux},\textsf{att})$ attempts to authenticates himself to a SP sid. Firstly, the user downloads the access requirement $(U,\textsf{C}, \mathcal {L})$ from the public ledger, where $U = \{ \boldsymbol{y}_1, \boldsymbol{y}_2, \ldots , \boldsymbol{y}_{N}\}$ is the candidate user set specified by $\textsf{sid}$, $\textsf{C}$ is the policy circuit and $\mathcal {L} =\{ (\mu _i, \boldsymbol{t}_i)\}_{i \in [1, \vert \mathcal {L} \vert ]}$ is the historical access list.

  Then the protocol proceeds nearly the same as the Authentication protocol in Sect. 4.1 except that user (resp. SP) needs to build the accumulator on set U by himself and performs all relevant computations on that accumulator value.

• Interaction with The Ledger. There are mainly two kinds of interactions among system participants and the public ledger, namely, uploading data to and obtaining data from the public ledger. To obtain data from the ledger, any participant of the system just needs to submit a “retrieve” request to $\mathcal {F}^{*}_{BB}$. Both users and service providers could upload data to the ledger through submitting a “store” request together with its pseudonym and its data to $\mathcal {F}^{*}_{BB}$. Recall that, a user needs to upload personal information in the registration process. A service provider could upload the access requirement $(U,\textsf{C},\mathcal {L})$ and access history $(\mu , \textbf{t})$ of a successfully authenticated user to the historical access list $\mathcal {L}$.

Security of the decentralized BLAC system given above is guaranteed by the following theorem whose proof will appear in the full version of the paper.

Theorem A.2

Assume the worst-case hardness of GapSVP$_{\gamma }$ (or SIVP$_{\gamma }$) for some polynomial $\gamma$, $\mathcal {F}^{*}_{BB}$ is a secure public append-only ledger, then the blocklistable anonymous credential system constructed above is a secure BLAC system in the random oracle model.