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.
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
.p12file to your local computer and keep a copy in a safe place (perhaps a removable USB drive in a secure location).
- Install the
.p12file 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.
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 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
.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 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 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.
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 mutt, it hands
S/MIME handling off to either OpenSSL or the GNU Privacy Guard (often
called GPG or GnuPG). To use S/MIME with mutt, you will want to
install the GNU Privacy Guard S/MIME tools, 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
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
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
Once you have imported your certificate, you can view information
about it with
gpgsm --list-keys firstname.lastname@example.org. In
particular, you may want to record the ID; for example, mine is
0xA0C28EF1. It is not required for configuring mutt, but you may
want to use it in a later step.
You can place the following configuration in your
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.
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 email@example.com 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!):
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.
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.
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. 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!
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.