DE102013016466B4 - Verfahren zur Umsetzung von Suchanforderungen für digitale Zertifikate - Google Patents

Verfahren zur Umsetzung von Suchanforderungen für digitale Zertifikate Download PDF

Info

Publication number
DE102013016466B4
DE102013016466B4 DE102013016466.4A DE102013016466A DE102013016466B4 DE 102013016466 B4 DE102013016466 B4 DE 102013016466B4 DE 102013016466 A DE102013016466 A DE 102013016466A DE 102013016466 B4 DE102013016466 B4 DE 102013016466B4
Authority
DE
Germany
Prior art keywords
certificates
resolve
ldap
client
search
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.)
Active
Application number
DE102013016466.4A
Other languages
English (en)
Other versions
DE102013016466A1 (de
Inventor
Gunnar Jacobson
Michael Krüger
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.)
SECARDEO GmbH
Original Assignee
SECARDEO GmbH
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
Application filed by SECARDEO GmbH filed Critical SECARDEO GmbH
Priority to DE102013016466.4A priority Critical patent/DE102013016466B4/de
Publication of DE102013016466A1 publication Critical patent/DE102013016466A1/de
Application granted granted Critical
Publication of DE102013016466B4 publication Critical patent/DE102013016466B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Viele E-Mailclients, insbesondere auf Mobilgeräten, nutzen für die Suche nach Empfängerzertifikaten zur Verschlüsselung von E-Mails Zugriffsprotokolle wie Exchange WebServices (EWS) oder Exchange ActiveSync (EAS). Damit können Zertifikate über einen Kollaborationsserver aus einem lokalen Directory abgerufen werden, nicht aber Zertifikate von externen Directories, die Suchanfragen über das LDAP Protokoll bedienen. Ein Proxy übermittelt alle Nachrichten zwischen Client und Server im EAS oder EWS Protokoll. Resolve Nachrichten werden zusätzlich in eine LDAP Suchanfrage umgewandelt und an einen Zertifikats-Broker gesendet, der eine globale Zertifikatssuche durchführt. Alle empfangenen Zertifikate werden in einer Resolve-Response vom Proxy an den Client zurück geliefert. Ein mobiler E-Mailclient wie die iOS Mail App kann über den Proxy sowohl die Zertifikate lokaler Empfänger als auch die Zertifikate globaler Empfänger abrufen. Damit wird eine spontane Verschlüsselung an beliebige Empfänger ermöglicht.

