EP1405274B1 - Method for verifying the validity of digital franking notes - Google Patents

Abstract

The invention relates to a method for verifying the authenticity of a franking note placed on a postal article. According to the invention, cryptographic information contained in the franking note is decoded and used for verifying the authenticity of the franking note. The inventive method is characterized in that the reading unit graphically records the franking note and transmits it to a verification unit and in that the verification unit controls a sequence of partial tests.

Description

It is known to provide postal items with digital franking marks.

Document EP-A-732673 discloses the features of the preamble of claim 1.

In order to make it easier for the senders of the mailpieces to generate the franking marks, it is possible, for example in the case of the franking system used by Deutsche Post AG, to generate franking markings in a customer system and to output them to a printer via any desired interface.

In order to avoid misuse of this method, the digital indicia contain cryptographic information, for example about the identity of the customer system controlling the creation of the indicium.

The invention has for its object to provide a method by which the authenticity of the franking marks can be checked quickly and reliably. In particular, the process should be suitable for a review in mass production, in particular in letter or freight centers.

Claim 1 discloses the subject of the invention. Preferred embodiments are disclosed in the dependent claims 2-16.

According to the invention, this object is achieved in that the reading unit records the franking mark graphically and transmits it to a checking unit, and that the checking unit controls a sequence of partial checks.

It is particularly appropriate that one of the partial examinations be the Decrypting the cryptographic information contained in the indicium.

By integrating the decryption of the cryptographic information in the examination process, it is possible to capture the authenticity of the franking marks directly, so that a review online - especially during the processing history of the mailing in a processing machine - can be done.

Furthermore, it is advantageous that one of the partial checks includes a comparison between the date of creation of the franking mark and the current date. The integration of the date of creation of the indicium - in particular in encrypted form - increases data security, since the comparison between the date of creation of the franking and the current date avoids the multiple use of a franking mark for the carriage of mail.

To further increase the checking speed, it is advantageous for the reading unit and the checking unit to exchange information by means of a synchronous protocol.

In another, likewise expedient embodiment of the invention, the reading unit and the checking unit communicate with each other via an asynchronous protocol.

In this case, it is particularly expedient for the reading unit to send a data telegram to the checking unit.

The data telegram preferably contains the content of the franking mark.

Further advantages, features and expedient developments of the invention will become apparent from the dependent claims and the following description of preferred embodiments with reference to the drawings.

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).

Show from the drawings

Fig. 1

a schematic representation of system components of a payment assurance system;

Fig. 2

a particularly preferred embodiment of the payment assurance system, hand-held scanner and pay-back PC);

Fig. 3

a schematic representation of a generation and verification of franking marks.

Fig. 4

an overview of components of the crypto-system;

Fig. 5

a preferred embodiment of the review process;

Fig. 6

a further particularly preferred embodiment of the verification method with a particularly preferred sequence of partial checks;

Fig. 7

a preferred sequence of distribution of keys between a central loading point (Postage Point) and individual cryptographic check units (Crypto Server).

The invention is illustrated below using the example of a PC franking system. The for payment Serving process steps are independent of the system used to generate the franking marks.

The illustrated decentralized check at individual control points, especially in letter centers, is particularly preferred, but a centralized check is equally possible.

In a first embodiment of the invention, the authenticity of the franking markings is preferably checked on a random basis by individual scanners.

A suitable verification set preferably contains the components shown in FIG.

FIG. 1 shows with which subsystems the crypto-system is related. They are briefly described below.

scanner

The scanners are used to read the franking mark of the PC franking. The franking marks are 2D codes in the format Datamatrix, with the error correction ECC200 used. Depending on the type of scanner, the data is transmitted by radio or by cable, whereby the radio scanners have a multi-line display and thus an output option and a touch screen, or a keyboard for rudimentary input.
The interface between the scanners and the remaining systems of the preferred pay-back PC franking system are the scanner controller and the validation controller as components. While the scanner controller manages a queue of matrix codes that are pending coming through the handheld scanner and essentially maintain contact with the scanners, it is in contact with the other systems only via the validation controller.

Scanner controller / verification unit

The scanner controller and the validation controller connected to the scanner controller serve as an interface between the scanners and the other systems for checking the 2D barcodes. They are transmitted to the optical capture converted and error-corrected 2D barcode content, and they then cause the review and provide in the case of the wireless scanner for output of the reading and test result, and serve as an interface between any necessary manual post-processing and tests of the examiner and the other systems.

Crypto system

The crypto system ensures the content and cryptographic verification of the 2D barcode content as well as the protected storage of security-relevant data and algorithms. The individual components will be discussed later.

Fee Charge (Postage Point)

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

The Postage Point is the central system within the PC franking. It serves as an interface to the customer systems. From it, the customers can discharge specified amounts for the subsequent franking. The keys for securing the procedure are generated on the Postage Point. It also serves as an interface to the billing systems. The following interfaces become the preferred payment assurance system for PC franking provided:

• Shipment information via the 2D barcode
• Symmetric keys
• Master data, such as default amounts, account balances

Preferred Remuneration Central

In the preferred centralized pay-back system, the shipment-related information is collected and made available to other systems. This is where the production reports are created, which in turn leads to the creation of the negative files. Furthermore, the central payment guarantee system receives the current key data from the charge amount charging point (Postage Point) and forwards them to the individual KryptoServer.

data providers

For checking the content of the 2D barcodes, a series of master data is required, such as negative files, minimum charges, validity periods in relation to the product and payment guarantee warning and follow-up processing codes. These data are provided from different systems (BDE, VIBRIS, local payment assurance system).

Payment assurance application

With the payment assurance application, it is possible to carry out a more detailed check of the franking during the postprocessing of rejected PC franking items, where the presentation of the test results is not limited by limited output options of the scanner. In addition, the auditor can also view further data, such as the validity period of the postage amount to which the current shipment relates, as well as the amount and the used frankings.

Automatic capture of 2D barcodes

The 2D barcodes are automatically detected. For this, the image information is forwarded to the AFM 2D code reader. There, the image is converted into the content of the data matrix code. Subsequently, the 2D bar code content is transmitted to the crypto system for review, the returned test result is evaluated and transmitted to the optical capture system (IMM) for encoding the shipment. Preferred components of such an extended verification method are shown in FIG.

AFM-2D code reader

For each reading machine (ALM / ILVM) exists an AFM-2D-Code-Leger, which receives the picture data of the programs via an optical recording system (IMM) and further processes it for payment assurance purposes. In the context of preferred payment assurance PC franking, in the case of a recognized 2D code, this means that the 2D data matrix code is extracted from the image data and converted with the aid of the error correction method ECC200 into a byte string representing the content of the 2D barcode.

This byte string is passed to the validation controller for verification. The test result is then transmitted via the interface of the optical detection system forwarded and used there for coding.

Crypto system for AFM 2D code reader

Depending on the characteristics of the crypto cards, it is possible to expect about 27 tests per second. Since the rate of reading machines is about 10 reads per second read, it does not make sense to combine each of the AFM-2D code readers with a crypto system. In addition, it can not be assumed that PC-F broadcasts will be produced one hundred percent on all machines at the same time. It therefore makes sense to separate the crypto-systems and operate several PC-F readers with a crypto-system. The solution should be chosen in such a way that it can be scaled, ie several crypto-systems per letter center are possible. This is relevant, for example, for mail centers with a high volume of mail and a large number of reading machines, where a second crypto system can initially be provided. In addition, later in operation, the number of servers can be increased as needed.

In order to reduce the complexity, the architecture is preferably to be selected such that the individual reading machines are permanently assigned to a crypto system and possibly extended by an additional fallback configuration which, in the event of an error, attempts to switch to a different crypto system.

The separation of crypto-system and AFM-2D-code reader has the advantage that both the machine reading and the hand scanner test can be done with the same crypto-system, and therefore the same function can not be duplicated, which also offers significant advantages in the implementation of the invention.

Preferred method steps for providing a mailpiece with a digital franking mark after loading a fee amount from a central loading point (Postage Point) and generating the franking mark by a local PC and subsequent delivery of the mailpiece and checking the franking mark applied to the mailpiece are shown in FIG.

Regardless of the distribution of keys, the procedure is such that a customer first loads a postage amount onto his PC. To identify the request, a random number is generated. A new postage amount is generated for the respective customer on the charge amount loading point (Postage Point) and the so-called crypto-ring is generated from the transmitted random number, further information on the identity of the customer system (the customer system identification information, hereinafter referred to as postage ID) and the postage amount a secret symmetric key existing on the charge amount charging point (Postage Point) is encrypted.

This Cryptostring and the corresponding postage amount are then transferred to the customer PC and stored safely with the random number in its "safe box" against unwanted access.

If a postage is franked by the customer after the transaction with the received postage amount, the shipment data relevant for the 2D barcode, inter alia cryptostring, franking date and franking amount, are expanded by the random number and the postage ID is collected in unencrypted form , and a hash value is created that uniquely identifies the content.

Since the random number is present in encrypted form within the crypto string as well as in unencrypted form within the hash value, it is ensured that the transmission data can not be changed or generated arbitrarily, and it is possible to infer the creator.

The relevant data for the shipment are then subsequently converted into a 2D barcode and printed as a corresponding franking mark by the printer of the customer on the shipment. The finished consignment can then be placed in the postal cycle.

In a particularly preferred embodiment of the payment assurance, the 2D barcode in the mail center is read by an AFM 2D code reader, or by a hand-held scanner, and subsequently checked. The associated process steps are shown in the figure under process numbers 5-8. To check the correctness of the 2D barcode, the AFM-2D-Code Reader transfers the complete shipment data to the crypto-system. There, a cryptographic information contained in the shipment data, in particular of the Cryptostrings decrypted to determine the random number used in the creation of the hash value.

Subsequently, a hash value (also called message digest) is determined for the shipment data including the decrypted random number, and it is checked whether the result is identical to the hash value contained in the 2D barcode.

In addition to the cryptographic validation, further content-related checks (process number 7b), which exclude the double use of a 2D barcode, for example, or check whether the customer passes through Fraud attempts was conspicuous and therefore listed on a negative file.

The corresponding test result is then transmitted to the PC-F reader, which forwards the result to the optical detection system (IMM) for encoding the bar code. The barcode is then injected onto the letter and the mailings are rejected in the event of a negative test result.

Crypto-system architecture; Components Overview

4 gives an overview of the subcomponents of the crypto-system, the labeled arrows representing input and output data streams to external systems. Since the preferred centralized pay-as-you-go system is used as a hub in the distribution of the Postage Point keys to the cryptographic systems of the local pay-back systems, and this data must be cached, a crypto-system component is also to be provided there However, the review unit is usually not used.

The sub-components of the crypto-system are described in more detail below.

Checking unit

The verification unit provides the interface for checking the complete 2D barcode content. The verification of the 2D barcode consists of a content-related and a cryptographic check. To this end The scanned 2D barcode content of the scanners should be forwarded to the review unit by the scanner controller.

Since the responsible scanner controller for the wired scanner and the checking unit are located on different computer systems, a TCP / IP-based communication between them should be provided, whereby instead of pure socket programming, the use of a protocol based thereon offers advantages. Within the framework of the crypto-system, the telegram manager used within the operational data acquisition (BDE) or the protocol used within the scope of the optical recording system, such as Corba / IIOP, can be used here.

The verification unit initiates the individual check routines, which in turn send their test results back to them.

The review unit is multisession-enabled. That is, it must be able to handle simultaneous inspection requests and direct the appropriate output to the right scanner. In addition, it should be designed so that it can execute several test requests as well as part of the test steps, for example hash value check and minimum fee check, simultaneously.

At the beginning of a session, the controller is told which type of scanner he is communicating with, and he is given an opportunity to call and issue manual routines via the CallBack method. Depending on the operating mode and scanner type, the results are then output either on the wireless scanner or the payment assurance system, and manual test results are recorded.

Crypto card

A special problem lies in the storage of the key with which the crypto-ring must be encrypted in a 2D barcode and decrypted for testing. This key ensures the forgery-proofing of 2D barcodes and therefore it must not be possible to spy on it. Therefore, it must be ensured by means of special security measures that this key is never visible in plain text on the hard disk, in the memory or in the transmission and is also secured by strong cryptographic methods.

Purely software-based solutions do not provide reliable security here, because at some point in the system but a key appears in plain text, or the key could be read out with a debugger in plain text in the memory. This danger is mainly due to the fact that the systems can be administered remotely, or may be given out of the house for the purpose of a repair.

In addition, the cryptographic methods generate a high load on the processor of the system, which is not optimized in terms of the operations to be performed.

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

It is therefore recommended to use a crypto processor card with the following characteristics:

• Special crypto processor for speeding up cryptographic processes
• Completed black box system to prevent access to critical data and procedures.

The cards that meet these characteristics are self-sufficient systems that are connected to the computer via the PCI or ISA bus depending on the model and communicate with the software systems on the computer via a driver.

In addition to battery-backed main memory, the cards also have a flash ROM memory in which an individual application code can be stored. The direct access to the main memory of the cards is not possible by the external systems, whereby a very high level of security is ensured since neither the key data nor the cryptographic methods for providing the security other than the secured driver are tangible.

In addition, the cards use their own sensors to monitor whether manipulation attempts have taken place (depending on the card design, for example, temperature peaks, radiation, opening the protective cover, voltage peaks).

If such a manipulation attempt is present, the battery-buffered main memory contents are deleted immediately and the card is shut down.

For the Crypto Server, the Postage ID Decryption feature, the hash value checking feature, as well as the key data importing feature should be loaded directly onto the card, as these routines have high security relevance.

Furthermore, all cryptographic keys, as well as the configurations of certificates necessary for performing the authentication, should also be saved in the battery-backed memory of the card. If the card does not have enough memory, the card usually has a master key, which is the one above encrypted data can be stored and then stored on the hard disk of the system. However, this requires that before using this information, the data is first decrypted again.

The following table gives an overview of the relevant card models from different manufacturers and at the same time names their certifications.

Crypto cards for use within the preferred PCM payment guarantee system Manufacturer type designation certification IBM 4759-023 FIPS PUB 140-1 Level 3 and ZKA-ecash IBM 4758-002 FIPS PUB 140-1 Level 4 and ZKA eCash (advance 07/2000) CCEAL 5 (targeted, currently in certification phase) Utimaco cryptoserver ITSEC-E2 and ZKA-eCash Utimaco KryptoServer 2000 (available approx. 1Q / 01) FIPSPUB 140-1 Level 3, ITSEC-E3 and ZKA-eCash (aspired) Racal / Zaxus WebSentry PCI FIPS PUB 140-1 Level 4

In addition to the fulfillment of the requirements placed on the card, it is also very important, due to the desired certification by the BSI, which certifications the individual models currently have and which certifications are currently in the evaluation process.

Certificates issued for the products are subdivided into the three classifications made by different certification authorities.

The ITSEC is a criteria work published by the European Commission for the certification of IT products and IT systems with regard to their security features. The trustworthiness rating is based on the levels E0 to E6, where E0 means insufficient and E6 highest security. Further development and harmonization with similar international standards are the CC (Common Criteria), which are currently in an ISO standardization process (ISO standard 15408). This policy is used to assess the safety of the system.

There is currently no product from the above table that has a CC certificate. However, the IBM Model 4758-002 is currently in such a certification phase.

The FIPS PUB 140-1 standard is a US government-issued criteria framework for assessing the security of commercial cryptographic devices. This criteria work orients itself very strongly on hardware characteristics. The rating is in 4 levels, where Level 1 means the lowest and Level 4 the highest security.

In addition to the above-mentioned valuation standard, there is another set of criteria published by the Central Credit Committee (ZKA), which regulates approvals for the operation of IT systems and products in the area of electronic cash.

• 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

However, besides the already mentioned features of the cards and the assigned certifications, there are a number of other advantages, which are listed below:

• Creation of own (signed) software and upload to the card possible
• Integrated random number generator (FIPS PUB 140-1 certified)
• DES, Triple DES and SHA-1 implemented on the hardware side
• RSA key generation and private / public key processing for keys up to 2048 bits in length
• Key Management - Functions
• Certificate Management - Functions
• Partly operation of several crypto cards in parallel in one system possible

Crypto interface

The security-relevant functions within the scope of the crypto card application are stored directly in the card and can therefore only be accessed externally via the card driver. The interface between the driver and the verification unit is the crypto interface component, which forwards the requests for test routines to the card by means of a driver.

Since several cards can be used within a computer, the task of the crypto interface is also to perform a load distribution of the individual test requests. This function is particularly useful if in addition one or, depending on the mail center, several AFM 2D code readers use the check routines of the crypto system.

Another task is to handle the communication to distribute the key data. In level 2, there may be only a rudimentary mechanism that transmits the keys encrypted for security within a signed file. A request to the crypto interface is then to provide a utility that allows the import of such a file.

Functions of the crypto-system Test procedure in the review unit

For checking the 2D barcode, a central checking function is provided by the checking unit as an interface to the scanner or the reading systems. This test function coordinates the course of the individual partial examinations.

The codes for the payment assurance incident transmitted from the individual sub-check routines are converted into the corresponding pay-back code on the basis of a predefined table, which is preferably maintained centrally and transmitted to the crypto system. Within this table, additional priorities are set that govern which pay-as-you-go code to assign when multiple pay-back incident has been detected.

This pay-back code is then returned together with a descriptive text as the test result. Depending on the processing system outside of the crypto system, this result is then output on the wireless scanner or within the payment assurance application, or it is converted into a TIT2 code during the automatic check and the delivery is printed on it.

Since the procedures between the hand-held scanner systems and the automatic reading systems are different, a different function is implemented for both cases.

Depending on which communication mechanism is used between the reading system and the checking unit, the call and the return of the results differ. When using a synchronous RPC-based protocol such as Corba / IIOP, the test method is called directly and the test results are passed after the test has been completed. The client, ie the scanner controller, or the reading system in this case wait for the execution and the return of the test results. In the case of the latter, therefore, a thread pool should be provided on the client, which can carry out the parallel checking of several requests.

In the case of the asynchronous mechanism by means of TGM, the scanner controller or the reading system does not call the test method directly, but a message is sent to the crypto system which contains the checking request, the content of the 2D barcode and further information such as the current sorting program , When this telegram is received on the crypto system, the test function is called, executed and the read and test results are sent back as a new telegram. The advantage with this method is that on the requesting system, the process is not blocked until the result is obtained.

Testing for hand-held scanner systems:

The test routine for the hand-held scanner systems expects the session ID and the content of the 2D barcode as input values.

As an additional parameter, the ID of the sorting program is also expected. The latter parameter is used to determine the minimum wage.

FIG. 5 shows an overview of the sequence of the check within the checking unit in the event that it was triggered by a hand-held scanner system. It is assumed that a test with a wireless scanner with subsequent manual comparison of the address with the 2D barcode content. In the case of a wired scanner, the display would be analogous to the payment assurance system or the payment assurance application.

A preferred verification procedure using a radio scanner, a scanner controller and a validation controller is shown in FIG.

In the illustrated, particularly preferred exemplary embodiment, the checking unit controls a sequence of partial checks, the first partial checking comprising reading in a matrix code contained in the digital franking mark. The read-in matrix code is first transmitted from a radio scanner to a scanner controller. Subsequently, in the area of the scanner controller, a check of the matrix code and a transmission to the checking unit takes place. The verification unit controls a splitting of the code content. The reading result is then transmitted to the detection unit - in the case illustrated a radio scanner. As a result, for example, a user of the reading unit learns that it was possible to read the franking mark and to recognize the information contained in the matrix in the process. Subsequently, the checking unit decrypts a crypto-string contained in the matrix code. For this purpose, preferably first verifies the version of the key likely to be used for the preparation of the franking mark. Then the hash value contained in the Cryptostring is checked.

Furthermore, an examination of the envisaged minimum wage will take place.

In addition, an identification number (Postage ID) of the customer system controlling the production of the franking mark is checked.

This is followed by a comparison of the identification number with a negative list.

By means of these checking steps, it is possible in this particularly simple and expedient form to easily determine unauthorized franking marks.

The result of the transmission is transmitted as a digital message, wherein the digital message can be transmitted, for example, to the original radio scanner. As a result, for example, a user of the radio scanner eject the shipment from the program run. In an automated implementation of this process variant, however, it is of course equally possible to eject the consignment from the normal processing run of the mailpieces.

The result of the check is preferably logged in the area of the checking unit.

The return value should be the code belonging to the pay-back incident and the corresponding text message as well as the 2D barcode object.

Examination procedure for the AFM 2D code reader

The input parameter of the check routine for the AFM 2D code reader is also expected to be the session ID, as well as the content of the 2D bar code and the unique identifier of the currently active sort program.

FIG. 6 shows an overview of the sequence of the check within the checking unit in the event that it was triggered by a reading system.

The illustration also shows the optical acquisition system (IMM system) and the AFM 2D code reader to illustrate the overall context of the test. However, the share of the crypto-system is limited to checking the functions between 2D barcode and the return as well as the logging of the result.

In the case of the telegram manager interface, several service tasks would be started on the checking unit, which would wait for test request telegrams and call the checking routine with the telegram content. The result of the test routine is awaited and packaged in a telegram and sent back to the requesting client.

FIG. 6 shows a further preferred embodiment of a control of a sequence of partial checks by the validation controller. In this further preferred embodiment, the franking marks are detected by an automatic optical recognition system (Prima / IMM). The data becomes a reading and detecting unit (AFM-2D code reader) from the optical inspection unit.

In the embodiment of the method for checking the validity of digital franking marks shown in FIG. 6, the digital franking marks are preferably read in an even more automated manner, for example by optically detecting a location of a mail item on which a franking mark is preferably arranged. The further checking steps are carried out essentially in accordance with the test procedure illustrated with reference to FIG. 5.

The return value of the check routine consists on the one hand of the pay-back code and an associated message as well as the converted and extended by the Postage ID content. From these return values, a telegram is generated and transmitted to the requesting reading system.

Content checks Split and reshape 2D barcode content Input: scanned 2D barcode Description:

In this function, the content of the 2D bar code consisting of 80 bytes must be divided up and converted into a structured object, referred to below as the 2D bar code object, in order to achieve a better display capability and more efficient postprocessing. The individual fields and conversions are described in the following table:

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

When converting from binary to decimal numbers, make sure that the left byte of a byte string is the most significant byte. If a conversion might not occur because of a type conflict or missing data, then a payback incident message "PC-F barcode is not "readable" to generate and return to the review unit.A further substantive, or cryptographic review is not useful in this case. field Type to transform into description Post-company ASCII (3 bytes) no conversion necessary franking Binary (1 byte) Small integer version identifier Binary (1 byte) Small integer Version number of the procedure Key no. Binary (1 byte) Small integer key type CrypcoString Binary (32 bytes) Byte sequence is to be adopted unchanged, after decryption the PostageID is split out PostageID Text (16 characters) Will be filled after decrypting the Cryptostrings current shipment number Binary (3 bytes) integer only positive counting Produktochlüssel Binary (2 bytes) integer positive numbers, reference to associated referrer table remuneration Binary (2 bytes) float Conversion into positive decimal number, to be divided by one hundred, in Euro franking Binary (3 bytes) Date After conversion to positive decimal, the date can be converted to the format YYYYMMDD EmpfängerPLZ Binary (3 bytes) 2 values, one for country, one for postal code After conversion to positive decimal number the first two digits give the country code, the five remaining digits the post code street / PO Box ASCII (6 bytes) Street code or mailbox If the first digits are numbers, then a postal code is coded, otherwise the first and last three digits of the street with house number Porto balance Binary (3 bytes) Float + currency field (text 32 characters) After conversion to a positive decimal number, the first digit gives the currency (1 = Euro), the following four digits the pre-decimal and the remaining two digits the decimal places Hash Binary (20 bytes) Byte sequence is to be adopted unchanged, serves for the cryptographic validation of the franking

• Return value: 2D barcode object
  Warning code 00 if conversion OK,
  otherwise warning for payment guarantee incident "PC-F barcode not readable"

Version number check Input: current 2D barcode object Description:

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

The first three fields show the version of the 2D barcode. From this it is also apparent whether the franking mark is a 2D barcode of Deutsche Post and not a 2D barcode of another service provider. The field contents are to be compared with a list of valid values preconfigured in the application. If no match is found, then a payback warning "PC-F version" is returned. The review of further content as well as cryptographic aspects is then meaningless and should not be pursued.

• Return value: Warning code 00 if version check OK, otherwise warning code for payment guarantee incident
  "PC-F version"

Check Postage ID Input: 2D barcode object with decrypted Postage ID Description:

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

The Postage ID contained in the 2D bar code is protected by a check digit method (CRC 16), which is to be checked at this point. If this check fails, the result should be a pay-back warning "PC-F Counterfeiting (Postage ID)". Checking the Postage ID requires the prior decryption of the CryptoString.

• Return value: Code "00" if check OK, otherwise warning code for pay-back incident
  "PC-F suspected counterfeiting (Postage ID)"

Checking the timeout Input: 2D barcode object Description:

This function is used to automatically check the time interval between franking a PC-cleared shipment and processing it at the mail center. There must be only a certain number of days between the two dates. The number of days depends on the product and its terms plus a leave day.

The configuration of the period is preferably stored in a product validity period relation and maintained centrally within the context of a maintenance mask. In the relation For each product key (field of 2D barcode) possible for PC franking, the corresponding number of days that may lie between franking and processing at the letter center are recorded. In a simplified procedure, only a period specification is preconfigured, which refers to standard programs and is stored as a constant in the system.

For verification, the number of days between the current test date during processing and the date contained in the 2D barcode is formed, for example 02.08. until 01.08. = 1 day. If the determined number of days is greater than the value specified for the product, then the remuneration assurance code assigned to the warning case "PC-F date (franking)" is returned to the checking unit, otherwise a code documenting the successful check. If a simplified procedure always compares to the value for standard programs, after the test result has been output, it should be possible, for example, manually via a button on the scanner, to correct this test result, if the current product allows a longer service life.

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

Another timeout check relates to the contents of the Postage ID. The postage amount downloaded as part of a specification and thus also the postage ID have a predetermined validity period in which the items are to be franked. The postage ID contains the time until which the postage amount is valid. If the franking date is greater than this validity date by a certain number of days, the payback warning code belonging to the "PC-F date (postage amount)" pay-back warning is returned.

• Return value: Code "00" if test OK, otherwise warning code for payment guarantee incident
  "PC-F date (postage amount)" or
  "PC-F date (franking)"

pay check Input: 2D barcode object; current sort program ID Description:

Within this function, the check contained in the 2D barcode is checked against a minimum charge, which is defined for shipments of the associated sorting program. The amounts are euro amounts.

The assignments are delivered between sort program and minimum charge via an automatic interface.

A simplified procedure is similar to the timeout test. Here a constant minimum fee is defined in the configuration file for the application, which applies to all shipments. Therefore, the transfer of the sorting program is not required.

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

The subsequent check compares whether the minimum fee contained in the 2D barcode is below this mark. If this is the case, then the code assigned to the payment guarantee incident "PC-F sub-franking" is returned, otherwise the success code.

• Return value: Code "00" if check OK, otherwise warning code for payment guarantee incident
  "PC-F insufficient postage"

Matching with negative file Input: 2D barcode object with decrypted Postage ID Description:

Within this function, the check is made as to whether the Postage ID belonging to the 2D barcode is contained in a negative file. The negative files are used to remove shipments of customers who have been noticed by abuse attempts, or their PC was stolen from the transport run.

The negative files are maintained centrally within the project database franking. As part of the interface to this project, the procedure for the exchange of data to the decentralized letter center systems is to be determined.

If the nursing application or the data exchange may not yet exist, a transitional mechanism must be created here. The maintenance of this data could be done intermittently in an Excel sheet from which a csv file is generated. This file should be sent by e-mail and imported via an import mechanism to be provided in the systems. Later, the transfer then takes place via the path defined within the preferred payment assurance IT fine concept.

A Postage ID identifies a single default that a customer retrieves from the system (Postage Point). These specifications are stored in a so-called safe box on the customer system. This is a hardware component in the form of a SmartCard including a reading system or a dongle. In the safe box For example, the deposit amounts are kept safely and the customer can retrieve individual franking amounts from them without being connected online to the Postage Point.

Each Safe Box is identified by a unique ID. This safe box ID is entered in the negative file, if the corresponding consignments are to be rejected due to a suspected abuse. The Safebox ID is composed of several fields. In addition to the unique key, the Safebox ID also contains other fields such as expiration date and check digit. To clearly identify the safe box, the first three fields of the safe box ID are relevant. These can also be found in the first three fields of the PostageID, whereby the assignment between safe box and default can be made. The fields are described in the following table: Byte no. length importance data content comment b1 1 Party identification 00 not used 01 Test Provider: Mail Order Company FF Postage point box of the mail order company b2 1 Approved model no. XX For each manufacturer of 01 (first submitted model) ascending for each newly approved model. b3, b4, b5 3 Serial number of the models XX XX XX For each approved model of each manufacturer from 00 00 01 to FF FF FF ascending.

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

Are the first three fields of the Postage ID the current If the checked franking is identical to the first three fields of a safe box ID contained in the negative file, then the payment guarantee incident assigned to the customer within the negative file is returned, otherwise the success code.

• Return value: Code "00" if check OK, otherwise warning code assigned to the customer or Safe Box in the negative file

Comparison 2D barcode content with transmission text Input: 2D Harcode object Description:

To prevent copies of 2D barcodes from being created, a comparison is made between the shipment data encoded in the 2D barcode and the data specified on the letter in plain text. This comparison is directly possible with the radio scanners, since there are sufficient display and input options. For hand-held scanners with wire connection, the check must be made on the PC (pay-back system).

The sequence is such that, after the automated checks have been completed, the checking unit initiates the output of the data of the 2D barcode on the radio scanner or on the payment assurance PC. For this, a callback method is available to him, which is assigned at the beginning of a session.

He calls this with the current 2D barcode object. Then the scanner controller, or the payment assurance PC for the representation of the 2D barcode content responsible and deliver as return value (after processing by the examiner) the callback method a "00", or an associated error code back.

If the evaluation is successful, the success code is returned, otherwise the code of the "PC-F clear text" payback warning.

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

For an automatic check, this check is not required. Here, the examination can preferably take place offline in the context of the central evaluations either by means of sales comparisons or by comparison of the destination postal code with the zip code contained in the 2D barcode.

• Return value: Code "00" if check OK, otherwise warning code for pay-back incident
  "PC-F plain text"

Cryptographic tests

• a) der Entschlüsselung des Cryptostrings und
• b) dem Hashwert-Vergleich.

The cryptographic exam consists of two parts:

• a) the decryption of the Cryptostrings and
• b) the hash value comparison.

Both methods are to be performed in the crypto card's protected area because a customer could generate valid postage hash values upon spying on the information being processed.

Decrypt Cryptostrip Input: 2D barcode object Description:

As input parameter, this function receives the split 2D barcode object of the scan result. It is selected based on the franking date and the key number of the valid for this time symmetric key and decrypted the CryptoString of the transferred object using this key according to the method Triple DES CBC. With which value the initialization vector is to be preassigned, or whether one is working with inner or outerbound CBC and with which block length, a decision is made within the framework of the interface to the remuneration assurance system.

If the key contained in the 2D barcode does not exist on the cryptosystem, the payback warning "PC-F Counterfeiting (key)" is returned with the error message that the key with the key number was not found.

The result of the operation consists of the decrypted Postage ID and the decrypted random number. The decrypted PostageID is entered in a corresponding field of the 2D barcode object. For safety reasons, the random number should not be disclosed, as the customer could generate valid hash values while holding this information and thus forge 2D barcodes.

Following decryption, the hash value calculation is called from the method and its return value is returned.

hash value Input: 2D barcode object decrypted random number from the crypto string (the decrypted random number must not be known outside the map) Description:

The function of the hash value calculation determines the first 60 bytes from the original scan result contained in the 2D barcode object. The decrypted Postage ID and the transferred decrypted random number are appended to this. From this, a hash value is calculated according to the method SHA 1 and compared with the hash value of the 2D barcode contained in the 2D barcode object. If all 20 bytes match, then the cryptographic check is successful and an appropriate return value is returned.

If it does not match, a pay-back alert "PC-F suspected counterfeit (hash)" is returned to the review unit.

• 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)"

The calculated return value is additionally the calculated hash value, so that it can be output in the test result.

• Return value: calculated hash code "00" if check OK, otherwise warning code for payment guarantee prefe rs
  "PC-F suspected counterfeit (hash value)" or
  "PC-F counterfeit suspicion (key)"

Results output Display test and reading result Description:

Using a callback method, the check unit has the option of controlling a result output on the output device belonging to the current check. For this purpose, it transfers the 2D barcode object and the calculated remuneration assurance warning code to this callback method. The return value can be the code of the selected postprocessing procedure.

The output callback method is also assigned at logon to the validator, also at the beginning of the session.

result logging Input: 2D barcode object, code of the test result Description:

Result logging is done in a simplified procedure in a file on the system where the validator is running. As a rule, the results or correction rates are transmitted directly to BDE and written to the database of the preferred local payment assurance system via the preferred payment assurance BDE interface.

Preferably, the Postage ID, the sequential number, the postage date, the charge, the product key, the postcode, the pay-back result code, the message text, the duration of the check, the time of the check, the ID of the scanner, the operating mode of the scanner, the acquisition mode, as well as the Weiterverarbeitungsart stored. All values are output by a semicolon separated in each case in a sentence per transmission and are for example in Excel further evaluable.

If the system is in the "initial detection" mode, an "e" must be entered in the Acquisition Mode column, otherwise an "n" for subsequent detection.

Master Data Deployment Description:

• 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

For the content check, a series of master data is necessary. These are:

• PC-F negative file
• Sorting programs and minimum charges
• General minimum charge
• Product key PC-F
• Maximum delivery time per product key PC-F
• General maximum delivery time
• Remuneration insurance incidents, priorities and assignment to follow-up instructions
• Further treatment instructions

