Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

KOM-LE-Clientmodul

    

     

      
Version
      
1.19.0
     
     

      
Revision
      
1048904
     
     

      
Stand
      
11.11.2024
     
     

      
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. gemPTV_ATV_Festlegungen, 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 „Nachricht senden“ und „Nachricht empfangen“ 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 zu bearbeitenden originalen MIME-Nachrichten von einem Clientsystem, die kleiner oder gleich 15 MiB sind, werden beim Senden entsprechend dem KOM-LE-S/MIME-Profil gemäß [gemSMIME_KOMLE] digital signiert und verschlüsselt und im empfangenden Clientmodul entschlüsselt und deren Signatur geprüft. Die originalen MIME-Nachrichten, die von einem Clientsystem an das Clientmodul übergeben werden, werden im KIM-Kontext als Client-Mails bezeichnet. Bei Client-Mails größer 15 MiB wird die gesamte Client-Mail auf einem separaten Speicherort (Fachdienst) verschlüsselt abgelegt (E-Mail-Daten). 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 die vom Clientmodul verarbeitete Client-Mail (signiert und verschlüsselt) die gemäß message/rfc822 als Anhang in die äußere Nachricht angehangen wird. Die so erzeugte Mail wird im KIM-Kontext als KOM-LE-Nachricht bezeichnet.

Abbildung 3: Abb_Struk_KOMLE_Msg Struktur einer KOM-LE-Nachricht

Die durch das Clientmodul versendeten Nachrichten können vom Client optional gekennzeichnet werden. Es wird empfohlen eine Dienstkennung zu setzen. Andernfalls werden Nachrichten mit einer standardisierten Dienstkennung versehen. Das hierfür notwendiges Attribut im Header der Mail (X-KIM-Dienstkennung) wird im Kapitel 3.6 beschrieben. Erfolgte durch den Client keine Belegung dieses Attributes, wird durch das Clientmodul eine Default-Kennung gesetzt. Um die Abholung der auf dem Mail-Server ankommenden Nachrichten inhaltsabhängig durchführen zu können, wird das Header-Feld "X-KIM-Dienstkennung" aus der inneren Nachricht, die signiert und verschlüsselt ist, in den äußeren Header der 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 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 optionale 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. Abzüglich der Tests der weggefallenen Schnittstelle ändert sich also das Zulassungsverfahren nicht.

3 Produktfunktionen

3.1 Allgemeine Anforderungen

Hinweis:

• Durch die Limitierung des Konnektors ist die Client-Mail Verarbeitung nur bis zu einer Größe von 15 MiB sinnvoll möglich.
• Es ist zu beachten dass durch die base64-Kodierung der übersendeten Client-Mail die empfangene Mailgröße am Clientmodul durch die Transportkodierung um den Faktor 1,37 erhöht ist. Das bedeutet es kann eine um diesen Faktor erhöhte Mailgröße bei der Übertragung vom Clientsystem zum Clientmodul vorkommen. 
• Wenn der Empfänger ein Clientmodul ab Version 1.5 nutzt, können mit der in Kap. 3.2 beschriebenen Vorgehensweise auch große Client-Mails über 15 MiB versendet 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.

Tabelle 1: Tab_Fehlercodes_KOMLE-Clientmodule

Die Meldungen beim Einsatz eines Virenscanners während der Verarbeitung durch das Clientmodul sind als optional zu betrachten und können bei Bedarf verwendet werden. Auf die Bereitstellung eines eigenen Header-Attributs wird verzichtet.

Die Fehlermeldungen beim Senden einer KIM-Mail werden über den Fachdienst zurück an den Sender übermittelt, da eine direkte Rückgabe der Fehlernachricht zum Client nicht vorgesehen ist. Das Clientmodul befüllt im Fehlerfall das X-KIM-Fehlermeldung-Attribut und sendet dies anschließend über den Fachdienst an den Sender zurück. Die Fehlermeldungen beim Empfang einer KIM-Mail werden auf direkten Weg dem Empfänger zugestellt. Der Client (z. B. PVS) muss die Fehlercodes aus der Tabelle Tab_Fehlercodes_KOMLE-Clientmodule auswerten.

Hinweis: Sollten mehrere negative Ergebnisse auftreten, KANN das Mail-Header-Attribut X-KIM-Fehlermeldung mehrmals verwendet werden.

Beispiel:
X-KIM-Fehlermeldung: 4001
X-KIM-Fehlermeldung: 4004
X-KIM-Fehlermeldung: X99

Die folgende Anforderung bezweckt, dass bei Einsatz mehrerer Clientmodule in unterschiedlichen Versionen, der KIM-Teilnehmer bei Verwendung eines Clientmoduls in einer kleineren Version darüber informiert wird, dieses zu updaten.

Hinweis: Das Attribut kimData ist in [gemSpec_VZD] definiert. Für die Aktualisierung der KOM-LE-Version im Verzeichnisdienst ruft das Clientmodul die Operation SetAccount an der Schnittstelle I_AccountManager_Service am Fachdienst des Absenders auf.

Beispiel: empfaenger@hrst_domain.kim.telematik,1.5,eArztbrief|LDT-Auftrag

Hinweis: Wenn die Mail-Adresse zu einem HBA-Account gehört, dann kann die Aktualisierung der KOM-LE-Version im Verzeichnisdienst erst erfolgen, nachdem ein POP3 Nachrichtenabruf erfolgt ist, da für die Aktualisierung im Verzeichnisdienst die UserID benötigt wird (für den Konnektor-Aufrufkontext zur Erzeugung des jwt).

Beispiel:
X-KIM-CMVersion: [VendorID]_2.1.2-8
X-KIM-PTVersion: 1.5.0-2
X-KIM-KONVersion: <secunet konnektor 2.0.0><Konnektor PTV4Plus><4.80.3><2.0.0><4.10.1>

Die Produkttypversion entspricht dabei der Produkttypversion aus dem Produkttypsteckbrief. Die Clientmodulversion entspricht dabei der zugelassenen Produktversion, die im TI-ITSM-System hinterlegt und gepflegt wird.

Hinweis: Die für die Service Lokalisierung zu verwendenden Resource Records werden in [gemSpec_FD_KOMLE#Tab_KOMLE_Service Discovery] beschrieben.

3.2 Umgang mit großen Client-Mails

Dieses Kapitel beschreibt die Verarbeitung von Client-Mails, welche die Größe von 15 MiB überschreiten. Die Größenbeschränkung auf 15 MiB basiert auf Limitierungen der Konnektoroperationen zum Signieren und Verschlüsseln.

Client-Mails mit einer Gesamtgröße bis zu 15 MiB werden entsprechend den Festlegungen in KOM-LE 1.0 behandelt. Übersteigt die Größe einer Client-Mail die 15-MiB-Grenze, wird die gesamte Client-Mail (E-Mail-Daten) durch das KOM-LE-Clientmodul auf einem Speicher (KAS) des KOM-LE-Fachdienstes abgelegt. Das KOM-LE-Clientmodul ersetzt die KOM-LE-Nachricht mit den Metadaten der auf dem KAS abgelegten E-Mail-Daten und versendet sie als signierte und verschlüsselte KOM-LE-Nachricht. Das KOM-LE-Clientmodul des Empfängers erkennt anhand der im Mail Header übergebenen X-KOM-LE-Version, dass es sich um eine KOM-LE 1.5 Nachricht handelt. Es nutzt die im Mail Body enthaltene Information, um die verschlüsselten E-Mail-Daten vom KOM-LE-Fachdienst (KAS) abzurufen, zu entschlüsseln und zu einer Client-Mail zusammenzufügen.

In Kapitel "Schnittstelle I_Attachment_Service" gemäß [gemSpec_FD_KOMLE] wird der Umgang mit großen Client-Mails in einem Sequenzdiagramm erläutert.

3.2.1 Senden von großen Client-Mails

In diesem Kapitel werden Anforderungen an das Clientmodul formuliert, die es erlauben, Client-Mails von über 15 MiB zu versenden.

Hinweis: Der Initialisierungsvektor muss vom Sender pro Nachricht zufällig erzeugt werden. Dieser wird nach Konvention dem Chiffrat (=> ersten 12 Byte) vorangestellt: [IV + Chiffrat].

Mit der folgenden Anforderung wird sichergestellt, dass ein Client nicht bereits unerwünschten Content (über die Attachment Datenstruktur) in die an das Clientmodul übergebene KIM-Mail eingefügt hat.

Hinweis: Bei den E-Mail-Daten handelt es sich um dieClient-Mail, nach eventueller Vorverarbeitung durch das Clientmodul, bevor diese verschlüsselt auf dem KAS abgelegt wurde und über den Freigabelink eindeutig zuordenbar ist. In der zu erzeugenden KOM-LE-Nachricht wird der Mail-Header der Client-Mail übernommen und der Mail-Body mit der KIM-Attachment-Datenstruktur ersetzt. Das folgende Beispiel soll die Verarbeitung verdeutlichen:

Beispiel für eine Client-Mail mit zwei Anhängen die 15 MiB überschreitet:

From: "Sender" <sender@maildomain.telematik>
To: <empfaenger@maildomain.telematik>
Message-Id: <II8HEDLEUEU4.EG0B98QUZNPM2@STST-TEST>
Subject: Mail mit zwei Anhängen
Mime-Version: 1.0

X-KIM-Dienstkennung: KIM-Mail;Default;V1.0
X-KIM-CMVersion: [VendorID]_2.1.2-8
X-KIM-PTVersion: 1.5.3-2
X-KIM-KONVersion: <secunet konnektor 2.0.0><Konnektor PTV4Plus><4.80.3><2.0.0><4.10.1>
X-KIM-Sendersystem: Beispiel-PVS;V2.81

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

Ein 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 zu erzeugende KOM-LE-Nachricht mit der KIM-Attachment-Datenstruktur vor der Verarbeitung durch den Konnektor:

From: "Sender" <sender@maildomain.telematik>
To: <empfaenger@maildomain.telematik>
Message-Id: <II8HEDLEUEU4.EG0B98QUZNPM2@STST-TEST>
Subject: Mail mit zwei Anhängen
Mime-Version: 1.0

X-KIM-Dienstkennung: KIM-Mail;Default;V1.0
X-KOM-LE-Version: 1.5
X-KIM-KAS-Size: 25525700
X-KIM-CMVersion: [VendorID]_2.1.2-8
X-KIM-PTVersion: 1.5.3-2
X-KIM-KONVersion: <secunet konnektor 2.0.0><Konnektor PTV4Plus><4.80.3><2.0.0><4.10.1>
X-KIM-Sendersystem: Beispiel-PVS;V2.81

Content-Type: text/plain; charset=utf-8
Content-Disposition: x-kas
Content-Transfer-Encoding: base64

  {
    "link":     "HTTPS://KIM-FD1.telematik/CXFDTE82346dfzwr7634dfs76sd76sdtzq376e3tzsd",
    "k":        "RzVEY3M0MzkmNGZkc2RneCVoX2tkdFQlNXczZnZDdDM2ZGZ2eGZzJDYxITJndmR1VWpzKGk=",
    "hash":     "Z6A65Z2dasI2I00mM7uxtQjLsEwwl+WLMnDw8eLntaA=",
    "size":     25525700
   }

Die für die Lokalisierung  benötigten DNS Service-Records werden in der [gemSpec_FD_KOMLE] im Kapitel 3.4 Service Lokalisierung beschrieben.

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 großen Client-Mails

In diesem Kapitel werden Anforderungen an das Clientmodul formuliert, die es erlauben, große Client-Mails zu empfangen.

Der ausgelesenen Wert soll für den Abgleich mit dem "size" Wert in der KIM-Attachment-Datenstruktur genutzt werden. Entspricht der Wert nicht dem dort hinterlegten Wert, dann wird der Download nicht durchgeführt.

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

Bei einer solchen Fehlernachricht gibt es folgende Optionen:

• Wenn die empfangene Nachricht vom Server gelöscht wurde, hat der Nutzer die Möglichkeit, durch das Senden an die eigene E-Mail-Adresse und das anschließende Abholen die Verarbeitung zu wiederholen.
• Wenn die empfangene Nachricht nicht vom Server gelöscht wurde, wird beim nächsten Abholen die Verarbeitung wiederholt.

Tabelle "Tab_Fehlertext_Download Fehlertext beim Download von E-Mail-Daten" enthält den Fehlertext, der in die Nachricht eingeführt wird, wenn der Download von E-Mail-Daten nicht durchgeführt werden konnte.

Tabelle 3: Tab_Fehlertext_Download Fehlertext beim Download von E-Mail-Daten

Bei einer solchen Fehlernachricht gibt es folgende Optionen:

• Wenn die empfangene Nachricht vom Server gelöscht wurde, hat der Nutzer die Möglichkeit, durch das Senden an die eigene E-Mail-Adresse und das anschließende Abholen die Verarbeitung zu wiederholen.
• Wenn die empfangene Nachricht nicht vom Server gelöscht wurde, wird beim nächsten Abholen die Verarbeitung wiederholt.

Tabelle "Tab_Fehlercodes_KOMLE-Clientmodule" enthält den Fehlertext, der in die Nachricht eingefügt wird, wenn der Abruf von E-Mail-Daten zu häufig ausgeführt wurde.

3.3 Senden von Nachrichten

3.3.1 Übersicht

Beim Senden von KOM-LE-Nachrichten sorgt das Clientmodul dafür, dass die gesendeten KOM-LE-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 Client-Mails größer 15 MiB wird die Client-Mail symmetrisch verschlüsselt und auf dem KAS des Fachdienstes abgespeichert.

Abbildung 5 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 6 dargestellten Zustandsmuster beschrieben. 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 Tab_SMTP_Ant_Init beschreibt Antworten, die das Clientmodul dem Clientsystem im CONNECT-Zustand sendet.

Tabelle 4: 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 während des Authentifizierungsverfahrens als Teil des Benutzernamens mitgeteilt werden. Ist dies nicht der Fall, d.h. ist der im Benutzernamen vorgesehene Teilstring nicht befüllt (#MTA’s URI und Port Nummer#), dann ermittelt das Clientmodul diese fehlenden Parameter mit Hilfe des übergebenen Benutzernamens (Domainanteil) und damit ausgelöster DNS Service Discovery [gemSpec_FD_KOMLE#Tab_KOMLE_Service Discovery].

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.

Übergibt das Clientsystem die MTA-Adresse und die Portnummer des SMTP-Dienstes als Teil des SMTP-Benutzernamens, sind sie 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 Parameter

• MandantId,
• ClientSystemId und
• WorkplaceId
• KonnektorId (optional)

übergeben (siehe Kapitel 3.5 und [gemSpec_Kon] für Details zu MandantId, ClientSystemId und WorkplaceId). Der optionale Parameter KonnektorID, als Bestandteil des Aufrufkontext für SM-B, ermöglicht die Unterstützung von Multikonnektor-Umgebungen. Die Parameter entsprechen denen des aufrufenden Clients und werden voneinander durch das Zeichen ’#’ getrennt.

Der Aufbau des SMTP-Benutzernamens entspricht somit dem folgenden Muster und hat der den Parametern vorangestellten Nummer in der Reihenfolge zu entsprechen:

[0] Benutzername
[1] <Domain Adresse des SMTP-Servers>:<Port>
[2] MandantId
[3] ClientsystemId
[4] WorkplaceId
— <optional> —
[5] KonnektorId
[...]

Abbildung 7: Abb_MTA_Nutzer-Name Format des SMTP-Benutzernamens

Beispiel:

Bei folgenden Informationen

• Benutzername des Clients = „erik.mustermann@hrst_domain.kim.telematik“,
• Domain Adresse des MTAs = „hrst_domain.kim.telematik“ und Portnummer = 465,
• MandantId = 1,
• ClientsystemId = KOM_LE,
• WorkplaceId = 7
• KonnektorId = Konn_1

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

erik.mustermann@hrst_domain.kim.telematik#hrst_domain.kim.telematik:465#1#KOM_LE#7#Konn_1

Das KOM-LE-Clientmodul bricht die Kommunikation mit dem entsprechende SMTP-Antwortcode ab (siehe Tabelle Tab_SMTP_Verbindung), wenn der erhaltene SMTP-Benutzername nicht alle erforderlichen Parameter enthält. Beinhaltet der SMTP-Benutzername zusätzliche optionale durch ‚#’ abgegrenzte Parameter (z. B. #KonnektorId), dann müssen diese Parameter vom Clientmodul ausgewertet werden 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 Tab_SMTP_Verbindung enthält SMTP-Antwortcodes, die das Clientmodul dem Clientsystem bei einem Verbindungsaufbau mit dem MTA übermittelt.

Tabelle 5: 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.

Hinweis: Sind die MTA-Adresse und die zugehörige Portnummer nicht Bestandteil des übergebenen Benutzernamens, dann ermittelt das Clientmodul diese fehlenden Parameter mit Hilfe des übergebenen Benutzernamens (Domainanteil) und damit ausgelöster DNS Service Discovery [gemSpec_FD_KOMLE#Tab_KOMLE_Service Discovery].

Der Parameter KonnektorId ist eine Referenz auf eine URI oder eine IP-Adresse eines Konnektors, um in einer Umgebung mit mehreren Konnektoren einen bestimmten Konnektor ansprechen zu können. Diese kann beispielweise in einer Konfigurations-Datei im Clientmodul hinterlegt sein.

Beispiel einer vollständigen SMTP-Benutzername-Zeichenkette:

• ohne optionale Bestandteile:

erik.mustermann@hrst_domain.kim.telematik#hrst_domain.kim.telematik:465#1#KOM_LE#7

• KonnektorId als optionaler Bestandteil:

erik.mustermann@hrst_domain.kim.telematik#hrst_domain.kim.telematik:465#1#KOM_LE#7#Konn_1

Erfolgt die Einbindung von KIM in ein bestehendes Mail-System, kann ein übergebener Delimiter ":" zwischen dem Serveranteil und dem Port (z. B. hrst_domain.kim.telematik:465) des SMTP-Benutzernamens zu Fehlern bei der Interpretation im Bestandsystem führen. Es werden daher weitere Delimiter im Benutzernamen unterstützt, sofern die Funktionalität gemäß der Bestandsanforderungen zu den Benutzernamen, in semantischer Abgrenzung, uneingeschränkt erhalten bleiben. Es gilt, dass die Bestandteile des SMTP-Benutzernamens in ihrem semantischen Bezug gemäß [RFC1123, RFC2822] einhalten müssen.

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.

Hinweis: Für die Bestimmung der Größe der Client-Mail und anschließender Prüfung auf passende Empfänger, ist es notwendig den Empfang von SMTP "DATA" abzuwarten. Erst danach können RCPT TO Kommandos mit passenden Empfängern an den Fachdienst weitergeleitet werden.

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.3.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.3.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 Client-Mail zu schützen wird diese 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 KOM-LE-Nachricht dar. Hierbei wird von einer Client-Mail Größe ausgegangen, die kleiner ist als 15 MiB.

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.8.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_ECC</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>

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.  Wenn im Verzeichnisdienst der TI für den Empfänger nur ein RSA Zertifikat gefunden wird, dann wird mit RSA verschlüsselt. Wenn ein RSA- und ECC-Zertifikat gefunden wird, dann wird nur mit dem ECC-Zertifikat verschlüsselt.

Hinweis: Für die SMC-B-Zertifikate einiger Herausgeber gibt es kein eineindeutiges Merkmal, an dem die Zugehörigkeit zweier Zertifikate zu ein und derselben SMC-B erkennbar ist. In solchen Fällen ist es zulässig, diese Zugehörigkeit anhand bestimmter Indizien im Zertifikat mit einer gewissen statistischen Sicherheit festzustellen.
Ein Algorithmus zum Herausfiltern von RSA-Empfängerzertifikaten, welcher eine statistisch ausreichende Sicherheit gewährleistet, ist unter https://github.com/gematik/kim-examples/releases/tag/1.0.0 zu finden.

Hinweis: Entgegen [RFC3464] muss bei der Übermittlung der Fehlernachricht im SMTP Kommando MAIL FROM die Absenderadresse angeben werden. Es geht um die Fehlernachricht-Inhalte. Der [RFC3464] gilt nicht normativ.

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 mehrere 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 stellt die oben beschriebenen Schritte als Aktivitätsdiagramm dar.

Abbildung 9: Abb_Verschl_Msg Verschlüsselung einer Nachricht

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.1.2). 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.telematik
To: musterfrau@komle.telematik
Message-Id: <II8HEDLEUEU1.EG0B98QUZNPM2@STST-TEST>
X-KIM-Dienstkennung: KIM-Mail;Default;V1.0
X-KIM-Sendersystem: Beispiel-PVS;V2.81
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.telematik) 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.telematik

To: musterfrau@komle.telemtik

Message-Id: <II8HEDLEUEU4.EG0B98QUZNPM2@STST-TEST>

X-KIM-Dienstkennung: KIM-Mail;Default;V1.0
X-KIM-Sendersystem: Beispiel-PVS;V2.81

Cc: mustermann2@komle.telematik

<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.telematik

To: musterfrau@komle.telematik

Message-Id: <II8HEDLEUEU4.EG0B98QUZNPM2@STST-TEST>

X-KIM-Dienstkennung: KIM-Mail;Default;V1.0
X-KIM-Sendersystem: Beispiel-PVS;V2.81

Cc: mustermann2@komle.telematik

<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 ENHANCEDSTATUSCODES

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 ENHANCEDSTATUSCODES

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.telematik>

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

>

S->M: 250 OK

M->C: 250 OK

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

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

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.telematik>

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

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.telematik>

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

>

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 ENHANCEDSTATUSCODES

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.telematik noch für musterfrau@komle.telematik 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.telematik>

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

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 verschluesselt werden, weil

Verschlüsselungszertifikate für mustermann@komle.telematik, musterfrau@komle.telematik 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.telematik>

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

S->M: 250 OK

M->C: 250 OK

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

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

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

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 „Nachricht empfangen“  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 10 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 KOM-LE-Nachrichten durchführt und die entschlüsselten Nachrichten an das Clientsystem liefert. Bei einer fehlgeschlagenen Integritätsprüfung wird der Empfänger der KOM-LE-Nachricht mit einer Fehlernachricht informiert. Die Weiterleitung der Client-Mail an das Clientsystem des Empfängers wird in diesem Fall durch das Clientmodul unterbunden.

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 Integritätsprü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 Integritätsprüfung der entschlüsselten KOM-LE-Nachricht fehlschlägt (z. B. weil die Integrität der Nachricht verletzt wurde) wird die entschlüsselte Nachricht verworfen und eine Fehlernachricht an den Empfänger der KOM-LE-Nachricht gesendet. Alternativ kann die Nachricht allerdings, mit dem Verweis auf eine fehlgeschlagene Integritätsprüfung, zugestellt werden.

Das Verhalten des Clientmoduls beim Abholen von Nachrichten kann mit Hilfe der in Abbildung 11 dargestellten Zustandsmuster beschrieben werden und haben 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 Tab_POP3_Ant_Init beschreibt die Antworten, die das Clientmodul dem Clientsystem im CONNECT-Zustand sendet.

Tabelle 6: 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. Ist dies nicht der Fall, d.h. ist der im Benutzernamen vorgesehene Teilstring nicht befüllt (#POP3 Server und Port Nummer#), dann ermittelt das Clientmodul diese fehlenden Parameter mit Hilfe des übergebenen Benutzernamens (Domainanteil) und damit ausgelöster DNS Service Discovery [gemSpec_FD_KOMLE#Tab_KOMLE_Service Discovery].

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.

Übergibt das Clientsystem die Server Adresse und die Portnummer des POP3-Dienstes als Teil des POP3-Benutzernamens, sind sie 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)
• KonnektorId (optional).

übergeben (siehe Kapitel 3.5 und [gemSpec_Kon] für Details zu MandantId, ClientSystemId, WorkplaceId und UserId). Der optionale Parameter KonnektorId, als Bestandteil des Aufrufkontext für SM-B, ermöglicht die Unterstützung von Multikonnektor-Umgebungen. 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). Der optionale Parameter KonnektorId kann ebenfalls entfallen, wenn das Clientmodul nicht mit mehreren Konnektoren kommunizieren muss.

Die Reihenfolge der Parameter entspricht dem folgenden Muster und hat der den Parametern vorangestellten Nummer in der Reihenfolge zu entsprechen:

[0] Benutzername
[1] <Domain Adresse des POP3-Servers>:<Port>
[2] MandantId
[3] ClientsystemId
[4] WorkplaceId
— <optional> —
[5] UserId
[6] KonnektorId
[...]

Abbildung 12: Abb_POP3_Nutzer_Name Format des POP3-Benutzernamens

Beispiel:

Bei folgenden Informationen

• Benutzername des Clients = „erik.mustermann@hrst_domain.kim.telematik“,
• Domain Adresse des POP3-Servers = „hrst_domain.kim.telematik“ und Portnummer = 995,
• MandantId = 1,
• ClientsystemId = KOM_LE,
• WorkplaceId = 7,
• UserId = 13
• KonnektorId = Konn_1

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

erik.mustermann@hrst_domain.kim.telematik#hrst_domain.kim.telematik:995#1#KOM_LE#7#13#Konn_1

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 optionale durch das Zeichen ‚#’ abgegrenzte Parameter enthält (z.B. #UserId#KonnektorId), dann müssen diese Parameter vom Clientmodul ausgewertet werden 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 Tab_POP3_Verbindung enthält POP3-Antwortcodes, die das Clientmodul dem Clientsystem bei einem Verbindungsaufbau mit dem POP3-Server übermittelt.

Tabelle 7: 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.

Der Parameter KonnektorId ist eine Referenz auf eine URI oder eine IP-Adresse eines Konnektors, um in einer Umgebung mit mehreren Konnektoren einen bestimmten Konnektor ansprechen zu können. Diese kann beispielweise in einer Konfigurations-Datei im Clientmodul hinterlegt sein.

Beispiel einer vollständigen POP3-Benutzername-Zeichenkette:

• ohne optionale Bestandteile:

erik.mustermann@hrst_domain.kim.telematik#hrst_domain.kim.telematik:995#1#KOM_LE#7

• nur UserId als optionaler Bestandteil:

erik.mustermann@hrst_domain.kim.telematik#hrst_domain.kim.telematik:995#1#KOM_LE#7#13

• keine UserId jedoch die KonnektorId:

erik.mustermann@hrst_domain.kim.telematik#hrst_domain.kim.telematik:995#1#KOM_LE#7#*#Konn_1

• UserId und KonnektorId als optionale Bestandteile:

erik.mustermann@hrst_domain.kim.telematik#hrst_domain.kim.telematik:995#1#KOM_LE#7#13#Konn_1

Erfolgt die Einbindung von KIM in ein bestehendes Mail-System, kann ein übergebener Delimiter ":" zwischen dem Serveranteil und dem Port (z. B. hrst_domain.kim.telematik:995) des POP3-Benutzernamens zu Fehlern bei der Interpretation im Bestandsystem führen. Es werden daher weitere Delimiter im Benutzernamen unterstützt, sofern die Funktionalität gemäß der Bestandsanforderungen zu den Benutzernamen, in semantischer Abgrenzung, uneingeschränkt erhalten bleiben. Es gilt, dass die Bestandteile des POP3-Benutzernamens in ihrem semantischen Bezug gemäß [RFC1123, RFC2822] einhalten müssen.

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 KOM-LE-Nachricht entgegen, entschlüsselt die Nachricht, prüft deren Integrität und leitet die aufbereitete Client-Mail dem Clientsystem weiter. Im Erfolgsfall wird in die aufbereitete Client-Mail ein Vermerk hinzugefügt und das Clientsystem über das erfolgreiche Abholen der Nachricht informiert. Im Fehlerfall wird das Clientsystem mit dem entsprechenden Antwortcode und Fehlernachricht ü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 (z.B. nicht signierte und nicht verschlüsselte Fehlernachrichten), soll sie ohne weitere Veränderungen dem Clientsystem übermittelt werden.

