PROCEDURE FOR UPDATING PERSONALIZATION DATA

Description

[0001] 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.

[0002] State-of-the-art sovereign valuable 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.

[0003] The prior art includes a variety of documents, particularly security or identification documents, that are implemented as chip cards with computing logic. Personalization data such as passport photos, fingerprints, or similar data are typically stored in a non-volatile memory area of ​​the chip card. These data can be used by a processor in the chip card, for example, during an authentication process to determine the identity of a document holder.

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

[0005] If the data stored in an elementary file is to be updated, i.e., replaced, with new data, problems can arise if the updated data overwriting the original data 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, it may happen that more data is read than expected, because the excess residual data is also read.

[0006] A common workaround in this case is to first overwrite the entire memory block, i.e., the entire file, with zeros, so that the logical end of the file coincides with the physical end of the file. Only after this process is the data to be updated written to the memory block. This usually makes it possible to identify where the updated data ends. However, the data content of the updated data still does not correspond to the written content, since the appended zeros could also be read when reading the written content.

[0007] The excess zeros can cause problems, especially if the chip card creates a signature based on the contents of a file, for example, and this signature is later to be verified outside the card. In this case, it is unclear whether the corresponding zeros are a logical component of the signed data or not. This can lead to problems when verifying signatures on corresponding files.

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

[0009] File structures that include a length specification of a logically related file section, e.g., TLV files, are known from the prior art. If several such TLV files are configured as consecutive file structures, it is not clear without additional information whether the data immediately following the logical file structures delimited by the length specification is negligible residual data or other meaningfully logically related data sections.

[0010] In the "Handbook of Chip Cards: Structure - Functionality - Use of Smart Cards," 4th edition, January 1, 2002, Wolfgang Rankl et al. describe chip cards and TLV structured data.

[0011] WO 2004 / 034202 A2 describes a system for data access and management on a smart card. A memory architecture is provided in the smart card that allows data stored on it to be shared by multiple parties. Access to data stored on the smart card is controlled by various access methods, depending on the actions to be performed on the data to be accessed.

[0012] US 2006 / 071420 A1 describes an entitlement substrate processing module comprising an entitlement substrate rotation device, a first data encoder, and a module controller. The entitlement substrate rotation device comprises a substrate holding device configured to hold a substrate in a substrate holding plane and rotate about a central axis, and a substrate feeding device. The first data encoder is configured to encode data for a substrate presented by the substrate rotation device.

[0013] EP 2 367 115 A1 describes a portable electronic device that executes a process based on a command input from an external device and stores a plurality of TLV data objects. The device comprises a storage unit configured to store the data class and data character of each TLV data object, each in two spaced-apart memory areas, and to store fixed-length addresses representing the positions of the data characters associated with each of the data classes.

[0014] The article "Secure File Management System for Java Cards" by Reza Asgari et al., in International Journal in Foundations of Computer Science & Technology, Vol. 3, No. 5, September 2013, pages 1 to 11, describes a design and implementation of a secure and dynamic file management system for Java cards.

[0015] The ETSI technical specification TS 101 206-3 V1.3.2 (1998-12) "Identification card systems; Telecommunications IC cards and terminals; Part 3: Application independent card requirements" specifies application-independent properties of multi-application integrated circuit (IC) cards and plug-in modules for telecommunications applications in order to ensure interoperability for telecommunications cards with the various systems and terminals.

[0016] The international standard ISO / IEC 7816-4:2005(E) specifies the organization, security and commands for the exchange of identification cards and integrated circuit (IC) cards.

[0017] DE 10 2006 006489 A1 describes a method for performing write access to a memory area of ​​a chip card. A cryptographic method is used to transmit an access command and / or the data to be written to the chip card.

[0018] DE 10 2006 030406 A1 describes a valuable or security document with at least first and second display devices, a processor for controlling the at least first and second display devices, and an interface for supplying energy to the processor from an external energy source.

[0019] The invention is therefore based on the object of creating an improved method for updating personalization data of a value or security document, which in particular also enables a secure change of the personalization data in sovereign applications.

[0020] The problem underlying the invention is solved by the features of the independent patent claims. Embodiments of the invention are specified in the dependent patent claims. Unless expressly stated otherwise, embodiments of the invention may be freely combined with one another.

