EP1908253A1 - Method and system for transmitting a message, and a suitable key generator for this purpose - Google Patents

Abstract

A method for transmitting a message is disclosed, in which a sender first of all directs an enquiry to a directory service, the directory service using said enquiry as a basis for looking for a recipient address in a key directory (8), reading out a recipient key (7), which is associated with the recipient address in the key directory (8), if the key directory (8) contains the recipient address and informing the sender of said recipient key, in which the sender then encrypts the message using the recipient key (7) and transmits it to the recipient address, characterized in that, if the key directory (8) does not contain the recipient address, a key generator (12) generates a gateway key (13) in response to the enquiry and informs the sender of said gateway key, the sender then encrypting the message using the gateway key (13) and finally transmitting it to the recipient address via a mail gateway (11) which decrypts the message.

Description

 Method and system for transmitting a message, as well as a suitable

Key generator for this

The invention relates to a method and system for transmitting a message, according to the preamble of claim 1 and 11 and a suitable key generator in which a sender first sends a request to a directory service, based on which the directory service searches a recipient address in a key directory, if the key directory contains the recipient address, reads out a recipient address associated with the recipient key in the key directory and notifies the sender, the sender then encrypting the message by means of the recipient key and transmitting it to the recipient address.

Methods and systems of the aforementioned type are generally known. In recent years, the surge in the spread of "electronic mail" (so-called "e-mail") has made security issues related to this type of communication more relevant. In particular, larger companies, authorities and associations with a large number of employees, who are also physically distributed, increasingly ensure the authenticity and integrity by the use of electronic signatures and the confidentiality of the transmitted information through the use of cryptographic methods. In addition to various proprietary methods, standardized methods are used in particular which use either the "S / MIME"("Secure Multipurpose Internet Email Extension") for the formation of hierarchical certificate trees in accordance with the ITU ("International Telecommunication Union", www.itu. int) administered X.509 standard for PKI ("Public Key Infrastructure") or how OpenPGP ensures the identity of the certificate holder through a hierarchical "web of trust".

In addition to distribution, directory services are offered according to the known methods or system, via which keys can also be queried from international directories on the one hand for internal recipient addresses from in-house databases and on the other hand for external communication partners. S / MIME certificates are usually provided via directory services in accordance with LDAP ("Lightweight Directory Access Protocol"), because they can be queried by the usual e-mail front-ends.

The known methods or systems offer no way to enforce the encryption of e-mail traffic, because for external recipient addresses not (or only in exceptional cases) in principle the existence of keys can be assumed. Since recipient addresses without a key can only process unencrypted e-mails, blocking unencrypted communication would also cut off any e-mail exchange with these recipients.

If unencrypted communication is permitted in a LAN, the confidentiality of eMails is basically not guaranteed due to the technically conditioned "publicity" in a packet-switched network: Any unencrypted eMail - including, for example, a "board e-mail" with personal or strategic content - can low technical effort by each participant in the network to be read.

Additional security issues raise unencrypted in-house communication when employees receive and write e-mails via mobile devices via so-called push services. In a well-known implementation Such a push service, a push server is quasi integrated as an internal subscriber in the LAN and mediated via its own Internet connection to several globally distributed node computer of the provider and the services of various mobile operators eMail communication with the mobile devices.

Such a push server could theoretically take in the LAN due to the rights required for the execution of his task access to all distributed eMails in the network and forward them via the node computer. Since the node computers are out of the control of the operator of the LAN, its security and trustworthiness can not be ensured and verified. At least theoretically, there is a risk that information will fall into unauthorized hands.

Furthermore, if unsigned communication is also permitted in the LAN, then the authenticity and the identity of each such e-mail is fundamentally in question, because e-mails with a falsified identity could be sent or intercepted and subsequently changed. Unsigned e-mails should not only be treated as a legally binding declaration of intent - where unauthorized communication is permitted, the intentional dissemination of false reports aimed at discrediting other persons ("bullying") is not allowed and / or unsigned communication also in the company LAN regularly both the technical administrative effort, as well as the requirements for the definition (and the control of compliance) of behavioral rules for communication.

task

The invention has for its object to enable the encryption of all messages in a LAN, without restricting the selection of communication partners.

solution

This object is achieved procedurally with the features of claim 1 and device technology with the features of claim 11 or 24th

According to the application, it is proposed that, if the key directory does not contain the recipient address, a key generator generates a gateway key and notifies the sender, the sender then encrypting the message by means of the gateway key and via a mail gateway (11) which decrypts the message , finally sent to the recipient address.

