S / MIME

from Wikipedia, the free encyclopedia

Secure / Multipurpose Internet Mail Extensions ( S / MIME ) is a standard for encryption and signing of MIME - objects by a hybrid cryptosystem . S / MIME is used in a large number of protocols for protection in the application layer . Typical applications of S / MIME are e-mail , AS2 and many more. In practice, S / MIME (content level) can be combined with TLS (transport level).

function

RFC 1847 (1995) defines two content types for MIME. The multipart/signedformat for signing an email and the multipart/encryptedformat for its encryption. An email can only be signed, only encrypted or subjected to both operations. Both S / MIME ( RFC 2633 ) and OpenPGP ( RFC 2440 ), both of which were specified later, use multipart/signed, whereas multipart/encryptedonly OpenPGP is used. S / MIME defines (also) the new content type for encryption application/pkcs7-mime. Most modern mail clients support S / MIME. It requires X.509 -based certificates to operate.

Multipart / Signed

The format contains exactly two blocks. The first contains the data, including the MIME header, via which the digital signature was created. The second contains the information to verify the signature. This means that the mail remains readable even for e-mail clients that do not support S / MIME. This is why it is multipart/signedthe recommended of several possible S / MIME methods.

application / pkcs7-mime

The content type application/pkcs7-mimehas the optional parameter smime-type, which describes the type of data (without having to be decoded for it): enveloped-data (encryption), signed-data (signature), certs-only (certificate). In addition, the file name of the optional but requested header entry Content-Disposition shows the type of data: smime.p7m (signed or encrypted data), smime.p7c (certificate), smime.p7s (signature).

A section with encrypted data also contains exactly two blocks. The first contains information needed for decryption. The second block contains the encrypted data. The body of the mail is completely encrypted and can therefore only be read by the intended recipient. This means that scanning for viruses and spam is only possible on the end device. The mail headers (including the subject), on the other hand, are still unencrypted and should therefore not contain any confidential information.

An example of an encrypted message looks like this: 

   Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
           name=smime.p7m
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7m

   rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
   7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
   f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
   0GhIGfHfQbnj756YT64V

In order to encrypt an e-mail, the sender must know the recipient's public key , which he can, for example, obtain from the certificate of a signed e-mail previously received by the recipient. An e-mail client simplifies handling by automatically saving all certificates received.

Classification of certificates

The providers of certificates for secure e-mail communication usually classify them into three classes that build on one another:

  • Class 1 - The certification authority (CA) guarantees the authenticity of the e-mail address and only this is part of the certificate.
  • Class 2 - In addition to the e-mail address, the associated name is included in the certificate, as well as the organization / company, if applicable.
  • Class 3 - Class 3 data is verified using third-party databases, copies of ID cards, extracts from the commercial register, etc.
  • Class 4 - For class 4 certificates, the applicant must identify himself personally.

Free certificates

Some companies and non-commercial organizations offer free S / MIME certificates. Several certificates can be created after registration, but they only contain the name after a certain number of proofs of identity. This can be done by members in a Web of Trust or other trusted bodies such as lawyers or accountants. Basically, issuing certificates by providers without verifying the identity of the applicant destroys the basic idea of ​​the secure exchange of information between two computers in the network. With some certificate issuers, for example, it is actually possible to obtain a certificate for a completely foreign website using fabricated operator information. The user would no longer be informed about a redirection of the information transmission, for example by the browser, if the certification authority was classified as trustworthy from the start by the browser manufacturer.

CAcert , a non-commercial, community-owned CA ( Certificate Authority ), provides free certificates. However, in many e-mail clients and web browsers it is not entered in the certificate database as a trusted certification authority. A user who establishes a connection to a server with a CAcert certificate or who receives an e-mail with an S / MIME certificate signed by CAcert will therefore receive the error message that the origin of the certificate could not be checked (unless CAcert was previously entered manually as trustworthy in the program).

Furthermore, free class 1 certificates (in some cases with a reduced period of validity of less than one year, for example as a test certificate) are offered by companies which, unlike CAcert, are also listed as trustworthy in the certificate databases of common software. However, these free S / MIME certificates are fully functional. Examples of these certificates, which are mostly intended for private use, are:

  • free secure email eID from WISeKey (1 year validity - attention: "private key" is generated by the server and is therefore known to the provider)
  • Secorio S / MIME (1 month validity, uses Comodo certificates)
  • GlobalSign as Free Trial PersonalSign 1 Certificate (valid for 30 days)
  • German Health Network (DGN) (valid for 1 year, class 2 - attention: "private key" is generated by the server and is therefore known to the provider)
  • ACTALIS SpA (1 year validity - attention: "private key" is generated by the server and is therefore known to the provider)