[0021] According to the invention, a "value or security document" refers to paper-based and / or plastic-based documents, for example, in the form of chip cards. Value or security documents include, for example, electronic identification documents, in particular passports, identity cards, residence permits, visas, as well as driver's 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, waybills, or other forms of authorization into which a data storage device for storing at least one attribute is integrated.

[0022] A valuable 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 item and a communication interface for reading the attribute or personalization data item. Preferably, the document, for example in the form of a chip card, has a secure memory area for storing the at least one attribute to prevent the attribute stored in the memory area from being altered in an unauthorized manner or read without the necessary authorization.

[0023] A "protected memory" is defined below as a non-volatile electronic memory that allows access to data stored in the memory only after verifying a cryptographic access condition. Furthermore, a protected memory may have access management that grants specific users with appropriate access authorization access to data stored in the memory after the user has been identified. However, it is not possible to read or write data from the protected memory without appropriate authorization.

[0024] According to one embodiment, the storage of the valuable or security document is a protected storage.

[0025] Various smart card operating systems with a hierarchical smart card file system are known, as defined, for example, in ISO / IEC 7816-4. Such a smart card file system typically has a root directory called a "master file," abbreviated as MF. Furthermore, a smart card file system has directory files, so-called "dedicated files," abbreviated as DFs. The MF is a special form of DF. A data file is a file dependent on a DF, which is also called an elementary file, abbreviated as EF.

[0026] With JavaCard OS, for example, an MF is not mandatory. In this case, 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 thus a special case of a dedicated file and represents the entire memory available for the data area in a chip card or a valuable or security document.

[0027] The smart card file system can also contain data objects that, 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 EFs.

[0028] Both an EF and a DF can contain control data, such as access conditions for the EF or for the files dependent on a DF. Personalization data is generally stored in the EFs.

[0029] In contrast to personalization data, "control data" of a valuable or security document refers to the associated administrative data, which, in particular, defines at least one access condition for accessing the personalization data. Furthermore, the control data can also contain an indication of the position of the relevant file 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 valuable or security document, as well as, for example, a file identifier (FID) and an application identifier (AID).

[0030] "Personalization data" refers to 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 during runtime (e.g., keys and associated cryptographic parameters) or can be read in compliance with the access conditions stored in the control data (e.g., cardholder data). In particular, "personalization data" refers to data required by a terminal application program that is interoperable with the chip card or a valuable or security document, such as biometric data, in particular fingerprint data, facial biometric data, and / or iris scan data, which a terminal requires for biometric authentication. Such sensitive personalization data may only be read from the chip card or card after prior authentication of the terminal.the valuable or security document can be read, whereby the necessary cryptographic access conditions are specified by the respective control data.

[0031] Particularly with chip cards, the power supply to the chip card's processor is usually provided via an RFID interface through a terminal. If the document were removed from the terminal too early during an update process, the document's power supply would be interrupted and any initiated update process could not be completed. This could potentially render the document unusable. Embodiments of the invention could have the advantage that this risk can be effectively avoided, for example by completely holding the document in a slot or other mechanical holder in the terminal and thus protecting it from access by a user. After the reload process is complete, the document could then be ejected from the terminal's mechanical holder.

[0032] By using contactless communication between the terminal and the document, 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 terminal holder 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, the combination of a mechanical holder with contactless communication can preserve the integrity of the data stored on the document, as premature removal of the document from the terminal can be ruled out. This ensures uninterrupted communication and power supply during the update process.

[0033] Embodiments of the invention can have the advantage that the pointer stored in the chip card file system uniquely defines the logical end of the personalization data in the EFs. This clearly specifies the point up to which the EF is to be read. Data located beyond the logical end specified by the pointer is not read and thus cannot lead to confusion. Furthermore, this can ensure that no unnecessary readout processes are performed or that no unnecessarily large amounts of data are read out. This increases the efficiency of the read process.

[0034] The personalization data could, for example, be the address of the holder of the valuable or security document. When moving, it becomes necessary to update the previously stored personalization data containing the old address with personalization data containing the new address.

[0035] According to one embodiment, the DF is an MF. According to another embodiment, the MF contains additional files, EFs and / or DFs, wherein the DFs can each comprise at least one EF.

[0036] According to one embodiment, the pointer is stored in the control data of the associated EF.

[0037] Embodiments of the invention may have the advantage that the pointer is directly assigned to the associated EF and can be read directly during access to the EF.

[0038] According to one embodiment, the DF comprises a plurality of EFs and a pointer table, wherein the pointer table assigns to each EF a pointer indicating the logical end of the personalization data stored in the associated EF.

[0039] Embodiments of the invention may have the advantage that the pointer information is provided in a central pointer table, thereby increasing the clarity of the system.

[0040] 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 backward, the present invention offers the advantage that the logical end of the updated personalization data is clearly defined.

[0041] According to one embodiment, the updated personalization data is 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.

[0042] According to one embodiment, the method performs the following checks before writing the second personalization data: Determining the length of the EF required for the write operation, determining whether the length of the EF is at least equal to the previously determined length, whereby the process is only continued if the length of the EF is greater than or equal to the previously determined length.

[0043] 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. Thus, errors can be prevented from occurring when writing the updated personalization data.

[0044] According to one embodiment, determining the length of the EF necessary for the write operation comprises: 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 the update of the first personalization data in the EF based on the length of the second personalization data.

[0045] Embodiments of the invention may have the advantage that the expected logical end of the updated personalization data can thus be determined efficiently.

[0046] According to one embodiment, after writing the second personalization data, the logical end of 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.

[0047] Embodiments of the invention may have the advantage that the logical end of file can be determined simply 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.

[0048] According to one embodiment, the write command is a write command of a sequence of write commands, wherein a last write command of the sequence of write commands comprises an indicator indicating that the last write command is a final write command, and wherein the preceding write commands each comprise an indicator indicating that a further write command follows.

[0049] Embodiments of the invention may have the advantage that a plurality of write commands can be used for a plurality of personalization data items. This is advantageous, for example, when the personalization data to be written is very extensive and, for data transmission reasons or predefined data formats, it is necessary 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 of updating different personalization data or parts of personalization data at different locations in 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 another write command follows, while a bit value of 0 indicates that this is the final write command. The pointer is only updated when a bit value of 0 indicates that this is the final write command. Then, the logical end of the file is placed after the most recently updated personalization data.

[0050] 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; setting the logical end of file to the end of the updated personalization data after executing the final write command by creating an updated pointer indicating the logical end of the updated personalization data.

[0051] Embodiments of the invention may have the advantage that the logical end of file can be determined efficiently. No additional information, such as write commands, is required for this. Thus, the entire write process can be designed more efficiently, even in the case of multiple write commands.

[0052] According to one embodiment, in response to a selection of another file and / or directory, the logical end of file is set to the end of the updated personalization data by creating an updated pointer indicating the logical end of the updated personalization data.

[0053] Embodiments of the invention may have the advantage that additional auxiliary constructions such as overwriting the entire contents of the EF with zeros are eliminated. This saves time, and it also eliminates an additional write command that would have to be triggered externally. Furthermore, in update methods according to the present disclosure, the logical content of the EF always matches the actually written content. This means that negligible residual data need not be taken into account during operations on the contents of the EF, such as reading the corresponding personalization data.

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

[0055] Embodiments of the present invention may have the advantage that no additional information about the start of the write operation is necessary, whereby the entire write operation can be made more efficient.

[0056] According to one embodiment, the write command comprises an offset value which determines a starting point within the memory length of the EF for updating the first personalization data, and the first personalization data are updated by overwriting them with the second personalization data.

[0057] Embodiments of the invention can have the advantage that the starting point for updating the personalization data can be selected flexibly. This is advantageous when the personalization data stored in the EF is very extensive and only a small portion of the stored first personalization data needs to be updated with second personalization data. In this case, using an offset value in the write command can prevent the entire personalization data from having to be updated.

[0058] For example, if the first personalization data is the address of the holder of the valuable or security document, and only the house number changes when the holder moves, the entire address does not need to be replaced. Instead, it is sufficient to simply update the house number with the new house number in the EF containing the address. Another example is a comprehensive certificate for which the validity of the signature has expired. Embodiments of the present invention make it possible to replace only the signature of the certificate without having to replace the entire certificate.

[0059] According to one embodiment, the first personalization data are read out 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 read out first personalization data, and the first personalization data are updated by overwriting them with the second personalization data.

