RU2408071C2 - Protected data loading and storage in data processing device - Google Patents

Abstract

FIELD: information technology. ^ SUBSTANCE: method involves reception of a payload data element using a processing device; performing cryptographic authentication of the payload data element; storing the authenticated received payload data element in a data processing device, and protecting integrity of the stored payload data element. The cryptographic authentication process involves calculation of a control hash function value of at least the received data element. Protection of integrity also involves calculation the standard value of a message authentication code at least for the control hash function value using a secret key stored in the data processing device as input data. ^ EFFECT: more computationally efficient mechanism for providing security, which protects software and when loading software into a device. ^ 34 cl, 11 dwg

Description

A method, software product and device for securely loading and storing data in a data processing device are disclosed.

Embedded systems, such as mobile phones and other data processing devices, depend on the execution of the correct software that has not been exposed in a prohibited manner. Unauthorized manipulations with the software can lead to malfunctioning of the device or even to a violation of the main features of ensuring the security of the device. Therefore, it is especially important to protect the basic software of the device. This can be achieved, for example, by storing the program in protected memory. The memory can either be physically protected from illegal access, or protected by cryptographic methods. It is almost difficult or expensive to create memory with good physical protection, and especially to protect memory interfaces. Therefore, the most attractive solution is to use some kind of cryptographic protection of the software stored in memory.

In addition, software for even fairly small systems is becoming more and more complex, thus increasing the risk of errors and unintentional actions, especially in earlier releases during the software life cycle. In addition, the functionality of earlier releases is usually limited. Consequently, there is an increasing need for frequent software updates stored in embedded devices.

The need for frequent updates and the desire to provide sufficient protection for the software of the data processing device create the need for security solutions that protect the software of the data processing device during storage, and this is taken into account with protected software updates.

US patent No. 6026293 discloses a method for preventing interference with the electronic memory of an electronic device. According to this prior art method, when it is desired to reprogram an electronic device using a data transmission device, the electronic device initiates an authentication scheme requesting and confirming a public / private key for authenticating the data transmission device. After authentication, the data device is allowed access to reprogram the memory. After reprogramming the memory, the electronic device calculates the hash function of the modified memory contents. The calculated hash value is sent to the data device for digital signature, and the signed hash value is returned to the electronic storage device. The signed hash value is subsequently used to monitor the integrity of the contents of the memory, for example, at boot time or periodically.

Even though the above prior art method provides both authentication protection during the boot phase and protection of the integrity of the contents of the electronic device’s memory, it involves a rather complicated scheme for generating and signing the generated hash value, thus leading to the process loading takes quite a long time.

Therefore, the problem is to provide a more computationally efficient security mechanism that protects the software both during the downloading of software to the device and subsequently when the software is stored in the device.

The above and other problems are solved using the method of loading data into a data processing device, this method comprises the steps of:

- receive the payload data element using the processing device;

- perform the cryptographic authentication process to ensure the authenticity of the payload data element;

- save the authenticated received payload data element in the data processing device and

- protect the integrity of the stored payload data item,

in which the execution of the cryptographic authentication process includes calculating a control (verification) value of the hash function for at least the received data element and

in which the integrity protection further comprises calculating a reference value of the message authentication code for at least the hash control value using the secret key stored in the data processing device as input.

In particular, since the hash control value calculated during the download process is calculated from the received payload data and this hash control value is subsequently reused during the calculation of the message authentication code, the number of necessary calculations performed during the software download is reduced , thus increasing the computational efficiency of the method.

In addition, since regular integrity protection is based on a secret key stored in the data processing device, integrity protection does not depend on any external cryptographic keys and, in particular, does not depend on the public key signing mechanism. The advantage is that the integrity check based on a symmetric key, i.e. an integrity check based on a message authentication code is computationally more efficient than a public key based integrity check that involves signing verification.

The term "data processing device" includes any electronic device containing a memory for storing data into which data can be downloaded from an external source, for example, from a data transmission system. In particular, the term “data processing device” includes any electronic equipment, portable radio communication equipment, and other handheld or portable devices. The term portable radio equipment includes all equipment, such as mobile phones, pagers, communicators, electronic notebooks, smartphones (smart mobile phones), personal digital assistants (PDAs), personal digital assistants, or similar devices.

The term payload data element includes any data loaded into a data processing device. In particular, the term payload data element includes configuration data, program code, for example, operating system environment software or application software designed to be executed by a device, or the like.

The cryptographic authentication process may be any appropriate cryptographic process for verifying the authenticity of the received data, i.e. in order to make sure that the data is actually sent by the object whose name they transfer, and that they have not been tampered with or modified.

In some embodiments, the cryptographic authentication process includes the steps of:

- take the reference value of the hash function and

- comparing the received reference value of the hash function with the calculated control value of the hash function to verify the authenticity of the received payload data element.

In a further embodiment, the cryptographic authentication process includes digitally signing a data item in accordance with a public key cryptosystem. Digitally signing software is an effective and reliable principle for verifying software downloaded to a mobile device. Successful verification of the signature ensures that the software is released by a legitimate source. In addition, digital signatures based on public key techniques have the advantage that the public key used for verification does not have to be reliably protected during movement or storage. Consequently, the same public key can be installed in a large number of devices without compromising security. This provides the ability to efficiently perform fast and secure software updates.

In some embodiments, the method comprises the steps of:

- receive a payload data element, a digital signature data element and a digital certificate signed by digital signature, the digital certificate data element includes a first public key and the digital signature data element includes a hash reference value encrypted with the first private key corresponding to the first public key;

- authenticate the digital certificate data element signed with a digital signature with respect to the root public key stored in the data processing device;

- authenticate the digital signature data element with respect to the authenticated digital certificate;

- comparing the received reference value of the hash function with the calculated control value of the hash function to verify the authenticity of the received payload data element.

Therefore, the authenticity of the digital signature is provided with a digital certificate, thereby further enhancing the security of the download process. It should be understood that the data processing device can accept more than one digital certificate, forming a chain of certificates, and one certificate in the chain is checked using the public root key stored in the data processing device.

In a further embodiment, cryptographic authentication of the hash reference value is performed, and the calculation of the message authentication code reference value is performed only if the hash reference value is successfully authenticated. Therefore, the execution of the message authentication code procedure in the data processing device is caused by obtaining an authenticated hash function reference value, thereby reducing the risk of the adversary using the message authentication code procedure of the data processing device to calculate unauthorized values of the message authentication code.

Message Authentication Codes (MAC, CAS) are a well-known mechanism for protecting message integrity. A MAC is a function that uses variable-length input and a key to create fixed-length output, a so-called MAC value, or label value. MACs are typically used by two participants who share a secret key to validate the information transmitted between these participants. In some embodiments, the MAC is computed by applying a one-way hash function to the payload data and encrypting the result using a secret key. Examples of relevant MAC functions that can be combined with a cryptographic hash function include HMAC (Key Based Hashing for Message Authentication), Cipher Block MAC (CBC) using, for example, AES or a robust one-way hash function. In the described download method, the message authentication code is used to verify the integrity of data stored in an unreliable or insecure medium, i.e. in this situation, the MAC uses only one participant, i.e. a data processing device when it stores and retrieves a payload data element.

