Re: [tor-dev] Safe Alternative Uses of Onion Service Keys

[Alexander Færøy <ahf@xxxxxxxxxxxxxx>]

On 2020/07/29 05:15, Matthew Finkel wrote:
>
> [ ... snip ... ]
> 
> A signature must include "v0" and the values used in "YYYY-MM-DD" and
> INT_8(validity_period), such that the client can derive the correct
> blinded public key for verification when starting from the long-term
> identity key. The signature should be over a certification of an
> independently generated ed25519 key pair. This new key pair (along with
> the certification) can be used for providing message integrity within
> the application's protocol. If, instead, the derived key is used
> directly for signing, and the application needs the keys online for
> signing messages, then this risks the security of the long-term key, as
> well. The blinding scheme allows for (partially) recovering the
> long-term secret key from the derived secret key.

This is super useful, Matt! Thanks for writing all of this down.

> Another example use case comes from Jeremy Rand where the onion service
> key is used in a root CA certificate, and a leaf certificate (signed by
> the CA cert) is used by the application.

This idea stemmed from a conversation between David, George, and me a
little while after the Stockholm meeting last summer. The implementation
of the tool for generating the various x509 files (the x509 CA and the
signed x509 certificates) is available from

    https://gitlab.torproject.org/ahf/onion-x509

For people who are unaware of what this tool is doing, I can flesh it
out here:

Tor uses an ed25519 secret key format that is incompatible with the
ed25519 secret key encoding found in x509, and we cannot just convert
the .onion identity ed25519 key to a PEM file and make, for example, a
web server use it directly. This also seems to be what Matt is
recommending against. As seen in Matt's [0], the signatures and public
keys are all using the same encoding, however.

In ordinary TLS, where the server sends the certificate chain, we don't
keep ANY of our CA's secret keys online (since we hopefully don't have
access to them under normal circumstances). Thus, we only need the
secret and public key of our leaf certificate to be available for our
TLS service to do signatures as part of the TLS protocol. We can
therefore generate an "Onion CA" from Tor's .onion identity secret key,
but never have to move any secret key with it into our TLS service
deployments.

Once we have generated this "Onion CA", which is identified by the onion
identity public key, we use the onion-x509 tool to issue leaf
certificates that are signed by the "Onion CA." By configuring our TLS
service to use the Onion CA and our ed25519 leaf key pair, and its x509
certificate (signed by the Onion CA), the client will be able to verify
if the certificate is "valid" just based on the Onion address itself.

I think the stateless nature of this system is pretty cool.  I don't
believe that moving to blinded keys blocks anything for it to work,
which means I think Jeremy and I should probably coordinate to do that
instead of the direct use of the onion identity key pair as the tool
does today.

Of course, the modifications to the browser are the terrifying part of
all of this as such changes touch some scary code paths in how TLS
certificates are validated. Still, if this can work, it would make x509
certificates very easily accessible for Onion service operators.

If Jeremy gets the demo to work in Tor Browser and it all looks
promising, we should also spend a bit of time rewriting the Go tool to C
and bundle it with the Tor codebase.

> Following from the previous example, (most likely) the CA certificate
> should not be signed directly using the onion service's long-term secret
> key. However, a derived key could be used in the CA certificate and the
> leaf cert could contain an ephemeral key (in exactly the same way that
> tor certifies ephemeral keys using the derived blinded signing key).
> This idea appears to be a concrete design of how the above (abstract)
> key certification could be implemented, and it could be a format that
> tor natively supports.

From what I can tell, it should be possible for us to update the
onion-x509 tool to use the blinded key instead.

Exciting stuff!

All the best,
Alex.

-- 
Alexander Færøy
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev