VERFAHREN ZUM ÜBERPRÜFEN DER GÜLTIGKEIT VON DIGITALEN FREIMACHUNGSVERMERKEN

Beschreibung

[0001] Es ist bekannt, Postsendungen mit digitalen Freimachungsvermerken zu versehen.

[0002] Das Dokument EP-A-732673 offenbart die Merkmale des Oberbegriffs von Anspruch 1.

[0003] 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.

[0004] 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.

[0005] 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.

[0006] Anspruch 1 offenbart den Gegenstand der Erfindung. Bevorzugte Ausführungs beispiele werden in den abhängigen Ansprüchen 2-16 offenbart.

[0007] Erfindungsgemäß wird diese Aufgabe dadurch gelöst, dass die Leseeinheit den Freimachungsvermerk graphisch erfasst und an eine Überprüfungseinheit übermittelt, und dass die Überprüfungseinheit einen Ablauf von Teilprüfungen steuert.

[0008] Es ist besonders zweckmäßig, dass eine der Teilprüfungen die Entschlüsselung der in dem Freimachungsvermerk enthaltenen kryptographischen Informationen beinhaltet.

[0009] 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 online - insbesondere während des Bearbeitungsverlaufs der Postsendung in einer Bearbeitungsmaschine - erfolgen kann.

[0010] 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 Freimachungsvermerks und dem aktuellen Datum eine mehrfache Verwendung eines Freimachungsvermerks zur Beförderung von Postsendungen vermieden wird.

[0011] Zur weiteren Erhöhung der Überprüfungsgeschwindigkeit ist es vorteilhaft, dass die Leseeinheit und die Überprüfungseinheit mittels eines synchronen Protokolls Informationen austauschen.

[0012] In einer anderen, gleichfalls zweckmäßigen Ausführungsform der Erfindung kommunizieren die Leseeinheit und die Überprüfungseinheit über ein asynchrones Protokoll miteinander.

[0013] Hierbei ist es besonders zweckmäßig, dass die Leseeinheit ein Datentelegramm an die Überprüfungseinheit sendet.

[0014] Vorzugsweise enthält das Datentelegramm den Inhalt des Freimachungsvermerks.

[0015] 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.

[0016] Von den Zeichnungen zeigen

Fig. 1

eine Prinzipdarstellung von Systemkomponenten eines Entgeltsicherungssystems;

Fig. 2

eine besonders bevorzugte Ausführungsform des Entgeltsicherungssystems, Handscanner und Entgeltsicherungs-PC);

Fig. 3

eine Prinzipdarstellung einer Erzeugung und Überprüfung von Freimachungsvermerken.

Fig. 4

eine Übersicht über Komponenten des Krypto-Systems;

Fig. 5

eine bevorzugte Durchführungsform des Überprüfungsverfahrens;

Fig. 6

eine weitere besonders bevorzugte Ausführungsform des Überprüfungsverfahrens mit einem besonders bevorzugten Ablauf von Teilprüfungen;

Fig. 7

einen bevorzugten Ablauf einer Verteilung von Schlüsseln zwischen einer zentralen Ladestelle (Postage Point) und einzelnen kryptographischen Überprüfungseinheiten (Crypto Server).

[0017] 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.

[0018] Die dargestellte dezentrale Überprüfung an einzelnen Kontrollstellen, insbesondere in Briefzentren, ist besonders bevorzugt, jedoch ist eine zentralisierte Überprüfung gleichermaßen möglich.

[0019] In einer ersten Ausführungsform der Erfindung erfolgt vorzugsweise eine Überprüfung der Echtheit der Freimachungsvermerke stichprobenweise durch einzelne Scanner.

[0020] Ein hierzu geeignetes Überprüfungssyetem enthält vorzugsweise die in Fig. 1 dargestellten Komponenten.

[0021] In Fig. 1 ist dargestellt, mit welchen Teilsystemen das Krypto-System in Beziehung steht. Sie werden im Folgenden kurz beschrieben.

Scanner

[0022] Die Scanner dienen zum Einlesen des Frankierungsvermerks der PC-Frankierung. Bei den Frankierungsvermerken handelt es sich um 2D-Codes im Format Datamatrix, mit der verwendeten Fehlerkorrektur ECC200. Je nach Scannertyp werden die Daten per Funk oder per Kabel übertragen, wobei die Funkscanner über ein mehrzeiliges Display und damit über eine Ausgabemöglichkeit und einen Touchscreen, beziehungsweise eine Tastatur zur rudimentären Eingabe verfügen.
Die Schnittstelle zwischen den Scannern und den restlichen Systemen des bevorzugten Entgeltsicherungs-PC-Frankierung-Systems bilden der Scanner Controller und die Überprüfungseinheit (Validation-Controller) als Komponenten. Während der Scanner-Controller eine Queue von Matrixcodes verwaltet, die über den Handscanner kommend zur Prüfung anstehen und im Wesentlichen den Kontakt zu den Scannern aufrechterhalten, ist er mit den weiteren Systemen nur über den Validation-Controller (Überprüfungseinheit) in Kontakt.

Scanner Controller/Überprüfungseinheit

[0023] Scanner Controller und die zum Scanner Controller verbundene Überprüfungseinheit (Validation-Controller), dienen als Schnittstelle zwischen den Scannern und den weiteren Systemen zur Überprüfung der 2D-Barcodes. Ihnen wird der aus der optischen Erfassung umgewandelte und fehlerkorrigierte 2D-Barcodeinhalt übermittelt, und sie veranlassen daraufhin die Überprüfung und sorgen im Falle der Funkscanner für eine Ausgabe des Lese- und Prüfergebnisses, und dienen als Schnittstelle zwischen eventuell notwendigen manuellen Nachbearbeitungen und Prüfungen des Prüfers und den übrigen Systemen.

Krypto-System

[0024] Das Krypto-System sorgt für die inhaltliche und kryptographische Überprüfung des 2D-Barcodeinhaltes sowie für die geschützte Speicherung sicherheitarelevanter Daten und Algorithmen. Auf die einzelnen Komponenten wird später eingegangen.

Gebührenbetragsladestelle (Postage Point)

[0025] Die Gebührenbetragsladestelle (Postage Point) ist das zentrale System innerhalb der PC-Frankierung. Sie dient als Schnittstelle zu den Kundensystemen. Von ihr können die Kunden Vorgabebeträge zur anschließenden Frankierung entladen. Auf der Gebührenbetragsladestelle (Postage Point) werden die Schlüssel zur Absicherung des Verfahrens generiert. Ferner dient sie als Schnittstelle zu den Abrechnungs-Systemen. Folgende Schnittstellen werden zu dem bevorzugten Entgeltsicherungssystem zur PC-Frankierung bereitgestellt:

• Sendungsinformationen über den 2D-Barcode
• Symmetrische Schlüssel
• Stammdaten, wie zum Beispiel Vorgabebeträge, Kontostände

Bevorzugte Entgeltsicherung Zentral

[0026] In dem bevorzugten Entgeltsicherungs-Zentral-System werden die sendungsbezogenen Informationen gesammelt und anderen Systemen zur Verfügung gestellt. Hier findet die Erstellung der Produktionsberichte statt, die wiederum zur Erstellung der Negativdateien führen. Weiterhin erhält das Entgeltsicherungs-Zentral-System von der Gebührenbetragsladestelle (Postage Point) die aktuellen Schlüsseldaten und leitet diese an die einzelnen KryptoServer weiter.

Datenlieferanten

[0027] Zur inhaltlichen Überprüfung der 2D-Barcodes sind eine Reihe von Stammdaten notwendig, wie zum Beispiel Negativdateien, Mindestentgelte, Gültigkeitszeiträume in Relation zu dem Produkt und Entgeltgicherung-Warnungs- und Folgeverarbeitungscodes. Diese Daten werden aus unterschiedlichen Systemen (BDE, VIBRIS, lokales Entgeltsicherungs-System) bereitgestellt.

Entgeltsicherung-Anwendung

[0028] Mit der Entgeltsicherung-Anwendung besteht die Möglichkeit, bei der Nachbearbeitung ausgeschleuster PC-Freimachungs-Sendungen eine detailliertere Überprüfung der Frankierung vorzunehmen, bei der die Darstellung der Prüfergebnisse nicht durch begrenzte Ausgabemöglichkeiten des Scanners eingeschränkt wird. Zusätzlich kann der Prüfer hier auch weitere Daten einsehen, wie den Gültigkeitszeitraum des Portobetrages, auf welchen sich die aktuelle Sendung bezieht, sowie den Betrag und die in Anspruch genommenen Frankierungen.

Automatische Erfassung der 2D-Barcodes

[0029] Die 2D-Barcodes werden automatisch erfasst. Hierzu werden die Bildinformationen an den AFM-2D-Code-Leser weitergeleitet. Dort erfolgt die Konvertierung des Bildes in den Inhalt des Datamatrixcodes. Im Anschluss daran wird der 2D-Barcodeinhalt an das Krypto-System zur Prüfung übermittelt, das zurückgegebene Prüfergebnis ausgewertet und an das optische Erfassungssystem (IMM) zur Codierung der Sendung übermittelt. Bevorzugte Bestandteile eines derart erweiterten Überprüfungsverfahrens sind in Fig. 2 dargestellt.

AFM-2D-Code-Leser

[0030] Pro Lesemaschine (ALM/ILVM) existiert ein AFM-2D-Code-Leger, der über ein optisches Erfassungssystem (IMM) die Bilddaten der Sendungen erhält und für Entgeltsicherungszwecke weiter verarbeitet. Im Rahmen von bevorzugter Entgeltsicherungs-PC-Frankierung bedeutet dies im Falle eines erkannten 2D-Codes, dass aus den Bilddaten der 2D-Datamatrixcode extrahiert und unter Zuhilfenahme des Fehlerkorrekturverfahrens ECC200 in eine Bytekette umgewandelt wird, die den Inhalt des 2D-Barcodes darstellt.

[0031] Diese Bytekette wird an die Überprüfungseinheit (Validation-Controller) zur Überprüfung übergeben. Das Prüfergebnis wird anschließend über die Schnittstelle des optischen Erfassungssystems weitergeleitet und dort zur Codierung verwendet.

Krypto-System für AFM-2D-Code-Leser

[0032] Je nach Eigenschaften der Kryptokarten kann beispielhaft mit etwa 27 Prüfungen pro Sekunde gerechnet werden. Da die Rate der Lesemaschinen bei etwa 10 gelesenen Sendungen pro Sekunde liegt, erscheint es nicht sinnvoll, jeden der AFM-2D-CodeLeser mit einem Krypto-System zu kombinieren. Hinzu kommt, dass auch nicht davon auszugehen ist, dass PC-F-Sendungen zu hundert Prozent auf allen Maschinen gleichzeitig produziert werden. Es erscheint daher sinnvoll, die Krypto-Systeme zu separieren und mehrere PC-F-Leser mit einem Krypto-System zu betreiben. Die Lösung sollte dabei so gewählt sein, dass sie sich skalieren lässt, also mehrere Krypto-Systeme pro Briefzentrum möglich sind. Dies ist zum Beispiel für Briefzentren mit einem hohen Sendungsaufkommen und einer hohen Anzahl Lesemaschinen relevant, bei denen initial ein zweites Krypto-System vorgesehen werden kann. Zudem kann später im Betrieb die Anzahl der Server bei entsprechendem Bedarf erhöht werden.

[0033] Die Architektur ist zur Verringerung der Komplexität dabei vorzugsweise so zu wählen, dass die einzelnen Lesemaschinen einem Krypto-System fest zugeordnet und eventuell noch um eine zusätzliche Fallback-Konfiguration erweitert werden, die im Fehlerfalle versucht, auf ein anderes Krypto-System auszuweichen.

[0034] Die Trennung von Krypto-System und AFM-2D-Code-Leser bringt zudem den Vorteil, dass sowohl die Maschinenlesung als auch die Handscannerprüfung mit dem gleichen Krypto-System erfolgen kann, und deshalb die gleiche Funktion nicht doppelt zu implementieren ist, was zusätzlich auch wesentliche Vorteile bei der Implementation der Erfindung bietet.

[0035] Bevorzugte Verfahrensschritte zum Versehen einer Postsendung mit einem digitalen Freimachungsvermerk nach Laden eines Gebührenbetrages von einer zentralen Ladestelle (Postage Point) und Erzeugung des Freimachungsvermerks durch einen lokalen PC sowie anschließender Einlieferung der Postsendung und Überprüfung des auf der Postsendung aufgebrachten Freimachungsvermerks sind in Fig. 3 dargestellt.

[0036] Unabhängig von der Schlüsselverteilung erfolgt der Ablauf so, dass ein Kunde zuerst einen Portobetrag auf seinen PC lädt. Zur Kennzeichnung der Anfrage wird dabei eine Zufallszahl generiert. Auf der Gebührenbetragsladestelle (Postage Point) wird ein neuer Portobetrag zu dem jeweiligen Kunden erzeugt und aus der übermittelten Zufallszahl, weiteren Informationen zu der Identität des Kundensystems (die Kundensystemidentifikationsangabe, nachfolgend Postage ID genannt) und zu dem Portobetrag wird der sogenannte Cryptostring erstellt, der mit einem auf der Gebührenbetragsladestelle (Postage Point) existierenden geheimen symmetrischen Schlüssel verschlüsselt wird.

[0037] Dieser Cryptostring und der entsprechende Portobetrag werden anschließend auf den Kunden-PC übertragen und zusammen mit der Zufallszahl in dessen "Safe-Box" sicher vor ungewollten Zugriffen abgelegt.

[0038] Wird von dem Kunden im Anschluss an diesen Vorgang mit dem erhaltenen Portobetrag eine Post-Sendung frankiert, so werden die für den 2D-Barcode relevanten Sendungsdaten, unter anderem Cryptostring, Frankierdatum und Frankierbetrag, um die Zufallszahl erweitert und die Postage ID in unverschlüsselter Form gesammelt, und es wird ein Hashwert erstellt, der den Inhalt eindeutig kennzeichnet.

[0039] Da die Zufallszahl in verschlüsselter Form innerhalb des Cryptostrings sowie in unverschlüsselter Form innerhalb des Hashwerts vorliegt, wird sichergestellt, dass die Sendungsdaten nicht verändert, beziehungsweise willkürlich generiert werden können, und es wird ein Rückschluss auf den Ersteller möglich.

[0040] Die relevanten Daten zur Sendung werden dann anschließend in einen 2D-Barcode umgewandelt und als entsprechendes Frankierungskennzeichen durch den Drucker des Kunden auf die Sendung gedruckt. Die fertige Sendung kann daraufhin in den Postkreislauf gegeben werden.

[0041] Bei einer besonders bevorzugten Ausführungsform der Entgeltsicherung wird der 2D-Barcode in dem Briefzentrum von einem AFM-2D-Code-Leser, beziehungsweise von einem Handscanner, gelesen und anschließend geprüft. Die damit verbundenen Prozessschritte werden in der Abbildung unter den Vorgangsnummern 5-8 deutlich. Zur Überprüfung der Korrektheit des 2D-Barcodes übergibt der AFM-2D-Code-Leser die kompletten Sendungsdaten an das Krypto-System. Dort wird eine in den Sendungsdaten enthaltene kryptographische Information, insbesondere des Cryptostrings entschlüsselt, um die bei der Erstellung des Hashwertes verwendete Zufallszahl zu ermitteln.

[0042] Anschließend wird ein Hashwert (auch Message Digest genannt) zu den Sendungsdaten inklusive der entschlüsselten Zufallszahl ermittelt, und es wird überprüft, ob das Ergebnis mit dem im 2D-Barcode enthaltenen Hashwert identisch ist.

[0043] Zusätzlich zu der kryptographischen Validierung erfolgen noch weitere inhaltliche Prüfungen (Vorgangsnummer 7b), die zum Beispiel die doppelte Verwendung eines 2D-Barcodes ausschließen, beziehungsweise prüfen, ob der Kunde durch Betrugsversuche auffällig wurde und deswegen auf einer Negativdatei gelistet ist.

[0044] Das entsprechende Prüfergebnis wird daraufhin an den PC-F-Leser übermittelt, der das Ergebnis an das optische Erfassungssystem (IMM) zur Codierung des Barcodes weiterleitet. Der Barcode wird im Anschluss auf den Brief gespritzt und die Sendungen werden bei einem negativen Prüfergebnis ausgeschleust.

Krypto-System-Architektur;

Komponentenübersicht

[0045] Fig. 4 gibt eine Übersicht über die Teilkomponenten des Krypto-Systems, wobei die beschrifteten Pfeile Ein- und Ausgabedatenströme zu externen Systemen darstellen. Da das bevorzugte Entgeltsicherungs-Zentral-System als Drehscheibe bei der Verteilung der Schlüssel der Gebührenbetragsladestelle (Postage Point) an die Krypto-Systeme der lokalen Entgeltsicherungssysteme verwendet wird und diese Daten zwischengespeichert werden müssen, ist dort ebenfalls eine Krypto-System-Komponente vorzusehen, bei der jedoch die Überprüfungseinheit in der Regel nicht genutzt wird.

[0046] Die Teilkomponenten des Krypto-Systems werden im Folgenden detaillierter beschrieben.

Überprüfungseinheit

[0047] Die Überprüfungseinheit stellt die Schnittstelle zur Überprüfung des kompletten 2D-Barcodeinhalts dar. Die Überprüfung des 2D-Barcodes besteht aus einer inhaltlichen und einer kryptographischen Überprüfung. Zu diesem Zweck sollte der eingelesene 2D-Barcodeinhalt der Scanner durch den Scanner Controller an die Überprüfungseinheit weitergeleitet werden.

[0048] Da sich der verantwortliche Scanner Controller für den drahtgebundenen Scanner und die Überprüfungseinheit auf unterschiedlichen Rechnersystemen befinden, ist eine TCP/IP-basierte Kommunikation zwischen ihnen vorzusehen, wobei statt reiner Socket-Programmierung der Einsatz eines darauf aufsetzenden Protokolls Vorteile bietet. Im Rahmen des Krypto-Systems kommen hier der innerhalb der Betriebsdatenerfassung (BDE) verwendete Telegrammmanager oder das im Rahmen des optischen Erfassungssystems verwendete Protokoll wie Corba/IIOP in Frage.

[0049] Die Überprüfungseinheit initiiert die einzelnen Prüfroutinen, die wiederum ihre Prüfergebnisse an sie zurückübermitteln.

[0050] Die Überprüfungseinheit ist "multisessions-fähig" augelegt. Das heißt, sie muss gleichzeitige Prüfanfragen bewerkstelligen und die entsprechende Ausgabe auf den richtigen Scanner lenken können. Zudem sollte sie so ausgelegt werden, dass sie gleichzeitig mehrere Prüfanfragen, sowie einen Teil der Prüfungsschritte, zum Beispiel Hashwertprüfung und Mindestentgeltprüfung, parallel dazu ausführen kann.

[0051] Zu Beginn einer Sitzung wird dem Controller mitgeteilt, mit welchem Typ von Scanner er kommuniziert, und er bekommt eine Möglichkeit zugeordnet, per CallBack-Methode, Routinen zur Ausgabe und zur manuellen Nachprüfung anzusteuern. Je nach Betriebsart und Scannertyp werden die Ergebnisse dann entweder auf dem Funkscanner oder dem Entgeltsicherung-System ausgegeben, sowie manuelle Prüfergebnisse erfasst.

Krypto Karte

[0052] Eine besondere Problematik liegt in der Aufbewahrung des Schlüssels, mit dem der Cryptostring in einem 2D-Barcode verschlüsselt und zur Prüfung wieder entschlüsselt werden muss. Dieser Schlüssel stellt die Fälschungssicherheit der 2D-Barcodes sicher und deshalb darf es nicht möglich sein, ihn auszuspionieren. Daher muss durch spezielle Sicherheitsmaßnahmen gewährleistet sein, dass dieser Schlüssel niemals im Klartext auf der Festplatte, im Speicher oder bei der Übertragung sichtbar und zudem durch starke kryptographische Verfahren abgesichert ist.

[0053] Rein Software basierte Lösungen bringen hier keine zuverlässige Sicherheit, da an irgendeiner Stelle im System doch ein Schlüssel im Klartext erscheint, oder der Schlüssel mit einem Debugger im Klartext im Speicher ausgelesen werden könnte. Diese Gefahr besteht vor allem auch dadurch, dass die Systeme remote administriert werden können, beziehungsweise zwecks einer Reparatur eventuell außer Haus gegeben werden.

[0054] Zudem erzeugen die kryptographischen Verfahren eine hohe Last auf dem Prozessor des Systems, der im Hinblick auf die durchzuführenden Operationen nicht optimiert ist.

[0055] Es empfiehlt sich daher der Einsatz einer Kryptoprozessorkarte mit folgenden Kennzeichen:

• Spezieller Kryptoprozessor zur Beschleunigung von kryptographischen Verfahren
• Abgeschlossenes Black-Box-System zur Verhinderung des Zugriffs auf sicherheitskritische Daten und Verfahren.

[0056] Bei den Karten, welche diese Kennzeichen erfüllen, handelt es sich um autarke Systeme, die je nach Ausführung über den PCI-oder den ISA-Bus mit dem Rechner verbunden sind und über einen Treiber mit den Softwaresystemen auf dem Rechner kommunizieren.

[0057] Neben batteriegepuffertem Hauptspeicher besitzen die Karten auch einen Flash-Rom-Speicher, in dem ein individueller Anwendungscode gespeichert werden kann. Der direkte Zugriff auf den Hauptspeicher der Karten ist von den äußeren Systemen nicht möglich, wodurch eine sehr hohe Sicherheit gewährleistet ist, da weder die Schlüsseldaten noch die kryptographischen Verfahren zur Bereitstellung der Sicherheit anders als über den gesicherten Treiber greifbar sind.

[0058] Zusätzlich überwachen die Karten mittels eigener Sensoren, ob Manipulationsversuche vorliegen (je nach Kartenausführung, zum Beispiel Temperaturspitzen, Strahlung, Öffnen der Schutzabdeckung, Spannungsspitzen).

[0059] Liegt ein solcher Manipulationsversuch vor, so wird der batteriegepufferte Hauptspeicherinhalt sofort gelöscht und ein Shutdown der Karte durchgeführt.

[0060] Für den Crypto Server sollte die Funktion zur Entschlüsselung der Postage ID, die Funktion zum Prüfen des Hashwertes, sowie die Funktion zum Importieren von Schlüsseldaten direkt auf die Karte geladen werden, da diese Routinen eine hohe Sicherheitsrelevanz besitzen.

[0061] Ferner sollten alle kryptographischen Schlüssel, sowie die Konfigurationen von Zertifikaten, die zur Durchführung der Authentisierung notwendig sind, ebenfalls im batteriegepufferten Speicher der Karte gesichert werden. Verfügt die Karte über nicht genügend Speicher, so existiert auf der Karte in der Regel ein Master Key, mit dem die oben aufgeführten Daten verschlüsselt werden und anschließend auf der Festplatte des Systems abgelegt werden können. Dies erfordert jedoch, dass vor Benutzung dieser Informationen die Daten zunächst wieder entschlüsselt werden.

[0062] Die folgende Tabelle gibt eine Übersicht der in Frage kommenden Kartenmodelle unterschiedlicher Hersteller und nennt gleichzeitig ihre Zertifizierungen.

[0063] Kryptokarten für den Einsatz innerhalb des bevorzugten Entgeltsicherungs-Systems für die PC-Frankierung

Hersteller	Typbezeichnung	Zertifizierung
IBM	4759-023	FIPS PUB 140-1 Level 3 und ZKA-ecash
IBM	4758-002	FIPS PUB 140-1 Level 4 und ZKA-eCash (voraus. 07/2000) CCEAL 5 (angestrebt, z.Zt. in Zertifizierungsphase)
Utimaco	KryptoServer	ITSEC-E2 und ZKA-eCash
Utimaco	KryptoServer 2000 (verfügbar ca. 1Q/01)	FIPSPUB 140-1 Level 3, ITSEC-E3 und ZKA-eCash (angestrebt)
Racal/Zaxus	WebSentry PCI	FIPS PUB 140-1 Level 4

[0064] Neben der Erfüllung der an die Karte gestellten Anforderungen ist es wegen der gewünschten Zertifizierung durch das BSI auch sehr wichtig, welche Zertifizierungen die einzelnen Modelle zur Zeit besitzen und welche Zertifizierungen sich zur Zeit im Evaluationsprozess befinden.

[0065] Für die Produkte ausgestellte Zertifikate unterteilen sich dabei in die drei von unterschiedlichen Zertifizierungsstellen vorgenommenen Einstufungen.

[0066] Die ITSEC ist ein von der Europäischen Kommission veröffentlichtes Kriterienwerk zur Zertifizierung von IT-Produkten und IT-Systemen im Hinblick auf deren Sicherheitseigenschaften. Die Vertrauenswürdigkeitsbewertung richtet sich nach den Stufen E0 bis E6, wobei E0 unzureichende und E6 höchste Sicherheit bedeutet. Eine Weiterentwicklung und Harmonisierung mit ähnlichen internationalen Standards sind die CC (Common Criteria), die sich zur Zeit in einem Standardisierungsprozess bei der ISO (ISO Norm 15408) befinden. Dieses Regelwerk wird zur Bewertung der Sicherheit des Systems herangezogen.

[0067] Es gibt zurzeit noch kein Produkt aus obiger Tabelle, das über ein Zertifikat nach CC verfügt. Das IBM-Modell 4758-002 befindet sich jedoch zurzeit in einer solchen Zertifizierungsphase.

[0068] Der Standard FIPS PUB 140-1 ist ein von der amerikanischen Regierung herausgegebenes Kriterienwerk zur Beurteilung der Sicherheit von kommerziellen kryptographischen Geräten. Dieses Kriterienwerk orientiert sich sehr stark an Hardwareeigenschaften. Die Bewertung erfolgt in 4 Stufen, bei denen Level 1 die geringste und Level 4 die höchste Sicherheit bedeutet.

[0069] Zusätzlich zu dem oben genannten Bewertungsstandard gibt es ein weiteres Kriterienwerk, das vom Zentralen Kreditausschuss (ZKA) herausgegeben wird und Zulassungen für den Betrieb von IT-Systemen und -Produkten im Bereich electronic cash regelt.

[0070] Neben den bereits erwähnten Eigenschaften der Karten und den zugeteilten Zertifizierungen gibt es jedoch noch eine Reihe weiterer Vorzüge, die nachfolgend kurz aufgelistet sind:

• Erstellung eigener (signierter) Software und Upload auf die Karte möglich
• Integrierter Zufallszahlengenerator (FIPS PUB 140-1 zertifiziert)
• DES, Triple DES und SHA-1 hardwareseitig implementiert
• RSA-Key-Erzeugung und Private/Public Key - Verarbeitung für Schlüssel bis zu 2048 Bit Länge
• Key Management - Funktionen
• Zertifikatsmanagement - Funktionen
• Zum Teil Betrieb mehrerer Kryptokarten parallel in einem System möglich

Krypto Interface

[0071] Die im Rahmen der Kryptokartenapplikation sicherheitsrelevanten Funktionen werden direkt in der Karte gespeichert und sind daher von außen nur über den Kartentreiber zugreifbar. Als Schnittstelle zwischen dem Treiber und der Überprüfungseinheit dient die Krypto Interface-Komponente, welche die Requests für Prüfroutinen per Treiber an die Karte weiterleitet.

[0072] Da mehrere Karten innerhalb eines Rechners zum Einsatz kommen können, liegt die Aufgabe des Krypto Interfaces auch darin, eine Lastverteilung der einzelnen Prüfrequests vorzunehmen. Diese Funktion ist insbesondere dann zweckmäßig, wenn zusätzlich noch einer oder je nach Briefzentrum mehrere AFM-2D-Code-Leser die Prüfroutinen des Krypto-Systems nutzen.

[0073] Eine weitere Aufgabe besteht in der Abwicklung der Kommunikation zwecks Verteilung der Schlüsseldaten. In Stufe 2 existiert eventuell nur ein rudimentärer Mechanismus, der die zur Sicherheit verschlüsselten Schlüssel innerhalb einer signierten Datei überträgt. Eine Anforderung an das Krypto Interface liegt dann darin, ein Utility bereitzustellen, das den Import einer solchen Datei ermöglicht.

Funktionen des Krypto-Systems

Ablauf der Prüfung in der Überprüfungseinheit

[0074] Zur Prüfung des 2D-Barcodes wird von der Überprüfungseinheit eine zentrale Prüffunktion als Schnittstelle zu den Scanner-beziehungsweise den Lesesystemen zur Verfügung gestellt. Diese Prüffunktion koordiniert den Ablauf der einzelnen Teilprüfungen.

[0075] Die aus den einzelnen Teil-Prüfroutinen übermittelten Codes für den Entgeltsicherung-Vorfall werden anhand einer vordefinierten Tabelle, die vorzugsweise zentral gepflegt und auf das Krypto-System übertragen wird, in den entsprechenden Entgeltsicherungs-Code umgewandelt. Innerhalb dieser Tabelle werden zusätzlich Prioritäten festgelegt, die regeln, welcher Entgeltsicherungs-Code zugewiesen wird, wenn mehrere Entgeltsicherungs-Vorfälle erkannt wurden.

[0076] Dieser Entgeltsicherungs-Code wird anschließend zusammen mit einem beschreibenden Text als Prüfergebnis zurückgeliefert. Je nach weiterverarbeitendem System außerhalb des Krypto Systems wird dieses Ergebnis dann auf dem Funkscanner oder innerhalb der Entgeltsicherungs-Anwendung ausgegeben, beziehungsweise bei der automatischen Prüfung in einen TIT2-Code umgewandelt und die Sendung damit bedruckt.

[0077] Da die Abläufe zwischen den Handscannersystemen und den automatischen Lesesystemen unterschiedlich sind, wird für beide Anwendungsfälle eine unterschiedliche Funktion implementiert.

[0078] Je nachdem, welcher Kommunikationsmechanismus zwischen dem Lesesystem und der Überprüfungseinheit verwendet wird, unterscheidet sich der Aufruf und die Rückgabe der Ergebnisse. Im Falle des Einsatzes eines synchronen RPC-basierten Protokolls wie Corba/IIOP wird die Prüfmethode direkt aufgerufen und die Prüfergebnisse werden nach Abschluss der Prüfung übergeben. Der Client, also der ScannerController, beziehungsweise das Lesesystem warten in diesem Fall auf die Ausführung und die Rückgabe der Prüfergebnisse. Bei letzterem ist daher auf dem Client ein Threadpool vorzusehen, der die parallele Prüfung mehrerer Anfragen durchführen kann.

[0079] Bei dem asynchronen Mechanismus mittels TGM wird vom Scanner Controller, beziehungsweise dem Lesesystem, die Prüfmethode nicht direkt aufgerufen, sondern es wird ein Telegramm an das Krypto-System gesendet, welches die Prüfanforderung, den Inhalt des 2D-Barcodes und weitere Informationen wie aktuelles Sortierprogramm enthält. Bei Eingang dieses Telegramms auf dem Krypto-System wird die Prüffunktion aufgerufen, durchgeführt und die Lese- und Prüfergebnisse wiederum als ein neues Telegramm zurückgesendet. Der Vorteil bei diesem Verfahren liegt darin, dass auf dem anfordernden System der Prozess nicht blockiert wird, bis das Ergebnis vorliegt.

Prüfung für Handscannersysteme:

[0080] Die Prüfroutine für die Handscannersysteme erwartet als Eingabewerte die Session-ID sowie den Inhalt des 2D-Barcodes.

[0081] Als zusätzlicher Parameter wird auch noch die ID des Sortierprogramms erwartet. Der zuletzt genannte Parameter dient zur Bestimmung des Mindestentgelts.

[0082] Fig. 5 zeigt eine Übersicht über den Ablauf der Prüfung innerhalb der Überprüfungseinheit für den Fall, dass diese von einem Handscannersystem ausgelöst wurde. Es wird dabei von einer Prüfung mit einem Funkscanner mit anschließendem manuellen Vergleich der Anschrift mit dem 2D-Barcodeinhalt ausgegangen. Bei einem drahtgebundenen Scanner würde die Darstellung analog auf dem Entgeltsicherung-System, beziehungsweise der Entgeltsicherungs-Anwendung erfolgen.

[0083] Ein bevorzugter Überprüfungsablauf durch Einsatz eines Funkscanners, eines Scanner-Controllers und einer Überprüfungseinheit (Validation Controller) ist in Fig. 5 dargestellt.

[0084] Die Überprüfungseinheit steuert bei dem dargestellten, besonders bevorzugten Ausführungsbeispiel, einen Ablauf von Teilprüfungen, wobei die erste Teilprüfung ein Einlesen eines in dem digitalen Freimachungsvermerks enthaltenen Matrixcodes beinhaltet. Der eingelesene Matrixcode wird zunächst von einem Funkscanner an einen Scanner-Controller übertragen. Anschließend erfolgt in dem Bereich des Scanner-Controllers eine Prüfung des Matrixcodes sowie eine Übermittlung an die Überprüfungseinheit. Die Überprüfungseinheit steuert eine Aufspaltung des Codeinhalts. Das Leseergebnis wird anschließend an die Erfassungseinheit - im dargestellten Fall ein Funkscanner - übermittelt. Hierdurch erfährt beispielsweise ein Benutzer der Leseeinheit, dass es möglich war, den Freimachungsvermerk zu lesen und die in der Matrix enthaltenen Informationen dabei zu erkennen. Anschließend entschlüsselt die Überprüfungseinheit einen in dem Matrixcode enthaltenen Cryptostring. Hierzu wird vorzugsweise zunächst die Version des voraussichtlich für die Erstellung des Freimachungsvermerks eingesetzten Schlüssels überprüft. Anschließend wird der in dem Cryptostring enthaltene Hashwert geprüft.

[0085] Ferner erfolgt eine Prüfung des vorgesehenen Mindestentgelts.

[0086] Außerdem wird eine Identifikationsnummer (Postage ID) des die Erzeugung des Freimachungsvermerks steuernden Kundensystems überprüft.

[0087] Hieran anschließend erfolgt ein Abgleich der Identifikationsnummer mit einer Negativliste.

[0088] Durch diese Überprüfungsschritte ist es in dieser besonders einfachen und zweckmäßigen Form möglich, auf einfache Weise unberechtigt erzeugte Freimachungsvermerke zu ermitteln.

[0089] Das Ergebnis der Übermittlung wird als eine digitale Nachricht übermittelt, wobei die digitale Nachricht beispielsweise an den ursprünglichen Funkscanner übermittelt werden kann. Hierdurch kann beispielsweise ein Benutzer des Funkscanners die Sendung aus dem Sendungslauf ausschleusen. Bei einer automatisierten Durchführung dieser Verfahrensvariante ist es jedoch selbstverständlich gleichermaßen möglich, die Sendung aus dem normalen Verarbeitungslauf der Postsendungen auszuschleusen.

[0090] Vorzugsweise wird das Ergebnis der Prüfung im Bereich der Überprüfungseinheit protokolliert.

[0091] Als Rückgabewert sollte der zu dem Entgeltsicherungs-Vorfall gehörende Code und die zugehörige Textmeldung sowie das 2D-Barcode-Objekt zurückgegeben werden.

Prüfungsablauf beim AFM-2D-Code-Leser

[0092] Als Eingabeparameter der Prüfroutine für den AFM-2D-Code-Leser wird ebenfalls die Session-ID, sowie der Inhalt des 2D-Barcodes und die eindeutige Kennzeichnung des zur Zeit aktiven Sortierprogramms erwartet.

[0093] Fig. 6 zeigt eine Übersicht über den Ablauf der Prüfung innerhalb der Überprüfungseinheit für den Fall, dass diese von einem Lesesystem ausgelöst wurde.

[0094] In der Abbildung sind zur Verdeutlichung des Ablaufs auch zusätzlich das optische Erfassungssystem (IMM-System) sowie der AFM-2D-Code-Leser aufgeführt, um den Gesamtkontext der Prüfung darzustellen. Der Anteil des Krypto-Systems beschränkt sich allerdings darauf, die Funktionen zwischen 2D-Barcode und der Rückgabe sowie der Protokollierung des Ergebnisses zu prüfen.

[0095] Im Falle der Telegrammmanager-Schnittstelle würden auf der Überprüfungseinheit mehrere Service Tasks gestartet, die auf Prüfanforderungstelegramme warten und mit dem Telegramminhalt die Prüfroutine aufrufen würden. Das Ergebnis der Prüfroutine wird abgewartet und in ein Telegramm verpackt und an den Anforderungsclient zurückgesendet.

[0096] In Fig. 6 ist eine weitere bevorzugte Ausführungsform einer Steuerung eines Ablaufs von Teilprüfungen durch die Überprüfungseinheit (Validation Controller) dargestellt. Bei dieser weiteren bevorzugten Ausführungsform erfolgt eine Erfassung der Freimachungsvermerke durch ein automatisches optisches Erkennungssystem (Prima/IMM). Die Daten werden von der optischen Überprüfungseinheit zu einer Lese- und Erfassungseinheit (AFM-2D-Code-Leser).

[0097] Bei der in Fig. 6 dargestellten Ausführungsform des Verfahrens zum Überprüfen der Gültigkeit von digitalen Freimachungsvermerken erfolgt ein Einlesen der digitalen Freimachungsvermerke vorzugsweise in einer noch stärker automatisierten Weise, beispielsweise durch optische Erfassung einer Stelle einer Postsendung, auf der vorzugsweise ein Freimachungsvermerk angeordnet ist. Die weiteren Überprüfungsschritte erfolgen im Wesentlichen entsprechend des anhand von Fig. 5 dargestellten Prüfungsablaufs.

[0098] Der Rückgabewert der Prüfroutine besteht einerseits aus dem Entgeltsicherungs-Code und einer zugehörigen Meldung sowie dem umgewandelten und um die Postage ID erweiterten Inhalt. Aus diesen Rückgabewerten wird ein Telegramm erzeugt und an das anfordernde Lesesystem übermittelt.

Inhaltliche Prüfungen

2D-Barcodeinhalt aufspalten und umformen

Input: gescannter 2D-Barcode

Beschreibung:

[0099] In dieser Funktion ist der aus 80 Bytes bestehende Inhalt des 2D-Barcodes aufzuteilen und in ein strukturiertes Objekt, im Folgenden mit 2D-Barcode-Objekt bezeichnet, umzuwandeln, um eine bessere Darstellungsmöglichkeit sowie eine effizientere Nachbearbeitung zu erreichen. Die einzelnen Felder und Umwandlungen sind in der nachfolgenden Tabelle beschrieben:

[0100] Bei der Umwandlung der Binär- in Dezimalzahlen ist darauf zu achten, dass das linke Byte einer Bytefolge das höchstwertige Byte ist. Kann eine Umwandlung eventuell wegen eines Typenkonflikts oder fehlender Daten nicht erfolgen, so ist eine Entgeltsicherungs-Vorfallsmeldung "PC-F-Barcode nicht lesbar" zu generieren und an die Überprüfungseinheit zurückzugeben. Eine weitere inhaltliche, beziehungsweise kryptographische Überprüfung ist in diesem Fall nicht sinnvoll.

Feld	Typ	umzuwandeln in	Beschreibung
Post-Unternehmen	ASCII (3 Byte)		keine Umwandlung notwendig
Frankierart	Binär (1 Byte)	Smallinteger
Versionskennzeichen	Binär (1 Byte)	Smallinteger	Versionsnummer des Verfahrens
Key-Nr.	Binär (1 Byte)	Smallinteger	Schlüsseltyp
CrypcoString	Binär (32 Byte)		Bytefolge ist unverändert zu übernehmen, nach Entschlüsselung wird die PostageID herausgespalten
postageID		Text(16 Zeichen)	Wird nach Entschlüsselung des Cryptostrings gefüllt
laufende Sendungsnummer	Binär (3 Byte)	Integer	nur positive Zählen
Produktochlüssel	Binär (2 Byte)	Integer	positive zahlen, verweis auf zugehörige Refereriztabelle
Entgelt	Binär (2 Byte)	Float	Umwandlung in positive Dezimalzahl, die durch hundert zu teilen ist, Angabe in Euro
Frankierdatum	Binär (3 Byte)	Date	Nach Umwandlung in positive Dezimalzahl, lässt sich das Datum nach dem Format YYYYMMDD umwandeln
EmpfängerPLZ	Binär (3 Byte)	2 werte, einen für Land, einen für PLZ-Code	Nach Umwandlung in positive Dezimalzahl ergeben die ersten beiden Ziffern den Länder-code, die fünf restlichen Ziffern die PLZ
straße/Postfach	ASCII (6 Byte)	Straßenkürzel oder Postfach	Handelt es sich bei den ersten Ziffern um Zahlen, dann ist eine PLZ codiert, ansonsten die ersten und letzten drei Stellen der Straße mit Hausnummer
Portorestbetrag	Binär (3 Byte)	Float + Währungsfeld (Text 32 Zeichen)	Nach Umwandlung in eine positive Dezimalzahl ergibt die erste Ziffer die Währung (1=Euro), die nachfolgenden vier Ziffern die Vorkomma- und die restlichen zwei Ziffern die Nachkommastellen
Hash-Wert	Binär (20 Byte)		Bytefolge ist unverändert zu übernehmen, dient zur kryptographischen validierung der Frankierung

Returnwert: 2D-Barcode-Objekt
Warnungscode 00 falls Umwandlung OK,
ansonsten Warnung für Entgeltsicherungs-Vorfall "PC-F-Barcode nicht lesbar"

Versionsnummernprüfung

Input: aktuelles 2D-Barcode-Objekt

Beschreibung:

[0101] Aus den ersten drei Feldern lässt sich die Version des 2D-Barcodes erkennen. Hieraus wird auch ersichtlich, ob es sich bei dem Frankiervermerk überhaupt um einen 2D-Barcode der Deutschen Post und nicht um einen 2D-Barcode eines anderen Dienstleisters handelt. Die Feldinhalte sind mit einer in der Anwendung vorkonfigurierten Liste gültiger Werte zu vergleichen. Wird keine Übereinstimmung gefunden, so wird eine Entgeltsicherungs-Warnung "PC-F-Version" zurückgeliefert. Die Überprüfung weiterer inhaltlicher als auch kryptographischer Aspekte ist dann sinnlos und sollte nicht weiterverfolgt werden.

Returnwert: Warnungscode 00 falls Versionsprüfung OK, ansonsten Warnungscode für Entgeltsicherung-Vorfall
"PC-F-Version"

Postage ID überprüfen

Input: 2D-Barcode-Objekt mit entschlüsselter Postage ID

Beschreibung:

[0102] Die in dem 2D-Barcode enthaltene Postage ID ist durch ein Prüfziffernverfahren (CRC 16) abgesichert, das an dieser Stelle zu überprüfen ist. Sollte diese Überprüfung fehlschlagen, so ist als Ergebnis eine Entgeltsicherungs-Warnung "PC-F Fälschungsverdacht (Postage ID)" zurückzugeben. Zur Überprüfung der Postage ID ist die vorherige Entschlüsselung des CryptoStrings erforderlich.

Returnwert: Code "00" falls Prüfung OK, ansonsten Warnungscode für Entgeltsicherungs-Vorfall
"PC-F Fälschungsverdacht (Postage ID)"

Prüfung der Zeitüberschreitung

Input: 2D-Barcode-Objekt

Beschreibung:

[0103] Diese Funktion dient der automatischen Überprüfung des Zeitintervalls zwischen Frankierung einer PC-freigemachten Sendung und deren Verarbeitung auf dem Briefzentrum. Zwischen beiden Daten darf nur eine bestimmte Anzahl von Tagen liegen. Die Anzahl der Tage richtet sich dabei nach dem Produkt und dessen Laufzeiten plus einem Karenztag.

[0104] Die Konfiguration des Zeitraums wird vorzugsweise in einer Produkt-Gültigkeitszeitraum-Relation gespeichert und im Rahmen einer Pflegemaske zentral gepflegt. In der Relation werden zu jedem für PC-Frankierung möglichen Produktschlüssel (Feld des 2D-Barcodes) die zugehörige Anzahl Tage, die zwischen Frankierung und Verarbeitung auf dem Briefzentrum liegen dürfen, festgehalten. In einem vereinfachten Verfahren wird nur eine Zeitraumangabe vorkonfiguriert, die sich auf Standardsendungen bezieht und als Konstante im System hinterlegt wird.

[0105] Zur Überprüfung wird die Anzahl der Tage zwischen dem aktuellen Testdatum bei der Verarbeitung und dem im 2D-Barcode enthaltenen Datum gebildet, zum Beispiel 02.08. bis 01.08. = 1 Tag. Ist die ermittelte Anzahl Tage größer als der für das Produkt vorgegebene Wert, so wird der dem Warnungsfall "PC-F-Datum (Frankierung)" zugeordnete Entgeltsicherungs-Code an die Überprüfungseinheit zurückgegeben, anderenfalls ein Code, der die erfolgreiche Prüfung dokumentiert. Wenn in einem vereinfachten Verfahren immer mit dem Wert für Standardsendungen verglichen wird, sollte nach Ausgabe des Prüfergebnisses die Möglichkeit gegeben sein, beispielsweise manuell über eine Taste am Scanner, dieses Prüfergebnis zu korrigieren, falls das aktuelle Produkt eine längere Laufzeit zulässt.

[0106] Eine weitere Prüfung der Zeitüberschreitung bezieht sich auf den Inhalt der Postage ID. Der im Rahmen einer Vorgabe heruntergeladene Portobetrag und damit auch die Postage ID besitzen einen vorgegebenen Gültigkeitszeitraum, in welchem die Sendungen zu frankieren sind. In der Postage ID ist der Zeitpunkt enthalten, bis zu welchem der Portobetrag gültig ist. Ist das Frankierdatum um eine bestimmte Anzahl Tage größer als dieses Gültigkeitsdatum, so wird der zur Entgeltsicherungs-Warnung "PC-F-Datum (Portobetrag)" gehörende Entgeltsicherungs-Warnungscode zurückgegeben.

Returnwert: Code "00" falls Prüfung OK, ansonsten Warnungscode für Entgeltsicherung-Vorfall
"PC-F-Datum (Portobetrag)" oder
"PC-F-Datum (Frankierung)"

Entgeltprüfung

Input: 2D-Barcode-Objekt; aktuelle Sortierprogramm-ID

Beschreibung:

[0107] Innerhalb dieser Funktion erfolgt die Prüfung des im 2D-Barcode enthaltenen Entgeltes gegen ein Mindestentgelt, das für Sendungen des zugehörigen Sortierprogramms definiert ist. Bei den Beträgen handelt es sich um Euro-Beträge.

[0108] Die Zuordnungen werden zwischen Sortierprogramm und Mindestentgelt über eine automatische Schnittstelle geliefert.

[0109] Ein vereinfachtes Verfahren ist ähnlich wie bei der Prüfung der Zeitüberschreitung anzuwenden. Hier wird in der Konfigurationsdatei zu der Anwendung ein konstantes Mindestentgelt definiert, das für alle Sendungen gilt. Daher ist die Übergabe des Sortierprogramms nicht erforderlich.

[0110] Bei der anschließenden Prüfung wird verglichen, ob das im 2D-Barcode enthaltene Mindestentgelt unterhalb dieser Marke liegt. Ist dies der Fall, so wird der dem Entgeltsicherungs-Vorfall "PC-F Unterfrankierung" zugeordnete Code zurückgegeben, ansonsten der Erfolgscode.

Returnwert: Code "00" falls Prüfung OK, ansonsten Warnungscode für Entgeltsicherung-Vorfall
"PC-F-Unterfrankierung"

Abgleich mit Negativdatei

Input: 2D-Barcode-Objekt mit entschlüsselter Postage ID

Beschreibung:

[0111] Innerhalb dieser Funktion erfolgt die Prüfung, ob die zu dem 2D-Barcode gehörende Postage ID in einer Negativdatei enthalten ist. Die Negativdateien dienen dazu, Sendungen von Kunden, die durch Missbrauchsversuche aufgefallen sind, beziehungsweise deren PC entwendet wurde, aus dem Beförderungslauf herauszunehmen.

[0112] Die Negativdateien werden dabei zentral im Rahmen des Projektes Datenbank Freimachung gepflegt. Im Rahmen der Schnittstelle zu diesem Projekt ist das Verfahren für den Austausch der Daten auf die dezentralen Briefzentrum-Systeme zu bestimmen.

[0113] Wenn die Pflegeanwendung, beziehungsweise der Datenaustausch eventuell noch nicht existiert, ist hier ein Übergangsmechanismus zu schaffen. Die Pflege dieser Daten könnte übergangsweise in einem Excel-Sheet erfolgen, aus dem eine csv-Datei generiert wird. Diese Datei sollte per eMail verschickt und über einen vorzusehenden Importmechanismus in den Systemen eingelesen werden. Später erfolgt die Übertragung dann über den innerhalb des bevorzugten Entgeltsicherungs-IT-Feinkonzeptes definierten Weg.

