4 ms·

I had to deep dive into the details of PGP in order to setup a trusted chain of artifacts in our internal CI system, all the way to published artifacts on Maven

by brabel 5y ago

I had to deep dive into the details of PGP in order to setup a trusted chain of artifacts in our internal CI system, all the way to published artifacts on Maven Central (the Java defacto main package repository)... it was a tough ride, as PGP is not very simple for end users, even with all the tooing they've created. The GNU PGP utility[1] is pretty easy to use on the terminal, and the UI version[2] actually makes it even easier to sign/encrypt/verify stuff and manage your local keys (also to integrate with email clients, which seems to be the most common use of PGP)... The problem is just that understanding exactly what a key is for, why I need a sub-key, how to move keys between CI agents securely, how to rotate keys, when to use a keyserver, where to store my master key, how to trust someone else's keys (or sub-keys?!) and so on... is really difficult and there's no one simple answer. Howver, I'm afraid these problems are independent of PGP itself: you'll have these problems whatever system you use, as the "key" (pun intended) issue is not the technology you use, but the public-key intfrastructure problem[3]. In summary: how do you trust someone else's public key without phisically having access to it directly from them? If you get the key online, wow can you know that the source is definitely reliable and the channel of communication has not been compromised? On the Web, Certificate Authorities (CA) play the role of vouching for someone's keys through certificate signing. But this is not an appropriate model for things like personal keys, and it introduces its own issues as well[4]. In PGP, the solution seems to be Key Signing Parties[5]! Sounds fun, but also completely unfeasible on the scale of the web. I don't know how Signal and other new solutions fair compared to PGP on these problems, but would be happy to know if anyone has any advice. [1] https://gnupg.org/ https://gnupg.org/ [2] https://gpgtools.org/ https://gpgtools.org/ [3] https://en.wikipedia.org/wiki/Public_key_infrastructure https://en.wikipedia.org/wiki/Public_key_infrastructure [4] https://gemini.circumlunar.space/docs/tls-tutorial.gmi https://gemini.circumlunar.space/docs/tls-tutorial.gmi [5] https://en.wikipedia.org/wiki/Key_signing_party https://en.wikipedia.org/wiki/Key_signing_party

georgyo 5y ago
I am a huge fan of OpenPGP, but the Web of Trust is never going mainstream. However, I do think things like OpenPGP-CA are going to make things _a lot_ easier for everyone. And I really hope that it catches on: https://openpgp-ca.org/blog/openpgp_ca_0_10_1/ https://openpgp-ca.org/blog/openpgp_ca_0_10_1/
- mxxc 5y ago
  i don't think the web of trust as a "first principle" is necessarily a good thing. it made sense a while ago perhaps, but nowadays it's just overkill. there are several use cases where either you want to keep a closed loop on everything (e.g. you intend keys to circulate only within your company), or very very different cases where there is value in keys that are valid only for the sake of a chat: it doesn't need to be anything illegal, but if two parties negotiate a message exchange and there is trust in the fact that the very first key exchange is secure, you only need the subsequent messages to match the first key pair. after that, the keys can safely be destroyed, not added to your respective keyrings and signed on the public internet.
  - taeric 5y ago
    I'm not following. How does one build the trust in the first key exchange in a way that isn't building a web of trust? And your first example is just a small web of trust for the closed loop. That is, you are still leaning heavily on it as a first class thing. If the argument is that we don't need a global web of trust that everyone is always a party of, I can agree with that.
    - mxxc 5y ago
      i think once most PGP implementations rely on public key servers + key signing a "global web of trust" is a first principle, while the "small web of trust" really isn't
      - taeric 5y ago
        Apologies on missing this. I agree that "global web of trust" is a bit tough. And I agree that reliance on far reaching trust is essentially that. The idea, though, seems to still hinge on the same concepts, whether writ large or small.