Description

  • Technisches Gebiet
  • Diese Erfindung betrifft das Gebiet des verschlüsselten Nachrichtenaustauschs und insbesondere Verfahren zur Bereitstellung digitaler Zertifikate von Empfängern.
  • Stand der Technik
  • Asymmetrische Kryptosysteme basieren darauf, dass Daten mit einem Chiffrierschlüssel verschlüsselt und mit einem dazu inversen Dechiffrierschlüssel wieder entschlüsselt werden können. Der Chiffrierschlüssel kann veröffentlicht werden, während der Dechiffrierschlüssel vom Eigentümer geheim gehalten wird. Ein System zur Verwaltung solcher Schlüssel wird als Public Key Infrastruktur (PKI) bezeichnet. Für PKI existieren zahlreiche Standards und Verfahren, vgl. „B. Schneier; Applied Cryptography 2nd ed.; Wiley & Sons; 1996”; S. 185–187, S. 461–502, S. 574–589.
  • Der X.509 Standard „ITU-T X.509, Directory Information Technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks, 2005” beschreibt insbesondere die Struktur von digitalen Zertifikaten. Ein digitales Zertifikat ordnet den öffentlichen Schlüssel eines Public Key Kryptosystems einem Teilnehmer zu und wird von einer vertrauenswürdigen Zertifizierungsstelle, (Certification Authority, CA) digital signiert. Digitale Zertifikate werden zur Verschlüsselung und digitalen Signierung von Daten sowie zur Authentisierung von Teilnehmern und Systemen verwendet. Teilnehmerzertifikate können effizient über Verzeichnisdienste zur Verfügung gestellt werden.
  • Als Zugriffsprotokoll für Verzeichnisdienste hat sich das Lightweight Directory Access Protocol (LDAP) durchgesetzt, das im Internet RFC 4510 spezifiziert ist und durch eine Reihe weiterer RFCs präzisiert und erweitert wurde. LDAP definiert Operationen zur Abfrage, Aktualisierung, sowie zum Schreiben und Löschen eines Verzeichnisses. Die wesentliche Operation für Teilnehmer ist die Suchoperation „search”, mit der Informationen im Verzeichnis lokalisiert und geholt werden können.
  • Die Verschlüsselung und digitale Signierung von E-Mails erfolgt in gängigen Produkten mittels Secure Multipurpose Internet Mail Extensions (S/MIME) gemäß RFC 3851. Viele E-Mailclients wie Microsoft Outlook, Lotus Notes oder Mozilla Thunderbird verwenden diesen Standard. Zunehmend wird S/MIME auch durch mobile Endgeräte unter iOS, Android und BlackBerry unterstützt.
  • Bei S/MIME wird der Datenverschlüsselungsschlüssel mit dem öffentlichen Schlüssel des jeweiligen Empfängers verschlüsselt. Der Empfänger entschlüsselt mit Hilfe seines privaten Schlüssels zunächst den Datenverschlüsselungsschlüssel und hiermit anschließend die Inhaltsdaten.
  • Der öffentliche Schlüssel eines Empfängers kann vom E-Mailclient über LDAP mittels einer Suchabfrage nach dem digitalen Zertifikat des Empfängers von einem Verzeichnisdienst abgefragt werden. Zur Suche wird üblicherweise das Attribut „mail” verwendet.
  • Gängige Desktop-Clients wie Outlook, Notes oder Thunderbird verwenden zur Suche nach Zertifikaten das LDAP Protokoll. Dabei werden die Zertifikatssuche und die anschließende Verschlüsselung transparent durchgeführt, wenn der Benutzer die Option „Verschlüsseln” gewählt hat.
  • In der Patentschrift DE 10 2004 015 457 B3 wird ein Verfahren beschrieben, mit dem bei LDAP Suchanfragen vertrauliche Daten in der Antwortnachricht verschlüsselt werden können. In den Abschnitten [0012] bis [0014] und [0027] wird dort gezeigt, dass sich dieses Verfahren insbesondere auch für LDAP Suchanfragen nach digitalen Zertifikaten, beispielsweise in Form eines LDAP-Proxys, eignet.
  • Einige E-Mailclients wie beispielsweise Apple Mail oder mobile Clients unter iOS und Android nutzen nicht das LDAP Protokoll zur Zertifikatssuche sondern verwenden hierzu spezielle Resolve Nachrichten, die das zum Zugriff auf einen Kollaborationsserver verwendete E-Mail Zugriffsprotokoll anbietet.
  • Eine Resolve Nachricht dient dazu, Kontaktinformationen für einen angegebenen Namen, Alias oder eine E-Mailadresse sowie Frei-/Beschäftigt Statusinformationen abzufragen. Zusätzlich können auch Zertifikate abgefragt werden.
  • Zum Zugriff auf einen Kollaborationsdient wie Microsoft Exchange stehen XML-basierte Protokolle wie das Exchange WebServices (EWS) Protokoll sowie Exchange ActiveSync (EAS) zur Verfügung, die zum Datentransport HTTP oder HTTPS verwenden.
  • EWS ist insbesondere für die Verwendung durch Desktop-Clients geeignet. Eine Spezifikation ist in der Exchange Web Services Reference unter http://msdn.microsoft.com/en-us/library/bb204119(v=exchg.140).aspx zu finden.
  • Die Beschaffung von Zertifikaten erfolgt im Exchange WebServices Protokoll über die Resolve Nachricht „ResolveNames Operation”.
  • In der ResolveNames Operation wird auch eine mehrdeutige Namensangabe bedient, indem Informationen über die Kandidaten zurück geliefert werden, mit denen der Client dann den Namen selbst auflösen kann.
  • Ein Zertifikat wird in dem Attribut „UserSMIMECertificate” des Contact Elements in der ResolveNames Response zurückgeliefert.
  • EAS wurde insbesondere für die Verwendung durch mobile Endgeräte konzipiert. Eine Spezifikation ist in [MS-ASCMD]: Exchange ActiveSync: Command Reference Protocol unter http://msdn.microsoft.com/en-us/library/dd299441(v=exchg.80).aspx zu finden.
  • Die Kodierung der Nachrichten des ActiveSync Protokolls erfolgt in WBXML (WAP Binary XML), welche insbesondere für schmalbandige Verbindungen geeignet ist.
  • Im ActiveSync Protokoll erfolgt die Beschaffung von Zertifikaten zur Verschlüsselung von S/MIME Nachrichten über die Resolve Nachricht „ReslveRecipients Command”.
  • In dem CertificateRetrieval Element im ResolveRecipients Command kann angegeben werden ob entweder kein Zertifikat, das vollständige Zertifikat oder ein sogenanntes Mini-Zertifikat für jeden aufgelösten Empfänger zurückgeliefert werden soll.
  • Mit dem MaxCertificates Element im ResolveRecipients Command kann die Gesamtanzahl der vom Server zurückgelieferten Zertifikate begrenzt werden.
  • Die Zertifikate oder Mini-Zertifikate eines Empfängers können in der ResolveRecipients Command Response im (Child-)Element Certificates des (Parent-)Elements Recipient enthalten sein.
  • In der Zeichnung Seite 1 ist der Ablauf im EWS und EAS Protokoll skizziert. Der Client sendet eine Resolve Nachricht an den Kollaborationsserver, welches die Adressen der vom Anwender angegebenen Empfänger E1–En enthält 1. Nachdem der Kollaborationsdienst die Resolve Nachricht erhalten hat, kann er in seiner lokalen Datenbank oder dem angeschlossenen Verzeichnisdienst (Directory Server) nach den Empfängeradressen suchen 2. Der Directory Server liefert die hierfür gefundenen Einträge inklusive der enthaltenen Zertifikate Z1–Zn an den Kollaborationsserver zurück 3. Der Client erhält die Zertifikate in der Resolve Antwortnachricht (ResolveNamesResponse bei EWS sowie ResolveRecipients Response bei EAS) vom Kollaborationsserver 4. Eine detaillierte Beschreibung dieses Verfahrens ist in der Patentschrift US 7,490,127 B2 zu finden.
  • In US 8,151,106 B2 wird ein Verfahren beschrieben, welches es einem mobilen Endgerät ermöglicht, Zertifikate für eine während einer verbindungslosen Zeitperiode (Offline Modus) aufgebaute Liste von Empfängern mittels ResolveRecipients zu beschaffen, sobald das Gerät wieder eine Netzwerkverbindung hat.
  • Daneben gibt es andere Verfahren zur Beschaffung von Zertifikaten auf (mobile) Endgeräte. In der Patentschrift CA 2476914 A1 wird ein Verfahren zur Suche und Synchronisation von Zertifikaten für vorhandene Kontakte beschrieben, mit dem Ziel dass ein Anwender deren Beschaffung für sein Adressbuch nicht manuell ausführen muss. Dabei werden mehrere Zertifikatsserver beispielsweise mittels LDAP durchsucht und die Ergebnisse werden im lokalen Adressbuch oder Zertifikatsspeicher gespeichert Ein Verfahren zur Synchronisation von CA Zertifikaten wird in EP 1 632 871 A1 beschrieben.
  • Alternativ können Zertifikate auch von einem zentralen Server auf die Endgeräte verteilt werden, wie es beispielsweise in EP 2 629 479 A1 beschrieben ist. Solche Verfahren werden in Mobile Device Management Systemen verwendet.
  • Neben der Beschaffung der benötigten Zertifikate muss auch sichergestellt werden, dass die Zertifikate gültig und vertrauenswürdig sind. Hierfür werden geeignete Validierungsverfahren benötigt.
  • Die Gültigkeitsprüfung wird üblicherweise mit Hilfe von Sperrlisten (Certificate Revocation List, CRL) gemäß RFC 5280 oder Online Statusabfragen (Online Certificate Status Protokol, OCSP) gemäß RFC 2560 durchgeführt.
  • Im Exchange WebServices Protokoll werden die Zertifikate vom Client mit Hilfe der oben genannten Sperrlisten oder Online Statusabfragen überprüft.
  • Im ActiveSnyc Protokoll können Zertifikate, die der Client entweder über ResolveRecipients oder beispielsweise über empfangene signierte E-Mails erhalten hat über das Kommando ValidateCert validiert werden.
  • In der Zeichnung Seite 2 ist der Ablauf skizziert. Der (mobile) E-Mailclient sendet eine Nachricht mit dem ValidateCert Kommando an den Kollaborationsserver, welches die Zertifikate Z1–Zn enthält 1. Nachdem er die ValidateCert Anfrage erhalten hat muss der Kollaborationsserver prüfen, ob das Zertifikat sowie die gesamte Zertifikatskette vertrauenswürdig und gültig ist. Dies kann er über eine Abfrage der Sperrliste (Certificate Revocation List), CRL) vornehmen, die er über den lokalen Verzeichnisdienst (Directory Server) oder beispielsweise einen Webserver anfordern kann 2a. Der Directory Server liefert die Sperrliste an den Kollaborationsserver zurück und der Kollaborationsserver prüft, ob eines der Zertifikate Z1–Zn hier aufgeführt ist 3a. Alternativ kann der Kollaborationsserver eine Statusanfrage für Z1–Zn an einen Validierungsserver senden, beispielsweise über das OCSP Protokoll (Online Certificate Status Protocol) 2b. Der Validierungsserver liefert für jedes angefragte Zertifikat den Status, beispielsweise good, revoked oder unknown an den Kollaborationsserver zurück 3b. Der Kollaborationsserver sendet dem Client eine ValidateCert Response Nachricht mit dem entsprechenden Status, beispielsweise 1 (Success), 15 (Revoked) oder 14 (Offline) 4.
  • Es sind verschiedene Methoden bekannt, um Protokollnachrichten zwischen LDAP und anderen Protokollen umzusetzen. In der Patentschrift US 2005/0 289 174 A1 wird in den Abschnitten [0033] und [0034] eine Methode beschrieben, wie SQL Zugriffsanfragen in entsprechende LDAP Anfragen sowie die LDAP Antwortnachrichten in SQL Antworten umgesetzt werden können. In US 2011/0 145 320 A1 wird in den Abschnitten [0009],[0011], [0012], [0030], [0036] sowie in Claim 1 und im Abstract mit Figur beschrieben, wie Protokollnachrichten zwischen dem Advanced Message Queuing Protocol (AMQP) und LDAP umgesetzt werden können.
  • Neben der Suche nach digitalen Zertifikaten kann LDAP in einer Public Key Infrastruktur für weitere Aufgaben dienen. in der Patentschrift US 2006/0 282 663 A1 wird in den Abschnitten [0006], [0011], [0022] bis [0025] sowie im Abstract mit Figur beschrieben, wie Daten aus einem Verzeichnisdienst über LDAP abgefragt und gemäß vorgegebener Regeln transformiert werden können, um daraus eine Zertifikatsanforderung zu erzeugen.
  • Beschreibung des Problems
  • Wenn die Absenderin Alice einer PKI 1 eine verschlüsselte Nachricht an den Empfänger Bob in der PKI 2 senden möchte, benötigt sie dessen Teilnehmerzertifikat und muss diesem vertrauen.
  • Bei dem zuvor beschriebenen Verfahren für ResolveNames (EWS) und ResolveRecipients (EAS) sucht der Kollaborationsserver nur in der lokalen Datenbank oder dem lokalen Verzeichnis der PKI 1. Das Zertifikat von Bob aus PKI 2 wird hier üblicherweise nicht gefunden. Somit kann Alice nicht transparent an Bob von ihrem Client aus verschlüsseln.
  • Für die Beschaffung des Teilnehmerzertifikats aus einer externen PKI eignen sich so genannte Zertifikats-Broker, die in „Öffentliche Zertifikatsverzeichinsse für Public Keys, DuD 7, GWV Fachverlage 2009” beschrieben sind. Ein Client kann automatisch über LDAP eine Suchanfrage für das Zertifikat von Bob an den Zertifikats-Broker stellen. Dieser ermittelt das für Bob's Zertifikat zuständige Zertifikatsverzeichnis (Repository), leitet die Anfrage dorthin weiter und sendet das empfangene Zertifikat an den LDAP Client zurück.
  • Beschreibung der Erfindung
  • Die Aufgabe der hier vorliegenden Erfindung ist es, einem S/MIME Client die Zertifikate von Empfängern, die von dem angeschlossenen Kollaborationsdienst nicht zurück geliefert werden bereit zu stellen. Das technische Verfahren wird im Folgenden beschrieben.
  • Das Verfahren erfordert keine technischen Änderungen am Client oder am Kollaborationsdienst. Es kann durch Vorschalten eines zusätzlichen Systems zwischen Client und Server realisiert werden. Ein solches System wird im Folgenden als „Proxy” bezeichnet.
  • Der Proxy hat die Aufgabe, Zertifikate, die vom Kollaborationsdienst nicht zurück geliefert werden zu besorgen und dem Client bereitzustellen. Dazu nutzt er die Dienste eines Zertifikats-Brokers.
  • Der Proxy leitet alle Anfrage- und Antwortnachrichten des Protokolls unverändert zum Server beziehungsweise zum Client zurück mit Ausnahme der Resolve Nachrichten, welche Zertifikate anfordern (ResolveNames bei EWS und ResolveRecipients bei EAS) und bereitstellen oder solche validieren (ValidateCert).
  • Eine Resolve Nachricht kann direkt vom Proxy angenommen und hieraus eine LDAP Suchanfrage (LDAP Search Request) gebildet werden. Dabei können bei dem ActiveSync Protokoll die Attribute aus dem optionalen Element „CertificateRetrieval” berücksichtigt werden. Sofern der Wert „Retrieve full/mini Certificate” ist, soll ein Zertifikat für die im Element „To” enthaltenen Empfänger gesucht werden.
  • Die LDAP Suchanfrage enthält das „mail” Attribut und wird an den Zertifikats-Broker übermittelt. Aus der enthaltenen LDAP Antwortnachricht wird das Zertifikat extrahiert und es wird eine Resolve-Response Nachricht (ResolveNamesResponse Message bei EWS bzw. ResolveRecipients Command Response bei EAS) für den Client gebildet, welche das Zertifikat im Attribut Certificates enthält. Diese Variante A) hat den Vorteil, dass eine einheitliche Schnittstelle zur Zertifikatssuche verwendet wird.
  • Eine solche Resolve Nachricht kann in einer anderen Variante B) auch unverändert an den Kollaborationsserver weitergeleitet werden. Aus der Resolve-Response Nachricht werden die Empfängeradressen aus der Empfängerliste im Element „To” direkt vom Proxy angenommen und hiermit wird eine LDAP Suchanfrage (LDAP Search Request) gebildet.
  • Die LDAP Suchanfrage enthält das „mail” Attribut und wird an den Zertifikats-Broker übermittelt. Aus der enthaltenen LDAP Antwortnachricht wird das Zertifikat extrahiert. Die ursprüngliche Resolve-Response wird um dieses Zertifikat ergänzt und an den Client gesendet. Diese Variante hat den Vorteil, dass Zertifikate, die nur lokal über den Kollaborationsserver gefunden werden können an den Client zurück geliefert werden.
  • Ein Ausführungsbeispiel ist in der Zeichnung Seite 3 abgebildet. Der E-Mailclient sendet eine Resolve Nachricht an den Proxy, welches die Adressen der vom Anwender angegebenen Empfänger E1–En enthält 1. Der Proxy leitet die Resolve Nachricht an den Kollaborationsserver weiter 2. Der Kollaborationsdienst kann in seiner lokalen Datenbank oder dem lokal angeschlossenen Verzeichnisdienst (Directory Server) nach den Empfängeradressen E1–En suchen 3. Der Directory Server liefert die hierfür gefundenen Einträge für Ei–Ej inklusive der enthaltenen Zertifikate Zi–Zj an den Kollaborationsserver zurück 4. Dieser erzeugt eine Resolve-Response Nachricht, welche die Zertifikate Zi–Zj jeweils im Attribut Certificates enthält und sendet die Nachricht an den Proxy 5. Der Proxy ermittelt die Empfängeradressen Ek–El, für die kein Zertifikat zurück geliefert wurde und sendet eine LDAP Suchanfrage für Ek–El an der Zertifikats-Broker 6. Der Zertifikats-Broker leitet die spezifischen LDAP Suchanfragen an die jeweils für einen Adressraum zuständigen externen Directory-Server weiter 7a–c. Die Directory-Server ermitteln die Zertifikate aus den betreffenden Directory-Einträgen und senden sie in einer LDAP Suchantwort an den Zertifikats-Broker zurück 8a–c. Sobald der Zertifikats-Broker alle Antwortnachrichten empfangen hat sendet er eine LDAP Suchantwort an den Proxy, die alle gefundenen Zertifikate Zk–Zl enthält 9. Der Proxy ergänzt die Resolve-Response Nachricht welche dann die empfangenen Zertifikate Zi–Zj und Zk–Zl im Attribut Certificates enthält und sendet diese an den E-Mailclient zurück 10.
  • Eine vom Client gesendete Anfragenachricht für die Validierung von Zertifikaten (ValidateCert Command Request) im ActiveSync Protokoll wird ebenfalls vom Proxy angenommen und ausgewertet.
  • Bei der zuvor beschriebenen Variante A) ist der Proxy zuständig für die Validierung aller Zertifikate.
  • Sofern der angebundene Zertifikats-Broker bereits eine Validierung durchführt und somit nur gültige und vertrauenswürdige Zertifikate zurückliefert, kann der Proxy für diese Zertifikate eine Antwortnachricht „gültig” (Status „success”) an den Client zurück senden.
  • Der Proxy kann die Validierung auch bei Variante B) für alle Zertifikate durchführen B1). Dazu kann der Proxy einen geeigneten Validierungsdienst, beispielsweise mittels OCSP abfragen und das Ergebnis in der Antwortnachricht an den Client zurück senden.
  • In einer weiteren Variante B2) kann der Proxy in der Anfragenachricht zur Validierung unterscheiden zwischen Zertifikaten, die vom Kollaborationsdienst zurück geliefert wurden und Zertifikaten, die vom Zertifikats-Broker zurückgeliefert wurden.
  • Die vom Zertifikats-Broker zurück gelieferten Zertifikate werden vom Proxy aus der Validierungs-Anfragenachricht entfernt und die Anfragenachricht wird an den Kollaborationsdienst weitergeleitet.
  • Der Kollaborationsdienst liefert den Status seiner lokalen Zertifikate an den Proxy zurück.
  • Der Proxy ermittelt den Zertifikatsstatus der verbleibenden Zertifikate. Dies kann durch eine Statusprüfung, beispielsweise mittels OCSP, erfolgen.
  • Sofern der Zertifikats-Broker selbst eine Validierung durchführt und somit nur gültige Zertifikate zurückliefert, kann auf eine zusätzliche Validierung durch den Proxy verzichtet werden.
  • Der Proxy bildet nun eine Antwortnachricht, welche den Zertifikatsstatus aller in der Validierungs-Anfragenachricht aufgeführten Zertifikate enthält und sendet die Antwort an den Client.
  • Ein Ausführungsbeispiel ist in der Zeichnung Seite 4 abgebildet. Der E-Mailclient sendet eine Nachricht mit dem ValidateCert Kommando an den Proxy, welches die Zertifikate Z1–Zn enthält 1. Dieser leitet die ValidateCert Anfrage an den Kollaborationsserver weiter 2. Der Kollaborationsserver kann eine Abfrage der Sperrliste (Certificate Revocation List, CRL) durchführen, die er über den lokalen Verzeichnisdienst (Directory Server) anfordert 3a. Der Directory Server liefert die Sperrliste an den Kollaborationsserver zurück und der Kollaborationsserver prüft, ob eines der Zertifikate Z1–Zn hier aufgeführt ist 4a. Alternativ sendet der Kollaborationsserver eine Statusanfrage für Z1–Zn an einen lokalen Validierungsserver 1 über das OCSP Protokoll (Online Certificate Status Protokol) 3b. Der Validierungsserver 1 liefert für jedes angefragte Zertifikat den Status in der OCSP Response an den Kollaborationsserver zurück 4b. Der Kollaborationsserver erzeugt eine ValidateCert Response Nachricht mit dem Status der Zertifikate Zi–Zj, den er jeweils lokal feststellen konnte und sendet diese dem Proxy 5. Der Proxy ermittelt die Zertifikate Zk–Zl, für die kein Status zurück geliefert wurde und sendet eine OCSP Anfrage für diese Zertifikate an den Validierungsserver 2 6. Der Validierungsserver 2 liefert für jedes angefragte Zertifikat den Status in der OCSP Response an den Proxy zurück 7. Der Proxy ergänzt die vorhandene ValidateCert Response Nachricht mit dem Status der Zertifikate Zk–Zl, und sendet diese dem E-Mailclient 8.

