Source: http://docplayer.org/10669885-Keyon-versichertenkarte-nach-art-42a-kvg-teil-1-2-version-autor-datum-kommentar-2-9b-r-eberhard-s-staible-7-juni-2011.html
Timestamp: 2017-11-23 11:04:12+00:00

Document:
keyon Versichertenkarte nach Art. 42a KVG Teil 1 / 2 Version Autor Datum Kommentar 2.9b R. Eberhard S. Staible 7. Juni PDF
keyon Versichertenkarte nach Art. 42a KVG Teil 1 / 2 Version Autor Datum Kommentar 2.9b R. Eberhard S. Staible 7. Juni 2011
Download "keyon Versichertenkarte nach Art. 42a KVG Teil 1 / 2 Version Autor Datum Kommentar 2.9b R. Eberhard S. Staible 7. Juni 2011"
1 Expertise Versichertenkarte nach Art. 42a KVG Teil 1 / 2 Version Autor Datum Kommentar 2.9b R. Eberhard S. Staible 7. Juni 2011 keyon AG Schlüsselstrasse Jona Tel Switzerland Fax
2 Inhaltsverzeichnis 1 Management Summary Beurteilung der technischen Sachlage Beurteilung der organisatorischen Sachlage Empfehlungen für das weitere Vorgehen Referenzen Über Keyon Abkürzungen Definitionen Referenzen auf weitere Dokumente Übersicht über die Dokumentenstruktur Auftrag Anstoss für den Auftrag Ziele Aufgaben Grundlagen ech Middleware Public Key Infrastructure Analyse ech-0064 Detailspezifikationen Einleitung Übersicht über die Ergebnisse Detailspezifikation der Schweizerischen Post Detailspezifikation der SASIS ech-0064: Kapitel 3.4 Dateisystem EF.ARR EF.ATR EF.DIR EF.ICCSN EF.ID EF.AD EF.LOG EF.CVC.PDC EF.PK.CA_ORG_PDC EF.CVC.CA_ORG_PDC EF.CVC.CA_ORG_HPC Verwaltung der Notfalldaten ech-0064: Kapitel , Card to Card-Authentication and Authorization Card to Card Authentication and Authorization Terminalauthentisierung CA-Hierarchie ech-0064: Kapitel , PIN-Management ech-0064: Kapitel 5, Kantonale Modellversuche nach Artikel 16 [VVK] ech-0064: Kapitel 6, Definition Zertifikate CV-Zertifikatsformat Signaturformat im Card to Card-Authentisierungsverfahren HPC Technische der FMH-HPC Ursachen der Abweichungen Seite 2/99
3 7.1 Kompetenzen, Verantwortung und Absprachen Aus Sicht EDI resp. BAG Aus Sicht der Versicherer Technische Verfahren und Standards Empfehlungen für das weitere Vorgehen Allgemeine Empfehlungen TAV VVK-EDI Testdaten und Referenzimplementation Public Key Infrastruktur Weiteres Vorgehen Weiterentwicklung des bestehenden Systems Spezifikation des zukünftigen Systems Anhang 1: Hex-Dump der Versicherungskarten VK-Post Hex-Dump VK-SASIS Hex-Dump Anhang 2: Analyse Dateisystem Definitionen Dateisystem [ech64] EF.DIR EF.ICCSN EF.ID EF.AD EF.LOG EF.BGTD EF.IMMD EF.TPLD EF.KHUF EF.ZUSE EF.MEDI EF.ALLG EF.ADDR EF.VERF EF.ATR EF.PIN EF.StatusPIN EF.S B EF.ARR EF.ARR EF.CVC.PDC EF.PK.CA_ORG_PDC EF.CVC.CA_ORG_PDC EF.CVC.CA_ORG_HPC EF.AUT Dateien ausserhalb des Standards EF.Version ief.c2cstate EF.GPKeys Personal Unblocking Key SK.Admin Seite 3/99
4 1 Management Summary Die Versichertenkarte identifiziert Leistungsbezüger (resp. versicherte Personen) und beinhaltet die wichtigsten administrativen Daten. Zukünftig besteht für die Versicherten die Möglichkeit persönliche und medizinische Daten auf der Versichertenkarte speichern zu lassen. Die Verwaltung der Daten auf der Versichertenkarte setzt eine erfolgreiche Authentisierung des Fachpersonals über die HPC voraus, welche die Leistungserbringer (Ärzte, Apotheker, etc.) identifiziert. Bis zum heutigen Zeitpunkt sind nur administrative Daten auf der Versichertenkarte gespeichert. Aufgrund fehlender Software und HPC Karten, die mit CV-Zertifikaten personalisiert sind, werden noch keine medizinischen Daten auf die Versichertenkarte gespeichert. Die Expertise untersucht die Abweichungen zwischen der [ech64] Spezifikation und den beiden Detailspezifikationen [SPEC-POST] und [SPEC-SASIS]. Sie unterstützt das BAG bei der Beurteilung der Abweichungen der beiden Detailspezifikationen von der [VVK-EDI] respektive [ech64] und gibt Empfehlungen für ein mögliches weiteres Vorgehen ab. Die Expertise hat ergeben, dass die Versichertenkarten der Post und der SASIS unter Verwendung einer Middleware einwandfrei funktionieren. Beide Umsetzungsvarianten weisen Abweichungen von den rechtlichen Vorgaben auf, die zum Teil auf Fehler und Interpretationsspielraum in den zugrundeliegenden Standards beruhen. 1.1 Beurteilung der technischen Sachlage [ech64] spezifiziert das System der Schweizerischen Versichertenkarte und bezieht sich, analog zu [VVK-EDI], auf unterschiedliche ISO Normen und RFC Standards. Falls spezifische Sachverhalten in [ech64] nicht näher erläutert sind, gelten die jeweils übergeordneten ISO Normen und RFC Standards. In [ech64] Kapitel 2.2 ist festgehalten, dass es sich hierbei um keinen Implementationsstandard, sondern ein Konzeptions-, Struktur- und Verfahrensstandard handelt. Demnach sind weitere Detailspezifikationen, wie sie in [SPEC-POST] und [SPEC-SASIS] erarbeitet wurden, für die Implementierung einer Versichertenkarte notwendig. Die [SPEC-POST] und die [SPEC-SASIS] wurden weitgehend autonom, mit unzureichender übergeordneter Koordination, erarbeitet 1. Da verschiedene Punkte aus [ech64] und den referenzierten ISO Normen und RFC Standards interpretierbar sind, weichen die [SPEC-POST] und die [SPEC-SASIS] untereinander und von [ech64] ab. Weiter sind einzelne Vorgaben aus [ech64], [VVK-EDI] sowie einer referenzierten ISO Norm 2 fehlerhaft, was sich aufgrund unzureichender Koordination zwischen den 1 Aufgrund verschiedener Sachverhalte muss davon ausgegangen werden, dass sich die Schweizerische Post sowie die SASIS partiell abgesprochen haben. 2 ISO Seite 4/99
5 Versicherern negativ auf die Übereinstimmung der [SPEC-POST] und [SPEC-SASIS] auswirkt. Obwohl beide Spezifikationen Abweichungen gegenüber [ech64] aufweisen, ist die [SPEC-POST] näher an [ech64] als die [SPEC-SASIS]. Eine Übersicht über die Ergebnisse ist in Kapitel 5.2 / Seite 17 aufgeführt. Die [SPEC-POST] hält sich grundsätzlich an die Vorgaben von [ech64], weicht aber, aufgrund unzureichender Koordination, in verschiedenen Punkten von [ech64] ab. Die Abweichungen ergeben sich primär aus Interpretationen der Standards sowie Fehlern in der Umsetzung. Die [SPEC-SASIS] hält sich mehrheitlich an die Vorgaben von [ech64], weicht aber, aufgrund unzureichender Koordination, in verschiedenen Punkten von [ech64] ab. Die Abweichungen ergeben sich primär aus der Verwendung eines von [ech64] abweichenden Zertifikatsformats und von [ech64] abweichenden Schlüssellängen oder Hash-Algorithmen, was einen entsprechenden Einfluss auf verschiedene Prozesse und Komponenten im System der Versichertenkarte hat. Zudem ergeben sich Abweichungen aus Interpretationen der Standards und Fehlern in der Umsetzung. Die praktischen Analysen der Versichertenkarte im Zusammenhang mit einer HPC haben gezeigt, dass die Versichertenkarten gemäss den jeweiligen Spezifikationen umgesetzt wurden und unter Verwendung einer geeigneten Middleware interoperabel zueinander sind. Einzelheiten über die praktischen Analysen sind in [Expertise VK - Tech] aufgeführt. Die Detailspezifikationen beider Kartenherausgeber sind in mehreren, Punkten so zu ergänzen, dass sie als Grundlage für die Entwicklung einer Middleware verwendet werden können. Die nach Art. 2 Abs. 2 VVK geforderte Kompatibilität der Versichertenkarten im Sinne des Gesetzgebers ist aus Sicht der Autoren dieser Expertise jedoch nicht gegeben. 1.2 Beurteilung der organisatorischen Sachlage Die Verantwortlichkeiten im Zusammenhang mit der Spezifikation und Umsetzung der Versichertenkarte wurden unzureichend koordiniert. Gemäss [VVK] und [VVK- Erläuterung] sorgen die Versicherer dafür, dass die von ihnen herausgegebenen Versichertenkarten untereinander kompatibel sind ist das EDI verantwortlich für die Festlegung der hierfür notwendigen technischen Einzelheiten, inklusive der Normen und Standards. Das EDI stützt sich hierbei auf Empfehlung einer Fachgruppe des Vereins ech Die Koordination und Zusammenarbeit zwischen den Versicherern untereinander sowie zwischen den Versicherern und dem EDI war unzureichend und führte zu den unterschiedlichen Spezifikationen und Umsetzungen der Versichertenkarte. Einzelheiten hierzu sind in Kapitel 7 / Seite 52 aufgeführt. Seite 5/99
6 1.3 Empfehlungen für das weitere Vorgehen Die Ziele des Systems der Versichertenkarte sind in [VVK-Erläuterung] festgehalten und können mit den aktuell verfügbaren Versichertenkarten der Post und SASIS unter Verwendung einer geeigneten Middleware umgesetzt werden. Um die Nachhaltigkeit der Lösung sicherzustellen, sollten jedoch die Grundlagen im Zusammenhang mit den technischen Spezifikationen neu geregelt werden. Die Aktivitäten für das weitere Vorgehen können so aufgeteilt werden, dass diese die Weiterentwicklung des bestehenden Systems sowie die Spezifikation des zukünftigen Systems gewährleisten. Die Arbeiten an den beiden Aktivitäten sollten parallel durchgeführt werden. Einzelheiten hierzu sind in Kapitel 8 / Seite 54 aufgeführt. Seite 6/99
7 2 Referenzen 2.1 Über Keyon Keyon ist ein führender Anbieter von Lösungen und Dienstleistungen in den Bereichen IT-Sicherheit und Software Engineering, Public Key Infrastrukturen sowie rechtsgültiger Langzeitarchivierung. Das Unternehmen verfügt über erstklassige Referenzen und hat eine Vielzahl strategischer Projekte für den Bund und seine Kunden aus den Bereichen Finanz, Versicherung, Handel, Industrie und Telekommunikation umgesetzt. 2.2 Abkürzungen Bezeichnung AID AM Application Identifier Access Mode APDU Application Protocol Data Unit nach ISO 7816 API CA CLA CVC DO EDI FID HPC INS LC LE MF P1 P2 PKI SASIS SC SFID VK Application Programming Interface Certification Authority Class-Byte of a command APDU Card Verifiable Certificate Data Object Eidgenössische Departement des Inneren File ID Health Professional Card Instruction-Byte of a command APDU Length Command Length Expected Master File Parameter P1 of a command APDU Parameter P2 of a command APDU Public Key Infrastruktur SASIS AG, beauftrage der santésuisse. Security Condition Short File ID (implizite, interne Selektion) Versichertenkarte Seite 7/99
8 2.3 Definitionen Bezeichnung VK-Post VK-SASIS Versichertenkarte umgesetzt nach den Spezifikationen der Schweizerischen Post Versichertenkarte umgesetzt nach den Spezifikationen der SASIS 2.4 Referenzen auf weitere Dokumente Referenz [ech106] [ech64] [ElDI-V] ech Spezifikation für das System Versichertenkarte Offline Card-to-Card Authentication and Authorization, V1.0 vom 22. März 2010 ech Spezifikationen für das System Versichertenkarte, V1.0 vom 4. Februar 2008 Verordnung des EFD über elektronische Daten und Informationen, SR , Stand am 1. Januar 2010 [Expertise VK - Tech] Expertise Versichertenkarte nach Art. 42a KVG, Teil 2 / 2, Praktische Analyse, Version 1.3 [FMH-HPC] Technische, Version 1.0 vom [ISO ] E DIN EN ISO : Draft Health informatics Patient healthcard data Part 5: Identification data (ISO/DIS :2006) [ISO ] ISO/DIS Health informatics Patient healthcard data Part 6: Administrative data [ISO ] ISO/IEC :2005(E) Identification cards - Integrated circuit cards - Part 4: Organization, security and commands for interchange [ISO ] ISO/IEC :2008 Information technology ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) [ISO ] ISO/IEC :2002 Information technology Security techniques Digital signature schemes giving message recovery Part 2: Integer factorization based mechanisms Seite 8/99
9 [ISO ] ISO/IEC Information technology Security techniques Entity authentication Part 3: Mechanisms using digital signature techniques [SPEC-POST] [SPEC-SASIS] [TAV ElDI-V] [TAV ZertES] [VVK] [VVK-EDI] [VVK-EDI-Änderung] Implementierungsanleitung für die Versichertenkarte nach ech-0064, V1.0.0 SASIS Versichertenkarte, Detailspezifikation, Version 1.4ech, Ausgabe: Technische und administrative Vorschriften für Zertifizierungsdienste im Bereich der ElDI-V im Zusammenhang mit der Ausstellung von Zertifikaten basierend auf fortgeschrittenen Signaturen, SR / Anhang, Inkrafttreten 1. Januar 2010 Referenziert in Art. 2 Abs. 4 [ElDI-V] Technische und administrative Vorschriften über Zertifizierungsdienste im Bereich der elektronischen Signatur, SR / Anhang, Inkrafttreten: 1.Dezember 2006 Referenziert in Art. 3 Abs. 2 und Art. 13 [VZertES] Verordnung über die Versichertenkarte für die obligatorische Krankenpflegeversicherung vom 14. Februar 2007 (Stand am 1. Januar 2009), SR Verordnung des EDI über die technischen und grafischen Anforderungen an die Versichertenkarte für die obligatorische Krankenpflegeversicherung, vom 20. März 2008 (Stand am 1. April 2008), SR Schreiben vom 9. August 2010 des Eidgenössisches Departement des Innern EDI mit dem Titel: Erläuterungen zu den Änderungen der Verordnung des EDI über die technischen und grafischen Anforderungen an die Versichertenkarte für die obligatorische Krankenpflegeversicherung (VVK-EDI), welche voraussichtlich am 1. November 2010 in Kraft treten wird [VVK-EDI-Erläuterung] Erläuterung zur VVK-EDI vom 20. März 2008 [VVK-Erläuterung] Erläuterung zur VVK vom 14. Februar 2007 [VZertES] Verordnung über die elektronische Signatur, SR , Stand 1. Januar 2005 Seite 9/99
10 2.5 Übersicht über die Dokumentenstruktur Expertise Teil 1/2 Expertise Teil 2/2 APDU Protokoll Expertise Teil 1/2 Version 2.9b Expertise Teil 2/2 Version 1.4 Primäres Dokument Management Summary Analyse der Spezifikation Technische Analyse des Sachverhalts, welche keine Card to Card Authentisierung voraussetzten Rechtliche und organisatorische Analyse des Sachverhalts Empfehlungen Technische Analyse des Sachverhalts, welche eine Card to Card Authentisierung voraussetzten APDU Protokoll APDU Protokoll als Grundlage für die Expertise Teil 2/2 Seite 10/99
11 3 Auftrag 3.1 Anstoss für den Auftrag Die technischen Anforderungen an die Versichertenkarte sind in der Verordnung des EDI über die technischen und grafischen Anforderungen an die Versichertenkarte für die obligatorische Krankenpflegeversicherung (VVK-EDI) und im Standard ech-0064 Spezifikationen für das System Versichertenkarte festgehalten. Dieser ist aber kein Implementierungsstandard und kann nur durch eine zusätzlich erarbeitete Detailspezifikation nach Kap (Anforderungen an die Detailspezifikation) des Standards umgesetzt werden. Die Verordnung über die Versichertenkarte für die obligatorische Krankenpflegeversicherung (VVK) überträgt den Versicherern die Aufgabe, untereinander kompatible Karten herzustellen und damit auch die Erarbeitung der Detailspezifikation. Zudem verlangt die VVK auch, dass die Bearbeitung der medizinischen Daten auf der Versichertenkarte (VK) nur mit Hilfe elektronischer Ausweise der medizinischen Leistungserbringer (HPC) möglich sein darf. Die Detailspezifikation und die Spezifikationen der HPC müssen daher aufeinander abgestimmt sein. Die Versichertenkarten werden von zwei verschiedenen Kartenherstellern, der SASIS AG und der Schweizerischen Post hergestellt. Beide Kartenhersteller haben die Vorgaben im Standard ech-0064 und die ausführenden technischen Detailspezifikationen unterschiedlich umgesetzt. Die Kompatibilität zwischen den Versichertenkarten und damit auch die Interoperabiliät zwischen den Versichertenkarten und der Health Professional Card muss angesichts dieser Ausgangslage in einer ersten Phase durch geeignete Software (Middleware) sichergestellt werden. In einer zweiten Phase soll eine Konvergenzlösung gefunden werden. Dafür braucht es insbesondere Kenntnis der Unterschiede der beiden Detailspezifikationen untereinander und Unterschiede der Detailspezifikationen zu den rechtlichen Vorgaben der Versichertenkarte. Es bleibt festzuhalten, dass die Versichertenkarte kein privates Produkt sondern ein öffentliches Gut ist. Die Kartenherausgeber müssen somit sämtliche Spezifikationen offenlegen, soweit diese für die Kompatibilität der Versichertenkarten eine Rolle spielen. Seite 11/99
12 3.2 Ziele Das BAG verfolgt folgende Ziele mit dieser Prüfung: Die Funktionstüchtigkeit der beiden Versichertenkarten für alle rechtlich geforderten Anwendungen (administrative Daten, medizinische Daten und kantonale Modellversuche) ist klar ersichtlich. Differenzen der beiden Detailspezifikationen und effektiv produzierten Versichertenkarten sind klar ersichtlich. Abweichungen der beiden Detailspezifikationen und effektiv produzierten Versichertenkarten von der Verordnung des EDI über die technischen und grafischen Anforderungen an die VVK-EDI und dem Standard ech-0064 sind klar ersichtlich. Der Bericht unterstützt das BAG in einer möglichen Überarbeitung der VVK-EDI und des Standards ech-0064 und bei der Schaffung einer zukünftigen Konvergenzlösung. 3.3 Aufgaben Um die Zielsetzungen zu erreichen, sollen folgende Arbeiten ausgeführt werden: Die Detailspezifikationen von SASIS und Post sind auf Vollständigkeit zu prüfen. Fehlende Angaben sind von den Kartenherausgebern allenfalls einzufordern. Die Detailspezifikationen müssen sämtliche Angaben enthalten, um das Lesen der administrativen Daten und die Bearbeitung der medizinischen Daten zu ermöglichen. Zudem ist das Angebot der beiden Versichertenkarten für kantonale Modellversuche wie Schlüssel, Zertifikate (lesen/schreiben bzw. nachladen), PIN s und Daten darzustellen. Die Funktionsfähigkeit des Systems mit effektiv produzierten Karten (FMH, SASIS und Post) ist zu beurteilen und die Ergebnisse sind festzuhalten. Die Differenzen der beiden Detailspezifikationen und effektiv produzierten Karten untereinander sind festzuhalten. Die Abweichungen der Detailspezifikationen und effektiv produzierten Karten von der VVK-EDI und ech-0064 sind festzuhalten Nach Möglichkeit sind Anpassungen von VVK-EDI und ech-0064 zu empfehlen. Seite 12/99
13 4 Grundlagen Um die Abweichungen der Spezifikationen und deren Auswirkungen auf Umsysteme besser verstehen zu können, werden in diesem Kapitel kurz die wichtigsten Grundlagen des Systems der Schweizerischen Versichertenkarte auf technischer Ebene beschrieben. 4.1 ech-0064 [ech64] spezifiziert das System der Schweizerischen Versichertenkarte unter Berücksichtigung international gültiger Normen auf technischer Ebene. Folgend ist eine Übersicht über die Rahmenbedingungen gegeben und wie diese in Bezug zur technischen Umsetzung der Systems Versichertenkarte stehen. Umsetzung Rahmenbedingungen: Verordnung / Normen KTMV Online-Systeme PC / Terminal Applikation / XML Layer KVG, VVK, VVK-EDI ISO / RFC Standards PKI Authentisierung (Middleware) ech-0064 Protokolle (APDU) Protokolle (APDU) Detailspez SASIS Post Datenstrukturen Datenstrukturen Dateisystem Umsysteme ech-0064 relevant HPC Versichertenkarte [ech64] spezifiziert das System der Schweizerischen Versichertenkarte und bezieht sich, analog zu [VVK-EDI], auf unterschiedliche ISO Normen und RFC Standards. Falls spezifische Sachverhalte in [ech64] nicht näher erläutert sind, gelten die jeweils übergeordneten ISO Normen und RFC Standards. In [ech64] Kapitel 2.2 ist festgehalten, dass es sich hierbei um keinen Implementationsstandard, sondern ein Konzeptions-, Struktur- und Verfahrensstandard handelt. Weiter ist in [ech64] Kapitel 2.1 festgehalten, dass nur ein Minimalset an technologischen Vorgaben definiert würde, um möglichst vielen Anbietern am Markt eine Umsetzung der Vorgaben zu ermöglichen. Seite 13/99
14 Da verschiedene Punkte aus [ech64] und den referenzierten ISO Normen und RFC Standards interpretierbar sind, müssen diese für die Implementierung einer Versichertenkarte detaillierter spezifiziert werden. Analoges gilt für allfällige Anpassungen im Zusammenhang mit Geschäftsprozessen oder gesetzlichen Vorgaben. Zudem müssen in den Detailspezifikationen einzelne fehlerhafte Vorgaben aus [ech64] korrigiert werden. [SPEC-POST] und [SPEC-SASIS] sind entsprechende Detailspezifikationen, welche eine technische Implementierung einer Versichertenkarte ermöglichen sollen. Sie präzisieren die Vorgaben aus [ech64] und den referenzierten ISO Normen und RFC Standards und sind verbindlich für die Implementierung der Versichertenkarte. Die Detailspezifikationen beziehen sich auf Datenstrukturen, Dateisysteme, Protokolle und Authentisierungsverfahren (jeweils blau hinterlegt). Nicht berücksichtigt in den Detailspezifikationen sind sämtliche Prozesse im Zusammenhang mit der Ausstellung und Verwaltung der Versichertenkarte sowie der fachspezifische Einsatz der Versichertenkarte in einem Geschäftsprozess. Hinweis Die Interpretation von [ech64] und den referenzierten ISO Normen und RFC Standards setzt ein umfassendes, tiefgreifendes technisches Fachwissen voraus. Verschiedene Sachverhalten, Datenstrukturen und Protokollbeschreibungen werden auf Ebene Bits und Bytes diskutiert und jeweils mit Sachverhalten, Datenstrukturen oder Protokollbeschreibungen aus anderen Standards verknüpft. Die in [ech64] referenzierten ISO Normen und RFC Standards sind interpretierbar und [ech64] verlangt daher zusätzliche Detailspezifikationen. Ihre Erarbeitung muss aber übergeordnet koordiniert werden Middleware Als Middleware werden anwendungsneutrale Schnittstellen bezeichnet, die zwischen unterschiedlichen Komponenten vermitteln, so dass die Komplexität dieser Komponenten verborgen wird. Im Umfeld der Versichertenkarte war vorgesehen, die Applikationen über die kartenspezifische Schnittstelle gemäss [ech64] anzubinden. Eine übergeordnete, kartenunabhängige Schnittstelle in Form eines API resp. einer Middleware war in [ech64] nur empfohlen 3, jedoch nicht zwingend. Hinweis Die Erarbeitung einer allfälligen API müsste zwingend übergeordnet koordiniert werden. Sie muss aus Sicht der Applikation unabhängig von den Eigenschaften der spezifischen Karten sein. 3 [ech64], Kapitel Seite 14/99
15 4.2 Public Key Infrastructure Jeder Inhaber einer Versichertenkarte und jeder Inhaber einer HPC hat eine digitale Identität in Form eines oder mehrerer digitaler Zertifikate 4. Die Zertifikate werden unter Berücksichtigung definierter Registrier-, Ausgabe- und Verwaltungsprozessen von CAs ausgegeben. Grundsätzlich wird in [ech64] zwischen den folgenden Zertifikaten unterschieden: Typ Root Zertifikat CVC Stammzertifikat einer CA. Das Root Zertifikat ist die Basis für die Validierung digitaler Identitäten. Es kann in Form einer X.509- oder CV Struktur abgebildet werden 5. Digitale Identität in Form eines Card Verifiable Certificates. CV Zertifikate werden an Leistungsbezüger (Versichertenkarte) und Leistungserbringer (HPC) im Zusammenhang mit der Card to Card Authentication eingesetzt. X.509 Digitale Identität in Form eines X.509 Zertifikats. X.509 Zertifikate werden an Leistungsbezüger (Versichertenkarte) und Leistungserbringer (HPC) im Zusammenhang mit der Authentisierung an Online-Systemen 6 eingesetzt. [ech64] definiert folgende CA Hierarchien und Abhängigkeiten im Zusammenhang mit der Card to Card Authentication: 4 Vergleichbar mit der SuisseID 5 Es kann davon ausgegangen werden, dass für CVC und X.509 Zertifikate jeweils eigenen Root CA Instanzen etabliert wurden. 6 Kantonale Modellversuche Seite 15/99
16 Root CA SASIS CVC.CA_ORG_PDC X.509 CVC, PKCS#1, V1.5 Root CA Post CVC.CA_ORG_PDC X.509 CVC, ISO Leistungserbringer Organisation 1 (Bsp. FMH) Leistungserbringer Organisation n (Bsp. Spital X) Arzt x HPC LE1.x_SASIS HPC LE1.x_POST HPC LEn.y_SASIS CVC, PKCS#1, V1.5 CVC, ISO CVC, PKCS#1, V1.5 Arzt y VK SASIS 1..n VK Post 1..n X.509 CVC, PKCS#1, V1.5 X.509 CVC, ISO Im Zusammenhang mit der Card to Card Authentication ergeben sich somit die folgenden Sachverhalte: Komponente VK Das spezifische Root Zertifikat wird in die Versichertenkarte des jeweiligen Anbieters integriert. Es bildet die Grundlage für die Validierung des HPC Zertifikats im Zusammenhang mit der Card to Card Authentication. HPC Die Root CA der jeweiligen Anbieter stellen Zertifikate für Leistungserbringer-Organisationen 7 aus. Diese wiederum stellen Zertifikate an spezifische Leistungserbringer 8 aus. Hinweis Aufgrund der oben abgebildeten CA Hierarchie ist ersichtlich, dass die Anzahl HPC Zertifikate, die für einen spezifischen Leistungserbringer ausgegeben werden müssen, identisch ist mit der Anzahl existierender Root CA (unabhängig von den jeweils eingesetzten Algorithmen und Schlüssellängen). 7 Beispiel: FMH, Spital X, etc. 8 Beispiel: Spezifischer Arzt oder Apotheker Seite 16/99
17 5 Analyse ech-0064 Detailspezifikationen 5.1 Einleitung In diesem Kapitel sind Abweichungen der [SPEC-POST] und der [SPEC-SASIS] gegenüber [ech64] beschrieben. Untersucht wurden alle relevanten Punkte, welche direkt Einfluss auf die Implementierung und Nutzung der Versichertenkarte haben. 5.2 Übersicht über die Ergebnisse In diesem Kapitel werden die Ergebnisse der Untersuchungen konsolidiert und grob bewertet. Aufgrund des Umfangs und der Komplexität des Systems und den beschränkten Ressourcen muss davon ausgegangen werden, dass nicht alle Abweichungen der [SPEC-POST] und der [SPEC-SASIS] gegenüber [ech64] aufgedeckt werden konnten. Es wurden aber genügend Abweichungen gefunden, um eine allgemeingültige Aussage über die Interoperabilität der Versichertenkarten machen zu können. Die Abweichungen der [SPEC-POST] und der [SPEC-SASIS] gegenüber [ech64] haben die folgenden Ursachen: a) In [ech64] ist kein Implementationsstandard, sondern ein Konzeptions-, Strukturund Verfahrensstandard. b) Die [SPEC-POST] und die [SPEC-SASIS] wurden weitgehend autonom, mit unzureichender übergeordneter Koordination, erarbeitet. c) Verschiedene Punkte aus [ech64] und den referenzierten ISO Normen und RFC Standards sind interpretierbar. d) Einzelne Vorgaben aus [ech64], [VVK-EDI] sowie einer referenzierten ISO Norm 9 sind fehlerhaft. Aufgrund der unzureichenden Koordinierung der Parteien führten die jeweiligen Fehler zu Abweichungen in den Spezifikationen oder in der Umsetzungen. 9 ISO Seite 17/99
18 Folgende Tabelle gibt eine Übersicht über die Erkenntnisse und gefundenen Abweichungen. Die einzelnen Spalten sind wie folgt zu lesen: Fehler Spec I/FI H/A/U Fehler in den zugrundeliegenden Spezifikationen, die einen direkten Einfluss auf I/FI oder H/A/U haben. Aufgrund der unzureichenden Koordinierung der Parteien führten die Fehler in den zugrundeliegenden Spezifikationen zu Abweichungen in den jeweiligen Spezifikationen oder Umsetzungen. Abweichung der Spezifikation resp. der Umsetzung aufgrund einer Interpretation resp. einer fehlerhaften Implementation gegenüber [ech64]. Abweichung der Spezifikation resp. der Umsetzung aufgrund dem Hinzufügen, Ändern oder Unterlassen von Elementen gegenüber [ech64]. [SPEC-POST] [SPEC-SASIS] Pos Analyse Fehler Spec I/FI H/A/U Kommentar Fehler Spec I/FI H/A/U Kommentar 1 A1 2 A2 3 A3 X Fehlender PKCS#15 Pfad in EF.DIR X 1 X Struktur "transparent" anstelle "linear variable" 4 A4 X 1 X BCD Kodierung von "Z" nicht definiert X 1 X Kodierung nach ISO 8601: A5 X 2 X ASN.1 Kodierung fehlerhaft umgesetzt X 2 X ASN.1 Kodierung fehlerhaft umgesetzt 6 A6 X 3 X Fehlerhafte Umsetzung der optionalen Felder Keine optionalen Felder definiert, daher kein I/FI 7 A7 X Unterlassen von EF.LOG 8 A8 Siehe A18 Siehe A18 9 A9 X 4 X EF.PK.CA_ORG_PDC als "Working" definiert X EF.PK.CA_ORG_PDC als "Working" definiert 10 A10 Siehe A15 11 A11 X Unterlassen von EF.CVC.CA_ORG_HPC X Unterlassen von EF.CVC.CA_ORG_HPC 12 A12 X 5 X Speicherkapazität der Karte X 5 X Speicherkapazität der Karte 13 A13 X Kartenspezifische Eigenschaften X Kartenspezifische Eigenschaften 14 A14 15 A15 X Von [ech64] abweichende CA Hierachie 16 A16 X Interpretation [VVK-EDI] / [ech64] 17 A17 X X PKCS#15, PIN2, etc. X X PKCS#15, PIN2, etc. 18 A18 X 1 X Von [ech64] abweichendes Zertifikatsformat X 1 X Von [ech64] abweichendes Zertifikatsformat 19 X Von [ech64] abweichendes Signatur-Padding 20 X Von [ech64] abweichender Hash-Algorithmus 21 X Von [ech64] abweichende Schlüssellänge 22 A19 X Fehlerhafte Implementation X Abhängig von A18 Total Legende Fehlerhafte Spezifikation 1 Fehler in ech64 2 Fehler in ISO Fehler in VVK-EDI 4 Die Vorgaben von ech64 sind nicht praxistauglich 5 Unklare Vorgaben in ech64 / VVK-EDI bez. Umgang mit reduzierten der Datenkatalogen Es ist schwierig, die einzelnen Abweichungen in Bezug auf den Einfluss auf das Gesamtsystem zu gewichten. Entscheidend ist, ob eine Abweichung über eine Middleware korrigiert werden kann oder nicht. Die praktischen Analysen haben gezeigt, dass die aktuellen Versichertenkarten unter Verwendung einer geeigneten Middleware interoperable zueinander sind [Expertise VK - Tech]. Offensichtlich grosse Abweichungen von [ech64] wie beispielsweise das Zertifikatsformat 10 können unter Berücksichtigung der aktuellen Situation im 10 A18, [VK-SASIS] Seite 18/99
19 Zusammenhang mit der Zertifikatshierarchie über eine geeignete Middleware zueinander interoperabel gemacht werden. Offensichtlich geringfügige Abweichungen von [ech64] wie beispielsweise die fehlerhafte Kodierung von DF.NOT 11 im Zertifikat könnten aufgrund von Prozessen, welche ausschliesslich auf der Versichertenkarte ausgeführt werden, nicht über eine geeignete Middleware zueinander interoperabel gemacht werden 12. Unabhängig vom Grad der Abweichungen muss eine Applikation die VK-POST und VK- SASIS unterschiedlich gemäss [SPEC-POST] resp. [SPEC-SASIS] ansteuern. Die Interoperabilität der unterschiedlichen Versichertenkarten muss über eine geeignete Middleware sichergestellt werden Detailspezifikation der Schweizerischen Post Die [SPEC-POST] hält sich grundsätzlich an die Vorgaben von [ech64]. Die technischen Einzelheiten werden verständlich beschrieben. Teilweise wären ausführlichere en oder Kommentare angebracht. Die H/A/U spezifischen Abweichungen A11 und A17 fallen wenig ins Gewicht, da sie mit der [SPEC-SASIS] abgeglichen wurden und keinen negativen Einfluss auf das Gesamtsystem haben. Die H/A/U spezifische Abweichung A16 hat einen Einfluss auf verschiedene Prozesse im Zusammenhang mit dem PIN-Schutz der medizinischen Daten. Die I/FI spezifischen Abweichungen zu [ech64] resp. zur [SPEC-SASIS] können über eine Middleware harmonisiert werden. Die I/F/I spezifische Abweichung A18 hätte bei Identischer Umsetzung der VK-Post und VK-Sasis die Verwendung eines einheitlichen Leistungserbringerzertifikats gemäss [ech64] verunmöglicht. Siehe Fussnote A18, [VK-Post], siehe Hinweis 12 Die Kodierung von DF.NOT bei der VK-Post hat in der aktuellen Situation im Zusammenhang mit der Zertifikatshierarchie keinen negativen Einfluss. Falls die VK-Post und VK-SASIS, mit Ausnahme der Kodierung von DF.NOT, identisch umgesetzt worden wären, hätte dies, analog der aktuellen Zertifikatsänderung bei der VK-SASIS, die Verwendung eines einheitlichen Leistungserbringerzertifikats verunmöglicht. 13 Siehe Hinweis in Kapitel 6 Seite 19/99
20 5.2.2 Detailspezifikation der SASIS Die [SPEC-SASIS] hält sich weitgehend an die Vorgaben von [ech64]. Die technischen Einzelheiten werden gut verständlich und ausführlich beschrieben. Die H/A/U spezifischen Abweichungen A11 und A17 fallen wenig ins Gewicht, da sie mit der [SPEC-POST] abgeglichen wurden und keinen negativen Einfluss auf das Gesamtsystem haben. Die H/A/U spezifische Abweichung A7 hat keinen negativen Einfluss auf das Gesamtsystem 14. Die H/A/U spezifische Abweichung A15 hat einen Einfluss auf die Hierarchie der Public Key Infrastruktur im Zusammenhang mit Terminalauthentisierung auf Seiten der Applikation (HPC) und muss dort entsprechend gehandhabt werden. Die Abweichung hat keinen Einfluss auf die Card to Card Authentication. Die H/A/U spezifische Abweichung A18 hat einen Einfluss auf die Public Key Infrastruktur sowie auf verschiedene Prozesse im Zusammenhang mit der Card to Card Authentication der VK-SASIS. Die Abweichung hat keinen Einfluss auf die Card to Card Authentication der VK-POST, da die VK-Post mit eigenen Zertifikaten arbeitet. Auffallend ist, dass die [SPEC-SASIS] sich in Kapitel 6 (Card to Card Authentifizierung und Autorisierung) im Abschnitt (Normative Grundlagen) nicht auf [ech64], sondern auf die technischen Richtlinien des BSI im Zusammenhang mit Extended Access Control (EAC) beziehen. Die CV Zertifikate wurden entsprechend der zuvor genannten Norm ausgegeben und halten sich nicht an die Vorgaben von [ech64]. Die I/FI spezifischen Abweichungen zu [ech64] resp. zur [SPEC- POST] können über eine Middleware harmonisiert werden. 14 Siehe Hinweis in Kapitel Seite 20/99
21 5.3 ech-0064: Kapitel 3.4 Dateisystem Im Folgenden sind die wesentlichen Unterschiede in Bezug auf das Dateisystem festgehalten. Es wurden nur die Dateien beschrieben, deren unterschiedliche Spezifikationen einen Einfluss auf das System der Versichertenkarte haben EF.ARR A1. EF.ARR [ech64] Kapitel [SPEC-POST] Im karteninternen File EF.ARR werden die Zugriffsregeln auf Ebene MF geregelt. EF.ARR ist in der [SPEC-POST] nicht beschrieben. Die Zugriffsregeln werden kartenspezifisch intern abgebildet. [SPEC-SASIS] EF.ARR ist in der [SPEC-SASIS] nicht beschrieben. Die Zugriffsregeln werden kartenspezifisch intern abgebildet EF.ATR A2. EF.ATR [ech64] Kapitel [SPEC-POST] Kapitel 2.5 Das File EF.ATR enthält Datenobjekte zur Identifizierung der Karte und ein Datenobjekt zur Anzeige der Grösse der Ein-/Ausgabe-Puffers. Die maximalen Längen der einzelnen APDU Kommandos unterscheiden sich bei den beiden Spezifikationen, sind aber Konform mit [ech64]. Bez. der problematischen Handhabung der Filestruktur wird auf Kapitel verwiesen. Die Längen der einzelnen APDU Kommandos sind gemäss [SPEC-POST] mit 0x04AF (1 199 Bytes) angegeben. Die VK-POST unterstützt Extended Lc and Le Felder. Hex-Dump EF.ATR 0x2f, 0x01 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 36 bytes, SW= E AF AF AF AF 66 0E 46 0C B 44 1B B f.F..DEG+D A 02.. Seite 21/99
22 Folgend ist die Auswertung des ATR aufgeführt. [SPEC-SASIS] Kapitel 4.3 Die Längen der einzelnen APDU Kommandos sind gemäss [SPEC-SASIS] mit 0x0400 (1 024 Bytes) angegeben. Die VK-SASIS unterstützt Extended Lc and Le Felder. Hex-Dump EF.ATR 0x2f, 0x01 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 45 bytes, SW= E E f.F..Inter D F E 31 MTCOS p Folgend ist die Auswertung des ATR aufgeführt. Seite 22/99
23 5.3.3 EF.DIR A3. EF.DIR [ech64] Kapitel [SPEC-POST] Kapitel 2.4 Das File EF.DIR ist ein Verzeichnis für die in der Versichertenkarte vorhandenen Anwendungen. [ech64] definiert fälschlicherweise die Struktur von EF.ATR als transparent und die Struktur von EF.DIR als linear variabel. Gemäss [ISO ] Kapitel ist definiert, dass die Struktur der beiden Files EF.ATR und DIR entweder linear variabel oder transparent sein müssen. Die VK-Post und die VK-SASIS spezifizieren und implementieren den Typ der Filestruktur sowie den Dateninhalt unterschiedlich. Entsprechend ist der Zugriff auf die Files sowie die Auswertung der Daten unterschiedlich. Die Interoperabilität der unterschiedlichen Spezifikationen kann über eine geeignete Middleware hergestellt werden. a) Die [SPEC-POST] spezifiziert die Struktur der beiden Files EF.ATR und EF.DIR gemäss [ech64] 15. [ech64] folgt jedoch nicht der Vorgaben von [ISO ]. EF.DIR ist entsprechend als linear variable Struktur umgesetzt. b) EF.DIR beinhaltet lediglich die AID von DF.NOT resp. dem DF.PKCS#15 File, nicht aber den Pfad (FID) zu den entsprechenden DFs. Im Zusammenhang mit PKCS#15 16 ist der Application Identifier (Tag 0x4F) und der Pfad (Tag 0x51) zwingend. Die entsprechenden FIDs müssen aus der [SPEC-POST] bezogen werden und statisch in der Middleware gespeichert werden. c) Record 3 ist in der [SPEC-POST] nicht definiert. Hex-Dump EF.DIR 0x2f, 0x00 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ RECORD 1 response: ResponseAPDU: 12 bytes, SW= F 06 D a.o..v.!.. READ RECORD 2 response: ResponseAPDU: 18 bytes, SW= E 4F 0C A B D a.o...cpkcs-15 READ RECORD 3 response: ResponseAPDU: 17 bytes, SW= D 4F 0B F F F a.o..vpostotp.. 15 EF.ATR: Transparent, EF.DIR: Linear variable 16 Kapitel Seite 23/99
24 [SPEC-SASIS] Kapitel 4.2 a) Die [SPEC-SASIS] spezifiziert die Struktur der beiden Files EF.ATR und EF.DIR als transparent und folgt somit [ISO ], jedoch nicht [ech64]. b) Analog zur [SPEC-POST] beinhaltet EF.DIR die AIDs von DF.NOT und DF.PKCS#15. Zudem enthält das EF.DIR der [SPEC-SASIS] je ein Applikations Label sowie die Referenz (FID) zum entsprechenden DF. Eine Middleware kann auf der Basis der beiden letztgenannten Parameter dynamisch auf DF.NOT resp. DF.PKCS#15 zugreifen. Hex-Dump EF.DIR, 0x2f, 0x00 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 86 bytes, SW= F 06 D D a.o..v.!..p.emer E F 00 DF D 4F 0C A0 gencyq.?...a.o B D B 43...cPKCS-15P.PKC D F 00 DF F 0A F7 56 S-15Q.?...a.O..V B 74 4D B 74 4D !.KtMV.P.KtMVQ F 00 DF 03? EF.ICCSN A4. EF.ICCSN [ech64] Kapitel Das File EF.ICCSN entspricht der Kennnummer der Versichertenkarte. Record 1 und 2 sind in [ech64] so spezifiziert, dass sie umgesetzt werden können. Problematisch ist Record 3. Hier legt [ech64] fälschlicherweise fest, dass die generaltime in Record 3 als BCD kodiert werden muss 17. Die VK-Post und die VK-SASIS spezifizieren und implementieren unterschiedliche Dateninhalte. Entsprechend ist die Auswertung der Daten unterschiedlich. Die Interoperabilität der unterschiedlichen Spezifikationen kann über eine geeignete Middleware hergestellt werden. 17 Der Buchstabe Z kann in BCD grundsätzlich nicht kodiert werden. Seite 24/99
25 [SPEC-POST] Kapitel 2.6 a) Die GeneralizedTime ist in 8 Bytes kodiert und folgt den Vorgaben aus [ech64]. Der Buchstabe Z wurde als ASCII Wert den Datumsangaben angefügt. b) Die Struktur von EF.ICCSN wurde in [ech64] als linear variable spezifiziert. Die [SPEC-POST] spezifiziert entgegen [ech64] EF.ICCSN als linear fixed. Dies hat zur Folge, dass die Middleware die Füllbytes gemäss [SPEC-POST] entfernen muss. Hex-Dump EF.ICCSN 0x2f, 0x05 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ RECORD 1 response: ResponseAPDU: 14 bytes, SW= A 0A Z..ui... READ RECORD 2 response: ResponseAPDU: 14 bytes, SW= i... [SPEC-SASIS] Kapitel 4.4 READ RECORD 3 response: ResponseAPDU: 14 bytes, SW= A BZ... Die GeneralizedTime ist nach ISO 8601:2004 kodiert und folgt nicht den Vorgaben aus [ech64]. Hex-Dump EF.ICCSN 0x2f, 0x05 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ RECORD 1 response: ResponseAPDU: 14 bytes, SW= A 0A Z..u` READ RECORD 2 response: ResponseAPDU: 10 bytes, SW= READ RECORD 3 response: ResponseAPDU: 15 bytes, SW= A Z Seite 25/99
26 5.3.5 EF.ID A5. EF.ID [ech64] Kapitel Das File EF.ID enthält die Identifikationsdaten des Karteninhabers nach Anhang 1 der [VVK-EDI]. [VVK-EDI] verweist bezüglich Kodierung der Identifikationsdaten auf [ISO :2006] und auf [ISO :2006]. Problematisch hierbei ist, dass die ASN.1 Kodierung in [ISO :2006], Tabelle 1, falsch spezifiziert wurde. Ein generischer ASN.1 Parser wäre nicht in der Lage, die entsprechenden Identifikationsdaten ohne zusätzliche Logik auslesen zu können. Korrekte Kodierung der Identifikationsdaten ASN.1 Struktur C: [APPLICATION 5] { 0002 A0 27: [0] { 0004 A1 A: [1] { : [1] 'Eberhard' : } 0010 A2 19: [2] { : SEQUENCE { : [1] 'Rene' 001A 81 5: [1] 'Guido' : [1] 'keyon AG' 18 : } : } : } 002B 82 8: [2] ' ' : [3] 'cardholderidentifier' 004B 84 1: [4] : 01. : } Kodierung der Identifikationsdaten nach [ISO :2006] ASN.1 Struktur C: [APPLICATION 5] { : [0] : A1 0A A : E F B : F 6E B 82 8: [2] ' ' : [3] 'cardholderidentifier' 004B 84 1: [4] : 01 : } Aus obiger Struktur ist ersichtlich, dass die einzelnen Identifikationsdaten (Name und Vornamen) nicht ohne zusätzliche Logik ausgelesen werden können. Die Spezifikation nach [ISO :2006] ist aus Sicht der Autoren dieser Expertise fehlerhaft. Die VK-Post und die VK-SASIS spezifizieren und implementieren unterschiedliche Dateninhalte. Beide halten sich bez. Kodierung der Daten nicht an [ISO :2006]. Entsprechend ist die Auswertung der Daten unterschiedlich. Die Interoperabilität der unterschiedlichen Spezifikationen kann über eine geeignete Middleware hergestellt werden. 18 keyon AG wurde als zusätzlicher Vorname der Struktur hinzugefügt. Seite 26/99
27 [SPEC-POST] Kapitel 2.4 Die [SPEC-POST] setzt die Vorgaben von [ech64] um und orientiert sich an [ISO :2006], hat jedoch die Kodierung der Daten falsch implementiert. Ein generischer ASN.1 Parser ist ohne zusätzliche Logik nicht in der Lage, die Daten korrekt auszulesen. Hex-Dump EF.ID 0x2f, 0x06 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 62 bytes, SW= A 80 1C 30 1A 30 0C 0C 0A E 73 2D 50 e: hans-p A C 06 4D eter0.0...muster D ASN.1 Struktur [SPEC-SASIS] Kapitel A: [APPLICATION 5] { C: [0] : 30 1A 30 0C 0C 0A E 73 2D : 30 0A C 06 4D : [2] ' ' 002A 83 D: [3] ' ' : [4] : 01 : } Die [SPEC-SASIS] legt eine eigene Kodierung für die Daten aus EF.ID fest, welche sich grundsätzlich an [ISO :2006] orientiert. Im Gegensatz zu [ISO :2006] trennt die [SPEC-SASIS] den Nachnamen mit den Vornamen nicht durch einzelne Felder sondern durch ein Komma gefolgt von einem Leerzeichen. Hex-Dump EF.ID 0x2f, 0x06 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 86 bytes, SW= B 80 0D C 20 4D B 75 e+..suter, Marku D s ASN.1 Struktur B: [APPLICATION 5] { D: [0] 'Suter, Markus' : [2] ' ' 001B 83 D: [3] ' ' 002A 84 1: [4] : 01 : } Seite 27/99
28 5.3.6 EF.AD A6. EF.AD [ech64] Kapitel [SPEC-POST] Kapitel 2.15 [SPEC-SASIS] Kapitel 4.9 Das File EF.AD enthält die administrativen Daten des Karteninhabers nach Anhang 1 der [VVK-EDI]. [VVK-EDI] Kapitel ist bezüglich der Definition der optionalen Parameter fehlerhaft. Die angegebenen Tags können nicht ohne zusätzliche Informationen BER kodiert werden. Es muss daher davon ausgegangen werden, dass diesbezüglich eigene Interpretationen in die Detailspezifikationen einfliessen werden. Die Interoperabilität der unterschiedlichen Spezifikationen kann über eine geeignete Middleware hergestellt werden. Die [SPEC-POST] setzt die Vorgaben von [ech64] korrekt um und definiert neben den zwingenden Feldern auch verschiedene optionale Felder (siehe Kapitel ). ASN.1 Struktur : [APPLICATION 5] { : [16] : : [17] 'Helsana' 000F 92 5: [18] '01562' : [19] ' ' 002C 94 8: [20] ' ' : } Die Spezifikation der optionalen Felder ist aber aufgrund der eingangs erwähnten Fehler von [VVK-EDI] falsch 19. Ein generischer ASN.1 Parser ist ohne zusätzliche Logik nicht in der Lage, die Daten korrekt auszulesen. Die [SPEC-SASIS] setzt die Vorgaben von [ech64] korrekt um, definiert aber keine optionalen Felder (siehe Kapitel ). ASN.1 Struktur : [APPLICATION 5] { : [16] : : [17] 'TEST' 000C 92 5: [18] '01234' : [19] ' ' : [20] ' ' : } 19 TAG 73 (National Extension) fehlt. TAG 09 ist nicht BER konform. Seite 28/99
29 5.3.7 EF.LOG A7. EF.LOG [ech64] Kapitel [SPEC-POST] Kapitel 2.7 [SPEC-SASIS] Das File EF.LOG ist eine anwendungsspezifische Protokolldatei mit dem Ziel der Behebung eines Fehlers resp. der Wiederherstellung eines kartenspezifischen Zustandes im Falle von technischen oder applikatorischen Problemen. Dies setzt jedoch voraus, dass die Middleware resp. die Applikation kartenspezifische Details kennt und weiss, wie diese anzusteuern sind 20. Die [SPEC-POST] beschreibt die Struktur des Files EF.LOG, jedoch werden keine Einzelheiten offengelegt, welche Behebung eines Fehlers resp. die Wiederherstellung eines kartenspezifischen Zustandes im Falle von technischen oder applikatorischen Problemen erlauben würde. Die [SPEC-SASIS] definiert kein File EF.LOG EF.CVC.PDC A8. EF.CVC.PDC [ech64] Kapitel [SPEC-POST] Kapitel 2.9 [SPEC-SASIS] Kapitel 4.11 Das File EF.CVC.PDC enthält das CV Zertifikat der Versichertenkarte. Die VK-Post und die VK-SASIS spezifizieren und implementieren unterschiedliche Zertifikatsformate. Die Interoperabilität der unterschiedlichen Spezifikationen kann über eine geeignete Middleware hergestellt werden. Die [SPEC-POST] definiert grundsätzlich das CV Zertifikat gemäss [ech64]. Siehe Kapitel Die [SPEC-SAIS] definiert ein vom [ech64] abweichendes Zertifikatsformat. Siehe Kapitel Praxisfremder Mechanismus Seite 29/99
30 5.3.9 EF.PK.CA_ORG_PDC A9. EF.PK.CA_ORG_PDC [ech64] Kapitel [SPEC-POST] Kapitel 2.8 Das File EF.PK.CA_ORG_PDC enthält den öffentlichen Schlüssel der Root CA 21. Die VK-Post und die VK-SASIS spezifizieren und implementieren unterschiedliche Signaturformate. Die Interoperabilität der unterschiedlichen Spezifikationen kann über eine geeignete Middleware hergestellt werden. Die [SPEC-POST] definiert entgegen [ech64] das File EF.PK.CA_ORG_PDC als Working und ist somit durch eine Middleware auslesbar. Diese Erweiterung der [ech64] Spezifikation wurde aufgrund der Eigenschaften der [ISO9796-2] basierten CV Zertifikate vorgenommen und ermöglicht es so einer Middleware, CV Zertifikatsketten ohne zusätzliche Parameter 22 von aussen prüfen zu können. Die Schlüssellänge stimmt mit den Vorgaben von [ech64] überein. Die [SPEC-POST] sollte noch die detaillierte Kodierung des öffentlichen Schlüssels beschreiben. Hex-Dump EF.PuK.CA_ROOT_VK 0x0e, 0x02 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 142 bytes, SW= A4 4D 1D 1C A8 8A 36 DE 97 BF M d A CE DB E3 3D A B =..* B BA E7 4E FC A0 15 AA 76 D9 7E 11 CB 9A 71 sk..n...v.~...q C A2 2E E1 B0 8F B A G..&...y.K C1 C4 77 E1 48 9D 4E D4 B2 FD w.H.NC.8...5yE C F0 FA E4 57 D6 45 0C A0 B0 9F D5 C#...W.E..( BD 14 ED 5F 78 B6 26 7B 2B FC 4F 14 F8 A5 6B..._x.&{+.O...k B E6 5D F7 9B 05 A8 F9 AC D9 07 6C AF 64 [.p.]...l.d B5 07 6A 7F j... Modulus n Exponent e [SPEC-SASIS] Kapitel 4.11 Die [SPEC-SASIS] definiert entgegen [ech64] das File EF.PK.CA_ORG_PDC als Working und ist somit durch eine Middleware auslesbar. Diese Erweiterung der [ech64] Spezifikation wäre aufgrund der Eigenschaften der [SPEC-SASIS] basierten CV Zertifikate nicht notwendig, da der öffentliche Schlüssel vollständig auf dem CV Zertifikat ausgelesen werden kann. Die Schlüssellänge weicht von den Vorgaben gemäss 21 CVC.CA_ORG_PDC 22 Öffentlicher Schlüssel Seite 30/99
31 [ech64] ab Siehe Kapitel Die [SPEC-SASIS] sollte noch die detaillierte Kodierung des öffentlichen Schlüssels beschreiben. Hex-Dump EF.PuK.CA_ROOT_VK 23 0x00, 0x1c SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ RECORD response: ResponseAPDU: 301 bytes, SW= B CHRVK` C4 40 0A F4 CE 1B FE 3F CF 81 4A 73 F4 3B 6D 70 DE 29 3D 56 9F B Js.;mp.)=V F A D E 9F 67 FC F3?.(1-a#n.g.5.(! B1 63 C1 63 7F 1D D 6D 4F D1 y.c.c..b.w.&mmo EE 84 3C 65 3F 6F 65 6A D7 51 7C D7 BB 6E 8F W..<e?oej.Q..n E8 AA D6 5F EB 41 B9 BF C 7B 8C 18..._.A..U`R4.{ E 48 E4 36 AF DB D FB CA EB 67 D9 52 E6.H.6...g.R A1 E6 DD 5A B3 55 B2 D0 35 BE Z.U..5.9y A0 8D 39 E7 BF 2F D DC E /..S.Fb.NbUw B C1 D7 3D B1 4D E5 59 4D (..=.M#8.YMPa C0 D E B4 04 EF 9A V.6.^...x.I#H" D F 4A 5E E7 21 D9 19 0F CB 4E 3D E OJ^.!...N=.E# E0 3F F F2 F9 48 3D FB AB E4 BC?..?..H=' F0 5C 2D CF E7 ED 60 3A D1 FC 1F E5 C4 9C 8E \-...`: F 6B 6F 8D 98 9B 9B B9 CF A5 CF 5D 78 1C.ko...3..]x B 20 CB B1 D9 F3 ED 2F A 0A A...../.VqV E B F FA 46.aaK...F Modulus n Exponent e EF.CVC.CA_ORG_PDC A10. EF.CVC.CA_ORG_PDC [ech64] Kapitel [SPEC-POST] Kapitel 2.8 Das File EF.CVC.CA_ORG_PDC enthält das CV Root Zertifikat. Die VK-Post und die VK-SASIS spezifizieren und implementieren unterschiedliche Zertifikatsformate. Die Interoperabilität der unterschiedlichen Spezifikationen kann über eine geeignete Middleware hergestellt werden. Die [SPEC-POST] definiert grundsätzlich das CV Zertifikat gemäss [ech64]. Siehe Kapitel Öffentlicher Schlüssel von EF.CVC.CA_ROOT_VK Seite 31/99
32 [SPEC-SASIS] Kapitel 4.11 Die [SPEC-SASIS] definiert ein vom [ech64] abweichendes Zertifikatsformat. Siehe Kapitel Im Weiteren speichert das File EF.CVC.CA_ORG_PDC nicht das wie in [ech64] definierte Root Zertifikat sondern das Herausgeber Zertifikat der Versicherer (Sub CA). Das eigentliche Root Zertifikat wird im File EF.CVC.CA_ROOT_VK gespeichert EF.CVC.CA_ORG_HPC A11. EF.CVC.CA_ORG_HPC [ech64] Kapitel [SPEC-POST] Im File EF.CVC.CA_ORG_HPC wird die HPC im Zusammenhang mit der Card to Card Authentication zwischengespeichert. Die VK-Post und die VK-SASIS spezifizieren und implementieren diesbezüglich die Card to Card Authentication abweichend von [ech64]. Die Interoperabilität der unterschiedlichen Spezifikationen kann über eine geeignete Middleware hergestellt werden. Die [SPEC-Post] definiert kein File EF.CVC.CA_ORG_HPC. [SPEC-SASIS] Die [SPEC-SASIS] definiert kein File EF.CVC.CA_ORG_HPC. Seite 32/99
33 Verwaltung der Notfalldaten A12. Verwaltung der Notfalldaten [VVK-EDI] und [ech64] legen technisch fest, wie spezifische Notfalldaten gespeichert werden müssen. Die folgenden Feststellungen gelten allgemein für alle Notfalldaten. [ech64] 24 fordert eine minimale Speicherkapazität von 32 KByte. Die in [VVK-EDI] spezifizierten Datenkataloge sind jedoch umfassender und können nicht in den minimal geforderten 32 KByte gespeichert werden. [ech64] unterlässt es aber, genaue Vorgaben zu machen, wie mit allfällig reduzierten Speicherkapazitäten umzugehen ist Verwaltung der Records [VVK-EDI] Kapitel 2.3 sowie [ech64] definieren die Elemente im Zusammenhang Allergien oder Überempfindlichkeiten auf Medikamenten wie folgt: Rekord [1..25] Soforttypreaktionen, [VVK-EDI], Kapitel Rekord [26..50] Spättypreaktionen, [VVK-EDI], Kapitel Eine Applikation, welche Daten im Zusammenhang mit Soforttypreaktionen speichern oder auslesen möchte, würde demnach auf Record 1 bis Record 25 zugreifen wollen. Analog würde die Applikation auf Record 26 bis Record 50 zugreifen wollen, wenn sie Daten im Zusammenhang mit Spättypreaktionen speichern oder auslesen wollte. Vergleicht man die Spezifikationen im Zusammenhang mit EF.ALLG (siehe Kapitel ) stellt man fest, dass die [SPEC-POST] total nur 6 Records und die [SPEC- SASIS] total nur 12 Records definiert. Aus den Spezifikationen geht nicht hervor, welche Records für Soforttypreaktionen und welche Records für Spättypreaktionen vorgesehen sind. Die einzelnen Elemente können einzig über die in [VVK-EDI] spezifizierten Tags, unabhängig von den Records, verwaltet werden. Hinweis Auf Ebene APDU ohne zusätzliche Spezifikationen ist es nicht möglich, die Notfalldaten auf der Versichertenkarte zu verwalten. Die [SPEC-POST] und die [SPEC-SASIS] spezifizieren die Filestrukturen im Zusammenhang mit den Notfalldaten unterschiedlich. Die Interoperabilität der unterschiedlichen Spezifikationen kann über eine geeignete Middleware hergestellt werden 24 Kapitel Seite 33/99
34 5.4 ech-0064: Kapitel , Card to Card-Authentication and Authorization Im Folgenden sind die Wesentlichen Unterschiede in Bezug auf die Card to Card- Authentication and Authorization festgehalten. Es wurden Sachverhalte beschrieben, deren unterschiedliche Spezifikationen einen Einfluss auf das System der Versichertenkarte haben Card to Card Authentication and Authorization A13. Card to Card Authentication and Authorization Die Card to Card Authentication and Authorization wird für die Freischaltung des Schreib-/Lesezugriffs auf die Notfalldaten verwendet. Dabei weist sich der Inhaber einer HPC über sein auf der HPC gespeichertes Zertifikat gegenüber der Versichertenkarte aus und erhält die seiner Leistungserbringergruppe entsprechenden Zugriffsrechte. [SPEC-POST] und [SPEC-SASIS] 25 halten sich dabei beide grundsätzlich an das in [ech64] Kapitel spezifizierte Verfahren, zeigen aber individuelle Abweichungen in den im Verfahren verwendeten Daten und Datenformaten. Auf APDU-Level zeigen die Implementierungen der VK-Post und der VK-SASIS Unterschiede. Diese sind aber wenig relevant, da [ech64] auf dieser Stufe keine Vorgaben macht. Die Interoperabilität muss entsprechend durch eine Middleware sichergestellt werden. Nachfolgende Tabelle beschreibt den Ablauf der Card to Card Authentication nach [ech64] und listet die Abweichungen von [SPEC-POST] und [SPEC-SASIS] zu [ech64] auf. Bezeichnung Abweichung gegenüber [ech64] Farbcode Keine Abweichung Geringfügige Abweichung Abweichung # [ech64] [SPEC-Post] [SPEC-SASIS] 1 Selektieren und Auslesen des Chipcard Identifier Files 2 Übertragung des Chipcard Identifier Files der Versichertenkarte 3 Selektieren und Auslesen des CV Personenzertifikats des Versicherten Liest die Kartenreferenznummer anstelle der ICCSN B Verweis auf Technical Guideline TR Record 2 anstelle von Record 1 Seite 34/99
35 4 Übertragung des CV Personenzertifikats des Versicherten 5 Setzen des öffentlichen Root-Schlüssels der Versichererorganisation des Versicherten 6 Prüfen des CV Personenzertifikats des Versicherten 6a Überprüfung der Chipkartenseriennummer durch Vergleich der Nummern auf der Karte und im CV Personenzertifikat 7 Selektieren und Auslesen des Chipcard Identifier Files der Leistungserbringerkarte 8 Übertragung des Chipcard Identifier Files der Leistungserbringerkarte 9 Selektieren und Auslesen des CV Leistungserbringerzertifikats 10 Übertragung des CV Leistungserbringerzertifikat 11 Auslesen und Speichern der notwendigen Leistungserbringer-Attribute aus dem CV Leistungserbringerzertifikat 12 Anhand der Leistungserbringer-Attribute wird das entsprechende Leistungserbringerorganisationszertifikat selektiert. 13 Der Container für das ausgewählte Leistungserbringerorganisationszertifikat wird ausgewählt und soll beschrieben werden. 14 Übertragung und Speicherung des Leistungserbringerorganisationszertifikats 15 Das CV Leistungserbringerzertifikat wird der Versichertenkarte zur Verifikation bereitgestellt 16 Setzen des Root-Schlüssels der Versichererorganisation des Versicherten 17 Prüfen des CV Zertifikats der entsprechenden Herausgeberorganisation 18 Setzen des öffentlichen CA-Schlüssels der entsprechenden Leistungserbringerorganisation Speichert das Zertifikat nicht in EF.CVC_CA_ORG_HPC 1 Die VK-SASIS verwendet ein geändertes CV Zertifikatsformat, geändertes Signaturformat und längere RSA- Schlüssel siehe 1 siehe 1 siehe 1 Speichert das Zertifikat nicht in EF.CVC_CA_ORG_HPC siehe 1 Die VK-SASIS verwendet aufgrund einer geänderten CA-Hierarchie einen anderen Schlüssel als den von CA_ORG_PDC siehe 1 19 Prüfen des CV Leistungserbringerzertifikats siehe 1 20 Zwischenspeicherung des Karteninhaberautorisierungsmerkmalswertes CHAn, welches im Leistungserbringerzertifikat eingebunden ist Seite 35/99
36 21 Zufallszahl erzeugen 22 Zufallszahl übermitteln 23 Zufallszahl signieren Verwendet ICCSN B als Hash-Input 24 Signierte Zufallszahl übermitteln 25 Verifikation der Signatur der signierten Zufallszahl 26 Der Karteninhaberautorisierungsmerkmalswert CHAn wird freigeschaltet 27 Datenaustausch zwischen dem Lesegerät/Anwendungsmodul und der Versichertenkarte 2 Verwendet ein anderes Signaturformat und längere RSA-Schlüssel siehe 2 Seite 36/99
37 5.4.2 Terminalauthentisierung A14. Terminalauthentisierung [ech64] Kapitel Schritt Nr.5 [SPEC-POST] Kapitel APDU-Seq. 1 Mit der Terminalauthentisierung weist sich die Versichertenkarte gegenüber dem Lesegerät aus. Die optionale Terminalauthentisierung der Versichertenkarte gegenüber dem Lesegerät erfolgt über den Vergleich der ICCSN aus der Datei EF.ICCSN mit der ICCSN aus dem CV Personenzertifikat der Versichertenkarte. Die VK-Post und die VK-SASIS spezifizieren diesbezüglich unterschiedliche Verfahren. Die Interoperabilität der unterschiedlichen Spezifikationen kann über eine geeignete Middleware hergestellt werden. Die [SPEC-POST] ist in sich nicht konsistent und weicht von [ech64] ab. Sie verwendet anstelle des in [ech64] definierten ICCSN B (10 Byte) die Kartenreferenznummer (8 Byte). Mit der Kartenreferenznummer kann keine Authentisierung der Versichertenkarte durchgeführt werden. Die [SPEC-POST] muss angepasst werden 27. Details [ech64] definiert dass in Schritt 1 der Inhalt von EF.ICCSN B ausgelesen werden soll. Die in EF.ICCSN B enthaltene ICCSN wird im optionalen Schritt 6a für den Vergleich mit der in CVC.PDC enthaltenen ICCSN benötigt. In den in [SPEC-POST], Kapitel aufgelisteten APDU-Sequenzen wird Record 1 anstelle von Record 2 aus der Datei EF.ICCSN gelesen. D.h. es werden anstelle 10 Byte langen ICCSN die 8 Byte lange Referenznummer der Karte ausgelesen. In Kapitel 3.2 der [SPEC-POST] wird die ICCSN als Input der Hash-Funktion aufgelistet. Allerdings wiederum nur mit 8 Byte Länge anstelle der 10 Byte der ICCSN, was auf eine Verwendung der Referenznummer anstelle der ICCSN hindeutet. [SPEC-SASIS] Kapitel 6.2 Die Terminalauthentisierung wurde nach [ech64] spezifiziert. 27 Gemäss Aussage der Post ist die Spezifikation falsch, die Umsetzung der Versichertenkarte jedoch korrekt. Diese Aussage konnte im Rahmen der Expertise nicht mehr überprüft werden. Seite 37/99
38 Arzt x Arzt y keyon CA-Hierarchie A15. CA-Hierarchie [ech64] Kapitel [SPEC-POST] [SPEC-SASIS] Kapitel Kapitel Die CA-Hierarchie, wie sie in [ech64] definiert wurde, ist in Kapitel 4.2 dieses Dokuments beschrieben. Die VK-Post und die VK-SASIS spezifizieren diesbezüglich unterschiedliche Hierarchien. Die Interoperabilität der unterschiedlichen Spezifikationen kann über eine geeignete Middleware hergestellt werden. Die [SPEC-POST] folgt den Vorgaben aus [ech64]. Die [SPEC-SASIS] führt eine in [ech64] nicht definierte Root-CA ein, welche Issuing CAs der Leistungserbringerorganisationen wie auch der Versichererorganisationen subordiniert. SASIS Issuing CA CVC.CA_ORG_PDC Root CA SASIS CVC.CA_ROOT_VK Root CA Post CVC.CA_ORG_PDC X.509 CVC, ISO EF.PuK.CA_ROOT_VK CVC, PKCS#1, V1.5 Leistungserbringer Organisation 1 (Bsp. FMH) Leistungserbringer Organisation n (Bsp. Spital X) HPC LE1.x_SASIS HPC LE1.x_POST HPC LEn.y_SASIS CVC, PKCS#1, V1.5 CVC, ISO CVC, PKCS#1, V1.5 VK SASIS 1..n VK Post 1..n Die CA-Zertifikate der Versichererorganisationen und Leistungserbringerorganisationen werden gemäss [SPEC-SASIS] nicht durch die in [ech64] Kapitel spezifizierten CAs ausgestellt und signiert. Die Einführung der neuen Root-CA hat einen Einfluss auf die Zertifikatsvalidierungsprozesse im Bereich der Versichertenkarte. Für die Card to Card Authentication muss der Public-Key der Root-CA anstelle des Schlüssels der Issuing-CA verwendet und auf den von der SASIS Seite 38/99
39 herausgegebenen Versichertenkarten gespeichert werden. Auf die optionale Validierung des Versichertenzertifikats durch das Terminal hat die zusätzliche CA keinen Einfluss. Hier kann das Zertifikat der SASIS Issuing CA als Trust-Anker verwendet werden. Optional kann aber auch eine Zertifikatsvalidierung bis zur Root-CA durchgeführt werden. Hinweis Durch die geänderte Hierarchie verliert die Issuing-CA der Versichertenorganisation ihre Rolle als Zertifizierungsstelle der CAs der Leistungserbringerorganisationen. Diese Rolle fällt nun der Root-CA zu. Diese kann damit offline betrieben werden. Seite 39/99
40 5.5 ech-0064: Kapitel , PIN-Management Im Folgenden sind die wesentlichen Unterschiede in Bezug auf das PIN-Management festgehalten. Es werden Sachverhalte beschrieben, deren unterschiedliche Spezifikationen einen Einfluss auf das System der Versichertenkarte haben. [ech64] legt fest, dass der Inhaber der Versichertenkarte den Zugriff auf ausgewählte Kategorien der Notfalldaten mit einer PIN sperren können muss. Weiter muss die PIN mit einem PUK entsperrt werden können. Die VK-Post implementiert zwei PINs und zwei PUKs. Die VK-SASIS implementiert zwei PINs und einen gemeinsamen PUK. Diese PINs und PUKs werden von den Karten wie folgt verwendet: [SPEC-Post] Schutz-Mechanismus Benötigt für: PIN.NOT Sperrung/Entsperrung des Zugriffs auf die Notfalldaten. PUK.NOT Entsperren von PIN.NOT PIN.USER Annahme: Freischaltung der Signaturerstellung mittels der X.509- Zertifikate für den kantonalen Modellversuch. (Verwendung aus [SPEC-POST] nicht ersichtlich) PIN.SO Annahme: Entsperren von PIN.NOT. (Verwendung aus [SPEC- POST] nicht ersichtlich) [SPEC-SASIS] Schutz-Mechanismus Benötigt für: PIN1 Sperrung/Entsperrung des Zugriffs auf die Notfalldaten. PIN2 Freischaltung der Signaturerstellung mittels der X.509-Zertifikate für den kantonalen Modellversuch. PUK Entsperren von PIN1 und PIN2 Auslieferungszustand der Karten: PIN1 ist bei der VK-SASIS bei Auslieferung deaktiviert, d.h. der Zugriff auf die Notfalldaten via Card-to-Card Authentisierung durch die HPC wird nicht blockiert. PIN1 muss bei der ersten Aktivierung des Zugriffsschutzes durch den Benutzer gesetzt werden. PIN2 ist auf einen zufälligen Wert gesetzt und muss vom Benutzer bei Teilnahme an einem kantonalen Modellversuch über den PUK neu gesetzt werden. Das PIN-Management ist in der [SPEC-POST] nur mangelhaft spezifiziert. Aussagen zum Auslieferungszustand der PINs und PUKs sind nicht möglich. Die PIN-Mechanismen der VK-Post und der VK-SASIS sind unterschiedlich und müssen von der Middleware kartenspezifisch implementiert werden. Seite 40/99
41 A16. Kategorie-spezifischer Schutz der Notfalldaten. [ech64] Kapitel 2.3 Kapitel 3.5 [SPEC-POST] Kapitel 2.16 [SPEC-SASIS] Kapitel [ech64] legt fest, dass der Inhaber der Versichertenkarte den Zugriff auf ausgewählte Kategorien der Notfalldaten mit einer PIN sperren können muss. Hinweis [ech64] konkretisiert hierbei die Anforderung der [VVK] 28 und spezifiziert, dass der PIN Schutz auf einzelne Kategorien der medizinischen Notfalldaten angewendet werden muss 29. Mit der VK-Post lassen sich die Notfalldaten nur als Ganzes und nicht Kategorie-weise mit einem PIN-Schutz belegen. [ech64] wird entsprechend nicht eingehalten. Die [SPEC-SASIS] erfüllt die Vorgaben von [ech64]. 28 Art. 7 Abs. 4 [VVK] 29 [ech64] Kapitel 2.3 und Kapitel Seite 41/99
42 5.6 ech-0064: Kapitel 5, Kantonale Modellversuche nach Artikel 16 [VVK] Im Folgenden sind die wesentlichen Unterschiede in Bezug auf die Definition der Sachverhalte im Zusammenhang mit den kantonalen Modellversuchen festgehalten. Es wurden Sachverhalte beschrieben, deren unterschiedliche Spezifikationen einen Einfluss auf das System der Versichertenkarte haben. A17. Kantonale Modellversuche [ech64] Kapitel 5 [SPEC-POST] Kapitel 4 [ech64] spezifiziert nur wenige Sachverhalte im Zusammenhang mit den kantonalen Modellversuchen. Im speziellen sind dies vier dedizierte Files unter DF.KtMV sowie den Anforderungen aus [ech64] Kapitel 5. Aufgrund der wenig spezifischen Vorgaben unterscheiden sich die [SPEC- POST] und [SPEC-SASIS] entsprechend. Im Wesentlichen fordert [ech64] die Bereitstellung eines leeren Containers für X.509 Zertifikate mit dem korrespondierenden privaten Schlüssel, welche über Standardapplikationen genutzt werden können. Die Schnittstelle für den Zugriff auf die diesbezüglichen Funktionen auf der Versichertenkarte erfolgt über eine anbieterspezifische Middleware 30. Da die zuvor genannten Schnittstellen genau spezifiziert sind und aus Sicht Applikation unabhängig von der Implementierung der Versichertenkarte aufgerufen werden können, fallen Abweichungen zwischen der [SPEC-POST] und der [SPEC-SASIS] nicht ins Gewicht. Detaillierte Untersuchungen auf Ebene APDU konnten im Zusammenhang mit kantonalen Modellversuchen nicht durchgeführt werden, da diese in der [SPEC-POST] nicht spezifiziert sind. Die Spezifikation ist dementsprechend zu ergänzen. Die diesbezüglichen Anwendungen sind nur über eine Middleware 31 zugänglich. a) Die [SPEC-POST] bildet die Filestruktur im Zusammenhang mit den kantonalen Modellversuchen in einer PKCS#15 Struktur ab, welche unter DF.KtMV abgelegt ist. [ech64] gibt vor, dass alle Files im Zusammenhang mit den kantonalen Modellversuchen, analog zu allen anderen Files, als EF unter DF.KtMV abgelegt werden müssen. b) [SPEC-POST] definiert, dass der zum X.509 Zertifikat korrespondierende private Schlüssel mit einem PIN / PUK Mechanismus 30 Microsoft CAPI, PKCS#11 31 AET SafeSign Seite 42/99
43 geschützt wird. [ech64] spezifiziert jedoch keinen Zugriffschutz auf den privaten Schlüssel, der in EF.PrKX509 gespeichert ist. Das Zertifikat kann ausschliesslich im Zusammenhang der Authentifizierung über SSL genutzt werden. X509v3 Key Usage 32 X509v3 Extended Key Usage Digital Signature, Non Repudiation, Key Agreement TLS Web Client Authentication c) Die VK Post hat ein persönliches X.509 Zertifikat mit korrespondierendem privaten Schlüssel gespeichert. Das X.509 Zertifikat wird von der SwissSign Personal Silver CA G2 33 ausgestellt. Die Vorinstallation eines persönlichen X.509 Zertifikats ist gemäss [ech64] nicht vorgesehen 34. X.509 Zertifikat Base64 kodiert BEGIN CERTIFICATE----- MIIGbzCCBVegAwIBAgIQAIa1d3K7Y1KiV0jgz7/UPDANBgkqhkiG9w0BAQUFADBV MQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMS8wLQYDVQQDEyZT d2lzc1npz24gugvyc29uywwgu2lsdmvyienbidiwmdgglsbhmjaefw0woteymtyx MzQzNTFaFw0xMzAzMTYxMzQzNTFaMEgxCzAJBgNVBAYTAkNIMRowGAYDVQQDExFN dxn0zxigsgfucy1qzxrlcjedmbsga1uebrmuoda3nty5otk5otk5otk5otk5otqw ggeima0gcsqgsib3dqebaquaa4ibdwawggekaoibaqdsvh/v9dniaju98yxchn2t /ovcmd3thhsoowmp2rf6xiqh1wvjqw5ugjuxbyb1gms6rllc+eoasooqpcsvxtaa gnp0jwhbt8nmh7x2l3ba1ecx7aw4r4j5ul95wgrcei0nfgzrbzcgh9awauva4bq+ EMKbXXYEbXWJrAfzO6PnNaU2D2yHSr9RFt5cM7H8dJA3nvmT3byBcal3Oj7DCbSD LqAtvzgD0w2gw7A6fnqkvFhK9yUfRvrIMvyzwZD5OWCG5q29scjWvkMnUCHLgonk Ohn+16WITTDXU8xH9CkxvGh8eGO6A0Cm0cyePuAsuBKCppkGReB8449acf+AQnNN AgMBAAGjggNGMIIDQjA7BgNVHREENDAyhjBodHRwczovL2xpbmtzLnZrLXNlcnZp Y2UuY2gvODA3NTY5OTk5OTk5OTk5OTk5OTQwDgYDVR0PAQH/BAQDAgPIMBMGA1Ud JQQMMAoGCCsGAQUFBwMCMB8GA1UdIwQYMBaAFOVfBP7h1ptZXZUrMfwu7ueT5ntJ MIIBEAYDVR0fBIIBBzCCAQMwTKBKoEiGRmh0dHA6Ly9jcmwuc3dpc3Muc2lnbmRl bw8uy29tl0u1nuywnezfrtfenjlcntk1rdk1mkizmuzdmkvfruu3otnfnjdcndkw gbkgga+ggayggalszgfwoi8vzglyzwn0b3j5lnn3axnzlnnpz25kzw1vlmnvbs9d Tj1FNTVGMDRGRUUxRDY5QjU5NUQ5NTJCMzFGQzJFRUVFNzkzRTY3QjQ5JTJDTz1T d2lzc1npz24lmjbbryuyq0m9q0g/y2vydglmawnhdgvszxzvy2f0aw9utglzdd9i 32 Auf Non Repudiation und Key Agreement sollte verzichtet werden. 33 Das entsprechende CA Zertifikat ist bei allen gängigen Applikationen bereits registriert. Die Versicherten können das Zertifikat ohne zusätzliche Prozesse nutzen. 34 Gem. Kapitel 4.2 der [SPEC-POST] werden die Zertifikate im Verlauf der ISO- Personalisierung erstellt. Die Dateien sind anschliessend nicht mehr beschreibbar. Seite 43/99
44 [SPEC-SASIS] Kapitel 8 YXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBLAYDVR0gBIIB IzCCAR8wggEQBglghXQBWQEDAQQwggEBMEoGCCsGAQUFBwIBFj5odHRwOi8vcmVw b3npdg9yes5zd2lzc3npz24uy29tl1n3axnzu2lnbi1tawx2zxitq1atq1btlvi0 LnBkZjCBsgYIKwYBBQUHAgIwgaUagaJnZXN0dWV0enQgYXVmIEFydC4gNDJBIEtW RywgZW4gdmVydHUgZGUgbCdhcnQuIDQyQSBMQU1hbCwgdmlzdG8gbCdhcnQuIDQy QSBMQU1hbCwgYmFzZWQgb24gYXJ0LiA0MkEgSElMLCBTUiA4MzIuMTAgLyBSUyA4 MzIuMTAgU2Nod2Vpei9TdWlzc2UvU3ZpenplcmEvU3dpdHplcmxhbmQwCQYHYIV0 AVkKAzB5BggrBgEFBQcBAQRtMGswaQYIKwYBBQUHMAKGXWh0dHA6Ly9zd2lzcy5z awduzgvtby5jb20vy2dplwjpbi9hdxrob3jpdhkvzg93bmxvywqvrtu1rja0rkvf MUQ2OUI1OTVEOTUyQjMxRkMyRUVFRTc5M0U2N0I0OTANBgkqhkiG9w0BAQUFAAOC AQEADuFam+d8eePDhV7nWmLhTTFYfukL8wkmQChVaVeeS2uz8qlTL/I1eehibxzf 2c6Bgbj0RXTnWBkZGvLXLG5ynfJ91tIzEnw1ljqqu1T1afURbYWibrF1tE66g7m7 kbc0zoy8ockgagxekdh4p5skgy22baqqohgwbpnqjb+la8smik1eb/k8hmyu36ze dc1mvyr8tadhtoapryez4+x/3ncoxifwwcfw2v7miqdx8bcvfu+n/m3bvbljc5oe 0+fDhHaBjMCFu4MOip72kZwBZNWfbFNTmJrnUmerPgJcVEsGRst630vodhYSyO5a lpticczc/aow8rdnncw8sd8u9g== -----END CERTIFICATE----- Die [SPEC-SASIS] spezifiziert alle Gegebenheiten im Zusammenhang mit den kantonalen Modellversuchen detailliert auf Stufe APDU. a) Die [SPEC-SASIS] bildet die Filestruktur im Zusammenhang mit den kantonalen Modellversuchen in einer PKCS#15 Struktur ab, welche unter DF.KtMV abgelegt ist. [ech64] gibt vor, dass alle Files im Zusammenhang mit den kantonalen Modellversuchen, analog zu allen anderen Files, als EF unter DF.KtMV abgelegt werden müssen. b) Die [SPEC-SASIS] definiert, dass der zum X.509 Zertifikat korrespondierende private Schlüssel mit einem PIN / PUK Mechanismus geschützt wird. [ech64] spezifiziert jedoch keinen Zugriffschutz auf den privaten Schlüssel, der in EF.PrKX509 gespeichert ist. c) Die VK-SASIS hat kein persönliches X.509 Zertifikat vorinstalliert und erfüllt somit die Vorgaben von [ech64]. Diese müssen über einen zusätzlichen, durch die Modellversuche zu definierenden Prozess auf der VK-SASIS gespeichert werden. d) Die [SPEC-SASIS] definiert zusätzlich zum Authentisierungszertifikat ein X.509 Zertifikat mit einem korrespondierenden, privaten Schlüssel für die Verschlüsselung resp. Entschlüsselung von Daten. Seite 44/99
45 5.7 ech-0064: Kapitel 6, Definition Zertifikate Im Folgenden sind die wesentlichen Unterschiede in Bezug auf die Definition der Zertifikate festgehalten. Es wurden Sachverhalte beschrieben, deren unterschiedliche Spezifikationen einen Einfluss auf das System der Versichertenkarte haben CV-Zertifikatsformat A18. CV-Zertifikatsformat [ech64] Kapitel 6 ff. [SPEC-POST] Kapitel 3.1 Kapitel 6 ff. spezifizieren das Format und den Inhalt der CV Zertifikate. Die Zertifikate folgen der Norm ISO/EC mit Message Recovery nach [ISO ]. [ech64] spezifiziert zusätzlich den Aufbau und Inhalt der im CV Zertifikat verwendeten Datenfelder. Die VK-Post und die VK-SASIS spezifizieren und implementieren unterschiedliche Zertifikate. Entsprechend ist die Verwendung der Zertifikate unterschiedlich. Die Interoperabilität der unterschiedlichen Spezifikationen kann über eine geeignete Middleware hergestellt werden. Die [SPEC-POST] definiert grundsätzlich das CV Zertifikat nach [ech64], jedoch in einem leicht abweichenden Zertifikatsformat. Dies war notwendig, weil das in [ech64] definierte Zertifikatsformat fehlerhaft und dadurch nicht ohne entsprechende Änderungen umsetzbar ist. a) [ech64] weist die folgenden beiden Fehler auf: 1. Falsche Längenangabe der OID (8 Bytes anstelle von 5 Bytes) 2. Falsches Padding resp. Fehler in der Zusammensetzung des Signaturteils des Zertifikats. Die Länge der Signaturdaten inkl. Padding entspricht nicht 1024 Bit, was ein Padding 6BB.. anstelle von 6A zur Folge hätte. Die [SPEC-POST] korrigiert den Fehler in [ech64] über die Längenberechnung der Signaturdaten im CV Zertifikat. Sie korrigiert die zuvor genannten Fehler durch Hinzufügen des zusätzlichen Elements CISD in der Signatur. b) [SPEC-POST] spezifiziert das Feld CHA nicht gemäss [ech64]. CHA hat den Zweck, die Zugriffsrechte des Karteninhabers in Bezug auf Daten, die in einer Versichertenkarte gespeichert sind, festzulegen. Gemäss [ech64] Kapitel muss beispielsweise CHA für eine PDC wie folgt kodiert werden: Seite 45/99
46 AID(DF.NOT) 00 Für eine PDC ergäbe sich somit folgender Wert für den CHA D [SPEC-POST] spezifiziert anstelle der AID(DF.NOT) die Zeichenfolge DF.NOT mit dem zusätzlichen Wert 0x00. Hinweis [ech64] Kapitel definiert, dass der CHA den Zweck hat, die Zugriffsrechte des Karteninhabers in Bezug auf Daten, die in einer anderen Karte gespeichert sind, festzulegen. Falls die VK-Post für die Überprüfung der Zugriffsrechte den ganzen CHA Datensatz 35 verwendet, wäre ein einheitliches Leistungserbringerzertifikat, unabhängig von der Zertifikatshierarchie, der Schlüssellänge, dem verwendeten Padding oder der Kodierung, mit der VK-SASIS nicht möglich. [SPEC-SASIS] Kapitel c) [SPEC-POST] spezifiziert in Kapitel fälschlicherweise den Wert 04 für CA Zertifikate und den Wert 03 für Enduser Zertifikate. Gemäss [ech64] ist der Wert 03 für CA Zertifikate und der Wert 04 für Enduser Zertifikate reserviert. Die [SPEC-POST] ist diesbezüglich anzupassen, die Implementierung in der VK-Post ist jedoch korrekt. Hex-Dump des CV Zertifiikats F D5 5F F 00 BC 1D AC A7 F7.!.._ F C3 0E EF FB 4D A A1 ED D5 io...mp.c*d FF 5F EE 8A 3A 9D 97 8C C 71 D9 3B 38._..:...b...q.; CB 8B BD 0B 31 B1 B0 0B 0D 08 0D 42 7D CC..V..1...B} BD F9 EC 9E 6A 0C 9D 1F 9B BC 43 C C4 3C...j...C.D8.< ED FB 3B 5B 90 C1 C5 21 CC AD ;[...!..Pg E 78 4B 25 7A 6E 8E C1 E8 A F2 ~xk%zn.8!t...d E7 5A A0 B2 AC 5C D7 07 DB C Z...\...l)v( DC 03 3E C AE 5F A E4 FA..>6.Q,._8Ds A B 78 3B C A3 FE E1 A8 F6 45 7B JXG+x;.E<...E{ A0 98 AD 99 7C 2D B E C3 E2 14 E0 F3 F9 FC y B0 51 D8 D1 46 5E 83 F6 FE 6B A9 65 1E 5A FD 12 5E Q..F^...k.e.Z..^ C0 1D 8B 7E 8D 08 A E ~...1b..3...B D CHDSP`.. Hex-Dump des Signaturfeldes a j.chdsp` e 4e 6f 74.ui...DF.Not b 0e f a0 4a d JÕ#t ba eb fa 5f b2 8e 1e e c5 5f ºë&.5 ú_²..â.eå_ d e9 b7 4c 7a ba 4a d b é LzºJÐ...' bf f aa 6b a d b 0f 8f...Oªk 4&M d d e7 be c8 a3 d4 6f 80 bd 7e 19 Õ...cç¾È Ôo.½~ bc cd 46 6a 82 ae cd fd 1d 2f 7b b4 b5 bc ¼ÍFj..5Íý./{ µ¼ Die [SPEC-SASIS] definiert entgegen [ech64] ein Zertifikatsformat auf der Basis von [ISO ]. Das in der [SPEC-SASIS] definierte Zertifikat weicht vollständig vom dem in [ech64] definierten Format ab. Folgend sind die wesentlichen Abweichungen aufgeführt: 1. Zertifikatsstruktur: Das Auslesen der einzelnen Datenfelder erfolgt 35 AID(DF.NOT) XY 36 Inhalt der zu signierenden Daten im CV Zertifikat (Tag 5F37) Seite 46/99
47 grundsätzlich unterschiedlich zu [ech64]. 2. Padding: PKCS#1 V1.5 anstelle von ISO gemäss [ech64] 3. Schlüssellängen: RSA Modulus n = 2048 anstelle von n = 1024 gemäss [ech64] 4. Hash Algorithmen: SHA-256 anstelle von SHA-1 gemäss [ech64] 5. Datenfelder Die Grösse und der Inhalt der folgenden Datenfelder wurden in [SPEC-SASIS] abweichend von [ech64] spezifiziert: CPI: Die [SPEC-SASIS] definiert von [ech64] abweichende CPI Werte. CAR: Die [SPEC-SASIS] definiert von [ech64] abweichende CAR Werte. CHR: Die [SPEC-SASIS] definiert von [ech64] abweichende CAR Werte. OID: Die [SPEC-SASIS] definiert von [ech64] abweichende CAR Werte. CHA 37 : Die [SPEC-SASIS] definiert von [ech64] abweichende CHA Werte. Die oben genannten Datenfelder enthalten jedoch alle für einen Einsatz als Versichertenkarte notwendigen Informationen. Dies sind u.a. Daten zur Identifizierung der Versicherten (ICCSN), zur Bildung von Zertifikatsvalidierungsketten (CAR, CHR), sowie zur Autorisierung des Zugriffes auf die Notfalldaten (CHA). Hex-Dump f f 4e b 5f !..e.N..[_)..B CHSASb f I...`.t." bf 64 6d 4f b3 25 c a 3f 3e dmo³%æ.`.?>d e9 4b 66 c3 2e 5a 11 cb 57 7d e ékfã.z.ëw}ã&.)p" d 04 e8 5d 6f 6e 06 4c bb ac 91 fd a8 37 5b %..è]on.l» ý 7[ ab a bd b ee cc f db «.i½.#îìö.p.rû f 9c 8a 9b f a 1d df e1 65 6f 68 de...ô...ßáeohþ de 20 ca b3 a2 62 e6 96 da a ab ea c8 Þ Ê³ bæ.ú...«êè fa e0 7c bf e9 4b a2 9f 2a 4a 57 ec ú1.à ék.*jwì a0 81 d3 18 e9 ca 59 c e6 ae 18 a0 bc.ó.éêyéw"..æ. ¼ 0000b fa dc cd 15 a f3 4c 75 3a úüí. dc.ólu: c0 7e 96 c4 ad f8 8d 6f 11 a2 a6 b3 bb 85 0e fd 8c ~.Ä ø.o. ³»..ý. 0000d0 ed 96 c7 b c a5 c7 eb f0 96 b1 í.ç 3.L Çë.Y.ð.± 0000e0 8e cd ed 3a 76 7a 74 ca bf ac 78 2a ec.í8..í:vztê x*ì 0000f0 60 4f c6 b e 72 5d 55 b8 e9 ab 8b f1 `OÆ¹ REnr]U é«.ñ e fc aa 57 bd 1d c ae a e2 36..üªW½.Æ0. w.â b c bb 5c 1f c9 94 3b a0 5e 4b 33 2e 8f kâ.r»\.é.; ^K bc be 27 de e4 ee 9e e9 1f 78 0c ¼¾'Þäî.é.x.Q 7.X f 20 0a E..._..u` f 4c 0c L...`.t." f f S.._%..._$ f b 25 f0 34 b2 0d..._7...K%ð4². 37 Vergleiche auch CHA der [SPEC-POST]. [SPEC-SASIS] verzichtet vollständig auf den Prefix AID(DF.NOT) Seite 47/99
48 dd 9d 2b 0e fd 8a b b5 30 1e ac Ý.+.ý.U. 9..µ f6 0f cf de c4 a7 63 6b a d cb cd.ö.ïþä ck!r..ëí ff b a9 72 a c b3 90 c1 ef ÿ³aq. r 1Y2.³.Áï 0001a0 9d 09 a5 9c d2 42 af ae 39 5d c0 9c 34 6a...e.ÒB 9]À.4j 0001b0 5e 2e cf 46 2b ce ce 34 6b 3b 2f 3e 47 ff ^. DÏF+ÎÎ4k;/>Gÿ 0001c d4 a7 94 ad 3c 3f 08 4d 4f f6 26 c2 7a 57.cÔ. <?.MOö&ÂzW 0001d0 2e 9e 2b e1 c2 db 3a 05 fe cb 8d áÂÛ:.þb. Ë.cs 0001e0 9c b7 31 5d d4 28 c a6 61 4e d ]Ô(À(. an.0õ4 0001f0 1c f7 05 7b fd 34 5e 5c d6 4f a4 3d 79 d1..{ý4^\.föo =yñ a b9 be c f3 a9 59 6b 91 1f b J¹¾Ç..pó Yk.¹B e f 7c ad f7 (.9.F...)Ft d 37 e8 2e cb 08 e3 67 ac df f 84.7è.Ë.ãg ß.u'u? e d2 6b 0a 73 9d e b0 9e cd 07 b0 87.Òk.s.F.an.Í e2 95 7e cb 78 c6 bc c2 e9 d2 d0 cc â.~ëxæ¼.6u.âéòðì ad d0 94 b6 70 f8 8d db 9f 8f 5c ff 6e ee RÐ. pø.û..\ÿnî f8 9f 38 7f be e1 21 6e ø.8.¾á!n8. ASN.1 Struktur : [APPLICATION 33] { E 15B: [APPLICATION 78] { 000A 69 1: [APPLICATION 41] : E 42 10: [APPLICATION 2] 'CHSASb ' : [APPLICATION 73] { : OBJECT IDENTIFIER ' ' 002E : [1] : BF 64 6D 4F B3 25 C A 3F 3E E9 4B : 66 C3 2E 5A 11 CB 57 7D E D : 04 E8 5D 6F 6E 06 4C BB AC 91 FD A8 37 5B AB A5 : BD B EE CC F DB 9F 9C : 8A 9B F A 1D DF E1 65 6F 68 DE DE 20 : CA B3 A2 62 E6 96 DA A AB EA C8 FA 31 : 85 E0 7C BF E9 4B A2 9F 2A 4A 57 EC D3 : 18 E9 CA 59 C E6 AE 18 A0 BC : FA DC CD 15 A F3 4C 75 3A E 96 : C4 AD F8 8D 6F 11 A2 A6 B3 BB 85 0E FD 8C ED 96 : C7 B C A5 C7 EB F0 96 B1 8E CD : ED 3A 76 7A 74 CA BF AC 78 2A EC 60 4F : C6 B E 72 5D 55 B8 E9 AB 8B F1 05 1E : FC AA 57 BD 1D C AE A E2 36 6B C2 : BB 5C 1F C9 94 3B A0 5E 4B 33 2E 8F BC BE : 27 DE E4 EE 9E E9 1F 78 0C : [2] : : } A: [APPLICATION 32] : C C: [APPLICATION 76] { : OBJECT IDENTIFIER ' ' : [APPLICATION 19] : 00 : } : [APPLICATION 37] : C 64 6: [APPLICATION 36] : : } : [APPLICATION 55] : 4B 25 F0 34 B2 0D DD 9D 2B 0E FD 8A B0 39 : B5 30 1E AC 84 F6 0F CF DE C4 A7 63 6B A1 : D CB CD FF B A9 72 A : 32 0C B3 90 C1 EF 9D 09 A5 9C D2 42 AF AE : 39 5D C0 9C 34 6A 5E 2E CF 46 2B CE CE 34 : 6B 3B 2F 3E 47 FF D4 A7 94 AD 3C 3F 08 4D : 4F F6 26 C2 7A 57 2E 9E 2B E1 C2 DB 3A 05 FE 62 : CB 8D C B7 31 5D D4 28 C A6 : 61 4E D5 34 1C F7 05 7B FD 34 5E 5C : D6 4F A4 3D 79 D1 4A B9 BE C F3 A9 59 : 6B 91 1F B E F 7C : AD F7 1D 37 E8 2E CB 08 E3 67 AC DF : F 84 9E D2 6B 0A 73 9D E : B0 9E CD 07 B0 87 E2 95 7E CB 78 C6 BC : 03 C2 E9 D2 D0 CC AD D0 94 B6 70 F8 8D DB : 9F 8F 5C FF 6E EE F8 9F 38 7F BE E1 21 6E : } Seite 48/99
49 5.7.2 Signaturformat im Card to Card-Authentisierungsverfahren A19. Signaturformat im Card to Card-Authentisierungsverfahren [ech64] Kapitel 3.6 ff. Kapitel 6.1 [SPEC-POST] Kapitel 3.2 Gemäss [ech64] muss die HPC während der für den Zugriff auf die Notfalldaten notwendigen Card to Card Authentication eine Signatur einer Zufallszahl erstellen, welche anschliessend von der PDC geprüft wird. Die genauen Signaturparameter (Signatureingangsdaten, Signaturformat) werden von [ech64] nicht explizit spezifiziert. Es wird jedoch auf [ISO ] verwiesen. [ech64] ist diesbezüglich zu wenig präzise und sollte überarbeitet werden. Die VK-Post und die VK-SASIS spezifizieren und implementieren unterschiedliche Signaturformate. Die Interoperabilität der unterschiedlichen Spezifikationen kann über eine geeignete Middleware hergestellt werden. Die [SPEC-POST] definiert als Hash-Eingangsdaten der Signatur nicht nur die 8 Byte lange Zufallszahl, sondern fügt in Anlehnung an [ISO ] zusätzlich noch eine von der HPC erzeugte Zufallszahl sowie die ICCSN B der Versichertenkarte hinzu. Details [SPEC-SASIS] Kapitel weist darauf hin, dass aufgrund der erstellten Signatur kein Rückschluss auf eine einmal hergestellte Verknüpfung zwischen einer bestimmten Versichertenkarte und der Leistungserbringerkarte möglich sein sollte. Das Signaturverfahren gemäss [SPEC-POST] lässt aufgrund der signierten ICCSNB der Versichertenkarte eine logisch nachweisbare Verknüpfung zur HPC zu. [SPEC-SASIS] Kapitel Obwohl [ech64] Kapitel 3.6 ff. das Padding der Signatur im Zusammenhang mit der Card to Card Authentication nicht explizit definiert, muss aufgrund der Signatureigenschaften der in [ech64] definierten CV Zertifikate ausgegangen werden, dass die HPC das Padding gemäss [ISO ] anwenden muss. [SPEC-SASIS] definiert das Padding und die RSA Signatur gemäss PKCS#1 V Analoges Verfahren wie für die gemäss [SPEC-SASIS] definierten CV Zertifikate. Seite 49/99
50 6 HPC [ech64] spezifiziert Einzelheiten im Zusammenhang mit den Versichertenkarten. Die Anforderungen an die HPC sind in [ech64], Kapitel nur kurz beschrieben. Die detaillierte Beurteilung der [FMH-HPC] analog zur [SPEC-POST] oder [SPEC-SASIS] war auch nicht Bestandteil der Expertise. Um die Funktionsfähigkeit des Systems mit effektiv produzierten Karten (FMH-HPC, VK-Post und VK-SASIS) beurteilen zu können, wurde die FMH-HPC im Zusammenhang mit der Card to Card Authentisierung einbezogen. 6.1 Technische der FMH-HPC Die technische der [FMH-HPC] hat zum Ziel, die notwendigen Informationen bereitzustellen, damit die FMH-HPC in Applikationen integriert werden kann. Die [FMH-HPC] ist keine Detailspezifikation vergleichbar mit [SPEC-POST] oder [SPEC-SASIS] und enthält entsprechend wenige technische Einzelheiten über die Struktur der Datenobjekte 39 und Schnittstellen der FMH-HPC. Es kann davon ausgegangen werden, dass sich die Autoren der [FMH-HPC] mit den Autoren der Versichertenkarten abgestimmt haben. Die in [ech64] fehlerhaft definierten Strukturen wurden analog zu den Spezifikationen der [SPEC-POST] korrigiert 40. Analog verhält es sich mit interpretierbaren Strukturen. Zu bemerken ist, dass die [FMH-HPC] keine Angaben zu der Zertifikatstruktur macht, wie sie in der [SPEC-SASIS] definiert wurde. Die praktischen Untersuchungen haben aber gezeigt, dass die FMH-HPC mit der VK-Post und der VK-SASIS interoperabel ist. 39 Insbesondere keine Angaben zu den FID 40 Hinweis: Die abgestimmten Strukturen weisen Unterschiede auf. Im Vergleich zur [SPEC- POST] beschreibt die [FMH-HPC] die Kodierung CED im CISD unterschiedlich. CED [SPEC- POST] := YYMM, CED [FMH-HPC] := MMYY Seite 50/99
51 Hinweis Aufgrund der in Kapitel 5 aufgeführten Unterschiede der Spezifikationen und Implementationen der Versichertenkarten kommt der HPC eine entscheidende Bedeutung für das korrekte Funktionieren des gesamten Systems zu. In diesem Dokument wurde mehrfach erwähnt, dass die Interoperabilität der unterschiedlich implementierten Versichertenkarten über eine geeignete Middleware hergestellt werden kann. Dies ist möglich, weil die FMH-HPC die folgenden zusätzlichen Eigenschaften gegenüber [ech64] erfüllt 41 : 1. Die HPC kann RSA RAW Signaturen ausführen. 2. Die HPC unterstützt 1024 Bit und 2048 Bit RSA Schlüssel. Die durchgeführten praktischen Tests haben gezeigt, dass die FMH-HPC die oben genannten Anforderungen erfüllt und somit das Funktionieren des Systems sichert. Folglich sind die VK-Post und die VK-SASIS unter Verwendung einer geeigneten Middleware und der FMH-HPC, bestückt mit zwei unterschiedlichen Leistungserbringerzertifikaten, interoperabel. Siehe [Expertise VK - Tech]. 41 Diese Anforderungen ergeben sich nicht aus [ech64] und sind demnach nicht verbindlich für die Umsetzung der HPC. Seite 51/99
52 7 Ursachen der Abweichungen In diesem Kapitel werden die Ursachen der unterschiedlichen Spezifikationen und Versichertenkarten aus Sicht der Autoren der Expertise beschrieben. 7.1 Kompetenzen, Verantwortung und Absprachen Die Koordination und Zusammenarbeit zwischen den Versicherern untereinander sowie zwischen den Versicherern und dem EDI war unzureichend und führte zu den unterschiedlichen Spezifikationen und Umsetzungen der Versichertenkarte Aus Sicht EDI resp. BAG Gemäss Art. 2 Abs. 2 VVK müssen die von den Versicherern herausgegebenen Karten untereinander kompatibel sein. Die Festlegung der hierfür notwendigen technischen Einzelheiten, inklusive der Normen und Standards, wurde gemäss Art. 17 VVK an das EDI delegiert. Die [VVK-Erläuterung] zu Art. 17 [VVK] präzisieren, dass das EDI (resp. das BAG) die Vorgaben unter Einbezug der interessierten Kreise festlegen soll. Im Speziellen sollen die Normen und Standards auf Empfehlung einer Fachgruppe des Vereins ech festgelegt werden. ech 42 ist ein Verein im Sinn von Art. 60 ff. des Schweizerischen Zivilgesetzbuches mit dem Zweck zur Förderung von egovernment-standards. Problematisch hierbei war, dass die Empfehlung der Fachgruppe des Vereins ech direkt über [ech64] in die [VVK-EDI] eingeflossen sind. Das EDI hat somit die ihr gemäss Art. 17 VVK übertragene Verantwortung zur Regelung der technischen Standards 43 an einen Verein übertragen, auf den das EDI kaum mehr Einfluss hat. Eine neue Version von [ech64], welche allfällig festgestellte Fehler korrigiert oder Erweiterungen und Änderungen zum bestehenden Standard definiert, kann das EDI nur unter Einbezug des Vereins ech veranlassen. Alternativ hierzu könnte das EDI, unabhängig vom Verein ech, Korrekturen, Erweiterungen oder Änderungen über dedizierte Dokumente definieren. Dies führt aber zu mehreren lose gekoppelten Dokumenten und erschwert die Umsetzung der entsprechenden Vorgaben Aus Sicht der Versicherer Gemäss [VVK-Erläuterung] zu Abs. 2 [VVK] sorgen die Versicherer dafür, dass die von ihnen herausgegebenen Versichertenkarten untereinander kompatibel sind. Der Gesetzgeber hatte die Absicht, die Versicherer darauf zu verpflichten, die technische Umsetzung der Versicherungskarte auf der Basis des durch das EDI vorgegebenen Standards so zu gestalten, dass diese untereinander kompatibel sind. 42 Statuten vom 31. Oktober Erarbeitung und Weiterführung Seite 52/99
53 Da es sich bei [ech64] nicht um einen Implementationsstandard, sondern um einen Konzeptions-, Struktur- und Verfahrensstandard handelt (siehe Kapitel 4.1), mussten die Versicherer entsprechende Detailspezifikationen verfassen, welche eine Umsetzung der Versichertenkarte erst ermöglichen. Aufgrund der unterschiedlichen Spezifikationen und Umsetzung der Versichertenkarten muss davon ausgegangen werden, dass die Versicherer der Verpflichtung zur Wahrung der Kompatibilität nicht oder nur unzureichend nachgekommen sind und sich entsprechend unzureichend untereinander und mit dem EDI resp. mit dem BAG abgesprochen haben. 7.2 Technische Verfahren und Standards Die technischen Verfahren und Standards haben sich über die Dauer der Erarbeitung von [ech64] und den entsprechenden Detailspezifikationen [SPEC-POST] und [SPEC- SASIS] weiterentwickelt. Insbesondere haben sich die Eigenschaften und Kapazitäten der Chipkarte weiterentwickelt. [ech64] hatte zum Ziel, Minimalanforderungen festzulegen, die von möglichst vielen Kartenanbietern erfüllt werden können. Diese Minimalanforderungen hatten u.a. Einfluss auf die Festlegung der Zertifikatsstrukturen, Schlüssellängen und Padding- Verfahren. Die [SPEC-POST] beschreibt die in [ech64] definierten Verfahren und Standards im Zusammenhang mit den Zertifikatsstrukturen, Schlüssellängen und Padding-Verfahren, obwohl diese heute kaum mehr eingesetzt werden. Die [SPEC-SASIS] hingegen beschreibt Zertifikatsstrukturen, Schlüssellängen und Padding-Verfahren, die nicht in [ech64] enthalten sind, dafür aber in modernen Applikationen Einsatz finden. Die interdisziplinäre und organisationsübergreifende Erarbeitung von Standards und Spezifikationen, die fortwährenden technischen Weiterentwicklungen unterliegen und über einen längeren Zeitraum dauern, setzen eine klar definierte Projektorganisation voraus, die allfällige Änderungen oder Erweiterungen formell koordiniert und für verbindlich erklärt. Eine solche Projektorganisation fehlte oder agierte unzureichend. Seite 53/99
54 8 Empfehlungen für das weitere Vorgehen Die Ziele des Systems der Versichertenkarte sind gemäss [VVK-Erläuterung] folgend aufgeführt: Effiziente Administration durch Reduktion des administrativen Aufwandes bei der Abrechnung von Leistungen Verbesserung der medizinischen Qualität und Sicherheit der Versorgung mit der Möglichkeit, persönliche Daten auf der Versichertenkarte zu speichern Stärkung der Eigenverantwortung der Versicherten (Entscheid über Umfang und Verwendung der persönlichen Daten) Die zuvor genannten Ziele können mit den aktuell verfügbaren Versichertenkarten der Post und SASIS unter Verwendung einer geeigneten Middleware umgesetzt werden 44. Um die Nachhaltigkeit der Lösung sicherzustellen, sollten jedoch die Grundlagen im Zusammenhang mit den technischen Spezifikationen neu geregelt werden. 8.1 Allgemeine Empfehlungen TAV VVK-EDI Die Verantwortlichkeiten bez. der Definition der Anforderungen an das System der Versichertenkarte sollte neu geregelt werden. Das BAG hat die Möglichkeit, die Definitionen der Anforderungen als technische und administrative Vorschriften (TAV VVK-EDI) zu verfassen und über [VVK-EDI] zu referenzieren. Mit diesem Vorgehen sichert sich das BAG die alleinige Verantwortung über die Festlegung der technischen Anforderungen und kann allfällige Korrekturen, Änderungen oder Erweiterungen über ein ordentliches Vernehmlassungsverfahren einleiten. Die TAV VVK-EDI wird in enger Zusammenarbeit mit den jeweiligen Anbietern und Experten verfasst. Eine Fachgruppe des Vereins ech kann, wie in den [VVK- Erläuterung] festgelegt, entsprechende Empfehlungen einbringen. Es kann z.b. aus politischen Gründen sinnvoll sein, die Regelung nicht auf Stufe Amt sondern auf Stufe Departement vorzunehmen. In diesem Fall werden die Vorgaben nicht in eine TAV sondern in die VVK-EDI aufgenommen Testdaten und Referenzimplementation Die verwendeten Normen und Standards sind interpretierbar. Eine Referenzimplementation mit entsprechenden Testdaten soll sicherstellen, dass die einzelnen Spezifikationen und Umsetzungen der Versichertenkarten kompatibel zueinander im Sinne des Gesetzgebers sind. 44 Die nach Art. 2 Abs. 2 VVK geforderte Kompatibilität der Versichertenkarten im Sinne des Gesetzgebers ist aus Sicht der Autoren dieser Expertise jedoch nicht gegeben. Seite 54/99
55 Die Referenzimplementation sollte vom BAG übergeordnet als verbindlich erklärt werden und von einem unabhängigen Anbieter 45 im Auftrag der Versicherer im Sinne von Art. 2 Abs. 2 [VVK] bereitgestellt werden. Bevor eine Versichertenkarten oder eine HPC ausgerollt werden darf, muss sie die Testprozeduren der Referenzimplementation bestehen 46. Mit dem Einsatz einer Referenzimplementation werden die Versicherer in ihrer Verpflichtung unterstützt, die Kompatibilität der Versichertenkarten sicherzustellen. Hinweis Ein analoger Sachverhalt ist Zusammenhang mit ICAO-konformen Reisepässen gegeben. Das Golden Reader Tool 47 (GRT) ist eine Referenzanwendung zum Auslesen elektronischer Ausweisdokumente. Es wurde im Auftrag des BSI entwickelt und wird weltweit genutzt, um die richtige Umsetzung von Technischen Richtlinien und Spezifikationen bei der Erstellung von elektronischen Ausweisdokumenten nachzuprüfen und die Interoperabilität der Ausweisdokumente verschiedener Nationen nachzuweisen Public Key Infrastruktur Die PKI sollte so harmonisiert werden, dass ein spezifischer Leistungserbringer nur ein einzelnes Zertifikat auf seiner HPC benötigt. Die PKI soll bezüglich der Registrierung der Leistungserbringer und Verwaltung der Zertifikate möglichst flexibel gehalten werden. Folgend ist ein Beispiel aufgeführt, welches die zuvor genannten Anforderungen erfüllt. Root HPC Issuing CA LE 1 Issuing CA LE n Leistungserbringer Organisation 1 (Bsp. FMH) Leistungserbringer Organisation 2 (Bsp. Spital Y) Leistungserbringer Organisation n (Bsp. Spital X) Arzt x HPC LE1 Arzt y HPC LE2 HPC LEn Arzt z VK SASIS 1..n VK Post 1..n Alternative Modelle mit zusätzlichen CA-Hierarchien sind denkbar. Entscheidend ist, dass alle Versichertenkarten einen definierten öffentlichen Schlüssel speichern, über den die jeweiligen Leistungserbringer authentisiert und autorisiert werden können. 45 Der Anbieter sollte nicht an der Umsetzung oder Bereitstellung der Versichertenkarten teil haben 46 Formelle Abnahme des BAG 47 https://www.bsi.bund.de/de/themen/elektronischeausweise/projekte/projektegrt/grt_node.html Seite 55/99
56 8.2 Weiteres Vorgehen Die Aktivitäten für das weitere Vorgehen können so aufgeteilt werden, dass diese die Weiterentwicklung des bestehenden Systems sowie die Spezifikation des zukünftigen Systems gewährleisten. Die Arbeiten an den beiden Aktivitäten sollten parallel durchgeführt werden. Die zeitlichen Angaben sind grobe Abschätzungen und müssen mit den jeweiligen Anbietern abgesprochen werden. Die einzelnen Projektphasen müssen sorgfältig geplant und aufeinander abgestimmt werden. Entsprechende Verantwortlichkeiten und Meilensteine sind zu definieren Weiterentwicklung des bestehenden Systems Die Weiterentwicklung des bestehenden Systems hat zum Ziel, möglichst rasch verschiedene Fachapplikationen an das System anzubinden. So können praktische Erfahrungen im Umgang mit den Versichertenkarten im Zusammenhang mit Leistungserbringern und Leistungsempfängern gesammelt werden. Folgend ist ein möglicher zeitlicher Ablauf der Weiterentwicklung des bestehenden Systems aufgezeigt: Q KVG, VVK, VVK-EDI ech-0064 Detailspez Post Detailspez SASIS VK SASIS VK SASIS Middleware HPC Applikationen Komponente VK-Post VK-SASIS HPC Middleware Aktuell verfügbare Komponenten. Voraussetzung für die Interoperabilität ist eine Middleware, welche die unterschiedlichen technischen Umsetzungen der Versichertenkarten abstrahiert. Die Middleware sollte bis Ende 2011 definiert und umgesetzt werden können. a) Die Middleware kann eine einheitliche, anbieterunabhängige Schnittstelle definieren, welche durch das BAG in Zusammenarbeit mit den jeweiligen Anbietern vorgegeben wird. Hinweis Die anbieterunabhängige Schnittstelle könnte künftig als technische und administrative Vorschrift (TAV) verfasst werden und aus [VVK- EDI] referenziert werden. Seite 56/99
57 b) Die Middleware kann eine anbieterspezifische Schnittstelle definieren. Entscheidend hierbei ist, dass die Schnittstelle so weit wie möglich mit der jeweiligen Schnittstelle des zukünftigen Systems kompatibel ist. Dies ermöglicht eine einfache Migration auf zukünftige Versichertenkarten. Applikationen Die Fachapplikationen sprechen die Funktionalität der Versichertenkarte über die Middleware an. Die Middleware sollten bis Mitte 2012 in die Applikationen integriert werden können. Hinweis Anpassungen der geplanten Anpassung der VVK-EDI Die Fachapplikationen können Funktionalitäten der Versichertenkarten bis zur Einführung der zukünftigen Versichertenkarten nutzen. Abhängig von der Kompatibilität der Schnittstellen der zukünftigen Middleware bedarf es bei einer Migration auf die zukünftigen Versichertenkarten mehr oder weniger Anpassungen an der Fachapplikation. Am 9. August 2010 hat das BAG in einem Schreiben 48 die geplanten Änderungen an der [VVK-EDI] erläutert, welche am 1. November 2010 in Kraft hätten treten sollen 49. Bei den geplanten Anpassungen handelte sich in erster Linie um technische Einzelheiten, welche bei der Umsetzung der Vorgaben festgestellt wurden und an das BAG gemeldet worden sind. Grundsätzlich betreffen die Änderungen der [VVK-EDI] nur Dateninhalte, unabhängig von der technischen Struktur der Versichertenkarten. Es wäre aber vorab zu prüfen, ob die Daten unter den geänderten Vorgaben in den bisherigen Strukturen der Versichertenkarten abgelegt werden können. Da die [SPEC-POST] und die [SPEC- SASIS] transparente oder linear variable Datenfelder für die administrativen und medizinischen Daten definieren, ist zu untersuchen, ob für die neu definierten Daten ausreichend Speicherplatz auf der Karte zur Verfügung steht. Die geplanten Änderungen haben Einfluss auf die Middleware, welche die Kompatibilität der verschiedenen Versichertenkarten herstellen kann. Die Softwarehersteller müssten entsprechende Änderungen an der jeweiligen Middleware vornehmen. 48 [VVK-EDI-Änderung] 49 Die Änderungen wurden bis Ende 2010 nicht umgesetzt. Seite 57/99
58 8.2.2 Spezifikation des zukünftigen Systems Die Spezifikation des zukünftigen Systems hat zum Ziel, die technische Spezifikation und Umsetzung des Systems zu vereinheitlichen. Das zukünftige System soll im Jahr 2015 bereitstehen, um so die bestehenden Versichertenkarten im ordentlichen Austauschverfahren ersetzen zu können. Grundsätzlich kann das zukünftige System in zwei Varianten spezifiziert und umgesetzt werden Variante 1 TAV VVK-EDI In der Variante 1 werden die zukünftigen technischen Grundlagen überarbeitet und in der Form von technischen und administrativen Vorschriften (TAV VVK-EDI) als Anhang zu [VVK-EDI] verfasst. Der Umfang der Überarbeitung muss vom BAG in Absprache mit den Anbietern vorgegeben werden. Folgend ist ein möglicher zeitlicher Ablauf der Spezifikation des zukünftigen Systems aufgezeigt: Q KVG, VVK, VVK-EDI VVK-EDI 2 ech-0064 TAV VVK Detailspez 2 Post VK 2 SASIS Detailspez Post Detailspez SASIS Detailspez 2 SASIS Detailspez 2 HPC VK 2 SASIS HPC 2 Migration der VK Detailspez HPC Referenzimpl. Middleware 2 Applikationen Komponente [VVK] [VVK-EDI] [SPEC- POST] [SPEC- SASIS] [FMH-HPC] VVK-EDI 2 Aktuell verfügbare Komponenten. Verschiedene Datenstrukturen der [VVK-EDI] können aktualisiert oder erweitert werden. Idealerweise fliessen bereits Erkenntnisse in VVK- EDI 2 ein, welche im Zusammenhang mit Anwendungen der Fachapplikationen des bestehenden Systems gewonnen werden konnten. Die überarbeitete Verordnung sollte bis Ende 2012 fertiggestellt sein. Seite 58/99
59 TAV VVK- EDI Detailspez 2 SASIS Post HPC VK 2 SASIS Post HPC 2 Middleware 2 Die technischen Vorgaben aus [ech64] werden in enger Zusammenarbeit mit den jeweiligen Anbietern und Experten neu überarbeitet und als technische und administrative Vorschriften (TAV VVK-EDI) als Anhang zu [VVK-EDI] verfasst. Die neue TAV VVK-EDI sollte bis Ende 2012 fertiggestellt sein. Die jeweiligen Detailspezifikationen müssen der neu erarbeiteten TAV VVK-EDI angepasst werden. Diese sollten bis Ende 2013 fertiggestellt werden können. Die jeweiligen Umsetzungen der Versichertenkarten müssen den neuen Detailspezifikationen angepasst werden. Die Umsetzung sollte bis Mitte 2014 fertiggestellt werden können. Die Middleware bildet die Schnittstelle zwischen der Applikation und den Versichertenkarten. Die Umsetzung sollte bis Anfangs 2014 fertiggestellt werden können. Referenzimpl. Die Referenzimplementation stellt definierte Testprozesse bereit und sichert so die Interoperabilität der Versichertenkarten und der HPC. Bevor eine Versichertenkarten oder eine HPC ausgerollt werden darf, muss sie die Testprozeduren der Referenzimplementation bestehen. Die Umsetzung sollte bis Anfangs 2014 fertiggestellt werden können. Applikationen Die Fachapplikationen sprechen die Funktionalität der Versichertenkarte über die Middleware an. Die Middleware sollten bis Mitte 2015 in die Applikationen integriert werden können. Hinweis Variante 2 ech-0064 V2 Abhängig von der Kompatibilität der Schnittstellen zur bestehenden Middleware bedarf es bei einer Migration auf die zukünftigen Versichertenkarten mehr oder weniger Anpassungen an der Fachapplikation. In der Variante 2 wird der aktuelle [ech64] überarbeitet. Im speziellen werden Fehler oder interpretationswürdige Passagen von [ech64] in enger Zusammenarbeit mit den jeweiligen Anbietern und Experten aktualisiert und als neue Version des ech-0064 Standards veröffentlicht. Das BAG muss die Fachgruppe des Vereins ech neu einberufen und die Aktualisierung des Standrads veranlassen 50. Der Umfang der Überarbeitung muss vom BAG in Absprache mit den Anbietern vorgegeben werden. Folgend ist ein möglicher zeitlicher Ablauf der Spezifikation des zukünftigen Systems aufgezeigt: 50 Der Verweis auf ech-0064 in VVK-EDI muss ebenfalls aktualisiert werden. Seite 59/99
60 Q KVG, VVK, VVK-EDI VVK-EDI 2 ech-0064 ech Detailspez 2 Post VK 2 SASIS Detailspez Post Detailspez SASIS Detailspez 2 SASIS Detailspez 2 HPC VK 2 SASIS HPC 2 Migration der VK Detailspez HPC Referenzimplementation Middleware 2 Applikationen Komponente [VVK] [VVK-EDI] [SPEC-POST] [SPEC-SASIS] [FMH-HPC] VVK-EDI 2 ech-0064 V2 Detailspez 2 SASIS Post HPC VK 2 SASIS Post HPC 2 Middleware 2 Aktuell verfügbare Komponenten. Verschiedene Datenstrukturen der [VVK-EDI] können aktualisiert oder erweitert werden. Idealerweise fliessen bereits Erkenntnisse in VVK-EDI 2 ein, welche im Zusammenhang mit Anwendungen der Fachapplikationen des bestehenden Systems gewonnen werden konnten. Die überarbeitete Verordnung sollte bis Anfangs 2012 fertiggestellt sein. Die technischen Vorgaben aus [ech64] werden in enger Zusammenarbeit mit den jeweiligen Anbietern und Experten überarbeitet. Die Ergebnisse fliessen in eine neue Version von ech Die überarbeitete Version von ech-0064 sollte bis Anfangs 2012 fertiggestellt sein. Die jeweiligen Detailspezifikationen müssen der neu erarbeiteten TAV VVK-EDI angepasst werden. Diese sollten bis Ende 2012 fertiggestellt werden können. Die jeweiligen Umsetzungen der Versichertenkarten müssen den neuen Detailspezifikationen angepasst werden. Die Umsetzung sollte bis Mitte 2013 fertiggestellt werden können. Die Middleware bildet die Schnittstelle zwischen der Applikation und den Versichertenkarten. Die Umsetzung sollte bis Ende 2013 fertiggestellt werden können. Seite 60/99
61 Referenzimpl. Die Referenzimplementation stellt definierte Testprozesse bereit und sichert so die Interoperabilität der Versichertenkarten und der HPC. Bevor eine Versichertenkarten oder eine HPC ausgerollt werden darf, muss sie die Testprozeduren der Referenzimplementation bestehen. Die Umsetzung sollte bis Ende 2013 fertiggestellt werden können. Applikationen Die Fachapplikationen sprechen die Funktionalität der Versichertenkarte über die Middleware an. Die Middleware sollten bis Mitte 2014 in die Applikationen integriert werden können. Hinweis Abhängig von der Kompatibilität der Schnittstellen zur bestehenden Middleware bedarf es bei einer Migration auf die zukünftigen Versichertenkarten mehr oder weniger Anpassungen an der Fachapplikation. 9 Anhang 1: Hex-Dump der Versicherungskarten 9.1 VK-Post Die VK-Post spezifischen Analysen wurden mit der Versicherungskarte von Hans-Peter Muster durchgeführt. Sie wird auf Anfrage von Keyon für spezifische Analysen ausgehändigt. Seite 61/99
62 9.1.1 Hex-Dump Folgend ist der Hex-Dump der spezifizierten und öffentlich auslesbaren Files der VK- Post aufgeführt. Broadcom Corp Contacted SmartCard 0: 3bdb96ff8131fe bb42a000a VK Post SELECT response: ResponseAPDU: 2 bytes, SW=9000 EF.DIR 0x2f, 0x00 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ RECORD 1 response: ResponseAPDU: 12 bytes, SW= F 06 D a.o..v.!.. READ RECORD 2 response: ResponseAPDU: 18 bytes, SW= E 4F 0C A B D a.o...cpkcs-15 READ RECORD 3 response: ResponseAPDU: 17 bytes, SW= D 4F 0B F F F a.o..vpostotp.. READ RECORD 4 response: ResponseAPDU: 2 bytes, SW=6a83 EF.ATR 0x2f, 0x01 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 36 bytes, SW= E AF AF AF AF 66 0E 46 0C B 44 1B B f.F..DEG+D A 02.. EF.VERSION 0x2f, 0x10 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 6 bytes, SW= DSP. EF.ICCSN 0x2f, 0x05 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ RECORD 1 response: ResponseAPDU: 14 bytes, SW= A 0A Z..ui... READ RECORD 2 response: ResponseAPDU: 14 bytes, SW= i... READ RECORD 3 response: ResponseAPDU: 14 bytes, SW= A BZ... READ RECORD 4 response: ResponseAPDU: 2 bytes, SW=6a83 EF.ID 0x2f, 0x06 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 62 bytes, SW= A 80 1C 30 1A 30 0C 0C 0A E 73 2D 50 e: hans-p A C 06 4D eter0.0...muster D Seite 62/99
63 EF.AD 0x2f, 0x07 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 56 bytes, SW= C E e4..ch..helsana EF.PuK.CA_ROOT_VK 0x0e, 0x02 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 142 bytes, SW= A4 4D 1D 1C A8 8A 36 DE 97 BF M d A CE DB E3 3D A B =..* B BA E7 4E FC A0 15 AA 76 D9 7E 11 CB 9A 71 sk..n...v.~...q C A2 2E E1 B0 8F B A G..&...y.K C1 C4 77 E1 48 9D 4E D4 B2 FD w.H.NC.8...5yE C F0 FA E4 57 D6 45 0C A0 B0 9F D5 C#...W.E..( BD 14 ED 5F 78 B6 26 7B 2B FC 4F 14 F8 A5 6B..._x.&{+.O...k B E6 5D F7 9B 05 A8 F9 AC D9 07 6C AF 64 [.p.]...l.d B5 07 6A 7F j... EF.CVC.PDC 0x2f, 0x03 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 219 bytes, SW= F D5 5F F 00 BC 1D AC A7 F7.!.._ F C3 0E EF FB 4D A A1 ED D5 io...mp.c*d FF 5F EE 8A 3A 9D 97 8C C 71 D9 3B 38._..:...b...q.; CB 8B BD 0B 31 B1 B0 0B 0D 08 0D 42 7D CC..V..1...B} BD F9 EC 9E 6A 0C 9D 1F 9B BC 43 C C4 3C...j...C.D8.< ED FB 3B 5B 90 C1 C5 21 CC AD ;[...!..Pg E 78 4B 25 7A 6E 8E C1 E8 A F2 ~xk%zn.8!t...d E7 5A A0 B2 AC 5C D7 07 DB C Z...\...l)v( DC 03 3E C AE 5F A E4 FA..>6.Q,._8Ds A B 78 3B C A3 FE E1 A8 F6 45 7B JXG+x;.E<...E{ A0 98 AD 99 7C 2D B E C3 E2 14 E0 F3 F9 FC y B0 51 D8 D1 46 5E 83 F6 FE 6B A9 65 1E 5A FD 12 5E Q..F^...k.e.Z..^ C0 1D 8B 7E 8D 08 A E ~...1b..3...B D CHDSP`.. EF.CVC.CA_ROOT_VK (EF.CVC.CA_ORG_PDC) 0x2f, 0x04 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 219 bytes, SW= F D5 5F A A F 45.!.._7...S$zS..E BB BA DC EE D DA 71 D8 7F F5 AD 14 )...sp.q D6 11 5D AF 7A 90 BB C AF CF 5A 44..].z ZD B F7 F3 9A 3A 58 F C8 45 D8 F0 B :X.6"'.E...G F B4 2F B A9 56 D3 EC 94 5E C /...V...^.I B7 BD 12 DA 76 F1 40 4C 4B FB AF 78 CA 69 F ED 64 A2 5E C CE DA FD 59 B7 CB 48.d.^ Y..H F0 6D D8 EB B F EA 3A A7 F0 '..m...0.`h..: DE F BA AC 0A 5F D 4E phF..._8DH.NC D4 B2 FD C F0 FA E4 57 D yEC#...W.E A0 0C A0 B0 9F D5 18 BD 14 ED 5F 78 B6 26 7B..(..._x.&{ B0 2B FC 4F 14 F8 A5 6B 5B E6 5D F7 9B 05 A8 +.O...k[.p.] C0 F9 AC D9 07 6C AF 64 B5 07 6A 7F l.d..j...B D CHDSP`.. Seite 63/99
64 9.2 VK-SASIS Die VK-SASIS spezifischen Analysen wurden mit der Versicherungskarte von Markus Suter durchgeführt. Sie wird auf Anfrage von Keyon für spezifische Analysen ausgehändigt Hex-Dump Folgend ist der Hex-Dump der spezifizierten und öffentlich auslesbaren Files der VK- Post aufgeführt. Broadcom Corp Contacted SmartCard 0: 3b9f1381b180371f038031f8694d54434f VK SASIS SELECT response: ResponseAPDU: 2 bytes, SW=9000 EF.DIR 0x2f, 0x00 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 86 bytes, SW= F 06 D D a.o..v.!..p.emer E F 00 DF D 4F 0C A0 gencyq.?...a.o B D B 43...cPKCS-15P.PKC D F 00 DF F 0A F7 56 S-15Q.?...a.O..V B 74 4D B 74 4D !.KtMV.P.KtMVQ F 00 DF 03?... EF.ATR 0x2f, 0x01 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 45 bytes, SW= E E f.F..Inter D F E 31 MTCOS p 2.1 EF.VERSION 0x56, 0x00 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 6 bytes, SW= SAS. EF.ICCSN 0x2f, 0x05 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ RECORD 1 response: ResponseAPDU: 14 bytes, SW= A 0A Z..u` READ RECORD 2 response: ResponseAPDU: 10 bytes, SW= READ RECORD 3 response: ResponseAPDU: 15 bytes, SW= A Z READ RECORD 4 response: ResponseAPDU: 2 bytes, SW=6a83 EF.ID 0x2f, 0x06 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 86 bytes, SW= B 80 0D C 20 4D B 75 e+..suter, Marku D s Seite 64/99
65 EF.AD 0x2f, 0x07 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 97 bytes, SW= e1..ch..test EF.CVC.PDC 0x2f, 0x03 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 620 bytes, SW= F F 4E B 5F !..e.N..[_)..B CHSASb F I...`.t." BF 64 6D 4F B3 25 C A 3F 3E dmO.%..`.?>d E9 4B 66 C3 2E 5A 11 CB 57 7D E Kf..Z..W}.&.)p" D 04 E8 5D 6F 6E 06 4C BB AC 91 FD A8 37 5B %...]on.l...7[ AB A BD B EE CC F DB...i...#...P.r F 9C 8A 9B F A 1D DF E1 65 6F 68 DE...eoh DE 20 CA B3 A2 62 E6 96 DA A AB EA C8....b FA E0 7C BF E9 4B A2 9F 2A 4A 57 EC K..*JW A0 81 D3 18 E9 CA 59 C E6 AE 18 A0 BC...Y.w" B FA DC CD 15 A F3 4C 75 3A dC..Lu: C0 7E 96 C4 AD F8 8D 6F 11 A2 A6 B3 BB 85 0E FD 8C ~...o D0 ED 96 C7 B C A5 C7 EB F0 96 B1...3.L...Y E0 8E CD ED 3A 76 7A 74 CA BF AC 78 2A EC..8...:vzt...x* F0 60 4F C6 B E 72 5D 55 B8 E9 AB 8B F1 `O...REnr]U E FC AA 57 BD 1D C AE A E W w B C BB 5C 1F C9 94 3B A0 5E 4B 33 2E 8F k..r.\...;.^k BC BE 27 DE E4 EE 9E E9 1F 78 0C '...x.Q.7.X F 20 0A E..._..u` F 4C 0C L...`.t." F F S.._%..._$ F B 25 F0 34 B2 0D..._7...K% DD 9D 2B 0E FD 8A B B5 30 1E AC..+...U F6 0F CF DE C4 A7 63 6B A D CB CD...ck.!r FF B A9 72 A C B3 90 C1 EF..aQ..r.1Y A0 9D 09 A5 9C D2 42 AF AE 39 5D C0 9C 34 6A...e..B..9]..4j B0 5E 2E CF 46 2B CE CE 34 6B 3B 2F 3E 47 FF ^..D.F+..4k;/>G C D4 A7 94 AD 3C 3F 08 4D 4F F6 26 C2 7A 57.c...<?.MO.&.zW D0 2E 9E 2B E1 C2 DB 3A 05 FE CB 8D :..b...cs E0 9C B7 31 5D D4 28 C A6 61 4E D ].(.(..aN F0 1C F7 05 7B FD 34 5E 5C D6 4F A4 3D 79 D1...{.4^\.f.O.=y A B9 BE C F3 A9 59 6B 91 1F B J...p..Yk...B E F 7C AD F7 (.9.F...)Ft D 37 E8 2E CB 08 E3 67 AC DF F g...u'u? E D2 6B 0A 73 9D E B0 9E CD 07 B0 87..k.s.F.an E2 95 7E CB 78 C6 BC C2 E9 D2 D0 CC..~.x...6U AD D0 94 B6 70 F8 8D DB 9F 8F 5C FF 6E EE. R...p...\.n F8 9F 38 7F BE E1 21 6E !n8. Seite 65/99
66 EF.CVC.CA_ORG_PDC 0x2f, 0x08 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 626 bytes, SW= F B 7F 4E F !..k.N..a_)..B B CHRVK` F I...`.t." B4 8F 5D 36 DD A8 44 B B0 EB ED 0A...]6..D..B E1 C C7 B3 B0 E4 4F B B2 71 2B C1 C1 DF 1F 70 4A EE 4B F3 C6 53.q+...pJ.K...S E 39 DB D2 15 F0 D3 36 C7 4A 1A 2C 78 AC DF J.,x F D4 33 D1 8E 8E AD A3 7A E1 22 0D CD z." D 45 1F DC 0D 88 EB 05 5A 02 E7 B0 BA 63..-E...Z...c B 9C 08 3D C6 DF 28 D B C3 C4 70 r[..=..(.u.qk..p A0 9C D2 AB 30 B7 A4 8C E2 CD 7A 4F 3D Q!.A..zO= B A 47 A8 BD CA FE FF 1A H.`jG C0 BD 0B F1 A3 75 7D A8 0D B7 A4 DD FF...u}..b#...v D0 06 4F BA 19 E2 AB 3B 2E FF A D7 E6.O...;.6...i E0 92 9D 8E F8 BF C DC E C1 45 B9...F%.x9f..E F0 DD 8E 0F 69 C1 0D 3F E0 84 BC 3C A4 FF 4E BD 79...i..?...<..N.y F8 3F BC 5C CA D E3 2E 3E 02 2D 57.?.\.v&w...>.-W F1 05 C C3 74 F9 99 7F C4 DA A t...T A 17 0E A5 EA 36 1C 5B DA E5 8E 15 DD q...6.[...a B F ;..._.CHSASb F 4C 0C L...` F t."..S.._% F F _$..._ E F9 E3 1E AE A2 CB B0 A1 08 CC 86 CE.^...h B3 A AF 1B D D9 6E e0...XTW.x.n A EA 19 F7 AE D4 D FD Z W.7a A E 79 6F 3F C1 D6 B9 A5 EF 79 F7 AE 14 RhC~yo?...y B0 AA 16 BB 05 D0 51 E0 50 7D F1 1D 3F Q.P}..?hG C0 15 E4 A3 69 F2 42 F6 F BF B2 0F i.B..f3...1.c D0 72 A8 30 D2 70 FA B0 D3 B8 AB 96 9F 6C 09 BE 92 r.0.p...l E0 DC 70 C D8 FE C5 4E 32 E6 70 1B.p C.N2.p F0 F0 1F D8 02 B5 5C DB C1 19 C4 C3 87 F6 49 3B A6...\...I; A A9 DD 24 C6 D1 0D CE 89 4E D D7 38 F9 4C 63 C EC 87 B6 AF 22 CA Lc..a..."..f F 2A 26 EE DA E C4 52 F2 68 C0 CA /*&...d~.t.r.h B9 8C 39 F9 4C FD 55 AB 9E 73 E2 51 E3 F5 C8...9.L.U..s.Q F 4A A3 46 5A 96 D3 F BD C0 96 BC 07 F5 _J.FZ...p AD C2 A1 F0 3A E8 AD D6 91 FA F9 C0 45 a...:.. r...e A4 AF B 26 5B 11 B0 08 B7 80 A1 0B CB r..va+&[... EF.CVC.CA_ROOT_VK 0x2f, 0x04 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 626 bytes, SW= F B 7F 4E F !..k.N..a_)..B B CHRVK` F I...`.t." C4 40 0A F4 CE 1B FE 3F C6 93 CF A 73 F4 3B 6D 70 DE 29 3D 56 9F B8 32 3F A8 28 Js.;mp.)=V..2?.( D E 9F 67 FC F3 79 B a#n.g.5.(!.y.c C1 63 7F 1D D 6D 4F D1 57 EE 84.c..B.w.&mmO.W C 65 3F 6F 65 6A D7 51 7C D7 BB 6E 8F E8 AA D6 <e?oej.q..n F EB 41 B9 BF C 7B 8C 18 9E 48 E4 _.A..U`R4.{...H AF DB D FB CA EB 67 D9 52 E6 81 A1 E6 6...g.R A0 DD 5A B3 55 B2 D0 35 BE D 39 E7.Z.U..5.9y B0 BF 2F D DC E /..S.Fb.NbUw C0 28 C1 D7 3D B1 4D E5 59 4D D (..=.M#8.YMPa.V D E B4 04 EF 9A F 6.^...x.I#H"1.O E0 4A 5E E7 21 D9 19 0F CB 4E 3D E F J^.!...N=.E#? F0 3F F2 F9 48 3D FB AB E4 BC 5C 2D CF?..H='...4..\ E7 ED 60 3A D1 FC 1F E5 C4 9C 8E F 6B 6F..`:...ko D 98 9B 9B B9 CF A5 CF 5D 78 1C B...3..]x.A CB B1 D9 F3 ED 2F A 0A 9E /.VqV...aa B F F B 60 K..._.CHRVK` F 4C 0C L...` F t."..S.._% F F _$..._ D DD B6 C3 D0 D3 8C 98 2C BC 99 5E 9D ED -...,..^.f( B 09 FE 86 8E B2 4F 3C C4 41 5F 7B 71...r2..O<.A_{q A 4D E3 9B 53 EC BC 4D 6D 7C 14 1C BB M..S..Mm...R# A0 AA 61 3C E8 7C D C AF C6 9A D6.a<..x B0 7A 9B 02 3E 21 C4 90 D7 07 5D B 7E E1 A0 z..>!...]06;~ C0 D2 19 FF A 79 D1 F9 1F CD A8 F6 06 1F D5...&IJy D F B F9 BC DF 09 EE 12 C4 6A 1B 9B r.o..;...j E0 B6 A F 6B 54 C A 3C A6...OkT.9."...< F CC 81 E1 C9 47 3B A 67 DA 8B `R...G;'.:g..a AE A D6 D8 00 AD 47 9A 4D AD..1.D...G.M F 6A C1 B7 BD 2D 20 C DA 23 CF Ha _j # F1 E3 EF 94 D6 19 2F A6 CA 87 D E.../...a B D0 72 B5 8F AE 0C C3 31 BA 01 F2 ".{.r...# D BC E6 51 9D FC A1 CA m..q...#.s.$ F6 C2 3F 0B 0D E D0 ED 07 EF C AB..?..&u...p D3 99 F6 CA 78 9F 1C 79 0C 63 A pH...x..y.c..E Seite 66/99
67 EF.PuK.CA_ROOT_VK 0x00, 0x1c SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ RECORD response: ResponseAPDU: 301 bytes, SW= B CHRVK` C4 40 0A F4 CE 1B FE 3F CF 81 4A 73 F4 3B 6D 70 DE 29 3D 56 9F B Js.;mp.)=V F A D E 9F 67 FC F3?.(1-a#n.g.5.(! B1 63 C1 63 7F 1D D 6D 4F D1 y.c.c..b.w.&mmo EE 84 3C 65 3F 6F 65 6A D7 51 7C D7 BB 6E 8F W..<e?oej.Q..n E8 AA D6 5F EB 41 B9 BF C 7B 8C 18..._.A..U`R4.{ E 48 E4 36 AF DB D FB CA EB 67 D9 52 E6.H.6...g.R A1 E6 DD 5A B3 55 B2 D0 35 BE Z.U..5.9y A0 8D 39 E7 BF 2F D DC E /..S.Fb.NbUw B C1 D7 3D B1 4D E5 59 4D (..=.M#8.YMPa C0 D E B4 04 EF 9A V.6.^...x.I#H" D F 4A 5E E7 21 D9 19 0F CB 4E 3D E OJ^.!...N=.E# E0 3F F F2 F9 48 3D FB AB E4 BC?..?..H=' F0 5C 2D CF E7 ED 60 3A D1 FC 1F E5 C4 9C 8E \-...`: F 6B 6F 8D 98 9B 9B B9 CF A5 CF 5D 78 1C.ko...3..]x B 20 CB B1 D9 F3 ED 2F A 0A A...../.VqV E B F FA 46.aaK...F SELECT response: ResponseAPDU: 2 bytes, SW=9000 PKCS#15::EF.CIAInfo 0x50, 0x32 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 66 bytes, SW= D A =...u` C D 49 6E SASIS-Interca A0 16 0C rd `. PKCS#15::EF.GPKeys 0x1f, 0x01 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 186 bytes, SW= A 30 1B 0C E :0...Signature B B 74 4D Key KtMV B A1 0E F 00 DF ? C 0D E B Signature Key B A1 0E 30 0C F 00 DF ? A 0C F Authori A F 6E 20 4B zation Key B A A0 30 0C F 00 DF ? B PKCS#15::EF.CD 0x1f, 0x03 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 254 bytes, SW= F PKCS#15::EF.DCOD 0x1f, 0x04 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 102 bytes, SW= PKCS#15::EF.AOD 0x1f, 0x05 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 93 bytes, SW= F 30 0D 0C E C /0...PIN A C 00 0A C B (0...PUK A E 00 0A > PKCS#15::EF.CERT 0x1f, 0x06 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 2057 bytes, SW= Seite 67/99
68 PKCS#15:EF.PuK.X509 0x1f, 0x08 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 272 bytes, SW= A A3 67 C3 FD C4 A g B4 74 6E 6E E EE F6 33.tnnE7&n83E A0 AE E C C6 00 A7 47 C4 4D 1F 6A D (.<...G.M.j EE AC C6 CF 08 F7 87 C D0 92 4A 0C...7..#..J FE F4 A9 02 0F BE 65 4A 46 A D9 35 2F EB 6F B E C1 9F 4F E0.5/.o.S.~..O..t D 0A 5C DF BC 39 4E A 7C 2B A 16..\..9NYW. +g B1 64 A3 4E DC 02 DB A2 E1 A6 C0.d.Np4S CF 0D F9 BC E1 DD 38 B4 5C E B8 45 7A...8.\R...Ez A B7 F BF 43 E AB E4 az..u..3t.c.d A D D8 F7 42 7E 37 1E CE D7 7E.f.7]..B~7..2..~ B0 2C 5B 83 F F0 6A BB F7 3C,[..XE.ja.u..8.< C FD F ED 1D 18 s8..ag.ra.gdu D0 21 DA 3D EF B6 FD BD EF 06 8C E 5E 6C 67!.=...i.>^lg E0 E2 D2 CD EB B1 1E A2 AF 81 3F E1 E3 A8 8A 48 E0...?...H F0 3A BD 19 D4 FD 2F 9A 58 FD F2 F0 8B 38 4B EC F4 :.../.X...8K A F 03 B qo PKCS#15:EF.PuK.DEC 0x1f, 0x07 SELECT response: ResponseAPDU: 2 bytes, SW=9000 READ BINARY response: ResponseAPDU: 272 bytes, SW= A BC FE 20 EE s AD A A A B cw.fh..$e..0:.s& A A B0 75 1A E5 1A B0 C4 F6 9B 8F...u." FE 06 E1 EE E4 D5 77 DD BA E7 FB FC 2A 29 A9 )...w...*) D0 4C 8C ED 90 E DF BF CA FB CC 58 F7 44 EC C0 A5 22 FF E5.e..X.D...".uaP FC D9 A7 24 A3 B D FE 5A 38 DA 43..T..$..6...Z8.C F C3 C1 C0 B D 0A DE A6 63 O...v.-.CG.$d.c FE C4 F6 52 FC C A3 11 B3...R.!hh..< B3 2D A D0 C A0 30 0D C7 A0 5F !T.0..._I A0 D0 2D BC C7 DA 24 8B 21 B C1 0C 3B AA B0 0E DE DF E5 BD F0 D0 36 FC.x B C0 F1 E7 2E 72 BD AB DB F2 D7 AC...r.b..ybs D0 DF DE A8 AB C D8 D6 AA q...r% E0 8C 90 9C 62 AD 9F 3A B0 7B BD 4E F7 1C 81 4C 11...b..:.{.N...L F0 CF F2 7C F E5 0C %.....B3.v C 70 BD 7A AB D7 D p.z.F... Seite 68/99
69 10 Anhang 2: Analyse Dateisystem Folgend sind die EF spezifischen Angaben aus der [SPEC-POST] und [SPEC-SASIS] gegenübergestellt Definitionen Bezeichnung Bewertungen Geringfügige Abweichung Abweichung 10.2 Dateisystem [ech64] EF.DIR [ech64]::seite 20 [VVK-EDI]:: [ech64] [POST] [SASIS] Struktur Linear variable Linear variable Transparent Type Record Working Working AM AM SC AM SC AM SC R Read Record Always SELECT Always Update Record SK.Admin && SM.MAC READ BINARY Always Erase Record SK.Admin && SM.MAC Append Record SK.Admin && SM.MAC Delete EF Never FID 2F00 2F00 SFID 1E F0 Anz. Records 3 Max. 10 Records à max. 36 Bytes Record Grösse 200 Bytes 84 Bytes Wert Länge Wert Länge Wert Länge Record 1 [POST]::Seite 7, Kapitel 2.4 [SASIS]::Seite8, Kapitel 4.2 Seite 69/99
70 Record 2 Kommentar 1. Seite 70/99
E-Government-Standards Seite 1 von 62 ech-0064 - Spezifikationen für das System Versichertenkarte Name Standard-Nummer Kategorie Reifegrad Spezifikationen für das System Versichertenkarte ech-0064 Standard

References: Art. 42
 Art. 42
 Art. 42
 Art. 42
 Art. 2
 Art. 42
 Art. 2
 Art. 3
 Art. 13
 Art. 7
 Art. 2
 Art. 17
 Art. 17
 Art. 60
 Art. 17
 Art. 2
 Art. 2