EP3308278B1 - Method for updating personalization data - Google Patents

Description

The invention relates to a method for updating personalization data of a valuable or security document, wherein the valuable or security document can in particular be a sovereign valuable or security document.

In the state of the art, sovereign value or security documents are often implemented as chip cards, such as the electronic passport, the electronic identity card and the electronic residence permit of the Federal Republic of Germany.

A large number of documents, in particular security or identification documents, are known in the prior art, which are designed as chip cards with arithmetic logic. In this case, personalization data such as passport photos, fingerprints or the like are usually stored in a non-volatile memory area of the chip card, which can be used by a processor of the chip card, for example in the course of an authentication process to determine the identity of a document owner.

Writable files on value or security documents, for example in the form of chip cards, for storing personalization data and for personalizing the value or security document are characterized by a physical storage length with a physical file end. A corresponding file has a predefined physical storage length, which corresponds to the storage space created. If personalization data is stored in the file, the file also has a logical end of file. The logical end of file indicates the end of a logically related section of the occupied storage space. The physical end of file, on the other hand, specifies the maximum amount of data that can be written to the file, i. H. it corresponds to the end of the memory block reserved for the corresponding file. The logical end of file, on the other hand, indicates up to which point in the memory block the file is already filled and up to which position the file is to be read. With a completely filled memory block, i. H. a file completely filled with stored data, the physical end of file and the logical end of file coincide.

If the data stored in an elementary file is to be updated, ie replaced, by new data, problems can arise if the updated data, with which the original data is overwritten, is shorter than the original data. In this case, the newly written personalization data is followed by residual data from the original personalization data. When reading out, it can happen that more data is read out than actually expected, since the excess residual data is also read out.

A common auxiliary construction in this case is to use the complete memory block, i. H. the complete file, first to be overwritten with zeros, whereby the logical file end corresponds to the physical file end. Only after this process is the data to be updated written to the memory block. This usually shows where the updated data ends. However, the data content of the updated data does not correspond to the written content, since the added zeros could also be read when the written content is read out.

The excess zeros can lead to problems in particular if the chip card is to create a signature for the content of a file, for example, and this signature is later to be checked outside the card. In this case, it is not clear whether the corresponding zeros are a logical part of the signed data or not. This can lead to problems when checking the signature of the corresponding files.

In addition, the inevitable reading of excess residual data means an increase in the workload when reading out the contents of the corresponding files.

File structures are known from the prior art which include a length specification of a logically related file section, e.g. B. TLV files. If several such TLV files are configured as file structures arranged one after the other, it is not clear without further information whether the data that are directly connected to the logical file structures delimited by the length specification are negligible residual data or other meaningful, logically related data data sections.

Wolfgang Rankl et al. described in the "Handbook of Smart Cards: Structure - Functionality - Use of Smart Cards", 4th edition, January 1, 2002 , chip cards and TLV structured data.

In contrast, the invention is based on the object of creating an improved method for updating personalization data of a value or security document, which in particular also enables the personalization data to be changed securely in sovereign applications.

The object on which the invention is based is achieved with the features of the independent patent claims. Embodiments of the invention are specified in the dependent claims. Unless expressly stated to the contrary, embodiments of the invention can be freely combined with one another.

According to the invention, a “value or security document” is understood to mean paper-based and/or plastic-based documents, for example in the form of chip cards. Valuable or security documents include, for example, electronic ID documents, in particular passports, identity cards, residence permits, visas and driving licenses, vehicle registration documents, vehicle registration documents, company ID cards, health cards, signature cards, SIM cards or other ID documents, means of payment, in particular banknotes, bank cards and credit cards, bills of lading or other proofs of entitlement, in which a data store for storing the at least one attribute is integrated.

A value or security document comprises in particular a "chip card" which has at least one data memory for storing at least one attribute or personalization data and a communication interface for reading out the attribute or personalization data. The document preferably has a secure memory area, for example in the form of a chip card, for storing the at least one attribute, in order to prevent the attribute stored in the memory area from being changed in an unauthorized manner or read out without the authorization required for this.

In the following, a “protected memory” is understood to mean, in particular, a non-volatile electronic memory which allows access to data stored in the memory only after a cryptographic access condition has been checked. Furthermore, a protected memory can have access management, which allows specific users who have appropriate access authorization to access the memory stored data granted after identification of the user. However, it is not possible to read or write the data from the protected memory without the appropriate authorization.

According to one embodiment, the memory of the value or security document is a protected memory.

Various chip card operating systems with a hierarchical chip card file system are known, as specified in ISO/IEC 7816-4, for example. Such a chip card file system usually has a root directory called "Masterfile", abbreviated MF. Furthermore, a chip card file system has directory files, so-called "dedicated files", DFs for short. The MF is a special form of the DF. A data file is a file dependent on a DF, which is also referred to as an elementary file, abbreviated to EF.

With JavaCard-OS, for example, an MF does not necessarily have to be present. Then each application manages its data in a DF without a higher-level MF. The root of the DF is then set using an application identifier (AID) directly when the application is selected. A master file is therefore a special case of a dedicated file and represents the entire memory available in a chip card or a value or security document for the data area.

The chip card file system can also contain data objects which, in principle, cannot be accessed externally. For example, such a data object contains a key, in particular a private key of an asymmetric cryptographic key pair, a password and/or cryptographic parameters. Such internal data objects are also referred to as Internal EF.

Both an EF and a DF can contain control data, such as an access condition to the EF or to the files dependent on a DF. Personalization data is generally stored in the EFs.

In contrast to personalization data, "control data" of a value or security document is understood to mean the assigned administrative data which, in particular, define at least one access condition for access to the personalization data. Furthermore, the control data can also contain an indication of the position of the file in question in the chip card file system, for example in the form of a pointer to the respective successor node in the file tree of the chip card or of the value or security document, as well as e.g. a file identifier (FID) and an application Identifier (AID).

"Personalization data" is understood to mean all data stored in the file system of the chip card operating system that can only be used internally by the chip card operating system at runtime (e.g. key and associated cryptographic parameters) or can be read out in compliance with the access conditions stored in the control data (e.g. data of the owner ). In particular, "personalization data" is understood to mean data that requires a terminal application program that is interoperable with the chip card or a value or security document, such as biometric data, in particular fingerprint data, facial biometric data and/or iris scan data that a terminal needs for a biometric authentication required. Such sensitive personalization data may only be read from the chip card or value or security document after prior authentication of the terminal, with the cryptographic access conditions required for this being specified by the respective control data.

