CA2514020A1

CA2514020A1 - Method for verifying the validity of digital franking notes and device for carrying out said method

Info

Publication number: CA2514020A1
Application number: CA002514020A
Authority: CA
Inventors: Peter Fery; Jurgen Helmus; Gunther Meier; Dieter Stumm; Carsten Vullriede
Original assignee: Individual
Current assignee: Deutsche Post AG
Priority date: 2003-02-12
Filing date: 2004-01-21
Publication date: 2004-08-26
Also published as: DE10305730B4; IL170246A; EP1604336A1; AU2004211020A1; CN1748231A; MXPA05008506A; JP2006527512A; KR20050101543A; DE10305730A1; CN100585643C; RU2333534C2; WO2004072911A1; RU2005123803A; NZ541371A; NO20053932L; US7580529B2; US20060190732A1; AU2004211020B2; UA84861C2; BRPI0407431A

Abstract

The invention relates to a method for verifying the authenticity of a franking note that is created by using a franking key and is applied to a piece of mail. Cryptographic data which is contained in said franking mark is decoded and is used for verifying whether the franking mark is authentic. The inventive method is characterized in that a new franking key is generated and is transmitted to local fee-securing systems (ZinS-lokal) by a central database (ZinS Zentral-System).

Description

1~THOD ~'OR VERIFYING THE VALIDITY
OF DIGITAL, FRANKING NOTBS
Description:
The invention relates to a method for verifying the authenticity of a postage indicium generated using a franking key and app~.ied onto a mailpiece, whereby cryptographic information contained in the postage indicium is decrypted and used for verifying the authenticity of the postage indicium.
It is a known procedure to provide mailp~.eces with digital postage indieia.
Zn order to make it easier for the senders of the mailpieces to p.rcduee postage indieia, it is possible, for example, with the franking system used by the Deutsche Post AG, t,o produce postage indicia in a customer system and to output them on a printer via any desired interface.
A method of this generic type is disclosed in German Preliminary Published Application 17E 100 20 402 A1.
In order to avoid fraudulent use of this method, the digital postage indicia contain cryptographic information, for example, about the identity of the customer system that controls the production of the postage indicium.
International patent application WO 01/17160 A1 relates to a method for the distribution of keys in which keys are Z
generated by a central management unit arid are transmitted in encrypted farm by a distribution unit to encryption devices.
These devices send a message about the successful or failed receipt of a key via the distribution unit to the management unit. Tf it was nat possible to receive the key successfully, it is ante again transmitted in unencrypted form to the appertaining encryption device.
European patent application EP 0 8S4 444 A~ discloses a method for encrypting and checking postage indicia that are produced with a franking machine. Here, additional keys are derived from a master key implemented in the franking machine and they are used for producing postage indicia. In a mail center, the additional keys are likewise generated and used for checking the postage indicia.
U.S. Pat. No. 5,150,408 discloses a method for key distribution in a communication system such as, for example, a wireless network, in which an encrypted message is transmitted to a communication device by a key distribution unit. After this message has been received, the communication device sends a confirmation to the key distribution unit.
The known standard ANSI X9.17 for the transmission of encrypted data (see UR1;, http://csrc.nist.gov/~ublications/nystpubs/800-7/node209.htm1 dated October 7, 1994) is based on a key hierarchy of several. keys. Here, at least one data key exists for encrypting data having a short lifetime, which is exchanged electronically and in encrypted form between communication partners as well as a key for encrypting the data key, which is exchanged manually. Moreover, the cited document describes the known Diffie-Hellmann method for encrypting data in which the communication partners compute a shared key from known numbers and from a secret random number.
Eurppean patent application EP 0 735 722 A2 describes a key management system fox generating, distributing and managing keys for franking machines. Here, there are several secure areas that are connECted to computers that allow communication among the areas as well as control of the areas. The generation of keys, their installation and their verification and canfixmation are each carried out in one of the secure areas. Each area is associated with an archive in which the status of the area is protocolled.
The invention is based on the objective of creating a method with which the authenticity of the postage indicia can be verified quickly and reliably. In particular, the method should be suitable for use in verification procedures on a large scale, especially in maix centexs or freight centers.
According to the invention, this objective is achieved by a method according to Claim 1.
In particular, it is provided that the method ~or verifying the authenticity is carried out in such a way that a data key is generated and transmitted from a central database (ZinS central system) to local payment assurance systems (~xnS local). This is done by using a generated franking key and a postage indiGium applied onto a mailpiece, whereby cryptographic information contained in the postage indicium is decrypted and used to verify the authenticity of the postage indicium.
In order to increase the security of the method, it is advantageous for the local payment assurance systems to IU import the data key and to transmit a result of the import to the central database (ZinS central system).
In an especially advantageous embodiment of the method, the result of the import is transmitted as a data record.
Preferably, the data record contains a key. the key can have various attributes. In particular, it can be either a symmetrical key or an asymmetrical key. Depending on the intended use, the key serves to decrypt and/or encrypt information. By virtue of its nature, the key can likewise transport information, Por example, the key contains information about the franking key, its key generation and/or its end date.
z5 zn order to ensure a uniform key exchange, it is advantageous for the central database (ZinS central system) to check the result o~ the import and to transmit it to a value transfer center (Postage Point)-This embodiment of the method makes it possible to carry out further process steps in the value transfEr center as a function of the result of the ~.mpart.
The result can be checked in various ways. i~awever, it is especially advantageous for the result to be checked by decryption of the key.
A preferred embodiment of the method is characterized in that, once the data key has been successfully imported into essentially all local payment assurance systems (ZinS local) , the data key is released as a new franking key at the vaJ.ue transfer center (Postage Point) and is subsequently used for producing new postage indicia.
This embodiment of the method makes it possible to carry out a key exchange in the value transfer center as a function of previously performed key exchanges in the payment assurance systems. This measure ensures that postage indicia will only be produced using the new key once the new key is already present in the local payment assurance systems. This ensures that the local payment assurance systems can verify the validity of each of the pastage indicia produced.
This especially preferred embodiment of the method with a control of the key exchange in the value transfer center as a function of the key exchanges in the local payment assurance systems is especially advantageaus in combination with at least some of the other process steps according to the invention.

Particularly, th~eough a combination of several fEatures, it is ensured that the key exchange can be performed quickly and reliably and that the execution o~ each lcey S exchange is verifiEd.
When the key exchange is performed, it is especially advantageous for the new data key to be transmitted from the vaJ.ue transfer Center (Postage Point) to the central payment assurance system.
Here, xt ~,s especially advantagEOUS for the value transfer center to encrypt the data key with a transport key (KT) .
Here, it is practical for the transport key to be encrypted with a master transport key (KTM).
Preferably, the data key is generated in the area o~ the 24 value transfer center. This has the advantage that fraudulent changes to the data key during its transport to the value trans~ex center are prevented.
Tn order to further increase the data security, it is advantageous for the data key to be provided with key identification information.
Advantageously, the key identification information is likewise transmitted in encrypted form.

In order to ensure that a valid data key is used for each of the encryption and/or decryption steps employed, it is advantageous for the data key to be provided with a generation counter and/or to be transmitted together with the generatxdn Counter.
In order to avoid the use of invalid keys, it is also advantageous for the franking key to be provided with an end date for the preceding data key and/or to be lU transmitted together with the end date.
The described data key can be used ~ox one ar more partial verifycations as well as for producing postage indicia and/or for decrypting information contained in the postage indicia.
It is especially advantageous ~or one of the partial verifications to comprise the decryption of cryptographic information contained in the postage indicium.
By integrating the decryption of the cryptographic information into the verification process, it is possible to ascertain the authenticity of the postage indicia directly so that the verification can be carried out in real time.
Moreover, it is advantageous for one of the partial verifications to comprise a comparison between the production date of the postage indicium and the current date. The integration of the production date of the postage indicium - especially in encrypted form -increases the data security, since multiple use of a postage indicium is prevented through the comparison between the production date of the postage indicium and the current date.
Tn order to further increase the verification speed, it is advantageous for the reading unit and the vErification unit to exchange information by means of a synchronous protocol.
~n another likewise advantageous embodiment of the invEntion, the reading unit and the verification unit communicate with each other via an asynchronous protocol.
Hexe, it is especially advantageous for the reading unit to send a data telegram to the verification unit.
Preferably, the data telegram contains the content of the postage indicium.
additional advantages, special features and practical refinements of the invention can be gleaned from the subordinate claims and from the presentation below of preferred embodiments making reference to the drawings.
The drawings show the following:
Figure 1 an especially preferred embodiment of a key distribution according to the invention;
Figure 2 application cases of a key distribution system according to the invention;

figure 3 a schematic diagram of an interface between a central payment assurance system (ZinS central system) and a value transfer center (Postage Point);
Figure 4 process steps far integrating a data key into the central payment assurance system (Zinc central);
Figure 5 a schematic diagram of a key distribution from the central payment assurance system (ZxnS
central system) to local payment assurance systems including the appertaining crypto-systems:
Figure 6 a connection of the D~~ interface;
Figure 7 a schematic diagram of process steps for encapsulating components and for handling error messages.
Belaw, the invention will be described with reference to a PC franking system. Here, the process steps that serve far payment assurance are independent of the system used for producing the postage indicia.
the described decentralized verification at individual verification stations, especially in mail centers, is especially preferred, but by the same token, centralized verification is also possible.

1~
In especially preferred embodiments o~ the invention, the individual verification stations are local payment assurance systems that are preferably connected to a central payment assurance system via a data connection.
In the especially preferred embodiments described, the central payment assurance system is also connected to a value transfer center.
especially preferred embodiments of the value transfer center are referred to below as a Postage Po~.nt.
Advantageous embodiments of the central payment assurance system are referred to below as ZinS central.
The techn~.cal. interface to be implemented between the value transfer center and the payment assurance system consists of an exchange of cryptographic keys.
The key that is to be exchanged between the value transfer center and the payment assurance system ensuxes that the produced postage indicia are forgery-proof. This is achieved especially in that part of the content of the 2D barcode that forms the postage indicium is encrypted using said key. Since, for performance-related reasons, the selected key is a symmetrical key, it has to be transmitted from the value txans~er center to the payment assurance system, where it is distributed to the individual. mail centers.
The reliable storage of the keys is ensured by using special crypto-cards. The invention encompasses several application cases in which these keys are managed using this special hardware. The entire life oycle df these keys, from their generation, their export and their distribution axJ. the way to their import into the S decentralized systems zs used in order to optimize the process paramEters.
An especially preferred sequence for the key distribution ~.s shown in FigurE 1.
Figure 1 shows an especially preferred key distribution between the value transfer center and the oentxal payment assurance system.
In a first process step 1 for an exchange of a franfc~.ng key used in the production of postage indicia, first of all, a new franking key is generated.
The term franking key here is by no means to be understood in a restrictive sense since the described keys can be used in different ways for producing postage indic~.a.
For example, it is possible to use the franking key directly fox producing postage indicia.
Howevex, it is likewise possible and especially advantageous ~or systems with an especially high security against manipulation to produce postage indicia with a 3Q multi-encrypted data content, whereby the data content is preferably formed as a result of sEVera1 operations, whereby at one or more places, the result of an operation is incorporated into the postage indicium with the franking key.
For example, a crypto-stzing of the type disclosed in German Preliminary Published Application DE 100 20 402 A7., is incorporated into the franking key.
In order to further improve the protection against a fraudulent production of postage indicia, an event-specific exchange of the franking key takes place.
In the presented case, the franking key is newly generated at regular intervals, for example, after the expiration of a pxedefinable time interval.
However, it is likewise possible to carry out a new generation of the franking key as a function of other parameters, for example, on the basis of the loaded postage amounts and/or of the xranked mailpieces.
As a matter of principle, a new generation of the new franking key can be carried out anywhere. However, in order to increase the data security, it is advantageous to minimize the transmission 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.
In order to ensure a high level of protection of the method against fraud, it is ad~rantageous for information contained in the postage indicia to be decrypted on the basis of a franking key in the area of local payment assurance systems, ~ar example, in mail centers or freight centers.
~n order to ensure this, the franking keys are transmitted from the value transfer center to the central payment assurance system. Preferably, the transmission is automated, The exchange is preferably effectuated via a server of the payment assurance system (ZinS central server). The value transfer center (Postage Point? does not have to be configured. Since the server does not have to know the value transfer center (ZinS local systerns~ arid its appertaining crypto-systems, exclusively the ZznS central server is of importance for said server.
After the new generation of a preferably symmetrical franking key, the latter is securely transmitted to the central payment assurance system - process step 2 in Figure Z - and distributed from there to the crypto-systems located in the local payment assurance systems -process step 3 in Figure 1. The local payment assurance systems return the result of the import operation -process step 4 in Figure 1 - and thus confirm the successful key import. The result is compiled by the central system, validated arid transmitted to the value transfer center (Postage Point) - process step 5 in Figure 1.

pnce the key has been successfully impaxted into all of the crypf,o-systems of the local payment assurance systems, it xs released at the value transfer center (Postage paint) and subsequently used for the generation of new S postage amounts - process step 6 in Figure 1.
The preferabJ.y symmetrical keys are an integral part of the forgery security of postage i~nd~.cxa produced using the franking key, whereby said postage indicia axe, far example, in the faz~m of two-dimensional barcodes. Thus, the exchange of these keys has to be secuxed by strong cryptography. In order to Ensure this, adherence to the following points is especially important:
~ Confidentiality of the content: it must not be possible fax third parties to read out the transmitted keys during the transmxssi.an. Moreover, it must also be ensured that the keys are securely stared and cannot be read out by third parties.
fhe latter functionality is ensured by the Web-Sentry crypto-card.
~ Integrity of the content: it must not be pass~.ble for third parties to forge parts o~ the key.
~ Authentication: both communication partners must be certain that the identity of the sender/recipient is correct. From the viewpoint of the x~eczpient, this means that the kEy was generated by the Postage Paint.. From the viewpoint of the sender, it must be ensured that only valid IS
ZinS local crypta-systems axe allowed to receive the key.
Tn the symmetrical method presented, both communication partners have the same key KT. The value transfer center (Postage Point) uses the key KT tv encrypt the data key K17 that is to be transmitted and then transfers said data key KD to the sexve~r of the payment assurance system (ZinS central system).
is From the central payment assurance system, this key is then further distributed to the ZinS laca~. crypto-systems of the local payment assurance systems. These systems likewise have access to the key KT and can thus decrypt the key Kp once again. Since the key K'~ is used to securely protect the key KD during the transport, it is also referrEd to below as the transport key.
Since all local payment assurance systems receive the same data, it is riot necessary to define a separate transport key KT between each local cxypto-server and the value transfer center (hostage Point). For secux~i.ty reasons, however, this key KT should be renewed like the data key KD at regular intervals. However, since not as 2~ much text is encrypted with this key as with the key KD, a longer exchange interval can be selected. An exchange interval of one or two years is especial~.y advantageous here.
An Essential component of this approach is the key exchange of the transport keys KT which, for security reasons, should not take place via the same channel as the exchange of the data keys KD. This exchange is not carried out manually. Since this procedure has to be carried out at regular intervals for several of the local payment assurance systems, another method has to be provided here, by means of which the exchange of the transport keys can likewise be automated.
For this purpose, the RNST standard X9.17 (Key Management fox Financial Services on the basis of symmetrical methods) defines anothex key level that is referred to as the master transport key (referred to below as KTM). This key has to be installed on the crypto-card under special security precautions and consequently only has to be exchanged at extended intervals. Mere, the same KTM is installed on al.~. systems. This key then encrypts the transport keys KT that are thexeby distributed and imported in an automated manner via the same channel. The distribution takes place in the same way as the distribution of the data keys, The initialization of the individual systems or of their crypto-cards is described ~.n greater detail in the sections below.
In order to ensure the integxi.ty of the message as well as the authentication of the sender (- Postage Point), a matrix code (MAC? is formed for the individual key messages. In order to generate the MAC, the signature key KS is needed which, like the KTM, is imported duxing the initialization of the crypto-card. The signature of the data key messages i,s subsequently carried out with this KS. The confident~.al~.ty of the information during the transmission of the messages in the Intranet of the Deutsche Ppst is thus secured through the use of this strong cryptpgraphic method. An especially preferred method for the encryption and decryption of messages is Triple DDS (key length 16$ bits). Hash values are preferably computed by means of the SHA-1 algorithm.
The various periods of validity that exist at the Postage Point and on the crypto-systems of the payment assurance systems have to be taken into account for the distxibutipn and storage of the data keys. A maximum of two keys KD have to be available at the Ppstage Point at any given point in time, namely, pne key that is currently valid and another key with which newly generated postage arnpunts are to be encrypted (KOnew).
In the 'exchange' mode of opexatipn of the existing key with the key (KDnew), the new key is transmitted to the crypto-systems of the payment assurance systems. Once 2U this key has successfully been impprted by all of the crypts-systems of the local payment assurance systems, a release message of the ZinS central system is generated and, as of this point in time, KDneW is used for the encryptipn of new postage amounts in the Postage Point.
As of this point in time, the old KD should be deleted from the Postage Paint and should not be used any more far the generation of new postage amounts.
The situation is different with the crypto-systems of the 34 local payment assurance systems: since a downloaded postage amount can be used for a predefinable period of time of, for example, three months, in order to produce postage indicia, there are several keys 1CD that have to be available for verifying the postage indicia.
S Moreover, when it comes to the distribution of the keys, it should also be taken into consideration what happens to keys that could not be imported into some of the cx~ypto-systems and could therefore not be activated at the Postage Point. It is possible that these keys were imported into other crypto-systems and, as a matter of princip~.e, should be taken into consideration there during future verifications.
In order to reach a uniform condition here, which allows 1S a clear versioning of the keys as well as the simplest possible system maintenance, the foJ.lawing execution form of the method of key distribution is especially advantageous:
a) Data keys are transmitted in encrypted form with an unambiguous key TD (key phase indicator), an ambiguous generation counter and an end date for the valid preceding data key.
The generation counter serves to distinguish erroneous mu~.tiple loading attempts from desired updates of the symmetrical data keys (ensuring transaction security, see g)).
b) Each transmission of a data key from the value transfer center (Postage Point) should be acknowledged by the central payment assurance system by means of a confirmation message.
c) If the acknowledgement is positive, the data key has been successfully installed in all J.ocal payment assurance systems and can be issued to the customers using pC franking.
In this case, the generation counter is increased by one for the transmission of a succeeding data 1Q key.
d) If the acknowledgement is negative, the data key has not been successfully installed in all local payment assurance systems and should riot be issued by the value transfer center to customer systems meant for the production of postage indicia, since othexwzse there is a risk of a mass diverting of valid mailpieces.
In this case, the generation counter is not inGxeased by ane for the transmission of a succeeding data key, that is to say, it remains at the value of the preced~.ng transmission.
e) Tf there is no acknowledgement, in the interim, the value transfer center (Postage Point) cannot start any further key transmission to the Central payment assurance system (ZinS central) (such attempts would, of Course, be ignored by the payment assurance system, but should also be blocked in the value transfer center), f) If an acknowledgement by the payment assurance system ~.s absent for a prolonged period of time (time-out exoeeded), then the value transfer cen-ter (Postage Point) can txigger an alarm via its 5 direct or indirect user interface.
g) As soon as a crypto-card receives a data key, it deletes all of the data keys that have the same generation saunter value as the mast recent 10 transmission. This ensures that, in case of error-related multiple transmission, keys that could previously aniy be suGCessfully loaded onto same of all of the crypto-cards are deleted. This allows a transactzon--secure key transmission.
h) On the crypto-cards in the J.acal payment assurance systems, a routine is invoked repeatedly, preferably regularly, especially daily, that deletes the data keys that are na longer nEeded. 1~
data key is deleted (in an advantageous embodiment in addition to Paint g)) when the end date stoxed for the succeeding data key in the CKA END_DAfE
attribute is smaller than the current system date.
2S i)When it comes to the end date of the preceding key, a grace period (as short as passibXe) should be planned s~.nce postage indicia produced with an Expired postage amount are still recognized as being valid for two more days after the end of their validity when they are checked i.n the area of the local payment assurance system. Moreover, a time-lag between the production and the release of the new data key also has to be taken into account.
Figure 2 shpws an overview of areas of application of the presented key management and its use in the area of payment assurance. Moreover, preferred areas of application are presented.
The application cases are described in greater detail below _ Subsequently, details about the described key management method will be presented.
The described applications axe presented by way of an example w~.th the use of crypto-cards.
First of all, the way in which the crypto-cards are initialized in the area o~ the value transfer center is presented:
~ installation and configuration of the card, uploading the card firmware, insofar as the manufacturer has not already done so. The functionality of the firmware was expanded by embedded code (proprietary software routinesy and, for security reasons, the PKCS#~.~.-specific (Public-Key Cryptography Standards) key routines (generation, deletion, etc.) should be blocked for the user. Thus, a higher key seourity is ensured on the card.

~ definition o~ clusters (with several crypto-cards) ~ Generation and storage o~ a local master key LMK.
S The LMK should be distributed avex at least three components o~ which two components are especially advantageaus for recreating or newly initialising crypto-server cards. Preferably, each of the components is written anto SmartCards with PIN
protection, whereby the security administrators receive a SrnartCard. In addition, backup SmartCards should also be made. Subsequently, the LMK Serves as the above-described master transport key KTM.
~ user administration: deletion of the default security administrator and definition o~ the security administrators including the requisite authentication rules (SmartCard-based) ~ generation of an initial signature key KS, encryption (wrapping) with the KTM and storage as a file. The later copying of this file onto a dzskette should be possible (access to the file/diskette should only be possible for the security administrators).
~ generation of a ~xrst transport key KT, creation of the appertaining key message and storage of the message in a file as well as later copying of this file onto a diskette (access should only be possible for the security adm~.nistrators).
Generating the transport master keys S
New transport master keys (KTM) are preferably generated in the manner described below. The local master key (LMK) of an appertaining confirmation card serves as the KTM.
For security reasons, the FMK should be divided into at least three components, of which at least two components are needed for re-importation.
The individual components axe stared on SrnartCards, whereby each sECUrity administrator receives a SmartCard and secures it with an individual PIN. Keeping the PIN
secret and storing the SmartCards in a safe place is to prevent unauthorized persons from being able to access them.
In order to implement the transport master keys, there are preferably at least two T,MK components -corresponding to two diffErent authorization cards - so that an automated implementation of a dual control principle is carried out.
The K'~M has to be a Triple DES kEy. The TD attribute of the key consists of a type identification and an unambiguous number.
Type a.dentification: KT
Unambiguous number: 07. to 99.

~4 Length: fix Q bytes is filed as CK CHARL ].
As a matter of principle, various security mechanisms are suitable far ensuring that only authorized persons are able to carry out an exchange of the keys. The embodiment described below using signature keys, however, is particularly advantageous since it accounts far especially high security against manipulation.
The signature key secures the integrity of the key messages. It can also be used before the import of the key to ascertain whether the sender of the key messages is the postage Point. ThE generation of the signature key should only be possible by a security administrator who is registered via a SmartCard. This should be a TDES key that has the security attributes 'sensitive' set to TRUE
and 'extractable' set to FALSE in oxder to prevent the key plain text from being discovered outside o~ the card.
The TD attribute o~ the key consists of a type identification and an unambiguous number.
Type identification: KS
Unambiguous number: 01 to 99.
Length: fix 4 bytes is filed as CK CHARS ].
In order for the key to be exported, it has to be wrapped with the KTM and it is then stored as a file an a diskette. The diskette has to be kept in a secure place and serves for the ~.nitiali~ation of the crypto-server cards. The integrity of the key file is ensured by a ~S
processing routinE preferably stored in the cards that is used ~ox the wrapping.
Preferred attributes of the transport key KS are compiled in the following table.
Attributes of the trar~spor~ key KS

