From 891730d13b324fad916572a82f0bd610c5de9aad Mon Sep 17 00:00:00 2001 From: Rob Austein Date: Sun, 13 Sep 2020 23:06:24 +0000 Subject: Rename for conversion --- raw-wiki-dump/ExternalProjectsTorHSM.trac | 76 +++++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 raw-wiki-dump/ExternalProjectsTorHSM.trac (limited to 'raw-wiki-dump/ExternalProjectsTorHSM.trac') diff --git a/raw-wiki-dump/ExternalProjectsTorHSM.trac b/raw-wiki-dump/ExternalProjectsTorHSM.trac new file mode 100644 index 0000000..13d88a6 --- /dev/null +++ b/raw-wiki-dump/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] + -- cgit v1.2.3