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 Signaturerstellungseinheit Secure Signature Creation Device (SSCD) CardOS V4.4 with Application for QES, Version 1.01 den nachstehend genannten Anforderungen des SigG und der SigV entspricht. Die Dokumentation zu dieser Bestätigung ist registriert unter: BSI TE Bonn, den 15. Juli 2011 Im Auftrag Bernd Kowalski Abteilungspräsident Das Bundesamt für Sicherheit in der Informationstechnik ist auf Grundlage des Gesetzes ü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 15 Seiten.

2 Beschreibung des Produktes für qualifizierte elektronische Signaturen Seite 2 von 15 Seiten 1 Handelsbezeichnung des Produktes und Lieferumfang Signaturerstellungseinheit CardOS V4.4 with Application for QES, Version 1.01 der Atos IT Solutions and Services GmbH. 1.1 Auslieferung Die verschiedenen Stufen und Wege der Auslieferung des EVG und die Abläufe der Initialisierung und Personalisierung sind im Dokument CardOS 4.4 (CNS) and CardOS DI V4.2C CNS, Life-cycle support [13] in englischer Sprache detailliert beschrieben. Das Dokument enthält die folgenden Kapitel: Delivery to the Chip Manufacturer, Delivery to the Trust Center / Certification Authority, General processing chain, Delivery to the Card Holder, Delivery to the Terminal Developer. 1.2 Antragsteller dieser Bestätigung sowie Hersteller und Vertreiber des Produkts Atos IT Solutions and Services GmbH Otto-Hahn-Ring München Deutschland 1.3 Lieferumfang des Produktes Die folgende Tabelle beschreibt den Auslieferungsumfang des Produktes: Nr Typ Beschreibung Version, Datum Auslieferungsart 1 Software (Operating System) CardOS V4.4 C80D, Software in der Chipkarte 2 V4.4 Software Application, Digital Signature (Application / Data Structure) Centralized Model: PersAppSigG.CSF PersAppSigG_withoutPUK.CSF De-Centralized Model: Skripte zum Laden der Datenstrukturen Pre-PersAppSigG.CSF Post-PersAppSigG.CSF Pre-PersAppSigG_withoutPUK.CSF Post-PersAppSigG_withoutPUK.CSF Mass_Pre-PersAppSigG.CSF Mass_Post-PersAppSigG.CSF

3 Seite 3 von 15 Seiten Nr Typ Beschreibung Version, Datum Auslieferungsart Both Models: Defines_1024.csf #5(*), Defines_1280.csf #5(*), Defines_1536.csf #5(*), Defines_1792.csf #5(*), Defines_2048.csf #5(*), Service Package (mandatory) Service Package 03h 04h 13h 02h C8h 0Dh(**) Skripte zum Laden der Datenstrukturen Software Verify_RC Package (mandatory) 5 Software SHA-2 Package (optional) Verify_RC Package SHA-2 Package 03h 04h 02h 01h C8h 0Dh(**) h 04h 05h 03h C8h 0Dh(**) Documentation CardOS V4.2B User s Manual 1.0, 09/2005 Papier/PDF 7 Documentation CardOS V4.4 Packages & Release Notes 2.0, 07/ Admin Documentation 9 User Documentation 10 ADS Documentation CardOS V4.4 Administrator Guidance 0.60, 07/2011 CardOS V4.4 User Guidance 0.60, 07/2011 CardOS V4.4 ADS_Description 0.60, 07/ Hardware (Chip) Infineon SLE66CX680PE m1534-a14 (Dresden) Chipkarte 12 Firmware RMS RMS RMS V2.5 Software in der Chipkarte 13 Software crypto library RSA2048 crypto library Version 1.5 Software in der Chipkarte 14 Firmware STS Self Test Software V55.0B.07 Software in der Chipkarte Tabelle 1: Auslieferungsumfang (*) Last two characters of entry %VERSION% (**) PID (package ID) containing package version 2 Funktionsbeschreibung 2.1 Kurzbeschreibung Das Produkt ist eine Signaturerstellungseinheit bestehend aus dem Prozessorchip Infineon SLE66CX680PE und der Software CardOS V4.4 with Application for QES, Version 1.01.