KeyAttr3bute Velum CKA ID KS + consecutive unambiguous numbEr (KSO1 to KS99) for unambiguous designation of the key.

CKA Is not filled, corresponds LABEL

_ to the default value of the hardware at the time of the generation.

START Date as of which the key DATE is CKA

_ supposed to be va lid in _ the PKCS#7.~. format (is specified by the security admxni,strator) CKA_END_DATE Date aftEr which the preceding key is to be deleted.

CKA SENSITIVE TRUE

CrCA EXTRACTA$hE FALSE

CKA ENCRXPT TRUE

CKA DECRXPT TRUE

The random number in the LABEL attribute serves to confirm the successful import into the crypto-server ld GardS. A hash value (for example, by means o~ SHA-1) is formed fox this random number and it is used for confirming the successful import as well as for releasing the transport key.

z~
The GKA ID and CKA LABEh attributes are to be filled as CK CHAR. A1~. further attributes are defined xn the type via the pkcsll . h f i7.e .
The signature kEy is encrypted with the KTM (=LMK, CKM KEY WRAP WEBSENTRY mechanism) and is upXoaded onto the hardware on site like the LMK.
The generation o~ the transport key will be described below.
Tn this application case, a transport key including the appertaining key message is generated. Preferably, the key generation module is configured in such as way that the generation of the transport key and/or of the appertaining key message can only be initiated by a security administrator. The exchange interval should be one or two years.
zo The transport key, in turn, is a T17ES key with the following attribute settings:
Attribu~ea of the transport ksy KT

