KR20070074617A - Data loading method, data processing unit, data item integrity protection method, and data item integrity verification method - Google Patents

Abstract

A method of loading data into a data processing apparatus is disclosed. The method comprises the steps of: receiving a payload data item by the data processing device, performing a password authentication process to ensure authenticity of the payload data item, and receiving the authenticated received payload data item. Storing in the data processing device, and integrity protecting the stored payload data item. The cryptographic authentication process includes calculating at least an audit hash value of the received data item. The integrity protection step further includes calculating at least a reference message authentication code value of the audit hash value using a secret key stored in the data processing device as an input.

Description

Data loading methods, data processing units, methods for protecting the integrity of data items, and methods for verifying the integrity of data items {SECURE LOADING AND STORING OF DATA IN A DATA PROCESSING DEVICE}

Disclosed are a method, a product means and an apparatus for safely loading and storing data in a data processing apparatus.

Embedded systems such as mobile phones and other data processing devices rely on the execution of correct software that has not been illegally tampered with. Operation of the software can lead to incorrect behavior of the device or even destruction of the basic security functions of the device. Therefore, it is particularly important to protect the core software of the device. This can be accomplished, for example, by storing the program in protected memory. This memory may be physically protected from illegal access or protected by cryptographic methods. In practice, it is difficult or expensive to manufacture a memory with good physical protection and in particular to protect the memory interface. As a result, the most interesting solution is to use some type of password protection of the software stored in memory.

In addition, even software for quite small systems is becoming increasingly complex, thereby increasing the risk of errors and unintended behavior, especially in early releases during the software life cycle. In addition, the functionality of early software distributions is generally limited. As a result, there is an increasing need for frequent updates of software stored on embedded devices.

The need for frequent updates and the need to provide sufficient protection for the software of the data processing device requires a security solution that protects the software of the data processing device in the storage device and also enables secure software upgrades.

U. S. Patent No. 6,026, 293 discloses a method of preventing electronic memory modulation in an electronic device. According to this prior art method, when the electronic device is to be reprogrammed by the data transmission device, the electronic device initiates a public / private based challenge-response authentication scheme to authenticate the data transmission device. Once authenticated, the data transfer device is allowed to access to reprogram the memory. After reprogramming the memory, the electronic device performs a hash calculation of the modified memory contents. The calculated hash value is sent to the data transmission device for digital signature, and the signed hash value is returned to the electronic device for storage. This signed hash value is used later to audit the integrity of the memory contents, for example during boot up or periodically.

While the prior art method described above provides both authentication protection during the loading phase and integrity protection of the memory contents of the electronic device, this requires a fairly complex way of generating a hash value and signing the generated hash value. The load process takes quite a long time.

Therefore, it is a problem to provide a computationally more efficient security mechanism that protects the software while loading the software onto the device and subsequently while the software is stored on the device.

The above and other problems are solved by a method of loading data into a data processing apparatus, which method,

Receiving a payload data item by the data processing device,

Performing a password authentication process to ensure authenticity of the payload data item,

Storing the authenticated received payload data item in the data processing device, and

-Integrity protecting said stored payload data item,

Performing the cryptographic authentication process includes calculating at least an audit hash value of the received data item, wherein the integrity protection step uses, as input, a secret key stored in the data processing device. Calculating at least a reference message authentication code value of the audit hash value.

Specifically, since the audit hash value calculated during the load process is calculated from the received payload data and the audit hash value is reused later during the calculation of the message authentication code, the number of necessary calculations performed during the software load is reduced, thereby The calculation efficiency of this method is increased.

In addition, since conventional integrity protection is based on the private key stored in the data processing device, the integrity protection is independent of any external cryptographic key, and in particular does not rely on the public key signature mechanism. The advantage is that symmetric key based integrity checking, i.e. integrity checking based on message authentication code, is computationally more efficient than public key based integrity checking involving signature verification.

The term 'data processing device' is intended to include any electronic device that includes a data memory into which data can be loaded from an external source, such as a data transmission system. Specifically, the term 'data processing device' is intended to include any electronic equipment, portable wireless communication equipment, and other handheld or portable devices. The term 'portable wireless communication equipment' includes all equipment such as mobile phones, pagers, communicators, electronic organizers, smart phones, personal digital assistants (PDAs), handheld computers, and the like.

The term 'payload data item' is intended to include any data loaded into the data processing device. Specifically, the term 'payload data item' is intended to include configuration data, program code, such as platform software or application software for execution on a device, and the like.

The password authentication process is any suitable cryptographic process for verifying the authenticity of the received data, i.e. to ensure that the data has actually been transmitted by the entity whose name it carries and also that the data has not been forged or altered. Can be.

In some embodiments, the password authentication process,

Receiving a reference hash value, and

Comparing the received reference hash value with the calculated audit hash value to verify the authenticity of the received payload data item.

In another embodiment, the cryptographic authentication process includes digitally signing the data item in accordance with a public key cryptosystem. Digital signature of software is an efficient and safe principle for the verification of software loaded on mobile devices. Successful verification of the signature ensures that the software has been issued by a legitimate source. In addition, digital signatures based on public key technology have the advantage that the public key used for verification does not have to be confidential when transmitted or stored. Thus, the same public key can be installed in a large number of devices without weakening security. This allows an efficient procedure for fast and secure software upgrades.

In some embodiments, the method,

Receiving the payload data item, the digital signature data item, and the digitally signed digital certificate data item, wherein the digital certificate data item includes a first public key, and the digital signature data item is stored in the first public key. Contains a reference hash value encrypted with the corresponding first secret key-,

Authenticating the digitally signed digital certificate data item against a root public key stored in the data processing device,

-Authenticating the digital signature data item against the authenticated digital certificate, and

Comparing the received reference hash value with the calculated audit hash value to verify the authenticity of the received payload data item.

Thus, the authenticity of the digital signature is guaranteed by the digital certificate, thus improving the security of the loading process. It is well understood that a data processing device may receive two or more digital certificates that form a certificate chain, and that one certificate in this chain is verified by a public root key stored in the data processing device. will be.

In another embodiment, the reference hash value is cryptographically authenticated and the step of calculating the reference message authentication code value is performed only if the reference hash value is successfully authenticated. As a result, the execution of the message authentication code procedure at the data processing device is subject to the receipt of an authenticated reference hash value, whereby an attacker may use the message authentication code procedure of the data processing device to calculate an unauthorized message authentication code value. Reduce the risk.

