From 8c9c212176606ffa7ee1bdcb186bfc0f40e6f283 Mon Sep 17 00:00:00 2001 From: Justin Cappos Date: Thu, 3 Oct 2019 16:09:18 -0400 Subject: [PATCH 1/7] Fixing link to [81] --- pep-0458.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-0458.txt b/pep-0458.txt index a5067b51a52..a89de53f460 100644 --- a/pep-0458.txt +++ b/pep-0458.txt @@ -856,7 +856,7 @@ indicates an attack. As for attacks that serve different versions of metadata, or freeze a version of a package at a specific version, they can be handled by TUF with techniques -like implicit key revocation and metadata mismatch detection [81]. +like implicit key revocation and metadata mismatch detection [2]. Appendix A: Repository Attacks Prevented by TUF From d656e3c9c1418f1c3606033f4549b8c39e2491f3 Mon Sep 17 00:00:00 2001 From: Justin Cappos Date: Fri, 4 Oct 2019 11:37:08 -0400 Subject: [PATCH 2/7] Addressing the frequency of updates issue... --- pep-0458.txt | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/pep-0458.txt b/pep-0458.txt index a89de53f460..dd7f87a595a 100644 --- a/pep-0458.txt +++ b/pep-0458.txt @@ -618,7 +618,11 @@ The project transaction and snapshot processes SHOULD work concurrently. Finally, project transaction processes SHOULD keep in memory the latest *bins* metadata so that they will be correctly updated in new consistent snapshots. -All project transactions MAY be placed in a single queue and processed +Signing updated snapshot, timestamp, and bin metadata needs to be done on each +update. Fortunately, the actual operation of signing is fast enough that this +may be done a thousand or more times per second. However, locking must be +used so that project transactions are handled sequentially. To achieve this, +all project transactions MAY be placed in a single queue and processed serially. Alternatively, the queue MAY be processed concurrently in order of appearance, provided that the following rules are observed: From 4296723f00802d1c19233969966517856270b4df Mon Sep 17 00:00:00 2001 From: Trishank K Kuppusamy Date: Fri, 4 Oct 2019 15:45:52 -0400 Subject: [PATCH 3/7] talk about managing online keys --- pep-0458.txt | 40 ++++++++++++++++++++++++++++++++++++---- 1 file changed, 36 insertions(+), 4 deletions(-) diff --git a/pep-0458.txt b/pep-0458.txt index dd7f87a595a..7b428af5429 100644 --- a/pep-0458.txt +++ b/pep-0458.txt @@ -509,11 +509,43 @@ discarded and more offline keys will not help resist key recovery attacks [21]_ unless diversity of keys is maintained. -Online and Offline Keys Recommended for Each Role -------------------------------------------------- +Managing online keys +--------------------- -In order to support continuous delivery, the *timestamp*, *snapshot*, *bins* -role keys MUST be online. +In order to support continuous delivery, the keys for the *timestamp*, +*snapshot*, all *bin-n* roles MUST be online. There is little benefit in +requiring all of these roles to use different online keys, since attackers +would presumably be able to compromise all of them if they compromise PyPI. +Therefore, it is reasonable to use one online key for them all. + +This online key MAY be stored, encrypted or not, on the Python infrastructure. +For example, the kept MAY be kept on a self-hosted key management service +(e.g. Hashicorp Vault__), or a third-party one (e.g. AWS KMS__, Google +Cloud KMS__, or Azure Key Vault__). + +__ https://www.vaultproject.io/ +__ https://aws.amazon.com/kms/ +__ https://cloud.google.com/kms/ +__ https://docs.microsoft.com/en-us/azure/key-vault/basic-concepts + +Some of these key management services allow keys to be stored on Hardware +Security Modules (HSMs) (e.g., Hashicorp Vault__, AWS CloudHSM__, Google +Cloud HSM__, Azure Key Vault__). This prevents attackers from exfiltrating +the online private key (although not from using it, although their actions +may now be cryptographically auditable). However, this requires modifying +the reference TUF implementation to support HSMs (WIP__). + +__ https://www.vaultproject.io/docs/enterprise/hsm/index.html +__ https://aws.amazon.com/cloudhsm/ +__ https://cloud.google.com/hsm/ +__ https://docs.microsoft.com/en-us/azure/key-vault/key-vault-hsm-protected-keys +__ https://github.com/secure-systems-lab/securesystemslib/pull/170 + +Regardless of where and how this online key is kept, its use SHOULD be +carefully logged, monitored, and audited. + +Managing offline keys +---------------------- As explained in the previous section, the *root* and *targets* role keys MUST be offline for maximum security: these keys will be offline in the sense that From 7d1c235245d415449701b6c4df4c8ac9178488ed Mon Sep 17 00:00:00 2001 From: Trishank K Kuppusamy <33133073+trishankatdatadog@users.noreply.github.com> Date: Mon, 7 Oct 2019 12:50:00 -0400 Subject: [PATCH 4/7] Update pep-0458.txt Co-Authored-By: lukpueh --- pep-0458.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-0458.txt b/pep-0458.txt index 7b428af5429..827a239dc2d 100644 --- a/pep-0458.txt +++ b/pep-0458.txt @@ -513,7 +513,7 @@ Managing online keys --------------------- In order to support continuous delivery, the keys for the *timestamp*, -*snapshot*, all *bin-n* roles MUST be online. There is little benefit in +*snapshot*, and all *bin-n* roles MUST be online. There is little benefit in requiring all of these roles to use different online keys, since attackers would presumably be able to compromise all of them if they compromise PyPI. Therefore, it is reasonable to use one online key for them all. From 3f3e8c39abf9ce78d1b58c453abfede1a3678f99 Mon Sep 17 00:00:00 2001 From: Trishank K Kuppusamy <33133073+trishankatdatadog@users.noreply.github.com> Date: Mon, 7 Oct 2019 12:50:43 -0400 Subject: [PATCH 5/7] Update pep-0458.txt Co-Authored-By: lukpueh --- pep-0458.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-0458.txt b/pep-0458.txt index 827a239dc2d..85fe0b6c8fe 100644 --- a/pep-0458.txt +++ b/pep-0458.txt @@ -519,7 +519,7 @@ would presumably be able to compromise all of them if they compromise PyPI. Therefore, it is reasonable to use one online key for them all. This online key MAY be stored, encrypted or not, on the Python infrastructure. -For example, the kept MAY be kept on a self-hosted key management service +For example, the key MAY be kept on a self-hosted key management service (e.g. Hashicorp Vault__), or a third-party one (e.g. AWS KMS__, Google Cloud KMS__, or Azure Key Vault__). From ddbf2aa9691c5a438d97dce7517c5e88d11f0905 Mon Sep 17 00:00:00 2001 From: Trishank K Kuppusamy Date: Mon, 7 Oct 2019 15:12:33 -0400 Subject: [PATCH 6/7] discuss offline key ceremony --- pep-0458.txt | 91 ++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 67 insertions(+), 24 deletions(-) diff --git a/pep-0458.txt b/pep-0458.txt index 85fe0b6c8fe..5e3ac939ce2 100644 --- a/pep-0458.txt +++ b/pep-0458.txt @@ -468,21 +468,8 @@ order to be able to run on as many systems as Python supports; and third, TUF recommends diversity of keys for certain applications. -Number Of Keys Recommended --------------------------- - -The *timestamp*, *snapshot*, and *bins* roles require continuous delivery. -Even though their respective keys MUST be online, this PEP requires that the -keys be independent of each other. Different keys for online roles allow for -each of the keys to be placed on separate servers if need be, and prevents side -channel attacks that compromise one key from automatically compromising the -rest of the keys. Therefore, each of the *timestamp*, *snapshot*, and *bins* -roles MUST require (1, 1) keys. - -The *bins* role MAY delegate targets in an automated manner to a number of -roles called "bins", as discussed in the previous section. Each of the "bin" -roles SHOULD share the same key as the *bins* role, due to space efficiency, -and because there is no security advantage to requiring separate keys. +Number and Type Of Keys Recommended +----------------------------------- The *root* role key is critical for security and should very rarely be used. It is primarily used for key revocation, and it is the locus of trust for all @@ -504,13 +491,12 @@ MUST be offline and independent of other keys. For simplicity of key management, without sacrificing security, it is RECOMMENDED that the keys of the *targets* role be permanently discarded as soon as they have been created and used to sign for the role. Therefore, the *targets* role SHOULD require -(1, 1) keys. Again, this is because the keys are going to be permanently +(2, 3) keys. Again, this is because the keys are going to be permanently discarded and more offline keys will not help resist key recovery attacks [21]_ unless diversity of keys is maintained. - -Managing online keys ---------------------- +For similar reasons, the keys for the *bins* role SHOULD be set up similar to +the keys for the *targets* role. In order to support continuous delivery, the keys for the *timestamp*, *snapshot*, and all *bin-n* roles MUST be online. There is little benefit in @@ -518,10 +504,15 @@ requiring all of these roles to use different online keys, since attackers would presumably be able to compromise all of them if they compromise PyPI. Therefore, it is reasonable to use one online key for them all. -This online key MAY be stored, encrypted or not, on the Python infrastructure. -For example, the key MAY be kept on a self-hosted key management service -(e.g. Hashicorp Vault__), or a third-party one (e.g. AWS KMS__, Google -Cloud KMS__, or Azure Key Vault__). + +Managing online keys +--------------------- + +The online key shared by the *timestamp*, *snapshot*, and all *bin-n* roles +MAY be stored, encrypted or not, on the Python infrastructure. For example, +the key MAY be kept on a self-hosted key management service (e.g. Hashicorp +Vault__), or a third-party one (e.g. AWS KMS__, Google Cloud KMS__, or Azure +Key Vault__). __ https://www.vaultproject.io/ __ https://aws.amazon.com/kms/ @@ -531,7 +522,7 @@ __ https://docs.microsoft.com/en-us/azure/key-vault/basic-concepts Some of these key management services allow keys to be stored on Hardware Security Modules (HSMs) (e.g., Hashicorp Vault__, AWS CloudHSM__, Google Cloud HSM__, Azure Key Vault__). This prevents attackers from exfiltrating -the online private key (although not from using it, although their actions +the online private key (albeit not from using it, although their actions may now be cryptographically auditable). However, this requires modifying the reference TUF implementation to support HSMs (WIP__). @@ -552,6 +543,58 @@ be offline for maximum security: these keys will be offline in the sense that their private keys MUST NOT be stored on PyPI, though some of them MAY be online in the private infrastructure of the project. +There SHOULD be an offline key ceremony to generate, backup, and store these +keys in in such a manner that the private keys can be read only by the Python +administrators when necessary (e.g., such as rotating the keys for the +top-level TUF roles). Thus, keys SHOULD be generated—preferably in a physical +location where side-channel attacks__ are not a concern—using: + +1. A trusted, airgapped__ computer with a true random number generator +__, and with no **data** persisted after the ceremony +2. A trusted operating system +3. A trusted set of third-party packages (e.g., cryptographic libraries, +the TUF reference implementation) + +__ https://en.wikipedia.org/wiki/Side-channel_attack +__ https://en.wikipedia.org/wiki/Air_gap_(networking) +__ https://en.wikipedia.org/wiki/Hardware_random_number_generator + +In order to avoid persisting sensitive data (e.g., private keys) other than +on backup media after the ceremony, offline keys SHOULD be generated +encrypted using strong passwords, either on (in decreasing order of trust): +private HSMs (e.g., YubiHSM__), cloud-based HSMs (e.g., those listed above), +in volatile memory (e.g., RAM), or in nonvolatile memory +(e.g., SSD or microSD). If keys must be generated on nonvolatile memory, +then this memory MUST be irrecoverably destroyed after having securely +backed up the keys. + +__ https://www.yubico.com/products/yubihsm/ + +Passwords used to encrypt keys SHOULD be stored somewhere durable and +trustworthy where only Python admins have access. + +In order to minimize OPSEC__ errors during the ceremony, scripts SHOULD be +written to automate tedious parts such as: + +- Exporting to sneakernet__ all code and data (e.g., previous TUF metadata, +targets, and *root* keys) required to generate new keys and replace old ones +- Tighten the firewall, update the entire operating system in order to +fix security vulnerabilities, and airgap the computer +- Print and save cryptographic hashes of new TUF metadata +- Export *all* new TUF metadata, targets, and keys to encrypted backup media +- Export *only* new TUF metadata, targets, and online keys to encrypted backup +media + +__ https://en.wikipedia.org/wiki/Operations_security +__ https://en.wikipedia.org/wiki/Sneakernet + +Note the one-time keys for the *targets* and *bins* role MAY be safely +generated, used, and deleted during the offline key ceremony. Furthermore, +the *root* keys MAY not be generated during the offline key ceremony itself: +instead, a threshold t of n Python administrators, as discussed above, may sign +independently sign the *root* metadata **after** the offline key ceremony used +to generate all other keys. + How Should Metadata be Generated? ================================= From 0980fc41d8d9bb9aba589254ecc28353eccdb432 Mon Sep 17 00:00:00 2001 From: Trishank K Kuppusamy Date: Wed, 9 Oct 2019 16:47:42 -0400 Subject: [PATCH 7/7] clarify --- pep-0458.txt | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/pep-0458.txt b/pep-0458.txt index 5e3ac939ce2..699c80dcad8 100644 --- a/pep-0458.txt +++ b/pep-0458.txt @@ -491,9 +491,9 @@ MUST be offline and independent of other keys. For simplicity of key management, without sacrificing security, it is RECOMMENDED that the keys of the *targets* role be permanently discarded as soon as they have been created and used to sign for the role. Therefore, the *targets* role SHOULD require -(2, 3) keys. Again, this is because the keys are going to be permanently -discarded and more offline keys will not help resist key recovery attacks [21]_ -unless diversity of keys is maintained. +(2, 2) keys. Again, this is because the keys are going to be permanently +discarded, and more offline keys will not help resist key recovery +attacks [21]_ unless diversity of cryptographic algorithms is maintained. For similar reasons, the keys for the *bins* role SHOULD be set up similar to the keys for the *targets* role. @@ -533,7 +533,9 @@ __ https://docs.microsoft.com/en-us/azure/key-vault/key-vault-hsm-protected-keys __ https://github.com/secure-systems-lab/securesystemslib/pull/170 Regardless of where and how this online key is kept, its use SHOULD be -carefully logged, monitored, and audited. +carefully logged, monitored, and audited, ideally in a such a manner that +attackers who compromise PyPI are unable to immediately turn off this logging, +monitoring, and auditing. Managing offline keys ---------------------- @@ -588,7 +590,7 @@ media __ https://en.wikipedia.org/wiki/Operations_security __ https://en.wikipedia.org/wiki/Sneakernet -Note the one-time keys for the *targets* and *bins* role MAY be safely +Note the one-time keys for the *targets* and *bins* roles MAY be safely generated, used, and deleted during the offline key ceremony. Furthermore, the *root* keys MAY not be generated during the offline key ceremony itself: instead, a threshold t of n Python administrators, as discussed above, may sign