Improved computing device

Abstract

A capability-based data processing architecture (100) with an integrated attestation module (120) and subroutines for: protecting and attesting to the boot phase of a replicated subsystem or an unreplicated subsystem (150) of a computing unit (130, 140) in the architecture; adding and removing computing units (140) from the boot system 150; re-signing authentication tokens when the boot subsystem (150) includes a computing unit; sealing and unsealing memory storing data structures processed by other subroutines described herein; and recovering a boot subsystem (150) plagued by a failure.

Description

Technical Field

[0001] The present invention relates to a secure computing architecture and a data processing method for improving the secure startup of such an architecture. Background Art

[0002] The same computer or computing resource can execute different software, or in the case of a device, firmware that implements different functionality over time. For example, a user may process an example banking application including a computing resource on a core during an online transaction, but later reuse the same core to process a computer game. The importance of software depends on the functionality it provides and the context in which it is used. Therefore, it is desirable to know which software is processed by the computing resource at a given point in time. Referring again to the banking application example, the user would want to reveal sensitive financial data and / or personal data if and only if the banking application is being processed, and would not reveal sensitive financial data and / or personal data later when the computer game has taken over the core. Various techniques have been developed to authenticate software running on a system. However, these techniques are limited to fixed and unchangeable trust roots, and when it comes to isolating different software components, they assume that the entire data processing platform is correct.

[0003] A system based on hardware capabilities is a solution that can solve this problem by isolating individual computing resources even in the presence of a limited set of hardware failures. A "capability" is a token used to grant or constrain access to computing resources in a computing system, which implements capability-based security. The capability includes at least a pointer and a set of permissions. A pointer includes a value pointing to an object, and the permissions associated with the pointer control the application's access to the object. A capability can also include an authentication token that encodes the intended software component or firmware component corresponding to the resource pointed to by the pointer, where such capabilities are called tagged capabilities. A capability with an authentication token grants access to an application only if the authentication token in the capability matches the resource provider at the computing resource pointed to by the capability (i.e., the resource holding the object pointed to by the capability).

[0004] In a capability-based system, possessing a capability with sufficient permissions is both necessary and sufficient to access the resource to which the capability refers. A capability c = (ptr, perm, l, auth) is an unforgeable token consisting of a pointer ptr to a resource r, a set of access permissions R, and optionally a label l and an authentication token auth. The owner of the capability can perform an operation op on the referenced resource r as long as perm contains the access permissions that authorize op. For example, in order to modify the physical memory area referenced by capability c, the set c.perm of the capability must contain the corresponding write permission, e.g., expressed as w∈c.perm. The label l is an application-supplied value that is stored in the capability and passed to the resource as an additional parameter when the capability is called to perform the operation. The authentication token authorizes access only if the digital representation of the resource providing subsystem matches auth.

[0005] In a capability-based platform, where the platform facilitates multiple feature-rich operating systems ("OS"), but where such OSes are complex and therefore potentially error-prone and vulnerable, an environment where trustworthiness is improved is called a secure zone. With such a platform, traditionally, when the platform boots up, the management OS is turned on first and is responsible for turning on and managing all secure zones, applications, and other resources that isolate the rich OS. That is, the platform boots up in an untrusted manner and then trust must be established in the secure zone and the code executed therein.

[0006] In order for remote users of such a platform to trust the integrity and security of applications running in a secure zone, the platform must provide a means for applications to prove that they are running in a secure setting. Since the management OS is first turned on at boot time, this assurance must be established as part of the later startup of the secure zone. The latest techniques for authenticating secure boot of secure zones are provided by In The protocol is implemented in a Trusted Platform Module ("TPM") in a secure zone provided by the The secure zone, that is, can only successfully process Intel-signed code and can extend this boot assurance by measuring the application to be launched. Thus, the boot secure zone provides evidence of the authenticated boot process through the TPM signing a message that contains the identity of the boot code (e.g., a hash) and a random number provided by a remote user to prevent replay attacks.

[0007] However, a fundamental limitation of these platforms and solutions is the inherent assumption that the block hardware is always correct: the correctness of any form of attested boot depends on the correctness of its root of trust anchored in the boot module. In the example case of a delayed start subsystem, this approach means attesting the correctness of the cryptographic algorithm used to attest the boot, or alternatively, attesting the correctness of the key generation algorithm used to equip the subsystem with key material with which it can report self-booting. Any compromise of the attestation module, any leakage of the embedded key material and / or vulnerabilities in the built-in cryptography poses the risk that an adversary will be able to spoof the boot certificate, thereby undermining the security of the platform. Therefore, the increasing complexity of hardware building blocks invalidates the scope of the inherent assumption that the block hardware is always correct, especially when known TPM solutions offer little updatability of the root of trust and when TPM complexity hinders large-scale integration and replication. These shortcomings are particularly prominent in the context of systems designed to last for decades.

[0008] The above considerations are compounded by the fact that faults often occur in system components, which may either crash silently or exhibit arbitrary (i.e., "Byzantine") behavior that other components may interpret as input. Byzantine fault-tolerant ("BFT") protocols, such as those developed by M. Castro and B. Liskov ("Practical byzantine faulttolerance" in 3rd Symposium on Operating Systems Design and Implementation, New Orleans, USA: ACM, February 1999) and GS Veronese et al. ("Efficient byzantine fault-tolerance" IEEE Trans. Comput., Vol. 62, No. 1, pp. 16-30, January 2013), provide tolerance mechanisms for this behavior, thereby preventing most responses from being interpreted as valid replies. These fault-tolerance mechanisms rely on the presence of replicated components, where the BFT protocol ensures that a majority of at least f+1 replicas eventually reach agreement on a pending request and the response to that request, when f is a configurable number of simultaneous failures or component compromises that the system should tolerate. To this end, the BFT protocol requires n=3f+1 replicas or n=2f+1 replicas, respectively, in the presence or absence of trusted-trusted components that prevent certain faulty behaviors. For example, the Trusted-Trusted Universal Sequence and Identity Generator ("USIG") in MinBFT allows replicas to verify messages that are sequentially continuous and monotonic: the USIG signs and returns a hash of the message and a cryptographically protected counter value that is incremented for each message.

[0009] Thus, most known security solutions depend on the correctness of the processor core that executes the operating system and the enclave code to deliver the desired security guarantees. However, the boot process of these systems (especially the methods that prove to create more trusted subsystems) reports all information about the platform and therefore cannot distinguish trust at the level of individual blocks. Therefore, faulty blocks are reported with the same assurance level as correct or hardened blocks, and the software cannot prove to its users that a suspected block has been relocated to another set of blocks after being faulty.

[0010] Therefore, an alternative solution is needed to secure the platform's boot-up phase and prove the security of the boot-up to alleviate at least some of the above-mentioned disadvantages. Summary of the invention

[0011] According to the present invention, a module, an architecture including the module, and a data processing method are provided, which collectively improve existing authentication startup technology in the following ways: providing hardware and methods for the startup of an authentication system or the late startup of a subsystem, so that the root of trust may change over time; developing startup methods for capability and tagged capability systems based on less trusted systems and using more trusted subsystems with the same capabilities; and extending corresponding methods to start replicated subsystems so that the system immediately benefits from the degree of replication of the subsystem and can reach consensus even if a limited number of copies fail or are damaged.

[0012] Therefore, according to a first aspect of the present invention, a module in a capability-based computing and / or data processing architecture is provided, comprising a storage device for storing a plurality of data structures and a first instruction set, wherein the first data structure comprises a first data sequence representing a startup subsystem, the subsystem comprising at least three computing units in the architecture, each computing unit comprising at least one computing resource; the second data structure comprises at least one capability set delivered to the subsystem to be started; and the third data structure comprises a second data sequence representing the configuration of the subsystem to be started and a startup instruction set. The module also comprises a computing device, which is configured by the first instruction set to calculate the first data sequence based on the stored second data sequence, the stored startup instruction set and the stored capability set; reset and suspend each computing unit of the subsystem; copy the stored capability set, the second data sequence and the stored startup instruction set to the memory resource of the suspended computing unit; change the identifier of the suspended computing unit to the calculated first data sequence, and then allow the suspended computing unit to resume startup. The module also comprises an interface device, which is used to operably interface with a module for data communication with the computing unit of the architecture.

[0013] In one embodiment of the module, the storage device may also store a data structure representing the current configuration of the core included in the startup subsystem. In a variation of this embodiment, the storage device may also store a data structure representing the configuration history of the core previously included in the startup subsystem. In another variation of any of these embodiments, the storage device may also include a non-volatile memory for storing one or more calculated first data sequences and capability sets of one or more previously started subsystems, respectively.

[0014] In one embodiment of the module, the storage device may also store at least one random value delivered to the module via a quote-requesting system to prevent replay, and data representing secure boot evidence calculated for the at least one random value.

