From cheald at gmail.com Sat Feb 2 16:32:11 2013 From: cheald at gmail.com (Chris Heald) Date: Sat, 2 Feb 2013 09:32:11 -0700 Subject: Security infrastructure proposal Message-ID: Hey folks -- I've been noodling on the state of the security infrastructure, and have congealed my thoughts on it into a proposal. I'd like to disclose up front that I am not a security expert per se, and don't seek to claim any kind of authority in that regard, but I am an experienced systems architect and hope that counts for something! :) I'm cross-posting this to the rubygems.org group as well as the rubygems-developers list as it would require changes to both the rubygems installable and distribution platforms like rubygems.org. The primary goals are: 1. Principle of least responsibility - the infrastructure consists of multiple independent systems, with the intent that a breach of any single system is covered by the other systems in place. 2. Verification of continuity - gem consumers should be confident that they are consuming authorized gems every time they do an install or upgrade of a gem. 3. Provision for multiple signers, so that group-maintained projects work easily in the system. 4. Provision for certificate revocation, in order to revoke certificates at any point in the chain of trust This proposal does not attempt to verify identity beyond email address ownership, nor does it intend to provide a vetting platform for code that would restrict publication of gems. It would still be possible to publish nasty gems under this system, but it would protect against backdoored gems and illicit uploads, as well as providing a revocation mechanism for end users to use to discover and remove compromised gems in the event of a breach. Additionally, I should mention that I based the proposal on X509, as Evan previously indicated that any signing mechanism would need to work with only the Ruby stdlib, which means OpenSSL. There has been some talk of GPG and Web-of-trust systems for certification, and while I think that such a system could be used with this setup, x509 gets the ball rolling faster as it's already in place in Rubygems, and has no external dependencies like GPG. I'm sure there are things I haven't considered in this system, and would very much like feedback, criticism, and flames. ------------------------------------------------------------------------------------------ # Root Key & Signing System A single X509 key is generated per distribution platform (Rubygems.org, Gemfury, etc). This key is used to sign gem author requests. A gem author may generate a certificate and request that the platform sign it. Alice generates her x509 keypair with her email address encoded as the x509 name field, stashes the private key somewhere safe, and submits the pubkey to the signing system. The signing system consists of two parts: 1. [Machine A] A web UI (or email inbox) responsible for accepting public keys and sending emails 2. [Machine B] A signing machine with a shared data store (shared NFS mount, redis store, whatever - it must simply be a data store to act as a dead drop) The UI accepts pubkeys, ensures their validity, parses the certificate for the name field, and sends a verification email to the email specified in the name field. The email contains a link with a cryptographic signature (something like an HMAC of the pubkey). The email owner clicks this link (or replies to the email) which causes Machine A to validate the response and put the affiliated pubkey into the dead-drop inbox. Machine B is monitoring the inbox for pubkeys. Once a key is received, it is signed, and placed in the dead-drop outbox. Machine A monitors the outbox for signed keys. It again parses the key for the name field again, encrypts the signed key with itself, and emails it to the name field in the record. Alice retrieves the key from her email inbox, decrypts it with her private key, and then may use it to sign her gems. This system could have an exceptionally small attack surface, consisting of only a minimal mailserver (A) and a local-only daemon (B) which operate on shared storage (on either A or B, or on a third server, C). # Gem certificate chain history server A separate server ["Chain of trust history server"] maintains and validates cert chain history for all gems on Rubygems.org, but which is queryable by Rubygems-bin, allowing Rubygems-bin to obtain the last known and verified certificate chain for a given gem when installing in the event that no local history is known. It must be separate from the Rubygems.org platform in order to avoid allowing a compromise of Rubygems.org to be pivoted into a compromise of the certificate history system, allowing an attacker to upload fraudulent certificates. This system would naturally serve as an automated IDS, as well, and could raise an alarm if it ever discovered that Rubygems.org had accepted a gem without a valid certificate chain, indicating a breach of the system's certificate verification mechanisms. # Gem Signing The gem is signed with something like: s.signing_key = File.expand_path("~/.gem/trust/.gem-private_cert.pem") s.cert_chain = ['rubygems-public_cert.pem', 'alice-public_cert.pem'] Alice may then upload her gem to Rubygems.org. Upon receipt of the gem, Rubygems.org ensures that the gem has been signed with a cert chain terminating in a certificate that it knows about and trusts. Additionally, it will ensure that the gem is signed with a certificate containing an email that matches the email on the account of the system. Rubygems(-bin) will maintain a local history of certificate chains for a gem. If a certificate is *removed* (without a signed authorization), then it will refuse to install the gem, suggest review, and require a user override to proceed. Rubygems.org will additionally maintain this certificate chain, and refuse to accept a gem that does not include the owning account's email as a part of the chain of trust. This ensures: * If an individual Rubygems.org account is compromised (but not the legitimate owner's private key), then a malicious entity cannot upload a modified gem into the account. * If an individual Rubygems.org account is comprimised, and the attacker has been able to forge a key with the account's email, then the attacker can upload new gems into the account, but cannot publish new versions of existing gems, as they will fail to validate the chain of trust history. * If Rubygems as a whole is compromised, then the attacker may be able to upload a malicious gem. However, Rubygems-bin will refuse to install any newer version of it. Rubygems will allow certificates to be *added* to the certificate chain, so long as they are signed by a non-root certificate in the chain. This permits for transfer of project ownership and multiple signing keys. For example: ### Project transfer Alice starts a project, Foobar, signs it with her key. The chain now looks like: [rubygems, alice] Alice then later abandons the project, and Charlie takes over as maintainer with Alice's blessing. Alice would generate a key re-issue signature on the project, authorizing the removal of her key, and the addition of Charlie's. The chain now looks like: [rubygems, charlie] (alice removed with authorization) As Alice signed Charlie's key and authorized her key's removal, she is still part of the chain of trust allowing the chain history to permit the change, the system permits installation, with the implicit understanding that Alice has blessed Charlie's key. Future releases will not need Alice's blessing. ### Multi-user projects Alice starts a popular project, which she then wants to add publishing members to while retaining publication ability herself. Initially, the trust chain is: [rubygems, alice] Upon wanting to add a new member, Alice generate a project master key, and authorizes key reissuance of the project using the new project master key [rubygems, project-master] (alice removed with authorization) Then Alice uses the project-master key to sign Charlie's key (and perhaps her own personal key): [rubygems, project-master, charlie] Alice may continue to publish to the project while allowing Charlie to publish to the project, without giving Charlie her personal key's trust. ### Malicious cert chain modification If Dave, a malicious actor, managed to wrest control of the project, he would be able to sign the gem, but its trust chain would look like: [rubygems, dave] Thus, both Rubygems.org and Rubygems-bin would reject the gem based on the gem's known certificate history, and Alice's unauthorized exclusion from the certificate chain. # Gem installation and verification Bob, a Ruby developer, wants to use Alice's gem. Bob would install the Rubygems.org public cert as a trusted certificate: gem cert --add rubygems-public_cert.pem Bob may then download and install Alice's gem, and Rubygems(-bin)'s HighSecurity policy will validate and accept the gem, and permit it to install. # Certificate revocation Before fetching a gem, Rubygems would need to fetch any certificate revocation lists. It would then check the trusted certificate list for revocations, and remove any that appear on the list. This is the primary mechanism in which a compromised CA key would be removed. Users would be required to manually install the new key in this event. This necessitates that the Rubygems public key must be published in a location that is not connected to the CA, as a compromise of the CA could allow an attacker to revoke the otherwise-legitimate root key and publish his own for consumption. Each time Rubygems runs a network operation, it should 1. Check if the revocation list has changed since the last time it validated certificates for known gems. 2. If the list has changed, validate the certificate chains for all installed gems. Prompt to remove any with invalid certificates. 3. If step 2 was run, write a hash of the revocation list and the list of gems that passed muster. 4. Remove any entries from the local chain of trust history that contain revoked certificates. 5. Check for a new revocation list 6. Run step 2 if the revocation list has changed. This allows for certificate verifications and revocations for multiple gem installs (RVM gemsets, bundler local installs) in a given system. # Attack Surfaces * Installation of a malicious certificate as a trusted root certificate on a local machine would result in signatures becoming unreliable. However, given that this would require some level of ownership of the machine, it would likely be a small problem in such an event. * Compromise of Rubygems.org's distribution platform may result in the upload of malicious gems. Such gems would be distributed to gem installers, which would then reject the gems due to either a local failed chain of trust, or a failed chain of trust from the chain history server. * Compromise of the chain history server would not be exploitable to install malicious software, as the attacker must also have control of the distribution platform. MITM attacks would be viable, but if you can MITM Rubygems.org, you can MITM chain history server queries. * Compromise of the chain history server AND Rubygems.org would allow for attackers to upload compromised gems to Rubygems.org and distribute them to pristine installs. Upgrades would still fail due to the local chain of trust history. * Compromise of the Rubygems' pubkey publication platform could result in an attacker publishing his own public key, which would affect people installing the certificate for the first time. However, legitimate gems from Rubygems.org would fail to install as they were not signed with the attacker's keypair. * Compromise of the pubkey platform AND the Rubygems.org platform would result in failure to install due to local or queried chain of trust histories. * Compromise of the CA's "Machine A" would result in people being able to obtain signed keys for emails without validation. It would not expose the private key for Machine B. This would permit uploading of new gems to a compromised user account, but new versions of existing gems would fail to upload, as the key provided would not be a part of the gem's existing chain of trust history. * Compromise of the CA's "Machine B" would result in disclosure of the private key, requiring that the root key be revoked and reissued. This would invalidate all current gem signatures. Illicit replacement of the private key on CA's "Machine B" would result in people being issued certificates that would fail to upload to Rubygems.org, due to failure to validate the cert chain against the Rubygems.org private key. * Compromise of the CA and Rubygems.org would result in pristine installs being served malicious software. Upgrades would still fail due to local chain of trust history. * An author's stolen private key may be used to fraudulently sign requests. This may be defended against by following proper key protection measures and password-protecting the key. * Most raised MITM attacks can be avoided by performing Rubygems.org and chain history queries via SSL. -- Chris From jftucker at gmail.com Sat Feb 2 17:06:00 2013 From: jftucker at gmail.com (James Tucker) Date: Sat, 2 Feb 2013 09:06:00 -0800 Subject: Security infrastructure proposal In-Reply-To: References: Message-ID: <471A2B85-FC61-43C1-B3F0-FED2D7DDEA02@gmail.com> Chris, I'm waiting for my hiking partner to arrive in the next few minutes, so I can't review this immediately, but I have a chance to offer you my gratitude for putting something together so swiftly and presenting it properly. I look forward to reading through it later. Cheers, James On Feb 2, 2013, at 8:32 AM, Chris Heald wrote: > Hey folks -- > > I've been noodling on the state of the security infrastructure, and have > congealed my thoughts on it into a proposal. I'd like to disclose up front > that I am not a security expert per se, and don't seek to claim any kind of > authority in that regard, but I am an experienced systems architect and > hope that counts for something! :) > > I'm cross-posting this to the rubygems.org group as well as the > rubygems-developers list as it would require changes to both the rubygems > installable and distribution platforms like rubygems.org. > > The primary goals are: > > 1. Principle of least responsibility - the infrastructure consists of > multiple independent systems, with the intent that a breach of any single > system is covered by the other systems in place. > 2. Verification of continuity - gem consumers should be confident that they > are consuming authorized gems every time they do an install or upgrade of a > gem. > 3. Provision for multiple signers, so that group-maintained projects work > easily in the system. > 4. Provision for certificate revocation, in order to revoke certificates at > any point in the chain of trust > > This proposal does not attempt to verify identity beyond email address > ownership, nor does it intend to provide a vetting platform for code that > would restrict publication of gems. It would still be possible to publish > nasty gems under this system, but it would protect against backdoored gems > and illicit uploads, as well as providing a revocation mechanism for end > users to use to discover and remove compromised gems in the event of a > breach. > > Additionally, I should mention that I based the proposal on X509, as Evan > previously indicated that any signing mechanism would need to work with > only the Ruby stdlib, which means OpenSSL. There has been some talk of GPG > and Web-of-trust systems for certification, and while I think that such a > system could be used with this setup, x509 gets the ball rolling faster as > it's already in place in Rubygems, and has no external dependencies like > GPG. > > I'm sure there are things I haven't considered in this system, and would > very much like feedback, criticism, and flames. > > ------------------------------------------------------------------------------------------ > > # Root Key & Signing System > > A single X509 key is generated per distribution platform (Rubygems.org, > Gemfury, etc). This key is used to sign gem author requests. > > A gem author may generate a certificate and request that the platform sign > it. Alice generates her x509 keypair with her email address encoded as the > x509 name field, stashes the private key somewhere safe, and submits the > pubkey to the signing system. > > The signing system consists of two parts: > > 1. [Machine A] A web UI (or email inbox) responsible for accepting public > keys and sending emails > 2. [Machine B] A signing machine with a shared data store (shared NFS > mount, redis store, whatever - it must simply be a data store to act as a > dead drop) > > The UI accepts pubkeys, ensures their validity, parses the certificate for > the name field, and sends a verification email to the email specified in > the name field. The email contains a link with a cryptographic signature > (something like an HMAC of the pubkey). The email owner clicks this link > (or replies to the email) which causes Machine A to validate the response > and put the affiliated pubkey into the dead-drop inbox. > > Machine B is monitoring the inbox for pubkeys. Once a key is received, it > is signed, and placed in the dead-drop outbox. > > Machine A monitors the outbox for signed keys. It again parses the key for > the name field again, encrypts the signed key with itself, and emails it to > the name field in the record. > > Alice retrieves the key from her email inbox, decrypts it with her private > key, and then may use it to sign her gems. > > This system could have an exceptionally small attack surface, consisting of > only a minimal mailserver (A) and a local-only daemon (B) which operate on > shared storage (on either A or B, or on a third server, C). > > # Gem certificate chain history server > > A separate server ["Chain of trust history server"] maintains and validates > cert chain history for all gems on Rubygems.org, but which is queryable by > Rubygems-bin, allowing Rubygems-bin to obtain the last known and verified > certificate chain for a given gem when installing in the event that no > local history is known. > > It must be separate from the Rubygems.org platform in order to avoid > allowing a compromise of Rubygems.org to be pivoted into a compromise of > the certificate history system, allowing an attacker to upload fraudulent > certificates. > > This system would naturally serve as an automated IDS, as well, and could > raise an alarm if it ever discovered that Rubygems.org had accepted a gem > without a valid certificate chain, indicating a breach of the system's > certificate verification mechanisms. > > # Gem Signing > > The gem is signed with something like: > > s.signing_key = File.expand_path("~/.gem/trust/.gem-private_cert.pem") > s.cert_chain = ['rubygems-public_cert.pem', 'alice-public_cert.pem'] > > Alice may then upload her gem to Rubygems.org. Upon receipt of the gem, > Rubygems.org ensures that the gem has been signed with a cert chain > terminating in a certificate that it knows about and trusts. Additionally, > it will ensure that the gem is signed with a certificate containing an > email that matches the email on the account of the system. > > Rubygems(-bin) will maintain a local history of certificate chains for a > gem. If a certificate is *removed* (without a signed authorization), then > it will refuse to install the gem, suggest review, and require a user > override to proceed. Rubygems.org will additionally maintain this > certificate chain, and refuse to accept a gem that does not include the > owning account's email as a part of the chain of trust. This ensures: > > * If an individual Rubygems.org account is compromised (but not the > legitimate owner's private key), then a malicious entity cannot upload a > modified gem into the account. > * If an individual Rubygems.org account is comprimised, and the attacker > has been able to forge a key with the account's email, then the attacker > can upload new gems into the account, but cannot publish new versions of > existing gems, as they will fail to validate the chain of trust history. > * If Rubygems as a whole is compromised, then the attacker may be able to > upload a malicious gem. However, Rubygems-bin will refuse to install any > newer version of it. > > Rubygems will allow certificates to be *added* to the certificate chain, so > long as they are signed by a non-root certificate in the chain. This > permits for transfer of project ownership and multiple signing keys. For > example: > > ### Project transfer > > Alice starts a project, Foobar, signs it with her key. The chain now > looks like: > > [rubygems, alice] > > Alice then later abandons the project, and Charlie takes over as > maintainer with Alice's blessing. Alice would generate a key re-issue > signature on the project, authorizing the removal of her key, and the > addition of Charlie's. The chain now looks like: > > [rubygems, charlie] (alice removed with authorization) > > As Alice signed Charlie's key and authorized her key's removal, she is > still part of the chain of trust allowing the chain history to permit the > change, the system permits installation, with the implicit understanding > that Alice has blessed Charlie's key. Future releases will not need Alice's > blessing. > > ### Multi-user projects > > Alice starts a popular project, which she then wants to add publishing > members to while retaining publication ability herself. Initially, the > trust chain is: > > [rubygems, alice] > > Upon wanting to add a new member, Alice generate a project master key, and > authorizes key reissuance of the project using the new project master key > > [rubygems, project-master] (alice removed with authorization) > > Then Alice uses the project-master key to sign Charlie's key (and perhaps > her own personal key): > > [rubygems, project-master, charlie] > > Alice may continue to publish to the project while allowing Charlie to > publish to the project, without giving Charlie her personal key's trust. > > ### Malicious cert chain modification > > If Dave, a malicious actor, managed to wrest control of the project, he > would be able to sign the gem, but its trust chain would look like: > > [rubygems, dave] > > Thus, both Rubygems.org and Rubygems-bin would reject the gem based on > the gem's known certificate history, and Alice's unauthorized exclusion > from the certificate chain. > > # Gem installation and verification > > Bob, a Ruby developer, wants to use Alice's gem. Bob would install the > Rubygems.org public cert as a trusted certificate: > > gem cert --add rubygems-public_cert.pem > > Bob may then download and install Alice's gem, and Rubygems(-bin)'s > HighSecurity policy will validate and accept the gem, and permit it to > install. > > # Certificate revocation > > Before fetching a gem, Rubygems would need to fetch any certificate > revocation lists. It would then check the trusted certificate list for > revocations, and remove any that appear on the list. This is the primary > mechanism in which a compromised CA key would be removed. Users would be > required to manually install the new key in this event. > > This necessitates that the Rubygems public key must be published in a > location that is not connected to the CA, as a compromise of the CA could > allow an attacker to revoke the otherwise-legitimate root key and publish > his own for consumption. > > Each time Rubygems runs a network operation, it should > > 1. Check if the revocation list has changed since the last time it > validated certificates for known gems. > 2. If the list has changed, validate the certificate chains for all > installed gems. Prompt to remove any with invalid certificates. > 3. If step 2 was run, write a hash of the revocation list and the list of > gems that passed muster. > 4. Remove any entries from the local chain of trust history that contain > revoked certificates. > 5. Check for a new revocation list > 6. Run step 2 if the revocation list has changed. > > This allows for certificate verifications and revocations for multiple gem > installs (RVM gemsets, bundler local installs) in a given system. > > # Attack Surfaces > > * Installation of a malicious certificate as a trusted root certificate on > a local machine would result in signatures becoming unreliable. However, > given that this would require some level of ownership of the machine, it > would likely be a small problem in such an event. > * Compromise of Rubygems.org's distribution platform may result in the > upload of malicious gems. Such gems would be distributed to gem installers, > which would then reject the gems due to either a local failed chain of > trust, or a failed chain of trust from the chain history server. > * Compromise of the chain history server would not be exploitable to > install malicious software, as the attacker must also have control of the > distribution platform. MITM attacks would be viable, but if you can MITM > Rubygems.org, you can MITM chain history server queries. > * Compromise of the chain history server AND Rubygems.org would allow for > attackers to upload compromised gems to Rubygems.org and distribute them to > pristine installs. Upgrades would still fail due to the local chain of > trust history. > * Compromise of the Rubygems' pubkey publication platform could result in > an attacker publishing his own public key, which would affect people > installing the certificate for the first time. However, legitimate gems > from Rubygems.org would fail to install as they were not signed with the > attacker's keypair. > * Compromise of the pubkey platform AND the Rubygems.org platform would > result in failure to install due to local or queried chain of trust > histories. > * Compromise of the CA's "Machine A" would result in people being able to > obtain signed keys for emails without validation. It would not expose the > private key for Machine B. This would permit uploading of new gems to a > compromised user account, but new versions of existing gems would fail to > upload, as the key provided would not be a part of the gem's existing chain > of trust history. > * Compromise of the CA's "Machine B" would result in disclosure of the > private key, requiring that the root key be revoked and reissued. This > would invalidate all current gem signatures. Illicit replacement of the > private key on CA's "Machine B" would result in people being issued > certificates that would fail to upload to Rubygems.org, due to failure to > validate the cert chain against the Rubygems.org private key. > * Compromise of the CA and Rubygems.org would result in pristine installs > being served malicious software. Upgrades would still fail due to local > chain of trust history. > * An author's stolen private key may be used to fraudulently sign requests. > This may be defended against by following proper key protection measures > and password-protecting the key. > * Most raised MITM attacks can be avoided by performing Rubygems.org and > chain history queries via SSL. > > -- Chris > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From jftucker at gmail.com Mon Feb 11 21:31:20 2013 From: jftucker at gmail.com (James Tucker) Date: Mon, 11 Feb 2013 13:31:20 -0800 Subject: Rubygems Trust Model Message-ID: All, We have taken some time to prepare the following document in regard to the current trust model, and future goals and requirements. We're looking for two things at present, before creating/evaluating proposals: * Interested parties (probably larger vendor security team members, although may be individual contributors also) * Missed goals/requirements discussions *http://goo.gl/ybFIO* Please feel free to provide feedback here on the ML, and as necessary we'll also be happy to add contributors to the editors and commenters lists on the document. Many thanks, James From halostatue at gmail.com Mon Feb 11 21:59:49 2013 From: halostatue at gmail.com (Austin Ziegler) Date: Mon, 11 Feb 2013 16:59:49 -0500 Subject: Rubygems Trust Model In-Reply-To: References: Message-ID: On Mon, Feb 11, 2013 at 4:31 PM, James Tucker wrote: > All, > > We have taken some time to prepare the following document in regard to the > current trust model, and future goals and requirements. We're looking for > two things at present, before creating/evaluating proposals: > > * Interested parties (probably larger vendor security team members, > although may be individual contributors also) > * Missed goals/requirements discussions Thank you. I'm definitely interested in this, and will need to read the document in more depth, but the focus on keeping the workflow easy is important. I decided recently to start signing my gems again?which means that I had to create a new cert pair and the public certs are published on RubyForge (I use `hoe` for most of my gems, and Ryan has done a great job of making this part fairly transparent; I had some issues getting the cert up for the first gem, but?). One thing that I think will be important with this is whether we should have more than one "authorized" key/cert for a particular gem or set of gems, or whether authors can/should have multiple identities (that is, should my diff-lcs gems be signed with the same cert/key that mime-types is?). I also think that, even though it's built on top of rubygems, Bundler should be part of this overall security discussion. -a -- Austin Ziegler ? halostatue at gmail.com ? austin at halostatue.ca http://www.halostatue.ca/ ? http://twitter.com/halostatue From tk47 at students.poly.edu Fri Feb 15 08:39:53 2013 From: tk47 at students.poly.edu (Trishank Karthik Kuppusamy) Date: Fri, 15 Feb 2013 03:39:53 -0500 Subject: Hello from the TUF team Message-ID: <511DF459.8010500@students.poly.edu> Hello rubygems, We hear from Donald Stufft at the Python Catalog-SIG mailing list that you are interested in securing rubygems. We are The Update Framework (TUF) project [https://www.updateframework.com/], and we would like to help Ruby and Python folks to help secure their package managers. TUF is a framework designed by computer scientists from NYU-Poly, University of Washington and the Tor project to help solve some of the more common problems with securing software updaters. Here are some papers we wrote on the subject: https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf https://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf What we would like to do is to help the rubygems community to understand how you may use TUF to secure your package manager with security designed carefully and intrinsically, so that you do not have to worry about the most common security issues. Donald, havenwood and raggi introduced us to the Rubygems Trust Model document [http://goo.gl/ybFIO], and we will comment on it as soon as we find the time. In fact, we are going to have a TUF hackathon here in a few hours, and we hope to make more progress on these matters soon enough. Please feel free to reach out to us with your questions! Thanks, Trishank From jftucker at gmail.com Sat Feb 16 00:16:37 2013 From: jftucker at gmail.com (James Tucker) Date: Fri, 15 Feb 2013 16:16:37 -0800 Subject: Hello from the TUF team In-Reply-To: <511DF459.8010500@students.poly.edu> References: <511DF459.8010500@students.poly.edu> Message-ID: Trishank, Thank you for stopping by and offering your assistance, I really appreciate it. I have been digesting the Survivable Key Compromise paper, spec and implementation, and it very much maps to my major concerns for the Rubygems system; it is so far the first proposal I have seen that appears to be close to complete. I still need more time to digest everything fully, but in the meantime I have some questions already (some of which may be born of misunderstandings, so your patience is appreciated): * What are your recommendations for the targets/* topology? - If we use simply gem names (not full name-version-platform tuples or strings), then I think the revocation model requires a rewrite of a whole target metadata be rewritten after target key compromise. This may be acceptable, however, - If we use targets/gemname/version-platform then we can rewrite targets/gemname.txt to disallow future publishing using compromised keys, but existing (non-malicious) gemname/version-platform.txt remain valid. Is this the case, and is this safe? (assuming all other standard roles) - The paper loosely suggests in the language having these map to files, which makes sense, but is somewhere between the above two options, and requires new targets to be issued regularly (maybe that is a good thing?). - There are some scaling concerns with each different approach that we may need to consider. In any of the latter cases, release.txt will continue to grow fast, although gzip and such will also continue to work well. At some point though, parsing becomes slow and/or memory intensive. * The paper mentions the metadata files for 8000 PyPI binaries reaching several megabytes. We have considerably more data than this, as such we may very much need to alter both the data format, and possibly slice the files into pieces. Do you have any particular recommendations in this area? Are there non-obvious key security considerations here (I think most are covered by timestamp.txt and release.txt)? * Given the existence of the release and higher level targets roles in this system, do you still strongly recommend leaf-targets (e.g. targets/gems/rails-3.2.0-ruby.txt) be rewritten in the event of a compromise of the rails key that signed it (in the event of t=1)? * There is scope in the metadata, for two roles to have the same paths or path patterns. Is it recommended such an event be a validation error? Many thanks, James On 15 February 2013 00:39, Trishank Karthik Kuppusamy < tk47 at students.poly.edu> wrote: > Hello rubygems, > > We hear from Donald Stufft at the Python Catalog-SIG mailing list that you > are interested in securing rubygems. > > We are The Update Framework (TUF) project [https://www.updateframework.** > com/ ], and we would like to help Ruby > and Python folks to help secure their package managers. > > TUF is a framework designed by computer scientists from NYU-Poly, > University of Washington and the Tor project to help solve some of the more > common problems with securing software updaters. > > Here are some papers we wrote on the subject: > > https://isis.poly.edu/~**jcappos/papers/cappos_mirror_**ccs_08.pdf > https://isis.poly.edu/~**jcappos/papers/samuel_tuf_ccs_**2010.pdf > > What we would like to do is to help the rubygems community to understand > how you may use TUF to secure your package manager with security designed > carefully and intrinsically, so that you do not have to worry about the > most common security issues. > > Donald, havenwood and raggi introduced us to the Rubygems Trust Model > document [http://goo.gl/ybFIO], and we will comment on it as soon as we > find the time. In fact, we are going to have a TUF hackathon here in a few > hours, and we hope to make more progress on these matters soon enough. > > Please feel free to reach out to us with your questions! > > Thanks, > Trishank > > ______________________________**_________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/**rubygems > RubyGems-Developers at rubyforge.**org > http://rubyforge.org/mailman/**listinfo/rubygems-developers > From tk47 at students.poly.edu Sat Feb 16 00:42:51 2013 From: tk47 at students.poly.edu (Trishank Karthik Kuppusamy) Date: Fri, 15 Feb 2013 19:42:51 -0500 Subject: Hello from the TUF team In-Reply-To: References: <511DF459.8010500@students.poly.edu> Message-ID: <511ED60B.9040202@students.poly.edu> Hello James, Thanks very much for your email. I just realized that I forgot to copy my advisor and one of the primary designers of the TUF framework, Prof. Justin Cappos. We are currently under some intense deadlines, but we will strive to get back to you as soon as possible. Thanks in advance for your patience! With best regards, Trishank On 02/15/2013 07:16 PM, James Tucker wrote: > Trishank, > > Thank you for stopping by and offering your assistance, I really appreciate > it. > > I have been digesting the Survivable Key Compromise paper, spec and > implementation, and it very much maps to my major concerns for the Rubygems > system; it is so far the first proposal I have seen that appears to be > close to complete. > > I still need more time to digest everything fully, but in the meantime I > have some questions already (some of which may be born of > misunderstandings, so your patience is appreciated): > > * What are your recommendations for the targets/* topology? > - If we use simply gem names (not full name-version-platform tuples or > strings), then I think the revocation model requires a rewrite of a whole > target metadata be rewritten after target key compromise. This may be > acceptable, however, > - If we use targets/gemname/version-platform then we can rewrite > targets/gemname.txt to disallow future publishing using compromised keys, > but existing (non-malicious) gemname/version-platform.txt remain valid. Is > this the case, and is this safe? (assuming all other standard roles) > - The paper loosely suggests in the language having these map to files, > which makes sense, but is somewhere between the above two options, and > requires new targets to be issued regularly (maybe that is a good thing?). > - There are some scaling concerns with each different approach that we > may need to consider. In any of the latter cases, release.txt will continue > to grow fast, although gzip and such will also continue to work well. At > some point though, parsing becomes slow and/or memory intensive. > * The paper mentions the metadata files for 8000 PyPI binaries reaching > several megabytes. We have considerably more data than this, as such we may > very much need to alter both the data format, and possibly slice the files > into pieces. Do you have any particular recommendations in this area? Are > there non-obvious key security considerations here (I think most are > covered by timestamp.txt and release.txt)? > * Given the existence of the release and higher level targets roles in > this system, do you still strongly recommend leaf-targets (e.g. > targets/gems/rails-3.2.0-ruby.txt) be rewritten in the event of a > compromise of the rails key that signed it (in the event of t=1)? > * There is scope in the metadata, for two roles to have the same paths or > path patterns. Is it recommended such an event be a validation error? > > Many thanks, > > James > > > > On 15 February 2013 00:39, Trishank Karthik Kuppusamy < > tk47 at students.poly.edu> wrote: > >> Hello rubygems, >> >> We hear from Donald Stufft at the Python Catalog-SIG mailing list that you >> are interested in securing rubygems. >> >> We are The Update Framework (TUF) project [https://www.updateframework.** >> com/ ], and we would like to help Ruby >> and Python folks to help secure their package managers. >> >> TUF is a framework designed by computer scientists from NYU-Poly, >> University of Washington and the Tor project to help solve some of the more >> common problems with securing software updaters. >> >> Here are some papers we wrote on the subject: >> >> https://isis.poly.edu/~**jcappos/papers/cappos_mirror_**ccs_08.pdf >> https://isis.poly.edu/~**jcappos/papers/samuel_tuf_ccs_**2010.pdf >> >> What we would like to do is to help the rubygems community to understand >> how you may use TUF to secure your package manager with security designed >> carefully and intrinsically, so that you do not have to worry about the >> most common security issues. >> >> Donald, havenwood and raggi introduced us to the Rubygems Trust Model >> document [http://goo.gl/ybFIO], and we will comment on it as soon as we >> find the time. In fact, we are going to have a TUF hackathon here in a few >> hours, and we hope to make more progress on these matters soon enough. >> >> Please feel free to reach out to us with your questions! >> >> Thanks, >> Trishank >> >> ______________________________**_________________ >> RubyGems-Developers mailing list >> http://rubyforge.org/projects/**rubygems >> RubyGems-Developers at rubyforge.**org >> http://rubyforge.org/mailman/**listinfo/rubygems-developers >> > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From jcappos at poly.edu Sat Feb 16 01:10:04 2013 From: jcappos at poly.edu (Justin Cappos) Date: Fri, 15 Feb 2013 20:10:04 -0500 Subject: Hello from the TUF team In-Reply-To: <511ED60B.9040202@students.poly.edu> References: <511DF459.8010500@students.poly.edu> <511ED60B.9040202@students.poly.edu> Message-ID: Just to be a little more specific on our timeline, we have some grant deadlines and paper deadlines all coming up on Thursday of next week. We'll try to get back to you with answers after that. You're asking a lot of good questions that I can't necessarily give off-the-cuff answers to. I need to take time and really digest Ruby's use case and think through my answers. Sorry for the delay! Thanks, Justin On Fri, Feb 15, 2013 at 7:42 PM, Trishank Karthik Kuppusamy < tk47 at students.poly.edu> wrote: > Hello James, > > Thanks very much for your email. I just realized that I forgot to copy > my advisor and one of the primary designers of the TUF framework, Prof. > Justin Cappos. > > We are currently under some intense deadlines, but we will strive to get > back to you as soon as possible. Thanks in advance for your patience! > > With best regards, > Trishank > > On 02/15/2013 07:16 PM, James Tucker wrote: > > Trishank, > > > > Thank you for stopping by and offering your assistance, I really > appreciate > > it. > > > > I have been digesting the Survivable Key Compromise paper, spec and > > implementation, and it very much maps to my major concerns for the > Rubygems > > system; it is so far the first proposal I have seen that appears to be > > close to complete. > > > > I still need more time to digest everything fully, but in the meantime I > > have some questions already (some of which may be born of > > misunderstandings, so your patience is appreciated): > > > > * What are your recommendations for the targets/* topology? > > - If we use simply gem names (not full name-version-platform tuples or > > strings), then I think the revocation model requires a rewrite of a whole > > target metadata be rewritten after target key compromise. This may be > > acceptable, however, > > - If we use targets/gemname/version-platform then we can rewrite > > targets/gemname.txt to disallow future publishing using compromised keys, > > but existing (non-malicious) gemname/version-platform.txt remain valid. > Is > > this the case, and is this safe? (assuming all other standard roles) > > - The paper loosely suggests in the language having these map to > files, > > which makes sense, but is somewhere between the above two options, and > > requires new targets to be issued regularly (maybe that is a good > thing?). > > - There are some scaling concerns with each different approach that we > > may need to consider. In any of the latter cases, release.txt will > continue > > to grow fast, although gzip and such will also continue to work well. At > > some point though, parsing becomes slow and/or memory intensive. > > * The paper mentions the metadata files for 8000 PyPI binaries reaching > > several megabytes. We have considerably more data than this, as such we > may > > very much need to alter both the data format, and possibly slice the > files > > into pieces. Do you have any particular recommendations in this area? Are > > there non-obvious key security considerations here (I think most are > > covered by timestamp.txt and release.txt)? > > * Given the existence of the release and higher level targets roles in > > this system, do you still strongly recommend leaf-targets (e.g. > > targets/gems/rails-3.2.0-ruby.txt) be rewritten in the event of a > > compromise of the rails key that signed it (in the event of t=1)? > > * There is scope in the metadata, for two roles to have the same paths > or > > path patterns. Is it recommended such an event be a validation error? > > > > Many thanks, > > > > James > > > > > > > > On 15 February 2013 00:39, Trishank Karthik Kuppusamy < > > tk47 at students.poly.edu> wrote: > > > >> Hello rubygems, > >> > >> We hear from Donald Stufft at the Python Catalog-SIG mailing list that > you > >> are interested in securing rubygems. > >> > >> We are The Update Framework (TUF) project [https://www.updateframework. > ** > >> com/ ], and we would like to help > Ruby > >> and Python folks to help secure their package managers. > >> > >> TUF is a framework designed by computer scientists from NYU-Poly, > >> University of Washington and the Tor project to help solve some of the > more > >> common problems with securing software updaters. > >> > >> Here are some papers we wrote on the subject: > >> > >> https://isis.poly.edu/~**jcappos/papers/cappos_mirror_**ccs_08.pdf< > https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf> > >> https://isis.poly.edu/~**jcappos/papers/samuel_tuf_ccs_**2010.pdf< > https://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf> > >> > >> What we would like to do is to help the rubygems community to understand > >> how you may use TUF to secure your package manager with security > designed > >> carefully and intrinsically, so that you do not have to worry about the > >> most common security issues. > >> > >> Donald, havenwood and raggi introduced us to the Rubygems Trust Model > >> document [http://goo.gl/ybFIO], and we will comment on it as soon as we > >> find the time. In fact, we are going to have a TUF hackathon here in a > few > >> hours, and we hope to make more progress on these matters soon enough. > >> > >> Please feel free to reach out to us with your questions! > >> > >> Thanks, > >> Trishank > >> > >> ______________________________**_________________ > >> RubyGems-Developers mailing list > >> http://rubyforge.org/projects/**rubygems< > http://rubyforge.org/projects/rubygems> > >> RubyGems-Developers at rubyforge.**org > >> http://rubyforge.org/mailman/**listinfo/rubygems-developers< > http://rubyforge.org/mailman/listinfo/rubygems-developers> > >> > > _______________________________________________ > > RubyGems-Developers mailing list > > http://rubyforge.org/projects/rubygems > > RubyGems-Developers at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > > > > From jcappos at poly.edu Fri Feb 22 21:25:09 2013 From: jcappos at poly.edu (Justin Cappos) Date: Fri, 22 Feb 2013 16:25:09 -0500 Subject: Hello from the TUF team In-Reply-To: References: <511DF459.8010500@students.poly.edu> Message-ID: Okay, thank you for being patient. My deadlines passed last night and I'm starting to dig out... * What are your recommendations for the targets/* topology? > - If we use simply gem names (not full name-version-platform tuples or > strings), then I think the revocation model requires a rewrite of a whole > target metadata be rewritten after target key compromise. This may be > acceptable, however, > Yes, you may need to do this in this case. In our thinking, a targets role would map to a project. So the root would end up revoking a key from a specific target and the list of trusted target keys would change. If I'm the developer of a different target, my key / targets.txt does not need to change. > - If we use targets/gemname/version-platform then we can rewrite > targets/gemname.txt to disallow future publishing using compromised keys, > but existing (non-malicious) gemname/version-platform.txt remain valid. Is > this the case, and is this safe? (assuming all other standard roles) > I suppose you could try to do things in this way (I don't know if it is safe). However, I think the more natural way to do what you want to do is make it so that older packages (only) are still trusted even if the key is later compromised. Instead, I would recommend revoking the compromised targets key and then signing the old packages with the new key. (Apologies if I'm misunderstanding this.) > - The paper loosely suggests in the language having these map to files, > which makes sense, but is somewhere between the above two options, and > requires new targets to be issued regularly (maybe that is a good thing?). > You can require targets to be reissued using TUF by setting expirations appropriately. Short expiration would require these keys to be online (or close to it). If you do this, you're trading timeliness (how long can someone get told an old version is current) for risk (how easy is it for someone to steal your key). > - There are some scaling concerns with each different approach that we > may need to consider. In any of the latter cases, release.txt will continue > to grow fast, although gzip and such will also continue to work well. At > some point though, parsing becomes slow and/or memory intensive. * The paper mentions the metadata files for 8000 PyPI binaries reaching > several megabytes. We have considerably more data than this, as such we may > very much need to alter both the data format, and possibly slice the files > into pieces. Do you have any particular recommendations in this area? Are > there non-obvious key security considerations here (I think most are > covered by timestamp.txt and release.txt)? > You can split things up via delegating trust. There isn't just one targets file which will simplify this tremendously. > * Given the existence of the release and higher level targets roles in > this system, do you still strongly recommend leaf-targets (e.g. > targets/gems/rails-3.2.0-ruby.txt) be rewritten in the event of a > compromise of the rails key that signed it (in the event of t=1)? > yes, absolutely. If compromise means that someone else has the rails key, they can act as a MITM for anyone getting updates and compromise all users that retrieve the package. Compromises should be rare, or at least much rarer than normal updates, so this shouldn't be a major performance or scalability worry. > * There is scope in the metadata, for two roles to have the same paths or > path patterns. Is it recommended such an event be a validation error? > Is there a reason why you would logically want this to occur? I would say that it seems both potentially useful and suspicious. Raising an error, but having a flag to override and continue may make sense. (I'm just pulling this out of the air though.) In the next week or so, we can get a setup together where you can play more with TUF and see how it works in different scenarios yourselves. We're starting to get into discussion with the PyPI folks too so our time is a little divided, but we'll do what we can to show you what a realistic deployment might look like. Thanks, Justin P.S. If you'd like to open your google doc for comments, I have a few other things I could mention there.