Key rotation (and explicit self-revocation)
110 views
Skip to first unread message
Hannes Mehnert
May 10, 2017, 9:44:15 AM5/10/17
to TUF
Hi,
Justin and myself have been thinking how it would be useful to have a
role be able to switch out the key used (i.e., rotate the key), without
requiring everyone that delegates to that key to re-do their delegation.
So we would like to propose that something similar to root role
rotation be supported for all keys. Here is a rough sketch about how to
support rotation for any role / key in the system.
I suspect this needs some clarifications and extended here and there,
but it's a first draft only.
* TAP 8 - key rotation
# abstract
TAP 8 generalises the mechanism of chaining public key generations, and
provides a secure way for key rotation. Rotation is the process by
which a*role uses their old key to invalidate their old key and transfer
trust in the old key to a new key. Performing a key rotation does not
require parties that delegated trust to the old key to change their
delegation to the new key. Conceptually, the rotation process says if
you trusted key X (or threshold of keys X_0, ... X_n), now instead trust
key Y (or threshold of keys Y_0, ... Y_n). Rotation of a key may be
performed any number of times, transferring trust from Y to Z, etc.
The mechanism in this TAP has an additional use case: if a rotation
cycle (A to B, B to A) is detected, all delegations into the cycle are
invalid. This also allows a developer to explicitly revoke their own
key (by introducing a cycle).
# motivation
TUF supports key rotation using multiple ways that are ad hoc and differ
based upon the mechanism. This leads to some concerns:
## Self-maintaining ``project'' role
It is common to have a single "project key" delegated from the targets
role so that the members of the project can change without the
delegations to the project being replaced. The ``project key''
represents a single point of failure / compromise. (Some projects may
prefer a quorum of developers instead, but this would require
delegations to be redone whenever this quorum changed.) Adding and
removing delegations of a project often uses the "project key" which is
delegated to. This project key gives persons with access to it elevated
privileges, and needs intervention from a higher level of delegations if
it needs to be rotated or revoked.
With TAP 8, the delegation can be initially to a (hash of a) set of keys
and a threshold value. Developers could then collectively sign rotation
metadata to change the set of keys and update the set of developers.
## Improve / clarify root key rotation
The different root metadata versions build a chain of trust, where if
the initial root is trusted (TOFU or by being distributed over a trusted
channel), following the chain of key rotations leads to verified keys
for the current root metadata. This means that even if the keys are not
changed, a client must download every version of the root metadata in
order to follow the chain of delegations. This could be an efficiency
concern in some situations.
## Auto-rotation timestamp role
Roles which typically have short lived keys, like the timestamp role,
may wish to revoke trust in the prior key and sign a new key with the
old. This limits the ability for attackers to walk back the set of
trusted keys. Right now, there is not a good way to do this within TUF,
which may result in some keys being trusted more than they should be.
Using TAP 8, the online key can rotate itself without a signature by the
offline key.
Note, this TAP is not meant to address all situations where keys will
change. If there is a scenario where new keys are generated and
delegated to by a master key this model remains the same as in TUF
today. For example a HSM may generate and sign new timestamp keys every
hour. Since the HSM's key does not change, this is not a rotation and
thus is not intended to be handled by this TAP.
# Specification
To support key rotation, the new metadata file type `rotate` is
introduced, which contains the new public key(s), the threshold, and is
signed by a threshold of old public keys. The intuition is while
delegations keep intact, the targets can rotate keys, shrink or grow.
Let's consider the project foo, initially delegated to a multi-role
threshold (of 2) to Alice, Bob, and Charlie. Let's assume the targets
file to be foo.hash(ABC2). When they want to add Dan to the project,
foo.hash(ABC2) is removed, and foo.rotate.hash(ABC2) is created which
contains keys ABCD, and a new threshold (again 2). The file
foo.rotate.hash(ABC2) is signed by at least 2 of ABC. The new metadata
file, foo.hash(ABCD2) needs to be signed by a new threshold of ABCD to
complete the rotation.
A client which encounters a delegation to ABC2 notices that this
metadata is no longer available, but has been rotated, and verifies the
signatures on foo.rotate.hash(ABC2). The new targets file,
foo.hash(ABCD2) is verified using the keys ABCD from the rotate file.
When Evelyn joins, and the threshold is increased to 3, foo.hash(ABCD2)
is replaced with the rotate file foo.rotate.hash(ABCD2) containing ABCDE
keys and the new threshold of 3, signed by two of ABCD. Delegations can
point to either foo.hash(ABC2), foo.hash(ABCD2), or foo.hash(ABCDE3),
they have all the same meaning.
If at a later point, foo decides to remove Evelyn again from the
project, and decrease the threshold to 2, this would introduce a cycle
(foo.rotate.hash(ABCD2) to foo.rotate.hash(ABCDE3), which links back to
foo.rotate.hash(ABCD2)). To avoid a cycle, anyone of ABCD needs to
rotate their own key (and re-sign all targets).
Root, timestamp and snapshot key rotation. These keys can rotate as
well, leading to root|timestamp|snapshot.rotate.HHH files, where HHH is
the hash of the public key. Each file is signed by key HHH, and
contains the new key. A client can fetch the actual data, timestamp,
and verify it, or else fetch the timestamp.rotate.HH file where HH is
the secure hash of the last trusted timestamp key, either in the root
file or locally cached. If the timestamp key is renewed by the root,
all timestamp.rotate files can be safely removed from the repository.
Initial root key provisioning. The root keys are no longer part of the
root file, but initially provided via some means (e.g. manually, via an
URL, or within the repository as initial_root_keys). When root keys are
rotated, a root.rotate.HHH (where HHH is the hash over the old root
keys) is generated, containing the new root keys, and signed with (a
threshold of) the old root keys. A client downloads the root file, and
the chain of rotations, starting from its trusted root keys.
Clients need to check for rotation cycles, and any delegation pointing
into a cycle is invalid. This enables a user to explicitly revoke their
own key by introducing a self-loop. For usability reasons, a repository
may want to check if an uploaded rotate file would lead to a loop and
warn the user.
The rotate files should be listed in the snapshot metadata and should be
downloaded as soon as they are available.
Rotation files are immutable and should not be replaced or modified
under any circumstances. If a client wants to rotate to a different key
(perhaps due to losing the new key), this requires a key revocation.
TODO: Obviously example file formats, etc. need to be added.
# security
There should be no security impact. The usability impact will be to
provide a simple mechanism extending and shrinking projects by
themselves without an individual with elevated privileges, but based on
a threshold of signatures.
Clients need to take care to check for 'a rotation loop' where key
rotations point to other keys in a cycle. This should be handled in the
same manner as an invalid metadata signature on by the role possessing
the key.
Intentionally creating cycles in rotations enables a repository, a
project, and individuals to explicitly revoke their key material
themselves. A repository where the root rotate files end up in a cycle
is marked as invalid, without a way to recover. An individual whose key
is compromised can introduce a rotation cycle, all delegation to them
will be invalid.
NOTE: Since TAP 5, root is not part of snapshot anymore. does this matter?
# backwards compatibility
TAP 8 is not backwards compatible since the root keys are no longer part
of the root file. Furthermore, clients have to download and verify the
rotation chain.
Justin and myself have been thinking how it would be useful to have a
role be able to switch out the key used (i.e., rotate the key), without
requiring everyone that delegates to that key to re-do their delegation.
So we would like to propose that something similar to root role
rotation be supported for all keys. Here is a rough sketch about how to
support rotation for any role / key in the system.
I suspect this needs some clarifications and extended here and there,
but it's a first draft only.
* TAP 8 - key rotation
# abstract
TAP 8 generalises the mechanism of chaining public key generations, and
provides a secure way for key rotation. Rotation is the process by
which a*role uses their old key to invalidate their old key and transfer
trust in the old key to a new key. Performing a key rotation does not
require parties that delegated trust to the old key to change their
delegation to the new key. Conceptually, the rotation process says if
you trusted key X (or threshold of keys X_0, ... X_n), now instead trust
key Y (or threshold of keys Y_0, ... Y_n). Rotation of a key may be
performed any number of times, transferring trust from Y to Z, etc.
The mechanism in this TAP has an additional use case: if a rotation
cycle (A to B, B to A) is detected, all delegations into the cycle are
invalid. This also allows a developer to explicitly revoke their own
key (by introducing a cycle).
# motivation
TUF supports key rotation using multiple ways that are ad hoc and differ
based upon the mechanism. This leads to some concerns:
## Self-maintaining ``project'' role
It is common to have a single "project key" delegated from the targets
role so that the members of the project can change without the
delegations to the project being replaced. The ``project key''
represents a single point of failure / compromise. (Some projects may
prefer a quorum of developers instead, but this would require
delegations to be redone whenever this quorum changed.) Adding and
removing delegations of a project often uses the "project key" which is
delegated to. This project key gives persons with access to it elevated
privileges, and needs intervention from a higher level of delegations if
it needs to be rotated or revoked.
With TAP 8, the delegation can be initially to a (hash of a) set of keys
and a threshold value. Developers could then collectively sign rotation
metadata to change the set of keys and update the set of developers.
## Improve / clarify root key rotation
The different root metadata versions build a chain of trust, where if
the initial root is trusted (TOFU or by being distributed over a trusted
channel), following the chain of key rotations leads to verified keys
for the current root metadata. This means that even if the keys are not
changed, a client must download every version of the root metadata in
order to follow the chain of delegations. This could be an efficiency
concern in some situations.
## Auto-rotation timestamp role
Roles which typically have short lived keys, like the timestamp role,
may wish to revoke trust in the prior key and sign a new key with the
old. This limits the ability for attackers to walk back the set of
trusted keys. Right now, there is not a good way to do this within TUF,
which may result in some keys being trusted more than they should be.
Using TAP 8, the online key can rotate itself without a signature by the
offline key.
Note, this TAP is not meant to address all situations where keys will
change. If there is a scenario where new keys are generated and
delegated to by a master key this model remains the same as in TUF
today. For example a HSM may generate and sign new timestamp keys every
hour. Since the HSM's key does not change, this is not a rotation and
thus is not intended to be handled by this TAP.
# Specification
To support key rotation, the new metadata file type `rotate` is
introduced, which contains the new public key(s), the threshold, and is
signed by a threshold of old public keys. The intuition is while
delegations keep intact, the targets can rotate keys, shrink or grow.
Let's consider the project foo, initially delegated to a multi-role
threshold (of 2) to Alice, Bob, and Charlie. Let's assume the targets
file to be foo.hash(ABC2). When they want to add Dan to the project,
foo.hash(ABC2) is removed, and foo.rotate.hash(ABC2) is created which
contains keys ABCD, and a new threshold (again 2). The file
foo.rotate.hash(ABC2) is signed by at least 2 of ABC. The new metadata
file, foo.hash(ABCD2) needs to be signed by a new threshold of ABCD to
complete the rotation.
A client which encounters a delegation to ABC2 notices that this
metadata is no longer available, but has been rotated, and verifies the
signatures on foo.rotate.hash(ABC2). The new targets file,
foo.hash(ABCD2) is verified using the keys ABCD from the rotate file.
When Evelyn joins, and the threshold is increased to 3, foo.hash(ABCD2)
is replaced with the rotate file foo.rotate.hash(ABCD2) containing ABCDE
keys and the new threshold of 3, signed by two of ABCD. Delegations can
point to either foo.hash(ABC2), foo.hash(ABCD2), or foo.hash(ABCDE3),
they have all the same meaning.
If at a later point, foo decides to remove Evelyn again from the
project, and decrease the threshold to 2, this would introduce a cycle
(foo.rotate.hash(ABCD2) to foo.rotate.hash(ABCDE3), which links back to
foo.rotate.hash(ABCD2)). To avoid a cycle, anyone of ABCD needs to
rotate their own key (and re-sign all targets).
Root, timestamp and snapshot key rotation. These keys can rotate as
well, leading to root|timestamp|snapshot.rotate.HHH files, where HHH is
the hash of the public key. Each file is signed by key HHH, and
contains the new key. A client can fetch the actual data, timestamp,
and verify it, or else fetch the timestamp.rotate.HH file where HH is
the secure hash of the last trusted timestamp key, either in the root
file or locally cached. If the timestamp key is renewed by the root,
all timestamp.rotate files can be safely removed from the repository.
Initial root key provisioning. The root keys are no longer part of the
root file, but initially provided via some means (e.g. manually, via an
URL, or within the repository as initial_root_keys). When root keys are
rotated, a root.rotate.HHH (where HHH is the hash over the old root
keys) is generated, containing the new root keys, and signed with (a
threshold of) the old root keys. A client downloads the root file, and
the chain of rotations, starting from its trusted root keys.
Clients need to check for rotation cycles, and any delegation pointing
into a cycle is invalid. This enables a user to explicitly revoke their
own key by introducing a self-loop. For usability reasons, a repository
may want to check if an uploaded rotate file would lead to a loop and
warn the user.
The rotate files should be listed in the snapshot metadata and should be
downloaded as soon as they are available.
Rotation files are immutable and should not be replaced or modified
under any circumstances. If a client wants to rotate to a different key
(perhaps due to losing the new key), this requires a key revocation.
TODO: Obviously example file formats, etc. need to be added.
# security
There should be no security impact. The usability impact will be to
provide a simple mechanism extending and shrinking projects by
themselves without an individual with elevated privileges, but based on
a threshold of signatures.
Clients need to take care to check for 'a rotation loop' where key
rotations point to other keys in a cycle. This should be handled in the
same manner as an invalid metadata signature on by the role possessing
the key.
Intentionally creating cycles in rotations enables a repository, a
project, and individuals to explicitly revoke their key material
themselves. A repository where the root rotate files end up in a cycle
is marked as invalid, without a way to recover. An individual whose key
is compromised can introduce a rotation cycle, all delegation to them
will be invalid.
NOTE: Since TAP 5, root is not part of snapshot anymore. does this matter?
# backwards compatibility
TAP 8 is not backwards compatible since the root keys are no longer part
of the root file. Furthermore, clients have to download and verify the
rotation chain.
GanduBaccha
Dec 2, 2017, 2:31:35 PM12/2/17
to The Update Framework (TUF)
as @ecordell mentioned:
How could we address particular attacker model of breaking cycles protection..Is there particular attacker model for which breaking on cycles
provided protection? Any thoughts or alternatives on this?
Feedback/alternatives about is root.rotate.HHH really necessary and handling root rotation mechanism in efficient way with rotation primitives.
->We could add root rotation to support all files but it can be completely unnecessary elsewhere. Will that be efficiency concern? I think the linked usage is much better here.
Any alternatives on efficiently handling rotate.ID long file name.Will this be issue? Also i think number of rotate files will keep on increasing (correct me here if i am wrong) will this be issue in efficiency?
Also size of snapshot file or rotate file could increase with large scaling. Any thoughts/feedback?
Tony Arcieri
Dec 2, 2017, 2:46:47 PM12/2/17
to Hannes Mehnert, TUF
On Wed, May 10, 2017 at 6:41 AM, Hannes Mehnert <han...@mehnert.org> wrote:
Justin and myself have been thinking how it would be useful to have a
role be able to switch out the key used (i.e., rotate the key), without
requiring everyone that delegates to that key to re-do their delegation.
Isn't the real answer here to have an actual identity system?
In regard to the traditional dimensions of access control systems like principals, credentials, and policies, where TUF seems to be most lacking is a notion of principals.
Principals provide an indirection mechanism between credentials and policies, allowing the credentials to be easily changed without the need to redo delegation/policies every time.
Tony Arcieri
Justin Cappos
Dec 3, 2017, 2:32:31 PM12/3/17
to Tony Arcieri, Hannes Mehnert, TUF
How would this work without the authority for principals from becoming overly trusted? In my mind, this is inevitable with this design (as I understand it).
I'm currently skeptical that integrating an identity system would improve security, but very open to having my mind changed. :)
Thanks,
Justin
--
You received this message because you are subscribed to the Google Groups "The Update Framework (TUF)" group.
Visit this group at https://groups.google.com/group/theupdateframework.
To view this discussion on the web visit https://groups.google.com/d/msgid/theupdateframework/CAHOTMVL-sSBG1Z7Ru4zx5XpfyCyOyM2cFzBVL0V7TvZnWEzwyA%40mail.gmail.com.
Tony Arcieri
Dec 5, 2017, 2:18:48 PM12/5/17
to Justin Cappos, Hannes Mehnert, TUF
On Sat, Dec 2, 2017 at 12:40 PM, Justin Cappos <jca...@nyu.edu> wrote:
How would this work without the authority for principals from becoming overly trusted? In my mind, this is inevitable with this design (as I understand it).
If the identity system were self-contained, it'd just be an indirection mechanism between principals, their credentials, and the packages they're releasing. What would be *particularly* nice about this approach is it would work nicely with a key transparency system ala https://github.com/google/keytransparency
It would introduce a new role into the system (the IdP), which could publish a key directory, which would otherwise carry the same sort of signatures as any other file published by any other role in the system.
At least in the case of package management systems, they all have publisher identities of this nature, and having an IdP would be a more natural fit for these systems, I think.
I'm currently skeptical that integrating an identity system would improve security, but very open to having my mind changed. :)
So there's a scarier approach I think you have in mind, and that's outsourcing key management to an identity provider.
As it were, this is being discussed for Rust's crates.io package repository. Specifically they would like to outsource authority for package signing keys to GitHub. They already use GitHub as their IdP, so this makes sense:
I'm not sure how TUF in its present form could function in tandem with a system like that though. If there were an IdP role, it could be optional, and either managed through TUF itself, or outsourced to a separate system.
Tony Arcieri
Justin Cappos
Dec 5, 2017, 4:01:45 PM12/5/17
to Tony Arcieri, Hannes Mehnert, TUF
So would you need both a identity signature and a key signature on metadata? How would this work in practice?
If the IdP is trusted to say justincappos -> E9C0 59EC 0D32 64FA B35F 94AD 465B F9F6 F8EB 475A, then what stops it from a malicious IdP from substituting a different key's fingerprint?
Tony Arcieri
Dec 5, 2017, 4:21:35 PM12/5/17
to Justin Cappos, Hannes Mehnert, TUF
On Tue, Dec 5, 2017 at 1:01 PM, Justin Cappos <jca...@nyu.edu> wrote:
So would you need both a identity signature and a key signature on metadata? How would this work in practice?
I think adding something like this would be a pretty significant change from how TUF works today. A rough sketch:
- Add a new role type, e.g. "identity"/"credentials", with a key signed by the root key. This role maintains a mapping between principal identifiers ("justincappos" in this case) and enrolled cryptographic keys (I would suggest N keys per principal for multi-device/key rotation support).
- Claimed targets switch to referencing principal identifiers rather than explicitly enumerating valid keys. This decouples AuthN (which principal signed a given target) from AuthZ (is this principal allowed to sign this target?)
If the IdP is trusted to say justincappos -> E9C0 59EC 0D32 64FA B35F 94AD 465B F9F6 F8EB 475A, then what stops it from a malicious IdP from substituting a different key's fingerprint?
Nothing! If a package system outsources identity to a third party IdP, then they trust that IdP absolutely as the authority for signature keys. This is par for the course with IdPs though.
So why outsource something so security critical? Because e.g. GitHub has a full-time security team and developers working on providing a robust identity solution with multifactor authentication. If it weren't GitHub in this case, Mozilla would be running a similar identity service, which because Mozilla can't e.g. dedicate full-time security staff to crates.io would almost certainly be less robust than GitHub's offering.
Tony Arcieri
Justin Cappos
Dec 7, 2017, 4:46:13 PM12/7/17
to Tony Arcieri, Hannes Mehnert, TUF
Sure, I understand the desire to do this and the philosophy behind it. I could see some value in letting delegations correspond to names but have the keys behind those names be provided by the IdP.
Would crates.io be interested in TUF if this feature were available? It would be more likely we would add this if there were an adopter (or soon to be adopter) pushing this.
Either way, I'll need to spend more time thinking about this. I see the usability win. I just need to think more about if security loss (to the extent there is one) can be minimized.
Vladimir Diaz
Mar 23, 2018, 3:26:03 PM3/23/18
to Justin Cappos, Tony Arcieri, Hannes Mehnert, TUF
We have two small updates:
* TAP 8, along with two other proposals, have been added to CNCF's Google Summer of Code project ideas. It would be great if we found a talented student to work on it over the summer.
* Hannes has begun implementing TAP 8 in Conex, a TUF-like system for the OCaml community.
I think Tony's proposal is one we can explore in the future, perhaps in a separate TAP. If there is a lot of interest, we should probably pursue it. Something of the sort might be beneficial to community repositories like PyPI, where key management is important.
Thanks,
Vlad
P.S. We recently redesigned our website! The previous one was pretty messy...
--
You received this message because you are subscribed to the Google Groups "The Update Framework (TUF)" group.
Visit this group at https://groups.google.com/group/theupdateframework.
To view this discussion on the web visit https://groups.google.com/d/msgid/theupdateframework/CAMVss_p6w3rMXjb_vP4oSHbtEFAheMH4eZgu770uUyoXTm%2BF-w%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages