diff options
| author | Rob Austein <sra@hactrn.net> | 2021-02-14 01:55:38 +0000 |
|---|---|---|
| committer | Rob Austein <sra@hactrn.net> | 2021-02-14 01:55:38 +0000 |
| commit | b58c60bcc4a6f3d3ccf4194ef862a808fdc3313b (patch) | |
| tree | ad43c2b937db286c2b3320b57066a9581264444a /tracwiki/ExternalProjectsTorHSM.trac | |
| parent | 23bb68fe7e9cc8af176ff60b56e8a51a70f05a89 (diff) | |
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.
Diffstat (limited to 'tracwiki/ExternalProjectsTorHSM.trac')
| -rw-r--r-- | tracwiki/ExternalProjectsTorHSM.trac | 76 |
1 files changed, 76 insertions, 0 deletions
diff --git a/tracwiki/ExternalProjectsTorHSM.trac b/tracwiki/ExternalProjectsTorHSM.trac new file mode 100644 index 0000000..13d88a6 --- /dev/null +++ b/tracwiki/ExternalProjectsTorHSM.trac @@ -0,0 +1,76 @@ += External project TorHSM
+
+== Problem
+
+The [https://www.torproject.org/about/overview.html.en 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
+
+* [https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt Tor directory protocol, version 3]
+* [https://www.crowdsupply.com/cryptech/open-hardware-security-module CrypTech Alpha system]
+
|