EP1908253A1 - Verfahren und system zur übermittlung einer nachricht, sowie ein geeigneter schlüsselgenerator hierfür - Google Patents

Verfahren und system zur übermittlung einer nachricht, sowie ein geeigneter schlüsselgenerator hierfür

Info

Publication number
EP1908253A1
EP1908253A1 EP06776437A EP06776437A EP1908253A1 EP 1908253 A1 EP1908253 A1 EP 1908253A1 EP 06776437 A EP06776437 A EP 06776437A EP 06776437 A EP06776437 A EP 06776437A EP 1908253 A1 EP1908253 A1 EP 1908253A1
Authority
EP
European Patent Office
Prior art keywords
key
gateway
recipient
recipient address
directory
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06776437A
Other languages
English (en)
French (fr)
Inventor
Henning Seemann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Utimaco Safeware AG
Original Assignee
Utimaco Safeware AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=37114695&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=EP1908253(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Priority claimed from DE102005035482A external-priority patent/DE102005035482A1/de
Application filed by Utimaco Safeware AG filed Critical Utimaco Safeware AG
Publication of EP1908253A1 publication Critical patent/EP1908253A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Definitions

  • 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.
  • 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.
  • LDAP Lightweight Directory Access Protocol
  • eMails are 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.
  • 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.
  • 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.
  • the invention has for its object to enable the encryption of all messages in a LAN, without restricting the selection of communication partners.
  • 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.
  • 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 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.
  • 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.
  • 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.).
  • the generated certificate can contain more information than the pure email address. This corresponds to z.
  • 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.
  • CA key generation authorities
  • the key generator preferably generates a gateway key personalized to the recipient address.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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 ..
  • a public key here: with the gateway key
  • the receiver here: the mail gateway
  • 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.
  • the gateway key is part of a certificate.
  • 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.
  • 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.
  • 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.
  • 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.
  • Fig. 2 the integration of a push server and Fig. 3, the integration of a virus and spam protection.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.)
  • 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.
  • 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.
  • 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.
  • the central provision of the keys is also an organizational or legal requirement.
  • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Storage Device Security (AREA)

Abstract

Offenbart ist ein Verfahren zur Übermittlung einer Nachricht, wobei ein Absender zunächst eine Anfrage an einen Verzeichnisdienst richtet, aufgrund derer der Verzeichnisdienst in einem Schlüsselverzeichnis (8) eine Empfängeradresse sucht, sofern das Schlüsselverzeichnis (8) die Empfängeradresse enthält, einen der Empfängeradresse in dem Schlüsselverzeichnis (8) zugeordneten Empfängerschlüssel (7) ausliest und diesen dem Absender mitteilt, wobei sodann der Absender die Nachricht mittels des Empfängerschlüssels (7) verschlüsselt und an die Empfängeradresse übermittelt, dadurch gekennzeichnet, dass auf die Anfrage, sofern das Schlüsselverzeichnis (8) die Empfängeradresse nicht enthält, ein Schlüsselgenerator (12) einen Gatewayschlüssel (13) generiert und diesen dem Absender mitteilt, wobei sodann der Absender die Nachricht mittels des Gatewayschlüssels (13) verschlüsselt und über ein Mailgateway (11), das die Nachricht entschlüsselt, schließlich an die Empfängeradresse übermittelt.

Description