er4hn 5y ago
I don't have a general solution, but the following works well for signed commits at my workplace (disclaimer - all comments and thoughts my own): * IT, authority of all secrets, owns the primary keys for all employees. * Each employee has a code signing subkey generated which is signed as trusted by an org-wide key. * The employee is given the private part of their code signing subkey. * The public parts of the org-wide key and employee code signing keys are made available to everyone via a keyserver. Now all commits can be forced to be signed, can be validated by checking that the org-wide key trusts the key, and be checked over time by using the keyserver. IT, being responsible for corporate security, manages the secret bits without involving engineering. Keys can be rotated on demand, when laptops are lost, and revoked when employees leave. It also resolves all the issues with each person managing their own primary key and dealing with the web of trust problems associated with that.
dale_glass 5y ago
> In summary: how do you trust someone else's public key without phisically having access to it directly from them? You obtain the key's fingerprint in a secure manner from them. They tell you directly, as in face-to-face, give you a business card where they printed the fingerprint, etc. This is not a problem that's solvable automatically. Depending on your scenario, you may be more or less paranoid. Eg, you might sign your friend's key with minimum fuss, because you've known him since you were 12, and that's that. If it's a facility dealing with nuclear weapons then you probably ask for multiple forms of ID, a background check, and interview other people to be really sure this person is the right one to trust. Once that is done, you sign their key with your. This can be uploaded to a keyserver. After that you don't need physical presence, because you trust your key, and that certifies what you trust unambigiously. > If you get the key online, wow can you know that the source is definitely reliable and the channel of communication has not been compromised? You sign their key yourself, or rely on somebody else's signature. In a company, you'd have say, the sysadmin in charge of that. * Alice is the sysadmin at Acme. * Bob gets hired * Bob is given a list of procedures to follow at the company, which include generating a key on his laptop, noting down the fingerprint somewhere (by hand, or printing it and verifying that just in case), and bringing it to Alice. * Alice is trusting that the company's HR department really hired Bob Smith and not some impostor, and that somebody checked his ID. Alice then verifies the fingerprint to make sure she really has Bob's correct key. * Alice then signs Bob's key with Acme's key. Bob in turn signs Acme's company key with the same process (obtaining the fingerprint from Alice). * At that point, Carol can trust Bob's key because she went through the same process, trusts Acme's key, so can establish the chain of trust of Carol -> Acme -> Bob.
- pnutjam 5y ago
  https://keybase.io/ https://keybase.io/ This is designed to handle key trust.
  - sleepybrett 5y ago
    ... and they got bought and it's not getting much work (if any at all) put into it. Shame.
- 5y ago
lifeisstillgood 5y ago
Can you tell us more about the key management you sovled for the internal CI? Sounds like you needed a CA?
- brabel 5y ago
  We have a lot of different repositories and internal as well as open source libraries we maintain. We publish things to our internal Nexus when it's internal, and Maven Central when it's public. Because our product is used in high security scenarios, we needed a way to verify that every artifact we download (from the repos mentioned above) during the CI build is signed to guarantee that if our repositories have been compromised, we won't end up with compromised artifacts being brough into our product anyway (because the signing keys are kept securely in the CI agents, which we trust much more than the repositories as, for example, they are not exposed on the Internet). So we needed signing keys in the CI agents, and we needed verification public keys (that we trust) in the releaser "machine" (which downloads everything and puts it together for the final build). We also needed the releaser machine to re-sign everything for publication on Maven Central and our distribution website, which our customers use to download it from and can also verify our signature on every artifact. You're right that a sort of CA could help, but as I understand it, with PGP you don't need that in our case because all keys are controlled by us, so it's easy for us to trust keys and generate new keys as we spawn new agents. This means our CI master has to have the master key, otherwise it couldn't sign other agent's keys... which is a bit of a problem but we think it's still fine because our master CI is well protected (and if that gets compromised, everything else falls anyway). It's been working well, but it was complicated to setup and it's a bit inconvenient to use when we do a full product release (it involves updating all keys locally as they're generated for CIs as I mentioned)...

by brabel 5y ago

georgyo 5y ago

I am a huge fan of OpenPGP, but the Web of Trust is never going mainstream. However, I do think things like OpenPGP-CA are going to make things _a lot_ easier for everyone. And I really hope that it catches on: https://openpgp-ca.org/blog/openpgp_ca_0_10_1/ https://openpgp-ca.org/blog/openpgp_ca_0_10_1/

mxxc 5y ago
i don't think the web of trust as a "first principle" is necessarily a good thing. it made sense a while ago perhaps, but nowadays it's just overkill. there are several use cases where either you want to keep a closed loop on everything (e.g. you intend keys to circulate only within your company), or very very different cases where there is value in keys that are valid only for the sake of a chat: it doesn't need to be anything illegal, but if two parties negotiate a message exchange and there is trust in the fact that the very first key exchange is secure, you only need the subsequent messages to match the first key pair. after that, the keys can safely be destroyed, not added to your respective keyrings and signed on the public internet.
- taeric 5y ago
  I'm not following. How does one build the trust in the first key exchange in a way that isn't building a web of trust? And your first example is just a small web of trust for the closed loop. That is, you are still leaning heavily on it as a first class thing. If the argument is that we don't need a global web of trust that everyone is always a party of, I can agree with that.
  - mxxc 5y ago
    i think once most PGP implementations rely on public key servers + key signing a "global web of trust" is a first principle, while the "small web of trust" really isn't
    - taeric 5y ago
      Apologies on missing this. I agree that "global web of trust" is a bit tough. And I agree that reliance on far reaching trust is essentially that. The idea, though, seems to still hinge on the same concepts, whether writ large or small.

