Sharing Encrypted Documents

How to share encrypted documents via email using GPG

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: Encryption | Cybersecurity

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Often clients want to share a document on a video platform and I decline. I am just not comfortable asking clients to share sensitive documents on a video platform I have not fully vetted (and no one has paid me to do that as of yet). I don’t want to be responsible if that platform is later discovered to be the source of leaking customer data.

I also don’t know everyone who is on calls in all cases since I’m not always responsible for scheduling them. I also cannot see if there are multiple people in a room on the other side of a call who can view a document.

I also don’t click random links in chat windows in video calls. Unfortunately, I don’t know the people on the calls in most cases. I would love to trust them all but refer to chapter eight in my book at the bottom of this post as to why I might be reluctant to do that.

I would prefer not to install some video call software on my machine, but I do when it is a requirement, if the payment is high enough. I just take a lot of other precautions that I know most people do not and it is time consuming. Depending on the platform I may have to configure a cloud environment and drivers to stream the video. I may have to configure a separate portion of my network to open ports required by that platform (I’m looking at you Microsoft Teams). It’s a pain and additional security risk that is not necessary for me to answer security questions for clients.

What I would rather have clients do is encrypt any documents with my public encryption key they want to send me and send them over in advance of the call. I also use this method when exchanging sensitive data on projects. In addition to limiting the scope of who can view customer documents, I can also review the documents before the call to provide a better assessment and hopefully a better answer on the call.

Encrypting documents sent in email

My preferred approach is to have clients send me encrypted documents in advance of a call using my public encryption key using the following steps:

Step 1: I provide the client with my public encryption key.

Step 2: The client verifies the signature through an alternate communication channel to ensure they got the correct public key.

Step 3: The client encrypts the documents they want to send with my public key.

Step 4: Only I can decrypt documents that are encrypted with my public key.

If I need to send documents back to the client, reverse the process.

Step 1: The client provides me with their public encryption key.

Step 2: I verify the signature through an alternate communication channel to ensure I got the correct public key.

Step 3: I encrypt the documents I want to send with the client’s public key.

Step 4: Only the client can decrypt documents that are encrypted with my public key.

Verifying that we are using the correct emails

Now as far as the email goes, it’s easier to verify we are all using the correct emails when I have a contract directly with a client, because the client and I have a signed contract through a [hopefully] secure document management system. We use the emails provided in the contract to exchange keys and send messages.

When working through third-parties (clients that schedule calls with me through IANS as I do not work through any other third parties at this time), we have to make sure we are using the correct emails and keys for data exchange a bit more. How does the client or a third-party know that the email they received is actually mine when they don’t know me or the person who is telling them what my email is?

Well, if there are any concerns, the client can contact me on LinkedIn, Twitter, or my business line to try verify that information. It’s not always easy to verify people are who they say they are but you can try to use multiple sources.

If you want to be even more technical about it, check out NIST 800–63A which covers remote verification of identities. I recently had to go through this process myself in relation to a data breach at a particular government security organization.

https://pages.nist.gov/800-63-3-Implementation-Resources/63A/ial2remote/

By using this approach, even though IANS is facilitating the communication and scheduling the call, a customer can provide a document that only I can view. I also delete any documents I receive after the call is over.

Why signature validation is important

The person using the public key needs to take steps to verify the signature of the public key in an out-of-band communication channel to ensure they are using the correct public key. Otherwise here’s the scenario.

• Attacker intercepts my email to a client with my public key attached.
• Attacker sends the client their own public key.
• Attacker intercepts message from client and decrypts the attachment with their own public key to read it.
• Then the attacker re-encrypts the document with my public key and sends it to me.
• I decrypt the document and never knew anyone else read it.

The above can also occur if a third-party is responsible for providing you someone’s public key. For example, I’m not sure how I feel about online registries that are supposed to provide you with people’s public keys. How secure are they really? Could someone swap out my public key in the registry for someone else’s? I had a company once use a key in a registry that was no longer valid to send me a document. I had forgotten to remove it. That’s why I prefer to use my own communication channels and exchange information directly with clients.

Also, if someone else is responsible for sending my public key to someone to facilitate a call, for example, the client should first contact me to verify the signature of my key before sending the documents. For example, reach out to me on my business line at https://2ndsightlab.com, though LinkedIn, or both.

