From 3aa8b1dd6e0f504ef83da99f8c9cdb2532f948f5 Mon Sep 17 00:00:00 2001
From: Rob Austein <sra@hactrn.net>
Date: Sun, 13 Sep 2020 23:10:21 +0000
Subject: Initial conversion pass

---
 raw-wiki-dump/ExternalProjectsTorHSM.md | 90 +++++++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)
 create mode 100644 raw-wiki-dump/ExternalProjectsTorHSM.md

(limited to 'raw-wiki-dump/ExternalProjectsTorHSM.md')

diff --git a/raw-wiki-dump/ExternalProjectsTorHSM.md b/raw-wiki-dump/ExternalProjectsTorHSM.md
new file mode 100644
index 0000000..9dd8b7c
--- /dev/null
+++ b/raw-wiki-dump/ExternalProjectsTorHSM.md
@@ -0,0 +1,90 @@
+# External project TorHSM
+
+## Problem
+
+The [Tor network](https://www.torproject.org/about/overview.html.en) 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](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt)
+* [CrypTech Alpha system](https://www.crowdsupply.com/cryptech/open-hardware-security-module)
+
+
-- 
cgit v1.2.3