WO2013004854A2

WO2013004854A2 - Processing system

Info

Publication number: WO2013004854A2
Application number: PCT/EP2012/069498
Authority: WO
Inventors: Peter Rombouts; Ventzislav Nikov
Original assignee: NXP BV
Current assignee: NXP BV
Priority date: 2012-09-26
Filing date: 2012-10-02
Publication date: 2013-01-10
Anticipated expiration: 2015-03-26
Also published as: WO2013004854A3

Abstract

A processing system is disclosed. The system comprises: a processor; memory adapted to store data for use by the processor; a verification unit adapted to identify a trusted region of the memory and to process data stored in the trusted memory region in accordance with a predetermined verification algorithm to verify the trusted status of the trusted memory region; and a memory access control unit adapted to control access of the processing unit to data stored in the trusted memory region based on whether its trusted status is verified by the verification unit.

Description

PROCESSING SYSTEM

FIELD OF THE INVENTION

This invention relates to processing systems, and more particularly to controlling access of a processing unit of a processing system to data stored by a memory of the processing system

BACKGROUND

Security is an important consideration for processing systems such as microcontrollers. For example, it may be desirable to ensure that a processor only executes a specific task which is described by a piece of executable program code (or equivalent set of instructions, such as a script for example)

However, the code and/or execution of the code may be may be subject to attacks. Attacks may include any of the following exemplary list:

- unauthorized modification of stored program code;

- modification of code during execution;

- code dumping (e.g. reading out code for the purposes of reverse engineering);

- unauthorized changing of memory access privileges;

- execution of unauthorized code from data segments

Several techniques are already known that aim to protect a processing system against attacks or limit the impact of malfunctioning software (either accidentally or as the result of a successful attack).

For example, the concept of code signing is widely known, in which signatures computed over code binaries are used to prevent the loading of an unauthorized program code image into memory or to verify the integrity of program code before running it. These signature verification concepts are typically implemented as a software routine in a boot program or an operating system.

It is also known to include a memory protection unit in processing systems. Such memory protection units are controlled by the same processor they are designed to protect and, as a result, are still vulnerable to attacks.

BRIEF SUMMARY OF THE INVENTION According to an embodiment of the invention, there is provided a processing system according to independent claim 1.

A processing system is proposed that can be protected against attacks and/or the execution of unsafe or unauthorized code. Embodiments may therefore prevent the execution of untrusted software or program code. Further protection may also be provided against software reverse engineering by controlling access to the stored program code. Embodiments may achieve this by verifying program code and subsequently assuring that this verified code is executed unaltered.

The processing system may be a smart card, an integrated circuit, a microcontroller, a microprocessor, a microchip or a processing platform. Therefore the processor may be a central processing unit (CPU) or a processor core.

According to an embodiment of the invention, there is provided a method of controlling access of a processing unit of a processing system to data stored by a memory of the processing system according to claim 12.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the present invention will now be described, by way of example only, with reference to the following drawings in which:

Figure 1 is a schematic block diagram of a processing system according to an embodiment of the invention;

Figure 2 is a schematic block diagram of a microcontroller arrangement according to an embodiment of the invention;

Figure 3 is a flow diagram of a method according to an embodiment of the invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Besides the components typically present in a processing system (a processor unit or CPU, memory, and peripherals, all connected by a communication bus), proposed embodiments further comprise two additional devices: a verification unit (otherwise referred to as a 'verifier') and an access control unit (otherwise referred to as a 'gatekeeper'). The verifier and the gatekeeper work in conjunction which each other to protect the processing system from unwanted or unauthorized attacks.

The verification unit (or verifier) is responsible for verifying areas of the memory and configuring conditions and/or parameters which can be used by the access control unit (or gatekeeper) to control access to the memory. For example, in a particular embodiment, the verifier may be adapted to check program code signatures and to set trust parameters for use by the gatekeeper.

The access control unit (or gatekeeper) controls access to the memory. It may therefore restrict access that components of the processing system have to areas of memory. A decision by the gatekeeper to grant or deny access to certain memory areas may be conditional on a set of configurable parameters. For example, in a particular embodiment, the gatekeeper may be adapted to allow or deny fetching of program code from certain regions in memory based on whether this code is indicated to be trusted by the verifier. Thus, the processor unit may be restricted to only have access to the areas of memory that are identified as requiring trust (e.g. areas having a signatures) and also confirmed as being trusted by verification of the trusted status. Put another way, the processor unit can be prevented from accessing all areas of memory except those which have been verified by the verifier. Alternatively, the processor unit may have full (data) read/write access to the memory, except for the regions which are configured to require verification. These regions may only become accessible after a successful verification (i.e. once they are confirmed to be trusted) and their access conditions may depend on their contents (as defined in a header field for example). By way of example, code regions become execute only and constant data regions become read-only. Further, a more extensive header format may be used and allow the definition of further memory regions and corresponding access restrictions.

Exemplary pseudo-code to determine the access conditions may be as follows: (i) If an identified region is not a protected region, then allow data access (read and write) and disallow code (fetch) access. End procedure.

(ii) If a protected memory region failed verification, disallow all types of access (except for the verifier which has read-only access). End procedure. (iii) Allow access rights according to the type of the memory contents: execute-only for CODE, read-only for CONSTANTS.

Embodiments are based on the following concepts:

i. Establishing a strong root of trust;

ii. Extending the trust to the program code through verification by the root of trust;

iii. Maintaining trust by preventing alterations to the program code and configuration;

iv. Enforcing the execution of trusted program code only; and

Embodiments may also protect the program code by restricting read access.

In embodiments, the concepts i-iv above are implemented as follows:

- A verification unit acts as a strong root of trust;

- This verification unit performs code verification and configures the access control unit depending on the result of the verification;

- The access control unit only accepts configuration from the verification unit; i.e. its configuration is inaccessible from any other part of the system such as e.g. the CPU;

- The access control unit prevents modification of the verified code (for example, all writing permissions, may be revoked prior to the start of a verification process undertaken by the verification unit);

- The access control unit prevents fetching of code from any part of memory except for code verified by the verification unit (i.e. verified code);

- The access control unit prevents data read operations from the program code image, except for the verification unit (including all read attempts prior to it having been verified);

In embodiments, the access control unit is adapted to be able to distinguish between a code fetch and a data read operation. In most conventional processing systems, these operations are performed using different busses or can be distinguished based on the bus signals. This can therefore be used by the access control unit to make the distinction. In other cases, a signal to differentiate the two operations may be generated which can then be used by the access control unit. Referring to Figure 1, there is shown a schematic block diagram of a processing system 100 according to an embodiment of the invention. The system comprises a processor unit or CPU 102 connected to communication bus 104. Also connected to the communication bus 104 (via respective interfaces 106a, 108a, and 110a) are volatile 106 and non- volatile 108 memory units, and peripherals 110.

Unlike conventional processing systems, the system of Figure 2 further comprises a verification unit 112 and an access control unit 114 connected to the communication bus 104.

The verification unit 112 is adapted to determine trusted areas of the memory 106,108 by verifying the authenticity of stored program code for example. The verification unit 1 12 is also adapted to determine conditions and/or parameters which can be used by the access control unit 114 to control access to the memory 106, 108.

The access control unit 114 is adapted to control access to the memory 106,108. It is therefore configured to restrict access that components of the processing system have to areas of the memory 106,108.

The access control unit 114 determines whether to grant or deny access to certain memory areas based on information from the verification unit 112 which indicates the authenticity or trustworthiness of the access request and/or data within the memory area(s). For example, here, the access control unit 1 14 is adapted to allow or deny fetching of program code from the non- volatile memory 108 based on whether program code stored by the non- volatile memory 108 is indicated to be trusted by the verification unit 112.

Trusted Program Code

Trusted program code resides in a trusted code image which may, for example, be stored in non-volatile memory 108. Thus, one or more trusted code images may be stored by the non- volatile memory 108 of the system 100.

The trusted code image comprises at least the following components:

- header: contains information for verifying the code image;

- program code: the executable part of the code image, preferably read-only and executable; and - constant data: the non-executable part of the code image containing constants and initialization data required by the code (it is preferably readonly and non-executable).

In this exemplary embodiment, the header, program code and constant data segments are stored in non-overlapping continuous memory regions (although it will be understood that alternative embodiments may be adapted to also support non- continuous memory regions). For the avoidance of doubt, the three segments (header, program code, and constant data) do not need to be stored in consecutive memory areas.

In this exemplary embodiment, the header comprises the following information: the address range that contains the program code; the address range that contains the constant data; and signature over the concatenation of the two address ranges, the code and the constant data

Other embodiments may contain additional fields and may replace the signature with any other method capable of proving the authenticity of the trusted code image; in particular a Message Authentication Code (MAC).

Operating Principle

At power-on, the verification unit 1 12 holds the processing unit (CPU) 102 in reset mode and configures the access control unit 114 such that all access to trusted code images is blocked (i.e. non-executable, non-readable and non-writable), except for the verification unit 112 itself which has read-only access.

The verification unit 112 then verifies one or more trusted code images (see verification procedure below). When verification succeeds for a trusted code image, the verification unit 112 re-configures the corresponding access restrictions for the access control unit 114 such that instruction fetch from program code segment and read-only access from the constant data segment are permitted.

After this, the verification unit 112 releases processing unit (CPU) 102 from the reset mode and a normal boot procedure starts. The access control unit 114 monitors all memory access operations and blocks/denies or allows certain operations based on the configuration information provided by the verification unit 112.

In some embodiments, the verification unit 112 may perform additional verifications triggered by a request from software running on the processor unit (CPU) 102. In some embodiments the verification unit 1 12 may also be periodically triggered (e.g. by a hardware timer) to perform a re-verification of an already verified trusted code image.

Verification Procedure

This section describes an exemplary verification procedure. Here, it is assumed that the verification unit 112 knows the starting address of the header of the trusted code image(s) it needs to verify. For example, the verification unit 112 may store a list of such addresses. The verification procedure is repeated for each of the trusted code images.

The verification procedure proceeds as follows:

The verification unit 112 reads the header of the trusted code image and computes a message digest over the address ranges of the header, the code segment and the constant data segment. It then uses the message digest to verify the signature using any suitable prior art method.

The Verification Unit 112

The verification unit 112 acts as the root of trust and verifies a code image. Depending on the result of this verification, it configures the access control unit 112 to permit or deny retrieval and/or execution of the code image.

In order for the verification unit 1 12 to be able to perform the verification, the code image contains redundant information. In particular, this redundant information may be a cryptographic signature, message authentication code (MAC) or any other suitable information.

The verification of the code image by the verification unit 112 may be triggered automatically or on request. Also, the verification unit 1 12 may perform the verification on the entire code image at once or it may perform the verification in chunks.

There are many possible ways in which the verification unit 112 can be implemented. Some exemplary implementations may be as follows:

- The verification unit 112 may be implemented as a hardware core performing verification of the code image and the configuration of the access control unit 114. When implemented in this way, the verification unit 1 12 will be difficult to attack and therefore provide a strong root of trust. - The verification unit 112 may be partly implemented in the processor (platform) and partly in a secure device such as a secure element (SE). The part implemented in the processor (platform) acts as a gateway providing a secure link to the secure device which performs the verification of the code image and the configuration of the access control unit. When implemented in this way, the secure device provides a strong root of trust and offers more flexibility than implementation as a hardware core. However, the gateway will have to provide a strong secure link to the secure device.

- The verification unit 1 12 may be implemented as a software routine running on the processor (platform) and performing the verification of the code image and the configuration of the access control unit 114. This implementation provides only a weak root of trust since the access control unit 1 14 needs to accept configuration by software. The access control unit 114 may therefore need to implement additional security measures, such as a source check for example. A source check checks that that the code that is configuring the parameters is in fact the code that is supposed to do this. By way of example, the addresses of the fetched instructions can be recorded, and when parameters are configured, a check can be made that these addresses have the expected values.

We should also have certainty that the data residing at these addresses is indeed the correct (expected, trusted) code hence it is preferable to store this code in memory that cannot be altered (typically ROM).

Since the code of the verification unit 112 can also not be checked it should preferably not be alterable (for example, reside in ROM or be protected against writing by the access control unit 114).

The verification unit 1 12 may use secrets or key values and as such become a target for attack itself. The processing system 100 may therefore need to provide secure storage and the implementation of the verification unit 112 may require countermeasures against side channel and fault attacks.

Access Control Unit 114