Therefore, in some embodiments, the integrity protection comprises storing a computed message authentication code reference value with respect to a received payload data element, thereby making it available for subsequent memory monitoring with the payload data element using a data processing device. Therefore, when monitoring the contents of the memory, the device calculates the value of the authentication code of the message of the stored payload data element using the secret key stored in the device, and compares the result with the previously stored MAC reference value. Therefore, in this embodiment, the secret key should be known only to the digital processing device. In some embodiments, the secret key is a secret data element unique to a data processing device, for example a secret data element known only to a data processing device.

In another embodiment, the calculation of the reference value of the message authentication code further comprises calculating the reference value of the message authentication code of the combined data item obtained from at least the hash control value and a random number. An advantage of this embodiment is that the input to the MAC is not completely dependent on the result of the authentication process, thereby further increasing the reliability of data protection.

When the calculation of the reference value of the message authentication code further comprises the calculation of the reference value of the message authentication code of the combined data item obtained from at least the control value of the hash function and the version control data item, the integrity protection is effectively combined with the version control mechanism, since subsequent memory control will successful only when both the contents of the memory and the version control information are consistent.

In some embodiments, the version control data record is stored in the version control data structure, the version control data record includes information about a received payload data element including at least a version control data element. In some embodiments, the implementation provides protection for the integrity of the control data structure.

In some embodiments, the version control data recording comprises a version counter. In some embodiments, the version control data recording further comprises a countdown identifying the number of previous versions with which the current version of the payload data item can be replaced, thereby providing a simple and efficient version control mechanism including a downward compatibility control mechanism.

In known software update schemes, where existing software is updated with a new software version, a software update is often adopted as a so-called delta file (delta file) or delta update. Such delta updates include differences between the new (updated) software and the current software, thereby reducing the size of the update package. In some delta file techniques, the update file also includes commands for controlling the generation of the updated software version from the current software and the received update. The delta file technique is also known in the art and is described, for example, in “Delta storage for arbitrary non-text files”, by Christian Reichenberger, Proc. Of the 3rd International Workshop on Software Configuration Management, p. 144-152, Norway, June 1991. It is desirable to provide an effective security mechanism that can also apply to delta updates. This problem is resolved when receiving a payload data element includes receiving a delta update of a previously received current data element, and a payload data element is generated as an updated payload data element from a previously received current data element and a received delta update. Therefore, according to this embodiment, an updated payload data element is generated and a hash control value is calculated from the generated updated payload data element. Therefore, the hash check value can be reused again to calculate the authentication authentication code message of the updated payload data that is stored in the device.

According to a second aspect, the problem of the aforementioned prior art system is to provide an effective and reliable way to protect the integrity of the current version of a data item stored in a data processing device in a situation where frequent updates of different versions of a stored data item occur.

The above and other problems are solved using the method of protecting the integrity of the current version of the data item stored in the data processing device, this method comprises the steps of:

- determine the reference value of the hash function of at least the data item;

- calculate the reference value of the authentication code of the message from the determined reference value of the hash function using the secret key stored in the data processing device;

- save the calculated reference message authentication code value for the data item;

characterized in that the calculation of the reference value of the message authentication code comprises calculating the reference value of the message authentication code from the combined data item obtained from the determined hash function reference value and at least from the version control data recording part, the version control data recording includes control information version of the current version of the data item.

Therefore, by calculating the reference authentication code of the message from the combined data item obtained from the determined hash function reference value and at least from the recording part of the version control data, the integrity protection of the stored payload data is effectively combined with reliable version control of the stored data.

The reference value of the hash function of at least the data item can be determined by calculating the value of the hash function for the data item or taking the value of the hash function together with the data item or from the authentication process in connection with obtaining the data item that is described in this paper.

The term combined data element contains any data element generated as a function of two or more data elements, for example, as a combination of two or more data elements, where one data element is attached to another. Therefore, the combined data item obtained from the determined hash function reference value and at least a part of the version control data record is generated as a function of at least the hash function reference value and at least a part of the version control data record.

In some embodiments, implementation provide protection of the integrity of the record of version control data.

In some embodiments, the version control data recording comprises a version counter and calculating a message authentication code reference value, comprising calculating a message authentication code reference value from a combined data item obtained from a specific hash control value and at least a version counter.

In some embodiments, the recording of version control data further comprises a countdown counter identifying a plurality of previous versions with which to replace the current version of the payload data element, thereby providing a simple and efficient version control mechanism including a downward compatibility control mechanism. In some embodiments, calculating a reference value of a message authentication code comprises computing a reference value of a message authentication code from a combined data item obtained from a specific hash reference value and at least a count back.

In another embodiment, the version control data record further comprises a hash reference value for the current version of the data item, thereby providing a compact “fingerprint” (checksum) of the data item.

In some embodiments, the secret key is known only to a digital processing device. In addition, the secret key may be a secret data item unique to the data processing device.

In some embodiments, the payload data is loaded in the manner indicated initially, thereby effectively combining secure loading and storage with reliable version control.

In yet another embodiment, the method further comprises the steps of:

- accept a delta update of a previously received current data item and

- generate a data item as an updated data item from a previously received current data item and a received delta update.

In yet another embodiment, the method further comprises generating a record of version control data and storing a record of version control data in a version control data structure, thereby making it available for subsequent memory verification.

Accordingly, in another aspect, a method for checking the integrity of a data element of a current version stored in a data processing device comprises the steps of:

- calculate the control value of the hash function of the data item;

- calculate the control value of the authentication code of the message from the calculated control value of the hash function using the secret key stored in the data processing device;

- comparing the calculated control value of the message authentication code with the reference value of the message authentication code stored for the data item.

According to this aspect, the method further comprises retrieving the version control data record, the version control data record including version control information about the current version of the data item and

the calculation of the control value of the message authentication code contains the calculation of the control value of the message authentication code from the combined data item obtained from the calculated control value of the hash function and at least from the version control data recording part.

The present invention relates to various aspects, including the methods described above and further, corresponding devices and computer programs, each of which leads to one or more of the advantages and benefits described in connection with one of the above methods, and each of which has one or more embodiments corresponding to the embodiments described in connection with one of the above methods.

More specifically, according to another aspect, the data processing device comprises a first processing circuit configured to perform a method of loading data into the data processing device described above and below.

In particular, it has been found that the described security mechanism can advantageously be applied to a device having a multi-chip architecture. In particular, when the first of the crystals accesses the memory through the second of the crystals, it is especially important for the first crystal to guarantee the authenticity of the data and the integrity of the contents of the memory.