[0114] Eine Postage ID kennzeichnet eine einzelne Vorgabe, die ein Kunde von dem System (Postage Point) abruft. Diese Vorgaben werden in einer sogenannten Safebox auf dem Kundensystem gespeichert. Es handelt sich hierbei um eine Hardwarekomponente in Form einer SmartCard inklusive Lesesystem, beziehungsweise eines Dongles. In der Safebox werden die Vorgabebeträge sicher aufbewahrt und der Kunde kann davon einzelne Frankierungsbeträge abrufen, ohne online mit der Gebührenbetragsladestelle (Postage Point) verbunden zu sein.

[0115] Jede Safe Box ist durch eine eindeutige ID gekennzeichnet. Diese Safebox-ID wird in der Negativdatei eingetragen, falls die zugehörigen Sendungen wegen Missbrauchsverdacht ausgeschleust werden sollen. Die Safebox-ID ist aus mehreren Feldern zusammengesetzt. Neben dem eindeutigen Schlüssel sind in der Safebox-ID auch weitere Felder wie Gültigkeitsdatum und Prüfziffer enthalten. Zur eindeutigen Identifizierung der Safebox sind die ersten drei Felder der Safebox-ID maßgeblich. Diese finden sich auch in den ersten drei Feldern der PostageID wieder, wodurch die Zuordnung zwischen Safebox und Vorgabe erfolgen kann. Die Felder sind in der nachfolgenden Tabelle beschrieben:

Byte Nr.	Länge	Bedeutung	Dateninhalt	Kommentar
b1	1	Anbieter-Kennzeichnung	00	nicht benutzt
			01	Test-Anbieter: Postversand-unternehmen
			FF	Postage-Point-Box des Postversand-unternehmens
b2	1	Zugelassene Modell-Nr.	XX	Für jeden Hersteller von 01 (erstes eingereichtes Modell) aufsteigend für jedes neu zugelassene Modell zu belegen.
b3, b4, b5	3	Seriennummer des Modelle	XX XX XX	Für jedes zugelassene Modell jedes Herstellers von 00 00 01 bis FF FF FF aufsteigend zu belegen.

[0116] Sind die ersten drei Felder der Postage ID der aktuell geprüften Frankierung identisch mit den ersten drei Feldern einer in der Negativdatei enthaltenen Safebox-ID, so wird der innerhalb der Negativdatei dem Kunden zugeordnete Entgeltsicherungs-Vorfall zurückgegeben, ansonsten der Erfolgscode.

Returnwert: Code "00" falls Prüfung OK, ansonsten dem Kunden, beziehungsweise der Safe-Box in der Negativdatei zugeordneter Warnungscode

Vergleich 2D-Barcodeinhalt mit Sendungsklartext

Input: 2D-Harcode-Objekt

Beschreibung:

[0117] Um zu verhindern, dass Kopien von 2D-Barcodes erstellt werden können, wird ein Vergleich zwischen den im 2D-Barcode kodierten Sendungsdaten und den auf dem Brief im Klartext angegebenen Daten durchgeführt. Dieser Vergleich ist bei den Funkscannern direkt möglich, da dort ausreichende Darstellungs- und Eingabemöglichkeiten vorhanden sind. Bei den Handscannern mit Drahtanbindung ist die Prüfung auf dem PC (Entgeltsicherung-System) vorzunehmen.

[0118] Der Ablauf sieht so aus, dass die Überprüfungseinheit nach Ablauf der automatisierten Prüfungen die Ausgabe der Daten des 2D-Barcodes auf dem Funkscanner, beziehungsweise auf dem Entgeltsicherungs-PC, veranlasst. Hierzu steht ihm eine Callback-Methode zur Verfügung, die am Anfang einer Sitzung zugeordnet wird.

[0119] Diese ruft er mit dem aktuellen 2D-Barcode-Objekt auf. Daraufhin sind der Scanner Controller, beziehungsweise der Entgeltsicherungs-PC für die Darstellung des 2D-Barcodeinhalts verantwortlich und liefern als Returnwert (nach Bearbeitung durch den Prüfer) der Callback-Methode eine "00", beziehungsweise einen zugehörigen Fehlercode zurück.

[0120] Bei erfolgreicher Auswertung wird der Erfolgscode, ansonsten der Code der Entgeltsicherungs-Warnung "PC-F-Klartext" zurückgegeben.

[0121] Bei einer automatischen Prüfung ist diese Prüfung nicht erforderlich. Hier kann die Prüfung vorzugsweise im Rahmen der zentralen Auswertungen offline entweder mittels Umsatzvergleichen oder über einen Vergleich der Zielpostleitzahl mit der im 2D-Barcode enthaltenen Postleitzahl erfolgen.

Returnwert: Code "00" falls Prüfung OK, ansonsten Warnungscode für Entgeltsicherungs-Vorfall
"PC-F-Klartext"

Kryptographische Prüfungen

[0122] Die kryptographische Prüfung besteht aus zwei Teilen:

a) der Entschlüsselung des Cryptostrings und

b) dem Hashwert-Vergleich.

[0123] Beide Verfahren sind in dem geschützten Bereich der Kryptokarte durchzuführen, da ein Kunde bei Ausspionage der bei der Verarbeitung anfallenden Information gültige Frankierungshashwerte erzeugen könnte.

Cryptostring entschlüsseln

Input: 2D-Barcode-Objekt

Beschreibung:

[0124] Als Eingangsparameter erhält diese Funktion das aufgesplittete 2D-Barcode-Objekt des Scanergebnisses. Es wird anhand des Frankierungsdatums und der Key-Nummer der für diesen Zeitpunkt gültige symmetrische Schlüssel herausgesucht und der CryptoString des übergebenen Objektes mit Hilfe dieses Schlüssels nach dem Verfahren Triple DES CBC entschlüsselt. Mit welchem Wert der Initialisierungsvektor vorzubelegen ist, beziehungsweise ob mit Inner- oder Outerbound-CBC und mit welcher Blocklänge gearbeitet wird, wird im Rahmen der Schnittstelle zu dem Entgeltsicherungssystem entschieden.

[0125] Sollte der in dem 2D-Barcode enthaltene Schlüssel auf dem Kryptosystem nicht vorhanden sein, so wird die Entgeltsicherungs-Warnung "PC-F Fälschungsverdacht (Schlüssel)" mit der Fehlermeldung, dass der Schlüssel mit der Key-Nummer nicht gefunden wurde, zurückgegeben.

[0126] Das Ergebnis der Operation besteht aus der entschlüsselten Postage ID, sowie der entschlüsselten Zufallszahl. Die entschlüsselte PostageID wird in einem entsprechenden Feld des 2D-Barcode-Objektes eingetragen. Die Zufallszahl sollte aus Sicherheitsgründen nicht bekannt gemacht werden, da der Kunde bei Besitz dieser Information gültige Hashwerte erzeugen und damit 2D-Barcodes fälschen könnte.

[0127] Im Anschluss an die Entschlüsselung wird aus der Methode heraus die Hashwertberechnung aufgerufen und deren Rückgabewert zurückgegeben.

Hashwertberechnung

Input: 2D-Barcode-Objekt entschlüsselte Zufallszahl aus dem Cryptostring (die entschlüsselte Zufallszahl darf nicht außerhalb der Karte bekannt sein)

Beschreibung:

[0128] Die Funktion der Hashwertberechnung ermittelt aus den im 2D-Barcode-Objekt enthaltenen Original-Scanergebnis die ersten 60 Bytes. Daran werden die entschlüsselte Postage ID sowie die übergebene entschlüsselte Zufallszahl angehängt. Hieraus wird nach dem Verfahren SHA 1 ein Hashwert berechnet und mit dem im 2D-Barcode-Objekt enthaltenen Hashwert des 2D-Barcodes verglichen. Stimmen alle 20 Bytes überein, so ist die kryptographische Überprüfung erfolgreich, und es wird ein entsprechender Rückgabewert zurückgeliefert.

[0129] Bei Nichtübereinstimmung wird eine Entgeltsicherungs-Warnung "PC-F-Fälschungsverdacht (Hashwert)" an die Überprüfungseinheit zurückgegeben.

[0130] Als Rückgabewert wird zusätzlich der errechnete Hashwert übermittelt, damit dieser bei dem Prüfergebnis mit ausgegeben werden kann.

Returnwert: errechneter Hashwert Code "00" falls Prüfung OK, ansonsten Warnungscode für Entgeltsicherungs-Vorf all
"PC-F-Fälschungsverdacht (Hashwert)" oder
"PC-F-Fälschungsverdacht (Schlüssel)"

Ergebnisausgabe

Prüf- und Leseergebnis darstellen

Beschreibung:

[0131] Über eine Callback-Methode hat die Überprüfungseinheit die Möglichkeit, eine Ergebnisausgabe auf dem zur aktuellen Prüfung gehörenden Ausgabegerät anzusteuern. Hierzu übergibt sie dieser Callback-Methode das 2D-Barcode-Objekt und den ermittelten Entgeltsicherung-Warnungscode. Als Rückgabewert kann der Code des ausgewählten Nachbearbeitungsverfahrens geliefert werden.

[0132] Die Callback-Methode für die Ausgabe wird, ebenfalls zu Beginn der Session, bei der Anmeldung an die Überprüfungseinheit zugewiesen.

Ergebnisprotokollierung

Input: 2D-Barcode-Objekt, Code des Prüfergebnisses

Beschreibung:

[0133] Die Ergebnisprotokollierung erfolgt in einem vereinfachten Verfahren in einer Datei auf dem System, auf dem die Überprüfungseinheit läuft. In der Regel werden die Ergebnisse, beziehungsweise Berichtigungssätze direkt an BDE übermittelt und über die bevorzugte Entgeltsicherungs-BDE-Schnittstelle in die Datenbank des bevorzugten lokalen Entgeltsicherungs-Systems geschrieben.

[0134] Vorzugsweise werden die Postage ID, die fortlaufende Nummer, das Frankierdatum, das Entgelt, der Produktschlüssel, die PLZ, der Entgeltsicherungs-Ergebniscode, der Meldungstext, die Dauer der Prüfung, der Zeitpunkt der Prüfung, die ID des Scanners, die Betriebsart des Scanners, der Erfassungsmodus, sowie die Weiterverarbeitungsart gespeichert. Alle Werte werden durch ein Semikolon voneinander getrennt in jeweils einem Satz pro Sendung ausgegeben und sind so zum Beispiel in Excel weiter auswertbar.

[0135] Befindet sich das System in der Betriebsart "Ersterfassung", so ist in der Spalte Erfassungsmodus ein "e", ansonsten ein "n" für Nacherfassung einzugeben.

Stammdatenbereitstellung

Beschreibung:

[0136] Für die inhaltliche Überprüfung sind eine Reihe von Stammdaten notwendig. Es handelt sich hierbei um:

• PC-F-Negativdatei
• Sortierprogramme und Mindestentgelte
• Allgemeines Mindestentgelt
• Produktschlüssel PC-F
• Maximale Einlieferungszeit je Produktschlüssel PC-F
• Allgemeine maximale Einlieferungszeit
• Entgeltsicherungs-Vorfälle, Prioritäten und Zuordnung zu Weiterbehandlungsanweisungen
• Weiterbehandlungsanweisungen

[0137] Stammdaten können in einer Übergangszeit mit Ausnahme der PC-F-Negativdatei sowie der kryptographischen Schlüssel der Gebührenbetragsladestelle (Postage Point) fest vorkonfiguriert werden.

[0138] Falls notwendig, können für einen Teil der Daten einfache Bearbeitungs- und Verteilanwendungen implementiert werden. Die Pflege sollte dann in einem Excel-Sheet erfolgen, aus dem eine csv-Datei generiert wird. Diese Datei sollte per eMail verschickt und über einen vorzusehenden Mechanismus in den Systemen eingelesen werden.

[0139] In der Regel werden die Daten entsprechend dem im Bevorzugte Entgeltsicherung-IT-Feinkonzept beschriebenen Verfahren verteilt, beziehungsweise ein Zugriff auf diese Daten ermöglicht.

[0140] Die zugehörigen Datenstrukturen werden im Datenmodell zum Feinkonzept Bevorzugte Entgeltsicherung beschrieben.

Verteilung der Schlüsseldaten

[0141] Die symmetrischen Schlüssel, die auf der Gebührenbetragsladestelle (Postage Point) zur Absicherung der 2D-Barcodeinhalte dienen und welche das Krypto-System zur Validierung benötigt, werden aus Sicherheitsgründen in regelmäßigen Abständen ausgetauscht. Bei Einsatz in allen Briefzentren müssen die Schlüssel vom (Postage Point) zu den Krypto-Systemen automatisch und sicher übertragen werden.

[0142] Der Austausch sollte dabei über den bevorzugten Entgeltsicherungs-Server erfolgen, da bei der Gebührenbetragsladestelle (Postage Point) nicht konfiguriert werden sollte, welche bevorzugten lokalen EntgeltsicherungsSysteme und welche Krypto-Systeme dazu existieren.

[0143] Besonders bevorzugte Verfahrensschritte für einen Austausch von Schlüsseln sind in Fig. 7 dargestellt. Der bevorzugte Schlüsselaustausch erfolgt zwischen einer zentralen Ladestelle (Postage Point), einem zentralen Crypto Server und mehreren lokalen Crypto Servern.

[0144] Da die symmetrischen Schlüssel von großer Bedeutung für die Fälschungssicherheit der 2D-Barcodes sind, muss der Austausch durch starke Kryptographie und durch eindeutige Authentisierung der Kommunikationspartner abgesichert sein.

Konfiguration

Grundkonfiguration/Key Management der Crypto Hardware

[0145] Für die Grundkonfiguration der Kryptokarte sind verschiedene Maßnahmen notwendig. Sie sollten durch einen Sicherheitsadministator durchgeführt werden. Es handelt sich dabei grob um folgende Tätigkeiten:

• Installation des Software-APIs auf der Karte
• Generierung, beziehungsweise Installation der privaten Schlüssel zur Absicherung von Administrationsanwendungen und einzuspielender Software

[0146] Je nach ausgewähltem Kartentyp und -hersteller sind dabei unterschiedliche Maßnahmen notwendig.

[0147] Die für das bevorzugte Entgeltsicherungs-System vorgesehene anwendungsbezogene Grundkonfiguration der Kryptokarte besteht aus folgenden Schritten:

• Sichere Verschlüsselung und Übertragung der symmetrischen Schlüssel auf die Karte - beispielsweise RSA-Schlüsselpaar - bei gleichzeitiger Zertifikatserzeugung für den Public Key und Ausgabe des Keys
• Zertifikat der Gebührenbetragsladestelle (Postage Point) fest vorkonfigurieren zur Sicherstellung, dass der zu importierende Schlüssel von der Gebührenbetragsladestelle (Postage Point) ausgestellt wurde.

Grundkonfiguration der Krypto-System-Applikation

[0148] Jeder Scanner, jeder Benutzer und jede Kryptokarte innerhalb des Krypto-Systems muss durch eine eindeutige ID gekennzeichnet sein. Letztlich ist auch jeder AFM-2D-Code-Leser durch eine eindeutige ID zu identifizieren.

Login/Logoff

[0149] Zu Beginn einer Session mit der Überprüfungseinheit muss ein Login erfolgen. Dieses Login enthält als Parameter die Scanner-ID, die User ID, sowie die Callback-Methoden für die manuelle Prüfung, beziehungsweise die Ausgabe der Lese- und Prüfergebnisse.

[0150] Als Rückgabewert wird eine Session-ID zurückgeliefert, die bei folgenden Prüfungsaufrufen innerhalb der Sitzung mit zu übergeben ist. Zu der Session ID wird auf der Überprüfungseinheit ein Session Context gespeichert, in dem die Übergabeparameter gespeichert sind.

[0151] Nimmt der Benutzer während seiner Sitzung Änderungen an der Betriebsart, an dem vordefinierten Produkt, beziehungsweise an weiteren zur Laufzeit konfigurierbaren Sitzungseinstellungen vor, so werden diese Änderungen in den dafür zugeordneten Variablen innerhalb des Session Contextes nachvollzogen.

[0152] Bei einem Logoff wird der Session Context entsprechend gelöscht. Nachfolgende Prüfungsaufrufe mit dieser Session ID werden abgewiesen.

[0153] Die Verwaltung von Benutzern und Passwörtern ist in einem allgemeinen Benutzerverwaltungskonzept für bevorzugte Entgeltsicherung zu definieren, das Bestandteil des Feinkonzeptes bevorzugte Entgeltsicherungs-IT ist.

[0154] Die Lesesysteme müssen sich vor der Durchführung von Prüfungsanfragen bei der Überprüfungseinheit registrieren lassen. Als Parameter ist die ID des Lesesystems sowie ein Passwort zu übergeben. Als Rückgabewert wird bei erfolgreicher Anmeldung ebenfalls eine Session ID zurückgeliefert, die bei den folgenden Überprüfungsanfragen zu übermitteln ist.

[0155] Bei einem Shutdown des Lesesystems muss ein entsprechender Logoff mit dieser Session ID erfolgen.

Sonstiges

Spezielle Benutzerrollen

[0156] Im Rahmen des Sicherheitskonzepts sind zwei spezielle Benutzerrollen vorzusehen, die von zwei unterschiedlichen Personen auszufüllen sind.

Der/die Sicherheitsadministrator(in)

[0157] Die Rolle der Sicherheitsadministration umfasst die folgenden Aufgaben:

• Erstellung von Befehlsdateien zur Administration der Krypto-Karte
• Signierung dieser Befehlsdateien
• Initialisierung und Verwaltung der Krypto-Karten
• Kontrolle der aufzuspielenden Software und der zugehörigen Konfiguration

[0158] Der Sicherheitsadministrator authentisiert sich mit dem Private Key zur Kartenadministration. Dieser ist auf einer Diskette oder Smart Card gespeichert und muss von dem Sicherheitsadministrator streng unter Verschluss gehalten werden.

[0159] Nur mit diesem Schlüssel signierte Administrationsbefehle lassen sich auf der Krypto-Karte ausführen. Da durch diesen Mechanismus die Befehlssequenz und die zugehörigen Parameter geschützt sind, kann die Ausführung dieser Befehle auch an Systemadministratoren vor Ort delegiert werden. Der Sicherheitsadministrator muss dazu die Befehle zur Verfügung stellen und eine entsprechende Verfahrensanweisung schreiben.

[0160] Eine weitere Aufgabe besteht in der Verwaltung der Krypto-Karten, wobei zu jeder Karte die Seriennummer, die Konfiguration und die Systemnummer des Systems, in welchem diese installiert sind, sowie der Standort des Systems festgehalten werden. Bei den Reserve-Krypto-Karten wird ferner festgehalten, in wessen Besitz sich die Karten befinden.

[0161] Zusammen mit dem QS-Manager Sicherheit kontrolliert er die Softwarequellen und die zugehörige Softwarekonfiguration und gibt diese zur Installation frei.

[0162] Außerdem erfolgt eine Prüfung der auf der Karte und auf dem Krypto Server zu installierenden, beziehungsweise installierten, Software sowie eine Freigabe und Signierung der Kartensoftware.

[0163] Die Kartensoftware ist speziell daraufhin zu prüfen, ob an irgendeiner Stelle einer der geheimen Schlüssel über die Treiberachnittstelle nach außen gegeben werden kann, beziehungsweise ob dort Manipulationsversuche wie zum Beispiel die Speicherung konstanter vordefinierter Schlüssel oder die Verwendung unsicherer Verschlüsselungsverfahren vorgenommen wurden. Zusätzlich zur Kartensoftware ist auch die mit ihr in Verbindung stehende Anwendungssoftware des Krypto Servers zu prüfen.

[0164] Die Authentisierung erfolgt genauso wie bei dem Sicherheitsadministrator mit einem Private Key. Es handelt sich hierbei jedoch um den Private Key zur Softwaresignierung.

[0165] Es besteht hier jedoch eine zusätzliche Sicherheit darin, dass zur Installation der Software nicht nur die Software zu signieren ist, sondern auch der zugehörige Installationsbefehl. Da hierfür zwei verschiedene Personen (Qs-Manager und Sicherheitsadministrator) zuständig sind und dadurch, dass die zugehörigen Schlüssel an zwei unterschiedlichen Orten aufbewahrt werden, ist hier ebenfalls eine hohe Sicherheit gewährleistet.

