You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 5, 2025. It is now read-only.
This Repository is created as a PoC (Proof of Concept) as part of the project *Toekomstbestendig maken UZI*, and
3
-
**should not be used as is in any production environment**.
1
+
# PoC with Yubikey
4
2
5
-
# Wat doet dit?
3
+
In order to automate certificate issuance for UZI, a PoC was done with a YubiKey and an ACME server. The keypairs are generated on the YubiKey and the certificate is issued by the ACME server. This program is designed to start with a _new_ YubiKey, meaning it should have the default PIN. This document will give you an high overview.
6
4
7
-
Dit neemt een yubikey (doe maar versie 5) en maakt daarin de PIV module *leeg*
5
+
### Steps
8
6
9
-
Nadat deze leeg is worden er 4 keys aangemaakt in de yubikey
7
+
- The YubiKey is reset: all the certificates on the device will be removed and the PIN code will be reset.
8
+
- We will generate 4 public and private key pairs on the YubiKey. These are for PIV Authentication, Digital Signature, Key Management and Card Authentication. Next to that, the YubiKey will generate additional attestation certificates, to prove that the private key is generated on the YubiKey itself. The private keys will always remain in the YubiKey.
9
+
- The user logs in via the chosen [authentication flow](./AUTH_FLOW.md). This returns an JWT, containing the user information.
10
+
- Per generated key pair, an certificate signing request (CSR) is created and signed by the private key.
11
+
- Finally, each certificate signing request with the corresponding attestation certificate is validated at the ACME server. When this is done, the server will issue an certificate for every key pair. Here, the JWT of the user is also used. This is done with the ACME server of iRealisatie. These are then saved back into the YubiKey into the corresponding slot.
10
12
11
-
Er wordt contact gelegd met de rdo-acme service. En er worden 4 orders aangemaakt
13
+
Now it is possible to use the certificate on the YubiKey to sign data.
12
14
13
-
Van deze 4 orders wordt de unique-anti-replay-token meegestuurd met een uzi-labs digid login verzoek
15
+
#### Diagram flow
14
16
15
-
Er wordt een browser geopend in de applicatie zelf, daarmee log je in als zorg identiteit bij de ziekenboeg-uzi-labs
17
+
This diagram expects that the Yubikey is already plugged in the user's computer. Next to that, it's expected that the user should use the **DigiD mock** login method.
16
18
17
-
De app haalt hierna de JWT-token op bij ziekenboeg-uzi-labs waarin de 4 acmetokens zitten.
19
+
```mermaid
20
+
sequenceDiagram
21
+
actor APP
22
+
participant YUBIKEY
18
23
19
-
Er wordt van de yubikey zelf opgehaald:
20
-
* Het intermediate certificaat behorende bij de yubikey zoals geleverd door yubico op de yubikey zelf
24
+
APP->>YUBIKEY: 1. Sends request to empty the Yubikeys certificates
25
+
YUBIKEY-->YUBIKEY: Empties the certificates
21
26
22
-
Per sleutel op de yubikey:
23
-
* Een door de yubikey ondertekend certificaat per sleutel waarin de garantie (attestation) staat dat de sleutel echt op een yubikey is gemaakt
24
-
* een CSR verzoek ondertekend door de aangemaakte sleutel
27
+
APP->>YUBIKEY: 2. Sends request to generate 4 new private key pairs
28
+
YUBIKEY-->YUBIKEY: 2.1 Create key pair for PIV Authentication
29
+
YUBIKEY-->YUBIKEY: 2.2 Create key pair for Digital Signature
30
+
YUBIKEY-->YUBIKEY: 2.3 Create key pair for Key Management
31
+
YUBIKEY-->YUBIKEY: 2.4 Create key pair for Card Authentication
25
32
26
-
Per order wordt dan verstuurd:
27
-
* De JWT
28
-
* Het yubikey intermediate certificaat
29
-
* Het attestation certificaat
33
+
create participant MAX
34
+
APP->>MAX: 3. Opens browser to login the user
35
+
MAX-->MAX: 3.1 Validates the user
36
+
MAX-->>APP: Returns the JWT containing the user information.
30
37
31
-
De acme server controleert dan per order:
32
-
* of het attestation certificaat van de sleutel klopt
33
-
* het token voor order in de JWT zit
34
-
* De JWT goed is en van een geldige uzi-cibg-labs-uitgever komt
38
+
APP->>APP: 4. Per generated key pair, <br> an certificate signing request (CSR)<br> is created and signed by the private key.
35
39
36
-
Als dat klopt dan geeft de acme server terug dat het klopt en dan vraagt deze app in de laatste stap een certificaat aan met de eerder genoemde CSR.
40
+
create participant ACME_SERVER
41
+
loop 5. For every certificate signing request (CSR)
42
+
APP->>ACME_SERVER: Validate every certificate signing request with the corresponding attestation certificate
43
+
ACME_SERVER-->>APP: OK
44
+
end
37
45
38
-
Als de CSR dezelfde public key heeft als in de vorige stap gecontroleerde gegevens wordt er een Labs-UZI certifcaat uitgegeven op basis van de gegevens in de JWT.
39
-
Dit certificaat bevat de huidige UZI-Certificaten structuur.
46
+
loop 6. For every key pair
47
+
APP->>ACME_SERVER: Request certificate for every key pair, also using the users' JWT
48
+
ACME_SERVER-->>APP: OK
49
+
ACME_SERVER-->>YUBIKEY: Save certificates
50
+
end
40
51
41
-
Als er een certificaat is opgehaald wordt dit opgeslagen op de juiste plek in de yubikey.
52
+
```
42
53
43
-
Door het laden van de yubikey pkcs11 library in de browser, office, mac os, windows of linux plekken (zoals beschreven door yubico) kan de yubikey daarna
44
-
worden gebruikt zoals een UZIpas ook gebruikt kan worden. Voor digitaal ondertekenen van documenten, verzoeken en om in te loggen in de browser bij
45
-
partijen die UZI certificaten login mogelijk maken.
54
+
### Disclaimer
55
+
56
+
This Repository is created as a PoC (Proof of Concept) as part of the project _Toekomstbestendig maken UZI_, and **should not be used as is in any production environment**.
57
+
58
+
### Licentie
59
+
60
+
This project is licensed under the [EUPL-1.2 license](./LICENSE.txt).
0 commit comments