UB Secure Email with S/MIME

The University at Buffalo offers certificates for email signing and encryption. These certificates allow you to send email that is verified to come from your UBIT account, as well as to verify that other users are sending email from their UBIT accounts. Routine usage of signed and/or encrypted mails can prevent users from falling prey to phishing attacks and protect sensitive emails from unauthorized viewing.

TL;DR

The TL;DR for encrypted email setup is this:

• Ensure that you have an S/MIME capable email client. I recommend Mutt, but your tastes may be less refined. Many other local email clients (including Thunderbird and Apple Mail) support S/MIME.
• Follow this link and the instructions therein to receive a UB S/MIME certificate: https://email.buffalo.edu/ClientCertificate.html
• Download the resulting .p12 file to your local computer and keep a copy in a safe place (perhaps a removable USB drive in a secure location).
• Install the .p12 file according to your preferred email client’s configuration.
• Configure your email client to sign emails by default.

What is S/MIME?

S/MIME, or “Secure/Multipurpose Internet Mail Extensions”, is a set of agreements on how email clients should interpret mail that has been protected by cryptographic techniques. It uses the same mechanism as email attachments, but in a very specific and well-defined way, and in conjunction with the public key infrastructure (PKI).

PKI is yet another set of cryptographic standards for managing encryption keys that can be used for signing and encrypting data. Encryption keys are bundles of data that observe certain mathematical properties that are outside of the scope of this discussion. What PKI provides is a way to determine the legitimate owner of those encryption keys, thereby binding them to a particular person or organization.

Signing is the process of using encryption keys to mark data as having come from a particular source. A digital signature on an email is an unforgeable (under some more-or-less realistic assumptions, depending on your perspective) proof that an email was sent by a particular user and has not been modified since. If you send a signed email, the recipient can have significant confidence that it was actually sent by you, and contains what you intended for it to contain. Likewise, if you receive a signed email and the signature is verifiable, you can have significant confidence that it was sent by the purported sender and contains what they intended for it to contain. This reduces the risk of, for example, acting on information or clicking on a link contained in the email. Note, however, that the signature is only as good as the tech savvy of the sender! If you have a coworker who is constantly sending out MLM scams and dubious discount links, you aren’t guaranteed that the links that they send are safe, only that they meant to send them to you.

Encryption uses the same or similar encryption keys to hide the contents of an email so that it can only be viewed by some intended set of recipients. If you send an email to a particular colleague at UB and use S/MIME encryption, you can have some confidence that they are the only user who can read that email. Like signatures, this is only technological trust; if they forward the email to their MLM group, the information may still get out.

Obtaining Keys

For S/MIME to work, you have to have an encryption key and a certificate that establishes that that key “belongs” to you in the PKI. While it is possible to create a key for yourself, it is not possible to create a PKI certificate for yourself that other users will believe. This means that you must get your PKI certificate from UBIT if you want to send UB secure email that other UB users will trust.

UBIT has a dubious mechanism for creating keys, in that they create (in fact, a third party entity that none of us have any business trusting creates, and then you download it without authenticating in a meaningful way) the encryption key and send it to you. This is not good security practice, but there does not seem to be a way to get around it. This means that you should use your UB certificate only for official UB business, as you cannot trust that your encrypted emails cannot be opened by administrative or IT staff at UB.

UBIT provides a web page where you can request a certificate. You will need to follow their instructions, which involves logging in with your UBIT Single Sign-On, receiving an email to a UBIT email account, and then downloading the certificate in your web browser. During this process you will have to create a password (which for some reason they call a PIN) that protects the key. Use a strong password, but don’t forget it! When you download the certificate, it will be in a file called yourubit_buffalo_edu.p12 and protected by that password. You will use that .p12 file to configure your email client.

Configuring Your Email

I recommend that you use Mutt. I will include information for configuring S/MIME in Mutt. Other email clients are also capable of supporting S/MIME to a greater or lesser degree, and I will describe the general outlines of that support, but I do not know how to use these lesser pieces of software.

In order to S/MIME sign emails, or decrypt S/MIME encrypted emails sent by other senders, your email client must know your S/MIME certificate. You will use your .p12 file (collected as described above) to install that certificate in your email client. The method of doing this varies, but it typically involves “importing” the key. When you do so, you will have to provide the password (“PIN”) that was given when you applied for the certificate. Your mail client should also prompt you for a new password (it may say passphrase) to protect the key once it is installed; use a strong passphrase, but remember that a) you will have to type it frequently, and b) if you forget it, you will have to reinstall the certificate.

Once the certificate is installed, you may want to configure your client to sign the emails that you send by default. This is an excellent way to encourage protection of sensitive information and good email handling practices. Recipients of your emails will see a message in their (compatible) email clients indicating that your email is verified to have come from you.

Setting up GnuPG for S/MIME

Signed or encrypted email requires both an encryption tool and an email client. In some cases these two things are bundled together, and in others they are separate tools. In the case of most Unix mail programs, S/MIME handling is normally handed off to either OpenSSL or the GNU Privacy Guard (often called GPG or GnuPG).

To use GnuPG for S/MIME, you will need to install the GnuPG tools for this purpose, which are probably called gpgsm or something similar in your distribution or package manager. On Debian-derived systems (such as Debian or Ubuntu), you can install it with sudo apt install gpgsm if it is not already installed.

Once you have installed GnuPG S/MIME support, you will need to import the certificate and private key that you downloaded above into your keyring. You will do that by running gpgsm --import yourubit_buffalo_edu.p12 (or whatever filename you chose to save the .p12 file as). This will prompt you for the password (PIN) you used when requesting the certificate, and then the passphrase that you want to use when signing or decrypting emails. Again, pick something strong but memorable! You’ll be typing it a lot. You can configure the GnuPG agent to remember your passphrase for a few minutes after you enter it, if you like; doing so is outside of the scope of this document.