[0060] Embodiments of the invention can have the advantage that a starting point for updating the personalization data is possible even 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 creating the write command in order to be able to determine which section corresponds to the data to be updated. Determining the starting point based on personalization data that is only read out during the write process allows data to be replaced even without corresponding prior knowledge. The starting point can be determined both automatically and manually. This allows the read-out first personalization data on the valuable or security document or the terminal to be analyzed, for example, based on corresponding criteria that are specified in the write command.Alternatively, the relevant data may 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 should be updated.

[0061] 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 uploaded via appropriate updates, for example, at predefined intervals. Furthermore, the corresponding second personalization data can be manually entered by a terminal user who has previously authenticated themselves and provided the appropriate credentials.

[0062] For example, in the aforementioned example of an address change, the terminal could be a municipal terminal where the user can independently report their change of address. To do so, the user enters the necessary information on the terminal and simultaneously changes the address stored in the corresponding EF.

[0063] 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, wherein retaining the subordinate section comprises: After writing the second personalization data, moving the subordinate section to the end of the second personalization data, setting the end of the subordinate section as the logical end of the updated personalization data by creating an updated pointer indicating the logical end of the updated personalization data.

[0064] According to one embodiment of the invention, updating comprises a partial physical relocation of the personalization data stored in the EF. The personalization data is copied from its original storage area to another storage area.

[0065] In particular, the shifting can be performed by reading the data section to be shifted from the EF and writing the read data section to a new position shifted from the original position. The new position is selected such that the beginning of the shifted section directly adjoins the end of the second personalization data. When the shifted section is written, the original data is overwritten.

[0066] 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, which already contains the corresponding data section, is used.

[0067] Embodiments of the invention can have the advantage that data sections within first personalization data can also be updated, wherein the subsequent personalization data is to be 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 remains within the personalization data, which can lead to problems in the interpretation of data to be read out. This can generally be avoided by updating, i.e. overwriting, the entire personalization data and preventing complications due to remaining residual data at the end of the file by updating the pointer to the logical end of the updated personalization data. However, this can be complex with 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 so that it indirectly connects to the updated section of the personalization data.

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

[0069] Personalization data can be created in the form of a TLV (Tag Length Value) structure, depending on the embodiment. A TLV structure is a data structure designed to simplify data organization. For this purpose, in addition to the content of the data structure (value), a header of the structure also specifies an identifier for the type of data contained (tag) and the length of the data object. If a program, which can only process a specific type of data object, 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, it can simply skip the TLV structure, since the length of the structure is specified in the value L.

[0070] 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 valuable or security document, indicating the start of the update process for updating the first personalization data. The flag is deleted after the pointer is updated. The flag initially set in the protected electronic memory for updating the personalization data indicates that a change to the personalization data is to be made. The flag is only reset after the pointer has been updated to the logical end of the updated personalization data.

[0071] This has the advantage that if the change process is aborted, for example, by removing the valuable or security document from the terminal, the personalization data is not only partially or incorrectly changed, nor is an incorrect logical end indicated by an outdated pointer. If the chip card operating system detects that the flag is set in the protected electronic memory when the valuable or security document is being used, this means that the valuable or security document is initially unusable. According to embodiments of the invention, in such a case, it can be provided that the state of the valuable or security document prior to the start of the change process is restored, after which the flag is reset, and the valuable or security document is ready for use again.This can be achieved by logging each step in the change process through log files from the smart card operating system so that changes made can be undone using these log files.

[0072] According to one embodiment of the invention, the terminal of the chip card system is a reader for a sovereign document, such as a reader for an electronic identity card, an electronic residence permit or an electronic passport.

[0073] According to one embodiment, the terminal comprises at least one electronic memory, a contactless communication interface, a closed housing and a mechanical feeder, wherein the mechanical feeder is configured to secure the value or security document against removal from the terminal, the method further comprising: Pulling the valuable or security document into the mechanical feeder of the terminal so that the valuable or security document is completely within the housing of the terminal after pulling it in, reloading the second personalization data onto the valuable or security document to update the first personalization data with the second personalization data, ejecting the valuable or security document from the mechanical feeder of the terminal after the update is complete.

[0074] To update the personalization data, the valuable or security document is first fed into the terminal's mechanical feeder so that the valuable or security document is completely contained within the terminal's housing after feeding. This ensures that the valuable or security document is not removed from the terminal while the personalization data is being updated, as otherwise, data loss could occur due to an interruption in the communication connection. Finally, the document is ejected from the mechanical feeder. Ejection here means that the document is released by the mechanical feeder sufficiently so that a document holder can remove it from the terminal.This can be done, for example, by ejecting the document in the sense of moving it out of the mechanical feeder, or the mechanical feeder can, for example, release a flap or opening so that the document can be grasped with the hands within the mechanical feeder.

[0075] According to one embodiment, the valuable or security document has a first contactless communication interface, while the terminal has a second contactless communication interface. The method then involves establishing a communication connection between the terminal and the valuable or security document via the first and second contactless communication interfaces. The second personalization data is then transferred to the protected non-volatile memory area of ​​the valuable or security document via this communication connection.

[0076] The communication connection could be an RFID or NFC connection, for example. In particular, the combination of contactless communication between the valuable or security document and the terminal and the insertion of the valuable or security document into a mechanical feeder could have the advantage that the mechanical feeder can prevent premature removal of the valuable or security document from the terminal's effective range, while at the same time, the means for contactless communication between the valuable or security document and the terminal can be embedded in the valuable or security document. The friction typically generated when using a mechanical feeder could wear out contacts used for contact-based data transmission.However, this risk is effectively avoided by embedding, for example, an antenna in the body of the valuables or security document, whereby the antenna does not protrude from the valuables or security document at any point.

[0077] According to one embodiment, establishing the communication connection between the terminal and the valuable or security document involves mutual authentication of the terminal and the valuable or security document. According to the invention, this establishes a secure communication channel between the terminal and the valuable or security document. The personalization data is then transmitted exclusively via this secure communication channel. Furthermore, after successful authentication with the valuable or security document, the terminal is granted access to personalization data stored in the non-volatile memory of the valuable or security document.

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

[0079] According to a further embodiment of the invention, after transferring the second personalization data to the non-volatile memory of the valuable or security document, the terminal deletes the second personalization data from the terminal's electronic memory. This could prevent the personalization data from being subsequently read from the terminal and potentially misused. A further embodiment follows the same basic idea, according to which the terminal's electronic memory is a volatile memory. For example, the terminal's electronic memory could be implemented as a random access memory (RAM). This would have the advantage that when the terminal is switched off, all personalization data stored in the terminal's memory from previous compression processes would be automatically deleted.It is then no longer necessary to specifically delete the personalization data from the terminal's memory.

[0080] According to a further embodiment, a reload token is used in the course of the method according to the invention, wherein the second personalization data to be reloaded onto the value or security document are contained on the reload token, wherein the reload token is connected to the terminal at the beginning of the method, wherein the connection between the terminal and the reload token is configured for data transmission between the terminal and the reload token, wherein the terminal is configured to extract the second personalization data to be reloaded from the reload token and to transfer it to the non-volatile electronic memory of the value or security document. For example, the reload token can be a smart card which 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.

[0081] 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 is contained, for example, in a reload token, then contains a cryptographic signature, wherein the value or security document is configured, after receipt of the personalization data to be reloaded from the terminal, to verify the cryptographic signature of the received data with the public key of the certificate. Furthermore, the value or security document is configured to delete reloaded second personalization data, the signature of which 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 during the production orBy storing the configuration process of the value or security document in the value or security document, a value or security document issuer can specify who can and cannot upload data to the value or security document. This means that only those parties who are provided with the corresponding private key by the value or security document issuer can upload data to the value or security document. This private key can generate a signature that can be verified with the public key of the asymmetric key pair.

[0082] According to one embodiment, the terminal comprises an energy source, wherein the energy source is a closed internal energy source and / or an external energy source.

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

[0084] According to one embodiment, the terminal comprises an authentication token, wherein the authentication token contains data for authenticating a user of the terminal. The authentication token can be configured as a replaceable physical data carrier. Here, too, the data carrier can be, for example, another chip card.

[0085] Embodiments could have the advantage that, by exchanging the authentication token, the terminal can be used by a variety of different users. 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 into the terminal is actually authorized to use the terminal.

[0086] According to one embodiment, the valuable or security document is an electronic identification document, in particular a passport, identity card, visa, driving license, vehicle registration document, vehicle registration document, company ID, a health card, signature cards, SIM cards and / or an electronic means of payment, in particular a banknote, bank card, credit card, a waybill and / or other proof of authorization.

[0087] Embodiments of the invention are explained in more detail below with reference to the drawings.

