FIELD OF THE INVENTION

Modern computing systems, especially mobile computing devices such as smartphones, require mechanisms to control software updates such that only trusted software application programs, or "apps", may be loaded. One important mechanism often used to control updates is the monotonic counter, which can only count in one direction, e.g. can only count up. The instant invention allows monotonic counters, and other control mechanisms, to be implemented more easily and at lower cost.

BACKGROUND

A Mobile Computing Device is typically implemented as a System-on-Chip or SoC. The SoC includes most or all of the computing resources needed for the computing system such as a smartphone or IoT device. The SoC may include inter alia a processor, memory of different types including volatile and non- volatile memory, as well as one or more modems for wired or wireless communication, an interface to a display and other human interface devices such as a microphone, etc.

The software application programs or apps are loaded into the system and stored in some sort of non- volatile storage so that they will remain available after power to the system has been removed and restored, or after power to the memory has been removed and restored. In a mobile device this non- volatile memory is often "Flash" memory, a type of EEPROM; in non-mobile computing systems the non-volatile memory may also be e.g. magnetic storage such as a disk drive. Another form of non-volatile memory is the "fuse", which is typically a write-once elec- trical device. A fuse can typically only be programmed once, for example from the closed (conducting) state to the open (non-conducting) state. Fuses can be used to implement a basic monotonic counter, since by their nature they can only change state in one direction, and that only once. Apps may be used to perform activities where security is wanted or needed, such as banking apps or communication apps. The apps may also contain or access data which should be kept secure, such as financial data, personal data or passwords. Therefore there is a need to keep these apps trustworthy and protected against software attacks using hardware enforcement, e.g. to prevent unwanted reading of data, etc. The attacks are often called "hacking", and may lead to the security of data or information being compromised. Typically the trusted applications, or Trustlets (from trusted applet), are intended to be secure and designed to be protected against attacks. Nevertheless, from time to time a fault or weakness or vulnerability in an trusted applications or app may be found, which can be exploited by attackers to successfully bypass or overcome the protections of that app. Once the weakness and exploit has been understood, the app is usually fixed so that the fault or vulnerability is no longer available for attacks. An updated app with the fix can then made available to all systems which use the app, as a newer or updated version. The new version of the app is loaded onto the system as an update, and the new version then replaces the older version.

When a given system or smartphone is updated with a new version of the app, the vulnerability which has been fixed is no longer available to attackers. One way to attack a fixed system is to "roll back" or revert the app in question to a previous version, which version includes the vulnerability that in turn can be exploited for an attack.

One possible protection against the reversion of an app to a vulnerable version is based on the enumeration or versioning of apps, in such a way that versions of the app which are newer have a higher version number and also have fewer vulnerabilities - or at least the known vulnerabilities have been fixed in the apps with higher version numbers, and therefore can no longer be exploited. Protection against "roll-back" or reversion to a vulnerable version of an app can thus be achieved with a monotonic counter for the version number. A counter for the app counts up with each new version of the app. Before loading an app, the system checks if the app to be loaded is at least as new as an existing version of the app in the system. If an app to be loaded has a version number higher (or perhaps at least as high) as the existing version number, then it is taken as an update. Otherwise the app is rejected as a roll-back or reversion to a previous version.

The versioning protection scheme requires at least one monotonic counter per app. Since version information may be complex, for example with a primary and a secondary version, accompanied by a date field, several bits or bytes may be required per app and per monotonic counter. Existing systems have implemented such monotonic counters with One Time Programmable (OTP) memory such as fuses; however, fuses may be undesirable in terms of silicon area required for implementation, cost, power supply issues connected with "burning" or changing the state of a fuse, etc.

SUMMARY OF THE INVENTION

In general, disadvantages of state-of-the art implementations of monotonic counters are found in the limitations in flexibility of One Time Programmable memory. OTP memory is currently available only in small quantities, e.g. in form of fuses. It would be desirable to have a means for implementing monotonic counters with technical characteristics and cost drivers comparable to existing storage for version numbers. This is achieved by the inventive concept disclosed herein. In one embodiment, monotonic counters are implemented by dedicating at least a portion of a non- volatile memory to rule-based access, and wherein the rule for writing to a location in the memory is that only values which are greater than (or greater-than or equal-to) the value currently stored at that location may be written. In one embodiment, the rule is enforced by a memory controller, which controls all access to the memory or to the portion of the memory used for rule- based access. Various rules are contemplated by the invention, including for example that a value written to a location may have a maximum value, or that the rule for one location may also depend on a value at a different location in the memory. Other rules contemplated include state- machine transitions, such as State E may only be reached from States B or C.

Another embodiment of this invention is for secure state machines, which enforce transitions between different states using rules, especially in conjunction with reaching certain privilege levels based on authentication. The privilege levels may grant or deny access to certain data or locations in the memory.

BRIEF DESCRIPTION OF THE FIGURES

Figure 1 shows an embodiment of the inventive concept with memory and memory controller.

Figure 2 shows an SoC including the inventive concept.

Figure 3 shows another implementation with external memory.

Figure 4 shows an implementation where separate busses connect the memory. Figure 5 shows the steps of reconfiguration during secure boot.

DETAILED DESCRIPTION Fig. 1 represents an embodiment of the inventive concept in a System-on-Chip (101), as might be found in a smartphone or other mobile computing device. However, nothing in the inventive concept limits its application to mobile devices.

A non- volatile memory or NVM, shown as 120, is used to store data and programs, including trusted applications or apps. Examples of non- volatile memory include EEPROM and its variant Flash, but also more exotic memory types known to the person of skill, such as MRAM or PCRAM. Another type of non-volatile memory is magnetic or core memory. The memory must be large enough to store apps which are kept on the system. In one embodiment the memory is divided into portions 121, 122, 123, of which one portion 122 may be subject to predefined rules. The memory is operated by a memory controller 1 10, which enforces the predefined rules for access to the memory. A processor 150 accesses the memory and executes programs, and reads and writes locations in the memory, via the controller. Reading comprises obtaining the value stored at a location and writing comprises storing a value at a location. The portion 122 or portions of the memory subject to rules may be much smaller than the totality of the memory, or they may comprise the totality of the memory. The memory controller 110 controls the access to the memory 120 as shown by access 131 to portion 121, 132 to portion 122, and 133 to portion 123. The access shown is symbolic, and may be implemented with one or more physical connections such as memory busses. In an embodiment the defined portion 122 may be defined by an address range. For example the portion subject to rules may be addresses OxlOaO to 0x1 Off. The portion may be defined by a characteristic of the address, for example even or odd addresses. In an embodiment the portion may be defined by a combination of an address range and a characteristic. The portion may be defined by a mapping table. The person of skill can easily imagine additional ways of specifying and defining the portion of the memory which is subject to the rules. In an embodiment the portion subject to rules may store any sort of data, subject only to the rules. The memory and the controller must be tightly coupled in order to allow sufficient bandwidth in the accesses to the memory. Especially for program execution, it may be necessary to have highspeed or wide busses between controller and memory. In one embodiment this may be achieved by putting memory and controller on the same substrate. In another embodiment, the two may be on separate substrates, but linked by high-bandwidth connections. In one embodiment, the two may be on separate substrates but in the same package, linked for example by chip-on-chip bonding. In order to ensure security for the data transferred between the two, it may be advantageous for the two to be thermally coupled, such that there is little or no empty space between the two. The mechanism for thermal coupling may also ensure that there is less opportunity to eavesdrop or to interfere with data transferred between the two.

In one embodiment, the rules which the memory controller enforces for access are defined during manufacturing. The definition of the rules may occur using a high-level silicon programming language such as Verilog or VHDL.

In another embodiment, the rules which the memory controller enforces are defined by software during a secure boot. The rules may be read from an NVM, for example from the memory 120. In one embodiment, the defined portion 122 or portions of the memory which are subject to the predefined rules, as well as the way in which the rules are enforced, are defined during manufac- hiring. In another embodiment, the portion or portions of the memory, as well as the way in which the rules are enforced, are defined by software during a secure boot. The definitions for the rules may be read from an NVM, for example from the memory 120.

In one embodiment the rules may be used to allow or deny certain access, for example a read access to a certain location. In another embodiment, only write access to a location may be allowed or denied by the rules. It is contemplated by the invention that a wide variety of access types may be allowed or denied in different ways and with different combinations, according to the rules. In one embodiment, an entire secure application or app may be stored in a defined portion of memory subject to rules. In another embodiment, only portions of an app may be stored in the portion of memory subject to rules. This latter embodiment may be useful for apps with version information, where the version information should be subject to certain rules, but the code and data of the app should not be subject to the rules. For example, the version information for an app may include a version number, or a major and minor version number, and perhaps also a date. Each of these pieces of information may be relevant for a security mechanism, and each may be subject to different rules.

The rules used should implement the security policy for the system. For example, one rule for the update of an app might be that a version number must monotonically increase. If an app has a single version number, then the version number of an update must be higher than the version number of the app which it is to update. It may also be a policy to allow apps to be updated with an app that has the same version number, for example if features or information have been added to the app which are not related to security. For example, in the case of a change of language, it may be desired to exchange an app in one language for the equivalent app in a different language, without any change in vulnerabilities. In this case, the rules must be adapted to recognize and implement the desired security policy.

If the app has a major and a minor revision number, the rules may specify, for example, that the major revision number of an update app must be greater than or equal to the major revision number of the current app, and the minor revision number of an update app must be greater than or equal to the minor revision number of the current app. In an embodiment, the minor revision number might be disregarded if the major revision number of the update app is greater than the current major revision number. The rules might also depend on the date. For example, if the update app has a date which is more than a year older than the date of the current app, then it might not be accepted, or only be accepted if the major revision number is greater than the current revision number. Effectively there is little limitation on what policies might be desired for installing or updating apps, and thus the instant invention allows flexibility in the corresponding rules.

Attacks on known systems are sometimes made possible by changing the secure boot process. In certain embodiments the instant invention offers protection against such attacks. The state transitions in embodiments of the inventive concept can be triggered by an internal or external au- thentication. In one embodiment of the inventive concept, the states protected may indicate different security levels and privileges. In one embodiment, only those state transitions which the rules allow are performed. The corresponding rules may be coded or otherwise implemented in the memory controller 110. One form of attack leverages the limitations of OTP memory in state-of-the art implementations. Several counters and state machines may be grouped together and secured by a few bits of OTP counters in regular intervals (for example according to US 2014/0331064). This results in security leaks, because not all intermediate states of all counters can be captured or protected. An at- tacker, who has information on the specific implementation, can identify security leaks in the groupings and choose the right timing for attacks in which counters are not protected by a "fused" OTP value.

The inventive concept may hinder such an attack, because it is not bound to OTP and in an era- bodiment, given the large amount of non-volatile memory available, each and every counter can be handled separately. In embodiments of this invention a securely configurable logic to access the memory can be used, with its attendant advantages. The version information can be used to insure that only safer versions of an app can be installed. One embodiment of the inventive concept is shown as a SoC layout 201 in Figure 2. This example uses a layout with a Bus Monitor 212, a Processor Analysis Module 213 and an additional communication infrastructure 251 in conjunction with a Processor 250 and Memory Controller 21 1. However, the invention can be implemented in any kind of system and is not dependent on this layout.

The extended bus controller comprising Bus Monitor 212, and Processor Analysis Module 213 allows an interception of the communication between the processor 250 and the non-volatile memory via the Memory Controller 21 1. In this implementation the Bus Monitor, Processor Analysis Module and Memory Controller interact to realize the inventive concept. The intercept- ed communication is propagated via a second bus 231 , which ensures additional security of the commands reading and storing data in the memory. In an embodiment, a separate bus 231 may connect the processor 250 to the memory controller 21 1. In an embodiment, the separate bus is used only for reading, or only for writing, or only for certain access to the memory. In an embodiment, the separate bus is used to access the defined portion 122 of the memory only for reading, or only for writing, or only for certain access to the memory. In an embodiment the separate bus is used only for access to the defined portion 122 of the memory, or is the exclusive bus for access to the defined portion 122 of the memory. For this purpose the extended memory controller 21 1 with bus controllers 212, 213 is aware of the regions or defined portions in the non-volatile memory representing state machines or mono- tonic counters. In one embodiment, the bus controller implements monotonic counters with the following rule for a defined portion of memory or section OxXX where counters are to be stored: The value x, which has to be written, must be higher than the value currently stored y:

Is the write access to OxXX?

If yes, read y from OxXX

Is y < x

If yes, write x, if not return write error

The section OxXX may hold version information for apps, and y may be a version number for a current app. A new app to replace the current app may have the version number x. In this example the version number will be updated and the new app will replace the current app according to the rule y < x, i.e. the new app has a higher version number that the current app. In this example the higher version number means that the app is newer. The Memory Controller 110 would receive the request to write the new version number x to the section OxXX from the Processor 150. It would then read the current version number y in section OxXX and apply the rule for this location by comparing x and y.

In another embodiment the apps may have version information which consists of a major and a minor version number. This may be expressed as V.w, where V is the major version and w is the minor version. The rule may be that a newer app must have a higher major version, or failing that a higher minor version. Thus version 2.1 is newer than 1.4, and 1.4 is newer than 1.3. If the CPU or Processor 150 requests to write the new version information to the defined portion 122 of memory, the Memory Controller 1 10 checks if the major version number is higher, and if not, then checks if the minor version number is higher. The Memory Controller may do this by first reading the major and minor version numbers from their respective locations in the defined portion 122 of memory. If the current app has version 1.3, and the CPU wishes to write version 2.1 , then the Memory Controller will allow the write because the major version V indicates a newer version. If the CPU wishes to write version 1.4, then the Memory Controller will allow the write because even though the major version V is the same, the minor version w indicates a newer version. If the CPU wishes to write version 1.2, then the Memory Controller will not allow the write, because the major and minor version both indicate that the version information is not that of a newer app.

For State Machines in one embodiment the bus controller A implements the following rule for a memory section OxXX and uses a write-only transformation table in memory section OxYY, such that the value x, which has to be written, must follow the transformation table : Is the write access to OxXX?

If yes, ready table y from OxYY

Is x a value representing either A, B, C, D

If no, error, if yes, read from OxXX the current value y (either A, B, C or D)

Check if a transformation from x to y is allowed according the table

If yes, write x , if not return write error

One possible implementation of the transformation table in the State Machines of the bus controller A:

Transformation possible if 1 , in case of 0 no transformation is allowed

A B C D

A X 0 1 1

B 0 X 1 1

C 1 0 X 1

D 0 0 1 X

Complex Access rules

It is contemplated by the invention to allow almost unlimited possibilities for rules that determine the access. In particular, the rules may be based on the content of multiple different locations and the relationships between different locations, as with the embodiment described above. The rules may also be applied differently for different forms of access. For example, there may be different rules for a read access than for a write access, or for an erase access, or for a preload access to store a predefined value at one or more locations. There may be rules to define erase access, whereby the value in one or more locations is deleted and replaced by a known value or a set of possible known values. In so-called Flash NVM memory, the erase access may operate on a block of values. The erase access may erase all locations in a row or a column of the memory. What follows are descriptions of different embodiments corresponding to different rules. One embodiment may be wherein the rules define dependencies on different locations in the defined portion of the memory (122). One embodiment may be wherein the rules define dependencies on multiple locations in the defined portion of the memory (122). One embodiment may be wherein the rules define that only if the value in a first location is greater than the value in a second loca- tion can a third location be accessed. One embodiment may be wherein only an access to write a location is subject to the rules. One embodiment may be wherein only an access to read a location is subject to the rules. One embodiment may be wherein all access to a location is subject to the rules. One embodiment may be wherein access which modifies multiple locations is subject to the rules. One embodiment may be wherein access includes erasing one or more memory loca- tions. Other embodiments with complex access rules may also easily be achieved.

Improvements and other embodiments

A further improvement of the SoC is shown in Figure 3. This improvement is intended as a compliment to the above inventive concept; however it is not necessarily tied to the above concept and can also be implemented as a stand-alone improvement. The implementation proposal for this invention is based on the SoC layout 301 with processor 350. This embodiment features an external NVM, which is accessed over a Peripheral Interconnect. External NVM 320 is accessed via the Peripheral Interconnect 330, which is coupled to Bus Monitor 312 for observation of access to NVM 320, and Bus Arbiter 313, which intervenes in access to the NVM as appropriate. The functionality of the Memory Controller 31 1 may be fully integrated into the Bus Monitor 312 and the Bus Arbiter 313 and is substantially identical to the embodiment shown in Fig. 2. Another embodiment, this time with internal Non-Volatile Memory, is shown in Figure 4. This embodiment uses a SoC layout with a Bus Monitor 412 and a Bus Arbiter 413 in conjunction with a Processor or Multi-Processor System 450 and interconnect 433. Interconnect 432 is cou- pled to Bus Monitor 412 for observation of access to NVM 420, while Bus Arbiter 413 intervenes in access to NVM 420 as appropriate. The functionality of the Memory Controller 41 1 may be fully integrated into the Bus Monitor 412 and the Bus Arbiter 413. The Bus Arbiter may observe access to different memory locations in the NVM, and may watch for access to locations which are to be treated differently from other locations according to predefined rules. In one embodiment, the Bus Arbiter may watch for access to target locations, or access to a defined range of locations. The Bus Arbiter may become active when it detects an access to one of these locations, and may apply its predefined rules. These rules may apply to writing to defined memory locations, such that a write to a target location may not be allowed according to the rules. The Bus Arbiter may block the write access in order to enforce the rules. In another embodiment the Bus Arbiter may block read access to defined locations, also in order to enforce the rules. The Bus Arbiter may need to access defined locations in the NVM for its own purposes, in order to determine whether the rules allow a defined access. For example, the Bus Arbiter may read an NVM location in order to determine if the rules allow a write of a defined value to that same location.

