itpol/trusted-team-communication.md

Trusted Team Communication

Establishing trusted communication between members of your team is paramount not only to avoid potential security problems associated with phishing and impersonation, but also to make it possible to exchange potentially sensitive information without having to rely on half-baked or insecure channels.

You should establish trusted communication guidelines as early as possible, before you put down any code or bring up any servers.

There are 3 core technologies you will be using:

• OpenPGP, favored in the open-source world
• X.509 and S/MIME, favored in the corporate world
• OTR, which is largely limited to instant messaging

In this document we'll be looking at each technology purely in terms of securing communication between team members and will not judge them on any other merits. We'll look at several core topics:

1. Trusting emails from your teammates
2. Trusting your IM sessions
3. Trusting your git commits
4. Releasing code trusted by the community

Trusting email

OpenPGP vs S/MIME

There are advantages and disadvantages to both, but if you're doing open-source development at all, chances are that OpenPGP will be a better solution for you.

S/MIME and OpenPGP do similar things for securing communication, but they differ in the way they delegate trust. X.509 relies on Certification Authorities to indicate trusted keys, while OpenPGP relies on the Web of Trust to accomplish the same goal.

Main upsides of S/MIME

• Your team can choose to rely on global certification authorities to certify each teammate's identity, without bothering with setting up your own CA infrastructure or dealing with establishing OpenPGP's web of trust.
• S/MIME is very well supported in desktop software, therefore barriers to entry and use will be lower than with OpenPGP.
• Portable devices tend to have decent mail client support for S/MIME, allowing to both read and write secure emails.

Main downsides of S/MIME

• Has poor acceptance in the open-source world, which relies a lot heavier on OpenPGP standards. If you will need to communicate with other teams of developers across the open-source realm, chances are they will not be using S/MIME and may ask you to to use OpenPGP instead.
• Many globally trusted CAs only need someone to verify that they can receive email sent to the email address being certified. If your team relies on external CAs, your trusted communication will be as weak as the password on some developer's inbox.
• If you do NOT rely on external CAs, then you will need to bring up and maintain your own CA, which means extra work to ensure its security, plus you will be placing ultimate trust into the person or persons maintaining your CA infrastructure.

Main upsides of OpenPGP

• Does not rely on external trust entities. Every member of the project will maintain their own web of trust. You do not have to place ultimate trust into the person who runs your CA infrastructure.
• OpenPGP is well accepted across open-source development teams for securing email communication, to a much greater degree than S/MIME.
• OpenPGP is used in many free software areas beyond just securing email, for example to create signed git tags and commits and to produce trusted software releases via detached OpenPGP signatures.
• OpenPGP email has decent support in most desktop email clients, either as a core feature, or as an add-on.

Main downsides of OpenPGP

• Few developers understand how the web of trust works, and even fewer managers do.
• Webs of trust are hard to get going if your team members are geographically dispersed.
• OpenPGP tools are difficult to learn and use, even by the technically inclined and educated.
• There are almost no mail clients for portable devices that support reading or sending OpenPGP-encrypted mail. Those that do support OpenPGP have questionable GUI or awkward UX.

Understanding the OpenPGP Web of Trust

OpenPGP is only a useful tool when everyone involved in team communication understands how the web of trust works. Please see the following links for a couple of detailed explanations:

• PGP Web of Trust: Core Concepts Behind Trusted Communication
• PGP Web of Trust: How does it work?

Using the Web of Trust in your team

Once you understand the core concepts behind the OpenPGP Web of Trust, you'll have to actively enforce and maintain it. Nobody should get access to your infrastructure or be allowed to push code without being part of your web of trust.

Spinning the web

Web of trust is established via signing your teammate's keys and assigning them trust. The protocol calls for an in-person meeting where both parties present documents validating their identities and exchange key fingerprints. Here's an in-depth document describing the procedure:

• https://www.phildev.net/pgp/gpgsigning.html

Yes, but what if they are 12 timezones away?