Using GPG

GPG stands for Gnu Privacy Guard and can be used for this type of public-private key encryption, also known as 2-key encryption or asymmetric encryption. If you want a good explanation and image of the encryption process check out this post:

I use a Mac and the command line when I encrypt and decrypt documents with GPG. It’s already installed so I don’t have to add anything. The above post tells you how to install GPG on other platforms.

You can also use GUI-based applications for the encryption and decryption process. However, one client I worked with used one of those tools and it installed a related piece of email functionality. I’m not sure exactly what that add-on did but it made it such that I could not decrypt any documents he sent me. If you do use a tools with a GUI I would avoid the add-on unless you know you need it.

Here’s a page where you can download software:

How to use GPG from the command line

You can find the full range of options when using GPG from the command line here:

Note the warnings at the bottom:

Create a GPG key

If you already have a GPG key, skip this step.

UPDATE: These instructions below are for RSA keys. Updated guidance from NIST is to use ECC. I wrote instructions to generate an ECC key here. The encryption and decryption instructions are the same.

1. Run this command:

gpg --full-generate-key

1. At the prompt, specify the kind of key you want, or press Enter to accept the default RSA and RSA. (Note that some people are starting to use Elgamal due to weaknesses in RSA, but I’ll let you research that option as I’m still looking into the details. Update: Yes, you should be using Elgamal or ECC as I described in this post due to new vulnerabilities coming to light. https://readmedium.com/what-to-do-about-a-recently-discovered-ssh-vulnerability-f390d618a605
2. Enter a key size. I recommend 4096 or greater.
3. Enter the length of time until the key expires or enter for no expiration.
4. Verify your information.
5. Enter your ID (email address).
6. Type a secure passphrase. Make sure you remember this too.
7. You’ll see the following while the key is generated. Do what it says:

9. Store your private key securely and don’t let anyone else access it.

10. Share your public key with anyone who needs to send you encrypted documents.

Export the PUBLIC (not the private) key for sharing

To share your public key you can run this command:

gpg --output [file] --armor --export [email]

Note that if you have multiple active keys for the same email you should use the ID, not the email to export the key. You can see the ID for the key when you run this command:

gpg --list-keys

It is the long string of numbers and letters associated with the key.

gpg --output [file] --armor --export [key id]

Verify the key

The recipient of a public key can validate the public key as follows by working with the owner of the key to ensure the fingerprint is correct.

1. Run the fingerprint command against the public key.

gpg — fingerprint [email address in my contract or provided securely]

2. Contact the key owner to verify the key signature is correct.

3. The key owner can generate the signature of their public key and read it to you to ensure the signature you generated matches the correct signature.

Use some form of communication other than email to verify the signature, since that is how you exchanged the keys. If your email system is compromised, hopefully the attacker has not also compromised your cell phone or a social media account, or example.

Encrypt a document

The following commands can help when you are trying to encrypt a document via the command line. For a GUI application, refer to that application’s instructions. Note that I’m also using the sign option below.

Get a list of GPG commands:
gpp --help

Get information about a key without importing it:
gpg [key file someomesent you]

Import a public key file:
gpg --import [key file someone sent you]

See which keys are imported on your system and related information 
(verify the import):
gpg --list-keys

Encrypt a file using the recipient email associated with the key:
gpg --output [name-for-encrypted-file] --encrypt --sign --armor --recipient [email address in contract] [name-of-file-to-encrypt]

You may also want to read up on signatures for documents and how you can verify them if you are receiving documents from someone.

Using a Yubikey to store your private key

Also, you can store your private key on an Yubikey, which is interesting. But the last time I tried to move a key to a Yubikey it somehow made it impossible to use the key. I’m also not sure of the security implications of the management software, etc. I need to explore that option a bit more at some point, but it seems like it would be a great option, depending on what you need to do to get the key there and if it works reliably. Then, instead of having your private key on your computer it’s stored on a separate device which you can remove when not in use.

Backing up your key

It’s a good idea to back up your key somewhere but not in plain text on your computer! Store it somewhere encrypted or perhaps a second Yubikey.

You will want to export your public key as above and your private key (which should never be shared.)

gpg --export-secret-keys > private-key-backup.gpg

If you really want to get into how GPG works and other files you may want to backup read the manual:

Preventing corruption of exchanged documents

Please note the following which can cause decryption to fail or may cause us to do additional formatting to decrypt messages, especially when sent between different operating systems (e.g. Mac vs. Windows).

• Do not use email plugins (to send me an encrypted message).
• Do not copy and paste the key or encrypted messages into the email body directly. This causes extra spaces to appear when copied into a text file between different systems. The mail system may be sending or receiving or displaying the email in HTML or some other format.
• Do not copy and paste the key into a Word document or other type of document. Same as the first bullet. This adds extra metadata around the encrypted content and may insert additional line breaks.
• Send the encrypted documents in an attachment as a text file. See the remaining instructions for how you can do that.
• Only one person should have access to each private key. If you want to have different individuals receive encrypted documents, each individual should have their own key.

What about companies that claim their email system encrypts email messages?

I often get that from people at banks. You can send it in email. We have a secure email system. Sigh. Should I take the time to explain or bother to ask additional questions they cannot answer?

They want me to send the documents and I know they don’t know what “secure” or “encrypted” means in this context. I wrote a whole series on security for the mortgage and real estate industry after related experiences.

Here are a few questions for those companies.

Is the document encrypted in such a manager that only the recipient can decrypt it? Generally, no.

The encryption that most people are referring to is encryption in transit via TLS. What that means is that if someone is sniffing the network between mail server A and mail server B, an attacker cannot read the mail in transit.

Additionally, if the data is encrypted at rest that means while the emails are sitting on disk, an attacker that gets malware on the machine can’t access the emails — depending on where the company stores the encryption key.

That does not mean that only the person that is supposed to receive the document can encrypt it.

Can your email administrators read emails with unencrypted documents? Generally, yes.

If they are super admins for the system that they install and manage themselves they will likely be able to turn on detailed logging that allows them to read emails sent via that system. I have managed Exchange and cheaper variations of mail servers in the past and been able to view emails on the system logs when troubleshooting problems for clients.

If I wanted to, in my current setup where I don’t manage the server but have super admin privileges, I could redirect emails belonging to the people that I host email for to my own email address. (I don’t.) That’s generally what happens when someone leaves a company. The company redirects that person’s email to someone else.

Is the network between your email server and mine secure? Since I don’t control the TLS configuration for my own email system (it’s a cloud platform) I can only hope that the TLS configuration is correct. In terms of any client with whom I’m exchanging messages I can’t know if their email server TLS configuration is secure or potentially downgraded without doing additional assessment work. Could an attacker intercept messages between our systems? A person trying to collect my mortgage documents at a bank almost certainly has no idea what the answer to this question is and cannot tell me that our messages are secure as they haven’t asked me anything about my mail server.

Are there any vulnerabilities on your mail system or mine? Exchange has been rife with security vulnerabilities over the past few years. The person telling me the messages are secure can’t know that without asking me if I use Exchange and what version. They never do. So telling me that they use a “secure messaging system” to send emails to me or receive emails from me without asking any questions is actually somewhat of a liability for a bank, I would think. But ask a lawyer.

What I know about GPG is that if you encrypt it with my public key and your email administrators, attackers, or someone at the cloud email hosting provider doesn’t have my private key, they can’t decrypt and read the document attached to the email.

Yes, using GPG encryption is too much to ask of bank customers and loan officers. That’s why I recommended a secure document portal instead in my series on that topic. However, I think that people working in security can probably handle GPG encryption if the security of the information they are sending is important to them.

Consider where and how you share sensitive documents

That’s it for now on GPG. If you are going to schedule a call with me at IANS Research and want to share some documents, please work with your IANS account or client representative to coordinate getting my public key and verifying it directly with me as explained above.

Is this a pain? Yes. But consider the alternative:

If you don’t want to encrypt the documents, you can also send them in plain text prior to the call, but I don’t recommend it unless you really don’t care who sees the documents.

I can provide a Google Drive folder as well but please me sure you get that directly from me. It is better than email as I can restrict it to specific gmail accounts, but not as good as GPG.

I also wrote about how you can store a GPG key on a Yubikey here:

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab