From 891730d13b324fad916572a82f0bd610c5de9aad Mon Sep 17 00:00:00 2001 From: Rob Austein Date: Sun, 13 Sep 2020 23:06:24 +0000 Subject: Rename for conversion --- raw-wiki-dump/Requirements | 136 --------------------------------------------- 1 file changed, 136 deletions(-) delete mode 100644 raw-wiki-dump/Requirements (limited to 'raw-wiki-dump/Requirements') diff --git a/raw-wiki-dump/Requirements b/raw-wiki-dump/Requirements deleted file mode 100644 index 50c54b0..0000000 --- a/raw-wiki-dump/Requirements +++ /dev/null @@ -1,136 +0,0 @@ -= HSM Requirements - -Requirements for the Cryptech Alpha System. Derived from Use Cases (see below). There are also utility, internal requirements (again, see below). - -== Capacity -=== Per key storage requirements -In addition to the actual key data, each key requires -- Key type – 4 bytes -- Key identifier – 4 bytes -- Key flags, e.g. exportable – 8 bytes -This results a total 16 bytes overhead for each key. - -=== Examples per algorithm -(For RSA, we might also want to include the primes p and q might also be included which requires additional storage.) - -- RSA-8192 requires 1024 bytes secret key, 1024 bytes public key + 4 bytes exponent + 16 bytes overhead = 2068 bytes -- RSA-4096 requires 512 bytes secret key, 512 bytes public key + 4 bytes exponent + 16 bytes overhead = 1044 bytes -- RSA-2048 requires 256 bytes secret key, 256 bytes public key + 4 bytes exponent + 16 bytes overhead = 532 bytes -- EC P-256 requires 32 bytes secret key, 64 bytes public key + 16 bytes overhead = 112 bytes -- EC P-384 requires 48 bytes secret key, 96 bytes public key + 16 bytes overhead = 160 bytes -- Curve 25519 requires 32 bytes secret key, 32 bytes public key + 16 bytes overhead = 80 bytes - - -== Use Cases -=== DNSSEC -==== Number of keys -- TLD (or provider using key sharing) requires ~ 100 key pairs -- 3 KSK per zone (previous, current, new) -- 3 ZSK per zone (previous, current, new) -==== Possibly dual algorithms -- A typical TLD operator usually has less than 10 TLDs -- Other DNS providers may use key sharing to limit number of keys required -==== Algorithms -- RSA-1024/SHA-256 -- RSA-2048/SHA-256 -- EC-P256/SHA-256 -==== Performance -Each update to a zone requires 3-4 signatures (per algorithm) -- Resign SOA (signed by ZSK) -- Resign updated RR (signed by ZSK) -- Resign NSEC/NSEC3 (signed by ZSK), may require multiple signatures -Non-interactive latency (batch), dynamic updates may require faster signing - -=== SAML -==== Number of keys -SAML federation operator requires max 10 key pairs (including space for roll) -==== Algorithms -- RSA-2048/SHA-256 -==== Performance -- Non-interactive latency (batch) - - non-MDX: … -- Interactive latency - - MDX: … - -=== PKIX (including RPKI) -==== Number of keys -- Typical Certification Authority ~ 10 key pairs - - CA key, OCSP, CRL per level in the CA - - Root CA is one level - - For subordinate CAs, perhaps 2-5 CAs in a HSM is reasonable? -==== Algorithms -- RSA-2048/SHA-256 -- RSA-4096/SHA-256 -- RSA-4096/SHA-512 ? -- EC-P256/SHA-256 -==== Performance -- Non-interactive latency - - Root CA: Less than 1 signature per day - - Issuing CA: One signature per issued certificate - - CRL: Less than 1 signature per hour -- Interactive latency - - OCSP: Multiple signatures per second - -=== Tor -Requirements according to (section 1): https://gitweb.torproject.org/torspec.git/plain/dir-spec.txt -==== Number of keys -- 1 private key -- 10 public keys -==== Algorithms -- RSA-2048/SHA-1 ? -- RSA-2048/SHA-256 -- RSA-4096/SHA-256 ? -- RSA-4096/SHA-512 ? -==== Performance -- 2 signatures per hour -- 20 verification operations per hour -- 1 second max latency for RSA-2048 based verification - -=== Certificate Transparency (CT) -==== Number of keys -CT requires 1 key (ECDSA or RSA) per log -==== Algorithms -- RSA-2048/SHA-256 -- RSA-4096/SHA-256 ? -- RSA-4096/SHA-512 ? -- EC-P256/SHA-256 -==== Performance -- A Certificate Transparency log uses one ECDSA or one RSA key to sign two separate documents: -- STH's might need to be signed once per hour -- SCT's might need to be signed once per second (*) - -See RFC 6962, section 2.1.4 – https://tools.ietf.org/html/rfc6962 - - -== Internal Functional Requirements - -=== Algorithms and functions -- Key wrapping using AES-256 with SIV, http://tools.ietf.org/html/rfc5297 -- Internal Storage Master Key (ISMK) in battery backed RAM connected to FPGA - - Battery connection controlled by tamper mechanism - - Active erasure controlled by tamper mechanism -- 32-bit high quality random number generation - -=== PKCS11 - -The following PKCS11 mechanisms are required to fulfill the aforementioned use cases: - -- RSA - - CKM_RSA_PKCS_KEY_PAIR_GEN - - CKM_RSA_PKCS - - CKM_RSA_X_509 ? - - CKM_SHA256_RSA_PKCS - - CKM_SHA512_RSA_PKCS ? -- ECDSA - - CKM_EC_KEY_PAIR_GEN - - CKM_ECDSA -- AES - - … TBD … -- Random - - … TBD … -- Key Wrapping - - … TBD … -- Hash - - CKM_SHA256 - - CKM_SHA512 (?) - -- cgit v1.2.3