EP1405274A1 - Verfahren zum überprüfen der gültigkeit von digitalen freimachungsvermerken - Google Patents

Verfahren zum überprüfen der gültigkeit von digitalen freimachungsvermerken

Info

Publication number
EP1405274A1
EP1405274A1 EP02754272A EP02754272A EP1405274A1 EP 1405274 A1 EP1405274 A1 EP 1405274A1 EP 02754272 A EP02754272 A EP 02754272A EP 02754272 A EP02754272 A EP 02754272A EP 1405274 A1 EP1405274 A1 EP 1405274A1
Authority
EP
European Patent Office
Prior art keywords
postage
checking
crypto
barcode
code
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP02754272A
Other languages
English (en)
French (fr)
Other versions
EP1405274B1 (de
Inventor
Alexander Delitz
Peter Fery
Jürgen Helmus
Aloysius Höhl
Gunther Meier
Elke Robel
Dieter Stumm
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Deutsche Post AG
Original Assignee
Deutsche Post AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=7689813&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=EP1405274(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Deutsche Post AG filed Critical Deutsche Post AG
Publication of EP1405274A1 publication Critical patent/EP1405274A1/de
Application granted granted Critical
Publication of EP1405274B1 publication Critical patent/EP1405274B1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00185—Details internally of apparatus in a franking system, e.g. franking machine at customer or apparatus at post office
    • G07B17/00435—Details specific to central, non-customer apparatus, e.g. servers at post office or vendor
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00459—Details relating to mailpieces in a franking system
    • G07B17/00661—Sensing or measuring mailpieces
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00185—Details internally of apparatus in a franking system, e.g. franking machine at customer or apparatus at post office
    • G07B17/00435—Details specific to central, non-customer apparatus, e.g. servers at post office or vendor
    • G07B2017/00443—Verification of mailpieces, e.g. by checking databases
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00459—Details relating to mailpieces in a franking system
    • G07B17/00661—Sensing or measuring mailpieces
    • G07B2017/00709—Scanning mailpieces
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00459—Details relating to mailpieces in a franking system
    • G07B17/00661—Sensing or measuring mailpieces
    • G07B2017/00709—Scanning mailpieces
    • G07B2017/00725—Reading symbols, e.g. OCR

Definitions

  • the digital postage indicia contain cryptographic information, for example about the identity of the
  • the invention has for its object to provide a method with which the authenticity of the postage indicia can be checked quickly and reliably.
  • the method should be suitable for a check in a large series application, in particular in letter or freight centers.
  • this object is achieved in that the reading unit records the franking mark graphically and transmits it to a checking unit, and in that the checking unit controls a sequence of partial checks.
  • one of the sub-exams is the Decryption of the cryptographic information contained in the franking note includes.
  • one of the partial tests compares the generation date of the
  • the reading unit and the checking unit exchange information using a synchronous protocol.
  • the reading unit and the checking unit communicate with one another via an asynchronous protocol.
  • the reading unit sends a data telegram to the checking unit.
  • the data telegram preferably contains the content of the franking mark.
  • FIG. 1 shows a schematic diagram of system components of a payment assurance system
  • FIG. 2 shows a particularly preferred embodiment of the payment assurance system, hand scanner and payment security PC
  • Fig. 3 is a schematic diagram of a generation and review of postage indicia.
  • FIG. 6 shows a further particularly preferred embodiment of the checking method with a particularly preferred sequence of partial tests
  • Fig. 7 shows a preferred sequence of distribution of keys between a central loading point
  • the invention is illustrated below using the example of a PC franking system.
  • the one to secure remuneration The process steps used are independent of the system used to generate the postage indicia.
  • decentralized check shown at individual control points in particular in letter centers, is particularly preferred, but a centralized check is equally possible.
  • Postage indicia on a random basis by individual scanners.
  • a checking system suitable for this purpose preferably contains the components shown in FIG. 1.
  • the scanners are used to read the franking note of the PC franking.
  • the franking marks are 2D codes in the data matrix format with the ECC200 error correction used.
  • the data is transmitted by radio or cable, whereby the radio scanners have a multi-cell display and thus an output option and a touchscreen, or a keyboard for rudimentary input.
  • Systems of the preferred payment security PC franking system form the scanner controller and the validation controller as components. While the scanner controller manages a queue of matrix codes, which are coming up for checking via the hand scanner and essentially maintaining contact with the scanners, he is only in contact with the other systems via the validation scanner.
  • Scanner controllers serve as an interface between the scanners and the other systems for checking the 2D barcodes.
  • the 2D barcode content converted and corrected from the optical recording is transmitted to them, and they then initiate the check and, in the case of the radio scanners, ensure that the reading and test results are output, and serve as an interface between any necessary manual reworking and checking by the tester and the other systems.
  • 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.
  • the postage point is the central system within PC franking. It serves as an interface to the customer systems. From there, customers can unload the specified amounts for subsequent franking. The keys to secure the process are generated at the postage point. It also serves as an interface to the accounting systems. The following interfaces become the preferred security system for PC franking provided :
  • Symmetrical keys • Master data, such as default amounts, account balances
  • the shipment-related information is collected and others
  • a number of master data are necessary, such as negative files, minimum fees, validity periods in relation to the product and payment assurance, warning and follow-up processing codes.
  • This data is provided from different systems (BDE, VIBRIS, local payment assurance system).
  • the general terms and conditions examiner who has to rework the PC franking items that have been removed, has the option of carrying out a more detailed check of the franking, in which the Test results are not restricted by the limited output options of the scanner.
  • the examiner can also view other data here, such as the validity period of the postage amount to which the current shipment relates, as well as the amount and the frankings used.
  • the 2D barcodes are automatically recorded within the SSA.
  • the image information is forwarded to the AFM-2D code reader. There the image is converted into the content of the data matrix code.
  • the 2D barcode content is then transmitted to the crypto system for verification, the returned verification result is evaluated and transmitted to the optical recording system (IMM) for coding the shipment.
  • IMM optical recording system
  • AFM 2D code reader per reading machine (ALM / ILVM), which receives the image data of the consignments via an optical recording system (IMM) and processes them further for payment security purposes.
  • AFM / ILVM optical recording system
  • IMM optical recording system
  • This byte chain is passed to the Validation Controller for checking.
  • the test result is then forwarded via the interface of the optical detection system and used there for coding.
  • the architecture should preferably be chosen such that the individual reading machines are permanently assigned to a crypto system and possibly also expanded by an additional fallback configuration which tries to switch to another crypto system in the event of an error.
  • the separation of the crypto system and the AFM-2D code reader also has the advantage that both the machine reading and the hand scanner check can be carried out with the same crypto system, and therefore the same function cannot be implemented twice, which is also the case essential Offers advantages in the implementation of the invention.
  • Preferred method steps for providing a postal item with a digital postage indicium after loading a fee amount from a central loading point (postage point) and generation of the postage indicium by a local PC as well as subsequent delivery of the postal item and checking of the postage indicium applied to the postal item are shown in FIG. 3 ,
  • the process is such that a customer first loads a postage amount onto his PC. A random number is generated to identify the request. A new postage amount is generated for the respective customer at the postage point and from the random number transmitted, further information on the identity of the customer system (the customer system identification information, hereinafter referred to as Postage ID) and the postage amount, the so-called cryptostring is created. which is encrypted with a secret symmetric key existing at the postage point.
  • Postage ID customer system identification information
  • This crypto string and the corresponding postage amount are then transferred to the customer PC and, together with the random number, stored securely in the "safe box" to prevent unauthorized access.
  • the shipment data relevant for the 2D barcode including the 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 ring and in unencrypted form within the hash value, it is ensured that the shipment data cannot be changed or generated arbitrarily, and it is possible to draw conclusions about the creator.
  • the relevant data for the shipment is then converted into a 2D barcode and as a corresponding one
  • the 2D barcode is read in the letter center by an AFM 2D code reader or a hand scanner and then checked.
  • the associated process steps are clear in the figure under process numbers 5-8.
  • the AFM 2D code reader transfers the complete shipment data to the crypto system.
  • cryptographic information contained in the mailing data, in particular the crypto ring is decrypted in order to determine the random number used in creating the hash value.
  • a hash value (also called a message digest) for the shipment data including the decrypted random number is then determined, and it is checked whether the result is identical to the hash value contained in the 2D barcode.
  • test result is then transmitted to the PC-F reader, which forwards the result to the optical detection system (IMM) for coding the bar code.
  • IMM optical detection system
  • the barcode is then sprayed onto the letter and the items are rejected if the test result is negative.
  • the fee amount loading point (postage point) is used to the crypto systems of the local payment assurance systems and this data has to be temporarily stored, a crypto system component must also be provided there, but the validation controller is generally not used.
  • the validation controller represents the interface for checking the entire 2D barcode content.
  • the checking of the 2D barcode consists of a content and a cryptographic check.
  • the scanned 2D barcode content of the scanner should be forwarded by the scanner controller to the validation controller.
  • Operating data acquisition used telegram manager or the protocol used within the scope of the optical acquisition system such as Corba / IIOP in question.
  • the validation controller initiates the individual test routines, which in turn transmit their test results back to it.
  • the validation controller Since several AGB validators work with different scanners at the same time, the validation controller has to be designed to be "multi-session capable". This means that it has to be able to handle simultaneous test requests and to be able to direct the corresponding output to the correct scanner. It should also be designed in such a way that he can simultaneously execute several test inquiries, as well as part of the test steps, for example hash value testing and minimum wage test.
  • the controller is informed of the type of scanner it is communicating with and is given the option of using the CallBack method to control routines for output and manual verification.
  • the results are then output either on the radio scanner or the EntgeltSich réelle system, and manual test results recorded.
  • a special problem is the storage of the key, with which the cryptostring is encrypted in a 2D barcode and has to be decrypted again for verification.
  • This key ensures the counterfeit security of the 2D barcodes and therefore it must not be possible to spy on it. Special security measures must therefore be taken to ensure that this key is never visible in plain text on the hard disk, in memory or during transmission and is also secured by strong cryptographic procedures.
  • the cryptographic methods generate a high load on the processor of the system, which is not optimized with regard to the operations to be carried out.
  • the cards that meet these characteristics are self-sufficient systems that, depending on the version, are connected to the computer via the PCI or ISA bus and communicate with the software systems on the computer via a driver.
  • the cards In addition to battery-backed main memory, the cards also have a flash rom memory in which an individual
  • Application code can be saved. Direct access to the main memory of the cards is not possible from the external systems, which ensures a very high level of security, since neither the key data nor the cryptographic methods for providing security can be accessed other than via the secure driver.
  • the cards use their own sensors to monitor whether attempts have been made to tamper (depending on the card version, for example temperature peaks, radiation, opening the protective cover, voltage peaks).
  • the function for decrypting the Postage ID, the function for checking the hash value and the function for importing key data should be loaded directly onto the card, since these routines have a high security relevance.
  • ITSEC is a set of criteria published by the European Commission for the certification of IT products and IT systems with regard to their security properties. The trustworthiness rating is based on the levels E0 to E6, where E0 means insufficient and E6 the highest level of security.
  • CC Common Criteria
  • ISO ISO Norm 15408
  • the FIPS PUB 140-1 standard is a set of criteria issued by the United States government for assessing the security of commercial cryptographic devices. This set of criteria is very strongly oriented
  • Hardware properties The assessment takes place in 4 levels, where level 1 means the lowest and level 4 the highest security.
  • the functions relevant to security as part of the crypto card application are stored directly in the card and are therefore only accessible from the outside via the card driver.
  • the interface between the driver and the validation controller is the crypto interface component, which forwards the requests for test routines to the card using the driver.
  • the task of the crypto interface is also to distribute the load 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 in order to distribute the key data. In stage 2 there may only be a rudimentary mechanism that transfers the keys encrypted for security within a signed file. A requirement for the crypto interface is then to provide a utility that enables the import of such a file.
  • the validation controller To validate the 2D barcode, the validation controller provides a central test function as an interface to the scanner or reading systems. This test function coordinates the course of the individual partial tests.
  • the codes for the payment security incident transmitted from the individual part checking routines are converted into the corresponding payment security code on the basis of a predefined table, which is preferably maintained centrally and transferred to the crypto system.
  • This table also defines priorities that regulate which remuneration protection code is assigned if several remuneration protection incidents have been identified.
  • This payment assurance code is then returned together with a descriptive text as the test result.
  • This payment assurance code is then returned together with a descriptive text as the test result.
  • the call and the return of the results differ depending on which communication mechanism is used between the reading system and the validation controller, the call and the return of the results differ. If a synchronous RPC-based protocol such as Corba / IIOP is used, the test method is called directly and the test results are transferred after the test has been completed. In this case, the client, i.e. the scanner controller, or the reading system are waiting for the execution and return of the test results. In the latter case, a thread pool must therefore be provided on the client, which can carry out the parallel check of several requests.
  • a synchronous RPC-based protocol such as Corba / IIOP
  • the scanner method or the reading system does not call the test method directly, but sends a telegram to the crypto system, which contains the test request, the content of the 2D barcode and other information such as the current sorting program .
  • the test function is called up, carried out and the reading and test results are sent back as a new telegram.
  • the test routine for the hand scanner systems expects the session ID and the content of the 2D barcode as input values.
  • the ID of the sorting program is also expected as an additional parameter.
  • the last-mentioned parameter is used to determine the minimum wage.
  • FIG. 5 shows an overview of the course of the test within the validation controller in the event that this was triggered by a hand scanner system.
  • a test with a radio scanner is then assumed, followed by a manual comparison of the address with the 2D barcode content.
  • the representation would take place analogously on the payment assurance system or the payment assurance application.
  • Verification unit (Validation Controller) is shown in Fig. 5.
  • the checking unit controls a sequence of
  • Partial tests including reading in a matrix code contained in the digital postage indicium.
  • the read-in matrix code is first transmitted from a radio scanner to a scanner controller.
  • the matrix code is then checked in the area of the scanner controller and transmitted to the checking unit.
  • the checking unit controls a splitting of the code content.
  • the reading result is then transmitted to the registration unit - in the case shown a radio scanner. In this way, for example, a user of the reading unit learns that it was possible to read the postage indicium and to recognize the information contained in the matrix.
  • the verification unit then decrypts a crypto string contained in the matrix code. This is preferably done first verifies the version of the key that is expected to be used to create the postage indicium.
  • the hash value contained in the crypto ring is then checked.
  • the planned minimum wage is also checked.
  • an identification number (Postage ID) of the customer system controlling the generation of the postage indicium is checked.
  • the result of the transmission is transmitted as a digital message, the digital message being able to be transmitted to the original radio scanner, for example.
  • a user of the radio scanner can eject the program from the program run. If this method variant is carried out automatically, it is of course equally possible to eject the mail item from the normal processing run of the mail items.
  • the result of the test is preferably logged in the area of the test unit.
  • the session ID, the content of the 2D barcode and the unique identification of the currently active sorting program are also expected as input parameters of the test routine for the AFM 2D code reader.
  • FIG. 6 shows an overview of the course of the test within the validation controller in the event that it was triggered by a reading system.
  • the figure also shows the optical recording system (IMM system) and the AFM-2D code reader to show the overall context of the test.
  • IMM system optical recording system
  • AFM-2D code reader optical recording system
  • the share of the crypto system is limited to checking the functions between the 2D barcode and the return and the logging of the result.
  • FIG. 6 shows a further preferred embodiment of a control of a sequence of partial tests by the checking unit (validation controller).
  • a checking unit validation controller
  • the reading in of the digital postage indicia is preferably carried out in an even more automated manner, for example by optically detecting a position of a mail item on which a postage indicium is preferably arranged.
  • the further checking steps essentially take place in accordance with the test sequence illustrated with reference to FIG. 5.
  • the return value of the check routine consists on the one hand of the security code and an associated message as well as the converted content and the Postage ID. A telegram is generated from these return values and transmitted to the requesting reading system.
  • the 80-byte content of the 2D barcode must be divided and converted into a structured object, hereinafter referred to as a 2D barcode object, in order to achieve a better display option and more efficient post-processing.
  • a 2D barcode object a structured object
  • the individual fields and conversions are described in the table below:
  • Warning code 00 if conversion is OK, otherwise warning for payment security incident "PC-F barcode not readable"
  • the version of the 2D barcode can be seen from the first three fields. This also shows whether the franking mark is a 2D barcode from Deutsche Post and not a 2D barcode from another
  • Warning code 00 if version check is OK, otherwise warning code for payment assurance-
  • the Postage ID contained in the 2D barcode is secured by a check digit procedure (CRC 16), which must be checked at this point. If this check fails, the result must be returned as a payment security warning "PC-F suspected of forgery (Postage ID)".
  • PC-F suspected of forgery Postage ID
  • the crypto string must be decrypted beforehand.
  • This function is used to automatically check the time interval between franking a PC-franked item and its processing at the letter center. There can only be a certain number of days between the two dates. The number of days depends on the product and its duration plus a waiting day.
  • the configuration of the period is preferably saved in a product validity period relation and maintained centrally in a maintenance mask.
  • a maintenance mask For each product key possible for PC franking (field of the 2D barcode), the associated number of days that may lie between franking and processing at the mail center are recorded.
  • a period of time is preconfigured, which relates to standard items and is stored as a constant in the system.
  • Barcode contained date 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, the payment assurance code assigned to the "PC-F date (franking)" warning case is returned to the Validation Controller, otherwise a code that documents the successful check. If In a simplified procedure, it is always compared with the value for standard consignments, after the test result has been issued, the possibility should be given, for example manually using a button on the scanner, to correct this test result if the current product allows a longer runtime.
  • Another check of the timeout relates to the content of the Postage ID.
  • the postage amount downloaded as part of a specification and thus also the Postage ID have a specified validity period in which the items are to be franked.
  • the Postage ID contains the time up to which the postage amount is valid. If the franking date is a certain number of days later than this validity date, the remuneration assurance warning code belonging to the remuneration assurance warning, PC-F date (postage amount) is returned.
  • PC-F date postage amount
  • PC-F date franking
  • the fee contained in the 2D barcode is checked against a minimum fee defined for items in the associated sorting program.
  • the amounts are amounts in euros.
  • the assignments are delivered between the sorting program and the minimum wage via an automatic interface.
  • the subsequent check compares whether the minimum wage contained in the 2D barcode is below this mark. If this is the case, the code assigned to the "PC-F under franking" payment security incident is returned, otherwise the success code.
  • This function is used to check whether the Postage ID belonging to the 2D barcode is contained in a negative file.
  • the negative files are used to remove consignments from customers that have attracted attention through misuse attempts or that have had their PCs stolen from the transport run.
  • the negative files are maintained centrally as part of the franking database project. As part of the
  • the interface to this project is to determine the procedure for the exchange of data on the decentralized letter center systems.
  • a Postage ID identifies a single specification that a customer retrieves from the system (Postage Point). These specifications are saved in a so-called safebox on the customer system. It is a hardware component in the form of a SmartCard included Reading system, or a dongle. The default amounts are securely stored in the Safebox and the customer can call up individual franking amounts without being connected online to the postage point.
  • Each Safe Box is identified by a unique ID.
  • This Safebox-ID is entered in the negative file if the related consignments are to be removed due to suspected misuse.
  • the Safebox ID is composed of several fields. In addition to the unique key, the Safebox ID also contains other fields such as the validity date and check digit.
  • the first three fields of the Safebox ID are decisive for the clear identification of the Safebox. These can also be found in the first three fields of PostagelD, which means that the assignment between Safebox and specification can be made. The fields are described in the table below:
  • the process is such that the validation controller initiates the output of the 2D barcode data on the radio scanner or on the payment security PC after the automated tests have ended. He has one for this
  • the scanner controller respectively the Remuneration Security PC responsible for displaying the 2D barcode content and returning a “00” or an associated error code as return value (after processing by the examiner) of the callback method.
  • This check is not required for an automatic check.
  • the check can preferably be carried out offline as part of the central evaluations either by comparing sales or by comparing the destination postal code with the postal code contained in the 2D barcode.
  • the cryptographic check consists of two parts:
  • This function receives the split 2D barcode object of the scan result as an input parameter. Based on the franking date and the key number, the symmetric key valid for this point in time is selected and the cryptostring of the transferred object is decrypted using this key using the Triple DES CBC method.
  • the remuneration warning "PC-F suspicion of forgery (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 PostagelD is entered in a corresponding field of the 2D barcode object.
  • the random number should not be made known, since the customer could generate valid hash values if this information was held and could thus forge 2D barcodes.
  • hash value calculation is called from the method and its return value is returned.
  • the hash value calculation function determines the first 60 bytes from the original scan result contained in the 2D barcode object.
  • the decrypted Postage ID as well as the decrypted random number passed are attached to it.
  • a hash value is calculated from this using the SHA 1 method and compared with the hash value of the 2D barcode contained in the 2D barcode object. If all 20 bytes match, the cryptographic check is successful and an appropriate return value is returned.
  • the calculated hash value is also transmitted as the return value so that it can be output with the test result.
  • the validation controller can use a callback method to control the output of results on the output device belonging to the current test. To do this, he transfers the 2D barcode object and the determined remuneration warning code to this callback method.
  • the code of the post-processing procedure selected by the AGB-Examiner can be delivered as return value.
  • the callback method for the output is also assigned at the start of the session when logging on to the Validation Controller.
  • Results or correction records are transmitted directly to BDE and written to the database of the preferred local payment assurance system via the preferred payment assurance BDE interface.
  • the Postage ID the consecutive number, the franking date, the charge, the product key, the zip code, the payment assurance 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 type of processing. All values are separated from each other by a semicolon in one sentence per shipment and can thus be further evaluated in Excel, for example.
  • Master data can be pre-configured in a transition period with the exception of the PC-F negative file and the cryptographic key of the fee amount loading point (Postage Point).
  • the data are distributed in accordance with the method described in the preferred payment assurance IT fine concept, or access to this data is made possible.
  • the exchange should take place via the preferred payment security server, since it should not be configured at the postage point that the preferred local payment security systems and which crypto systems exist.
  • FIG. 7 Particularly preferred method steps for an exchange of keys are shown in FIG. 7.
  • the preferred key exchange takes place between a central loading point (postage point), a central crypto server and several local crypto servers.
  • the application-related basic configuration of the crypto card intended for the preferred payment security system consists of the following steps:
  • Every scanner every user and every crypto card within the crypto system must be identified by a unique ID.
  • every AFM 2D code reader can also be identified by a unique ID.
  • This login contains the scanner ID, the user ID, as well as the callback methods for the manual check, or the output of the read and check results as parameters.
  • a session ID is returned as the return value, which must be passed on to the following test calls within the session.
  • a session context is stored on the validation controller, in which the transfer parameters are stored.
  • Session settings these changes are reflected in the assigned variables within the session context.
  • the reading systems must be registered with the Validation Controller before carrying out test inquiries.
  • the ID of the reading system and a password must be transferred as parameters. If the registration is successful, a session ID is also returned as a return value, which must be transmitted in the following verification requests.
  • the role of security administration includes the following tasks:
  • the security administrator authenticates himself with the private key for card administration. This is stored on a floppy disk or smart card and must be taken from it
  • Another task is to manage the crypto cards, with each card recording the serial number, the configuration and the system number of the system in which they are installed, and the location of the system.
  • the reserve crypto cards also record who owns the cards.
  • the software to be installed or installed on the card and on the crypto server is checked and the card software is released and signed.
  • the card software has to be checked especially for whether one of the secret keys is located at any point Driver interface can be given to the outside, or whether manipulation attempts such as the storage of constant predefined keys or the use of insecure encryption methods were carried out there.
  • the associated application software of the crypto server must also be checked.
  • Authentication takes place in the same way as with the security administrator with a private key. However, this is the private key for software signing.
  • the software is distributed by the QS Security Manager in coordination with the security administrator.
  • This particularly preferred embodiment of the invention thus provides two different authentication keys, so that data security is increased considerably.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Checking Fares Or Tickets At Control Points (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)
  • Road Signs Or Road Markings (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)

Abstract

Die Erfindung betrifft ein 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. Erfindungsgemäß zeichnet sich das Verfahren dadurch aus, dass die Leseeinheit den Freimachungsvermerk graphisch erfasst und an eine Überprüfungseinheit übermittelt, und dass die Überprüfungseinheit einen Ablauf von Teilprüfungen steuert.

Description

Verfahren zum Überprüfen der Gültigkeit von digitalen
Freimachungsvermerken
Beschreibung :
Es ist bekannt, Postsendungen mit digitalen Freimachungsvermerken zu versehen.
Um den Absendern der Postsendungen die Erzeugung der Freimachungsvermerke zu erleichtern, ist es beispielsweise bei dem von der Deutschen Post AG eingesetzten Frankierungssystem möglich, Freimachungsvermerke in einem Kundensystem zu erzeugen und über eine beliebige Schnittstelle auf einen Drucker auszugeben.
Um einen Missbrauch dieses Verfahrens zu vermeiden, enthalten die digitalen Freimachungsvermerke kryptographische Informationen, beispielsweise über die Identität des die
Erzeugung des Freimachungsvermerkes steuernden Kundensystems.
Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren zu schaffen, mit dem die Echtheit der Freimachungsvermerke schnell und zuverlässig überprüft werden kann. Insbesondere soll sich das Verfahren für eine Überprüfung in einem Großserieneinsatz, insbesondere in Brief- oder FrachtZentren, eignen.
Erfindungsgemäß wird diese Aufgabe dadurch gelöst, dass die Leseeinheit den Freimachungsvermerk graphisch erfasst und an eine Überprüfungseinheit übermittelt, und dass die Überprüfungseinheit einen Ablauf von Teilprüfungen steuert.
Es ist besonders zweckmäßig, dass eine der Teilprüfungen die Entschlüsselung der in dem Freimachungsvermerk enthaltenen kryptographischen Informationen beinhaltet.
Durch die Integration der Entschlüsselung der kryptographischen Informationen in den Prufungsprozess 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.
Ferner ist es vorteilhaft, dass eine der Teilprüfungen einen Vergleich zwischen dem Erzeugungsdatum des
Freimachungsvermerks und dem aktuellen Datum beinhaltet. Die Integration des Erzeugungsdatums des Freimachungsvermerks - insbesondere in verschlüsselter Form - erhöht die
Datensicherheit, da durch den Vergleich zwischen dem Erzeugungsdatum des Freimachungsvermerkes und dem aktuellen Datum eine mehrfache Verwendung eines Freimachungsvermerks zur Beförderung von Postsendungen vermieden wird.
Zur weiteren Erhöhung der Überprüfungsgeschwindigkeit ist es vorteilhaft, dass die Leseeinheit und die Überprüfungseinheit mittels eines synchronen Protokolls Informationen austauschen.
In einer anderen, gleichfalls zweckmäßigen Ausführungsform der Erfindung, kommunizieren die Leseeinheit und die Überprüfungseinheit über ein asynchrones Protokoll miteinander.
Hierbei ist es besonders zweckmäßig, dass die Leseeinheit ein Datentelegramm an die Überprüfungseinheit sendet.
Vorzugsweise enthält das Datentelegramm den Inhalt des Freimachungsvermerks. Weitere Vorteile, Besonderheiten und zweckmäßige Weiterbildungen der Erfindung ergeben sich aus den Unteransprüchen und der nachfolgenden Darstellung bevorzugter Ausführungsbeispiele anhand der Zeichnungen.
Von den Zeichnungen zeigen
Fig. 1 eine Prinzipdarstellung von Systemkomponenten eines Entgeltsicherungssystems;
Fig. 2 eine besonders bevorzugte Ausführungs- form 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üfungsverf hrens ;
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) .
Nachfolgend wird die Erfindung am Beispiel eines PC- Freimachungssystems dargestellt. Die zur Entgeltsicherung dienenden Verfahrensschritte sind dabei unabhängig von dem zur Erzeugung der Freimachungsvermerke eingesetzten System.
Die dargestellte dezentrale Überprüfung an einzelnen Kontrollstellen, insbesondere in BriefZentren, ist besonders bevorzugt, jedoch ist eine zentralisierte Überprüfung gleichermaßen möglich.
In einer ersten Ausführungsform der Erfindung erfolgt vorzugsweise eine Überprüfung der Echtheit der
Freimachungsvermerke stichprobenweise durch einzelne Scanner.
Ein hierzu geeignetes Überprüfungssystem enthält vorzugsweise die in Fig. 1 dargestellten Komponenten.
In Fig. 1 ist dargestellt, mit welchen Teilsystemen das Krypto-System in Beziehung steht. Sie werden im Folgenden kurz beschrieben.
Scanner
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 mehrzelliges 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 der 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 System nur über den Validation-Scanner in Kontakt.
Scanner Controller/Validation-Controller
Scanner Controller, beziehungsweise 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
Das Krypto-System sorgt für die inhaltliche und kryptographische Überprüfung des 2D-Barcodeinhaltes sowie für die geschützte Speicherung sicherheitsrelevanter Daten und Algorithmen. Auf die einzelnen Komponenten wird später eingegangen.
Gebührenbetragsladestelle (Postage Point)
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
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 Krypto-
Server weiter.
Datenlieferanten
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 Entgeltsicherung-Warnungs- und Folgeverarbeitungscodes. Diese Daten werden aus unterschiedlichen Systemen (BDE, VIBRIS, lokales Entgeltsicherungs-System) bereitgestellt .
EntgeltSicherung-Anwendung
Mit der Entgeltsicherung-Anwendung hat der AGB-Prüfer, der die ausgeschleusten PC-Freimachungs-Sendungen nachbearbeiten muss, die Möglichkeit, 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, wie den Gültigkeitszeitraum des Portobetrages, auf welchen sich die aktuelle Sendung bezieht, sowie den Betrag und die in Anspruch genommenen Frankierungen einsehen.
Automatische Erfassung der 2D-Barcodes
Die automatische Erfassung der 2D-Barcodes erfolgt innerhalb der SSA. 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
Pro Lesemaschine (ALM/ILVM) existiert ein AFM-2D-Code-Leser, 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.
Diese Bytekette wird an den 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
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-Code- Leser 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 Server bei entsprechendem Bedarf erhöht werden.
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.
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.
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.
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 Kundensystem- identifikationsangabe, 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.
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.
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. 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.
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.
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.
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.
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.
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
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 Entgeltsicherung 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 der Validation Controller in der Regel nicht genutzt wird.
Die Teilkomponenten des Krypto-Systems werden im Folgenden detaillierter beschrieben.
Validation Controller
Der Validation Controller 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 den Validation Controller weitergeleitet werden.
Da sich der verantwortliche Scanner Controller für den drahtgebundenen Scanner und der Validation Controller 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
Betriebsdatenerassung (BDE) verwendete Telegrammmanager oder das im Rahmen des optischen Erfassungsystems verwendete Protokoll wie Corba/IIOP in Frage.
Der Validation Controller initiiert die einzelnen Prüfroutinen, die wiederum ihre Prüfergebnisse an ihn zurückübermitteln .
Da mehrere AGB-Prüfer mit unterschiedlichen Scannern gleichzeitig tätig werden, ist der Validation Controller „multisessions-fähig" auszulegen. Das heißt, er muss gleichzeitige Prüfanfragen bewerkstelligen und die entsprechende Ausgabe auf den richtigen Scanner lenken können. Zudem sollte er so ausgelegt werden, dass er gleichzeitig mehrere Prüfanfragen, sowie einen Teil der Prüfungsschritte, zum Beispiel Hashwertprüfung und Mindestentgeltprüfung, parallel dazu ausführen kann.
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
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.
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.
Zudem erzeugen die kryptographischen Verfahren eine hohe Last auf dem Prozessor des Systems, der im Hinblick auf die durchzuführenden Operationen nicht optimiert ist.
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.
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.
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.
Zusätzlich überwachen die Karten mittels eigener Sensoren, ob Manipulationsversuche vorliegen (je nach Kartenausführung, zum Beispiel Temperaturspitzen, Strahlung, Öffnen der Schutzabdeckung, Spannungsspitzen) .
Liegt ein solcher Manipulationsversuch vor, so wird der batteriegepufferte Hauptspeicherinhalt sofort gelöscht und ein Shutdown der Karte durchgeführt.
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.
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.
Die folgende Tabelle gibt eine Übersicht der in Frage kommenden Kartenmodelle unterschiedlicher Hersteller und nennt gleichzeitig ihre Zertifizierungen.
Kryptokarten für den Einsatz innerhalb des bevorzugten Entgeltsicherungs-Systems für die PC-Frankierung
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. Für die Produkte ausgestellte Zertifikate unterteilen sich dabei in die drei von unterschiedlichen Zertifizierungsstellen vorgenommenen Einstufungen.
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.
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.
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 .
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. 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
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 dem Validation Controller dient die Krypto Interface-Komponente, welche die Requests für Prüfroutinen per Treiber an die Karte weiterleitet.
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. 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 im Validation Controller
Zur Prüfung des 2D-Barcodes wird von dem Validation Controller 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.
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-Vorfalle erkannt wurden.
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 Entgeltsicherung-Anwendung ausgegeben, beziehungsweise bei der automatischen Prüfung in einen TIT2- Code umgewandelt und die Sendung damit bedruckt. Da die Abläufe zwischen den Handscannersystemen und den automatischen Lesesystemen unterschiedlich sind, wird für beide Anwendungsfälle eine unterschiedliche Funktion implementiert .
Je nachdem, welcher Kommunikationsmechanismus zwischen dem Lesesystem und dem Validation Controller 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.
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:
Die Prüfroutine für die Handscannersysteme erwartet als Eingabewerte die Session-ID sowie den Inhalt des 2D-Barcodes. Als zusätzlicher Parameter wird auch noch die ID des Sortierprogramms erwartet. Der zuletzt genannte Parameter dient zur Bestimmung des Mindestentgelts.
Fig. 5 zeigt eine Übersicht über den Ablauf der Prüfung innerhalb des Validation Controllers 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 Entgeltsicherung-Anwendung erfolgen.
Ein bevorzugter Überprüfungsablauf durch Einsatz eines Funkscanners, eines Scanner-Controllers und einer
Überprüfungseinheit (Validation Controller) ist in Fig. 5 dargestellt .
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 .
Ferner erfolgt eine Prüfung des vorgesehenen Mindestentgelts.
Außerdem wird eine Identifikationsnummer (Postage ID) des die Erzeugung des Freimachungsvermerks steuernden Kundensystems überprüft.
Hieran anschließend erfolgt ein Abgleich der Identifikationsnummer mit einer Negativliste.
Durch diese Überprüfungsschritte ist es in dieser besonders einfachen und zweckmäßigen Form möglich, auf einfache Weise unberechtigt erzeugte Freimachungsvermerke zu ermitteln.
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.
Vorzugsweise wird das Ergebnis der Prüfung im Bereich der Überprüfungseinheit protokolliert.
Als Rückgabewert sollte der zu dem Entgeltsicherung-Vorfall gehörende Code und die zugehörige Textmeldung sowie das 2D- Barcode-Objekt zurückgegeben werden. Prüfungsablauf beim AFM-2D-Code-Leser
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.
Fig. 6 zeigt eine Übersicht über den Ablauf der Prüfung innerhalb des Validation Controllers für den Fall, dass diese von einem Lesesystem ausgelöst wurde.
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.
Im Falle der Telegrammmanager-Schnittstelle würden auf dem Validation Controller 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.
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) . 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.
Der Rückgabewert der Prüfroutine besteht einerseits aus dem Entgeltsicherung-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:
In dieser Funktion ist der aus 80 Bytes bestehende Inhalt des 2D-Barcodes aufzuteilen und in ein strukturiertes Objekt, im Folgenden mit 2D-Barcode-0bjekt bezeichnet, umzuwandeln, um eine bessere Darstellungsmöglichkeit sowie eine effizientere Nachbearbeitung zu erreichen. Die einzelnen Felder und Umwandlungen sind in der nachfolgenden Tabelle beschrieben:
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 den Validation Controller zurückzugeben. Eine weitere inhaltliche, beziehungsweise kryptographische Überprüfung ist in diesem Fall nicht sinnvoll .
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 :
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 :
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 Entgeltsicherung- 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 EntgeltSicherung- Vorfall
„PC-F Fälschungsverdacht (Postage ID) "
Prüfung der Zeitüberschreitung
Input: 2D-Barcode-0bjekt
Beschreibung:
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.
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.
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 den Validation Controller 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, bespielsweise manuell über eine Taste am Scanner, dieses Prüfergebnis zu korrigieren, falls das aktuelle Produkt eine längere Laufzeit zulässt.
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 Entgeltsicherung-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-Ob ekt ; aktuelle Sortierprogramm-ID
Beschreibung:
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.
Die Zuordnungen werden zwischen Sortierprogramm und Mindestentgelt über eine automatische Schnittstelle geliefert .
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.
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 :
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.
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.
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 an die AGB-Prüfer verschickt und von diesen ü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.
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.
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 PostagelD wieder, wodurch die Zuordnung zwischen Safebox und Vorgabe erfolgen kann. Die Felder sind in der nachfolgenden Tabelle beschrieben:
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 Entgeltsicherung-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-Barcode-0bjekt
Beschreibung:
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.
Der Ablauf sieht so aus, dass der Validation Controller 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.
Diese ruft er mit dem aktuellen 2D-Barcode-Objekt auf. Daraufhin sind der Scanner Controller, beziehungsweise der Entgeltsicherung-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.
Bei erfolgreicher Auswertung wird der Erfolgscode, ansonsten der Code der Entgeltsicherungs-Warnung „PC-F-Klartext " zurückgegeben .
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 Entgeltsicherung- Vorfall „PC-F-Klartext"
Kryptographische Prüfungen
Die kryptographische Prüfung besteht aus zwei Teilen:
a) der Entschlüsselung des Cryptostrings und b) dem Hashwert-Vergleich.
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: 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.
Sollte der in dem 2D-Barcode enthaltene Schlüssel auf dem Kryptosystem nicht vorhanden sein, so wird die Entgeltsicherung-Warnung „PC-F Fälschungsverdacht (Schlüssel) " mit der Fehlermeldung, dass der Schlüssel mit der Key-Nummer nicht gefunden wurde, zurückgegeben.
Das Ergebnis der Operation besteht aus der entschlüsselten Postage ID, sowie der entschlüsselten Zufallszahl. Die entschlüsselte PostagelD wird in einem entsprechenden Feld des 2D-Barcode-0bjektes 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.
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: 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.
Bei Nichtübereinstimmung wird eine Entgeltsicherung-Warnung
„PC-F-Fälschungsverdacht (Hashwert) " an den Validation Controller zurückgegeben.
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 Entgeltsicherung-
Vorfall
„PC-F-Fälschungsverdacht (Hashwert) " oder „PC-F-Fälschungsverdacht (Schlüssel) " Ergebnisausgabe
Prüf- und Leseergebnis darstellen
Beschreibung:
Über eine Callback-Methode hat der Validation Controller die Möglichkeit, eine Ergebnisausgabe auf dem zur aktuellen Prüfung gehörenden Ausgabegerät anzusteuern. Hierzu übergibt er dieser Callback-Methode das 2D-Barcode-Objekt und den ermittelten Entgeltsicherung-Warnungscode. Als Rückgabewert kann der Code des von dem AGB-Prüfer ausgewählten Nachbearbeitungsverfahrens geliefert werden.
Die Callback-Methode für die Ausgabe wird, ebenfalls zu Beginn der Session, bei der Anmeldung am Validation Controller zugewiesen.
Ergebnisprotokol1ierung
Input: 2D-Barcode-Objekt , Code des Prüfergebnisses
Beschreibung:
Die Ergebnisprotokollierung erfolgt in einem vereinfachten
Verfahren in einer Datei auf dem System, auf dem der Validation Controller 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.
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.
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:
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
Entgeltsicherung-Vorfälle, Prioritäten und Zuordnung zu
Weiterbehandlungsanweisungen
Weiterbehandlungsanweisungen
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.
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 an die AGB-Prüfer verschickt und von diesen über einen vorzusehenden Mechanismus in den Systemen eingelesen werden.
In der Regel werden die Daten entsprechend dem im Bevorzugte Entgeltsicherung- IT-Feinkonzept beschriebenen Verfahren verteilt, beziehungsweise ein Zugriff auf diese Daten ermöglicht .
Die zugehörigen Datenstrukturen werden im Datenmodell zum Feinkonzept Bevorzugte EntgeltSicherung beschrieben.
Verteilung der Schlüsseldaten
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.
Der Austausch sollte dabei über den bevorzugten Entgeltsicherungs-Server erfolgen, da bei der Gebührenbetragsladestelle (Postage Point) nicht konfiguriert werden sollte, welche bevorzugten lokalen Entgeltsicherungs- Systeme und welche Krypto-Systeme dazu existieren.
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.
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
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
Je nach ausgewähltem Kartentyp und -hersteiler sind dabei unterschiedliche Maßnahmen notwendig.
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üssel- paar - 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-Syste -Applikation
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
Zu Beginn einer Session mit dem Validation Controller 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 .
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 dem Validation Controller ein Session Context gespeichert, in dem die Übergabeparameter gespeichert sind.
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.
Bei einem Logoff wird der Session Context entsprechend gelöscht. Nachfolgende Prüfungsaufrufe mit dieser Session ID werden abgewiesen. 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.
Die Lesesysteme müssen sich vor der Durchführung von Prüfungsanfragen bei dem Validation Controller 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.
Bei einem Shutdown des Lesesystems muss ein entsprechender Logoff mit dieser Session ID erfolgen.
Sonstiges
Spezielle Benutzerrollen
Im Rahmen des Sicherheitskonzepts sind zwei spezielle Benutzerrollen vorzusehen, die von zwei unterschiedlichen Personen auszufüllen sind.
Der/die Sicherheitsadministrator (in)
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
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.
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.
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.
Zusammen mit dem QS-Manager Sicherheit kontrolliert er die
Softwarequellen und die zugehörige Sof warekonfiguration und gibt diese zur Installation frei.
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.
Die Kartensoftware ist speziell daraufhin zu prüfen, ob an irgendeiner Stelle einer der geheimen Schlüssel über die Treiberschnittstelle 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.
Die Authentisierung erfolgt genauso wie bei dem Sicherheitsadministrator mit einem Private Key. Es handelt sich hierbei jedoch um den Private Key zur Softwaresignierung .
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.
Die Distribution der Software wird von dem QS-Manager Sicherheit in Abstimmung mit dem Sicherheitsadministrator vorgenommen.
Diese besonders bevorzugte Ausführungsform der Erfindung sieht somit zwei verschiedene Authentisierungsschlüssel vor, so dass die Datensicherheit erheblich erhöht wird.

