doc/spec/proposals/103-multilevel-keys.txt

   1 Filename: 103-multilevel-keys.txt
   2 Title: Splitting identity key from regularly used signing key.
   3 Version: $Revision$
   4 Last-Modified: $Date$
   5 Author: Nick Mathewson
   6 Created: Jan 2007
   7 Status: Closed
   8 Implemented-In: 0.2.0.x
   9
  10 Overview:
  11
  12   This document proposes a change in the way identity keys are used, so that
  13   highly sensitive keys can be password-protected and seldom loaded into RAM.
  14
  15   It presents options; it is not yet a complete proposal.
  16
  17 Proposal:
  18
  19   Replacing a directory authority's identity key in the event of a compromise
  20   would be tremendously annoying.  We'd need to tell every client to switch
  21   their configuration, or update to a new version with an uploaded list.  So
  22   long as some weren't upgraded, they'd be at risk from whoever had
  23   compromised the key.
  24
  25   With this in mind, it's a shame that our current protocol forces us to
  26   store identity keys unencrypted in RAM.  We need some kind of signing key
  27   stored unencrypted, since we need to generate new descriptors/directories
  28   and rotate link and onion keys regularly.  (And since, of course, we can't
  29   ask server operators to be on-hand to enter a passphrase every time we
  30   want to rotate keys or sign a descriptor.)
  31
  32   The obvious solution seems to be to have a signing-only key that lives
  33   indefinitely (months or longer) and signs descriptors and link keys, and a
  34   separate identity key that's used to sign the signing key.  Tor servers
  35   could run in one of several modes:
  36     1. Identity key stored encrypted.  You need to pick a passphrase when
  37        you enable this mode, and re-enter this passphrase every time you
  38        rotate the signing key.
  39     1'. Identity key stored separate.  You save your identity key to a
  40        floppy, and use the floppy when you need to rotate the signing key.
  41     2. All keys stored unencrypted.  In this case, we might not want to even
  42        *have* a separate signing key.  (We'll need to support no-separate-
  43        signing-key mode anyway to keep old servers working.)
  44     3. All keys stored encrypted. You need to enter a passphrase to start
  45        Tor.
  46   (Of course, we might not want to implement all of these.)
  47
  48   Case 1 is probably most usable and secure, if we assume that people don't
  49   forget their passphrases or lose their floppies.  We could mitigate this a
  50   bit by encouraging people to PGP-encrypt their passphrases to themselves,
  51   or keep a cleartext copy of their secret key secret-split into a few
  52   pieces, or something like that.
  53
  54   Migration presents another difficulty, especially with the authorities.  If
  55   we use the current set of identity keys as the new identity keys, we're in
  56   the position of having sensitive keys that have been stored on
  57   media-of-dubious-encryption up to now.  Also, we need to keep old clients
  58   (who will expect descriptors to be signed by the identity keys they know
  59   and love, and who will not understand signing keys) happy.
  60
  61 A possible solution:
  62
  63   One thing to consider is that router identity keys are not very sensitive:
  64   if an OR disappears and reappears with a new key, the network treats it as
  65   though an old router had disappeared and a new one had joined the network.
  66   The Tor network continues unharmed; this isn't a disaster.
  67
  68   Thus, the ideas above are mostly relevant for authorities.
  69
  70   The most straightforward solution for the authorities is probably to take
  71   advantage of the protocol transition that will come with proposal 101, and
  72   introduce a new set of signing _and_ identity keys used only to sign votes
  73   and consensus network-status documents.  Signing and identity keys could be
  74   delivered to users in a separate, rarely changing "keys" document, so that
  75   the consensus network-status documents wouldn't need to include N signing
  76   keys, N identity keys, and N certifications.
  77
  78   Note also that there is no reason that the identity/signing keys used by
  79   directory authorities would necessarily have to be the same as the identity
  80   keys those authorities use in their capacity as routers.  Decoupling these
  81   keys would give directory authorities the following set of keys:
  82
  83        Directory authority identity:
  84            Highly confidential; stored encrypted and/or offline.  Used to
  85            identity directory authorities.  Shipped with clients.  Used to
  86            sign Directory authority signing keys.
  87
  88        Directory authority signing key:
  89            Stored online, accessible to regular Tor process.  Used to sign
  90            votes and consensus directories.  Downloaded as part of a "keys"
  91            document.
  92
  93            [Administrators SHOULD rotate their signing keys every month or
  94            two, just to keep in practice and keep from forgetting the
  95            password to the authority identity.]
  96
  97        V1-V2 directory authority identity:
  98            Stored online, never changed.  Used to sign legacy network-status
  99            and directory documents.
 100
 101        Router identity:
 102            Stored online, seldom changed.  Used to sign server descriptors
 103            for this authority in its role as a router.  Implicitly certified
 104            by being listed in network-status documents.
 105
 106        Onion key, link key:
 107            As in tor-spec.txt
 108
 109
 110 Extensions to Proposal 101.
 111
 112   Define a new document type, "Key certificate".  It contains the
 113   following fields, in order:
 114
 115     "dir-key-certificate-version": As network-status-version.  Must be
 116          "3".
 117     "fingerprint": Hex fingerprint, with spaces, based on the directory
 118          authority's identity key.
 119     "dir-identity-key": The long-term identity key for this authority.
 120     "dir-key-published": The time when this directory's signing key was
 121          last changed.
 122     "dir-key-expires": A time after which this key is no longer valid.
 123     "dir-signing-key": As in proposal 101.
 124     "dir-key-certification": A signature of the above fields, in order.
 125          The signed material extends from the beginning of
 126          "dir-key-certicate-version" through the newline after
 127          "dir-key-certification".  The identity key is used to generate
 128          this signature.
 129
 130       These elements together constitute a "key certificate".  These are
 131       generated offline when starting a v3 authority.  Private identity
 132       keys SHOULD be stored offline, encrypted, or both.  A running
 133       authority only needs access to the signing key.
 134
 135       Unlike other keys currently used by Tor, the authority identity
 136       keys and directory signing keys MAY be longer than 1024 bits.
 137       (They SHOULD be 2048 bits or longer; they MUST NOT be shorter than
 138       1024.)
 139
 140   Vote documents change as follows:
 141
 142       A key certificate MUST be included in-line in every vote document.  With
 143       the exception of "fingerprint", its elements MUST NOT appear in consensus
 144       documents.
 145
 146   Consensus network statuses change as follows:
 147
 148       Remove dir-signing-key.
 149
 150       Change "directory-signature" to take a fingerprint of the authority's
 151       identity key and a fingerprint of the authority's current signing key
 152       rather than the authority's nickname.
 153
 154       Change "dir-source" to take the a fingerprint of the authority's
 155       identity key rather than the authority's nickname or hostname.
 156
 157   Add a new document type:
 158
 159       A "keys" document contains all currently known key certificates.
 160       All authorities serve it at
 161
 162           http://<hostname>/tor/status/keys.z
 163
 164       Caches and clients download the keys document whenever they receive a
 165       consensus vote that uses a key they do not recognize.  Caches download
 166       from authorities; clients download from caches.
 167
 168   Processing votes:
 169
 170       When receiving a vote, authorities check to see if the key
 171       certificate for the voter is different from the one they have.  If
 172       the key certificate _is_ different, and its dir-key-published is
 173       more recent than the most recently known one, and it is
 174       well-formed and correctly signed with the correct identity key,
 175       then authorities remember it as the new canonical key certificate
 176       for that voter.
 177
 178   A key certificate is invalid if any of the following hold:
 179       * The version is unrecognized.
 180       * The fingerprint does not match the identity key.
 181       * The identity key or the signing key is ill-formed.
 182       * The published date is very far in the past or future.
 183
 184       * The signature is not a valid signature of the key certificate
 185         generated with the identity key.
 186
 187   When processing the signatures on consensus, clients and caches act as
 188   follows:
 189
 190       1. Only consider the directory-signature entries whose identity
 191          key hashes match trusted authorities.
 192
 193       2. If any such entries have signing key hashes that match unknown
 194          signing keys, download a new keys document.
 195
 196       3. For every entry with a known (identity key,signing key) pair,
 197          check the signature on the document.
 198
 199       4. If the document has been signed by more than half of the
 200          authorities the client recognizes, treat the consensus as
 201          correctly signed.
 202
 203          If not, but the number entries with known identity keys but
 204          unknown signing keys might be enough to make the consensus
 205          correctly signed, do not use the consensus, but do not discard
 206          it until we have a new keys document.