Therefore, in some embodiments, the data processing apparatus further comprises storage means configured to store the received payload data element and a second processing circuit associated with the storage means and the first processing circuit; moreover, the second processing circuit is configured to provide the first processing circuit with at least read access to the storage medium.

In a further embodiment, the first processing scheme comprises local storage means for storing the root public key of an asymmetric cryptographic system. In a further embodiment, the first processing circuit comprises local storage means for storing said secret key, thereby providing secure storage under the control of the first crystal of cryptographic keys used in the mechanism for ensuring the authenticity and integrity of the data.

According to another aspect, the data processing device comprises storage means for storing the current version of the data item and recording version control data, the recording of version control data includes version control information about the current version of the data item, and processing means configured to perform the above and Further, a method for checking the integrity of a current version data item.

It should be noted that the features of the methods described above and further can be embodied in software and executed in a data processing device or other processing means based on the execution of program code, for example, computer-executed instructions. In this description, the term processing means comprises any circuit and / or device, respectively, configured to perform the above functions. In particular, the above term contains special or general purpose programmable microprocessors, digital signal processors (DSP), specialized integrated circuits (ASIC), programmable logic arrays (PLA), user programmable gate arrays (FPGAs), special electronic circuits, etc. ., or a combination thereof.

Therefore, according to another aspect, the computer program comprises program code configured to cause the data processing device to perform the steps of the above and further described method when said computer program is executed in the data processing device.

For example, program code can be loaded into memory, such as random access memory (RAM, OP), from a storage medium or from another computer through a computer network. Alternatively, the described features may be implemented in hardware instead of software or in combination with software.

The above and other aspects will be apparent and understandable from the embodiments described below in relation to the drawings, in which:

figure 1 shows a schematic structural diagram of a system for downloading data to a mobile terminal;

figure 2 shows a schematic structural diagram of an example of a mobile terminal with a single-chip architecture;

figure 3 shows a schematic structural diagram of an example mobile terminal with a dual-chip architecture;

4 shows a schematic structural diagram of another example of a dual-chip mobile terminal;

5 illustrates an example message structure used in the process of downloading software to a mobile terminal;

6 shows a flowchart of a software download process for downloading a new software version;

7 illustrates an embodiment of calculating a message authentication code;

FIG. 8 illustrates another embodiment of a message authentication code calculation including a version control mechanism; FIG.

9 shows a flowchart of a version control process;

10 illustrates an example version control mechanism, and

11 shows a flowchart of a software download process for updating a software.

Figure 1 shows a schematic structural diagram of a system for downloading data to a mobile terminal. The system comprises a loading station 101 and a mobile terminal 102.

The boot device may be a conventional, suitably programmed computer, such as a PC (personal computer), containing the appropriate communication interface. In some embodiments, the download device may generate payload data, such as software version, configuration data, and / or similar data that will download. In particular, the download device can generate a digital signature and certificate that will be downloaded along with the payload data. In other embodiments, the download device receives payload data and header information from a remote computer, such as a personal computer, workstation, network server, etc. For example, data can be received via a computer network, such as the Internet, a local area network, a corporate network, an extranet, etc., or by any other suitable means, for example, on computer-readable media such as a floppy disk, CD-ROM -ROM) etc. In this embodiment, signature calculation and certificate generation may be performed by a remote computer, rather than a download station. The download device, together with the mobile terminal, downloads data to the mobile terminal.

The mobile terminal 102 comprises a communication interface 104 comprising circuits and / or devices suitable for enabling the mobile terminal to communicate with the download station via a wired communication channel or via a radio communication channel 103, such as a direct communication channel, a communication system, or a similar communication channel. For example, data can be downloaded via a local short-range wireless channel, for example via a Bluetooth connection, an infrared connection or the like, or via a wired interface. In other embodiments, data can be downloaded to a mobile terminal via a communications system, such as radio communication (OTA) via a cellular data network, such as GSM (Global System for Mobile Communications), WCDMA (Code Division Multiple Access) or a similar network .

Therefore, examples of suitable communication modules include a wired serial connection, such as an RS-232 communication channel (standard serial data interface), a USB (universal serial bus) connection, a FireWire connection as described in IEEE 1394, or the like. compound. Additional examples include a wireless infrared interface or radio frequency (RF) interface, such as a main antenna of a mobile phone (not shown) or another antenna in a mobile phone, such as a Bluetooth transceiver, or the like. Other examples of suitable interfaces include a cable modem, telephone modem, integrated digital services network (ISDN) adapter, digital subscriber line adapter (DSL), satellite transceiver, Ethernet adapter, or the like.

The mobile terminal further comprises a processor 105 for controlling the operation of the mobile terminal and a memory 106. For example, the processor may comprise a special or general purpose programmable microprocessor, a digital signal processor (DSP), a specialized integrated circuit (ASIC), a programmable logic matrix (PLA ), Field Programmable Gate Array (FPGA), etc. or a combination thereof. The storage device 106 may be flash memory, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or any other type of memory or storage device, such as non-volatile memory.

When data is downloaded to the mobile terminal, the processor 105 performs the described data authentication and integrity protection and stores the data in the storage device 106.

During the subsequent operation of the mobile terminal, the processor may retrieve the downloaded data from the storage device 106. For example, in the case of software, the processor loads the software from the storage device 106 into RAM for execution.

Figure 2 shows a block diagram of an example of a mobile terminal with a single-chip architecture. The mobile terminal 101 comprises a controller 105 for controlling the operation of the mobile terminal. The controller 105 works together with flash memory 106 for storing programs and random access memory (RAM) 209. The controller 105 includes a microprocessor 208, internal read-only memory (ROM) 207, and a securely stored private key 218. For example, private key 218 can be a unique crystal key, for example, stored in hardware, for example, using the so-called technology of e-fuse (electrically burned jumpers). Alternatively, the secret key may be stored in ROM 207. ROM 207 comprises a boot code, a hash code, a MAC code, an authentication code, and a public root key. In some embodiments, the hash code and / or MAC code may be embodied at least partially in hardware instead of or in addition to being embodied in ROM. The command system associated with the normal operation of the mobile phone is contained in the flash memory 106 programs. Random access memory 209 is used for operations that are part of the normal call processing of a mobile terminal. In some embodiments, operations involving sensitive data, hash function calculations, and authentication processes are performed together with secure static random access memory (PSRAM) (not shown), which includes the microcontroller 105. The controller 105 communicates with the flash memory 106 programs and RAM 209 via the memory bus 219.