In the case of chip cards in particular, the power supply for the processor means of the chip card is usually provided by a terminal via an RFID interface. If the document were to be removed from the terminal too early during an update process, the power supply to the document would be interrupted and any update process that might have been triggered could not be completed. This could potentially make the document unusable. Embodiments of the invention could have the advantage that this risk can be effectively avoided by the document for example in a Slot or another type of mechanical recording of the terminal is fully included and thus protected from access by a user. After the end of the reloading process, the document could then be ejected from the mechanical receptacle of the terminal.

When using contactless communication between the terminal and the document, the wear and tear on the document can be reduced to a minimum despite the use of a mechanical holder. The contact surface between the document and the holder of the terminal is irrelevant for the communication between the document and the terminal, as well as for the coupling of energy to operate the document. Thus, friction effects on the surface of the document body do not impair the functionality of the document. At the same time, by combining mechanical recording with contactless communication, the integrity of the data stored on the document can be preserved, since premature removal of the document from the terminal can be ruled out. This ensures uninterrupted communication and power supply during the update process.

Embodiments of the invention can have the advantage that the logical end of the personalization data in the EFs is clearly defined by the pointer stored in the chip card file system. This clearly defines the point up to which the EF is to be read. Data that is arranged after the logical end defined by the pointer is not read out and can therefore not lead to ambiguities. In addition, it can be ensured in this way that no unnecessary reading processes are carried out or no unnecessarily extensive amounts of data are read out. Thus, the efficiency of the reading process is increased.

The personalization data can be, for example, an address of the owner of the value or security document. When moving, there is a need for the previously saved personalization data containing old address with personalization data containing the new address.

According to one embodiment, the DF is an MF. According to a further embodiment, further files, EFs and/or DFs, are combined in the MF, it being possible for the DFs in turn to each comprise at least one EF.

According to an embodiment not according to the invention, the pointer is stored in the control data of the associated EF.

This can have the advantage that the pointer is directly assigned to the associated EF and can be read out directly in the course of accessing the EF.

According to the invention, the DF comprises a plurality of EFs and a pointer table, the pointer table associating each EF with a pointer which indicates the logical end of the personalization data stored in the associated EF.

Embodiments of the invention can have the advantage that the pointer information is provided in a central pointer table, which increases the clarity of the system.

The present invention is particularly advantageous if the updated personalization data is shorter than the previous personalization data. However, even if the updated personalization data is longer and the logical end is thus shifted backwards, the present invention offers the advantage that the logical file end of the updated personalization data is clearly defined.

According to one embodiment, the updated personalization data are shorter than the first personalization data, so that the logical end of the updated Personalization data is arranged before the logical end of the first personalization data.

• Ermitteln der für den Schreibvorgang notwendigen Länge des EFs,
• Ermitteln, ob die Länge des EFs mindestens der zuvor ermittelten Länge entspricht, wobei das Verfahren nur fortgesetzt wird, falls die Länge des EFs größer oder gleich der zuvor ermittelten Länge ist.

According to one embodiment, the method carries out the following checks before writing the second personalization data:

• Determining the length of the EF required for the write process,
• Determining whether the length of the EF is at least equal to the previously determined length, the method only continuing if the length of the EF is greater than or equal to the previously determined length.

Embodiments of the present invention may have the advantage that personalization data is only written to an EF if the resulting length of the updated personalization data does not exceed the length of the EF. It can thus be prevented that errors occur when writing the updated personalization data.

• Ermitteln des logischen Endes der ersten Personalisierungsdaten durch Auslesen des Zeigers aus dem Chipkartendateisystem,
• Ermitteln des voraussichtlichen logischen Endes der aktualisierten Personalisierungsdaten infolge der Aktualisierung der ersten Personalisierungsdaten in dem EF auf Basis der Länge der zweiten Personalisierungsdaten.

According to one embodiment, determining the length of the EF necessary for the write process includes:

• Determining the logical end of the first personalization data by reading the pointer from the chip card file system,
• determining the expected logical end of the updated personalization data as a result of updating the first personalization data in the EF based on the length of the second personalization data.

Embodiments of the invention can have the advantage that the probable logical end of the updated personalization data can thus be determined efficiently.

According to one embodiment, after writing the second personalization data, the logical end of the file is set to the end of the second personalization data by creating an updated pointer indicating the logical end of the updated personalization data.

Embodiments of the invention can have the advantage that the logical end of file can be determined easily and reliably. Once the personalization data is written to the EF, the logical end of file is placed directly after the currently written data block of personalization data.

According to one embodiment, the write command is a write command in a sequence of write commands, with a last write command in the sequence of write commands comprising an indicator which indicates that the last write command is a final write command, and with the preceding write commands each comprising an indicator which indicates another write command follows.

Embodiments of the invention can have the advantage that a plurality of write commands can thus be used for a plurality of personalization data. This is advantageous, for example, when the personalization data to be written is very extensive and it is necessary for reasons of data transmission or predefined data formats to divide the personalization data to be written into a plurality of data blocks, each of which is assigned a write command. Furthermore, embodiments of the present invention open up the possibility that different personalization data or parts of personalization data can be updated at different points of the EF. The various write commands can be linked, for example, via a command chaining bit in the CLASS byte according to ISO 7816-4 of the write command. A bit value of 1 indicates that a further write command follows, while a bit value of 0 indicates that this is a final write command. The pointer is not updated until an indicator in the form of a bit value 0 indicates that this is the final write command. Then the logical end of file is placed after the last updated personalization data.

According to one embodiment, the method comprises: Before updating the pointer, checking using the indicator whether the write command is a final write command, if the write command is not a final write command, executing the next write command in the sequence, if the write command is a final write command, setting the logical end of the file after executing the final write command to the end of the updated personalization data by creating an updated pointer indicating the logical end of the updated personalization data

Embodiments of the invention may have the advantage that the logical end of file can be determined efficiently. No further information, such as write commands, is required for this. The entire write process can thus be configured more efficiently, even in the case of a plurality of write commands.

In one embodiment, the logical end of file is placed at the end of the updated personalization data in response to a selection of another file and/or directory by creating an updated pointer that indicates the logical end of the updated personalization data.

Embodiments of the invention can have the advantage that additional auxiliary constructions such as overwriting the entire content of the EF with zeros are not required. This saves time on the one hand and on the other hand there is no need for an additional write command that would have to be triggered externally. In addition, the logical content of the EF always matches the actually written content in update methods according to the present disclosure, ie in operations on the content of the EF, such as reading out the corresponding personalization data, negligible residual data need not be taken into account.

