Imagine the setup described above in a DME setting. For a user to read a signed and/or encrypted e-mail on a mobile device, the user would need to download and install certificates on the device. Furthermore, to send an signed e-mail, the user’s private key would need to be installed on the mobile device. This is impractical for a number of reasons:
Security: If your mobile device is lost, your private key is in danger of being stolen. If that happens, another user could in theory digitally pose as you (“identity theft”).
Security: Not all users in a mail system knows about certificates, S/MIME and all that, and may tend to just accept any prompt to install certificates.
Security: Spam and virus filters are unable to scan S/MIME e-mails.
Administration: Why should all users have the trouble of managing certificates on their mobile devices?
Instead of users storing certificates on their mobile devices, DME stores all certificates on the server. There are a number of advantages to this:
Certificates are not stored on the devices, and therefore they cannot be lost.
The administrator gets to decide which trust authorities to include in the trusted list.
Spam and virus filters can be applied to e-mails after decryption on the server.
If an external person (that is, a person identified by an e-mail address which is not part of the DME system) exists on the DME system, every user in the DME system can send encrypted messages to that external person. The public certificate from the external person is automatically accepted by the server.
The certificate part of a signed message sent to several DME users is stored on the DME server, and only the e-mail as such is passed on to the users - saving traffic costs. The last part of the e-mail’s journey to the reader is subject to the heavy encryption and security schemes of DME anyway.
The attachments of encrypted messages sent to a DME user are stored encrypted on the server, and only the e-mail as such is passed on to the user - saving traffic costs and storage and processing power on the devices. The user can choose to download the decrypted attachments separately.
When DME administers the keys, the users’ personal certificates holding their public and private keys must be uploaded to DME in order for the users to be able to send signed and encrypted messages. This is where myDME comes in. With myDME, users upload their own personal certificates with additional password protection. This additional password protection means that an administrator cannot access the private keys, even though he has physical access to the server on which the keys are stored.
In order to be able to send signed messages from or decrypt received messages on the device, the user needs to enter the password for the private key, which he entered when uploading the personal certificate. This password is entered in the security settings page of the client.