EP1604336A1 - Verfahren zum überprüfen der gü ltigkeit von digitalen freimachungsvermerken und vorrichtung zur durchführung des verfahrens - Google Patents

Verfahren zum überprüfen der gü ltigkeit von digitalen freimachungsvermerken und vorrichtung zur durchführung des verfahrens

Info

Publication number
EP1604336A1
EP1604336A1 EP04703745A EP04703745A EP1604336A1 EP 1604336 A1 EP1604336 A1 EP 1604336A1 EP 04703745 A EP04703745 A EP 04703745A EP 04703745 A EP04703745 A EP 04703745A EP 1604336 A1 EP1604336 A1 EP 1604336A1
Authority
EP
European Patent Office
Prior art keywords
key
data
data key
message
import
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP04703745A
Other languages
English (en)
French (fr)
Inventor
Peter Fery
Jürgen Helmus
Gunther Meier
Dieter Stumm
Carsten Vullriede
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
Application filed by Deutsche Post AG filed Critical Deutsche Post AG
Publication of EP1604336A1 publication Critical patent/EP1604336A1/de
Withdrawn 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/00733—Cryptography or similar special procedures in a franking system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • 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/00733—Cryptography or similar special procedures in a franking system
    • G07B2017/00741—Cryptography or similar special procedures in a franking system using specific cryptographic algorithms or functions
    • G07B2017/0075—Symmetric, secret-key algorithms, e.g. DES, RC2, RC4, IDEA, Skipjack, CAST, AES
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00733—Cryptography or similar special procedures in a franking system
    • G07B2017/00846—Key management
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00733—Cryptography or similar special procedures in a franking system
    • G07B2017/00846—Key management
    • G07B2017/0087—Key distribution