[0088] They show: Figures 1a to e show schematic representations of data assignments of EFs, Figure 2 shows a block diagram of a system comprising a terminal and a value or security document for carrying out a method according to the invention, Figure 3 shows a block diagram of an embodiment comprising a terminal and a value or security document for carrying out a method according to the invention, Figure 4 shows a schematic representation of the method for updating personalization data, Figure 5 shows a further schematic representation of the method for updating personalization data, Figure 6 shows a further schematic representation of the method for updating personalization data, and Figures 7a to c show a further schematic representation of the method for updating personalization data.

[0089] In the following, similar elements are marked with the same reference numerals.

[0090] Figure 1ashows an EF 132 with a predefined physical memory length, which represents the memory block reserved for the EF 132. The physical end 166 denotes the physical end of the reserved memory block. Since no personalization data 140 is stored, the logical file end 141 is zero. If a file 162, as in Figure 1b shown, longer than the predefined physical memory 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 1dshows a case in which 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 remains in the EF 132. Figure 1eshows a situation when overwriting first personalization data 140 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, i.e. the logical end 164 of the updated personalization data, lies before the logical end 141 of the first personalization data 140. In order to prevent the residual data 170 arranged between the logical end 164 and the logical end 141 from being read out, the logical end 163 of the second personalization data 162 is identified as the logical end 164 of the updated personalization data.

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

[0092] The Figure 2shows a system 100 comprising a terminal 102 and a valuable or security document 110 in the form of a chip card. In the embodiment shown here, the terminal 102 includes a communication interface 108, a processor 104, and a memory 101 for temporarily storing second personalization data 162. The memory 101 can, for example, be a non-volatile flash-based memory. Furthermore, the terminal 102 shown includes an authentication token 107, a reload token 105, another communication interface 109, and a power source 103. The authentication token 107 and the second communication interface 109 represent optional features of the terminal 102.

[0093] 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 self-contained energy source 103 could have the advantage of making the terminal 102 both completely self-sufficient and portable. However, the energy source 103 can also be a power supply or another type of connection to an external energy supply. Furthermore, a combination of external and internal energy supplies is also possible, which would improve the reliability of the terminal 102.

[0094] The memory 101 can be either a volatile or a non-volatile memory. In this case, it may be expedient 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 is shut down after the personalization data on the valuable or security document 110 has been successfully updated, the second personalization data 162 stored in the terminal 102 for the update would be automatically deleted. This would prevent misuse of the second personalization data 162 by subsequent reading from the terminal 102.

[0095] The valuable or security document 110 includes a chip card operating system 118 and a chip card file system 117 with a logical data structure comprising EFs 132, 142 with personalization data 140, 150. Control data 128, 134, 144 are also stored in the chip card file system 117. 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. The control data 134 and 144 also each include a pointer that points to the logical end 136, 146 of the assigned personalization data 140, 150.

[0096] As in Figure 2As indicated schematically, the communication interface 108 of the terminal 102 enables communication between the terminal 102 and the valuable or security document 110. For example, the valuable or security document 110 can be addressed via the communication interface 108, whereby an update or reloading process can be initiated. In this case, the communication interface 108 can be configured, for example, in accordance with ISO 14443. To establish such communication, it can be provided that an identification and authentication process is first carried out between the valuable or security document 110 and the terminal 102. For this purpose, a corresponding application program 106 can be provided in the processor 104 of the terminal 102.For example, during the authentication process, a mutual exchange of security certificates may be provided, which are stored in the memory 124 of the valuable or security document 110 or in a corresponding authentication token 107 of the terminal 102. However, the authentication methods possible within the meaning of the present invention are not limited to this.

[0097] Once a secure data connection has been established between the valuable or security document 110 and the terminal 102, the processor 104 of the terminal 102 can, for example, using the application program 106, store second personalization data 162, which is stored, for example, in the reload token 105 of the terminal 102, in the memory 124 of the valuable or security document 110. In this case, it can be provided that an indicator ID is also transmitted to the valuable or security document 110, for example as part of a corresponding APDU 158, in which the valuable or security document 110 is informed of the identity of the EF 132 intended for storing the second personalization data 162.