According to one embodiment, the first personalization data is updated by overwriting it with the second personalization data, beginning at the beginning of the first personalization data.

Embodiments of the present invention can have the advantage that no additional information about the start of the writing process is required, as a result of which the entire writing process can be made more efficient.

According to one embodiment, the write command includes an offset value that determines a starting point within the memory length of the EF for updating the first personalization data, and the first personalization data is updated by overwriting it with the second personalization data.

Embodiments of the invention can have the advantage that the starting point for updating the personalization data can be chosen flexibly. This is advantageous if the personalization data stored in the EF is very extensive and only a small part of the stored first personalization data has to be updated with second personalization data. In this case, by using an offset value in the write command, it can be avoided that the entire personalization data has to be updated.

If, for example, the first personalization data is the address of the owner of the value or security document and if the owner moves house only the house number changes, the entire address does not have to be replaced, but simply replacing the house number with the new house number in to update the EF containing the address. Another example is an extensive certificate in which the validity of the signature has expired. Embodiments of the present invention allow only the signature of the certificate to be replaced without having to replace the entire certificate.

According to one embodiment, the first personalization data is read before updating, a starting point within the memory length of the EF for updating the first personalization data is determined on the basis of the first personalization data read out, and the first personalization data is updated by overwriting it with the second personalization data.

Embodiments of the invention can have the advantage that a starting point for updating the personalization data is also possible without knowledge of the first personalization data. When using an offset value in the write command, the content of the personalization data or its structure must be known when the write command is created in order to be able to determine which section corresponds to the data to be updated. Determining the starting point on the basis of personalization data, which is only read out in the course of the writing process, makes it possible to replace data even without the relevant prior knowledge. The starting point can be set either automatically or manually. The read out first personalization data on the value or security document or the terminal can thus be analyzed, for example on the basis of corresponding criteria which are defined in the write command. Alternatively, the corresponding data can be displayed, for example, on a display device of the terminal, so that a user of the terminal can manually specify which sections of the personalization data are to be updated.

Corresponding second personalization data can be provided to the terminal automatically, for example via an encrypted internet connection. Alternatively, the corresponding personalization data can be pre-installed on the terminal or can be loaded using appropriate updates, for example at predefined time intervals. Furthermore, the corresponding second personalization data can be specified by manual input by a user of the terminal who has previously authenticated himself and has provided appropriate proof of authorization.

In the above-mentioned example of a change of address, the terminal can be a corresponding terminal of a city administration, to which the user can independently report his change of address. To do this, the user makes the necessary entries on the terminal and at the same time changes the address stored in the corresponding EF.

• Nach dem Schreiben der zweiten Personalisierungsdaten, Verschieben der nachgeordneten Abschnitts an das Ende der zweiten Personalisierungsdaten,
• Festlegen des Endes des nachgeordneten Abschnitts als das logische Ende der aktualisierten Personalisierungsdaten durch Erstellen eines aktualisierten Zeigers, der das logische Ende der aktualisierten Personalisierungsdaten angezeigt.

According to one embodiment, the write command comprises a command for retaining a section of the first personalization data which is subordinate to a section of the first personalization data to be updated, the retention of the subordinate section comprising:

• After writing the second personalization data, moving the downstream section to the end of the second personalization data,
• designating the end of the downstream section as the logical end of the updated personalization data by creating an updated pointer that indicates the logical end of the updated personalization data.

According to an embodiment of the invention, the updating comprises a partial physical relocation of the personalization data stored in the EF. Here, the personalization data are copied from their original storage area to another storage area.

In particular, the shifting can be performed as reading the data section to be shifted from the EF and writing the data section read out to a new position shifted from the original position. The new position is selected in such a way that the beginning of the shifted section is directly connected to the end of the second personalization data. Writing the moved section overwrites the original data.

This can have the advantage that the data section to be moved does not have to be additionally provided by the terminal as part of the second personalization data, but rather the data already provided by the value or security document is used for this purpose, which already contains the corresponding data section contain.

Embodiments of the invention can have the advantage that data sections within the first personalization data can also be updated, with the subsequent personalization data being at least partially retained. If, for example, an updated middle section of the personalization data is shorter than the preceding logically equivalent middle section, residual data remain within the personalization data, which can lead to problems in the interpretation of data to be read out. In principle, this can be avoided by updating the entire personalization data, i.e. overwriting it, and by updating the pointer to the logical end of the updated personalization data, complications due to residual data remaining at the end of the file are prevented. However, this can be time-consuming in the case of extensive personalization data. If only a short remaining section of the first personalization data is to be retained, it can be significantly more efficient to physically move or copy this remaining section in such a way that it is indirectly connected to the updated partial section of the personalization data.

Embodiments of the present inventive method can advantageously also be applied to personalization data with a TLV structure.

According to embodiments, personalization data can be created in the form of a TLV (Tag Length Value) structure. A TLV structure is a data structure intended to simplify the organization of data. For this purpose, in addition to the content of the data structure (value), an identifier for the type of data contained (tag) and the length of the data object is also specified in a header of the structure. If a program that can only process a certain type of data object, for example, processes a series of TLV structures, it can first check whether the data content of a TLV structure can be processed at all by reading the tag of the TLV structure. If the program determines that the type of data contained cannot be processed with the program, the program can simply skip the TLV structure, since the length of the structure is specified in the value L.

According to embodiments of the invention, at the beginning of the update of the first personalization data, the chip card operating system initially sets a flag in the non-volatile electronic memory of the value or security document, which indicates the start of the update process for updating the first personalization data, and the flag after the Updating the pointer is cleared. The flag initially set in the protected electronic memory for updating the personalization data indicates that the personalization data is to be changed. Only after the pointer to the logical end of the updated personalization data has been updated is the flag reset.

This has the advantage that if the change process is aborted, for example by removing the value or security document from the terminal, the personalization data has not been changed only partially or incorrectly, or an incorrect logical end is indicated by a pointer that has not been updated. If the chip card operating system determines when using the value or security document that the flag is set in the protected electronic memory, this means that the value or security document cannot initially be used. According to embodiments of the invention, it can be provided in such a case that the state of the value or security document before the start of the change process is restored, after which the flag is reset and the value or security document is ready for operation again. This can be achieved in that each step in the change process is logged by log files from the chip card operating system, so that changes made can be reversed using these log files.

According to one embodiment of the invention, the terminal of the chip card system is a reading device for an official document, such as a reading device for an electronic identity card, an electronic residence permit or an electronic passport.