FIG. 3 shows a schematic structural diagram of an example dual-chip mobile terminal architecture. In this embodiment, the controller 105 comprises two crystals 310 and 313, respectively, an external memory 106 and an internal memory 209. Each of these two crystals contains at least one microprocessor 312 and 315, respectively, and a ROM 311 and 314, respectively. External storage device 106 is any suitable type of non-volatile memory, such as flash memory. Internal storage device 209 is a quick access storage device such as random access memory. In the embodiment of FIG. 3, these two crystals share an internal storage device 209. In addition, in this embodiment, only the crystal 313 has direct access to the external storage device 106. Therefore, when the processor 312 from the crystal 310 has to execute software stored in the external storage device 106, before the software can be executed, it is loaded into the internal storage device 209 through the chip 313. In this embodiment, both P 311 and 314 contain boot code, but only ROM 311 contains a hash code, MAC code, authentication code, and public root key, and only crystal 310 contains private key 318. As described above, private key 318 can be stored in hardware, for example, using the so-called technology of e-fuse (electrically burnable jumpers). Alternatively, the secret key may be stored in ROM 311. Furthermore, in some embodiments, the hash code and / or MAC code may be embodied at least partially in hardware instead of or in addition to being embodied in ROM.

Figure 4 shows a schematic structural diagram of another example of a dual-chip mobile terminal. This embodiment is similar to the embodiment of FIG. 3 except that the two crystals 310 and 313 of this embodiment do not share common internal memory. Instead, each crystal has its own internal memory 416 and 417, respectively. As in the embodiment of FIG. 3, only the chip 313 has direct access to the external storage device 106. Therefore, when the processor 312 from the chip 310 needs to execute software stored in the external storage device 106, the software to be executed is downloaded into an internal memory 416 of the crystal 310 through the crystal 313 before it can be executed.

In alternative embodiments with two crystals with a public or separate random access memory (RAM), both crystals can have direct access to an external non-volatile storage device and directly execute software that must be executed from this storage device or first load it into RAM and then to perform.

5 illustrates an example message structure used in the process of downloading software to a mobile terminal. Message 520 contains header section 521, payload section 522, digital certificate section 523, and digital signature 524.

The payload section 522 contains actual payload data that will be downloaded to the mobile terminal. The payload data may include software, such as application software, pre-loading software, designed to organize and / or control the loading of other software, part of the operating system of a mobile terminal, or similar software. Alternatively or additionally, the payload data may contain other data, for example, configuration data for storage in flash memory or in other memory blocks of a mobile terminal, for example, EPROM, EEPROM, or similar memory blocks.

Section 521 of the header contains information corresponding to the loading process, such as information about payload data, for example version control data, information about the mobile terminal, control parameters that determine how the mobile terminal should process the data, and / or similar information.

The signature section contains a digital signature of payload 522. The digital signature is computed using an open / closed key pair of an asymmetric cryptosystem, such as the RSA system (Rivest, Shamir and Adleman). The digital signature is calculated by initially calculating a one-way hash function of the payload data, i.e. software and / or data to be downloaded to the mobile terminal. The calculated hash value is then encrypted with the private key of the public / private key pair.

A one-way hash function is used to create a hash function value that represents payload data 522. A public / private key system is used to protect the correct hash function and authenticate the loading station or data device from which message 520 is sent.

A one-way hash function is a function that is simple to calculate in the forward direction, but difficult to calculate in the opposite direction. The one-way hash function H (M) operates on input data of arbitrary length M, which in some embodiments consists of payload data 522 or selected pieces of payload data. The hash function executed on M returns the value of the hash function of a fixed length, h = H (M).

There are many functions that take input information of arbitrary length and return output information of a fixed length, but one-way hash functions have the following additional characteristics: for a given M, it is easy to calculate h; for a given h, it is difficult to calculate M; and for a given M it is difficult to find another message M ', so that H (M) = H (M'). The purpose of a one-way hash function is to provide a unique signature or “fingerprint” M. The output of the hash function is referred to as the value of the hash function or as the digest of the message.

In embodiments of the described method, before sending message 520 to the mobile terminal, a reliable one-way hash function is performed with payload data 522 or with selected content to create a hash reference value. Message 520 includes a reference hash value as a digital signature, as further described below. Upon receipt of message 520, the mobile terminal calculates the hash control value of the payload data 522 (or its selected content) and compares the hash control value with the hash reference value received as part of the message 520.

The corresponding one-way hash function is, for example, the SHA-1 function. Other examples of related functions include MD5, Snerfu, H-Hash, MD2, MD4, or similar algorithms.

Public key algorithms use two keys: one available to everyone and one private (secret key) for tasks such as encrypting and decrypting messages, authenticating messages and digital signatures. When the transmitter has encrypted the message with the private key, any receiver with the corresponding public key can be sure of the authenticity of the transmitter, since only the transmitter having the private key can encrypt the message. The latter scheme is used to authenticate payload data in accordance with the loading process described. The corresponding public key algorithm is the RSA algorithm. Other relevant examples include Fiat-Shamir (FS), ELGAMAL, DSA (Digital Signature Algorithm), Fiege-Fiat-Shamir, or similar algorithms.

In particular, in the described download process, the calculated hash value is encrypted with the private key of the download device (or payload generator) to create a digital signature 524, which includes message 520.

Section 523 of the digital certificate of message 520 includes a certificate that includes a corresponding public key. A digital certificate is a data structure used in a public key cryptosystem in order to associate a specific authenticated person with a specific public key. A digital certificate is a digital representation of information that identifies the certification authority that issued it, names or identifies the person whose public key it includes, and contains the public key of that person. A digital certificate is signed using a digital signature by the certification authority that issued it, thus allowing the recipient to verify the authenticity of the certificate using the public key of the certification authority.

It should be understood that the digital certificate section may contain one digital certificate or a chain of certificates. In any case, the certificate or certificate chain can be authenticated using the mobile terminal using the root public key corresponding to one certificate or the last certificate in the certificate chain. An example of a key hierarchy in connection with downloading software to mobile phones is described in WO 03/060673.

It should be understood that in some embodiments, the payload for computing the digital signature can be divided into smaller parts, as described, for example, in WO 03/060673, or you can simply calculate this signature.

It is generally desirable to protect header data 521 as well as payload data 522. In some embodiments, this is achieved by protecting the header data 521 itself with a digital signature. In other embodiments, the above encryption of the calculated hash value further comprises encrypting the hash value calculated for the header data 521, for example, by encrypting / signing the union h (SW) | h (H) of a hash function h (SW) calculated for software (and data) 522, and a hash function h (H) calculated for header data 521.

6 shows a flowchart of a software download process for downloading a new software version.

At an initial step 601, the mobile terminal receives a software data packet from the reprogramming means via a local or remote interface, for example GSM, WCDMA, etc., as described above. The package contains new SW software, one or more C certificates and a digital signature S (h _r ) of secure software and data, as described above in connection with FIG. Additionally, new software may include data, such as configuration data. The signature S (h _r ) contains at least an encrypted hash value calculated from software and data. The signature is calculated so that first the value h _r = H (SW) of the one-way hash function of the software and the SW data is calculated, and then at least the calculated value of the hash function is encrypted with the private key public / private key pairs, for example public / closed RSA. The software data package includes a certificate that includes the corresponding public key. Upon receipt of the software package and data, the mobile terminal stores the software, data, certificate (s) and signature in the external storage device 106. As indicated above in connection with FIG. 5, in some embodiments, the signature can protect not only the payload, but also the header data, for example, by encrypting the union of the hash function value calculated for the software and the hash function value calculated for the header.

