Title: HSM Requirements
Date: 2016-12-15 22:39
Requirements for the Cryptech Alpha System. Derived from Use Cases (see below). There are also utility, internal requirements (again, see below).
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.
(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
- TLD (or provider using key sharing) requires ~ 100 key pairs
- 3 KSK per zone (previous, current, new)
- 3 ZSK per zone (previous, current, new)
- A typical TLD operator usually has less than 10 TLDs
- Other DNS providers may use key sharing to limit number of keys required
- RSA-1024/SHA-256
- RSA-2048/SHA-256
- EC-P256/SHA-256
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 federation operator requires max 10 key pairs (including space for roll)
- Non-interactive latency (batch)
- Interactive latency
- 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?
- RSA-2048/SHA-256
- RSA-4096/SHA-256
- RSA-4096/SHA-512 ?
- EC-P256/SHA-256
- 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
Requirements according to (section 1): https://gitweb.torproject.org/torspec.git/plain/dir-spec.txt
- 1 private key
- 10 public keys
- RSA-2048/SHA-1 ?
- RSA-2048/SHA-256
- RSA-4096/SHA-256 ?
- RSA-4096/SHA-512 ?
- 2 signatures per hour
- 20 verification operations per hour
- 1 second max latency for RSA-2048 based verification
CT requires 1 key (ECDSA or RSA) per log
- RSA-2048/SHA-256
- RSA-4096/SHA-256 ?
- RSA-4096/SHA-512 ?
- EC-P256/SHA-256
- 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
- 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
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
- Random
- Key Wrapping
- Hash
- CKM_SHA256
- CKM_SHA512 (?)
