SSI Authentication and Authorization Protocol for Web Resource Access; verified using ProVerif (and DeepSec)
This repository contains the formal verification of security properties of the protocol flow for authentication and authorization for Web resource access. We use ProVerif for proving secrecy and agreement, and use DeepSec for proving unlinkability.
The structure of our GitHub repository.
Plain VCs | Secrecy | 1 | ssipv.pv#L287 | [x] | [ ] |
2 | archive/ssipv_forward_secrecy.pv | [x] | [ ] | ||
Agreement | 3 | ssipv.pv#L309 | [x] | [ ] | |
4 | ssipv_ok_VP_leaked.pv | [x] | [ ] | ||
5 | ssipv_unforgeable_VC.pv | [x] | [ ] | ||
6 | ssipv_attack_domain_missing_replay.pv | [ ] | [x] | ||
7 | ssipv_attack_no_nonce_VP_leaked.pv | [ ] | [x] | ||
8 | ssipv_attack_VC_reissued.pv | [ ] | [x] | ||
Unlinkability | 9 | ssipv_unlinkable.dps | [x] | [ ] | |
10 | ssipv_attack_verifier_unlinkablity.dps | [ ] | [x] | ||
Anon VCs | Secrecy | 11 | ssipv.pv#L297 | [x] | [ ] |
Agreement | 12 | ssipv.pv#L319 | [x] | [ ] | |
Unlinkability | 13 | ssipv_unlinkablity_ok_wrt_verifier.dps | [x] | [ ] | |
Plain VCs + Diffie-Hellman | Secrecy | 14 | ssipv.pv#L302 | [x] | [ ] |
Agreement | 15 | ssipv.pv#L324 | [x] | [ ] | |
Anon VCs + Diffie-Hellmann | Secrecy | 16 | ssipv.pv#L312 | [x] | [ ] |
Agreement | 17 | ssipv.pv#L334 | [x] | [ ] | |
For a description of the potential attacks when deviating from the protocol, visit the Plain VCs parent directory.
For more detailled information, visit the corresponding "protocol directories", i.e.,
- Plain VCs for an instance of the protocol using plain/simple Verifiable Credentials (VCs) and DIDComm (which is typically the instance of the protocol we refer to),
- Anon VCs for an instance of the protocol using anonymous credentials and DIDComm,
- Plain VCs + Diffie-Hellmann for an instance of the protocol using plain/simple Verifiable Credentials (VCs) and a Diffie-Hellmann handshake, and
- Anon VCs + Diffie-Hellmann for an instance of the protocol using anonymous credentials and a Diffie-Hellmann handshake.
The protocol is indended for a client-server scenario on the Web. A client desires are Web resource served by the server. Upon request, access is denied and the client is pointed towards the authentication-authorization endpoint. The client acts as the prover and the authentication-authorization endpoint acts as the verifier.
The authentication-authorization endpoint enforces predefined access control rules (ACRs). These ACRs specify which attribute the prover needs to have asserted by which issuer.
In a nutshell, Verifiable Credentials (VCs) enable an agent (the "holder") to prove to a second agent (the "verifier") that a third agent (the "issuer") has asserted and signed some statements or claims. In other words, with a presentation of a VC an agent proves to a verifying agent that
- they are in possession of the VC
- the VC was issued by a particular issuer (agent)
- the VC contains some claims, e.g., attributes of the holder
- the VC was presented by the proving agent, e.g., the holder itself
For example, consider the use case of a student accessing online teaching material of some guest professor. Here, the student's university, the issuer, provides the student, the holder, a digital student credential, which asserts that the holder is a student signed by the university. A guest professor at the university has a (private) Web server where online teaching material is accessible only to students of the university they are guest lecturing at. As the professor does not know all the students, i.e., the group of all students is private, the professor can not grant this group access to the Web resources. To gain access to the online teaching material, the students have to prove that they are really enrolled at the university using a presentation, i.e., a VP, of the corresponding digital student credential, i.e., the VC. This VP includes the VC and some additional meta data, and is typically signed by the holder to prove that the student assertion is really about them. In this way, the professor's Web server can verify the above mentioned facts (1)-(4). The use case is generaliseable to general accessing resources on the Web.
How do the students know that they are really talking to the professor (or his Web server) when authenticating online? The students may look up the personal homepage of the professor where the professor's identifier (the professor's DID) is advertised. With that, the system relies on the Domain Name System (DNS) and the transport protocol of HTTPS to ensure that agents are able to be identified correctly. Other approaches, as mentioned below, may include government registries, governed blockchains or smart contracts.
- The Self-Sovereign Identity (SSI) assumption:
All agents can mint and manage a keypairs in a self-sovereign manner. - The Decentralised Identifier (DID) assumption:
All agents assume that the (integrity of the) link between DID of an agent, the thereby advertised public key and corresponding secret key can be trusted, in the sense that we assume that only the controller of the DID (the agent in control of the corresponding secret key) is able to modify/update the public key linked to the DID. Each agent is thus assumed to keep the link between the DID, the thereby advertised their public key and their corresponding secret key, intact (meaning they use the corresponding secret key in communication). Possible implementations e.g. via certification using DNS, in government registries, governed blockchains or smart contracts. - The Verifier-Issuer assumption:
The verifier assumes the issuer to have due diligence on validating the assertions they make, e.g. that Holder is actually a student (which may be out-of-band). The verifier thus assumes that the issuer behaves honestly according to the protocol (given the context of the use case).
An interesting observation is that, the holder checking the signature of an anonymous credential after issuance and before usage in a provenance session is not as critical for authentication as it is for regular VCs (in short, because zero-knowledge proofs never reveal the anonymous credential itself, only a proof-of-possession of the anonymous credential). Yet, the holder checking the signature and contents of an anonymous credential after issuance and before usage is critical for unlinkability (in short, because an issuer may attempt to inject unsolicited identifying information into the attributes).
Find a Message Sequence Chart (MSC) of the plain model here.
Here, we give the corresponding formal model (cf. Proverif code):
M, N, K ::= | x | |||
(M, |
||||
Holder |
Issuer |
---|---|
Prover |
Verifier |
---|---|
Issuer |
Holder |
Verifier |
---|---|---|