Claims

Patentansprü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, d a d u r c h g e k e n n z e i c h n e t, dass die Leseeinheit den Freimachungsvermerk graphisch erfasst und an eine Überprüfungseinheit übermittelt, und dass die Überprüfungseinheit einen Ablauf von Teilprüfungen steuert .
2. Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t, 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 , d a d u r c h g e k e n n z e i c h n e t, 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, d a d u r c h g e k e n n z e i c h n e t , dass die Leseeinheit und die Überprüfungseinheit mittels eines synchronen Protokolls Informationen austauschen.
5. Verfahren nach Anspruch 4, d a d u r c h g e k e n n z e i c h n e t, dass das Protokoll RPC basiert ist.
6. Verfahren nach einem oder mehreren der Ansprüche 1 bis 5, d a d u r c h g e k e n n z e i c h n e t, dass die Leseeinheit und die Überprüfungseinheit über ein asynchrones Protokoll miteinander kommunizieren.
7. Verfahren nach Anspruch 6, d a d u r c h g e k e n n z e i c h n e t, dass die Leseeinheit ein Datentelegramm an die Überprüfungseinheit sendet.
8. Verfahren nach Anspruch 7, d a d u r c h g e k e n n z e i c h n e t, dass das Datentelegramm den Inhalt des Freimachungsvermerks enthält.
9. Verfahren nach einem oder mehreren der Ansprüche 1 bis 8, d a d u r c h g e k e n n z e i c h n e t, 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, d a d u r c h g e k e n n z e i c h n e t, dass durch ein Krypto-Interface eine Lastverteilung zwischen mehreren Überprüfungsmitteln erfolgt.
11. Verfahren nach einem oder mehreren der Ansprüche 1 bis 10, d a d u r c h g e k e n n z e i c h n e t, dass der Inhalt des Freimachungsvermerks in einzelne Felder aufgeteilt wird.
12. Verfahren nach Anspruch 11 , d a d u r c h g e k e n n z e i c h n e t, 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, d a d u r c h g e k e n n z e i c h n e t, 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, d a d u r c h g e k e n n z e i c h n e t, 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, d a d u r c h g e k e n n z e i c h n e t, dass Überprüfungsparameter des Verfahrens geändert werden können .
16. Verfahren nach Anspruch 15, d a d u r c h g e k e n n z e i c h n e t, dass eine Änderung von Verfahrensparametern nur nach Eingabe eines persönlichen digitalen Schlüssels (Private Key) eines Systemadministrators erfolgt .
EP02754272A 2001-07-01 2002-06-28 Verfahren zum überprüfen der gültigkeit von digitalen freimachungsvermerken Expired - Lifetime EP1405274B1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10131254 2001-07-01
DE10131254A DE10131254A1 (de) 2001-07-01 2001-07-01 Verfahren zum Überprüfen der Gültigkeit von digitalen Freimachungsvermerken
PCT/DE2002/002348 WO2003005307A1 (de) 2001-07-01 2002-06-28 Verfahren zum überprüfen der gültigkeit von digitalen freimachungsvermerken

Publications (2)

Publication Number Publication Date
EP1405274A1 true EP1405274A1 (de) 2004-04-07
EP1405274B1 EP1405274B1 (de) 2006-10-25

Family

ID=7689813

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02754272A Expired - Lifetime EP1405274B1 (de) 2001-07-01 2002-06-28 Verfahren zum überprüfen der gültigkeit von digitalen freimachungsvermerken

Country Status (22)

Country Link
US (1) US20040249764A1 (de)
EP (1) EP1405274B1 (de)
JP (1) JP2005508537A (de)
CN (1) CN100388306C (de)
AT (1) ATE343830T1 (de)
AU (1) AU2002320894B2 (de)
BG (1) BG64913B1 (de)
CA (1) CA2452750A1 (de)
CZ (1) CZ301362B6 (de)
DE (2) DE10131254A1 (de)
DK (1) DK1405274T3 (de)
HK (1) HK1065146A1 (de)
HR (1) HRP20031076B1 (de)
HU (1) HUP0400462A2 (de)
NO (1) NO325464B1 (de)
NZ (1) NZ530387A (de)
PL (1) PL369445A1 (de)
RU (1) RU2292591C2 (de)
SK (1) SK16272003A3 (de)
WO (1) WO2003005307A1 (de)
YU (1) YU101803A (de)
ZA (1) ZA200400093B (de)

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU763571B2 (en) 1998-12-23 2003-07-24 Chase Manhattan Bank, The System and method for integrating trading operations including the generation, processing and tracking of and trade documents
US8793160B2 (en) 1999-12-07 2014-07-29 Steve Sorem System and method for processing transactions
US7831467B1 (en) 2000-10-17 2010-11-09 Jpmorgan Chase Bank, N.A. Method and system for retaining customer loyalty
US8849716B1 (en) 2001-04-20 2014-09-30 Jpmorgan Chase Bank, N.A. System and method for preventing identity theft or misuse by restricting access
US7689506B2 (en) 2001-06-07 2010-03-30 Jpmorgan Chase Bank, N.A. System and method for rapid updating of credit information
US7266839B2 (en) 2001-07-12 2007-09-04 J P Morgan Chase Bank System and method for providing discriminated content to network users
US8020754B2 (en) 2001-08-13 2011-09-20 Jpmorgan Chase Bank, N.A. System and method for funding a collective account by use of an electronic tag
DE10150457A1 (de) * 2001-10-16 2003-04-30 Deutsche Post Ag Verfahren und Vorrichtung zur Bearbeitung von auf Oberflächen von Postsendungen befindlichen graphischen Informationen
US7987501B2 (en) 2001-12-04 2011-07-26 Jpmorgan Chase Bank, N.A. System and method for single session sign-on
GB0225290D0 (en) * 2002-10-30 2002-12-11 Secretary Trade Ind Brit Anti-counterfeiting apparatus and method
US8301493B2 (en) 2002-11-05 2012-10-30 Jpmorgan Chase Bank, N.A. System and method for providing incentives to consumers to share information
RU2232419C1 (ru) * 2002-12-17 2004-07-10 Аби Софтвер Лтд. Система автоматизации ввода и контроля документов
DE10305730B4 (de) * 2003-02-12 2005-04-07 Deutsche Post Ag Verfahren zum Überprüfen der Gültigkeit von digitalen Freimachungsvermerken
US8306907B2 (en) 2003-05-30 2012-11-06 Jpmorgan Chase Bank N.A. System and method for offering risk-based interest rates in a credit instrument
DE10337164A1 (de) * 2003-08-11 2005-03-17 Deutsche Post Ag Verfahren sowie Vorrichtung zur Bearbeitung von auf Postsendungen befindlichen graphischen Informationen
US8175908B1 (en) 2003-09-04 2012-05-08 Jpmorgan Chase Bank, N.A. Systems and methods for constructing and utilizing a merchant database derived from customer purchase transactions data
FR2863076B1 (fr) * 2003-11-28 2006-02-03 Bull Sa Systeme cryptographique haut debit a architecture modulaire.
DE102004003004B4 (de) * 2004-01-20 2006-10-12 Deutsche Post Ag Verfahren und Vorrichtung zur Frankierung von Postsendungen
JP4139382B2 (ja) * 2004-12-28 2008-08-27 インターナショナル・ビジネス・マシーンズ・コーポレーション 製品／サービスに係る所有権限を認証する装置、製品／サービスに係る所有権限を認証する方法、及び製品／サービスに係る所有権限を認証するプログラム
US7401731B1 (en) 2005-05-27 2008-07-22 Jpmorgan Chase Bank, Na Method and system for implementing a card product with multiple customized relationships
US7925578B1 (en) 2005-08-26 2011-04-12 Jpmorgan Chase Bank, N.A. Systems and methods for performing scoring optimization
US8355028B2 (en) 2007-07-30 2013-01-15 Qualcomm Incorporated Scheme for varying packing and linking in graphics systems
US8805747B2 (en) 2007-12-07 2014-08-12 Z-Firm, LLC Securing shipment information accessed based on data encoded in machine-readable data blocks
US8521656B2 (en) 2007-12-07 2013-08-27 Z-Firm, LLC Systems and methods for providing extended shipping options
US8527429B2 (en) 2007-12-07 2013-09-03 Z-Firm, LLC Shipment preparation using network resource identifiers in packing lists
US8812409B2 (en) 2007-12-07 2014-08-19 Z-Firm, LLC Reducing payload size of machine-readable data blocks in shipment preparation packing lists
US8818912B2 (en) 2007-12-07 2014-08-26 Z-Firm, LLC Methods and systems for supporting the production of shipping labels
US8622308B1 (en) 2007-12-31 2014-01-07 Jpmorgan Chase Bank, N.A. System and method for processing transactions using a multi-account transactions device
US8554652B1 (en) 2008-02-21 2013-10-08 Jpmorgan Chase Bank, N.A. System and method for providing borrowing schemes
US8392337B2 (en) * 2008-05-16 2013-03-05 Bell And Howell, Llc Generation of unique mail item identification within a multiple document processing system environment
DE102008063009A1 (de) * 2008-12-23 2010-06-24 Deutsche Post Ag Verfahren und System zum Versenden einer Postsendung
KR101072277B1 (ko) * 2009-08-31 2011-10-11 주식회사 아나스타시스 실시간 데이터 무결성 보장 장치 및 방법과 이를 이용한 블랙박스 시스템
US8554631B1 (en) 2010-07-02 2013-10-08 Jpmorgan Chase Bank, N.A. Method and system for determining point of sale authorization
US9058626B1 (en) 2013-11-13 2015-06-16 Jpmorgan Chase Bank, N.A. System and method for financial services device usage
EP2879099B1 (de) * 2013-12-02 2019-01-09 Deutsche Post AG Verfahren zum Überprüfen einer Authentizität eines Absenders einer Sendung
US11227252B1 (en) 2018-09-28 2022-01-18 The Descartes Systems Group Inc. Token-based transport rules
WO2021018241A1 (zh) * 2019-07-31 2021-02-04 北京市商汤科技开发有限公司 信息处理

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5769480A (en) * 1980-10-15 1982-04-28 Omron Tateisi Electronics Co Seal-impression collation system
US4670011A (en) * 1983-12-01 1987-06-02 Personal Products Company Disposable diaper with folded absorbent batt
GB2174039B (en) * 1985-04-17 1989-07-05 Pitney Bowes Inc Postage and mailing information applying system
US4757537A (en) * 1985-04-17 1988-07-12 Pitney Bowes Inc. System for detecting unaccounted for printing in a value printing system
US5349633A (en) * 1985-07-10 1994-09-20 First Data Resources Inc. Telephonic-interface game control system
US4796193A (en) * 1986-07-07 1989-01-03 Pitney Bowes Inc. Postage payment system where accounting for postage payment occurs at a time subsequent to the printing of the postage and employing a visual marking imprinted on the mailpiece to show that accounting has occurred
US4813912A (en) * 1986-09-02 1989-03-21 Pitney Bowes Inc. Secured printer for a value printing system
US4893338A (en) * 1987-12-31 1990-01-09 Pitney Bowes Inc. System for conveying information for the reliable authentification of a plurality of documents
US4949381A (en) * 1988-09-19 1990-08-14 Pitney Bowes Inc. Electronic indicia in bit-mapped form
GB8823301D0 (en) * 1988-10-04 1988-11-09 Scantech Promotions Inc Coupon validation terminal
US5022080A (en) * 1990-04-16 1991-06-04 Durst Robert T Electronic notary
US5170044A (en) * 1990-11-09 1992-12-08 Pitney Bowes Inc. Error tolerant 3x3 bit-map coding of binary data and method of decoding
US5142577A (en) * 1990-12-17 1992-08-25 Jose Pastor Method and apparatus for authenticating messages
US5241600A (en) * 1991-07-16 1993-08-31 Thinking Machines Corporation Vertification system for credit or bank card or the like
US5388158A (en) * 1992-11-20 1995-02-07 Pitney Bowes Inc. Secure document and method and apparatus for producing and authenticating same
US5448641A (en) * 1993-10-08 1995-09-05 Pitney Bowes Inc. Postal rating system with verifiable integrity
US5454038A (en) * 1993-12-06 1995-09-26 Pitney Bowes Inc. Electronic data interchange postage evidencing system
US5606613A (en) * 1994-12-22 1997-02-25 Pitney Bowes Inc. Method for identifying a metering accounting vault to digital printer
GB9505433D0 (en) * 1995-03-17 1995-05-03 Neopost Ltd Postage meter system and verification of postage charges
US5661803A (en) * 1995-03-31 1997-08-26 Pitney Bowes Inc. Method of token verification in a key management system
US6889214B1 (en) * 1996-10-02 2005-05-03 Stamps.Com Inc. Virtual security device
US6032138A (en) * 1997-09-05 2000-02-29 Pitney Bowes Inc. Metering incoming deliverable mail
DE19748954A1 (de) * 1997-10-29 1999-05-06 Francotyp Postalia Gmbh Verfahren für eine digital druckende Frankiermaschine zur Erzeugung und Überprüfung eines Sicherheitsabdruckes
DE19812902A1 (de) * 1998-03-18 1999-09-23 Francotyp Postalia Gmbh Verfahren für eine Frankier- und Adressiermaschine
US6175827B1 (en) * 1998-03-31 2001-01-16 Pitney Bowes Inc. Robus digital token generation and verification system accommodating token verification where addressee information cannot be recreated automated mail processing
ATE373929T1 (de) * 1998-11-24 2007-10-15 Ericsson Telefon Ab L M Verfahren und kommunikationssytem mit dynamisch anpassbaren teilnehmern
US6480831B1 (en) * 1998-12-24 2002-11-12 Pitney Bowes Inc. Method and apparatus for securely transmitting keys from a postage metering apparatus to a remote data center
US6847951B1 (en) * 1999-03-30 2005-01-25 Pitney Bowes Inc. Method for certifying public keys used to sign postal indicia and indicia so signed
US6178412B1 (en) * 1999-04-19 2001-01-23 Pitney Bowes Inc. Postage metering system having separable modules with multiple currency capability and synchronization
JP2001215853A (ja) * 2000-01-31 2001-08-10 Canon Inc 画像データ処理装置、画像データ記録装置、画像データ記録システム、画像データ記録方法及び記憶媒体
DE10020566C2 (de) * 2000-04-27 2002-11-14 Deutsche Post Ag Verfahren zum Versehen von Postsendungen mit Freimachungsvermerken
US6868407B1 (en) * 2000-11-02 2005-03-15 Pitney Bowes Inc. Postage security device having cryptographic keys with a variable key length
DE10055145B4 (de) * 2000-11-07 2004-09-23 Deutsche Post Ag Verfahren zum Versehen von Postsendungen mit Frankierungsvermerken
US6938017B2 (en) * 2000-12-01 2005-08-30 Hewlett-Packard Development Company, L.P. Scalable, fraud resistant graphical payment indicia

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO03005307A1 *

Also Published As

Publication number Publication date
JP2005508537A (ja) 2005-03-31
HRP20031076B1 (en) 2008-04-30
WO2003005307A1 (de) 2003-01-16
ZA200400093B (en) 2005-04-01
NO20035858L (no) 2004-01-20
CN100388306C (zh) 2008-05-14
CZ301362B6 (cs) 2010-01-27
BG108505A (en) 2004-08-31
PL369445A1 (en) 2005-04-18
BG64913B1 (bg) 2006-08-31
DE10131254A1 (de) 2003-01-23
CZ20033555A3 (en) 2004-05-12
SK16272003A3 (en) 2004-10-05
HK1065146A1 (en) 2005-02-08
EP1405274B1 (de) 2006-10-25
HRP20031076A2 (en) 2005-10-31
RU2003137601A (ru) 2005-05-27
ATE343830T1 (de) 2006-11-15
NO325464B1 (no) 2008-05-05
YU101803A (sh) 2005-06-10
CA2452750A1 (en) 2003-01-16
RU2292591C2 (ru) 2007-01-27
US20040249764A1 (en) 2004-12-09
NZ530387A (en) 2005-06-24
AU2002320894B2 (en) 2007-04-26
DK1405274T3 (da) 2007-02-26
CN1554076A (zh) 2004-12-08
HUP0400462A2 (hu) 2005-02-28
DE50208553D1 (de) 2006-12-07