At 602, the mobile terminal processor reads the recently stored software and data SW, certificate (s) C, and signature S (h _r ) into its internal storage device.

At step 603, the processor calculates a control value h _a = H (SW) of the one-way hash function of the new software and SW data.

At 604, the processor reads the root public key PK from the memory 605. In some embodiments, the root public key is securely stored, i.e. protect integrity. In one embodiment, the root public key is stored in the internal ROM of the processor, as described above. The processor uses the PK root public key to verify the S (h _r ) signature of the new software and data. If only one certificate is used, then the signature S (h _r ) is checked against the public key in certificate C. Certificate C, in turn, is then checked against the PK root public key. If multiple certificates are used, then the entire certificate chain is checked. In this case, the signature of the last certificate in the chain is checked against the root public key. Then, at 604, the processor checks the public key used to sign the new software and data. If the verification is successful, then the processor continues to verify the signature in step 606. Otherwise, the software download process is stopped.

At 606, the processor decrypts the digital signature S (h _r ) of the software and data using the public key verified at 604 to obtain a hash reference value h _r .

At step 607, the decrypted signature, i.e. the reference value h _{r of the} hash function is checked with respect to the control value h _{a of the} one-way hash function calculated in step 603. If the verification is successful, i.e. if the hash reference value h _{a and the} hash reference value h _r are equal, then the processor continues at step 608 with the calculation of the message authentication code (MAC). Otherwise, the software download process is stopped.

At 608, the processor uses the verified value of h _a (= h _r ) of the one-way hash function and the unique key of the crystal K (or the value obtained from K) as the input value of the MAC calculation function, obtaining the reference value of the message authentication code t _r = MAC ( h _a ; K). MAC Function Output Value — The MAC reference value of new software and data. In some embodiments, the unique K chip is stored in secure memory, which is accessible only to the processor. For example, a unique key K can be burned in the crystal during the manufacturing process, using, for example, the so-called e-fuse (electrically burnable jumpers) technology. Embodiments of the message authentication code will be described below. The processor stores the new reference value MAC t _r in the external storage device 106 together with new software and data SW. Additionally, the certificate (s) and digital signature values can be deleted from the external storage device.

The download process described above is controlled by the processor of the mobile terminal. In a dual-chip architecture, as described in connection with FIGS. 3 and 4, the above steps are performed using a chip 311, which is intended to subsequently execute software.

Cryptographic functions for authenticating received data and, in particular, MAC functions can be performed using special-purpose software, which is stored, for example, as part of the boot code in the internal ROM of the processor, which performs the above steps.

Consequently, the stored MAC reference value is now available for subsequent verification of the software and data by the processor. For example, to verify the integrity of stored software, the processor calculates a hash control value h (SW) of the stored software and data hash and a MAC control value t _a = MAC (h (SW); K) of the calculated hash control value using a unique key K crystal. The processor compares the calculated MAC t _a reference value with the stored MAC t _r reference value. If the two values are equal, then check the integrity of the software.

For example, such verification may be performed during the download process of the mobile terminal, and / or each time the software is to be executed, and / or periodically at predetermined intervals, for example, as described in US Pat. No. 6,026,293.

7 illustrates an embodiment of a Message Authentication Code (MAC) code calculation. MAC is a function that takes input of variable length M and key K to create output of a fixed length t, the so-called MAC value, or label (tag) value: t = MAC (M; K). In some embodiments, the MAC is determined so that for an attacker who knows M but does not have information about the value of K, it is computationally difficult (impossible) to find a message M 'different from M but with the same label value. In addition, the MAC function can be determined so that it is difficult for an attacker who knows the message M, but does not have information about the value of K, to predict the correct value of the label t. In the described download method, MACs are used to verify the integrity of data stored on insecure or insecure media, i.e. in this situation, the MAC is used by only one participant, i.e. a mobile terminal while storing and retrieving payload data. In some embodiments, the MAC function is based on a cryptographic hash function and, in particular, on the hash function H used to validate the received payload data, as described above. This makes it possible to reuse the value of the hash function calculated during authentication of the received payload data, calculating the MAC value for subsequent integrity protection, thereby significantly reducing the amount of computational work needed to calculate the MAC value and thus reducing installation time.

7 shows a block diagram of a MAC calculation module. The MAC computing unit comprises a MAC function calculating unit 732. The MAC function calculator 732 takes h as input, h is a validated hash value that was calculated during the previous signature verification process 736 for the received payload, i.e. h = h _a or h = h _r . As a second portion of the input, the MAC function 732 receives the secret key K ', which is obtained from the unique key of the crystal K. In particular, the key K' can be generated using a pseudo-random function 731, for example, a pseudo-random function that is based on a hash function, for example, SHA-1, from a unique K crystal key and mode identifier 735. For example, the unique key of a K crystal may be a random number generated during the production of an LIS crystal. Obtaining the key K 'from the master key K has the advantage that different keys K' can be used for various purposes, for example, to protect different types of software, different pieces of software, etc., thus providing cryptographic separation and increasing the flexibility of the method. The identifier 735 mode allows you to select various modes. For example, in a multi-chip scenario, different modes may be used for each given chip for which the software is intended. Examples of appropriate MAC functions include HMAC (Key Based Hashing for Message Authentication), Cipher Block Interlocking MAC (CBC) using, for example, AES or a robust one-way hash function, such as CBC-MAC, as defined in the Handbook of Cryptology ", By AJMenezes, PC van Oorschot, SAVanstone, p. 353, CRC Press, 1997, where the AES block cipher is used as the block cipher E. The MAC function 732 produces the corresponding tag value t, as described above.

To prevent the calculation of unresolved MAC values, the MAC circuit only provides the calculated MAC t when the successful verification of the signature precedes the calculations. Therefore, the MAC computing module subsequently receives input 733 from the signature verification process 736, indicating whether the digital signature of the received payload data has been successfully verified. Block 734 accepts the tag value and signal 733 as input and provides the calculated tag value only if signal 733 indicates that the hash value h is verified, i.e. genuine hash value. For example, in the method of FIG. 6, a signal 733 is generated in step 607.

It should be noted that the MAC computing module may be implemented as a separate MAC computing circuit in the processor chip. In addition, a subsequent comparison between the calculated MAC value and the reference value can be performed in the comparison circuit attached to the MAC circuit. In addition, the secret key K can be stored as part of this scheme. Therefore, all MAC computation may be limited in a special design and thus does not require presentation / transmission of the computed MAC outside the design.

The MAC calculation in FIG. 7 can be further improved with very little processing power so that it further includes reliable version control and disrupts the predictability of the input data h for MAC calculation. This alternative embodiment of the MAC calculation will now be described with respect to FIG. 8 and FIG. 9.

