Init commit: stub README; RFI for hs_pki_uc needed
commit
f5c69eaf0b
|
@ -0,0 +1,108 @@
|
||||||
|
Hardware:
|
||||||
|
Root CA:
|
||||||
|
~raspi:
|
||||||
|
+ USB / integrated / SFF ICC reader
|
||||||
|
+ USB / external reader
|
||||||
|
~+ 5 additional USB for external ICC readers for bootstrap process to be more convinient
|
||||||
|
+ USB / storage for moving artifacts
|
||||||
|
+ Serial interface for I/O
|
||||||
|
~+ Dummy terminal (better) or USB keyboard + VGA
|
||||||
|
|
||||||
|
CA:
|
||||||
|
~raspi:
|
||||||
|
+ USB / integrated / SFF ICC reader
|
||||||
|
+ USB for KC
|
||||||
|
+ USB for audit log replication (or syslog dependency + offline backup)
|
||||||
|
+ network interface
|
||||||
|
|
||||||
|
KC:
|
||||||
|
~ USB reader for his workstation
|
||||||
|
|
||||||
|
Bootstraping Root CA (ca be Root CA, but other ICC readers through USB)
|
||||||
|
* 2 ICC readers for Root_CA_ICC
|
||||||
|
* 2 ICC readers for CA_ICC
|
||||||
|
* 2 ICC readers for KC ICC
|
||||||
|
* 1 port for USB storage
|
||||||
|
Root CA
|
||||||
|
* 1 Root CA ICC reader
|
||||||
|
* 1 KC ICC
|
||||||
|
* 1 for USB storage
|
||||||
|
|
||||||
|
Components:
|
||||||
|
- Root CA ICC (javacard + nxp)
|
||||||
|
* Root CA signing keypair
|
||||||
|
* CA keypair (for issuing KC certificates)
|
||||||
|
|
||||||
|
- CA ICC (javacard + nxp)
|
||||||
|
* CA signing keypair (for end-user/device certificate issuing)
|
||||||
|
* CA server keypair (for communication between CA's)
|
||||||
|
|
||||||
|
- CA tools/interfaces (go? python? java)
|
||||||
|
|
||||||
|
- CA server (webservice API + gui + queue srvc)
|
||||||
|
|
||||||
|
- KC ICC (javacard + NXP)
|
||||||
|
* CA key share
|
||||||
|
* KC Signing certificate (US CAC interface?)
|
||||||
|
|
||||||
|
- KC tools (go? python? java)
|
||||||
|
|
||||||
|
- Monitor ICC (javacard + NXP)
|
||||||
|
|
||||||
|
Roles:
|
||||||
|
- Root CA: Issue CA ceritifcates and KC certificates (at least N>2)
|
||||||
|
- CA: Issues end-user/device certificates (N>2)
|
||||||
|
- Key Custodian: PKI peptide control interface (N>2)
|
||||||
|
- Key Custodian: CA KC performing action in ceremony.
|
||||||
|
- Master of Ceremony: PKI meta-peptide control interface for CA ceremonies.
|
||||||
|
Should not be Key Custodian during ceremony. N=1
|
||||||
|
- Key Manager: Spin all this shit around.
|
||||||
|
- Auditor: Looking at others hands.
|
||||||
|
|
||||||
|
I Bootstrap
|
||||||
|
|
||||||
|
A KC cards
|
||||||
|
?> First 2 KCs generate their keys and CSR's on KC ICC using KC tools.
|
||||||
|
This can be done on their workstation, but doing it on Root CA will be more convinient.
|
||||||
|
|
||||||
|
># KC init
|
||||||
|
<# Set PIN
|
||||||
|
># ****
|
||||||
|
<# PIN set
|
||||||
|
<# DN:
|
||||||
|
># cn=<username>,ou=pki,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
<# KC ICC done
|
||||||
|
|
||||||
|
<- KC1_ICC:KC1PK
|
||||||
|
<- KC1.csr
|
||||||
|
<- KC2_ICC:KC2PK
|
||||||
|
<- KC2.csr
|
||||||
|
|
||||||
|
B Root_CA_1
|
||||||
|
|
||||||
|
CA_N1
|
||||||
|
-> Key manager initiates self-generation of asymmetric crypto keys on 1st CA ICC and
|
||||||
|
sets two initial KC:
|
||||||
|
|
||||||
|
># ca init -a KC1.csr -a KC2.csr
|
||||||
|
<# CA
|
||||||
|
|
||||||
|
<- CA_N1_ICC:CA_sigPK
|
||||||
|
<- CA_N1_ICC:CA_srvPK
|
||||||
|
<- CA_N1_ICC:CA_admPK
|
||||||
|
<- CA_N1_InitCAsig.crt
|
||||||
|
<- CA_N1_InitCAsrv.crt
|
||||||
|
<- CA_N1_InitCAadm.crt
|
||||||
|
<- CA1_KC1.crt
|
||||||
|
<- CA1_KC2.crt
|
||||||
|
|
||||||
|
C CA_N2
|
||||||
|
-> Key manager initiates key generation on 2nd CA ICC
|
||||||
|
|
||||||
|
># ca
|
||||||
|
|
||||||
|
.B same as 1.A but on 2nd CA ICC and any further CA ICC
|
||||||
|
|
||||||
|
|
||||||
|
1. NXP Java card as keystore
|
||||||
|
2. Token concept?
|
|
@ -0,0 +1,40 @@
|
||||||
|
ou=Peoples,dc=hackerspace,dc=pl
|
||||||
|
ou=Services,dc=hackerspace,dc=pl
|
||||||
|
ou=Group,dc=hackerspace,dc=pl
|
||||||
|
|
||||||
|
#Root of PKI
|
||||||
|
cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
|
||||||
|
# Certificate templates (access for server ro, KC rw)
|
||||||
|
ou=Templates,ou=Certificate,cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
|
||||||
|
# Authoritative Information Extension (CA bundle; all CA certificates are published here,
|
||||||
|
# each CA has it's own subtree here)
|
||||||
|
cn=AIA,cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
cn=CA1,cn=AIA,cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
cn=CA2,cn=AIA,cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
...
|
||||||
|
|
||||||
|
# PKI KC certs store (rw for servers, ro for KC):
|
||||||
|
cn=KC,cn=AIA,cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
uid=enleth,cn=KC,cn=AIA,cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
uid=cranix,cn=KC,cn=AIA,cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
uid=q3k,cn=KC,cn=AIA,cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
|
||||||
|
# CRL Distribution Points - each CA has its own
|
||||||
|
cn=CDP,cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
cn=CA1,cn=CA1,cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
cn=CA2,cn=CA2,cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
...
|
||||||
|
|
||||||
|
# Issued certificates
|
||||||
|
cn=Certificates,cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
uid=d3llf,cn=Certificates,cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
|
||||||
|
# End user certificates
|
||||||
|
cn=People,cn=Certificates,cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
|
||||||
|
# Application certificates
|
||||||
|
cn=App1,cn=Certificates,cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
cn=App2,cn=Certificates,cn=PKI,ou=Services,dc=hackerspace,dc=pl
|
||||||
|
...
|
|
@ -0,0 +1,12 @@
|
||||||
|
Root CA cert valid for 6y
|
||||||
|
Root CA CRL valid for 14m
|
||||||
|
* need ceremony at least once per y to renew CRL
|
||||||
|
|
||||||
|
KC certificates valid for 8m (verify calculation of influence on possible new CA)
|
||||||
|
|
||||||
|
CA certs valid for 1y
|
||||||
|
Limited certificate depth to 1 (so it can't issue CA)
|
||||||
|
|
||||||
|
CA CRL valid for 1d (or even less)
|
||||||
|
|
||||||
|
End user / device certificates valid for 3m
|
|
@ -0,0 +1,19 @@
|
||||||
|
End user:
|
||||||
|
End user split in:
|
||||||
|
- soft stored certs
|
||||||
|
- obfuscated certs
|
||||||
|
- hardware secured certs
|
||||||
|
|
||||||
|
End user:
|
||||||
|
- Client certs (auth)
|
||||||
|
- E-mail certs (signing)
|
||||||
|
- Encryption
|
||||||
|
|
||||||
|
Device:
|
||||||
|
- TLS certs (encr/auth)
|
||||||
|
* server
|
||||||
|
* client
|
||||||
|
* server+client(?)
|
||||||
|
|
||||||
|
All above should be issued per application or generally applications should
|
||||||
|
leverage main user certificate
|
|
@ -0,0 +1,33 @@
|
||||||
|
UC1. Bootstraping itself
|
||||||
|
UC2. Issuing new certificates
|
||||||
|
UC2.1 Key Generation + Archival
|
||||||
|
UC2.2 Signing external CRL's
|
||||||
|
UC3. Revoking existing keys (CRL)
|
||||||
|
UC3.1 Renewing CRL (no need of KC interaction if there was no additional certs)
|
||||||
|
UC3.2? DeltaCRL
|
||||||
|
UC4. Monitoring
|
||||||
|
UC5. Backup
|
||||||
|
UC5.1 Backup verification
|
||||||
|
UC6 High availability (cluster)
|
||||||
|
UC6.1 Adding/decomissioning new Root CA node to PKI cluster
|
||||||
|
UC6.2 Adding/decomissioning new CA node to PKI cluster
|
||||||
|
UC6.3 Adding/decomissioning new Monitor
|
||||||
|
UC7 RA
|
||||||
|
UC7.1 RA notifies KC on new requests (ra@pki.hackerspace.pl?)
|
||||||
|
UC Agent(?) to request/renew certificates from end device
|
||||||
|
UC ICC deployment agent (for issuing member cards)
|
||||||
|
UC Renewing member certificate / lost password (other 2 members is enough,
|
||||||
|
no KC need to be involved)
|
||||||
|
UC ICC for servers (how to secure?)
|
||||||
|
UC Agent(?) to fetch CRL
|
||||||
|
UC Enrollment agent for stupid devices (ansible/salt)
|
||||||
|
|
||||||
|
|
||||||
|
SR1. CA Private key is never under control of single user or device (SPOF)
|
||||||
|
SR2. Low level verification if CA is issuing only end-user certificates
|
||||||
|
SR2.1 Policy constraints with certificate depth for CA
|
||||||
|
SR3. Auditing
|
||||||
|
SR3.1 Non repudative audit log (merkle trees)
|
||||||
|
SR4 Adding new KC
|
||||||
|
SR4.1 Revoking KC
|
||||||
|
SR5 Mass revoke/renew certificates
|
Loading…
Reference in New Issue