d3llf
/
hs_pki
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Init commit: stub README; RFI for hs_pki_uc needed

master
d3llf 2017-02-05 12:53:47 +01:00
commit f5c69eaf0b
6 changed files with 213 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
README.md Normal file
View File

@ -0,0 +1 @@
Warsaw Hackerspace PKI

108
design/hs_pki_architecture Normal file
View File

@ -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?

40
design/hs_pki_ldap Normal file
View File

@ -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
...

12
design/hs_pki_policy Normal file
View File

@ -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

19
design/hs_pki_templates Normal file
View File

@ -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

33
design/hs_pki_uc Normal file
View File

@ -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