• Einziehen des Wert- oder Sicherheitsdokument in den mechanischen Einzug des Terminals, so dass sich das Wert- oder Sicherheitsdokument nach dem Einziehen vollständig innerhalb des Gehäuses des Terminals befindet,
• Nachladen der zweiten Personalisierungsdaten auf das Wert- oder Sicherheitsdokument zum Aktualisieren der ersten Personalisierungsdaten durch die zweiten Personalisierungsdaten,
• Auswerfen des Wert- oder Sicherheitsdokument aus dem mechanischen Einzug des Terminals nach Abschluss der Aktualisierung.

According to one embodiment, the terminal has at least one electronic memory, a contactless communication interface, a closed housing and a mechanical feeder, the mechanical feeder being configured to secure the value or security document against removal from the terminal, the method further which has the following:

• Pulling the valuable or security document into the terminal's mechanical feeder so that the valuable or security document is completely inside the terminal's housing after being drawn in,
• Reloading the second personalization data onto the value or security document to update the first personalization data with the second personalization data,
• Ejection of the value or security document from the terminal's mechanical feeder after the update is complete.

In order to update the personalization data, the value or security document is first drawn into the mechanical feeder of the terminal, so that the value or security document is completely inside the housing of the terminal after it has been drawn in. It can hereby be ensured that the value or security document is not removed from the terminal while the personalization data is being updated, since otherwise data loss could be caused by an interruption in the communication connection. Finally, the document is ejected from the mechanical feeder. Ejection is to be understood here as meaning that the document is released by the mechanical feed to such an extent that a document holder can remove the document from the terminal. This can be done, for example, by ejection in the sense of a movement of the document from the mechanical feeder happen or the mechanical feeder can release a flap or opening, for example, so that the document can be gripped with the hands within the mechanical feeder.

According to one embodiment, the value or security document has a first contactless communication interface, while the terminal has a second contactless communication interface. The method then includes setting up a communication connection between the terminal and the value or security document via the first and second contactless communication interface. The transmission of the second personalization data into the protected, non-volatile memory area of the value or security document then takes place via precisely this communication link.

The communication connection can be an RFID or NFC connection, for example. In particular, the combination of contactless communication between the value or security document and the terminal and the drawing of the value or security document into a mechanical feed could have the advantage that the mechanical feed prevents premature removal of the value or security document from the effective range of the terminal while at the same time the means for contactless communication between the value or security document and the terminal can be embedded in the value or security document. Contacts that are used for contact-based data transmission could wear out due to the friction that usually occurs when using a mechanical feed. However, this risk is effectively avoided by embedding, for example, an antenna in the value or security document body, in which case the antenna does not protrude from the value or security document at any point.

According to one embodiment, the establishment of the communication link between the terminal and the value or security document includes a mutual authentication of the terminal and the value or security document. This will according to the invention, a secure communication channel is set up between the terminal and value or security document. The personalization data is then transmitted exclusively via this secure communication channel. Provision is also made for the terminal to have access to personalization data stored in the non-volatile memory of the value or security document after successful authentication with respect to the value or security document.

Embodiments of the invention could have the advantage that by securing the communication between the value or security document and the terminal, spying out of the transmitted personalization data can be prevented. For example, according to a further embodiment, a challenge-response method can be used for authentication. For example, authentication can be performed using the Basic Access Control (BAC) method or using the Password Authenticated Connection Establishment (PACE) method.

According to a further embodiment of the invention, after the second personalization data has been transferred to the non-volatile memory of the value or security document, the terminal deletes the second personalization data from the electronic memory of the terminal. This could prevent the personalization data from being subsequently read out of the terminal and possibly misused. Another embodiment follows the same basic idea, according to which the electronic memory of the terminal is a volatile memory. For example, the electronic memory of the terminal could be designed as a random access memory (RAM). This would have the advantage that when the terminal is switched off, all the personalization data stored in the terminal's memory from previous compression processes are automatically deleted. A targeted deletion of the personalization data from the memory of the terminal is then no longer necessary.

According to a further embodiment, a reloading token is used in the course of the method according to the invention, the value or security document second personalization data to be reloaded are contained on the reload token, the reload token being connected to the terminal at the beginning of the method, the connection between the terminal and reload token being configured for data transmission between the terminal and reload token, the terminal being configured to load the second personalization data to be reloaded to extract from the reload token and transfer it to the non-volatile electronic memory of the value or security document. For example, the reload token can be a smart card that is inserted into the terminal. The connection between the terminal and the reload token is configured for data transmission between the terminal and the reload token.

According to a further embodiment, the value or security document contains a certificate with a public key of an asymmetric key pair. The second personalization data to be reloaded onto the value or security document, which are contained in a reload token, for example, then contain a cryptographic signature, with the value or security document being configured, after receiving the personalization data to be reloaded from the terminal, to match the cryptographic signature of the received data with the public Verify the certificate key. Furthermore, the value or security document is configured to delete subsequently loaded second personalization data whose signature cannot be verified with the public key from the non-volatile memory of the value or security document. Since the public key or the certificate is usually stored in the value or security document during the production or configuration process of the value or security document, a value or security document issuer can thereby specify who is to reload data onto the value or security document can and who can't. Thus, only parties who have been provided with the appropriate private key by the issuer of the value or security document, which can generate a signature, can load data onto the value or security document. which can be verified with the public key of the asymmetric key pair.

According to one embodiment, the terminal comprises an energy source, the energy source being a self-contained internal energy source and/or an external energy source.

Embodiments could have the advantage that when using an internal energy source, the terminal can be designed as a portable device that is completely self-sufficient. Such a self-sufficiency would improve the security of the terminal against access by unauthorized persons, since communication only takes place between the value or security document and the terminal. Furthermore, a combination of an internal energy source, such as a battery, and an external energy source, such as a mains connection, can improve the reliability of the terminal since the probability of both energy sources failing is lower than the probability of one of the energy sources failing.

According to one embodiment, the terminal includes an authentication token, with the authentication token containing data for authentication of a user of the terminal, with the authentication token being able to be configured as an exchangeable physical data carrier. Here, too, the data carrier can be another chip card, for example.

Embodiments could have the advantage that the terminal can be used by a large number of different users by exchanging the authentication token. However, this also ensures that only the user whose authentication token is currently connected to the terminal can use the terminal. It can be provided that the terminal independently checks whether a user whose authentication token is currently inserted in the terminal is actually authorized to use the terminal.

According to one embodiment, the value or security document is an electronic identification document, in particular a passport, identity card, visa, driver's license, vehicle registration document, vehicle registration document, company ID card, a health card, signature cards, SIM cards and/or an electronic means of payment, in particular a Bank note, bank card, credit card, bill of lading and/or other proof of entitlement.