Verfahren und System zur Übermittlung einer Nachricht, sowie ein geeigneter
Schlüsselgenerator hierfür
Die Erfindung betrifft ein Verfahren bzw. System zur Übermittlung einer Nachricht, nach dem Oberbegriff des Anspruchs 1 und 11 sowie ein geeigneter Schlüsselgenerator, bei denen ein Absender zunächst eine Anfrage an einen Verzeichnisdienst richtet, aufgrund derer der Verzeichnisdienst in einem Schlüsselverzeichnis eine Empfängeradresse sucht, sofern das Schlüsselverzeichnis die Empfängeradresse enthält, einen der Empfängeradresse in dem Schlüsselverzeichnis zugeordneten Empfängerschlüssel ausliest und diesen dem Absender mitteilt, wobei sodann der Absender die Nachricht mittels des Empfängerschlüssels verschlüsselt und an die Empfängeradresse übermittelt.
Verfahren bzw. Systeme der vorgenannten Art sind allgemein bekannt. In den vergangenen Jahren haben durch den sprunghaften Anstieg der Verbreitung der „elektronischen Post" (so genannter „eMail") Sicherheitsfragen im Zusammenhang mit dieser Art der Kommunikation eine gesteigerte Relevanz erhalten. Insbesondere größere Firmen, Behörden und Verbände mit einer Vielzahl von zudem räumlich verteilt Mitarbeitenden gewährleisten zunehmend durch die Verwendung von elektronischen Signaturen die Authentizität und Integrität und durch den Einsatz von kryptographischen Verfahren die Vertraulichkeit der übermittelten Informationen. Neben verschiedenen proprietären Verfahren kommen hierbei insbesondere standardisierte Verfahren zum Einsatz, die entweder die „S/MIME" („Secure Multipurpose Internet eMail Extension") auf der Bildung hierarchischer Zertifikatsbäume gemäß dem von der ITU („International Telecommunication Union", www.itu.int) administrierten X.509-Standard für PKI („Public-Key-Infrastruktur") basieren, oder wie OpenPGP durch ein hierarchieloses „Web of Trust" die Identität des Zertifikatsinhabers gewährleisten.
Neben der Verteilung werden nach den bekannten Verfahren bzw. System Verzeichnisdienste angeboten, über die Schlüssel einerseits für interne Empfängeradressen aus hausinternen Datenbanken und andererseits für externe Kommunikationspartner außerdem aus internationalen Verzeichnissen abgefragt werden können. S/MIME-Zertifikate werden hierbei zumeist über Verzeichnisdienste gemäß LDAP („Lightweight Directory Access Protocol") bereitgestellt, weil diese von den üblichen eMail-Frontends abgefragt werden können.
Die bekannten Verfahren bzw. Systeme bieten keine Möglichkeit, die Verschlüsselung des eMail-Verkehrs zu erzwingen, weil für externe Empfängeradressen nicht (oder nur in Ausnahmefällen) grundsätzlich die Existenz von Schlüsseln angenommen werden kann. Da Empfängeradressen ohne Schlüssel nur unverschlüsselte eMails verarbeiten können, würde die Unterbindung unverschlüsselter Kommunikation zugleich jeden eMail-Austausch mit diesen Empfängern kappen.
Wird in einem LAN unverschlüsselte Kommunikation zugelassen, so ist aufgrund der technisch prinzipiell bedingten „Öffentlichkeit" in einem paketvermittelten Netzwerk die Vertraulichkeit von eMails grundsätzlich nicht gewährleistet: Jede unverschlüsselte eMail - auch beispielsweise eine „Vorstands-eMail" mit personenbezogenem oder strategischem Inhalt - kann mit geringem technischen Aufwand von jedem Teilnehmer am Netz mitgelesen werden.
Zusätzliche Sicherheitsfragen wirft unverschlüsselte firmeninterne Kommunikation auf, wenn Mitarbeitende über so genannten Push-Dienste eMails mittels mobiler Endgeräte empfangen und schreiben. In einer allgemein bekannten Implementation eines solchen Push-Dienstes wird ein Push-Server quasi als interner Teilnehmer in das LAN eingebunden und vermittelt über eine eigene Internetanbindung an mehrere weltweit verteilte Knotenrechner des Anbieters und die Dienste verschiedener Mobilfunkanbieter die eMail-Kommunikation mit den mobilen Endgeräten.
Ein solcher Push-Server könnte dabei theoretisch in dem LAN aufgrund der für die Ausführung seiner Aufgabe erforderlichen Rechtestruktur Zugriff auf alle im Netzwerk verteilten eMails nehmen und diese über die Knotenrechner weiterleiten. Da die Knotenrechner außerhalb der Kontrolle des Betreibers des LAN sind, kann aus dessen Sicht deren Sicherheit und Vertrauenswürdigkeit nicht sichergestellt und nachgeprüft werden. Damit besteht zumindest theoretisch die Gefahr, dass Informationen in nicht autorisierte Hände fallen.
Ist darüber hinaus im LAN auch unsignierte Kommunikation erlaubt, so steht zudem die Authentizität und die Identität jeder derartigen eMail grundsätzlich in Frage, weil eMails mit gefälschter Identität versandt oder abgefangen und nachträglich verändert werden könnten. Unsignierte eMails dürfen nicht nur prinzipiell nicht als rechtlich wirksame Willenserklärung behandelt werden - wo unsignierte Kommunikation zugelassen wird, ist zudem die absichtliche Verbreitung von Falschmeldungen mit dem Ziel, andere Personen zu diskreditieren („Mobbing") grundsätzlich nicht zu verhindern. Insgesamt erhöht die Zulassung unverschlüsselter und/oder unsignierter Kommunikation auch im firmeninternen LAN regelmäßig sowohl den technischadministrativen Aufwand, als auch die Anforderungen an die Definition (und die Kontrolle der Einhaltung) von Verhaltensmaßregeln für die Kommunikation.
Aufgabe
Der Erfindung liegt die Aufgabe zugrunde, in einem LAN die Verschlüsselung aller Nachrichten zu ermöglichen, ohne die Auswahl der Kommunikationspartner einzuschränken.
Lösung
Gelöst wird diese Aufgabe verfahrenstechnisch mit den Merkmalen des Anspruchs 1 und vorrichtungstechnisch mit den Merkmalen des Anspruchs 11 oder 24.
Anmeldungsgemäß wird vorgeschlagen, dass auf die Anfrage, sofern das Schlüsselverzeichnis die Empfängeradresse nicht enthält, ein Schlüsselgenerator einen Gatewayschlüssel generiert und diesen dem Absender mitteilt, wobei sodann der Absender die Nachricht mittels des Gatewayschlüssels verschlüsselt und über ein Mailgateway (11), das die Nachricht entschlüsselt, schließlich an die Empfängeradresse übermittelt.
Anmeldungsgemäß wird einem Absender auf eine entsprechende Anfrage von dem Verzeichnisdienst oder von dem Schlüsselgenerator immer ein für die Verschlüsselung der Nachricht geeigneter Schlüssel - nämlich entweder der Empfängerschlüssel oder der Gatewayschlüssel - mitgeteilt. Die Verschlüsselung einer von dem Mailserver von Absendern aus dem LAN zu einer beliebigen Empfängeradresse vermittelten Nachricht ist so unabhängig davon, ob zu der Empfängeradresse in einem internen oder externen Schlüsselverzeichnis ein Empfängerschlüssel existiert. Die Kommunikation auch mit Empfängeradressen, zu denen auf die Anfrage kein Empfängerschlüssel ermittelt werden konnte, ist nach dem erfindungsgemäßen Verfahren gleichwohl uneingeschränkt möglich, da in diesem Fall beim Absender mit dem Gatewayschlüssel verschlüsselt wird: Erreicht aus dem LAN eine mit diesem Gatewayschlüssel verschlüsselte Nachricht das Mailgateway, dann wird diese zunächst entschlüsselt und in entschlüsselter Form (also in Klartext) an die externe Empfängeradresse weitergeleitet. In Verbindung mit entsprechenden Verhaltensmaßregeln für die eMail-Kommunikation oder auch mittels technischer Maßnahmen, die im LAN den unverschlüsselten Versand von Nachrichten verbieten oder unmöglich machen, kann die Verschlüsselung aller von Absendern im LAN über das Mailgateway vermittelten Nachrichten sicher stellen.
Das anmeldungsgemäße Verfahren bzw. System kann in vergleichbarer Form auch mit anderen Nachrichten-Pushdiensten zum Einsatz kommen. Derartige Dienste zeichnen sich aus durch die Kommunikation nach einem „store-and-forward"-Prinzip, das die Abfrage eines Empfängerschlüssels im Dialog mit dem Empfänger nicht vorsieht. Der Begriff „Mailgateway" umfasst in diesem Fall Gateways für derartige Pushdienste.
Vorteilhafte Weiterbildungen der anmeldungsgemäßen Gegenstände werden mit den Merkmalen der Unteransprüche beschrieben.
Vorteilhafterweise kann die Gültigkeit der Empfängeradresse vor der Schlüsselgenerierung geprüft werden, da die Verschlüsselung nur dann einen Sinn macht, wenn der Empfänger diese auch lesen kann. Dazu muss er entweder den zugehörigen privaten Schlüssel zur Verfügung gestellt bekommen oder jemand anderes muss für ihn die eMail entschlüsseln. Ferner muss die Emailadresse existieren und korrekt geschrieben werden.
Die Überprüfung der Gültigkeit der Empfängeradresse kann vorteilhafterweise durch eine Anfrage beim eMailserver des Empfängers erfolgen. Dem gegenüber ist eine weitere Alternative die Abfrage beim Verzeichnisdienst, insbesondere öffentlichen Verzeichnisdienst, des Empfängers, falls ein solcher bekannt ist. Wenn dem Absender kein Schlüssel für die Empfängeradresse zur Verfügung gestellt wird, erkennt er vor Absendung der eMail, dass die Empfängeradresse nicht existiert. Je nach Konfiguration seines eMailclients kann er die eMail so gar nicht absenden. Es wird damit vermieden, dass eine potentiell vertrauliche eMail wegen Unzustellbarkeit im Internet liegen bleibt oder z. B. zur manuellen Problembeseitigung an einen Administrator weitergeleitet wird. Dieser ist normalerweise nicht berechtigt, den Inhalt zu sehen, was aber bei einer unverschlüsselten eMail immer möglich ist.
Die Abfrage bei einem internen Verzeichnisdienst bietet vorteilhafterweise zusätzlich die Möglichkeit, Metainformationen über den Empfänger (Real Name, Position in der Organisationsstruktur, Titel, ... ) zu erlangen. Damit kann das erzeugte Zertifikat mehr Informationen enthalten als die reine eMailadresse. Dies entspricht z. B. bei X.509 dem Normalfall, wenn Zertifikate manuell durch eine PKI ausgestellt werden. Ein externer Absender bekommt so ein hochwertigeres Zertifikat mit zusätzlichen, ggf. hilfreichen Informationen zur Verfügung gestellt.
Unerwünschte Metainformationen können natürlich unterdrückt werden. Weiterhin ist es vorteilhaft basierend auf den Metainformationen Eigenschaften des erzeugten Zertifikats, beispielsweise Schlüssellänge, Gültigkeitsdauer, Autoritäten für Schlüsselzurückziehung, oder -austellung zu steuern. Speziell, wenn ein zentrales Gateway mit verschiedenen Schlüsselgenerierungsautoritäten (CA) zusammenarbeitet, kann man aus den Metainformationen entnehmen, welche CA für die Schlüsselerzeugung zuständig ist.
Bevorzugt generiert im Rahmen des anmeldungsgemäßen Verfahrens bzw. Systems der Schlüsselgenerator einen auf die Empfängeradresse personalisierten Gatewayschlüssel. Ein derartiges anmeldungsgemäßes Verfahren bzw. System ermöglicht beim Absender im LAN auch den Einsatz weit verbreiteter eMail- Frontends (wie beispielsweise Microsoft® Outlook®), die in gegenüber den Standards eingeschränkter Funktionalität nur die Verwendung personalisierter Zertifikate erlauben.
Besonders bevorzugt wird der Gatewayschlüssel in dem Schlüsselverzeichnis der Empfängeradresse zugeordnet. Der Gatewayschlüssel steht dann nach seiner Generierung aus Anlass einer ersten Anfrage bei weiteren Anfragen aus dem LAN ohne erneute Berechnung zur Verfügung. Ein derartiges Verfahren bzw. System erfordert einerseits gegenüber einem Verfahren ohne Speicherung des Gatewayschlüssels (bei angesichts der Preise für Speichermedien irrelevant erhöhtem Speicheraufwand) einen geringeren Berechnungsaufwand. Andererseits muss gewährleistet sein, dass eine mit dem Gateschlüssel beim Absender verschlüsselte Nachricht auch dann noch vom Mailgateway entschlüsselt werden kann, wenn sie erst einige Zeit später beim Mailgateway eintrifft. Die Gültigkeitsdauer eines Gatewayschlüssels wird hierbei vorzugsweise auf wenige Tage, beispielsweise auf eine Woche beschränkt. Der Gatewayschiüssei kann insbesondere in einem dem Schlüsselgenerator unmittelbar zugeordneten Cache gespeichert werden.
In einer vorteilhaften Ausführung generiert der Schlüsselgenerator gemeinsam mit dem Gatewayschlüssel einen diesem zugeordneten Entschlüsselungsschlüssel, und das Mailgateway entschlüsselt die Nachricht mittels des Entschlüsselungsschlüssels. Ein derartiges Verfahren bzw. System verwendet also ein asymmetrisches Verschlüsselungsverfahren, bei dem eine Nachricht beim Absender mit einem öffentlichen Schlüssel (hier: mit dem Gatewayschlüssel) verschlüsselt und beim Empfänger (hier: das Mailgateway) mit einem geheimen, nur diesem bekannten „privaten" Schlüssel (hier: mit dem Entschlüsselungsschlüssel) entschlüsselt wird. Gegenüber einem alternativ einsetzbaren symmetrischen
Verschlüsselungsverfahren, wobei derselbe Schlüssel zum Ver- und Entschlüsseln verwendet wird, ist die asymmetrische Verschlüsselung weniger anfällig gegen unbeabsichtigte Verbreitung des zur Entschlüsselung erforderlichen Schlüssels. Besonders bevorzugt ist der Gatewayschlüssel Teil eines Zertifikats. Insbesondere S/M I ME-Zertifikate ermöglichen aufgrund ihrer weiten Verbreitung und der Implementation in allen relevanten Frontends zumeist auch ohne zusätzliche Programme die Ausführung des erfindungsgemäßen Verfahrens.
Die Nachricht wird vorzugsweise von dem Absender über einen Mailserver an die Empfängeradresse übermittelt. Der Mailserver kann hierbei insbesondere - wie bei größeren Firmennetzwerken üblich - Teil der internen Infrastruktur des LAN sein. Das Mailgateway wird dann in der Regel zwischen dem Mailserver und dem Internet angeordnet. Alternativ kann das erfindungsgemäße Verfahren auch im Rahmen eines LAN ohne eigenen Mailserver eingesetzt werden, wenn die einzelnen Mitarbeitenden im LAN ihre eMail-Nachrichten von einem externen SMTP-Server beziehen.
Vorteilhafterweise können bestehende Mailgateways einen Schlüsselgenerator benutzen, um ausgehende eMails mit einem bisher nicht vorhandenen Schlüssel zu signieren. Weitere vorteilhafte Ausführungsformen sind Gegenstand der weiteren Ansprüche.
Ausführungsbeispiel
Der anmeldungsgemäße Gegenstand wird nachfolgend anhand eines Ausführungsbeispiels erläutert. Die Zeichnungsfiguren stellen schematisch unterschiedliche Aspekte der Ausführung des anmeldungsgemäßen Verfahrens bzw. Systems dar. Es zeigt
Fig. 1 die Handhabung von Schlüsseln,
Fig. 2 die Einbindung eines Push-Servers und Fig. 3 die Einbindung eines Viren- und Spamschutzes.
In einem kabelgebundenen firmeninternen LAN 1 sind gemäß Fig. 1 Bildschirmarbeitsplätze 2 und mobile Endgeräte 3 von Mitarbeitenden 4 untereinander vernetzt. Eine interne Zertifizierungsstelle 5 stellt den Mitarbeitenden 4 personalisierte Schlüssel 6 zum Signieren von eMails beispielsweise auf einem (nicht dargestellten) Hardwaretoken zur Verfügung. Die öffentlichen Empfängerschlüssel 7 zur Verschlüsselung von eMails an die Mitarbeitenden 4 veröffentlicht die interne Zertifizierungsstelle 5 zusammen mit den zugehörigen Meta-Informationen der Mitarbeitenden 4 in einem hausinternen Schlüsselverzeichnis 8.
Die Kommunikation der Mitarbeitenden 4 aus dem LAN 1 mit externen Partnern 9 über das Internet 10 wird über ein Mailgateway 11 geführt. Die (an die Nomenklatur gemäß dem OSl-Schichtenmodell gemäß ISO 7498-1 bzw. DIN ISO 7498 angelehnte) Bezeichnung „Gateway" verdeutlicht hierbei, dass - im Gegensatz zur ausschließlich weiterleitenden Funktionalität des Mailservers - an dieser Stelle Form und Inhalt der übermittelten Daten an die Erfordernisse des jeweiligen Empfängers angepasst werden. Das Mailgateway 11 stellt im hier dargestellten Fall (in Zusammenarbeit mit weiteren in der Folge dargestellten Komponenten) sicher, dass die in dem LAN 1 verbreiteten eMail-Nachrichten immer sowohl signiert, als auch verschlüsselt sind - unabhängig davon, ob sie verschlüsselt zu Partnern 9 weitergeleitet oder signiert oder verschlüsselt von diesen empfangen wurden.
Wenn ein Mitarbeitender eine eMail an einen externen Partner 9 schreiben möchte, wählt er in seinem (nicht dargestellten) Frontend zunächst dessen Empfängeradresse. Das Frontend sendet automatisch eine Anfrage an einen Verzeichnisdienst, der zunächst in dem lokalen Schlüsselverzeichnis 8 und anschließend in verschiedenen (nicht dargestellten) externe Schlüsselverzeichnissen versucht, anhand der Empfängeradresse einen Empfängerschlüssel 7 zu ermitteln, um die eMail zu verschlüsseln. Im Erfolgsfall wird der ermittelte Empfängerschlüssel 7 an das Frontend weitervermittelt. Ist die Anfrage erst bei einem der externen Verzeichnisse erfolgreich, so wird der ermittelte Empfängerschlüssel 7 für spätere Verwendung in dem lokalen Schlüsselverzeichnis 8 zwischengespeichert.
Ist die Anfrage weder bei dem lokalen Schlüsselverzeichnis 8, noch bei den externen Schlüsselverzeichnissen erfolgreich, so wird die Anfrage an einen mit dem Mailgateway 11 verbundenen Schlüsselgenerator 12 weitergeleitet, der für die Empfängeradresse einen öffentlichen Gatewayschlüssel 13 generiert und an das Frontend sendet. Zugleich generiert der Schlüsselgenerator 12 einen „privaten" Entschlüsselungsschlüssel 14 und reicht diesen an das Mailgateway 11 weiter. Das Frontend verschlüsselt die eMail mit dem Gatewayschlüssel 13 und sendet sie an das Mailgateway 11. Das Mailgateway 11 entschlüsselt die eMail anhand des Entschlüsselungsschlüssels 14 und leitet sie - unverschlüsselt - über das Internet 10 an den externen Partner 9 weiter.
Die Verwendung des Mailgateway 11 ermöglicht innerhalb des LAN 1 einschließlich des internen Mailservers 15 und eines an diesen gemäß Figur 2 angeschlossenen Pushservers 16 die Signierung und Verschlüsselung der gesamten eMail- Kommunikation.
Figur 3 zeigt die Einbindung eines Spam- und Virenscanners 17 in die Gatewayarchitektur: Dieser ist zwischen dem internen Mailgateway 11 und einem zweiten, externen Mailgateway 18 angeordnet. Das externe Mailgateway 18 hat (in nicht dargestellter Weise) Zugriff auf einen weiteren persönlichen Schlüssel 19 der Mitarbeitenden 4. (Die Schlüssel 6 und 19 der Mitarbeitenden 4 können identisch sein.) Anhand dieser Schlüssel 19 entschlüsselt das externe Mailgateway 18 jede von außen für die Mitarbeitenden 4 verschlüsselt eingehende eMail-Kommunikation und leitet diese an den Spam- und Virenscanner 17 weiter. Wird die eingehende eMail von diesem beanstandet, so erfolgt eine automatische Mitteilung an den Empfänger mit Anweisungen zum weiteren Vorgehen. Wird die eMail nicht beanstandet, so wird sie mit einem Hinweis hierauf versehen an das interne Mailgateway 11 weitergeleitet, das sie mit dem öffentlichen Schlüssel des Empfängers verschlüsselt und beispielsweise mit dem Entschlüsselungsschlüssel 14 des internen Mailgateways 11 signiert.
Auf dieselbe Weise wird auch jede nicht signiert oder nicht verschlüsselt aus dem Internet 10 eingehende eMail mit einem entsprechenden Hinweis versehen und nachträglich mit dem öffentlichen Schlüssel des Empfängers verschlüsselt und wiederum beispielsweise mit dem Entschlüsselungsschlüssel 14 des internen Mailgateways 11 signiert. Der Mailserver 15 ist außerdem derart konfiguriert, das unverschlüsselte oder unsignierte eMails grundsätzlich nicht an den Empfänger weitergeleitet, sondern mit einer Fehlermeldung an den Absender zurückgesandt werden. In Kombination mit der beschriebenen Funktionalität des internen Mailgateways 11 insbesondere in Verbindung mit dem Schlüsselgenerator 12 ist so sichergestellt, dass jede über das LAN 1 verbreitete eMail-Kommunikation - einschließlich der Kommunikation über den Push-Server - sowohl signiert als auch verschlüsselt ist.
An dieser Stelle sei grundsätzlich erneut die vorteilhafte Verwendung der Überprüfung auf Gültigkeit der Empfängeradresse dargestellt. Hierzu ist zu erwähnen, dass wenn der Absender und das Gateway bzw. der Verzeichnungsdienst zu seiner Organisation gehören und ausgehende Emails, d.h. in Richtung Internet oder dergleichen, verschlüsselt werden müssen, kommen beliebige Empfänger in Betracht.
Wenn ein externer Absender E-Mails an eine Organisation mit Gateway und Verzeichnisdienst schicken will, kommen nur Empfänger innerhalb der Domäne der Organisation in Frage. Weiterhin soll für die eMailadresse tatsächliche in Postfach existieren.
Vorteilhaft ist es darum vor der Erzeugung eines Schlüsselpaares zu prüfen, ob die angefragte eMailadresse innerhalb der eigenen Domäne(n) liegt und ob es dazu ein Postfach gibt. Ersteres ist durch Prüfung eines entsprechenden Regelwerkes möglich. Letzteres kann durch eine Anfrage an ein internes Benutzerverzeichnis oder an den internen Mailserver geprüft werden.
Damit wird sichergestellt, dass keine Schlüssel mit nicht existenten eMailadressen in Umlauf kommen. Der Absender erkennt frühzeitig, dass er sich z. B. in der Schreibweise der eMailadresse vertan hat. Außerdem wird der Schlüsselgenerierungsdienst entlastet, da er keine sinnlosen Schlüssel erzeugen muss.
Weiterhin kann der Schlüssel und ggf. der private Schlüssel zur Archivierung an das interne Verzeichnis übermittelt werden. Vorteilhaft ist die Sicherung des Schiüsseis (Backup) gegen Datenverluste sowie die Möglichkeit später verschlüsselte Versionen von E-Mails entschlüsseln zu können. Gegebenenfalls ist die zentrale Bereithaltung der Schlüssel auch eine organisatorische oder gesetzliche Auflage.
Grundsätzlich soll hervorgehoben werden, dass mehrere interne Verzeichnisdienste oder eMailserver angefragt werden können.
sfiguren sind:
LAN Bildschirmarbeitsplatz mobiles Endgerät Mitarbeitender interne Zertifizierungsstelle personalisierter Schlüssel Empfängerschlüssel Schlüsselverzeichnis externer Partner Internet (internes) Mailgateway Schlüsselgenerator Gatewayschlüssel „privater" Entschlüsselungsschlüssel Mailserver Pushserver Spam- und Virenscanner Externes Mailgateway persönlicher Schlüssel

Claims

Ansprüche
1. Verfahren zur Übermittlung einer Nachricht, wobei ein Absender zunächst eine Anfrage an einen Verzeichnisdienst richtet, aufgrund derer der Verzeichnisdienst in einem Schlüsselverzeichnis (8) eine Empfängeradresse sucht, sofern das Schlüsselverzeichnis (8) die Empfängeradresse enthält, einen der Empfängeradresse in dem Schlüsselverzeichnis (8) zugeordneten Empfängerschlüssel (7) ausliest und diesen dem Absender mitteilt, wobei sodann der Absender die Nachricht mittels des Empfängerschlüssels (7) verschlüsselt und an die Empfängeradresse übermittelt, dadurch gekennzeichnet, dass auf die Anfrage, sofern das Schlüsselverzeichnis (8) die Empfängeradresse nicht enthält, ein Schlüsselgenerator (12) einen Gatewayschlüssel (13) generiert und diesen dem Absender mitteilt, wobei sodann der Absender die Nachricht mittels des Gatewayschlüssels (13) verschlüsselt und über ein Mailgateway (11), das die Nachricht entschlüsselt, schließlich an die Empfängeradresse übermittelt.
2. Verfahren nach Anspruch 1 , wobei die Gültigkeit der Empfängeradresse geprüft wird.
3. Verfahren nach Anspruch 2, wobei die Gültigkeit der Empfängeradresse durch Überprüfung beim E-Mailserver des Empfängers erfolgt.
4. Verfahren nach Anspruch 2, wobei die Gültigkeit der Empfängeradresse durch Überprüfung bei einem Verzeichnisdienst, vorzugsweise öffentlichen Verzeichnisdienst, des Empfängers erfolgt.
5. Verfahren nach einem der Ansprüche 2 bis 4, wobei nach erfolgreicher Prüfung auf Gültigkeit der Empfängeradresse zusätzliche Metainformationen zur Verfügung gestellt wird.
6. Verfahren nach dem vorgenannten Anspruch, dadurch gekennzeichnet, dass der Schlüsselgenerator (12) einen auf die Empfängeradresse personalisierten Gatewayschlüssel (13) generiert.
7. Verfahren nach einem der vorgenannten Ansprüche, dadurch gekennzeichnet, dass der Gatewayschlüssel (13) in dem Schlüsselverzeichnis (8) der Empfängeradresse zugeordnet wird.
8. Verfahren nach einem der vorgenannten Ansprüche, dadurch gekennzeichnet, dass der Schlüsselgenerator (12) gemeinsam mit dem Gatewayschlüssel (13) einen diesem zugeordneten Entschlüsselungsschlüssel (14) generiert und das Mailgateway (11) die Nachricht mittels des Entschlüsselungsschlüssels (14) entschlüsselt.
9. Verfahren nach dem vorgenannten Anspruch, dadurch gekennzeichnet, dass der Gatewayschlüssel (13) Teii eines Zertifikats ist.
10. Verfahren nach einem der vorgenannten Ansprüche, dadurch gekennzeichnet, dass die Nachricht von dem Absender über einen Mailserver an die Empfängeradresse übermittelt wird.
11. System zur Übermittelung einer Nachricht, insbesondere zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 10, bestehend aus einem Mittel für einen Verzeichnisdienst, der eine Anfrage von einem Absender empfängt, wobei das Mittel für den Verzeichnisdienst in einem Mittel für ein Schlüsselverzeichnis (8) eine Empfängeradresse sucht, dadurch gekennzeichnet, dass ein Schlüsselgenerator vorgesehen ist, der einen Gatewayschlüssel aufgrund der Anfrage erzeugt, wenn das Schlüsselverzeichnis die Empfängeradresse nicht enthält.
12. System nach Anspruch 11 , wobei ein Mittel zum Überprüfen der Gültigkeit der Empfängeradresse vorgesehen ist.
13. System nach Anspruch 12, wobei die Gültigkeit der Empfängeradresse durch Überprüfung beim E-Mailserver des Empfängers erfolgt.
14 System nach Anspruch 12, wobei die Gültigkeit der Empfängeradresse durch Überprüfung bei einem öffentlichen Verzeichnisdienst des Empfängers erfolgt.
15. System nach einem der Ansprüche 12 bis 14, wobei nach erfolgreicher Prüfung auf Gültigkeit der Empfängeradresse zusätzliche Metainformationen zur Verfügung gestellt wird.
16. System nach einem der Ansprüche 11 bis 15, dadurch gekennzeichnet, dass ein Mittel zum Verschlüsseln der Nachricht mittels des Gatewayschlüssels vorgesehen ist.
17. System nach einem der Ansprüche 11 oder 16, dadurch gekennzeichnet, dass ein Mittel zum Signieren der Nachricht mittels des Gatewayschlüssels vorgesehen ist.
18. System nach einem der Ansprüche 11 bis 17, dadurch gekennzeichnet, dass ein Mailgateway zum Signieren vorgesehen ist.
19. System nach einem der Ansprüche 11 bis 18, dadurch gekennzeichnet, dass ein Mailgateway zum Entschlüsseln der Nachricht vorgesehen ist.
20. System nach einem der Ansprüche 11 bis 19, dadurch gekennzeichnet, dass der Schlüsselgenerator (12) einen auf die Empfängeradresse personalisierten Gatewayschlüssel (13) generiert hat.
21. System nach einem der Ansprüche 11 bis 20, dadurch gekennzeichnet, dass der Gatewayschlüssel (13) in den Schlüsselverzeichnis der Empfängeradresse zugeordnet wird.
22. System nach einem der Ansprüche 11 bis 21 , dadurch gekennzeichnet, dass der Schlüsselgenerator (12) gemeinsam mit dem Gatewayschlüssel (13) einen diesem zugeordneten Entschlüsselungsschlüssel (14) generiert und das Mailgateway (11) die Nachricht mittels des Entschlüsselungsschlüssels (14) entschlüsselt.
23. System nach einem der Ansprüche 11 bis 22, dadurch gekennzeichnet, dass der Gatewayschlüssel (13) Teil eines Zertifikats ist.
24. Schlüsselgenerator, insbesondere zur Verwendung bei dem Verfahren nach einem Ansprüche 1 bis 10, oder zur Verwendung in dem System nach einem der Ansprüche 11 bis 23, der aufgrund einer Anfrage durch einen Absender an einen Verzeichnisdienst, einen Gatewayschiüssel generiert.
25. Schlüsselgenerator nach Anspruch 24, wobei der Gatewayschlüssel generiert wird, wenn ein Schlüsselverzeichnis die von dem Absender angefragte Empfängeradresse nicht enthält.
EP06776437A 2005-07-26 2006-07-26 Verfahren und system zur übermittlung einer nachricht, sowie ein geeigneter schlüsselgenerator hierfür Withdrawn EP1908253A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE102005035482A DE102005035482A1 (de) 2005-07-26 2005-07-26 Verfahren zur Übermittlung einer Nachricht
DE202005016825U DE202005016825U1 (de) 2005-07-26 2005-10-26 System zur Übermittlung einer Nachricht, sowie ein geeigneter Schlüsselgenerator hierfür
PCT/EP2006/007404 WO2007012483A1 (de) 2005-07-26 2006-07-26 Verfahren und system zur übermittlung einer nachricht, sowie ein geeigneter schlüsselgenerator hierfür

Publications (1)

Publication Number Publication Date
EP1908253A1 true EP1908253A1 (de) 2008-04-09

Family

ID=37114695

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06776437A Withdrawn EP1908253A1 (de) 2005-07-26 2006-07-26 Verfahren und system zur übermittlung einer nachricht, sowie ein geeigneter schlüsselgenerator hierfür

Country Status (4)

Country Link
EP (1) EP1908253A1 (de)
JP (1) JP2009503963A (de)
DE (1) DE202005016825U1 (de)
WO (1) WO2007012483A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080187140A1 (en) * 2007-02-07 2008-08-07 Comodo Ca Limited Method and System of Securely Transmitting Electronic Mail
DE102007045909A1 (de) * 2007-09-26 2009-08-06 T-Mobile Internationale Ag Verfahren zum Schutz vor Viren/Spam in Mobilfunknetzen

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6061448A (en) * 1997-04-01 2000-05-09 Tumbleweed Communications Corp. Method and system for dynamic server document encryption
GB2368756A (en) * 2000-11-02 2002-05-08 Roke Manor Research Email encryption system in which messages are sent via an encryption server which stores the public keys of intended recipients
US20040133774A1 (en) * 2003-01-07 2004-07-08 Callas Jonathan D. System and method for dynamic data security operations

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007012483A1 *

Also Published As

Publication number Publication date
DE202005016825U1 (de) 2006-12-07
JP2009503963A (ja) 2009-01-29
WO2007012483A1 (de) 2007-02-01

Similar Documents

Publication Publication Date Title
DE60316809T2 (de) Verfahren und vorrichtung zur verarbeitung von nachrichten in einem kommunikationsnetzwerk
DE19960977B4 (de) System für ein elektronisches Datenarchiv mit Erzwingung einer Zugriffskontrolle beim Datenabruf
DE60221514T2 (de) Privilegiertes e-mail-system mit routing-steuerungen
DE69836545T2 (de) Firewall für elektronische post mit verschlüsselung/entschlüsselung mittels gespeicherter schlüssel
WO2007045395A1 (de) Vorrichtungen und verfahren zum durchführen von kryptographischen operationen in einem server-client-rechnernetzwerksystem
EP3672142A1 (de) Verfahren und system zur sicheren übertragung eines datensatzes
EP1653701B1 (de) Verfahren, Vorrichtungen und Computerprogrammprodukt zur Überprüfung der Signaturen signierter Dateien und zur Konvertierung unsignierter Dateien
EP1908253A1 (de) Verfahren und system zur übermittlung einer nachricht, sowie ein geeigneter schlüsselgenerator hierfür
EP2932677B1 (de) Verfahren für die sichere übertragung einer digitalen nachricht
DE69925923T2 (de) Sicheres datenübertragungssystem
EP1865675A1 (de) Verfahren und System zur Filterung elektronischer Nachrichten
DE102017105396A1 (de) System zum elektronischen Signieren eines Dokuments
DE112007000419B4 (de) Digitale-Rechte-Managementsystem mit diversifiziertem Inhaltsschutzprozess
EP2449494A1 (de) Vorrichtungen und verfahren zum erstellen und validieren eines digitalen zertifikats
DE10334550A1 (de) Verfahren zur Ver- und Entschlüsselung oder Signatur von E-Mails über einen E-Mail-Server
DE102022112839A1 (de) Kommunikationssystem, Verfahren und Computerprogrammprodukt zur Bereitstellung von Dokumenten von einem oder mehreren Absendern an mindestens einen Empfänger
WO2007099026A1 (de) Verfahren und vorrichtung zum authentifizieren eines öffentlichen schlüssels
EP1944928A2 (de) Verfahren und System zum gesicherten Austausch einer E-Mail Nachricht
DE102005035482A1 (de) Verfahren zur Übermittlung einer Nachricht
EP2037643A1 (de) Verfahren zur Übermittlung einer elektronischen Nachricht in einem Transportnetzwerk
EP1248432B1 (de) Verfahren und System zum Abfragen von Zertifikatsinformationen unter Verwendung von dynamischen Zertifikatsreferenzen
DE10133184C2 (de) Verfahren zur Sicherheitsüberprüfung verschlüsselter Daten in einem Firewall-System
EP2591583B1 (de) Verfahren zur sicheren datenübertragung und entschlüsselung für die kommunikation via internet
DE102017214273A1 (de) Geschützte Nachrichtenübertragung
DE102015001817B4 (de) Verfahren, Vorrichtungen und System zur Online-Datensicherung

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080123

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: SEEMANN, HENNING, DR.

17Q First examination report despatched

Effective date: 20091007

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20100127