1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
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 (?)
|