Claims (8)

  1. Verfahren zur Umsetzung der Anforderung von digitalen Zertifikaten von Empfängern aus einer Resolve Nachricht in einem E-Mail Zugriffsprotokoll in eine Suchanfrage des Lightweight Directory Access Protocol (LDAP) und Umsetzung der LDAP Suchantwort in eine Resolve Antwortnachricht des E-Mail Zugriffprotokolls mit den gefundenen Zertifikaten, das die folgenden Schritte umfasst: a) Empfang einer Anforderung von Zertifikaten in einer Resolve Nachricht für angegebene Empfänger von einem Client; b) Erzeugen einer LDAP Suchanfrage, welche eine oder mehrere dieser Empfängeradressen enthält; c) Senden der LDAP Suchanfrage an einen Verzeichnisdienst; d) Empfang der LDAP Suchantwort, welche die gefundenen Zertifikate enthält; e) Erzeugen einer Resolve Antwortnachricht des E-Mail Zugriffsprotokolls, welche die gefundenen Zertifikate enthält; f) Senden der Resolve Antwortnachricht an den Client;
  2. Verfahren gemäß Anspruch 1, bei dem die LDAP-Suchanfrage in Schritt b) alle Empfängeradressen der Resolve Nachricht in Schritt a) enthält und durch den Verzeichnisdienst bedient wird.
  3. Verfahren gemäß Anspruch 1, bei dem vor der LDAP Suchanfrage in Schritt b) ein Kollaborationsserver abgefragt wird und die LDAP Suchanfrage diejenigen Empfängeradressen enthält, für die keine Zertifikate vom Kollaborationsserver gefunden wurden und das hierfür zusätzliche Schritte a1)–a3) sowie einen erweiterten Schritt e) umfasst: a1) Weiterleitung der Resolve Nachricht aus Schritt a) an einen Kollaborationsserver; a2) Empfang der Resolve Antwortnachricht, welche die vom Kollaborationsserver gefundenen Zertifikate enthält; a3) Ermittlung der Empfängeradressen aus Schritt a), für die keine Zertifikate in der Resolve Antwortnachricht enthalten sind und Fortsetzung mit b); e) Erzeugen einer Resolve Antwortnachricht des E-Mail Zugriffsprotokolls durch Ergänzen der Resolve Antwortnachricht aus Schritt a2) mit den Zertifikaten aus Schritt d) und Fortsetzung mit f);
  4. Verfahren gemäß Anspruch 1, bei dem zusätzlich folgende Schritte durchgeführt werden: g) Empfang einer oder mehrerer Validierungsanfragen von einem Client im E-Mail Zugriffsprotokoll, welche jeweils ein oder mehrere der gefundenen Zertifikate enthält; h) Feststellung der Gültigkeit und Vertrauenswürdigkeit der Zertifikate; i) Senden der Validierungsergebnisse im E-Mail Zugriffsprotokoll an den Client;
  5. Verfahren gemäß Anspruch 2 oder 3 bei dem als E-Mail Zugriffsprotokoll das Exchange ActiveSync Protokoll verwendet wird und die Suchanfrage nach S/MIME Zertifikaten für angegebene Empfängeradressen über das ResolveRecipients Kommando erfolgt.
  6. Verfahren gemäß Anspruch 2 oder 3 bei dem als E-Mail Zugriffsprotokoll das Exchange WebServices Protokoll verwendet wird und bei dem die Suchanfrage nach S/MIME Zertifikaten für angegebene Empfängeradressen über die ResolveNames Operation erfolgt.
  7. Verfahren gemäß Anspruch 4, bei dem als E-Mail Zugriffsprotokoll das Exchange ActiveSync Protokoll verwendet wird und die Anfrage zur Validierung von Zertifikaten über das ValidateCert Kommando erfolgt.
  8. System zur Umsetzung von Resolve Nachrichten im Exchange Webservices (EWS) oder Exchange ActiveSync (EAS) Protokoll, welche die digitalen Zertifikate von Empfängern anfordern in Suchanfragen des Lightweight Directory Access Protokol (LDAP) gekennzeichnet dadurch, dass es als Proxy zwischen einem E-Mailclient und einem Kollaborationsserver wirkt und alle Nachrichten unverändert weiterleitet mit Ausnahme von Resolve Nachrichten (ResolveNames bei EWS und ResolveRecipients bei EAS) oder Resolve Antwortnachrichten (ResolveNamesResponse Message bei EWS und ResolveRecipients Command Response bei EAS), aus welchen es alle oder einen Teil der im Element „To” enthaltenen Empfängeradressen in einer oder mehreren LDAP Suchanfragen mit dem Attribut „mail” an einen Zertifikats-Broker sendet, welcher die Suchanfragen an angeschlossene Verzeichnisdienste weiterleitet und die gefundenen Zertifikate in einer oder mehreren LDAP Antwortnachrichten an den Proxy zurück sendet, welcher dann die Zertifikate aus den LDAP Antwortnachrichten in einer oder mehreren Resolve Antwortnachrichten im Attribut „Certificates” an den E-Mailclient zurück sendet.
