E-mail encryption and e-mail signing
First of all, an e-mail is like a postcard: anyone who holds it in their hands (or through whose server it is routed) can read or process the content. And an e-mail is also like a postcard in another aspect: you don't know whether the sender is really who he claims to be.
There are solutions for this:
- Content encryption (e.g. S/MIME or OpenPGP): the e-mail is encrypted with the recipient's public key and decrypted again with the private key known only to the recipient.
- Transport encryption (e.g. STARTTLS): The e-mail itself remains unencrypted, but the transport channel between two mail servers is encrypted. Further options can be added: should the encryption be enforced or only offered? Should the identity also be checked or only encryption be established?
- Signature by the user (e.g. S/MIME or OpenPGP): The e-mail is signed with the sender's private key and the signature is verified with the sender's public key.
- Signature by server (e.g. DKIM): The sending e-mail server signs the e-mail with its private key, the recipient retrieves the public key from the Domain Name Service (DNS) and verifies the signature.
Die verschiedenen Methoden aber unterschiedliche Vor- und Nachteile und Möglichkeiten der Implementierung: Ende zu Ende, Server zu Server oder Kombinationen daraus - mit unterschiedlichem Aufwand was den Austausch von Schlüsselmaterial und die Anwenderfreundlichkeit und Transparenz für den Endanwender angeht.
Wir beraten Sie gern bei der Auswahl der zu Ihren Sicherheitsanforderungen passenden Verschlüsselungslösungen!
Trust Store Management
To ensure that data is transmitted really securely, it is not enough to encrypt it only according to the state of the art.It also requires checking the authenticity of the communication partner. After all, it doesn't help if an e-mail is transmitted through an encrypted secure channel that doesn't lead to the recipient at all but to an attacker. Or if you encrypt the content according to the best available technology, but use a key that has been foisted on you by an attacker.
Theoretically, you can verify and deposit each individual public key/certificate manually - or you can check via a "trust anchor": You trust the issuer of a certificate (the so-called root CA) or a certain intermediate certificate and check via cryptographic methods whether the transmitted certificate was issued by this CA and is valid.And there can be a wide variety of requirements depending on the security requirements and protection classes/objectives, which also depend on who the issuer of the certificate is and how intensively the identity of the certificate holder has been checked.It is also possible that the same issuer has different certificate chains for strict and less strict checks (e.g. domain validated, organization validated, extended validation).
In a trust store or key store, all trust anchors are stored from which trust on individual certificates can be derived.
We provide support here in the selection and maintenance of trust stores for your specific requirements or the verification of keys / certificates of business partners.