Hack images, store outputs in git again for now

Easier to track what each script change does if we keep the before and
after versions of the markdown in git too.  Clean this up eventually,
but simplifies development.

1 files changed, 136 insertions, 0 deletions

diff --git a/tracwiki/Requirements.trac b/tracwiki/Requirements.trac
new file mode 100644
index 0000000..50c54b0
--- /dev/null
+++ b/tracwiki/Requirements.trac
@@ -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 (?)

+