From b092ffbcbe2c9398494f7dc9db6f0796971633e0 Mon Sep 17 00:00:00 2001 From: Rob Austein Date: Sun, 13 Sep 2020 23:04:30 +0000 Subject: Import Cryptech wiki dump --- raw-wiki-dump/Requirements | 136 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 136 insertions(+) create mode 100644 raw-wiki-dump/Requirements (limited to 'raw-wiki-dump/Requirements') diff --git a/raw-wiki-dump/Requirements b/raw-wiki-dump/Requirements new file mode 100644 index 0000000..50c54b0 --- /dev/null +++ b/raw-wiki-dump/Requirements @@ -0,0 +1,136 @@ += 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