4 Seite 4 von 15 Seiten 2.2 Funktionsbeschreibung des Produkts 4 Die Signaturerstellungseinheit CardOS V4.4 with Application for QES, Version 1.01 ist in Form einer Smart-Card Anwendung auf dem Betriebssystem CardOS V4.4 auf der Hardware-Plattform SLE66CX680PE lauffähig. CardOS V4.4 ist ein multifunktionales Smart-Card-Betriebssystem, das aktiven und passiven Datenschutz unterstützt. CardOS V4.4 ist konform zu ISO 7816 Teil 3, Teil 4, Teil 5, Teil 8 und Teil 9. CardOS V4.4 with Application for QES, Version 1.01 wurde entwickelt, um den Anforderungen des deutschen Signaturgesetzes zu genügen. Generelle Eigenschaften von CardOS V4.4: Läuft auf den Infineon-Chips des Typs SLE66CX680PE. Der SLE66CX680PE Chip mit integriertem Security Controller für asymmetrische Kryptografie und echtem Zufallszahlengenerator wurde erfolgreich gemäß Stufe EAL5+ der Common Criteria nach dem Stand der Technik zertifiziert. Alle Kommandos entsprechen den ISO , -8 und -9 Standards. PC/SC- und CT-API-fähig. Sicherheitsarchitektur und Schlüsselmanagement sind klar strukturiert. Kunden- und anwendungsabhängige Konfigurierbarkeit der Kartendienste und -kommandos. Erweiterbarkeit des Betriebssystems durch ladbare Software-Komponenten / -Packages. Das Dateisystem: CardOS V4.4 bietet ein dynamisches und flexibles Dateisystem, das durch Chipspezifische kryptografische Mechanismen geschützt wird: Beliebige Anzahl von Dateien (EFs, DFs), beschränkt durch die Speichergröße. Schachtelungstiefe von DFs nur durch die Speichergröße begrenzt. Dynamisches Speicher-Management für optimale Ausnutzung des verfügbaren EEPROMs. Schutz gegen EEPROM-Defekte und Spannungsverlust. Zugriffskontrolle: Bis zu 126 verschiedene vom Programmierer definierbare Zugriffsrechte. Zugriffsrechte können mit beliebig komplexen Booleschen Ausdrücken kombiniert werden. Jedes Daten-Objekt kann mit eigenem Zugriffsschema geschützt werden. Alle Sicherheitstests und Schlüssel 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: Implementierte Algorithmen: RSA mit bis zu 2048 Bit Schlüssellänge (PKCS#1 Padding), SHA-1, SHA-2 (optionales Package), Triple-DES (CBC), DES (ECB, 4 Die nachfolgende Beschreibung ist vom Hersteller bereitgestellt und von der Bestätigungsstelle nur geringfügig angepasst worden.

5 Seite 5 von 15 Seiten CBC), MAC, Retail-MAC. 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. Schutz gegen Differential Fault Analysis ( Bellcore-Attack ). Schutz von DES und RSA gegen Simple Power Analysis and Differential Power Analysis. Unterstützung von Command Chaining nach ISO 7816 Teil 4. Generierung asymmetrischer Schlüssel unter Verwendung des onboard Zufallszahlengenerators. Digitale Signaturfunktionen on chip. 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. Secure Messaging: Kompatibel mit ISO Unabhängig definierbar für Kombination aus Zugriffsart und Datenobjekt. 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, [ ] SigV, 15, Abs. 1: (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

6 Seite 6 von 15 Seiten 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 V4.4 with Application for QES, Version 1.01 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]-[13]) 5 sowie im Zertifizierungsreport [17] beachten. Die mit der SSEE CardOS V4.4 with Application for QES, Version 1.01 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 V4.4 with Application for QES, Version 1.01 ist der Bundesnetzagentur vorzulegen. 3. Die durch Atos IT Solutions and Services GmbH ausgelieferten Initialisierungstabellen 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 Auflagen für den Personalisierer 1. Der Personalisierer muss die Hinweise, Auflagen und sonstigen Vorgaben in den Handbüchern [8] - [13] 6 sowie im Zertifizierungsreport [17] beachten. Die mit der SSEE CardOS V4.4 with Application for QES, Version 1.01 an den Personalisierer ausgelieferten Handbücher sind auf Integrität und Authentizität zu prüfen. 5 Hinweis: Die Handbücher wurden gegenüber dem in BSI-DSZ-CC zertifizierten Stand aktualisiert. Es sind explizit die hier referenzierten Versionen zu verwenden. 6 Hinweis: Die Handbücher wurden gegenüber dem in BSI-DSZ-CC zertifizierten Stand aktualisiert. Es sind explizit die hier referenzierten Versionen zu verwenden.

7 Seite 7 von 15 Seiten 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 V4.4 with Application for QES, Version 1.01 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 globale PUK sind die Angaben in den Handbüchern [8] bis [13] und im Zertifizierungsreport [17] zu berücksichtigen. 7. Zur Auswahl von Parametern bei der Personalisierung wird auf die Tabellen /-2 der Administrator Guidance [8] besonders hingewiesen. Da das Produkt aber eine sehr variable Einstellung der Parameter ermöglicht, sind folgende Randbedingungen zur Erfüllung der Anforderungen aus SigG/SigV umzusetzen: 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 Personalisierungsvarianten A und B (siehe Kap ) 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 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

8 Seite 8 von 15 Seiten 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 V4.4 with Application for QES, Version 1.01 zugeordnet sein. 2. Die eingesetzte Zertifizierungskomponente zur Erzeugung von qualifizierten Zertifikaten (Certification Generation Application, CGA) hat die Sicherheitsanforderungen des Security Target [6], Kapitel 3.1 (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 (1024 bis 2048 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 V4.4 with Application for QES, Version 1.01 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 V4.4 with Application for QES, Version 1.01 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 Auflagen an den Kartenherausgeber 1. Der Herausgeber der SSEE CardOS V4.4 with Application for QES, Version 1.01 informiert den Empfänger des Produktes gemäß der Vorgaben und

9 Seite 9 von 15 Seiten Anforderungen aus den Benutzerhandbüchern [8] - [13] 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 V4.4 with Application for QES, Version 1.01 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 V4.4 with Application for QES, Version 1.01 mehrere Signaturen erstellt werden können, informiert der Herausgeber der SSEE CardOS V4.4 with Application for QES, Version 1.01 den Endanwender entsprechend den Informationen und Auflagen im Sicherheitskonzept des ZDA. 3. Die Übermittlung der Transport-PIN und der globalen PUK der Signaturkarte an den Karteninhaber erfolgt auf gesichertem Weg 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 V4.4 with Application for QES, Version 1.01 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. 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 V4.4 with Application for QES, Version 1.01 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

10 Seite 10 von 15 Seiten 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 3.1 (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. Der ZDA sollte den Signaturschlüssel-Inhaber darauf hinweisen, dass dieser bei Zweifeln an der ausreichenden Sicherheit seiner Einsatzumgebung eine anerkannte Prüf- und Bestätigungsstelle gemäß 18 SigG kontaktieren möge Auflagen zur Nutzung des Signaturbegrenzungszählers Die Signatur-Applikation der SSEE CardOS V4.4 with Application for QES, Version 1.01 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 V4.4 with Application for QES, Version 1.01 bietet 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 Signaturbegrenzungszähler n=1. Die Berechtigung erlischt nach der Generierung von genau einer Signatur. 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. C. Zwei PINs, Massensignatur (iv) Es gibt zwei verschiedene PINs, die jeweils unterschiedlichen Personen

11 Seite 11 von 15 Seiten zugeordnet sind, um ein 4-Augen-Prinzip sicherzustellen. In dieser Konfiguration erlischt die Berechtigung zur Generierung von Signaturen im gleichen Sicherheitskontext nicht. Diese Variante wird vom Entwickler Two PIN -Modus genannt. Die Verwendung dieser Variante ist nicht Gegenstand dieser Bestätigung nach SigG! 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 V4.4 with Application for QES, Version 1.01 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 V4.4 with Application for QES, Version 1.01, 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 den Varianten (iii) und (iv) 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. Die Verwendung von Variante (iv) ist nicht Gegenstand dieser Bestätigung nach SigG! 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- und 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 V4.4 sowie der Signatur-Applikation der SSEE CardOS V4.4 with Application for QES, Version 1.01 zu berücksichtigen.

12 Seite 12 von 15 Seiten 2. Bei der Erzeugung einer qualifizierten Signatur mit Übergabe eines extern berechneten Hashwertes an die SSEE CardOS V4.4 with Application for QES, Version 1.01 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 3.1 (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 können die Algorithmen SHA-224, SHA-256, SHA-384 und SHA-512 verwendet werden. Dabei sind die folgenden Vorgaben zu beachten: 1. Beim externen Hashen sind die Vorgaben des Herstellers aus Abschnitt Specification of the SigG Digital Signature Application for QES der User Guidance [9] einzuhalten. Dabei kann der Algorithmus SHA-224 bis Ende 2015, SHA-256 bis SHA-512 bis Ende 2017 eingesetzt werden (siehe [16]). 2. Bei der Personalisierung der SSEE bestehen grundsätzlich die beiden Möglichkeiten - ein DSI-Objekt auf der SSEE anzulegen, mit dem ein bestimmtes zulässiges Hashverfahren (s. Abschnitt 2) festgelegt wird (nur dieses darf dann beim externen Hashen verwendet werden), oder - kein DSI-Objekt anzulegen und bei jedem Signiervorgang den zu signierenden Daten einen DigestInfo voranzustellen, mit dem der OID für das angewendete (zulässige) Hashverfahren übermittelt wird. 3.3 Algorithmen und zugehörige Parameter Die SSEE CardOS V4.4 with Application for QES, Version 1.01 unterstützt zur Erstellung von elektronischen Signaturen den RSA-Algorithmus mit einer Bitlänge zwischen 1024 und 2048 Bit. Das Padding-Verfahren ist kompatibel zu SSA- PKCS#1-v1_5 BT 1 gemäß Standard PKCS#1 [18], Kapitel 9.2. Die Hashwertberechnung erfolgt extern und das Ergebnis wird in die SSEE importiert. Dabei muss die Hashwertberechnung 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 V4.4 with Application for QES, Version 1.01 der durch den zugrundeliegenden Prozessorchip [7] zur Verfügung gestellte Hardware-Zufallszahlengenerator verwendet. Dieser Zufallszahlengenerator ist ein P2-Generator der Stärke hoch 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 V4.4 with Application for QES, Version 1.01 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 (Mindestwert) Einsetzbar bis RSA 1976 Bit Ende 2017

13 Seite 13 von 15 Seiten Tabelle 3: Zulässige Schlüssellängen für qualifizierte elektronische Signaturen Für RSA-Signaturen ist dabei das Formatierungsverfahren SSA-PKCS#1-v1_5 BT 1 gemäß Standard PKCS#1 [18], Kapitel 9.2 nur noch bis Ende 2014 geeignet, und es wird empfohlen, dieses nicht mehr über Ende 2013 hinaus zu verwenden. 3.4 Prüfstufe und Mechanismenstärke Das Produkt SSEE CardOS V4.4 with Application for QES, Version 1.01 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 V4.4 with Application for QES, Version 1.01 nach den Common Criteria unter der Zertifizierungskennung BSI- DSZ-CC beim BSI zertifiziert [17]. Nach Erteilung des Zertifikates erfolgte eine nicht sicherheitsrelevante Änderung am Produkt und an den Handbüchern, die in dieser Bestätigung berücksichtigt wurden. Dazu hat der Antragsteller einen Bericht zur Erläuterung und Auswirkung der Änderungen (Impactanalyse-Bericht [19]) und die zugehörigen Nachweise bereitgestellt. Die Änderungen betreffen ein neues Service Package, Änderungen in Handbüchern und Änderung des Herstellernamens und wurden als nicht sicherheitskritisch eingestuft. Die Evaluierung und Zertifizierung des Produktes CardOS V4.4 with Application for QES, Version 1.01 wurde in Form einer sog. Composition Evaluation durchgeführt, die die Evaluierungs- und Zertifizierungsergebnisse der CC Evaluierung und Zertifizierung des zugrundeliegenden Halbleiters wiederverwendet. Diese Evaluierung und Zertifizierung des Halbleiters erfolgte beim BSI unter der Zertifizierungskennung BSI-DSZ-CC mit der Prüfstufe EAL 5+ (EAL 5 mit den Augmentierungen AVA_VLA.4 (gegen ein hohes Angriffspotential), AVA_MSU.3 (vollständige Missbrauchsanalyse) und ALC_DVS.2 (ausreichende Sicherheitsmaßnahmen)). Die für eine SSEE nach SigV maßgebende Evaluierungsstufe EAL 4+ (mit Augmentierung 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 und der Begutachtung der o.g. nachfolgenden nicht sicherheitsrelevanten Änderungen. Diese Bestätigung ist gültig bis Ergeben sich innerhalb der Laufzeit der Bestätigung neue Feststellungen hinsichtlich der Sicherheit des Produktes oder der Eignung der verwendeten 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 1, September 2006 Part 2: Security functional components, Revision 2, September 2007 Part 3: Security assurance components, Revision 2, September 2007 [2] Common Methodology for Information Technology Security Evaluation (CEM), Evaluation Methodology, Version 3.1, Rev. 2, September 2007 [3] BSI certification: Procedural Description (BSI 7125) [4] Application Notes and Interpretations of the Scheme (AIS) as relevant for the TOE 7 7 specifically

14 Seite 14 von 15 Seiten [5] German IT Security Certificates (BSI 7148), periodically updated list, published also on the BSI Website [6] Security Target, CardOS V4.4 with Application for QES, Atos IT Solutions and Services GmbH, Version 0.70, Edition 07/2011, [7] Certification report for SLE66CX680PE / m1534-a14, SLE66CX360PE / m1536- a14, SLE66CX482PE / m1577-a14, SLE66CX480PE / m1565-a14, SLE66CX182PE / m1564-a14, all optional with RSA2048 V1.5 and all with specific IC dedicated software, from Infineon Technologies AG, Certification ID BSI-DSZ-CC , , Bundesamt für Sicherheit in der Informationstechnik (BSI) aktualisiert durch Neubewertung vom [8] CardOS V4.4, Administrator Guidance, Edition 07/2011, Version 0.60, Atos IT Solutions and Services GmbH, [9] CardOS V4.4, User Guidance, Edition 07/2011, Version 0.60, Atos IT Solutions and Services GmbH, [10] Sequences of the personalisation scripts, Atos IT Solutions and Services GmbH, CardOS V4.4 SigG Personalization scripts dated [11] User s Manual CardOS V4.2B, release 09/2005, Siemens AG, [12] CardOS V4.4, Package & Release Notes, Atos IT Solutions and Services GmbH, Edition 07/2011, [13] CardOS 4.4 (CNS) and CardOS DI V4.2C CNS, Life-cycle support, Atos IT Solutions and Services GmbH, Version 0.50, Edition 07/2011, [14] Directive 1999/93/ec of the European parliament and of the council of 13 December 1999 on a Community framework for electronic signatures 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) 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) [15] CardOS V4.4, ADS Description, Edition 07/2011, Version 0.60, Atos IT Solutions and Services GmbH, [16] Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung (Übersicht über geeignete Algorithmen) vom 20. Mai 2011 (Veröffentlicht am 07. Juni 2011 im Bundesanzeiger Nr. 85, Seite 2034), Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen AIS 25, Version 6, 7 September 2009, Anwendung der CC auf Integrierte Schaltungen including JIL Document and CC Supporting Document AIS 26, Version 7, 3 August 2010, Evaluationsmethodologie für in Hardware integrierte Schaltungen including JIL Document and CC Supporting Document AIS 31, Version 1, 25 Sept Funktionalitätsklassen und Evaluationsmethodologie für physikalische Zufallszahlengeneratoren AIS 32, Version 6, 3 August 2010, CC-Interpretationen im deutschen Zertifizierungsschema AIS 34, Version 2, 24 October 2008, Evaluation Methodology for CC Assurance Classes for EAL5+ (CCv2.3 & CCv3.1) and EAL6 (CCv3.1) AIS 36, Version 3, 19 October 2010, Kompositionsevaluierung including JIL Document and CC Supporting Document AIS 38, Version 2.0, 28 September 2007, Reuse of evaluation results

15 Seite 15 von 15 Seiten [17] Certification report for CardOS V4.4 with Application for QES, from Siemens IT Solutions and Services GmbH, Certification ID BSI-DSZ-CC , , Bundesamt für Sicherheit in der Informationstechnik (BSI) [18] PKCS#1 v2.1: RSA Cryptographic Standard, RSA Laboratories, Version 2.1, [19] CardOS V4.4 (CNS) and CardOS DI V4.2C CNS Impact Analysis Report, version 1.20, Edition 07/2011,13 July 2011, Atos IT Solutions and Services GmbH (confidential document) Ende der Bestätigung