summaryrefslogblamecommitdiff
path: root/wiki/Requirements.trac
blob: 50c54b082d45b9f951c7462e2e643efe9052bed3 (plain) (tree)







































































































































                                                                                                                                                  
= 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 (?)