Similar Documents

Publication Publication Date Title
EP1405274B1 (de) Verfahren zum überprüfen der gültigkeit von digitalen freimachungsvermerken
DE69634397T2 (de) Verfahren zum Erzeugen von Wertmarken in einem offenen Zählsystem
DE69631025T2 (de) System und Verfahren zur Wiederherstellung im Falle einer Katastrophe in einem offenen Zählsystem
DE69434621T2 (de) Postgebührensystem mit nachprüfbarer Unversehrtheit
DE3841389C2 (de) Informationsübermittlungssystem zur zuverlässigen Bestimmung der Echtheit einer Vielzahl von Dokumenten
DE69932396T2 (de) Verfahren und Vorrichtung zur sicheren Schlüsselübertragung zwischen einer Frankiermaschine und einer entfernten Datenzentrale
DE69738636T2 (de) Verbessertes Verschlüsselungskontrollsystem für ein Postverarbeitungssystem mit Überprüfung durch das Datenzentrum
DE10056599C2 (de) Verfahren zum Versehen von Postsendungen mit Freimachungsvermerken
DE10300297A1 (de) Verfahren und Vorrichtung zur Bearbeitung von auf Oberflächen von Postsendungen befindlichen graphischen Informationen
DE10305730A1 (de) Verfahren zum Überprüfen der Gültigkeit von digitalen Freimachungsvermerken und Vorrichtung zur Durchführung des Verfahrens
DE10020566C2 (de) Verfahren zum Versehen von Postsendungen mit Freimachungsvermerken
EP1807808B1 (de) Verfahren und vorrichtung zum frankieren von postsendungen
EP1340197B1 (de) Verfahren zum versehen von postsendungen mit frankierungsvermerken
DE69930202T2 (de) Verfahren zur Begrenzung der Schlüsselbenutzung in einem Frankiersystem welches kryptographisch gesicherte Briefmarken produziert
EP1486028B1 (de) Verfahren und vorrichtung zur erstellung prüfbar fälschungssicherer dokumente
EP2140429A1 (de) Verfahren und vorrichtungen zur frankierung einer postsendung mit speicherung der kennungsinformation der postsendung in einer positivliste
EP1779332A1 (de) Verfahren und vorrichtung zur frankierung von postsendungen
EP1759486B1 (de) Verfahren zur dokumentation wenigstens einer verifikation an einem analogen oder digitalen dokument sowie herstellung eines derartigen dokumentes
DE102004047221A1 (de) Verfahren und Vorrichtung zum Frankieren von Postsendungen
AT513805A2 (de) Ausweis, insbesondere elektronischer Ausweis

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20040202

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1065146

