WO2013128247A1 - Code checking system - Google Patents

Code checking system Download PDF

Info

Publication number
WO2013128247A1
WO2013128247A1 PCT/IB2012/055148 IB2012055148W WO2013128247A1 WO 2013128247 A1 WO2013128247 A1 WO 2013128247A1 IB 2012055148 W IB2012055148 W IB 2012055148W WO 2013128247 A1 WO2013128247 A1 WO 2013128247A1
Authority
WO
WIPO (PCT)
Prior art keywords
check
program code
counter
value
processor
Prior art date
Application number
PCT/IB2012/055148
Other languages
French (fr)
Inventor
Yaaron SELLA
Ittael Fraenkel
Itsik Mantin
Original Assignee
Nds Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nds Limited filed Critical Nds Limited
Publication of WO2013128247A1 publication Critical patent/WO2013128247A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1417—Boot up procedures

Definitions

  • the present invention relates to checking program code authenticity.
  • devices are often designed to perform, upon boot, a public key signature check of their own code prior to executing the code.
  • the motivation is to ensure the device executes authorized code only.
  • the problem is that as the device's code size gets larger, the above signature check takes longer, and as a result the device boot time increases. This annoys the user, and in some cases, it is simply unacceptable.
  • the most time-consuming part in a public key signature check is cryptographic hashing of the code.
  • the present invention in certain embodiments thereof, seeks to provide an improved code checking system.
  • a system including a counter having a value, a first processor to perform, as part of a boot-loading process, a code check including performing a partial check of program code or a full check of the program code dependent on the value of the counter, the program code having a plurality of sections, adjust the counter value in a first direction if the full check is successful, and adjust the counter value in a second direction, opposite to the first direction, if the partial check fails, and continue with the boot-loading process if the code check is successful, wherein the full check includes authenticating all of the program code against a first digital signature, the partial check includes authenticating one of the sections of the program code against a second digital signature, and the partial check excludes authenticating all the sections of the program code, the first signature being the same as, or different from, the second signature.
  • the partial check includes randomly or pseudo-randomly selecting the one section from the plurality of sections of the program code.
  • the system includes a second processor operative to execute the program code, wherein the first processor is operative only to run the boot-loading process and the counter is protected so that the counter can be adjusted or reset by the first processor but not by the second processor.
  • the counter is protected from being reset or adjusted manually.
  • the first processor operative is also operative to execute the program code, wherein the counter is protected so that the counter can only be adjusted or reset by the first processor during the boot-loading process.
  • the first digital signature is different from the second digital signature which is different for each one of the sections of the program code so that there are a plurality of second digital signatures.
  • the second digital signatures are compressed together into a single physical structure.
  • the first digital signature is different from the second digital signature.
  • the first digital signature is the same as the second digital signature.
  • the first processor is operative to decrement the counter value if the full check is successful, increment the counter value if the partial check fails, and perform the full check of the program code when the value of the counter is greater than, or equal to, a threshold value.
  • the first processor is operative to increment the counter value if the full check is successful, decrement the counter value if the partial check fails, and perform the full check of the program code when the value of the counter is less than, or equal to, a threshold value.
  • a method including performing, as part of a boot-loading process, a code check including performing a partial check of program code or a full check of the program code dependent on the value of the counter, the program code having a plurality of sections, adjusting the counter value in a first direction if the full check is successful, adjusting the counter value in a second direction, opposite to the first direction, if the partial check fails, continuing with the boot- loading process if the code check is successful, wherein the full check includes authenticating all of the program code against a first digital signature, the partial check includes authenticating one of the sections of the program code against a second digital signature, and the partial check excludes authenticating all the sections of the program code, the first signature being the same as, or different from, the second signature.
  • Fig. 1 is a partly pictorial, partly block diagram view of a system constructed and operative in accordance with an embodiment of the present invention
  • Fig. 2 is a partly pictorial, partly block diagram view of a system constructed and operative in accordance with an alternative embodiment of the present invention
  • Fig. 3 is a partly pictorial, partly block diagram view of the system of Fig. 1 authenticating code
  • Fig. 4 is a partly pictorial, partly block diagram view of the code signed in accordance with an alternative method for use in the system of Fig. 1;
  • Fig. 5 is a flow chart showing a first mode of operation of the code checking system of Fig. 1;
  • Fig. 6 is a flow chart showing a second mode of operation of the code checking system of Fig. 1.
  • Fig. 1 is a partly pictorial, partly block diagram view of a system 10 constructed and operative in accordance with an embodiment of the present invention.
  • the system 10 typically includes a counter 12 and a processor 14.
  • the processor 14 is operative to check program code 16.
  • the processor 14 is operative to execute the program code 16 after a successful boot-load procedure.
  • the processor 14 uses the counter 12 as a private sanction counter which is stored in non-volatile memory. The use of the counter will be described in more detail below with reference to Figs. 3 to 5.
  • the counter 12 is typically protected from being reset or adjusted manually (by human intervention) and is accessible for writing (adjusting or resetting) by the processor 14 only during the boot-loading process and not during execution of the program code 16.
  • One mechanism for implementing the private sanction counter 12 can be a one-time-write random access memory (RAM) bit, which allows writing to the sanction counter 12 only when the RAM bit is zero.
  • the processor 14 would typically set the RAM bit to one before it terminates and transfers control to the main image of the program code 16.
  • the one-time write RAM bit is typically reset when the CPU is reset.
  • FIG. 2 is a partly pictorial, partly block diagram view of a system 18 constructed and operative in accordance with an alternative embodiment of the present invention.
  • the system 18 is substantially the same as the system 10 of Fig. 1, except that in the system 18, the processor 14 is operative to only run the boot- loading process which checks at least part of the program code 16 and another processor 20 is operative to execute the program code 16 after successful completion of the boot-loading.
  • the counter 12 is typically a private sanction counter protected so that the counter 12 can be adjusted or reset by the processor 14 but not by the processor 20. Additionally, the counter 12 is protected from being reset or adjusted manually.
  • the private sanction counter 12 can secured for "private use" by a hardware memory protection unit (MPU) or memory management unit (MMU) mechanism, by way of example only.
  • MPU hardware memory protection unit
  • MMU memory management unit
  • Fig. 3 is a partly pictorial, partly block diagram view of the system 10 of Fig. 1 authenticating the code 16.
  • the program code 16 includes n sections 22.
  • the program code 16 is signed with an entire code signature 26 and each of the sections 22 is individually signed with a different signature 24.
  • the signature 26 is typically different from any of the signatures 24.
  • Fig. 4 describes the program code 16 and the sections 22 being signed in accordance with a different scheme.
  • the signatures 24 and the entire code signature 26 may be compressed if possible.
  • the processor 14 randomly or pseudo-randomly selects one section 22 of the program code 16.
  • the processor 14 then calculates a hash, using a cryptographic hash function (e.g.
  • SHA-1 or SHA-256 on the selected section 22, instead of on the entire program code 16 yielding a hash value 28 which is authenticated against the signature 24 of the selected section 22 typically using a public key 32 as is known is the art of digital signature authentication (block 30).
  • non-asymmetric digital signature authentication may be performed using a suitable secret.
  • the partial check typically cuts the signature check time to roughly 1/n of the original time, which represents a very significant saving.
  • checking only 1/ n of the program code 16 introduces some issues, complications and security problems that need to be addressed.
  • One issue is how to arrange the code in n sections.
  • One approach is to allocate the first section 22 to bytes 0, n, 2*n, ..., the second section 22 to bytes 1, n+1, 2*n+l,... etc.
  • Another approach is to have the first section 22 be the first 1/n of the code 16 and the second section 22 be the second 1/n of the code 16. It will be appreciated by those ordinarily skilled in the art that there are many suitable ways in which to arrange the code 16 in n sections.
  • the processor 14 uses the counter 12 as a private sanction counter which is stored in non-volatile memory.
  • the value of the counter 12 is adjusted.
  • a full signature check on the entire program code 16 is required at boot. The full check takes more time, but due to security concerns the time constraint is overridden.
  • the full check is typically performed by the processor 14 calculating a cryptographic hash of the entire program code 16 yielding a hash value which is authenticated against the entire code signature 26 using a public key or secret as appropriate.
  • Fig. 4 is a partly pictorial, partly block diagram view of the code 16 signed in accordance with an alternative method for use in the system 10 of Fig. 1.
  • the program code 16 and all the sections 22 are signed with a single signature 34 and each of the sections 22 has a hash value 36 and the entire program code 16 has a entire code hash 38.
  • all the hash values 36 and the entire code hash 38 are hashed together, using a cryptographic hash function, they yield another hash (a hash of the hash values 36, 38) effectively creating a two-level hash tree.
  • the hash of the hash values 36, 38 is authenticated using the signature 34 so that any of the sections 22, or the entire program code 16, may be authenticated with the signature 34 in conjunction with the other hash values and an appropriate public key or secret, as appropriate.
  • the processor 14 calculates a hash, using a cryptographic hash function (e.g. SHA-1 or SHA-256) on the selected section 22, instead of on the entire program code 16, yielding a hash value which is compared with the existing hash value 36 of the selected section 22. If the calculated hash of the selected section 22 is not equal to the existing hash value 36 for the selected section 22, then the check of the selected section 22 has failed. If the calculated hash of the selected section 22 is equal to the existing hash value 36 for the selected section 22, then the existing hash value 36 for the selected section 22 needs to be authenticated against the signature 34.
  • the authentication of the existing hash value 36 is performed as follows.
  • the existing hash value 36 of the selected section 22 and the existing hash values 36 of all the other sections 22 and the entire code hash 38 of the entire program code 16 are hashed together, using a cryptographic hash function, yielding another hash which is authenticated against the signature 34 typically using a public key or secret depending on the mode of digital signature authentication employed.
  • Fig. 5 is a flow chart showing a first mode of operation of the system 10 of Fig. 1.
  • the value of the counter 12 (Fig. 3) typically starts at zero and the counter value is adjusted by failures of the partial check and successes of the full check during successive boot attempts, as will now be described in more detail.
  • the boot process starts at step 40.
  • step 42 the counter value is compared to a threshold value. If the counter value is less than, or equal, to a threshold value Z, a partial check is performed (steps 44, 46). If the counter value is greater than the threshold value Z, then a full check is performed (step 48).
  • step 44 one of the sections 22 (Fig. 3) of the program code 16 is selected (typically randomly or pseudo-randomly).
  • step 46 the selected section 22 is checked for authenticity.
  • step 50 if the selected section 22 is authentic the boot process continues in step 52. If the selected section 22 is not authentic, the counter value is incremented by X in step 54 and the process returns to the start of the process (step 40).
  • the authentication of the selected section 22 may fail for various reasons, for example, but not limited to, a processing error, an error in the signature authenticating the selected section 22, or due to the selected section 22 having been tampered with. If the selected section 22 has been tampered with, authentication of the entire program code 16 will fail as well. However, if the selected section 22 has not been tampered with, then authenticating the entire program code 16 against the entire code signature 26 (Fig. 3) may prove to be an effective authentication step without ignoring potential security risks.
  • step 48 the entire program code 16 is checked for authenticity (for example against the entire code signature 26).
  • step 56 if the entire program code 16 is authentic, the counter value is decremented by Y in step 58, and the boot process is continued in step 52. If the authentication of the entire program code 16 fails, the boot-loading process is restarted (step 40).
  • X, Y and Z can be set to any suitable values, for example, Y could be equal to 1, X greater than or equal to one (e.g. 3), and Z less than or equal to X (e.g. 1 or 2).
  • Fig. 6 is a flow chart showing a second mode of operation of the system 10 of Fig. 1.
  • the flow chart of Fig. 6 is substantially the same as the flow chart of Fig. 4 except that in step 58, instead of decrementing the counter by Y, the counter is reset to the initial value, (e.g. zero).
  • the counter value starts at a certain initial value (e.g. zero or could be any other positive or even negative value) and increases (by fixed value or as a function (e.g. a fraction or exponential function) of the counter value) on failure of the partial check.
  • the flowchart in Fig. 5 checks for the counter value being greater than the threshold value. However, the check for performing a full check could be when the counter value equals (or hits) the threshold value. Therefore, the partial check is performed unless the counter value hits or exceeds (depending on the criteria) a threshold value (could be a negative value, a positive value or zero) thereby requiring that a full check be performed.
  • the counter value is reset to the initial value or reduced by a certain value (by a fixed value or as a function (e.g. a fraction or exponential function) of the counter value).
  • a certain value by a fixed value or as a function (e.g. a fraction or exponential function) of the counter value.
  • the counter value starts at a certain initial value (e.g. zero or it could be any other positive or even negative value) and is reduced (by a fixed value or as a function (e.g. a fraction or exponential function) of the counter value) on failure of the partial check.
  • the partial check is performed unless the counter value hits or falls below a certain threshold value (could be a negative value, a positive value or zero) thereby requiring that a full check be performed.
  • the counter value is reset to the initial value or increased by a certain value (by a fixed value or as a function (e.g. a fraction or exponential function) of the counter value).
  • a certain initial value e.g. zero or it could be any other positive or even negative value
  • a function e.g. a fraction or exponential function
  • the counter value starts at a certain initial value (e.g. zero or could be any other positive or even negative value) and is increased (by a fixed value or as a function (e.g. a fraction or exponential function) of the counter value) on success of the full check.
  • the full check is performed unless the counter value hits or exceeds a certain threshold value (could be a negative value, a positive value or zero) thereby allowing a partial check to be performed.
  • the counter value is reset to the initial value or reduced by a certain value (by a fixed value or as a function (e.g. a fraction or exponential function) of the counter value).
  • the counter value is reset to the initial value.
  • the counter value starts at a certain initial value (e.g. zero or could be any other positive or even negative value) and is decreased (by a fixed value or as a function (e.g. a fraction or exponential function) of the counter value) on success of the full check.
  • the full check is performed unless the counter value hits or falls below a certain threshold value (could be a negative value, a positive value or zero) thereby allowing a partial check to be performed. If the partial check fails, the counter value is reset to the initial value or increased by a certain value (by a fixed value or as a function (e.g. a fraction or exponential function) of the counter value). When a new download is received, the counter value is reset to the initial value.
  • a certain initial value e.g. zero or could be any other positive or even negative value
  • a function e.g. a fraction or exponential function
  • the processor 14 is typically a processor to perform, as part of a boot-loading process, a code check including performing a partial check of the program code or a full check of the program code dependent on the value of the counter 12.
  • the full check typically includes authenticating all of the program code 16 against a digital signature (for example, the entire code signature 26 or the signature 34 according to the authentication method of Fig. 4).
  • the partial check typically includes randomly or pseudo-randomly selecting one of the sections 22 from the plurality of sections 22 of the program code 16.
  • the partial check includes authenticating the selected section 22 of the program code 16 against a digital signature (for example, one of the digital signatures 24 or the signature 34 according to the authentication method of Fig. 4).
  • a digital signature for example, one of the digital signatures 24 or the signature 34 according to the authentication method of Fig. 4.
  • the partial check may include checking two or more sections 22 of the program code 16.
  • the partial check excludes performing a signature check on all of the sections 22 of the program code 16.
  • the full check or the partial check may be based on asymmetric cryptography using a public key as described herein above.
  • the full check or the partial check may be based on symmetric cryptography, for example, by authenticating the program code 16 or the selected section 22 against a message authentication code (MAC) based on a secret shared between the processor 14 and the supplier/distributor of the program code.
  • MAC message authentication code
  • the processor 14 is typically operative to adjust the counter value in a first direction if the full check is successful and adjust the counter value in a second direction, opposite to the first direction, if the partial check fails.
  • the processor 14 is operative to: decrement the counter value if the full check is successful; increment the counter value if the partial check fails; and perform the full check of the program code 16 when the value of the counter 12 is greater than, or equal to, a threshold value.
  • the processor 14 is operative to: increment the counter value if the full check is successful; decrement the counter value if the partial check fails; and perform the full check of the program code 16 when the value of the counter 12 is less than, or equal to, a threshold value.
  • the processor is operative to continue with the boot-loading process if the code check yields a positive validation.
  • system 10 may be implemented in any suitable environment for example, but not limited to, in a car, in a router, in a TV or in a set-top box.
  • software components of the present invention may, if desired, be implemented in ROM (read only memory) form.
  • the software components may, generally, be implemented in hardware, if desired, using conventional techniques. It is further appreciated that the software components may be instantiated, for example, as a computer program product; on a tangible medium; or as a signal interpretable by an appropriate computer.

Abstract

A system including a counter having a value, a processor to perform, as part of a boot-loading process, a code check including performing a partial check or a full check of the program code dependent on the value of the counter, the program code having a plurality of sections, adjust the counter value in a first direction if the full check is successful, and adjust the counter value in a second direction, if the partial check fails, and continue with the boot-loading process if the code check is successful, wherein the full check includes authenticating all of the program code against a first digital signature, the partial check includes authenticating one of the sections of the program code against a second digital signature, the first signature being the same as, or different from, the second signature. Related apparatus and methods are also described.

Description

CODE CHECKING SYSTEM
FIELD OF THE INVENTION
The present invention relates to checking program code authenticity.
BACKGROUND OF THE INVENTION
For security reasons, devices are often designed to perform, upon boot, a public key signature check of their own code prior to executing the code. The motivation is to ensure the device executes authorized code only. The problem is that as the device's code size gets larger, the above signature check takes longer, and as a result the device boot time increases. This annoys the user, and in some cases, it is simply unacceptable. Generally, the most time-consuming part in a public key signature check is cryptographic hashing of the code.
The following references are also believed to represent the state of the art:
US Patent 5,978,913 to Broyles, et al.;
US Patent 6,718,461 to Ewertz; and
US Patent 7,555,677 to Wiley, et al.
SUMMARY OF THE INVENTION
The present invention, in certain embodiments thereof, seeks to provide an improved code checking system.
There is thus provided in accordance with an embodiment of the present invention, a system including a counter having a value, a first processor to perform, as part of a boot-loading process, a code check including performing a partial check of program code or a full check of the program code dependent on the value of the counter, the program code having a plurality of sections, adjust the counter value in a first direction if the full check is successful, and adjust the counter value in a second direction, opposite to the first direction, if the partial check fails, and continue with the boot-loading process if the code check is successful, wherein the full check includes authenticating all of the program code against a first digital signature, the partial check includes authenticating one of the sections of the program code against a second digital signature, and the partial check excludes authenticating all the sections of the program code, the first signature being the same as, or different from, the second signature.
Further in accordance with an embodiment of the present invention, the partial check includes randomly or pseudo-randomly selecting the one section from the plurality of sections of the program code.
Still further in accordance with an embodiment of the present invention, the system includes a second processor operative to execute the program code, wherein the first processor is operative only to run the boot-loading process and the counter is protected so that the counter can be adjusted or reset by the first processor but not by the second processor.
Additionally in accordance with an embodiment of the present invention, the counter is protected from being reset or adjusted manually.
Moreover in accordance with an embodiment of the present invention, the first processor operative is also operative to execute the program code, wherein the counter is protected so that the counter can only be adjusted or reset by the first processor during the boot-loading process. Further in accordance with an embodiment of the present invention, the first digital signature is different from the second digital signature which is different for each one of the sections of the program code so that there are a plurality of second digital signatures.
Still further in accordance with an embodiment of the present invention, the second digital signatures are compressed together into a single physical structure.
Additionally in accordance with an embodiment of the present invention, the first digital signature is different from the second digital signature.
Moreover in accordance with an embodiment of the present invention, the first digital signature is the same as the second digital signature.
Further in accordance with an embodiment of the present invention, the first processor is operative to decrement the counter value if the full check is successful, increment the counter value if the partial check fails, and perform the full check of the program code when the value of the counter is greater than, or equal to, a threshold value.
Still further in accordance with an embodiment of the present invention, the first processor is operative to increment the counter value if the full check is successful, decrement the counter value if the partial check fails, and perform the full check of the program code when the value of the counter is less than, or equal to, a threshold value.
There is also provided in accordance with still another embodiment of the present invention, a method including performing, as part of a boot-loading process, a code check including performing a partial check of program code or a full check of the program code dependent on the value of the counter, the program code having a plurality of sections, adjusting the counter value in a first direction if the full check is successful, adjusting the counter value in a second direction, opposite to the first direction, if the partial check fails, continuing with the boot- loading process if the code check is successful, wherein the full check includes authenticating all of the program code against a first digital signature, the partial check includes authenticating one of the sections of the program code against a second digital signature, and the partial check excludes authenticating all the sections of the program code, the first signature being the same as, or different from, the second signature.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention will be understood and appreciated more fully from the following detailed description, taken in conjunction with the drawings in which:
Fig. 1 is a partly pictorial, partly block diagram view of a system constructed and operative in accordance with an embodiment of the present invention;
Fig. 2 is a partly pictorial, partly block diagram view of a system constructed and operative in accordance with an alternative embodiment of the present invention;
Fig. 3 is a partly pictorial, partly block diagram view of the system of Fig. 1 authenticating code;
Fig. 4 is a partly pictorial, partly block diagram view of the code signed in accordance with an alternative method for use in the system of Fig. 1;
Fig. 5 is a flow chart showing a first mode of operation of the code checking system of Fig. 1; and
Fig. 6 is a flow chart showing a second mode of operation of the code checking system of Fig. 1.
DETAILED DESCRIPTION OF AN EMBODIMENT
Reference is now made to Fig. 1, which is a partly pictorial, partly block diagram view of a system 10 constructed and operative in accordance with an embodiment of the present invention.
The system 10 typically includes a counter 12 and a processor 14.
The processor 14 is operative to check program code 16.
In addition to performing the boot-load, the processor 14 is operative to execute the program code 16 after a successful boot-load procedure.
As part of the code checking procedure, the processor 14 uses the counter 12 as a private sanction counter which is stored in non-volatile memory. The use of the counter will be described in more detail below with reference to Figs. 3 to 5.
The counter 12 is typically protected from being reset or adjusted manually (by human intervention) and is accessible for writing (adjusting or resetting) by the processor 14 only during the boot-loading process and not during execution of the program code 16. One mechanism for implementing the private sanction counter 12 can be a one-time-write random access memory (RAM) bit, which allows writing to the sanction counter 12 only when the RAM bit is zero. The processor 14 would typically set the RAM bit to one before it terminates and transfers control to the main image of the program code 16. The one-time write RAM bit is typically reset when the CPU is reset.
Reference is now made to Fig. 2, which is a partly pictorial, partly block diagram view of a system 18 constructed and operative in accordance with an alternative embodiment of the present invention.
The system 18 is substantially the same as the system 10 of Fig. 1, except that in the system 18, the processor 14 is operative to only run the boot- loading process which checks at least part of the program code 16 and another processor 20 is operative to execute the program code 16 after successful completion of the boot-loading. The counter 12 is typically a private sanction counter protected so that the counter 12 can be adjusted or reset by the processor 14 but not by the processor 20. Additionally, the counter 12 is protected from being reset or adjusted manually. The private sanction counter 12 can secured for "private use" by a hardware memory protection unit (MPU) or memory management unit (MMU) mechanism, by way of example only.
For the sake of simplicity, the system for checking the program code 16 will now be described with reference to the system 10 of Fig. 1. However, it will be appreciated by those ordinarily skilled in the art that the code checking described herein may also be implemented with any suitable code checking system, for example, but not limited to, the system 18 of Fig. 2.
Reference is now made to Fig. 3, which is a partly pictorial, partly block diagram view of the system 10 of Fig. 1 authenticating the code 16.
The program code 16 includes n sections 22.
The value of n is greater than 1 and typically less than 20, for example, but not limited to, n = 5. It will be appreciated by those ordinarily skilled in the art that n may have any suitable value and even a value greater than 20 may be suitable in certain applications.
For authentication purposes, the program code 16 is signed with an entire code signature 26 and each of the sections 22 is individually signed with a different signature 24. The signature 26 is typically different from any of the signatures 24. Fig. 4 describes the program code 16 and the sections 22 being signed in accordance with a different scheme.
As the device running the program code 16 needs to store more signatures (the signatures 24 of each section 22 and the entire code signature 26), the signatures 24 and the entire code signature 26 may be compressed if possible. By way of example, if an RSA signature scheme is used, then the signatures 24 and the entire code signature 26 can potentially be compressed into a single, physical signature. In overview, the processor 14 randomly or pseudo-randomly selects one section 22 of the program code 16. The processor 14 then calculates a hash, using a cryptographic hash function (e.g. SHA-1 or SHA-256) on the selected section 22, instead of on the entire program code 16 yielding a hash value 28 which is authenticated against the signature 24 of the selected section 22 typically using a public key 32 as is known is the art of digital signature authentication (block 30). Alternatively, non-asymmetric digital signature authentication may be performed using a suitable secret.
As the hash is calculated for the selected section 22, instead of on the entire program code 16, the partial check typically cuts the signature check time to roughly 1/n of the original time, which represents a very significant saving. However, checking only 1/ n of the program code 16 introduces some issues, complications and security problems that need to be addressed.
One issue is how to arrange the code in n sections. One approach is to allocate the first section 22 to bytes 0, n, 2*n, ..., the second section 22 to bytes 1, n+1, 2*n+l,... etc. Another approach is to have the first section 22 be the first 1/n of the code 16 and the second section 22 be the second 1/n of the code 16. It will be appreciated by those ordinarily skilled in the art that there are many suitable ways in which to arrange the code 16 in n sections.
Yet another issue, is that only checking part of the code 16 is insecure. A carefully crafted rogue image would only be discovered by the processor 14 with a probability of 1/n and a signature check failure could be overcome with a simple reboot. In order to address the security problem identified above, the processor 14 uses the counter 12 as a private sanction counter which is stored in non-volatile memory.
If the partial security check fails, the value of the counter 12 is adjusted. When the counter 12 reaches a certain value, a full signature check on the entire program code 16 is required at boot. The full check takes more time, but due to security concerns the time constraint is overridden.
The full check is typically performed by the processor 14 calculating a cryptographic hash of the entire program code 16 yielding a hash value which is authenticated against the entire code signature 26 using a public key or secret as appropriate.
How and when the counter 12 is updated is described in more detail with reference to Figs. 5 and 6.
Reference is now made to Fig. 4, which is a partly pictorial, partly block diagram view of the code 16 signed in accordance with an alternative method for use in the system 10 of Fig. 1.
For authentication purposes, the program code 16 and all the sections 22 are signed with a single signature 34 and each of the sections 22 has a hash value 36 and the entire program code 16 has a entire code hash 38. When all the hash values 36 and the entire code hash 38 are hashed together, using a cryptographic hash function, they yield another hash (a hash of the hash values 36, 38) effectively creating a two-level hash tree. The hash of the hash values 36, 38 is authenticated using the signature 34 so that any of the sections 22, or the entire program code 16, may be authenticated with the signature 34 in conjunction with the other hash values and an appropriate public key or secret, as appropriate.
So for example, in order to check one of the sections 22 (a partial check), the processor 14 (Fig. 3) calculates a hash, using a cryptographic hash function (e.g. SHA-1 or SHA-256) on the selected section 22, instead of on the entire program code 16, yielding a hash value which is compared with the existing hash value 36 of the selected section 22. If the calculated hash of the selected section 22 is not equal to the existing hash value 36 for the selected section 22, then the check of the selected section 22 has failed. If the calculated hash of the selected section 22 is equal to the existing hash value 36 for the selected section 22, then the existing hash value 36 for the selected section 22 needs to be authenticated against the signature 34. The authentication of the existing hash value 36 is performed as follows. First, the existing hash value 36 of the selected section 22 and the existing hash values 36 of all the other sections 22 and the entire code hash 38 of the entire program code 16 are hashed together, using a cryptographic hash function, yielding another hash which is authenticated against the signature 34 typically using a public key or secret depending on the mode of digital signature authentication employed.
Reference is now made to Fig. 5, which is a flow chart showing a first mode of operation of the system 10 of Fig. 1.
The value of the counter 12 (Fig. 3) typically starts at zero and the counter value is adjusted by failures of the partial check and successes of the full check during successive boot attempts, as will now be described in more detail.
The boot process starts at step 40.
In step 42 the counter value is compared to a threshold value. If the counter value is less than, or equal, to a threshold value Z, a partial check is performed (steps 44, 46). If the counter value is greater than the threshold value Z, then a full check is performed (step 48).
Therefore, for each boot attempt either a partial check or a full check is performed. If the check (partial or full) fails, a new boot attempt is performed, as will be described below.
The partial checking route is now described in more detail.
In step 44, one of the sections 22 (Fig. 3) of the program code 16 is selected (typically randomly or pseudo-randomly). In step 46, the selected section 22 is checked for authenticity.
In step 50, if the selected section 22 is authentic the boot process continues in step 52. If the selected section 22 is not authentic, the counter value is incremented by X in step 54 and the process returns to the start of the process (step 40).
The authentication of the selected section 22 may fail for various reasons, for example, but not limited to, a processing error, an error in the signature authenticating the selected section 22, or due to the selected section 22 having been tampered with. If the selected section 22 has been tampered with, authentication of the entire program code 16 will fail as well. However, if the selected section 22 has not been tampered with, then authenticating the entire program code 16 against the entire code signature 26 (Fig. 3) may prove to be an effective authentication step without ignoring potential security risks.
In step 48, the entire program code 16 is checked for authenticity (for example against the entire code signature 26). In step 56, if the entire program code 16 is authentic, the counter value is decremented by Y in step 58, and the boot process is continued in step 52. If the authentication of the entire program code 16 fails, the boot-loading process is restarted (step 40).
If the authentication of the program code 16 fails, then depending on the values of X, Y and Z the process with continue to loop around steps 42, 48, 56 and 40 until a new version of the program code 16 is installed at which time the counter value is reset to zero.
It will be appreciate that X, Y and Z can be set to any suitable values, for example, Y could be equal to 1, X greater than or equal to one (e.g. 3), and Z less than or equal to X (e.g. 1 or 2).
Reference is now made to Fig. 6, which is a flow chart showing a second mode of operation of the system 10 of Fig. 1. The flow chart of Fig. 6 is substantially the same as the flow chart of Fig. 4 except that in step 58, instead of decrementing the counter by Y, the counter is reset to the initial value, (e.g. zero).
The process described with reference to Figs. 5 and 6 may be generalized as follows.
The counter value starts at a certain initial value (e.g. zero or could be any other positive or even negative value) and increases (by fixed value or as a function (e.g. a fraction or exponential function) of the counter value) on failure of the partial check. The flowchart in Fig. 5 checks for the counter value being greater than the threshold value. However, the check for performing a full check could be when the counter value equals (or hits) the threshold value. Therefore, the partial check is performed unless the counter value hits or exceeds (depending on the criteria) a threshold value (could be a negative value, a positive value or zero) thereby requiring that a full check be performed. If the full check is successful, the counter value is reset to the initial value or reduced by a certain value (by a fixed value or as a function (e.g. a fraction or exponential function) of the counter value). When a new download is received the download is checked in full and the counter value is reset to the initial value.
Other options are now described below.
The counter value starts at a certain initial value (e.g. zero or it could be any other positive or even negative value) and is reduced (by a fixed value or as a function (e.g. a fraction or exponential function) of the counter value) on failure of the partial check. The partial check is performed unless the counter value hits or falls below a certain threshold value (could be a negative value, a positive value or zero) thereby requiring that a full check be performed. If the full check is successful, the counter value is reset to the initial value or increased by a certain value (by a fixed value or as a function (e.g. a fraction or exponential function) of the counter value). When a new download is received, the download is checked in full and the counter value is reset to the initial value.
Another option is as follows. The counter value starts at a certain initial value (e.g. zero or could be any other positive or even negative value) and is increased (by a fixed value or as a function (e.g. a fraction or exponential function) of the counter value) on success of the full check. The full check is performed unless the counter value hits or exceeds a certain threshold value (could be a negative value, a positive value or zero) thereby allowing a partial check to be performed. If the partial check fails, the counter value is reset to the initial value or reduced by a certain value (by a fixed value or as a function (e.g. a fraction or exponential function) of the counter value). When a new download is received, the counter value is reset to the initial value.
Yet another option is as follows. The counter value starts at a certain initial value (e.g. zero or could be any other positive or even negative value) and is decreased (by a fixed value or as a function (e.g. a fraction or exponential function) of the counter value) on success of the full check. The full check is performed unless the counter value hits or falls below a certain threshold value (could be a negative value, a positive value or zero) thereby allowing a partial check to be performed. If the partial check fails, the counter value is reset to the initial value or increased by a certain value (by a fixed value or as a function (e.g. a fraction or exponential function) of the counter value). When a new download is received, the counter value is reset to the initial value.
Reference is again made to Fig. 3.
The system 10 is now described in more detail.
The processor 14 is typically a processor to perform, as part of a boot-loading process, a code check including performing a partial check of the program code or a full check of the program code dependent on the value of the counter 12.
The full check typically includes authenticating all of the program code 16 against a digital signature (for example, the entire code signature 26 or the signature 34 according to the authentication method of Fig. 4).
The partial check typically includes randomly or pseudo-randomly selecting one of the sections 22 from the plurality of sections 22 of the program code 16. The partial check includes authenticating the selected section 22 of the program code 16 against a digital signature (for example, one of the digital signatures 24 or the signature 34 according to the authentication method of Fig. 4). Typically only one of the sections 22 is checked as part of the partial check during the boot-loading process. However, the partial check may include checking two or more sections 22 of the program code 16. However, it should be noted that the partial check excludes performing a signature check on all of the sections 22 of the program code 16.
The full check or the partial check may be based on asymmetric cryptography using a public key as described herein above. Alternatively, the full check or the partial check may be based on symmetric cryptography, for example, by authenticating the program code 16 or the selected section 22 against a message authentication code (MAC) based on a secret shared between the processor 14 and the supplier/distributor of the program code.
The processor 14 is typically operative to adjust the counter value in a first direction if the full check is successful and adjust the counter value in a second direction, opposite to the first direction, if the partial check fails. In accordance with one embodiment of the present invention, the processor 14 is operative to: decrement the counter value if the full check is successful; increment the counter value if the partial check fails; and perform the full check of the program code 16 when the value of the counter 12 is greater than, or equal to, a threshold value.
In accordance with an alternative embodiment of the present invention, the processor 14 is operative to: increment the counter value if the full check is successful; decrement the counter value if the partial check fails; and perform the full check of the program code 16 when the value of the counter 12 is less than, or equal to, a threshold value.
The processor is operative to continue with the boot-loading process if the code check yields a positive validation.
It will be appreciated the system 10 may be implemented in any suitable environment for example, but not limited to, in a car, in a router, in a TV or in a set-top box.
It is appreciated that software components of the present invention may, if desired, be implemented in ROM (read only memory) form. The software components may, generally, be implemented in hardware, if desired, using conventional techniques. It is further appreciated that the software components may be instantiated, for example, as a computer program product; on a tangible medium; or as a signal interpretable by an appropriate computer.
It will be appreciated that various features of the invention which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable sub-combination.
It will be appreciated by persons skilled in the art that the present invention is not limited by what has been particularly shown and described hereinabove. Rather the scope of the invention is defined by the appended claims and equivalents thereof.

Claims

What is claimed is: CLAIMS
1. A system comprising:
a counter having a value;
a first processor to:
perform, as part of a boot-loading process, a code check including performing a partial check of program code or a full check of the program code dependent on the value of the counter, the program code having a plurality of sections;
adjust the counter value in a first direction if the full check is successful; and
adjust the counter value in a second direction, opposite to the first direction, if the partial check fails; and
continue with the boot-loading process if the code check is successful, wherein: the full check includes authenticating all of the program code against a first digital signature; the partial check includes authenticating one of the sections of the program code against a second digital signature; and the partial check excludes authenticating all the sections of the program code, the first signature being the same as, or different from, the second signature.
2. The system according to claim 1, wherein the partial check includes randomly or pseudo-randomly selecting the one section from the plurality of sections of the program code.
3. The system according to claim 1 or claim 2, further comprising a second processor operative to execute the program code, wherein: the first processor is operative only to run the boot-loading process and the counter is protected so that the counter can be adjusted or reset by the first processor but not by the second processor.
4. The system according to any of claims 1-3, wherein the counter is protected from being reset or adjusted manually.
5. The system according to claim 1 or claim 2, wherein the first processor operative is also operative to execute the program code, wherein the counter is protected so that the counter can only be adjusted or reset by the first processor during the boot-loading process.
6. The system according to any of claims 1-5, wherein the first digital signature is different from the second digital signature which is different for each one of the sections of the program code so that there are a plurality of second digital signatures.
7. The system according to claim 5, wherein the second digital signatures are compressed together into a single physical structure.
8. The system according to any of claims 1-5, wherein the first digital signature is different from the second digital signature.
9. The system according to any of claims 1-5, wherein the first digital signature is the same as the second digital signature.
10. The system according to any of claims 1-9, wherein the first processor is operative to:
decrement the counter value if the full check is successful;
increment the counter value if the partial check fails; and perform the full check of the program code when the value of the counter is greater than, or equal to, a threshold value.
11. The system according to any of claims 1-9, wherein the first processor is operative to: increment the counter value if the full check is successful;
decrement the counter value if the partial check fails; and perform the full check of the program code when the value of the less than, or equal to, a threshold value.
12. A method comprising:
performing, as part of a boot-loading process, a code check including performing a partial check of program code or a full check of the program code dependent on the value of the counter, the program code having a plurality of sections;
adjusting the counter value in a first direction if the full check is successful;
adjusting the counter value in a second direction, opposite to the first direction, if the partial check fails;
continuing with the boot-loading process if the code check is successful, wherein: the full check includes authenticating all of the program code against a first digital signature; the partial check includes authenticating one of the sections of the program code against a second digital signature; and the partial check excludes authenticating all the sections of the program code, the first signature being the same as, or different from, the second signature.
PCT/IB2012/055148 2012-02-29 2012-09-27 Code checking system WO2013128247A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201261634430P 2012-02-29 2012-02-29
US61/634,430 2012-02-29

Publications (1)

Publication Number Publication Date
WO2013128247A1 true WO2013128247A1 (en) 2013-09-06

Family

ID=47505270

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2012/055148 WO2013128247A1 (en) 2012-02-29 2012-09-27 Code checking system

Country Status (1)

Country Link
WO (1) WO2013128247A1 (en)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5978913A (en) 1998-03-05 1999-11-02 Compaq Computer Corporation Computer with periodic full power-on self test
US6718461B1 (en) 2000-04-28 2004-04-06 Intel Corporation Booting processor-based systems
US6725368B1 (en) * 1999-12-09 2004-04-20 Gateway, Inc. System for executing a post having primary and secondary subsets, wherein the secondary subset is executed subsequently to the primary subset in the background setting
EP1550988A2 (en) * 2003-12-30 2005-07-06 WMS Gaming Inc Gaming machine having software verification
US20080229055A1 (en) * 2002-11-21 2008-09-18 Craft David J Hardware-Based Secure Code Authentication
US7555677B1 (en) 2005-04-22 2009-06-30 Sun Microsystems, Inc. System and method for diagnostic test innovation

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5978913A (en) 1998-03-05 1999-11-02 Compaq Computer Corporation Computer with periodic full power-on self test
US6725368B1 (en) * 1999-12-09 2004-04-20 Gateway, Inc. System for executing a post having primary and secondary subsets, wherein the secondary subset is executed subsequently to the primary subset in the background setting
US6718461B1 (en) 2000-04-28 2004-04-06 Intel Corporation Booting processor-based systems
US20080229055A1 (en) * 2002-11-21 2008-09-18 Craft David J Hardware-Based Secure Code Authentication
EP1550988A2 (en) * 2003-12-30 2005-07-06 WMS Gaming Inc Gaming machine having software verification
US7555677B1 (en) 2005-04-22 2009-06-30 Sun Microsystems, Inc. System and method for diagnostic test innovation

Similar Documents

Publication Publication Date Title
US10719606B2 (en) Security processor for an embedded system
US20210124820A1 (en) Application program integrity verification method and network device
US20200125756A1 (en) Implementing access control by system-on-chip
US9853974B2 (en) Implementing access control by system-on-chip
US9705678B1 (en) Fast CAN message authentication for vehicular systems
JP5703391B2 (en) System and method for tamper resistant boot processing
US8341393B2 (en) Security to extend trust
US20090193211A1 (en) Software authentication for computer systems
EP2668566B1 (en) Authenticate a hypervisor with encoded information
EP3284000B1 (en) Secure software authentication and verification
US20140298026A1 (en) Information processing device and computer program product
US9443107B2 (en) Method for protecting the integrity of a group of memory elements using an aggregate authentication code
US9866553B2 (en) Method for securing access to a computer device
US20180204004A1 (en) Authentication method and apparatus for reinforced software
US10803176B2 (en) Bios security
US11537757B2 (en) Securely writing data to a secure data storage device during runtime
US20160350537A1 (en) Central processing unit and method to verify mainboard data
US11347858B2 (en) System and method to inhibit firmware downgrade
EP1465038B1 (en) Memory security device for flexible software environment
US20200233676A1 (en) Bios management device, bios management system, bios management method, and bios management program-stored recording medium
US9100374B2 (en) Method for managing remote upgrading keys in an information security apparatus
US20170147838A1 (en) Systems and methods for cache memory authentication
WO2020036887A1 (en) Authentication of files
WO2013128247A1 (en) Code checking system
CN108399328B (en) System memory content authentication apparatus and method

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12810421

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12810421

Country of ref document: EP

Kind code of ref document: A1