hs_pki/design/hs_pki_architecture

172 lines
5.4 KiB
Plaintext

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:
- CA: Certificate Authority.
Issues end-user/device certificates (N>2)
CA is online, connected to infrastructure.
- Root CA: Issue CA ceritifcates and KC certificates (at least N>2).
Root CA is offline, airgapped device.
- AIA: Authority Information Access - CA certificates repo (ldap/https)
- CRL: Certificate Revocation List. List of certificates that CA issued
but must be revoked (i.e. compromised) before end of it's
lifetime.
- CDP: CRL distribution point.
- Key Custodian: PKI peptide control interface (N>2).
- 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:KC1_sigPK #Used for issuing commands to CA/RootCA
<- KC1_ICC:KC1_CAzmkPK #Used to protect backups of CA private keys
<- KC1_sigPK.csr #Export to RootCA to get KC certificate
<- KC1_zmkPK.csr #Export for CA to encrypt it's private keys
<- KC2_ICC:KC2_sigPK #Same as above for KC2
<- KC2_ICC:KC2_CAzmkPK
<- KC2_sigPK.csr
<- KC2_zmkPK.csr
...
<- KCN_ICC:KCN_sigPK #Same as above for KCN
<- KCN_ICC:KCN_CAzmkPK
<- KCN_sigPK.csr
<- KCN_CAzmkPK.csr
B Root_CA_N1
-> Key manager initiates self-generation of asymmetric crypto keys on 1st CA ICC and
sets two (or more) initial KC's:
># ca root init -kc KC1*.csr -kc KC2*.csr [-kc KCN*.csr]
<- Root_CA_N1_ICC:RootCA_sigPK:pub #Will be used in CA cert but also for integrity
<- Root_CA_N1_ICC:RootCA_sigPK:priv #Used for issuing CA and KC certificates
<- Root_CA_N1_ICC:RootCA_KC_zmkPK:pub #Will be used by KC to send recovery share to CA
<- Root_CA_N1_ICC:RootCA_KC_zmkPK:priv #Will be used by CA to decrypt share from KC
<- (Root_CA_N1_ICC:RootCA_sigPK:priv(.aes_key) #Option: generate AES key for protection
# of CA signing key
<- (Root_CA_N1_ICC:RootCA_sigPK:priv.encr.aes) #Option: Encrypt signing key with AES
<- Root_CA_N1_ICC:RootCA_sigPK:priv(.aes_key)_SSSS_1..N # Split signing key (or it's
# encryption key) into shares
# for each KC
<- Root_CA_N1_sigPriv_SSSS_1_KC1_zmk.enc #Encrypt CA private key share1 with KC1
#encryption key
<x Root_CA_N1_ICC:RootCA_sigPK:priv(.aes_key)_SSSS_1 #Remove share1
<- Root_CA_N1_sigPriv_SSSS_2_KC2_zmk.enc #Share2 for KC2
<x Root_CA_N1_ICC:RootCA_sigPK:priv(.aes_key)_SSSS_2 #Remove share2
...
<- Root_CA_N1_sigPriv_SSSS_N_KCN_zmk.enc #ShareN for KCN
<x Root_CA_N1_ICC:RootCA_sigPK:priv(.aes_key)_SSSS_N #Remove shareN
<- Root_CA_N1_sigPriv_SSSS_1_KC1_zmk.enc.RootCA_sigPK.sig #Integrity check enc -> sig
<- Root_CA_N1_sigPriv_SSSS_2_KC2_zmk.enc.RootCA_sigPK.sig #Integrity check enc -> sig
...
<- Root_CA_N1_sigPriv_SSSS_N_KCN_zmk.enc.RootCA_sigPK.sig #Integrity check enc -> sig
<- Root_CA_N1_sigPriv_SSSS_1_RootCA_sigPK.sig_KC1_zmk.enc #Integrity check sig -> enc
<- Root_CA_N1_sigPriv_SSSS_2_RootCA_sigPK.sig_KC1_zmk.enc #Integrity check sig -> enc
...
<- Root_CA_N1_sigPriv_SSSS_N_RootCA_sigPK.sig_KC1_zmk.enc #Integrity check sig -> enc
<- Root_CA_N1_ICC:RootCA_KC1_encPK # CA encryption public key for KC to send
# their encrypted shares
<- Root_CA_N1_KC1.kc.crt # KC1 certificate issued with Root_CA
# This will be used to issue commands to RootCA
<- Root_CA_N1_KC2.kc.crt # Same as above for KC2 ...
...
<- Root_CA_N1_KCN.crt.kc # ... and KCN
<- Root_CA_N1.crt # Issue self-signed certificate
<- Root_CA_N1.csr # Issue CSR for root cross-signing
<x Root_CA_N1_ICC:RootCA_sigPK:priv # Destroy signing private key
===================================
Root_CA_N1_ICC:
RootCA_sigPK:pub # Retain it or not?
RootCA_KC_zmkPK:priv # Decrypt CA signing private key shares from KC
C CA_N2
-> Key manager initiates key generation on 2nd CA ICC
># ca root init -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?