From f5c69eaf0b7359d0ce9be655d9fdce9212b57352 Mon Sep 17 00:00:00 2001 From: d3llf Date: Sun, 5 Feb 2017 12:53:47 +0100 Subject: [PATCH] Init commit: stub README; RFI for hs_pki_uc needed --- README.md | 1 + design/hs_pki_architecture | 108 +++++++++++++++++++++++++++++++++++++ design/hs_pki_ldap | 40 ++++++++++++++ design/hs_pki_policy | 12 +++++ design/hs_pki_templates | 19 +++++++ design/hs_pki_uc | 33 ++++++++++++ 6 files changed, 213 insertions(+) create mode 100644 README.md create mode 100644 design/hs_pki_architecture create mode 100644 design/hs_pki_ldap create mode 100644 design/hs_pki_policy create mode 100644 design/hs_pki_templates create mode 100644 design/hs_pki_uc diff --git a/README.md b/README.md new file mode 100644 index 0000000..f8fa2aa --- /dev/null +++ b/README.md @@ -0,0 +1 @@ +Warsaw Hackerspace PKI diff --git a/design/hs_pki_architecture b/design/hs_pki_architecture new file mode 100644 index 0000000..6931e94 --- /dev/null +++ b/design/hs_pki_architecture @@ -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=,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? diff --git a/design/hs_pki_ldap b/design/hs_pki_ldap new file mode 100644 index 0000000..16e8a3f --- /dev/null +++ b/design/hs_pki_ldap @@ -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 +... diff --git a/design/hs_pki_policy b/design/hs_pki_policy new file mode 100644 index 0000000..b90e145 --- /dev/null +++ b/design/hs_pki_policy @@ -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 diff --git a/design/hs_pki_templates b/design/hs_pki_templates new file mode 100644 index 0000000..3196fc6 --- /dev/null +++ b/design/hs_pki_templates @@ -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 diff --git a/design/hs_pki_uc b/design/hs_pki_uc new file mode 100644 index 0000000..7a40901 --- /dev/null +++ b/design/hs_pki_uc @@ -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