[0098] The additional communication interface 109 of terminal 102 can be configured, for example, for administering terminal 102. Communication interface 109 can be an Ethernet connection, for example. The authentication token 107 and the reload token 105 can be implemented as either a software token or a hardware token, for example, in the form of a chip card for insertion into terminal 102. For example, the reload token 105 can be supplied by a manufacturer of the valuable or security document to be updated. However, it is also possible for the reload token 105 to be permanently installed in terminal 102, so that manufacturer-specific update data would have to be transferred to terminal 102 via communication interface 109. The reload token 105 can also be configured as a memory area within terminal 102.Second personalization data 162 can therefore be stored in the memory 101 and / or in the reload token 105. Different update data can also be stored in the memory 101 and the reload token 105.

[0099] The communication interface 108, via which communication between the terminal 102 and the valuable or security document 110 is to be ensured, can additionally have a mechanical retractor for partially or completely receiving the valuable or security document 110 in the terminal 102. The retractor can be designed to protect the valuable or security document 110 from being removed from the terminal 102 by a user, at least for the duration of the reloading process. This can ensure uninterrupted communication and power supply during the reloading process.

[0100] As previously explained, terminal 102 is configured to replace at least portions of the personalization data 140, 150 stored in valuable or security document 110 during a reloading process. The reloading process is a multi-part process preceded by an initialization. During the initialization, the second personalization data 162 is uploaded to terminal 102 for updating either as a software token via communication interface 109 or as a hardware token 105.

[0101] The Figure 3shows a chip card system 100 with a terminal 102. The terminal 102 can be, for example, a reader for a government document, in particular for an electronic identity card, an electronic residence permit, or an electronic passport. The terminal 102 has a processor 104 for executing an application program 106, which is interoperable with a valuable or security document 110 in the form of a chip card, as well as an interface 108 for establishing a communication connection with a corresponding interface 112 of the chip card 110.

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

[0103] The chip 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 chip card 110. For this purpose, the program module 116 can, for example, implement those steps of a challenge-response protocol that relate to the chip card 110, whereby the application program 106 can then implement those steps of the challenge-response protocol that relate to the terminal 102. Another possibility is authentication by means of a secret identifier, e.g., a so-called PIN, which a user enters into the terminal and which is verified by the program module 116, e.g., according to the PACE protocol as specified by the Federal Office for Information Security (BSI).

[0104] The processor 114 also serves to execute a chip card operating system 118 and has a volatile 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.

[0105] Files of a chip card file system 117 are stored in the memory 124, forming a file tree. Figure 3 shows, by way of example, an MF 126 of the file tree, which contains control data 128 including a pointer 130 to a successor node, i.e., the EF 132. The EF 132 also contains control data 134, including a pointer 138 to its successor node in the file tree, namely an EF 142, as well as a pointer 136 to the logical end of the personalization data 140, which are also stored in the EF 132.

[0106] An analogous structure is provided by the EF 142, which comprises 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 a Figure 3 not shown successor node of the EF 142 in the file tree.

[0107] During 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 as well as a specification ID of the EF of the chip card file system 117 whose personalization data is to be changed. Without limiting the generality, it is assumed below, by way of example, that this is the EF 132 or its personalization data 140.

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

[0109] In the following, the Figure 4 an embodiment of the updating process according to the invention is described.

[0110] In a first step of the procedure in Figure 4During the process sequence shown for reloading personalization data 162 from a terminal 102 onto a valuable or security document 110, the terminal 102 is activated. Activation can occur, for example, by pressing a power switch, or the terminal 102 can be configured so that it is awakened from a sleep state when a valuable or security document 110 is inserted into a corresponding mechanical feeder. Subsequently, operator authentication can be provided, for example, through a password query, which, if successful, initiates the update process. For this to happen, however, the terminal 102 must have a suitable input option, such as a keyboard, as well as the authentication token 107.

[0111] After the terminal 102 has been activated, energy is transferred to the valuable or security document 110, which also activates the valuable or security document 110. A communication channel is then established between the terminal 102 and the valuable or security document 110. This can be done, for example, by inserting the valuable or security document 110 into the slot of a card reader or by establishing a wireless connection.

[0112] Mutual authentication of terminal 102 and valuable or security document 110 then occurs, allowing a secure channel to be established between terminal 102 and valuable or security document 110. For this purpose, appropriate authentication data can be stored in terminal 102, for example, in authentication token 107, which is used during the mutual authentication. Authenticating terminal 102 with valuable or security document 110 provides the necessary authorization for terminal 102 to reload data into valuable or security document 110.