The access control unit 114 maintains the trust established by the verification unit 112 by controlling access to program code and enforcing that only trusted code is accessed and/or executed. The access control unit 114 may also enforce further access restrictions that prevent a code image from being copied, and may also protect other memory areas.

The access control unit 114 bases its determination of the memory regions it must protect and/or the access restrictions it must enforce on information from the verification unit 112. Preferably, the access control unit 1 14 only accepts information from the verification unit 112 when making such a determination.

While the verification unit 112 will typically only perform its task at specific times (e.g. at startup or on request), the access control unit 114 is adapted to remain active at all times.

The initial configuration of the access control unit 114 may depend on the embodiment, but in most cases it will be adapted to block all memory accesses except those performed by the verification unit 1 12.

In the case where the verification unit 112 is implemented as a software routine running on the processor (platform), the initial configuration may need to allow access of the processor 102 (CPU) to the memory.

The configuration of the access control unit 1 14 may contain any of the following parameters:

- memory (address) regions from which code can be executed;

- memory (address) regions from which data read access is denied;

- memory (address) regions to which data write access is denied; and

- additional conditions under which the access restrictions or permissions apply; such as: (i) memory (address) regions which the source address of the instruction being executed comes from (for example, read access to a certain memory region may be restricted to certain software routines who's code resides in a specific memory region); (ii) the source device the access attempt comes from (for example, the verification unit 1 12 may be allowed to read from all memory regions but not from peripherals, whereas the processor may only be allowed to read from certain memory regions but is allowed to read from all peripherals).

The access control unit 1 14 may be implemented in a centralized or distributed manner, depending on the embodiment. In a centralized implementation, one device implements the access control unit 114 functionality and manages all memories. In a distributed implementation, each memory type may have its own device implementing a part of the access control unit 114 functionality only for that particular memory.

The access control unit 114 may be implemented, depending on the embodiment, as part of an existing component of a processor (platform) such as a Memory Management Unit, a Memory Protection Unit, an Address Decoder, a Memory Interface (in case of a distributed implementation), or it may be implemented as a separate device.

The access control unit 114 may therefore prevent the processing unit (CPU) 102 from executing a command in several different ways. For example it may generate a memory error, trigger an interrupt, provide a non-executable instruction, return a NOP instruction, or a combination thereof.

Turning to Figure 2, there is shown a microcontroller arrangement 200 according to an embodiment. The microcontroller arrangement 200 comprises a microcontroller unit (MCU) 202, otherwise referred to as a central processing unit (CPU). Memory 204 for storing program code is connected to the MCU 202 via an access control unit 206. Also connected to the MCU 202 is a shared memory unit 208 and a mixed signal unit 210.

An I/O interface 212 for inputting/outputting data to/from shared memory unit 208 is provided.

A verification unit 214 is connected to the access control unit 206, but is also adapted to have access to the MCU 202 and memory 204 (as indicated by the dashed lines in Figure 2).

The access control unit 206 contains a set of records, whereby each record comprises the following fields: start address, end address, execute flag, read flag, write flag. The start and end address define a region of the memory 204 for which access permissions are defined by the flags. If the execute flag is set, then program code fetches are allowed from addresses within the defined region of memory 204. The same applies mutatis mutandis to the read and write flags, i.e. executable-only for program code and read-only for constant data.

The set of records are configured by the verification unit 214. More specifically, the verification unit 214 determines trusted areas of the memory 204 by verifying the authenticity of stored program code for example. If verification succeeds for stored program code, the verification unit 214 configures the corresponding access restrictions for the access control unit 114 by setting the fields of a corresponding record to have appropriate values.

The access control unit 206 continuously monitors communication between the MCU 202 and the memory 204 to determine if access is permitted or not. By way of example, the access control unit 206 can extract the following information from the communication link between the MCU 202 and the memory 204:

- requester: which devices requests the access;

- type of access: data read, data write or code fetch; and

- requested address.

If the requester is the MCU, then the access control unit 206 looks up a record corresponding to the requested address. If no record is found, access is granted or denied depending on a predetermined default setting. If a record is found, the access control unit 206, grants or denies the access depending on the flag value set in the record for the requested type of access.

Referring to Figure 3, there is illustrated a flow diagram of a method according to an embodiment of the invention. The method provides for the controlling of access of a processing unit of a processing system to data stored by a memory of the processing system.

The method begins in step 302 with the step of identifying a region of the memory that is indicated to be trusted. By way of example, the starting address of the header of a trusted code image may be identified (from a database or by scanning the memory for example).

Next, in step 304, the data stored in the identified trusted memory region is processed in accordance with a verification algorithm to verify is the trusted status of the memory region is correct. Here, a message digest may be computed over the address ranges of the header, the code and the constant data segments of the trusted code image. The computed message digest may then be used to verify if the trusted code image does in fact adhere to security requirements that indicate the code image is to be trusted.

Finally, in step 306, access of the processing unit to data stored in the trusted memory region is controlled based on the result of the verification step (step 204), i.e. base on whether or not the trusted status of the trusted memory region has been verified as correct. For example, access to data stored in the trusted memory region can be granted or denied depending on whether the trustworthiness of the trusted memory region has been verified in step 204.

Embodiments may be captured in a computer program product for execution on a processor of a computer, e.g. a personal computer or a network server, where the computer program product, if executed on the computer, causes the computer to implement the steps of a method according to an embodiment. Since implementation of these steps into a computer program product requires routine skill only for a skilled person, such an implementation will not be discussed in further detail for reasons of brevity only.

In an embodiment, the computer program product is stored on a computer- readable medium. Any suitable computer-readable medium, e.g. a CD-ROM, DVD, USB stick, memory card, network-area storage device, internet-accessible data repository, and so on, may be considered.

Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practising the claimed invention, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measured cannot be used to advantage. A computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid- state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems. Any reference signs in the claims should not be construed as limiting the scope.

Claims

1. A processing system (100) comprising:

a processor (102);

memory (108) adapted to store data for use by the processor;

a verification unit (112) adapted to identify a trusted region of the memory and to process data stored in the trusted memory region in accordance with a predetermined verification algorithm to verify the trusted status of the trusted memory region; and

a memory access control unit (114) adapted to control access of the processing unit to data stored in the trusted memory region based on whether its trusted status is verified by the verification unit.

2. The system of claim 1, wherein the verification unit (112) is further adapted to generate information representing: the location of the trusted region of the memory; and access permissions for the trusted region.

3. The system of claim 2, wherein the information representing access permissions for the trusted region comprises an indication of at least one of: data read permissibility, data write permissibility; and program code fetch permissibility.

4. The system of claim 2 or 3, wherein the verification unit (112) is further adapted to generate information representing conditions applicable to the access permissions.

5. The system of any preceding claim, wherein the data comprises:

a header comprising information for verifying if the data is trusted; and a body comprising program code for execution by processor.

6. The system of claim 5, wherein the body further comprises data values for use by the program code.

7. The system of claim 5 or 6, wherein the information for verifying if the data is trusted comprises a cryptographic signature or an authentication code.

8. The system of any preceding claim, wherein the memory access control unit (114) is adapted to grant or deny access to data stored by the memory based on information generated by the verification unit (112) indicating the trustworthiness of the trusted memory region.

9. The system of any preceding claim, wherein the verification unit (112) is adapted to verify the trusted status of trusted memory region that has previously been verified.

10. The system of any preceding claim, wherein at least part of the verification unit is implemented in read-only memory.

11. A microcontroller comprising a processing system (100) according to any preceding claim.

12. A method of controlling access of a processing unit of a processing system to data stored by a memory of the processing system, the method comprising the steps of:

identifying a trusted region of the memory;

processing data stored in the trusted memory region in accordance with a predetermined verification algorithm to verify the trusted status of the trusted memory region; and

controlling access of the processing unit to data stored in the trusted memory region based on whether its trusted status is verified by the verification unit.

13. The method of claim 11, further comprising the step of generating information representing: the location of the trusted region of the memory; and access permissions for the trusted region.

14. The method of claim 11 or 12, further comprising generating information indicating the trustworthiness of the trusted memory region, and wherein the step of controlling access comprises granting or denying access to data stored by the memory based on generated information.

15. A computer program product for controlling access of a processing unit of a processing system to data stored by a memory of the processing system, the computer program product comprising a computer-readable storage medium having computer- readable program code embodied therewith, the computer-readable program code configured to perform all of the steps of any of claims 12 to 14.