diff options
author | Rob Austein <sra@hactrn.net> | 2021-02-14 01:35:10 +0000 |
---|---|---|
committer | Rob Austein <sra@hactrn.net> | 2021-02-14 01:35:10 +0000 |
commit | 23bb68fe7e9cc8af176ff60b56e8a51a70f05a89 (patch) | |
tree | 27c87a0c157e6eb343518031c4c3afd1e95bc488 /raw-wiki-dump/ExternalProjectsTorHSM.md | |
parent | fa8b4d0e872d182ee878020fb1b066ce0da621ae (diff) |
Now generating pages directly from sqlite3
Diffstat (limited to 'raw-wiki-dump/ExternalProjectsTorHSM.md')
-rw-r--r-- | raw-wiki-dump/ExternalProjectsTorHSM.md | 90 |
1 files changed, 0 insertions, 90 deletions
diff --git a/raw-wiki-dump/ExternalProjectsTorHSM.md b/raw-wiki-dump/ExternalProjectsTorHSM.md deleted file mode 100644 index 9dd8b7c..0000000 --- a/raw-wiki-dump/ExternalProjectsTorHSM.md +++ /dev/null @@ -1,90 +0,0 @@ -# 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) - - |