Master data can be permanently preconfigured in a transitional period, with the exception of the PC-F negative file and the cryptographic key of the Postage Point.

If necessary, simple editing and distribution applications can be implemented for some of the data. The maintenance should then take place in an Excel sheet from which a csv file is generated. This file should be emailed sent and read via a mechanism to be provided in the systems.

As a rule, the data is distributed in accordance with the method described in the preferred remuneration assurance IT detailed concept, or access to this data is made possible.

The associated data structures are described in the data model for the detailed concept Preferred Remuneration.

Distribution of key data

The symmetric keys used to secure the 2D bar code content at the Postage Point charging point and required by the crypto system for validation are exchanged at regular intervals for security reasons. When used in all mail centers, the keys from the (Postage Point) to the crypto systems must be transmitted automatically and securely.

The exchange should take place via the preferred payment assurance server, since the charge amount charging point (Postage Point) should not be configured as to which preferred local payment assurance systems and which crypto systems exist for this purpose.

Particularly preferred method steps for exchanging keys are shown in FIG. The preferred key exchange takes place between a central loading point (Postage Point), a central crypto server and several local crypto servers.

Since the symmetric keys are of great importance for the tamper resistance of 2D barcodes, the replacement must be secured by strong cryptography and by clear authentication of communication partners.

configuration Basic configuration / key management of the crypto hardware

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

For the basic configuration of the crypto card various measures are necessary. They should be carried out by a security administrator. These are roughly the following activities:

• Installing the software API on the card
• Generation or installation of private keys to secure administration applications and software to be imported

Depending on the selected card type and manufacturer different measures are necessary.

• 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.

The application-related basic configuration of the crypto card provided for the preferred payment assurance system consists of the following steps:

• Secure encryption and transfer of symmetric keys to the card - for example RSA key pair - with certificate generation for the public key and output of the key
• Firmly preconfigure Certificate of Postage Point to ensure that the key to be imported is issued by the Postage Point has been.

Basic configuration of the crypto-system application

Every scanner, user and crypto card within the crypto system must be identified by a unique ID. Ultimately, every AFM 2D code reader is identified by a unique ID.

Login / logoff

At the beginning of a session with the review unit, a login must be made. This login contains as parameters the scanner ID, the user ID, as well as the callback methods for the manual check or the output of the reading and test results.

The return value is a session ID, which is to be passed on during the following test calls within the session. To the session ID, a session context is stored on the verification unit, in which the transfer parameters are stored.

If the user makes changes to the operating mode, to the predefined product, or to other session settings that can be configured at runtime during his session, these changes are reflected in the associated variables within the session context.

For a logoff, the session context is deleted accordingly. Subsequent test calls with this session ID will be rejected.

The management of users and passwords is in one Defining general user management concept for preferred remuneration protection, which is part of the fine concept preferred payment assurance IT.

The reading systems must register with the verification unit prior to the execution of examination requests. The ID of the reading system and a password are to be transferred as parameters. If the login is successful, the return value will also be a Session ID, which will be sent to the following verification requests.

When the reading system shuts down, a corresponding logoff must be made with this session ID.

miscellaneous Special user roles

The security concept requires two special user roles to be filled in by two different people.

The Security Administrator

• 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

The role of security administration includes the following tasks:

• Creation of command files for the administration of the crypto card
• Signing of these command files
• Initialization and management of crypto cards
• Control of the software to be recorded and the associated configuration

The security administrator authenticates with the Private Key for card administration. This is stored on a floppy disk or smart card and must be kept under strict lock-up by the security administrator.

Only administration commands signed with this key can be executed on the crypto card. Because this mechanism protects the command sequence and associated parameters, execution of these commands can also be delegated to local system administrators. The security administrator must provide the commands and write a corresponding procedural instruction.

Another task is the management of the crypto cards, whereby the serial number, the configuration and the system number of the system in which they are installed as well as the location of the system are recorded for each card. The reserve crypto cards also record who owns the cards.

Together with the QS Manager Security, he controls the software sources and the associated software configuration and releases them for installation.

In addition, a check is made of the software to be installed or installed on the card and on the Krypto Server, as well as the approval and signing of the card software.

The card software must be specially checked to see if at any point one of the secret keys can be given to the outside via the driver interface, or whether manipulation attempts such as the storage of constant predefined keys or the use of insecure encryption methods were carried out there. In addition to the map software, the related application software of the crypto server must also be checked.

The authentication takes place just like the security administrator with a private key. However, this is the private key for software signing.

However, there is additional security in that not only the software must be signed to install the software, but also the associated installation command. Since two different persons (Qs manager and security administrator) are responsible for this and that the associated keys are stored in two different locations, this also ensures a high level of security.

The software is distributed by the QA Manager Security in coordination with the security administrator.

This particularly preferred embodiment of the invention thus provides two different authentication keys, so that the data security is considerably increased.

Claims (16)

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.

Images