A message authentication code (MAC) is a known mechanism for integrity protection of a message. MAC is a function that takes a variable length input and a key and produces a fixed-length output, a so-called MAC value or a tag value. MAC is typically used between these parties to verify the information sent between two parties sharing a secret key. In some embodiments, the MAC is calculated by applying a one-way hash function to the payload data and encrypting the result using a secret key. Examples of suitable MAC functions that may be combined with cryptographic hash functions include Keyed-Hashing for Message Authentication (HMAC), for example, Cipher Block Chaining (CBC) MAC using AES or secure one-way hash functions. In the load method described herein, the message authentication code is used to check the integrity of the data stored on an untrusted or insecure medium, ie in this situation, when storing and retrieving payload data items, the MAC Is used only by one party, namely the data processing device.

As a result, in some embodiments, the integrity protecting step further includes storing the calculated reference message authentication code value in relation to the received payload data item, whereby the reference message authentication code value is stored in the data. Make the payload data item available for subsequent memory auditing by the processing device. Thus, when auditing the memory contents, the device calculates the message authentication code value of the stored payload data item using the secret key stored in the device, and compares the result with a previously stored reference MAC value. As a result, 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 item unique to the data processing device, eg, a secret data item known only to the data processing device.

In another embodiment, calculating the reference message authentication code value further comprises calculating the reference message authentication code value of a combined data item derived from at least the audit hash value and a random number. The advantage of this embodiment is that the input to the MAC does not depend at all on the result of the authentication process, thus improving the security of data protection.

Calculating the reference message authentication code value further comprises calculating the reference message authentication code value of a combined data item derived from at least the audit hash value and a version control data item, the integrity protection being version It is effectively combined with the control mechanism because subsequent memory audits are only successful if both the memory content and the version control information match.

In some embodiments, a version control data record is stored in a version control data structure, wherein the version control data record includes information regarding the received payload data item including at least the version control data item. In some embodiments, the control data structure is integrity protected.

In some embodiments, the version control data record includes a version counter. In some embodiments, the version control data record further comprises a back counter identifying a number of previous versions that can replace the current version of the payload data item, thereby controlling backward compatibility. It provides a simple and efficient version control mechanism that includes a mechanism.

In known software upgrade schemes in which existing software is upgraded by new versions of software, software upgrades are often received as so-called delta files or delta updates. This delta update includes the new (updated) software difference to the current software, thus reducing the size of the upgrade packet. In some delta-file descriptions, the update file also includes instructions for controlling generation of updated software versions from current software and received updates. Delta-file techniques are known per se in the art and are described, for example, in Christian Reichenberger's "Delta storage for arbitary non-text files", Proc. Of the 3rd International Workshop on Software Configuration Management, pp. 144-152, Norway, June 1991. It is desirable to provide an efficient security mechanism that can also be applied to delta updates. The problem is that receiving the payload data item includes receiving a delta update of a previously received current data item, and from the previously received current data item and the received delta update. And generating the payload data item as an updated payload data item. Thus, according to this embodiment, an updated payload data item is generated and an audit hash value is calculated from the updated payload data item. As a result, the audit hash value can be reused for the calculation of the reference message authentication code of the updated payload data stored in other words the device.

According to a second aspect, a problem of the prior art system is to provide an efficient and safe method of protecting the integrity of the current version of data items stored in the data processing device in the event of frequent upgrades of different versions of stored data items. will be.

The above and other problems are solved by a method of protecting the integrity of the data item of the current version stored in the data processing device, which method,

Determining at least a reference hash value of the data item,

Calculating a reference message authentication code value from the determined reference hash value using a secret key stored in the data processing apparatus, and

Storing the calculated reference message authentication code value in association with the data item,

Calculating the reference message authentication code value comprises calculating the reference message authentication code value from a combined data item derived from at least a portion of the determined reference hash value and a version control data record, wherein the version control data The record may include version control information about the data item of the current version.

Thus, by calculating the reference message authentication code value from a combined data item derived from at least a portion of the determined reference hash value and version control data record, integrity protection of the stored payload data may be achieved by secure version control of the stored data. Combined efficiently.

At least a reference hash value of the data item is determined by calculating the hash value from the data item or by receiving the hash value from an authentication process in conjunction with the data item or in connection with receiving the data item as described herein. Can be determined.

The term 'combined data item' is a function of two or more data items, for example, any data item that occurs as a concatenation of two or more data items to which one data item is attached to the other data item. It is intended to be included. Thus, a combined data item derived from at least a portion of the determined reference hash value and version control data record is generated as a function of at least the reference hash value and at least a portion of the version control data record.

In some embodiments, the version control data record is integrity protected.

In some embodiments, the version control data record comprises a version counter, and the step of calculating the reference message authentication code value comprises a reference message authentication code from the determined audit hash value and at least a combined data item derived from the version counter. Calculating a value.

In some embodiments, the version control data record further comprises a back counter that identifies the number of previous versions that can replace the payload data item of the current version, thereby including a mechanism to control backward compatibility. And provide an efficient version control mechanism. In some embodiments, calculating the reference message authentication code value comprises calculating a reference message authentication code value from the determined reference hash value and at least a combined data item derived from the back counter.

In another embodiment, the version control data record further includes the reference hash value for the data item of the current version, thereby providing a compact fingerprint of the data item.

In some embodiments, the secret key is known only to the 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 by the first mentioned method, thereby efficiently combining safe load and store with safe version control.

In another embodiment, the method,

Receiving a delta update of a previously received current data item, and

Generating the data item as an updated data item from the previously received current data item and the received delta update.

In another embodiment, the method includes generating the version control data record, and storing the version control data record in a version control data structure, thereby making the version control data record available for future memory auditing. It includes the steps to make.

Thus, in another aspect, a method of verifying the integrity of a data item of a current version stored in a data processing device,

Calculating an audit hash value of the data item,

Calculating an audit message authentication code value from the calculated audit hash value using a secret key stored in the data processing device, and

Comparing the calculated audit message authentication code value with a stored reference message authentication code value in relation to the data item.

According to this aspect, the method further comprises retrieving a version control data record, the version control data record comprising version control information relating to a data item of the current version,

Computing the audit message authentication code value includes calculating an audit message authentication code value from the calculated audit hash value and a combined data item derived from at least a portion of the version control data record.

The present invention relates to other aspects, including the methods described above and below, and a corresponding apparatus, and a computer program, each of which is one of the advantages and advantages described in connection with one of the methods described above. In addition, each of these has one or more embodiments corresponding to the embodiments described in connection with one of the methods described above.

More specifically, according to another aspect, the data processing apparatus includes a first processing circuit adapted to perform a method of loading data into the data processing apparatus as described above and below.

