aboutsummaryrefslogtreecommitdiff
path: root/pelican/content/Requirements.md
blob: 434e4db4e56014e941cfe9cb533c4d240b60dde4 (plain) (blame)
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
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172

   

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