In the following, embodiments of the invention are explained in more detail with reference to the drawings.

Figuren 1a bis e

schematische Darstellungen von Datenbelegungen von EFs,

Figur 2

ein Blockdiagramm eines Systems aus Terminal und Wert- oder Sicherheitsdokument zur Ausführung eines erfindungsgemäßen Verfahrens,

Figur 3

ein Blockdiagramm einer nicht erfindungsgemäßen Ausführungsform aus Terminal und Wert- oder Sicherheitsdokument,

Figur 4

eine schematische Darstellung des Verfahrens zum Aktualisieren von Personalisierungsdaten,

Figur 5

eine weitere schematische Darstellung des Verfahrens zum Aktualisieren von Personalisierungsdaten,

Figur 6

eine weitere schematische Darstellung des Verfahrens zum Aktualisieren von Personalisierungsdaten, und

Figuren 7a bis c

eine weitere schematische Darstellung des Verfahrens zum Aktualisieren von Personalisierungsdaten.

Show it:

Figures 1a to e

schematic representations of data assignments of EFs,

figure 2

a block diagram of a system consisting of a terminal and a value or security document for carrying out a method according to the invention,

figure 3

a block diagram of a non-inventive embodiment of terminal and value or security document,

figure 4

a schematic representation of the method for updating personalization data,

figure 5

a further schematic representation of the method for updating personalization data,

figure 6

a further schematic representation of the method for updating personalization data, and

Figures 7a to c

a further schematic representation of the method for updating personalization data.

Elements that are similar to one another are identified below with the same reference symbols.

Figure 1a 13 shows an EF 132 with a predefined physical memory length, which represents the block of memory reserved for the EF 132. FIG. The physical end 166 designates the physical end of the reserved memory block. Since no personalization data 140 is stored, the logical end of file 141 is zero. Is a file 162, as in Figure 1b shown, longer than the predefined physical storage length of the EF 132, ie if the logical end 163 of the second personalization data 162 to be stored is beyond the physical end 166, the update process is aborted. Figure 1c shows an EF 132 with first personalization data 140, the end of which defines the logical end 141.

Figure 1d 12 shows a case where the logical end 164 of the updated personalization data, which corresponds to the logical end 163 of the second personalization data 162, lies beyond the logical end 141 of the first personalization data 140. In this case, the second personalization data 162 is longer than the first personalization data 140. Thus, when the first personalization data 140 is overwritten with the second personalization data 162, no residual data of the first personalization data 140 remain in the EF 132. Figure 1e shows a situation when first personalization data 140 is overwritten with second personalization data 162, in which the second personalization data 162 is shorter than the first personalization data 140. In this case, the logical end 163 of the second personalization data 162, ie the logical end 164 of the updated personalization data, lies before the logical end 141 of the first personalization data 140 Residual data 170 are also read out, the logical end 163 of the second personalization data 162 is identified as the logical end 164 of the updated personalization data.

For this purpose, the pointer 136 is updated accordingly, so that it points to the logical end 163 or 164.

the figure 2 shows a system 100 from a terminal 102 and a value or security document 110 in the form of a chip card. In the embodiment shown here, the terminal 102 contains a communication interface 108, a processor 104 and a memory 101 for temporarily storing second personalization data 162. The memory 101 can be a non-volatile flash-based memory, for example. The terminal 102 shown also includes an authentication token 107, a reload token 105, a further communication interface 109 and an energy source 103. The authentication token 107 and the second communication interface 109 are optional features of the terminal 102.

The energy source 103 can be, for example, a battery or a power-generating unit such as a fuel cell or a solar cell. The use of such a closed energy source 103 could have the advantage that the terminal 102 can be made completely self-sufficient on the one hand and portable on the other. However, the energy source 103 can also be a power pack or some other type of connection to an external energy supply. Furthermore, a combination of external and internal energy supply is also possible, which would improve the failsafety of the terminal 102.

The memory 101 can be both a volatile and a non-volatile memory. In this context, it can be useful for the memory 101 to be configured as a volatile memory for the temporary storage of second personalization data 162 . This would have the particular advantage that after the terminal 102 has been switched off and the personalization data on the value or security document 110 has been successfully updated, the second personalization data 162 stored in the terminal 102 for the update is automatically updated would be deleted. This would prevent the second personalization data 162 from being misused by subsequent reading out of the terminal 102 .

The value or security document 110 includes a chip card operating system 118 and a chip card file system 117 with a logical data structure that includes EFs 132, 142 with personalization data 140,150. Control data 128, 134, 144 are also stored in the chip card file system 117, wherein the control data 128 can be assigned to an MF 126, while the control data 134 and 144 are each assigned to an EF 132, 142 and thus to a set of personalization data 140, 150. In this case, the control data 134 and 144 also each include a pointer that refers to the logical end 136, 146 of the associated personalization data 140, 150 (not claimed embodiment).

As in figure 2 indicated schematically, communication between the terminal 102 and the value or security document 110 is made possible by the communication interface 108 of the terminal 102 . For example, the value or security document 110 can be addressed through the communication interface 108, as a result of which an updating or reloading process can be initiated. In this case, the communication interface 108 can be configured in accordance with ISO 14443, for example. In order to set up such a communication, provision can be made for an identification and authentication process to be carried out between the value or security document 110 and the terminal 102 first. A corresponding application program 106 can be provided in the processor 104 of the terminal 102 for this purpose. For example, a mutual exchange of security certificates can be provided in the course of the authentication method, which are stored in the memory 124 of the value or security document 110 or in a corresponding authentication token 107 of the terminal 102 . However, the authentication methods that are possible within the meaning of the present invention are not limited to this.

As soon as a secure data connection has been established between the value or security document 110 and the terminal 102, the processor 104 of the Terminals 102, for example by means of the application program 106, store second personalization data 162, which are stored, for example, in the reload token 105 of the terminal 102, in the memory 124 of the value or security document 110. In this case, it can be provided that an indicator ID is also transmitted to the value or security document 110, for example as part of a corresponding APDU 158, in which the value or security document 110 about the identity of the storage of the second personalization data 162 provided EFs 132 is informed.

The further communication interface 109 of the terminal 102 can be configured for the administration of the terminal 102, for example. The communication interface 109 can be an Ethernet connection, for example. The authentication token 107 and the reload token 105 can be designed both as a software token and as a hardware token, for example in the form of a chip card for insertion into the terminal 102 . For example, the reload token 105 can be supplied by a manufacturer of the value or security document to be updated. However, it is also possible for the reload token 105 to be permanently installed in the terminal 102 so that manufacturer-specific update data would have to be transmitted to the terminal 102 via the communication interface 109 . The reload token 105 can also be configured as a storage area within the terminal 102 . Accordingly, second personalization data 162 can be stored in the memory 101 and/or in the reload token 105 . Different update data can also be stored in memory 101 and in reload token 105 .

The communication interface 108, via which communication between the terminal 102 and the value or security document 110 is to be ensured, can additionally have a mechanical feeder for partially or completely receiving the value or security document 110 in the terminal 102. In this case, the collection can be such that the valuable or security document 110 is withdrawn at least for the duration of the reloading process before removal the terminal 102 by a user. This ensures uninterrupted communication and power supply during the reloading process.

As already explained above, the terminal 102 is configured to replace at least parts of the personalization data 140, 150 stored in the value or security document 110 in the course of a reloading process. The reloading process is a multi-part process that is preceded by an initialization. In the initialization, the second personalization data 162 for updating is either uploaded to the terminal 102 as a software token via the communication interface 109 or introduced into the terminal 102 as a hardware token 105 .

the figure 3 shows a chip card system 100 with a terminal 102. The terminal 102 can be, for example, a reading device for an official document, in particular for an electronic identity card, an electronic residence permit or an electronic passport. Terminal 102 has a processor 104 for executing an application program 106, which is interoperable with a value or security document 110 in the form of a chip card, and an interface 108 for establishing a communication link with a corresponding interface 112 of chip card 110.

The interfaces 108 and 112 are configured as contactless interfaces, in particular as RFID or NFC interfaces. The chip card 110 preferably does not have its own energy supply, but is supplied with electrical energy by coupling electromagnetic energy from the interface 108 into the interface 112, for which purpose the interface 112 has an antenna.

The smart card 110 has a processor 114 for executing a program module 116 for the authentication of the terminal 102 or the mutual authentication of the terminal 102 and the smart card 110. For this purpose, the program module 116, for example, those steps of a challenge-response protocol implement, which concern the chip card 110, wherein the application program 106 can then implement those steps of the challenge-response protocol, which concern the terminal 102. Another possibility is authentication by means of a secret identifier, for example a so-called PIN, which a user enters into the terminal and which is checked by the program module 116, for example according to the PACE protocol, as specified by the Federal Office for Information Security ( BSI) has been specified.

The processor 114 is also used to run a chip card operating system 118 and has a volatile main memory 120. The processor 116 is connected to the interface 112 of the chip card 110 and via an internal data bus 122 to a non-volatile, protected electronic memory 124.

Files of a chip card file system 117 are stored in the memory 124 and form a file tree. the figure 3 shows an example of a MF 126 of the file tree, not according to the invention, which contains control data 128 including a pointer 130 to a successor node, ie the EF 132 . The unclaimed EF 132 also includes control data 134, including a pointer 138 to its child node in the file tree, namely an EF 142, and a pointer 136 to the logical end of the personalization data 140 also stored in the EF 132.

A structure analogous thereto has unclaimed EF 142, which includes control data 144, including a pointer 146 to the logical end of the personalization data 150 also stored in the EF 142 and a pointer 148 to one in the figure 3 child nodes, not shown, of EF 142 in the file tree.

In the course of the update, the chip card 110 receives second personalization data 162 from the terminal 102, for example by the application program 106 sending a command APDU 158 from the interface 108 to the interface 112, which contains the second personalization data 162 and a specification ID of the EF of the chip card file system 117 whose personalization data are to be changed. Without loss of generality, the following is an example assumed that this is the EF 132 or its personalization data 140.

In addition, a flag F 152 is shown in the memory 124, which the chip card operating system 118 initially sets at the beginning of the update process and deletes it again after its completion. Furthermore, together with the flag F 152, a log file P can also be created in the memory 124 in order to log the steps of the update process.

The following is now based on the figure 4 an embodiment of the update process according to the invention is described.

In a first step of the in figure 4 illustrated procedure for reloading personalization data 162 from a terminal 102 on a value or security document 110, the terminal 102 is activated. In this case, for example, activation can take place by actuating a power switch, or the terminal 102 can be configured in such a way that it is woken up from an idle state when a value or security document 110 is inserted into a corresponding mechanical feeder. An operator authentication can then be provided, for example by means of a password query, which, if successful, initiates the update process. To do this, however, the terminal 102 must have a suitable input option, such as a keyboard, and the authentication token 107 .

After the terminal 102 has been activated, energy is transferred to the value or security document 110, whereby the value or security document 110 is also activated. A communication channel is then set up between the terminal 102 and the value or security document 110 . This can be done, for example, by inserting the value or security document 110 into the slot of a card reader or by setting up a wireless connection.

The terminal 102 and the value or security document 110 are then mutually authenticated, so that a secure channel can be set up between the terminal 102 and the value or security document 110 . For this purpose, corresponding authentication data can be stored in the terminal 102, for example in the authentication token 107, which are used in the course of the mutual authentication. A necessary authorization of the terminal 102 for reloading data into the value or security document 110 is obtained by the authentication of the terminal 102 with respect to the value or security document 110 .

In order to be able to write personalization data 162 into an EF 132 of the value or security document 110, the terminal 102 transmits cryptographic information to the value or security document 110 as proof of an access authorization, the transmitted cryptographic information fulfilling a cryptographic access condition of the EF 132.

In a subsequent method step, the terminal generates or activates an already existing key for encrypting all or part of the second personalization data 162 and the associated write command. The second personalization data 162 and the associated write command are then transmitted in encrypted form from the terminal 102 to the value or security document 110 via the secure channel.

The second personalization data 162 on the value or security document 110 is then decrypted and written to the EF 132 in accordance with the write command in order to update the first personalization data 140 .

Then the pointer 136 is updated to point to the logical end 164 of the updated personalization data. The successful implementation of the update is confirmed by the value or security document 110 to the terminal 102 by transmitting a response with a write confirmation.

The connection and the secure channel between the terminal 102 and the value or security document 110 are then cleared and the power supply is terminated. As a result, the value or security document 110 is deactivated.

If the value or security document 110 was drawn into a corresponding mechanical feeder of the terminal 102, the value or security document 110 is issued and the terminal 102 is deactivated again.

The procedure for updating the personalization data 140 of the EF 132 can be as follows, for example, as in FIG figure 5 shown:
In step 500, the terminal 102 is first authenticated with respect to the chip card 110. In addition to the authentication, an authorization check can also be carried out, namely whether the terminal 102 has the necessary rights to change personalization data 140. This can be done, for example, by the terminal 102 transmitting an authorization certificate to the chip card 110, the rights of the terminal 102 to change the personalization data 140 being specified in the authorization certificate. The authorization certificate contains cryptographic information that satisfies a cryptographic access condition of the EF 132 defined in the control data 134 .

In step 502, the chip card 110 receives second personalization data 162 from the terminal 102, for example by the application program 106 sending a command APDU 158 from the interface 108 to the interface 112, which contains the second personalization data 162 and also a specification ID of the EF of the Chip card file system whose first personalization data are to be changed. This is, for example, the EF 132 or its personalization data 140 without loss of generality.

In step 504, the chip card operating system 118 sets a flag F 152 in the memory 124. A log file P can also be created in the memory 124 to log the subsequent steps of the update process.

In step 506, the chip card operating system 118 accesses the memory 124 via the internal data bus 122 and partially overwrites the first personalization data 140 with the second personalization data 162 of the APDU 158, thereby replacing the previous version of the personalization data 140. The second personalization data 162 is shorter in this case than the first personalization data 140, so only partial overwriting occurs. A remainder of the previous version of the personalization data 140 remains in the EF 132 and is arranged immediately following the logical end 163 of the second personalization data 162, the logical end 163 of the second personalization data 162 in the present case being aligned with the logical end 164 of the updated personalization data coincides.

The command APDU 158 contains the personalization data 162 and an identifier (ID) 160 of that file whose personalization data are to be changed, here the EF 132 whose personalization data 140 are to be changed.

In step 508, the pointer 136 is then updated so that it no longer points to the logical end 141 of the personalization data 140 but to the logical end 164 of the updated personalization data. In the present example, the logical end 163 of the second personalization data 162 coincides with the logical end 164 of the updated personalization data. The rest of the data in the data system can remain unchanged.

After the process of changing the personalization data 140 has been completed in this way, the flag 152 is reset in step 510 and the log file 154 is deleted.

Finally, in step 512 a reply with a write confirmation is generated from the value or security document and sent to the terminal 102 in step 514 via the contactless communication interface 112 .

Another example for an update of the personalization data 140 is given in figure 6 shown:
Steps 600, 602, 604, and 606 correspond to steps 500, 502, 504, and 506 of FIG figure 5 . Step 606 is followed by step 607, in which it is checked on the basis of an indicator in the write command whether it is a final write command or whether further write commands follow. If another write command follows, step 606 is repeated with the following write command. The corresponding loop is run through until a corresponding indicator identifies a write command as the final write command. In this case the method continues with step 608 . The further steps 608, 610, 612 and 614 correspond to the steps 508, 510, 512 and 514 from figure 5 .

the Figures 7a to 7c Schematic representations of an update method according to the invention are shown. Figure 7a shows an EF 132, which has first personalization data 140. This personalization data 140 is divided into three sections 140', 140' and 140'. The logical end 141 of the first personalization data 140 is defined by the end of the third section 140‴. In the course of an update of the first personalization data 140 with second personalization data 162, only the middle section 140" of the first personalization data 140 is to be replaced by the second personalization data 162. In contrast, the third section 140‴ is to be retained. For this purpose, the corresponding write command has an offset value, which 'corresponds to the length of the first section 140. Thus, as in Figure 7b shown, the middle section 140 'overwritten from the end of the first section 140' with the second update data 162 . Since the second update data 162 is shorter than the middle section 140" of the first personalization data 140, undesired residual data 170' remain. In order to avoid the residual data 170' and at the same time to completely retain the last subsection 140‴, the last subsection 140‴ is physically shifted to the logical end 163 of the second personalization data 162. This physical shifting can take place, for example, by reading out the last subsection 140‴ to be shifted from the EF 132 and writing the subsection 140‴ to the logical end 163 of the second personalization data 162. As a result, residual data 170 remains at the end of the updated data block, but this can be ignored by setting the pointer 136 to the end of the shifted subsection 140‴. The end of the shifted third section 140‴ is thus defined as the logical end 164 of the updated personalization data. As a result, the residual data 170 between the logical end 164 and the logical end 141 of the first personalization data will no longer be read out in future read-out processes, since a read-out only takes place up to the point specified by the pointer 136 .

Reference List

100

chip card system

101

Storage

102

terminal

103

energy source

104

processor

105

reload token

106

program

107

authentication token

108

interface

109

interface

110

value or security document

112

interface

114

processor

116

program

117

smart card file system

118

chip card operating system

120

random access memory

122

data bus

124

Storage

126

Master File (MF)

128

control data

130

pointer

132

Elementary File (EF)

134

control data

136

pointer

138

pointer

140

Personalization Data

140'

Personalization Data subsection

140"

Personalization Data subsection

140‴

Personalization Data subsection

141

logical end

162

Personalization Data

142

Elementary File (EF)

144

control data

146

pointer

148

pointer

150

Personalization Data

151

logical end

152

Flag (F)

154

log file (P)

158

APDU

160

identifier

162

Personalization Data

163

logical end

164

logical end

166

physical end

170

residual data

170'

residual data

Claims (13)

1. A method for updating first personalisation data (140) of a value document or security document (110) by means of second personalisation data (162), wherein

   the value document or security document (110) has a non-volatile electronic memory (124) having a chip card operating system (118) and having a chip card file system (117), wherein the chip card file system (117) comprises a dedicated file (126) having at least one elementary file (132),

   wherein the elementary file (132) has a predefined physical storage length,

   wherein the elementary file (132) comprises control data (134) and first personalisation data (140),

   wherein the control data (134) comprise a cryptographic access condition and reading and/or writing in the elementary file (132) is possible only if the cryptographic access condition is fulfilled, and wherein

   a pointer (136) is stored in the chip card file system (117), which pointer indicates the logical end (141) of the first personalisation data (140) in the elementary file (132), wherein the value document or security document (110) also has a contactless communication interface (112) for receiving and transmitting personalisation data (162), wherein the updating of the first personalisation data (140) with second personalisation data (162) comprises:

   • coupling electrical energy into the value document or security document (110) via the contactless communication interface (112) to supply power to the value document or security document (110) by a terminal (102),

   • authenticating the terminal (102) and value document or security document (110) to one another and demonstrating access authorisation via the contactless communication interface (112), wherein the demonstration of access authorisation comprises at least a transmission of cryptographic information from the terminal (102) to the value document or security document (110), wherein the transmitted cryptographic information satisfies the cryptographic access condition of the elementary file (132),

   on the condition of successful mutual authentication and at least fulfilment of the cryptographic access condition of the elementary file (132):

   • receiving a first writing command of the terminal (102) to update the first personalisation data (140) in the elementary file (132) with the second personalisation data (162) via the contactless communication interface (112), wherein the chip card operating system (118) is configured such that the chip card operating system performs the following functions in response to the receipt of the writing command:

   • updating the first personalisation data (140) by writing the second personalisation data (162) into the elementary file (132),

   • determining the logical end (163) of the updated personalisation data,

   • creating an updated pointer (136) that indicates the logical end (163) of the updated personalisation data,

   • storing the updated pointer (136) in the chip card file system (117),

   • creating a response with a writing confirmation, and

   • sending the response via the contactless communication interface (112) to the terminal (102),

   wherein the dedicated file (126) comprises a plurality of elementary files (132, 142) and a pointer table, wherein the pointer table assigns each elementary file (132, 142) a pointer (136, 146) which indicates the logical end (141, 151) of the personalisation data (140, 150) stored in the assigned elementary file (132, 142).