Bei einer Nachricht mit dem Subject „Die KIM-Version der empfangenen Nachricht wird nicht unterstützt“ gibt es folgende Optionen:

• Wenn die empfangene Nachricht vom Server gelöscht wurde, hat der Nutzer die Möglichkeit durch das Senden an die eigene E-Mail-Adresse und das anschließende Abholen über ein Clientmodul mit passender Version die Aufbereitung zu wiederholen.
• Wenn die empfangene Nachricht nicht vom Server gelöscht wurde, wird beim nächsten Abholen dieser Nachricht die Aufbereitung wiederholt.

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.

Für die vereinfachte Darstellung wird im Folgenden ein Beispiel einer Fehlernachricht ohne die Originalnachricht dargestellt:

From: "Sender" <sender@maildomain.telematik>
To: <empfaenger@maildomain.telematik>
Message-Id: <II8HEDLEUEU4.EG0B98QUZNPM2@STST-TEST>
Subject: Die KIM-Version der empfangenen Nachricht wird nicht unterstuetzt
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-hDUtypluINBWKuVpu2reTw=="
X-KIM-Fehlermeldung: 4008

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

Das verwendete Clientmodul unterstützt die in der empfangenen
Nachricht angegebene KIM-Version [1.5] nicht.
Das verwendete Clientmodul unterstützt nur Nachrichten einer KIM-
Version [1.0].

Es wird empfohlen, das verwendete Clientmodul zu aktualisieren!
Leiten Sie diese Mail an Ihre eigene KIM-E-Mail-Adresse weiter, um die
Nachrichtenverarbeitung beim nächsten Abruf der Nachricht zu
wiederholen.

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.8.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 entschluesselt 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 entschluesselt werden

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

From: mustermann@komle.telematik

To: musterfrau@komle.telematik

Message-Id: <II8HEDLEUEU1.EG0B98QUZNPM2@STST-TEST>

X-KIM-Fehlermeldung: cmgerr_4

X-KIM-DecryptionResult: 01

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.telematik) 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.telematik

To: musterfrau@komle.telematik

Message-Id: <II8HEDLEUEU4.EG0B98QUZNPM2@STST-TEST>

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7

77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH

HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh

...

9efmAAAAAAAAAAAAAA==

--unique-boundary-1--

Bei einer Nachricht mit dem Subject „Die Nachricht konnte nicht entschluesselt werden“ gibt es folgende Optionen:

• Wenn die empfangene Nachricht vom Server gelöscht wurde, hat der Nutzer die Möglichkeit durch das Senden an die eigene E-Mail-Adresse und das anschließende Abholen die Aufbereitung zu wiederholen.
• Wenn die empfangene Nachricht nicht vom Server gelöscht wurde, wird beim nächsten Abholen dieser Nachricht die Aufbereitung wiederholt.

