diff options
| author | Rob Austein <sra@hactrn.net> | 2020-09-13 23:04:30 +0000 |
|---|---|---|
| committer | Rob Austein <sra@hactrn.net> | 2020-09-13 23:04:30 +0000 |
| commit | b092ffbcbe2c9398494f7dc9db6f0796971633e0 (patch) | |
| tree | 6fabf690f1ebf485a9fea9af5298e44ad2a59a3e /raw-wiki-dump/Requirements | |
| parent | 9d927e49d9c10fc16c6dfa4a2a96cdb6216e4e2b (diff) | |
Import Cryptech wiki dump
Diffstat (limited to 'raw-wiki-dump/Requirements')
| -rw-r--r-- | raw-wiki-dump/Requirements | 136 |
1 files changed, 136 insertions, 0 deletions
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 (?)
+
|