er4hn 5y ago

I don't have a general solution, but the following works well for signed commits at my workplace (disclaimer - all comments and thoughts my own): * IT, authority of all secrets, owns the primary keys for all employees. * Each employee has a code signing subkey generated which is signed as trusted by an org-wide key. * The employee is given the private part of their code signing subkey. * The public parts of the org-wide key and employee code signing keys are made available to everyone via a keyserver. Now all commits can be forced to be signed, can be validated by checking that the org-wide key trusts the key, and be checked over time by using the keyserver. IT, being responsible for corporate security, manages the secret bits without involving engineering. Keys can be rotated on demand, when laptops are lost, and revoked when employees leave. It also resolves all the issues with each person managing their own primary key and dealing with the web of trust problems associated with that.

dale_glass 5y ago

> In summary: how do you trust someone else's public key without phisically having access to it directly from them? You obtain the key's fingerprint in a secure manner from them. They tell you directly, as in face-to-face, give you a business card where they printed the fingerprint, etc. This is not a problem that's solvable automatically. Depending on your scenario, you may be more or less paranoid. Eg, you might sign your friend's key with minimum fuss, because you've known him since you were 12, and that's that. If it's a facility dealing with nuclear weapons then you probably ask for multiple forms of ID, a background check, and interview other people to be really sure this person is the right one to trust. Once that is done, you sign their key with your. This can be uploaded to a keyserver. After that you don't need physical presence, because you trust your key, and that certifies what you trust unambigiously. > If you get the key online, wow can you know that the source is definitely reliable and the channel of communication has not been compromised? You sign their key yourself, or rely on somebody else's signature. In a company, you'd have say, the sysadmin in charge of that. * Alice is the sysadmin at Acme. * Bob gets hired * Bob is given a list of procedures to follow at the company, which include generating a key on his laptop, noting down the fingerprint somewhere (by hand, or printing it and verifying that just in case), and bringing it to Alice. * Alice is trusting that the company's HR department really hired Bob Smith and not some impostor, and that somebody checked his ID. Alice then verifies the fingerprint to make sure she really has Bob's correct key. * Alice then signs Bob's key with Acme's key. Bob in turn signs Acme's company key with the same process (obtaining the fingerprint from Alice). * At that point, Carol can trust Bob's key because she went through the same process, trusts Acme's key, so can establish the chain of trust of Carol -> Acme -> Bob.

pnutjam 5y ago
https://keybase.io/ https://keybase.io/ This is designed to handle key trust.
- sleepybrett 5y ago
  ... and they got bought and it's not getting much work (if any at all) put into it. Shame.
5y ago

lifeisstillgood 5y ago

Can you tell us more about the key management you sovled for the internal CI? Sounds like you needed a CA?

brabel 5y ago
We have a lot of different repositories and internal as well as open source libraries we maintain. We publish things to our internal Nexus when it's internal, and Maven Central when it's public. Because our product is used in high security scenarios, we needed a way to verify that every artifact we download (from the repos mentioned above) during the CI build is signed to guarantee that if our repositories have been compromised, we won't end up with compromised artifacts being brough into our product anyway (because the signing keys are kept securely in the CI agents, which we trust much more than the repositories as, for example, they are not exposed on the Internet). So we needed signing keys in the CI agents, and we needed verification public keys (that we trust) in the releaser "machine" (which downloads everything and puts it together for the final build). We also needed the releaser machine to re-sign everything for publication on Maven Central and our distribution website, which our customers use to download it from and can also verify our signature on every artifact. You're right that a sort of CA could help, but as I understand it, with PGP you don't need that in our case because all keys are controlled by us, so it's easy for us to trust keys and generate new keys as we spawn new agents. This means our CI master has to have the master key, otherwise it couldn't sign other agent's keys... which is a bit of a problem but we think it's still fine because our master CI is well protected (and if that gets compromised, everything else falls anyway). It's been working well, but it was complicated to setup and it's a bit inconvenient to use when we do a full product release (it involves updating all keys locally as they're generated for CIs as I mentioned)...