mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-09-21 13:34:59 +02:00
d230827912
Tor doesn't use SVN anymore, making $Revision$, $Id$ and $Date$ meaningless. Remove them without replacement.
205 lines
9.0 KiB
Plaintext
205 lines
9.0 KiB
Plaintext
Filename: 103-multilevel-keys.txt
|
|
Title: Splitting identity key from regularly used signing key.
|
|
Author: Nick Mathewson
|
|
Created: Jan 2007
|
|
Status: Closed
|
|
Implemented-In: 0.2.0.x
|
|
|
|
Overview:
|
|
|
|
This document proposes a change in the way identity keys are used, so that
|
|
highly sensitive keys can be password-protected and seldom loaded into RAM.
|
|
|
|
It presents options; it is not yet a complete proposal.
|
|
|
|
Proposal:
|
|
|
|
Replacing a directory authority's identity key in the event of a compromise
|
|
would be tremendously annoying. We'd need to tell every client to switch
|
|
their configuration, or update to a new version with an uploaded list. So
|
|
long as some weren't upgraded, they'd be at risk from whoever had
|
|
compromised the key.
|
|
|
|
With this in mind, it's a shame that our current protocol forces us to
|
|
store identity keys unencrypted in RAM. We need some kind of signing key
|
|
stored unencrypted, since we need to generate new descriptors/directories
|
|
and rotate link and onion keys regularly. (And since, of course, we can't
|
|
ask server operators to be on-hand to enter a passphrase every time we
|
|
want to rotate keys or sign a descriptor.)
|
|
|
|
The obvious solution seems to be to have a signing-only key that lives
|
|
indefinitely (months or longer) and signs descriptors and link keys, and a
|
|
separate identity key that's used to sign the signing key. Tor servers
|
|
could run in one of several modes:
|
|
1. Identity key stored encrypted. You need to pick a passphrase when
|
|
you enable this mode, and re-enter this passphrase every time you
|
|
rotate the signing key.
|
|
1'. Identity key stored separate. You save your identity key to a
|
|
floppy, and use the floppy when you need to rotate the signing key.
|
|
2. All keys stored unencrypted. In this case, we might not want to even
|
|
*have* a separate signing key. (We'll need to support no-separate-
|
|
signing-key mode anyway to keep old servers working.)
|
|
3. All keys stored encrypted. You need to enter a passphrase to start
|
|
Tor.
|
|
(Of course, we might not want to implement all of these.)
|
|
|
|
Case 1 is probably most usable and secure, if we assume that people don't
|
|
forget their passphrases or lose their floppies. We could mitigate this a
|
|
bit by encouraging people to PGP-encrypt their passphrases to themselves,
|
|
or keep a cleartext copy of their secret key secret-split into a few
|
|
pieces, or something like that.
|
|
|
|
Migration presents another difficulty, especially with the authorities. If
|
|
we use the current set of identity keys as the new identity keys, we're in
|
|
the position of having sensitive keys that have been stored on
|
|
media-of-dubious-encryption up to now. Also, we need to keep old clients
|
|
(who will expect descriptors to be signed by the identity keys they know
|
|
and love, and who will not understand signing keys) happy.
|
|
|
|
A possible solution:
|
|
|
|
One thing to consider is that router identity keys are not very sensitive:
|
|
if an OR disappears and reappears with a new key, the network treats it as
|
|
though an old router had disappeared and a new one had joined the network.
|
|
The Tor network continues unharmed; this isn't a disaster.
|
|
|
|
Thus, the ideas above are mostly relevant for authorities.
|
|
|
|
The most straightforward solution for the authorities is probably to take
|
|
advantage of the protocol transition that will come with proposal 101, and
|
|
introduce a new set of signing _and_ identity keys used only to sign votes
|
|
and consensus network-status documents. Signing and identity keys could be
|
|
delivered to users in a separate, rarely changing "keys" document, so that
|
|
the consensus network-status documents wouldn't need to include N signing
|
|
keys, N identity keys, and N certifications.
|
|
|
|
Note also that there is no reason that the identity/signing keys used by
|
|
directory authorities would necessarily have to be the same as the identity
|
|
keys those authorities use in their capacity as routers. Decoupling these
|
|
keys would give directory authorities the following set of keys:
|
|
|
|
Directory authority identity:
|
|
Highly confidential; stored encrypted and/or offline. Used to
|
|
identity directory authorities. Shipped with clients. Used to
|
|
sign Directory authority signing keys.
|
|
|
|
Directory authority signing key:
|
|
Stored online, accessible to regular Tor process. Used to sign
|
|
votes and consensus directories. Downloaded as part of a "keys"
|
|
document.
|
|
|
|
[Administrators SHOULD rotate their signing keys every month or
|
|
two, just to keep in practice and keep from forgetting the
|
|
password to the authority identity.]
|
|
|
|
V1-V2 directory authority identity:
|
|
Stored online, never changed. Used to sign legacy network-status
|
|
and directory documents.
|
|
|
|
Router identity:
|
|
Stored online, seldom changed. Used to sign server descriptors
|
|
for this authority in its role as a router. Implicitly certified
|
|
by being listed in network-status documents.
|
|
|
|
Onion key, link key:
|
|
As in tor-spec.txt
|
|
|
|
|
|
Extensions to Proposal 101.
|
|
|
|
Define a new document type, "Key certificate". It contains the
|
|
following fields, in order:
|
|
|
|
"dir-key-certificate-version": As network-status-version. Must be
|
|
"3".
|
|
"fingerprint": Hex fingerprint, with spaces, based on the directory
|
|
authority's identity key.
|
|
"dir-identity-key": The long-term identity key for this authority.
|
|
"dir-key-published": The time when this directory's signing key was
|
|
last changed.
|
|
"dir-key-expires": A time after which this key is no longer valid.
|
|
"dir-signing-key": As in proposal 101.
|
|
"dir-key-certification": A signature of the above fields, in order.
|
|
The signed material extends from the beginning of
|
|
"dir-key-certicate-version" through the newline after
|
|
"dir-key-certification". The identity key is used to generate
|
|
this signature.
|
|
|
|
These elements together constitute a "key certificate". These are
|
|
generated offline when starting a v3 authority. Private identity
|
|
keys SHOULD be stored offline, encrypted, or both. A running
|
|
authority only needs access to the signing key.
|
|
|
|
Unlike other keys currently used by Tor, the authority identity
|
|
keys and directory signing keys MAY be longer than 1024 bits.
|
|
(They SHOULD be 2048 bits or longer; they MUST NOT be shorter than
|
|
1024.)
|
|
|
|
Vote documents change as follows:
|
|
|
|
A key certificate MUST be included in-line in every vote document. With
|
|
the exception of "fingerprint", its elements MUST NOT appear in consensus
|
|
documents.
|
|
|
|
Consensus network statuses change as follows:
|
|
|
|
Remove dir-signing-key.
|
|
|
|
Change "directory-signature" to take a fingerprint of the authority's
|
|
identity key and a fingerprint of the authority's current signing key
|
|
rather than the authority's nickname.
|
|
|
|
Change "dir-source" to take the a fingerprint of the authority's
|
|
identity key rather than the authority's nickname or hostname.
|
|
|
|
Add a new document type:
|
|
|
|
A "keys" document contains all currently known key certificates.
|
|
All authorities serve it at
|
|
|
|
http://<hostname>/tor/status/keys.z
|
|
|
|
Caches and clients download the keys document whenever they receive a
|
|
consensus vote that uses a key they do not recognize. Caches download
|
|
from authorities; clients download from caches.
|
|
|
|
Processing votes:
|
|
|
|
When receiving a vote, authorities check to see if the key
|
|
certificate for the voter is different from the one they have. If
|
|
the key certificate _is_ different, and its dir-key-published is
|
|
more recent than the most recently known one, and it is
|
|
well-formed and correctly signed with the correct identity key,
|
|
then authorities remember it as the new canonical key certificate
|
|
for that voter.
|
|
|
|
A key certificate is invalid if any of the following hold:
|
|
* The version is unrecognized.
|
|
* The fingerprint does not match the identity key.
|
|
* The identity key or the signing key is ill-formed.
|
|
* The published date is very far in the past or future.
|
|
|
|
* The signature is not a valid signature of the key certificate
|
|
generated with the identity key.
|
|
|
|
When processing the signatures on consensus, clients and caches act as
|
|
follows:
|
|
|
|
1. Only consider the directory-signature entries whose identity
|
|
key hashes match trusted authorities.
|
|
|
|
2. If any such entries have signing key hashes that match unknown
|
|
signing keys, download a new keys document.
|
|
|
|
3. For every entry with a known (identity key,signing key) pair,
|
|
check the signature on the document.
|
|
|
|
4. If the document has been signed by more than half of the
|
|
authorities the client recognizes, treat the consensus as
|
|
correctly signed.
|
|
|
|
If not, but the number entries with known identity keys but
|
|
unknown signing keys might be enough to make the consensus
|
|
correctly signed, do not use the consensus, but do not discard
|
|
it until we have a new keys document.
|