In particular, it has been found that the security mechanisms described herein can be advantageously applied to devices having a multichip architecture. Specifically, when the first of the chips accesses the memory through the second of the chips, it is particularly important that the first chip ensures data authenticity and integrity of the memory contents.

As a result, in some embodiments, the data processing apparatus further comprises storage means adapted to store the received payload data item, and a second processing circuit connected to the storage means and the first processing circuit, wherein the second The processing circuit is configured to provide the first processing circuit with at least read access to the storage means.

In another embodiment, the first processing circuit comprises local storage means for storing a root public key of an asymmetric cryptographic system. In another embodiment, the first processing circuit includes local storage means for storing the secret key, thereby providing secure storage under control of a first chip of an encryption key used in data authenticity and integrity mechanisms.

According to another aspect, a data processing apparatus includes: storage means for storing a data item and a version control data record of a current version, wherein the version control data record includes version control information relating to the data item of the current version; It also includes processing means adapted to perform a method for verifying the integrity of a data item of a current version described below.

It should be noted that the features of the methods described above and below can also be implemented in software and executed on other processing means as a result of the execution of program code means, such as a data processing apparatus or computer executable instructions. Here also and hereinafter, the term 'processing means' includes any circuitry and / or apparatus suitably adapted to perform the above functions. Specifically, the term is used for general purpose or dedicated programmable microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), programmable logic arrays (PLAs), field programmable gate arrays (FPGS), and dedicated electronic circuits. , And the like, or combinations thereof.

Thus, according to another aspect, the computer program comprises program code means adapted to cause the data processing apparatus to perform the steps of the method described above and below when the computer program is executed on the data processing apparatus. .

For example, the program code means may be loaded into a memory, such as a random access memory (RAM), from a storage medium or from another computer via a computer network. As another alternative, the described features may be implemented by a hardwired circuit instead of or in combination with software.

The foregoing and other aspects will become apparent and apparent from the embodiments described below with reference to the drawings.

1 is a schematic block diagram of a system for loading data into a mobile terminal.

2 is a schematic block diagram of an example of a mobile terminal having a single chip architecture.

3 is a schematic block diagram of an example of a mobile terminal having a two-chip architecture.

4 is a schematic block diagram of another example of a mobile terminal having a two-chip architecture.

5 illustrates an example of a message structure used in a loading process for loading software into a mobile terminal.

6 is a flowchart of a software loading process for initial loading of a software version.

7 is a diagram illustrating calculation of an embodiment of a message authentication code.

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

9 is a flowchart of a version control process.

10 shows an example of a version control mechanism.

11 is a flowchart of a software loading process for software upgrade.

1 shows a schematic block diagram of a system for loading data into a mobile terminal. The system includes a loading station 101 and a mobile terminal 102.

The loading station may be a conventional, properly programmed computer, for example a PC, including a suitable communication interface. In some embodiments, the loading station may generate payload data to be loaded, eg, software version, configuration data, and / or the like. In detail, the loading station can generate a digital signature and certificate to be loaded with payload data. In another embodiment, the loading station receives payload data and header information from a remote computer, such as a personal computer, workstation, network server, or the like. For example, the data may be transmitted over a computer network, such as the Internet, a local area network, an intranet, an extranet, or the like, or by any other suitable means, for example, a computer such as a floppy disk, CD ROM, or the like. May be received on a readable medium. In this embodiment, the calculation of the signature and the generation of the certificate can be performed by a remote computer rather than a loading station. The loading station, in cooperation with the mobile terminal, performs the task of loading data into the mobile terminal.

The mobile terminal 102 is a communication including circuitry and / or apparatus suitable for enabling the mobile terminal to communicate data with the loading station via a wired or wireless communication link 103 such as a direct data link, a communication network, or the like. Interface 104. For example, data may be loaded via a local short range wireless communications link, such as a Bluetooth connection, an infrared connection, or the like or via a wired interface. In another embodiment, data may be loaded to a mobile terminal via a communication network, for example via over-the-air (OTA) via a cellular telecommunication network such as GSM, WCDMA, and the like.

As a result, examples of suitable communication units include wired serial communication, such as an RS-232 link, a USB connection, a FireWire connection described in the IEEE 1394 standard, and the like. Other examples include an RF interface, such as a wireless infrared interface, or a primary antenna of a cellular telephone (not shown) or another antenna (bluetooth transceiver, etc.) within a cellular telephone. Other examples of suitable interfaces include cable modems, telephone modems, integrated services digital network (ISDN) adapters, digital subscriber line (DSL) adapters, satellite transceivers, Ethernet adapters, and the like.

The mobile terminal further includes a processing unit 105 that controls the operation of the mobile terminal, and a memory 106. For example, the processing unit may be a general purpose or dedicated programmable microprocessor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a programmable logic array (PLA), a field programmable gate array (FPGA), or the like, or Combinations thereof. Memory 106 may be any other type of memory or storage device, such as flash memory, EPROM, EEPROM, or nonvolatile memory.

When data is loaded into the mobile terminal, the processing unit 105 performs the data authentication and integrity protection described herein and stores the data in the memory 106.

During subsequent operation of the mobile terminal, the processing unit may retrieve the loaded data from the memory 106. For example, in the case of software, the processing unit loads software from memory 106 into RAM for execution.

2 shows a block diagram of an example of a mobile terminal having a single-chip architecture. The mobile terminal 101 includes a controller 105 that controls the operation of the mobile terminal. Controller 105 operates in conjunction with flash program memory 106 and random access memory (RAM) 209. The controller 105 includes a microprocessor 208, an internal read only memory (ROM) 207, and a securely stored secret key 218. For example, the secret key 218 can be a chip-specific key that is stored, for example, in hardware (eg, using so-called e-fuse technology). Alternatively, the secret key may be stored in ROM 207. ROM 207 includes a boot code, hashing code, MAC code, authentication code, and public root key. In some embodiments, the hashing code and / or MAC code may be implemented at least partially in hardware instead of or in addition to implementing in ROM. Instruction code associated with general operation of a cellular telephone is contained in flash program memory 106. RAM memory 209 is used for operations that are part of normal mobile terminal call processing. In some embodiments, operations involving sensitive data, hash value calculation, and authentication processes are performed in connection with protected static random access memory (PSRAM) (not shown) included in microcontroller 105. . The controller 105 communicates with the flash program memory 106 and the RAM 209 via the memory bus 219.

3 shows a schematic block diagram of an example of a mobile terminal having a two-chip architecture. In this embodiment, the controller 105 includes two chips (310 and 313, respectively), an external memory 106 and an internal memory 209. Each of these two chips includes at least one microprocessor (312, 315, respectively), and ROM (311, 314, respectively). External memory 106 is any suitable type of nonvolatile memory, for example flash memory. Internal memory 209 is a fast access memory, for example RAM. In the embodiment of FIG. 3, the two chips share internal memory 209. In addition, in this embodiment, only the chip 313 directly accesses the external memory 106. Thus, when the processor 312 of the chip 310 needs to execute software stored in the external memory 106, the software to be executed is loaded into the internal memory 209 through the chip 313 before it can be executed. . In this embodiment, both ROMs 311 and 314 include boot code, only ROM 311 includes hashing code, MAC code, authentication code, and public root key, and only chip 310 with secret key 318. ). As described above, the secret key 318 may be stored in hardware (eg, using so-called e-fuse technology). As another alternative, the secret key may be stored in ROM 311. In addition, in some embodiments, the hashing code and / or MAC code may be implemented at least partially in hardware instead of or in addition to being implemented in ROM.

4 shows a schematic block diagram of another example of a mobile terminal having a two-chip architecture. This embodiment is similar to the embodiment of FIG. 3 except that the two chips 310, 313 of this embodiment do not share a common internal memory. Instead, each chip has its own internal memory 416, 417, respectively. As in the embodiment of FIG. 3, only the chip 313 directly accesses the external memory 106. Thus, when the processor 312 of the chip 310 needs to execute software stored in the external memory 106, the software to be executed may be executed by the chip 313 through the internal memory of the chip 310 through the chip 313. 416).

In an alternative two-chip embodiment with shared or separate random access memory (RAM), both chips can directly access external nonvolatile memory and also run the software to be executed directly from or load it into RAM first. Can be run on

5 shows an example of a message structure used in a loading process for loading software into a mobile terminal. The message 520 includes a header section 521, a payload section 522, a digital certificate section 523, and a digital signature 524.

Payload section 522 contains actual payload data to be loaded into the mobile terminal. This payload data may include application software, pre-loader software that organizes and / or controls the loading of other software, portions of the operating system of the mobile terminal, and so forth. Alternatively or in addition, the payload data may include configuration data for storing in other data, eg, flash memory or other memory of the mobile terminal (eg, EPROM, EEPROM, etc.). .

Header section 521 may include information about payload data (eg, version control data, etc.), information about the mobile terminal, control parameters that determine how the mobile terminal should process the data, and / or the like. , Information related to the loading process.

The signature section contains the digital signature of the payload 522. Digital signatures are calculated using public-private key pairs of asymmetric cryptosystems (e.g., RSA (Rivest, Shamir and Adleman) systems). The digital signature is initially calculated by calculating the payload data, ie the one-way hash function of the software and / or data to be loaded into the mobile terminal. The computed hash value is then encrypted with the secret key of the public-private key pair.

The one-way hash function is used to derive a hash value representative of payload data 522. The public / private system is used to provide security for valid hash values and to authenticate the loading station or data transmission device from which the message 520 is sent.

One-way hash functions are simple to compute in all directions but difficult to compute in the reverse direction. The one-way hash function H (M) operates on a random-length input M (in some embodiments, consisting of payload data 522 or a selected portion of payload data). The hash function performed on M returns a fixed-length hash value h = H (M).

There are many functions that can take arbitrary-length inputs and return fixed length outputs, but the one-way hash function has the following additional features. Given M, it is easy to calculate h; given h, it is difficult to calculate M; given M, it is difficult to find another message M ', where H (M) = H (M'). The goal of a one-way hash is to provide M's own signature or fingerprint. The output of a hash function is called a hash value or message digest.

In embodiments of the method described herein, prior to sending the message 520 to the mobile terminal, a secure one-way hash function is performed on the payload data 522 or its selected content to generate a reference hash value. do. This reference hash value is included in the message 520 as a digital signature, as described further below. Upon receipt of message 520, the mobile terminal calculates an audit hash value of payload data 522 and compares this audit hash value with a reference hash value received as part of message 520.

Suitable one-way hash functions are, for example, SHA-1 functions. Other examples of suitable functions include the MD5 algorithm, Snerfu, H-Hash, MD2, MD4, and the like.

Public key algorithms use two keys, one is publicly available and one is privately held (secret) for such tasks as message encryption and decryption, message authentication, and digital signatures. When the sender encrypts the message with the secret key, any recipient with the corresponding public key can be assured of the authenticity of the sender, since only the sender who owns the secret key could encrypt the message. The latter approach is used to authenticate payload data according to the loading process described herein. A suitable public key algorithm is the RSA algorithm. Other suitable examples include Fiat-Shamir (FS) algorithms, ELGAMAL, DSA, Fiege-Fiat-Shamir, and the like.

Specifically, in the loading process described herein, the calculated hash value is encrypted with the loading station's private key to generate a digital signature 524 that is included in the message 520.

The corresponding public key is included in the certificate included in digital certificate section 523 of message 520. A digital certificate is a data structure used in a public key system to associate a particular authenticated person with a particular public key. A digital certificate is a digital representation of information that identifies the certification authority that issues this certificate, identifies the name of the individual whose public key is included or identifies it, and contains the public key of that individual. . The digital certificate is digitally signed by the issuing authority, thereby allowing the recipient to authenticate the certificate using the certificate authority's public key.

It will be appreciated that the digital certificate section may contain a single digital certificate or certificate chain. In either case, the certificate or certificate chain may be authenticated by the mobile terminal with a root public key corresponding to a single certificate or the last certificate in the certificate chain. An example of a key hierarchy relating to loading software into a mobile phone is described in WO 03/060673.

In some embodiments, it is well understood that the payload may be split into smaller portions or only this signature may be calculated, for example, as described in WO 03/060673 to calculate the digital signature. Will know.

In general, it is desirable to protect not only the header data 521 but also the payload data 522. In some embodiments, this is accomplished by protecting the header data 521 itself by digital signature. In another embodiment, the encryption of the calculated hash value is, for example, a hash value h (SW) calculated over software (and data) 522 and a hash value h (calculated over header data 521). Concatenation h (SW) | H (H) further comprises the encryption of the hash value calculated over the header data 521 by encrypting / signing.

6 shows a flowchart of the software loading process for initial loading of a software version.

In an initial step 601, the mobile terminal receives a software data packet from a reprogramming tool via a local or remote interface (eg, GSM, WCDMA, etc.), as described above. This packet contains a new software SW, one or more certificates C, and a digital signature S (h _r ) of the protected software and data, as described in connection with FIG. 5 above. Optionally, this new software may include data, for example configuration data. The signature S (h _r ) contains an encrypted hash value calculated from at least software and data. This signature is such that the one-way hash h _r = H (SW) of the software and data is first calculated and then at least the calculated hash value is encrypted with the secret key of the public-private key pair (e.g. RSA public-private pair). , Is calculated. The corresponding public key is included in the certificate contained in the software data packet. Upon receipt of the software and data packet, the mobile terminal stores software, data, certificate (s), and signature in external memory 106. As mentioned in connection with FIG. 5 above, in some embodiments, the signature may include header data as well as payload, for example, by encrypting a combination of hash values calculated from software and hash values calculated from headers. Can also protect.

In step 602, the processor of the mobile terminal reads newly stored software and data SW, certificate (s) C, and signature S (h _r ) into its internal memory.

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

In step 604, the processor reads the root public key PK from memory 605. In some embodiments, the root public key is stored securely, i.e. integrity protected. In one embodiment, the root public key is stored in an internal ROM of the processor, as described above. The processor uses the root public key PK to verify the signature S (h _r ) of the new software and data. If only one certificate is used, the signature S (h _r ) is verified against the public key in certificate C. This certificate C is in turn verified against the root public key PK. If several certificates are used, the entire certificate chain is verified. In that case, the signature of the last certificate in the chain is verified against the root public key. Thus, at step 604, the processor verifies the public key used to sign new software and data. If the verification succeeds, the processor proceeds to step 606 to verify the signature. Otherwise, the software loading process is interrupted.

In step 606, the processor decrypts the digital signature S (h _r ) of the software and data using the public key verified in step 604, resulting in a reference hash value h _r .

In step 607, the decrypted signature, i.e. the reference hash value h _r, is verified against the one-way audit hash value h _a calculated in step 603. If the verification succeeds, that is, if the audit hash value h _a and the reference hash value h _r are equal, the processor proceeds to step 608 to calculate the reference message authentication code (MAC). Otherwise, the software loading process is interrupted.

In step 608, the processor uses the verified one-way hash value h _a (= h _r ) and the chip unique key K (or a value derived from K) as input to the MAC calculation function, resulting in a reference message authentication code value t _r = MAC (h _a ; K) is obtained. The output of the MAC function is the reference MAC value of the new software and data. In some embodiments, the chip unique key K is stored in a secure memory accessible only by the processor. For example, the unique key K can be burned to the chip during the manufacturing process, for example using so-called e-fuse technology. An embodiment of a message authentication code is described below. The processor stores the new reference MAC value tr, along with the new software and data SW, in external memory 106. Optionally, the certificate (s) and digital signature values are removed from external memory.

The loading process is controlled by the processor of the mobile terminal. In a two-chip architecture as described in connection with Figures 3 and 4, the above steps are performed by the chip 311 which is later adapted to execute the software.

The cryptographic function, in particular the MAC function, for authenticating the received data may be performed by dedicated software stored in the internal ROM of the processor performing the above steps, for example as part of the boot code.

Thus, the stored reference MAC value is now available for subsequent auditing of software and data by the processor. For example, to verify the integrity of the stored software, the processor uses the chip unique key K to audit the audit hash value h (SW) of the stored software and data and the audit MAC value t _a = MAC of the calculated audit hash value. Compute (h (SW); K). The processor compares the calculated audit MAC value t _a with the stored reference MAC value t _r . If the two values are the same, the integrity of the software is verified.

For example, such an audit may be performed periodically during the boot processor of the mobile terminal and / or whenever the software is executed and / or at predetermined time intervals, as described, for example, in US Pat. No. 6,026,293. have.

7 shows a calculation of an embodiment of a message authentication code (MAC). MAC is a function that takes a variable length variable M and a key K and produces a fixed-length output t (so-called MAC value or tag value), ie t = MAC (M; K). In some embodiments, for an attacker who knows M but does not have information about the value of K, the MAC is defined so that it is computationally difficult (not feasible) to find the same tag value but different message M 'from M. do. In addition, the MAC function can be defined such that it is difficult for an attacker who knows message M but does not have information about the value of K to predict the exact tag value t. In the loading method described herein, the MAC is used to check the integrity of the data stored on an unreliable or insecure medium, i.e. in this situation, when storing and retrieving payload data, the MAC is It is only used by one party, ie mobile terminal. In some embodiments, the MAC function is based on a cryptographic hash function, in particular the hash function H used to authenticate received payload data, as described above. This enables the reuse of the calculated hash value during authentication of the received payload data when calculating the MAC value for future integrity protection, significantly reducing the computational effort for calculating the MAC value and thus the installation time. Decreases.

7 shows a block diagram of a MAC calculation module. The MAC calculation module includes a MAC function calculator 732. The MAC function calculator 732 receives as input h (h is a validated hash value calculated during the preceding signature verification process 736 for the received payload, h = h _a or h = h _r ). As a second input, the MAC function 732 receives the secret key K 'derived from the chip unique key K. Specifically, the key K 'is a pseudo random function based on a pseudo random function 731, for example, a hash function (e.g., SHA-1), from the chip unique key K and the mode identifier 735. Can be generated. For example, the chip unique key K may be a random number generated during ASIC manufacture of the chip. Deriving the key K 'from the master key K means that different keys K' can be used for different purposes (e.g., to protect different types of software, different parts of the software, etc.), Thereby ensuring cryptographic separation and increasing the flexibility of the method. The mode identifier 735 allows the selection of different modes. For example, in a multi-chip scenario, different modes may be used for each target chip for which software is to be used. Examples of suitable MAC functions are Keyed-Hashing for Message Authentication (HMAC), Cipher Block Chaining (CBC) MAC (e.g., using AES or a secure one-way hash function), e.g. AJ Menezes, PC van Oorschot, SA Vanstone, "Handbook of Cryptology", p. CBC-MAC as defined in 353, CRC Press (1997), where AES block encryption cipher is used as block cipher E. MAC function 732 generates the corresponding tag value t, as described above.

To prevent illegal MAC value calculation, the MAC circuit only emits the calculated MAC value t when there is a successful signature verification prior to calculation. Thus, the MAC calculation module receives from the signature verification process 736 an additional input 733 indicating whether the digital signature of the received payload data was successfully verified. Block 734 accepts a tag value and signal 733 as inputs and emits a calculated tag value only if signal 733 indicates that hash value h is verified, i.e., an authentic hash value. For example, in the method of FIG. 6, signal 733 is generated by step 607.

Note that the MAC computation module may be implemented as a separate MAC computation circuit on the processor chip. In addition, subsequent comparisons between the calculated MAC value and the reference value can be performed inside the comparison circuit attached to the MAC circuit. In addition, the secret key K can be stored as part of the circuit. As a result, the overall MAC calculation can be limited to a dedicated circuit and thus does not require exposure / emission of the calculated MAC outside of that circuit.

The MAC calculation of FIG. 7 further includes secure version control and can be further improved with very low computational costs to prevent the predictability of the input h in the MAC calculation. This alternative embodiment of MAC calculation is now described with reference to FIGS. 8 and 9.

8 illustrates the calculation of another embodiment of a message authentication code that includes a version control mechanism, and FIG. 9 shows a flowchart of the version control process.

According to this embodiment of the MAC circuit 800, the MAC computation at block 732 is performed on a 4-tuple (rand, h, cnt, back_cnt) 844. Four-tuple 844 includes a short (eg, 64-bit) random value rand that ensures that the input to the MAC computation is not fully controlled by the input from the signature verification process 736. do. The 4-tuple further includes the hash value h verified as in the previous embodiment. Finally, the 4-tuple includes the version control counter cnt and the version control back counter back_cnt of the version control mechanism described below. The MAC function 732 (eg HMAC, CBC-MAC, etc.) also receives the secret key K 'as described in connection with FIG. 7 and calculates the MAC value from the 4-tuple and secret key K'. . Likewise, as described with respect to FIG. 7, the calculated tag value t is emitted only if the signature signal 703 indicates that the signature verification process has verified the hash value h.

Four-tuple 844 is generated by version control module 841, which maintains a version control list 842 of previously received software versions. Specifically, version control list 841 includes a list of data records, where each data record includes four tuples corresponding to previously observed hash values. The record with the most recent hash value refers to the top element of the list 842 corresponding to the software actually installed / in use.

The version control module 841 receives the verified hash value h and a digital signal 733 indicating from the signature verification process as described above that the signature was successfully verified. In addition, version control module 841 receives software version counter cnt and number back_cnt from signature verification process 736. This number back_cnt indicates how many previous versions can still be installed if a given software version is installed. For example, back_cnt can be a number between 0 and C _MAX (eg, C _MAX = 15), where back_cnt = 0 means that new software is not allowed to be replaced by the previous version. Thus, back_cnt implements a simple but effective mechanism for controlling backward and forward compatibility of loaded software. In some embodiments, the values of cnt and back_cnt are received as part of a software packet received during the loading process, eg, as part of a header section of the received software packet.

Upon receipt of a new hash value h, new counter cnt, new back_cnt value, and signal 733 from the signature verification process 736 (step 901), the version control module 841 uses the signal 733 during the loading process. To check whether the hash value h was verified during the signature verification process 736 (step 902). If not verified, the version control module 841 blocks the value of h, i.e., the version control and MAC calculation process stops. If signal 733 indicates that the hash value is true, version control module 841 continues to step 903.

At step 903, version control module 841 compares the received hash value with a hash value in version control list 842. If the received hash value h is equal to one of the previous hash values h _prev in the version control list 842, the version control module 841 continues to step 904, otherwise the process continues to step 906.

In step 904, i.e., if the received hash value h is equal to one of the previous hash values h _prev , the process retrieves the corresponding 4-tuple (rand, h, cnt, back_cnt) _prev , It is determined whether the counter value cnt _prev is within the allowed range defined by the values cnt and back_cnt received from the signature verification process 736. In some embodiments, this 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 for the range of allowed values. However, it will be appreciated that in other embodiments, an upper limit may be defined.

If cnt _prev is within the allowed range, the version control module 841 determines that the new random values generated by the component rand _new = version control module 841, h _new = h, cnt _new = cnt _prev , back_cnt _new = back_cnt Generate a new 4-tuple with _prev (rand, h, cnt, back_cnt) _new (step 905), and the version control module replaces the old tuple with the same h value with the new tuple and replaces this new tuple in the list. Set as the top level element.

If the test in step 903 shows that h is not equal to one of the previous hash values, then a new random value, hash value h, and counter are stored in the version control list with the allowed back_cnt (associated with this h). (Step 906). In this case, _new = new random value rand, h _new = h, cnt = cnt _new, back_cnt _new = min - the _new generation (back_cnt, cnt min_allowed_version) new 4-tuple (rand, h, cnt, back_cnt ) according to This new tuple becomes the top element in the list. Where min_allowed_version is the current lowest allowed version by any tuple in the update list. After this entry is placed at the top of the update list, min_allowed_version is recalculated as cnt _top -back_cnt _top , ie from counters cnt _top and back_cnt versions of the top element (step 907). Finally, every element in the list is updated so that its back_cnt value is the largest possible value that does not provide a lower version number than the smallest allowed version min_allowed_version (step 908). If the list contains entries with versions outside the allowed range, these entries are deleted.

In some embodiments, the MAC check value MACLIST is associated with a version control list to prevent illegal manipulation of entries in the list, thereby further improving the security of this method. The MACLIST value is updated only when the list is updated, i.e. after successful signature verification. Prior to accessing / using the version control list, the current MAC check may be checked against the MACLIST value. To prevent illegal MACLIST value calculations, the MAC circuit only emits the calculated MAC value if there is a successful signature verification before that calculation (controlled by block 734 of FIGS. 7 and 8).

Thus, the stored reference MAC values and version control lists are now available for subsequent auditing of software and data by the processor. For example, to verify the integrity of the stored software, the processor computes the audit hash value h _a = h (SW) of the stored software and data and audit tuples (rand, cnt and back_cnt with the values rand, cnt and back_cnt retrieved from the version control list). h _a , cnt, back_cnt). From this, the processor calculates the audit MAC value ta = MAC ((rand, h _a , cnt, back_cnt); K) of the audit tuple calculated using the chip unique key K. The processor compares the calculated audit MAC value t _a with the stored reference MAC value t _r . If these two values are the same, the integrity of the software is verified.

As noted above, this audit may be performed periodically during the boot process of the mobile terminal and / or whenever software needs to be executed and / or at predetermined time intervals.

The process is now further described with reference to FIG. 10 as an example.

FIG. 10 shows an example of a version control mechanism in which a version control list of size 3 is used, that is, the version control list can store three tuples. In this example, it is also assumed that there are a series of eight software version distributions with hash values h, version counter cnt and back counter back_cnt values (h, cnt, back_cnt) 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)