According to the application, a sender is always notified of a key that is suitable for encrypting the message, namely either the recipient key or the gateway key, on the basis of a request from the directory service or from the key generator. The encryption of a message sent by the mail server from senders from the LAN to any recipient address is thus independent of whether there is a recipient key to the recipient address in an internal or external key directory. The communication with recipient addresses, to which no recipient key could be determined on the request, nevertheless unrestricted by the inventive method, since in this case the sender is encrypted with the gateway key: Reached From the LAN a message encoded with this gateway key message the mail gateway, then this is first decrypted and forwarded in decrypted form (ie in plain text) to the external recipient address. In conjunction with appropriate behavioral rules for e-mail communication or even by means of technical measures that prohibit or make impossible the unencrypted transmission of messages in the LAN, the encryption of all messages transmitted by senders in the LAN via the mail gateway can ensure.

The method or system according to the application can also be used in a comparable form with other message push services. Such services are characterized by the communication according to a "store-and-forward" principle, which does not provide for the interrogation of a recipient key in dialogue with the recipient.The term "mail gateway" in this case includes gateways for such push services.

Advantageous developments of the objects according to the application are described with the features of the subclaims.

Advantageously, the validity of the recipient address can be checked before the key generation, because the encryption makes sense only if the recipient can read them as well. For this he must either get the associated private key made available or someone else must decrypt the email for him. Furthermore, the email address must exist and be written correctly.

The verification of the validity of the recipient address can advantageously be done by a request to the e-mail server of the recipient. On the other hand, another alternative is querying the directory service, in particular public directory service, of the recipient, if such is known. If that Sender is provided no key for the recipient address, he recognizes before sending the e-mail that the recipient address does not exist. Depending on the configuration of his email client, he can not send the email at all. It avoids that a potentially confidential eMail remains because of undeliverability in the Internet or z. B. is forwarded to an administrator for manual troubleshooting. This is usually not allowed to see the content, but this is always possible with an unencrypted email.

The query with an internal directory service advantageously additionally offers the possibility of obtaining meta information about the receiver (real name, position in the organizational structure, title, etc.). Thus, the generated certificate can contain more information than the pure email address. This corresponds to z. For example, in X.509, the normal case is when certificates are issued manually by a PKI. An external sender gets a higher quality certificate with additional, possibly helpful information provided.

Unwanted meta-information can of course be suppressed. Furthermore, it is advantageous, based on the meta-information, to control properties of the generated certificate, for example key length, validity period, key withdrawal authorities, or -exhibition. Specifically, when a central gateway cooperates with different key generation authorities (CA), one can see from the meta information which CA is responsible for key generation.

In the context of the method or system according to the application, the key generator preferably generates a gateway key personalized to the recipient address. Such an application according to the method or system allows the sender in the LAN and the use of widespread email front-ends (such as Microsoft® Outlook®), in relation to the Standards of limited functionality only allow the use of personalized certificates.

Particularly preferably, the gateway key is assigned in the key directory of the recipient address. The gateway key is then available after its generation on the occasion of a first request for further requests from the LAN without recalculation. On the one hand, such a method or system requires less computational effort than a method without storage of the gateway key (in the case of storage costs that are irrelevant in view of the prices for storage media). On the other hand, it must be ensured that a message encrypted with the gate key at the sender can still be decrypted by the mail gateway even if it arrives at the mail gateway some time later. The validity period of a gateway key is here preferably limited to a few days, for example to one week. The Gatewayschiüssei can be stored in particular in a key generator directly assigned cache.

In an advantageous embodiment, the key generator together with the gateway key generates a decryption key assigned to it, and the mail gateway decrypts the message by means of the decryption key. Such a method or system thus uses an asymmetric encryption method in which a message is encrypted at the sender with a public key (here: with the gateway key) and at the receiver (here: the mail gateway) with a secret, only this known "private" key (here: with the decryption key) is decrypted .. Compared to an alternatively usable symmetric

Encryption techniques, where the same key is used for encryption and decryption, asymmetric encryption is less vulnerable to unintentional spreading of the key required for decryption. Particularly preferably, the gateway key is part of a certificate. In particular, S / MI ME certificates, due to their widespread use and implementation in all relevant frontends, usually allow the execution of the method according to the invention even without additional programs.

The message is preferably transmitted by the sender via a mail server to the recipient address. In particular, the mail server can be part of the internal infrastructure of the LAN, as is usual with larger corporate networks. The mail gateway is then usually located between the mail server and the Internet. Alternatively, the inventive method can also be used in the context of a LAN without its own mail server, if the individual employees in the LAN refer their e-mail messages from an external SMTP server.