[0015] In one embodiment of the module, the architecture may further include authentication tokens, and wherein at least one authentication token is set to a first data sequence. In a variation of this embodiment, the initial set of at least one capability may be divided into a number of subsets, each subset having a respective identifier (i) for identifying a respective replica of each computing unit in the subsystem, whereby the modules and computing units of the subsystem are replicated in the architecture. In a variation of this further embodiment, the architecture may further include at least one voter module, and wherein voting is performed on the operation of the or each replica of the initiating subsystem by directing an operation proposal of the first module replica to the or each remaining module replica.

[0016] In one embodiment of the module, the module may also include a tamper-proof protected storage area for storing data and a reconfigurable logic for updating the module. In a variation of this embodiment, the protected storage area may include a first non-volatile memory that stores multiple cryptographic keys for verifying and decrypting updates of the first instruction set; and a second non-volatile memory that stores multiple cryptographic keys for updating, certifying, and starting the certification module. In a variation of this other embodiment, the first non-volatile memory may also store a first circuit area corresponding to an update circuit for the reconfigurable logic, and the second non-volatile memory may also store a second circuit area corresponding to a definition of the reconfigurable logic, wherein the second circuit area may be exchanged with the first circuit area. In these embodiments, the reconfigurable logic may advantageously include one or more of the following: a lookup table, a router, and other FPGA building blocks, and a portion of a computing module.

[0017] According to another aspect of the present invention, there is also provided a capability-based computing and / or data processing architecture, which includes at least one subsystem to be started, the subsystem or each subsystem includes at least three computing units, each computing unit includes at least one computing resource, wherein at least one computing unit in the subsystem or each subsystem includes an embodiment of the above module, and wherein the architecture includes an on-chip network and is provided on a chip, and / or includes an integrated chip (IC) or a microprocessor. Such an architecture can preferably be embodied in a multi-core or many-core data processing device.

[0018] According to another aspect of the present invention, a capability-based computing and / or data processing architecture is also provided, comprising at least one subsystem to be started, the subsystem or each subsystem comprising at least three computing units, each computing unit comprising at least one computing resource; wherein at least one computing unit in the subsystem or each subsystem comprises a module operably interfaced with other computing units of the subsystem; wherein the module comprises a storage resource for storing a first instruction set and a plurality of data structures, the plurality of data structures comprising a first data structure comprising a first data sequence representing a started subsystem; a second data structure comprising at least one capability set passed to the subsystem to be started; and a third data structure comprising a second data sequence and a startup instruction set, the second data sequence representing a configuration of the subsystem to be started; wherein the module also comprises a computing resource, the computing resource being configured through the first instruction set to calculate the first data sequence based on the stored second data sequence, the stored startup instruction set and the stored capability set; resetting and pausing each computing unit of the subsystem; copying the stored capability set, the second data sequence and the stored startup instruction set to the memory resource of the paused computing unit; changing the identifier of the paused computing unit to the calculated first data sequence, and then allowing the paused computing unit to resume startup. Various embodiments of the architecture may include embodiments of the modules substantially as described above, thus inheriting their respective advantages.

[0019] Various embodiments of the architecture presented and described herein may be usefully embodied in a multi-core or many-core data processing device.

[0020] According to another aspect of the present invention, there is also provided a data processing method for starting a subsystem, the subsystem comprising at least three computing units in a capability-based computing and / or data processing architecture, each computing unit comprising at least one computing resource, at least one computing unit in the subsystem comprising a module operably interfaced with other computing units of the subsystem, the method comprising the following steps performed at the module: storing a first instruction set; storing a first data structure comprising a first data sequence representing the starting subsystem; storing a second data structure comprising at least one capability set passed to the subsystem to be started; storing a third data structure comprising a second data sequence and a startup instruction set, the second data sequence representing the configuration of the subsystem to be started; calculating a first data sequence based on the stored second data sequence, the stored startup instruction set and the stored capability set; resetting and pausing each computing unit of the subsystem; copying the stored capability set, the second data sequence and the stored startup instruction set to the memory resources of the paused computing unit; changing the identifier of the paused computing unit to the calculated first data sequence; and allowing the paused computing unit to resume startup.

[0021] An embodiment of the method may include the further steps of storing a fourth data structure representing a current configuration of a core included in the boot subsystem; storing a fifth data structure comprising at least one random value received from a quote request system to prevent replay; and generating a signature based on the at least one random value, the fourth data structure, and the calculated first data sequence, wherein the signature proves secure booting of the subsystem.

[0022] An embodiment of the method may include the further steps of: storing a data segment for processing by the startup instruction set; including a computing unit copy identifier in the data segment; calculating a third data sequence based on the calculated first data sequence and the stored identifier; wherein the step of storing the second data structure further includes: dividing the capability set into at least two subsets; wherein the step of changing the identifier of each suspended computing unit further includes: changing the identifier to the calculated third data sequence; and wherein the step of copying the stored capability set further includes: storing at least one capability subset with the corresponding computing unit copy identifier to the memory resource of each suspended computing unit.

[0023] A variation of this embodiment may include other steps: using the voter module (1110) to poll each computing unit replica of the startup subsystem (150); and reserving the step of allowing the suspended computing unit to resume startup after the computing unit replicas reach a quota of votes. A variation of this other embodiment may include other steps, namely, reserving the step of generating a signature to prove the secure startup of the subsystem when the computing unit replicas reach a quota of votes.

[0024] According to some further aspects of the present invention, there are also provided a data processing method for adding and removing computing units to a subsystem started according to any of the startup method embodiments described above, a method for re-marking each computing unit in a subsystem also started according to any of the startup method embodiments described above, a method for using copies to protect and release non-volatile memory of a module in a subsystem started according to an embodiment of the startup method, and a data processing method for using copies to restore a subsystem started according to an embodiment of the startup method.

[0025] Other aspects of the present invention also provide a computer-readable storage medium for storing computer-readable instructions, and a computer program or computer program product including software code, wherein the computer-readable instructions are suitable for implementing and the software code is suitable for executing the steps of the method described in this document and described in the attached claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0027] Figure 1 is an example of a data processing architecture including a plurality of blocks, a plurality of proof modules, and an example subsystem according to one embodiment of the present invention;

[0028] Figure 2 is a set of at least one proof module and a subset of blocks Figure 1 subsystem;

[0029] Figure 3 yes Figure 1 and Figure 2 Details of the interconnection of the blocks in;

[0030] Figure 4 It includes ultra-high protection area and non-volatile memory Figure 1 and Figure 2 An embodiment of a proof module;

[0031] Figure 5 yes Figure 4 Details of the ultra-high protection area;

[0032] Figure 6 yes Figure 4 An example of a data structure stored in a non-volatile memory;

[0033] Figure 7 is manifested in Figures 1 to 6 The data processing method of the corresponding logical blocks processed in the architecture.

[0034] Fig. 8A It is used for processing Figures 1 to 6The authentication of the subsystem in Figure 7 The sequence of the first part of the data processing method cited in;

[0035] Figure 8B Yes means Fig. 8A The sequence of the second part of the method shown;

[0036] Fig. 9 yes Figure 7 Examples of competency derivation structures and various competency types used in the data processing methods cited in the paper;

[0037] Fig.10 It is used to prove the safety of startup Fig. 8A and Figure 8B The sequence of subroutines of the method shown;

[0038] Fig.11 is an example configuration for a replication subsystem that votes on actions to be performed by a collection of Proof-of-Replication modules;

[0039] Fig.12 It is used for processing Figures 1 to 6 and Fig.11 The authentication of the subsystem shown is started Figure 7 The sequence of alternative data processing methods cited in;

[0040] Fig.13A It is used to add blocks to Figures 1 to 6 of the subsystem Figure 7 a sequence of the first subroutine of the data processing method cited in;

[0041] Fig. 13B It is used to remove blocks from the subsystem. Fig.13A a sequence of a second subroutine of a method;

[0042] Fig.14 It is used for re-marking Figures 1 to 6 of the subsystem Figure 7 The sequence of data processing methods cited in;

[0043] Fig.15A It is used for sealing Figure 4 and Figure 6 Non-volatile memory Figure 7 a sequence of the first subroutine of the data processing method cited in;

[0044] Fig. 15B It means it is used for opening Figure 4 and Figure 6 Non-volatile memory Fig.15A a sequence of a second subroutine of a method;

[0045] Fig.16 It is used to recover from failure Figures 1 to 6 of the subsystem Figure 7 The sequence of the data processing method cited in the data processing method includes the following steps: generating an update BLOB and executing an update process;

[0046] Fig.17 It is used to generate and update BLOB Fig.16 a sequence of subroutines of the method shown; and

[0047] Fig.18 It is used to perform the update process Fig.16 The sequence of subroutines of the method is shown. DETAILED DESCRIPTION

[0048] In particular, the present invention relates to securely launching a capability-based platform and / or its subsystems, proving the security characteristics of the launch, and then maintaining the security of the launched platform and / or its subsystems. In the above, the combination of resources and permissions is referred to as an object referenced by a capability, where capabilities have a certain type to mean that they point to objects of similar kinds. However, unlike the techniques observed in the prior art, the present invention considers platforms that do not depend on the correctness of a single processor core, and assumes hardware capability units to isolate cores, for example, as described in the applicant's co-pending international patent application PCT / EP2018 / 053203.

[0049] Described herein is a device referred to as an attestation module, a block-based data processing architecture, and a data processing method that supports differentiated trust in blocks by attesting to isolation and boot processes, by supporting relocation by adding and removing blocks to a boot subsystem, and by allowing the ability to re-label blocks equipped with authentication tokens in a replication subsystem. The scope of applicability of the methods described herein extends to a replication architecture that is susceptible to allowing a limited number of attestation module replicas to be compromised without sacrificing platform security. Also described are methods by which attestation module replicas in an architecture booted according to the present invention can be updated after they have been compromised for repairing these boot modules.

[0050] Now, refer to Figures 1 to 3 , the apparatus, architecture, and principles herein contemplate the creation of one or more subsystems 150 and their co-location with other subsystems and a management operating system (OS) in the same tiled multi-core or many-core platform, where each subsystem 150 spans a certain number of blocks 120, 140, and optionally 130 of the multi-core or many-core platform 100, and where key components of the subsystem 150 execute on a subset of these blocks.

[0051] Blocks 120, 130, 140 are any combination of compute resources and memory resources located at the same logical location in an on-chip interconnect of a network-on-chip ("NoC") 300 and sharing a common network interface, with hardware capability units 310 located at the block-to-NoC interconnect.

[0052] Among the blocks, the computing blocks include any combination of conventional general-purpose processor cores, special types of accelerators (including graphics processing units, caches, tightly coupled memories, and interfaces required for accessing memory-mapped IO devices (MMIO)). Applications and management OS are processed by computing blocks, and in the architecture proposed in this article, the threads of applications or management OS must call capabilities located in the hardware capability unit 310 on the blocks they execute in order to access resources of other blocks. Memory blocks are inactive because they do not process threads that call capabilities. Such blocks include on-chip memories, logic associated with these memories (e.g., for calculating error correction codes ECC), interfaces to access off-chip storage devices, and any combination of MMIO interfaces. Applications on computing blocks use the storage of memory blocks as additional computing block external resources, and these applications can access the additional computing block external resources by calling capabilities.

[0053] In this context, subsystem 150 preferably includes at least three blocks, for example, including a single core with local instruction and data caches, connected to off-chip memory and other resources, whose interfaces are also organized as blocks. Examples of interconnect networks include buses such as Crossbar switch, or network on chip.

[0054] The connection size can range from two to eight blocks in a multi-core system to thousands of blocks in a many-core system. 1-N , 140 1-N and optionally 130 1-N can be located on a single chip 1101; Figure 1 As specifically shown, the plurality of chips 110 in the chip stack 100 are 1-N ; or form blocks in a 3D system design. Therefore, each block 120, 130, 140 can include various types of memory, cache, core, accelerator, FPGA unit, and other logic and storage circuits. Each block 120, 130, 140 is equipped with a capability unit 310, and the capability unit 310 forms a unique connection with the NoC 300 and indirectly forms connections with resources in other blocks. Special blocks can also form input-output connections with on-chip resources or off-chip resources that are not directly connected to the NoC 300.

[0055] The data processing architecture 150 structured as a subsystem includes a block 120N , 140 1-N and optionally 130 1-N A subset 150 of the blocks in the subset 150 is provided to enable rich OS features and functionality, and to demonstrate secure booting of software or firmware on the blocks in the subset 150. Figure 2 Such a subset 150 is illustrated as consisting of adjacent blocks so as not to unnecessarily obscure the present description, but a person skilled in the art will appreciate that the subset may also or alternatively include non-adjacent blocks. Further, as described below, the subset is illustrated as including at least one attestation module 120 for secure booting of the attestation subsystem 150. N , but for scalability purposes, several proof modules 120 may be included in the same subsystem 150 1-N .

[0056] In particular, an embodiment of the data processing architecture of the present invention considers a version of such a hardened multi-core or many-core system with enhanced resilience, which replicates each proof module 120 several times: for a fault tolerance threshold f AM , the required number of copies n AM Depends on the voting algorithm used, for example, for MinBFT, n AM =2f AM +1. refer to Fig.11 , an example of which is illustrated and described. The skilled reader will appreciate that the voting algorithm and the number of replicas are parameters of the proof module that need to be fixed when designing the architecture, however, these parameters can be defined and updated as part of the architecture recovery method described herein. Embodiments of the data processing architecture of the present invention also contemplate using a trusted kernel with more privileges than the management OS and various subsystems for critical operations, such as, as described below, forcing a block to be revoked from a subsystem, where such a kernel should be in a state with<master0,ID> The capability is executed on a specially hardened core 130 enabled by a proof module 120 that grants, among other permissions, the authority to forcibly revoke blocks from a subsystem.

[0057] Therefore, in Figures 1 to 3 In the tiled architecture shown, the attestation module 120 of the present invention combines blocks 120, 140 and optionally a subset of hardened blocks 130 into a subsystem 150 and attests to the secure boot of the subsystem 150. Thus, compared to the security zones of the prior art, the subsystem 150 can be more trusted than the management OS. However, unlike the security zones where the attributes remain unchanged with respect to confidentiality and integrity properties, the functionality is extended to maintain the availability of boot resources by revoking the management OS's access to blocks 120, 130, 140 under the control of the subsystem 150.

[0058] Now, refer to Figures 4 to 6, an embodiment of the proof module 120 is described in detail, wherein Figure 4 The diagram shows a complete configuration of a proof module suitable for implementing all data processing methods disclosed herein. It can be considered that a simpler embodiment includes only a subset of the module components described below, which is at least suitable for implementing the reference FIG. 8A to FIG. 8B The described proof starts the processing method.

[0059] The proof module 120 first includes a computing module 401, which is composed of a memory and logic that executes the functionality provided by the proof module 120, where examples of the logic may include a memory and a small core that can interpret instructions, a reconfigurable logic 441, and various types of accelerators or a combination of these components. However, if the reconfigurable logic 441 does not implement all the functionality provided by the proof module 120, the computing module may be optional.

[0060] Next, the proof module 120 includes several registers. The first register is a core set register 402, in which data representing the current configuration of the core belonging to the boot subsystem 150 is stored. The second register is a core set history register 403, in which data representing the history of all core set configurations, such as numerical values, are stored. The third register is an ID register 404, which is suitable for storing numerical representations of the current boot subsystem and the previous subsystem under the control of the core at least at the first instantiation of the boot process, wherein the latter is usually at the management OS. The fourth register is a random number register 405, which stores a random value passed by the quotation request system to prevent replay, wherein the proof module 120 combines the random number with the secure boot evidence to ensure the authenticity of the current state. The fifth register is a random number-ID-core set register 406, which is suitable for storing data representing the secure boot evidence of a given random number. The sixth register is an error register 407, in which errors reported by the data processing steps of the proof module 120 and the subsystem 150 are stored, such as a mismatch between the vote in the subsystem 150 and the vote copy.

[0061] Next, the attestation module 120 includes a configurable capability register 410 adapted to temporarily store capabilities for operation of the attestation module 120. In particular, the capability register temporarily stores the initial capabilities C passed to the boot subsystem 150.

[0062] Next, the attestation module 120 includes a volatile memory area 412 in which to store both the code corresponding to the first stage of the boot process of the block (hereinafter referred to as the "startup code") and the hash 150 of the subsystem in which the code should be started. This volatile memory area 412 can also be used to temporarily store updates of the attestation module 120.

[0063] Next, the attestation module 120 includes a non-volatile memory area 415, hereinafter referred to as the "AM boot memory", in which an encrypted attestation module ("AM") boot image is to be stored, which, when present, may include a description of code, data, and reconfigurable logic in the computing module 401.

[0064] Next, refer to Figure 4 and Figure 5 , the certification module 120 includes another non-volatile memory area 417, hereinafter referred to as "sealed memory" 417, which is divided into a plurality of segments 417 1-N , where each segment 417 N Stores data values ​​and a plurality of capability sets 4173 of previously launched subsystems 150. This set is accessible only if the following dual conditions are met: the ID (404) of the launched subsystem matches the stored ID 4171, and the block (402, 403) on which the subsystem 150 has been launched matches the stored core set 4172, where vacant cores are allowed to be unsealed regardless of the core on which the subsystem was launched.

[0065] Reference Figure 4 and Figure 6 The certification module 120 also includes a protection area 430, which is defined as an area of ​​the certification module, which is independent of the other components 401-417 of the module 120. N In particular, the tamper resistance of the data and logic stored in this area (used for the module recovery step) must be good enough to prevent introspection and modification through physical attacks on the chip, as well as to resist attacks from compromised attestation modules.

[0066] The components maintained in the protection area 430 include an update area 432, which includes a non-volatile memory area in which updates to be applied to the block 120 are to be stored. The update includes a new update key and key 431, which are used to authenticate and decrypt the updated AMB boot area 415; and a new circuit description 433 for the reconfigurable logic 441.

[0067] The components maintained in the protection area 430 also include a key area 435, which includes a non-volatile memory area in which keys used to update, certify and start the certification module 120 are stored; and a circuit area 436, which includes a non-volatile memory area in which the definition of the reconfigurable logic 441 is stored, wherein the latter area can be exchanged with the new circuit area 433 of the update area 412 and retains at least the definition of the update logic and the password for updating and certifying the secure boot.

[0068] The components maintained in the protection area 430 also include a reconfigurable logic area 441, which corresponds to the portion of the logic configured by the circuit area 436 responsible for verifying and performing the update. For example, the reconfigurable logic elements can include lookup tables, routers, and other FPGA building blocks. Thus, other reconfigurable logic 441 can exist as part of the computing module 401 to assist in the operation of the proof module 120. However, in contrast to the update logic, this logic is configured based on the information stored in the proof module startup memory 415.

[0069] Therefore, the proof module 120 may include the elements described above, however, this structure is provided only as a non-limiting example, and a person skilled in the art will appreciate that equivalent elements may be substituted within the disclosure without changing the basic function or operation of the device 120. Moreover, a person skilled in the art should point out that some of the data processing methods described below may be performed using a trusted platform module, a single non-replicated proof module, or a proof module 120 that does not include certain components, some of the components described above are optional.

[0070] Now, refer to Figure 7 In use, each attestation module 120 is adapted to process a plurality of data processing methods, ie logic, each data processing method being encoded and stored as a respective subroutine that cooperates with the management OS 700 to provide the attestation module 120 with respective functionality.

[0071] In this context, a first subroutine 701 defines a sequence of data processing instructions for the boot phase of a subsystem 150 of a protection block and for proving the secure boot of the subsystem. A second first subroutine 702 defines an alternative sequence of data processing instructions for the boot phase of a subsystem 150 of a protection block and for proving the secure boot of the subsystem when the boot subsystem 150 includes a replicated block. A third subroutine 703 defines a sequence of data processing instructions for adding and removing blocks 140 from the boot system 150. A fourth subroutine 704 defines a sequence of data processing instructions for re-marking an authentication token when the boot subsystem 150 includes a replicated block. A fifth subroutine 705 defines a sequence of data processing instructions for sealing and unsealing a memory storing data structures processed by other subroutines described herein. A sixth subroutine 706 defines a sequence of data processing instructions for recovering a boot subsystem 150 plagued by a fault.

[0072] The following references FIG. 8A to FIG. 18 The individual data processing steps of each subroutine 701 to 706 that includes some or all of the components 401 to 441 of the proof module 120 of the present invention are described.

[0073] First, refer to FIG. 8A to FIG. 8B , a data processing instruction sequence 701 for protecting the trusted subsystem 150 of the core subset boot phase entry block and for proving the secure boot of the subsystem starts with the following: At step 800, the management OS 700 on the platform is started to start the platform in an unauthenticated manner and through a special ID (for example, ID=0) representing the fact that the untrusted management OS is in control of the platform.

[0074] In this example, the boot process is for a capability-based system with an authentication token, where the capability is<type,ID> , where type refers to the resource, ID is the authentication token, and where the authentication token in a capability may lose its meaning and may be removed to reduce the capability to <type>.

[0075] After the management OS has started the platform, in order to start the subsystem 150 at block t (140, optionally 130), at step 801a, the management OS 700 selects the subsystem 150 that has the capability<AM,0> In an alternative embodiment where the platform is a secure boot platform based on a TPM, at step 801b, the management OS 700 selects the authentication module AM ​​(120) having the capability<AM,0> In another alternative embodiment, reference Fig. 9 , when the OS supports capability derivation, then at step 801c, the management OS<master,0> Ability to deduce ability<AM,0> .

[0076] Since the subsystems on the first block will add additional cores to eventually form a subset S of the available cores, the following description uses the set notation S = {t}.<init(t),0> Identifies block t in set S, the capability authorizes management OS 700, and in turn, attestation module 120, to reset all active components in block t (i.e., all cores, accelerators, etc.), while preserving the state of all passive (memory) components. In preparation for attestation boot, management OS 700 calls memory capability to the scratchpad memory in the boot block to copy the configuration of the system to be booted to the block. Alternatively, management OS 700 installs the configuration in a memory area external to the boot block. In this case, management OS supplies the capability to this external memory area of ​​the attestation module.

[0077] The configuration of the system to be started 150 includes a set of code (or logic description or firmware in the case of an FPGA block) for the system to be started (for the code segment, this is represented by CS), initial data for system startup (for the data segment, this is represented by DS), and an initial set of capabilities C. At step 806, the management OS 700 calculates a sufficiently explicit digital representation of the configuration, such as a key cryptographic hash, which is stored in Fig. 8A and Figure 8B It is represented by hash1.

[0078] At step 807, the management OS 700 calls the capability<AM,0> The startup code and the calculated configuration hash are installed in the volatile memory 412 of the attestation module 120: in a system with an authentication token, this is only possible if the ID 404 of the attestation module 120 matches the ID field 4171 in the capability 4173.

[0079] At step 808, the management OS 700 installs the initial set of capabilities C of the subsystem to be started 150 in the capability register 410 of the attestation module 120, and at step 809, sets the core set register 402 to the selected block S. In an alternative embodiment starting with the TPM selection at step 801b, since the TPM does not support the core set and capability registers 410, nor does it provide a startup code memory 412, the information in these components must be installed directly in its block to be started 140 (130) and then measured there, which means that when the TPM measures the information, the block is trusted to return to that state. Advantageously, the attestation module 120 of the present invention does not require such trust.

[0080] Steps 801a to 809 prepare the boot block 140 (130) and the certification module 120 for authentication boot. Next, at step 810, when the preparation is complete, the management OS 700 calls the capability<AM,0> To initiate authentication.

[0081] At step 811, the attestation module 120 copies the value of the ID register 404 to a backup version of the register, and at step 812, the attestation module 120 measures the startup code and configuration hash 412 by calculating the explicit digital representation of the measurement code and hash, hash2. At step 813, the attestation module 120 creates a digital representation hash3 of the capability set C, and at step 814, stores the combined digital representation of measurement hash2 and the digital representation of C hash3 in the ID register 404. In this example system with authentication token capabilities, the storage of step 814 changes the ID, thereby preempting the capability<AM,0> In an alternative embodiment without authentication token capability, all significant <am>The ability to reduce privileges, thereby preventing the Management OS 700 from proving itself as a security subsystem.

[0082] Next, at step 815, the certification module 120 calls the second capability<init(t),0> Then, at step 816, the attestation module 120 copies the boot code and configuration hash 412 to the memory of the first block, and at step 817, calls the special capability<init0(t),0> , only the certification module 120N is based on<init(t),0> To derive this special ability<init0(t),0> , used to change the ID of t to the value stored in the ID register 404 of the certification module 120 in the previous step 814, and resume the execution block at the start code.

[0083] In an alternative embodiment starting with TPM selection at step 801b, management OS 700 still needs to block block t, and must install capability C before starting the block. Thus, in this alternative embodiment, steps 811 to 817 need to be combined into a single step, where the TPM measures the boot code installed in block t before the block starts, and then appends the measurement result and the measurement result of capability C to the platform control register in the TPM.

[0084] Then, at step 818, the certification module 120 copies the capability C to the capability register 410 of the hardware capability unit 310 of t. Next, at step 819, the certification module 120 copies the capability C to the capability register 410 of the hardware capability unit 310 of t.<AM,ID> and ability<master,ID> Added to the capability register 410 of the hardware capability unit 310 of t. These additional capabilities respectively authorize the block to obtain the certificate to boot the system and create a new capability using the authentication token set as the ID.

[0085] Booting continues with the boot code waiting for the capabilities in C to be installed by the attestation module 120, whereby at step 820, the attestation module 120 measures the configuration and compares the measurement to the configuration hash1. Next, at step 821, a question is asked as to whether the comparison of step 820 is positive. If the answer to the question of step 821 is negative, a corresponding error report is generated and stored in the error register 407. Alternatively, the answer to the question of step 821 is positive, whereby at step 822, the attestation module 120 finally transfers control to the measured configuration.

