The digital signature of an email has nothing to do with the familiar email signatures (often ASCII drawings, address and contact data); the content of these email signatures - unlike the digital signature - is part of the message and can be forged just as easily as the message itself. Electronic signature, in turn, is a legal term from the area of the Signature Act (SigG).
Digitally signed and/or encrypted emails can make email communication much more secure, with 2 levels:
With unsigned emails, you can generally never be sure who sent the message and whether it has been modified!
With non-encrypted emails, you never know who else can read it.
Regardless of the use of end-to-end encryption (E2EE) with S/MIME, PGP, …, emails should be transported as securely as possible: the SMTP server ("outgoing mail server") should absolutely support SMTPS or Mail Submission (and enforce the use - like at Graz University of Technology), the IMAP server ("incoming mail server") should be able to handle IMAPS (and enforce the use as well) and also the transmission between the sending and the receiving server should only be encrypted (ESMTP/TLS).
In addition to a true end-to-end solution, it would also be possible to work with gateways that sign and (if possible) encrypt the messages, but the advantage over the use of ESMTP and e. g. DKIM is small; confidentiality may be conveyed that is not at all given, because the message is then available in plain text from the gateway (which in turn makes it possible to examine the emails for malware or spam, which is not possible centrally with end-to-end encryption).
f possible, emails should always be digitally signed, but digitally encrypted only if the content requires iti due to
There are 2 common variants of digital email signatures:
Both variants work with asymmetric encryption (public key/private key) and for both variants there are add-ons for many email programs with which the transparent can be integrated into the email client. For example, the program Thunderbird can handle S/MIME directly, and the add-on Enigmail for PGP is now also a fixed component. For webmail versions that do not support PGP directly (e. g., OWA), there is, for example, the browser extension Mailvelope.
With (Open)PGP or GnuPG you only work with self-generated key pairs, the extension PGP/MIME then ensures that attachments are also encrypted. For the S/MIME standard there is a whole range of certificate providers (Certifcate Authority - CA), which then confirm that a public key belongs to a person (and generally also generate the key pair). Some of these CAs also offer certificates free of charge.
So the main difference is that in one case (S/MIME) you trust a certificate provider (and all certificates issued by him), in the other case (PGP) you need mutual trust or there is a WoT: you authenticate the keys of people you know (keysigning party), which then allows you to trust the keys of unknown people (A trusts B, A sees that B also trusts C and thus A can now trust C as well).
With both variants, one must also trust that the cryptographic methods have been implemented without errors and that there are no unknown solutions for the underlying mathematical functions or that there is no hardware with which the mathematical problem can be solved significantly faster than estimated (quantum computer!).
Where Can I Get an S/MIME Certificate?
If a designated person has multiple profiles (such as staff and students), then he or she can currently only order a certificate for the staff email address. Furthermore, we may only issue certificates for addresses for which we can centrally guarantee the assignment of person ⇔ email address, which are all addresses on the central email servers of ZID.
These certificates are person-related, i. e. it is therefore not possible to obtain certificates for function-related email addresses (e. g. postmaster, office, …) via the aforementioned interface, should such be required, please submit an appropriate request.
If you need a S/MIME certificate for another address (e. g. your address at the institute email server), you have to contact one of the many providers, a few still offer this for free, e. g. Actalis S.p.A. (validity: 1 year) or WISeID (validity: 3 months).
As mentioned above, there are 2 ways of using it: the digital signature and the encryption.
For the digital signature, sender A only needs his key pair: a hash (a kind of fingerprint) is generated from the message he wants to send and this is encrypted with the sender's private key and then appended to the message together with sender A's public key.
Recipient B can then verify that the email actually comes from sender A (either because he also trusts the certificate provider or via the WoT of this signature).
Furthermore, B can verify that the message is unchanged by also generating the hash value and comparing it with the hash value sent along, which he decrypts with the public key of sender A (the email program does this automatically and displays the result).
To encrypt messages, you need the public key of the recipient.
In the above example, B has already received A's public key in A's last email. B can now encrypt the entire message with A's public key and sign it with his own private key (this is also done completely automatically by the email program if the appropriate settings are made).
A can then decrypt B's message with his own private key and now also has B's public key, so from now on they can communicate in encrypted form (completely automatically).
If already the first email has to be encrypted, one must first somehow get to the public key of the other - this works either through a PKI (for PGP e. g. through so-called "Public Key Servers") or more simply by storing these keys e. g. on the homepage (for PGP best in ASCII format, for S/MIME in DER or PEM format) - example:
PGP and S/MIME.
In this case the key has to be imported manually, insofar it is easier if A simply asks B for a signed email.
After installing their own certificates and activating the function, modern email clients sign and encrypt/decrypt automatically without any further action on the part of the sender and recipient, and only display the result (valid or not valid). I. e. after a relatively small configuration effort the sending and receiving runs as usual, only one gets also with each email then indicated whether everything is o. k. and with encrypted emails one can be sure that these can't be read by anyone else, encrypted emails to the own address cannot be read thus also e. g. by the administrators. If the certificate gets lost (replacement of computer!) or one forgets the associated password, then this information can't be read any longer.
| Unfortunately, however, some (webmail) clients (GMX?) can't really handle this and instead of showing an icon for a valid signature, these clients display an attachment they can't open - so if you are addressed to an attachment smime.p7s that can't be opened, point out your digital signature! |
Verification of TCS Certificates with Thunderbird
In order for Thunderbird to automatically verify these signatures, you may first need to confirm in the certificate manager that you accept these GÉANT certificates for email signature.
To accept the certificates for email, switch to the "Certificate Authorities" tab in the certificate management and select the "GÉANT Personal CA" via "The USERTRUST Network". Via "Edit Trust…" you then confirm that you accept these certificates for email.
Your email client should then show you whether an email is encrypted or just signed and whether the signature is correct.
If a signature is displayed as invalid, this can have several causes. You can find out the details by clicking on the corresponding icon.
Possible reasons can be e. g.:
Critical in the first place is if the email has been changed afterwards, but this cannot be checked for HTML emails with external content.