[0113] 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 access authorization, wherein the transmitted cryptographic information fulfills a cryptographic access condition of the EF 132.

[0114] In a subsequent method step, the terminal generates or activates an 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 via the secure channel from the terminal 102 to the valuable or security document 110.

[0115] Subsequently, the second personalization data 162 on the valuable or security document 110 is decrypted and written to the EF 132 according to the write command to update the first personalization data 140.

[0116] Subsequently, the pointer 136 is updated so that it points to the logical end 164 of the updated personalization data. The successful execution of the update is confirmed by the valuable or security document 110 to the terminal 102 by transmitting a response with a write confirmation.

[0117] The connection and the secure channel between terminal 102 and valuable or security document 110 are then terminated, and the power supply is shut off. This deactivates valuable or security document 110.

[0118] If the valuable or security document 110 has been fed into a corresponding mechanical feeder of the terminal 102, the valuable or security document 110 is dispensed and the terminal 102 is deactivated again.

[0119] To update the personalization data 140 of the EF 132, for example, you can proceed as follows, as described in the Figure 5shown: In step 500, the terminal 102 is first authenticated to the chip card 110. In addition to the authentication, an authorization check can also be performed, namely to determine 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, wherein the authorization certificate specifies the rights of the terminal 102 to change the personalization data 140. The authorization certificate contains cryptographic information that fulfills a cryptographic access condition of the EF 132 defined in the control data 134.

[0120] 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 as well as a specification ID of the EF of the chip card file system whose first personalization data is to be changed. Without limiting the generality, this is, for example, the EF 132 or its personalization data 140.

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

[0122] 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 than the first personalization data 140, which is why only a partial overwriting occurs. A remainder of the previous version of the personalization data 140 remains in the EF 132 and is located immediately following the logical end 163 of the second personalization data 162, wherein the logical end 163 of the second personalization data 162 in the present case coincides with the logical end 164 of the updated personalization data.

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

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

[0125] After the change process of the personalization data 140 has been completed, the flag 152 is reset in step 510 and the log file 154 is deleted.

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

[0127] Another example of an update of the personalization data 140 is shown in Figure 6 shown: Steps 600, 602, 604 and 606 correspond to steps 500, 502, 504 and 506 from Figure 5Step 606 is followed by step 607, in which a check is carried out based on an indicator in the write command to determine whether it is a final write command or whether further write commands follow. If another write command follows, step 606 is repeated with the next 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 steps 508, 510, 512, and 514 from Figure 5 .

[0128] The Figures 7a to 7c schematic representations of an updating method according to the invention are shown. Figure 7ashows 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 updating the first personalization data 140 by 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. The third section 140‴, in contrast, is to be retained. For this purpose, the corresponding write command has an offset value that corresponds to the length of the first section 140'. Thus, as in Figure 7bshown, the middle section 140" is overwritten with the second update data 162 from the end of the first section 140'. Since the second update data 162 is shorter than the middle section 140" of the first personalization data 140, unwanted residual data 170' remains. In order to avoid the residual data 170' and at the same time to retain the last section 140‴ in full, the last section 140‴ is physically moved to the logical end 163 of the second personalization data 162. This physical moving can be done, for example, by reading the last section 140‴ to be moved from the EF 132 and writing the section 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 neglected by setting the pointer 136 to the end of the shifted subsection 140‴.Thus, the end of the shifted third subsection 140‴ is defined as the logical end 164 of the updated personalization data. Consequently, the remaining data 170 between the logical end 164 and the logical end 141 of the first personalization data will no longer be read out during future readout processes, since reading only occurs up to the point specified by the pointer 136.

Claims

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

2. The method according to claim 1, wherein the pointer (136) is stored in the control data (134) of the associated elementary files (132), or 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).

3. The method according to any 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).

4. The method according to any 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.

5. The method according to claim 4, 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).

6. The method according to any 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.

7. The method according to any one of claims 1 to 5, 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.

8. The method according to claim 7, 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.

9. The method according to any one of claims 1 to 5, 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.

10. The method according to any 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).

11. The method according to any one of claims 1 to 9, 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).

12. The method according to any 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.

13. The method according to any one of the preceding claims, further 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).

14. The method according to any one of the preceding claims, wherein the value document 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.

15. The method according to any 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.