What is S/MIME?
S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for securely transmitting MIME-encapsulated messages (such as email). It is tailored for end-to-end security and support for S/MIME is built into most modern email software and is interoperable.
S/MIME uses public-key based infrastructure to do its job. Keys are used in pairs: a public key that may be (and usually is) published and a private key which is known only by its owner. Two functions can be achieved using these keys:
- Using a public key to authenticate that a message originated with the holder of a private key
- Encrypting a message with a public key to ensure only the holder of the matching private key can decrypt it
These functions are used by S/MIME to provide several cryptographic services.
Encryption
Transmitting sensitive information can be done using S/MIME encryption. When encrypting a message, the sender uses the public key of the recipient(s). Only the recipient that has the private key corresponding to this public key can decrypt the message.
When using encryption with S/MIME, all contents (such as body and attachments) of the message are encrypted. Message headers are not encrypted – most of these are required to be able to deliver a message. Examples of unencrypted information are email addresses (sender, recipient(s)) and the mail subject which are transmitted in plain text.
Encryption ensures confidentiality and integrity of the transmitted data.
Authentication
S/MIME can also be used to authenticate both message sender and content. When sending a message, the sender can use his private key to add a digital signature to the outgoing message. The public key of the sender is also added to the message.
This combination of information can be used by the recipient of the message to authenticate the sender (i.e. validate the identity). It also ensures non-repudiation: signatures are unique and cannot be disowned, much like signatures on paper. Data integrity is also ensured with digital signatures: any modification to the signed message invalidates the signature immediately.
<h3″>How does the Kopano S/MIME plugin work?
The Kopano S/MIME plugin aims to make message signing and encryption easy to use. An easy example is the addition of the ‘sign’ and ‘encrypt’ buttons to the compose email screen.
Some of the features provided by S/MIME (encryption) require that the sender knows the public key of the recipient(s). There are two ways the Kopano S/MIME plugin helps in the exchanging and managing public keys within the infrastructure.
Automatic key exchange
The Kopano S/MIME plugin automatically saves public keys that have been received with a signed email message. These keys can later be used when sending an encrypted email message. This is a standard way of exchanging public keys between S/MIME users.
Storage in user management
Using S/MIME encryption within one organization can be made easy for both user and administrator by managing the public keys in a user management service such as Active Directory or LDAP. These keys, when exposed to the Global Address Book, can be used by the Kopano S/MIME plugin to send encrypted messages without having to exchange public keys first.
Where and how are the keys stored?
Private keys
When using the Kopano S/MIME plugin, the private key is stored in the user’s WebApp profile. Storing private keys ‘online’ is generally not a recommended practice. We made the compromise between applying this best practice and making S/MIME easily usable for every user. Encryption and signing of e-mails raises security and privacy of e-mailing only when as many users as possible really use it. Private keys stored in the profile are encrypted per default. Decrypting the key will require the user to enter the passphrase associated with the key. On demand, the passphrase can be changed only by the user that has the correct passphrase used with the key. That’s why we make it as easy as possible to use S/MIME: lowering the technical requirements to use it efficiently as possible for users yet keeping the maximum level of protection to protect the messages and their content.
Note that if the private key is irrecoverably lost (e.g. the user profile is reset without having a backup on a separate medium) access to encrypted data is permanently lost.
Public keys
Exchanged public keys are stored in the user’s WebApp profile. Public keys are not encrypted, they never are. A list of exchanged public keys can be viewed and managed in the S/MIME settings pane in WebApp. When public keys are managed in the user management service (AD, LDAP) these receive higher priority than exchanged public keys.
Management of keys
When rolling out S/MIME to a company certificates usually are delivered as pkcs#12-files to users. Traditionally a second medium (this is recommended practice) is used to deliver the password to unlock the certificate (for example by letter, sms, …). The user then imports the certificate and uses the password to unlock it. In some mail clients the unlock password can be stored to keep the private key unlocked, so no further password re-entry is required to sign or decrypt an e-mail.
Active Directory Certificate Services (AD CS) stores certificates and keys in the encrypted PFX format. These files are recoverable for the user that has the password. Administrators that have the Key Recovery Agent (KRA) enabled (which is traditionally the case in most environments) can recover the private key as well (and therefore gain access to any encrypted information). If you use AD CS and you do not have KRA enabled you can still use Kopano S/MIME by storing the certificates in the WebApp profile. This eliminates potential exposure towards Administrators by for example using Web Enrollment for distribution of keys to users.
Downside of this procedure is: The certificate-holder decides where to store his certificate. It could be kept on an USB stick, stay in a mailbox as if it was sent as attachment or end up on a file server (for example with roaming profiles) when the holder decides to store it on his desktop or in his personal folders. The more locations a key is exposed to, the higher the risk of the key being potentially exposed unintentionally.
With Kopano the private key does not have to be delivered to the owner. The internal IT department has the option to directly place it in the owners profile. This way, just the password used for generation requires to be delivered to the owner. The compromise we decided to go for ensures encrypted keys are stored on a server protected in the owners store while in the standard setups the risk of lost or vulnerable keys is higher as they could theoretically be stored also on potentially insecure media location.
Future development with DeskApp
Easiness of use makes storing the private key (encrypted) in the user’s WebApp profile required at this time. Storing private keys on the local system would add an additional step in terms of security. We are currently researching the storing the private keys on the local system in combination with DeskApp.