Advantageously, existing mail gateways can use a key generator to sign outgoing e-mails with a previously missing key. Further advantageous embodiments are the subject of the other claims.

embodiment

The object according to the application will be explained below with reference to an embodiment. The drawing figures represent schematically different aspects of the execution of the method or system according to the application. It shows

1 shows the handling of keys,

Fig. 2, the integration of a push server and Fig. 3, the integration of a virus and spam protection.

As shown in FIG. 1, in a wired company-internal LAN 1, screen workstations 2 and mobile terminals 3 of employees 4 are networked with one another. An internal certification authority 5 provides the employees 4 personalized keys 6 for signing e-mails, for example, on a hardware token (not shown). The public recipient key 7 for encrypting e-mails to the employees 4 publishes the internal certification authority 5 together with the associated meta-information of the employees 4 in an in-house key directory 8.

The communication of the employees 4 from the LAN 1 with external partners 9 via the Internet 10 is conducted via a mail gateway 11. The designation "Gateway" (based on the nomenclature according to the OSI layer model according to ISO 7498-1 or DIN ISO 7498) makes it clear here that - in contrast to the exclusively forwarding functionality of the mail server - the form and content of the transmitted data are displayed here In the case shown here, the mail gateway 11 ensures (in cooperation with other components shown below) that the email messages distributed in the LAN 1 are always both signed and encrypted-regardless of this whether they were encrypted to partners 9 forwarded or signed or received encrypted by them.

If an employee wants to write an e-mail to an external partner 9, he first selects his recipient address in his (not shown) frontend. The frontend automatically sends a request to a directory service, which first attempts to determine a receiver key 7 in the local key directory 8 and then in various external key directories (not shown) based on the recipient address. to encrypt the email. If successful, the determined recipient key 7 is forwarded to the frontend. If the request succeeds only in one of the external directories, the determined recipient key 7 is buffered in the local key directory 8 for later use.

If the request succeeds neither at the local key directory 8 nor at the external key directories, the request is forwarded to a key generator 12 connected to the mail gateway 11, which generates a public gateway key 13 for the recipient address and sends it to the front end. At the same time, the key generator 12 generates a "private" decryption key 14 and forwards it to the mail gateway 11. The frontend encrypts the email with the gateway key 13 and sends it to the mail gateway 11. The mail gateway 11 decrypts the email using the decryption key 14 and forwards it - unencrypted - via the Internet 10 to the external partner 9 on.

The use of the mail gateway 11 allows within the LAN 1 including the internal mail server 15 and connected to this according to Figure 2 push server 16, the signing and encryption of the entire e-mail communication.

FIG. 3 shows the integration of a spam and virus scanner 17 into the gateway architecture. It is arranged between the internal mail gateway 11 and a second, external mail gateway 18. The external mail gateway 18 has access (not shown) to another personal key 19 of the employees 4. (The keys 6 and 19 of the employees 4 may be identical.) On the basis of this key 19, the external mail gateway 18 decrypts each from the outside for the Employee 4 encrypts incoming e-mail communication and forwards it to the spam and virus scanner 17. Will the incoming E-mail complained of this, it is an automatic message to the recipient with instructions for further action. If the e-mail is not objected to, then it is provided with a note on this to the internal mail gateway 11, which encrypts it with the public key of the recipient and signed, for example, with the decryption key 14 of the internal mail gateway 11.

In the same way, any not signed or not encrypted from the Internet 10 incoming e-mail is provided with a corresponding note and subsequently encrypted with the public key of the recipient and in turn signed, for example, with the decryption key 14 of the internal mail gateway 11. The mail server 15 is also configured in such a way that unencrypted or unsigned e-mails are not forwarded to the recipient, but are returned to the sender with an error message. In combination with the described functionality of the internal mail gateway 11, in particular in connection with the key generator 12, it is thus ensured that each e-mail communication distributed over the LAN 1-including the communication via the push server-is both signed and encrypted.

In principle, the advantageous use of the check for the validity of the recipient address should again be shown here. It should be noted that if the sender and the gateway or directory service belong to his organization and outgoing emails, i. toward the Internet or the like, must be encrypted, any recipient come into consideration.

If an external sender wants to send e-mails to an organization with gateway and directory service, only recipients within the domain will get the domain name Organization in question. Furthermore, there should be actual mailboxes for the email address.

