External Project Tor HSM

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