5

One of the options for security.txt is to include a reference to a PGP key for use when reporting vulnerabilities in a private, secure way. It makes perfect sense to me for a researcher to use PGP to encrypt a message to report a vulnerability.

But what about the business on the other end? How should they safely implement a PGP key for such reports?

One option would be to simply use one person's personal (or, more likely, a one-off created exclusively for this purpose) key, but then there is a risk that the person will die (unavailability) or turn rogue (DOS/MitM reports).

Another option would be to generate a key pair for this purpose and share it among a group of trusted individuals. This solves the "death" problem and the DOS problem, but it expands the risk of one person receiving a report and doing something nefarious with it.

A shared key also means that any private-keyholder can issue a message "as" that identity. This can probably be solved by making it clear that the key is for "receipt-only" when minting it.

Is there a standard and/or safe way to do things like this?

3

One way I would suggest is sharing the Encryption subkey among the members of the security team, but not the Certify ("master") nor Sign subkeys. This way every member of the team can decrypt the messages sent to the email address listed in security.txt, but not send signed email back. The Certify and Sign subkeys can be kept on a vault system, which can be used for the purposes of the following:

  • signing official communication
  • revoking the shared Encryption subkey and creating a new one in case a member of the group leaves

The vault system can have those subkeys on some kind of HSM that can't be physically removed; similarly, either the system itself or the room where it's kept must require multiple people present in order to operate.

  • Interesting, I hadn't thought of using the key-capabilities as a way to remove e.g. signing capabilities. That's a really great solution. – Christopher Schultz Sep 5 '18 at 20:40
  • So... how does one share only the subkey of a GPG key, and what does the passphrase become? Can the passphrase be changed per-export of a subkey? I've never done anything like this before... only vanilla GPG keys where one person has control of the whole key. Can you add some details to your answer? – Christopher Schultz Sep 5 '18 at 20:48
  • @ChristopherSchultz I can't really, since that would basically require writing a 50-page guide. I suggest you follow one of the subkey guides (e.g. here's mine: github.com/lfit/itpol/blob/master/protecting-code-integrity.md) and adapt it to your needs. – mricon Sep 5 '18 at 20:55
  • The reference to the subkeys guide is, I think, enough detail for this forum. – Christopher Schultz Sep 6 '18 at 13:36
2

Great question.

As always, it comes down to your specific threat model.

You bring up a number of interesting ones (e.g. insider, rogue, death, etc...)

For most folks using security.txt, the question mostly stops at "How do I let researchers communicate securely with my company" and the assumption is that the business has addressed these questions of access to the private key however makes sense for their particular risk tolerance.

If only one person has the job of responding to security reports, their key, generated for this purpose is fine, and the business accepts the kinds of risks you outline for a single user. If it's a team, then by definition the team all have access, and you face the other class of risks.

One size won't fit all. Were I designing something, and asked to consider all of the threats you outline, I'd go with something like the following:

Private key of the PGP pair stored in AWS Secrets Manager

https://aws.amazon.com/secrets-manager/

and access managed through Roles and Policies via the Key Management Service

https://aws.amazon.com/kms/

This puts the business in charge of defining the roles and policies and access controls appropriate to their risk profile, and the threats they care about.

No one person, or even group of people control "the private key" but access to use it can be granted and revoked centrally, by adding and removing permissions according to the organization's rules.

This would also give you an audit trail of which member of a group used the key to respond to a specific request.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.