aboutsummaryrefslogblamecommitdiff
path: root/pelican/content/Requirements.md
blob: 8f4a592c3ddeb6676f361b5cc2cbc7cc68809df5 (plain) (tree)
1
2
3
                   
                      
 











































































































































































                                                                                                                                                 

   

Title: Requirements Date: 2016-12-15 22:39

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