Country of ref document: HK

17Q First examination report despatched

Effective date: 20050615

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: RO

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT;WARNING: LAPSES OF ITALIAN PATENTS WITH EFFECTIVE DATE BEFORE 2007 MAY HAVE OCCURRED AT ANY TIME BEFORE 2007. THE CORRECT EFFECTIVE DATE MAY BE DIFFERENT FROM THE ONE RECORDED.

Effective date: 20061025

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20061025

Ref country code: IE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20061025

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

REF Corresponds to:

Ref document number: 50208553

Country of ref document: DE

Date of ref document: 20061207

Kind code of ref document: P

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20070125

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20070205

GBT Gb: translation of ep patent filed (gb section 77(6)(a)/1977)

Effective date: 20070117

REG Reference to a national code

Ref country code: CH

Ref legal event code: NV

Representative=s name: R. A. EGLI & CO. PATENTANWAELTE

REG Reference to a national code

Ref country code: DK

Ref legal event code: T3

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20070326

REG Reference to a national code

Ref country code: HK

Ref legal event code: GR

Ref document number: 1065146

Country of ref document: HK

ET Fr: translation filed
PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: NL

Payment date: 20070615

Year of fee payment: 6

REG Reference to a national code

Ref country code: IE

Ref legal event code: FD4D

