Hi,
tl;dr How to move key material out of tor?
## The idea of a vault component
ahf and others in the network team have been discussing the possibility of a "vault" component in tor, for moving private keys out of the tor process. Separating secret key material from the code handling data from the network seems valuable and providing a component making different implementations "pluggable" would allow for anyone to use their favourite technology without touching the tor code base. Examples are local trusted execution environments like Intel SGX and Arm TrustZone and various HSM's and security keys/tokens.
One way of implementing this would be to define a protocol, for a vault component to talk to a daemon running on the same host as tor, over some IPC mechanism. This protocol would allow tor to request a signature over a hash, or a document, in a certain key. Whether the daemon has access to the key material or has to forward the request to a separate device or hardware component is irrelevant to the protocol and the vault component.
Even if the design focuses on signatures it should probably take encryption and decryption into account, to be added later.
## The vault as a possible match for TorHSM
Such a vault component would fit well with a project where Peter Stuge and myself are building an HSM for Tor directory authority signing keys [0] based on the CrypTech design [1].
[0] https://trac.cryptech.is/wiki/ExternalProjectsTorHSM [1] https://cryptech.is/
One of the options for tor to delegate the signing of votes and consensuses to such a device would be to use a vault component as described above. We would then have a signing daemon responsible for the USB communication with the TorHSM device. Another option would be to build support directly into tor for communicating with the device, through a library capable of a USB vendor specific protocol defined by TorHSM.
There are pros and cons with both options. I'd like to hear what the Tor developers community think would be best.
## Asynchronous signing API
Vault or not, tor needs to change the way signing is done to be able to move key material out of the main process. First, external devices may need more time to perform a signature operation than what tor can accept to spend blocking in its main thread. Second, an external device might disappear or malfunction, requiring the possibility for an operation to time out.
This can be implemented either with callbacks or with a state machine with more well defined state transitions. Maybe there are more options that I didn't think of.
## Protocol choice
If we decide to go for the vault component with a separate daemon we should consider using the ssh-agent protocol for tor to talk to the daemon. Apart from being already defined there are multiple well tested implementations of this protocol. It also has a couple of features we might want, such as forgetting a certain key and locking/unlocking of the vault. Finally, it's extensible and should accommodate potential additions we might want to make later.
On 20 May (17:45:51), Linus Nordberg wrote:
Hi,
Greeting Linus!
tl;dr How to move key material out of tor?
## The idea of a vault component
ahf and others in the network team have been discussing the possibility of a "vault" component in tor, for moving private keys out of the tor process. Separating secret key material from the code handling data from the network seems valuable and providing a component making different implementations "pluggable" would allow for anyone to use their favourite technology without touching the tor code base. Examples are local trusted execution environments like Intel SGX and Arm TrustZone and various HSM's and security keys/tokens.
One way of implementing this would be to define a protocol, for a vault component to talk to a daemon running on the same host as tor, over some IPC mechanism. This protocol would allow tor to request a signature over a hash, or a document, in a certain key. Whether the daemon has access to the key material or has to forward the request to a separate device or hardware component is irrelevant to the protocol and the vault component.
Even if the design focuses on signatures it should probably take encryption and decryption into account, to be added later.
Love it.
## The vault as a possible match for TorHSM
Such a vault component would fit well with a project where Peter Stuge and myself are building an HSM for Tor directory authority signing keys [0] based on the CrypTech design [1].
[0] https://trac.cryptech.is/wiki/ExternalProjectsTorHSM [1] https://cryptech.is/
One of the options for tor to delegate the signing of votes and consensuses to such a device would be to use a vault component as described above. We would then have a signing daemon responsible for the USB communication with the TorHSM device. Another option would be to build support directly into tor for communicating with the device, through a library capable of a USB vendor specific protocol defined by TorHSM.
There are pros and cons with both options. I'd like to hear what the Tor developers community think would be best.
## Asynchronous signing API
Vault or not, tor needs to change the way signing is done to be able to move key material out of the main process. First, external devices may need more time to perform a signature operation than what tor can accept to spend blocking in its main thread. Second, an external device might disappear or malfunction, requiring the possibility for an operation to time out.
This can be implemented either with callbacks or with a state machine with more well defined state transitions. Maybe there are more options that I didn't think of.
Right, I don't think this is any show stopper here. Signing with the long term key material is not something that don't happens "often" and so adding delays to it is probably negligible in the grand scheme of things.
## Protocol choice
If we decide to go for the vault component with a separate daemon we should consider using the ssh-agent protocol for tor to talk to the daemon. Apart from being already defined there are multiple well tested implementations of this protocol. It also has a couple of features we might want, such as forgetting a certain key and locking/unlocking of the vault. Finally, it's extensible and should accommodate potential additions we might want to make later.
That is a _great_ idea in my opinion. It is robust, maintained by serious people/project and did through the test of time!
I'm very excited about this "proposal" especially for relays and dirauth.
However, I do wonder about onion services here because one difference here is that for v3 onion service offline key to work, the operator needs to derive a series of keys (blinded keys) from the master key which implies secret key material access so maybe something we could discuss with HSM token designer that is this concept of "key derivation" from the secret material. And who knows, maybe they have?
Cheers! David
David Goulet dgoulet@torproject.org wrote Fri, 29 May 2020 09:41:51 -0400:
## The idea of a vault component
ahf and others in the network team have been discussing the possibility of a "vault" component in tor, for moving private keys out of the tor process. Separating secret key material from the code handling data from the network seems valuable and providing a component making different implementations "pluggable" would allow for anyone to use their favourite technology without touching the tor code base. Examples are local trusted execution environments like Intel SGX and Arm TrustZone and various HSM's and security keys/tokens.
One way of implementing this would be to define a protocol, for a vault component to talk to a daemon running on the same host as tor, over some IPC mechanism. This protocol would allow tor to request a signature over a hash, or a document, in a certain key. Whether the daemon has access to the key material or has to forward the request to a separate device or hardware component is irrelevant to the protocol and the vault component.
Even if the design focuses on signatures it should probably take encryption and decryption into account, to be added later.
Love it.
Glad to hear that there's support for the vault idea. Let's see if TorHSM should use such a vault or not.
## The vault as a possible match for TorHSM
Such a vault component would fit well with a project where Peter Stuge and myself are building an HSM for Tor directory authority signing keys [0] based on the CrypTech design [1].
[0] https://trac.cryptech.is/wiki/ExternalProjectsTorHSM%3E [1] https://cryptech.is/%3E One of the options for tor to delegate the signing of votes and consensuses to such a device would be to use a vault component as described above. We would then have a signing daemon responsible for the USB communication with the TorHSM device. Another option would be to build support directly into tor for communicating with the device, through a library capable of a USB vendor specific protocol defined by TorHSM.
There are pros and cons with both options. I'd like to hear what the Tor developers community think would be best.
Do you have an opinion on the choice between a separate daemon and a lib/torhsm?
The daemon way is the more generic and PT-like pluggable idea that also involves quite some more work. I would probably need some help with that.
The library option would be specific to this particular HSM and probably not very reusable. I'd sort this out myself, given that an "asynchronous signing API" (as discussed below) is in place.
## Asynchronous signing API
Vault or not, tor needs to change the way signing is done to be able to move key material out of the main process. First, external devices may need more time to perform a signature operation than what tor can accept to spend blocking in its main thread. Second, an external device might disappear or malfunction, requiring the possibility for an operation to time out.
This can be implemented either with callbacks or with a state machine with more well defined state transitions. Maybe there are more options that I didn't think of.
Right, I don't think this is any show stopper here. Signing with the long term key material is not something that don't happens "often" and so adding delays to it is probably negligible in the grand scheme of things.
As long as the time consumed waiting for signing operations to finish is counted in seconds and not minutes this should indeed be negligible for consensus periods of one hour, as in the public Tor network.
Two things to consider are test networks, which have substantially lower consensus periods, and the rumour about a feature called variable consensus periods.
I think that test networks could be dealt with by warning, or even refusing to start, when a dirauth configured with a period shorter than N minutes is also configured for having keys in an HSM.
The variable consensus period thing is something I heard about for the first time at the Stockholm meeting last year. I'm still not certain that it exists. Does anybody have a pointer?
## Protocol choice
If we decide to go for the vault component with a separate daemon we should consider using the ssh-agent protocol for tor to talk to the daemon. Apart from being already defined there are multiple well tested implementations of this protocol. It also has a couple of features we might want, such as forgetting a certain key and locking/unlocking of the vault. Finally, it's extensible and should accommodate potential additions we might want to make later.
That is a _great_ idea in my opinion. It is robust, maintained by serious people/project and did through the test of time!
I'm very excited about this "proposal" especially for relays and dirauth.
Happy to hear that! What do you think would be a good next step? A decision about state machine vs. callbacks might be a good start. How would this be made? I'm happy to take a stab at implementing either, preferable with someone in the network team at my side.
However, I do wonder about onion services here because one difference here is that for v3 onion service offline key to work, the operator needs to derive a series of keys (blinded keys) from the master key which implies secret key material access so maybe something we could discuss with HSM token designer that is this concept of "key derivation" from the secret material. And who knows, maybe they have?
Looking at the most famous API for talking to HSM's, PKCS#11, there's indeed the concept of "key derivation", for example through the C_DeriveKey[0] function. What the chances are that any HSM is doing exactly what's laid out in rend-spec-v3.txt A.2 [1] I don't know yet.
[0] http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/errata01/os/pkcs11-base-... [1] https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n2267
On Wed, May 20, 2020 at 11:46 AM Linus Nordberg linus@torproject.org wrote:
Hi,
tl;dr How to move key material out of tor?
## The idea of a vault component
ahf and others in the network team have been discussing the possibility of a "vault" component in tor, for moving private keys out of the tor process. Separating secret key material from the code handling data from the network seems valuable and providing a component making different implementations "pluggable" would allow for anyone to use their favourite technology without touching the tor code base. Examples are local trusted execution environments like Intel SGX and Arm TrustZone and various HSM's and security keys/tokens.
One way of implementing this would be to define a protocol, for a vault component to talk to a daemon running on the same host as tor, over some IPC mechanism. This protocol would allow tor to request a signature over a hash, or a document, in a certain key. Whether the daemon has access to the key material or has to forward the request to a separate device or hardware component is irrelevant to the protocol and the vault component.
Even if the design focuses on signatures it should probably take encryption and decryption into account, to be added later.
Hi!
I'm also +1 on this idea, and I think you're correct to hint that the "vault" or "separate daemon" part doesn't have to be a tor-specific tool. Moving responsibilities out of the core Tor process should help us make it harder for keys to leak.
One issue with the ssh-agent protocol as I see it is that it isn't originally designed for decryption or for high-volume usage. If we want to support those in the future, we'll need to make sure that we have an extension path for them in whatever vault tool we're using.
yrs,
Nick Mathewson nickm@freehaven.net wrote Tue, 2 Jun 2020 11:51:07 -0400:
One issue with the ssh-agent protocol as I see it is that it isn't originally designed for decryption or for high-volume usage. If we want to support those in the future, we'll need to make sure that we have an extension path for them in whatever vault tool we're using.
Good point. The extension mechanism defined for the protocol (see [draft-miller-ssh-agent-04] section 4.7) could be used for finding out if and how other types of operations are supported by the "vault" or "crypto daemon". This sounds like an invitation to complicate things though, like defining an extension function returning a new endpoint for a separate, more powerful, protocol. But maybe we should be able to constrain ourselves.
An alternative to using the ssh-agent protocol extension would be to have the internal key data type in tor include a protocol and an endpoint and let the user set things up through torrc (default "call_openssl://path/to/privkey"). This would allow for expressing that your signing keys have moved from "ssh-agent://path/to/ssh-agent.socket" to "new-and-shiny://path/to/powerful-crypto-daemon.socket".
And even if I don't like it much, there's always the option of defining something new, encompassing all our needs from start. To be weighed against the upside of being able to use already well established software for our specific needs of signing. One could argue that the minimal implementation of such a protocol, only for signing, could forward requests to a running instance of ssh-agent but the number of moving parts just went up. Simple is better here IMO.
[draft-miller-ssh-agent-04] https://www.ietf.org/id/draft-miller-ssh-agent-04.txt
-
David Goulet -
Linus Nordberg -
Nick Mathewson