[tor-dev] Moving key material out of the main tor process

[David Goulet]

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

-- 
2dLUG6IluthaObnf5+xfKeuu4WDC9xYQHzFNeGRqvzw=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20200529/a50e521f/attachment.sig>