Understanding Citadel: How Does It Work Under the Hood?

Citadel is a zero-knowledge proof solution where users and institutions have full control over their personal or sensitive information. Here we explore how it works from the technical perspective, describing the main points of the protocol for the sake of completeness.

NOTE: This is a Citadel explanation for the sake of completeness. Refer to the original paper to learn more about the details.

Self-Sovereign Identity (SSI) refers to a concept where an individual is able to manage their identity in a fully transparent and private manner. This means that at any moment, such an individual knows what information about them is being shared with others while interacting with them. We are talking about a scenario where we have a service provider (SP) providing services to different users, all wanting to manage their identities using an SSI mechanism.

Using Citadel, a user and an SP interact with each other by means of the Dusk Network, and the following properties are satisfied:

• Proof of Ownership: the user can prove ownership of a license, without revealing anything beyond the fact that such a statement is true (i.e. that they actually own that license).
• Proof of Validity: SPs have the power to revoke licenses, which after being issued are included in a Merkle tree. In other words, SPs can remove, by consensus, licenses from the Merkle tree. That’s why users need to provide a membership proof, that demonstrates that a given license is still valid.
• Unlinkability: any activity done by a user cannot be related by anyone to any other activity done in the network.
• Decentralized Nullification: when spending a license, the whole network learns that a license has been spent, so it won’t be spendable again.
• Attribute Blinding: the user commits to their personal information and is able to leak only the desired piece of information.

But, how is all this achieved? Before going into detail about the Citadel protocol, we need to talk about its main building block: a novel private NFT model we built for this purpose. Basically, an NFT is a piece of information that is minted in the blockchain and belongs to someone. Taking the very same approach used in Dusk to handle money (the notes), we created a model where users can input any value they want as the payload of the note, instead of an amount of money. Like this, anyone can mint a new note with any input addressed to someone. And the interesting thing is that such a value remains private, as well as the sender and the receiver.

So now, how does Citadel work? The first step is for a user to request a license from the SP to use their service. In order to do that, many options are possible. For example, the SP might request payment in Dusk coins. As such, the user will pay the SP, and the important thing here is that included in the transaction will be an NFT whose value is a note public key (a.k.a. stealth address) belonging to the user - the address where the user wants the license to be received.

As soon as the SP verifies that the payment is correct, they will set the attributes that define this user (e.g. the ticket and seat number for an event) and will sign them, along with the note public key (like this, the license is tied to a given user, and thus cannot be transferred). These two elements will be minted as an NFT addressed to the note public key set by the user, and as soon as the user receives it, they will be able to use such a license.

The user will compute a ZKP that verifies the signature provided by the SP, using its public key. Such a proof will be transacted in the Dusk blockchain, in order to nullify such a license so that it cannot be used again. As such, the user needs to sign the transaction using the note secret key of the license, and such a signature is also verified in-circuit. As both the license and the transaction signatures are in-circuit related by a single note public key, the user is proving that such a license is owned by them. Furthermore, the user will verify in-circuit a Merkle proof that proves that such a license is currently included in the Merkle tree of notes.

But there is more: depending on the use case, a license can be used once, or multiple times. For such a reason, the SP might request the user to set a specific challenge value as an input for the computation of the license nullifier. This value can always be 0, and like this, the nullifier will always be the same and thus, accepted only once by the network. Or, it can be a value like a day/month/year timestamp, that allows users to use the license once per day (as the nullifier will change every day), as an example.

Finally, there is attribute blinding. The user attributes, the public key of the SP, and the challenge are private inputs of the circuit, so no-one learns those values. However, the SP needs to actually verify them. For such a reason, the user commits in-circuit to those and provides the openings as an NFT along with the transaction. Those openings are what we call the session cookie, a value known only by the user and the SP, and that refers only to a single transaction.

So, the user transacts such a proof, along with the session cookie NFT. Then, they can actually use such a license, by simply sending off-chain the session cookie to the SP through a secure channel, to authenticate. As only the user can know such a cookie, the SP knows for sure that that given user is the same one that created the transaction previously received. Plus, it can verify the openings included in the session cookie, to be sure that the attributes, the public key of the SP, and the challenge are correct. Now, the user is granted access to the service.

Additional properties of Citadel are its full integration with Dusk. For example, the same proof delegation mechanism that is used to delegate heavy computational tasks to trusted parties works with Citadel as well. Moreover, no additional information needs to be stored or remembered by the user to get their licenses back after installing the wallet into a new device, beyond the secret seed itself.

As per the future work on this project, as soon as we are ready with Piecrust, we will be able to plug in the gadget (the one that allows users to spend licenses, right now available in our repository) into the transfer contract, do the needed changes to the wallet to handle the licenses, and start testing it out in our testnet. Furthermore, we will work on new iterations over the paper, providing a formal model for Citadel, and a formalization of the security analysis.