[0086] Now, refer to Fig.10 , by receiving a random number (i.e., a random value) from client c as a quote request system, a subroutine of the first method 701 for proving a secure boot on block t 140 (130) to client c is called. Thus, the subroutine is an iterative loop that begins with a question at step 850 as to whether the subsystem 150 has received the client random number. As long as the random number has not been received, the answer to the question is negative and the loop is repeated. At step 851, when the answer to the question is positive, the subsystem 150 calls<AM,ID> , then at step 852, the random number received from c is installed in the random number register 405. At step 853, this update causes the attestation module 120 to update the random number-ID-core set register 406 to the signature of the random number 405, the core set 402, and the ID 404. Thereafter, control returns to the question of step 850.

[0087] In an alternative embodiment of subroutine 701 modified to use a replication proof module with authentication token capability, the management OS 700 installs<Init(t),0> Capability auto-transformation Capabilities added to identify all copies of the attestation module<AM,ID> and<master,X> A copy of , where these capabilities identify the copy.<master,X> The capability only authorization block 140 (130) creates a capability with ID X. Since X does not include a core set, installing the same system 150 twice without distinguishing the elements would allow one system to create the capabilities of the other system. To address this problem, the different instances are distinguished in the configuration data and in the configuration hash passed to the startup code. Since it is no longer necessary for the certification module 120 to call other than<init(t),X> or<init0(t),X> The remaining capabilities of set C are therefore stored in a degenerate capability register file that is not allowed to be called.

[0088] Therefore, the calling capability<AM,0> The replication proof module 120 1-N Trigger all proof module copies 120 1-N During the consensus start, each replica measures the startup code, configuration hash, and initial capability set C. Furthermore, when<Init(t),0> Derivation<Init0(t),0> Furthermore, if the number of proof module replicas is 120 1-N If consensus is reached, the capability units of block t only accept blocking and recovering blocks 120, 130, 140 with different IDs.

[0089] By this embodiment, the proof of the secure boot subroutine previously described with reference to steps 850 to 853 is changed in that the subsystem 150 replaces one copy reporting the signature hash of the random number, ID and core set triple 406 at step 853 from all proof module copies 120 1-N Request such proof and send a copy of the proof module from the query 120 1-N A quorum of matching proof responses are received as evidence.

[0090] In all variants of the attestation module 120, the sequence of data processing steps 801a to 822 can be integrated into the TPM and the platform can integrate them. However, the boot process is limited to starting a single block t 140 (130), where the size of the subsystem 150 is expanded thereafter. When the subsystem does not include a replicated block or includes too few active replicas to allow for the number of f that a fully booted replication system can tolerate. c This approach, while improving the security features of the boot process, still leaves a window of vulnerability during the boot process.

[0091] Now, to close the vulnerability window for most critical subsystems, refer to Fig.11 and Fig.12 , an alternative embodiment of a sequence of data processing steps is described for initiating a process capable of withstanding the f from a first instance c In this alternative embodiment, when subsystem 150 needs to tolerate up to f c There are several failed or damaged replicas 120, 130, 140, so n are needed for this purpose. c When there are 120, 130, or 140 copies, the startup method is n c The authentication is performed by simultaneously starting the proof module 120 and the key components started by the module 120. The subscript is preferably used to distinguish the number of proof module copies n. AM , the number of faults they can tolerate AM 、(in n c The number of copies of the key component n) executed on different cores c , and these n c The number of failures that can be tolerated by a replica is f c .n AM 、f AM 、n c and f c is a natural number, parameter n AM and f AM is fixed when the system is created, and n c and f c Can be dynamically selected, where n c It is limited only by the number of cores available in the multi-core or many-core platform 10 .

[0092] Fig.11 The ideal call architecture of the replicated components in subsystem 150 is illustrated, wherein, at least in the context of subroutines 702 and 706, operation proposals (such as the ability to call each block) are directed to one or more proof modules 120. 1-N , the voting module 1110 specifically includes the corresponding subsystem block 140 of the replica 1-3 Subsystem management copy 1101 1-3 When a quorum of operations is reached, the voter module 1110 forwards the request to a single attestation module 1201, or if the attestation module itself is replicated, to a copy of that module 120 2-3 .

[0093] The data processing steps of the alternative "quota" startup protocol 702 generally follow the reference Fig. 8A and Figure 8B Steps 801-822 of the first embodiment of the startup process are described, however, with the following exceptions. c As needed to start to form a can withstand f c The quorum-start protocol starts n blocks simultaneously as follows: c This startup block set can optionally be expanded to the final subsystem size or larger subsystem sizes using the subroutine 703 described below.

[0094] At step 801a, in order to nc On starting the subsystem manager 11011 has n c 1101 copies 2-N Subsystem A (150), management OS 700 again chooses to have the capability<AM,0> Alternatively, at step 801b, when the platform is a TPM-based secure boot platform, the management OS 700 may again choose to have the capability<AM,0> At step 802, through the capability<init(t),0> , identify block t in set S again.

[0095] According to steps 803 to 809, the management OS 700 prepares each block again: At step 803, the management OS 700 calls the memory capability to the temporary storage of all the blocks 140 (130) to be started, so as to copy the configuration of the system to be started to these blocks. As mentioned above, the configuration of the system to be started includes the code segment CS, the data segment DS, and the initial set of capabilities C. However, in this embodiment, at step 1201, the configuration is divided into n c subsets C1,…,C nc .

[0096] The capabilities of the critical resources owned by all capabilities require unique replica identifiers to distinguish replicas from each other during voting operations. Since the goal is to start replicas with unique IDs, but still distinguish replicas, at step 1202, an identifier i is assigned to each replica at each known location in DS, such as where block t i Identified by identifier i. Optionally, as a further precaution against booting a compromised subsystem 150, the management OS 700 is installed as part of each capability set Ci, where this allows a replica to introspect the state of all other subset management blocks.

[0097] Next, the management OS 700 calculates a sufficiently explicit digital representation of the configuration of the system to be started, for example, by once again calculating the key cryptographic hash except for the replica identifier i, and then by calling the capability<AM,0> The startup code and the calculated configuration hash are installed in the volatile memory 412 of the attestation module 120. Next, the management OS 700 installs the initial capability set C of the subsystem to be started in the capability register 410 of the attestation module 120 and sets the core set register 402 to set S.

[0098] At step 810, after preparing the boot block and the certification module, the management OS calls the capability<AM,0> To initiate an authenticated boot. According to steps 811, 812, the attestation module 120 begins by copying the value of the ID register 404 to a backup version of the register and measuring the boot code and configuration hash by calculating an explicit digital representation of the measured code and hash. According to step 813, the attestation module 120 also creates a digital representation of the capability set C and, according to step 814, stores the combined numerical representation of the measurement result and the digital representation of C in the ID register 404. In a platform system without an authentication token, it is necessary to use <am>The ability is invalid.

[0099] According to step 815, after the measurement, the certification module 120 calls<init(t),0> , however, in this embodiment, t∈S is called for all blocks. Then, according to step 816, the proof module 120 copies the startup code to the memory of these blocks, and at step 1203, appends the copy identifier i to the configuration hash, such as by computing a hash of the configuration hash and the copy identifier i. At step 1204, the proof module 120 copies the appended hash to the configuration hash location in the startup code. Then, according to step 817, the proof module 120 derives and calls<init0(t),0> , to change the ID of t to the value in the ID register 404 of the certification module 120, for resuming execution of block 140 (130) at the boot code.

[0100] At step 1205, for all blocks t in the set S i , Proof Module 120 will be Competency C i Copy to each block t i The capability register 410 of the corresponding hardware capability unit 310 and at step 1206, the certification module 120 adds the capability<AM,ID> and ability<master,ID> , both capabilities are emulated using replica identifier i.

[0101] As previously described, startup continues with the startup code waiting for the capabilities in Ci to be installed by the certification module 120, after which the certification module 120 measures its own configuration. Finally, according to step 822, the startup code relinquishes control of the code in the code segment.

[0102] In an alternative embodiment where the introspection subroutine is used, the startup code can also measure the configuration of all peer replicas through the introspection capability, and then compare the measurements with the configuration hash with the corresponding replica identifier to ultimately participate in the vote for ensuring that the quorum of replicas has been correctly started. In this example, at step 822, the startup code will only relinquish control if the replica vote is successful, i.e., no operation can be performed unless the quorum of subsystem replicas confirms the validity of the startup of its peer replica.

[0103] Now, refer to Fig.13A and Fig. 13B , describes a data processing instruction sequence 703 for adding and removing blocks, respectively, which advantageously complements either of the aforementioned secure boot subroutine and certification subroutine because it allows the boot subsystem 150 to modify its number of blocks while retaining the security features of the certified initial boot. The add / subtract subroutine can be called either immediately after the control transfer of step 822, such as as an adjunct to the quorum boot subroutine 702 for adding replicas to the subsystem 150, or at a later time during runtime (e.g., in parallel or closer to calling the recovery subroutine 706 described below).