I~c~yAttribute Value I1~ KT + consecutive unambiguous CKA

_ number (KTO1 to KT99) for unambiguous designation o the key.

LAHEL Random value having the CKA

, length of 64 bytes that was enerated usin the PKCS#I1 C Generate~tandom method.

CIiADATE Date as of which the key START is _ _ supposed to be valid in the ~KGS#11 format (is specified by the security administrator) ~KA END Date after which the DATE

_ _ preceding key is to be deleted.

GKA SENSrTTVE TRUE

CKA EXTRACTABLE FALSE

CKA ENCRYP'1 TRUE

CKA DECRYPT TRUE

The random number in the LABEL attribute serves to confirm the successful import into the crypto-server Cards. A hash value (for example, by means of SHA-1) is foxrned for this random number and it is used for confirming the successful import as well as for releasing the transport key.
The GKA ID and CfCA LABEL attrib~xtes are to be filled as 14 CK CHAR [ ]. All further attributes are defined in the type via the pkcs~.~..h file.
The transport key is encrypted with the KTM (=LMK, CKM KEY WRAP WEBSENTRY mechanism) and a message having the following structure is formed for the transmission from the value transfer center to the central payment assurance system:
Iteut ~rigt Hyde no. Desigxta~ivn Description h 1 2 fl - f2 MsgType Identification of the key message, constant 'KT' 2 1 f3 Version Version of the structure of the message, 1 byte starting with the value 'al' 3 4 f4 - f8 KeyTD ID of the transport key in plain text 4 4 f9 - f12 SigKEyID ID of the key used for the signature n-~.3 f13 - f"1 TranspKeyEncr Result of the ypt encryption (wrap) of the transport ke y 6 24 fn+1 - MAC MAC far the key fn+z4 message; is farmed in that an SHA-1 hash value is formed ox the Fields 1 to 5 of the message, and this hash value is encrypted with the signature key D~S~ CBC_PAD
(CKM

_ mechanism, the IV

xs filled up with zeros; ID see field 5).