It is easy to set up a video session and have them show their identification papers to the camera. Obviously, this process is easier to subvert than with person-to-person meetings, but not by much. Unless you are an expert at identifying various foreign or out-of-state identification documents, it would be easy for an attacker to create a convincing driver's license that you've never seen before.

At any rate, this protocol is less about identifying a person's state-issued identity, and more about creating a communication channel that is equally as trusted as a video session, a phone call, or an in-person meeting. If you are comfortable enough that the person at the other end of your video chat is who they say they are, and that they belong on your team, then you should feel comfortable enough to sign their key.

Keysigning parties

Chances are, large portions of your team will be attending the same events or even specially-organized hackfests. You should use this opportunity to strengthen your web of trust by holding "keysigning parties."

Sending trusted emails

When to sign

There are two distinct operations with each outgoing email, both for S/MIME and OpenPGP:

• Sign, which signs your message in a way that proves to the recipient that you were the one who sent it and that the message was not tampered with in transit.
• Encrypt, which encrypts your message so the contents cannot be read in transit by mail relays.

Best practice is to always sign your messages, unless you have a good reason not to (usually for plausible deniability reasons). For OpenPGP, the recommended mechanism for signatures is MIME-signing, as inline-signing tends to clutter the message with OpenPGP headers and footers, which may annoy your correspondents.

When to encrypt

You should only need to encrypt messages actually containing sensitive data that you do not wish others to know about (passwords and other account information, confidential details that should not leak to the public, etc). Chances are, your recipient has only configured their mail client to read encrypted emails on their workstation and not on their mobile device, so adopting a policy of "always encrypt by default" may annoy your recipients, especially if the contents are not confidential or sensitive (patches, lunch invitations, bikeshedding discussions, etc).

When encrypting, you should also sign the message (unless you do need that plausible deniability). Simply encrypting the message does not make it trusted, as an enemy is also perfectly capable of encrypting a message to someone's public key and faking the "From:" header.

If you receive an encrypted message that isn't also signed, be extra wary, as it may be a spear phishing attempt.

Trusting IM sessions

Almost all development teams use some kind of instant messaging solution in order to coordinate their activities in real time -- be it IRC, Hangouts, Slack, or any number of other means. If critical decisions are taken during such meetings, then you should ensure that they happen over trusted communication channels.

One-on-one chat

There is no lack of clients for instant messaging, and while most of them will encrypt your conversations from the client to the server, the contents will still be seen in cleartext by the service providers, and most likely logged in some fashion. In some cases, these conversations can be later retrieved by attackers, so if you need to ensure that the provider does not know about the contents of your messages, you need to communicate via a protocol that offers point-to-point encryption and verification.

The only widely used cross-client protocol for securing end-to-end communication is Off-The-Record messaging (OTR). It is easy to set up in most desktop clients, and there are several mobile clients available for communicating on the go (just search for "OTR" and you should be able to find them).

As with email, merely encrypting your connections does nothing to assure that the person you are talking to is who they claim they are. You will need to verify your contacts via OTR's excellent verification protocols before you trust the chat session to be secure.

You may choose not to bother with point-to-point encryption for chat sessions with your team members, but you should firmly establish as a matter of policy what kind of conversations are suitable for IM, and what should be only sent via secured email.

NOTE: Google has, confusingly, called something else "Off-The-Record" conversations, which merely exclude your chat sessions from being logged in your inbox, but they are not point-to-point encrypted, and are still known to Google.

Group chat

There is currently no widely used mechanisms to set up perfectly secure multi-user group chat sessions with point-to-point encryption. You may sidestep this limitation by running your own multi-user chat server (IRC, Jabber, HipChat) and requiring that everyone both authenticates and connects via a trusted protocol (both IRC and Jabber offer TLS), but you will still have to trust the administrators of that server not to log or misuse your data.

Alternatively, simply establish a firm policy that only public conversations are allowed in group chat and everything else should happen over secure email exchange.

Trusting git commits

You will most likely be using git in some fashion -- be it to track your code, your system's config management tree, etc. You can use OpenPGP to add a layer of trust to your tags and commits.

Signed-off-by's

First of all, Signed commits shouldn't be confused with Signed-off-by: lines in git commit messages. Despite sounding similar, the Signed-off-by: entries actually offer no guarantees that they were inserted there by those people. These are merely a way to track code provenance and code review chains, but offer no assurances.

Signed tags and commits

You can, however, create cryptographic signatures when committing code to a git repository, or when creating a tag, as a way to assure people who will be pulling these commits that the repository they are pulling from has not been tampered with by an attacker.

The easiest is to just sign the tags -- which will help, however may not be sufficient depending on the nature of your project. More recent versions of git have introduced a way to sign each individual commit, which makes it significantly more difficult for an attacker to sneak in a malicious commit into someone's tree. However, without proper checking done by code maintainers, this will only make it tamper-evident, and not tamper-proof (in other words, someone may sneak in a malicious commit, and the most you'll be able to do is exonerate a trusted developer, but not prevent the compromise from happening).

Signed commits also make merges and other branch operations more complicated, but not insurmountable. Please see the following in-depth document to learn more about how you can organize your workflow around signed git commits:

• http://mikegerwitz.com/papers/git-horror-story

Releasing code trusted by the community

If you produce open-source code, you have to establish a way for the community to validate that the releases you put forward are trusted and have not been tampered with by attackers. If you are relying on the OpenPGP web of trust, you should designate one or several "release engineers" who will be responsible for creating detached OpenPGP signatures and making them available at the same download location as the rest of the code.

Alternatively, you may choose to create a separate key that will be used for signing the releases, but in this case you should get several core members of your team to sign that key to indicate that it should be trusted by others. Special care should be taken to ensure that the release-signing key is kept secure, and preferably protected by a passphrase. If you choose to make it part of an automated process, make sure you don't expose the key to external entities.

To create a detached signature for a tarball, use the following command:

gpg -ba tarball.tar.gz

This will create a file called tarball.tar.gz.asc which should be uploaded to the release server.

Alternatively, if you only release via git, you may simply use signed git tags and let packagers create their own tarballs from git.

Securing infrastructure access

You should rely on these trusted communication channels to grant access to your infrastructure -- be it shell access to the servers, git-over-ssh access with public keys, credentials to access VPN or shared services, etc.

Most commonly, this will entail having someone send in their ssh public key, which should always be sent via signed email (no sense encrypting it, though).

Using PGP keys with SSH

Alternatively, you can use GnuPG with ssh to turn an OpenPGP Auth key into an ssh private key. We publish a detailed guide on how to do that using either a smartcard reader or a Yubikey NEO.

This will offer an extra benefit of adding 2-factor authentication to your infrastructure access (yubikeys and smartcards are "something you have").

Checklist

Here is a convenient checklist for your team to ensure that you have all these aspects covered.

• Every member of the team has a trusted PKI certificate

  • If using X.509, the certificate is issued by a CA trusted by all members of the team
  • If using OpenPGP, each team member's key carries at least one, preferably three signatures from other members of the team

• Members of the team are able to send and receive encrypted, signed email

  • Members of the team understand the necessity behind email security, and agree to it as a requirement for discussing sensitive subjects
  • Members of the team know how to verify cryptographic signatures to establish that the email came from a trusted source and has not been altered in transit

• The team uses an agreed-upon IM client and protocol for secure, trusted real-time communication with point-to-point encryption

• The team uses an agreed-upon group chat mechanism and understands its limitations and security risks

• Members of the team know which subjects should be discussed only via trusted and encrypted channels (security, accounts, confidential data, etc), and never via public channels such as group chat or untrusted IM and email

• The team has an established workflow that makes use of cryptographic features in git

• The project has a defined mechanism for providing trusted releases either via detached OpenPGP signatures, or via signed git tags

• Access to infrastructure is granted via trusted communication channels

License

This work is licensed under a [Creative Commons Attribution-ShareAlike 4.0 International License][0].