Signs of Triviality

May 18th, 2021

This document is intended to help you decide how to share confidential information with others. It describes in some detail the various trade-offs, assumptions, and risks associated with each approach.

If all you want is a quick chart to tell you what to use, please see this image (OmniGraffle source).

If even that is too much work for you then:

• for secrets in use by services and systems, use your preferred Key Management System
• for secrets used by humans, use a team password manager

The best way to keep a secret a secret is to not share it. However, it is frequently necessary to share a secret with some parties: you may wish to provide a password to a social media account to the people in your organization responsible for managing that account, you may need to share an access token for an API with a team of developers, or you may need to provide a secret TLS key to all the systems serving HTTPS.

"No biggie," you say, "cryptography to the rescue! Rub some crypto on it, and it'll be secure!"

Yes biggie, things aren't quite that easy! So let's talk a bit about sharing secrets...

Table of Content

• Types of Secrets
• Secrecy in Transit and Protection at Rest
• Secret Revocation and Rotation
• Some Assumptions
• Sharing Options
  • Don't use a secret
  • Exchange secrets over the phone
  • Use your Key Management System
  • Use a shared key store or password manager vault
  • Use of client-side encrypted pastebin or similar service
  • Use of a restricted Google doc
  • Direct message in Slack or similar chat service
  • Signal / WhatsApp / Apple Message
  • Stashing a file on a shared computer with permissions
  • Sending encrypted data via email
  • Stashing an encrypted file in a code repository
  • Using a third-party storage service like Dropbox, Box, etc.

Types of Secrets

First, we have to realize that not all "secrets" are created equal. There are passwords, access tokens, private keys, one-time tokens, trade secrets, confidential data, and a million other cases in between. Some "secrets" can (easily) be changed once disclosed, others may automatically expire. Some secrets are used for authentication purposes (think passwords or API access tokens), others can be used by themselves (e.g., TLS certificate keys); some are intended for use by humans, others for use by computers.

All of these properties should influence how you approach sharing them: although there are methods that are reasonable for all types, you often can make tradeoff decisions if you understand what it is you're protecting from what specific threat (see also: this introduction to threat modeling).

To this end, a "secret" really is not all that different from any data: you always need to be conscious of who should have access to the data, to ensure that only those authenticated and authorized can gain and retain said access.

Secrecy in Transit and Protection at Rest

When we talk about "sharing secrets", we may focus primarily on the protection of the information in transit -- the secrecy or confidentiality guarantee provided by reasonable cryptography. But while that is an important aspect, there's more to it.

One fundamental implication of sharing a secret with somebody else is that you're effectively outsourcing the secrecy to the recipient. No matter how well you protect your secret, once you share it, it's only as secure as the other party keeps it.

Secondly, besides transmitting secrets between two (or more) parties, you, generally speaking, also have to store secrets. In practice, the way we store secrets exposes us to more risk of exposure than the way we transmit secrets.

"Three may keep a secret, if two of them are dead." -- Benjamin Franklin

Within the context of this document, there is some overlap between the secure transmission of a secret to another party and the protection of the secret at rest. After all, storing a secret really is just sharing a secret with your future self.

The discussion below will, however, not concern itself with how each individual party may store the secret data once they have gained access, and only focus on the act of sharing the data. That is, when we talk about encryption at rest, we only consider the intermediate storage, not whatever the recipient may do with the data.

Secret Revocation and Rotation

It often makes sense to consider access revocation for a secret. This plays an important role especially when the secret needs to be shared not with individual people, but with groups of people, possibly with fluctuating membership. That is, members of a group should be able to access all secrets for the group, and new members joining the group should have access to previously shared secrets, but members leaving the group should no longer retain access.

It is of course impossible to guarantee that a secret once shared is not duplicated elsewhere by the recipient(s), but you do want to avoid accidentally sharing an updated version with the no longer privileged user(s).