Version 8: (H8, 8, 4)

Also, except for version 7, which is not applied, it is assumed that the versions are applied sequentially. 10 shows version control list 1001 after installation of version 8. FIG. Each row of the version control list 1001 includes a corresponding 4-tuple for one of the installed versions, row 1002, the highest element of the list, corresponds to version 8, row 1003 corresponds to version 6, Row 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 lowest allowed version was 4 (because version 8's cnt is 8 and version 8's back_cnt is 4 and 8-4 = 4), thus min_allowed_version = 4. Thus, after version 8 was added, the back_cnt value of the remaining entries in the list was adjusted during the installation of version 8 to meet the restrictions on the lowest allowed version. Specifically, the back_cnt value in row 1002 was set to 2, and the back_cnt value in row 1003 was set to 1. Prior to the update to version 8, the lowest allowed version was 3, but this value has been increased to 4 through version 8.

10 also shows version control table 1011 after installation of version 7. FIG. First of all, the counter value cnt of version 7 is 7, i.e., it is within the allowed range of the current version. The hash value H7 does not yet exist in the version control list 1001, so that a new four-tuple 1007 with a new hash value H7 is stored as a new top element 1012 of the version control table 1011. The previous top element is moved down in the list and corresponds to row 1013. Version 6 is now in row 1014, while version 5 is removed from the list because, in this example, there is only space for three 4-tuples in the version control list. The value of back_cnt of the new top element 1012 is set to 3 to satisfy the limit of the current lowest allowed version (min_allowed_version = 4).

11 shows a flowchart of a software loading process for software upgrade. This process is similar to the process shown in FIG. 6 that loads software for the first time.

In the first step 1101, the mobile terminal receives a software upgrade data packet from the reprogramming tool via a local or remote interface (eg GSM, WCDMA, etc.) as described above. This packet contains a new software upgrade Δ, one or more certificates C, and a digital signature S (h _r ) of the protected software, as described in connection with FIG. 5 above. Optionally, the software may also include data, for example updated configuration data. In one embodiment, the new software is loaded as a so-called delta-file containing the difference of the new software over the current software, thus reducing the size of the upgrade packet. Delta-file techniques are known in the art and are described, for example, in Christian Reichenberger, "Delta storage for arbitary non-text files", Proc. Of the 3rd International Workshop on Software Configuration Management, pp. 144-152, Norway, June 1991. Alternatively, other upgrade file creation methods may be used or new software may be received in its entirety. The signature S (h _r ) contains an encrypted hash value computed from the new software. This signature is first calculated so that the one-way hash h _r = H (SW) of the new software SW is computed and then this hash value is encrypted with the secret key of the public-private key pair (for example, the RSA public-private pair). do. The corresponding public key is included in the certificate included in the software upgrade package. Upon receipt of the software upgrade package, the mobile terminal stores the software upgrade, certificate (s), and signature in external memory 106.

In step 1102, the processor of the mobile terminal reads the newly stored software upgrade, certificate (s) C, and signature S (h _r ) into its internal memory.

In step 1122, the processor performs version control. The mobile terminal receives the software version number of the new software version as part of the upgrade packet. The software version number of the new software image is checked against the version number of the current software stored in the external memory (protected by the MAC). If the new software version number is lower than the previous software version number, 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 of step 1122 was successful, the process continues to step 1123, wherein the processor creates a new software SW _new from the received delta-file Δ and the current software version SW _prev stored in the external memory (protected by MAC). do.

In step 1103, the processor calculates the one-way audit hash value h _a = H (SW _new ) of the new software SW _new .

In step 1104, the processor reads the root public key PK from memory 1105. In some embodiments, the root public key is stored securely, i.e. integrity protected. In one embodiment, the root public key is stored in an internal ROM of the processor, as described above. The processor uses the root public key PK to verify the signature S (h _r ) of the new software. If only one certificate is used, the signature S (h _r ) is verified against the public key in certificate C. Certificate C is then verified against the root public key PK in turn. If several certificates are used, the entire certificate chain is verified. In that case, the signature of the last certificate in the chain is verified against the root public key. Thus, at step 1104, the processor verifies the public key used to sign the new software. If the verification succeeds, the processor continues with step 1106 to verify the signature. Otherwise, the software loading process is interrupted.

In step 1106, the processor decrypts the digital signature S (h _r ) of the software using the public key verified in step 1104, resulting in a reference hash value h _r .

In step 1107, the decrypted signature, i.e. the reference hash value h _r, is verified against the one-way audit hash value h _a calculated in step 1103. If this verification succeeds, that is, if the audit hash value h _a and the reference hash value h _r are equal, the processor proceeds to step 1108 to calculate the reference message authentication code (MAC). Otherwise, the software loading process is stopped.

In step 1108, the processor checks the verified one-way hash value h _a And the chip unique key K (or a value derived from K) as an input value to the MAC calculation function, and as a result, a reference message authentication code value t _r = MAC (h _a ; K) is obtained. The output of the MAC function is the reference MAC value of the new software. In some embodiments, the chip unique key K is baked into the chip during the manufacturing process, for example using so-called e-fuse technology. As another alternative, the key K is stored in another secure memory accessible only to the processor. The embodiment of the message authentication code has been described above. The processor stores the new reference MAC value t _r in external memory 106 along with the new software. The previous MAC value is deleted. Optionally, the certificate (s) and digital signature values are removed from external memory. The new software version SW _new is stored in external memory and the previous software version is deleted.

The loading process is controlled by the processor of the mobile terminal. In a two-chip architecture as described in connection with FIGS. 3 and 4, the steps are performed by a chip 311 which is supposed to execute software later.

Thus, in the above, a robust software signature mechanism is described for the protection of software for many different systems. This mechanism is effectively combined with a symmetric key-based integrity protection mechanism for secure software storage. If the SW is installed on the platform, a symmetric key based mechanism is used and benefits from the previous calculations. In addition, a combined mechanism for protecting version control software is described herein.

Integrity protection provided to the storage device is particularly beneficial with respect to the two CPU architecture when non-volatile memory is connected to an untrusted CPU and also when a SW update is needed.

While some embodiments have been described and illustrated in detail, the invention is not limited thereto, and may also be embodied in other ways within the scope of the subject matter defined in the following claims.

In detail, these embodiments are mainly described with reference to a mobile terminal as an example of a data processing apparatus. However, it will be appreciated that the methods, product means, and apparatus described herein may be applied to other data processing apparatus.

