Proposal 230: How to change RSA1024 relay identity keys
Here's a design for what to do to support a massive RSA1024 relay key migration, if we need to do another one in the future. (I'm not sure whether this is timely for responding to CVE-2014-0160 or not; possibly not.) Filename: 230-rsa1024-relay-id-migration.txt Title: How to change RSA1024 relay identity keys Authors: Nick Mathewson Created: 7 April 2014 Target: 0.2.? Status: Draft 1. Intro and motivation Some times, a relay would like to migrate from one RSA1024 identity key to another without losing its previous status. This is especially important because proposal 220 ("Migrate server identity keys to Ed25519") is not yet implemented, and so server identity keys are not kept offline. So when an OpenSSL bug like CVE-2014-0160 makes memory-reading attacks a threat to identity keys, we need a way for routers to migrate ASAP. This proposal does not cover migrating RSA1024 OR identity keys for authorities. 2. Design I propose that when a relay changes its identity key, it should include a "old-identity" field in its server descriptor for 60 days after the migration. This old-identity would include the old RSA1024 identity, a signature of the new identity key with the old one, and the date when the migration occurred. This field would appear as an "old-id" field in microdescriptors, containing a SHA1 fingerprint of the old identity key, if the signature turned out to be value. Authorities would store old-identity => new-identity mappings, and: * Treat history information (wfu, mtbf, [and what else?]) from old identities as applying to new identities instead. * No longer accept any routers descriptors signed by the old identity. Clients would migrate any guard entries for the old identity to the new identity. (This will break clients connections for clients who try to connect to the old identity key before learning about the new one, but the window there won't be large for any single router.) 3. Descriptor format details Router descriptors may contain these new elements: "old-rsa1024-id-key" NL RSA_KEY NL Contains an old RSA1024 identity key. If this appears, old-rsa1024-id-migration must also appear. [At most once] "old-rsa1024-id-migration" SP ISO-TIME NL SIGNATURE NL Contains a signature of: The bytes "RSA1024 ID MIGRATION" [20 bytes] The ISO-TIME field above as an 8 byte field [8 bytes] A SHA256 hash of the new identity [32 bytes] If this appears, "old-rsa1024-id-key" must also appear. [At most once]. 4. Interface To use this feature, a router should rename its secret_id_key file to secret_id_key_OLD. The first time that Tor starts and finds a secret_id_key_OLD file, it generates a new ID key if one is not present, and generates the text of the old-rsa-1024-id-key and old-rsa1024-id-migration fields above. It stores them in a new "old_id_key_migration" file, and deletes the secret_id_key_OLD file. It includes them in its desecriptors. Sixty days after the stored timestamp, the router deletes the "old_id_key_migration" file and stops including its contents in the descriptor.
On Tue, Apr 8, 2014 at 1:50 PM, Nick Mathewson <nickm@torproject.org> wrote:
Filename: 230-rsa1024-relay-id-migration.txt Title: How to change RSA1024 relay identity keys Authors: Nick Mathewson Created: 7 April 2014 Target: 0.2.? Status: Draft
1. Intro and motivation
Some times, a relay would like to migrate from one RSA1024 identity key to another without losing its previous status.
This is especially important because proposal 220 ("Migrate server identity keys to Ed25519") is not yet implemented, and so server identity keys are not kept offline. So when an OpenSSL bug like CVE-2014-0160 makes memory-reading attacks a threat to identity keys, we need a way for routers to migrate ASAP.
This proposal does not cover migrating RSA1024 OR identity keys for authorities.
2. Design
I propose that when a relay changes its identity key, it should include a "old-identity" field in its server descriptor for 60 days after the migration. This old-identity would include the old RSA1024 identity, a signature of the new identity key with the old one, and the date when the migration occurred.
This field would appear as an "old-id" field in microdescriptors, containing a SHA1 fingerprint of the old identity key, if the signature turned out to be value. s/value/valid
Authorities would store old-identity => new-identity mappings, and:
* Treat history information (wfu, mtbf, [and what else?]) from old identities as applying to new identities instead.
possibly: bw authority weights?
* No longer accept any routers descriptors signed by the old identity.
To clarify here: does "router[s] descriptors signed by the old identity" include the old-id field? That is, in case an identity key is compromised is there a race to claim the old-id mapping? If not, how should the authorities/clients treat a pair of descriptors claiming the mapping?
4. Interface
To use this feature, a router should rename its secret_id_key file to secret_id_key_OLD. The first time that Tor starts and finds a secret_id_key_OLD file, it generates a new ID key if one is not present, and generates the text of the old-rsa-1024-id-key and old-rsa1024-id-migration fields above. It stores them in a new "old_id_key_migration" file, and deletes the secret_id_key_OLD file. It includes them in its desecriptors.
I guess it's possible a relay operator could shoot themselves in the foot here by causing some inconsistent state between these three files. I guess at worst, though, this should again be a case where the window of vulnerability is small, so very few (or possibly no) relays would lose their history this way. -- ------------------------------------------------------------------------ Nicholas Hopper Associate Professor, Computer Science & Engineering, University of Minnesota Visiting Research Director, The Tor Project ------------------------------------------------------------------------
On Tue, Apr 8, 2014 at 2:15 PM, Nicholas Hopper <hopper@cs.umn.edu> wrote:
To clarify here: does "router[s] descriptors signed by the old identity" include the old-id field? That is, in case an identity key is compromised is there a race to claim the old-id mapping? If not, how should the authorities/clients treat a pair of descriptors claiming the mapping?
Further thinking about this, I think the right answer should be: if ANY authority posts two different identities claiming the same old-id, all history associated with the old id is dropped (i.e. will not be associated with ANY other identity). This seems to be the safest compromise between performance and security: - if the old id was not compromised, or the adversary chooses not to claim it, then retaining the identity's history improves performance, and so the network is better off than before this proposal (when the history would have been lost). - if two claims are made for the old id, then that confirms that the identity was compromised; we have no safe way to judge which new identity is the "true heir," and so dropping the history leaves the network in the same state as it would have been without this proposal. Sorry if this was obvious and I was just too slow to realize it. -- ------------------------------------------------------------------------ Nicholas Hopper Associate Professor, Computer Science & Engineering, University of Minnesota Visiting Research Director, The Tor Project ------------------------------------------------------------------------
On Tue, Apr 08, 2014 at 02:15:12PM -0500, Nicholas Hopper wrote:
4. Interface
To use this feature, a router should rename its secret_id_key file to secret_id_key_OLD. The first time that Tor starts and finds a secret_id_key_OLD file, it generates a new ID key if one is not present, and generates the text of the old-rsa-1024-id-key and old-rsa1024-id-migration fields above. It stores them in a new "old_id_key_migration" file, and deletes the secret_id_key_OLD file. It includes them in its desecriptors.
I guess it's possible a relay operator could shoot themselves in the foot here by causing some inconsistent state between these three files. I guess at worst, though, this should again be a case where the window of vulnerability is small, so very few (or possibly no) relays would lose their history this way.
I'm a little wary of having the tor binary perform an irrevocable operation like deleting the old key file. Maybe have it rename it? Or only delete the file once the migration has appeared (and the signatures verified) in a consensus or five? - Ian
participants (3)
-
Ian Goldberg -
Nicholas Hopper -
Nick Mathewson