DE102013016466.4A 2013-10-03 2013-10-03 Verfahren zur Umsetzung von Suchanforderungen für digitale Zertifikate Active DE102013016466B4 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102013016466.4A DE102013016466B4 (de) 2013-10-03 2013-10-03 Verfahren zur Umsetzung von Suchanforderungen für digitale Zertifikate

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102013016466.4A DE102013016466B4 (de) 2013-10-03 2013-10-03 Verfahren zur Umsetzung von Suchanforderungen für digitale Zertifikate

Publications (2)

Publication Number Publication Date
DE102013016466A1 DE102013016466A1 (de) 2015-04-09
DE102013016466B4 true DE102013016466B4 (de) 2017-04-13

Family

ID=52693109

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102013016466.4A Active DE102013016466B4 (de) 2013-10-03 2013-10-03 Verfahren zur Umsetzung von Suchanforderungen für digitale Zertifikate

Country Status (1)

Country Link
DE (1) DE102013016466B4 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115292683B (zh) * 2022-08-08 2024-01-23 国网江苏省电力有限公司泰州供电分公司 一种配电自动化终端加密证书管理系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004015457B3 (de) * 2004-03-30 2005-04-28 Secardeo Gmbh Verfahren zum Schutz der Vertraulichkeit von Informationen eines elektronischen Verzeichnisses sowie System zur stellvertretenden Annahme und Beantwortung von Lightweight Directory Access Protocol Suchanfragen (LDAP Proxy)
US20050289174A1 (en) * 2004-06-28 2005-12-29 Oracle International Corporation Method and system for implementing and accessing a virtual table on data from a central server
US20060282663A1 (en) * 2005-06-08 2006-12-14 International Business Machines Corporation Name transformation for a public key infrastructure (PKI)
US20110145320A1 (en) * 2009-12-15 2011-06-16 Rich Megginson Message bus based replication

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7490127B2 (en) 2003-06-13 2009-02-10 Microsoft Corporation Concurrent recipient resolution and certificate acquisition
CA2476914A1 (en) 2004-08-09 2006-02-09 Research In Motion Limited System and method for certificate searching and retrieval
EP1632871A1 (de) 2004-09-01 2006-03-08 Research In Motion Limited System und Verfahren zum Abfragen von verwandten Zertifikaten
US7716479B2 (en) 2005-06-03 2010-05-11 Microsoft Corporation Dynamically resolving recipients to retrieve public keys during send/receive
CA2799903C (en) 2012-02-17 2017-10-24 Research In Motion Limited Certificate management method based on connectivity and policy

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004015457B3 (de) * 2004-03-30 2005-04-28 Secardeo Gmbh Verfahren zum Schutz der Vertraulichkeit von Informationen eines elektronischen Verzeichnisses sowie System zur stellvertretenden Annahme und Beantwortung von Lightweight Directory Access Protocol Suchanfragen (LDAP Proxy)
US20050289174A1 (en) * 2004-06-28 2005-12-29 Oracle International Corporation Method and system for implementing and accessing a virtual table on data from a central server
US20060282663A1 (en) * 2005-06-08 2006-12-14 International Business Machines Corporation Name transformation for a public key infrastructure (PKI)
US20110145320A1 (en) * 2009-12-15 2011-06-16 Rich Megginson Message bus based replication