[0166] Die Distribution der Software wird von dem QS-Manager Sicherheit in Abstimmung mit dem Sicherheitsadministrator vorgenommen.

[0167] Diese besonders bevorzugte Ausführungsform der Erfindung sieht somit zwei verschiedene Authentisierungsschlüssel vor, so dass die Datensicherheit erheblich erhöht wird.

Ansprüche

1. Verfahren zur Überprüfung der Echtheit 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, dadurch gekennzeichnet, dass
die Überprüfung in einem System, bestehend aus einer Überprüfungseinheit und mehreren Leseeinheiten, erfolgt,
wobei eine der Leseeinheiten einen Freimachungsvermerk graphisch erfasst und der in dem Freimachungsvermerk enthaltene Matrixcode an die Überprüfungseinheit übermittelt wird,
wobei die Überprüfungseinheit für den empfangenen Matrixcode einen Ablauf von Teilprüfungen steuert,
wobei die Überprüfungseinheit Teilprüfungen des empfangenen Matrixcodes parallel ausführt, und
wobei die Überprüfungseinheit das Prüfergebnis des empfangenen Matrixcodes an die richtige Leseeinheit lenkt.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass eine der Teilprüfungen die Entschlüsselung der in dem Freimachungsvermerk enthaltenen kryptographischen Informationen beinhaltet.

3. Verfahren nach einem oder beiden der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass eine der Teilprüfungen einen Vergleich zwischen dem Erzeugungsdatum des Freimachungsvermerkes und dem aktuellen Datum beinhaltet.

4. Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die eine Leseeinheit und die Überprüfungseinheit mittels eines synchronen Protokolls Informationen austauschen.

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass das Protokoll RPC-basiert ist.

6. Verfahren nach einem oder mehreren der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die eine Leseeinheit und die Überprüfungseinheit über ein asynchrones Protokoll miteinander kommunizieren.

7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass die eine Leseeinheit ein Datentelegramm an die Überprüfungseinheit sendet.

8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass das Datentelegramm den Inhalt des Freimachungsvermerks enthält.

9. Verfahren nach einem oder mehreren der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass das Datentelegramm eine Anforderung zum Starten einer kryptographischen Überprüfungsroutine enthält.

10. Verfahren nach einem oder mehreren der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass durch ein Krypto-Interface eine Lastverteilung zwischen mehreren Überprüfungsmitteln erfolgt.

11. Verfahren nach einem oder mehreren der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass der Inhalt des Freimachungsvermerks in einzelne Felder aufgeteilt wird.

12. Verfahren nach Anspruch 11 , dadurch gekennzeichnet, dass eine Identifikationsnummer (Postage ID) des die Erzeugung des Freimachungsvermerks steuernden Kundensystems aus dem Freimachungsvermerk ermittelt wird.

13. Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass einzelne Kundensystemidentifikationsangaben (Postage ID) in einer Negativdatei erfasst und die zu dieser Postage ID gehörenden Sendungen aus einem normalen Bearbeitungsverlauf von Postsendungen ausgeschleust werden.

14. Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass eine in dem Freimachungsvermerk enthaltene verschlüsselte Angabe einer Empfängeradresse mit einer für die Beförderung der Postsendung angegebenen Empfängeradresse verglichen wird.

15. Verfahren nach einem oder mehreren der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass Überprüfungsparameter des Verfahrens geändert werden können.

16. Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass eine Änderung von Verfahrensparametern nur nach Eingabe eines persönlichen digitalen Schlüssels (Private Key) eines Systemadministrators erfolgt.

Claims

1. A method for verifying the authenticity of a franking mark which has been applied onto a mailpiece, with cryptographic information contained in the franking mark being decrypted and used to verify the authenticity of the franking mark,
characterized in that
the verification takes place in a system consisting of a verifying unit and several reading units,
whereby one of the reading units graphically records a franking mark and the matrix code contained in the franking mark is transmitted to the verifying unit,
whereby the verifying unit controls a sequence of partial examinations for the received matrix code,
whereby the verifying unit concurrently carries out partial examinations of the received matrix code, and
whereby the verifying unit sends the examination result of the received matrix code to the correct reading unit.

2. The method as claimed in Claim 1,
characterized in that
one of the examination components comprises decryption of the cryptographic information contained in the franking mark.

3. The method as claimed in either or both of Claims 1 and 2,
characterized in that
one of the examination components comprises a comparison between the date of production of the franking mark and the current date.

4. The method as claimed in one or more of the preceding claims,
characterized in that
the one reading unit and the verifying unit interchange Information using a synchronous protocol.

5. The method as claimed in Claim 4,
characterized in that
the protocol is RPC based.

6. The method as claimed in one or more of Claims 1 to 5,
characterized in that
the one reading unit and the verifying unit communicate with one another using an asynchronous protocol.

7. The method as claimed in Claim 6,
characterized in that
the one reading unit sends a data message to the verifying unit,

8. The method as claimed in Claim 7,
characterized in that
the data message contains the content of the franking mark.

9. The method as claimed in one or more of Claims 1 to 8,
characterized in that
the data message contains a request to start a cryptographic verifying routine.

10. The method as claimed in one or more of Claims 1 to 9,
characterized in that
a crypto interface performs load distribution between a plurality of verifying means.

11. The method as claimed in one or more of Claims 1 to 10,
characterized in that
the content of the franking mark is split into individual fields.

12. The method as claimed in Claim 11,
characterized in that
an identification number (Postage ID) for the customer system controlling the production of the franking mark is ascertained from the franking mark.

13. The method as claimed in one or more of the preceding claims,
characterized in that
individual customer system identification specifications (Postage ID) are recorded in a negative file, and the mailpieces associated with this Postage ID are discharged from a normal processing progression for mailpieces.

14. The method as claimed in one or more of the preceding claims,
characterized in that
an encrypted recipient address statement contained in the franking mark is compared with a recipient address indicated for delivery of the mailpiece.

15. The method as claimed in one or more of Claims 1 to 14,
characterized in that
verifying parameters for the method can be changed.

16. The method as claimed in Claim 15,
characterized in that
method parameters are changed only after input of a personal digital key (private key) associated with a system administrator.

Revendications

1. Procédé pour contrôler l'authenticité d'une marque d'affranchissement appliquée sur un envoi postal, dans lequel des informations cryptographiques contenues dans la marque d'affranchissement sont décryptées et mises en oeuvre pour contrôler l'authenticité de la marque d'affranchissement, caractérisé en ce que,
le contrôle se réalise dans un système constitué d'une unité de contrôle et de plusieurs unités de lecture,
l'une des unités de lecture capte graphiquement une marque d'affranchissement et un code matriciel contenu dans la marque d'affranchissement est transmis à l'unité de contrôle,
l'unité de contrôle commande un déroulement de contrôle partiel pour le code matriciel reçu,
l'unité de contrôle réalise en parallèle des contrôles partiels du code matriciel reçu, et
l'unité de contrôle dirige le résultat du contrôle du code matriciel reçu vers la bonne unité de lecture.

2. Procédé selon la revendication 1, caractérisé en ce que l'un des contrôles partiels contient le décryptage des informations cryptographiques contenues dans la marque d'affranchissement.

3. Procédé selon l'une ou les des revendications 1 ou 2, caractérisé en ce que l'un des contrôles partiels comprend une comparaison entre la date de création de la marque d'affranchissement et la date actuelle.

4. Procédé selon l'une ou plusieurs des revendications précédentes, caractérisé en ce que ladite une unité de lecture et l'unité de contrôle échangent des informations au moyen d'un protocole synchrone.

5. Procédé selon la revendication 4, caractérisé en ce que le protocole est basé sur RPC.

6. Procédé selon l'une ou plusieurs des revendications 1 à 3, caractérisé en ce que ladite une unité de lecture et l'unité de contrôle communiquent entre elles par l'intermédiaire d'un protocole asynchrone.

7. Procédé selon la revendication 6, caractérisé en ce que ladite une unité de lecture envoie un télégramme de données à l'unité de contrôle.

8. Procédé selon la revendication 7, caractérisé en ce que le télégramme de données contient le contenu de la marque d'affranchissement.

9. Procédé selon l'une ou plusieurs des revendications 1 à 8, caractérisé en ce que le télégramme de données contient une requête de démarrage d'un sous-programme de contrôle cryptographique.

10. Procédé selon l'une ou plusieurs des revendications 1 à 9, caractérisé en ce qu'une répartition de charge se réalise entre plusieurs moyens de contrôle à l'aide d'une interface cryptographique.

11. Procédé selon l'une ou plusieurs des revendications 1 à 10, caractérisé en ce que le contenu de la marque d'affranchissement est divisé en différents champs individuels.

12. Procédé selon la revendication 11, caractérisé en ce qu'un numéro d'identification (identifiant ID d'affranchissement) du système client commandant la création de la marque d'affranchissement est déterminé à partir de la marque d'affranchissement.

13. Procédé selon l'une ou plusieurs des revendications précédentes, caractérisé en ce que différentes données individuelles d'identification de système client (identifiant ID d'affranchissement) sont saisies dans un fichier négatif et les envois appartenant à cet identifiant ID d'affranchissement sont éclusés d'un déroulement opératoire normal des envois postaux.

14. Procédé selon l'une ou plusieurs des revendications précédentes, caractérisé en ce qu'une donnée cryptée d'une adresse de destinataire contenue dans la marque d'affranchissement est comparée à une adresse de destinataire indiquée pour l'acheminement de l'envoi postal.

15. Procédé selon l'une ou plusieurs des revendications 1 à 14, caractérisé en ce que des paramètres de contrôle du procédé peuvent être modifiés.

16. Procédé selon la revendication 15, caractérisé en ce qu'une modification des paramètres de procédé ne se réalise qu'après saisie d'une clé numérique personnelle (clé privée) d'un administrateur du système.

Zeichnung