FIG. 8 illustrates another embodiment of calculating a message authentication code including a version control mechanism, and FIG. 9 shows a flowchart of a version control process.

According to this embodiment of the MAC circuit 800, the MAC calculation in block 732 is performed on a four-element tuple 844 (rand, h, cnt, back_cnt). A four-element tuple 844 contains a short (eg, 64 bits) random value, rand, which provides a situation in which the input for calculating the MAC was not completely controlled by the input from the signature verification process 736. The four-element tuple further comprises a verified value h of the hash function, as in the previous embodiment. Finally, the four-element tuple contains the version control counter, cnt, and the reverse version control counter, back_cnt, the version control mechanism described later. A MAC function 732, such as an HMAC, a CBC-MAC, or a similar function, further receives the secret key K ', as described in connection with FIG. 7, and calculates the MAC t value from the four-element tuple and the secret key K'. Similarly, as described in connection with FIG. 7, the calculated label value t is issued only if the signature signal 703 indicates that the signature verification process has verified the hash value h.

A four-element tuple 844 is generated using a version control module 841, which maintains a version control list 842 of previously adopted program versions. In particular, the version control list 841 contains a list of data records, where each data record contains a tuple of four elements corresponding to the previously noted value of the hash function. An entry with a new hash value is referred to as the top of list 842, which corresponds to the software that is actually installed / used.

The version control module 841 receives the verified hash value h and a digital signal 733 indicating that the signature has been successfully verified from the signature verification process, as described above. In addition, the version control module 841 receives a program version counter, cnt, and the number back_cnt from the signature verification process 736. The back_cnt number indicates how many previous versions can still be installed when this version of the program is installed. For example, back_cnt can be a number between 0 and C _MAX , for example C _MAX = 15, where back_cnt = 0 implies that new software does not allow it to be replaced with a previous version. Consequently, back_cnt embodies a simple but effective mechanism for controlling downward and upward compatibility of downloadable software. In some embodiments, cnt and back_cnt are accepted as part of the software package that is received during the download process, for example, as part of the header section of the received software package.

After receiving (step 901) a new hash value h, a new cnt counter, a new back_cnt value and a signal 733 from the signature verification process 736 during the boot process, the version control module 841 uses the verification signal 733 (step 902) to indicate whether there was a value h hash functions were verified during the signature verification process 736. If this is not the case, then version control module 841 blocks the value of h, i.e. the version control process and the MAC calculation stop. If signal 733 indicates that the hash value is genuine, then version control module 841 continues to operate at 903.

At 903, the version control module 841 compares the received hash value with the hash values in the version control list 842. If the accepted value h of the hash function equals one of the previous values h _{prev of the} hash function in the version control list 842, then the version control module 841 continues to operate at block 904; otherwise, the process continues to block 906.

At step 904, i.e. if the accepted value of the hash function h is equal to one of the previous values of the _{prev prev of the} hash function, the process extracts the corresponding tuple of four elements (rand, h, cnt, back_cnt) _prev and determines whether the counter cnt _prev value of the previous version is in the allowed the range that is determined by the cnt and back_cnt values received from the signature verification process 736. In some embodiments, the allowed range is defined as the range [cnt _top -back_cnt, ∞), where cnt _top is the cnt value of the current top element of the list. For simplicity, it is assumed that there is no upper limit to the range of allowed values. However, it should be understood that in other embodiments, the upper limit can be determined.

If cnt _prev is in the allowed range, then version control module 841 generates (step 905) a new tuple of four elements (rand, h, cnt, back_cnt) _new with rand _new components — a new random value generated by version control module 841, h _new = h, cnt _new = cnt _prev , back_cnt _new = back_cnt _prev , and the version control module replaces the previous tuple with the same value of h with a new tuple and sets the new tuple as the top item in the list.

If the check in step 903 shows that h is not equal to any of the previous values of the hash function, then the new random value, the value of h of the hash function and the counter are stored together with the allowed back_cnt (associated with this h) in the version control list ( step 906). In this case, a new tuple of four elements (rand, h, cnt, back_cnt) _{new is} created according to: rand _new = new random value, h _new = h, cnt _new = cnt, back_cnt _new = minimum value (back_cnt, cnt - min_allowed_version) , and the new tuple becomes the top item in the list. In this case, min_allowed_version is the current lowest version allowed by any tuple in the update list. After the entry has been placed on the top of the update list, min_allowed_version is recalculated as cnt _top -back_cnt _top , i.e. from the cnt _top and back_cnt counters of the version of the top element (step 907). Finally, all the items in the list are updated (step 908) so that their back_cnt values are the highest values that do not specify a version number that is lower than the lowest allowed version of min_allowed_version. If the list contains an entry with a version that is out of the allowed range, then this entry will be deleted.

In some embodiments, the MAC Validation Value (MACLIST) is associated with a version control list to prevent unauthorized forgery of entries in the list, thereby further increasing the security of the method. The value of MACLIST is updated only when the list is updated, i.e. after successful verification of the signature. Before accessing / using the version control list, the current MAC check value can be checked against the MACLIST value. To prevent unauthorized calculations of the MACLIST value, the MAC circuit only provides the calculated MAC value when the successful signature verification preceded the calculations (which is controlled by block 734 in FIGS. 7 and 8).

Consequently, the stored MAC reference value and version control list are now available for subsequent verification of the software and data by the processor. For example, to verify the integrity of stored software, the processor calculates the control value h _a = h (SW) of the hash function of the stored software and data and generates a control tuple (rand, h _a , cnt, back_cnt) with the values rand, cnt and back_cont extracted from the version control list. From this, the processor calculates the MAC control value t _a = MAC ((rand, h _a , cnt, back_cnt); K) of the computed control tuple using the unique key of the crystal K. The processor compares the calculated MAC t _a control value with the stored reference value MAC t _r . If the two values are equal, then check the integrity of the software.

As described above, such verification may be performed during the download process of the mobile terminal, and / or each time the software is to be executed, and / or periodically at predetermined time intervals.

The above process will now be further illustrated by way of example and with respect to FIG. 10.

10 illustrates an example version control mechanism where a version 3 version control list is used, i.e. a version control list can store three tuples. In this example, it is additionally assumed that there is a sequence of 8 releases of the software version with the following values (h, cnt, back_cnt) of the h values of the hash function, cnt version counter and back_cnt counter, received from the signature verification process:

version 1: (H1, 1, 0),

version 2: (H2, 2, 1),

version 3: (H3, 3, 2),

version 4: (H4, 4, 3),

version 5: (H5, 5, 2),

version 6: (H6, 6, 3),

version 7: (H7, 7, 4) and

version 8: (H8, 8, 4).