Tabelle Tab_Fehlertext_Entschl enthält die Fehlertexte, die in die Nachricht eingeführt werden, wenn die Entschlüsselung nicht durchgeführt werden konnte. Der Eintrag mit der ID 00 ist nicht als Fehlertext zu verstehen, sondern dient als Ersatz des bisher geforderten Vermerk in der Nachricht zur erfolgreichen Entschlüsselung.

Tabelle 8: Tab_Fehlertext_Entschl Fehlertexte für Entschlüsselungsfehler

*) Diese ID und dazugehöriger Fehlertext sind nur relevant, wenn das Clientmodul einen Konnektor zur Ver- bzw. Entschlüsselung vorsieht.

**) Diese ID und dazugehöriger Fehlertext sind nur relevant, wenn das Clientmodul ein HSM zur Ver- bzw. Entschlüsselung vorsieht. (z.B. Basis-Consumer)

Hinweis: Sollten mehrere negative Ergebnisse bei der Entschlüsselung einer KOM-LE Nachricht hervorgehen KANN das Mail-Header-Attribut X-KIM-DecryptionResult mehrmals verwendet werden.
Beispiel:
X-KIM-DecryptionResult: 01
X-KIM-DecryptionResult: 02
X-KIM-DecryptionResult: X99

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 in Kapitel 3.8.2.