It is also possible to encrypt messages with a self-signed certificate. This requires a self-created root certificate that represents your own certification authority. In principle, any certificates can be signed with this. However, all communication partners must first import this root certificate and trust it before encrypted communication is possible.

With the help of SMIMEA, it is possible for the administrator of the domain to publish a (root) certificate via DNS and thus take over the authentication.

Security key generation

In order to use S / MIME certificates for encryption and signing, a key pair consisting of a public and a private key is required due to the public key encryption method used . Both keys can be created by a service provider. The creation of the private key by the service provider requires the trust that no copy / backup / log file or the like will remain with the service provider after it has been handed over. Reputable service providers Certificate Authorities (CAs) instead offer a procedure in which the private key is created by the customer and does not have to be handed over to the CA at any time. For this purpose, the customer transfers "his initial public key" to the CA via Certificate Signing Request (CSR request) and the CA generates the public certificate that can be verified worldwide.

Depending on the protection requirements, the private key and the CSR file can either be conveniently generated in the browser via a website provided by the CA or, at the other extreme, this can be done on a separate computer that is only procured and used for this purpose and via Console commands is operated. The CA's final public certificate is often sent by email. Reputable CAs offer each public certificate they generate in their own publicly accessible certificate directory, including a public revocation list.

For organizations that require a large number of S / MIME certificates, the CAs also offer special certificate manager administration programs with which the administration effort is reduced, even if the need for protection is increased.

Security S / MIME for e-mail

Various studies were carried out by a group of German security researchers in 2018 and 2019 on the security of signed and encrypted communication by email using S / MIME and PGP:

  • The cryptographic method is still secure, but the implementation as the S / MIME protocol has some conceptual weaknesses due to certain optional variants. These weaknesses were discussed in public under the catchphrase Efail . With RFC 8551 , the proposed changes were taken up as S / MIME 4.0 and Efail is also mentioned by name in the RFC.
  • In 2019, these studies were expanded to include the question of the extent to which commercially available e-mail software can be tricked when checking the signature on the recipient's side, if the signature is used via S / MIME as a CMS or on the attachment or an email Mail contains two signatures. The researchers communicated the vulnerabilities to the manufacturers before they were released, so some have already provided security updates.

Alternatives

As an alternative to S / MIME, PGP or OpenPGP can also be used using a public key infrastructure (PKI). However, the two methods are not compatible, even if they use the same encryption method in some cases, as they use different data formats. PGP / INLINE or PGP / MIME are common here . With Pretty Easy privacy , the use of S / MIME or PGP is to be automated and thus massively simplified.

See also

Norms and standards

S / MIME is constantly being developed:

  • RFC 2311 S / MIME Version 2 Message Specification (1998, obsolete)
  • RFC 2633 S / MIME Version 3 Message Specification (1999, obsolete)
  • RFC 3851 Secure / Multipurpose Internet Mail Extensions (S / MIME) Version 3.1 Message Specification (2004, obsolete)
  • RFC 5751 Secure / Multipurpose Internet Mail Extensions (S / MIME) Version 3.2 Message Specification (2010, obsolete)
  • RFC 8551 Secure / Multipurpose Internet Mail Extensions (S / MIME) Version 4.0 Message Specification (2019)

There is also another S / MIME series that deals with certificate handling and revocation lists:

  • RFC 2632 S / MIME 3.0 Certificate Handling (1999, obsolete)
  • RFC 3850 S / MIME 3.1 Certificate Handling (2004, obsolete)
  • RFC 5750 S / MIME 3.2 Certificate Handling (2010, obsolete)
  • RFC 8550 S / MIME 4.0 Certificate Handling (2019)

Web links

Individual evidence

  1. ↑ https://www.heise.de/newsticker/meldung/Vorsicht-bei-kostenlosen-SSL-Zertifikaten-137817.html
  2. ↑ Free Secure email eID https://account.wisekey.com
  3. ↑ https://www.secorio.com/de/faqs/smime-zertifikate/78-how-much-does-an-email-certificate-for-private-use-cost
  4. ↑ GlobalSign PersonalSign products https://www.globalsign.com/de-de/personalsign/
  5. ↑ DGNcert - The e-mail soft certificate from the German health network. Retrieved March 1, 2020 .
  6. ↑ ACTALIS Free Mail Certificate. Retrieved May 6, 2020 .
  7. ↑ Schlyter, Jakob, Hoffman, Paul: Using Secure DNS to Associate Certificates with Domain Names for S / MIME. Retrieved July 10, 2017 (English).
  8. ↑ a b Reiko Kaps: Another coffin nail. How CAs further undermine trust in SSL technology. In: c't . No. 14 , 2014, p. 46 f . ( heise.de [accessed November 25, 2018]).
  9. ↑ Fabian A. Scherschel: S / MIME and PGP: E-mail signature verification can be tricked. In: heise online. May 1, 2019, accessed May 4, 2019 .