A common example here might be a corporate environment, where a user is granted access to a secret store, but once the user leaves the company or changes roles, that access is revoked. Even though the previously shared secrets still need to be rotated, any updated secrets must be unavailable to the user who left.

This is where role based access controls (RBAC) come into play, in turn mandating on-demand authentication.

Some Assumptions

Despite outsourcing the confidentiality of your secret to the best practices exercised by the people you are sharing the secret with, we will need a few basic assumptions to allow us to discuss which approaches to sharing might be suitable for which kinds of secrets.

Defining these assumptions helps clarify your threat model and hopefully make a more informed decision.

To begin, let us state that if an attacker compromises the device on which you are storing the secret (e.g., your laptop), then you lose. This is the case even if you are storing the secret in encrypted form, since to access it, you at some point have to decrypt it, at which point the attacker is assumed to have observed it as well. That is, a password manager, for example, cannot protect against an attacker with access to the device from which you access the password manager, regardless of whether the password manager stores secrets on the device or fetches them from e.g., cloud storage.

Secondly, we assume that the attacker is able to observe clear-text network traffic between you and the person you wish to share the secret with. (If they weren't, you could trivially share the secret.)

Thirdly, we assume that the party we are sharing the secret with will store it on their side using unknown (if any) protections. That is, if an attacker compromises the recipient's device, then you lose, again.

Finally, we are discussing these options in the context of making it easy for most users to do the right thing under most circumstances, not to guarantee absolute security under all circumstances against all attackers. When in doubt, it's always a good idea to consult with your friendly neighborhood Paranoid to clarify your requirements.

Sharing Options

With all of the above out of the way, here are a few thoughts on the various solutions for sharing your secrets and the implications of using a given method. Picking the one that best suits your needs is then up to you. (Sorry, no easy solutions in #infosec.)

Don't use a secret

The by far best way to protect a secret is to not have one to begin with. That is, for shared access to e.g., a social media account, check whether or not the service offers a collaborator feature whereby multiple separate accounts can be granted access to a shared account rather than having one single-factor password to share amongst people.

This translates to many other services or systems: retain or use multiple accounts to grant access to shared resources rather than sharing a single account's access. (Think use of sudo(8) by multiple separately authenticated users versus sharing of root's password.)

Useful when:

• the problem can be solved via authentication rather than possession of a secret

You need to trust:

• nobody (well, your process by which you identify whom you give the access to, but that's orthogonal to this discussion)

Encryption at rest: not a concern, there is no secret here!

Authentication of remote party: no remote party, no auth, no problemo.

Exchange secrets over the phone

Here, we make the assumption that you have a method of verifying the authenticity of the other party. This may be because you (believe you can) recognize the other party's voice directly, or you are using a trusted phone book (e.g., your organization's directory) to forward/reverse look up contact information. You further assume that your attacker is not tapping your phone lines.

Useful when:

• you need to share a one-time secret with parties that don't have access to any of the other solutions; e.g., providing a password to decrypt an encrypted data file that is shared by other means
• the other options are too technically complex or otherwise not feasible

You need to trust:

• that you can identify the other party yourself (alternatively: the authenticity of the phone number and how you got it)
• the telephone network operator

Disadvantages:

• you can only share secrets that you can relay vocally; good luck dictating your TLS private key to another person
• the other party has to immediately write down the secret; this will likely yield a copy of the secret with less protection than might happen in other cases

Encryption at rest: not applicable here.

Authentication of the remote party: easy if you know them, somewhat harder if you don't. Subject to social engineering.

Use your Key Management System

Most large corporate environments already have explicit requirements to manage secrets across multiple production systems. To this extent, they may be using an in-house Key Management System (KMS), a cloud service like AWS KMS, or perhaps the functionality of their configuration management system to distribute e.g., encrypted data.

This enables secret sharing on the basis of access to an authorized system, such as a server, an API, or via e.g., a web UI. The other advantage here is that these systems are usually tightly integrated and will easily solve the 'terminated employee' problem.

In addition, some of these systems may enable, facilitate, and even automate key rotation, which is a huge plus.

Useful when:

• you want to distribute the secret but don't need to actually know it
• you want to enforce proper long-term storage and or ease of secret rotation
• all parties have access to the same system
• you require automated access by e.g., services and systems

You need to trust:

• the parties operating the KMS
• the administrators of the key namespace or equivalent access controls

Disadvantages:

• often complex and not easy to use
• not well suited to human interactions

Encryption at rest: generally provided by the system.

Authentication of the remote party: easily outsourced to the service.

Use a shared key store or password manager vault

This is conceptually similar to the KMS, but with a focus on human use. Many password managers nowadays offer the concept of a "team" store, sometimes under the "enterprise solutions" buzzword. Here, a password store -- essentially a collection of files encrypted for multiple recipients -- is made available to all members of a group. The application / service handles all authentication and authorization aspects, making it a good candidate for many of the human<->human use cases encountered in corporate environments.

The drawbacks here may include vendor lock-in, and vulnerabilities found in the vendor's / provider's software or service. Another common issue is the lack of automated revocation or rotation of secrets when team memberships change; in services that do not tightly integrate with your Single-Sign-On solution, you may also encounter accidental or intended enrollment of "foreign" accounts (e.g., an employee's personal email address is used to gain access to the secret store). Unfortunately, these tools frequently lack a good API and access and use is expected to be interactive, often browser- or custom application based.

On the plus side, within enterprise settings you may be able to further dictate the access requirements, such as mandating multi-factor authentication for human access.

Useful when:

• all participants are onboarded to the service via e.g., SSO within your organization

You need to trust:

• the service provider
• the app / app store used to access the service
• the administrator of the namespace / organization of equivalent

Disadvantages:

• often only sharing within an organization possible
• organization admins may have a way to access the secret via e.g., escrow keys

Encryption at rest: generally provided by the system.

Authentication of the remote party: usually easily outsourced to the service.

Use of client-side encrypted pastebin or similar service

There are several public services that provide for encrypted, short-lived data storage such as e.g., https://zerobin.net/ or https://0bin.net/.

These services utilize client-side encryption in the browser, so the server never sees the clear-text.

Using such a service has the advantage that you and the party you're sharing your secret with need nothing more than just a browser, so ease of use allows sharing even with non-advanced users.

Another advantage is that the services often offer to remove the data after it has been accessed, thereby reducing the chance of it being leaked.

A disadvantage is that the URL to share becomes a de-facto secret itself, as it includes the private key used to decrypt the key. That is, anybody with access to the full URL can then access and decrypt the secret.

Secondly, as a public service, you are further outsourcing some of the trust (such as e.g., that they do not serve you backdoored javascript code) into the service provider. This can be mitigated by standing up an internal service using e.g., https://privatebin.info/.

Useful when:

• you want to share secrets with technically non-advanced users
• you want to share files or data that is larger than just a short passphrase or token
• you can share the URL in a reasonable secure fashion (e.g., private message)
• you want to be able to remove access to the secret after it has been shared
• you can use an internal service that requires additional access controls

You need to trust:

• the service provider
• the medium by which you share the link

Disadvantages:

• only partially solves your problem: sharing the link requires a trusted channel

Encryption at rest: provided by the service.

Authentication of the remote party: non-existent. You decide how and where to share the link and would perform authentication as part of that step.

Use of a restricted Google doc

In some cases, it may be reasonable to share certain information via e.g., a shared Google doc or a file in Google Drive. By using Google's access controls and ensuring the sharing settings explicitly restrict access to the individuals you select, you can control (to some degree) who has access to the information.

This of course requires the secret to be stored on Google's servers in unencrypted form, and access controls may be transferred by the Google Suite admins of your organization.

The biggest win here is that you are effectively outsourcing access control to Google. If the Google account you shared the document with requires multi-factor authentication or SSO via another organization's access controls, then those are now used to protect your secret. On the other hand, this also means that if somebody can compromise the other party's Google account (e.g., via phishing), then they get implicit access to the secret.

Useful when:

• you want to share text data with people who have a Google account
• you need to share text data with technically non-advanced users

You need to trust:

• Google
• your Google Suite Admins
• the recipient's ability to protect their Google account

Disadvantages:

• easy to accidentally broaden access
• secrets remain discoverable unless carefully deleted

Encryption at rest: non-existent. Even if you delete the data from the document, revision history will retain it. Even if you move the document to the trash, it will remain on Google's servers until you empty the trash.

Authentication of the remote party: outsourced to Google, so generally quite strong, provided you set the correct controls on your end.

Direct message in Slack or similar chat service

Popular chat services like e.g., Slack allow for "private" rooms as well as direct messages between individuals or multiple users. In many corporate settings, access to the chat system is additionally protected via multi-factor authentication or use of their SSO system, adding another layer of protection.

These systems have the advantage that (within an trusted organization) you get authenticity assurance of the users with whom you're looking to share information. Transport security is provided via https.

Since the chat service is usually hosted outside of your environment and provided by a third party, you are outsourcing a fair bit of trust here.

The drawback here is that these systems tend to keep logs of all messages being exchanged, including private messages. These messages may be available to the administrators of the organization and may be retained on the service's servers and in logs without your being aware of this.

Useful when:

• you want to share low-sensitivity or one-time credentials, such as e.g., the link to a privbin

You need to trust:

• your chat service admins
• the chat service

Disadvantages:

• secrets leaked into logs in third party service
• if your account is compromised, past secret exchanges may be discovered

Encryption at rest: some chat services will encrypt chat logs at rest, but this is often opaque to you. Assume no encryption at rest.

Authentication of the remote party: outsourced to the chat service and possibly your SSO solution, so generally quite strong.

Signal / WhatsApp / Apple Message

Modern mobile phones come with messaging apps that provide rather good protection of data in transit, notably the Signal Protocol in use by, well, Signal as well as WhatsApp.

Sharing secrets using these messaging apps can be a reasonably secure way to transmit the information, but it requires you to handle authentication as well as worry about encryption at rest. Sharing larger amounts of data such as e.g., files.

Another concern here is that your secret is now stored in your (and the recipient's) app's history. Some apps support disappearing messages, but that is unreliable.

Useful when:

• you need to share a one-time secret with others

You need to trust:

• the app
• the app store used to install the app
• the service itself

Disadvantages:

• not easy to share larger files from e.g., your desktop
• mixing boundaries from mobile to desktop means duplication of the secret
• message history may retain the secret

Encryption at rest: generally provided by the service, but data is generally available within the app history without any additional protection.

Authentication of the remote party: not too difficult, but it's on you, so subject to social engineering etc.

Stashing a file on a shared computer with permissions

If you and the recipients have remote access to a shared computer, you may be able to share your secret by temporarily stashing it in a suitably protected file on the system.

Care must be taken to ensure only authorized parties have access to the system and that permissions are set appropriately. If both of you have e.g., sudo(8) privileges on the system, making the file owned by root with mode 0400 would ensure that the usual (and hopefully strong) authentication mechanisms protecting the system also protect your secret here. If only one party has superuser privileges, have them chown(8) the file to the other party.

The drawback is of course that you both need to have access to the system, that anybody else who has access may also be able to gain access to the secret, and that the secret may leak to the disk. Of course you'd have to remember to remove the file after the other party has retrieved it.

Useful when:

• you and your recipients have shared access
• you need to share larger files

You need to trust:

• all users who have superuser access to the remote system
• all users who have physical access to the system

Disadvantages:

• easy to get permissions wrong
• only suitable for recipients with basic skill level to retrieve the data

Encryption at rest: possibly provided by the remote system with respect to how data ends up on the disk, but otherwise none.

Authentication of the remote party: provided by authentication to the system.

Sending encrypted data via email

Email seems a straightforward solution to transmitting data to another party. What's interesting about email is that nowadays a large portion of email is actually encrypted in transit, albeit usually opportunistically and unreliably, so if you control the sending and receiving mail server, sharing a secret via email wouldn't be as terrible as it may sound.

In practice, however, you cannot assume even transport encryption; the bigger issue with email then also becomes the issue of having the secret be stored in the clear and remain in users' inboxes or get quoted/forwarded etc.

To that extent, it'd be desirable to encrypt the data separately. Realistically, the only options here are limited (and don't bring up SMIME - I said realistically!).

PGP is a reasonable option if the parties involved are technically advanced enough to use it, since modern web mail clients have poor integration with PGP.

Another option might be to symmetrically encrypt a file with a password and attach it to an email. This can be an option when dealing with technically non-advanced users across different platforms by using e.g., openssl enc or 7zip. Of course this means that now you have the problem of relaying the password for the encrypted file, but for that, you might use some of the approaches noted above.

Useful when:

• you need to share secret files
• none of the other options works well

You need to trust:

• yourself and the other party to use the tools correctly

Disadvantage:

• PGP: hard to use
• PGP: lack of integration with the mail providers
• symmetric encryption: now you have to share the password via one of the other methods

Encryption at rest: provided!

Authentication of the remote party: up to you -- for PGP, verifying the user's key brings the usual web of trust issues; for symmetric encryption, the problem is pushed to the mechanism by which you share the password.

Stashing an encrypted file in a code repository

This is basically a variation of the above solution to use email. That is, encrypting the data shifts the secret sharing problem to that of either authenticating the asymmetric key of the recipient(s) or of sharing the symmetric key / password.

However, in addition to PGP and 7zip, you might be able to utilize already existing asymmetric keys in your environment. For example, if your organization uses SSH keys to access systems or services, you might be able to use a tool like jass; if your organization uses client-side TLS certificates, you can use those to encrypt the data.

Storing the encrypted data in e.g., a code repository has the benefit of adding revision history and access controls, turning your repository into a poor man's key management system. This, however, also suggests that perhaps you ought to instead use a proper key management system.

But this is a very custom approach and hard to generalize in this context.

Useful when:

• you want to add revision control to your secret
• you have existing asymmetric secrets or tokens already distributed

You need to trust:

• the receiving party to handle their secret keys with care

Disadvantages:

• only solves the data sharing component; the secrecy must still be provided via other means with all the complexities therein

Encryption at rest: provided!

Authentication of the remote party: likely already provided by your infrastructure in some way.

Using a third-party storage service like Dropbox, Box, etc.

Many online services like Dropbox or Box allow users to share files. This can be a useful way of sharing a secret with a party outside of your organization who is not technically advanced.

The advantage here is that it's generally easy to share files with individuals without requiring them to have a specific app or even an account. The disadvantage is of course that you are placing the secret data into the hands of a third party and are relying on them to protect it correctly.

Useful when:

• you want to share files with people outside your organization

You need to trust:

• the third party service

Disadvantages:

• services often opaque to you
• you risk exposing the secret/data to a third party service

Encryption at rest: depends on the service.

Authentication of the remote party: generally provided by the service via either login or an emailed URL and token.

Phew, that's a lot of ways of sharing secrets! And there are so many others that I didn't cover, be they standalone services, ad-hoc servers (e.g., https://github.com/warner/magic-wormhole), or tools to encrypt data in e.g., your configuration management system. Which one to use... depends. It depends on your threat model, the data in question, whom you're looking to share it with, their capabilities, and network or application access.

The above discussion is meant to provide you with the background to make a reasonable decision, to understand when it might be ok to use one approach and when to use another. Make sure to look and ask around in your organization: you may have internal systems or services set up specifically for one or more of the use cases discussed here.

However, in all cases would it be a Good Idea(tm) to consult with your friendly neighborhood Paranoid if you are unsure. Your local infosec staff are there to help you!

May 18th, 2021