pelican/content/ExternalProjectsTorHSM.md


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


Title: ExternalProjectsTorHSM
Author: ln5
Date: 2018-09-17 10:26
Modified: 2018-10-01 14:38
External project TorHSM
Problem
The Tor network is defined by a small number, about ten, of special relays called Directory Authorities (DAs).
Directory Authorities sign the critical status votes and consensus status documents using SHA-1 and SHA-256 together with RSA-2048 or RSA-3072 once per hour, using medium-term on-line authority signing keys signed by their individual off-line long-term authority identity keys. Authority signing keys typically have a lifetime of three to twelve months.
Authority signing keys are currently kept on the same general purpose computer that runs the Directory Authority and are thus subject to a large number of network threats.
Proposed solution
Move authority signing keys away from the general purpose computer onto an external device which can sign the consensus document without exposing key material to the networked computer system.
The CrypTech project has created an open source (BSD licensed) Alpha hardware which would be especially suitable, because the open software and hardware offers unprecedented transparency while also enabling a simple, efficient and legacy-free solution.
Current typical key roll-over procedure

Generate new authority signing key on offline system
Sign new key using authority identity key on offline system
Save new authority signing key and key certificate on USB stick
Transfer new authority signing key and key certificate to DA system via network

The key roll-over procedure becomes

Use administrative tool from this project on DA system to generate new authority signing key on HSM
The new authority signing key initially remains inactive and unavailable for use
The public part of new authority signing key is exported from HSM onto the DA system


Transfer new public part of authority signing key to USB stick
Sign new public key using authority identity key on offline system
Save key certificate on USB stick
Transfer key certificate to DA system via network and make available to DA
(Optional?) Use administrative tool from this project on DA to present key certificate to HSM
Activate key (automatic on verified key certificate, manual without key certificate verification)

Milestones
The minimum viable product (MVP) at MS3 is a system where the authority signing key is no longer accessible by the DA system while not making any part of the process worse from a security perspective.
The system at MS6 (to MS8) does not make any part of the process worse from a //usability// perspective (subjective) and also adds rate limiting.
MS1 -- PoC using OpenSSL PKCS#11 engine

tor using openssl p11 engine; no key management or rate-limiting
useful for test and verification

MS2 -- Using CrypTech RPC instead of OpenSSL

function declarations in sw/libhal/hal.h, definitions in sw/libhal/rpc_*.c
TODO: daemon

MS3 (MVP) -- HSM configuration I

"HSM configuration" is aka "key management"
administrator connected to MGMT can make HSM
generate a MK based on passphrase
print public part of MK


administrator connected to USER can make HSM
generate a new authority signing key pair, wrap the secret part in MK, store both parts in flash memory and export the public part


MS4 -- HSM configuration II

rate limiting
enforcing key validity

MS5 -- Enforcing key validity HSM side
MS6 -- Rate limiting of signatures
MS7 -- New Shiny Crypto Hardware API using CrypTech RPC
MS8 -- Getting entropy from HSM
MS9 -- Support for more protocols in New Shiny Crypto Hardware API
References

Tor directory protocol, version 3
CrypTech Alpha system