summaryrefslogtreecommitdiff
path: root/markdown/Requirements.md
diff options
context:
space:
mode:
Diffstat (limited to 'markdown/Requirements.md')
-rw-r--r--markdown/Requirements.md172
1 files changed, 0 insertions, 172 deletions
diff --git a/markdown/Requirements.md b/markdown/Requirements.md
deleted file mode 100644
index 434e4db..0000000
--- a/markdown/Requirements.md
+++ /dev/null
@@ -1,172 +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 (?)
-
-