In der Tabelle "Tab_Verm_Sig_Prüf" 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 des Konnektors gemäß [gemSpec_KON#TAB_KON_754] und [gemSpec_KON#TAB_KON_124].

Wenn die Integritätsprüfung der entschlüsselten KOM-LE-Nachricht fehlschlägt, dann wird eine Fehlernachricht gemäß [A_23165] generiert und das X-KIM-IntegrityCheckResult Header-Element mit der jeweiligen ID gemäß der Tabelle "Tab_Verm_Sig_Prüf" befüllt. Der Eintrag mit der ID 01 ist nicht als Fehlercode zu verstehen sondern dient als Ersatz des bisher geforderten Vermerk in der Nachricht zur erfolgreichen Signatur- bzw. Integritätsprüfung.

Tabelle 9: 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 und einen Arztbrief als PDF-Anhang.

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

MIME-Version: 1.0

From: mustermann@komle.telematik

To: musterfrau@komle.telematik

Message-Id: <II8HEDLEUEU4.EG0B98QUZNPM2@STST-TEST>

Subject: Arztbrief

Content-Type: multipart/mixed;

X-KIM-Dienstkennung: Arztbrief;VHitG-Versand;V1.2
X-KIM-CMVersion: [VendorID]_2.1.2-8
X-KIM-PTVersion: 1.5.0-2
X-KIM-KONVersion: <secunet konnektor 2.0.0><Konnektor PTV4Plus><4.80.3><2.0.0><4.10.1>
X-KIM-Sendersystem: Beispiel-PVS;V2.81
X-KIM-DecryptionResult: 00
X-KIM-IntegrityCheckResult: 01

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: 8bit

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

--unique-boundary-1

Content-Type: application/pdf;

name="Arztbrief_Muster.pdf"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;

Content-Description: eAB-PDF-signed

filename="Arztbrief_Muster.pdf"

JVBERi0xLjQNCiXDpMO8w7bDnw0KMiAwIG9iag0KPDwgL0xlbmd0aCAzIDAgUg0KICAgL0Zp

bHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCnicrVhda1sxDH0P5D/4uQ+3lvxxfaEM

...

OEJCQUExQzY0NDU+IF0NCj4+DQpzdGFydHhyZWYNCjIyNDU3Mg0KJSVFT0YNCg==

--unique-boundary-1--

Hinweis: Für lange Header-Elemente (z. B. bei reply-to) muss "folding" gemäß [RFC822] unterstützt werden.
Ein "folding" muss beim Header-Vergleich berücksichtigt werden und muss daher, wenn es vorhanden ist, vor dem Vergleich entfernt werden. Die Integritätsprüfung beinhaltet nur die Werte der Header-Elemente, nicht die Bezeichner der Header-Elemente. Die Werte der Header-Elemente müssen der Addr-Spec Specification genügen (https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1).

Hinweis:

• Es muss sichergestellt werden, dass das Verhalten bei fehlgeschlagener Integritätsprüfung konfigurierbar ist. Dies gewährleistet, dass z. B. keine durch die Krankenkasse beim Leistungserbringer bestätigte eAU (signalisiert durch eine DSN) verworfen wird.
• Sollten mehrere negative Ergebnisse aus der Integritätsprüfung hervorgehen KANN das Mail-Header-Attribut X-KIM-IntegrityCheckResult mehrmals verwendet werden.
  
  Beispiel:
  X-KIM-IntegrityCheckResult: 08
  X-KIM-IntegrityCheckResult: X99

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.telematik#pop.komle.telematik: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.telematik

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 10: Tab_Header_Kat Header-Feld Kategorie

Die zu verwendenden Dienstkennungen werden durch die gematik festgelegt und sind über das Fachportal der gematik im Bereich "Toolkit" abrufbar. Die dort durch die gematik auf der Seite "Dienstkennung" administrierte Übersicht liefert bei Bedarf die Default-Dienstkennung. Diese wird durch das Clientmodul vor der weiteren Verarbeitung in das Headerfeld X-KIM-Dienstkennung der ursprünglichen E-Mail eingetragen, wenn keine Dienstkennung durch den Mail-Client des Senders eingetragen wurde.

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,
• Wechsel zu einer anderen Telemati-ID
• Beantragen und Herunterladen der PKCS#12-Datei,
• Lokalisierung des Account Managers über DNS Service Discovery,
• Meldung der KIM-Version an den Account Manager,
• Meldung der Anwendungskennzeichen an den Account Manager,
• Verwaltung von Abwesenheitsnotizen.

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ötigte PKCS#12 Dateien für das Clientmodul herunterladen.

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

1. Der Leistungserbringer schließt einen Vertrag mit einem KOM-LE-Anbieter
1. Der KOM-LE-Anbieter übermittelt die folgenden Zugangsdaten an den Leistungserbringer (das Verfahren wird vom KOM-LE-Anbieter festgelegt):
1. eine referenceId (wenn diese vom Anbieter benötigt wird) für die Zuordnung beim Anbieter sowie
2. das initiale Passwort
2. Falls für das KIM Clientmodul/Administrationsmodul die Client Authentifizierungsmethode gegenüber dem Konnektor noch nicht konfiguriert wurde, muss diese Konfiguration jetzt erfolgen. Für die Authentifizierungsmethode TLS-Client-Authentifizierung des Clientsystems am verwendeten Konnektor kann dies folgendermaßen erfolgen, falls noch kein TLS Client Zertifikat im KIM Clientmodul vorliegt:
1. Über das Managementinterface des Konnektors wird das X.509-Zertifikat für das KIM Clientmodul und der  zugehörigen privaten Schlüssel erzeugt und exportiert.
2. Über das KIM Administrationsmodul werden X.509-Zertifikat und der zugehörigen privaten Schlüssel importiert.
3. Mit dem importierten X.509-Zertifikat kann das KIM Administrationsmodul die Verbindungen zum Konnektor aufbauen, welche zur Signatur der JSON Web Token nötig sind.
3. Der Leistungserbringer verwendet das Administrationsmodul, um sich am Account Manager seines Fachdienstes zu registrieren
1. Es wird eine serverseitig authentisierte TLS-Verbindung zwischen dem Administrationsmodul und dem Account Manager des Fachdienstes aufgebaut.
2. Im Zuge des Registrierungsprozesses wird die Operation registerAccount() am Account Manager aufgerufen und folgende Parameter an den Account Manager übermittelt:
1. die referenceId (wenn diese vom Anbieter übermittelt wurde),
2. das initiale Passwort,
3. eine E-Mail-Adresse,
   
4. das neue Passwort (die Operation getServiceInformation der Schnittstelle I_ServiceInformation stellt die Password Policy des Anbieters bereit),
5. die KIM-Version.
6. optional Anwendungskennzeichen, handelt es sich um die erste einzutragende E-Mail-Adresse eines Verzeichnisdiensteintrages, wird das Standard Anwendungskennzeichen (StAK) "KIM-Mail" übergeben.
7. optional eingeschränkte Befüllung der mail Attribute im VZD-Eintrag (Parameter "noVzdMailEntry", nur für Basis Consumer)
3. Der Request wird mit dem Auth-Zertifikat der verwendeten Karte (HBA oder SMC-B) signiert
4. Der KOM-LE-Anbieter trägt die angegebene E-Mail-Adresse sowie die KIM-Version in den Verzeichnisdienst ein
   
4. Optional: Automatisiertes Beantragen des kryptografischen Materials (PKCS#12-Datei)
1. Das Administrationsmodul generiert optional ein Passwort gemäß [gemSpec_Krypt] zum Sichern der PKCS#12-Datei. Um sicherzustellen das der Fachdienst den optionalen Wegfall des Passwort unterstützt (beginnend mit KIM 1.5.3) kann über die Abfrage der Operation getServiceInformation die aktuelle Version des Fachdienstes ermittelt werden. 
2. Anschließend ruft das Administrationsmodul die Operation createCert() auf, um das kryptografische Material (PKCS#12) anzufordern.
3. Das Administrationsmodul übergibt die PKCS#12-Datei an das Clientmodul. Wenn kein Passwort verwendet wurde, dann darf die heruntergeladene PKCS#12 Datei nicht persistent gespeichert werden.
4. Dieses Zertifikat wird anschließend vom Clientmodul für alle E-Mail-Adressen und KIM-Fachdienste verwendet.

Konzeptionelle Hinweise zum Standard Anwendungskennzeichen:

Die Existenz eines StAKs soll es ermöglichen, eine KIM Mail auch bei nicht zur genutzten Anwendung passenden Anwendungskennzeichen zu versenden. Um dies sicherstellen zu können, wird innerhalb eines Fachdiensteintrages (FAD) im jeweiligen zu einer Telematik ID gehörenden Verzeichnisdiensteintrags ein StAK "KIM-Mail" hinterlegt. Sendersysteme können bei fehlendem passenden Anwendungskennzeichen auf den mit dem StAK markierten Eintrag im FAD des eigentlichen Empfängers zurückgreifen. Eine Änderung an den aktuell vereinbarten Anwendungskennzeichen darf daher nicht zur vollständigen Löschung eines existierenden StAK innerhalb eines FAD führen. Dahingehende notwendige Änderungen müssen durch das Administrationsmodul berücksichtigt werden, die Möglichkeit der Verlagerung des StAK innerhalb des FAD muss dem Nutzer ermöglicht werden.

3.7.1 Allgemeine Anforderungen

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

hrst.kim.telematik

Hinweis: Durch den Aufruf der Operation listAccounts am Interface I_AccountManager_Service des Account Managers, des jeweiligen KIM Fachdienstes kann eine Liste der zu einer Telematik ID existierenden Accounts abgerufen werden. Dies ermöglicht es, die aktuell existierenden Anwendungskennzeichen in einem VZD Eintrag zu bestimmen.

Hinweis: Das Clientmodul kann das Prüfergebnis für 3 Stunde in einem Cache speichern.
Hinweis: KIM-Teilnehmer können zu ihrer KIM Mail-Adresse ein oder mehrere Anwendungskennzeichen festlegen. Die Zuordnung von KIM-Version zur KIM Mail-Adresse sowie die dazu vergebenen Anwendungskennzeichen werden im Verzeichnisdienst-Eintrag gespeichert. Ein sendendes Clientsystem kann aus dem gefundenen Verzeichnisdienst-Eintrag die KIM Mail-Adresse des Empfängers aussuchen, die das zur X-KIM-Dienstkennung passende Anwendungskennzeichen hat.

Die Anwendungskennzeichen werden von den jeweiligen KIM-Anwendungen festgelegt und der gematik mitgeteilt. Die gematik veröffentlicht alle gültigen Anwendungskennzeichen in der Dienstkennungsliste (https://fachportal.gematik.de/toolkit/dienstkennung-kim-kom-le ) und für technische Systeme in einem FHIR CodeSystem (https://simplifier.net/app-transport-framework/app-tags-cs/$download?format=json).

Das Anwendungskennzeichen wird im Verzeichnisdienst LDAP-Directory im Attribut kimData gespeichert. Die Pflege des Anwendungskennzeichens erfolgt durch den Nutzer mittels Clientmodul und Account Manager.

Die URL wird wie folgt gebildet:

https://<FQDN gemäß DNS-SD SRV RR>:<Port gemäß DNS-SD SRV RR><Base-path gemäß TXT RR><path gemäß yaml Datei>

Der Parameter "alg" ist informativ. Anstatt einer üblichen Signatur bildet er den Hash gemäß [gemSpec_Krypt#A_19644]. Dieser wird mittels der externalAuthenticate-Funktion des Konnektors mit dem AUT-Zertifikat des HBA bzw. der SMC-B signiert. Als Signature Type muss ECDSA (alg = BP256R1) verwendet werden. Sollte der Konnektor dabei einen Fehler melden, wird als Fallback RSASSA-PSS (alg = PS256) verwendet. Diese Signatur wird anstatt des Signaturteils des Tokens angehängt.

Hinweis: Die Gültigkeitsdauer des JSON-Web-Token wird vom Fachdienst festgelegt und als Abfrageparameter jwtExpiration in der ServiceInformation.yaml (I_ServiceInformation) bereitgestellt. 

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) kann von den Anforderungen zur Dialogsteuerung abgewichen werden.

Hinweis: Wird durch das Clientmodul die KOM-LE-Version auch für die Sender in einem lokalen Cache hinterlegt, ist eine Aktualisierung jeweils nach einer Änderung erforderlich.

3.7.2 Registrierung KOM-LE-Teilnehmer

Hinweis: Wird durch den Anbieter keine referenceId bei der initialen Anmeldung benötigt, kann dieser Parameter an dieser Stelle entfallen. Der Nutzer muss in so einem Fall in geeigneter Form informiert werden. Über eine Abfrage an der Schnittstelle I_ServiceInformation am KIM Fachdienst kann festgestellt werden, welche Credentials seitens des Fachdienstes bei der initialen Registrierung benötigt werden.

Hinweis: Wenn "noVzdMailEntry == true" dann werden durch den Account Manager die VZD "mail" und komLeData Attribute nicht befüllt oder im Fall von setAccount werden vorhandene mail und komLeData Attribute gelöscht.
Dieses Attribut soll client-seitig nur vom Basis Consumer unterstützt werden, weil es nur für Krankenkassen relevant ist, um mehrere KIM-Adressen zu ermöglichen.

3.7.3 Deregistrierung KOM-LE-Teilnehmer

3.7.4 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 Parameter 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 mit den Parametern Context (dem Sender entsprechender Aufrufkontext) und CardHandle (Handle der ausgewählten SM-B). 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 14 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 ggfs. 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, wird die Operation GetPinStatus des Konnektors mit den Parametern Context (dem Empfä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 (optional) 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. Wenn die p12-Datei passwort-geschützt ist, dann 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 (optional) 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.

Das jeweilige TLS-Server-Zertifikat muss gemäß KOM-LE-A_2065 in einem geschützten Schlüsselspeicher gespeichert werden.

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.

Der Konnektor verwendet je nach Konfiguration als TLS-Server-Zertifikat:

• Zertifikat der ID.AK.AUT - Der private Schlüssel dazu ist in der gSMC-K geschützt, das Zertifikat wird entweder von der gSMC-K gelesen oder falls es bereits über die TI erneuert wurde aus dem Speicher des Konnektors. Der CommonName dieses Zertifikats ist mit der ICCSN und dem Herausgabedatum befüllt und nicht mit dem Hostnamen des Konnektors. Eine Hostnamenprüfung darf mit diesen Identitäten nicht durchgeführt werden. Die Zertifikate tragen alle Subject.AltNames DNSName="konnektor.konlan". Je nach Herstellungsdatum gibt es neben der RSA 2048 Version dieser Identität auch eine ECC 256 Identität auf Basis von Brainpool Kurven. RSA 2048 ist nur bis Ende 2025 zu verwenden.
• Extern generiertes Zertifikat - Das Schlüsselmaterial wird ebenso extern generiert. Privater Schlüssel und Zertifikat wurden in den Konnektor importiert. Die kryptographischen Verfahren sind in [gemSpec_Kon#TAB_KON_866] festgelegt.
• Im Konnektor generiertes selbstsigniertes Zertifikat - Das Schlüsselmaterial wurde ebenso vom Konnektor erzeugt. Die kryptographischen Verfahren sind in [gemSpec_Kon#TAB_KON_866] festgelegt. Die Zertifikate enthalten den aktuellen Hostnamen des Konnektors, so dass eine reguläre Hostnamevalidierung möglich ist.

A_24333* ist als Bestandsschutz für bereits im Feld bestehende KIM-Installationen zu verstehen. Mit dem Update eines KIM-CM, welches dann A_24332* umsetzt, soll gerade nicht eine bereits bestehende Vertrauensbeziehung zwischen Konnektor und CM zwingend erneuert werden, auch wenn diese auf einer generischen Prüfung des Konnektor-Zertifikats gegen die TI-Komponenten-CA beruht.

4.1.4 Transportsicherung zwischen Clientmodul und Fachdienst

Die Verbindungen zwischen KOM-LE-Clientmodul und KOM-LE-Fachdiensten (inklusive KAS) erfolgen immer über TLS. Der TLS Handshake zwischen dem Clientmodul und dem MTA sowie POP3-Server 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 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).

Hinweis:

Für das lokale Caching von Sperrinformationen und für die Toleranzzeiten gilt A_23225 - lokales Caching von Sperrinformationen und Toleranzzeiten.

Die Anforderung ist wie folgt zu interpretieren:

• Als Sperrinformation gilt die Response des Konnektors zum Request VerifyCertificate.
• Die Zeit zu der die Sperrinformation erzeugt wurde ist der Zeitpunkt der Response des Konnektors.
• TUC_PKI_006 wird nicht verwendet, daher entfällt Punkt 4 der Anforderung.

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 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 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 Tab_Felder_Ablauf_Prot aufgezählten Felder.

Tabelle 11: 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 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 Tab_Felder_Fehler_Prot aufgezählten Felder.

Tabelle 12: Tab_Felder_Fehler_Prot Felder im Fehlerprotokoll

4.4 Konfiguration

Die in der Tabelle Tab_Konf_Param 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.

5.5.2 Weitere Dokumente