-
Es ist bekannt, Postsendungen mit
digitalen Freimachungsvermerken zu versehen.
-
Um den Absendern der Postsendungen
die Erzeugung der Freimachungsvermerke zu erleichtern, ist es beispielsweise
bei dem von der Deutschen Post AG eingesetzten Frankierungssystem
möglich,
Freimachungsvermerke in einem Kundensystem zu erzeugen und über eine
beliebige Schnittstelle auf einen Drucker auszugeben.
-
Ein derartiges gattungsgemäßes Verfahren
ist in der Deutschen Offenlegungsschrift
DE 100 20 402 A1 offenbart.
-
Um einen Missbrauch dieses Verfahrens
zu vermeiden, enthalten die digitalen Freimachungsvermerke kryptographische
Informationen, beispielsweise über
die Identität
des die Erzeugung des Freimachungsvermerkes steuernden Kundensystems.
-
Der Erfindung liegt die Aufgabe zugrunde,
ein Verfahren zu schaffen, mit dem die Echtheit der Freimachungsvermerke
schnell und zuverlässig überprüft werden
kann. Insbesondere soll sich das Verfahren für eine Überprüfung in einem Großserieneinsatz,
insbesondere in Brief- oder Frachtzentren, eignen.
-
Erfindungsgemäß wird diese Aufgabe dadurch
gelöst,
dass das Verfahren zur Überprüfung der
Echtheit so durchgeführt
wird, dass ein Datenschlüssel
erzeugt und von einer zentralen Datenbank (ZinS Zentral-System)
an lokale Entgeltsicherungs systeme (ZinS-lokal) übertragen wird. Dies geschieht
mittels eines erzeugten Freimachungsschlüssels und eines auf einer Postsendung
aufgebrachten Freimachungsvermerks, wobei in dem Freimachungsvermerk
enthaltene kryptographische Informationen entschlüsselt und
zur Überprüfung der
Echtheit des Freimachungsvermerkes eingesetzt werden.
-
Zur Erhöhung der Sicherheit des Verfahrens
ist es vorteilhaft, dass die lokalen Entgeltsicherungssysteme den
Datenschlüssel
importieren und ein Ergebnis des Imports an die zentrale Datenbank
(ZinS Zentral-System) übermitteln.
-
In einer besonders zweckmäßigen Ausführungsform
des Verfahrens wird das Ergebnis des Imports als ein Datensatz übermittelt.
-
Vorzugsweise enthält der Datensatz einen Schlüssel. Der
Schlüssel
kann verschiedene Beschaffenheiten haben. Insbesondere kann es sich
sowohl um einen symmetrischen als auch um einen asymmetrischen Schlüssel handeln.
Je nach Einsatzzweck dient der Schlüssel zu einem Entschlüsseln und/oder
Verschlüsseln von
Informationen. Durch seine Beschaffenheit kann der Schlüssel ebenfalls
Informationen transportieren. Beispielsweise enthält der Schlüssel Informationen über den
Freimachungsschlüssel,
seine Schlüsselgeneration und/oder
sein Verfallsdatum.
-
Zur Sicherstellung eines einheitlich
erfolgenden Schlüsselwechels
ist es zweckmäßig, dass
die zentrale Datenbank (ZinS Zentral-System) das Ergebnis des Imports überprüft und an
ein Wertübertragungszentrum
(Postage Point) übermittelt.
-
Diese Ausführungsform des Verfahrens ermöglicht es,
weitere Verfahrensschritte in dem Wertübertragungszentrum in Abhängigkeit
von dem Ergebnis des Imports durchzuführen.
-
Die Überprüfung des Ergebnisses kann auf
verschiedene Weisen erfolgen. Es ist jedoch besonders vorteilhaft,
dass die Überprüfung des
Ergebnisses durch Entschlüsselung
des Schlüssels
erfolgt.
-
Eine bevorzugte Ausführungsform
des Verfahrens zeichnet sich dadurch aus, dass bei erfolgreichem Import
des Datenschlüssels
auf im Wesentlichen allen lokalen Entgeltsicherungssystemen (ZinS-lokal)
der Datenschlüssel
als neuer Freimachungsschlüssel
auf dem Wertübertragungszentrum
(Postage Point) freigegeben und im Anschluss bei der Erstellung
neuer Freimachungen verwendet wird.
-
Diese Ausführungsform des Verfahrens ermöglicht es,
einen Schlüsselwechsel
in dem Wertübertragungszentrum
in Abhängigkeit
von zuvor durchgeführten
Schlüsselwechseln
in den Entgeltsicherungssystemen durchzuführen. Hierdurch wird sichergestellt,
dass erst dann Freimachungsvermerke unter Einsatz des neuen Schlüssels erzeugt
werden, nachdem der neue Schlüssel
bereits in den lokalen Entgeltsicherungssystemen vorliegt. Hierdurch
wird sichergestellt, dass die lokalen Entgeltsicherungssysteme die
Gültigkeit
der jeweils erzeugten Freimachungsvermerke überprüfen können.
-
Diese besonders bevorzugte Ausführungsform
des Verfahrens mit einer Steuerung des Schlüsselwechsels in dem Wertübertragungszentrum
in Abhängigkeit
von den Schlüsselwechseln
in den lokalen Entgeltsicherungssystemen ist insbesondere in Kombination
mit wenigstens einzelnen der weiteren erfindungsgemäßen Verfahrensschritte
von Vorteil.
-
Insbesondere wird durch eine Kombination
mehrerer Merkmale sichergestellt, dass der Schlüsselwechsel rasch und zuverlässig erfolgen
kann und dass die Durchführung
der jeweiligen Schlüsselwechsel überprüft wird.
-
Bei der Durchführung des Schlüsselwechsels
ist es besonders vorteilhaft, dass der neue Datenschlüssel von
dem wertübertragungszentrum
(Postage Point) an das zentrale Entgeltsicherungssystem übertragen wird.
-
Hierbei ist es besonders vorteilhaft,
dass das Wertübertragungszentrum
den Datenschlüssel
mit einem Transportschlüssel
(KT) verschlüsselt.
-
Hierbei ist es zweckmäßig, dass
der Transportschlüssel
mit einem Master-Transportschlüssel
(KTM) verschlüsselt
wird.
-
Vorzugsweise wird der Datenschlüssel im
Bereich des Wertübertragungszentrums
erzeugt. Dies hat den Vorteil, dass missbräuchliche Veränderungen
des Datenschlüssels
während
eines Transports zu dem Wertübertragungszentrum
vermieden werden.
-
Zur weiteren Erhöhung der Datensicherheit ist
es vorteilhaft, dass der Datenschlüssel mit einer Schlüsselidentifikationsangabe
versehen wird.
-
Zweckmäßigerweise wird die Schlüsselidentifikationsangabe
ebenfalls verschlüsselt übertragen.
-
Um sicherzustellen, dass für die eingesetzten
Verschlüsselungs-
und/oder Enschlüsselungsschritte
jeweils ein gültiger
Datenschlüssel
eingesetzt wird, ist es zweckmäßig, dass
der Datenschlüssel
mit einem Generationszähler
versehen und/oder gemeinsam mit dem Generationszähler übertragen wird.
-
Zur Vermeidung eines Einsatzes von
ungültigen
Schlüsseln
ist es ferner zweckmäßig, dass
der Freimachungsschlüssel
mit einem Verfallsdatum für
den vorangegangenen Datenschlüssel
versehen und/oder mit dem Verfallsdatum übertragen wird.
-
Der dargestellte Datenschlüssel kann
sowohl für
eine oder mehrere Teilprüfungen
als auch für
die Erzeugung von Freimachungsvermerken und/oder die Entschlüsselung
von in den Freimachungsvermerken enthaltenen Informationen eingesetzt
werden.
-
Es ist besonders zweckmäßig, dass
eine der Teilprüfungen
die Entschlüsselung
der in dem Freimachungsvermerk enthaltenen kryptographischen Informationen
beinhaltet.
-
Durch die Integration der Entschlüsselung
der kryptographischen Informationen in den Prüfungsprozess ist es möglich, die
Echtheit der Freimachungsvermerke unmittelbar zu erfassen, so dass
eine Überprüfung in
Echtzeit erfolgen kann.
-
Ferner ist es vorteilhaft, dass eine
der Teilprüfungen
einen Vergleich zwischen dem Erzeugungsdatum des Freimachungsvermerks
und dem aktuellen Datum beinhaltet. Die Integration des Erzeugungsdatums
des Freimachungsvermerks – insbesondere
in verschlüsselter
Form – erhöht die Datensicherheit,
da durch den Vergleich zwischen dem Erzeugungsdatum des Freimachungsvermerkes
und dem aktuellen Datum eine mehrfache Verwendung eines Freimachungsvermerks
vermieden wird.
-
Zur weiteren Erhöhung der Überprüfungsgeschwindigkeit ist es
vorteilhaft, dass die Leseeinheit und die Überprüfungseinheit mittels eines
synchronen Protokolls Informationen austauschen.
-
In einer anderen, gleichfalls zweckmäßigen Ausführungsform
der Erfindung, kommunizieren die Leseeinheit und die Überprüfungseinheit über ein
asynchrones Protokoll miteinander.
-
Hierbei ist es besonders zweckmäßig, dass
die Leseeinheit ein Datentelegramm an die Überprüfungseinheit sendet.
-
Vorzugsweise enthält das Datentelegramm den Inhalt
des Freimachungsvermerks.
-
Weitere Vorteile, Besonderheiten
und zweckmäßige Weiterbildungen
der Erfindung ergeben sich aus den Unteransprüchen und der nachfolgenden
Darstellung bevorzugter Ausführungsbeispiele
anhand der Zeichnungen.
-
Von den Zeichnungen zeigen
-
1 eine
besonders bevorzugte Ausführungsform
einer erfindungsgemäßen Schlüsselverteilung;
-
2 Anwendungsfälle eines
erfindungsgemäßen Schlüsselverteilungssystems;
-
3 eine
Prinzipdarstellung einer Schnittstelle zwischen einem zentralen
Entgeltsicherungssystem (ZinS Zentral-System) und einem Wertübertragungszentrum
(Postage Point);
-
4 Verfahrensschritte
zur Integration eines Datenschlüssels
in das zentrale Entgeltsicherungssystem (ZinS Zentral);
-
5 eine
Prinzipdarstellung einer Schlüsselverteilung
von dem zentralen Entgeltsicherungssystem (ZinS Zentral-Server)
zu lokalen Entgeltsicherungssystemen einschließlich der zugehörigen Krypto-Systeme;
-
6 eine
Anbindung der DLL-Schnittstelle;
-
7 eine
Prinzipdarstellung von Verfahrensschritten zur Kapselung von Komponenten
und zur Behandlung von Fehlermeldungen.
-
Nachfolgend wird die Erfindung am
Beispiel eines PC-Freimachungssystems dargestellt. Die zur Entgeltsicherung
dienenden Verfahrensschritte sind dabei unabhängig von dem zur Erzeugung
der Freimachungsvermerke eingesetzten System.
-
Die dargestellte dezentrale Überprüfung an
einzelnen Kontrollstellen, insbesondere in Briefzentren, ist besonders
bevorzugt, jedoch ist eine zentralisierte Überprüfung gleichermaßen möglich.
-
Bei besonders bevorzugten Ausführungsbeispielen
der Erfindung bilden die einzelnen Kontrollstellen lokale Entgeltsicherungssysteme,
die vorzugsweise über
eine Datenverbindung mit einem zentralen Entgeltsicherungssystem
verbunden sind.
-
Das zentrale Entgeltsicherungssystem
ist in den dargestellten besonders bevorzugten Ausführungsbeispielen
außerdem
mit einem Wertübertragungszentrum
verbunden.
-
Besonders bevorzugte Ausführungsformen
des Wertübertragungszentrums
werden nachfolgend als Postage Point bezeichnet. Vorteilhafte Ausführungsformen
des zentralen Entgeltsicherungssystems werden nachfolgend als ZinS
Zentral be zeichnet.
-
Die zwischen dem Wertübertragungszentrum
und dem Entgeltsicherungssystem zu realisierende technische Schnittstelle
besteht darin, kryptographische Schlüssel auszutauschen.
-
Der Schlüssel, der zwischen dem Wertübertragungszentrum
und dem Entgeltsicherungssystem auszutauschen ist, stellt die Fälschungssicherheit
der hergestellten Frankiervermerke sicher. Dies erfolgt insbesondere
dadurch, dass ein Teil des Inhaltes des den Frankiervermerk bildenden
2D-Barcodes mit ihm verschlüsselt
wird. Da es sich bei dem ausgewählten
Schlüssel
aus Gründen
der Performance um einen symmetrischen Schlüssel handelt, muss er von dem
Wertübertragungszentrum
an das Entgeltsicherungssystem übertragen
und dort an die einzelnen Briefzentren verteilt werden.
-
Die sichere Speicherung der Schlüssel ist
durch den Einsatz spezieller Kryptokarten gewährleistet. Die Erfindung beinhaltet
verschiedene Einsatzfälle,
bei denen das Management dieser Schlüssel unter Einsatz dieser speziellen
Hardware erfolgt. Es wird dabei der gesamte Lebenszyklus dieser
Schlüssel,
von der Generierung, dem Export, der Verteilung bis hin zum Import
auf den dezentralen Systemen für
eine Optimierung von Verfahrensparametern genutzt.
-
Ein besonders bevorzugter Ablauf
bei der Schlüsselverteilung
lässt sich
aus 1 entnehmen.
-
1 zeigt
eine besonders bevorzugte Schlüsselverteilung
zwischen dem Wertübertragungszentrum und
dem zentralen Entgeltsicherungssystem.
-
In einem ersten Verfahrensschritt
1 für einen
Austausch eines bei einer Erstellung von Freimachungen eingesetzten
Frei machungsschlüssels
wird zunächst
ein neuer Freimachungsschlüssel
erzeugt.
-
Der Begriff des Freimachungsschlüssels ist
in keiner Weise einschränkend
zu verstehen, da die dargestellten Schlüssel auf verschiedene Weisen
für die
Erstellung von Freimachungen eingesetzt werden können.
-
Beispielsweise ist es möglich, den
Freimachungsschlüssel
unmittelbar für
eine Erzeugung von Freimachungen einzusetzen.
-
Es ist jedoch gleichfalls möglich und
für Systeme
mit einer besonders hohen Manipulationssicherheit besonders zweckmäßig, Freimachungsvermerke
mit einem mehrfach verschlüsselten
Dateninhalt zu erzeugen, wobei der Dateninhalt vorzugsweise als
ein Ergebnis mehrerer Verknüpfungen
gebildet wird, wobei an einer oder an mehreren Stellen das Ergebnis
einer Verknüpfung
mit dem Freimachungsschlüssel
in den Freimachungsvermerk eingeht.
-
Beispielsweise wird in den Freimachungsschlüssel ein
Krypto-String, wie
er beispielsweise in der Deutschen Patentanmeldung
DE 100 20 402 A1 offenbart
ist, eingebracht.
-
Zur weiteren Verbesserung des Schutzes
vor einer missbräuchlichen
Erstellung von Freimachungen erfolgt anlassbezogen ein Austausch
des Freimachungsschlüssels.
-
In dem dargestellten Fall erfolgt
eine Neuerstellung des Freimachungsschlüssels in regelmäßigen Abständen, beispielsweise
nach Ablauf eines vorgebbaren Zeitintervalls.
-
Es ist jedoch gleichfalls möglich, eine
Neuerstellung des Freimachungsschlüssels in Abhängigkeit
von anderen Parametern, beispielsweise der Anzahl der geladenen
Gebührenbeträge und/oder
der freigemachten Sendungen durchzuführen.
-
Eine Neuerstellung des neuen Freimachungsschlüssels kann
grundsätzlich
an einer beliebigen Stelle erfolgen. Zur Erhöhung der Datensicherheit ist
es jedoch zweckmäßig, den Übertragungsaufwand
für den
neuen Freimachungsschlüssel
zu minimieren und die Schlüsselerzeugung
in dem Wertübertragungszentrum,
beziehungsweise in dem Bereich des Wertübertragungszentrums, vorzunehmen.
-
Um einen hohen Schutz des Verfahrens
vor einem Missbrauch zu gewährleisten,
ist es vorteilhaft, dass im Bereich von lokalen Entgeltsicherungssystemen,
beispielsweise innerhalb von Brief- oder Frachtzentren, in den Freimachungsvermerken
enthaltene verschlüsselte
Informationen anhand eines Freimachungsschlüssels entschlüsselt werden.
-
Um dies zu gewährleisten, werden die Freimachungsschlüssel von
dem Wertübertragungszentrum
zu dem zentralen Entgeltsicherungssystem übertragen. Vorzugsweise erfolgt
die Übertragung
automatisiert.
-
Der Austausch erfolgt vorzugsweise über einen
Server des Entgeltsicherungssystems (ZinS Zentral Server). Das Wertübertragungszentrum
(Postage Point) braucht nicht konfiguriert werden. Da der Server
das Wertübertragungszentrum
(ZinS Lokal-Systeme)
und dessen zugehörige
Krypto-Systeme nicht kennen muss, ist für ihn einzig und allein der
ZinS Zentral Server von Bedeutung.
-
Nach Neugenerierung eines vorzugsweise
symmetrischen Freimachungsschlüssels
wird dieser gesichert an das zentrale Entgeltsicherungssystem übertragen – Verfahrensschritt
2 in 1 – und von
dort an die in den lokalen Entgeltsicherungssystemen befindlichen
Krypto-Systeme verteilt – Verfahrens schritt
3 in 1 -. Die lokalen
Entgeltsicherungssysteme geben das Ergebnis der Importoperation
zurück – Verfahrensschritt
4 in 1 – und bestätigen so
einen erfolgreichen Schlüsselimport.
Das Ergebnis wird von dem Zentral-System zusammengefasst, validiert
und entsprechend an das Wertübertragungszentrum
(Postage Point) übermittelt – Verfahrensschritt
5 in 1-.
-
Bei erfolgreichem Import auf allen
Krypto-Systemen der lokalen Entgeltsicherungssysteme wird der Schlüssel auf
dem Wertübertragungszentrum
(Postage Point) freigegeben und im Anschluss bei der Erstellung neuer
Portobeträge
verwendet – Verfahrensschritt
6 in 1 -.
-
Die vorzugsweise symmetrischen Schlüssel sind
ein wesentlicher Bestandteil der Fälschungssicherheit von mit
Hilfe des Freimachungsschlüssels
erzeugten Freimachungsvermerken, welche beispielsweise die Form
von zweidimensionalen Barcodes haben. Somit muss der Austausch dieser
Schlüssel
durch eine starke Kryptographie abgesichert sein. Um dies zu gewährleisten,
ist die Einhaltung der folgenden Punkte besonders wichtig:
- – Vertraulichkeit
des Inhalts: Die übertragenen
Schlüssel
dürfen
während
der Übertragung
nicht von Dritten ausgelesen werden können. Ferner muss auch sichergestellt
sein, dass die Schlüssel
sicher gespeichert und nicht von Dritten ausgelesen werden können. Letztere
Funktionalität
wird von der Web-Sentry – Kryptokarte
gewährleistet.
- – Integrität des Inhalts:
Dritten darf es nicht möglich
sein, Teile des Schlüssels
zu verfälschen.
- – Authentisierung:
Beide Kommunikationspartner müssen
Sicherheit darüber
erlangen, dass die Identität des
Senders/Empfängers
korrekt ist. Aus Sicht des Empfängers
bedeutet dies, dass der Schlüssel
vom Postage Point erstellt wurde. Aus Sicht des Senders muss sichergestellt
sein, dass nur gültige
Zins Lokal Krypto Systeme den Schlüssel erhalten dürfen.
-
Bei dem dargestellten symmetrischen
Verfahren besitzen beide Kommunikationspartner den gleichen Schlüssel KT.
Das Wertübertragungszentrum
(Postage Point) verschlüsselt
mit dem Schlüssel
KT den zu übertragenden
Datenschlüssel
KD und übergibt
diesen an den Server des zentralen Entgeltsicherungssystems (ZinS
Zentral-System).
-
Von dem zentralen Entgeltsicherungssystem
wird dieser Schlüssel
an die ZinS Lokalen Krypto-Systeme der lokalen Entgeltsicherungssysteme
weiterverteilt. Diese verfügen
ebenfalls über
KT und können
somit den Schlüssel
KD wieder entschlüsseln.
Da der Schlüssel
KT verwendet wird, um den Schlüssel
KD sicher beim Transport zu schützen,
wird er im Folgenden auch als Transportschlüssel bezeichnet.
-
Da alle lokalen Entgeltsicherungssysteme
die gleichen Daten erhalten, ist es nicht erforderlich, zwischen
jedem lokalen Krypto-Server und dem Wertübertragungszentrum (Postage
Point) einen separaten Transportschlüssel KT zu definieren. Aus
Sicherheitsgründen
sollte dieser Schlüssel
KT aber ähnlich
wie der Datenschlüssel
KD in regelmäßigen Abständen erneuert
werden. Da mit diesem Schlüssel
jedoch nicht so viel Text verschlüsselt wird wie mit dem Schlüssel KD,
kann das Wechselintervall breiter gewählt werden. Ein jährlicher
oder zweijähriger
Wechselabstand ist hier besonders vorteilhaft.
-
Ein wesentlicher Bestandteil dieser
Vorgehensweise ist der Schlüsselaustausch
der Transportschlüssel
KT, der aus Sicherheitsgründen
nicht über
denselben Kanal wie der Austausch der Datenschlüssel KD erfolgen sollte. Dieser
Austausch wird nicht manuell durchgeführt. Da dieser Vorgang in regelmäßigen Abständen für mehrere
der lokalen Entgeltsicherungssysteme erfolgen muss, ist hier ein
anderes Verfahren vorzuziehen, über
das die Transportschlüssel
ebenfalls automatisisert ausgetauscht werden können.
-
In dem Ansi-Standard X9.17 (Key Management
im Finanzumfeld auf der Grundlage symmetrischer Verfahren) wird
hierzu eine weitere Schlüsselebene
definiert, die mit Master-Transport-Schlüssel
(im Folgenden als KTM abgekürzt)
bezeichnet wird. Dieser Schlüssel
ist unter speziellen Sicherheitsvorkehrungen auf die Krypto-Karte
zu bringen und muss daher auch nur in großen Abständen gewechselt werden. Auf
allen Systemen wird dabei der gleiche KTM installiert. Mit diesem
Schlüssel
werden dann die Transportschlüssel
KT verschlüsselt,
die dadurch über
den gleichen Kanal automatisiert verteilt und eingespielt werden.
Die Verteilung erfolgt wie die Verteilung der Datenschlüssel. Die
Initialisierung der einzelnen Systeme, bzw. ihrer Kryptokarten wird
in den nachfolgenden Abschnitten detaillierter beschrieben.
-
Zur Sicherstellung der Integrität der Nachricht,
sowie der Authentisierung des Absenders (= Postage Point) wird für die einzelnen
Schlüsselnachrichten
ein Matrix-Code (MAC) gebildet. Zur Erstellung des MACs ist der
Signaturschlüssel
KS notwendig, der ebenfalls wie der KTM während der Initialisierung der
Krypto-Karten importiert wird. Die Signatur der Datenschlüsselnachrichten
erfolgt im Anschluss mit diesem KS. Die Sicherstellung der Vertraulichkeit
der Informationen während
der Übertragung
der Nachrichten im Intranet der Deutschen Post wird somit durch
die Verwendung dieser starken kryptographischen Verfahren garantiert.
Ein besonders bevor zugtes Verfahren zur Verschlüsselung und Entschlüsselung
von Nachrichten ist Triple DES (Schlüssellänge 168 Bit). Die Errechnung
von Hashwerten geschieht vorzugsweise mittels des SHA-1-Algorithmus.
-
Bei der Verteilung und Aufbewahrung
der Datenschlüssel
sind die unterschiedlichen Gültigkeitszeiträume, die
auf dem Postage Point und den Krypto-Systemen der Entgeltsicherungssysteme
existieren, zu berücksichtigen.
Auf dem Postage Point müssen
zu einem Zeitpunkt maximal zwei Schlüssel KD vorgehalten werden.
Ein Schlüssel,
der aktuell gültig
ist und ein weiterer Schlüssel
mit dem neu erzeugte Portobeträge
verschlüsselt
werden sollen (KDNeu).
-
Im Betriebsmodus ,Austausch' des existierenden
Schlüssels
mit dem Schlüssel
(KDNeu), wird der neue Schlüssel an
die Krypto-Systeme
der Entgeltsicherungssysteme übertragen.
Wurde dieser von allen Krypto-Systemen der lokalen Entgeltsicherungssysteme
erfolgreich eingespielt, erfolgt eine Freigabemeldung des ZinS Zentral-Systems
und KDNeu wird ab diesem Zeitpunkt für die Verschlüsselung
neuer Portobeträge
im Postage Point verwendet. Der alte KD sollte ab diesem Zeitpunkt
auf dem Postage Point gelöscht
werden, bzw. darf nicht weiter zum Erstellen neuer Portobeträge verwendet
werden.
-
Anders sieht es bei den Krypto-Systemen
der lokalen Entgeltsicherungssysteme aus: Da mit einem abgerufenen
Portobetrag noch für
einen vorgebbaren Zeitraum von beispielsweise drei Monaten Frankierungen
angefertigt werden können,
existieren dort mehrere Schlüssel
KD, die zur Prüfung
der Frankierungen zur Verfügung
stehen müssen.
-
Ferner gilt es bei der Verteilung
der Schlüssel
noch zu berücksichtigen,
was mit Schlüsseln
passiert, die auf einem Teil der Krypto-Systeme nicht importiert
werden konnten und daher auf dem Postage Point nicht aktiviert werden.
Es kann sein, dass diese Schlüssel
auf anderen Krypto-Systemen eingespielt wurden und dort prinzipiell
bei zukünftigen
Prüfungen
berücksichtigt
werden.
-
Um hier einen einheitlichen Stand
zu erreichen, der eine klare Versionierung der Schlüssel ermöglicht, sowie
eine möglichst
einfache Systemwartung zur Folge hat, ist folgende Durchführungsform
des Verfahrens der Schlüsselverteilung
besonders vorteilhaft:
- a) Datenschlüssel werden
mit einer eindeutigen Schlüssel-ID(Keyphasen-Indikator),
einem nicht eindeutigen Generationszähler und einem Verfallsdatum
für den
validen Vorgängerdatenschlüssel verschlüsselt übertragen.
Der Generationszähler
dient dazu, fehlerbedingte Mehrfach-Ladeversuche von gewollten Updates
der symmetrischen Datenschlüssel
unterscheiden zu können
(Gewährleistung
der Transaktionssicherheit, siehe (g)).
- b) Jede Übertragung
eines Datenschlüssels
von dem Wertübertragungszentrum
(Postage Point) sollte von dem zentralen Entgeltsicherungssystem
durch eine Bestätigungsmeldung
quittiert werden.
- c) Erfolgt eine positive Quittierung, ist der Datenschlüssel in
allen lokalen Entgeltsicherungssystemen erfolgreich installiert
worden und kann von PC-Frankierung an die Kunden ausgegeben werden.
In diesem Fall wird für
die Übertragung
eines nachfolgenden Datenschlüssels
der Generationszähler
um eins erhöht.
- d) Erfolgt eine negative Quittierung, ist der Datenschlüssel nicht
in allen lokalen Entgeltsicherungssystemen erfolgreich installiert
worden und sollte von dem Wertübertragungszentrum
nicht an für
die Erzeugung von Freimachungsvermerken vorgesehene Kundensysteme
ausgegeben werden, da sonst eine Massenausschleusung valider Sendungen
droht. In diesem Fall wird für
die Übertragung
eines nachfolgenden Datenschlüssels
der Generationszähler
nicht um eins erhöht,
d.h. er bleibt auf dem Wert der Vorgängerübertragung.
- e) Erfolgt keine Quittierung, kann das Wertübertragungszentrum (Postage
Point) zwischenzeitlich keine weitere Schlüsselübertragung an das zentrale
Entgeltsicherungssystem (ZinS Zentral) starten (derartige Versuche
würden
zwar von dem Entgeltsicherungssystem ignoriert, sollten in dem Wertübertragungszentrum
jedoch auch blockiert werden).
- f) Bleibt eine Quittierung seitens des Entgeltsicherungssystems
für längere Zeit
aus (Timeout-Überschreitung),
kann das Wertübertragungszentrum
(Postage Point) über
seine direkte oder indirekte Benutzerschnittstelle einen Alarm auslösen.
- g) Sobald eine Kryptokarte einen Datenschlüssel empfängt, löscht sie alle Datenschlüssel, die
den gleichen Generationszähler-Wert
haben, wie die jüngste Übertragung.
Damit ist sichergestellt, dass bei fehlerbedingter Mehrfachübertragung
Schlüssel, die
zuvor nur auf einen Teil aller Kryptokarten erfolgreich geladen werden
konnten, gelöscht
werden. Dies ermöglicht
eine transaktionssichere Schlüsselübertragung.
- h) Auf den Kryptokarten in den lokalen Entgeltsicherungssystemen
wird mehrfach, vorzugsweise regelmäßig, insbesondere täglich eine
Routine aufgerufen, welche die nicht mehr benötigten Datenschlüssel löscht. Ein
Datenschlüssel
wird dann gelöscht
(in einer zweckmäßigen Ausführungsform
zusätzlich
zu Punkt g)), wenn das bei dem Nachfolge-Datenschlüssel im
Attribut CKA_END_DATE gespeicherte Verfallsdatum kleiner ist als
das aktuelle Systemdatum.
- i) Bei dem Verfallsdatum für
den Vorgängerschlüssel sollte
eine (so klein wie mögliche)
Karenzzeit eingeplant werden, da zu einem abgelaufenen Portobetrag
erstellte Frankierungen noch zwei Tage nach Gültigkeitsende bei der Prüfung im
Bereich des lokalen Entgeltsicherungssystems als valide erkannt
werden. Ferner ist auch ein Time-Lag zwischen Erstellung und Freigabe
eines neuen Datenschlüssels
zu berücksichtigen.
-
2 zeigt
eine Übersicht über Einsatzbereiche
des dargestellten Schlüsselmanagements
und ihres Einsatzes im Bereich der Entgeltsicherung. Ferner sind
bevorzugte Anwendungsbereiche dargestellt.
-
Die Anwendungsfälle werden im Folgenden detaillierter
beschrieben.
-
Nachfolgend werden Einzelheiten des
beschriebenen Schlüssel verwaltungsverfahrens
dargestellt.
-
Die beschriebenen Anwendungen sind
beispielhaft bei Einsatz von Krypto-Karten dargestellt.
-
Zunächst wird dargestellt, wie
die Krypto-Karte in dem Bereich des Wertübertragungszentrums initialisiert
wird:
- – Einbau
und Konfiguration der Karte, Aufspielen der Kartenfirmware, sofern
vom Hersteller nicht bereits erfolgt. Die Firmware wurde durch Embedded
Code (eigene Software-Routinen) in ihrer Funktionalität erweitert,
und aus Sicherheitsgründen
sollten die Pkcs#11 spezifischen Schlüssselroutinen (Generierung,
Löschung
usw.) gesperrt sein für
den Anwender. So wird eine höhere
Schlüsselsicherheit
auf der Karte gewährleistet.
- – Definition
von Clustern (bei mehreren Krypto-Karten)
- – Erstellung
und Speicherung eines lokalen Master Key LMK. Der LMK sollte dabei
mindestens auf drei Komponenten verteilt werden, von denen zwei
Komponenten zur Wiederherstellung, bzw. Neuintialisierung von Krypto-Server-Karten
besonders vorteilhaft sind. Vorzugsweise jede der Komponenten wird
PIN-geschützt
auf SmartCards geschrieben, wobei die Sicherheitsadministratoren
eine SmartCard erhalten. Zusätzlich
sollten auch noch Backup-SmartCards erstellt werden. Der LMK dient
im Folgenden als der oben beschriebene Master-Transport-Schlüssel KTM.
- – Benutzerverwaltung:
Löschen
des Default-Sicherheitsadministrators
und Definition der Sicher heitsadministratoren inkl. notwendiger
Authentifizierungsregeln (Smatcard-basiert)
- – Generierung
eines initialen Signierschlüssels
KS, Verschlüsselung
(Wrapping) mit dem KTM und Speicherung als Datei. Das spätere Kopieren
dieser Datei auf Diskette sollte möglich sein. (Zugriff auf die
Datei/Diskette sollte nur den Sicherheitsadministratoren möglich sein.)
- – Generierung
eines ersten Transportschlüssels
KT, Erstellung der zugehörigen
Schlüsselnachricht
und Speicherung der Nachricht in einer Datei, sowie späteres Kopieren
dieser Datei auf Diskette (Zugriff sollte nur für Sicherheitsadministratoren
möglich
sein).
-
Erzeugen der
Transport-Master-Schlüssel
-
Die Erzeugung neuer Transport-Master-Schlüssel (KTM)
erfolgt vorzugsweise auf die nachfolgend dargestellte Weise. Als
KTM dient der Local Master Key einer entsprechenden Berechtigungskarte.
Aus Sicherheitsgründen
sollte der LMK in mindestens drei Komponenten aufgeteilt werden,
von denen mindestens zwei Komponenten zum Wiedereinspielen benötigt werden.
-
Die einzelnen Komponenten werden
auf SmartCards gespeichert, wobei jeder Sicherheitsadministrator
eine SmartCard erhält
und diese durch eine individuelle PIN sichert. Durch Geheimhaltung
der PIN und Verwahrung der SmartCards an einem sicheren Ort muss
verhindert werden, dass unbefugte Personen Zugriff darauf erhalten
können.
-
Für
eine Implementation der Transport-Master-Schlüssel sind vorzugsweise wenigstens
zwei LMK-Komponenten – entsprechend
zwei verschiedenen Berechtigungskarten – vorgesehen, so dass hierdurch
eine automatisierte Implementation eines 4-Augen-Prinzips erfolgt.
-
Bei dem KTM muss es sich um einen
Triple DES-Schlüssel
handeln. Das ID-Attribut des Schlüssels besteht aus einem Typkennzeichen
und einer eindeutigen Nummer.
Typkennzeichen : KT
Eindeutige
Nummer : 01 bis 99.
Länge
: fix 4 Byte wird als CK_CHAR[] hinterlegt.
-
Grundsätzlich eignen sich verschiedene
Sicherungsmechanismen zur Sicherstellung, dass nur berechtigte Personen
in der Lage sind, einen Wechsel der Schlüssel durchzuführen. Die
nachfolgend dargestellte Ausführungsform
unter Einsatz von Signierschlüsseln
ist jedoch besonders vorteilhaft, da sie eine besonders hohe Sicherheit
vor einer Manipulation ermöglicht.
-
Der Signierschlüssel stellt die Integrität der Schlüsselnachrichten
sicher. Mit ihm kann ferner vor dem Import des Schlüssels festgestellt
werden, ob es sich bei dem Absender der Schlüsselnachricht um den Postage
Point handelt. Die Signierschlüsselgenerierung
sollte nur von einem über
Smart Card angemeldeten Sicherheitsadministrator durchgeführt werden
können.
Es sollte sich hierbei um einen TDES-Schlüssel handeln, der die Sicherheitsattribute
Sensitive auf „True" und Extractable
auf „False" gesetzt hat, um
eine Ermittlung des Schlüsselklartexts
außerhalb
der Karte zu verhindern. Das ID-Attribut
des Schlüssels
besteht aus einem Typkennzeichen und einer eindeutigen Nummer.
Typkennzeichen
: KS
Eindeutige Nummer : 01 bis 99.
Länge : fix 4 Byte wird als CK_CHAR[]
hinterlegt.
-
Zum Export des Schlüssels ist
dieser mit dem KTM zu wrappen und wird im Anschluss als Datei auf Diskette
gesichert. Die Diskette ist sicher aufzubewahren und dient der Initialisierung
der Krypto-Server-Karten. Die Integrität der Schlüsseldatei wird durch vorzugsweise
in den Karten enthaltene Verarbeitungsroutine sichergestellt, die
zum Wrappen verwendet wird.
-
Bevorzugte Attribute der Transportschlüssel KS
sind in der nachfolgenden Tabelle dargestellt.
-
-
Die Zufallszahl im Attribut Label
dient zur Bestätigung
des erfolgreichen Imports auf den Krypto-Server-Karten. Zu dieser
Zufallszahl wird ein Hash-Wert (beispielsweise mittels SHA-1) gebildet
und dieser zur Bestätigung
des erfolgreichen Imports, sowie zur Freischaltung des Transportschlüssels verwendet.
-
Die Attribute CKA_ID und CKA_LABEL
sind als CK_CHAR zu besetzen. Alle weiteren Attribute sind im Typ
definiert über
die Pkcs11.h Datei.
-
Der Signierschlüssel wird mit dem KTM(=LMK,
Mechanismus CKM_KEY_WRAP_WEBSENTRY) verschlüsselt und wird wie der LMK
vor Ort auf die Hardware aufgespielt.
-
Nachfolgend wird die Erzeugung des
Transportschlüssels
dargestellt.
-
Bei diesem Anwendungsfall wird ein
Transportschlüssel
inklusive zugehöriger
Schlüsselnachricht
erstellt. Vorzugsweise ist das Schlüsselerstellungsmodul so beschaffen,
dass die Erstellung des Transportschlüssels und/oder der zugehörigen Schlüsselnachricht
nur durch einen Sicherheitsadministrator ausgelöst werden kann. Das Wechselintervall
sollte jährlich
oder zweijährlich
sein.
-
Bei dem Transportschlüssel handelt
es sich wiederum um einen TDES-Key mit folgenden Attributsettings:
-
Die Zufallszahl im Attribut Label
dient zur Bestätigung
des erfolgreichen Imports auf den Krypto-Server-Karten. Zu dieser
Zufallszahl wird ein Hash-Wert (mittels SHA-1) gebildet und dieser
zur Bestätigung
des erfolgreichen Imports, sowie zur Freischaltung des Transportschlüssels verwendet.
-
Die Attribute CKA_ID und CKA_LABEL
sind als CK_CHAR [] zu besetzen. Alle weiteren Attribute sind im
Typ definiert über
die Pkcs11.h Datei.
-
Der Transportschlüssel wird mit dem KTM(=LMK,
Mechanismus CKM_KEY_WRAP_WEBSENTRY) verschlüsselt, und es wird eine Nachricht
für die Übermittlung
von dem Wertübertragungszentrum
zu dem zentralen Entgeltsicherungssystem mit folgendem Aufbau gebildet:
-
Diese Transportschlüsselnachricht
wird im Anschluss zur Weiterverteilung an den ZinS Zentral-Server übergeben.
Die Schnittstelle wird als Session Bean realisiert, das Auffinden
dieses Dienstes erfolgt mittels eines Namensdienstes (JNDI). Die
Methode zum Transport soll den oben aufgeführten Datenblock erwarten.
-
Weiterhin wird die Nachricht auf
dem Postage Point als Datei gespeichert, um von den Sicherheitsadministratoren
später
auf einer oder mehreren sicher zu verwahrenden Disketten gespeichert
werden zu können.
Die Disketten finden dann im Anschluss bei der Initialisierung neuer
Krypto-Server-Karten Verwendung.
-
Nachfolgend wird ein bevorzugtes
Ausführungsbeispiel
für das
Freischalten der Transportschlüssel
erläutert.
-
Das Wertübertragungszentrum ist so gestaltet,
dass es den Transportschlüssel
KT freischalten kann. Zur Freischaltung des Transportschlüssels KT
ist eine Schnittstelle vorgesehen, über die das zentrale Wertübertragungszentrum
nach erfolgreicher Verteilung und erfolgreichem Import eines Transportschlüssels auf
allen lokalen Entgeltsicherungssystemen (ZinS Krypto Systemen) diesen
Transportschlüssel
freischalten kann. Erst durch die Freischaltung wird der betroffene
Transportschlüssel
im Folgenden für
die Verschlüsselung
von Datenschlüsseln
(KD) verwendet.
-
Die Schnittstelle wird als Session
Bean realisiert. Das Auffinden dieses Dienstes erfolgt mittels eines Namensdienstes.
-
Die Datenstruktur zur Freischaltung
besitzt vorzugsweise folgende Parameter:
-
Die Authentisierung des Schlüsselzuweisungssystems
des Entgeltsicherungssystems (ZinS-KeyManagement-Systems) gegenüber dem
PP-KeyManagement-System erfolgt über
den Parameter 2. Es handelt sich hierbei um einen Hashwert, der
mittels des Verfahrens SHA-1 aus dem Attribut Label des Transportschlüssels gebildet
wird. Das Attribut Label wird bei der Generierung des Transportschlüssels mit
einem Zufallswert belegt. Da der Transportschlüssel und alle seine Attribute
während
der Übertragung
verschlüsselt
sind, kann nur der ZinS Krypto-Server den korrekten Hashwert errechnen.
-
Ist der übergebene Hash-Wert identisch
mit dem zu dem Label-Attribut
berechneten Hashwert des KTs, der sich auf dem PostagePoint-Web
Sentry Modul befindet und ist der übergebene Verarbeitungsstatus =
true, dann wird der Transportschlüssel aktiviert. Dies bedeutet,
dass im Folgenden die Datenschlüsselnachrichten
mit dem Transportschlüssel
verschlüsselt
werden.
-
Eine Variante dieses Anwendungsfalls
besteht bei einer fehlerhaften Verarbeitung (übergebener Status = false).
In diesem Fall wird der Status zu dieser Schlüsselgenerierung und -verteilung
protokolliert und der zugehörige
Transportschlüssel
wird entsprechend gelöscht.
-
Nachfolgend wird ein bevorzugtes
Beispiel einer Generierung neuer Datenschlüssel dargestellt.
-
Bei diesem Anwendungsfall wird ein
Datenschlüssel
inklusive zugehöriger
Schlüsselnachricht
erstellt. Vorzugsweise ist das Schlüsselzuweisungssystem so beschaffen,
dass diese Aktion nur von einem Sicherheitsadministrator ausgelöst werden
kann. Sie sollte vierteljährlich
erfolgen. Existiert ein Datenschlüssel KD im Umlauf, zu dem von
dem zentralen Entgeltsicherungssystem (ZinS Zentral-System) noch
keine Rückmeldung (Freigabe,
bzw. Fehler) erfolgt ist, so wird die Generierung neuer KD so lange
blockiert, bis die Rückmeldung erfolgt.
-
Der Datenschlüssel (KD) dient zur Verschlüsselung
bestimmter Matrixcodeinhalte und stellt darüber sicher, dass keine gültigen Freimachungsvermerke
erstellt werden können,
die nicht gegenüber
dem Postunternehmen abgerechnet wurden. Auf den ZinS Krypto-Servern
dient dieser Datenschlüssel
zur Verifizierung der digitalen Freimachungsvermerke.
-
Bei den Datenschlüsseln handelt es sich ebenfalls
um TDES-Keys, die
mit Hilfe der PKCS#11-Funktion C_GenerateKey erzeugt werden und
folgende Attribute besitzen:
-
Die Werte für das Attribut CKA_ID und den
Generationszähler
werden von dem System vorgegeben. Die CKA_ID wird dabei immer um
eins hochgezählt,
der Generationszähler
nur bei erfolgreicher Schlüsselfreigabe.
Die Attribute CKA_ID und CKA_LABEL sind als CK_CHAR [ ] zu besetzen.
Alle weiteren Attribute sind im Typ definiert über die Pkcs11.h Datei.
-
Die Zufallszahl im Attribut Label
dient zur Bestätigung
des erfolgreichen Imports auf den Krypto-Server-Karten. Zu dieser
Zufallszahl wird ein Hash-Wert (mittels SHA-1) gebildet und dieser
zur Bestätigung
des erfolgreichen Imports, sowie zur Freischaltung des Datenschlüssels verwendet.
-
Die Erstellung einer Nachricht zum
Austausch der Datenschlüssel
ist etwas komplexer und besteht aus dem folgenden Ablauf:
- 1. Der Datenschlüssel wird mit dem KTM(=LMK,
Mechanismus CKM_KEY_WRAP_WEBSENTRY) verschlüsselt. Dies hat den Vorteil,
dass auch alle Attribute des Schlüssels (u.a. CKA_EXTRACTABLE=false) mit
verschlüsselt
werden und bei der Entschlüsselung
automatisch wieder richtig gesetzt sind. Mit dieser verschlüsselten
Bytefolge wird eine Zwischennachricht mit folgendem Aufbau gebildet:
- 2. Die Zwischennachricht wird wiederum mit dem aktiven Transportschlüssel KT
verschlüsselt
unter Zuhilfenahme des Mechanismus CKM_DES3_CBC_PAD (der IV wird
mit Nullen gefüllt).
- 3. Es wird die zu verteilende Nachricht gebildet, die folgenden
Aufbau besitzt:
- 4. Im Anschluss wird die Datenschlüsselnachricht zur Weiterverteilung
an den ZinS Zentral-Server übergeben.
weiterhin wird er von den Sicherheitsadministratoren auf einer oder
mehreren sicher zu verwahrenden Disketten gespeichert, um zur Initialisierung
neuer ZinS Krypto-Server-Karten
verwendet werden zu können.
-
Der Vorteil der doppelten Verschlüsselung
des Nachrichteninhalts liegt darin, dass weniger Chiffretext zu
dem KTM über
das Intranet übertragen
werden muss und dadurch eine Kryptoanalyse dieses Schlüssels wesentlich
erschwert wird.
-
Für
die Freischaltung des Datenschlüssels
KD sind eine Schnittstelle und ein Protokollmechanismus vorgesehen,
durch den die Freischaltung des Datenschlüssels protokolliert wird. Das
zentrale Entgeltsicherungssystem ist vorzugsweise so geschaffen,
dass erst nach erfolgreicher Verteilung und erfolgreichem Import eines
Datenschlüssels
auf den Krypto-Systemen
der lokalen Entgeltsicherungssysteme der Datenschlüssel freigeschaltet
wird. Erst durch die Freischaltung wird der betroffene Datenschlüssel im
Folgenden für
die Verschlüsselung
von in die Freimachungsvermerke einzubringenden Krypto-Strings verwendet
und die zugehörige
Schlüsselidentifikationsangabe
KeyID in der Identifikationsangabe (PostageID) von Portobeträgen codiert.
-
Die Schnittstelle wird über CWMS
zwischen dem zentralen Entgeltsicherungssystem (ZinS Zentral) und
dem lokalen Entgeltsicherungssystem (ZinS Lokal) realisiert. Das
Wertübertragungszentrum
(Postage Point) PP erhält
die Information über
das entsprechende Bean. Die Datenstruktur zur Freischaltung besitzt
folgende Inhalte:
-
Die Authentisierung des Schlüsselzuweisungssystems
des Entgeltsicherungssystems gegenüber dem Schlüsselzuweisungssystem
des Wertübertragungszentrums
PP erfolgt über
den Parameter 2. Es handelt sich hierbei vorzugsweise um einen Hashwert,
der mittels des Verfahrens SHA-1 aus dem Attribut Label des Datenschlüssels gebildet
wird. Das Attribut Label wird bei der Generierung des Datenschlüssels mit
einem Zufallswert belegt. Da der Datenschlüssel und alle seine Attribute
während
der Übertragung
verschlüsselt
sind, kann nur vom Krypto-Server des Entgeltsicherungssystems der
korrekte Hashwert errechnet werden.
-
Ist der übergebene Hash-Wert identisch
mit dem zu dem Label-Attribut
berechneten Hashwert des KDs, der sich auf dem PostagePoint-Web
Sentry Modul befindet, und ist der übergebene Verarbeitungsstatus =
true, dann wird der Datenschlüssel
aktiviert. Dies bedeutet, dass im Folgenden die Krypto-Strings zu
den Freimachungsvermerken/Portobeträgen mit diesem Datenschlüssel verschlüsselt werden.
Bei der Aktivierung eines Datenschlüssels wird der Generationszähler der
Datenschlüssel
um eins erhöht.
-
Eine Variante dieses Anwendungsfalls
besteht bei einer fehlerhaften Verarbeitung (übergebener Status = false).
In diesem Fall wird der Status zu dieser Schlüsselgenerierung und -verteilung
protokolliert und der zugehörige
Datenschlüssel
wird entsprechend auf der Karte gelöscht. Der Generationszähler wird
in diesem Fall nicht um eins erhöht.
-
Vorzugsweise enthalten die Schlüsselzuweisungssysteme
einen Statusspeicher zur Speicherung von vorgenommenen Schlüsselgenerierungen.
Solange noch keine Rückmeldung
von dem zentralen Entgeltsicherungssystem (ZinS Zentral-System)
zur vorgenommenen Schlüsselverteilung
erfolgt ist, wird der Status als offen angezeigt. Bei erfolgreicher.
Rückmeldung
und Freigabe wird der Schlüssel
als aktiviert gekennzeichnet. Im Fehlerfall wird die übergebene
Statusmeldung angezeigt.
-
Bei Fehlern oder bei längerzeitigem
Ausbleiben einer Freigabemeldung wird eine Fehlerklärungsroutine
aufgerufen.
-
Es ist zweckmäßig, eine Archivierung der
Schlüssel
vorzusehen. Nachfolgend wird eine bevorzugte Archivierung der Schlüssel im
Bereich des Wertübertragungszentrums
dargestellt. Zur Sicherung der Schlüssel kann der Sicherheitsadministrator
eine Archivierungsfunktion starten, die alle Schlüssel (Ausnahme
KTM) mit dem KTM verschlüsselt
(Mechanismus CKM_KEY_WRAP_WEBSENTRY) und zurückgibt. Diese Schlüssel sollten
gesichert in der Datenbank oder in einem gesicherten Filesystembereich
gespeichert werden.
-
Nach erfolgreicher Archivierung werden
alle Schlüssel
gelöscht,
die ihr Gueltig – Ab – Datum
um mehr als 6 Monate überschritten
haben und nicht mehr aktiv sind.
-
Die Restaurierung von Schlüsseln – insbesondere
im Bereich des Wertübertragungszentrums
PP – geschieht
dadurch, dass die archivierten Schlüsseldaten wieder entschlüsselt (Unwrap)
und auf der Karte gespeichert werden. Der verwendete Mechanismus
ist wiederum CKM_KEY_WRAP_WEBSENTRY.
-
Nach dem Entschlüsseln eines Schlüssels wird
ein bereits auf der Karte bestehender Schlüssel mit gleicher Schlüsselidentifikationsangabe
KeyID gelöscht.
-
Durch besondere Sicherheitsmaßnahmen
sowohl der WebSentry-Karte,
als auch durch die Verteilung auf mehrere SmartCards ist der Master-Transportschlüssel KTM
sicher vor Kompromittierung geschützt.
-
Falls dennoch ein Austausch des Master-Transportschlüssels durchgeführt werden
soll, muss analog zum Anwendungsfall eines Initialisierens einer „Kryptokarte" (PP) ein neuer KTM
und auch neue Signier-, Transport- und Datenschlüssel müssen erstellt werden.
-
Der bisherige KTM bleibt als sogenannter „dormant
LMK" auf der Karte
bestehen und muss von dem Sicherheitsadministrator entsprechend
gelöscht
werden.
-
Nachfolgend werden bevorzugte Anwendungsfälle des
Schlüsselzuweisungssystems
beschrieben. Die Darstellung gilt auch für Anwendungen in allen Bereichen
des Entgeltsicherungssystems. Falls einzelne Bestandteile vorzugsweise
im Bereich des lokalen Entgeltsicherungssystems oder des zentralen
Entgeltsicherungssystems implementiert werden, ist dies besonders
vorteilhaft. Ein Einsatz in dem jeweiligen anderen Entgeltsicherungssystem
ist jedoch gleichfalls möglich.
-
Ein erster Anwendungsfall ist die
Initialisierung der Krypto-Karte
im Bereich des Entgeltsicherungssystems.
-
Zur Initialisierung der Krypto-Karte
sind folgende Grundkonfigurationen vorzunehmen, wobei ein Großteil der
Funktionalität über ein
Administrationswerkzeug (WebSentry Manager) erledigt werden kann:
- – Einbau
und Konfiguration der Karte, Aufspielen der Kartenfirmware, sofern
vom Hersteller nicht bereits erfolgt. Die Firmware enthält den Embedded
Code (eigene Software-Routinen) (Letztere Funktionalität wird in
WebSentryManager integriert)
- – Definition
von Clustern (bei mehreren Kryptokarten) (WebSentryManager)
- – Einspielen
der Transport-Master-Schlüssel
(KTM), siehe separaten Anwendungsfall (Funktionalität wird von
WebSentryManager bereitgestellt)
- – Benutzerverwaltung:
Löschen
des Default-Sicherheitsadministrators
und Definition der Sicherheitsadministratoren inkl. notwendiger
Authentifizierungsregeln (Smartcard-basiert) Erstellung zweier „normaler" Benutzer (einer
für Schlüsselprüfung/ einer
für Schlüsselimport),
die sich über
eine vorgegebene PIN authorisieren. Die Funktionalität der Benutzerverwaltung
wird ebenfalls von dem WebSentryManager bereitgestellt.
- – Einspielen
der Signierschlüssel
(KS); Siehe separaten Anwendungsfall
- – Einspielen
der Transportschlüssel
(KT); Siehe separaten Anwendungsfall
- – Gegebenenfalls
noch Einspielen der Datenschlüssel
(KD); (siehe ebenfalls eigenen Anwendungsfall), sofern diese bereits
generiert wurden.
-
Die Schlüssel sind dabei in der oben
definierten Reihenfolge einzuspielen. Die Karteninitialisierung kann
an einem zentralen Ort erfolgen, wobei der komplette Krypto System-Rechner initialisiert
und anschließend
versendet werden muss. Dies liegt daran, dass die WebSentry-Karte
den internen Speicher löscht,
sobald sie aus dem PCI-Slot gezogen wird.
-
Das Einspielen der Transport-Master-Schlüssel kann
vorzugsweise nur von mindestens zwei Sicherheitsadministratoren
vorgenommen werden, die sich mit einem SmartCard-Leser und zugehörigen SmartCards
lokal gegenüber
dem Krypto System identifiziert haben. Aufgrund der Wichtigkeit
des Schlüssels
KTM wird dieser Schlüssel
nur im Vier-Augen-Verfahren auf der Karte eingespielt. Dies bedeutet,
dass zum Einspielen mindestens zwei der PIN-geschützten SmartCards benötigt werden,
die im Anwendungsfall „Transport-Master-Schlüssel erzeugen" erstellt wurden.
-
Dadurch dass der Master-Transportschlüssel KTM
nur durch beide SmartCards auf die Karte geladen werden kann und
da die Schlüsselverwendung
PIN-gesichert erfolgt, ist gewährleistet,
dass dieser Schlüssel nur
im Vier-Augen-Prinzip auf die Karte gebracht werden kann. Es ist
dadurch ein sehr hoher Schutz vor Ausspionage des Schlüssels gegeben.
-
Diese Funktionalität wird über das
Administrationswerkzeug Web Sentry Manager bereitgestellt. Das Administrationswerkzeug
gibt eine Möglichkeit,
einen sogenannten Local Master Key (LMK entspricht dem in diesem
Konzept beschriebenen KTM) über
SmartCards zu laden und diesen in einem sicheren Speicherbereich
der Karte zu speichern.
-
Es ist besonders vorteilhaft, den
LMK auf drei Smartcards aufzuteilen, wobei alle drei Teile benötigt werden,
um den LMK auf die Kryptohardware einzuspielen. In diesem Fall werden
für das
Einspielen der Master-Transportschlüssel KTM drei Sicherheitsadministratoren
benötigt.
-
Der Signierschlüssel stellt die Integrität der Schlüsselnachrichten
sicher, mit ihm kann ferner vor dem Import des Schlüssels festgestellt
werden, ob es sich bei dem Absender der Schlüsselnachricht um das Wertübertragungszentrum
(Postage Point) handelt. Die Generierung des Signierschlüssels kann
auf verschiedene Weise erfolgen, wobei die dargestellten Beispiele
besonders vorteilhaft sind. Die zugehörige Schlüsselnachricht wird von dem
Administrator auf einer Diskette gespeichert und wird über diesen
Anwendungsfall auf einer zu initialisiserenden Krypto-Karte des
Entgeltsicherungssystems eingespielt.
-
Zum Einspielen des Schlüssels wird
die auf der Diskette gespeicherte Schlüsselnachricht mit dem Master-Transportschlüssel KTM
entschlüsselt
(PKCS#11-Funktion C_Unwrap, Mechanismus CKM_KEY_WRAP_WEBSENTRY).
Die Integrität
der Schlüsselnachricht
wird durch diese Routine automatisch überprüft. Sollte bereits ein Schlüssel mit
dieser KeyID existieren, so wird dieser im Anschluss gelöscht.
-
Zum Weitertransport der Transportschlüsselnachrichten
wird von dem Server des zentralen Entgeltsicherungssystems eine
Schnittstelle bereitgestellt, über
die die Verteilung und der anschließende Import auf den Krypto-Systemen
der einzelnen lokalen Entgeltsicherungssysteme angeregt werden kann.
-
Die Schnittstelle wird als RMI-Dienst
realisiert. Das Auffinden dieses Dienstes erfolgt mittels eines
Namensdienstes (JNDI). Die Verteilung erfolgt über das zur Verteilung der
P/N-Liste verwendete CWMS.
-
Wird ein neuer Verteilauftrag erstellt,
so wird die Schlüsselnachricht
an alle zur Zeit registrierten Krypto Systeme weitergeleitet und
jeweils ein Protokolleintrag geschrieben. Die Verwaltung der Krypto
Systeme erfolgt über
einen Anwendungsfall des Entgeltsicherungssystems.
-
Auf den einzelnen Krypto Servern
wird der Empfang neuer Schlüsselnachrichten
in regelmäßigen Abständen (abhängig vom
Verteilmechanismus) von einem ImportController geprüft. Bei
Empfang einer neuen Nachricht wird der Anwendungsfall „Transportschlüssel einspielen" automatisch angestoßen. Der
Rückgabewert
dieser Aktion wird geprüft.
Sollte eine negative Rückmeldung
kommen, so wird der Importversuch bis zu drei Mal wiederholt.
-
Ist nach dreimaligem Versuch der
Import immer noch nicht möglich,
so wird eine Protokollmeldung über
den Misserfolg an das ZinSZentral-System gesandt (wiederum abhängig vom
Transportmechanismus). Bei erfolgreichem Import erfolgt eine positive
Protokollmeldung.
-
Die Protokollmeldungen werden zentral über den
Anwendungsfall „Schlüsselverarbeitung
protokollieren" verarbeitet.
Entsprechend wird auch die Freigabe des Transportschlüssels ausgelöst.
-
Ein Einspielen der Transportschlüssel wird
entweder von einem Sicherheitsadministrator ausgeführt, der
vor Ort an dem Krypto System die Initialisierung durchführt, oder
er wird durch den ImportController der Schlüsselverteilung automatisch
ausgelöst,
wenn dieser eine neue Transportschlüsselnachricht empfängt.
-
Der Import des Schlüssels erfolgt
vorzugsweise entsprechend der nachfolgenden Verfahrensschritte:
- 1. Es erfolgt eine Anmeldung an der Karte mit
der zu dem KeyImport-Benutzer zugehörigen ID und PIN.
- 2. Zu den Feldern 1–5
der Transportschlüsselnachricht
wird mittels des Verfahrens SHA-1 ein Hashwert gebildet.
- 3. Es wird der Signierschlüssel
ermittelt, der die KeyID besitzt, die in dem Feld 4 angegeben wurde.
- 4. Mit diesem Schlüssel
wird der unter Punkt 2 gebildete Hashwert verschlüsselt (Mechanismus CKM_DES3_CBC_PAD,
der IV wird mit Nullen gefüllt)
und mit Feld 6 verglichen. Stimmen beide Werte überein, ist die Integrität gesichert
und es ist sichergestellt, dass die Nachricht vom PC-F-System erstellt wurde.
- 5. Der Inhalt des Feldes 5 der Nachricht wird mit dem KTM entschlüsselt (Methode
C_UnwrapKey, Mechanismus CKM_KEY_WRAP_WEBSENTRY). Hierdurch wird
automatisch das entsprechende Transportschlüsselobjekt auf der Karte erzeugt
und gespeichert. Zusätzlich
wird durch den Mechanismus wiederum die Integrität des Schlüssels als auch der korrekte
Absender implizit mitgeprüft.
- 6. Sollte bereits ein Schlüssel
mit gleicher KeyID auf der Karte existieren, so wird dieser gelöscht.
- 7. Es wird zu dem Attribut Label des neu importierten Schlüssels ein
Hashwert nach dem Verfahren SHA-1 gebildet und dieser zusammen mit
der KeyID und der Positivmeldung als Rückgabewert zurückgeliefert.
- 8. Die Benutzersession wird beendet.
- 9. Aus den Rückgabewerten
wird eine Protokollnachricht generiert und diese an das ZinS Zentral-System gesendet.
- 10. Etwaige zu dieser KeyID gespeicherte Fehlversuche (s. unten
beschriebene Variante) werden zurückgesetzt.
-
Eine Variante dieses Anwendungsfalls
besteht darin, dass eine der Routinen oder die Überprüfung des MACs fehlschlägt. In diesem
Fall wird die weitere Verarbeitung abgebrochen, und es wird ein
Rückgabewert zurückgeliefert,
der die KeyID, den Fehlercode, sowie eine Fehlernachricht enthält. Zu der
KeyID wird die gespeicherte Anzahl der Fehlversuche um eins erhöht. Sollte
sie bei drei angelangt sein, so wird aus dem zuletzt übergebenen
Rückgabewert
eine Protokollnachricht generiert und an das zentrale Entgeltsicherungssystem gesendet.
-
Im Falle des manuellen Anstoßes wird
das Ergebnis des Imports zusätzlich
am Bildschirm des Sicherheitsadministrators angezeigt.
-
Vorzugsweise laufen die Schritte
2–7 direkt
in der Kartensoftware (Embedded Code) ab. Dies erhöht sowohl
die Performance als auch die Sicherheit vor einem Ausspioniertwerden.
-
Für
den Weitertransport der Datenschlüsselnachrichten wird von dem
Server des zentralen Entgeltsicherungssystems eine weitere Schnittstelle
bereitgestellt, über
die die Verteilung und der anschließende Import der Datenschlüssel auf
die einzelnen Krypto-Systeme der lokalen Entgeltsicherungssysteme
erfolgt.
-
Die Schnittstelle wird als Session
Bean realisiert, das Auffinden dieses Dienstes erfolgt mittels eines Namensdienstes
(JNDI).
-
Die Verteilung erfolgt vorzugsweise über das
zur Verteilung der P/N-Liste verwendete CWMS.
-
Wird ein neuer Verteilauftrag erstellt,
so wird die Schlüsselnachricht
an alle zur Zeit registrierten Krypto Systeme weitergeleitet und
jeweils ein Protokolleintrag geschrieben. Die Verwaltung der Krypto
Systeme erfolgt über
ein Zuweisungssystem. Sollte bereits ein Verteilauftrag für einen
Datenschlüssel
im Umlauf sein, zu dem noch keine Rückmeldung beim Wertübertragungszentrum
PP erfolgt ist, so wird bis zum Zeitpunkt der Rückmeldung die Annahme weiterer
Verteilaufträge
für Datenschlüssel abgewiesen.
-
Auf den einzelnen Krypto Servern
wird der Empfang neuer Schlüsselnachrichten
in regelmäßigen Abständen (abhängig vom
Verteilmechanismus) von einem ImportController geprüft. Bei
Empfang einer neuen Nachricht wird der Anwendungsfall „Datenschlüssel einspielen" automatisch angestoßen. Der
Rückgabewert dieser
Aktion wird geprüft.
Sollte eine negative Rückmeldung
kommen, so wird der Importversuch bis zu drei Mal wiederholt.
-
Ist nach dreimaligem Versuch der
Import immer noch nicht möglich,
so wird eine Protokollnachricht über
den Misserfolg an das ZinS Zentral – System gesandt (wiederum
abhängig
vom Transportmechanismus). Bei erfolgreichem Import erfolgt eine
positive Protokollnachricht.
-
Die Protokollnachrichten werden zentral über den
Anwendungsfall „Schlüsselverarbeitung
protokollieren" verarbeitet.
Von diesem Anwendungsfall wird auch die Freigabe des Datenschlüssels ausgelöst.
-
Das Einspielen der Datenschlüssel wird
entweder von einem Sicherheitsadministrator ausgeführt, der vor
Ort an dem Krypto System die Initialisierung durchführt oder
er wird durch den ImportController der Schlüsselverteilung automatisch
ausgelöst,
wenn dieser eine neue Datenschlüsselnachricht
empfängt.
-
Der Import des Schlüssels erfolgt
analog zum Import der Transportschlüssel unter Berücksichtigung der
Besonderheiten einer Datenschlüsselnachricht:
- 1. Es erfolgt eine Anmeldung an der Karte mit
der zu dem KeyImport-Benutzer zugehörigen ID und PIN.
- 2. Zu den Feldern 1–7
der Datenschlüsselnachricht
wird mittels des Verfahrens SHA-1 ein Hashwert gebildet.
- 3. Es wird der Signierschlüssel
ermittelt, der die KeyID besitzt, die in dem Feld 5 angegeben wurde.
- 4. Mit diesem Schlüssel
wird der unter Punkt 2 gebildete Hashwert verschlüsselt (Mechanismus CKM_DES3_CBC_PAD,
der IV wird mit Nullen gefüllt)
und mit Feld 8 verglichen. Stimmen beide Werte überein, ist die Integrität gesichert,
und es ist sichergestellt, dass die Nachricht vom PC-F-System erstellt wurde.
- 5. Es wird der Transportschlüssel
ermittelt, der die KeyID besitzt, die in Feld 6 der Schlüsselnachricht
angegeben wurde.
- 6. Der Inhalt des Feldes 7 der Nachricht wird mit dem unter
Punkt 5 ermittelten Schlüssel
entschlüsselt
(Methode C_Decrypt, Mechanismus CKM_DES3_CBC_PAD, der IV wird mit
Nullen gefüllt
). Das Resultat der Entschlüsselung
ist eine Zwischennachricht.
- 7. Der Inhalt des Feldes 1 der Zwischennachricht wird mit dem
KTM entschlüsselt
(Methode C_UnwrapKey, Mechanismus CKM_KEY_WRAP_WEBSENTRY). Hierdurch
wird automatisch das entsprechende Datenschlüsselobjekt auf der Karte erzeugt
und gespeichert. Zusätzlich
wird durch den Mechanismus implizit die Integrität des Schlüssels als auch der korrekte
Absender geprüft.
- 8. Sollte bereits ein Schlüssel
mit gleicher KeyID auf der Karte existieren, so wird dieser gelöscht.
- 9. Es werden alle Datenschlüssel
auf der Kryptokarte gelesen und geprüft, ob sie im Attribut Label,
Byte 1 den gleichen Wert des Generationszählers besitzen, wie der neu
eingespielte Schlüssel.
Ist dies der Fall, so werden diese Schlüssel von der Karte entfernt.
Es handelt sich hierbei um Schlüssel,
die durch einen Fehler beim Import auf einem Krypto-System eines
anderen lokalen Entgeltsicherungssystems nicht auf dem Wertübertragungszentrum
PP freigegeben wurden.
- 10. Es wird zu den Bytes 2–65
des Attributs Label des neu importierten Schlüssels ein Hashwert nach dem Verfahren
SHA-1 gebildet und dieser zusammen mit der KeyID und der Positivmeldung
als Rückgabewert zurückgeliefert.
- 11. Die Benutzersession mit der Kryptokarte wird beendet.
- 12. Aus den Rückgabewerten
wird eine Protokollnachricht generiert und diese an das ZinS Zentral-System gesendet.
- 13. Etwaige zu dieser KeyID gespeicherten Fehlversuche (s. unten
beschriebene Variante) werden zurückgesetzt.
-
Eine Variante dieses Anwendungsfalls
besteht darin, dass eine der Routinen oder die Überprüfung des MACs fehlschlägt. In diesem
Fall wird die weitere Verarbeitung abgebrochen, und es wird ein
Rückgabewert zurückgeliefert,
der die KeyID, den Fehlercode, sowie eine Fehlernachricht enthält. Zu der
KeyID wird die gespeicherte Anzahl der Fehlversuche um eins erhöht. Sollte
sie bei drei angelangt sein, so wird aus dem zuletzt übergebenen
Rückgabewert
eine Protokollnachricht generiert und diese an das zentrale Entgeltsicherungssystem
(ZinS Zentral System) gesendet.
-
Im Falle des manuellen Anstoßes wird
das Ergebnis des Imports zusätzlich
am Bildschirm des Sicherheitsadministrators angezeigt.
-
Vorzugsweise laufen die Schritte
2–10 direkt
in der Kartensoftware (Embedded Code) ab. Dies erhöht sowohl
die Performance als auch die Sicherheit vor Ausspionage (speziell
des IVs, sowie des KTMs).
-
Ein Bereinigen der Datenschlüssel erfolgt
mehrfach, vorzugsweise regelmäßig, auf
möglichst
vielen, vorzugsweise allen Krypto-Systemen des Entgeltsicherungssystems
und dient dazu, nicht mehr benötigte
Datenschlüssel
zu löschen.
-
Vorgehensweise bei der Datenschlüsselbereinigung
- 1. Es werden alle auf der Karte befindlichen
Datenschlüssel
KD ermittelt und nach ihrer ID (Attribut CKA_ID) aufsteigend sortiert.
- 2. Für
jeden Schlüssel
dieser Liste werden folgende Prüfungen
vorgenommen:
- I. Es wird der Nachfolger des Schlüssels ermittelt (nächstgrößere ID).
- II. Falls vorhanden, wird geprüft:
- 1. Ob das Attribut CKA_END_DATE des Nachfolgers, welches das
Gültigkeitsende
des Vorgängers
angibt, kleiner ist als das aktuelle Systemdatum. Ist dies der Fall,
so wird der aktuell bearbeitete Schlüssel der Liste gelöscht.
- 2. Ob der Generationszähler
des Nachfolgers (Byte 1 des Attributs CKA_LABEL) identisch ist mit
dem Generationszähler
des aktuell bearbeiteten Schlüssels.
Ist dies der Fall, so wird der aktuell bearbeitete Schlüssel der
Liste gelöscht.
-
Die Protokollierung der Schlüsselverarbeitung
läuft vorzugsweise
auf dem Server des zentralen Entgeltsicherungssystems (ZinS Zentral-Server)
ab. Bei den Schlüsseln,
die durch diesen Anwendungsfall protokolliert werden, handelt es
sich um die Transport- und Datenschlüssel.
-
Bei jedem Verteilauftrag wird protokolliert,
an welche aktiven Krypto-Systeme die Schlüsselnachricht versendet wurde.
Für jedes
System und jeden Verteilauftrag wird dabei ein eigener Eintrag erstellt,
der zunächst
auf den Status „Gesendet" gesetzt wird.
-
Nach einer erfolgreichen, aber auch
nach einer nicht erfolgreichen Schlüsselverarbeitung wird von den einzelnen
Krypto-Systemen eine Protokollnachricht erstellt und an das zentrale
Entgeltsicherungssystem (ZinS ZentralSystem) gesendet. Diese Verteilung
erfolgt entweder über
JMS Queues oder per Datenbankreplikation.
-
Im Bereich des zentralen Entgeltsicherungssystems
werden die Nachrichten nach Erhalt dazu verwendet, die oben beschriebenen
Protokolleinträge
zu aktualisieren. Es wir dazu sowohl der Status „Verarbeitung erfolgreich" / „Nicht
erfolgreich" als
auch ein eventueller Fehlercode und die Nachricht gespeichert.
-
Im Anschluss an die Verarbeitung
der Protokollnachrichten wird geprüft, ob Verteilaufträge existieren, die
von allen Krypto Systemen erfolgreich eingearbeitet wurden. Ist
dies der Fall, so wird die Freigabe des jeweiligen Schlüssels, insbesondere
im Bereich des Wertübertragungszentrums,
angestoßen.
Sobald ein System einen Fehler meldet, wird eine entsprechende Meldung
mit negativem Status in dem Bereich des Wertübertragungszentrums vorgenommen.
-
Der Aufruf der Schlüsselfreigabe
wird bei dem Verteilauftrag vermerkt, damit zu einem Auftrag nicht mehrere
Freigaben durchgeführt
werden. So lange der Vermerk jedoch noch nicht gesetzt ist, wird
in regelmäßigen Abständen erneut
versucht, den Freigabedienst zu kontaktieren.
-
Eine besondere Variante liegt dann
vor, wenn nach einer zu definierenden Zeit, vorzugsweise mehrere Tag
, beispielsweise 3, noch nicht von allen Krypto-Systemen eine Rückmeldung
erfolgt ist. Nach Ablauf dieser Zeit erfolgt dann eine negative
Freigabemeldung an das Wertübertragungszentrum.
-
Vorzugsweise enthält das Schlüsselzuweisungssystem eine Benutzeroberfläche, die
einem Administrator eine Kontrolle des Status eines Schlüsselverteilauftrags
ermöglicht.
Zu jedem Verteilauftrag werden dann folgende Daten angezeigt:
- – Anzahl
der Systeme, an welche die Verteilnachricht gesendet wurde
- – Anzahl
der Systeme, die eine erfolgreiche Verarbeitung zurückgemeldet
haben
- – Anzahl
der Systeme, bei denen der Ausgang der Verarbeitung noch nicht zurückgemeldet
wurde
- – Anzahl
der Systeme, die eine nicht erfolgreiche Verarbeitung zurückgemeldet
haben
-
Ferner kann auch eine detaillierte
Auflistung erstellt werden, bei der für jedes System der aktuelle
Status angezeigt wird.
-
Alternativ ist es möglich, lokal
die auf der jeweiligen Karte gespeicherten Schlüssel anzuzeigen.
-
Es ist zweckmäßig, dass alle Schlüssel, zu
denen Verteilaufträge
erstellt wurden, im Bereich des zentralen Entgeltsicherungssystems
archiviert werden. Auf den lokalen Systemen wird vorzugsweise keine
Archivierung vorgenommen. Dort werden die Schlüssel im nicht flüchtigen
Speicher der Karte aufbewahrt. Es werden nur Schlüsselnachrichten
archiviert, die auch freigegeben wurden.
-
Die Schlüsselrestaurierung von Transport-
und Datenschlüsseln kann
für ein
spezielles Kryptosystem zentral angestoßen werden. Es werden in diesem
Fall aus dem Archiv die aktuellen Schlüssel ermittelt und an das spezielle
Krypto System gesendet. Es werden hierzu ebenfalls Protokollnachrichten
generiert. Lediglich die Freigabemeldung entfällt bei dieser Art von Schlüsselverteilung.
-
Sollte der Master-Transportschlüssel KTM
verloren gehen, so muss das entsprechende Krypto System zur Neuinitialisierung
entweder den Sicherheitsadministratoren zugeschickt werden, oder
die Sicherheitsadministratoren müssen
das jeweilige System vor Ort neu initialisieren.
-
Durch besondere Sicherheitsmaßnahmen
sowohl der WebSentry-Karte,
als auch durch die Verteilung auf mehrere SmartCards, sowie durch
das mehrstufige Schlüsselsystem,
ist der Master-Transportschlüssel KTM
sicher vor Kompromittierung geschützt.
-
Sollte dennoch ein Austausch des
Master-Transportschlüssels
erfolgen, muss ein neuer Master-Transportschlüssel KTM erstellt und auch
neue Signier-Transport- und Datenschlüssel erstellt werden.
-
Diese müssen dann auf allen Krypto-Systemen
der lokalen Entgeltsicherungssysteme eingespielt werden.
-
Dies bedeutet einen erhöhten Aufwand,
da entweder alle Krypto Systeme zur zentralen Administrationsstelle
und wieder zurück
transportiert werden müssten,
oder die Sicherheitsadministratoren alle Standorte der lokalen Entgeltsicherungssysteme
bereisen müssten.
Daher ist ein Einsatz der erfindungsgemäßen Sicherungsmechanismen für den Master-Transportschlüssel KTM
besonders vorteilhaft.
-
Der bisherige Master-Transportschlüssel KTM
bleibt als sogenannter „dormant
LMK" auf der Karte
bestehen und muss von dem Sicherheitsadministrator entsprechend
gelöscht
werden.
-
Das Keyhandling und das Entschlüsseln sollte
als Embedded Code auf der Kryptokarte vorliegen. Hierdurch wird
nicht nur ein erhöhter
Sicherheitsstand erzielt, sondern auch ein Performance – Gewinn
des Kryptosystems erwartet.
-
Vorzugsweise enthalten die Krypto-Karten
die nachfolgend genannten Standard Pkcs#11 Funktionen:
- – C_CloseSession
- – C_GetSlotList
- – C_Init
- – C_Initialize
- – C_Login
- - C_Logout
- - C_OpenSession
und dazu die dargestellten Erweiterungen.
Ferner sollten fest gespeicherte Funktionen keine weiteren Erweiterungen
dritter Parteien beinhalten und die hier geforderten Erweiterungen
sind ausschließlich
als Funktionen für
Krypto-Karten des Entgeltsicherungssystems integriert.
-
Um die Embedded – Keyhandling – Methoden
der Pkcs#11 DLL zu kennzeichnen, wird diesen Methoden ein Präfix vorangestellt.
Dieses Präfix
wird als CE_ definiert. CE steht in diesem Fall für Crypto
Extension.
-
Jede Embedded – Methode liefert einen Returnvalue
des Types CK_RV, welcher als fester Bestandteil der Includedatei
pkcs11.h definiert ist. Es ist zweckmäßig, dass bei der Implementierung
der Embedded Methoden weitere Fehlerrückgabewerte definiert und diese
in einer C++ Headerdatei zum Einbinden bereitgestellt werden. Diese
Maßnahme
ist insofern vorteilhaft, als durch einen Aufruf einer Embedded
Methode diverse Pkcs11 Methoden geschachtelt auf der Hardware aufgerufen
werden können.
Ein weiterer Vorteil hierbei ist das völlig neu aufgesetzte Keyhandling
innerhalb der Software der Krypto-Karten.
-
Beispiel zur Verdeutlichung der Methodensyntax
CK_RV
= CE_MethodenName(Parameterliste)
-
Innerhalb der Parameterliste werden
Parameter, die mit einem Ergebnis besetzt werden müssen, durch
call by reference übergeben.
Der Methodenname wird aus sinnvollen Wortkombinationen gebildet,
die einen guten Eindruck vermitteln, was die Methode leistet.
-
Die Wortwahl erfolgt so, dass eine
Zuordnung zu Bedeutungsinhalten, beispielsweise durch einen Einsatz
englischer Fachausdrücke,
möglich
ist.
-
Die Einführung zweier Enumerationstypen
dient zur Verifizierung der Funktionalität unterschiedlicher Embedded
Methoden. Es wird zwischen dem Enumerationstyp für Schlüsselarten und Schlüsselattribute
unterschieden.
CE_EnumKey = {CE_KT, CE_DT, CE_SE, CE_KA}
-
CE_KA nimmt eine Sonderstellung ein.
Es handelt sich nicht um einen Schlüssel, sondern um die Menge
aller Schlüssel.
Wird dieses Enumelement angegeben, so implementieren die Methoden
eine Funktionalität,
die sich auf alle enthaltenden Schlüssel der Karte beziehen.
CE_EnumKeyAttribut
= {CE_ID, CE_LABEL, CE_STARTDATE, CE_ENDDATE}
-
Die notwendigen Defines sind mit
in das File pkcs11.h zu übernehmen.
Die definierten Erweiterungen können
sich in einer separaten Headerdatei befinden, die in der Datei pkcs11.h
eingeschlossen sind. Bei der Umsetzung der Embedded Methoden sind
verschiedene Mechanismen möglich.
-
Im kryptographischen Umfeld wird
eine Methode definiert, die alle relevanten Prüfungen selbständig mit
den ihr zur Verfügung
stehenden Pkcs#11 Methoden durchführt.
CK_RV CE_Decrypt
(CK_SESSION_HANDLE session, CK_BYTE[ ] message, CK_BYTE* postageID, CK_BBOOL
bOk)
-
Funktionsbeschreibung:
-
Die Embedded-Kryptographie-Methode
bekommt im Parameter message ein 57 Byte langes Datum überstellt,
welches dem Matrixcode des Frankiervermerkes entspricht. Die Zählweise
in der folgenden Erklärung
der Arbeitsschritte beginnt bei eins.
- 1. Schritt
: Bildung des Initialisierungsvektors IV
Als Initialisierungsvektor
werden die ersten zwei Bytes mit Null aufgefüllt und dann die Bytes f6–f10 plus Byte
f14 an den Matrixcode angehängt.
- 2. Schritt : Bestimmung des zu verwendenden KD
In Byte
f14 ist der Keyphasenindikator enthalten, er gibt Aufschluß darüber, welcher
Schlüssel
zu verwenden ist. Der Keyphasenindikator ist im Schlüsselattribut
CKA_ID hinterlegt und identifiziert so eindeutig den Schlüssel. Das
weiter unten aufgeführte
Keyhandling sollte ein effizientes Auffinden des Schlüssels ermöglichen.
- 3. Schritt : Decrypten der enthaltenen verschlüsselten
Nachricht
Der verwendete Mechanismus in CK_MECHANISM ist CKM_DES3_CBC.
Entschlüsselt
werden die Bytes f15–f38,
das sind 24 Bytes, die ersten 12 Bytes des entschlüsselten
Ergebnisses werden durch den Parameter postageID nach außen getragen.
Ist das Decrypten erfolgreich durchgeführt worden, wird in Schritt 4
weiter verfahren, ansonsten in Schritt 5.
- 4. Schritt : Bildung und Abgleichung des Hashwertes Zur Bildung
des Hashwertes des Datums wird, aus einem eigens konstruierten 77
Byte großen
Datenblock gewonnen.
Byte 1 bis 53 : Übereinstimmend mit den ersten
53 Byte des Matrixcodes
Byte 54 bis 65 : Übereinstimmend mit den ersten
12 Byte des aktuellen, unverschlüsselten
Nachrichtenteils (PostageID)
Byte 66 bis 77 : Übereinstimmend
mit den letzten 12 Byte des aktuellen, unverschlüsselten Nachrichtenteils.
Die
Hashwertbildung erfolgt nach SHA-1 und die ersten vier Byte müssen nach
diesem Vorgang mit den Byte f54–f57 übereinstimmen.
Ist dies nicht der Fall, so handelt es sich um ein ungültiges Datum.
Sollte ein Fehler bei der Ausführung
des Hashing erfolgen oder der Hashwert abweichen, so wird wie in
Schritt 5 verfahren.
- 5. Schritt : Rückgabe
des Erfolgsindikators
Der Parameter bOk wird, wenn alle Arbeitsschritte
erfolgreich waren, mit true besetzt und mit false, wenn der Hashwertabgleich
eine Abweichung ergeben hat oder eine der Pkcs#11 Methoden einen
Fehler verursacht hat. Der Returnvalue ist dementsprechend mit der Fehlernachricht
zu besetzen oder mit CKR_OK, wenn kein Fehler aufgetreten ist.
CK_RV
CE_VerifyMsg (CK_SESSION_HANDLE session, CK_BYTE[] message, int
length, CK_BBOOL bOk)
Ein allgemeiner Datenblock message zur
Verifizierung ist nachfolgend dargestellt:
-
Nicht benutzte Felder werden mit
Nullen aufgefüllt. Über den
Parameter MsgType wird die Arbeitsweise der Methode bestimmt.
-
Für
den MsgType KT und KD wird in message ein generierter Datenblock übergeben.
Der Datenblock wird aus den jeweiligen erhaltenen Nachrichten aufgefüllt.
-
Die Funktionszuweisung CE_VerifyMsg
für den
MsgType KT bekommt die komplette Transportschlüsselnachricht im Attribut message übergeben,
dessen Länge
in dem Attribut length. Diese Embedded Methode soll die Integrität der Transportschlüsselnachricht
beim Empfänger
sicherstellen, um die Prüfung
zu tätigen, sind
folgende Schritte auszuführen.
- 1. Schritt : Bildung des Initialisierungsvektors
IV Der Initialisierungsvektor wird mit Nullen aufgefüllt.
- 2. Schritt : Decrypten der enthaltenen verschlüsselten
Nachricht
Der verwendete Mechanismus in CK_MECHANISM ist CKM_DES3_CBC_PAD.
Entschlüsselt
werden die Byte des variablen MAC Feldes. Sollte ein Fehler während der
Decodierung auftreten, so ist wie in Schritt 4 zu verfahren.
- 3. Schritt : Abgleichung des Hashwertes
Zur Bildung des
Hash – wertes
des Datums wird aus den Feldern 1+2+5+6+8 der Transportschlüsselnachricht
ein Hash gebildet. Der mit dem aus Schritt 2 verglichen wird. Die
Hashwertbildung erfolgt nach SHA-1. Sind die Hashwerte nicht identisch,
so handelt es sich um ein ungültiges
Datum. Sollte ein Fehler bei der Ausführung des Hashing erfolgen
oder der Hashwert abweichen, so wird wie in Schritt 4 verfahren.
- 4. Schritt : Rückgabe
des Erfolgsindikators
Der Parameter bOk wird, wenn alle Arbeitsschritte
erfolgreich waren, mit „true" besetzt und mit „falle", wenn der Hashwertabgleich
eine Abweichung ergeben hat oder eine der Pkcs#11 Methoden einen
Fehler verursacht hat. Der Returnvalue ist dementsprechend mit der Fehlernachricht
zu besetzen oder mit CKR_OK, wenn kein Fehler aufgetreten ist.
-
Nach der Funktionszuweisung CE_VerifyMsg
für den
MsgType KD wird die komplette Datenschlüsselnachricht im Attribut message
und deren Länge
in dem Attribut length übergeben.
Dies soll die Integrität
der Transportschlüsselnachricht
beim Empfänger
sicherstellen. Um die Prüfung
zu tätigen,
sind folgende Schritte auszuführen.
- 1. Schritt : Bildung des Initialisierungsvektors
IV
Als Initialisierungsvektor wird mit Nullen aufgefüllt.
- 2. Schritt : Entschlüsseln
der enthaltenen verschlüsselten
Nachricht
Der verwendete Mechanismus in CK_MECHANISM ist CKM_DES3_CBC_PAD.
Entschlüsselt
werden die Byte des variablen MAC Feldes. Sollte ein Fehler während der
Decodierung auftreten, so ist wie in Schritt 4 zu verfahren.
- 3. Schritt : Abgleichung des Hashwertes
Zur Bildung des
Hashwertes des Datums wird aus den Feldern 1+2+4+3+6+7+8 der Datenschlüsselnachricht
ein Hash gebildet, der mit dem aus Schritt 2 verglichen wird. Die
Hashwertbildung erfolgt nach SHA-1. Sind die Hashwerte nicht identisch,
so handelt es sich um ein ungültiges
Datum. Sollte ein Fehler bei der Ausführung des Hashing erfolgen
oder der Hashwert abweichen, so wird wie in Schritt 4 verfahren.
- 4. Schritt : Rückgabe
des Erfolgsindikators
Der Parameter bOk wird, wenn alle Arbeitsschritte
erfolgreich waren, mit „true" besetzt und mit „false", wenn der Hashwertabgleich
eine Abweichung ergeben hat oder eine der Pkcs#11 Methoden einen
Fehler verursacht hat. Der Returnvalue ist dementsprechend mit der
Fehlernachricht zu besetzen oder mit CKR_OK, wenn kein Fehler aufgetreten
ist.
-
Diese Embedded-Keyhandling Methoden
sollen den Schlüsselimport
eines gewrappten Schlüssels und
eine effiziente Schlüsselverwaltung
beinhalten. Importiert werden sollen Schlüssel der Art KS, KD und KT.
CK_RV
CE_ImportKey (CK_SESSION_HANDLE session, CK_BYTE_PTR data, CK_ULONG
length, CK_BYTE* hashValue, CE_EnumKey keyTyp, CK_CHAR [] KeyKTID)
-
Die Funktionszuweisung CE_ImportKey
erfolgt vorzugsweise wie nachfolgend beschrieben:
Beim Wrappen
wird der Mechanismus CKM_KEY_WRAP_WEBSENTRY verwendet. Demnach wird
beim Unwrap derselbe Mechanismus gefordert. Der erhaltene Schlüssel wird
durch das Unwrappen auf die Kryptohardware eingespielt, wobei ein
Schlüssel,
der ein zweites Mal, also mit der selben Keyphase importiert wird, den
alten Schlüssel überschreibt.
-
Der gewrappte Schlüssel wird
im Parameter data übergeben
und dessen Länge
im Parameter length. Die Länge
des Schlüssels
ist abhängig
von der Besetzung der Schlüsselattribute.
Die Schlüsselart
wird über den
Parameter keyTyp verifiziert und entsprechend behandelt.
-
Der Schlüssel wird dann in die im Cache
Betrieb gehaltene Schlüsselverwaltung
aufgenommen und evtl. der doppelte Vorgänger gelöscht.
-
Der DT wird durch den KT entschlüsselt, welcher
durch den Parameter KeyKTID identifiziert wird, bei allen anderen
Schlüsselarten
bleibt dieser Parameter unberücksichtigt
und wird mit NULL belegt.
-
Wichtig ist die Abhängigkeit
des Attributes CKA_END_DATE. Diese gibt das Ablaufdatum des Schlüsselvorgängers an.
-
In dem Schlüsselattribut des importierten
Schlüssels
ist die Zufallszahl enthalten, über
die der Hashwert nach SHA-1 gebildet werden sollte. Der Hashwert
wird im Parameter hashValue der embedded Methode zurückgegeben.
Der Hashwert wird für
die Schlüsselquittierungsnachricht
benötigt.
-
Im Fehlerfall während des Unwrappmechanismus
oder der Hashbildung wird der entsprechende Fehlercode im Returnvalue
ausgegeben, ansonsten CKR_OK.
CK_RV CE_GetKeyCount (CK_SESSION_HANDLE
session, CE_EnumKey keyTyp, int* counter)
-
Die Funktionszuweisung CE_GetKeyCount
zeigt an, wieviele Schlüssel
der jeweiligen Schlüsselart
auf der Karte in der im Cache Betrieb gehaltenen Schlüsselverwaltung
registriert sind. Hierdurch ist in Verbindung mit der nachfolgend
dargestellten Methode ein Auslesen von Schlüsselattributen möglich.
-
Diese Methode ist wie folgt definiert:
CK_RV
CE_GetAttribute(CK_SESSION_HANDLE session, CE_EnumKey keyTyp, CE_EnumKeyAttribute keyAttribute, int
pos, CK_BYTE[]* attribute, int* length)
-
Über
den Parameter keyTyp wird die Schlüsselart bestimmt und damit
die Tabelle, aus der gelesen werden soll, wenn die unterschiedlichen
Schlüsselarten
auf der Kryptohardware in unterschiedlichen Listen geführt werden,
geordnet nach Art der Schlüssel.
-
Der Parameter keyAttribut legt das
Attribut fest, welches ausgelesen werden soll und der Parameter pos
liefert den Einstiegspunkt innerhalb einer Tabelle, dessen maximaler
Wert ist zuvor mit der Methode CE_getKeyCount für alle Schlüssel oder für eine Schlüsselart zu erfragen. Bei der
Ausgabe des Attributes CKA_END_DATE ist darauf zu achten, dass der
letzte aktuelle Schlüssel
theoretisch unendlich gültig
ist (bis ein neuer Schlüssel
der gleichen Art importiert wird), und sich in seinem Attribut CKA_END_DATE
das Ablaufdatum für
den Vorgängerschlüssel der
gleichen Schlüsselart
befindet, wobei das CKA_END_DATE dieses angegebenen Schlüssels ausgegeben
wird.
-
Die Attribute für ein Datum haben eine feste
Länge von
8 Byte, dagegen die Attribute CKA_ID und CKA_LABEL eine feste Länge von
128 Byte. Sollte bei diesen beiden Parametern die Attribute innerhalb
der Schlüssel
kürzer
als 128 Byte sein, werden die restlichen Byte bis 128 mit Null aufgefüllt. So
kann vom Benutzer den entsprechenden Methoden immer ausreichend
Speicherplatz bereit gestellt werden. In dem Fall, dass der Anwender
einen zu kleinen Buffer bereitstellt, werden die Informationen getrimmt
und eine entsprechende Fehlermeldung über CK_RV übermittelt.
CK_RV CE_
DeleteExpiredKeys (CK_SESSION_HANDLE session, CE_EnumKey keyTyp,
int* counter)
-
Die Funktionszuweisung CE_DeleteExpiredKeys
durchsucht die Karte nach abgelaufenen Schlüsseln und löscht diese von der Karte. Abgelaufene
Schlüssel
sind durch das Merkmal zu identifizieren, dass das Systemdatum älter ist
als das CKA_END_DATE des Nachfolgeschlüssels, siehe unter 2.5.8. gilt
auch für
KT und KS. Es wird durch den Enumtypen ein selektives Löschen ermöglicht und
durch CE_KA kann die gesamte Karte gelöscht werden (nur der LMK bleibt
erhalten). Wichtig ist, dass diese Methode nicht aktiv werden darf,
wenn ein Schlüsselimport
vollzogen wird. Dies wird vorzugsweise im Embedded Code kontrolliert
und mit einem entsprechenden Returnvalue angezeigt. Durch diese
Maßnahme
werden eventuell nicht überschaubare
mögliche Seiteneffekte
bei der internen Schlüsselpflege
vermieden.
-
Die Schnittstelle zwischen dem Entgeltsicherungssystem
und dem Wertübertragungszentrum
ist vorzugsweise möglichst
schmal, um Manipulationsmöglichkeiten
durch Seitenkanäle
auszuschließen.
-
Der Aufbau der Schnittstelle zwischen
dem Wertübertragungszentrum
(Postage Point) und dem zentralen Entgeltsicherungssystem ist in 3 dargestellt.
-
Von dem zentralen Entgeltsicherungssystem
wird eine Schnittstelle zur Verteilung von Schlüsseln bereitgestellt, über die
in der KeyManagement – Komponente
des Wertübertragungszentrums
(Postage Points) erstellte Schlüssel
auf die Krypto-Systeme der Entgeltsicherungssysteme verteilt werden
können.
-
Das Wertübertragungszentrum stellt dem
Entgeltsicherungssystem eine Schlüsselfreigabe-Schnittstelle
zur Verfügung, über die
von dem Entgeltsicherungssystem aus nach erfolgreicher Verteilung
und Verarbeitung eines Schlüssels
die Verwendung dieses Schlüssels
freigegeben werden kann.
-
Da in beiden Projekten größtenteils
Java zum Einsatz kommt, empfiehlt sich eine Applikationsschnittstellenrealisierung
mittels Session Beans. Zur Entkopplung der beiden Systeme sollte
das Lookup der Dienste über
einen Namensdienst mittels JNDI erfolgen.
-
Ein Session Bean liefert die nötige Funktionalität zum Einspielen
der Schlüsseldaten
in das ZinS Zentral System. Die gesamte Kommunikation ist in 4 dargestellt.
-
4 zeigt
Verfahrensschritte zur Integration eines Datenschlüssels in
das zentrale Entgeltsicherungssystem (ZinS Zentral).
-
Die Verfahrensroutine importKey übergibt
den Datenschlüsselsatz
an ZinSZentral.
-
Sie bereitet je nach Verwendung von
ASN.1 Nachrichten die erhaltene Nachricht auf und veranlasst, dass
die Nachricht in der Datenbank hinterlegt wird. Die Verfahrensroutine
importKey initiiert dann die Verteilung der Schlüsseldaten mittels CWMS an die
ZinS Lokal Systeme.
-
Die Reihenfolge Einspielen der Daten
in die Datenbank und anschließendes
Verteilen der Nachricht sollte eingehalten werden. So ist sichergestellt,
dass die empfangenen Daten gesichert sind, bevor auf ihnen oder
mit ihnen gearbeitet wird. Vorteil dieses Vorgehens ist, dass sich
Ereignisse im Fehlerumfeld besser rekonstruieren lassen und bei
einem Datenverlust zur Not auf die Datenbank zurückgegriffen werden kann.
-
Die Parameter der insertKeyData Methode
sind noch nicht spezifiziert, da zu diesem Zeitpunkt noch nicht
klar ist, ob das ASN.1 Format unterstützt wird. Die Methode wird
aber mit zwei Parametern ausgestattet werden müssen, um auch eine detailliertere
Nachricht an den Postage Point versenden zu können.
-
In ZinSZentral sorgt die Verteilmethode
des Schlüsselzuweisungssystems
für:
- 1. Die Archivierung der Schlüsselnachricht
auf dem ZinSZentralserver.
- 2. Verteilung der Schlüsselnachrichten
vom Postage Point zu den einzelnen BZs mittels der von Vibris bereitgestellten
CWMS Schnittstelle. Aufbau und Verwendung des CWMS Dienstes ist
dem Manual dieser Schnittstelle zu entnehmen.
- 3. Nach abgeschlossener Verteilung und Import in die einzelnen
BZ's erfolgt Generierung
einer entsprechenden Rückmeldung.
-
Die Daten werden von dem Wertübertragungszentrum
(Postage Point) im ASN.1 Format übermittelt. Die
entsprechende Rückantwort
wird ebenfalls im ASN.1 Format erwartet. An Stelle dieses Formates
können jedoch
selbstverständlich
auch andere Formate eingesetzt werden. Die jeweiligen Formate werden
durch einen geeigneten Parser für
den Einsatz angepasst.
-
Beorzugte Datenformate in ASN.1 sehen
wie folgt aus: Verteilungsnachricht
Transportschlüssel
Verteilungsnachricht
Datenschlüssel
Freischaltungsnachricht
-
Die Datenstrukturen können einen
verschiedenen Aufbau aufweisen. Ein Aufbau entsprechend den dargestellten
Ausführungsbeispielen
ist jedoch besonders vorteilhaft, da hierbei sowohl eine Übermittlung sämtlicher
zu berücksichtigender
Informationen als auch ein geringer Datenübertragungsaufwand erzielt
werden. Insbesondere werden die Daten mittels CWMS an die lokalen
Entgeltsicherungssysteme, die sich vorzugsweise in Briefzentren
des Postunternehmens befinden, übermittelt.
-
Beim Einsatz des ASN.1 Formates müssten die
Daten zunächst
wieder in die interne Schlüsselnachricht
geparst werden, was bei direkter Verwendung der in diesem Dokument
definierten Nachrichten entfallen würde.
-
Die durch das CWMS erhaltenen Datenpakete
entsprechen den zuvor in diesem Dokument definierten Schlüsselnachrichten.
Diese werden dann der VerifyMsg Methode des Embedded Code unterzogen,
nachdem sie vorab an die Datentabelle auf Seite 29 angepasst worden
sind. Nach dessen Prüfung
wird entweder mit dem Import des Schlüssels über den Embedded Code begonnen
oder eine entsprechende Fehlermeldung generiert. Vergleiche Schlüsselnachrichten
und Seite 12–14
in Bezug auf die Importdatenstruktur der Embedded Code Methode CE_ImportKey.
Das Löschen
der alten Schlüssel,
sowie das Aktualisieren wird automatisch durch die oben beschriebenen
Embedded Code Methoden durchgeführt.
-
Täglich
wird die Methode CE_DeleteExpiredKeys aufgerufen, welche täglich die
abgelaufenen Schlüssel
von der Kryptohardware entfernt, soweit dieses notwendig ist. Die
CA_ImportKey Methode sorgt beim Import dafür, dass doppelte Schlüssel gelöscht werden
und neuere an deren Stelle treten.
-
Die Embedded Code Methoden werden
durch die Javaklasse KryptoAdapter an die Applikation gebunden.
KryptoAdapter bieten alle Funtionen (namentlich gleich), die der
Embedded Code und weitere Pkcs#11 Methoden bieten.
-
Mittels JNI wird eine DLL (KryptoAdapter.DLL)
benutzt, die die bereitgestellte DLL von Zaxus statisch gelinkt
hat. Durch das statische Linken wird das Sicherheitsrisiko weiter
minimiert.
-
Die C++ Implementierung der JNI Schnittstelle
liefert zudem ein Errorhandling für jede angeforderte Session,
siehe dazu in dem Design Dokument PCFM Stufe 3 unter Multithreading.
Es wird das Workerkonzept unterstützt, indem die Kryptohardware
im Multithreadingmodus initialisiert wird und nach dem Login jeder
Worker sich seine eigene Session holt (getSession, C_GetSession),
wodurch in der DLL dieser Worker registriert und für ihn ein
eigens geführtes
Errorhandling etabliert wird. Der Mainstream der DLL wird durch
das Login angesprochen und verfügt
ebenfalls über
ein eigenes Errorhandling bezüglich
der Ausführung
von Pkcs#11 Methoden und den Embedded Methoden.
-
6 gibt
eine Übersicht
der Implementation. Vorzugsweise werden die Schlüsselliste und der Code der
durch die Embedded Methoden bereitgestellt wird, entfernt werden.
Ansonsten ist der Aufbau der Strukturen gleich zu wählen.
Anbindung
der DLL.
-
Eine bevorzugte Kapselung und ein
vorteilhaftes Errorhandling sind in 7 beispielhaft
dargestellt.
-
Eine Implementation der Keylisten
ist nicht vonnöten,
falls die Schlüssellisten
komplett im Embedded Code der Kryptohardware gehalten werden. Die
GetAttribute Methoden schrumpfen auf den einzigen Aufruf der Embedded
Methode CE_GetAttribute zusammen; ebenso reduzieren sich die Aufrufe
für den
Import und dessen Implementierung, da dies nach der Übergabe
der nötigen
Daten der Embedded Code selbständig
ausführt.
-
Eine erweiterte Fehlerkonstantenliste
wird in dem Embedded Code bereitgestellt.
-
Die Schlüsselnachrichten vom Postage
Point werden in ZinS Zentral in einer Datenbank gespeichert, um
ein späteres
Aufsetzen eines schadhaften lokalen Entgeltsicherungssystems zu
ermöglichen.
Zum einen ist gefordert, die Nachricht als solche in die Datenbank
aufzunehmen und zum andern eine administrative Auskunft zu erhalten.
-
Daher sind folgende Datenbanktabellen
notwendig.
-
-
Schlüsseldaten speichert die Schlüsselnachricht,
wie sie vom Postage Point empfangen wurde, ihre Archivierung dient
dazu bei einem Ausfall eines lokalen Entgeltsicherungssystems dieses
durch das Aufspielen der archivierten Schlüssel mit den anderen verbleibenden
lokalen Entgeltsicherungssystemen abzustimmen. Vor der Speicherung
muss die Nachricht von ASN.1 zerlegt werden, um sie an die lokalen
Systeme zu übermitteln.
Als Speicherung wird die gemeinsame Form der Datensätze bevorzugt,
dies entspricht der Tabelle, welche den Datenblock beschreibt, die
für die
Embedded Methode CE_VerifyMessage verwendet wird.
-
-
Dieser Datensatz hat eine zentrale
Bedeutung. Er dient zum einen zur Auswertung der erhaltenen Rückmeldungen
der lokalen Entgeltsicherungssystem in den Briefzentren, vorzugsweise
aller in das Versandsystem des Postunternehmens integrierten Briefzentren,
sowie einer starken Fehleranalyse und Alarmierung des Systemoperators
bei Zeitüberschreitungen
im Verteilvorgang.
-
Ebenso kommt dieser Tabelle eine
administrative Informationsaufbereitung zu. Über sie lassen sich durch den
Eintrag SNPosNr die zugehörige
TransportSchlüsseldaten
Tabelle und die TransportSchlüsselReplayMessage
der einzelnen (83) BZ's
zuordnen und ggf. auswerten.
-
-
-
In dieser Tabelle werden die einzelnen
Schlüsselantwortnachrichten
der lokalen Entgeltsicherungssysteme in den Briefzentren des Postunternehmens
in Abhängigkeit
des Einspielvorganges archiviert.