Additionally, it is assumed that the above versions were applied sequentially, except for version 7, which was not applied. 10 shows a version control list 1001 after installing version 8. Each row of the version control list 1001 includes a corresponding tuple of four elements for one of the installed versions: line 1002, the top of the list corresponds to version 8, line 1003 corresponds to version 6, and line 1004 corresponds to version 5. R8, R6 and R5 are random numbers generated by the version control module, as described above. After version 8 was applied, the youngest allowed version was 4 (since the cnt value of version 8 is 8, and the value of back_cnt version 8 is 4, and 8-4 = 4), so min_allowed_version = 4. Accordingly, the values The back_cnt of the rest of the entries in the list were adjusted during the installation of version 8 to match the limitation on the lowest permitted version after version 8 was added. In particular, the back_cnt value in line 1002 is set to 2, and the back_cnt value in line 1003 is set to 1. Prior to version 8 upgrade, the smallest permitted version was 3, but this value was raised to 4 through version 8.

10 further shows a version control table 1011 after installing version 7. First of all, the cnt value of the counter of version 7 is 7, i.e. is in the allowed range of the current version. The H7 value of the hash function does not yet exist in the version control list 1001, therefore, the new four-element tuple 1007 with the new H7 value of the hash function is stored as the new top element 1012 of the version control table 1011. The previous top item is moved down in the list, and it corresponds to line 1013. Version 6 is now placed on line 1014, while version 5 is removed from the list, because in this example there is only three tuples of four items in the version control list . The back_cnt value of the new top element 1012 is set to 3 in order to satisfy the limitation of the current smallest permitted version (min_allowed_version = 4).

11 shows a flowchart of a software download process for updating a software. The process is similar to the software bootstrap process shown in FIG.

At an initial step 1101, the mobile terminal receives a software update data packet from the reprogramming means via a local or remote interface, for example GSM, WCDMA, etc., as described above. The package contains a new software update Δ, one or more C certificates and a digital signature S (h _r ) of the protected software, as described above in connection with FIG. In addition, the software may further include data, such as updated configuration data. In one embodiment, the new software is downloaded as a so-called delta file, including the differences between the new software and the current software, thereby reducing the size of the update package. The delta file technique is known from the prior art and is described, for example, in “Delta storage for arbitrary non-text files”, by Christian Reichenberger, Proc. Of the 3rd International Workshop on Software Configuration Management, p. 144-152, Norway, June 1991. Alternatively, other methods for generating the update file may be used, or the whole new software may be accepted. The signature S (h _r ) contains the encrypted hash value calculated from the new software. The signature is calculated so that first the value h _r = H (SW) of the one-way hash function of the new SW software is calculated, and subsequently, the value of the hash function is encrypted with the private key of the public / private key pair, for example, the public / private RSA key pair. The software update package includes a certificate that includes the corresponding public key. Upon receipt of the software update package, the mobile terminal stores the software update, certificate (s) and signature in the external storage device 106.

At 1102, the mobile terminal processor reads the recently saved software update, certificate (s) C, and signature S (h _r ) into its internal storage device.

At 1122, the processor performs version control. The mobile terminal accepts the new software version number as part of the service pack. The version number of the new software is checked against the version number of the current software stored in an external storage device (protected by MAC). If the new software version number is lower than the old software version number, then the mobile terminal stops the update process. In another embodiment, the version control process described in connection with FIGS. 8 and 9 is performed.

If the version control step 1122 is successful, the process continues to step 1123, where the processor generates new SW _new software from the received delta file Δ and the current SW _prev software version stored in an external memory device (protected by MAC).

At step 1103, the processor calculates a control value h _a = H (SW _new ) of the one-way hash function of the new SW _new software.

At 1104, the processor reads the root public key PK from the storage device 1105. In some embodiments, the root public key is securely stored, i.e. protect integrity. In one embodiment, the root public key is stored in the internal ROM of the processor, as described above. The processor uses the PK root public key to verify the signature S (h _r ) of the new software. If only one certificate is used, then the signature S (h _r ) is checked against the public key in certificate C. Certificate C, in turn, is then checked against the PK root public key. If multiple certificates are used, then the entire certificate chain is checked. In this case, the signature of the last certificate in the chain is verified against the root public key. Then, at 1104, the processor checks the public key used to sign the new software. If the verification is successful, then the processor continues to step 1106 with the verification of the signature. Otherwise, the software download process is stopped.

At 1106, the processor decrypts the digital signature S (h _r ) of the software using the public key verified at 1104 to obtain a hash reference value h _r .

At step 1107, the decrypted signature, i.e. the reference value h _{r of the} hash function is checked with respect to the control value h _{a of the} one-way hash function calculated in step 1103. If the verification is successful, i.e. if the hash reference value h _{a and the} hash reference value h _r are equal, then the processor continues at step 1108 with the calculation of the message authentication code (MAC). Otherwise, the software download process is stopped.

At 1108, the processor uses the verified value of h _a one-way hash function and the unique chip of the crystal K (or the value obtained from K) as the input value of the MAC calculation function, obtaining the reference value t _r = MAC (h _a ; K) of the message authentication code . The output value of the MAC function is the MAC reference value of the new software. In some embodiments, the unique K key of the crystal is burned in the crystal during the manufacturing process using, for example, the so-called e-fuse (electrically fired jumper) technology. Alternatively, the K key is stored in another secure memory that is accessible only to the processor. Embodiments of the message authentication code have been described above. The processor stores the new reference value MAC t _r in the external storage device 106 along with new software. The previous MAC value is deleted. Additionally, the certificate (s) and digital signature values can be deleted from external memory. The new SW _new software version is stored in the external storage device, and the old software version is deleted.

The download process described above is controlled by the processor of the mobile terminal. In a dual-chip architecture, as described in connection with FIGS. 3 and 4, the above steps are performed using a chip 311, which will subsequently execute the software.

Therefore, the powerful software signing mechanism for protecting software for many different systems is described above. This mechanism is effectively combined with an integrity protection mechanism based on a symmetric key for reliable software storage. As soon as SW is installed on the platform, a mechanism based on a symmetric key is used and the advantages of the calculations made earlier are used. In addition, this paper describes an integrated software protection and version control mechanism.

Provided storage integrity protection is particularly beneficial in connection with a dual-CPU architecture, when non-volatile memory is associated with an unreliable CPU, and when there is a need for SW updates.

Although some embodiments are described and shown in detail, the invention is not limited to them, but may also be embodied in other ways within the scope of the invention defined in the following claims.

In particular, embodiments are described mainly with respect to a mobile terminal as an example of a data processing device. It should be understood, however, that the described method, software product and device can also be applied to other data processing devices.

The described method, software product and device can be implemented through hardware containing several different elements, and through an appropriately programmed microprocessor. Several devices are listed in the claims, some of these tools can be implemented using the same hardware element, for example using a suitably programmed microprocessor, one or more digital signal processors, or similar devices. The fact that certain criteria are listed in the different dependent claims or described in various embodiments does not indicate that a combination of these criteria cannot be used to advantage.