Figure 5 shows reconfiguration during secure boot. In one embodiment, a re-configuration of the rules for monotonic counters and the access rules for the protected memory can be performed by an authorized process. In an embodiment the protected memory is an NVM or a defined portion of the NVM. Such re-configuration may be performed by an update of the secure second bootloader. This second bootloader programs the bus logic according to the needs of the whole system in a secure manner before the rich Operating System (RichOS or rOS) is booted. In addition this boot code may be authorized with a digital signature by a device-external entity, The digital signature may be verified by a hardcoded, often called "ROMized", first bootloader. As a result of the signature check, only the external entity owning the correct signature key may be able to modify the secure boot and hereby the behavior of rules concerning monotonic counters or state machines in the memory. The first bootloader thus defines a "root of trust". The first bootloader may be a form of hardware DRM or a hardware-based restriction on content. This may be called Verified Boot or Trusted Boot or Secure Boot. In UEFI systems (Unified Extensible Firmware Interface) this may be called Secure Boot, and may define a Platform Key (PK) which can be used to verify drivers and loaders. In this way the first bootloader may provide integrity protection for the subsequent steps.

In the embodiment of Figure 5, the steps of reconfiguration 501 are shown. After reset 510, the system executes a 1 st level bootloader 520. This first bootloader 520 may have the task of insuring that no malicious or unauthorized software may run during the boot sequence. The first boot- loader may verify that other bootloader code has an authorized signature before running it. The first bootloader may check that other bootloader code is signed by a public key from a known Certificate Authority. In an embodiment, once the first bootloader has completed, it proceeds with starting the next level bootloader 530.

The next level bootloader, shown in the embodiment of Figure 5 as 2nd level bootloader 540, may do the actual configuration of the rules for the memory. Other embodiments may use other means to protect the configuration of the rules. For example, other embodiments may use signatures, or cryptography, or read-only memory or other storage. The bootloader in embodiments may configure the memory controller 1 10, or the combination of bus monitor, bus arbiter, memory controller 21 1 , 212, 213 , or the elements of 31 1 as appropriate, or the bus arbiter 413. In embodiments where the rules are configurable, the rules for access to defined portions of the memory may stay defined and fixed after the second bootloader 540 has defined the rules, or there may be further possibilities to modify the rules.

In embodiments where the rules are defined by the second bootloader, a signature check during the first bootloader may be the only mechanism to insure the integrity of the predefined rules, or there may be other mechanisms used. In the embodiment of Figure 5, following the second bootloader 540, other software may be started as 550. This may be one or more further bootloaders 561 , 562, 563. Or this may be a Rich OS (Operating System) or a real-time OS or other OS. This may be one or multiple software sets. In one embodiment of the invention, system (101) comprises a non-volatile memory (120) and a memory controller (1 10), wherein a defined portion of the memory (122) may only be accessed according to predefined rules, wherein the rules are enforced by the memory controller (1 10), and the rules include a data dependency on the data which is in the defined portion of the memory (122).

In one embodiment of the invention, a method of operating a computing system (101) comprising a non-volatile memory (120) and a memory controller (1 10), wherein a defined portion of the memory (122) is only accessed according to predefined rules, and wherein the rules are enforced by the memory controller (1 10), consists in that the rules include a data dependency on the data which is in the defined portion of the memory.

In the above description of the invention the words read, write, and access are used to describe different ways of using a memory, and all ways of using a memory are contemplated by this invention. Additionally, the Memory Controller may be a single unit, or it may be a combination of functional units or aspects of functional units which collectively serve to enforce the access rules for accessing the memory. With respect to the use of substantially any plural and/or singular terms herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. The various singular/plural permutations may be expressly set forth herein for sake of clarity. The present invention is not limited to the embodiments taken as examples above. Variations and modifications may be effected by a person of ordinary skill in the art, and other embodiments of the present invention may be easily envisioned without departing from the scope of this invention, as defined in the claims.