[0104] Fig.13A The subroutine for adding one or more blocks is illustrated in FIG. 1 and begins at step 1301 where the management OS 700 derives the capability of the new block t 140 (130) to be added.<init(t),0> And pass the capability to subsystem 150. Next, at step 1302, management OS 700 calls<AM,ID> capability, whereby subsystem 150 will<init(t),0> The capabilities are passed to the certification module 120 .

[0105] To add a new block t, at step 1303, the proof module 120 performs steps similar to steps 815, 816 and 817 of the startup subroutines 701, 702, in that it blocks the new block t, updates the core set register 402 to include the new block t, while maintaining a numerical representation of the previous historical core set 403 and the current configuration (CS, DS, C), such as a hash.

[0106] Then, at step 1304, the attestation module 120 copies its identifier ID 404 to the ID register 404 (130) of the added block 140; at step 1305, the startup code is copied to the added block 140 (130); and at step 1306, execution is resumed during the waiting process, thereby allowing the code to resume from the subsystem core that is already in the active state.<init(t),0> The capability is invalid, so at step 1307, the certification module 120 will<init(t),0> Capability conversion<init(t),ID> capability, and at step 1308, providing the calling subsystem 150 to the<init(t),ID> This preserves the access rights of<init(t),ID> The permissions conveyed to the added block t.

[0107] Two primary methods may be used to remove or subtract one or more blocks 140 (130) from the boot subsystem 150 so that the management OS 700 can regain control of them: either by the subsystem 150 voluntarily releasing control of the blocks; or, in an alternative embodiment, by instructing the trusted-trusted kernel to forcibly revoke the blocks from the subsystem 150, typically with the trusted-trusted kernel agreeing to operate on them only if pre-negotiated revocation conditions are met.

[0108] Fig. 13B The subroutine for a subsystem to voluntarily remove or subtract one or more blocks is illustrated in FIG. 1 and begins at step 1310, where the subsystem calls its<init(t),ID> Capable<AM,ID> Capabilities are determined in order to remove block t (130 or 140). At step 1311, the attestation module 120 blocks block t, resets t's capability unit 310 to invalidate all capabilities possessed by t, and changes t's ID 404 to a null value of 0. At the next step 1312, the attestation module 120 removes t from the core set register 402, and then at step 1313, updates the core set history 403 by hashing the old register value 403-1 with the new core set 402 appropriately reduced by the block removal.

[0109] Preferably, the alternative method of forcibly revoking blocks from subsystem 150 is performed by a trusted-trusted component such as a trusted hypervisor, thereby compromising the availability or timeliness guarantees of the subsystem, because in the absence of this component, the management OS 700 can revoke these resources at any point in time when the subsystem 150 may still need them. Such a trusted management subsystem is preferably equipped with a special capability<master0,X> , so it can be deduced<reset(t),X> Ability to instruct the reliable proof module 120 to perform the revocation steps 1311 to 1313 as described above, however, wherein the entire state of block t is reset. As a special case,<reset(t),X> The identifier X in the capability does not need to match the ID 404 of the attestation module 120 .

[0110] As with the startup subroutines 701 and 702 that can be integrated into the TPM, the block addition and subtraction subroutines 703 can also be performed using the TPM, however, at step 1306, once the attestation module 120 adds the block, a modification is required to revoke the capability from the management OS 700<init(t)> , so step 1307 is not required in this embodiment.

[0111] Including the replication proof module 120 1-N The specific context of subroutine 702, blocks blocking and recovery operations as well as<init0,0> The identifier ID of the unit 310 can vote for reconfiguration operations that require a quorum of subsystem replicas, making it easy to prevent a small number of compromised proof module replicas 120. (1-(N-2)) Perform these key operations. In this embodiment, refer again to Fig.11 , a similar calling structure is used for these add and remove operations, where each subsystem manages a copy 1101 1-N Calling its corresponding block 130 or 140<AM,ID> The ability to propose the addition of block t to or the removal of block t from subsystem 150. After consensus is reached on the operation, voter 1110 forwards the request to a single attestation module 120, or to all replicas 120 of the module if the attestation module itself is replicated. 1-N .

[0112] Now, refer to Fig.14 , describes a data processing instruction sequence 704 for revoking all significant capabilities of subsystem 150 by requesting attestation module 120 to re-label subsystem 150, thereby advantageously supplementing any of the aforementioned secure boot and attestation subroutines in that it allows booting subsystem 150 to remediate situations in which trust in the credibility of traditional capability revocation methods cannot be maintained. The re-labeling routine can either be called immediately after the control transfer at step 822, or at a later time during runtime (e.g., in parallel with or closer to the recovery subroutine 706 described later).

[0113] The subroutine for re-labeling a subsystem 150 begins at step 1401, where the subsystem manager 1101 calls a<master,ID> of<AM,ID> Therefore, at step 1402, the proof module 120 derives the block t(130 1-N , 140 1-N ) or each block t(130 1-N , 140 1-N )of<init0(t),ID> capability, and at step 1403, the corresponding identifier ID of the block is changed to an alternative identifier ID', where ID' is a joint digital representation of the identifier ID and the relabeling that occurred, for example, in the form of hash(ID,"relabel").

[0114] Once all blocks have been re-labeled, at step 1404, the proof module 120 changes its own identifier ID 404 to the alternative identifier ID'. At step 1405, the proof module 120<master,ID’> Ability and<AM,ID’> Capability to install in all (one or more) subsystem manager blocks (130 1-N , 140 1-N Then, at step 1406, the subsystem manager block(s) may authenticate the authentication token according to<master,ID’> A new capability with an alternative identifier ID' is derived in .

[0115] Now, refer to Fig.15A and Fig. 15B , describes a data processing instruction sequence 705 for sealing and unsealing memory 417, respectively, thereby advantageously complementing the previously described quota-based secure boot and certification subroutine 702, because sealing effectively links the data to the ID of the boot subsystem 150, thereby only when the subsystem 150 has been booted, the data can be accessed. By combining secret sharing with sealed memory, this subroutine assists the copy proof module by protecting the contents of the sealed memory (for example, as part of the quotation) from leakage. The seal / unseal subroutine can be called immediately after the control transfer of step 822, or at a later time during runtime.

[0116] thus, Fig.15A The subroutine for sealing storage 417 is illustrated, which starts at step 1501 with a question as to whether the attestation module 120 of the boot subsystem 150 includes sealed storage 417. When the answer to the question at step 1501 is affirmative, since each quorum boot replica must receive only its own capabilities, at step 1502, the sealed capacity 4173 of the sealed storage 417 is partitioned by replica identifier i, wherein access to partition i of the sealed capacity 4173 is granted only to block t i A copy of i.

[0117] At step 1503, each replica 1101 of the subsystem manager 1101 1-N The protected data d is encrypted and a secure hash of the data is generated using a randomly generated key k. At step 1504, each replica 1101 1-N The encrypted data and hash are stored in external non-volatile memory. At step 1505, the subsystem manager replica 1101 1-N Select n points p respectively i Copies of modules for the formation and certification of quota 120 1-N The size of the subsystem manager 1101 matches the polynomial p of degree. The condition p must satisfy is p(0)=k. At step 1506, the subsystem manager replica 1101 1-N Perform a voting sequence to convert point p i Install to proof module copy 120 1-N The sealed memory 417 is stored in the sealed memory 417, so that each proof module copy r i Store the corresponding p i .

[0118] The unseal subroutine typically performs steps 1502-1506 in reverse order: Subsystem Manager Copy 1101 1-N 120 copies from different proof modules 1-N Retrieve n points p i , reconstruct the polynomial p, retrieve the key k, and decrypt the stored data d. However, due to the number of up to f AM Faulty replicas 120 (1-(N-3)) may delete or change the points they store i , so not all combinations of the specified points can form a valid polynomial p. Fig. 15B The illustrated embodiment of the unseal subroutine mitigates the above risks and begins at step 1511, where the subsystem copy 1101 is N Set to boot subsystem copy r i At step 1512, boot the subsystem copy r i A number n of points (whose number is a function of the quota size) are combined into a polynomial p, and at step 1513, k=p(0) is calculated.

[0119] At step 1514, boot the subsystem copy r i The data d and the hash h(d) are decrypted, and the hash of d is compared to the stored value h(d). Next, at step 1516, a question is asked as to whether the comparison returns a match. If the answer to the question at step 1516 is yes, then at step 1517, the boot replica r i Waiting for other copies 1101 (2-N) to confirm the operation as they each repeat steps 1512 through 1515, respectively. However, if the answer to the question at step 1516 is negative, control returns to step 1512, where the boot subsystem copy r i It tries different combinations of n points until it finds a combination that satisfies the match in step 1516.

[0120] In an alternative embodiment of the unsealing subroutine, a certification module 120 may be added. 1-N The quota size and number of the quota size are at least 2f AM +1 copy, where n AM At least 3f AM +1, and p remains at degree f AM +1 polynomial. Then, by choosing f AM +1 point to execute according to n AM The stored points verify the polynomial so that f AM The other points are solutions to the same polynomial. The polynomial thus verified is then used to retrieve the key k=p(0) and to encrypt the data.

[0121] In addition to using different passwords in different copies of the attestation module, the attestation module 120 used for replication 1-N The corresponding versions of subroutines 701 to 705 of the present invention prepare the startup subsystem 150 to allow up to 100% of the f AM However, under sustained attack, this threshold may be exhausted, where as f AM copies are compromised, ultimately exceeding the security features of subsystem 150.

[0122] Therefore, now, refer to Figures 16 to 18 , describes a data processing instruction sequence 706 for returning one or more boot attestation module replicas to a healthy state after a compromise, destruction of a password in use, or disclosure of any replica key. Depending on the attack timing and attack strength, the recovery subroutine may be called either immediately after the control transfer of step 822 or at a later time during runtime. Furthermore, the subroutine requires an embodiment of the attestation module 120, which includes reference Figure 4 and Figure 6 A protection chip region 430 and its various subcomponents are depicted.

[0123] The step of updating the components in the protection area 430 of the proof module 120 is performed during the voting operation 1601 (e.g., the replica voting during the quorum startup sequence 702, or installing the point pi into the sealing storage 417 during its sealing in the sequence 705) with respect to the replication proof module 120. 1-N The process begins with question 1602 of whether a replication proof module in has detected a voting mismatch. When the answer to the question is negative, control returns to the existing voting operation. However, at step 1603, when the answer to the question of step 1602 is positive, the detection module 120N generates an error report in the error register 407, and the management OS 700 can then forward the error report to the proof module developer.

[0124] The error register 407 contains a counter which is incremented by each report generated at step 1603, whereby next, a question is asked at 1604 as to whether the current counter value now exceeds a predefined threshold. The predefined threshold preferably represents a value which is related to f AM When the answer to the question in step 1604 is negative, the counter does not yet represent the damage to up to f proof module copies. AM The subroutine 706 ends with the compromise of the proof module copy.

[0125] However, at step 1605, when the answer to the question at step 1604 is affirmative, that is, when the counter exceeds the predefined threshold, the detection proof module 120 N The reconfigurable logic 441 of the 441 disables it, wherein the disabled module refuses to participate in other votes. Thus, the accumulated errors eventually lead to the platform being unavailable.

[0126] The attestation module developer is responsible for ensuring the correctness of the attestation module 120 and providing updates for it. A third party may decide not to trust the attestation module developer by downgrading the developer's device to an untrusted state. To mitigate these penalties, the developer must initiate recovery of the attestation module copy by generating the relevant updates and forwarding them as an update binary large object ("BLOB") to the management OS 700 at step 1606. Fig.17 , the subroutines involved in sequence step 1606 are further described.

[0127] First, at step 1701, questions are provided as to whether the developer has received an error report forwarded by the management OS 700 at step 1603, or alternatively, whether a compromise of a used password has been detected, or alternatively, whether a predetermined time interval has passed since the last update (due to the passage of time, the trust in protecting the factory attestation module has decreased). When the answer to the question of step 1701 is affirmative, the developer initiates recovery of the attestation module copy, first defining an update of the circuit area 436 at step 1702, which may include an update of the password used to verify the update, and wherein the update may optionally include an accelerator for the novel cryptographic algorithm used by the computing module 401.

[0128] At the next step 1703, the update of the attestation module boot memory 415 is defined, i.e., the code and data used by the computing module 401 to implement the attestation module functionality that is not implemented in the reconfigurable logic 441 in the protection compartment 430. At the next step 1704, new keys are defined for the next update, attestation module startup, the root keys for deriving the attestation keys (i.e., those keys used to create secure boot evidence in the subroutine 701), or in the case of directly embedding the attestation keys, new keys for the attestation keys and the keys for verifying the integrity of the attestation module boot memory 415. At the next step 1705, the attestation module boot memory 415 is encrypted using the attestation module startup key generated in the previous step 1704. At this stage, the update BLOB is completed, so at step 1706, it is signed and encrypted using the current update key, and then at step 1707, the developer forwards it to the management OS 700. The update key used to encrypt the update BLOB can be, for example, a one-time password.

[0129] Now, return to Fig.16 At step 1607, subroutine 706 resumes when it receives the signed and encrypted update BLOB from the developer, whereupon, at step 1608, management OS 700 calls upon detecting a copy of the certification module to be updated.<AM,0> Capability to copy the update BLOB into its startup code memory 412, and then, at step 1609, call the update process for the copy of the certification module. Fig.18 , the subroutines involved in sequence step 1609 are further described.

[0130] In this embodiment, the update process of step 1609 is implemented entirely by updating using the reconfigurable logic 441 of the proof module 120. At step 1801, the reconfigurable logic 441 first decrypts the update BLOB, and then at step 1802, uses the update password in the reconfigurable logic 441 and the update key in the key area 435 (e.g., by XOR-ing with a one-time password for decrypting data) to verify its integrity. Next, at step 1803, a question is asked about whether the integrity check has verified the update. When the answer to the question of step 1803 is affirmative, the reconfigurable logic 441 generates an error report 407, thereby ultimately prompting the new update BLOB by the developer as described above. Alternatively, the answer to the question of step 1803 is affirmative, and the update logic installs the new key at step 1704 into the key area 435 at step 1804, and installs the new encrypted proof module boot image of step 1703 into the non-volatile proof module boot memory 415 at step 1805.

[0131] Next, at step 1806, the update logic disables all portions of the detection proof module except for swapping the current circuit region 436 with the portion of region 433 in update region 432 containing the new circuit description at step 1807: region 433 storing the new circuit description becomes current circuit region 436, and the previous circuit region 436 is reused for update region 432 to accommodate the next future update. After completing the switch at step 1807, the remainder of the update logic triggers a reset of proof module 120 at step 1808, causing it to restart in the updated state. After the restart at step 1808, other proof module replicas 120 may be updated using their respective update BLOBs. (2-N) to completely replace the previous configuration.

[0132] In the context of subroutine 706, a protocol for proving the start sequence of a module copy may optionally be provided to better support recovery of the module according to steps 1601 to 1609. In addition, Fig.16 An embodiment of the protocol is illustrated where in reconfigurable logic 441 in protected area 430 , attestation module 120 should start from a logic description in protected circuit area 436 .

[0133] First, at step 1611, the logic checks the integrity of the attestation module boot memory 415, and then decrypts it into the volatile memory of the computing module 401 at step 1612. The attestation module boot image may contain code, data, and a description of the reconfigurable logic 441 in the computing module 401. The protection logic then provides the computing module 401 with the keys 435 required for its normal operation, however, there is no need to update or boot the keys 435 required. Therefore, at step 1613, the protection logic forwards the attestation key to the computing module 401, and at step 1614, forwards the root key to the computing module 401. In an alternative embodiment where the protection granted to the attestation module is increased, the protection logic may retain all the keys, and instead provide encryption functionality and decryption functionality where one or more of these keys may be selected.

[0134] Thus, the architecture and algorithms disclosed herein are intended to mitigate advanced and persistent threats, which include sophisticated attacks by highly skilled and well-equipped adversaries seeking to compromise in a variety of ways: all software layers including the hypervisor and processor core code; blocks at the hardware level (e.g., by manipulating IP blocks to install trapdoors that grant them administrator privileges to the compromised blocks); off-chip resources (e.g., a network card that grants them high-speed entry into the system to persist their attack); and the system's attestation module 120.

[0135] In general, the inventive principles described herein implement security, dependency, and fault and / or intrusion tolerance techniques. More specifically, the inventive principles described herein are applied to secure and reliable architectures and middleware that contribute to the resilience of large-scale systems and critical information infrastructures, examples of which include cloud storage, telecommunication networks, energy distribution and management, highly sensitive data storage and management systems, and embedded real-time networked systems (such as Internet of Vehicles and self-driving cars).

[0136] Embodiments in the present invention described with reference to the accompanying drawings include computer devices and / or processes executed in computer devices. However, the present invention also extends to computer programs, particularly computer programs stored on or in a carrier suitable for implementing the present invention. The program can be in the form of a code between source code, object code, or intermediate source code and object code, such as in a partially compiled form or any other form suitable for implementing the method according to the present invention. The carrier can include a storage medium such as a read-only memory ("ROM"), an optical recording medium, or a magnetic recording medium. The carrier can be an electrical signal or an optical signal, which can be transmitted via an electrical cable or an optical cable or by radio or other means.