Definitions

  • the digital postage indicia contain cryptographic information, for example about the identity of the customer system controlling the generation of the postage indicium.
  • 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 is intended to be suitable for a check in a large series application, in particular in letter or freight centers.
  • this object is achieved in that the method for checking the authenticity is carried out in such a way that a data key is generated and transferred from a central database (ZinS central system) to local payment assurance companies. Systems (ZinS-local) is transferred. This is done by means of a franking key generated and a franking mark applied to a mail item, the cryptographic information contained in the franking mark being decrypted and used to check the authenticity of the franking mark.
  • the local security systems import the data key and transmit a result of the import to the central database (ZinS central system).
  • the result of the import is transmitted as a data record.
  • the data record preferably contains a key.
  • the key can have different textures. In particular, it can be both a symmetrical and an asymmetrical key.
  • the key is used to decrypt and / or encrypt information. Due to its nature, the key can also carry information. For example, the key contains information about the franking key, its key generation and / or its expiry date.
  • the result can be checked in different ways. However, it is particularly advantageous that the result is checked by decrypting the key.
  • a preferred embodiment of the method is characterized in that when the data key is successfully imported into essentially all local payment assurance systems (ZinS-local), the data key is released as a new franking key at the value transfer center (Postage Point) and then used to create new postage ,
  • ZinS-local essentially all local payment assurance systems
  • Postage Point the value transfer center
  • This embodiment of the method makes it possible to carry out a key change in the value transfer center as a function of key changes previously carried out in the payment assurance systems. This ensures that postage indicia are only generated using the new key after the new key is already available in the local remuneration security systems. This ensures that the local
  • Remuneration assurance systems can check the validity of the franking notes generated.
  • This particularly preferred embodiment of the method with control of the key change in the value transfer center as a function of the key changes in the local security systems is particularly advantageous in combination with at least some of the further method steps according to the invention.
  • a combination of several features ensures that the key change can be carried out quickly and reliably and that the implementation of the respective key change is checked.
  • the new data key is transferred from the value transfer center (postage point) to the central payment security system.
  • the value transfer center encrypts the data key with a transport key (KT).
  • the transport key is encrypted with a master transport key (KTM).
  • KTM master transport key
  • the data key is preferably generated in the area of the value transfer center. This has the advantage that improper changes to the data key during a
  • Transport to the value transfer center can be avoided.
  • the data key is advantageous for the data key to be provided with key identification information.
  • the key identification information is also expediently transmitted in encrypted form.
  • the data key In order to ensure that a valid data key is used for the encryption and / or decryption steps used, it is expedient for the data key to be provided with a generation counter and / or to be transmitted together with the generation counter. To avoid the use of invalid keys, it is also expedient that the franking key is provided with an expiry date for the previous data key and / or is transmitted with the expiry date.
  • the data key shown can be used both for one or more partial checks and for generating postage indicia and / or decrypting information contained in the postage indicia.
  • one of the partial checks includes the decryption of the cryptographic information contained in the postage indicium.
  • one of the partial checks includes a comparison between the date of creation of the postage indicium and the current date.
  • the integration of the generation date of the postage indicium - in particular in encrypted form - increases data security since the comparison between the generation date of the postage indicium and the current date avoids multiple use of a postage indicium.
  • 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 notice.
  • FIG. 3 shows a schematic diagram of an interface between a central payment assurance system (ZinS central system) and a value transfer center (postage point);
  • ZinS central system central payment assurance system
  • postage point value transfer center
  • FIG. 7 shows a basic illustration of method steps for encapsulating components and for handling error messages.
  • the invention is illustrated below using the example of a PC franking system.
  • the procedural steps used to secure remuneration 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.
  • the individual control points form local remuneration security systems, which are preferably connected to a central remuneration security system via a data connection.
  • the central payment assurance system is also connected to a value transfer center.
  • the technical interface to be implemented between the value transfer center and the payment security system consists of exchanging cryptographic keys.
  • the key that is to be exchanged between the value transfer center and the remuneration security system ensures that the franking marks produced are secure against forgery. This is done in particular by encrypting part of the content of the 2D barcode forming the franking mark with it. Since the selected key is a symmetrical key for performance reasons, it must be transferred from the value transfer center to the remuneration security system and distributed there to the individual letter centers.
  • the secure storage of the keys is guaranteed through the use of special crypto cards.
  • the invention includes various applications in which these keys are managed using this special hardware.
  • the entire life cycle of these keys, from generation, export, distribution to import on the decentralized systems, is used to optimize process parameters.
  • FIG. 1 A particularly preferred sequence for key distribution can be seen in FIG. 1.
  • 1 shows a particularly preferred key distribution between the value transfer center and the central payment assurance system.
  • a new franking key is first generated.
  • franking key is not to be understood in any way restrictive, since the keys shown can be used in various ways for the creation of frankings.
  • a crypto string as disclosed for example in German patent application DE 100 20 402 AI, is introduced into the franking key.
  • the franking key is exchanged as the need arises.
  • the franking key is recreated at regular intervals, for example after a predeterminable time interval has elapsed.
  • the new franking key can generally be created at any point. To increase data security, however, it is expedient to minimize the transfer effort for the new franking key and to generate the key in the value transfer center or in the area of the value transfer center.
  • the franking keys are transferred from the value transfer center to the central remuneration security system.
  • the transmission is preferably automated.
  • the exchange is preferably carried out via a server of the payment assurance system (ZinS central server).
  • the postage point does not need to be configured. Since the server does not need to know the value transfer center (ZinS local systems) and its associated crypto systems, the ZinS central server is the only important factor for him.
  • the key is released at the value transfer center (postage point) and then used to create new postage amounts - method step 6 in FIG. 1 -.
  • the preferably symmetrical keys are an essential part of the security against forgery of franking marks generated with the aid of the franking key, which have the form of two-dimensional bar codes, for example.
  • the exchange of these keys must be secured by strong cryptography. To ensure this, the following points are particularly important:
  • both communication partners have the same key KT.
  • the value transfer center (postage point) encrypts the data key KD to be transmitted with the key KT and transfers it to the server of the central payment assurance system (ZinS central system).
  • This key is distributed from the central payment security system to the ZinS local crypto systems of the local payment security systems. These also have KT and can therefore decrypt the KD key again. Because the key is used to KT
  • the transport key To protect the key KD securely during transport, it is also referred to below as the transport key.
  • KTM master transport key
  • This key must be put on the crypto card under special security measures and therefore only needs to be changed at large intervals.
  • KTM is installed on all systems.
  • This key is then used to encrypt the transport key KT, which is then automatically distributed and imported via the same channel. The distribution is like the distribution of the
  • MAC matrix code
  • the signature key KS is required, which, like the KTM, is imported during the initialization of the crypto cards.
  • the data key messages are then signed with this KS.
  • the procedure for encrypting and decrypting messages is Triple DES (key length 168 bits).
  • Hash values are preferably calculated using the SHA-1 algorithm.
  • KD Ne u the new key is transferred to the crypto systems of the payment protection systems. If this has been successfully imported by all crypto systems of the local payment assurance systems, the ZinS central system will release a message and KD Neu will be used for the encryption of new postage amounts at the postage point. From this point on, the old KD should be deleted from the postage point or should not be used to create new postage amounts.
  • the following implementation of the key distribution method is particularly advantageous in order to achieve a uniform status, which enables a clear versioning of the keys and results in system maintenance that is as simple as possible: a) Data keys are identified with a unique key ID (key phase Indicator), an ambiguous generation counter and an expiry date for the valid previous data key.
  • the generation counter is used to differentiate error-related multiple loading attempts from wanted updates of the symmetrical data key (to ensure transaction security, see (g)).
  • the generation counter is increased by one for the transmission of a subsequent data key. d) If there is a negative acknowledgment, the data key has not been successfully installed in all local payment assurance systems and should not be provided by the value transfer center for the generation of postage indicia
  • the generation counter is not increased by one for the transmission of a subsequent data key, i.e. it remains at the value of the previous transfer.
  • a crypto card As soon as a crypto card receives a data key, it deletes all data keys that have the same generation counter value as the most recent transmission. This ensures that in the event of error-related multiple transmission, keys, that could previously only be loaded successfully on a part of all crypto cards are deleted. This enables transaction-secure key transmission.
  • a security routine is called several times, preferably regularly, in particular daily, which deletes the data keys that are no longer required.
  • a data key is then deleted (in an expedient embodiment, in addition to point g)) if the expiry date stored in the successor data key in the attribute CKA_END_DATE is earlier than the current system date.
  • a grace period (as short as possible) should be planned for the expiry date for the previous key, as postage paid for an expired postage amount will still be recognized as valid two days after the validity date when checking in the area of the local remuneration system.
  • a time lag between the creation and release of a new data key must also be taken into account.
  • FIG 2 shows an overview of the areas of application of the key management shown and their use in the area of payment security. Preferred areas of application are also shown.
  • the LMK should be divided into at least three components, two of which are particularly advantageous for restoring or re-initializing crypto server cards. Each of the components is preferably written on S artCards in a PIN-protected manner, with the security administrators receiving a SmartCard. Backup SmartCards should also be created.
  • the LMK serves as the one described above
  • New transport master keys are preferably generated in the manner shown below.
  • the Local Master Key of a corresponding authorization card serves as the KTM.
  • the LMK should be divided into at least three components, of which at least two components are required for re-import.
  • the individual components are stored on SmartCards, with each security administrator receiving a SmartCard and securing it with an individual PIN.
  • PIN PIN
  • SmartCards By keeping the PIN secret and keeping the SmartCards in a safe place, it must be prevented that unauthorized persons can gain access to them.
  • the transport master keys are preferably at least two LMK components - corresponding to two different authorization cards - are provided, so that this implements an automated implementation of a four-eyes principle.
  • the KTM must be a Triple DES key.
  • the ID attribute of the key consists of a type identifier and a unique number.
  • the signing key ensures the integrity of the key messages. It can also be used to determine whether the sender of the key message is the postage point before the key is imported.
  • the generation of the signature key should only be possible by a security administrator registered with a smart card. This should be a TDES key that has the security attributes Sensitive set to "True” and Extractable set to "False” to prevent the key plain text from being determined outside the card.
  • the ID attribute of the key consists of a type identifier and a unique number.
  • Type code KS Unique number: 01 to 99.
  • Length fixed 4 bytes is stored as CK_CHAR []. To export the key, it must be wrapped with the KTM and then saved as a file on a floppy disk. The floppy disk must be kept safely and is used to initialize the crypto server cards. The integrity of the key file is ensured by the processing routine preferably contained in the cards, which is used for wrapping.
  • Preferred attributes of the transport key KS are shown in the table below.
  • the random number in the attribute label serves to confirm the successful import on the crypto server cards.
  • a hash value (for example using SHA-1) is formed for this random number and this is used to confirm the successful import and to activate the transport key.
  • the attributes CKA_ID and CKA_LABEL are to be set as CK_CHAR. All other attributes are defined in the type via the Pkcsll.h file.
  • a transport key including the associated key message is created.
  • the key generation module is preferably designed such that the generation of the transport key and / or the associated key message can only be triggered by a security administrator.
  • the change interval should be annual or biennial.
  • the transport key is again a TDES key with the following attribute settings:
  • the random number in the attribute label serves to confirm the successful import on the crypto server cards.
  • a hash value (using SHA-1) is formed for this random number and this is used to confirm the successful import and to activate the transport key.
  • the attributes CKA_ID and CKA_LABEL are to be set as CK_CHAR []. All other attributes are defined in the type via the Pkcsll.h file.
  • F nl + 1 - MAC MAC to which f nl + 24 key message; is formed by forming a SHAl hash value for fields 1-5 of the message, and this hash value is encrypted with the signing key (mechanism CKM_DES3_CBC_PAD, the IV is padded with zeros; ID see field 5).
  • This transport key message is then passed on to the ZinS central server for further distribution.
  • the interface is implemented as a session bean, this service is found using a name service (JNDI).
  • JNDI name service
  • the message is saved on the postage point as a file so that the security administrators can later save it on one or more disks that are to be kept safe.
  • the floppy disks are then found when initializing new crypto server cards Use.
  • the value transfer center is designed in such a way that it can unlock the transport key KT.
  • An interface is provided to enable the transport key KT, via which the central value transfer center can be used after successful distribution and import of a transport key to all local ones
  • Payment security systems can unlock this transport key.
  • the transport key concerned is only used for the encryption of data keys (KD) after activation.
  • the interface is implemented as a session bean. This service is located using a name service.
  • the data structure for activation preferably has the following parameters:
  • the authentication of the key allocation system of the remuneration security system (ZinS key management system) to the PP key management system takes place via parameter 2. It is a hash value that is generated using the SHA-1 method from the attribute label of the transport key. The attribute label is assigned a random value when the transport key is generated. Since the transport key and all of its attributes are encrypted during transmission, only the ZinS crypto server can calculate the correct hash value.
  • the transport key becomes activated. This means that the data key messages are subsequently encrypted with the transport key.
  • a data key including the associated key message is created.
  • the key assignment system is preferably such that this action can only be triggered by a security administrator. It should be done quarterly. If there is a data key KD in circulation, none of which is yet available from the central payment assurance system (ZinS central system)
  • the data key (KD) is used to encrypt certain matrix code contents and ensures that no valid postage indicia can be created that have not been billed to the postal company. This data key is used on the ZinS crypto servers to verify the digital postage indicia.
  • the data keys are also TDES keys that are generated using the PKCS # ll function C_GenerateKey and have the following attributes:
  • the system specifies the values for the attribute CKA_ID and the generation counter.
  • the CKA_ID is always incremented by one, the generation counter only if the key has been successfully released.
  • the attributes CKA_ID and CKA_LABEL are to be set as CK_CHAR []. All other attributes are defined in the type via the Pkcsll.h file.
  • the random number in the attribute label serves to confirm the successful import on the crypto server cards.
  • a hash value (using SHA-1) is formed for this random number and this is used to confirm the successful import and to unlock the data key.
  • the intermediate message is in turn encrypted with the active transport key KT with the aid of the mechanism CKM_DES3_CBC_PAD (the IV is filled with zeros).
  • the message to be distributed is formed, which has the following structure:
  • the security administrators store it on one or more floppy disks to be used for initializing new ZinS crypto server cards.
  • An interface and a protocol mechanism are provided for the activation of the data key KD, through which the activation of the data key is logged.
  • the central payment security system is preferably created in such a way that the data key is only released after the successful distribution and import of a data key on the crypto systems of the local payment security systems. Only after activation, the data key concerned is subsequently used for the encryption of crypto strings to be included in the postage indicia and the associated key identification information KeylD in the
  • the interface is implemented via CWMS between the central payment assurance system (ZinS Prima) and the local payment assurance system (ZinS Lokal).
  • the value transfer center (Postage Point) PP receives the information about the corresponding bean.
  • the data structure for activation has the following content:
  • the key allocation system of the value transfer center PP is carried out via parameter 2.
  • This is preferably a hash value that is generated by means of the method SHA-1 is formed from the attribute label of the data key.
  • the attribute label is assigned a random value when the data key is generated. Since the data key and all of its attributes are encrypted during transmission, the correct hash value can only be calculated by the crypto server of the payment protection system.
  • the data key is activated. This means that in the following the crypto strings for the postage indicia / postage amounts are encrypted with this data key.
  • Activation of a data key increases the generation counter of the data key by one.
  • the status of this key generation and distribution is logged and the associated data key is deleted on the card accordingly.
  • the generation counter is not increased by one.
  • the key assignment systems preferably contain a status memory for storing key generations that have been carried out. As long as there is no feedback from the central payment assurance system (ZinS central system) regarding the key distribution, the
  • Security administrator start an archiving function that encrypts all keys (exception KTM) with the KTM (mechanism CKM_KEY_WRAP_WEBSENTRY) and returns it. These keys should be saved in the database or in a secure file system area.
  • the restoration of keys - especially in the area of the value transfer center PP - is done by decrypting the archived key data (unwrap) and storing it on the card.
  • the mechanism used is again CKM_KEY_WRAP_WEBSENTRY.
  • the KTM master transport key is securely protected against compromise thanks to special security measures on both the WebSentry card and the distribution across several SmartCards.
  • the previous KTM remains on the card as a so-called "dormant LMK" and must be deleted accordingly by the security administrator.
  • a first use case is the initialization of the crypto card in the area of the payment security system.
  • Firmware contains the embedded code (own software routines) (the latter functionality is integrated in WebSentryManager)
  • User administration deletion of the default security administrator and definition of the security administrator incl. Required authentication rules (smart card-based) Creation of two "normal" users (one for key verification / one for key import) who authorize themselves via a specified PIN.
  • the functionality of the user administration is also provided by the WebSentryManager.
  • the keys are to be imported in the order defined above. Card initialization can take place at a central location, whereby the complete crypto system computer must be initialized and then sent. This is because the WebSentry card clears the internal memory as soon as it is pulled out of the PCI slot.
  • the transport master key can preferably only be imported by at least two
  • This functionality is provided via the administration tool Web Sentry Manager.
  • LTK Local Master Key
  • the signing key ensures the integrity of the key messages, and it can also be used to determine whether the key is imported before the key is imported
  • the sender of the key message is the postage point.
  • the signing key can be generated in various ways, the examples shown being particularly advantageous.
  • the associated key message is stored on a floppy disk by the administrator and is loaded onto a crypto card of the remuneration security system to be initialized via this use case.
  • the key message stored on the diskette is decrypted with the master transport key KTM (PKCS # ll function CJJnwrap, mechanism CKM_KEY_WRAP_WEBSENTRY).
  • KTM master transport key
  • the integrity of the key message is automatically checked by this routine. If a key with this KeylD already exists, it will be deleted afterwards.
  • the server of the central payment assurance system provides an interface via which the distribution and the subsequent import on the crypto systems of the individual local payment assurance systems can be stimulated.
  • the interface is implemented as an RMI service. This service is found using a
  • JNDI Name service
  • the crypto systems are managed via an application of the payment protection system.
  • the receipt of new key messages on the individual crypto servers is checked at regular intervals (depending on the distribution mechanism) by an import controller.
  • the "Import transport key" application is triggered automatically.
  • the return value of this action is checked. If there is negative feedback, the import attempt is repeated up to three times.
  • the log messages are processed centrally using the "Log key processing" use case.
  • the release of the transport key is also triggered accordingly.
  • Importing the transport key is either carried out by a security administrator who carries out the initialization on site at the crypto system, or it is triggered automatically by the key distribution import controller when he receives a new transport key message.
  • the key is preferably imported in accordance with the following process steps:
  • a hash value is formed for fields 1-5 of the transport key message using the SHA-1 method.
  • the signature key is determined, which has the KeylD that was specified in field 4.
  • a hash value was formed using the SHA-1 method and returned together with the KeylD and the positive message as a return value.
  • a variant of this use case is that one of the routines or the MAC check fails.
  • the further processing is terminated and a return value is returned that contains the KeylD, the error code and an error message.
  • the saved number of failed attempts is increased by one. If it has reached three, a protocol message is generated from the last returned return value and sent to the central payment assurance system.
  • the result of the import is also displayed on the security administrator's screen.
  • Steps 2-7 preferably run directly in the
  • Card software (embedded code). This increases both the performance and the security against being spied on.
  • a further interface is provided by the server of the central payment security system, via which the distribution and the subsequent import of the data keys to the individual crypto systems of the local payment security systems takes place.
  • the interface is implemented as a session bean, this service is found using a name service (JNDI).
  • JNDI name service
  • the distribution is preferably carried out via the CWMS used to distribute the P / N list.
  • the key message is forwarded to all currently registered crypto systems and a log entry is written in each case.
  • the crypto systems are managed via an allocation system. If a distribution order for a data key is already in circulation, for which no confirmation has yet been sent to the PP value transfer center, the acceptance of further distribution keys for data keys will be rejected until the time of the confirmation.
  • the receipt of new key messages on the individual crypto servers is checked at regular intervals (depending on the distribution mechanism) by an import controller.
  • the "Import data key" use case is triggered automatically.
  • the return value of this action is checked. If there is negative feedback, the import attempt is repeated up to three times.
  • the log messages are processed centrally using the "Log key processing" use case. This use case also triggers the release of the data key.
  • the import of the data key is either carried out by a security administrator who is on site at the The crypto system carries out the initialization or it is triggered automatically by the key distribution import controller when it receives a new data key message.
  • the key is imported in the same way as the transport key, taking into account the special features of a data key message:
  • a hash value is formed for fields 1-7 of the data key message using the SHA-1 method.
  • the signature key is determined, which has the KeylD that was specified in field 5.
  • the transport key is determined that has the KeylD that was specified in field 6 of the key message.
  • the content of field 1 of the intermediate message is decrypted using the KTM (method CJJnwrapKey, mechanism CKM_KEY_WRAP_WEBSENTRY). This automatically creates and stores the corresponding data key object on the card. The mechanism also implicitly checks the integrity of the key and the correct sender.
  • KTM method CJJnwrapKey, mechanism CKM_KEY_WRAP_WEBSENTRY
  • a hash value is formed for bytes 2-65 of the attribute label of the newly imported key using the SHA-1 procedure and this is returned together with the KeylD and the positive message as a return value.
  • a variant of this use case is that one of the routines or the MAC check fails.
  • the further processing is terminated and a return value is returned that contains the KeylD, the error code and an error message.
  • the saved number of failed attempts is increased by one. If it has reached three, a protocol message is generated from the last returned return value and this is sent to the central payment assurance system (ZinS Central System).
  • the result of the import is also displayed on the security administrator's screen.
  • Steps 2-10 preferably run directly in the card software (embedded code). This increases both the performance and the security against espionage (especially of the IV, as well as the KTM).
  • the data keys are cleaned several times, preferably regularly, on as many, preferably all, crypto systems of the payment security system as possible and are used to delete data keys that are no longer required.
  • the key processing is preferably logged on the central server
  • the keys that are logged by this use case are the transport and data keys.
  • each distribution order For each distribution order, it is logged to which active crypto systems the key message was sent. A separate entry is created for each system and each distribution order, which is initially set to the status "Sent". After successful but also unsuccessful key processing, the individual crypto systems create a protocol message and send it to the central payment assurance system (ZinS central system). This distribution takes place either via JMS queues or via database replication.
  • the messages are used after receipt to update the log entries described above.
  • the status "Processing successful” / "Not successful” as well as a possible error code and the message are saved.
  • the call for the key release is noted in the distribution order so that multiple releases are not carried out for one order. As long as the note has not yet been set, attempts will be made to contact the approval service at regular intervals.
  • a special variant is present if, after a time to be defined, preferably several days, for example 3, not all crypto systems have given feedback. After this time, a negative release message is sent to the value transfer center.
  • the key assignment system preferably contains a user interface which enables an administrator to control the status of a key distribution order. The following data is then displayed for each distribution order:
  • a detailed list can also be created, with the current status for each system being displayed.
  • the key restoration of transport and data keys can be triggered centrally for a special cryptosystem.
  • the current keys are determined from the archive and sent to the special crypto system.
  • Log messages are also generated for this. Only the release notification is not required with this type of key distribution.
  • the corresponding crypto system must either be sent to the security administrators for reinitialization, or the security administrators must reinitialize the respective system on site.
  • the KTM master transport key is securely protected against compromise thanks to special security measures on both the WebSentry card, as well as the distribution over several SmartCards and the multi-level key system.
  • the previous KTM master transport key remains on the card as a so-called "dormant LMK" and must be used by be deleted accordingly by the security administrator.
  • the key handling and decryption should be available as embedded code on the crypto card. As a result, not only is an increased security level achieved, but also a performance gain of the cryptosystem is expected.
  • the crypto cards preferably contain the following standard Pkcs # ll functions:
  • CE stands for Crypto Extension.
  • Each embedded method delivers a return value of the type
  • CK_RV which is defined as an integral part of the include file pkcsll.h. It is advisable that further error return values are defined when implementing the embedded methods and these in a C ++ Header file to be provided. This measure is advantageous in that various Pkcsll methods can be called nested on the hardware by calling an embedded method. Another advantage here is the completely new key handling within the software of the crypto cards.
  • CK_RV CE_MethodName (parameter list)
  • parameters that must be filled with a result are transferred by call by reference.
  • the method name is formed from meaningful combinations of words that give a good impression of what the method does.
  • the wording is chosen in such a way that it can be assigned to meaning content, for example by using English technical terms.
  • CE_EnumKey ⁇ CE_KT, CE_DT, CE_SE, CE_KA ⁇
  • CE_KA has a special position. It is not a key, but the set of all keys. If this enum element is specified, the methods implement a functionality that relates to all keys contained on the card.
  • CE_EnumKeyAttribut ⁇ CE_ID, CE_LABEL, CE_STARTDATE, CE_ENDDATE ⁇
  • the necessary defines have to be included in the file pkcsll.h.
  • the defined extensions can be in a separate header file, which is included in the pkcsll.h file.
  • Various mechanisms are possible when implementing embedded methods.
  • CK_RV CE_Decrypt (CK_SESSION_HANDLE session, CK_BYTE [] message, CK_BYTE * postagelD, CK_BBOOL bOk)
  • the embedded cryptography method is given a 57 byte long date in the parameter message, which corresponds to the
  • the matrix code of the franking mark corresponds.
  • the counting in the following explanation of the work steps starts at one.
  • Step 1 Formation of the initialization vector IV
  • the initialization vector the first two bytes are filled with zero and then the bytes f6 - flO plus byte f14 are appended to the matrix code.
  • Step 2 Determine the KD to be used
  • the key phase indicator is contained in byte fl4 and provides information on which key is to be used.
  • the key phase indicator is stored in the key attribute CKA_ID and thus clearly identifies the key.
  • the key handling listed below should enable the key to be found efficiently.
  • CK_MECHANISM The mechanism used in CK_MECHANISM is CKM_DES3_CBC.
  • the bytes fl5 - f38 are decrypted, that is 24 bytes, the first 12 bytes of the decrypted result are carried out by the parameter postagelD. If the decrypte has been carried out successfully, the procedure is continued in step 4, otherwise in step 5.
  • the hash value of the date is obtained from a specially constructed 77-byte data block.
  • Bytes 66 to 77 Corresponds to the last 12 bytes of the current, unencrypted part of the message.
  • the hash value is formed according to SHA-1 and the first four bytes must match bytes f54 - f57 after this process. If this is not the case, the date is invalid. If an error occurs during the execution of the hashing or the hash value differs, the procedure is as in step 5.
  • Step 5 return of the success indicator
  • the bOk parameter is set to true if all the steps have been successful and false if the hash value comparison has resulted in a deviation or one of the Pkcs # ll methods has caused an error.
  • the return value is accordingly with the Error message to be filled or with CKR_OK if no error has occurred.
  • CK_RV CE VerifyMsg (CK_SESSI0N_HANDLE Session, CK_BYTE [] message, int length, CK_BBOOL bOk)
  • KD MAC, to the key message; Is formed by adding a SHA1 hash to the fields
  • Unused fields are padded with zeros.
  • the method of operation of the method is determined via the parameter MsgType.
  • Step 1 Formation of the initialization vector IV
  • the initialization vector is padded with zeros.
  • Step 2 Decrypt the encrypted message it contains
  • CK_MECHANISM The mechanism used in CK_MECHANISM is CKM_DES3_CBC_PAD.
  • the bytes of the variable MAC field are decrypted. If an error occurs during decoding, proceed as in step 4.
  • Step 3 matching the hash value
  • a hash is formed from fields 1 + 2 + 5 + 6 + 8 of the transport key message to form the hash value of the date. Which is compared with that from step 2.
  • the hash value is formed according to SHA-1. If the hash values are not identical, the date is invalid. If an error occurs during the execution of the hashing or the hash value differs, the procedure is as in step 4.
  • Step 4 return of the success indicator
  • the parameter bOk is set to "true” if all work steps have been successful and "false” if the hash value comparison has resulted in a deviation or one of the Pkcs # ll methods has caused an error.
  • the return value is accordingly with the Error message to be filled or with CKR_OK if no error has occurred.
  • Step 1 Formation of the initialization vector IV
  • the initialization vector is padded with zeros.
  • Step 2 Decrypt the encrypted message it contains
  • CK_MECHANISM The mechanism used in CK_MECHANISM is CKM_DES3_CBC_PAD.
  • the bytes of the variable MAC field are decrypted. If an error occurs during decoding, proceed as in step 4.
  • Step 3 Matching the hash value To create the hash value of the date, the
  • Fields 1 + 2 + 4 + 3 + 6 + 7 + 8 of the data key message have a hash that is compared with that from step 2.
  • the hash value is formed according to SHA-1. If the hash values are not identical, the date is invalid. If an error occurs during the execution of the hashing or the hash value differs, the procedure is as in step 4.
  • Step 4 return of the success indicator
  • the parameter bOk is set to "true” if all work steps have been successful and "false” if the hash value comparison has resulted in a deviation or one of the Pkcs # ll methods caused an error. Accordingly, the return value must be filled with the error message or with CKR_OK if no error has occurred.
  • These embedded key handling methods should include key import of a wrapped key and efficient key management. Keys of the type KS, KD and KT are to be imported.
  • CK_RV CE_ImportKey (CK_SESSION_HANDLE session, CK_BYTE_PTR data,
  • the function assignment CE_ImportKey is preferably carried out as described below:
  • the mechanism CKM_KEY_WRAP_WEBSENTRY is used for wrapping. Accordingly, the same mechanism is required for the unwrap.
  • the key obtained is imported to the crypto hardware by the unwrapping, whereby a key that is imported a second time, ie with the same key phase, overwrites the old key.
  • the wrapped key is passed in the data parameter and its length in the length parameter.
  • the length of the key depends on the key attributes.
  • the key type is verified via the keyTyp parameter and handled accordingly.
  • the key is then included in the cached key management and possibly. the double predecessor deleted.
  • the DT is decrypted by the KT, which is identified by the KeyKTID parameter; for all other key types, this parameter is ignored and is set to NULL.
  • the random attribute in the key attribute of the imported key contains the hash value according to SHA-1.
  • the hash value is returned in the hashValue parameter of the embedded method.
  • the hash value is required for the key confirmation message.
  • the corresponding error code is output in the return value, otherwise CKR_OK.
  • the function assignment CE_GetKeyCount shows how many
  • Keys of the respective key type are registered on the card in the cached key management. This makes it possible to read out key attributes in conjunction with the method shown below.
  • CK_RV CE_GetAttribute (CK_SESSION_HANDLE session, CE_EnumKey keyTyp, CE_EnumKeyAttribute keyAttribute, int pos,
  • the key type is used to determine the key type and thus the table from which to read if the different key types are kept in different lists on the crypto hardware, arranged according to the type of key.
  • the keyAttribut parameter defines the attribute that is to be read out and the pos parameter supplies the
  • the attributes for a date have a fixed length of 8 bytes, whereas the attributes CKA_ID and CKA_LABEL have a fixed length of 128 bytes. If the attributes within the key are shorter than 128 bytes for these two parameters, the remaining bytes up to 128 are filled with zero. In this way, the user can always provide the appropriate methods with sufficient storage space. In the event that the user provides a buffer that is too small, the information is trimmed and a corresponding error message is transmitted via CK RV.
  • CK_RV CE_ DeleteExpiredKeys (CK_SESSION_HANDLE Session, CE_EnumKey keyTyp, int * counter)
  • CE_DeleteExpiredKeys searches the card for expired keys and deletes them from the card.
  • Expired keys can be identified by the characteristic that the system date is older than the CKA_END_DATE of the successor key, see under 2.5.8. also applies to KT and KS.
  • the enum type enables selective deletion and with CE_KA the entire card can be deleted (only the LMK is retained). It is important that this method must not be activated if a key import is carried out. This is preferably checked in the embedded code and displayed with a corresponding return value. This measure may prevent possible side effects in internal key maintenance that are not clear.
  • the interface between the payment assurance system and the value transfer center is preferably as narrow as possible in order to rule out manipulation possibilities through side channels.
  • the value transfer center (postage point) and the central payment assurance system are shown in FIG. 3.
  • the central payment security system provides an interface for the distribution of keys, via which keys created in the KeyManagement component of the value transfer center (Postage Points) can be distributed to the crypto systems of the payment security systems.
  • the value transfer center provides the
  • Fee security system a key release interface is available, via which from the fee security system after successful distribution and processing of a
  • a session bean provides the functionality required to import the key data into the ZinS central system. The entire communication is shown in Fig. 4.
  • the importKey procedure passes the data key set to ZinSZentral.
  • ASN.l prepares the received message and causes the message to be stored in the database.
  • the importKey procedure then initiates the distribution of the key data to the ZinS local systems using CWMS.
  • the parameters of the insertKeyData method have not yet been specified, as it is not yet clear whether the ASN.l format is supported. However, the method will have to be equipped with two parameters in order to be able to send a more detailed message to the Postage Point.
  • ASN.l The data are transmitted from the value transfer center (Postage Point) in ASN.l format.
  • the corresponding response is also expected in ASN.l format.
  • other formats can of course also be used.
  • the respective formats are adapted for use by a suitable parser.
  • Preferred data formats in ASN.l look as follows: Distribution message transport key
  • the data structures can have a different structure. However, a structure corresponding to the exemplary embodiments shown is particularly advantageous, since both the transmission of all information to be taken into account and the low data transmission effort are achieved.
  • the data is transmitted to the local payment assurance systems, which are preferably located in the mail company's mail centers, using CWMS.
  • the data packets received by the CWMS correspond to the key messages previously defined in this document. These are then subjected to the VerifyMsg method of the embedded code after they have been previously adapted to the data table on page 29. After checking it, either the key import via the embedded code is started or a corresponding error message is generated. Compare key messages and page 12-14 regarding the import data structure of the embedded code method CE_ImportKey.
  • the old keys are deleted and updated automatically using the embedded code methods described above.
  • CE_DeleteExpiredKeys is called daily, which removes the expired keys from the crypto hardware daily, insofar as this is necessary.
  • CA_ImportKey method ensures that duplicate keys are deleted and newer ones replace them.
  • KryptoAdapters offer all functions (in particular the same) that the embedded code and other Pkcs # ll methods offer.
  • a DLL (KryptoAdapter.DLL) is used that has the Zaxus DLL provided with a static link. Static linking further minimizes the security risk.
  • the C ++ implementation of the JNI interface also provides error handling for each requested session, see the design document PCFM level 3 under multithreading.
  • the worker concept is supported in that the crypto hardware is initialized in multithreading mode and after the login each worker gets his own session (getSession, C_GetSession), which registers this worker in the DLL and establishes a specially managed error handling for him.
  • the mainstream of the DLL is addressed by the login and also has its own error handling with regard to the execution of Pkcs # ll methods and the embedded methods.
  • the key messages from the Postage Point are stored in ZinS Central in a database for later use
  • the key message stores the key data as it was received by the postage point; its archiving is used in the event of a failure of a local payment assurance system to coordinate this with the other remaining local payment assurance systems by uploading the archived keys. Before being saved, the message must be dismantled by ASN.l in order to transmit it to the local systems.
  • the common form of the data records is preferred for storage, this corresponds to the table which contains the data block describes, which is used for the embedded method CE " VerifyMessage.
  • This data set is of central importance. It serves on the one hand to evaluate the feedback received from the local remuneration system in the mail centers, preferably all of the mail centers integrated in the mailing company's mailing system, as well as a strong error analysis and
  • This table also has administrative information processing.
  • the associated transport key data can be entered via the SNPosNr entry

Abstract

Die Erfindung betrifft ein Verfahren zur Überprüfung der Echtheit eines unter Einsatz eines Freimachungsschlüssels erzeugten und auf einer Postsendung aufgebrachten Freimachungsvermerks, wobei in dem Freimachungsvermerk enthaltene kryptographische Informationen entschlüsselt und zur Überprüfung der Echtheit des Freimachungsvermerks eingesetzt werden. Erfindungsgemäß zeichnet sich das Verfahren dadurch aus, dass ein neuer Freimachungsschlüssel erzeugt und von einer zentralen Datenbank (ZinS Zentral-System) an lokale Entgeltsicherungssysteme (ZinS-lokal) übertragen wird.

Description

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

Claims

Patentansprüche :
1. Verfahren zur Überprüfung der Echtheit eines unter Einsatz eines Freimachungsschlüssels erzeugten und 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 ein Datenschlüssel (KD) erzeugt und von einem zentralen Entgeltsicherungssystem an lokale EntgeltSicherungssysteme übertragen wird.
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 die lokalen Entgeltsicherungssysteme den Datenschlüssel importieren und ein Ergebnis des Imports an die zentralen EntgeltSicherungssysteme (ZinS Zentral-System) übermitteln.
3. Verfahren nach Anspruch 2, d a d u r c h g e k e n n z e i c h n e t, dass das Ergebnis des Imports als ein Datensatz übermittelt wird.
4. Verfahren nach Anspruch 3, d a d u r c h g e k e n n z e i c h n e t, dass der Datensatz einen Schlüssel enthält .
5. Verfahren nach einem oder mehreren der Ansprüche 2 bis 4, d a d u r c h g e k e n n z e i c h n e t, dass das zentrale Entgeltsicherungssystem (ZinS Zentral-System) das Ergebnis des Imports überprüft und an ein WertübertragungsZentrum (Postage Point) übermittelt.
6. Verfahren nach Anspruch 5, d a d u r c h g e k e n n z e i c h n e t, dass die Überprüfung des Ergebnisses durch Entschlüsselung des Schlüssels erfolgt.
7. Verfahren nach einem oder mehreren der Ansprüche 1 bis 6, d a d u r c h g e k e n n z e i c h n e t, dass bei erfolgreichem Import des Datenschlüssels auf im Wesentlichen allen lokalen
Entgeltsicherungssystemen (ZinS-lokal) der Datenschlüssel auf dem WertübertragungsZentrum (Postage Point) freigegeben und im Anschluss bei der Erstellung neuer Portobeträge verwendet wird.
Verfahren nach einem oder mehreren der Ansprüche 1 bis 7, d a d u r c h g e k e n n z e i c h n e t, dass der Datenschlüssel ein symmetrischer Schlüssel ist.
9. 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 der neue Datenschlüssel von dem Wertübertragungszentrum (Postage Point) an das zentrale Entgeltsicherungssystem übertragen wird.
10. Verfahren nach Anspruch 9, d a d u r c h g e k e n n z e i c h n e t, dass das WertübertragungsZentrum den Datenschlüssel mit einem TransportSchlüssel (KT) verschlüsselt.
11. Verfahren nach Anspruch 10, d a d u r c h g e k e n n z e i c h n e t, dass der Transportschlüssel mit einem Master-Transportschlüssel (KTM) verschlüsselt wird.
12. Verfahren nach einem oder mehreren der Ansprüche 9 bis
11, d a d u r c h g e k e n n z e i c h n e t, dass der Datenschlüssel im Bereich des WertübertragungsZentrums erzeugt wird.
13. Verfahren nach einem oder mehreren der Ansprüche 9 bis
12, d a d u r c h g e k e n n z e i c h n e t, dass der Datenschlüssel mit einer Schlüsselidentifikationsangabe versehen wird.
14. Verfahren nach Anspruch 13, d a d u r c h g e k e n n z e i c h n e t, dass die Schlüsselidentifikationsangabe verschlüsselt übertragen wird.
15. Verfahren nach einem oder mehreren der Ansprüche 9 bis 14, d a d u r c h g e k e n n z e i c h n e t, dass der Datenschlüssel mit einem Generationszähler versehen und/oder gemeinsam mit dem Generationszähler übertragen wird.
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 der Datenschlüssel an ein kryptographisches Element, insbesondere eine Krypto- Karte, übermittelt wird, und dass das kryptographische Element nach Erhalt des Datenschlüssels alle Datenschlüssel löscht, die den gleichen Wert des Generationszählers wie der übertragene Datenschlüssel aufweisen.
17. Verfahren nach einem oder mehreren der Ansprüche 9 bis 16, d a d u r c h g e k e n n z e i c h n e t, dass der Datenschlüssel mit einem Verfallsdatum für den vorangegangenen Datenschlüssel versehen und/oder mit dem Verfallsdatum übertragen wird.
18. Verfahren nach Anspruch 17, d a d u r c h g e k e n n z e i c h n e t, dass der Freimachungsschlüssel an ein kryptographisches Element übermittelt wird und dass das kryptographische Element überprüft, ob andere Datenschlüssel ein Verfallsdatum aufweisen und ob das bei dem Nachfolge-Datenschlüssel gespeicherte Verfallsdatum älter ist als ein in dem Entgeltsicherungssystem gespeichertes Datum.
19. 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 der Datenschlüssel oder wenigstens ein Teil des Datenschlüssels einen Bestandteil eines
Freimachungsschlüssels für die Erzeugung der Freimachungsvermerke bildet .
EP04703745A 2003-02-12 2004-01-21 Verfahren zum überprüfen der gü ltigkeit von digitalen freimachungsvermerken und vorrichtung zur durchführung des verfahrens Withdrawn EP1604336A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10305730A DE10305730B4 (de) 2003-02-12 2003-02-12 Verfahren zum Überprüfen der Gültigkeit von digitalen Freimachungsvermerken
DE10305730 2003-02-12
PCT/DE2004/000083 WO2004072911A1 (de) 2003-02-12 2004-01-21 Verfahren zum überprüfen der gültigkeit von digitalen freimachungsvermerken und vorrichtung zur durchführung des verfahrens

Publications (1)

Publication Number Publication Date
EP1604336A1 true EP1604336A1 (de) 2005-12-14

Family

ID=32797351

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04703745A Withdrawn EP1604336A1 (de) 2003-02-12 2004-01-21 Verfahren zum überprüfen der gü ltigkeit von digitalen freimachungsvermerken und vorrichtung zur durchführung des verfahrens

Country Status (16)

Country Link
US (1) US7580529B2 (de)
EP (1) EP1604336A1 (de)
JP (1) JP2006527512A (de)
KR (1) KR20050101543A (de)
CN (1) CN100585643C (de)
AU (1) AU2004211020B2 (de)
BR (1) BRPI0407431A (de)
CA (1) CA2514020A1 (de)
DE (1) DE10305730B4 (de)
IL (1) IL170246A (de)
MX (1) MXPA05008506A (de)
NO (1) NO20053932L (de)
NZ (1) NZ541371A (de)
RU (1) RU2333534C2 (de)
UA (1) UA84861C2 (de)
WO (1) WO2004072911A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104301332A (zh) * 2014-10-31 2015-01-21 成都卫士通信息产业股份有限公司 一种基于无线级联的密钥分发系统

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1379968A2 (de) * 2001-02-23 2004-01-14 United States Postal Service Systeme und verfahren zum ausgeben von briefmarken
US20060101310A1 (en) * 2004-10-22 2006-05-11 Nimrod Diamant Device, system and method for verifying integrity of software programs
US7912223B2 (en) * 2006-09-29 2011-03-22 Hitachi, Ltd. Method and apparatus for data protection
DE102007052458A1 (de) * 2007-11-02 2009-05-07 Francotyp-Postalia Gmbh Frankierverfahren und Postversandsystem mit zentraler Portoerhebung
JP2010220019A (ja) * 2009-03-18 2010-09-30 Panasonic Corp 鍵管理方法および鍵管理装置
US9177281B2 (en) 2010-03-18 2015-11-03 United Parcel Service Of America, Inc. Systems and methods for a secure shipping label
US8995667B2 (en) * 2013-02-21 2015-03-31 Telefonaktiebolaget L M Ericsson (Publ) Mechanism for co-ordinated authentication key transition for IS-IS protocol
US10861025B2 (en) * 2018-03-02 2020-12-08 Capital One Services, Llc Systems and methods of photo-based fraud protection
US20210051002A1 (en) * 2019-08-15 2021-02-18 F5 Networks, Inc. Accessing Security Hardware Keys
US11682010B2 (en) * 2021-06-03 2023-06-20 Fidelity Information Services, Llc Systems and methods for executing real-time reconciliation and notification of electronic transactions

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS60183842A (ja) * 1984-03-02 1985-09-19 Toshiba Corp 伝送方式
JP2574279B2 (ja) * 1987-03-09 1997-01-22 松下電器産業株式会社 暗号化情報処理方式
US5150408A (en) * 1991-02-27 1992-09-22 Motorola, Inc. Key distribution communication system
US5150508A (en) * 1991-06-28 1992-09-29 E. R. St. Denis & Sons, Limited Hemming machine and method
US5729608A (en) * 1993-07-27 1998-03-17 International Business Machines Corp. Method and system for providing secure key distribution in a communication system
US5481613A (en) * 1994-04-15 1996-01-02 Northern Telecom Limited Computer network cryptographic key distribution system
US5812666A (en) 1995-03-31 1998-09-22 Pitney Bowes Inc. Cryptographic key management and validation system
JPH09319673A (ja) * 1996-05-27 1997-12-12 Matsushita Electric Works Ltd 暗号鍵更新方法およびそのシステム
US5748736A (en) * 1996-06-14 1998-05-05 Mittra; Suvo System and method for secure group communications via multicast or broadcast
US5982896A (en) * 1996-12-23 1999-11-09 Pitney Bowes Inc. System and method of verifying cryptographic postage evidencing using a fixed key set
US6820065B1 (en) * 1998-03-18 2004-11-16 Ascom Hasler Mailing Systems Inc. System and method for management of postage meter licenses
DE19816344C2 (de) * 1998-04-01 2000-08-10 Francotyp Postalia Gmbh Verfahren zur sicheren Schlüsselverteilung
JP3726259B2 (ja) * 1999-02-18 2005-12-14 日本電信電話株式会社 公開鍵証明証の有効性確認方法、公開鍵証明証の有効性確認装置における利用者側装置、および公開鍵証明証の有効性確認プログラムを記録した記録媒体
AU767180B2 (en) * 1999-08-31 2003-11-06 Motorola Solutions, Inc. Key management methods for secure communication systems
US20020018571A1 (en) * 1999-08-31 2002-02-14 Anderson Walter F. Key management methods and communication protocol for secure communication systems
US7089211B1 (en) * 2000-01-12 2006-08-08 Cisco Technology, Inc. Directory enabled secure multicast group communications
US7231517B1 (en) * 2000-03-03 2007-06-12 Novell, Inc. Apparatus and method for automatically authenticating a network client
DE10020402C2 (de) * 2000-04-27 2002-03-14 Deutsche Post Ag Verfahren zum Versehen von Postsendungen mit Freimachungsvermerken
JP2002290396A (ja) * 2001-03-23 2002-10-04 Toshiba Corp 暗号鍵更新システムおよび暗号鍵更新方法
DE10131254A1 (de) * 2001-07-01 2003-01-23 Deutsche Post Ag Verfahren zum Überprüfen der Gültigkeit von digitalen Freimachungsvermerken
DE10150455A1 (de) * 2001-10-16 2003-04-24 Deutsche Post Ag Verfahren und Vorrichtung zum Bearbeiten von Postsendungen

Non-Patent Citations (1)

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

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104301332A (zh) * 2014-10-31 2015-01-21 成都卫士通信息产业股份有限公司 一种基于无线级联的密钥分发系统
CN104301332B (zh) * 2014-10-31 2017-10-27 成都卫士通信息产业股份有限公司 一种基于无线级联的密钥分发系统

Also Published As

Publication number Publication date
NZ541371A (en) 2008-12-24
KR20050101543A (ko) 2005-10-24
DE10305730A1 (de) 2004-09-02
DE10305730B4 (de) 2005-04-07
US20060190732A1 (en) 2006-08-24
WO2004072911A1 (de) 2004-08-26
CN1748231A (zh) 2006-03-15
US7580529B2 (en) 2009-08-25
RU2333534C2 (ru) 2008-09-10
NO20053932L (no) 2005-08-23
MXPA05008506A (es) 2005-10-20
AU2004211020A1 (en) 2004-08-26
CN100585643C (zh) 2010-01-27
CA2514020A1 (en) 2004-08-26
JP2006527512A (ja) 2006-11-30
IL170246A (en) 2010-06-16
AU2004211020B2 (en) 2009-04-09
BRPI0407431A (pt) 2006-01-24
UA84861C2 (ru) 2008-12-10
RU2005123803A (ru) 2006-03-27

Similar Documents

Publication Publication Date Title
EP0944027B1 (de) Frankiereinrichtung und ein Verfahren zur Erzeugung gültiger Daten für Frankierabdrucke
DE69433466T2 (de) Verfahren und Vorrichtung zum Ändern eines Verschlüsselungsschlüssels in einem Postverarbeitungssystem mit einer Frankiermaschine und einem Überprüfungszentrum
EP0892368B1 (de) Verfahren zur Statistikmodusnachladung und zur statistischen Erfassung nach Statistikklassen bei der Speicherung eines Datensatzes
DE69932396T2 (de) Verfahren und Vorrichtung zur sicheren Schlüsselübertragung zwischen einer Frankiermaschine und einer entfernten Datenzentrale
WO2003005307A1 (de) Verfahren zum überprüfen der gültigkeit von digitalen freimachungsvermerken
EP1615173A2 (de) Verfahren und Anordnung zum Generieren eines geheimen Sitzungsschlüssels
WO2006111135A1 (de) Verfahren zur schlüsselverwaltung für kryptographiemodule
DE10305730B4 (de) Verfahren zum Überprüfen der Gültigkeit von digitalen Freimachungsvermerken
DE19816344C2 (de) Verfahren zur sicheren Schlüsselverteilung
DE10056599C2 (de) Verfahren zum Versehen von Postsendungen mit Freimachungsvermerken
EP0969420B1 (de) Verfahren zur sicheren Übertragung von Dienstdaten an ein Endgerät und Anordnung zur Durchführung des Verfahrens
DE60015907T2 (de) Verfahren und Vorrichtung zur Erzeugung von Nachrichten welche eine prüfbare Behauptung enthalten dass eine Veränderliche sich innerhalb bestimmter Grenzwerte befindet
EP1807808B1 (de) Verfahren und vorrichtung zum frankieren von postsendungen
EP1279147B1 (de) Verfahren zum versehen von postsendungen mit freimachungsvermerken
EP1340197B1 (de) Verfahren zum versehen von postsendungen mit frankierungsvermerken
DE10020561A1 (de) Sicherungsmodul und Verfahren zur Erstellung fälschungssicherer Dokumente
EP2439902A2 (de) Verfahren und Anordnung zum rechtsverbindlichen Senden und Empfangen von vertraulichen elektronischen Mitteilungen
EP1222512B1 (de) Sicherungsmodul und verfahren zur erstellung fälschungssicherer dokumente
EP1486028B1 (de) Verfahren und vorrichtung zur erstellung prüfbar fälschungssicherer dokumente
WO2024012624A1 (de) Verfahren zur sicheren generierung eines herausgebbaren tokens, verfahren zur sicheren vernichtung eines tokens und tokenherausgeber

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: 20050912

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1077114

Country of ref document: HK

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20100127

REG Reference to a national code

Ref country code: HK

Ref legal event code: WD

Ref document number: 1077114

Country of ref document: HK

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20120607