Subsequent to the further distribution, this transport key message is transferred to the ZinS central server.
The interface is realized as a Session Bean, this service 5 is looked up by means of a naming service (Java Laming and Dix~eatary Interface - J'NDI), The method far the transport should expect the above-mentioned data block.

z~
Moreover, the message is stored at the Postage Point as a file sa that the security administrators can later store it onto one or more diskettes that are to be kept zn a safe place. The diskettes are then used for the in~.tialization of new crypta-server cards.
A preferred embodiment for releasing the transport key will be explained below.
The rralue transfer center is canfiguxed in such a way that i.t can release the transport key K'f. In order to release the transport key KT, there is an interface via which the central value transfer center can release this transport key onoe it has successfully been distributed and successfully imported into all local payment assur-ance systems (ZinS crypto-systems). Qnly through the release is the appertaining transport key used subsequently for the encryption of data keys (KD).
za The izltex~ace is realizEd as a Session Sean. This sezviCe is looked up by means of a naming servyce.
The data structure for the releas~.ng procedure preferably has the Following parameters:
Item ,Lex~g~~y~~ aa. Dea~gnatian Descriptiaa h 1 4 f1 - f9 ~CeyxD ID of the transport key in plain text 2 201 f4 - f24 RandomHash SHA-1 hash value of the random number that was transferred as the LABEL

attribute of the transport key 3 1 f2a State Result of the encryption:

true = processing necessary, re~.ease can take place false =

processing not successful 4 128 f26 - Message Detailed message f153 about the error ...

causes, ox detailed success message The authentication of 'the key allocation system of the payment assurance system (Z~.nS KeyManagement system) vis-~-vis the PP KeyManagement system ~.s carried out via Parameter 2. This is a hash value that is formed using the SHA-1 method from the LABEL attribute of the transport key. The LABEL attr~.bute is filled with a random value at the time of the generat~.on o~ the transport key. S~.nce the transport key and all of its lU attributes are encrypted during the transmission, only the Z~.nS crypto-server can compute the correct hash value.
If the transmitted hash value is identical to the hash value of the KT computed for the LABEL attribute, whereby l5 said hash value is located on the Postage Poxnt WebSentry module, and if the transmitted processing status = true, then the transport key is activated. This means that subsequently, the data key messages are encrypted with the transport key.
S A var~.ant of this application case exists if the processing is erroneous (transmitted status = false). In this case, the status for this key generation and key distribution is protoCOlled and the appertaining transport key is deleted accordingly.
to ~1 preferred example of a generation of new data keys is shown below.
In this application case, a data key including the 15 appertaining key message ~.s generated. Preferably, the key allocation system is configured in such a way that thys action can only be initiated by a sECUrity administrator. This should be donE every three months. If a data key KD is in circulation for which no feedback 20 (release or error) has yet been received from the central payment assurance system (ZinS central system), then the generation of new KDS is blocked until the ~eedback has been received.
25 The data key (KD) serves for the encryption of certain matrix Gode contents and also ensures that na valzd postage indicia can be produced for which no payment has been made to the postal service provider. xhis data key serves to verify the digital postage indicia at the ZinS
30 crypto-servers. The data keys are likewise TDES keys that are generated using the PKCS#11 function C GenerateKey and that have the following attributes:
Attributes of the data key I~

~eyAttrabute Value ID Consecutive unambiguous CKA

_ number (e.g. O1) for unambiguous designation of th,e key (without a prefix) corresponds to the key phase indicator that is encoded xn the postagE indicium and in the PostagelD.

LABEI, fist Byte: Generation counter CKA

_ for simplified deletion of keys in the ZinS crypto-systems that could not be activated Bytes 2-65: random value having the length of 64 bytes that was generated using the PKCS#11 C GenerateKey method.

START Date as of which the key is DATE
CKA

_ supposed to be vaxid in the _ PKCS#11 format (is filled with the current date) CKA_END_DATE Does not indicate the end of the vala.dity of the key itself but rather the end o the validity of the predecessor. The date after which the preceding key is to be deleted.

CKA SENSITIVE TRUE

CKA EXTRACTABLE FALSE

CKA ENCRYPT TRUE

CKA DECRYPT TRUE

The values for the CKA rn attribute and the generation counter are prescribed by the system. 'Ihe CKS-III is always counted upwards by one, whereas the generation counter is only inGxeased when the key release has been successful. The CKA ID and CKA LABEL attributes are to be filled as CK CHAR [ ]. All further attributes are defined in the type via the pkcsll.h file.
The random number in the T~A~~L attribute serves to confirm the successful import into the crypto-server cards. A hash value is formed (by means o~ SHA-1) for this random number and it is used for confix~m~.ng the successful import as well as for releasing the transport key, The generation of a message for the exchange of the data key is somewhat more complex and consists of the following sequence:
1. The data key is encrypted with the KTM (=LMK, CKM KEY WRAP WEBSENTRY mechanism). Th~.s has the advantage that all of the attributes of the key (among others, CKArEXTRACTABLE=false) are concomitantly encrypted and are set correctly again at the time of the decryption. With this encrypted byte sequence, an intexxm message with the following structure is formed:
Structure of an interim mee$ege for data key IUD

Itemsiengt ~y~e ao. Deeigx~atfon Deacriptioa h 1 n fl - n DataKey~ncryp Result of the t encryption (wrap) of the data key KD with the special WebSentry meohan~.sm ( key KTM) 2. The zntexim message, in turn, is encrypted with the active transport key KT making use of the cars aES3 cBC eAD mechanism (the initialization vector IV is filled with zexos).
3. The message to be distributed is formed and it has the following structure:
S~.ruc~ur~
df the d:fetr~but~on atessage for the data 7cey KD

Ittm .LesagtByte no. Designation ~sc,~ip~ioa h 1, 2 fl - f2 MsgType Identification of the key message, Constant 'KT' 2 1 f3 Version Version of the structure of the message, 1 byte starting with the value 'O1' 3 1 f4 KeyID ID o the data key in plain text 4 2 f5 - f7 KeyGeneration Genexat~.on counter in plain text, e.g. '01' 5 4 f8 - 7.2 SigKeyID ID of the key used for the signature 4 f12 - KTID ID o:f the f16 transport key used ax the encxyptian of the interim message 7 ri 16 - f" HelperMsgEncr Result of the s ypt encryption of the interim message 8 24 triltl MAC MAC or the -f"1+2a interim message:

is farmed in that an SHA-1 hash value is generated for the Fields Z-7 of the message and this hash value, provided with the signature key D~S3_CDC_PAD
(CKM

_ mechanism, the IV

i.s filled with zeros; ID see field 5), is encrypted.

9. Subsequently, the data key message is transferred for further distribution to the ZinS central server.
Moreover, it is stored by the security adm~.ni,strators 5 onto one or more diskettes that have to be kept xn a secure p~.ace sa that they can be used for the initialization of n,ew Z~.nS crypt.o-~ser~rer cards.
The advantage of the double encryption of the message 10 content is that less cipher text has to be transmitted to the KTM via the ~ntranet and consequent~.y, arypta-analysis of this key is renderEd much more difficult.

For purposes of releasing the data key KD, an interface and a protocol mechanism are provided by means of which the release of the data key is protocolled. The Central payment assurance system is preferably configured in such a Way that the data key is onXy released after the successful distribution and successful import of a data key into the crypto-systems of the local payment assurance systems. Only through this release is the appertaining data key subsequently used far the encryption of crypto-strings that are to be incorporated into the postage .indicia and then the appertaining key identification information KeyID is encoded in the identification information (PostageID) of postage amounts.
The interface is realized via CWMS (computerized work management systems) between the central payment assurance system (ZinS central) and the local payment assurance system (ZinS local). The value transfer center (Postage Point) PP receives the information via the appropriate bean. The data structure for the releasing procedure has the following contents:
Structure of the ~ethnd for releasing da~~e k~eya I~

Item Zengt Hyta no. Designation Daacriptior~

h 1 1 f1 KeyID ID of the data key in plain text 2 20 f2 - f22 RandomHash SHA-1 hash value of the random number that was transmitted as the T~ABEL

attribute of the data key 3 1 f23 State Result of the encryption:

true = processing successful, release can take pz~c~

false =

processing not successful 4 12$ f23 - Message Detailed mes$age f151 about error causes, ox detailed success message The authentication of the key allocation system of the payment assurance system vis-a-vis the key allocation system of the value transfer center PP is caxxied out via parameter 2. This is preferably a hash value that is formed using the SHA-1 method from the LABEL attribute of the data key. I'he LABEL attribute is filled with the random value at the time of the generation of the data key. Since the data key and all of its attributes are encrypted during the transmission, the correct hash va7.ue can only be computed by the crypto-server of the payment assurance system.
If the transmitted hash value is identical to the hash value of the KD that has been computed for the LABEL
attribute and is located on the Postage Point-WebSentxy module, and ifi the transmitted processing status = true, then the data key is activated. This means that subsequently, the crypto-strings for the postage indicia/postage amounts are encrypted with this data key.

When a data key is activated, the generation counter of the signature key is increased by one.
A variant of this application case exists if the processing is erroneous ttransmitted status = false). ~n this case, the status for this key generation and key distribution is protocolled and the appertaining data key is correspondingly deleted on the card. In this case, the generation counter is not increased by one.
preferably, the key allocation systems contain a status memory to stare the executed key generations. As long as no feedback has been received from the central payment assurance system (ZinS central system) about the executed key distribution, the status is displayed as open. After the successful feedback and distribution, the key is designated as having been activated. Yn case of error, the transmitted status message is displayed. Zn case of errors or the prolonged absence of a release message, an error investigation routine is invoked.
It is advantageous to perform an archiving of the kegs. A
preferred archiving of the keys in the area of the value transfer center will be described below. In order to secure the keys, the security administrator can start an arChxving function that encrypts all of the keys (except for KTM) with the KTM (CKM-KEY WRAP WEBSENTRY mechanism) and returns them. These keys should be securely stored in the database or in a secure file system area.

After the successful archiving, all of the keys are deleted that have exceeded their initial validity date by more than six months and ax'e no longer active.
Keys are restored - especially in the area of the value transfer center PP - in that the archived key data is decrypted again (unwrapped) and stored on the card. The mechanism used is once again CFCM_KEY WRAP WEBSENTRY.
After a key has been decrypted, a key with the same key identification information KeyID that already exists on the card is deleted.
Through special security measures of the WebSentry card and through the distribution onto several SmartCards, the master transport key KTM is reliably secured against being compromised.
If nevertheless an exchange o~ the master transport key is to be made, then analogous to the application case involving an initialization of a "erypto-card" (EP?, a new KTM as well as new signature keys, transport keys and data keys have to be generated.
The priar KTM rema~.ns on the card as a so-called "dormant LMK" and has to be appropriately deleted by the security administrator.
Preferred application cases of the key allocation system will be described below. The presentation also applies to applications in all areas of the payment assurance system.

This is especially advantageous if individual components are implemented preferably in the area of the local payment assurance system or of the central payment assurance system. However, use in each of the other payment assurance system is likewise possible.
A first application case is the initialization of the cxypta-card in the area of the payment assurance system.
In order to initialize the crypto-card, the following basic configurations are to be undertaken, whereby mast of the functionality can be managed via a management tool (WebSentryManager):
~ installation and configuration of the card, uploading the card firmware, insofar as the manufacturer has not already done sa. The firmware contains the Embedded Code (proprietary software routines) (the latter functionality is integrated into the WebSentryManager) ~ definition of clusters (with several crypto-cards) (WebSentryManager) ~ import a~ the transport master key (KTM), see separate application case (functionality is provided by the WebSentryManager) ~ user administration: deletion of the default security administrator and definition of the security administrators including the requisite authentication rules (SmartCard-based) Generation o~ twa "normal" users (one fox key verification / one fox key import) that authorize themselves via a predefined PIN.
The functionality of the user administration is likewise provided by the WebSentryManager.
~ import of the signature keys (KS): see separate applzcat~.an case ~ import of the transport keys (KT); see separate application case ~ optionally also import of the data keys (KD);
(likewise see their own application case) insofar as they have already been generated.
Here, the keys have to be imported in the above--def~.ned sequence. The card can be initialized at a central place, whereby the complete crypto-system computer has to be initialized and subsequently has to be sent. This is because the WebSentry Card deletes the internal memory as soon as it is pulled out of the PCI slot.
Preferably, the transport master kEy can only be imported by at least two security administrators who have locally identified themselves vis-~-vis the crypto-system by means of a SmartCaxd reader and the associated SmartCards.
~0 Due to the importance of the key KTM, this key can only be imparted onto the card using the dual control principle. This means that at least two of the PIN-proteCted SmartCards that were generated in the application case "'transport master key" are needed for the import.
Since the master transport key KTM can only be loaded onto the card using both SmartCards and since the key use is PIN-protected, it ~.s ensured that this key can only be installed onto the card using the dual control principle.
This provides a very high level of protection against the key being breached.
This functionality is pxovided via the management tool WebSentryManager. This management tool makes it passable to load a so-called local master key (LMK corresponds to the KTM described in this concept) via SmartCards and to store them in a secure storage area of the card.
zt is especially advantageous to distribute the LMK onto 24 three SmartCards, whereby all three parts are needed in order to import the LMK onto the crypto-hardware. Tn this case, three security administratoz~s are needed for importing the mastex transport key KTM.
The signature key ensures the ~.ntegrity of the key messages; it can also be used before the import of the key to determine whether the sender of the key message is the value transfer center (Postage Point). The sygnature key can be generated in different ways, whereby the examples presented here are especially advantageous. The appertaining key message is stored by the administrator onto a diskette and, through this application case, is imported onto a crypto-card of the payment assurance system that is to be initialized.
~n order to import the key, the key message stored on the diskette is decrypted with the master transport key KTM
(PKCS#11 function C Unwrap, GKM~KEY_ WRAP WEBSENTRY
mechanism). The integrity of the key message is automatically checked by this routine, rf a key with this KeyID already exists, it is subsequently deleted.
For the further transport of the transport key messages, the server of the central, payment assurance system provides an interface via which the distribution and the subsequent import into the crypto-systems of the individual local payment assurance systems can be initiated.
The interface is realized as an RMZ service. This Service is looked up by means of a naming service (JNDr). The distribution is carried aut via the CWMS (computerized work management system) used for the distribution of the P/N list.
If a new distribution job is created, the key message is forwarded to all of the currently registered crypto-systems and a protocol entry is written for each case.
The management o~ the crypto-systems is carried out via an application case o~ the payment assurance system.

The receipt of new key messages i.s checked at the individual crypta-systems by an ImportCantroller at regu.la.~ intervals (as a function ofi the distr~.bution mechanism). When a new message is received, the application case "import transport key" is automatically launched. The return, value of this action i.s checked. If a negatzve feedback is received, then the import attempt is repeated up t4 three times.
If the impart is still not possible after three attempts, then a protocol message about the failure is sent to the ZinS central system (once again as a function of the transport mechani.sm). If the import was successful, a positive protocol message is issued.
The protocol messages are processed centrally via the application case "protocol key processing". The release of the transport key is also triggered accordingly.
2U The import of the transport keys is either carried out by a security administrator who initializes the crypto-system on site or else this import is triggered automat~.cally by the ImpaxtCantroller of the key distribution when the ImportController receivES a new transport key message. The key is preferably imported according to the following process steps:
1. A registration an the card is carried out with the ID
and PIN belonging to the Keylmpart user.

2. A hash vaJ.ue is formed for Fields ~ - S o~ the transport key message using the SHA-1 method.
3. The signature key is ascertained that owns the KeyID
5 that was indicated in Field 4.
4. This key is used to encrypt the hash ~ralue formed under Point 2 (CKM oES3 cHC PAD mechanism, the initialization vector IV is filled with zeros) and 10 compared to Field 5. If these two values match, the integrity is ensured and it is assured that the message was created by the PC franking system.
5. The content of Field 5 of the message is decrypted 15 with the KTM (C ClnwrapKey method, CKM KEY WRAP WEBSENTRY mechanism). As a result, the appropriate transport key object is gene,rat~d automatically and stored on the card. In addition, the mechanism once again implicitly checks the 20 integrity of the key as wel.1 as the correct sender.
~. If a key with the same KeyII7 already exists on the card, it is de3.eted.
25 '7. A hash value is formed for the BABEL attribute of the new~.y imported key using the SHA-1 method and this is returned together with the KeyID and the positive message as the return value.
30 8. mhe user session is ended.

Q
9. A protocol message is created from the return valuEs and it is sent to the ZinS central system.
10. Any failed attempts stored for this KeyID (see variant described below) are reset.
A variant of this application case is that one o~ the routines or the checking of the MACS fails. In this case, further processing is aborted and a return value is returned containing ~,he KeyID, the error code as well as an error message. E'or the ~CeyID, the stored number of failed attempts is increased by ane. Once this number has reached three, a protocol message is created from the most recently transferred return value and sent to the central payment assurance system.
In case of manual initiation, the result of the impart is additionally displayed on the monitor of the security administrator.
Preferably, steps 2 to 7 run directly i.n the card software (embedded code). This increases the performance as well as the security against being breached.
For the further transport of the data key messages, the server of the central payment assurance systEm provides another interface by means of which the dzstxi.butior~ and the subsequent import of the data keys into the individual crypto-systems of the local payment assurance systems take place.

The interface is realized as a Session Hean; this service is looked up by means of a naming service (~7ava Naming and Directory Interface - JNDI).
S The distribution is carried out via the GWMS
(computerized work management system) used for the distribution of the P/N list.
If a new distxi.butian job is created, the key message is forwarded to all of the currently registered crypto--systems and a protocol entry is written far each case.
The crypto~-systems is managed via an allocation system.
If a distribution job for a data key is already in circulation for which no feedback has been received at the value transfer center PP, then the acceptance of further d~.stribution jobs for data keys is rejected until the point in t~.me of the feedback.
The receipt of new key messages is checked at the individual crypto-systems by an zmportController at regular intervals (as a function of the distribution mechanism). When a new message is received, the application case "import transport key" is launched automatically. The return value of this action is checked.
If a negative feedback is received, then the import attempt is repeated up to three times.
x~ the import is still not possible after three attempts, then a protocol message about the failure is sent to the ZinS central system (once again as a function of the transport mechanism). Tf the zmpart, Was successful., a positive protocaJ. message is issued.
'the protocol messages are processed centraJ.J.y via the appl~.cation case "protocol key processing". 'Ihe release of the transport key is also t~'iggered by this application case.
The import of the data keys is either carried out by a 14 security administrator who initializes the crypto-system on site ar else this import is tx~.ggered automatically by the ImportCantroller of the key distribution when the TmportCantroller receives a new data key message.
1S The key is imported analogously to the import of the transport key, taking into account the special ~eatures of a data key message:
1. A registration on the card is carried out w~.th the ID
20 and fZN belonging to the Keylmpart user.
2. A hash value xs formed for Fields 1 - 7 of the data key message using the SHA-1 method.
2S 3. The signature key is ascertained that owns the KeyID
that was indicated in Field 5~.
4. This key is used to encrypt the hash value formed under Point ~ (CKM DES3 csc PAra mechanism, the 30 in~.tialization vector IV is filled with zez~os) and compared to Field 8. If these two values match, the integrity is ensured and it is assured that the message was created by the PC franking system.
5. The transport key i,s ascertained that awes the KeyID
that was indicated in Eield 6.

6. The content o~ Field 7 of the message is decrypted with the key ascertained under Point 5 ( C-Decrypt method, CKM~DES~ cac_PAa mechanism, the initialization lp vector IV is filled up with zeros). The result o~ the decryption is an interim message.

7. The content of Field 1 of the interim rnessage is decrypted with the KTM (C UnwrapKey method, 1S CKM KEY W1~P WEBSENTRX mechanism). As a result, the appropriate data key object is generated automatically and stored on the card. In addition, the mechanism once again implicitly checks the integrity of the key as well as the correct sender.
ZO

8. If a key with the same KeyID already exists on the card, it is deleted.

9. All of the data keys on the crypto~-card are read and 25 checked as to whether the value of the generation counter in the LABEL attribute, byte 1, is the same as the newly imported key. If this is the case, these keys are removed from the card. These are keys that -due to an error in the import into a crypto-system of 30 another local payment assurance system -- were not released on the value txansfer center PP.

sa 7Ø A hash value is formed for bytes 2-65 of the LABEL
attribute of the newly imported key using the SHA-1 method and this is returned together with the KeyTD
and the positive message as the return value.
~.1.. The user session with the erypto-card i.s ended.
12. A protocol message is created frarn the return values and it is sent to the Zins central system.
13. Any failed attempts stored ~ar this KeyID (see variant described below) are rese'~.
A variant of this application case is that one of the routines or the checking of the MACS fails. In this case, further processing is aborted and a return value is returned containing the KeylD, the errox node as well as an error message. Far the KeyID, the stored number of failed attempts is increased by one. Once this number has reached three, a protocol message is created from the most recently transferred return value and it is sent to the centxal payment assurance system (ZinS centxal system).
Tn case of manual. initiation, the result of the import is additionally displayed on the monitor of the security admini.stratar.
Preferably, steps 2 to 10 run dirECtly in the card software (embedded cQde). This increases the performance ~1 as well as the security against being breached (especially of the initzalizatian vectors IV as well as of the KTMs).
A cleanup of the data keys is carried out repeatedly, preferably regularly, an as many crypta-systems of the payment assurance system as possible, preferably an all of them, and serves to delete data keys that are no longer needed.
Procedure of the data key cleanup 1. All of the data keys KD located an the card are ascertained and sorted in ascending order accard~.ng to their ID (CKA ID attribute).
2. For each key o~ this list, the following Checking procedures are carried out:
I. The successor of the key is determined (next-larger ID).
II. Zf present, the following xs verified:
l.whether the CKA END DATE attribute of the successor indicating the end of the validity of the predecessor is smaller than the current system date. If this is the case, then the Currently processed key of the list is deleted.

2. whether the generation counter of the successor (byte 1 of the CK~ LABEL attribute) is identical to the gEneration counter of the currently processed key. If this is the case, then the currently processed key of the list is deleted.
The key processing is preferably protocolled on the servex of the central payment assurance system (ZinS
cEntral server). xhe keys that are protocolled by th~.s application case are the transport key and the data key.
for each distribution jab, a protocol is drawn up indicating to which active crypto-system the key message was sent. Fox each system and each distribution jab, a separate entry is generated that is first set at the status "sent".
After each successful but also aftEr each unsuccessful key processing, the individual cxypto-systems generate a protocol message and send it to the centxal payment assurance system (ZinS central system). 'Ibis distribution either takes place via CMS gueues or by database replication.
In the area of the central payment assurance system, after the messages have been received, they are used to update the above-described protocol entries. Fox this purpose, the status "processing successful" / "not successful" as well as possibly an error code and the message are stored.

Following the processing of the protocol messages, it is Checked whether distribution jobs exist that were sucaessfuJ.l.y incorporated by all of the arypta-systems.
Tf this ~.s the case, then the release of each appertaining key, especially in the area of the value transfer center, is initiated. As satin as a system reports an exxar, a corresponding message with a negative status is generated in the area of the value transfer center .
The fact that the key release has been invokEd is noted with the distribution job so that no additional releases are carried out for a given job. As long as the note, however, has not been entered, a new attempt is made at regular intervaJ.s to contact the release service.
A special variant is present when, after a period of time to be defined, prEferably several days, for example, three days, feedback has not bEEn received yet from aJ.l.
of the crypto-systems. After the expiration of this time, a negative release message is sent to the value transfer centex.
Preferably, the key allocation system has a user interface that allows an administrator to check the status of a key distribut~.on jab. The following data is then displayed for each distribution job:
~ the number of systems to which the distxi.butian message was sent ~ the number of systems that have reported back a successful processing ~ the number of systems that have not yet reported back the outcome o~ the processing ~ the number of systems that have reported back an unsuccessful. processing Moreover, a detailed listing can be drawn up in which the current status of each system is displayed.
As an alternative, it is possible to display locally the keys stored on the appertaining card.
It is advantageous for all of the keys for whzch distribution jobs were generated to be archived in the area of the central payment assurance system. Preferably, no archiving zs carried out on the local systems . There, the keys are stored in the non-volatile memory of the card. Only key messages that were also released are archived.
The key restoration o~ transport keys and data keys can be J.aunched centrally for a specific crypto-system. In this case, the current keys from the archive are ascer-tained and sent to the specific crypto-system. For this purpose, protocol messages are likewise generated. With this type o~ key distribution, only the re~.ease message is absent.

If the master transport key KTM is lost, then the corresponding crypto-system eithex has to be sent to the security administrators for new initialization or else S the security administrators have to initialize each systEm on site.
The master transport key KTM is reliably secured against being compromised through special security measures of 10 the WebSentry card and through the distribution onto sevEral SmartCards as well as through the mufti-stage key system.
Nevertheless, if an exchange of the master transport key 15 is to take place, a new master transport key KTM as well as new signature keys, transport keys and data keys have to be generated.
These then have to be imported into all of the crypto-20 systems of the local payment assurance systems. Thzs involves more effort since either all of the crypto-systems have to be transported to the central administration site and back again, or else the security administrators have to travel to all of the sites of the 25 local payment assurance systems. Therefore, the use of the security mechanisms according to the invention far the master transport key KTM is especially advantageous.
The p~.ior master transport key KTM remains on the card as 30 a so-called "dormant ZMK" and has to be appropriately deleted by the security administrator.

5&
The key handling and the decryption should be present on the crypta-card as embedded code. In this manner, not only a greater degree of security is achieved but also a performance improvement of the crypto-system is expected.
Preferably, the crypto-cards contain the standard PKCS#11 functions listed below:
~ C ClaseSession ~ C GetSlotList ~ C Init ~ C Initialize ~ C Login ~ C~Lagout ~ C OpenSession along with the presented extensions. Moreover, permanently stared functions should not contain any further extensions of third parties and the extensions required here are exclusively integrated as functions for crypto-cards of the payment assurance system.
In order to designate the embedded key-handling methods of the PKCS#11 DLL, these methods are given a prefix.
This prefix is defined as CE_. In this case, CE stands for Crypto Extension.
Each embedded method supplies a return value of the type CK RV, which is defined as a fixed component of the pkcsll.h include file. It is advantageous that, during the implementation of the embedded methods, additional error return values are defined and these are provided in a C+* header file for integration. This measure is advantageous ~.n that, through an invocation of an embedded method, vax~.ous Pkcsll methods can be invoked which are nested on the hardware. Another advantage here is the completely newly established key-handling within the software of the crypto-cards.
Example for illustrating the method syntax:
CK RV = CE Methoc~lame (parameter list) Within the parameter list, parameters that hare to be filled with a result are transferred by means of call by reference. The method name is formed from meaningful woxd combinations that provide a good idea of what the method does.
The word selection is made in such a way as to allow an association of meaning contents, for example, through the use of English technical terms.
The introduct~.on of two enumeration types serves to 2S verify the functionality of different embedded methods. A
distinction is made between the enumeration type fox key typES and key attributes.
CE EnumKey = ~ CE KT, CE_DT, CE SE, CE KA }