It is therefore advantageous, before generating a key pair, to check whether the requested e-mail address lies within its own domain (s) and whether there is a mailbox for this purpose. The former is possible by examining a corresponding set of rules. The latter can be checked by a request to an internal user directory or to the internal mail server.

This ensures that no keys with non-existent e-mail addresses come into circulation. The sender recognizes early that he z. B. has lost in the spelling of eMailadresse. In addition, the key generation service is relieved because it does not have to generate meaningless keys.

Furthermore, the key and possibly the private key for archiving can be transmitted to the internal directory. It is advantageous to be able to protect the security against data loss as well as the ability to decrypt later encrypted versions of e-mails. Optionally, the central provision of the keys is also an organizational or legal requirement.

In principle, it should be emphasized that several internal directory services or e-mail servers can be requested.

Figures are:

LAN VDU workstation mobile terminal employee internal certification authority personalized key receiver key external partner directory Internet (internal) mail gateway key generator gateway key "private" decryption key mail server pushserver spam and virus scanner external mail gateway personal key

Claims

claims A method for transmitting a message, wherein a sender first makes a request to a directory service on the basis of which the directory service in a key directory (8) searches for a recipient address, if the key directory (8) contains the recipient address, one of the recipient address in the key directory ( 8) assigned recipient key (7) and this tells the sender, then the sender encrypts the message by means of the recipient key (7) and transmitted to the recipient address, characterized in that the request, if the key directory (8) is not the recipient address contains, a key generator (12) generates a gateway key (13) and this informs the sender, then the sender encrypted the message by means of the gateway key (13) and finally via a mail gateway (11), which decrypts the message to the recipient address overmi ttelt. 2. The method of claim 1, wherein the validity of the recipient address is checked. 3. The method of claim 2, wherein the validity of the recipient address is made by checking the e-mail server of the recipient. 4. The method of claim 2, wherein the validity of the recipient address by checking at a directory service, preferably public directory service, the recipient takes place. 5. The method according to any one of claims 2 to 4, wherein after successful examination for validity of the receiver address additional meta information is provided. 6. The method according to the preceding claim, characterized in that the key generator (12) generates a personalized to the recipient address gateway key (13). 7. The method according to any one of the preceding claims, characterized in that the gateway key (13) in the key directory (8) is assigned to the recipient address. 8. The method according to any one of the preceding claims, characterized in that the key generator (12) together with the gateway key (13) generates a decryption key associated with this (14) and the mail gateway (11) decrypts the message by means of the decryption key (14). 9. Method according to the preceding claim, characterized in that the gateway key (13) is part of a certificate. 10. The method according to any one of the preceding claims, characterized in that the message is transmitted from the sender via a mail server to the recipient address. 11. A system for transmitting a message, in particular for carrying out the method according to one of claims 1 to 10, comprising means for a directory service receiving a request from a sender, wherein the means for the directory service in a means for a key directory ( 8) searches a recipient address, characterized in that a key generator is provided which generates a gateway key based on the request if the key directory does not contain the recipient address. 12. The system of claim 11, wherein means for verifying the validity of the recipient address is provided. 13. The system of claim 12, wherein the validity of the recipient address is carried out by checking the e-mail server of the recipient. The system of claim 12, wherein the validity of the recipient address is established by checking at a public directory service of the recipient. 15. System according to any one of claims 12 to 14, wherein after successful examination for validity of the receiver address additional meta-information is provided. 16. System according to any one of claims 11 to 15, characterized in that a means for encrypting the message by means of the gateway key is provided. 17. System according to any one of claims 11 or 16, characterized in that a means for signing the message by means of the gateway key is provided. 18. System according to any one of claims 11 to 17, characterized in that a mail gateway is provided for signing. 19. System according to any one of claims 11 to 18, characterized in that a mail gateway is provided for decrypting the message. 20. System according to any one of claims 11 to 19, characterized in that the key generator (12) has generated a personalized to the recipient address gateway key (13). 21. System according to any one of claims 11 to 20, characterized in that the gateway key (13) is assigned to the key directory of the recipient address. 22. System according to any one of claims 11 to 21, characterized in that the key generator (12) together with the gateway key (13) generates a decryption key associated with this (14) and the mail gateway (11) decrypts the message by means of the decryption key (14) , 23. System according to any one of claims 11 to 22, characterized in that the gateway key (13) is part of a certificate. 24. A key generator, in particular for use in the method according to one of claims 1 to 10, or for use in the system according to one of claims 11 to 23, which generates a gateway key due to a request by a sender to a directory service. 25. The key generator according to claim 24, wherein the gateway key is generated when a key directory does not contain the requested by the sender recipient address.