Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updates to Key Compromise Analysis #43

Merged
merged 3 commits into from
Oct 18, 2019
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 21 additions & 32 deletions pep-0458.txt
Original file line number Diff line number Diff line change
Expand Up @@ -808,8 +808,8 @@ Revoking Trust in Projects and Versions
=======================================

From time to time either a project or a version of a package will need to be revoked.
To revoke trust in either a project or a version of a package, the associated bin-n role can
simply remove the corresponding targets and re-sign the bin-n metadata. This action only
To revoke trust in either a project or a version of a package, the associated bin-n role can
simply remove the corresponding targets and re-sign the bin-n metadata. This action only
requires actions with the online bin-n key.


Expand All @@ -828,41 +828,25 @@ private cryptographic keys (belonging to any of the PyPI roles) are
compromised. The leftmost column lists the roles (or a combination of roles)
that have been compromised, and the columns to its right show whether the
compromised roles leave clients susceptible to malicious updates, a freeze
attack, or metadata inconsistency attacks.
attack, or metadata inconsistency attacks. Note that if the timestamp, snapshot,
and bin-n roles are stored in the same online location, a compromise of one
means they will all be compromised. Therefore the table considers these
roles together. A version of this table that considers these roles separately
is included in PEP 480 [26]_.

+-----------------+-------------------+----------------+--------------------------------+
| Role Compromise | Malicious Updates | Freeze Attack | Metadata Inconsistency Attacks |
+=================+===================+================+================================+
| timestamp | NO | YES | NO |
| | snapshot and | limited by | snapshot needs to cooperate |
| | targets or any | earliest root, | |
| | of the bins need | targets, or | |
| | to cooperate | bin expiry | |
| | | time | |
+-----------------+-------------------+----------------+--------------------------------+
| snapshot | NO | NO | NO |
| | timestamp and | timestamp | timestamp needs to cooperate |
| | targets or any of | needs to | |
| | the bins need to | cooperate | |
| | cooperate | | |
+-----------------+-------------------+----------------+--------------------------------+
| timestamp | NO | YES | YES |
| **AND** | targets or any | limited by | limited by earliest root, |
| snapshot | of the bins need | earliest root, | targets, or bin metadata |
| | to cooperate | targets, or | expiry time |
| | | bin metadata | |
| | | expiry time | |
+-----------------+-------------------+----------------+--------------------------------+
| targets | NO | NOT APPLICABLE | NOT APPLICABLE |
| targets | NO | NO | NO |
| **OR** | timestamp and | need timestamp | need timestamp and snapshot |
| bin | snapshot need to | and snapshot | |
| bins | snapshot need to | and snapshot | |
| | cooperate | | |
+-----------------+-------------------+----------------+--------------------------------+
| timestamp | YES | YES | YES |
| **AND** | | limited by | limited by earliest root, |
| snapshot | | earliest root, | targets, or bin metadata |
| **AND** | | targets, or | expiry time |
| bin | | bin metadata | |
| **AND** | limited by | limited by | limited by earliest root, |
| snapshot | earliest root, | earliest root, | targets, or bins metadata |
| **AND** | targets, or bins | targets, or | expiry time |
| bin-n | expiry time | bins metadata | |
| | | expiry time | |
+-----------------+-------------------+----------------+--------------------------------+
| root | YES | YES | YES |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a suggestions: Would collapsing the columns make the table easier to read?

+-----------------+-------------------+----------------+--------------------------------+
| Role Compromise | Malicious Updates | Freeze Attack  | Metadata Inconsistency Attacks |
+=================+===================+================+================================+
| targets         | NO                                                                  |
| **OR**          | timestamp and snapshot need to cooperate for any of the attacks     |
| bins            |                                                                     |
+-----------------+-------------------+----------------+--------------------------------+
| timestamp       | YES                                                                 |
| **AND**         | but all of the attacks are limited by earliest root, targets or     |
| snapshot        | bins metadata expiry time                                           |
| **AND**         |                                                                     |
| bin-n           |                                                                     |
+-----------------+-------------------+----------------+--------------------------------+
| root            | YES                                                                 |
+-----------------+-------------------+----------------+--------------------------------+

If not, I advise to use the same wording in every box, if the condition is the same, i.e.:

  • "[roles] need to cooperate" vs. "need [roles]" (in row 1)
  • "[... roles] expiry time" vs. "[... roles] metadata expiry" (in row 2)

Expand All @@ -875,17 +859,22 @@ was susceptible to these attacks and how TUF could protect users against them

__ https://mail.python.org/pipermail/distutils-sig/2013-September/022755.html

Note that compromising *targets* or any delegated role (except for project
targets metadata) does not immediately allow an attacker to serve malicious
Note that compromising *targets* or *bins*
does not immediately allow an attacker to serve malicious
updates. The attacker must also compromise the *timestamp* and *snapshot*
roles, which are both online and therefore more likely to be compromised.
This means that, in order to launch any attack, one must not only be able to
act as a man-in-the-middle, but also compromise the *timestamp* key (or
compromise the *root* keys and sign a new *timestamp* key). To launch any
attack other than a freeze attack, one must also compromise the *snapshot* key.
In practice, this PEP recommends storing the *snapshot*, *timestamp*, and
*bin-n* keys together, or even using the same key for all of these roles.
Because of this, the attacker only needs to compromise this single server to
perform any of the attacks listed above. However, the offline *root* key will
allow the repository to recover from an attack by revoking the online key(s).

Finally, a compromise of the PyPI infrastructure MAY introduce malicious
updates to *bins* projects because the keys for these roles are online. The
updates to *bin-n* projects because the keys for these roles are online. The
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels like the leading two sentences in this paragraph pretty much repeat what has been said at the end of the previous paragraph. I suggest to remove them.

To bridge from online key compromise to PEP 480. I suggest to rephrase the remainder of this paragraph to something like:

The maximum security model shows how TUF mitigates online key compromises by introducing additional roles for end-to-signing. Details about how to generate developer keys and singing upload distributions are provided in PEP 480 [26]_.

maximum security model discussed in PEP 480 [26]_ addresses this issue and goes
into more detail about generating developer keys and signing uploaded
distributions.
Expand Down