DE102004036008A1 - Computergestützte, zentral geschützte Generierung, Speicherung und Verwaltung von privaten asymmetrischen Benutzerschlüsseln (Software Token) in Public Key Infrastruktures des Mobilfunknetzes - Google Patents

Computergestützte, zentral geschützte Generierung, Speicherung und Verwaltung von privaten asymmetrischen Benutzerschlüsseln (Software Token) in Public Key Infrastruktures des Mobilfunknetzes Download PDF

Info

Publication number
DE102004036008A1
DE102004036008A1 DE102004036008A DE102004036008A DE102004036008A1 DE 102004036008 A1 DE102004036008 A1 DE 102004036008A1 DE 102004036008 A DE102004036008 A DE 102004036008A DE 102004036008 A DE102004036008 A DE 102004036008A DE 102004036008 A1 DE102004036008 A1 DE 102004036008A1
Authority
DE
Germany
Prior art keywords
key
hsm
user
signature
mobile signature
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102004036008A
Other languages
English (en)
Inventor
Wolfgang Dr. Ing. Geppert
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GEPPERT, WOLFGANG, DR., 14482 POTSDAM, DE
Original Assignee
Service Concepts Integrat GmbH
Service Concepts Integrated Technologies GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Service Concepts Integrat GmbH, Service Concepts Integrated Technologies GmbH filed Critical Service Concepts Integrat GmbH
Priority to DE102004036008A priority Critical patent/DE102004036008A1/de
Publication of DE102004036008A1 publication Critical patent/DE102004036008A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2117—User registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Medical Informatics (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Computergestützte, zentral geschützte Generierung, Speicherung und Verwaltung von privaten asymmetrischen Benutzerschlüsseln (Software Token) in Public Key Infrastructures des Mobilfunknetzes. DOLLAR A Mit der Erfindung wird ein Verfahren geschaffen, welches über eine technische Schnittstelle die zentrale Schlüsselgenerierung in einem Hardware Security Module (HSM) und die anschließende verschlüsselte Speicherung und Verwaltung in einer Datenbank ermöglicht. Die Benutzer eines intelligenten Mobil Funk Endgerätes (PDA, Pocket PC) können Vorgänge mit ihrem zentralen Sofware Token im Mobilfunknetz gesichert signieren.

Description

  • Die Entwicklung neuer Applikationen der mobilen Datenübertragung im Funk-Netz eröffnet neue Möglichkeiten des ortsungebundenen Informationsaustausches und der wirtschaftlichen Betätigung. Warenbestellungen, Zahlungsanweisungen an Banken, Anträge oder Einsprüche bei Behörden, die Übermittlung sensitiver Daten im medizinischen Bereich und eine Vielzahl weiterer Kommunikationsbeziehungen, die in der Vergangenheit über Papier abgewickelt wurden, erfolgen auf elektronischem Wege. Jedoch kann die Rechtsverbindlichkeit nach Signaturgesetz für die mobile Kommunikation nicht gewährleistet werden. Die elektronische Signatur realisiert die digitale Lösung der rechtsverbindlichen Unterschrift auf Grundlage des Signaturgesetzes.
  • Zur Anwendung einer elektronischen Signatur wird ein privater und ein öffentlicher kryptographischer Schlüssels erzeugt. Der öffentliche Schlüssel wird durch ein Zertifikat einer natürlichen Person fest zugeordnet (qualifizierte Signatur). Die Zuordnung wird durch ein qualifiziertes Signaturschlüssel-Zertifikat der ausstellenden Zertifizierungsstellen beglaubigt. Der Sinn von Zertifizierungsstellen ist die Einrichtung vertrauenswürdiger Instanzen, die durch ihre digitalen Signaturen die Bindung des öffentlichen Schlüssels an einen Benutzeridentität versichern. Die digitale Signatur einer Zertifizierungsstelle soll auf diese Weise einem öffentlichen Schlüssel ein hohes Maß an Vertrauenswürdigkeit vermitteln, als durch die Signaturen beliebiger Benutzer erreicht werden könnte. Die von einer Zertifizierungsstelle verwendeten Zertifikate entsprechen in der Regel dem in X.509 definierten Format. Es handelt sich dabei um eine signierte digitale Struktur, die den jeweiligen öffentlichen Schlüssel sowie den Namen der Person, der er zugeordnet ist, oder ein Pseudonym enthält.
  • Eine solche Infrastruktur ist Voraussetzung für die vertrauenswürdige, rechtsverbindliche Nutzung der mobilen Datenübertragung in Funk-Netzen.
  • Nach Signaturgesetz SigG darf für die Speicherung eines privaten kryptografischen Schlüssels eines Zertifikats nicht das Risiko der Korruption oder die Möglichkeit einer Kopieerstellung gegeben sein. Insofern werden nach Stand der Technik Chipkarten zur Aufnahme und zum Schutz des privaten Schlüssels eingesetzt. Chipkarten, oder auch Smart Cards, sind IT-Komponenten von der Größe einer Scheckkarte. Sie waren anfangs nur als reine Speicherchipkarten verfügbar und dienten zur Ablage von Daten. Später kamen Prozessorchipkarten hinzu, in die Mikroprozessoren und speichernde Bauteile integriert sind. Derzeit werden Chipkarten vermehrt zur Abwicklung kryptografischer Anwendungen eingesetzt, also auch der digitalen Signatur. Chipkarten lassen sich so gestalten, dass der auf ihnen gespeicherte Schlüssel nicht auslesbar ist. Die Aktivierung der Chipkarte geschieht durch eine eigene PIN.
  • Obwohl z.B. viele Applikationsobjekte in der mobilen Kommunikation zukünftig auch signiert werden müssen, verhindern die speziellen Hardwareanforderungen für die Einführung eines weiteren Chipkartenlesegerätes in MobilePhones derzeit ihren generellen Einsatz. Ohne Signatur lassen sich jedoch elektronische Vorgänge in keiner Weise authentifizieren und deren unveränderte Form validieren.
    •
  • Problem
  • Der im Anspruch 1–4 angegebene Erfindung liegt das Problem zugrunde, dass das übliche Verfahren für digitale Signaturen die Signaturkomponenten Chipkarte und Kartenlesegerät benötigen. Dabei schützt die Chipkarte mit ihrer technischen Umgebung den privaten Schlüssel des Chipkartenbesitzers mittels eines sicheren Betriebssystem und einer PIN. Der private Schlüssel darf nicht aus der Chipkarte ausgelesen oder kopiert werden, denn die Einmaligkeit des privaten Schlüssels ist Grundvoraussetzung für die rechtsverbindliche Zuordnung des privaten Schlüssels mit den Personendaten im Zertifikat.
  • Dennoch kann auch die Chipkarte nicht vor Verlust geschützt werden und es sind bereits Verfahren bekannt geworden, dass die PIN der Chipkarte von einem Fremden kompromittiert wurde. Beide Umstände, also Besitz der Chipkarte und Kenntnis der PIN lassen die Nutzung der Chipkarte durch Fremde und damit das Vortäuschen einer anderen Identität zu.
  • Für die Anwendung der digitalen Signatur in einem mobilen Endgerät, kann nach Signaturgesetz das MobilePhone mit seinem Besitz und dem Geheimnis der PIN zur Authentifizierung bei der Nutzung eines zentralen Signatur Tokens genutzt werden.
  • Es galt ein Verfahren zu finden, welches den zentralen privaten Schlüssel eines mobilen Benutzers in analoger Weise und auf gleich hohem Sicherheitsniveau schützt, wie vom Stand der Technik für Signatur-Chipkarten.
  • Erzielbare Vorteile
  • Mit der Erfindung wird den Nutzern von mobilen Endgeräten im Funk-Netz die Möglichkeit geschaffen, ihre elektronischen Vorgänge ortsungebunden und ohne die Verwendung einer Chipkarte zu signieren. Das mobile Endgerät benötigt für die Erfindung kein Chipkartenlesegerät.
  • Die Betreiber von Mobilfunknetzen dürfen mit der Erhöhung des Sicherheitsniveaus und der unabstreitbaren Rechtssicherheit ihrer Prozesse eine höhere Akzeptanz und Nutzen für ihre Teilnehmer erwarten. Dies führt in Verbindung mit medienbruchfreier, signaturfähiger Vorgangsbearbeitung im Firmennetz oder Internet wiederum zur Kostensenkung für die Mobilfunknutzer.
    •
  • Beschreibung von Ausführungsbeispielen
  • Im Folgenden sollen die Ausführungsbeispiele anhand der Abbildung für die Systemarchitektur, Zertifikatsanforderung der Registrierungsstelle und der Signaturanwendung eines Benutzers näher beschrieben werden. Die gesetzlichen Anforderungen eines nationalen Normgebers werden erfindungsgemäß nicht betrachtet.
  • Es zeigen
  • 1 das Schema zur Darstellung der Public Key Infrastructure (PKI) zur zentralen Erzeugung eines asymmetrischen Schlüsselpaar (Private-Public Key) mit einem hardwaregekapselten, asymmetrischen Schlüssel einer CA über eine doppel-kryptograpischen Speicherung in einem proprietären Schlüsselspeicher (Key Store) (2) Speicherformat.
  • Das System besteht aus folgenden Komponenten
    • 1. Proxy
    • 2. Applikation
    • 3. mobiles Endgerät (PDA)
    • 4. Certificate Authority Server (CA Server)
    • 5. Certificate Authority (CA) mit Hardware Security Module (HSM)
  • Die Sicherheitskomponeten 1–5 kommunizieren in einem geeigneten Protokoll, welches die bekannte Angriffsarten und Sicherheitsprobleme in der Client/Server Anwendung berücksichtigt. Die Kommunikationsart muss insbesondere geeignet sein die Sicherheitskomponenten untereinander mit Zertifikaten sicher zu authentifizieren und zu autorisieren. Weiterhin sind alle Software-Sicherheitskomponeten unbedingt vor unbemerkten Veränderungen zu schützen. Programmiersprachen wie Java und C#.NET bieten entsprechende Schutzmechanismen (MAC, Strong Name Assembly).
  • Die Sicherheitskomponente 1. Proxy ist ein Softwaremodul, welches die gesicherte Kommunikation zwischen einer Client-Anwendung und dem Certificate Authority Server übernimmt. Die Verbindung zwischen dem Proxy und dem Certificate Authority Server erfolgt über das Mobilfunknetz. Der Proxy übernimmt gleichzeitig das Schlüssel- und Zerifikatsmanagement. Der Proxy wird durch ein Zertifikat ausgewiesen.
  • Die Sicherheitskomponente 2. Applikationen sind beliebige Anwendungen der Teilnehmer, die digitale Signaturen anfordern.
  • Die Sicherheitskomponente 3. mobiles Endgerät (PDA) zeigt ein mobiles Endgerät des Funknetzes für die Aufnahme der Sicherheitskomponenten 1. und 2., welches innerhalb einer PKI die Signaturanforderungen des Teilnehmers entgegennimmt und der CA zustellt. Der Teilnehmer erhält durch das Subscriber Identification Module (SIM) und seiner Benutzer PIN zur sicheren Authentifizierung Zugriff auf sein Server Software Token.
  • Die Sicherheitskomponete 4. CA Server ist ein Softwaremodul, welches der eigentlichen CA vorangestellt wird. Dies dient der sicheren Abgrenzung der CA von einer unsicheren Netzwerkumgebung des CA Servers. Der CA Server muss auf einem sicheren Server-Betriebsystem installiert werden, um nach dem Stand der Technik Sicherheitsrisiken des Betriebsystems zu reduzieren. Der CA Server ist ,point to point' mit dem Rechner der CA über eine nicht IP basierten Kommunikation verbunden. Der Verbindungsaufbau zwischen der CA und dem CA Server erfolgt verschlüsselt und wird mit ihren Zertifikaten sicher authentifizieren und autorisieren. Der CA Server muss jeden nicht authorisierten Zugriff auf die CA unterbinden. In außerordentlichen Situationen muss der CA Server die ,point to point' Verbindung auftrennen, indem die Kommunikationstreiber entladen werden.
  • Die Sicherheitskomponete 5. CA mit HSM ist ein Software/Hardwaremodul, welches neue Zertifikate auf Antrag einer RA ausstellt und Signaturen für die identifizierten Teilnehmer erstellt. Zu diesem Zweck nutzt die CA ein Hardware Security Module (HSM) zum Schutz der privaten CA Schlüssel. Dabei wird der asymmetrische private Schlüssel für die CA Signierung der Benutzerzertifikate und der asymmetrische private Schlüssel für den Schutz der datenbankgespeicherten Benutzerschlüsselobjekte (einschließlich Privat Schlüssel) in der HSM abgelegt. Das HSM verbietet das Lesen oder Kopieren der privaten Schlüssel und bietet den höchsten Schutz gegen andere Formen der Kompromittierung.
  • 2 das Schema zur Darstellung eines Speicherobjekts des Teilnehmerschlüssels. Dieses Objekt besteht aus einem Identifikationsbereich (UserID oder öffentlicher Schlüssel) und dem verschlüsselten Bereich mit den gewrappten Wiederholungszähler, der Teilneh mer PIN und seinem privaten Schlüssel. Der Schlüsselspeicher in einer regulären Datenbank schützt kryptografisch den Privaten Schlüssel 5, das Benutzerkennwort (PIN) 10, sowie einem Zähler 15 über die Anzahl der erfolglosen Versuche der PIN-Übergabe. Der Schlüsselspeicher wird über eine Benutzer ID in der Datenbank verwaltet.
  • 3 das Schema zur Darstellung einer Zertifikatsanforderung der Registrierungsstelle des Mobilfunkbetreibers. Die Dialogerfassung (Widerrufskennwort, Authentifizierung-Kennwort) und Personenidentifizierung erfolgt durch einen zugelassenen Mitarbeiter der Registrierungsstelle auf einen zugelassenen Rechner. Mitarbeiter und Rechner der RA benötigen für die Authentifizierung ihrer Zulassung spezielle Zertifikate. Die Erfassung der PIN durch den Antragsteller kann mit der separaten Tastatur des Chipkartenterminals erfolgen. Die Benutzeroberfläche der RA stellt nach positiver Identifizierung des Antragstellers 5, durch den Mitarbeiter der RA die notwendigen Personendaten (Common Data) 10 für ein X.509 Zertifikats 20 zusammen. Der Verbindungsaufbau mit dem CA Server erfolgt über den Proxy 25. Die RA sendet dem CA Server einen X.509 Zertifikatsentwurf (ohne Public Key) 30. Ein gültiger authentifizierter Zertifizierungsauftrag der RA wird vom CA Server mit einem abgesicherten Verbindungaufbau zum CA Rechner beantwortet. Die Verbindung zwischen CA Server und CA erfolgt ,none IP point to point' (RS232, USB, parallel) auf der Grundlage von nicht veröffentlichten Zertifikaten, die sicherstellen, dass ausschließlich CA und CA Server miteinander kommunizieren. Jeder andere Teilnehmer wird abgewiesen. Jede Verbindung wird nach einer Anforderungsbearbeitung abgebaut.
  • Für den X.509 Zertifikatsentwurf der RA wird in einer HSM der CA ein Schlüsselpaar erzeugt 35. Die kryptografischen Parameter wie z.B. Schlüssellänge oder Kryptoalgorithmus sind für die Erfindung ohne Bedeutung und können nach gesetzlichen Anforderungen frei gewählt werden. Der öffentliche Schlüssel wird in das Zertifikat des Antragsstellers eingefügt und anschließend mit der privaten Schlüssel der CA signiert. Der entsprechende private Schlüssel, Benutzer PIN und PIN-Zähler werden in der CA HSM gewrapped und anschließend im Format des Schlüsselspeichers (2) sowie einer Identifikation des Teilnehmers in einer Datenbank abgelegt 45.
  • Nach der Signatur des Antragstellerzertifikats stellt die CA einen Veröffentlichungsauftrag 40 für das Zertifikat an den CA Server, der seinerseits das signierte Zertifikat in dem Ldap Verzeichnisdienst veröffentlicht 40. Nach erfolgreicher Veröffentlichung des Zertifikats lie fert der CA Server der RA das Zertifikat 50. Die RA Benutzeroberfläche zeigt das ausgestellte Zertifikat 55.
  • 4 das Schema zur Darstellung der Schutzräume für eine Zertifikatsanforderung. Das System unterscheidet zwei Sicherheitsräume:
    • 1. einen sicheren, geschützten Bereich eines Servers in einem Safe eines sicheren Serverraumes und
    • 2. einen hochsicheren Bereich eines HSM.
  • Die in 4 dargestellten Abläufe untersetzen den Punkt 35 der 3 und weisen dabei insbesondere die Sicherheitsräume aus, in denen die Prozesse laufen.
  • Die CA fordert bei Zeritfikatsanforderung die HSM zur Generierung (4 1.) eines asysmetrischen Schlüsselpaares auf. Der private Schlüssel des Antragsstellers verlässt die HSM ungeschützt (also verschlüsselt) niemals. Der private Schlüssel steht unverschlüsselt in seinem Lebenszyklus anderen Prozessen (außerhalb der HSM) nicht zur Verfügung. Die Nutzung des privaten Schlüssels ist nur nach Entschlüsselung und über Funktionsaufrufen in der HSM möglich. Insofern wird der Schlüssel mit dem öffentlichen CipherCert Schlüssel der HSM verschlüsselt (wrap) (4 2.). Für einen Verlust der HSM in einem Notfall, wird ein zweite HSM bereitgehalten und mit diesem öffentlichen Schlüssel eine Ersatzverschlüsselung (4 3.) des Benutzerschlüssels vorgenommen. Insofern werden von jedem privaten Benutzerschlüssel zwei geschützte Schlüssel erstellt. Der öffentliche Benutzerschlüssel wird außerhalb der HSM in den X.509 Zertifikatsentwurf der Common Data des Antragstellers eingefügt (4 4.) und als Certificate Signing Request (CSR) intern von der CA bearbeitet. Nach Verschlüsselung der Benutzer PIN (4 6.) wird das Schlüsselspeicher-Objekt ergänzt (4 7.) und in einer Datenbank abgelegt (4 8.).
  • 5 das Schema zur Darstellung einer Signaturanforderung durch einen Benutzer. Für die Signierung eines Objektes bedarf es der Sicherheitskomponente 1. Proxy. Die Clientanwendung lädt den Proxy 80 übergibt dem Proxy die PIN des Schlüsselspeichers, das zu signierende Objekt oder ein Hash des Objektes 85. Der Proxy übernimmt die gesicherte Kommunikation zwischen der Client-Anwendung und dem CA Server. Der Proxy übernimmt gleichzeitig das Schlüssel- und Zerifikatsmanagement. Für eine Signaturanforderung muss auf der Clientseite der Computer ein gültiges Zertifikat 90 und das Betriebssystem die eindeutige Benutzerauthentifizierung an den Proxy liefern. Der Proxy sendet seine Signaturanforderung mit der Benutzeridentifikation, dem Computerzertifikat und dem Objekthash an den CA Server. Ein gültige authentifizierte Signaturanforderung 90 des Proxies wird vom CA Server mit einem abgesicherten Verbindungaufbau zum CA Rechner beantwortet. Die Verbindung zwischen CA Server und CA erfolgt 95 ,none IP point to point' auf der Grundlage von nicht veröffentlichten Zertifikaten, die sicherstellen, dass ausschließlich CA und CA Server miteinander kommunizieren. Jeder andere Teilnehmer wird abgewiesen. Jede Verbindung wird nach einer Anforderungsbearbeitung abgebaut.
  • Die CA kann mit der Benutzeridentifikation den Datensatz zum Schlüsselspeicher aus der Datenbank abrufen und mit dem Schlüssel der HSM entschlüsselt in dem Speicher der HSM ablegen 100. Die Benutzer PIN administriert den Zugriff auf den privaten Schlüssel des Benutzers, so dass die CA mit dem Objekthash und dem privaten Schlüssel des Benutzers die Signatur in der HSM erzeugen kann 105. Die Signatur wird über den CA Server und Proxy an die Clientanwendung zur geliefert 110. Die CA entfernt alle unbenutzte Objekte 115.
  • Die PIN Prüfung erfolgt über einen Vergleich der entschlüsselten PIN des Schlüsselspeichers in der HSM mit der Benutzer PIN aus der Signaturanforderung. Bei Angabe einer falschen Benutzer PIN wird die Signaturanforderung abgewiesen und der PIN Zähler um eins erhöht. Der PIN Zähler wird ebenfalls in der HSM verschlüsselt und steht ungeschützt außerhalb der HSM als Zähler nicht zur Verfügung. Damit sind manipulative Resets des PIN Zähler ausgeschlossen. Bei Überschreitung eines maximalen Zählers wird der private Benutzerschlüssel gesperrt oder gelöscht. Die Wahl richtet sich nach den gesetzlichen und administrativen Anforderungen.
  • 6 und 7 das Schema zur Darstellung der Schutzräume für eine Zertifikatsanforderung. Das System unterscheidet zwei Sicherheitsräume:
    • 3. einen sicheren, geschützten Bereich eines Servers in einem Safe eines sicheren Serverraumes und
    • 4. einen hochsicheren Bereich eines HSM.
  • Die in 6 und 7 dargestellten Abläufe untersetzen den Punkt 105 der 5 und weisen dabei insbesondere die Sicherheitsräume aus, in denen die Prozesse laufen.
  • Die CA fordert bei Signaturanforderung den Schlüsselspeicher aus der Datenbank über die Benutzer Id (6 1.) an. Die geschützte PIN wird der HSM zur Entschlüsselung übergeben (unwrap) (6 2.) und über Zeiger in der HSM mit der Signaturanforderungs-PIN verglichen (6 3.). Wenn die Signaturanforderungs-PIN nicht mit der PIN übereinstimmt, wird die Anforderung abgewiesen und der PIN Zähler um eins erhöht (6 4.). Der PIN Zähler wird durch Verschlüsselung (wrap-unwrap) (6 5.) in der HSM geschützt. Bei richtiger PIN wird der geschützte Benutzerschlüssel an das HSM zur Entschlüsselung übergeben (unwrap) (7 1.). Die Signatur des Benutzerobjekt (7 2.) erfolgt mittels eines Zeigers auf den privaten Benutzerschlüssel (7 3.) in der HSM. Der PIN Zähler wird zurückgesetzt (7 4.). Das Schlüsselobjekt wird in die Datenbank zurückgeschrieben (7 5.). Die Signatur wird an den Benutzer über ein gesichertes Protokoll zurückgeliefert. Die nicht genutzten Objekte werden in der CA und in der HSM entfernt (7 6.).
  • 8 das Schema zur Darstellung einer Systemwiederherstellung in einem Notfall. Das System verfügt über zwei getrennte HSM Einheiten 110, die jeweils einen CipherCert Schlüsselpaar generiert haben. Eine der beiden HSM's verbleibt im System als Produktionsmodul 115 wogegen die andere HSM außerhalb des Servergebäudes an einer sicheren Stellen aufbewahrt wird. Innerhalb des normalen Betriebs verwendet das Produktions-HSM die öffentlichen Schlüssel beider (einschließlich der gelagerten) HSM's. In einem Notfall, also wenn die Produktions-HSM zerstört wurde 120, wird zunächst das 2. HSM in das System eingebracht 125 und in einem 3. HSM ein 3. Schlüsselpaar generiert. Das 3. HSM 130 geht an Stelle des 2. HSM in die Sicherung und der öffentliche Schlüssel der 3. HSM in die Produktion 135. Zuvor werden allerdings alle Benutzerschlüsselspeicher in der Datenbank regeneriert, in dem die Schlüsselspeicher mit dem privaten Schlüssel in dem 2. HSM entschlüsselt (unwrap) 140, in einem Zug wieder mit den öffentlichen Schlüsseln des 2. HSM und 3. HSM verschlüsselt (wrap) 145 und sodann wieder in der Datenbank abgelegt. Dieser Vorgang ist für den Fall eines weiteren Verlustes des 2. HSM mit einem 4. HSM zu wiederholen.

Claims (4)

  1. Mobile Signatur für eine computergestützte zentrale Generierung eines asymmetrischen Schlüsselpaars, der verschlüsselten Speicherung als Schlüsselobjekt mit dem privaten Schlüssel des Benutzers in einer Datenbank und für die Nutzung als zentrales, kryptografisches Software Token in Public Key Infrastructures (PKI). dadurch gekennzeichnet, dass die technische Einrichtung der mobile Signatur aus einer Softwareschicht zur Ansteuerung eines Hardware Security Module (HSM) einer Zertifizierungsstelle, sowie einer Softwareschicht zur Kommunikation über gesicherte Protokolle (z.B. SSL, XAgent) mit dem Dienst der Zertifizierungsstelle und der Mobilanwendung zusammengesetzt ist.
  2. Mobile Signatur nach Patentanspruch 1, dadurch gekennzeichnet, dass die technische Einrichtung der mobilen Signatur, über einen Proxy eine Verbindung zum Dienst der Zertifizierungsstelle herstellt, den Registrierungsbenutzer, den Proxy und seinen Rechner sicher authentifiziert und die Personendaten der mobile Signatur an den Zertifizierungsdienst übergibt.
  3. Mobile Signatur nach Patentanspruch 1 und 2, dadurch gekennzeichnet, dass die technische Einrichtung der mobilen Signatur, auf Anfrage zur Zertifikatserstellung in einem Hardware Security Module (HSM) eine asymmetrisches Schlüsselpaar generiert und innerhalb der HSM mit dem öffentlichen Schlüssel einer oder mehrer HSM's symmetrisch oder asymmetrisch verschlüsselt (wrap), sowie das so verschlüsselte Schlüsselobjekt in einer Datenbank zu speichern, ohne die Möglichkeit einer Kompromittierung des privaten kryptografischen Benutzerschlüssels zu bewirken.
  4. Mobile Signatur nach Patentanspruch 1, 2 und 3, dadurch gekennzeichnet, dass die technische Einrichtung der mobilen Signatur, eine clienseitige Nutzung des zentralen, privaten Benutzerschlüssels durch Angabe einer PIN, Benutzerauthentifizierung und Authentifizierungszertifikate des Proxy sowie Rechner für Digitale Signaturen zulässt, indem sie über einen Proxy eine Verbindung zum Dienst der Zertifizierungsstelle herstellt, in der Zertifizierungsstelle das Schlüsselobjekt aus der Datenbank mit der Benutzerindentifikation abruft, in Hardware Security Module (HSM) lädt, dort entschlüsselt (unwrap) und für den Signaturvorgang innerhalb der HSM nutzt.
DE102004036008A 2004-07-26 2004-07-26 Computergestützte, zentral geschützte Generierung, Speicherung und Verwaltung von privaten asymmetrischen Benutzerschlüsseln (Software Token) in Public Key Infrastruktures des Mobilfunknetzes Withdrawn DE102004036008A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102004036008A DE102004036008A1 (de) 2004-07-26 2004-07-26 Computergestützte, zentral geschützte Generierung, Speicherung und Verwaltung von privaten asymmetrischen Benutzerschlüsseln (Software Token) in Public Key Infrastruktures des Mobilfunknetzes

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102004036008A DE102004036008A1 (de) 2004-07-26 2004-07-26 Computergestützte, zentral geschützte Generierung, Speicherung und Verwaltung von privaten asymmetrischen Benutzerschlüsseln (Software Token) in Public Key Infrastruktures des Mobilfunknetzes

Publications (1)

Publication Number Publication Date
DE102004036008A1 true DE102004036008A1 (de) 2006-05-04

Family

ID=36201536

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102004036008A Withdrawn DE102004036008A1 (de) 2004-07-26 2004-07-26 Computergestützte, zentral geschützte Generierung, Speicherung und Verwaltung von privaten asymmetrischen Benutzerschlüsseln (Software Token) in Public Key Infrastruktures des Mobilfunknetzes

Country Status (1)

Country Link
DE (1) DE102004036008A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006058410B4 (de) 2006-02-17 2022-02-03 Husqvarna Ab Kraftstoffsystem

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006058410B4 (de) 2006-02-17 2022-02-03 Husqvarna Ab Kraftstoffsystem

Similar Documents

Publication Publication Date Title
EP3596653B1 (de) Ausstellen virtueller dokumente in einer blockchain
DE60114986T2 (de) Verfahren zur herausgabe einer elektronischen identität
DE60211841T2 (de) Vorrichtung zur Aktualisierung und zum Entzug der Gültigkeit einer Marke in einer Infrastruktur mit öffentlichen Schlüsseln
EP3474172B1 (de) Zugangskontrolle unter verwendung einer blockchain
DE112018003825T5 (de) Blockchain-berechtigungsprüfung mittels hard/soft-token-überprüfung
DE69534490T2 (de) Verfahren zur sicheren anwendung digitaler unterschriften in einem kommerziellen verschlüsselungssystem
DE60023705T2 (de) Sichere verteilung und schutz einer schlüsselinformation
EP1946481B1 (de) Verfahren zur erzeugung einer fortgeschrittenen elektronischen signatur eines elektronischen dokuments
EP1777907B1 (de) Vorrichtungen und Verfahren zum Durchführen von kryptographischen Operationen in einem Server-Client-Rechnernetzwerksystem
DE60119857T2 (de) Verfahren und Vorrichtung zur Ausführung von gesicherten Transaktionen
DE102009027723A1 (de) Verfahren zum Lesen von Attributen aus einem ID-Token
EP3182318A1 (de) Signaturgenerierung durch ein sicherheitstoken
EP4092958B1 (de) Ausstellen eines digitalen verifizierbaren credentials
DE102014204252A1 (de) Sicherheitssystem mit Zugriffskontrolle
EP3422274A1 (de) Verfahren zur konfiguration oder änderung einer konfiguration eines bezahlterminals und/oder zur zuordnung eines bezahlterminals zu einem betreiber
AT504634B1 (de) Verfahren zum transferieren von verschlüsselten nachrichten
DE102020118716A1 (de) Verfahren zur sicheren Durchführung einer Fernsignatur sowie Sicherheitssystem
EP4254234A1 (de) Ausstellen eines digitalen credentials für eine entität
EP3289509B1 (de) Verfahren zur erzeugung einer elektronischen signatur
DE102004036008A1 (de) Computergestützte, zentral geschützte Generierung, Speicherung und Verwaltung von privaten asymmetrischen Benutzerschlüsseln (Software Token) in Public Key Infrastruktures des Mobilfunknetzes
DE102006009725A1 (de) Verfahren und Vorrichtung zum Authentifizieren eines öffentlichen Schlüssels
DE102004053890A1 (de) Virtuelle Chipkarte zur computergestützten zentralen, geschützten Generierung, Speicherung und Verwaltung von privaten asymetrischen Benutzerschlüssel (Software Token) in Public Key Infrastructures
DE19923807A1 (de) Verfahren zur Erhöhung der Sicherheit bei digitalen Unterschriften
EP1248432B1 (de) Verfahren und System zum Abfragen von Zertifikatsinformationen unter Verwendung von dynamischen Zertifikatsreferenzen
EP3358488A1 (de) Verfahren zum erkennen von unberechtigten kopien digitaler sicherheits-token

Legal Events

Date Code Title Description
8122 Nonbinding interest in granting licences declared
8127 New person/name/address of the applicant

Owner name: GEPPERT, WOLFGANG, DR., 14482 POTSDAM, DE

8139 Disposal/non-payment of the annual fee