Bestätigung von Produkten für qualifizierte elektronische Signaturen

Transkript

1 Bestätigung von Produkten für qualifizierte elektronische Signaturen gemäß 15 Abs. 7 S. 1, 17 Abs. 4 Gesetz über Rahmenbedingungen für elektronische Signaturen 1 und 11 Abs. 3 und 15 Signaturverordnung 2 Bundesamt für Sicherheit in der Informationstechnik 3 Godesberger Allee Bonn bestätigt hiermit gemäß 15 Abs. 7 S. 1, 17 Abs. 2 SigG sowie 11 Abs.3, 15 Abs. 2 und 4 SigV, dass die Digitale Signatur: Sichere Signaturerstellungseinheiten CardOS V5.0 with Application for QES, V1.0 den nachstehend genannten Anforderungen des SigG und der SigV entspricht. Die Dokumentation zu dieser Bestätigung ist registriert unter: BSI TE Bonn, den 31. Juli 2013 Im Auftrag Bernd Kowalski Abteilungspräsident Das Bundesamt für Sicherheit in der Informationstechnik ist auf Grundlage des Gesetz über das Bundesamt für Sicherheit in der Informationstechnik (BSI-Gesetz BSIG) vom 14. August 2009, Bundesgesetzblatt I S und gemäß der Veröffentlichung im Bundesanzeiger Nr. 31 vom 14. Februar 1998, Seite 1787, zur Erteilung von Bestätigungen für Produkte gemäß 15 Abs. 7 S. 1 (oder 17 Abs. 4) SigG ermächtigt. 1 Gesetz über die Rahmenbedingungen für elektronische Signaturen (Signaturgesetz - SigG) in der Fassung vom 16. Mai 2001 (BGBl. Jahrgang 2001 Teil I Nr. 22) zuletzt geändert durch Artikel 4 des Gesetzes vom 17. Juli 2009 (BGBl. I S. 2091) 2 Verordnung zur elektronischen Signatur (Signaturverordnung - SigV) in der Fassung vom 16. November 2001 (BGBl. Jahrgang 2001 Teil I Nr. 59) zuletzt geändert durch die Verordnung vom 15. November 2010 (BGBl. I S. 1542) 3 Bundesamt für Sicherheit in der Informationstechnik, Godesberger Allee , Bonn, Postfach , Bonn, Tel: +49(0) , Fax: +49(0) , bsi@bsi.bund.de, Web: Die Bestätigung zur Registrierungsnummer BSI TE besteht aus 17 Seiten.

2 Beschreibung des Produktes für qualifizierte elektronische Signaturen: Seite 2 von 17 Seiten 1 Handelsbezeichnung des Produktes und Lieferumfang Sichere Signaturerstellungseinheit CardOS V5.0 with Application for QES, V1.0 der Atos IT Solutions and Services GmbH. 1.1 Lieferumfang Die folgende Tabelle beschreibt den Auslieferungsumfang des Produktes: Nr Type Identifier Release Version Release Date Form of Delivery 1 Hardware (chip) SLE78CFX*P (M7892 B11) 4 M7892 B11 - IC package 2 Software CardOS for 240kByte flash C loaded in protected part of Flash EEPROM 3 Software CardOS for 300kByte flash C loaded in protected part of Flash EEPROM 4 Software CardOS for 404kByte flash C loaded in protected part of Flash EEPROM 5a Software RSA-library loaded in protected part of Flash EEPROM 5b Software Toolbox loaded in protected part of Flash EEPROM 5c Software SHA-2-library loaded in protected part of Flash EEPROM 6 Personalization script for QES Germany centralized model PersAppSigG.csf file 7 Pers. script for QES Germany centr. Model without PUK PersAppSigG_withoutPUK.csf file 8 Pers. script for QES Germany decentralized model, file system only (by Trust Center) Pre-PersAppSigG.csf file 4 The Begriff SLE78CFX*P steht für die drei Chipgrößen SLE78CFX2400P, SLE78CFX3000P oder SLE78CFX4000P

3 Nr Type Identifier Release Version Release Date Seite 3 von 17 Seiten Form of Delivery 9 Pers. script for QES Germany decentralized model, end user data + certificate (by RA) Post-PersAppSigG.csf file 10 Pers. script for QES Germany decentr. model, file model only (by TC), without PUK 11 Pers. script for QES Germany decentr. model, end user data + certificate (by RA), without PUK 12 Pers. script for QES similar to QES Germany decentr. model, file system only (by TC), for 4EP mass signature 13 Pers. script for QES similar to QES Germany decentr. model, end user data + certificate (by RA), for 4EP mass signature Pre-PersAppSigG_without PUK.csf Post-PersAppSigG_withou tpuk.csf Mass_Pre-PersAppSigG.c sf Mass_Post-PersAppSigG. csf file file file file 14 Constants definitions for RSA key pair, length 1976 bits, centr. and decentr. mode 15 Constants definitions for RSA key pair, length 2048 bits, centr. and decentr. model 16 Constants definitions for RSA key pair, length 2560 bits, centr. and decentr. model Defines_1976.csf file Defines_2048.csf file Defines_2560.csf file

4 Nr Type Identifier Release Version Release Date Seite 4 von 17 Seiten Form of Delivery 17 Constants definitions for RSA key pair, length 3072 bits, centr. and decentr. model 18 Constants definitions for RSA key pair, length 3584 bits, centr. and decentr. model 19 Constants definitions for RSA key pair, length 4096 bits, centr. and decentr. model Defines_3072.csf file Defines_3584.csf file Defines_4096.csf file 20 Service Package V50_ServicePack_Packag e.csf 21 Documentation User Guidance 'CardOS V5.0 with Application for QES V1.0' 22 Documentation CardOS V5.0 Package & Release Notes 23 Documentation Administrator Guidance 'CardOS V5.0 with Application for QES V1.0' 24 Documentation CardOS V5.0, User s Manual 25 Documentation Application Digital Signature 'CardOS V5.0 with Application for QES V1.0' file paper or PDF file - 03/2013 paper or PDF file paper or PDF file - 03/2013 paper or PDF file paper or PDF file Tabelle 1: Auslieferungsumfang Die Items Nr.1 bis Nr.5 werden als ein Gegenstand (IC Plattform mit Embedded Software) an das Trust Center geliefert, da die Embedded Software beim IC Hersteller Infineon in den Chip eingebracht wurde. Die Items Nr.2, Nr.3 und Nr.4 repräsentieren die Embedded Software Maske, die 3 verschiedene Chipgrößen unterstützt (SLE78CFX2400P mit 240 kbyte Flash Speicher, SLE78CFX3000P mit 300 kbyte Flash Speicher und SLE78CFX4000P mit 404kByte Flash Speicher. Der Flash Loader wird deaktiviert, bevor die Chips die Produktionsstätte von Infineon verlassen. Items Nummer Nr.6 bis Nr.11 und Nr.14 bis Nr.19 repräsentieren Scriptfiles, die für die Initialisierung und Personalisierung gemäß SigG erforderlich sind. Alle gelisteten Files werden an das Trust Center / Certification Authority (TC/CA) ausgeliefert. In der Administrator Guidance [8] (item Nr.23) ist deren Verwendung beschrieben.

5 Seite 5 von 17 Seiten Die Scripfiles Mass_Pre-PersAppSigG.csf und Mass_Post-PersAppSigG.csf (Tabelle 1 item Nr.12 und Nr.13) gehören zum Lieferumfang des Produktes, deren Verwendung ist jedoch nicht Gegenstand der Bestätigung nach SigG, d.h. sie dürfen nicht verwendet werden, wenn die Signaturkarte für den Einsatz nach SigG personalisiert werden soll. Diese Scriptfiles würden so genannte QES Two-PIN Signaturen für Massensignaturen nach dem 4-Augen-Prinzip ermöglichen entsprechend der Beschreibung im Adminstrator Handbuch. Diese Form der Massensignatur ist nach SigG nicht zulässig. Die Vorbereitung des Finalen Produktes kann auf zwei verschiedene Arten geschehen: nach einem dezentralisierten Modell und nach einem zentralisierten Modell. Zentralisiertes Modell: Initialisierung und Personalisierung finden beide im Trust Center statt. Dezentralisiertes Modell: Die Initialisierung findet im Trust Center statt. Die Personalisierung findet in einer Registration Authority satt, die räumlich vom Trust Center getrennt ist. Das TC/CA ist verantwortlich für Handhabung des Produktes (Hardware, Software und Dokumentation) derart, dass Vertraulichkeit, Integrität und Authentizität im Bereich des TC/CA gemäß der Benutzerhandbücher gewahrt sind. Bevor das Produkt zum Endanwender (Karteninhaber) gelangt, passiert es die folgenden logischen Einheiten, deren Arbeitsschritte in einer oder unterschiedlichen Organisationseinheiten durchgeführt werden können: Embedder (EMB): Initialisierung Certification Authority (CA): Schlüsselerzeugung Personalisierer (PERS): Personalisierung (Local) Registration Authority (LRA): Zertifikat Einbringung Alle diese Einheiten (EMB, CA, PERS, LRA) sind verpflichtet, die Sicherheitspolitik des TC/CA umzusetzen und die Eingangskontrollen und Annahmeprozeduren sicherzustellen, wie sie im Adminstrator Handbuch beschrieben sind. 1.2 Auslieferung des Produktes Das Trust Center / Certification Authority erhält die Chip Hardware mit der aufgebrachten Embedded Software (items Nr.1 - Nr.5) direkt per Kurier vom Chip Hersteller Infineon oder vom Atos Lager und erhält alle aufgelisteten Scriptfiles und die Dokumentation (Items Nr.6 bis Nr.25) vom Software Entwickler Atos IT Solutions and Services GmbH als signierte und verschlüsselte Files. Die Scriptfiles und die Dokumentation (items Nr.6 to Nr.25), die vom TC/CA ggf. den Organisationseinheiten EMB, CA, PERS, LRA zur Verfügung gestellt werden, werden signiert und verschlüsselt übermittelt. Die Auslieferung vom TC/CA zum Karteninhaber ist ebenfalls Gegenstand der Sicherheitspolitik des TC/CA. Der Software Entwickler hat zu keiner Zeit eine direkte Interaktion mit dem Karteninhaber. Die Auslieferung vom TC/CA zum Terminal Entwickler / Entwickler einer Signaturanwendungskomponente ist ebenfalls Gegenstand der Sicherheitspolitik des TC/CA. Die Dokumentation (item Nr.22 und Nr.24) wird signiert und verschlüsselt übermittelt.

6 1.3 Antragsteller dieser Bestätigung Atos IT Solutions and Services GmbH Otto-Hahn-Ring München Deutschland Seite 6 von 17 Seiten 1.4 Hersteller des Produkts Hersteller der Embedded Software, der Scriptfiles sowie der zugehörigen Dokumentation ist Atos IT Solutions and Services GmbH. Hersteller der Chiphardware ist Infineon AG. 2 Funktionsbeschreibung 2.1 Kurzbeschreibung Das Produkt ist eine Signaturerstellungseinheit bestehend aus dem Prozessorchip SLE78CFX*P (M7892 B11) und der Software CardOS V5.0 with Application for QES, V Funktionsbeschreibung des Produkts Die Signaturerstellungseinheit CardOS V5.0 with Application for QES, V1.0 ist in Form einer Smart-Card-Anwendung auf dem Betriebssystem CardOS V5.0 auf der Hardware-Plattform SLE78CFX*P (M7892 B11) lauffähig. CardOS V5.0 ist ein multifunktionales Smart-Card-Betriebssystem, das aktiven und passiven Datenschutz unterstützt. CardOS V5.0 ist konform zu ISO 7816 Teil 3, Teil 4, Teil 5, Teil 8 und Teil 9. Generelle Eigenschaften von CardOS V5.0: Läuft auf den Infineon-Chips des Typs SLE78CFX*P (M7892 B11): SLE78CFX2400P, SLE78CFX3000P oder SLE78CFX4000P. Der SLE78CFX*P (M7892 B11) Chip mit integriertem Security Controller für asymmetrische Kryptografie und echtem Zufallszahlengenerator wurde gemäß Stufe EAL5+ der Common Criteria nach dem Stand der Technik zertifiziert [7]. Alle Kommandos entsprechen den ISO , -8 und -9 Standards. PC/SC- und CT-API-fähig. Strukturierte Sicherheitsarchitektur und Schlüsselmanagement. Kunden- und anwendungsabhängige Konfigurierbarkeit der Kartendienste und -kommandos. Grundsätzliche Erweiterbarkeit des Betriebssystems durch ladbare Software-Komponenten / -Packages (Das Laden von Software-Komponenten / -Packages ist im bestätigten Produkt nicht möglich, da die Bestätigung sich auf eine bestimmte Konfiguration und Scriptfiles bezieht). Das Dateisystem: CardOS V5.0 bietet ein dynamisches und flexibles Dateisystem, das durch Chip-spezifische kryptografische Mechanismen geschützt wird: Beliebige Anzahl von Dateien (EFs, DFs), nur beschränkt durch die Speichergröße. Schachtelungstiefe von DFs nur durch die Speichergröße begrenzt. 5 The Begriff SLE78CFX*P steht für die drei Chipgrößen SLE78CFX2400P, SLE78CFX3000P oder SLE78CFX4000P

7 Seite 7 von 17 Seiten Dynamisches Speicher-Management für optimale Ausnutzung des verfügbaren Flash-EEPROMs. Schutz gegen EEPROM-Defekte und Spannungsverlust. Die o.g. Scriptfiles legen die für die Signaturerstellung relevanten Dateistrukturen fest. Zugriffskontrolle: Sicherheitsarchitektur Access Rule basiert gemäß ISO-Standard (Access Rules im erweiterten Format) Alle Schlüssel und PINs sind in so genannten "basic security objects" in den DFs gespeichert (keine reservierten File-IDs für Schlüssel- oder PIN-Files). Die Sicherheitsstruktur kann ohne Datenverlust nach dem Anlegen von Dateien noch inkrementell verfeinert werden. Kryptografische Dienste, die das Produkt Card OS bietet: Implementierte Algorithmen: RSA mit bis zu 4096 Bit Schlüssellänge (PKCS1_5 Padding, PSS Padding), ECC mit bis zu 512 bit Schlüssellänge, SHA-1, SHA-2, Triple-DES (CBC), DES (ECB,CBC), MAC, Retail-MAC, AES (CBC). Dabei sind nur die in Kapitel und 3.3 aufgeführten Algorithmen Teil der Prüfung im Hinblick auf diese Bestätigung nach SigG gewesen. Unterstützung von Command Chaining nach ISO 7816 Teil 4. Generierung asymmetrischer Schlüssel unter Verwendung des Zufallszahlengenerators der Chip-Plattform. Digitale Signaturfunktionen. Anschlussfähigkeit an externe Public Key Zertifizierungsdienste. Im Rahmen der qualifizierten Signatur sind die zu signierenden Daten zunächst extern zu hashen. Für das externe Hashen sind die Vorgaben in Abschnitt und 3.3 zu beachten. Alternativ können die Daten auch intern gehasht werden. Secure Messaging Funktionalität: nicht Teil des bestätigten Produktes. Die Einsatzumgebung muss den Schutz der Daten zwischen Signaturanwendungskomponente und Signaturerstellungseinheit sicherstellen) : 3 Erfüllung der Anforderungen des Signaturgesetzes und der Signaturverordnung 3.1 Erfüllte Anforderungen Das Produkt erfüllt die Anforderungen nach: SigG, 17, Abs. 1: (1) Für die Speicherung von Signaturschlüsseln sowie für die Erzeugung qualifizierter elektronischer Signaturen sind sichere Signaturerstellungseinheiten einzusetzen, die Fälschungen der Signaturen und Verfälschungen signierter Daten zuverlässig erkennbar machen und gegen unberechtigte Nutzung der Signaturschlüssel schützen. Werden die Signaturschlüssel auf einer sicheren Signaturerstellungseinheit selbst erzeugt, so gilt Absatz 3 Nr. 1 entsprechend. SigG, 17, Abs. 3, Satz 1: (3) Die technischen Komponenten für Zertifizierungsdienste müssen Vorkehrungen enthalten, um 1. bei Erzeugung und Übertragung von Signaturschlüsseln die Einmaligkeit und Geheimhaltung der Signaturschlüssel zu gewährleisten und eine Speicherung außerhalb der sicheren Signaturerstellungseinheit auszuschließen, [ ]

8 SigV, 15, Abs. 1: Seite 8 von 17 Seiten (1) Sichere Signaturerstellungseinheiten nach 17 Abs. 1 Satz 1 des Signaturgesetzes müssen gewährleisten, dass der Signaturschlüssel erst nach Identifikation des Inhabers durch Besitz und Wissen oder [...] angewendet werden kann. Der Signaturschlüssel darf nicht preisgegeben werden. [...] Die zur Erzeugung und Übertragung von Signaturschlüsseln erforderlichen technischen Komponenten nach 17 Abs. 1 Satz 2 oder Abs. 3 Nr. 1 des Signaturgesetzes müssen gewährleisten, dass aus einem Signaturprüfschlüssel oder einer Signatur nicht der Signaturschlüssel errechnet werden kann und die Signaturschlüssel nicht dupliziert werden können. SigV, 15, Abs. 4: (4) Sicherheitstechnische Veränderungen an technischen Komponenten nach den Absätzen 1 bis 3 müssen für den Nutzer erkennbar werden. 3.2 Einsatzbedingungen Für die SSEE (Sichere Signaturerstellungseinheit) CardOS V5.0 with Application for QES, V1.0 gelten die Anforderungen nach SigG und SigV unter der Voraussetzung, dass folgende Einsatzbedingungen gewährleistet sind, als erfüllt: Auflagen für den Initialisierer 1. Der Initialisierer muss die Hinweise, Auflagen und sonstigen Vorgaben in den Handbüchern [8] - [12] sowie im Zertifizierungsreport [17] beachten. Die mit der SSEE CardOS V5.0 with Application for QES, V1.0 an den Initialisierer ausgelieferten Handbücher sind auf Integrität und Authentizität zu prüfen. 2. Für den Initialisierungsprozess ist eine ausreichend sichere Umgebung mit geeigneten personellen, organisatorischen und technischen Sicherheitsmaßnahmen aufzusetzen. Hierfür muss insbesondere ein sicheres Key Management (insbesondere für Authentisierungsschlüssel) eingerichtet und die ausreichende Sicherung des Datentransfers innerhalb des Initialisierungsprozesses sichergestellt sein. Ausschließlich autorisiertes und erfahrenes Personal, das für die definierten Sicherheitsmaßnahmen ausreichend geschult ist, darf in den Initialisierungs- und Testaktivitäten eingesetzt werden. Das Sicherheitskonzept für die Initialisierung der SSEE CardOS V5.0 with Application for QES, V1.0 ist der Bundesnetzagentur vorzulegen. 3. Die durch Atos IT Solutions and Services GmbH ausgelieferten Initialisierungstabellen (Scriptfiles) sind auf sichere Art und Weise beim Initialisierer zu behandeln. 4. Der Initialisierer behandelt die Geheimnisse, mit denen er sich gegenüber der Chipkarte authentisiert und danach die Initialisierungstabelle laden kann, vertraulich. 5. Aus Sicherheitsgründen dürfen für den Initialisierungsprozess ausschließlich sichere, den unautorisierten Zugriff verhindernde Systeme, eingesetzt werden und auch nur innerhalb eines separaten Netzwerks. 6. Die Scripfiles Mass_Pre-PersAppSigG.csf und Mass_Post-PersAppSigG.csf (Tabelle 1 Nr. 12 und 13) gehören zum Lieferumfang des Produktes, sind jedoch nicht Gegenstand der Bestätigung nach SigG und dürfen daher nicht für die Initialisierung einer Signaturkarte nach SigG verwendet werden.

9 3.2.2 Auflagen für den Personalisierer Seite 9 von 17 Seiten 1. Der Personalisierer muss die Hinweise, Auflagen und sonstigen Vorgaben in den Handbüchern [8] - [12] sowie im Zertifizierungsreport [17] beachten. Die mit der SSEE CardOS V5.0 with Application for QES, V1.0 an den Personalisierer ausgelieferten Handbücher sind auf Integrität und Authentizität zu prüfen. 2. Für den Personalisierungsprozess ist eine ausreichend sichere Umgebung mit geeigneten personellen, organisatorischen und technischen Sicherheitsmaßnahmen aufzusetzen. Hierfür muss insbesondere ein sicheres Key Management (insbesondere für Authentisierungs- und Personalisierungsschlüssel) eingerichtet und die ausreichende Sicherung des Datentransfers innerhalb des Personalisierungsprozesses sichergestellt sein. Ausschließlich autorisiertes und erfahrenes Personal, das für die definierten Sicherheitsmaßnahmen ausreichend geschult ist, darf in den Personalisierungs- und Testaktivitäten eingesetzt werden. Das Sicherheitskonzept für die Personalisierung der SSEE CardOS V5.0 with Application for QES, V1.0 ist der Bundesnetzagentur vorzulegen. 3. Die Personalisierungsdaten sind auf sichere Art und Weise beim Personalisierer zu behandeln. Insbesondere sind Datenintegrität, -authentizität und -vertraulichkeit der Personalisierungsdaten sicherzustellen. 4. Der Personalisierer behandelt die Geheimnisse zu seiner Authentisierung gegenüber der Chipkarte, die nachfolgend die Personalisierung des Produktes ermöglicht, vertraulich. 5. Aus Sicherheitsgründen dürfen für den Personalisierungsprozess ausschließlich sichere, den unautorisierten Zugriff verhindernde Systeme, eingesetzt werden und auch nur innerhalb eines separaten Netzwerks. 6. Für die Personalisierung von Parametern für die Datenobjekte Signatur-PIN und PUK sind die Angaben in den Handbüchern [8] - [12] und im Zertifizierungsreport [17] zu berücksichtigen. 7. Das Produkt kann für unterschiedliche Anforderungen personalisiert werden (siehe auch [6]). Die Randbedingungen zur Erfüllung der Anforderungen aus SigG/SigV werden durch die Personalisierung gemäß den Vorgaben für QES-Germany erfüllt. Zur Auswahl von Parametern bei der Personalisierung wird auf die entsprechenden Tabellen 2 und 3 und die weiteren Vorgaben in Kapitel 5.1 der Administrator Guidance [8] besonders hingewiesen: Signatur-PIN: Die Mindestlänge m der Signatur-PIN muss größer oder gleich 6 gewählt werden. Der FBZ der Signatur-PIN darf maximal mit dem Wert m/2 (abgerundet) personalisiert werden und den Wert 20 nicht überschreiten. PUK (optional): Die Mindestlänge der PUK muss größer oder gleich 8 gewählt werden. Der Fehlbedienungszähler der PUK darf einen Maximalwert von 3 besitzen. Der Nutzungszähler NTZ (Usecount) kann nur so oft zur Entsperrung der PIN eingesetzt werden, wie NTZ (zulässige Werte im Bereich 15-60) angibt. Transport-PIN: Für die Transport-PIN ist die Länge mit 5 vorgegeben; dabei sind max. 3 Fehlversuche zulässig; der Mechanismus darf nur einmal (NTZ = 1) korrekt genutzt werden. 8. Bei den für SigG zulässigen Personalisierungsvarianten ist die Nutzung des PUK Letter Concept konfigurierbar. Dabei wird dem Karteninhaber auf separatem Wege (und unabhängig von anderen ausgelieferten Objekten) ein PUK-Brief zugestellt (gegen Empfangsbestätigung). Die darin enthaltene PUK kann zur

10 Seite 10 von 17 Seiten Entsperrung der Transport-PIN verwendet werden, wenn der Fehlbedienungszähler für die Transport-PIN abgelaufen ist. Eine erfolgreiche Entsperrung ist nur einmal möglich (NTZ = 1). Diese PUK ist in ihrer Funktion zu unterscheiden von der PUK, die der Karteninhaber nach korrekter Eingabe der Transport-PIN zur möglichen späteren Entsperrung seiner PIN festlegt; für letztere muss der Karteninhaber aus Sicherheitsgründen einen anderen Wert festlegen; der ausgebende ZDA ist gemäß den Vorgaben aus der User Guidance verpflichtet, den Karteninhaber hierauf explizit hinzuweisen Auflagen für den Zertifizierungsdiensteanbieter (ZDA) 1. Der öffentliche Signaturschlüssel (Signaturprüfschlüssel) ist nach seinem Export aus der Chipkarte vor und während der Erstellung des zugehörigen Signaturschlüsselzertifikats gegen Veränderungen zu schützen. Der Signaturprüfschlüssel muss eindeutig einer bestimmten SSEE CardOS V5.0 with Application for QES, V1.0 zugeordnet sein. 2. Die eingesetzte Zertifizierungskomponente zur Erzeugung von qualifizierten Zertifikaten (Certification Generation Application, CGA) hat die Sicherheitsanforderungen des Security Target [6], Kapitel (siehe A.CGA ) zu erfüllen. 3. Vor der Erstellung des qualifizierten Zertifikats muss sich der Zertifizierungsdiensteanbieter (ZDA) von der Integrität und Authentizität des Signaturprüfschlüssels überzeugen. 4. Zur Erstellung des qualifizierten Zertifikats muss der ZDA die Identität des Kartenempfängers bzw. Signaturschlüssel-Inhabers gemäß den gesetzlichen Vorgaben überprüfen. 5. Der ZDA muss sicherstellen, dass die Eignung der verwendeten Schlüssellänge (1976 bis 4096 Bit) und des vorgesehenen Padding-Verfahrens bis zum Ende der Laufzeit des qualifizierten Signaturschlüsselzertifikats gegeben ist. Hierzu ist jeweils der aktuelle Algorithmenkatalog der Bundesnetzagentur [16] heranzuziehen. 6. Die kryptographischen Schlüssel, die zur Administration der SSEE CardOS V5.0 with Application for QES, V1.0 berechtigen, sind sicher und vertraulich zu behandeln. Hierbei sind die Regelungen aus dem Sicherheitskonzept des ZDA, das der Bundesnetzagentur vorzulegen ist, einzuhalten. 7. Der ZDA hat den Signaturschlüssel-Inhaber über bestätigte Kartenterminals und Signaturanwendungskomponenten, die für die Erzeugung von qualifizierten elektronischen Signaturen eingesetzt werden können, zu unterrichten. 8. Anwendungsprogramme, die ein ZDA seinen Kunden i.s.v. 5 Abs. 1 Satz 2 SigV zur Übertragung von Authentisierungsdaten zur SSEE CardOS V5.0 with Application for QES, V1.0 zur Verfügung stellt (d.h. mit denen der Signaturschlüssel-Inhaber seine Signatur-PIN eingeben, setzen bzw. ändern kann), müssen derart voreingestellt sein, dass die Eingabe der Authentisierungsdaten standardmäßig über die Tastatur des Chipkartenlesers erfolgen muss. Für den Fall, dass das Anwendungsprogramm optional die Deaktivierung der Tastatur des Chipkartenlesers erlaubt und stattdessen die PC-Tastatur zur Eingabe vorsieht, muss das Programm beim Wechsel auf diese Eingabeart einen Warnhinweis auf den damit verbundenen möglichen Sicherheitsverlust anzeigen.

11 3.2.4 Auflagen für den Kartenherausgeber Seite 11 von 17 Seiten 1. Der Herausgeber der SSEE CardOS V5.0 with Application for QES, V1.0 informiert den Empfänger des Produktes gemäß der Vorgaben und Anforderungen aus den Benutzerhandbüchern [8] - [12] und dem Zertifizierungsreport [17] sowie sonstiger Vorgaben, Anforderungen und Hinweise, die sich aus der Personalisierung des Produktes sowie von Seiten des Zertifizierungsdiensteanbieters (ZDA) ergeben. Dabei unterscheidet der Herausgeber zwischen Anwendungsentwicklern, welche die SSEE CardOS V5.0 with Application for QES, V1.0 in ihre Applikation einbinden wollen, und Signaturschlüssel-Inhabern, welche die Signaturapplikation als Endanwender nutzen. 2. Falls nach einmaliger Eingabe der Signatur-PIN mit der SSEE CardOS V5.0 with Application for QES, V1.0 mehrere Signaturen erstellt werden können, informiert der Herausgeber der SSEE CardOS V5.0 with Application for QES, V1.0 den Endanwender entsprechend den Informationen und Auflagen im Sicherheitskonzept des ZDA. 3. Die Übermittlung der Transport-PIN und der PUK der Signaturkarte an den Karteninhaber erfolgt auf gesichertem Weg. 4. Der Kartenherausgeber muss in seinem Sicherheitsrisikomanagement in Abstimmung mit dem ZDA berücksichtigen, dass sich Angriffsmethoden auf Signaturerstellungseinheiten und auf Signaturanwendungskomponenten mit dem Stand der Technik weiterentwickeln. Daher sollte er unabhängig von der formalen Gültigkeitsdauer dieser Bestätigung ein Überprüfungsintervall festlegen in dem die Vertrauenswürdigkeit des Produktes nach dem jeweils aktuellen Stand der Technik überprüft wird Allgemeine Auflagen für den Signaturschlüssel-Inhaber (Endanwender) Nachfolgend werden die Auflagen genannt, die vom Signaturschlüssel-Inhaber bei der Nutzung der Signatur-Applikation der SSEE CardOS V5.0 with Application for QES, V1.0 mindestens zu beachten sind. Darüber hinaus sind die Auflagen, Vorgaben und Hinweise relevant, die der Herausgeber der Signaturkarte dem Signaturschlüssel-Inhaber mitteilt. 1. Der Signaturschlüssel-Inhaber muss die Signatur-PIN sowie die Transport-PIN gegen Kompromittierung schützen. Er darf die Signatur-PIN und die Transport-PIN anderen Personen nicht mitteilen und muss die zuvor genannten Authentisierungsdaten ausreichend sicher verwahren. Entsprechendes gilt für die der Signatur-PIN zugeordnete PUK. 2. Der Karteninhaber muss zum Ersetzen der Transport-PIN durch eine echte PIN sowie zum Wechseln der PIN einen bestätigten Chipkartenleser mit sicherer PIN-Eingabe verwenden. 3. Der Signaturschlüssel-Inhaber muss mittels der Transport-PIN überprüfen, dass noch keine Signatur-PIN gesetzt ist und lediglich das Setzen der Signatur-PIN möglich ist. Der Signaturschlüssel-Inhaber muss dazu verifizieren, dass die fünfstellige Transport-PIN noch gültig ist. Hierzu setzt der Signaturschlüssel-Inhaber unter Verwendung der Transport-PIN eine neue, von ihm selbst gewählte Signatur-PIN, die über eine Mindestlänge von sechs Ziffern verfügt. Ist die Transport-PIN nicht gültig oder hat diese nicht genau fünf Stellen, so muss sich der Signaturschlüssel-Inhaber mit dem Kartenherausgeber in Verbindung setzen. 6 Zu Überprüfung der Vertrauenswürdigkeit eines bestätigten Produktes kann der Hersteller (hier Atos IT Solutions and Services GmbH) beim BSI einen entsprechenden Antrag auf Wiederholungsprüfung im Rahmen einer Nachtragsbestätigung stellen.

12 Seite 12 von 17 Seiten 4. Der Signaturschlüssel-Inhaber muss seine Signatur-PIN in regelmäßigen Abständen und dann, wenn er eine Kompromittierung vermutet, wechseln. 5. Der Signaturschlüssel-Inhaber ist verantwortlich für den Wechsel der Transport-PIN zur Signatur-PIN und für die Wahl einer zufälligen und geheimen Signatur-PIN, deren Mindestlänge 6 Ziffern beträgt. 6. Der Signaturschlüssel-Inhaber muss die SSEE CardOS V5.0 with Application for QES, V1.0 so behandeln und aufbewahren, dass Missbrauch und Manipulation vorgebeugt werden. 7. Zur Erstellung qualifizierter elektronischer Signaturen sollen ausschließlich vertrauenswürdige Signaturanwendungskomponenten verwendet werden, die gemäß 15 Abs. 7 Satz 1 oder 17 Abs. 4 Satz 1 SigG von einer Bestätigungsstelle bestätigt worden sind. Bestätigte Signaturanwendungskomponenten werden auf den Internetseiten der Bundesnetzagentur ( aufgeführt. Zusätzlich sind folgende Punkte zu berücksichtigen: - Ordnungsgemäße Installation der Signaturanwendungskomponenten und Einhaltung der vorgesehenen Einsatzumgebung gemäß der Sicherheitshinweise in den zugehörigen Handbüchern und Bestätigungen. - Regelmäßige Überprüfung der Integrität der Signaturanwendungskomponenten und der zugrunde liegenden Plattform (Hardware und Betriebssystem). - Schutz der IT-Plattform vor Schadsoftware. - Vertrauenswürdige Sicherheitsadministration. - Vertrauenswürdige Netzinfrastruktur, falls der Einsatz der SSEE in einem IT-Netz erfolgt. - Vertrauenswürdige Anbindung an externe Kommunikationsnetze, falls die SSEE in einem IT-Netz mit Anbindung an externe Kommunikationsschnittstellen eingesetzt wird. Der Hersteller einer Signaturanwendungskomponente zur Erzeugung von qualifizierten elektronischen Signaturen (Signature Creation Application, SCA) hat die Sicherheitsanforderungen des Security Targets [6], Kapitel (siehe A.SCA ) zu berücksichtigen. 8. Der Signaturschlüssel-Inhaber muss überprüfen, dass die Umgebung, in der die Signaturkarte genutzt wird, ausreichend bzgl. Vertraulichkeit und Integrität der Authentisierungsdaten (z.b. der Signatur-PIN, PUK) sowie bzgl. Integrität der zu signierenden Daten abgesichert ist, da das Produkt dies in der bestätigten Konfiguration nicht unterstützt. Der ZDA sollte den Signaturschlüssel-Inhaber darauf hinweisen, dass dieser bei Zweifeln an der ausreichenden Sicherheit seiner Einsatzumgebung oder dem Verdacht der Kompromittierung des Signaturschlüssels den ZDA oder die Bundesnetzagentur kontaktieren möge Auflagen zur Nutzung des Signaturbegrenzungszählers Die Signatur-Applikation der SSEE CardOS V5.0 with Application for QES, V1.0 verwaltet einen sog. Signaturbegrenzungszähler. Im Rahmen der Personalisierung des Produktes wird festgelegt, wie viele Signaturen n nach einmaliger Eingabe der Signatur-PIN erstellt werden können; die Anzahl n stellt dabei den Wert des Signaturbegrenzungszählers dar. Das Produkt CardOS V5.0 with Application for QES, V1.0 bietet bei der Personalisierung gemäß SigG/SigV ( QES-Germany ) mehrere Personalisierungsvarianten an, von denen eine unter Berücksichtigung der jeweiligen Auflagen ausgewählt werden muss: A) Eine PIN, Einzelsignatur (i) Es gibt eine PIN mit dem dazugehörigen Signaturbegrenzungs-

13 zähler n=1. Die Berechtigung erlischt nach genau einer Signatur. Seite 13 von 17 Seiten der Generierung von B) Eine PIN, Massensignatur (ii) Es gibt eine PIN mit dem dazugehörigen Signaturbegrenzungszähler n zwischen 2 und 254. Die Berechtigung erlischt nach der Generierung von n Signaturen. oder (iii) Es gibt eine PIN, der dazugehörige Signaturbegrenzungszähler ist unendlich. Es ist eine unbegrenzte Anzahl von Signaturen bezogen auf eine einzelne erfolgreiche PIN-Verifikation möglich. Eine Anzahl n für den Signaturbegrenzungszähler größer als 1 ist nur unter den folgenden Bedingungen zulässig: 1. Der Zertifizierungsdiensteanbieter (ZDA) ist verpflichtet, den Antragsteller über die besonderen Sicherheitsanforderungen für die Einsatzumgebung der SSEE CardOS V5.0 with Application for QES, V1.0 mit mehrfacher Signaturerzeugungsmöglichkeit (sog. Multisignatur-SSEE) im Rahmen des 6 Abs. 1 SigG zu unterrichten. Die Unterrichtung muss vor Ausstellung des qualifizierten Zertifikats erfolgen und soll die besonderen Sicherheitsanforderungen, die sich aus dem hohen Angriffspotential ergeben, im Einzelnen auflisten. Insbesondere, jedoch nicht ausschließlich, sind alle Sicherheitsanforderungen an die Umgebung anzugeben, die in der Bestätigung genannt sind. 2. Die Einsatzumgebung muss durch den Signaturschlüssel-Inhaber unter Berücksichtigung der vorliegenden Gegebenheiten und des geplanten Einsatzzweckes physisch und logisch so abgesichert werden, dass ein Missbrauch der Signaturfunktionalität der Signaturkarte als Multisignatur-SSEE und die Ausspähung der zugehörigen Identifikationsdaten (Signatur-PIN, PUK) durch Angreifer mit hohem Angriffspotential praktisch ausgeschlossen sind und damit die alleinige Kontrolle des Signaturschlüssel-Inhabers über den Prozess der Signaturerzeugung gegeben ist. Der ZDA ist verpflichtet, mindestens eine Einsatzumgebung anzugeben, die diese Anforderungen erfüllt. 3. Zu den physischen Sicherungsmaßnahmen gehört der physikalische Schutz gegen unbefugten Zugriff auf die SSEE CardOS V5.0 with Application for QES, V1.0, insbesondere bei einem unbeaufsichtigten Betrieb. In der Unterrichtung des ZDA gemäß 6 Abs. 2 SigG soll in diesem Zusammenhang auf die Zurechnung der qualifizierten elektronischen Signaturen besonders hingewiesen werden. 4. Die SSEE erlaubt in der Variante (iii) eine unbegrenzte Anzahl an Signaturen. In diesen Fällen muss die SAK die Anzahl der durchgeführten Signaturen auf eine angemessene Anzahl oder eine angemessene Zeit begrenzen. 5. Der ZDA sollte den Signaturschlüssel-Inhaber einer Multisignatur-SSEE darauf hinweisen, dass er bei Zweifeln an der ausreichenden Sicherheit seiner Einsatzumgebung eine anerkannte Prüf- oder Bestätigungsstelle gemäß 18 SigG kontaktieren möge Auflagen für den Entwickler und Hersteller von Signaturanwendungskomponenten 1. Der Hersteller einer Signaturanwendungskomponente hat die Funktionalität und Schnittstellen des Chipkarten-Betriebssystems CardOS V5.0 sowie der Signatur-Applikation der SSEE CardOS V5.0 with Application for QES, V1.0 zu berücksichtigen.

14 Seite 14 von 17 Seiten 2. Bei der Erzeugung einer qualifizierten Signatur mit Übergabe eines extern berechneten Hashwertes an die SSEE CardOS V5.0 with Application for QES, V1.0 ist durch die Signaturanwendungskomponente die Verwendung einer durch die Karte unterstützten Hashfunktion sicherzustellen. Der Hersteller einer Signaturanwendungskomponente zur Erzeugung von qualifizierten elektronischen Signaturen (Signature Creation Application, SCA) hat die Sicherheitsanforderungen des Security Targets [6], Kapitel (siehe A.SCA ) zu berücksichtigen Einsatzbedingungen für das externe Hashen Zu signierende Daten werden extern durch eine sicherheitsbestätigte oder herstellererklärte SAK (Anwendung, Funktionsbibliothek) gehasht. Beim externen Hashen dürfen die Algorithmen SHA-224, SHA-256, SHA-512/256, SHA-384 und SHA-512 verwendet werden. Beim externen Hashen sind die Vorgaben des Herstellers aus Abschnitt 5.3 Specification of the Application Digital Signature for QES der User Guidance [9] einzuhalten. Dabei kann der Algorithmus SHA-224 bis Ende 2015, SHA-256 bis SHA-512 bis Ende 2019 eingesetzt werden (siehe [16]) Einsatzbedingungen für das interne Hashen Die zu signierenden Daten können alternativ auch intern gehasht werden. Beim internen Hashen dürfen die Algorithmen SHA-256, SHA-384 und SHA-512 verwendet werden. Beim internen Hashen sind die Vorgaben des Herstellers aus Abschnitt 5.3 Specification of the Application Digital Signature for QES der User Guidanc e [9] einzuhalten. Dabei kann der Algorithmus SHA-256 bis SHA-512 bis Ende 2019 eingesetzt werden (siehe [16]). 3.3 Algorithmen und zugehörige Parameter Die SSEE CardOS V5.0 with Application for QES, V1.0 unterstützt zur Erstellung von elektronischen Signaturen den RSA-Algorithmus mit einer Bitlänge zwischen 1976 und 4096 Bit. Das Padding-Verfahren ist kompatibel zu EMSA-PSS und EMSA-PKCS1-v1_5 BT 1 gemäß Standard PKCS1 [18], Kapitel 9. Die Hashwertberechnung erfolgt extern und das Ergebnis wird in die SSEE importiert. Alternativ kann die Hashberechnung auch in der SSEE erfolgen. Dabei muss die Hashwertberechnung jeweils gemäß den Bestimmungen aus dem Algorithmenkatalog der Bundesnetzagentur [16] und Kap ablaufen. Für die Erzeugung von Zufallszahlen zur Generierung von RSA-Signaturschlüsselpaaren wird in der SSEE CardOS V5.0 with Application for QES, V1.0 der durch den zugrunde liegenden Prozessorchip [7] zur Verfügung gestellte Hardware-Zufallszahlengenerator verwendet. Dieser Zufallszahlengenerator ist ein Generator der Klasse PTG.2 im Sinne der Anforderungen des BSI gemäß AIS 31. Die gezogenen Zufallszahlen werden im laufenden Betrieb geeigneten statistischen Tests unterzogen ( Onlinetests ). Gemäß der Veröffentlichung der Bundesnetzagentur sind die in der SSEE CardOS V5.0 with Application for QES, V1.0 verwendeten kryptographischen Algorithmen als geeignet einzustufen, sofern zulässige Schlüssellängen verwendet werden. Hierbei sind die folgenden zeitlichen Randbedingungen zu beachten: Schlüssellänge RSA 1976 Bit (Mindestwert) Ende 2019 RSA 2048 Bit (Empfehlung) Ende 2019 Einsetzbar bis

15 Seite 15 von 17 Seiten Tabelle 3: Zulässige Schlüssellängen für qualifizierte elektronische Signaturen Für RSA-Signaturen ist dabei das Formatierungsverfahren EMSA-PKCS1-v1_5 BT 1 gemäß Standard PKCS1 [18], Kapitel 9.2 nur noch bis Ende 2015 geeignet, und es wird empfohlen, dieses nicht mehr über Ende 2014 hinaus zu verwenden. 3.4 Prüfstufe und Mechanismenstärke Das Produkt SSEE CardOS V5.0 with Application for QES, V1.0 wurde erfolgreich nach den Common Criteria (CC) Version 3.1 R3 mit der Prüfstufe EAL 4+ (EAL 4 mit dem Zusatz AVA_VAN.5 (gegen ein hohes Angriffspotenzial)) den Anforderungen aus SigG und SigV folgend evaluiert. Zusätzlich zu dieser Bestätigung wurde das Produkt CardOS V5.0 with Application for QES, V1.0 nach den Common Criteria unter der Zertifizierungskennung BSI-DSZ-CC beim BSI zertifiziert [17]. Die Evaluierung und Zertifizierung des Produktes CardOS V5.0 with Application for QES, V1.0 wurde in Form einer sog. Kompositionsevaluierung durchgeführt, die die Evaluierungs- und Zertifizierungsergebnisse der CC Evaluierung und Zertifizierung des zugrunde liegenden Halbleiters wiederverwendet. Diese Evaluierung und Zertifizierung des Halbleiters erfolgte beim BSI unter der Zertifizierungskennung BSI-DSZ-CC (und dem Maintenance-Verfahren BSI-DSZ-CC MA-01) mit der Prüfstufe EAL 5+ (EAL 5 mit den Ergänzungen AVA_VAN.5 und ALC_DVS.2). Die für eine SSEE nach SigV maßgebende Evaluierungsstufe EAL 4+ (mit Ergänzung AVA_VAN.5) und die Prüfung gegen ein hohes Angriffspotenzial sind damit erreicht. Die Sicherheitsaussage dieser Bestätigung basiert auf dem Ergebnis der genannten Evaluierung und Zertifizierung. 3.5 Gültigkeit der Bestätigung Diese Bestätigung ist gültig bis bedingt durch die Begrenzung der Einsetzbarkeit der Algorithmen gemäß [16]. Die Gültigkeit der Bestätigung des Produktes kann verlängert werden, wenn zu dem zuvor genannten Ablaufzeitpunkt keine Hinderungsgründe hinsichtlich der Sicherheit des Produktes oder der Eignung der verwendeten kryptographischen Algorithmen und Parameter vorliegen. Ergeben sich innerhalb der Laufzeit der Bestätigung neue Feststellungen hinsichtlich der Sicherheit des Produktes oder der Eignung der verwendeten kryptographischen Algorithmen und Parameter, so kann die Gültigkeit der Bestätigung des Produktes verkürzt werden. 4 Literaturverzeichnis [1] Common Criteria for Information Technology Security Evaluation, Version 3.1, Part 1: Introduction and general model, Revision 3, July 2009 Part 2: Security functional components, Revision 3, July 2009 Part 3: Security assurance components, Revision 3, July 2009 [2] Common Methodology for Information Technology Security Evaluation (CEM), Evaluation Methodology, Version 3.1, Rev. 3, July 2009 [3] BSI certification: Procedural Description (BSI 7125) [4] Application Notes and Interpretations of the Scheme (AIS) as relevant for the TOE 7 7 specifically

16 Seite 16 von 17 Seiten [5] German IT Security Certificates (BSI 7148), periodically updated list, published also on the BSI Website [6] Security Target BSI-DSZ-CC , Rev. 2.00, Edition 03/2013, , Security Target 'CardOS V5.0 with Application for QES V1.0', Atos IT Solutions and Services GmbH [7] Certification Report BSI-DSZ-CC for Infineon Security Controller M7892 A21 with optional RSA2048/4096 v , EC v , SHA-2 v1.01 and Toolbox v libraries and with specific IC dedicated software (firmware) from Infineon Technologies AG Assurance Continuity Maintenance Report, BSI-DSZ-CC MA-01, Infineon Security Controller M7892 B11 with optional RSA2048/4096 v , EC v , SHA-2 v1.01 and Toolbox v libraries and with specific IC dedicated software (firmware) from Infineon Technologies AG [8] Administrator Guidance 'CardOS V5.0 with Application for QES V1.0', Rev. 1.30, Edition 03/2013, Atos IT Solutions and Services GmbH, (confidential document) [9] User Guidance 'CardOS V5.0 with Application for QES V1.0', Rev. 1.40, Edition 03/2013, Atos IT Solutions and Services GmbH, (confidential document) [10] CardOS V5.0 User's Manual, Edition 03/2013, Atos IT Solutions and Services GmbH, (confidential document) [11] CardOS V5.0 Package & Release Notes, Edition 03/2013, Atos IT Solutions and Services GmbH, (confidential document) [12] Application Digital Signature 'CardOS V5.0 with Application for QES V1.0', Rev. 1.10, Edition 03/2013, Atos IT Solutions and Services GmbH, (confidential document) [13] Directive 1999/93/ec of the European parliament and of the council of 13 December 1999 on a Community framework for electronic signatures [14] Gesetz über die Rahmenbedingungen für elektronische Signaturen (Signaturgesetz - SigG) in der Fassung vom 16. Mai 2001 (BGBl. Jahrgang 2001 Teil I Nr. 22) zuletzt geändert durch Artikel 4 des Gesetzes vom 17. Juli 2009 (BGBl. I S. 2091) [15] Verordnung zur elektronischen Signatur (Signaturverordnung - SigV) in der Fassung vom 16. November 2001 (BGBl. Jahrgang 2001 Teil I Nr. 59) zuletzt geändert durch die Verordnung vom 15. November 2010 (BGBl. I S. 1542) [16] Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung (Übersicht über geeignete Algorithmen), Vom 20. Februar 2013, Veröffentlicht am 27. März 2013 im Bundesanzeiger, Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen AIS 25, Version 7, Anwendung der CC auf Integrierte Schaltungen including JIL Document and CC Supporting Document AIS 26, Version 8, Evaluationsmethodologie für in Hardware integrierte Schaltungen including JIL Document and CC Supporting Document AIS 31, Version 2.1, Funktionalitätsklassen und Evaluationsmethodologie für physikalische Zufallszahlengeneratoren AIS 32, Version 7, CC-Interpretationen im deutschen Zertifizierungsschema AIS 34, Version 3, Evaluation Methodology for CC Assurance Classes for EAL5+ (CCv2.3 & CCv3.1) and EAL6 (CCv3.1) AIS 36, Version 3, Kompositionsevaluierung including JIL Document and CC Supporting Document AIS 38, Version 2.9, Reuse of evaluation results

17 Seite 17 von 17 Seiten [17] Zertifizierungsreport für CardOS V5.0 with Application for QES, V1.0 der Atos IT Solutions and Services GmbH, Zertifizierungs-ID BSI-DSZ-CC , , Bundesamt für Sicherheit in der Informationstechnik (BSI) [18] PKCS1 v2.1: RSA Cryptographic Standard, RSA Laboratories, Version 2.1, Ende der Bestätigung