gemSpec_CM_KOMLE_V1.8.1

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

KOM-LE-Clientmodul

    

     

      
Version
      
1.8.1
     
     

      
Revision
      
548770
     
     

      
Stand
      
10.09.2020
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_CM_KOMLE
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Das vorliegende Dokument spezifiziert die Anforderungen an den Produkttyp KOM-LE-Clientmodul. Das Clientmodul ist verantwortlich für das Signieren und Verschlüsseln von KOM-LE-Nachrichten beim Versenden sowie für die Entschlüsselung und Signaturprüfung beim Abholen von KOM-LE-Nachrichten.

Aus den Kommunikationsbeziehungen mit Clientsystem, Konnektor, Verzeichnisdienst und KOM-LE-Fachdienst resultieren vom Clientmodul anzubietende Schnittstellen, die in diesem Dokument normativ beschrieben werden. Vom Clientmodul genutzte Schnittstellen liegen zumeist in anderen Verantwortungsbereichen (Konnektor, Verzeichnisdienst). Diese werden in den entsprechenden Produkttypspezifikationen definiert.

1.2 Zielgruppe

Dieses Dokument richtet sich an

• Entwickler des KOM-LE-Clientmoduls,
• Primärsystemhersteller und
• Verantwortliche für Zulassung und Test.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren werden durch die gematik GmbH in gesonderten Dokumenten (z.B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

1.4 Arbeitsgrundlagen

Grundlagen für die Ausführungen dieses Dokumentes sind

• Lastenheft Adressierte Kommunikation Leistungserbringer
• Systemspezifisches Konzept KOM-LE [gemSysL_KOMLE]
• KOM-LE S/MIME-Profil [gemSMIME_KOMLE]
• Gesamtarchitektur der TI [gemÜK_Arch_TI]
• Konzept Architektur der TI-Plattform [gemKPT_Arch_TIP]
• Spezifikation PKI [gemSpec_PKI]
• Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur [gemSpec_Krypt]
• Spezifikation Konnektor [gemSpec_Kon]

1.5 Abgrenzung des Dokuments

Spezifiziert werden in dem Dokument die vom Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert.

Die Systemlösung der Fachanwendung KOM-LE ist im systemspezifischen Konzept [gemSysL_KOMLE] beschrieben. Dieses Konzept setzt die fachlichen Anforderungen des Lastenheftes auf Systemebene um, zerlegt die Fachanwendung KOM-LE in die zugehörigen Produkttypen, darunter das KOM-LE-Clientmodul und der KOM-LE-Fachdienst. Ferner definiert es die Schnittstellen zwischen den einzelnen Produkttypen. Für das Verständnis dieser Spezifikation wird die Kenntnis von [gemSysL_KOMLE] vorausgesetzt.

Die Anforderungen am Fachdienst werden separat in der Spezifikationen Fachdienst KOM-LE [gemSpec_FD_KOMLE] beschrieben.

Die Anforderungen an das Format der KOM-LE-Nachrichten, die zwischen dem Clientmodul und dem Fachdienst übermittelt werden, werden separat im KOM-LE-S/MIME-Profil [gemSMIME_KOMLE] beschrieben.

Abbildung 1 zeigt schematisch die Einbettung des vorliegenden Dokuments in die Dokumentenlandschaft der Lastenheft- und Pflichtenheftphase in Form einer Dokumentenhierarchie.

Abbildung 1: Abb_Dok_Hierarchie Dokumentenhierarchie KOM-LE

1.6 Methodik

1.6.1 Anforderungen

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche innerhalb der Afo-ID und der Textmarke angeführten Inhalte.

1.6.2 Diagramme

Die Darstellung der Spezifikationen von Komponenten erfolgt auf der Grundlage einer durchgängigen Use-Case-Modellierung als

• technische Use Cases (eingebundene Graphik sowie tabellarische Darstellung mit Vor- und Nachbedingungen gemäß Modellierungsleitfaden),
• Sequenz- und Aktivitätendiagramme sowie
• Klassendiagramme
• XML-Strukturen und Schnittstellenbeschreibungen.

1.6.3 Nomenklatur

Sofern im Text dieser Spezifikation auf die Ausgangsanforderungen verwiesen wird, erfolgt dies in eckigen Klammern, z.B. [KOMLE-A_2015]. Wird auf Eingangsanforderungen verwiesen, erfolgt dies in runden Klammern, z.B. (KOMLE-A_202).

2 Systemüberblick

Das Clientmodul bietet die Funktionalität, die für Anwendungsfälle KOM-LE_AF_1 „Nachricht senden“ und KOM-LE_AF_2 „Nachricht empfangen“ (siehe [gemSysL_KOMLE]) relevant ist. Die Aufgabe des Clientmoduls ist das Aufbringen und Aufheben des Schutzes der Integrität und Vertraulichkeit der zwischen den KOM-LE-Teilnehmern ausgetauschten E-Mail-Nachrichten. Dabei kommuniziert das Clientmodul mit dem Clientsystem, dem KOM-LE-Fachdienst und nutzt mehrere Dienste der TI-Plattform. Optional kann das Clientmodul in das Clientsystem integriert werden. Abbildung 2 stellt die grundlegenden Elemente der KOM-LE-Architektur dar.

Abbildung 2: Abb_KOMLE_Komp KOM-LE-Komponenten

Die im Clientmodul bearbeitende E-Mail-Nachrichten kleiner 25 MB werden beim Senden entsprechend dem KOM-LE-S/MIME-Profil [gemSMIME_KOMLE] digital signiert und verschlüsselt und beim Empfangen entschlüsselt und deren Signatur geprüft. Bei E-Mail-Nachrichten größer 25 MB wird der Anhang aus der E-Mail extrahiert und auf einem separaten Speicherort (Fachdienst) verschlüsselt abgelegt. Das KOM-LE-S/MIME-Profil konkretisiert die S/MIME-Spezifikation und stellt sicher, dass die Interoperabilität zwischen den verschiedenen KOM-LE-Komponenten sowie der Schutz von Integrität und Vertraulichkeit für alle personenbezogenen medizinischen Daten gewährleistet werden.

Jede dem KOM-LE-S/MIME-Profil entsprechende Nachricht hat die in Abbildung 3 dargestellte Struktur. Die äußere Nachricht ist eine entsprechend dem S/MIME-Standard signierte und verschlüsselte E-Mail-Nachricht. Die innere Nachricht ist eine im Clientsystem erzeugte E-Mail-Nachricht, die Nutzdaten enthält und als message/rfc822 Anhang in die äußere Nachricht verpackt ist.

Abbildung 3: Abb_Struk_KOMLE_Msg Struktur einer KOM-LE-Nachricht

Die durch das Clientmodul versendeten Nachrichten können vom Client optional gekennzeichnet werden. Das hierfür notwendiges Attribut im Header der Mail (Dienstkennung) wird im Kapitel 3.6 beschrieben. Erfolgte durch den Client keine Belegung dieses Attributes, wird durch das Clientmodule eine Default-Kennung gesetzt. Um auch die Abholung der auf dem Mail-Server ankommenden Nachrichten inhaltsabhängig durchführen zu können, wird das Header-Feld mit der Information zur Kennzeichnung der Mail in den äußeren Header der signierten und verschlüsselten inneren Nachricht übernommen.

Zusätzlich wird das Clientmodul um das Administrationsmodul erweitert (siehe auch Kap. 3.7). Mit Hilfe des Administrationsmoduls kann sich der KOM-LE-Teilnehmer beim Fachdienst registrieren, seinen Registrierungsstatus abfragen oder eine Deregistrierung vornehmen. Zugleich kann über das Administrationsmodul das benötigte Clientzertifikat (PKCS#12 - Datei) heruntergeladen werden.

Abbildung 4 Administrationsmodul für die Kommunikation mit dem Account Manager

Der Funktionsumfang des Clientmodules kann optional in das Clientsystem integriert werden. Somit ist kein separates Clientmodul mehr notwendig.

Wenn das Clientmodul in das Clientsystem (PVS) integriert wird richten sich die Anforderungen des Clientmodul an das Clientsystem (PVS). Durch die optionalen Integration entfallen alle Anforderungen an die Schnittstelle zwischen Clientsystem und Clientmodul, da diese nicht mehr existiert. 

In diesem Szenario gilt für Anforderungen, die nur Anteile auf die Schnittstelle zwischen Clientsystem und dem Clientmodul enthalten (z.B. "vom Clientsystem erhaltene E-Mail-Nachrichten"), dass diese Anteile entfallen und die restliche Anforderung umgesetzt werden muss.

Folgende Anforderungen an die Schnittstelle zwischen Clientsystem und dem Clientmodul entfallen bei der Integration in das Clientsystem:

• KOM-LE-A_2003
• KOM-LE-A_2007
• KOM-LE-A_2008
• KOM-LE-A_2009
• KOM-LE-A_2010
• KOM-LE-A_2011
• KOM-LE-A_2012
• KOM-LE-A_2015
• KOM-LE-A_2016
• KOM-LE-A_2018
• KOM-LE-A_2176
• KOM-LE-A_2029
• KOM-LE-A_2030
• KOM-LE-A_2031
• KOM-LE-A_2032
• KOM-LE-A_2033
• KOM-LE-A_2034
• KOM-LE-A_2037
• KOM-LE-A_2038
• KOM-LE-A_2040
• KOM-LE-A_2041
• KOM-LE-A_2044
• KOM-LE-A_2046
• KOM-LE-A_2047
• KOM-LE-A_2066
• KOM-LE-A_2067
• KOM-LE-A_2181
• KOM-LE-A_2094

3 Produktfunktionen

3.1 Allgemeine Anforderungen

Durch die Limitierung des Konnektors sind E-Mail-Nachrichten bis zu einer Größe von 25 MB möglich. Wenn der Empfänger einen KOM-LE-Client ab Version 1.5 nutzt, können mit der in Kap. 3.2 beschriebenen Vorgehensweise auch Mails mit größeren Anhängen versendet werden. Der Mail-Body ohne Anhänge darf aber weiterhin die Größe von 25 MB nicht übersteigen und muss durch das KOM-LE-Clientmodul und den KOM-LE-Fachdienst verarbeitet werden.

Die PKCS#12-Datei wird für die Registrierung eines KOM-LE-Teilnehmers sowie bei Ablauf des Clientzertifikates benötigt.

Diese Spezifikation erläutert nicht alle Schritte und Einzelheiten der SMTP- und POP3-Kommunikation zwischen dem Clientsystem, dem KOM-LE-Clientmodul und dem KOM-LE-Fachdienst. Es setzt voraus, dass das Format einer E-Mail, MIME, SMTP und POP3 dem Leser bekannt sind.

Die Übermittlung der KOM-LE-Version vom Anbieter kann hierbei postalisch erfolgen. Die jeweilige Client-Version kann aus dem LDAP-Directory Attribut: KOM-LE-Version vom VZD entnommen werden.

Die Übermittlung der Fehlernachrichten ermöglicht somit eine automatische Auswertung und Klassifizierung der eingehenden Nachrichten auf der Empfängerseite durch Auswertung des Mail-Header Attributs.

3.2 Umgang mit großen Anhängen

Dieses Kapitel beschreibt die Verarbeitung von Mails, welche die Nettogröße von 25 MB überschreiten. Die Größenbeschränkung auf 25 MB basiert auf den Konnektoroperationen zum Signieren und Verschlüsseln. Für diese Operationen existiert eine Größenbeschränkung auf 25 MB.

E-Mails mit einer Gesamtgröße bis zu 25 MB werden entsprechend den Festlegungen im KOM-LE 1.0 behandelt. Übersteigt die Größe einer Mail die 25-MB-Grenze, werden alle Anhänge durch das KOM-LE-Clientmodul aus der Mail entnommen und auf einem Speicher des KOM-LE-Fachdiensts (KAS) abgelegt. Das KOM-LE-Clientmodul ergänzt die Mail um die Links auf die Anhänge und versendet sie als KOM-LE-Mail. Das KOM-LE-Clientmodul des Empfängers erkennt die Links der entfernten Anhänge in der Mail, lädt die Anhänge vom KOM-LE-Fachdienst (KAS) und setzt sie wieder in die Mail ein. 

In [gemSpec_FD_KOMLE]  Kapitel "Schnittstelle I_Attachment_Services" wird der Umgang mit großen Anhängen in einem Sequenzdiagramm erläutert.

3.2.1 Senden von Nachrichten mit großen Anhängen

In diesem Kapitel werden Anforderungen an das Clientmodul formuliert, die es erlauben, große Anhänge zu versenden.

Beispiel (ohne KOM-LE Header) für eine Mail mit zwei Anhängen vor der Entnahme der Anhänge:

From: "Sender" <sender@maildomain.de>
To: <empfaenger@maildomain.de>
Subject: Mail mit zwei Anhängen
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="body_part_boundary"

--body_part_boundary
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Eine Dokument und eine Aufnahme im Anhang.

--body_part_boundary
Content-Type: application/msword; name="MR-2020-04-01-xyz.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="MR-2020-04-01-xyz.doc"

ABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCD
[Anhang gekürzt]
ABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCD
ABCDABCDABCDABCDABCDABCDABCD==

--body_part_boundary
Content-Type: image/jpeg; name="Roentgenbild-375632378.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Roentgenbild-375632378.jpg"

/9j/4AAQSkZJRgABAQEASSBIAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEDAQEBAQEBAQEBAEEBAQEB
[Anhang gekürzt]
RAQFRBcwRD8H6y8B+voDMoSa1I4Md6+UMzwKVdT3W/fz4cotgwwoZDa1sbvrwU1QcEyNlI3KwKwZ
uiFj1Ka6BVAM2WU4rCh+xfXS1/p573//2Q==

--body_part_boundary

Die gleiche Mail nach Entnahme der Anhänge:

From: "Sender" <sender@maildomain.de>
To: <empfaenger@maildomain.de>
Subject: Mail mit zwei Anhängen
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="body_part_boundary"

--body_part_boundary
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Eine Dokument und eine Aufnahme im Anhang.

--body_part_boundary
X-kim-attachment-name MR-2020-04-01-xyz.doc 
X-kim-attachment-link HTTPS://KIM-FD1.telematik.de/CXFDTE82346dfzwr7634tzdfs76sd76sdtzq376e3tzsd 
X-kim-attachment-pass G5Dcs439&4f§dsdgx%h_kdtT%5w3fvCt36dfvxfs$61!2gvduUjs(i 
X-kim-attachment-hash fcf7c1b8749cf99d88e5f34271d636178fb5d130  
X-kim-attachment-typ application/msword 
X-kim-attachment-size 143271
--body_part_boundary
X-kim-attachment-name Roentgenbild-375632378.jpg 
X-kim-attachment-link HTTPS://KIM-FD1.telematik.de/Cduiz763478dfjkdfjhkhgow4784JHKZsdtq376e3t478d 
X-kim-attachment-pass G/4fdiuhcs439&4f§dsdgx%h_kdtT%5w3fvCt36daserfg89345uisrf 
X-kim-attachment-hash fawer3q04985ofisdjüu3945ueg09j09309u3gj0o 
X-kim-attachment-typ image/jpeg 
X-kim-attachment-size 32573
--body_part_boundary

Der KAS ist ein Bestandteil des Fachdiensts. Deshalb gelten für die TLS-Verbindungen (inklusive genutzter Zertifikate) zum KAS ebenfalls die Festlegungen von Kap. 4.1.4.

3.2.2 Empfangen von Nachrichten mit großen Anhängen

In diesem Kapitel werden Anforderungen an das Clientmodul formuliert, die es erlauben, große Anhänge zu empfangen.

Die Mail ist immer kleiner als 25MB und wird als KOM-LE 1.0 Mail empfangen. Die eventuell nötige Ergänzung um die Anhänge erfolgt in den Folgeschritten.

Die Anforderungen an die TLS Authentifizierung und die Zertifikate entsprechen den Anforderungen von dem Fachdienst.

3.3 Senden von Nachrichten

3.3.1 Übersicht

Beim Senden von KOM-LE-Nachrichten sorgt das Clientmodul dafür, dass die gesendeten E-Mail-Nachrichten digital signiert und verschlüsselt dem MailTransfer Agent des KOM-LE-Fachdienstes (weiter im Text als MTA bezeichnet), bei dem der Sender registriert ist, übermittelt werden. Bei E-Mail-Nachrichten größer 25 MB werden alle zur E-Mail-Nachricht gehörenden Anhänge vor der Durchführung der kryptographischen Operationen extrahiert und symmetrisch verschlüsselt auf dem Fachdienst abgespeichert.

Abbildung 4 stellt die Interaktionen zwischen den am Senden von KOM-LE-Nachrichten beteiligten Komponenten dar. Aus der Sicht des Clientsystems agiert das Clientmodul als ein MTA und aus der Sicht des MTAs des Fachdienstes agiert das Clientmodul als MUA. Für Funktionen wie Datentransport, kryptographische Operationen und Kommunikation mit dem Verzeichnisdienst verwendet das Clientmodul entsprechende Dienste der TI-Plattform.

Abbildung 5: Abb_Send_Msg Senden von Nachrichten

Beim Senden von Nachrichten findet die Kommunikation zwischen dem Clientsystem, dem Clientmodul und dem MTA über SMTP statt. Das Clientmodul fungiert als SMTP Proxy, der das Clientsystem mit dem MTA verbindet, die Integrität und Vertraulichkeit der vom Clientsystem gesendeten Nachricht schützt und die Nachricht an den MTA übermittelt.

Sobald die Nachricht komplett dem MTA übertragen wurde und der MTA das Ankommen der Nachricht bestätigt, übergibt das Clientmodul die Verantwortung für die Nachricht an den MTA. Die Übermittlung von Nachrichten zwischen MTAs ist nicht Bestandteil dieser Spezifikation.

Es liegt in der Verantwortung des Clientmoduls sicher zu stellen, dass die Nachricht erfolgreich dem MTA übertragen wird. Falls die Übermittlung einer Nachricht an den MTA fehlschlägt (z.B. bei Verbindungsaufbau mit dem MTA, Authentifizierung gegenüber dem MTA, Verschlüsselung oder Signieren der Nachricht), benachrichtigt das Clientmodul das Clientsystem unter Verwendung entsprechenden SMTP-Antwortcodes über den Fehler.

Beispiel: Verwendet das Clientsystem beim Senden von Nachrichten falsche Anmeldungsdaten, erhält es vom Clientmodul „535 5.7.8 Der Nutzer konnte nicht authentifiziert werden“ als Antwort auf sein AUTH-Kommando.

Das Verhalten des Clientmoduls beim Senden von Nachrichten wird mit Hilfe der in Abbildung 5 dargestellten Zustandsmuster beschrieben werden. Die im Dokument dargestellten Zustände haben nur illustrativen und keinen normativen Charakter. Die Umsetzung kann sich unterscheiden, solange das Ergebnis das Gleiche ist. Die den Zuständen zugeordnete Anforderungen sind normativ, können aber außerhalb des Kontexts dieser Zustände umgesetzt werden.

Abbildung 6: Abb_State_CM_Send Zustände Clientmodul beim Senden von Nachrichten

Das Clientmodul lauscht auf einem TCP Port und wartet bis ein Clientsystem mit ihm eine Verbindung aufbaut. Sobald dies passiert, geht das Clientmodul in den CONNECT-Zustand über und betrachtet die SMTP-Verbindung als geöffnet. Die Verbindung zwischen dem Clientsystem und dem Clientmodul muss mit TLS geschützt werden.

Im CONNECT-Zustand führt das Clientmodul einen SMTP-Dialog mit dem Clientsystem, in dem ihm die Anmeldedaten des Nutzers sowie die Adresse und die Portnummer des MTAs mitgeteilt werden. Sobald die Anmeldedaten und die Adresse des MTAs übermittelt sind, baut das Clientmodul eine über TLS geschützte SMTP-Verbindung mit dem MTA auf, authentifiziert sich und geht in den PROXY-Zustand über.

Im PROXY-Zustand leitet das Clientmodul SMTP-Kommandos und SMTP-Antwortcodes zwischen dem Clientsystem und dem MTA weiter, bis das Clientsystem mit dem DATA-Kommando die Übertragung einer Nachricht initiiert. Sobald das Clientsystem anfängt, Inhalte einer Nachricht zu übertragen, geht das Clientmodul in den PROCESS-Zustand über.

In PROCESS-Zustand wird die Nachricht entsprechend dem KOM-LE-S/MIME-Profile [gemSMIME_KOMLE] geschützt und anschließend an den MTA übermittelt. Sobald die Nachricht erfolgreich an den MTA übertragen wurde oder im Fehlerfall, geht das Clientmodul in den PROXY-Zustand zurück.

Nachdem die Verbindungen zwischen dem Clientsystem, dem Clientmodul und dem MTA aufgebaut wurden, übermittelt das Clientmodul die SMTP-Meldungen zwischen dem Clientsystem und dem MTA so lange die beiden Verbindungen bestehen.

3.3.2 CONNECT-Zustand

Sobald die TCP-Verbindung zwischen dem Clientsystem und dem Clientmodul aufgebaut ist, geht das Clientmodul in den CONNECT-Zustand über.

3.3.2.1 Initialisierung

Beispiel einer solchen Begrüßung: 220 KOM-LE-Clientmodul ESMTP

Das Clientmodul führt einen SMTP-Dialog mit dem Clientsystem bis zum Punkt, an dem das Clientsystem ihm die Adresse und die Portnummer des MTAs als einen Teil des während des Authentifizierungsverfahrens übertragenen Benutzernamens mitteilt (siehe Kapitel 3.2.2.2).

Tabelle 1 beschreibt Antworten, die das Clientmodul dem Clientsystem im CONNECT-Zustand sendet.

Tabelle 2: Tab_SMTP_Ant_Init Antworten Clientmodul im CONNECT-Zustand

3.3.2.2 Verbindungsaufbau mit MTA

Das Clientmodul kann die Verbindung mit dem MTA nur dann aufbauen, wenn ihm das Clientsystem die Adresse des MTAs und die Portnummer des SMTP-Dienstes übermittelt. Das Clientmodul erwartet, dass ihm der Domain Name oder die IP-Adresse und die Portnummer während des Authentifizierungsverfahrens als Teil des Benutzernamens mitgeteilt werden.

Das Clientmodul führt das Authentifizierungsverfahren mit dem Clientsystem bis zu dem Punkt, an dem es mit dem entsprechenden Antwortcode die Authentifizierung akzeptieren oder ablehnen muss. Das Clientmodul allein kann das Clientsystem nicht authentifizieren. Die Authentizität der Zugangsdaten kann nur vom MTA überprüft werden. Dazu authentifiziert sich das Clientmodul im Auftrag vom Clientsystem gegenüber dem MTA.

Die MTA-Adresse und die Portnummer des SMTP-Dienstes sind als Teil des SMTP-Benutzernamens vom Clientsystem zu übergeben. Sie sind vom eigentlichen Benutzernamen durch das Zeichen ’#’ getrennt und als adresse:port String formatiert.

Um mit der SM-B über den Konnektor kommunizieren zu können, werden dem KOM-LE-Clientmodul ebenfalls als Teil des SMTP-Benutzernamens, die Prameter

• MandantId,
• ClientSystemId und
• WorkplaceId

übergeben (siehe Kapitel 3.5 und [gemSpec_Kon] für Details zu MandantId, ClientSystemId und WorkplaceId). Die Parameter entsprechen denen des aufrufenden Clients und werden voneinander durch das Zeichen ’#’ getrennt.

Der Aufbau des SMTP-Benutzernamens entspricht somit dem folgenden Muster:

Abbildung 7: Abb_MTA_Nutzername Format des SMTP- Benutzernamens

Beispiel:

Bei folgenden Informationen

• Benutzername des Clients = „ erik.mustermann@komle.de“,
• Domain Adresse des MTAs = „mail.komle.de“ und Portnummer = 465,
• MandantId = 1,
• ClientsystemId = KOM_LE,
• WorkplaceId = 7

erwartet das Clientmodul, dass das Clientsystem ihm folgenden SMTP-Benutzernamen als String überträgt:

erik.mustermann@komle.de#mail.komle.de:465#1#KOM_LE#7

Das KOM-LE-Clientmodul bricht die Kommunikation mit dem entsprechende SMTP-Antwortcode ab (siehe Tabelle 2), wenn der erhaltene SMTP-Benutzername nicht alle erforderlichen Parameter enthält. Beinhaltet der SMTP-Benutzername zusätzliche durch ‚#’ abgegrenzte Parameter (z.B. #UserId), werden diese Parameter vom Clientmodul nicht ausgewertet und der Sendevorgang wird fortgesetzt.

Für SMTP-Authentifizierung existieren sowohl Mechanismen für die Übertragung von Nutzername und Passwort im Klartext (PLAIN und LOGIN) als auch Challenge-Response-Mechanismen. Die auf Challenge-Response (DIGEST-MD5, CRAM-MD5, NTLM) basierenden Mechanismen machen das Extrahieren des Passworts aus der Challenge-basierten Response für das Clientmodul unmöglich. Deshalb werden für die SMTP-Authentifizierung nur die PLAIN oder LOGIN-Mechanismen verwendet.

Sobald das Clientmodul die Anmeldedaten des Nutzers erhält, extrahiert es die Adresse des MTAs und die Portnummer des SMTP-Dienstes aus dem Nutzernamen und baut damit  die Verbindung zum MTA auf. Die Verbindung wird über TLS geschützt. Details zum Aufbau der TLS-Verbindung werden in Kapitel 4.1.3 beschrieben.

Tabelle 2 enthält SMTP-Antwortcodes, die das Clientmodul dem Clientsystem bei einem Verbindungsaufbau mit dem MTA übermittelt.

Tabelle 3: Tab_SMTP_Verbindung SMTP-Antwortcodes für MTA-Verbindungsaufbau

Die Verbindungen zwischen dem Clientsystem und dem Clientmodul sowie zwischen dem Clientmodul und dem MTA bleiben solange offen, bis eine von beiden geschlossen oder abgebrochen wird. Sobald eine der beiden Verbindungen geschlossen oder abgebrochen wird, übermittelt das Clientmodul die ausstehenden SMTP-Meldungen und schließt die andere Verbindung. Die SMTP-Sitzung wird damit für den MTA, das Clientsystem und das Clientmodul beendet.

Beispiel: Nachdem das Clientmodul das QUIT-Kommando vom Clientsystem erhalten und dem MTA übermittelt hat, bestätigt der MTA das Ankommen des Kommandos mit dem „221“ Antwortcode und schließt die Verbindung mit dem Clientmodul. Das Clientmodul übermittelt den „221“ Antwortcode dem Clientsystem und schließt die Verbindung mit dem Clientsystem.

Nachdem sich das Clientsystem gegenüber dem MTA erfolgreich authentifiziert hat, geht das Clientmodul in den PROXY-Zustand über. Anderenfalls bleibt das Clientmodul im CONNECT-Zustand.

3.3.3 PROXY-Zustand

Im PROXY-Zustand vermittelt das Clientmodul SMTP-Meldungen und Antwortcodes zwischen dem Clientsystem und dem MTA. Das Clientmodul bleibt in diesem Zustand bis das Clientmodul das DATA-Kommando bekommt und der MTA das Erhalten von diesem Kommando mit dem Antwortcode „354“ bestätigt. Das Clientmodul leitet den Antwortcode „354“ an das Clientsystem weiter und geht in den PROCESS-Zustand über.

3.3.4 PROCESS-Zustand

Im PROZESS-Zustand nimmt das Clientmodul die Inhalte der vom Clientsystem gesendeten Nachricht entgegen. Mit Hilfe von Diensten der TI-Plattform schützt es die Vertraulichkeit und Integrität der Nachricht entsprechend dem KOM-LE-S/MIME-Profil [gemSMIME_KOMLE]. Anschließend leitet das Clientmodul die geschützte Nachricht an den MTA, bei dem der Nutzer registriert ist, weiter. Im Erfolgsfall wird das Clientsystem über das Versenden der Nachricht informiert. Im Fehlerfall wird das Clientsystem mit dem entsprechenden Antwortcode über den Fehler benachrichtigt. Im folgenden Text wird eine entsprechend dem KOM-LE-S/MIME-Profil geschützte Nachricht auch als KOM-LE-S/MIME-Nachricht bezeichnet.

3.3.4.1 Empfang und Weiterleitung einer Nachricht

Nachdem die Bereitschaft zum Empfangen der Nachricht dem Clientsystem mit dem Antwortcode „354“ bestätigt wurde, erwartet das Clientmodul, dass das Clientsystem mit der Übertragung der Nachricht fortfährt. Die Inhalte der Nachricht werden im Clientmodul zwischengespeichert und sobald das Clientsystem durch die „<CRLF>.<CRLF>“ Zeichensequenz das Ende der Nachricht markiert, werden die Inhalte der Nachricht im Clientmodul durch digitale Signatur und die Verschlüsselung geschützt. Die Details werden im Kapitel 3.2.4.1.1 beschrieben.

KOM-LE bietet die Möglichkeit Nachrichten, die beim Abholen nicht entschlüsselt wurden (z.B. auf Grund eines fehlenden HBA mit dem entsprechenden privaten Schlüssel), nachträglich zu entschlüsseln. Um die nachträgliche Entschlüsselung einer verschlüsselten KOM-LE-Nachricht durchführen zu können, schickt der Empfänger die verschlüsselte Nachricht als ein message/rfc822 Anhang in einer neuen Nachricht an seine eigene E-Mail-Adresse. Beim nächsten Abholvorgang kann diese Nachricht, sofern die erforderliche Karte vorhanden ist, durch das Clientmodul entschlüsselt werden. Werden solche Nachrichten im Clientmodul erkannt, werden sie weder signiert noch verschlüsselt. Stattdessen wird die verschlüsselte KOM-LE-Nachricht aus dem message/rfc822 Anhang extrahiert und die from Header-Elemente werden durch das from Header-Element (E-Mail-Adresse des Absenders) der angekommenen multipart MIME-Nachricht ersetzt. Anschließend wird die Nachricht dem MTA übermittelt. Die Details werden im Kapitel 3.2.4.1.2 beschrieben.

Die Benachrichtigung des Clientsystems über den Erfolg des Sendens einer Nachricht findet nur dann statt, wenn der MTA die Übernahme der Verantwortung für die Nachricht mit positiven Erledigungsstatus über den „250“ Antwortcode bestätigt. Ab diesem Moment gilt die Nachricht für das Clientsystem als versendet und der MTA hat sich zu ihrer Lieferung oder Benachrichtigung des Senders über einen Fehlerfall verpflichtet.

Nachdem das Clientsystem über das erfolgreiche Senden der Nachricht oder über einen Fehlerfall mit entsprechendem Antwortcode benachrichtigt wurde, löscht das Clientmodul die zwischengespeicherten Inhalte der Nachricht und geht zurück in den PROXY-Zustand.

3.3.4.1.1 Bearbeitung einer ungeschützten Nachricht

Um die Vertraulichkeit und die Integrität einer Nachricht zu schützen wird die Nachricht entsprechend dem KOM-LE-S/MIME-Profil signiert und verschlüsselt. Für das Signieren und die Verschlüsselung nutzt das Clientmodul die Dienste der TI-Plattform. Die folgende Abbildung stellt den prinzipiellen Ablauf und die Aktivitäten des Clientmoduls beim Erzeugen einer dem KOM-LE-S/MIME-Profil entsprechenden Nachricht dar. Hierbei wird von einer E-Mail-Nachricht Größe von kleiner 25 MB ausgegangen.

Abbildung 8: Abb_Sig_Verschl Signieren und Verschlüsseln entsprechend S/MIME Profil

Für das digitale Signieren einer Nachricht verwendet das Clientmodul den privaten PrK.HCI.OSIG-Schlüssel der SM-B. Der Zugriff auf die entsprechende Karte und die Erstellung der Signatur erfolgt über die Aufrufe der entsprechenden Operationen der Außenschnittstelle des Konnektors. Eine detaillierte Beschreibung erfolgt im Kapitel 3.5.1.

Wenn das Signieren fehlschlägt, wird das Senden der Nachricht abgebrochen indem dem MTA das RSET-Kommando übermittelt wird und das Clientsystem mit dem Antwortcode „451“ inklusive der entsprechenden Fehlermeldung über den Fehlerfall informiert wird.

Ein Beispiel einer diesem Profil konformen Nachricht für den Aufbau des binären CMS-Container ist in [gemSMIME_KOMLE]. enthalten. Insbesondere wird auf die Aufnahme des „Content Headers“ hingewiesen.

Folgend ein Beispiel für den SOAP-Request beim Signieren:

<?xml version="1.0" encoding="UTF-8" ?>

<SIG:SignDocument xmlns:CERTCMN="http://ws.gematik.de/conn/CertificateServiceCommon/v2.0" xmlns:CONN="http://ws.gematik.de/conn/ConnectorCommon/v5.0" xmlns:CCTX="http://ws.gematik.de/conn/ConnectorContext/v2.0" xmlns:SIG="http://ws.gematik.de/conn/SignatureService/v7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema">

  <CONN:CardHandle>zDgq6V5EsA</CONN:CardHandle>

  <SIG:Crypt>RSA</SIG:Crypt>

  <CCTX:Context>

  <CONN:MandantId>Praxis Dr. Mustermann</CONN:MandantId>

  <CONN:ClientSystemId>Mediakom-PVS-3000</CONN:ClientSystemId>

  <CONN:WorkplaceId>Arztzimmer2</CONN:WorkplaceId>

  </CCTX:Context>

  <SIG:TvMode>NONE</SIG:TvMode>

  <SIG:SignRequest RequestID="SignRequestNo_001">

  <SIG:OptionalInputs>

  <dss:SignatureType>urn:ietf:rfc:5652</dss:SignatureType>

  <dss:Properties>

  <dss:SignedProperties>

  <dss:Property>

  <dss:Identifier>RecipientEmailsAttribute</dss:Identifier>

  <dss:Value>

<CMSAttribute>QnNVakJzUjA5RWJHaGpaMGRUUVV4TlVqQnNSMDlFYkdoalowZFRRVXhOUVVGQlVRVU

ZCVVVOQlJVMXRRMXAwZFUxR1VYaEVVemhp</CMSAttribute>

  </dss:Value>

  </dss:Property>

  </dss:SignedProperties>

  </dss:Properties>

  <SIG:IncludeEContent>true</SIG:IncludeEContent>

  </SIG:OptionalInputs>

  <SIG:Document ShortText="none">

<dss:Base64Data>TUlNRS1WZXJzaW9uOiAxLjANCkNvbnRlbnQtdHlwZTogdGV4dC9wbGFpbjsgY2hh

cnNldD1pc28tODg1OS0xNQ0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogOGJpdA0KRnJvbTogPGhh

bnMubXVzdGVyYXJ6dEBwcmF4aXNBLmRlPg0KVG86IDxldmEubXVzdGVyYXJ6dEBwcmF4aXNCLmRlPg0K

U3ViamVjdDog3GJlcndlaXN1bmcgSHIuIE0uIFBhdGllbnRCDQpEYXRlOiBNb24sIDExIE5vdiAyMDEz

IDE0OjM0OjI3ICswMTAwDQoNClNlaHIgZ2VlaHJ0ZSBGcmF1IEtvbGxlZ2luIERyLiBNdXN0ZXJhcnp0

LA0KDQpoaWVybWl0IPxiZXJ3ZWlzZSBpY2ggSWhuZW4gSHIuIE0uIFBhdGllbnRCIGF1ZiBHcnVuZCAu

Li4uDQoNCk1pdCBmcmV1bmRsaWNoZW4gR3L832VuLA0KDQpEci4gSGFucyBNdXN0ZXJhcnp0</dss:Ba

se64Data>

  </SIG:Document>

  <SIG:IncludeRevocationInfo>false</SIG:IncludeRevocationInfo>

  </SIG:SignRequest>

</SIG:SignDocument>

Da der Versand einer Nachricht an mehrere Empfänger erfolgen kann und das Clientmodul nicht erkennt, ob alle Empfänger ECC beherrschen, muss das Signieren einer Nachricht immer mit dem RSA-Schlüssel der SM-B erfolgen.

Die Verschlüsselung erfolgt sowohl für den Sender als auch für alle Empfänger. Die erforderlichen Verschlüsselungszertifikate C.HCI.ENC für Institutionen und C.HP.ENC für Leistungserbringer werden im Verzeichnisdienst zur Verfügung gestellt. Für die Suche nach den passenden Einträgen im Verzeichnisdienst wird die KOM-LE-E-Mail-Adresse als Suchschlüssel verwendet. Wenn der Sender bzw. ein Empfänger mehrere Verschlüsslungszertifikate hat (z.B. wenn dem Empfänger ein neuer HBA  ausgegeben wurde und der alte noch gültig ist), wird die Nachricht mit allen vorhandenen Verschlüsselungszertifikaten verschlüsselt.

Folgend ein Beispiel für den SOAP-Request beim Verschlüsseln:

<?xml version="1.0" encoding="UTF-8" ?>

<CRYPT:EncryptDocument xmlns:CONN="http://ws.gematik.de/conn/ConnectorCommon/v5.0" xmlns:CCTX="http://ws.gematik.de/conn/ConnectorContext/v2.0" xmlns:CRYPT="http://ws.gematik.de/conn/EncryptionService/v6.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema">

  <CCTX:Context>

  <CONN:MandantId>Praxis Dr. Mustermann</CONN:MandantId>

  <CONN:ClientSystemId>Mediakom-PVS-3000</CONN:ClientSystemId>

  <CONN:WorkplaceId>Arztzimmer2</CONN:WorkplaceId>

  </CCTX:Context>

  <CRYPT:RecipientKeys>

  <CRYPT:CertificateOnCard>

  <CONN:CardHandle>zDgq6V5EsA</CONN:CardHandle>

  <CRYPT:Crypt> ECC </CRYPT:KeyReference>

  </CRYPT:CertificateOnCard> <CRYPT:Certificate>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</CRYPT:Certificate>

  </CRYPT:RecipientKeys>

  <CONN:Document>

<dss:Base64Data>QnNVakJzUjA5RWJHaGpaMGRUUVV4TlVqQnNSMDlFYkdoalowZFRRVXhOUV

VGQlVRVUZCVVVOQlJVMXRRMXAwZFUxR1VYaEVVemhp</dss:Base64Data>

  </CONN:Document>

  <CRYPT:OptionalInputs>

  <CRYPT:EncryptionType>urn:ietf:rfc:5652</CRYPT:EncryptionType>

  <CRYPT:UnprotectedProperties>

  <dss:Property>

  <dss:Identifier>RecipientEmailsAttribute</dss:Identifier>

  <dss:Value>

<CMSAttribute>QnNVakJzUjA5RWJHaGpaMGRUUVV4TlVqQnNSMDlFYkdoalowZFRRVXhOUVVG

QlVRVUZCVVVOQlJVMXRRMXAwZFUxR1VYaEVVemhp</CMSAttribute>

  </dss:Value>

  </dss:Property>

  </CRYPT:UnprotectedProperties>

  </CRYPT:OptionalInputs>

</CRYPT:EncryptDocument>

Zum Verschlüsseln der Nachricht bezieht das Clientmodul die erforderlichen Zertifikate aus dem Verzeichnisdienst der TI. Vor der Verwendung der Zertifikate für die Verschlüsselung muss das Clientmodul prüfen, ob der verwendete Konnektor die ECC-Kryptographie unterstützt. Ist dies nicht der Fall, dürfen im Verzeichnisdienst gefundene ECC-Zertifikate nicht für die Verschlüsselung benutzt werden. Unterstützt der Konnektor ECC, sind sowohl die RSA- als auch die ECC-Zertifikate für die Verschlüsselung zu verwenden. Durch diese Herangehensweise wird sichergestellt, dass auch Empfänger, die noch kein ECC beherrschen, die Nachricht entschlüsseln können. Dieses Prinzip gilt solange, bis alle TI-Beteiligten ECC beherrschen und somit die RSA-Zertifikate gesperrt sind.

Nachdem die Nachricht erfolgreich signiert wurde und die entsprechenden Verschlüsselungszertifikate zur Verfügung stehen, führt das Clientmodul die Verschlüsselung der Nachricht für alle Empfänger bzw. Sender durch. Die Empfänger werden über die E-Mail-Adressen aus den RCPT-Kommandos identifiziert. Die Sender werden über die E-Mail-Adressen im sender Header-Element identifiziert. Wenn der Header der Nachricht kein sender Element enthält, werden die E-Mail-Adressen des Senders aus dem from Header-Element übernommen.

Beim Verschlüsselungsvorgang sind die folgenden Szenarien möglich:

• Die Nachricht kann für alle E-Mail-Adressen (sowohl Sender als auch Empfänger) verschlüsselt werden.
• Es gibt E-Mail-Adressen, für die aufgrund der fehlenden oder nicht gültigen Zertifikate die Nachricht nicht verschlüsselt werden kann. In diesem Fall wird die Nachricht mit den verfügbaren Zertifikaten verschlüsselt und an den MTA übermittelt. Die E-Mail-Adressen für die die Verschlüsselung nicht durchgeführt werden konnte werden aus dem Header entfernt. Der Absender der Nachricht wird über eine im Clientmodul generierte und an den MTA übermittelte E-Mail über den Fehlerfall informiert. Die Nachricht mit der Fehlermeldung wird weder signiert noch verschlüsselt.
• Wenn die Verschlüsselung für keinen der Empfänger durchgeführt werden kann, wird das Senden der Nachricht abgebrochen. Dabei wird dem MTA das RSET-Kommando gesendet und das Clientsystem wird mit dem Antwortcode „451“ und der entsprechenden Fehlermeldung über den Fehlerfall informiert.

Die Verschlüsselung erfolgt über die Aufrufe der entsprechenden Operationen der Außenschnittstelle des Konnektors. Eine detaillierte Beschreibung erfolgt in Kapitel 3.5.3.

Das KOM-LE-S/MIME-Profil fordert, dass jede entsprechend dem Profil verschlüsselte Nachricht das recipient-emails Attribut enthält. In diesem Attribut werden  Zusammenhänge zwischen den für die Verschlüsselung verwendeten Zertifikaten und den E-Mail-Adressen der Empfänger bzw. des Senders angegeben. Das Clientmodul befüllt dieses Attribut nur mit den E-Mail-Adressen für die die Nachricht erfolgreich verschlüsselt werden konnte.

Um die Anzahl von Anfragen an den Verzeichnisdienst und die Bearbeitungszeiten zu reduzieren werden die für die Verschlüsselung verwendeten Zertifikate für eine konfigurierbare Zeitdauer im Clientmodul gecached.

Die folgenden Schritte stellen den Schutzvorgang für eine Nachricht im Clientmodul dar. Die Schritte haben einen beschreibenden und nicht normativen Charakter. Die Umsetzung kann sich unterscheiden, solange die Anforderungen des Dokuments erfüllt sind.

1. Der Cache und anschließend falls erforderlich der Verzeichnisdienst werden für Verschlüsselungszertifikate der Empfänger und Sender durchgesucht. Die entsprechenden E-Mail-Adressen dienen als die Suchschlüssel.
2. Der Signaturdienst der TI-Plattform wird mit der zu sendenden Nachricht und der Referenz auf den Signaturschlüssel als Aufrufparameter aufgerufen.
3. Der Verschlüsselungsdienst der TI-Plattform wird mit der signierten Nachricht und den gefundenen Verschlüsselungszertifikaten als Aufrufparameter aufgerufen.
4. Die TI-Plattform prüft den Sperrstatus der übergebenen Verschlüsselungszertifikate und führt die Verschlüsselung durch, wenn alle Zertifikate gültig sind. Sollte die Prüfung eines oder mehreren Zertifikate als nicht gültig ausweisen, bricht die TI-Plattform den Verschlüsselungsvorgang ab. Falls sich unter den ungültigen Zertifikaten die aus dem Cache geholten Zertifikate befinden, wird der Verzeichnisdienst nach Ersatzzertifikaten durchsucht.

1. Falls Ersatzzertifikate gefunden werden, wird der Verschlüsselungsvorgang wiederholt.
2. Werden keine Ersatzzertifikate gefunden, werden diesen Zertifikaten entsprechende Empfänger aus dem Header der Nachricht entfernt und über den Fehlerfall mit Hilfe einer im Clientmodul generierten E-Mail informiert. Die ursprüngliche Nachricht wird an diese Empfänger nicht gesendet, weil sie nicht in der Lage sind, diese Nachricht zu entschlüsseln.

Abbildung 9: Abb_Verschl_Msg Verschlüsselung einer Nachricht

Abbildung 8 stellt die oben beschriebenen Schritte als Aktivitätsdiagramm dar.

Nachdem die Verschlüsselung durchgeführt wurde, verpackt das Clientmodul das vom Konnektor verschlüsselte CMS-Objekt in eine äußere Nachricht entsprechend KOM-LE-S/MIME-Profil und überträgt die geschützte Nachricht an den MTA.

3.3.4.1.2 Bearbeitung einer geschützten KOM-LE-Nachricht

Wenn während eines Abholvorgangs eine KOM-LE-Nachricht nicht im Clientmodul entschlüsselt werden konnte, wird sie dem Clientsystem als eine message/rfc822 Einheit mit einem Fehlertext geliefert (siehe das Beispiel im Kapitel 3.3.4.2.1). Um die Nachricht im Anhang nachträglich zu entschlüsseln und ihre Signatur prüfen zu können, muss der Nutzer die erhaltene Nachricht an seine eigene E-Mail-Adresse senden. Beim nächsten Abholvorgang wird diese Nachricht dann nochmalig im Clientmodul aufbereitet.

Beispiel für die oben beschriebene Transformation:

MIME-Version: 1.0

Content-Type: multipart/mixed; boundary="unique-boundary-1"

Subject: WG: Signed and encrypted in attachment

Date: Fri, 10 Feb 2012 14:29:21 +0100

From: musterfrau@komle.de

To: musterfrau@komle.de

This is a multi-part message in MIME format.

--unique-boundary-1

Content-Type: text/plain;    charset="iso-8859-1"

Content-Transfer-Encoding: quoted-printable

Der f=FCr die Entschl=FCsselung der Nachricht ben=F6tigte Schl=FCssel =

wurde nicht gefunden. =DCberpr=FCfen Sie ob die entsprechende Karte =

gesteckt ist und leiten Sie diese Nachricht an Ihre eigene Email Adresse =

(musterfrau@komle.de) weiter. Beim n=E4chsten Abholen der Nachricht =

wird der Entschl=FCsselungsvorgang wiederholt.

--unique-boundary-1

Content-Type: message/rfc822    

X-KOM-LE-Version: 1.0

MIME-Version: 1.0

Content-Type: application/pkcs7-mime; smime-type=enveloped-data;name="smime.p7m";

Content-Transfer-Encoding: base64

Content-Disposition: attachment;    filename="smime.p7m"

Subject: KOM-LE Nachricht

Date: Fri, 9 Feb 2012 12:07:17 +0100

From: mustermann@komle.de

To: musterfrau@komle.de

Cc: mustermann2@komle.de

<verschlüsselter Inhalt>

--unique-boundary-1

Im Clientmodul wird diese Nachricht entsprechend der Anforderung [KOM-LE-A_2029] aufbereitet:

X-KOM-LE-Version: 1.0

MIME-Version: 1.0

Content-Type: application/pkcs7-mime;

smime-type=enveloped-data; name="smime.p7m"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;    filename="smime.p7m"

Subject: KOM-LE Nachricht

Date: Fri, 9 Feb 2012 12:07:17 +0100

From: mustermann@komle.de

To: musterfrau@komle.de

Cc: mustermann2@komle.de

<Verschlüsselter Inhalt>

3.3.5 Beispiele

Das Clientsystem (C) verbindet sich mit dem Clientmodul (M) und sendet dem MTA-Server (S) eine Nachricht (im Beispiel werden auch die Zustände des Clientmoduls dargestellt):

C:     <das Clientsystem öffnet eine mit TLS geschützte Verbindung mit dem Clientmodul>

M:    <CONNECT Zustand>

M->C: 220 KOM-LE Clientmodul ESMTP

C->M: EHLO [192.168.1.5]

M->C: 250 – SIZE 35882577

M->C: 250 - AUTH LOGIN PLAIN

M->C: 250 – 8BITMIME

M->C: 250 ENCHANCEDSTATUSCODES

C->M: AUTH LOGIN

M->C: 334 VXNlcm5hbWU6

C->M: bXVzdGVybWFubkBrb21sZS5kZSNtYWlsLmtvbWxlLmRlOjU4NyMxI0tPTS1MRSM3==

M->C: 334 UGFzc3dvcmQ6

C->M: lkajsdfvlj

M:    <das Clientmodul öffnet eine mit TLS geschützte Verbindung mit dem MTA>

S->M: 220 SMTP Server ESMTP

M->S: EHLO [192.168.1.5]

S->M: 250 – SIZE 35882577

S->M: 250 - AUTH LOGIN PLAIN

S->M: 250 – 8BITMIME

S->M: 250 ENCHANCEDSTATUSCODES

M->S: AUTH LOGIN

S->M: 334 VXNlcm5hbWU6

M->S: bXVzdGVybWFubkBrb21sZS5kZQ==

S->M: 334 UGFzc3dvcmQ6

M->S: lkajsdfvlj

S->M: 235 2.7.0 Authentication successful

M:     <PROXY Zustand>

M->C: 235 2.7.0 Authentication successful

C->M: MAIL FROM:<mustermann@komle.de>

M->S: MAIL FROM:<mustermann@komle.de>

S->M: 250 OK

M->C: 250 OK

C->M: RCPT TO:<musterfrau@komle.de>

M->S: RCPT TO:<musterfrau@komle.de>

S->M: 250 OK

M->C: 250 OK

C->M: DATA

M->C: 354 Start mail input; end with <CRLF>.<CRLF>

M:    <PROCESS Zustand>

C->M: From: "Max Mustermann" <mustermann@komle.de>

C->M: To: "Erika Musterfrau" <musterfrau@komle.de>

C->M: Subject: Biopsie Ergebnisse für Frau S. Muster

C->M: Date: Mon, 30 Jan 2012 13:14:12 +0100

C->M:

C->M: <Inhalt der KOM-LE Nachricht>

C->M: .

M:    <Die Nachricht wird im Clientmodul aufbereitet>

M->S: DATA

S->M: 354 Start mail input; end with <CRLF>.<CRLF>

M->S: X-KOM-LE-Version: 1.0

M->S: MIME-Version: 1.0

M->S: From: "Max Mustermann" <mustermann@komle.de>

M->S: To: "Erika Musterfrau" <musterfrau@komle.de>

M->S: Subject: KOM-LE Nachricht

M->S: Date: Mon, 30 Jan 2012 13:14:12 +0100

M->S: Content-Type: application/pkcs7-mime; mime-type=enveloped-data;name=smime.p7m

M->S: Content-Transfer-Encoding: base64

M->S: Content-Disposition: attachment; filename=smime.p7m

M->S:

M->S: <verschlüsselter Inhalt der KOM-LE Nachricht>

M->S: .

M:    <PROXY Zustand>

S->M: 250 Ok

M->C: 250 Ok

C->M: QUIT

M->S: QUIT

S->M: 221 Bye

S:    <der MTA schließt die Verbindung mit dem Clientmodul>

M->C: 221 Bye

M:    <das Clientmodul schließt die Verbindung mit dem Clientsystem>

Das Senden einer Nachricht wird abgebrochen, weil die Anmeldedaten keine MTA-Adresse erhalten:

C:     <das Clientsystem öffnet eine mit TLS geschützte Verbindung mit dem Clientmodul>

M:     <CONNECT Zustand>

M->C: 220 KOM-LE Clientmodul ESMTP

C->M: EHLO [192.168.1.5]

M->C: 250 – SIZE 35882577

M->C: 250 - AUTH LOGIN PLAIN

M->C: 250 – 8BITMIME

M->C: 250 ENCHANCEDSTATUSCODES

C->M: AUTH LOGIN

M->C: 334 VXNlcm5hbWU6

C->M: bXVzdGVybWFubkBrb21sZS5kZQ==

M->C: 334 UGFzc3dvcmQ6

C->M: lkajsdfvlj

M->C: 501 5.5.4 Benutzername muss die Adresse und die Portnummer des SMTP Servers

Enthalten

M:    <das Clientmodul schließt die Verbindung mit dem Clientsystem>

Das Senden einer Nachricht wird abgebrochen, weil Verschlüsselungszertifikate weder für mustermann@komle.de noch für musterfrau@komle.de gefunden werden konnten:

...

C->M: DATA

M->C: 354 Start mail input; end with <CRLF>.<CRLF>

M:    <PROCESS Zustand>

C->M: From: "Max Mustermann" <mustermann@komle.de>

C->M: To: "Erika Musterfrau" <musterfrau@komle.de>

C->M: Subject: Biopsie Ergebnisse für Frau S. Muster

C->M: Date: Mon, 30 Jan 2012 13:14:12 +0100

C->M:

C->M: <Inhalt der KOM-LE Nachricht>

C->M: .

M:    <Das Clientmodul konnte die Verschlüsselungszertifikate nicht finden>

M->C: 451 Die Nachricht konnte nicht verschlüsselt werden, weil

Verschlüsselungszertifikate für mustermann@komle.de, musterfrau@komle.de nicht zugänglich sind

M->S: RSET

S->M: 250 2.0.0 Flushed

C->M: QUIT

M->S: QUIT

S->M: 221 Bye

S:    <der MTA schließt die Verbindung mit dem Clientmodul>

M->C: 221 Bye

M:    <das Clientmodul schließt die Verbindung mit dem Clientsystem>

Das Senden einer Nachricht wird abgebrochen, weil die Verbindung zwischen dem Clientmodul und dem Clientsystem abgebrochen wird:

...

M->C: 235 2.7.0 Authentifizierung erfolgreich

C->M: MAIL FROM:<mustermann@komle.de>

M->S: MAIL FROM:<mustermann@komle.de>

S->M: 250 OK

M->C: 250 OK

C->M: RCPT TO:<musterfrau@komle.de>

C:     <das Clientsystem bricht die Verbindung mit dem Clientmodul ab>

M->S: RCPT TO:<musterfrau@komle.de>

M:     <das Clientmodul schließt die Verbindung mit dem MTA>

3.4 Empfangen von Nachrichten

In diesem Kapitel werden Anforderungen an das Clientmodul formuliert, die für den Anwendungsfall „KOM-LE_AF_2 Nachricht empfangen“ [gemSysL_KOMLE] spezifisch sind.

3.4.1 Übersicht

Beim Empfangen von KOM-LE-Nachrichten sorgt das Clientmodul dafür, dass für abgeholte Nachrichten vor der Weiterleitung an das Clientsystem der Vertraulichkeitsschutz aufgehoben und die Integrität geprüft werden. Abbildung 9 stellt die Interaktionen zwischen den am Abholen von KOM-LE-Nachrichten beteiligten Komponenten dar. Aus Sicht des Clientsystems agiert das Clientmodul als POP3-Server, und aus Sicht des POP3-Servers des Fachdienstes (weiter im Text auch als POP3-Server bezeichnet) agiert das Clientmodul als E-Mail-Client. Für Funktionen wie Datentransport, kryptographische Operationen, Kommunikation mit dem Verzeichnisdienst verwendet das Clientmodul entsprechende Dienste der TI-Plattform.

Abbildung 10: Abb_Empfangen_Msg Empfangen von Nachrichten

Beim Abholen von Nachrichten findet die Kommunikation zwischen dem Clientsystem, dem Clientmodul und dem POP3-Server über POP3 statt. Das Clientmodul fungiert als POP3-Proxy, der das Clientsystem mit dem POP3-Server verbindet, die Entschlüsselung und Signaturprüfung für die abgeholten Nachrichten durchführt und die entschlüsselten Nachrichten an das Clientsystem liefert. Die Ergebnisse der Signaturprüfung werden dem Nutzer als Vermerk, der in den Inhalt der Nachricht integriert wird sowie als ein detaillierter Bericht in Form einer angehängten PDF-Datei mitgeteilt.

Dieses Dokument spezifiziert nicht alle Schritte und Einzelheiten der POP3-Kommunikation zwischen dem Clientsystem, dem Clientmodul und dem POP3-Server. Es setzt voraus, dass POP3 und dessen Erweiterungen dem Leser bekannt sind.

Das Clientmodul benachrichtigt den Nutzer über Fehler, die während der Nachrichtenübertragung zwischen dem POP3-Server und dem Clientmodul oder bei der Bearbeitung der Nachrichten im Clientmodul auftreten. In den meisten Fällen wird das Clientsystem durch POP3-Meldungen über Fehler informiert. Das Clientsystem entscheidet anschließend über das weitere Vorgehen (weitermachen oder abbrechen und den Nutzer über den Fehler informieren).

Beispiel: Verwendet das Clientsystem beim Empfangen von Nachrichten falsche Anmeldungsdaten, bekommt es vom Clientmodul „-ERR Der Nutzer konnte nicht authentifiziert werden“ als Antwort auf sein PASS-Kommando.

Fehler, die bei der Entschlüsselung oder Signaturprüfung einer Nachricht auftreten, werden anders behandelt:

• Kann die Nachricht nicht entschlüsselt werden (z.B. weil der entsprechende HBA nicht zu Verfügung steht), wird durch das Clientmodul eine Fehlernachricht generiert, die die verschlüsselte Nachricht als Anhang enthält. Um die Nachricht nachträglich zu entschlüsseln und ihre Signatur zu prüfen, kann der Nutzer die Nachricht an seine eigene E-Mail-Adresse senden, Maßnahmen treffen damit beim nächsten Abholen der entsprechende Schlüssel gefunden wird und den Abholvorgang wiederholen.
• Wenn die Signaturprüfung der entschlüsselten Nachricht fehlschlägt (z.B. weil die Integrität der Nachricht verletzt wurde, das Signaturzertifikat nicht vorhanden ist, ein OCSP-Responder nicht zur Verfügung steht usw.) wird die entschlüsselte Nachricht dem Clientsystem mit dem entsprechenden Vermerk übergeben.

Das Verhalten des Clientmoduls beim Abholen von Nachrichten kann mit Hilfe der in Abbildung 10 dargestellten Zustandsmuster beschrieben werden. Die im Dokument dargestellten Zustände haben einen illustrativen und nicht normativen Charakter. Die Umsetzung kann sich unterscheiden, solange das Ergebnis das gleiche ist. Die den Zuständen zugeordnete Anforderungen sind normativ, können aber außerhalb des Kontexts dieser Zustände umgesetzt werden.

Abbildung 11: Abb_Status_CM_Empfang Zustände Clientmodul beim Nachrichtenempfang

Das Clientmodul lauscht auf einem TCP-Port und wartet bis ein Clientsystem mit ihm eine Verbindung aufbaut. Sobald dies passiert, geht das Clientmodul in den CONNECT-Zustand über und betrachtet die POP3-Verbindung als geöffnet. Die POP3-Verbindung zwischen dem Clientmodul und dem Clientsystem muss mit TLS erfolgen.

Im CONNECT-Zustand führt das Clientmodul einen POP3-Dialog mit dem Clientsystem, in dem ihm die Anmeldedaten des Nutzers sowie die Adresse und die Portnummer des POP3-Servers mitgeteilt werden. Sobald die Anmeldedaten und die Adresse des POP3-Servers übermittelt sind, baut das Clientmodul eine über TLS geschützte POP3-Verbindung mit dem POP3-Server auf, authentifiziert sich und geht in den PROXY-Zustand über.

Im PROXY-Zustand leitet das Clientmodul POP3-Meldungen und POP3-Antwortcodes zwischen dem Clientsystem und dem POP3-Server hin und her, bis das Clientsystem mit dem RETR-Kommando das Abholen einer Nachricht initiiert. Sobald der POP3-Server beginnt, Inhalte einer Nachricht zu übertragen, geht das Clientmodul in den PROCESS-Zustand über.

Im PROCESS-Zustand wird die Nachricht entschlüsselt, ihre Signatur geprüft und die aufbereitete Nachricht dem Clientsystem übermittelt. Sobald die Nachricht erfolgreich an das Clientsystem übermittelt wurde oder im Fehlerfall, geht das Clientmodul in den PROXY-Zustand zurück.

3.4.2 CONNECT-Zustand

Sobald die TCP-Verbindung zwischen dem Clientsystem und dem Clientmodul aufgebaut wurde, geht das Clientmodul in den CONNECT-Zustand über.

3.4.2.1 Initialisierung

Nachdem die POP3-Verbindung zwischen dem Clientsystem und dem Clientmodul aufgebaut wurde, sendet das Clientmodul dem Clientsystem die POP3-Begrüßung.

Beispiel einer solchen Begrüßung: +OK KOM-LE Clientmodul POP3

Das Clientmodul führt einen POP3-Dialog mit dem Clientsystem bis ihm das Clientsystem die Adresse und die Portnummer des POP3-Servers als einen Teil des während des Authentifizierungsverfahrens übertragenen Benutzernamens mitteilt.

Tabelle 3 beschreibt die Antworten, die das Clientmodul dem Clientsystem im CONNECT-Zustand sendet.

Tabelle 4: Tab_POP3_Ant_Init Antworten Clientmodul im CONNECT-Zustand

3.4.2.2 Verbindungsaufbau mit dem POP3-Server

Das Clientmodul kann die Verbindung mit dem POP3-Server nur dann aufbauen, wenn ihm das Clientsystem die Adresse des POP3-Servers und die Portnummer des POP3-Dienstes übermittelt. Das Clientmodul erwartet, dass der Domain Name oder die IP-Adresse und die Portnummer während des Authentifizierungsverfahrens als Teil des Benutzernamens übergeben werden.

Das Clientmodul führt das Authentifizierungsverfahren mit dem Clientsystem bis zu dem Punkt, an dem es mit dem entsprechenden Antwortcode die Authentifizierung akzeptieren oder ablehnen muss. Das Clientmodul allein kann das Clientsystem nicht authentifizieren. Die Authentizität der Zugangsdaten kann nur vom POP3-Server überprüft werden. Dazu authentisiert sich das Clientmodul im Auftrag vom Clientsystem gegenüber dem POP3-Server.

Die Server Adresse und die Portnummer des POP3-Dienstes sind als Teil des POP3-Benutzernamens vom Clientsystem zu übergeben. Sie sind vom eigentlichen Benutzernamen durch das Zeichen ’#’ getrennt und als adresse:port String formatiert.

Um mit SM-B/HBA über den Konnektor kommunizieren zu können, werden dem KOM-LE-Clientmodul ebenfalls als Teil des POP3-Benutzernamens, die

• MandantId
• ClientSystemId
• WorkplaceId
• UserId (optional – ist für einen Zugriff auf HBA erforderlich).

übergeben (siehe Kapitel 3.5 und [gemSpec_Kon] für Details zu MandantId, ClientSystemId, WorkplaceId und UserId). Die Parameter entsprechen denen des aufrufenden Clients und werden voneinander durch das Zeichen ’#’ getrennt. Der Parameter UserId wird nur für den Zugriff auf einen HBA benötigt und kann entfallen wenn kein HBA erforderlich ist (z.B. wenn die Entschlüsselung der empfangenen Nachrichten ausschließlich mit SM-B durchgeführt wird).

Die Reihenfolge der Parameter entspricht dem folgenden Muster:

Abbildung 12: Abb_POP3_Nutzer_Name Format des POP3- Benutzernamens

Beispiel:

Bei folgenden Informationen

• Benutzername des Clients = „ erik.mustermann@komle.de“,
• Domain Adresse des POP3-Servers = „pop.komle.de“ und Portnummer = 995,
• MandantId = 1,
• ClientsystemId = KOM_LE,
• WorkplaceId = 7,
• UserId = 13

erwartet das Clientmodul, dass das Clientsystem ihm den folgenden POP3-Benutzernamen als String überträgt:

erik.mustermann@komle.de#pop.komle.de:995#1#KOM_LE#7#13

Enthält der POP3-Benutzername nicht alle erforderlichen Parameter, bricht das KOM-LE-Clientmodul den Empfangsvorgang mit dem -ERR Antwortcode ab. Wenn der erhaltene POP3-Benutzername zusätzliche durch das Zeichen ‚#’ abgegrenzte Parameter enthält (z.B. UnknownParameter1#UnknownParamenter2), werden diese Parameter nicht vom Clientmodul ausgewertet und der Empfangsvorgang wird fortgesetzt.

Es gibt mehrere Benutzername/Password-basierte POP3-Authentifizierungsmechanismen:

• Mechanismen, wo die Übertragung von Benutzername und Passwort im Klartext erfolgt (USER/PASS und PLAIN)
• Challenge-Response-Mechanismen, wo der Benutzername im Klartext und das Passwort in Form eines auf vom Server erhaltenen Challenge-basierten Responses übertragen wird (DIGEST-MD5, CRAM-MD5, NTLM).

Die auf Challenge-Response basierten Mechanismen machen das Extrahieren des Passworts aus der Challenge-basierten Response für das Clientmodul unpraktikabel. Deshalb werden für die Clientsystem-Clientmodul-Authentifizierung die PLAIN oder USER/PASS-Mechanismen verwendet.

Sobald das Clientmodul die Anmeldedaten des Nutzers erhält, extrahiert es die Adresse des POP3-Servers und die Portnummer des POP3-Dienstes aus dem Nutzernamen und baut damit die Verbindung zum POP3-Server auf. Die Verbindung wird über TLS geschützt. Details zum Aufbau der TLS-Verbindung werden in Kapitel 4.1.3 beschrieben.

Tabelle 4 enthält POP3-Antwortcodes, die das Clientmodul dem Clientsystem bei einem Verbindungsaufbau mit dem POP3-Server übermittelt.

Tabelle 5: Tab_POP3_Verbindung Antwortcodes für POP3-Server-Verbindungsaufbau

Die Verbindungen zwischen dem Clientsystem und dem Clientmodul sowie zwischen dem Clientmodul und dem POP3-Server bleiben solange offen, bis eine der beiden geschlossen oder abgebrochen wird. Sobald eine der beiden Verbindungen geschlossen oder abgebrochen wird, übermittelt das Clientmodul die ausstehenden POP3-Meldungen und schließt die andere Verbindung. Die POP3-Sitzung wird damit für den POP3-Server, das Clientsystem und das Clientmodul beendet.

Beispiel:

Nachdem das Clientmodul das QUIT-Kommando vom Clientsystem erhält und dem POP3-Server übermittelt, bestätigt der POP3-Server das Ankommen des Kommandos mit dem Antwortcode „+OK“ und schließt die Verbindung mit dem Clientmodul. Das Clientmodul übermittelt den Antwortcode „+OK“ an das Clientsystem und schließt die Verbindung mit dem Clientsystem.

Nachdem das Clientsystem sich gegenüber dem POP3-Server erfolgreich authentifiziert hat, geht das Clientmodul in den PROXY-Zustand über. Anderenfalls bleibt das Clientmodul im CONNECT-Zustand.

3.4.3 PROXY-Zustand

Im PROXY-Zustand vermittelt das Clientmodul POP3-Meldungen und Antwortcodes zwischen dem Clientsystem und dem POP3-Server. Das Clientmodul bleibt in diesem Zustand bis das Clientsystem das RETR-Kommando sendet und der POP3-Server das Erhalten dieses Kommandos mit dem Antwortcode „+OK“ bestätigt. Das Clientmodul leitet den Antwortcode „+OK“ an das Clientsystem weiter und geht in den PROCESS-Zustand über.

In diesem Zustand kann das Clientmodul vom Clientsystem das TOP-Kommando erhalten, das <MsgID> und <N> als Parameter hat. Es fordert den POP3-Server zur Übertragung des Headers und von <N> Nachrichtenzeilen der durch <MsgID> identifizierten Nachricht auf. Um sicherzustellen, dass das Clientmodul keine Teile einer verschlüsselten S/MIME-Nachricht bekommt, wird der Parameter <N> vom Clientmodul immer auf 0 gesetzt.

Hinweis für Implementierung

Wegen eines Thunderbird bugs:

Das getrennte Laden von Header und Body ist in Thunderbird nicht korrekt implementiert. Möglicher Bugfix im CM: Bei TOP 0 den Msg Header ändern: MIME Element(MIME-Version: 1.0) aus Header entfernen, dann klappt das nachladen.

3.4.4 PROCESS-Zustand

Im PROZESS-Zustand nimmt das Clientmodul die Inhalte der vom POP3-Server abgerufenen Nachricht entgegen, entschlüsselt die Nachricht, prüft deren Integrität, fügt einen Vermerk sowie einen PDF-Anhang mit dem Ergebnis der Signaturprüfung in die Nachricht ein und leitet die aufbereitete Nachricht dem Clientsystem weiter. Im Erfolgsfall wird das Clientsystem über das erfolgreiche Abholen der Nachricht informiert. Im Fehlerfall wird das Clientsystem mit dem entsprechenden Antwortcode über den Fehler informiert.

3.4.4.1 Empfang und Weiterleitung einer Nachricht

Nachdem der POP3-Server das Erhalten des RETR-Kommandos mit dem Antwortcode „+OK“ bestätigt, erwartet das Clientmodul, dass der POP3-Server mit der Übertragung der Nachricht beginnt. Die Inhalte der Nachricht werden im Clientmodul zwischengespeichert. Wenn die Nachricht eine entsprechend dem KOM-LE-S/MIME-Profil geschützte Nachricht ist, bereitet das Clientmodul die erhaltene Nachricht auf und übermittelt sie anschließend dem Clientsystem. Wenn es keine KOM-LE-S/MIME-Nachricht ist, wird sie ohne jegliche Änderungen dem Clientsystem übermittelt.

Nachdem die Nachricht dem Clientsystem übermittelt wurde, löscht das Clientmodul die zwischengespeicherten Nachrichtinhalte und geht in den PROXY-Zustand zurück.

3.4.4.2 Aufbereitung einer Nachricht

Das Clientmodul soll zwischen den KOM-LE S/MIME und anderen Nachrichten unterscheiden. Wenn die angekommene Nachricht eine KOM-LE-S/MIME-Nachricht ist, entschlüsselt das Clientmodul ihre Inhalte und führt die Prüfung ihrer Signatur durch. Die KOM-LE-S/MIME-Nachrichten sind anhand des X-KOM-LE-Version Header-Elements erkennbar. Wenn die ankommende Nachricht keine KOM-LE-S/MIME-Nachricht ist, soll sie ohne weitere Veränderungen dem Clientsystem übermittelt werden.

Für die Entschlüsselung und die Signaturprüfung verwendet das Clientmodul die Dienste der TI-Plattform, die dem Clientmodul über Schnittstellen des Konnektors zur Verfügung gestellt werden.

3.4.4.2.1 Entschlüsselung

Für die Entschlüsselung der ankommenden Nachricht wird der private Schlüssel PrK.HCI.ENC bzw. Prk.HP.ENC verwendet, der dem Verschlüsselungszertifikat der Institution bzw. des Leistungserbringers zugeordnet ist. Der Zugriff auf die entsprechende Karte und die Entschlüsselung erfolgen über die Aufrufe der entsprechenden Operationen der Außenschnittstelle des Konnektors. Eine detaillierte Beschreibung erfolgt im Kapitel 3.5.4.

Wenn die Nachricht für mehrere Empfänger verschlüsselt wurde, liegt es in der Verantwortung des Clientmoduls sicherzustellen, dass die Nachricht mit dem Schlüssel des den Abholvorgang auslösenden Nutzers entschlüsselt wird. Der erforderliche Schlüssel kann mit Hilfe des im KOM-LE-S/MIME-Profil beschriebenen recipient-emails Attributs im EnvelopedData CMS-Objekt identifiziert werden. Das EnvelopedData CMS-Objekt enthält die verschlüsselten Inhalte und im recipient-emails Attribut werden die Zusammenhänge zwischen den E-Mail-Adressen der Empfänger und den verwendeten Verschlüsselungszertifikaten definiert. Das ermöglicht die Identifizierung des erforderlichen Verschlüsselungszertifikats, dessen zugehöriger privater Schlüssel für die Entschlüsselung verwendet werden soll. Dadurch kann vermieden werden, dass die Nachricht mit dem freigeschalteten Schlüssel eines Empfängers entschlüsselt wird, der nicht derjenige ist, der den Abholvorgang ausgelöst hat. Das Clientmodul geht davon aus, dass der Nutzername, der für die POP3-Authentifizierung verwendet wurde, der E-Mail-Adresse des Empfängers entspricht und benutzt ihn, um den entsprechenden RecipientIdentifier aus dem recipient-emails Attribut auszulesen. Wenn es keinen RecipientIdentifier gibt, der dem POP3-Nutzernamen des Empfängers entspricht, wird die Entschlüsselung als fehlgeschlagen betrachtet.

Wenn die Entschlüsselung fehlschlägt, wird dem Clientsystem die verschlüsselte Nachricht im Anhang einer Fehlernachricht übermittelt. Hierzu wird die angekommene KOM-LE-S/MIME-Nachricht als eine message/rfc822 MIME-Einheit in eine multipart/mixed MIME-Nachricht verpackt, die zusätzlich eine text/plain MIME-Einheit mit der Fehlermeldung enthält. Die orig-date, from, sender, reply-to, to und cc Header-Elemente der neuen Nachricht werden aus der ursprünglichen Nachricht übernommen. Der Betreff der neuen Nachricht enthält die Zeichenkette „Die Nachricht konnte nicht entschlüsselt werden“.

Beispiel:

Kann eine Nachricht auf Grund des fehlenden HBA mit dem erforderlichen privaten Schlüssel nicht im Clientmodul entschlüsselt werden, wird die Nachricht wie folgt dem Clientsystem übermittelt:

MIME-Version: 1.0

Content-Type: multipart/mixed; boundary="unique-boundary-1"

Subject: Die Nachricht konnte nicht entschlüsselt werden

Date: Fri, 9 Feb 2012 12:07:17 +0100

From: mustermann@komle.de

To: musterfrau@komle.de

This is a multi-part message in MIME format.

--unique-boundary-1

Content-Type: text/plain;    charset="iso-8859-1"

Content-Transfer-Encoding: quoted-printable

Der f=FCr die Entschl=FCsselung der Nachricht ben=F6tigte Schl=FCssel =

wurde nicht gefunden. =DCberpr=FCfen Sie ob die entsprechende Karte =

gesteckt ist und leiten Sie diese Nachricht an Ihre eigene Email Adresse =

(musterfrau@komle.de) weiter. Beim n=E4chsten Abholen wird der =

Entschl=FCsselungsvorgang wiederholt.

--unique-boundary-1

Content-Type: message/rfc822    

X-KOM-LE-Version: 1.0

MIME-Version: 1.0

Content-Type: application/pkcs7-mime; name="smime.p7m"; name="smime.p7m"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;    filename="smime.p7m"

Subject: KOM-LE Nachricht

Date: Fri, 9 Feb 2012 12:07:17 +0100

From: mustermann@komle.de

To: musterfrau@komle.de

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7

77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH

HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh

...

9efmAAAAAAAAAAAAAA==

--unique-boundary-1

Durch das Versenden einer solchen Fehlernachricht erhält der Nutzer die Möglichkeit, die E-Mail entweder vom Server zu löschen oder durch das Senden an die eigene E-Mail-Adresse und das anschließende Abholen die Aufbereitung zu wiederholen. Ein anderer Weg wäre die Nachrichten, die nicht vom Clientmodul aufbereitet werden konnten, auf dem Mail Server zu belassen und beim nächsten Abholen die Aufbereitung zu wiederholen. Der Nachteil eines solchen Ansatzes wäre, dass unter Umständen „E-Mail-Leichen“ entstehen. Hierbei handelt es sich um E-Mails, die z.B. auf Grund des Verlustes des erforderlichen HBA nicht mehr aufbereitet werden können und deswegen auf dem E-Mail-Server verbleiben würden.

Tabelle 5 enthält die Fehlertexte, die in die Nachricht eingeführt werden, wenn die Entschlüsselung nicht durchgeführt werden konnte.

Tabelle 6: Tab_Fehlertext_Entschl Fehlertexte für Entschlüsselungsfehler

3.4.4.2.2 Integritätsprüfung

Nachdem die angekommene Nachricht erfolgreich entschlüsselt wurde, prüft das Clientmodul ihre Integrität. Dabei werden die digitale Signatur der Nachricht, der Zertifizierungspfad für das Signaturzertifikat und die Integrität des recipient-emails Attributs geprüft. Für die Signaturprüfung der Nachricht wird das im CMS-Objekt mitgelieferte C.HCI.OSIG-Institutionszertifikat benutzt. Die Prüfung der Signatur erfolgt über die Aufrufe der entsprechenden Operationen der Außenschnittstelle des Konnektors. Eine detaillierte Beschreibung erfolgt Kapitel 3.5.2.

Das Ergebnis der Signaturprüfung und des Abgleichs des recipient-emails Attributs wird als Vermerk, der den Text der Nachricht ergänzt, dem Empfänger mitgeteilt. Zusätzlich wird eine PDF-Datei mit einem detaillierten Signaturprüfungsbericht als Anhang in die Nachricht eingefügt.

Der Dateiname des Signaturprüfungsberichtes ist Signaturpruefungsbericht.pdf und hat die folgende Struktur:

Tabelle 7: Tab_Strukt_Sig_Prüf_Report Struktur Signaturprüfbericht

Falls der Zertifikatstatus des Signaturzertifikates nicht geprüft werden kann (z.B. der OCSP-Responder ist unerreichbar), die mathematische Prüfung der Signatur aber erfolgreich durchgeführt wurde, wird ein entsprechender Vermerk in der Body der Nachricht eingetragen.

Tabelle 7 stellt die Vermerke entsprechend den Ergebnissen der Signaturprüfung dar. In dieser Tabelle werden die Prüfergebnisse mit den entsprechenden Fehlercodes sowie die Vermerke zusammengefasst. Die Prüfergebnisse entsprechen dem Gesamtergebnis für die Prüfung einer nicht qualifizierten Dokumentensignatur (nonQES) für die Operation VerifyDocument gemäß [gemSpec_KON#TAB_KON_754] und [gemSpec_KON#TAB_KON_124].

Tabelle 8: Tab_Verm_Sig_Prüf Vermerke mit Ergebnissen der Signaturprüfung

Es folgt ein Beispiel einer entschlüsselten multipart/mixed Nachricht deren Signatur erfolgreich geprüft wurde. Die Nachricht enthält eine text/plain Einheit im Nachrichtentext, einen Arztbrief als PDF-Anhang sowie den Signaturprüfungsbericht ebenfalls als PDF-Anhang.

Date: Fri, 9 Feb 2012 12:07:17 +0100

MIME-Version: 1.0

From: mustermann@komle.de

To: musterfrau@komle.de

Subject: Arztbrief H. Muster

Content-Type: multipart/mixed;

boundary="unique-boundary-1"

This is a multi-part message in MIME format.

--unique-boundary-1

Content-Type: text/plain;    charset="iso-8859-1"

Content-Transfer-Encoding: quoted-printable

Sehr Geehrte Frau Dr. Musterfrau,

hiermit sende ich Ihnen den Arztbrief f=FCr Herrn H. Muster.

Mit Freundlichen Gr=FC=DFen

Dr. med. Mustermann

Arzt f=FCr Allgemeinmedizin

---------------------------------------------

Die Nachricht wurde entschl=FCsselt

Die Signatur wurde erfolgreich gepr=FCft.

--unique-boundary-1

Content-Type: application/pdf;

name="Arztbrief_Muster.pdf"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;

filename="Arztbrief_Muster.pdf"

JVBERi0xLjQNCiXDpMO8w7bDnw0KMiAwIG9iag0KPDwgL0xlbmd0aCAzIDAgUg0KICAgL0Zp

bHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCnicrVhda1sxDH0P5D/4uQ+3lvxxfaEM

...

OEJCQUExQzY0NDU+IF0NCj4+DQpzdGFydHhyZWYNCjIyNDU3Mg0KJSVFT0YNCg==

--unique-boundary-1

Content-Type: application/pdf;

name="Signaturpruefungsbericht.pdf"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;

filename="Signaturpruefungsbericht.pdf"

CjwhLS0gc2F2ZWQgZnJvbSB1cmw9KDAwMzgpaHR0cDovL2l3aS53aXdpLmh1LWJlcmxpbi5kZS9+

ZXZkb2tpbS8gLS0+CjxodG1sPjxoZWFkPjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg

...

PC9saT4KPC91bD4KCgo8L2JvZHk+PC9odG1sPg==

--unique-boundary-1

3.4.5 Beispiele

Das Clientsystem (C) verbindet sich mit dem Clientmodul (M) und holt vom POP3-Server (S) eine Nachricht (im Beispiel werden auch die Zustände des Clientmoduls dargestellt):

C:    <das Clientsystem öffnet eine mit TLS geschützte Verbindung mit dem Clientmodul>

M:    <CONNECT Zustand>

M->C: +OK KOM-LE Clientmodul POP3

C->M: CAPA

M->C: +OK Capability list follows

M->C: TOP

M->C: USER

M->C: SASL PLAIN

M->C: UIDL

M->C: .

C->M: USER mustermann@komle.de#pop.komle.de:110#1#KOM-LE#7

M->C: +OK

C->M: PASS password

M:    <das Clientmodul öffnet eine mit TLS geschützte Verbindung mit dem POP3 Server>

S->M: +OK POP Server Ready

M->S: CAPA

S->M: +OK Capability list follows

S->M: TOP

S->M: USER

S->M: SASL PLAIN CRAM-MD5

S->M: UIDL

S->M: RESP-CODES

S->M: .

M->S: USER mustermann@komle.de

S->M: +OK

M->S: PASS password

S->M: +OK Maildrop ready

M:    <PROXY Zustand>

M->C: +OK Maildrop ready

C->M: STAT

M->S: STAT

S->M: +OK 1 13950

M->C: +OK 1 13950

C->M: LIST

M->S: LIST

S->M: +OK

M->C: +OK

S->M: 1 13950

M->C: 1 13950

S->M: .

M->C: .

C->M: UIDL

M->S: UIDL

S->M: +OK

M->C: +OK

S->M: 1 01SDF8-1RiSd50vfv-00FGJN

M->C: 1 01SDF8-1RiSd50vfv-00FGJN

S->M: .

M->C: .

C->M: RETR 1

M->S: RETR 1

S->M: +OK

M->C: +OK

M:    <PROCESS Zustand>

S->M: <Inhalt der verschlüsselten KOM-LE Nachricht>

S->M: .

M:    <die Nachricht wird im Clientmodul aufbereitet>

M->C: <Inhalt der KOM-LE Nachricht>

M->C: .

M:    <PROXY Zustand>

C->M: QUIT

M->S: QUIT

S->M: +OK

S:    <der POP3 Server schließt die Verbindung mit dem Clientmodul>

M->S: +OK

M:    <das Clientmodul schließt die Verbindung mit dem Clientsystem>

Während des Löschens einer Nachricht wird die Verbindung zwischen dem Clientmodul und dem POP3-Server abgebrochen:

...

C->M: UIDL

M->S: UIDL

S->M: +OK

M->C: +OK

S->M: 1 01SDF8-1RiSd50vfv-00FGJN

M->C: 1 01SDF8-1RiSd50vfv-00FGJN

S->M: .

M->C: .

C->M: DELE 1

C:    <die Verbindung zwischen dem Clientmodul und dem Clientsystem wird abgebrochen>

M->S: DELE 1

M:    <die Verbindung zwischen dem Clientmodul und dem POP3 Server wird geschlossen>

3.5 Übermittlung von Kontaktdaten

Ein KOM-LE-Nutzer soll die Möglichkeit haben in seinem Clientsystem die Suche nach den E-Mail-Adressen der Empfänger seiner KOM-LE-Nachrichten durchzuführen. Die TI-Plattform stellt einen Verzeichnisdienst zur Verfügung, der unter anderem Einträge mit Kontaktdaten von KOM-LE-Nutzern enthält. Der Verzeichnisdienst kann über LDAP abgefragt werden und kann somit als Adressbuch für KOM-LE benutzt werden. Eine detaillierte Beschreibung des Verzeichnisdienstes der TI-Plattform befindet sich in [gemSpec_VZD]. Um LDAP-Anfragen gegenüber dem Verzeichnisdienst durchzuführen, fungiert der Konnektor als LDAP-Proxy wie in [gemSpec_Kon] beschrieben.

Der Verzeichnisdienst kann direkt von Clientsystemen, die die entsprechenden LDAP-Suchanfragen generieren, angefragt werden. Das LDAP-Schema des Verzeichnisdienstes wird in [gemSpec_VZD] beschrieben.

3.6 Übermittlung von E-Mail-Kategorien

Das Clientmodul soll die Kategorisierung von versendeten E-Mails ermöglichen. Zusätzlich zu den für den Versand einer gültigen E-Mail notwendigen Header-Feldern wird ein weiteres Attribut im Header eingefügt und mit der Information befüllt, welche der verwendete E-Mail-Client liefert.

Tabelle #: Tab_Header_Kat Header-Feld Kategorie

Die zu verwendenden Dienstkennungen werden durch die gematik festgelegt und sind über das Fachportal der gematik abrufbar.

Das Header-Feld X-KIM-Dienstkennung wird im unverschlüsselten Header der E-Mail enthalten sein, um eine eventuelle Verarbeitung der E-Mail auf Seiten des Empfängers zu ermöglichen. Eine entsprechende Festlegung erfolgt in der [gemSMIME_KOMLE] im Kapitel 2.1.1.1.

3.7 Administrationsmodul

Das Administrationsmodul ist Bestandteil des KOM-LE-Clientmoduls. Das Modul ermöglicht die Verwaltung des Accounts des KOM-LE-Teilnehmers. Dazu kommuniziert das Administrationsmodul über eine TLS-Verbindung mit dem Account Manager des KOM-LE-Fachdienstes. Zum Funktionsumfang des Modules gehören:

• Registrierung des neuen KOM-LE-Teilnehmers
• Deregistrierung des KOM-LE-Teilnehmers
• Registerstatusabfrage des KOM-LE-Teilnehmers
• Herunterladen (manuell und automatisiert) der PKCS#12-Datei
• Lokalisierung des Account Managers über DNS Service Discovery
• Meldung der Clientmodul-Version an den Account Manager

Im ersten Schritt konfiguriert der KOM-LE-Teilnehmer einmalig die Domain des KOM-LE-Fachdienstes im Administrationsmodul. Dadurch ist das Administrationsmodul in der Lage, den Account Manager über DNS Service Discovery zu lokalisieren. Danach können sich neue KOM-LE-Teilnehmer über das Administrationsmodul bei ihrem KOM-LE-Fachdienst registrieren und die benötigten PKCS#12 Dateien für das Clientmodul herunterladen.

Die konzeptionelle Betrachtung für das Administrationsmodul sieht wie folgt aus:

1. Der Account Manager ist nur in der Telematikinfrastruktur erreichbar.
2. TLS-Verschlüsselung zwischen Administrationsmodul (AM) und Account Manager.
3. Das Admistrationsmodul meldet die Clientmodul-Version an den Account Manager.
4. Das Administrationsmodul ist Bestandteil des Clientmoduls (CM).
5. Der KOM-LE-Anbieter erzeugt die Schlüsselpaare für die Zertifikate, die das CM benötigt. Die Zertifikate müssen über einen sicheren Kanal zum CM übertragen werden [gemSpec_FD_KOMLE#KOM-LE-A_2303, KOM-LE-A_2302].
6. Registrierungsprozess des KOM-LE-Teilnehmers:
1. Vorabinformationen z.B. über den Postweg
   
1. Username und Kennwort für den Account Manager
2. Kennwort für die PKCS#12
3. Domain des KOM-LE-Fachdienstes
2. Konfiguration der Domain im Administrationsmodul durch den KOM-LE-Teilnehmer
3. Administrationsmodul nutzt DNS Service Discovery zur Dienstlokalisierung des Account Managers
4. Registrierung durch Authentisierung am Account Manager mit Username, Kennwort und Signatur mit AUT-Zertifikat
5. Download der PKCS#12
6. Übergabe der Zertifikate an das CM sowie Installation auch durch das CM
7. Austausch der Zertifikate bei Ablauf der zeitlichen Gültigkeit:
   
1. Der KOM-LE Anbieter stellt frühzeitig neue Zerifikate als PKCS#12-Datei zum Download zur Verfügung
2. Das Administrationsmodul ermöglicht den Download der PKCS#12-Datei
3. Das CM ermöglicht die Installation der neuen Zertifikate

3.7.1 Allgemeine Anforderungen

Die Domain des Anbieters kann. z.B. die folgende Ausprägung haben:

hrst.kim.telematik

Der Account Manager ist Bestandteil des Fachdiensts und deshalb gelten für die TLS-Verbindungen (inklusive genutzter Zertifikate) zum Account Manager ebenfalls die Festlegungen von Kap. 4.1.4.

Abweichung außerhalb der Leistungserbringerumgebung

Für Umgebungen außerhalb der Leistungserbringerumgebung (z. B. im Rechenzentrum) können von den Anforderungen zur Dialogsteuerung abgewichen werden.

3.7.2 Registrierung KOM-LE-Teilnehmer

3.7.3 Deregistrierung KOM-LE-Teilnehmer

3.7.4 Registrierungsstatus KOM-LE-Teilnehmer

3.7.5 Download PKCS#12 KOM-LE-Teilnehmer

3.8 Kryptographischen Schnittstellen des Konnektors

Das digitale Signieren und die Verschlüsselung von Nachrichten sowie deren Entschlüsselung und die Prüfung ihrer digitalen Signaturen beinhalten den Zugriff auf die SOAP-Schnittstellen des Konnektors, die die folgenden Operationen zu Verfügung stellen:

• SignDocument - Erzeugung einer digitalen Signatur,
• VerifyDocument – Prüfung einer digitalen Signatur,
• EncryptDocument – Verschlüsselung und
• DecryptDocument - Entschlüsselung.

Die Verschlüsselung und das digitale Signieren erfordern dabei den Zugriff auf eine SM-B und/oder einen HBA mit dem erforderlichen Schlüsselmaterial. Zur Erstellung einer digitalen Signatur ist der Zugriff auf den geheimen Schlüssel PrK.HCI.OSIG einer SM-B erforderlich. Für die Verschlüsselung ist der Zugriff auf den geheimen Schlüssel Prk.HCI.ENC einer SM-B oder Prk.HP.ENC eines HBA notwendig.

Der Zugriff auf den entsprechenden geheimen Schlüssel erfolgt während der Durchführung der SignDocument und DecryptDocument Operationen. Die Eingangsparameter der beiden Operationen beinhalten das Context Element (Aufrufkontext). Der Aufrufkontext umfasst die Angaben zu Mandanten (MandantId), Arbeitsplatz (WorkplaceId), Anwendung (ClientSystemId) und Identifikation des Benutzers (UserId). Die Angaben zur Identifikation des Benutzers (UserId) sind optional und nur für Aufrufe, die einen Zugriff auf den HBA brauchen, erforderlich. Die Elemente des Aufrufkontexts werden dem Clientmodul als Teile des MTA- bzw. POP3-Benutzernamens übertragen (siehe Kapitel 3.2.2.2, 3.3.2.2).

Zur Identifikation der Karte benötigen die Operationen zusätzlich den Paramemter cardHandle. Das cardHandle gilt für die Dauer des Steckzyklus einer Karte und wird beim Stecken einer Karte vom Konnektor generiert. Um eine Karte über mehreren Steckzyklen zu identifizieren kann die Seriennummer der Karte (ICCSN) verwendet werden.

Die über den Konnektor verfügbaren SM-Bs und HBAs, ihre Handles und ICCSNs können über die GetCards Operation des Konnektors ermittelt werden.

3.8.1 Erstellung der digitalen Signatur einer Nachricht mit einer SM-B

Das Signieren von ausgehenden Nachrichten erfolgt mit dem Schlüssel PrK.HCI.OSIG der SM-B, die der Institution des Senders entspricht. Ein Konnektor kann von mehreren Institutionen (Mandaten) gleichzeitig benutzt werden und dementsprechend mit mehreren SM-Bs, die den unterschiedlichen Identitäten entsprechen, ausgestattet sein. Die Ermittlung der SM-B, die für die Erstellung der Nachrichtensignatur verwendet werden soll, kann entsprechend dem in der Abbildung "Abb_Zugriff_SMB SM-B-Zugriff zur Erstellung der Nachrichtensignatur" dargestellten Aktivitätsdiagramm erfolgen. Die Aktivitäten und deren Reihenfolge haben illustrativen und nicht normativen Charakter. Die konkrete Umsetzung kann sich unterscheiden, solange das Ergebnis das Gleiche ist.

Abbildung 13: Abb_Zugriff_SMB SM-B-Zugriff zur Erstellung der Nachrichtensignatur

Es folgt die Beschreibung der einzelnen Aktivitäten des Diagramms:

1. Die über den Konnektor verfügbaren Karten werden über die Operation GetCards mit dem Parameter Context (dem Sender entsprechender Aufrufkontext aus dem Benutzernamen) ermittelt.
2. In den anhand des Aufrufkontexts über GetCards ermittelten Karten wird nach einer verfügbaren SM-B gesucht:

• Falls eine verfügbare SM-B gefunden wurde, wird mit Aktivität 3 fortgesetzt.
• Falls sich unter den verfügbaren Karten keine SM-B befindet, kann die Nachricht nicht signiert werden und das Senden wird abgebrochen.

1. Um festzustellen, ob die Eingabe der PIN für die Freischaltung der Karte notwendig ist, wird die GetPinStatus Operation des Konnektors aufgerufen. Dabei werden die Parameter Context (dem Sender entsprechender Aufrufkontext), CardHandle (Handle der ausgewählten SM-B) und PinTyp (PIN.SMC) verwendet.

• Falls die Karte freigeschaltet ist, fährt das Clientmodul mit Aktivität 5 fort.
• Falls eine PIN-Eingabe erforderlich ist, fährt das Clientmodul mit Aktivität 4 fort.

1. Für die Eingabe der PIN zur Freischaltung der ausgewählten Karte wird die VerifyPin Operation des Konnektors verwendet. Die Operation wird mit den Parametern Context (dem Sender entsprechender Aufrufkontext), CardHandle (Handle der ausgewählten SM-B), PinTyp (PIN.SMC) aufgerufen. Der Sender wird zur Eingabe der PIN über das Display des Kartenterminals angefordert.
2. Die Signatur der KOM-LE-Nachricht erfolgt unter Verwendung der SignDocument Operation des Konnektors. Dabei werden die Parameter Context (dem Sender entsprechender Aufrufkontext), CardHandle (Handle der ausgewählten SM-B), KeyReference (C.OSIG_RSA oder C.OSIG_ECC ) verwendet. Die Verwendung weiterer Parameter muss unter Berücksichtigung der Anforderungen aus [gemSMIME_KOMLE] erfolgen.

3.8.2 Prüfung der digitalen Signatur einer Nachricht

Die Prüfung der digitalen Signatur einer Nachricht erfolgt mittels der VerifyDocument Operation des Konnektors. Dabei werden die Parameter Context (dem Empfänger entsprechender Aufrufkontext) und Document (signierte Daten) verwendet.

3.8.3 Verschlüsselung einer Nachricht

Die Verschlüsselung einer Nachricht erfolgt mittels der EncryptDocument Operation des Konnektors. Dabei werden die Parameter Context (dem Empfänger entsprechender Aufrufkontext), Document (zu verschlüsselnde Daten) und Certificate (alle Zertifikate mit denen die Nachricht verschlüsselt werden soll) verwendet.

3.8.4 Entschlüsselung einer Nachricht mit einer SM-B bzw. einem HBA

Für die Entschlüsselung von empfangenen Nachrichten verwendet das Clientmodul den privaten Schlüssel PrK.HP.ENC eines HBA bzw. den privaten Schlüssel PrK.HCI.ENC einer SM-B. Die Zuordnung von den für die Verschlüsselung verwendeten Zertifikaten und den E-Mail-Adressen der Empfänger wird im recipient-emails Attribut des CMS-Objektes mit den verschlüsselten Daten abgebildet (siehe [gemSMIME_KOMLE]). Die Ermittlung des HBAs bzw. der SM-B, die für die Entschlüsselung der empfangenen Nachricht verwendet wird, kann entsprechend dem in Abbildung 13 dargestellten Aktivitätsdiagramm durchgeführt werden. Die Aktivitäten und deren Reihenfolge haben illustrativen und nicht normativen Charakter. Die konkrete Umsetzung kann sich unterscheiden, solange das Ergebnis das Gleiche ist.

Abbildung 14: Abb_Zugriff_SMB_HBA SM-B/HBA-Zugriff zur Nachrichtentschlüsselung

Es folgt die Beschreibung der einzelnen Aktivitäten des Diagramms:

1. Die über den Konnektor verfügbaren Karten werden über die Operation GetCards mit dem Parameter Context (dem Empfänger entsprechender Aufrufkontext) ermittelt.
2. Um die Anzahl der Zugriffe auf die Schnittstellen des Konnektors zu reduzieren, verwaltet das Clientmodul einen Cache, der Zuordnungen zwischen E-Mail-Adresse, Zertifikats-ID und ICCSN von HBA/SM-B zwischenspeichert. Dabei sind die gespeicherten Zertifikats-IDs vom ASN.1-Typ IssuerAndSerialNumber (siehe [gemSMIME_KOMLE#2.3.3]). Der Cache wird anhand der E-Mail-Adresse des Empfängers und der zugehörigen Zertifikats-IDs aus dem recipient-emails Attribut des CMS-Objektes durchsucht.

• Falls ein passender Eintrag im Cache gefunden wird und die ICCSN dieses Eintrages mit einer über GetCards ermittelten ICCSN übereinstimmt, fährt das Clientmodul mit Aktivität 5 fort.
• Falls der Cache keine passenden Einträge enthält, fährt das Clientmodul mit Aktivität 3 fort.

1. Die IDs der Verschlüsselungszertifikate (Ermittlung über die Operation ReadCardCertificate des Konnektors) der über GetCards ermittelten HBAs und SM-Bs werden mit den Zertifikats-IDs aus dem recipient-emails Attribut des CMS-Objektes, die zur E-Mail-Adresse des Empfängers gehören, verglichen. Bei der Ermittlung der Zertifikate über die Operation ReadCardCertificate ist sowohl das RSA-ENC-Zertifikat als auch ECC-ENC-Zertifikat der  Karten zu berücksichtigen.

• Falls eine Karte mit passender Zertifikats-ID vorhanden ist, fährt das Clientmodul mit Aktivität 4 fort.
• Falls keine passende Karte gefunden wird, wird die Entschlüsselung der Nachricht abgebrochen.

1. Die ermittelte (ICCSN – E-Mail-Adresse – Zertifikats-ID) Zuordnung wird im Cache des Clientmoduls gespeichert.
2. Um festzustellen ob die Eingabe der PIN zur Freischaltung der ermittelten Karte notwendig ist, wirddie Operation GetPinStatus des Konnektors mit den Parametern Context (dem Emfänger entsprechender Aufrufkontext), CardHandle (Handle der SM-B bzw. des HBA), PinTyp (PIN.SMC für SM-B bzw. PIN.CH für HBA) aufgerufen.

• Falls die Karte freigeschaltet ist, fährt das Clientmodul mit Aktivität 7 fort.
• Falls die PIN-Eingabe erforderlich ist, fährt das Clientmodul mit Aktivität 6 fort.

1. Die Operation VerifyPin des Konnektors wird mit den Parametern Context (dem Empfänger entsprechender Aufrufkontext), CardHandle (Handle der/des ausgewählten SM-B/HBA), PinTyp (PIN.SMC für SM-B bzw. PIN.CH für HBA) aufgerufen. Der Empfänger wird zur Eingabe der PIN über das Display des Kartenterminals aufgefordert.
2. Die Operation DecryptDocument des Konnektors wird mit den Parametern Context (dem Empfänger entsprechender Aufrufkontext), CardHandle (Handle der SM-B bzw. des HBA), KeyReference (C.ENC_RSA oder C.ENC_ECC ), Document (die verschlüsselten Daten) aufgerufen.

4 Nichtfunktionale Anforderungen

In diesem Kapitel werden nichtfunktionale Anforderungen an das KOM-LE-Clientmodul definiert.

4.1 Transportsicherung

Beim Senden bzw. Empfangen von Nachrichten baut das Clientmodul mit folgenden Systemen Verbindungen auf:

• Clientsysteme (muss stets über TLS erfolgen),
• KOM-LE-Fachdienste (muss stets über TLS erfolgen) und
• Konnektor (muss stets über TLS erfolgen).

In diesem Kapitel werden die Anforderungen an den Aufbau der TLS-Verbindungen mit diesen Systemen definiert.

4.1.1 Allgemeine Festlegungen

Die Vorgaben zu X.509-Identitäten für die TLS/SSL-Authentifizierung, unterstützten TLS-Versionen und TLS Cipher Suites werden aus [gemSpec_Krypt] übernommen.

Der Aufbau von TLS-Verbindungen mit Clientsystemen oder die zertifikatsbasierte clientseitige Authentisierung beim Aufbau von TLS-Verbindungen mit dem Konnektor oder den Fachdiensten erfordert das Vorhandensein des entsprechenden Schlüsselmaterials.

Üblicherweise liegt ein Zertifikat zusammen mit dem zugehörigen geheimen Schlüssel in einem standardisierten und passwortgeschützten Format (p12) [PKCS#12] vor. Das Clientmodul kann ein Zertifikat und den zugehörigen geheimen Schlüssel auf mindestens zwei Arten nutzen:

1. Das Clientmodul importiert das Zertifikat und den Schlüssel aus der p12-Datei und verwaltet diese anschließend in einem eigenen Schlüsselspeicher. Dazu muss während des Importvorgangs das Passwort der p12-Datei eingegeben werden (Transportsicherung). Danach hat das Clientmodul Zugriff auf den für den TLS-Verbindungsaufbau benötigten privaten Schlüssel.
2. Das Clientmodul nutzt einen Systemschlüsselspeicher, z.B. den Zertifikatsspeicher von Windows oder den des Java JRE. Auch hier ist für den Importvorgang das Passwort des der p12-Datei einzugeben. Anschließend stehen das Zertifikat und der Schlüssel über entsprechende Systemfunktionen/Bibliotheken zur Verfügung. Idealerweise kann der Administrator des Clientmoduls im gewählten Zertifikatsspeicher browsen und das gewünschte Zertifikat für die Verwendung auswählen. Alternativ kann in der Clientmodul-Konfiguration eine eindeutige Referenz auf das Zertifikat (Name oder Index) eingegeben werden.

Lösungen die Zertifikat und Schlüsselmaterial in der ausgelieferten Software des Clientmoduls enthalten und Lösungen bei denen derselbe Schlüssel für mehrere Clientmodule verwendet wird, sind aus Sicherheitsgründen nicht zulässig.

4.1.2 Transportsicherung zwischen Clientsystem und Clientmodul

Die SMTP- und POP3-Verbindungen zwischen dem Clientmodul und den Clientsystemen müssen über TLS geschützt werden, sofern Clientmodul und E-Mail-Client nicht auf demselben PC laufen.

Die Server-Authentisierung erfolgt mit einem Zertifikat, das im gemäß KOM-LE_2065 geschützten Schlüsselspeicher gespeichert wird.

4.1.3 Transportsicherung zwischen Clientmodul und Konnektor

Die Kommunikation zwischen Clientmodul und Konnektor basiert auf HTTP. Der Konnektor bietet vier Varianten der HTTP(S)-Verbindung an:

1. TLS deaktiviert. Verwendung von HTTP ohne Absicherung auf Transportebene wird vom Konnektor akzeptiert.
2. TLS ohne Client-Authentifizierung.
3. TLS mit Client-Authentifizierung. Die Client-Authentisierung muss mit den Zertifikaten erfolgen, die der Administrator entweder mit seinen eigenen Mitteln selbst oder mittels des Konnektors erzeugt. In beiden Fällen müssen diese Zertifikate sowohl im Clientmodul (hier zusammen mit ihren privaten Schlüsseln), als auch im Konnektor vorhanden sein.
4. Kombination von TLS ohne Client-Authentifizierung und HTTP-Basic-Authentifizierung. Das Clientmodul muss Benutzername und Passwort für die HTTP-Basic-Authentifizierung statisch konfigurieren, so dass eine Übereinstimmung mit der Konfiguration am Konnektor besteht.

Für die Basic-Authentifizierung (auch “Basic Access Authentication”, ein Standard der HTTP-Authentifizierung) soll dabei das Clientmodul die notwendigen Parameter „Benutzername“ und „Passwort“ verwalten. Das Clientmodul muss über entsprechende Konfigurationsparameter verfügen. Diese müssen mit den gleichen Werten für Benutzername und Passwort befüllt werden, wie an der Managementschnittstelle des Konnektors.

Die zertifikatsbasierte Client-Authentifizierung erfolgt mit einem Zertifikat, das im gemäß KOM-LE-A_2065 passwortgeschützten Schlüsselspeicher gespeichert wird.

4.1.4 Transportsicherung zwischen Clientmodul und Fachdienst

Die Verbindungen zwischen KOM-LE-Clientmodul und KOM-LE-Fachdiensten (inklusive KAS) sowie zwischen KOM-LE-Clientmodul und Verzeichnisdienst erfolgen immer über TLS. Der TLS Handshake zwischen dem Clientmodul und dem MTA, POP3-Server bzw. Verzeichnisdienst findet unmittelbar nach dem Aufbau der entsprechenden TCP-Verbindung statt. Damit wird sichergestellt, dass die Anmeldungsdaten des Nutzers immer über die mit TLS geschützte Verbindung transportiert werden.

Während des Aufbaus der TLS-Verbindung authentifizieren sich die KOM-LE-Fachdienste bzw. der Verzeichnisdienst  gegenüber dem Clientmodul mit X.509 TLS-Server-Zertifikaten. Zur Überprüfung dieser Zertifikate verwendet das Clientmodul die Operation VerifyCertificate des Konnektors.

Das Clientmodul wiederum authentisiert sich gegenüber den KOM-LE-Fachdiensten mit dem vom KOM-LE-Anbieter zur Verfügung gestellten TLS-Client-Zertifikat und dem entsprechenden privaten Schlüssel (KOM-LE-A_2065, KOM-LE-A_2300 und KOM-LE-A_2301 sind zu beachten).

4.2 Nutzung von Webservice-Schnittstellen des Konnektors

Aus der Herstellerdokumentation des Konnektors ist der FQDN zu entnehmen, unter dem der Konnektor seinen Dienstverzeichnisdienst anbietet. Innerhalb des FQDN können Hostname und Domain-Name je nach Konfiguration der LE-Umgebung individuell konfiguriert sein. Der resultierende FQDN des Dienstverzeichnisdienstes muss in die Konfiguration des Clientmoduls übernommen werden.

Durch das Auslesen des Dienstverzeichnisdienstes erhält das Clientmodul Webservice-Endpunkte von Diensten des Konnektors. Die Dienste des Konnektors sind versioniert. Es ist möglich, dass ein Konnektor mehrere Versionen eines Dienstes gleichzeitig anbietet. Die Versionierung der Dienste hilft dem Clientmodul dabei, genau die Dienstversionen zu nutzen, die es clientseitig implementiert hat.

Da nicht davon ausgegangen werden kann, dass die Inhalte des Dienstverzeichnisdienstes statisch sind, sollte das Lesen des Verzeichnisses beim Programmstart und in Fehlersituationen erfolgen, um den Dienstverzeichnis-Cache zu erneuern. Die weitere Kommunikation mit den Diensten des Konnektors erfolgt dann über die im Dienstverzeichnis-Cache propagierten Dienstendpunkte.

4.3 Protokollierung/Logging

Das Clientmodul soll Protokolldateien schreiben, die eine Analyse technischer Vorgänge erlauben. Diese Protokolldateien sind dafür vorgesehen, aufgetretene Fehler zu identifizieren, die Performance zu analysieren und interne Abläufe zu beobachten. Um die Anforderungen an den Datenschutz zu gewährleisten, dürfen keine medizinischen und personenbezogenen Daten protokolliert werden. Geheimes Schlüsselmaterial darf ebenfalls nicht protokolliert werden.

Die Protokolldateien folgen einem einheitlichen Format, das vom Hersteller festgelegt wird. Es muss geeignet sein, automatische Auswertungen mit wenig Aufwand durch Dritte zu ermöglichen. Ein Vorbild ist das Weblog des Apache Webservers.

Der Zugriff auf Protokolldateien muss auf autorisierte Personen durch angemessene technische oder organisatorische Maßnahmen eingeschränkt werden. Die Logdateien können auf ein separates Speichermedium kopiert werden. Zudem soll der Administrator das Protokollieren für die Performanceanalyse und der internen Abläufe einzeln deaktivieren und wieder aktivieren können. Für den Produktivbetrieb soll das Protokollieren der internen Abläufe grundsätzlich deaktiviert sein. Damit die Protokolldateien nur begrenzten Speicherplatz belegen, werden sie automatisch nach einem konfigurierbaren Zeitraum gelöscht bzw. überschrieben.

Um mehrere Protokolleinträge zu korrelieren, soll beim Aufruf einer Operation eine Vorgangsnummer gebildet werden. Diese Vorgangsnummer wird in allen Protokolleinträgen dieses Operationsaufrufs genutzt. Die Vorgangsnummer wird vom KOM-LE-Clientmodul pseudozufällig gebildet.

4.3.1 Ablaufprotokoll

Die Protokolleinträge im Ablaufprotokoll enthalten mindestens die in Tabelle 9 aufgezählten Felder.

Tabelle 9: Tab_Felder_Ablauf_Prot Felder im Ablaufprotokoll

Das Ablaufprotokoll soll die Ausführungsschritte enthalten, die einen Einblick in den internen Ablauf für Administratoren, Anbieter und Tester ermöglichen und die Analyse von Fehlersituationen erleichtern.

4.3.2 Performance

Die Protokolleinträge im Performanceprotokoll enthalten mindestens die in Tabelle 10 aufgezählten Felder und müssen geeignet sein, um die tatsächlichen Ausführungszeiten des KOM-LE-Clientmoduls mit den Vorgaben in Kapitel 4.6.1 zu vergleichen. Für jeden Aufruf einer Schnittstelle des Clientmoduls KOM-LE werden ein oder mehrere Protokolleinträge geschrieben.

Tabelle 10: Tab_Felder_Perf_Prot Felder im Performance-Protokoll

Jede der in Tabelle 11 aufgelisteten Aktionen führt zu einem Eintrag im Performanceprotokoll. Diese Durchlaufzeiten sollen separat protokolliert werden, damit die Ausführungszeit des Clientmoduls ohne Zeiten anderer Komponenten ermittelbar ist.

Tabelle 11: Tab_Auslöser_Prot_Entry Auslöser Protokolleinträge im Performanceprotokoll

4.3.3 Fehler

Tritt innerhalb einer Operation ein Fehler auf bzw. wird eine Operation nicht beendet, soll trotzdem ein Protokolleintrag erstellt werden, in dem eindeutig auswertbar ist, dass die Ausführung der Operation fehlerhaft war.

Die Protokolleinträge im Fehlerprotokoll enthalten mindestens die in Tabelle 12 aufgezählten Felder.

Tabelle 12: Tab_Felder_Fehler_Prot Felder im Fehlerprotokoll

4.4 Konfiguration

Die in der Tabelle 13 aufgeführten Parameter müssen über eine Managementoberfläche oder eine Konfigurationsdatei für das KOM-LE-Clientmodul konfigurierbar sein.

Tabelle 13: Tab_Konf_Param Standardkonfiguration allgemeine Parameter

4.5 Update-Mechanismen

4.6 Produktleistungen

4.6.1 Performance

Die durch das Clientmodul einzuhaltenden Performanceanforderungen werden in diesem Dokument nicht betrachtet sondern in [gemSpec_Perf] aufgeführt.

4.6.2 Skalierbarkeit

Das Clientmodul kann in Einzelpraxen, Praxisgemeinschaften, Gemeinschaftspraxen oder in medizinischen Versorgungszentren (MVZ) eingesetzt werden. Zusätzlich ist der Einsatz in Krankenhäusern und Umgebungen der Kostenträger vorgesehen. In diesen Umgebungen sind gleichzeitige Sende- und Abholvorgänge möglich. Das Clientmodul muss in der Lage sein, solche Vorgänge parallel bearbeiten zu können.

Im Rahmen dieser Spezifikation wird gefordert, dass ein KOM-LE-Clientmodul grundsätzlich beliebig viele parallele Sende- und Abholvorgänge unterstützt. Die Anzahl der tatsächlich unterstützten parallelen Aufrufe wird durch die eingesetzte Hardware und Beschränkungen des Herstellers begrenzt.

5 Anhang A – Verzeichnisse

5.1 Abkürzungen

5.2 Glossar

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

5.3 Abbildungsverzeichnis

5.4 Tabellenverzeichnis

5.5 Referenzierte Dokumente

5.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummer entnehmen Sie bitte der aktuellen, auf der Internetseite der gematik veröffentlichten Dokumentenlandkarte, in der die vorliegende Version aufgeführt wird.

5.5.2 Weitere Dokumente