Also Published As

Publication number Publication date
DE102013016466A1 (de) 2015-04-09

Similar Documents

Publication Publication Date Title
DE102013108714B3 (de) Unterstützung einer Entschlüsselung von verschlüsselten Daten
US10469460B2 (en) Data sharing in a blockchain-enabled trust domain
US7664947B2 (en) Systems and methods for automated exchange of electronic mail encryption certificates
DE60315434T2 (de) Zertifikatinformationsspeichersystem und verfahren
DE60318825T2 (de) Vorrichtung und verfahren zur unterstützung von mehreren zertifizierungstatusanbietern auf einem mobilen kommunikationsgerät
EP3031226B1 (de) Unterstützung der nutzung eines geheimen schlüssels
US8880875B1 (en) System, apparatus and method for decentralizing attribute-based encryption information
DE60313778T2 (de) System zur sicheren Dokumentlieferung
DE602005002643T2 (de) Automatisierte Auswahl und Aufnahme einer Nachrichtensignatur
US8281125B1 (en) System and method for providing secure remote email access
US9754128B2 (en) Dynamic pseudonymization method for user data profiling networks and user data profiling network implementing the method
EP3424176A1 (de) Systeme und verfahren zur verteilten daten-nutzung mit asynchroner drittpartei-beglaubigung
DE102017000327A1 (de) In den Arbeitslauf am Desktop eingebettete mobile Signatur
US20110167258A1 (en) Efficient Secure Cloud-Based Processing of Certificate Status Information
CN112534773A (zh) 用于基于组的通信系统内的加密密钥管理的方法、装置和计算机程序产品
DE202012013453U1 (de) Gehostete Speichersperrung
DE102009031817A1 (de) Verfahren zur Ausstellung, Überprüfung und Verteilung von digitalen Zertifikaten für die Nutzung in Public-Key-Infrastrukturen
DE112021006319T5 (de) Hochverfügbare kryptografische schlüssel
CN106657348A (zh) 一种基于二维码的文件协同处理方法及系统
DE102013016466B4 (de) Verfahren zur Umsetzung von Suchanforderungen für digitale Zertifikate
Freitag A new Privacy Preserving and Scalable Revocation Method for Self Sovereign Identity--The Perfect Revocation Method does not exist yet
DE102009051206B4 (de) Verfahren zur vertrauenswürdigen Transformation von digitalen Zertifikaten
EP2685682A2 (de) Verfarhen und System zur sicheren Nachrichtenübertragung
CN114386072A (zh) 数据共享方法、装置和系统
EP3591925B1 (de) Verschlüsselungssystem für vertrauensunwürdige umgebungen

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R086 Non-binding declaration of licensing interest
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final