TorHSM

= TorHSM workshop, Stockholm 2019-07-14 11:15-13:30

TorHSM wiki page is at https://trac.torproject.org/projects/tor/wiki/TorHSM

== Background The HSM module would be used by directory authorities to secure the private signing keys used to sign votes and consensuses every hour. those keys are certified by the offline directory authority identity keys every 3 to 12 months.

The idea is to have the HSM as an external "computer" that, while slow (< 5 minutes latency for signatures), would be more secure as it wouldn't expose the private keys to a possible attacker. Traditionnally, HSMs are opaque machines that sell for hundreds of thousands of dollars and really are an outdated linux machine. Instead, we are considering a thing from a project called CrypTech that has been working on a open hardware design for amongst other things a HSM module since 2013. It's a initiated by people from the IETF and ISOC. There's currently an "alpha board" that connects over USB and costs about $800 on one of the crowdsourcing platforms.

The Alpha board made of:

stm32 ARM processor
FPGA board
AVR microcontroller to wipe a key memory when a tripwire is triggered
TRNG made, among other things, an overpowered transistor that generates noise, covered by a shield

This thing can do RSA but also ECC and other crypto primitives.

== Agenda for today In todays session we're going to have two dirauth operators try out three things: - 1. populate a TorHSM device with a dirauth long term identity key (public part) - 2. a) generate a new dirauth medium term signing key on the device, b) have it signed by the identity key (on their own computer) and c) tell the device to start using the new signing key by showing it the certificate from step b - 3. run a chutney network on their computer, with one of the dirauths patched and configured to use a TorHSM device instead of using a signing key on disk, with the goal of producing a valid consensus

=== Step 1 -- get identity key onto the device

There's a single slot for identity key.

Alternative for a new dirauth: Generate a key and return the public key.

=== Step 2 -- key roll

There are two slots for singing keys, one active and one inactive ("next key").

=== Step 3 -- tor using the key on the device

5 seconds for 2k keys. 3k keys seem to have experienced regresion recently.

Some refactoring required in tor to deal with the slowness, compared to local openssl signing.

== Suggestsions during the session:

The hsm could have another key to sign new signing keys so the directory operator could check that it is a valid key to be signed with its identity key, which turns the new key issuance more or less in a CSR (Certificate Signing Request) in X509. mMnufacturing doesn't need to be unique, because the CSR signing key can be generated in the setup phase.
Current design verifies if the new signed key is correctly signed, not sure if it's necessary because that's done by the tor daemon and clients anyways. it makes setup more complicated, and it also makes dirauth identity key rotation harder because it would require either re-setup (requiring physical access to the HSM) or using a presumably compromised identity key for fooling the HSM. Not having verification would make it easier to understand. verification in the HSM doesn't seem to bring us any security property that's not already provided by the current design, because an attacker could just discard the HSM anyways if they control the machine.
Generating keys on the HSM has been typially flawed in other HSMs, e.g. the Yubikey FIPS recent vulns, so we might want to allow loading keys generated elsewhere onto the HSM ("key import").
Some organizations might want to control random number generation explicitly without wanting to generate the key, but this adds complexity to the system and might mean an attacker could influence or nullify the RNG as well, so possibly risky.

Possible attack: Attacker can execute code on the machine where the dirauth runs and makes the HSM issue fake signatures and exports them to another, malicious, dirauth. Possible solution: Rate limit? We think tor shortens the voting interval if things start to seem critical wrt getting a new consensus out, ie when there's 12h or so left before the most fresh consensus goes stale. Rate limiting on the 1h voting interval would make the situation worse. Securely Counter? Unclear how a counter could be embedded in the signature without changing the entire consensus protocol.

== Action points

Figure out how legacy dirauth keys are meant to be used and if they're stil considered a good idea.
Verify new signing keys or just activate new key when operator says so.
Does tor still need variable consensus periods? If so, rate-limiting might not work.

Comments