It should be emphasized that the terms "contains / containing", which are used in this description, are used to determine the presence of the claimed features, steps or components, which does not impede the presence or addition of one or more other features, steps, components or groups thereof.

Claims (34)

1. A method of loading data into a data processing device, the method comprising the steps of:
receiving a payload data element using a data processing device; performing a cryptographic authentication process to ensure the authenticity of the payload data element, wherein the cryptographic authentication process comprises computing a hash control value for at least the received data element;
storing the authenticated received payload data element in the data processing device; and
protect the integrity of the stored payload data item,
characterized in that
integrity protection further comprises calculating a reference value of the message authentication code for at least the hash control value calculated during said cryptographic authentication process, the calculation of the message authentication code value using a secret key stored in the data processing device as input. 2. The method according to claim 1, in which the cryptographic authentication process includes the steps of:
accept the reference value of the hash function; and
comparing the received reference value of the hash function with the calculated control value of the hash function to verify the authenticity of the received payload data element. 3. The method of claim 2, wherein the cryptographic authentication process includes digitally signing a data item in accordance with a public key cryptosystem. 4. The method according to claim 3, containing stages in which:
receiving a payload data element, a digital signature data element and a digitally signed digital certificate data element, the digital certificate data element including a first public key, and the digital signature data element including a hash reference value encrypted with the first private key corresponding to the first public key;
authenticating the digital certificate signed data item with respect to the root public key stored in the data processing device;
authenticating the digital signature data element with respect to the authenticated digital certificate;
comparing the received reference value of the hash function with the calculated control value of the hash function to verify the authenticity of the received payload data element. 5. The method according to claim 3 or 4, further comprising cryptographic authentication of the reference value of the hash function; and in which the calculation of the reference value of the authentication code of the message is performed only if the reference value of the hash function is successfully authenticated. 6. The method of claim 1, wherein the integrity protection further comprises storing a computed message authentication code reference value for a received payload data element. 7. The method according to claim 1, in which the calculation of the reference value of the authentication code of the message further comprises calculating the reference value of the authentication code of the message for the combined data item obtained from at least the control value of the hash function and a random number. 8. The method according to claim 1, wherein calculating a reference value of the message authentication code further comprises calculating a reference value of the message authentication code for the combined data item obtained from at least the hash control value and the version control data item. 9. The method of claim 8, further comprising storing a record of the version control data in the structure of the version control data, wherein the record of the version control data includes information about a received payload data element including at least a version control data element. 10. The method according to claim 9, in which the integrity of the stored record of version control data is protected. 11. The method according to claim 9 or 10, wherein the recording of version control data comprises a version counter. 12. The method according to claim 11, in which the recording of version control data further comprises a countdown counter identifying the number of previous versions with which the current version of the payload data element can be replaced. 13. The method according to claim 1, in which the secret key is a secret data element that is unique to the data processing device. 14. The method according to claim 1, in which the secret key is a secret data element, known only to the data processing device. 15. The method according to claim 1, wherein receiving a payload data element comprises receiving a delta update of a previously received current data element and generating a payload data element as an updated payload data element from a previously received current data element and a received delta update. 16. A computer-readable medium comprising program code means configured to cause the data processing device to perform the steps of the method according to any one of claims 1 to 15, when said computer program is executed in the data processing device. 17. A data processing device containing a first processing circuit, configured to perform the method according to any one of claims 1 to 15. 18. The data processing apparatus according to claim 17, further comprising storage means configured to store the received payload data element; and a second processing circuit associated with the storage means and the first processing circuit; moreover, the second processing circuit is configured to provide the first processing circuit with at least read access to the storage medium. 19. The data processing device according to claim 17 or 18, wherein the first processing circuit comprises a local storage means for storing the root public key of an asymmetric cryptographic system. 20. The data processing apparatus according to claim 17, wherein the first processing circuit comprises a local storage means for storing said secret key. 21. A method for protecting the integrity of the current version of a data item stored in a data processing device, the method comprising the steps of:
determining a reference value of the hash function of at least the data item;
calculating the reference value of the message authentication code from the determined reference hash value using the secret key stored in the data processing device;
storing the calculated reference message authentication code value for the data item,
characterized in that
calculating a reference value of the message authentication code comprises calculating a reference value of the message authentication code from the combined data item obtained from the determined hash function reference value and at least a part of the version control data record, the version control data recording including a version counter; and in which the calculation of the reference value of the authentication code of the message comprises calculating the reference value of the authentication code of the message from the combined data item obtained from the determined reference value of the hash function, and at least a version counter. 22. The method according to item 21, in which the record of version control data further comprises a countdown counter identifying the number of previous versions with which the current version can be replaced; and in which the calculation of the reference value of the authentication code of the message includes the calculation of the reference value of the authentication code of the message from the combined data item obtained from a specific reference value of the hash function and at least from a countdown counter. 23. The method according to any one of paragraphs.21 and 22, in which the record version control data further comprises a reference hash value for the current version of the data item. 24. The method of claim 21, further comprising generating a version control data record; and storing the version control data record in the version control data structure. 25. The method according to paragraph 24, further comprising protecting the integrity of the record data version control. 26. The method according to item 21, in which the secret key is a secret data element that is unique to a data processing device. 27. The method according to item 21, in which the secret key is a secret data element, known only to the data processing device. 28. The method according to item 21, further comprising stages in which:
receive a delta update of a previously received current data item; and
generating a data item as an updated data item from a previously received current data item and a received delta update. 29. A method for checking the integrity of the current version of a data item stored in a data processing device, the method comprising the steps of:
calculating the control value of the hash function of the data item;
calculating a control value of the message authentication code from the calculated control value of the hash function using a secret key stored in the data processing device;
comparing the calculated control value of the message authentication code with the reference value of the message authentication code stored for the data item,
characterized in that
the method further comprises extracting a record of version control data, wherein the record of version control data includes a version counter indicating a current version of the data item; and
that the calculation of the control value of the authentication code of the message includes the calculation of the control value of the authentication code of the message from the combined data item obtained from the calculated control value of the hash function, and at least a version counter. 30. The method according to item 21 or 29, in which the data item is loaded using the method according to any one of claims 1 to 15. 31. A data processing device comprising storage means for storing a current version of a data item and recording version control data, the recording of version control data including version control information about a current version of the data item; and processing means configured to perform the method according to any one of paragraphs.21-28. 32. A data processing device comprising storage means for storing a current version of a data item and recording version control data, the recording of version control data including version control information about a current version of the data item; and processing means configured to perform the method according to any one of claims 29 and 30. 33. A computer-readable medium comprising program code means configured to cause a data processing device to perform the steps of a method according to any one of claims 21 to 28 when said computer program is executed on the data processing device. 34. A computer-readable medium comprising program code means configured to cause the data processing device to perform the steps of the method according to any of claims 29 and 30 when said computer program is executed on the data processing device.

Images