``` 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:///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. ```