Note: As of Spring 2023, the keys that are generated by the third-party provider do not import into GnuPG versions up to and including 2.2.39, failing with a PKCS#12 parsing error (as best I can tell). I thought that the reason was probably this bug, but it is fixed in 2.2.35 and the problem persists in later versions of GnuPG. I honestly cannot tell if it’s a gpg problem or a key problem without more work. (OpenSSL also doesn’t seem to like the .p12 file so much, though.) As a workaround, what I have found is that you can import the key into Chrome (go to settings, Privacy and security, Security, Manage certificates, then import the .p12 file with the import button) and then re-export it and gpgsm will load it just fine. I dream of the day that UB/UBIT figures out how public key cryptography is supposed to work.

Once you have imported your certificate, you can view information about it with gpgsm --list-keys yourubit@buffalo.edu. In particular, you may want to record the ID; for example, mine is 0xA0C28EF1. It is not required for configuring mutt or Emacs, but you may want to use it in a later step.

Setting up Mutt with GnuPG

Mutt is a terminal-based email client with excellent standards support and a high quality interface for dealing with large quantities of mail, particularly from mailing lists and other group services. It allows you to use your favorite editor (Emacs, of course, or maybe Jed) to compose email and supports a wide variety of encryption, attachment, and encoding mechanisms.

To use S/MIME with mutt, you will want to install the GNU Privacy Guard S/MIME tools per the instructions above.

You can place the following configuration in your ~/.muttrc to configure your UB S/MIME certificate and enable email signing by default; if you’re already a mutt user you can just add this to your existing configuration, and if you’re a new mutt user you can add your existing configuration to this.

set crypt_use_gpgme
set smime_is_default
set crypt_autosign

If you find that your mutt can never verify incoming emails as authentic, you may need something like the following (which works on Debian and Ubuntu systems); this is probably already configured for you.

set smime_ca_location=/etc/ssl/certs/ca-certificates.crt

If you have more than one S/MIME certificate or (for some reason) mutt keeps asking you what key ID you wish to use, you can use the ID that you identified via gpgsm --list-keys yourubit@buffalo.edu when setting up GnuPG to tell it what key ID you wish to use by default. To do that, add the following line to your .muttrc (using your key ID in place of mine!):

set smime_default_key="0xA0C28EF1"

Every time you send an email, you should now see “Security: Sign (S/MIME)” before sending, and be prompted for a passphrase if your key has not been recently used and cached in the GnuPG agent. When you receive S/MIME signed emails, you will see a brief message indicating whether they were verifiable or not (and GnuPG S/MIME will attempt to fetch and import the requisite certificates for verification if it does not have them).

If you wish to send an encrypted email, press the S key at the compose screen and select e for encrypt or b for both encrypt and sign. You will have to have the S/MIME certificates of the recipient(s) of the message in order to do this; the easiest way to handle that is to ask them to send you a signed email first, which will cause GnuPG S/MIME to import their certificate for future use.

Setting up Emacs and mu4e with GnuPG

Dealing With Problems

There are some problems that come along with signed emails. They are broadly separated into two categories: technical problems, and user interaction problems. They are not unrelated.

Technical Problems

Some users may report that your signed emails do not display correctly, or that your encrypted emails cannot be opened at all. This is because their email client is misconfigured or does not understand S/MIME, or because your email client is misconfigured or does not understand S/MIME. If you are using a high quality email client and communicating with University recipients, you should not see this very often. If you’re communicating with your MLM group and most of them are still using AOL and Juno, it’s likely. On the other hand, if you’re communicating with University at Buffalo users who are using the UBIT-provided and recommended Outlook 365 web mail client on any browser except Google Chrome, you will likely also have this problem, because … I don’t know why, except that neither UBIT nor Microsoft understands email very well. The “fix” for this problem has two forks: you can stop signing (or encrypting) emails that you send to this recipient, or you can convince them to use a well-supported email client. For professional contacts within the University at Buffalo, please try the latter approach! I believe UBIT recommends that they switch to desktop Outlook, which might work for Windows users (I cannot confirm).

User Problems

Probably the most common user issues with encryption and signing schemes revolve around keys and certificates. Broadly speaking, users can lose their keys, and they can accidentally disclose their keys. Sometimes these things happen at the same time (for example, their keys are on their laptop, and they lose their laptop).

If you lose your installed encryption key or certificate, most commonly by forgetting the passphrase, you may be able to reinstall it using the original .p12 file if you remember the password (PIN) that you used at creation. Otherwise, you may be able to request a new certificate using the same process you used to get the first one. If you lose your certificate but remember the revocation password, you should use it to revoke your certificate; revocation is outside of the scope of this document.

If you accidentally disclose your key, you should revoke it immediately by using the revocation password that you set when you created it (if possible), or contact UBIT for assistance otherwise. Revocation is outside of the scope of this document.

The second problem that you are likely to encounter, particularly from nontechnical users with substandard email clients, is that your emails may either appear to have an attachment that their computer does not know how to handle, or may show up as unverified (rather than saying nothing at all, as an unsigned email would). In the former case, the attachment will normally be a file ending in .p7s, and you can tell the user that it’s OK to simply ignore it. In the latter case, you should suggest to UB users that they configure their email client for S/MIME. I hesitate to suggest reassuring users that they ignore the “unverified” warning, but you might explain to them that it means that your email is verifiable and their email client does not have enough information to verify it, and that it is not automatically something to worry about.