2. The method according to one of the preceding claims, wherein the updated personalisation data are shorter than the first personalisation data (140), so that the logical end (163) of the updated personalisation data is arranged before the logical end (141) of the first personalisation data (140).
3. The method according to one of the preceding claims, wherein the method, prior to the writing of the second personalisation data (162), performs the following checks:

   • determining the length of the elementary file (132) necessary for the writing process,

   • determining whether the length of the elementary file (132) corresponds at least to the previously determined length, wherein the method is continued only if the length of the elementary file (132) is greater than or equal to the previously determined length.
4. The method according to claim 3, wherein the determination of the length of the elementary file (132) necessary for the writing process comprises:

   • determining the logical end (141) of the first personalisation data (140) by reading the pointer (136) from the chip card file system (117),

   • determining the anticipated logical end (163) of the updated personalisation data as a result of the updating of the first personalisation data (140) in the elementary file (132) on the basis of the length of the second personalisation data (162).
5. The method according to one of the preceding claims, wherein the logical file end (164) after the writing of the second personalisation data (162) is set at the end (163) of the second personalisation data (162) by creating an updated pointer (136) which indicates the logical end (164) of the updated personalisation data.
6. The method according to one of claims 1 to 4, wherein the writing command is a writing command from a sequence of writing commands, wherein a last writing command from the sequence of writing commands comprises an indicator which indicates that the last writing command is a terminating writing command, and wherein the preceding writing commands each comprise an indicator which indicates that a further writing command follows.
7. The method according to claim 6, wherein the method comprises:

   before the updating of the pointer (136), checking on the basis of the indicator whether the writing command is a terminating writing command: if the writing command is not a terminating writing command, performing the next writing command in the sequence; if the writing command is a terminating writing command,

   setting the logical file end (164), once the terminating writing command has been performed, to the end of the updated personalisation data by creating an updated pointer (136) which indicates the logical end (164) of the updated personalisation data.
8. The method according to one of claims 1 to 4, wherein the logical file end (164), in response to a selection of another file and/or another directory, is set to the end of the updated personalisation data by creating an updated pointer (136) which indicates the logical end (164) of the updated personalisation data.
9. The method according to one of the preceding claims, wherein the updating of the first personalisation data (140) is performed by overwriting with the second personalisation data (162) starting at the beginning of the first personalisation data (140).
10. The method according to one of claims 1 to 8, wherein the writing command comprises an offset value which determines a starting point within the storage length of the elementary file (132) for the updating of the first personalisation data (140), and the first personalisation data (140) are updated by overwriting with the second personalisation data (162), or
    wherein the first personalisation data (140) are read before being updated, a starting point within the storage length of the elementary file (132) for the updating of the first personalisation data (140) is determined on the basis of the read first personalisation data (140), and the first personalisation data (140) are updated by overwriting with the second personalisation data (162).
11. The method according to one of the preceding claims, wherein the writing command comprises a command for retaining a portion (140‴) of the first personalisation data (140) which is arranged downstream of a portion (140ʺ) of the first personalisation data (140) that is to be updated, wherein the retention of the downstream portion (140") comprises:

    • after the writing of the second personalisation data (162), wherein the second personalisation data (162) are shorter than the portion (140ʺ) of the first personalisation data (140) that is to be updated, shifting the downstream portion (140ʺ) to the end of the second personalisation data (162),

    • defining the end of the downstream portion (140ʺ) as the logical end (164) of the updated personalisation data by creating an updated pointer (136) which indicates the logical end (164) of the updated personalisation data.
12. The method according to one of the preceding claims, wherein, at the start of the updating of the first personalisation data (140), a flag (152) is initially set by the chip card operating system (118) in the non-volatile electronic memory (124) of the value document or security document (110), which flag indicates the start of the updating process for updating the first personalisation data (140), and wherein the flag (152) is deleted once the pointer (136) has been updated, and/or

    also comprising a download token (105), wherein the second personalisation data (162) to be downloaded to the value document or security document (110) are contained on the download token (105), wherein the download token (105) is connected at the start of the method to the terminal (102), wherein the connection between terminal (102) and download token (105) is configured for a data transfer between terminal (102) and download token (105), wherein the terminal (102) is configured to extract from the download token (105) the second personalisation data (162) that are to be downloaded and to transfer said data into the non-volatile electronic memory (124) of the value document or security document (110), and/or

    wherein the value document and/or security document (110) contains a certificate with a public key of an asymmetric key pair, wherein the second personalisation data (162) to be downloaded onto the value document or security document (110) contain a cryptographic signature, wherein the value document or security document (110) is configured, after receipt from the terminal (102) of the second personalisation data (162) to be downloaded, to verify the cryptographic signature of the received second personalisation data (162) with the public key of the certificate, wherein the value document or security document (110) deletes from the non-volatile electronic memory (124) of the value document or security document (110) any downloaded second personalisation data (162) for which signing with the public key cannot be verified.
13. The method according to one of the preceding claims, wherein the terminal (102) has at least one electronic memory (101), a contactless communication interface (108, 109), a closed housing and a mechanical feeder, wherein the mechanical feeder is configured to secure the value document or security document (110) against removal from the terminal, wherein the method also comprises the following:

    • feeding the value document or security document (110) into the mechanical feeder of the terminal (102) so that the value document or security document (110), after having been fed in, is located fully within the housing of the terminal (102),

    • downloading the second personalisation data (162) to the value document or security document (110) to update the first personalisation data (140) by the second personalisation data (162),

    • ejecting the value document or security document (110) from the mechanical feeder of the terminal (102) once the update is complete.

Images