[0137] The present invention is not limited to the above-described embodiments, but may vary in construction and details. For example, it should be readily understood by those skilled in the art that the inventive principles disclosed herein regarding hardware architecture and / or components and / or their arrangement may be permanently integrated into a standard configuration of a microprocessor through relevant manufacturing techniques.

[0138] In the specification, the terms "comprise, comprise, comprised and comprising" or any variations thereof and the terms "include, include, included and including" or any variations thereof are considered to be fully interchangeable and should all be given the broadest interpretation and vice versa.< / am> < / am> < / type>

Claims

1. A module (120) in a data processing architecture (100), comprising: A storage device for storing a plurality of data structures (404, 410, 412) and a first instruction set (415), wherein A first data structure (404) includes a first data sequence, the first data sequence representing a startup subsystem, the subsystem including at least three computing units in the architecture, each computing unit including at least one computing resource; A second data structure (410) includes at least one capability set to be delivered to the subsystem to be activated; as well as The third data structure (412) includes a second data sequence and a startup instruction set, wherein the second data sequence represents the configuration of the subsystem to be started; The computing device is configured by the first instruction set (415) to: calculating (811, 812, 813, 814) the first data sequence based on the stored second data sequence, the stored startup instruction set, and the stored capability set; selectively resetting and suspending each computing unit (130, 140) of the subsystem; copying the stored set of capabilities, the second sequence of data, and the stored set of startup instructions to memory resources of a paused computing unit; changing the identifier of the suspended computing unit to the first data sequence of the calculation, and then allowing the suspended computing unit to resume startup; as well as An interface device (310) for operatively interfacing with said module for data communication with said computing unit of said architecture.

2. A data processing architecture, comprising: at least one subsystem (150) to be started, the subsystem or each subsystem comprising at least three computing units (130, 140), each computing unit comprising at least one computing resource; wherein at least one computing unit in the or each subsystem comprises a module (120) operably interfaced with other computing units (130, 140) of the subsystem; The module (120) includes a storage resource for storing a first instruction set (415) and a plurality of data structures (404, 410, 412), wherein the plurality of data structures (404, 410, 412) include: a first data structure (404), the first data structure (404) comprising a first data sequence representing a promoter system; a second data structure (410), the second data structure (410) comprising at least one capability set to be transferred to the subsystem to be activated; and a third data structure (412), the third data structure (412) comprising a second data sequence and a startup instruction set, the second data sequence representing the configuration of the subsystem to be started; and The at least one computing resource of the module (120) is configured by a first instruction set (415) to: calculating (811, 812, 813, 814) the first data sequence based on the stored second data sequence, the stored startup instruction set, and the stored capability set; selectively resetting and suspending each computing unit (130, 140) of the subsystem; copying the stored set of capabilities, the second sequence of data, and the stored set of startup instructions to memory resources of a paused computing unit; The identifier of the suspended computing unit is changed to the first data sequence of the calculation, and then the suspended computing unit is allowed to resume startup.

3. A data processing method for starting a subsystem (150), the subsystem (150) comprising at least three computing units in a data processing architecture, each computing unit comprising at least one computing resource, at least one computing unit in the subsystem comprising a module (120) operably interfaced with other computing units (130, 140) of the subsystem, the method comprising the following steps performed at the module: storing a first instruction set (415); storing a first data structure (404), the first data structure (404) including a first data sequence representing the initiator subsystem (150); storing a second data structure (410), the second data structure (410) comprising at least one capability set to be transferred to the subsystem to be activated; storing a third data structure (412), the third data structure (412) comprising a second data sequence and a startup instruction set, the second data sequence representing the configuration of the subsystem to be started; calculating (811, 812, 813, 814) the first data sequence based on the stored second data sequence, the stored startup instruction set, and the stored capability set; Then, selectively resetting and suspending each computing unit (130, 140) of the subsystem; copying the stored set of capabilities, the second sequence of data, and the stored set of startup instructions to memory resources of a paused computing unit; changing the identifier of the suspended computing unit to the first data sequence of the computing; as well as The suspended computing unit is allowed to resume startup.

4. The method according to claim 3, further comprising the steps of: storing a fourth data structure (402), the fourth data structure (402) representing a current configuration of cores included in the boot subsystem; storing a fifth data structure (405), the fifth data structure (405) comprising at least one random value, the at least one random value received from the quote request system to prevent replay; as well as A signature is generated based on the at least one random value, the fourth data structure (402), and the calculated first data sequence, wherein the signature proves a secure boot of the subsystem.

5. The method according to claim 3 or 4, comprising the further steps of: storing data segments for processing by the boot instruction set; including a computing unit replica identifier in the data segment; calculating a third data sequence based on the calculated first data sequence and the stored identifier; The step of storing the second data structure further comprises: dividing the capability set into at least two subsets; wherein the step of changing the identifier of each suspended computing unit further comprises: changing the identifier to a third data sequence of the computation; and The step of replicating the stored capability set further comprises: storing at least one capability subset with a corresponding computing unit replica identifier in the memory resource of each suspended computing unit.

6. The method according to claim 5, further comprising the step of: Polling each computing unit replica of the startup subsystem (150) using a voting module (1110); and The step of allowing the suspended computing unit to resume startup after a quorum of computing unit replicas votes is reached is retained.

7. The method according to any one of claims 3 to 6, comprising the further steps of: selecting, resetting, and then pausing another computing unit (130, 140); updating the stored second data sequence of the third data structure (412) to represent a current configuration of a kernel included in the boot subsystem (150) including the other computing unit; Calculating the first data sequence; copying the stored set of capabilities, the second sequence of data, and the stored set of boot instructions to a memory resource of the other computing unit; changing the identifier of the other computing unit to the first data sequence of the computing; and The other computing unit is allowed to resume booting.

8. The method according to any one of claims 3 to 6, comprising the further steps of: Selecting a computing unit (130, 140) of the startup subsystem (150); Pausing the selected computing unit (130, 140); changing the identifier of the suspended computing unit corresponding to the computed first data sequence to a null value; and The stored second data sequence of the third data structure (412) is updated to represent a current configuration of cores included in the launch subsystem (150) excluding the selected computation.

9. The method according to any one of claims 3 to 6, comprising the further steps of: calculating an alternative data sequence based on the calculated first data sequence and data representing a re-marking event; changing said calculated first data sequence to said calculated alternative sequence in each calculation unit and said module of said subsystem (150); copying the stored set of boot instructions to the memory resources of each computing unit; as well as Allow each unit to resume startup.

10. The method according to claim 5 or 6, comprising the further steps of: By each module copy (120 1-N ) to partition at least one capability set stored in the memory (417); as well as At each compute unit replica, Encrypting the data to be protected in the memory using a key, generating a data sequence representing the data, and storing the encrypted data and the generated data sequence; Select n points p i Module copies used to form and quota (120 1-N ) whose size matches a polynomial of degree p, where p(0) is equal to the key; as well as Perform a voting sequence to convert the point p i Installed to each module copy (120 1-N ) in the memory (417), so that each module copy r i Store the corresponding point p i .

11. The method according to claim 10, comprising the further steps of: At each compute unit replica, From multiple module copies (120 1-N ) to retrieve n points p i , Combining a plurality of the retrieved points into a polynomial p, wherein the plurality of module copies (120 1-N ) is the number of module copies of the quota (120 1-N ) is a function of the size of; Calculating the key according to p(0); decrypting the stored data using the calculated key; generating a data sequence representing the decrypted data and comparing it to the stored data sequence for a match; Wherein, in case of a matching failure, the steps of combining, calculating, decrypting, generating and matching are repeated using a plurality of different retrieval points.

12. The method according to claim 5 or 6, wherein the module (120) further comprises a tamper-protected storage area (430) storing cryptographic keys and reconfigurable logic (441), the method comprising the further steps of: detecting a voting operation mismatch in the subsystem (150); communicating an alert representing said detection; receiving a data structure including a cryptographic key and an instruction set including an encrypted update of an update circuit description of the module; replacing the key stored in the tamper-protected storage area with the received cryptographic key; replacing the first set of instructions with the encrypted updated set of instructions (415); disabling the module (120) to preserve a portion of the reconfigurable logic; swapping a first portion of the tamper-protected memory area storing a current circuit description of the module with a second portion of the tamper-protected memory area storing an updated circuit description of the module; and Triggering the reset of the update module (120).

13. The method according to claim 12, comprising the further steps of: incrementing the counter with each subsequent mismatch detection; and When the counter reaches a predetermined number of mismatches, the module copy (120) of the subsystem (150) is disabled. 1-N ).

14. A computer-readable storage medium for storing computer-readable instructions, the computer-readable instructions being adapted to implement the steps of the method according to any one of claims 3 to 13.

15. A computer program or a computer program product comprising software code adapted to perform the steps of the method according to any one of claims 3 to 13.

Images