PLBI Opposition filed

Free format text: ORIGINAL CODE: 0009260

PLAX Notice of opposition and request to file observation + time limit sent

Free format text: ORIGINAL CODE: EPIDOSNOBS2

26 Opposition filed

Opponent name: SIEMENS AG

Effective date: 20070724

NLR1 Nl: opposition has been filed with the epo

Opponent name: SIEMENS AG

PLAF Information modified related to communication of a notice of opposition and request to file observations + time limit

Free format text: ORIGINAL CODE: EPIDOSCOBS2

PLBB Reply of patent proprietor to notice(s) of opposition received

Free format text: ORIGINAL CODE: EPIDOSNOBS3

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20070630

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20070126

PLAB Opposition data, opponent's data or that of the opponent's representative modified

Free format text: ORIGINAL CODE: 0009299OPPO

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DK

Payment date: 20080610

Year of fee payment: 7

NLV4 Nl: lapsed or anulled due to non-payment of the annual fee

Effective date: 20090101

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20090101

PLCK Communication despatched that opposition was rejected

Free format text: ORIGINAL CODE: EPIDOSNREJ1

APBM Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNO

APBP Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2O

APAH Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNO

APBQ Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3O

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20070628

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20061025

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: AT

Payment date: 20090615

Year of fee payment: 8

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20061025

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: CH

Payment date: 20090617

Year of fee payment: 8

REG Reference to a national code

Ref country code: DK

Ref legal event code: EBP

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: BE

Payment date: 20090715

Year of fee payment: 8

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20090630

BERE Be: lapsed

Owner name: DEUTSCHE POST A.G.

Effective date: 20100630

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100630

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100630

APBU Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9O

PLBN Opposition rejected

Free format text: ORIGINAL CODE: 0009273

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: OPPOSITION REJECTED

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100628

27O Opposition rejected

Effective date: 20110426

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100630

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20110630

Year of fee payment: 10

REG Reference to a national code

Ref country code: DE

Ref legal event code: R100

Ref document number: 50208553

Country of ref document: DE

Effective date: 20110426

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20110620

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: IT

Payment date: 20110623

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20110630

Year of fee payment: 10

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20120628

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20120628

REG Reference to a national code

Ref country code: FR

Ref legal event code: ST

Effective date: 20130228

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 50208553

Country of ref document: DE

Effective date: 20130101

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20120628

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20120702

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20130101