5$
CE KA assumes a special position. It is not a kEy but rather the set of all keys. If this Ez~umElement is indicated, then the methods implement a functionality that relates to all of the keys contained in the card.
CE~EnumKeyAttr~.but8 = { CE_ID, CE LABEL, CE-STARTDATE, CE ENDDATE ]
ThE necessary defines are to be taken over into the )0 pkcsll.h file. The defined extensions can be located in a separate header file that are enclosed in the pkcsll.h file. Various mechanisms are possible to implement the embedded methods.
1S In the cryptographic environment, a method is defined that autonomously carries out all of the relevant verifications with the PKCS#11 methods that are available to it.
20 CK-RV CE Decrypt (CK SESSION HANDLE session, CK~~3yTE [ ] message, CK BYTE* postageID
CK BBOOL bOk) F'unation description:
The embedded cryptography method receives a 57-byte long date in the parameter message and thzs date corresponds to the matrix code of the postagE indicium. The counting in the following explanation of the work steps starts at one _ 1$t Step: formation of the initialization vector IV
As the initialization vector, the first two bytes are filled with zeros and then bytes ff - f10 plus byte f19 are appended to the matrix code.
2nd Step: determination of the KD to be used The key phase indicator is contained in byte f14; it indicates which key is to be used. The key phase indicator is stored in the CKA_ID key attribute and thus unambiguously identifies the key. The key handling described further below should allow an efficient finding of the key.
3rd Step: decryption of the contained encrypted message The mechanism employed in CK~MECHANISM is CKM DES3 CBG. Eytes f15 - f38 are decrypted, that is 24 bytes, the first 1,2 bytes of the decrypted result are output by the parameter postageID. Once the decryptxcn has been carried out successfully, the process continues with Step 4, otherwise with Step 5.
4t" Step: formation and cleanup o~ the hash value A specially constructed 77-byte large data block serves as the basis for the formation of the hash value of the date.
Bytes 1 to 53: corresponding to the first 53 bytes of the matrix code bytes 54 to 55: corresponding to the first 12 bytes of the cuxxent, unencrypted message part (POStageID) Bytes 56 to 77: corresponding to the last l~ bytes bf the current, unencrypted message part The hash value is formed using SfIA~-1 and, after this procedure, the first four bytes have to match bytes f54 - f57. If this is not the case, then the date is not valid. If an error occurs during the execution of the hashing or if there is a discrepancy in the hash value, then the procedure is as in Step 5.
5x° Step: return of the success indicator The parameter bOk is filled with "true" if all of the work steps were successful, and with "false" zf the hash value cJ.eanup has revealed a discrepancy or if one of the Pkcs#11 methods has caused an error. The return value has to accordingly be fziJ.ed with the error message or with CKRlOK if no error has occurred, CK_RV DE VerifyMsg (CK-S~SSxON HANDLE session, zo CK BYTE [ ] message, int length, CK ~BOOL bOk~
A general data block message far the verification procedure is shown below:
beta block for tire verification procedure I~em I,sngtHyde ao. Desfgriation Deecxip~ioa h 1 2 fl - f2 MsgType Identification of the key message, constant 'KT' or Kl~.

2 1 f3 Version Vexszon of the structure of the message, 1 byte starting with the value '01' 3 2 f4 - f5 KeyGeneration Generation counter in plain text, e.g. 'O1' 4 1 t6 KeyID TD d the data key in plain text 5 4 f7 - f11 KeyID ID of the transport key in plain text 6 4 fl2 - SigKeyID ID of the key f16 used for the signature 7 4 f1'~ - KTID ID of the f21 transport key used for the encryption d the interim message (see Item 2) 8 n-22 f22 - fn TranspKeyEncr KT: result of the ypt encryption (wrap) of the transport _____________ key HelperMsgEncr -------------ypt KD: result of the encryption of the interim message 9 24 fn+1 - MAC KT: MAC fdx the fn+24 key message; is dxmed in that an SHA-1 hash value is formed for the Fields Z+2+5+6+8 of the message, and this hash va~.ue zs encrypted with the signature key DES~_CHC_PAD
(CKM

_ mechanism, the IV

is filled up with zeros; ID see item 6).

KD: MAC for the key message; is farmed in that an SHA-1 hash value is formed for the E"ields 1+2+9+3+6+7+8 of the message, and _ this hash value is encrypted w~.th the signature key (CKM_D$9~_CBC_PAD

mechanism, the IV

is filled up with zeros; ID see item 6) .

Unused fields are filled up with zeros. The mode of operation of the method is determined via the parameter MsgType.
A generated data block is transferred in message for the MsgType KT and KD. The data block is filled up with each of the received messages.
IO The function aJ.XoCatian CE VerifyMsg KT far the MsgType KT receives the complete transport key message in the MESSAGE attribute, and its length in the DENGTH attribute.
This embedded message serves to ensure the integrity of the transport key message at the recipient. In order to actuate the verification, the following steps have to be performed:
1st Step: formation of the initialization vector IV
The initialization vector is filled with zeros.
2°d Step: decryption of the received encrypted message The mechanism used in CK MECHANxSM 15 CK~i DES~,CHC-PAD.
The bytes of the variable MAC field are decrypted. If an error occurs during the decoding, then the procedure is as in Step 4.
3rd Step: cleanup of the hash value In order to form the hash value of the date, a hash is formed from the Fields 1+2+5+5+$ of the transport key message and it is compared to the hash of Step 2.
The hash value is ~axmed using SHA-1. Tf the hash values are not identical, then the date is not valid.
T~ an error occurs during the execution of the hashing or if there is a discrepancy in the hash value, then the procedure is as in Step 4.
9~h Step: return of the success indicator The parameter bOk is filled with "true" if all of the work steps were successful, and with "false" if the hash value cleanup has revealed a discrepancy or if one ofi the Pkcs#~.l methods has caused an error. The return value has to be filled accordingly with the error message or with CKR OK if no error has occurred.

After the function allocation CE VerifyMsg for the MsgType KD, the complete data key message is transferred in the M~SSAG~ attribute, and its length in the LENGTH
attribute. This serves to ensure the integrity of the transport key message at the recipient. In order to actuate the verification, the following steps have to be performed:
1s~ Step: formation of the initialization vector IV
The initialization vector is filled with zeros.
2°d Step: decryption of the received encrypted message The mechanism used in CK MECHANISM 18 CFSM DES C8C PAS.
The bytes of the variable MAC field are decrypted. If an error occurs durzng the decoding, then the procedure is as in Step 4.
3rd Step: cleanup o~ the hash value In order to form the hash value of the date, a hash is formed from the fields Z+2+4+3+6+7+8 of the data key message and it is compared to the hash of Step 2.
The hash value is ~arrned using is carried out using SH~1-1. If the hash values are not identical, then the date is not valid. If an error occurs during the execution of the hashing or if there is a discrepancy in the hash value, then the procedure ~.s as zn Step 9.
9'h Step: return o~ the success indicator The parameter bOk is filled with "true" if all of the work steps wEre successful, and with "false" if the hash value clEanup has revealed a discrepancy or if one of the Fkcs#11 methods has caused an errar. The return value has to be filled accordingly with the error message or with CKR QK if no error has occurred.
5 These embedded key-handling methods should comprise the key import of a wrapped key and an ef~iGient key management. Keys of the type KS, KD and KT should be imparted.
10 CK RV CE-ImportKey (CK SESSION HANDLE session, CK'BYTE-PTR data, CK~U~ONG length, CK~HYTE* HashValue, CE EnumKey KeyType, CK~CHAR t ~ xeyKTZ~~
is The function allocation CE_ImpartKey is preferably carried out as described below:
The CKM KEY WRAP WEBSENTRY mechanism is used for the 20 wrapping. Accordingly, the same mechanism is needed for the unwrapping. The key obtained is imported ~.nto the crypto-hardware lay the unwrapping, whereby a key that ~.s imported a second time, that is to say, with the same key phase, overwrites the old key.
The wxapped key is transferred to the DATA parameter and its length in the LENGTH parameter. The length of the key depends on the filling of the key attributes. The key type is verified by the KeyType parameter and treated accordingly.

bb The key is then taken into the kEy management held in the cache operation and, if applicable, the duplicate predecessor is deleted.
The DT is decrypted by the KT that is identified by the KeyKTrD parameter; for all of the other key types, this parametEr is not taken into consideration and is fried w~.th zeros .
The dependence of the CKA-END DATE attribute is important.
It indicates the end date of the key predecessor.
The key attribute of the imported key contains the random numbEr by means of which the hash value is to be formed '.
~S using SHA-1. The hash value is retuxned in the HashValue parameter of the embedded method. The hash value is needed for the key acknowledgement message.
In case of error during the unwrap mechanism or the hash formation, the appropriate error code is output in the return value, otherwise CKR_OK.
CK-RV CE GetKeyCount (CK SESSION HAN17~E session, CE EnumKey KeyType, int* counter) The function al7.ocation CE_GetKeyCount shows how many keys of Each key type are registered on the card in the key management held in the cache operation. In this manner, the key attributes can be read out in conjunction with the method described below.

This method is defined as follows:
CK RV CE GetAttribute (CK SESSION HANDLE session, CE EnumKey KeyType, CE EnumKeyAttribute KeyAttribute, int pos, CK BYTE [ ] * attribute, in~t * length ) The key type is determined via the KeyType parameter and thus also the table that is to be read from when the different key types on the orypto-hardware are recorded in different lists according to the type of key.
The KeyAttribute parameter specifies the attribute that is to be read out and the ITEM parameter indicates the staxting paint within a table; its maximum value first has to be acquixed using the CE GetKeyCount method for all keys or else for one key type. when the CKA_END-DATE
attribute is output, it must be noted that the last current key is theoretically infinitely vaJ.id (until a new key of the same type is imported) and, in its CKA END DATE attribute, contains the end date for the predecessor key of the same key type, whereby the CKA END DATE of this indicated key is output.
The attributes for a date have a fixed length of 8 bytes whereas the CSK 2D and CKA LABEL attributes have a fixed length of 128 bytes. x~ the attributes within the keys for these two parameters should be shorter than 128 bytes, then the remaining bytes up to 128 are filled up with zeros. Thus, the user aan always provide sufficient memory for the methods in question. In case the usex provides a buffer that is too small, the information is trimmed and a message to this effect is transmitted via CK RV.
CK RV CE-DeleteExpiredKeys (CK~SESSION HANDLE session, CE EnumKey KeyType, i.nt* saunter) The function allocation CE DeleteExpiredKeys searches the card for expired keys and deletes them from the card.
Expired keys can be identified by the fact that the system date is older than the CKA END-DATE of the successax~ key, see under 2.5.8; this also applies to KT
and KS. Selective deletion is made possible through the EnumType arid the entire card can be deleted by means of CE-KA (only the LMK is retained). It is important that this method must not be allowed to become active when a key import is carried out. This is preferably controlled in the embedded code and ~.ndzcated with an appropriate return value. Thanks to this measure, any indeterminate side effects in the internal key management are avoided.
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 structure o~ the interface between the value transfer center (Postage Point) and the central payment assurance system is shown in Figure 3.
The central payment assurance system provides an interface for distributing keys by means of which keys generated in the KeyManagement component of the value transfex center (Postage Point) can be distributed to the crypto-systems o~ the payment assurance systems.
The value transfer center provides the payment assurance system with a key xelease interface by means of which the payment assurance system can release the key after the ,_.
successful distribution and processing of said key.
Since mainly Java is used in both projects, an application interface realization using Session Beans is xecommendEd. In ordex to uncouple the two systems, the services should be looked up by a naming service using J'NDI.
A Session Bean prov~.des the necESSary functionality for importing the key data into the ZinS central system. The entire communication is shown in Figure ~.
~'igure 4 shows process steps fox integration of a data key into the central payment assurance system (ZinS
central).
The process routine ImportKey tz~ansfers the data key set to the ZinS central.

Depending on the use of ASN.1 messages, this process routine prepares the received message and causes the message to be stored in the database. The process routine 5 ImportKey then initiates the distribution of the key data to the ZinS local systems by means o~ CWMS.
The sequenoe o~ importing the data into the database and subsequent distribution of the messages should be 10 observed. This ensures that the received data is secured before work is done to it or with it. The advantage of this approach is that events in the realm of errors can be better reconstructed and, in case of a data loss, access can be gained to the database if need be.
The parameters o~ the InsertKeyData method are not yet specified since at this point in time, it is not yet clear whether the A5N.1 format is supported. f~owever, the method will have to be equipped with two parameters in order to also be able to sent a detailed message to the Postage Point.
In ZinS central, the distribution method of the key allocation system is responsible for the following:

1. archiving the key message on the ZinS central server.
2. distributing the key messages from the Postage Point to the ~.ndividual mail centers by means of the CWMS
interface provided by Vibris. The structure and use of the CWMS service can bE found in the manual of this interface.
3. after the distribution and import into the individual mail. centers has been completed, an appertaining return message i.s generated.
The data xs transmitted from the value transfex center (Postage Point) in the ASN.I format. The appertaining t0 z~eturn response is likewise expected in the ASN.1 format.
Instead of this ~oxmat, however, other formats can, of course, also be used. 'Ihe particular formats are adapted for use by a suitabJ.e parser.
Preferred data formats in ASN.7. are the following:
Distribution messages far the transport key TransportKeyMessage .. SEQUENCE
MsgType OCTET STRING, ( fix 'KT' ) Version OCTET STRING, ( Qx01 ) Keyln OCTET STRING, ( CKA ID ) SigKeyID OCTET STRING, ( CKA zD of SignatureKey usEd for MAG ) TransKeyEnexypt OCTET STRING, ( TransportKey wrapped with LMK ) MAG OGTET STRING ( MAC over all previous elements ) Distrzbutian m~ssac~o for the data key PostageKeyMessage .. SEQUENCE

MsgType OCTET SfRrNG, ( fix 'KD' ) Version OCTET ST»rNG, ( 0x01 ) KeyID OCTET STRING, ( CKA-ID ) KeyGener3tion pCTET STRING, ( 0x01 ascending ) SigKeyID OCTET STRING, ( CKA_ID of SignatureKey used for MAC) TransKeyID OCTET STRING, ( CKA-ID of TransportKey ) DataKeyEncrypted OCTET STRING, ( 1?ostageKey wrapped with LMK
and encrypted with TranspoxtKey ) MAC OCTET STRING ( MAC over all previous elements ) ) Also see section 2.9.6.
Release message KeyExchangeReceipt .. SEQUENCE
KeyID OCTET STRING, ( CT~1_ID of received key ) Key~abelHash OCTET STRING, ( SHA-1 hash of CKA LABEL of received key ) State BOOLEAN, ( TRUE/FALSE to enable/dismiss key ) Message OCTET STRING ( Description of success/faz7.ure }
The data structures can have a different set-up. However, a sEt-up according to the embodiments presented is especially advantageous since they allow the transmission of all of the information that is to be taken into 3D consideration and they account for a small data transmission effort. In particular, the data is transmitted via CWMS to the local payment assurance systems which are preferably located in mail centers of the postal, service provider.
When the ASN.1 format is used, the data would first have to be parsed into the intexna.l key message, which would be dispensed with if the messages defined in this document were used dzxectly.
'The data packets receivEd through the CWMS correspond to the k.~y messages prevxdusly defined in this document.
These messages are then subjected to the VerifyMsg method of the embedded code aftex they have first been adapted to the data table above title "Attx~.butes of the data key KD". A~tex the verification, either the impart of the key is started via the embedded code or else an appropriate error message is generated. Compare key messages and gages 12 to 14 in terms o~ the import data structure of the CE-TmportKey embedded code method. The deletion of the old keys as well as the updating are carried out automatically by the above-described embedded code methods.
Every day, the CE_~eleteExpiredKeys method is invoked which removes the expired keys Exam the crypto-hardware daily, whenevex this is necessary. Curing the import, the CA_ImportKey method ensures that duplicate keys are deleted and that newer ones replace them.
3U The embedded code methods are bound to the application by the Java class CryptoAdapters. CryptoAdapters offer all functions (similarly named) that the embedded code arid other PKCS#11 methods o~fer.
By means of ~NI, a DLL (CryptoAdapter.DLL) is used that has statically linked the DLL provided by Zaxus. The security risk is further minimized through the static linking.
The C++ implementation of the JNI interface also provides error handling for each requested session; in this context, see Stage 3 under "multithreading" in the PCFM
Design Document. The worker ooncept is supported in that the crypto-haxdware is initialized in the multithreading mode and, after the login, each worker gets its own 1$ session (getSession, C GetSession), as a result of which this worker is registered in the DLL and error handling is established specifically for the worker. The mainstream of the DLL is addressed by the login and likewise has its own error handling for the execution of Pkcs#11 methods and the embedded methods.
Figure 6 shows an overview of the implementation.
Preferably, the key list and the code that is provided by the embedded methods are removed. Otherwise, the set-up ~5 of the structures must be selected to be identical.
Connection of the DLL
A preferred encapsulation and an advantageous error handling are shown in Figure 7 by way of an example.

~1n implementati.on of the key lists is not needed if the key Lists are held completely in the embedded code of the crypto-hardware. The CetAttribute methods decrease to the one single invocation of the embedded CE GetAttribute 5 method; by the same token, the invocations for the import and ~.ts implementation are reduced since this is automatically carried out by the embedded code after the transfer of the necessary data.
10 An expanded error constant list is provided in the embedded code.
The key messages from the Postage Point acre stored in ZinS central in a database in order to allow a later 15 replacement of a defective local payment assurance system.
First of a11, it is required that the message as such be incorporated into the database and secondly, that administrative ~.nformation be received.
20 Consequently, the following database tables are needed.
TransportKeyData SDItemNO INT

Key data record See table on page Key data stores the key message in the way in, wh~.ch it was received by the Postage Point; in case of a failure 25 0~ a local payment assurance system, the archiving of the key message serves to coordinate the ~axJ.ed local payment assurance system with the other remaining local payment assurance systems by imparting the archived key. Before the storage, the message has to be parsed by ASN.1 in order to txansmit it to the local systems. The shared form of the data records is preferred as the storage modality; this corresponds to the table that describes the data block that is used fox the CE VerifyMessage embedded method.
TransportKeyManagement SNItemNa Number ReceiptDate DATE ( /
timestamp ) GompletionDate DATE ( /
timestamp ?

DistributionDate DATE ( /
timestamp ) EndStatus VARCHAR(20) StatusTBxt VARCHAR(20) This data record has a central significance. First of all, it serves to evaluate the feedback received from the local payment assurance system in the mail centers, preferably all of the mail centers that are integrated into the mailing system of the postal service provider, as weal as to conduct a capable error analysis and to alarm of the system operator whenever the time is exceeded duxing the distribution procedure.
Hy the same token, this table involves administrative information processing. This makes it possible to use the entry SNItemNa to allocate and to evaluate the appertaining TransportKeyData table and the TransportKeyReplayMessage of the individual (83) mail centers, if applicable,.
TranspoxtKeyReplayMessage SNItemNo Number MailCenterNo Number MessageDate DATE

timestamp ) MessageText VARCHAR(520) In this table, the individual key response messages of the local payment assurance system are archived i.n the mail centers o~ the postal service provider as a function of the import procedure.

Claims

1. A method for verifying the authenticity of a postage indicium generated using a franking key and applied onto a mailpiece, whereby cryptographic information contained in the postage indicium is decrypted and used for verifying the authenticity of the postage indicium, characterized in that a data key (KD) is generated, transmitted from a central payment assurance system (ZinS central) to local payment assurance systems (ZinS local) and imported by the latter, in that a result of the import is transmitted to the central payment assurance system (ZinS central) and in that, once the data key (KD) has been successfully imported into essentially all local payment assurance systems (ZinS
local), the data key (KD) is released for the prodution of new postage indicia.

2. The method according to Claim 1, characterized in that the data key is provided with an end date for the preceding data key and/or it is transmitted with the end date.

3. The method according to Claim 2, characterized in that the franking key is transmitted to a cryptographic element and in that the cryptographic element checks whether other data keys have an end date and whether the end date stored for the successor data key is older than a date stored in the payment assurance system.

4. The method according to one or more of the preceding claims, characterized in that the data key is provided with a generation counter and/or is transmitted together with the generation counter.

5. The method according to Claim 4, characterized in that the data key is transmitted to a cryptographic element, especially to a crypto-card, and in that, as soon as the cryptographic element receives the data key, it deletes all of the data keys that have the same generation counter value as the transmitted data key.

6. The method according to one or more of the preceding claims, characterised in that the result of the import is transmitted as a data record.

7. The method according to Claim 6, characterized in that, the data record contains a key.

8. The method according to one or more of the preceding claims, characterized in that, the result of the import is transmitted to a value transfer center (Postage Point).

9. The method according to one or more of the preceding claims, characterized is that the result is checked by decryption of the key.

10. The method according to one or more of the preceding claims, characterized is that once the data key has been successfully imported into essentially all local payment assurance systems (ZinS
local), the data key is released at the value transfer center (Postage Point).

11. The method according to one or more of the preceding claims, characterized is that the data key is a symmetrical key.

12. The method according to one or more of the preceding claims, characterized in that the new data key is transmitted from the value transfer center (Postage Point) to the central payment assurance system.

13. The method according to one or more of the preceding claims, characterized in that the value transfer center encrypts the data key with a transport key (KT).

14. The method according to claim 9, characterized in that the transport key is encrypted with a master transport key (KTM).

15. The method according to one or more of the preceding claims, characterised in that the data key is generated in the area of the value transfer center.

16. The method according to one or more of the preceding claims, characterized in that the data key is provided with key identification information.

17. The method according to Claim 16, characterised in that the key identification information is transmitted in encrypted form.

18. The method according to one or more of the preceding claims, characterized in that the data key or at least part of the data key forms a component of a franking key for the generation of postage indicia.