The methods, product means, and apparatus described herein may be implemented by hardware including several individual elements and also by a suitably programmed microprocessor. In the device claim enumerating several means, several of these means may be embodied in one and the same hardware article, for example, a suitably programmed microprocessor, one or more digital signal processors, or the like. The simple fact that certain measures are cited in different dependent claims or described in different embodiments does not mean that a combination of these measures cannot be used to advantage.

It should be emphasized that the term "comprising / comprising", when used herein, should be taken to indicate the presence of the stated feature, integer, step, or component, and one or more other features, integers, steps, components Or does not exclude the presence or addition of groups thereof.

Claims (32)

A method of loading data into a data processing device, Receiving a payload data item by the data processing device, Performing a password authentication process to ensure authenticity of the payload data item, Storing the authenticated received payload data item in the data processing device, and Integrity protecting the stored payload data item Including; Performing the cryptographic authentication process comprises calculating at least an audit hash value of the received data item; And said integrity protecting step further comprises calculating at least a reference message authentication code value of said audit hash value using a private key stored in said data processing device as input. The method of claim 1, wherein the password authentication process, Receiving a reference hash value, and Comparing the received reference hash value with the calculated audit hash value to verify the authenticity of the received payload data item. Data loading method comprising a. 3. The method of claim 2, wherein the cryptographic authentication process comprises digitally signing the data item in accordance with a public key cryptosystem. The method of claim 3, Receiving the payload data item, the digital signature data item, and the digitally signed digital certificate data item, wherein the digital certificate data item includes a first public key, and the digital signature data item corresponds to the first public key. Includes a reference hash encrypted with the first secret key Authenticating the digitally signed digital certificate data item against a root public key stored in the data processing device; Authenticating the digital signature data item against the authenticated digital certificate, and Comparing the received reference hash value with the calculated audit hash value to verify the authenticity of the received payload data item. Data loading method comprising a. The method of claim 3 or 4, further comprising cryptographically authenticating the reference hash value. The calculating of the reference message authentication code value is performed only when the reference hash value is successfully authenticated. 6. The method of any of claims 1 to 5, wherein the integrity protecting step further comprises storing the calculated reference message authentication code value in relation to the received payload data item. 7. The method of any one of the preceding claims, wherein calculating the reference message authentication code value comprises calculating the reference message authentication code value of a combined data item derived from at least the audit hash value and a random number. Data loading method further comprising. 8. The method of any one of the preceding claims, wherein calculating the reference message authentication code value comprises at least the reference message authentication code value of a combined data item derived from the audit hash value and a version control data item. A data loading method further comprising the step of calculating. The method of claim 8, further comprising storing a version control data record in a version control data structure, And the version control data record comprises information about the received payload data item including at least the version control data item. 10. The method of claim 9, wherein the stored version control data record is integrity protected. The method of claim 9 or 10, wherein the version control data record comprises a version counter. 12. The method of claim 11 wherein the version control data record further comprises a back counter identifying a number of previous versions that can replace a current version of the payload data item. 13. The data loading method according to any one of claims 1 to 12, wherein the secret key is a secret data item unique to the data processing device. The data loading method according to any one of claims 1 to 13, wherein the secret key is a secret data item known only to the data processing device. The method of claim 1, wherein receiving the payload data item comprises: Receiving a delta update of a previously received current data item, and Generating the payload data item as an updated payload data item from the previously received current data item and the received delta update Data loading method comprising a. A computer program comprising program code means adapted to cause a data processing apparatus to perform the steps of the method according to any one of claims 1 to 15, The computer program running on the data processing device. A data processing apparatus comprising a first processing circuit adapted to perform the method according to any one of claims 1 to 15. The method of claim 17, Storage means adapted to store the received payload data item, and A second processing circuit connected to said storage means and said first processing circuit More, And said second processing circuit is adapted to provide said first processing circuit with at least read access to said storage means. 19. The data processing apparatus of claim 17 or 18, wherein the first processing circuit includes local storage means for storing a root public key of an asymmetric cryptographic system. 20. The data processing apparatus according to any one of claims 17 to 19, wherein the first processing circuit includes local storage means for storing the secret key. A method of protecting the integrity of a current version of a data item stored in a data processing device. Determining a reference hash value of at least the data item, Calculating a reference message authentication code value from the determined reference hash value using a secret key stored in the data processing apparatus, and Storing the calculated reference message authentication code value in association with the data item Including; Calculating the reference message authentication code value comprises calculating the reference message authentication code value from a combined data item derived from at least a portion of the determined reference hash value and a version control data record, And the version control data record includes version control information about the data item of the current version. The system of claim 21, wherein the version control data record comprises a version counter, And calculating the reference message authentication code value comprises calculating a reference message authentication code value from the determined reference hash value and at least a combined data item derived from the version counter. 23. The system of claim 22, wherein the version control data record further comprises a back counter that identifies a number of previous versions that can replace the current version, And calculating the reference message authentication code value comprises calculating a reference message authentication code value from the determined reference hash value and at least a combined data item derived from the back counter. 24. The method of any of claims 21 to 23, wherein the version control data record further comprises the reference hash value for the data item of the current version. The method according to any one of claims 21 to 24, Generating the version control data record, and Storing the version control data record in a version control data structure A method of protecting the integrity of a data item further comprising. 27. The method of claim 25, further comprising integrity protecting the version control data record. 27. The method of claim 21, wherein the secret key is a secret data item unique to the data processing device. 28. The method of any one of claims 21 to 27, wherein the secret key is a secret data item known only to the data processing device. The method according to any one of claims 21 to 28, wherein Receiving a delta update of a previously received current data item, and Generating the data item as an updated data item from the previously received current data item and the received delta update A method of protecting the integrity of a data item further comprising. A method of verifying the integrity of a current version of a data item stored in a data processing device, Calculating an audit hash value of the data item, Calculating an audit message authentication code value from the calculated audit hash value using a secret key stored in the data processing apparatus, and Comparing the calculated audit message authentication code value with a stored reference message authentication code value with respect to the data item. Including; The method further comprises retrieving a version control data record, The version control data record includes version control information about a data item of the current version, Calculating the audit message authentication code value comprises calculating an audit message authentication code value from the calculated audit hash value and a combined data item derived from at least a portion of the version control data record. How to verify the integrity of data items. 31. The method of any of claims 21-30, wherein the data item is loaded by performing the method defined in any one of claims 1-15. Storage means for storing a current version of the data item and a version control data record, the version control data record including version control information about the data item of the current version; and Processing means adapted to carry out the method according to any of claims 21 to 31. Data processing device comprising a.

Images