System and methods for provably secure authorized code execution, authorized cryptographic operations and authorized network communications

Abstract

System and methods for provably secure authorized code execution and authorized data encryption on computer platforms are provided, addressing the shortcomings of current state-of-the-art solutions that rely on system agents implicitly trusting the underlying operating environment. The invention enables mathematically backed security guarantees at the very lowest operating level, including firmware, hypervisors, and operating systems, thereby cutting out entire classes of complex cyberattacks proactively by design. Unlike current reactive approaches that focus on mitigating effects after an attack has occurred, this novel solution institutes a secure by default system immune to attacks such as remote code execution, advanced persistent threats, ransomware, and memory access exploits. The invention ensures authorized code execution and data encryption using dedicated program execution elements, providing a fundamentally different approach to ensuring the security and integrity of commodity computer platforms.

Description

[0001] SYSTEM AND METHODS FOR PROVABLY SECURE AUTHORIZED CODE EXECUTION, AUTHORIZED CRYPTOGRAPHIC OPERATIONS AND AUTHORIZED NETWORK COMMUNICATIONS

[0002] RELATED APPLICATIONS

[0003] This application claims the benefit under 35 U. S. C. 119(e) of U. S. Provisional Application No. 63 / 714,170 filed on October 31, 2024, which is incorporated herein in its entirety.

[0004] TECHNICAL FIELD

[0005] The present disclosure relates to at least the field of design of computer platforms including cybersecurity.

[0006] BACKGROUND ART

[0007] The subject matter discussed in the background section should not be considered prior art merely because of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be considered to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves, may also correspond to claimed embodiments.

[0008] The current state of the art in cybersecurity solutions is characterized by an increasing reliance on system agents to implement desired security solutions. These agents make use of artificial intelligence (Al) and machine learning (ML) including runtime introspection and monitoring frameworks to effect protections. These agents can manifest within the computing platform (cloud or local), firewalls, intrusion detection systems, and antivirus software.

[0009] However, these solutions suffer from several significant shortcomings. Unfortunately, the agents implicitly trust the underlying operating environment, which means that if the underlying operating environment is exploited, it can lead to the agents themselves being compromised. This is especially true in the face of complex attacks including remote code execution, advanced persistent threats, and ransomware, which exploit memory access exploits such as temporal and spatial buffer overflows, arbitrary pointer access, NULL pointer dereferencing, code and data integrity exploits: code overwriting, DMA attacks, return-oriented programming attacks, and return-to-libc. Furthermore, current solutions often require extensive manual configuration and maintenance, which can be time-consuming and prone to human error. Moreover, the "patch or break" approach used in many current solutions is unsustainable in today's fast-paced computing environment. This approach involves fixing vulnerabilities in software through patches but leaves underlying design flaws unaddressed. As a result, this cycle of patching and breaking can lead to an endless loop of security issues, making it difficult to maintain a secure system.

[0010] In addition, when patches are not available, such as in the case of 0-day attacks, current solutions have no solution to offer. This leaves systems vulnerable to attack and exploitation. The lack of effective security measures has led to a growing concern among users and organizations about the security and integrity of their data.

[0011] Current solutions often focus on reacting to threats rather than preventing them. This reactive approach can lead to a situation where systems are always playing catch-up, trying to mitigate the effects of an attack after it has occurred. The emphasis on reaction rather than prevention means that the underlying weaknesses and vulnerabilities remain unaddressed, leaving systems vulnerable to attack.

[0012] It is therefore the objective of the present invention to provide a novel solution that stands out from current state-of-the-art solutions by offering a fundamentally different approach to ensuring authorized code execution, authorized cryptographic operations and authorized network communications on commodity computer platforms. The invention enables mathematically backed security guarantees on commodity computer platforms running hardware and software stack elements at the very lowest operating level such as firmware, hypervisors and operating systems. This will help cut out entire classes of complex cyberattacks proactively by design and institute a secure by default system which are immune to those attacks.

[0013] In U. S. Patent No. 8,627,414 issued January 7, 2014, inventors McCune et al. disclose a computer including a processor and a verification device. The processor in the computer performs the steps of authenticating a secure connection between a hypervisor and the verification device, measuring the identity of at least a portion of a select guest before the select guest executes any instruction, and sending a measurement of the identity of the select guest to the verification device. The verification device compares the policy stored in the verification device with the measurement of the select guest received by the verification device. The steps of authenticating, measuring, sending, and comparing are performed after receiving a signal indicative of a request to execute the selected guest and without rebooting the computer. In U. S. Patent No. 12,093,367 issued September 17, 2024, inventor Amit Vasudevan discloses a system architecture that structures commodity heterogeneous interconnected computer platforms around universal object abstractions, which are a fundamental system abstraction and building block that provides practical and provable end-to-end guarantees of security, correctness, and timeliness for the platform.

[0014] In U. S. Patent No. 12,367,328 issued July 22, 2025, the entirety of which is incorporated herein by reference, inventors Amit Vasudevan et al., disclose systems and methods for mathematical modeling of the hardware and software stack of commodity computer platforms. The mathematical model provides provable guarantees on memory, device, and program execution. This approach addresses the technical problem of reliance on system agents that rely on implicit trust in the operating environment, which can be exploited by sophisticated attackers using complex threats such as memory access exploits and code / data integrity exploits. The solution provides a proactive, mathematically-backed security solution that eliminates entire classes of cyberattacks by design, ensuring provable guarantees on commodity computer platforms running hardware and software stack elements at the lowest operating level. This approach has significant advantages over reactive cybersecurity methods, including reduced complexity and overhead, and increased confidence in the integrity of the system. The solution’s main uses include providing mathematically-backed security and availability guarantees for critical infrastructure, financial institutions, and other organizations vulnerable to cyberattacks.

[0015] In U. S. Patent Application No. 19 / 254,764 filed on June 30, 2025, the entirety of which is incorporated herein by reference, inventors Amit Vasudevan et al., disclose systems and methods for providing unforgeable telemetry on computer platforms. Mathematical modeling and theorem proving are utilized to guarantee the integrity of telemetry probe execution flow and trigger, thereby preventing circumvention and tampering of logged probe data. In contrast to current state-of-the-art solutions that rely implicitly on the operating environment, this approach provides a sound and complete assurance of telemetry output. The system enables organizations to map unforgeable telemetry probe data to industry and government cybersecurity regulatory controls, ensuring compliance therewith. This invention addresses the shortcomings of existing solutions, including their vulnerability to sophisticated attacks, operational complexity, and inability to provide unforgeable telemetry data, thereby providing a reliable and accurate monitoring output in the presence of cyberattacks on computer platforms. SUMMARY

[0016] System and methods for provably secure authorized code execution and authorized data encryption on computer platforms are provided, addressing the shortcomings of current state-of-the-art solutions that rely on system agents implicitly trusting the underlying operating environment. The invention enables mathematically backed security guarantees at the very lowest operating level, including firmware, hypervisors, and operating systems, thereby cutting out entire classes of complex cyberattacks proactively by design. Unlike current reactive approaches that focus on mitigating effects after an attack has occurred, this novel solution institutes a secure by default system immune to attacks such as remote code execution, advanced persistent threats, ransomware, and memory access exploits. The invention ensures authorized code execution and data encryption using dedicated program execution elements, providing a fundamentally different approach to ensuring the security and integrity of commodity computer platforms.

[0017] The following passages present representative formulations of aspects of the invention in claim-style format. They are provided in the Summary for convenience of understanding the disclosed subject matter, and to illustrate how various features can be arranged in hierarchical dependency. These formulations are not intended to define the invention or to limit the scope of the claims that are formally set forth, amended, or pursued in any application claiming priority hereto.

[0018] Aspect (1). A system comprising:

[0019] a computer platform having

[0020] at least one processor, and

[0021] at least one non-transitory computer-readable storage medium having stored thereon a set of program execution elements (PEE), each PEE of the set of PEEs (i) executable by the at least one processor, (ii) having a respective privilege level, (iii) in a respective memory address space, and (iv) enforcing a trusted path security mechanism; and

[0022] a mathematical model of the computer platform, the mathematical model

[0023] having a formal representation of the at least one processor, the at least one non- transitory computer-readable storage medium, and the set of PEEs; and

[0024] defining and proving the trusted path security mechanism for the set of PEEs, the trusted path security mechanism enforcing permitted patterns of operations of the computer platform, the operations of the computer platform including at least one of (i) memory access operations; (ii) peripheral access operations; (iii) operations of the at least one processor including at least execution of processor instructions; and (iv) operations involving access to and manipulation of a state of the at least one processor (“processor state”), a state of the at least one non-transitory computer-readable storage medium (“memory state”), and / or a state of a peripheral (“peripheral state”).

[0025] Aspect (2). The system of Aspect (1), wherein the computer platform further comprises at least one peripheral, and the formal representation in the mathematical model further includes the at least one peripheral.

[0026] Aspect (3). The system of Aspect (1), wherein

[0027] the trusted path security mechanism comprises a privilege-separation mechanism that enforces access controls on the operations of the computer platform that involve peripheral access, or access to and manipulation of the processor state, the memory state, or the peripheral state; and

[0028] the access controls ensure that each of said operations is executed with a privilege level required to perform the operation.

[0029] Aspect (4). The system of Aspect (3) wherein

[0030] the set of PEEs includes a first subset of PEEs and a second subset of PEEs; and the access controls enforced by the privilege-separation mechanism further comprise an access control policy;

[0031] a caller PEE to initiate a privileged operation, the caller PEE in the first subset of PEEs and the respective memory address space of the caller PEE being a caller memory address space;

[0032] a callee PEE to perform the privileged operation, the callee PEE in the second subset of PEE and the respective memory address space of the callee PEE being a callee memory address space; and

[0033] an access control matrix utilized by the access controls to enforce caller PEE - callee PEE access control by allowing or denying calls per the access control policy. Aspect (5). The system of Aspect (3) wherein the privilege separation mechanism is implemented using at least one of (i) hardware capabilities of the computer platform and (ii) software verification and / or software fault isolation.

[0034] Aspect (6). The system of Aspect (1), wherein

[0035] the operations of the computer platform include memory access operations; and the trusted path security mechanism includes a memory-safety mechanism to ensure that all the memory access operations are valid.

[0036] Aspect (7). The system of Aspect (6), wherein

[0037] the at least one non-transitory computer-readable storage medium includes allocated memory; and

[0038] the memory-safety mechanism has

[0039] (i) a spatial memory safety mechanism to control memory layout and memory access boundaries and to ensure that the memory accesses operations are within valid bounds, and

[0040] (ii) a temporal memory safety mechanism to ensure that the memory access operations are consistent with respect to a lifetime and state of the allocated memory.

[0041] Aspect (8). The system of Aspect (7), wherein the spatial memory safety mechanism enforces memory protections for a subset of PEEs within the set of PEEs by utilizing

[0042] (a) hardware capabilities of the computer platform and platform memory management unit (MMU) configuration to set guard memory regions and global offset table (GOT) as readonly; and / or

[0043] (b) software-based verification and / or software fault isolation enforced within code of the PEEs within the subset to set the guard memory regions and GOT as read-only.

[0044] Aspect (9). The system of Aspect (7), wherein the spatial memory safety mechanism adds guard memory regions preceding and succeeding PEE global data variables for a subset of PEEs within the set of PEEs and enforces memory protections by utilizing

[0045] (a) hardware capabilities of the computer platform and platform memory management unit (MMU) configuration by a higher-privileged PEE outside the subset of PEEs to set the guard memory regions as read-only, the higher-privileged PEE having a higher privilege level than any of the PEEs in the subset of PEEs; and / or

[0046] (b) software-based verification and / or software fault isolation enforced within code of the PEEs within the subset to set the guard memory regions as read-only.

[0047] Aspect (10). The system of Aspect (7), wherein

[0048] the spatial memory safety mechanism has a data bounds safety mechanism for a subset of PEEs within the set of PEEs,

[0049] the data bounds safety mechanism (i) associates each of a plurality of PEE variables with information about size and alignment of said PEE variable and (ii) emits runtime checks in a PEE code region to ensure access to said PEE variables are always within the valid bounds.

[0050] Aspect (11). The system of Aspect (7), wherein the temporal memory safety mechanism further comprises a heap safety mechanism to monitor allocations, deallocations and protection of predefined memory regions.

[0051] Aspect (12). The system of Aspect (11) wherein

[0052] a total memory address space is a union of each of the respective memory address spaces of the PEEs in the set of PEEs; and

[0053] the heap safety mechanism comprises (i) one or more heap manager PEEs in the set of PEEs to manage physical and virtual memory mappings within the total memory address space; (ii) said one or more heap manager PEEs execute at one or more privilege levels; and (iii) said one or more heap manager PEEs each have one or more functions that enforces memory protection against heap allocation and deallocation attacks.

[0054] Aspect (13). The system of Aspect (12) wherein the one or more functions are implemented using at least one of hardware capabilities of the computer platform, software verification, and software fault isolation.

[0055] Aspect (14). The system of Aspect (1), wherein

[0056] the trusted path security mechanism comprises a control-flow integrity (CFI) mechanism to ensure that execution of the processor instructions follows the permitted patterns. Aspect (15). The system of Aspect (14), wherein

[0057] the processor instructions include of one or more branch instructions and one or more return instructions that, respectively, transfer control to and return control to specific processor instructions in a processor instruction flow; and

[0058] the CFI mechanism comprises

[0059] a code-safety mechanism to ensure that the processor instructions, once executed by the at least one processor, are immutable in the respective memory address space of a first PEE in the set of PEEs; and

[0060] a stack-safety mechanism to enforce integrity of the processor state for both the branch instructions and the return instructions thereby preserving overall integrity of the processor instruction flow.

[0061] Aspect (16). The system of Aspect (15), wherein the code-safety mechanism enforces memory protections for a subset of PEEs within the set of PEEs by utilizing

[0062] (a) hardware capabilities of the computer platform and platform memory management unit (MMU) configuration by a higher-privileged PEE outside the subset of PEEs to set PEE code memory regions as read-only, the higher-privileged PEE having a higher privilege level than any of the PEEs in the subset of PEEs; and / or

[0063] (b) software-based verification and / or software fault isolation enforced within code of the PEEs within the subset to set the PEE code memory regions as read-only.

[0064] Aspect (17). The system of Aspect (15), wherein the code-safety mechanism further enforces memory protections for a subset of PEEs within the set of PEEs by utilizing

[0065] (a) hardware capabilities of the computer platform and platform memory management unit (MMU) configuration by a higher-privileged PEE outside the subset of PEEs to set PEE procedure linkage table (PLT) memory regions as read-only, the higher-privileged PEE having a higher privilege level than any of the PEEs in the subset of PEEs; and / or

[0066] (b) software-based verification and / or software fault isolation enforced within code of the PEEs within the subset to set the PEE PLT memory regions as read-only.

[0067] Aspect (18). The system of Aspect (15), wherein

[0068] the stack-safety mechanism comprises a forward-edge CFI mechanism to ensure that the processor instructions in the processor instruction flow are valid and authorized; and

[0069] a backward-edge CFI mechanism to ensure that return instructions from a prior branch instruction occur to valid and authorized processor instructions.

[0070] Aspect (19). The system of Aspect (18), wherein

[0071] the set of PEEs includes a second PEE that is the same or different than the first PEE; the one or more branch instructions include a first branch instruction;

[0072] the set of PEEs includes an external PEE; and

[0073] the forward-edge CFI mechanism further validates that a memory address to which the first branch instruction transfers control to within the second PEE in the set of PEEs

[0074] (i)(a) is within a valid memory region containing PEE code, (b) points to a valid PEE function of the second PEE, or (c) points to the external PEE;

[0075] (ii) is aligned correctly; and

[0076] (iii) matches a signature of a valid PEE function prototype or a signature of the valid PEE code region block.

[0077] Aspect (20). The system of Aspect (18), wherein

[0078] the backward-edge CFI mechanism further validates that a first memory address to which a first return instruction transfers control is (i) within a valid first memory region containing first PEE code, (ii) aligned correctly, (iii) follows the prior branch instruction that invoked a target PEE function or second memory region containing second PEE code; and (iv) contains a hash value adjacent to the first memory address of the prior branch instruction that matches a hash of a prototype of the PEE target function or a hash of a third memory region containing third PEE code;

[0079] the first return instruction is among the return instructions;

[0080] the valid first memory region is the same or different as the second memory region; the second memory region is the same or different as the third memory region;

[0081] the valid first memory region is the same or different as the third memory region; the first PEE code is the same or different as the second PEE code;

[0082] the second PEE code is the same or different as the third PEE code; and

[0083] the first PEE code is the same or different as the third PEE code. Aspect (21). The system of Aspect (18), wherein the backward-edge CFI mechanism comprises a meta-stack mechanism to ensure every PEE function in a first PEE among the set of PEEs (i) has a local stack for storing local variables and a meta stack for storing return instruction addresses, (ii) always executes the return instructions using the meta stack to obtain a return instruction pointer, and (iii) always writes to the local variables using the local stack.

[0084] Aspect (22). The system of Aspect (18), wherein the backward-edge CFI mechanism further comprises a stack-frame protection canary mechanism to ensure that each PEE function in a first PEE among the set of PEEs (i) stores a random value (the “canary”) at a beginning of a stack frame of the PEE function before a memory location of a first local variable within the stack frame and (ii) before returning from the PEE function, ensures a value currently at the beginning of the stack frame matches the canary.

[0085] Aspect (23). The system of Aspect (18) wherein the forward edge CFI mechanism and backward edge CFI mechanism are implemented using at least one of (i) hardware capabilities of the computer platform, and (ii) software verification and / or software fault isolation.

[0086] Aspect (24). The system of Aspect (18) wherein the forward edge CFI mechanism and backward edge CFI mechanism are implemented on PEE code.

[0087] Aspect (25). The system of Aspect (1), wherein

[0088] the set of PEEs includes a first PEE and a second PEE, having first and second privilege levels, respectively, the first privilege level being a higher privilege level than the second privilege level; and

[0089] the first PEE utilizes a first memory address space and the second PEE utilizes a second memory address space different from the first memory address space.

[0090] Aspect (26). The system of Aspect (1) wherein

[0091] the mathematical model (i) defines operational aspects of hardware elements and software stack elements, (ii) defines predicates for security mechanisms on the computer platform that are translatable to proof obligations in a composable manner, and (iii) interprets and verifies the proof obligations; the hardware elements comprise the at least one processor, and the at least one non-transitory computer-readable storage medium; and

[0092] the software stack elements comprise the set of PEEs.

[0093] Aspect (27). The system of Aspect (1), wherein

[0094] a first subset of the set of PEEs are implemented in a low-level programming language; a second subset of the set of PEEs are implemented in a high-level programming language;

[0095] the PEEs in the first subset enforce the trusted path security mechanism; and

[0096] the PEEs in the second subset enforce the trusted path security mechanism.

[0097] Aspect (28) The system of Aspect (1), wherein the mathematical model

[0098] (i) defines a first subset of the set of PEEs are implemented in a low-level programming language;

[0099] (ii) defines a second subset of the set of PEEs are implemented in a high-level programming language; and

[0100] (iii) defines and proves the trusted path security mechanism of the union of the PEEs of the first subset and the PEEs in the second subset.

[0101] Aspect (29). The system of Aspect (1) wherein the at least one non-transitory computer-readable storage medium has stored thereon the mathematical model.

[0102] Aspect (30). The system of Aspect (1) wherein each of the PEEs in the set of PEEs comprise one or more of the group consisting of a source code file, a binary executable file, a script executable file, a configuration file, and a platform-specific configuration file.

[0103] Aspect (31). The system of Aspect (1) wherein

[0104] each PEE in a subset of the set of PEEs includes

[0105] one or more functions to form an atomic unit of functionality of the PEE; and a memory map in the respective memory address space, the memory map comprising one or more of the group consisting of code regions, global data variables, heaps, stacks, procedure linkage table (PLT) entries, and global offset table (GOT) entries; each of the one or more functions is composed of a set of instructions including return instruction and a return instruction pointer; and

[0106] the memory map is randomized at a time the respective PEE is loaded into its respective memory address space.

[0107] Aspect (32). The system of claim 31 wherein each PEE in a subset of the set of PEEs further includes operational semantics for the one or more functions, the operational semantics comprising one or more of the group consisting of semantics for reading and writing to global variables, stack, and heap; allocating and freeing heaps; calling other functions within the PEE; calling functions of another PEE; and returning to a parent PEE function.

[0108] Aspect (33). A system, comprising:

[0109] a computer platform having:

[0110] at least one processor; and

[0111] at least one non-transitory computer-readable storage medium having stored thereon a set of program execution elements (PEEs), each PEE of the set of PEEs being (i) executable by the at least one processor, (ii) having a respective privilege level, (iii) in a respective memory address space, and (iv) enforcing security through an interface confined security mechanism (ICSM) comprising a subset of the set of PEEs (“ICSM PEEs”) that establish boundary limiting interactions (“bastion interfaces”) with resources of the computer platform for a set of adversary-controlled PEEs, wherein said ICSM PEEs are at a higher privilege level than the adversary-controlled PEEs; and

[0112] a mathematical model of the computer platform to define and prove the ICSM, the mathematical model having

[0113] a formal representation of the at least one processor, the at least one non- transitory computer-readable storage medium, and the set of PEEs; and

[0114] at least one adversary model for each of the bastion interfaces,

[0115] wherein

[0116] the set of PEEs includes the set of adversary-controlled PEEs; and

[0117] the ICSM ensures security mechanisms of the computer platform by enforcing the bastion interfaces. Aspect (34). The system of Aspect (33) wherein the resources of the computer platform are one or more of the at least one processor, the at least one non-transitory computer-readable storage medium, memory address space, and peripherals.

[0118] Aspect (35). The system of Aspect (33), wherein

[0119] the set of PEEs includes a first PEE and a second PEE, having first and second privilege levels, respectively, the first privilege level being a higher privilege level than the second privilege level; and

[0120] the first PEE utilizes a first memory address space and the second PEE utilizes a second memory address space different from the first memory address space.

[0121] Aspect (36). The system of Aspect (33), wherein the computer platform further comprises at least one peripheral, and the formal representation in the mathematical model further includes the at least one peripheral.

[0122] Aspect (37). The system of Aspect (33) wherein

[0123] the mathematical model further (i) defines operational aspects of hardware elements and software stack elements, (ii) defines predicates for security mechanisms on the computer platform that are translatable to proof obligations, and (iii) includes a theorem prover to interpret and verify the proof obligations;

[0124] the hardware elements comprise the at least one processor, and the at least one non-transitory computer-readable storage medium; and

[0125] the software stack elements comprise the set of PEEs.

[0126] Aspect (38). The system of Aspect (33) wherein the ICSM includes an approved code execution mechanism to ensure that only authorized PEEs are executed in the computer platform.

[0127] Aspect (39). The system of Aspect (38) wherein the approved code execution mechanism comprises an approved code execution provisioning mechanism to provision authorized PEEs.

[0128] Aspect (40). The system of Aspect (39) wherein

[0129] the computer platform is a first computer platform; and the approved code execution provisioning mechanism provisions authorized PEEs from a second computer platform that is local or remote to the first computer platform.

[0130] Aspect (41). The system of Aspect (38) wherein

[0131] the at least one non-transitory computer-readable storage medium has stored thereon a set of files; and

[0132] the approved code execution mechanism comprises a file protection mechanism to ensure that a subset of the set of files are always read-only.

[0133] Aspect (42). The system of Aspect (41) wherein the subset of files comprises one or more of PEE executable files and / or one or more PEE configuration files.

[0134] Aspect (43). The system of Aspect (41) wherein

[0135] the bastion interfaces include a subset of bastion interfaces;

[0136] the subset of bastion interfaces includes one or more non-volatile storage interfaces and one or more volatile storage interfaces; and

[0137] the file protection mechanism uses the subset of bastion interfaces to set the subset of the set of files to read-only.

[0138] Aspect (44). The system of Aspect (38) wherein

[0139] the set of PEEs includes a first subset of PEEs;

[0140] the PEEs in a first subset of PEEs comprises PEE executable files and the approved code execution mechanism further comprises a PEE load protection mechanism that loads authorized PEE executable files from the at least one non-transitory computer-readable storage medium to a memory address space.

[0141] Aspect (45). The system of Aspect (38) wherein

[0142] the set of PEEs includes a subject PEE;

[0143] the set of PEEs includes a first subset of PEEs;

[0144] the PEEs in the first subset of PEEs comprises PEE executable files;

[0145] the PEE executable files include PEE executable code regions and a set of memory regions; and the approved code execution mechanism further comprises a PEE execute protection mechanism that marks PEE executable code regions of the subject PEE and a subset of the set of memory regions in the respective memory address space of the subject PEE as read-only before executing the PEE executable files in the memory address space.

[0146] Aspect (46). The system of Aspect (38) wherein

[0147] the set of PEEs includes a subject PEE;

[0148] the set of PEEs includes a first subset of PEEs;

[0149] the PEEs in the first subset of PEEs comprises PEE executable files; and

[0150] the approved code execution mechanism further comprises a PEE unload protection mechanism to unload authorized PEE executable files of the subject PEE from the respective memory address space of the subject PEE and to perform cleanup of the respective memory address space once execution of the subject PEE is complete.

[0151] Aspect (47). The system of Aspect (38) wherein

[0152] the bastion interfaces includes at least one or more of the group consisting of a code execution interface, a memory interface, a non-volatile storage interface, a device interface, a processor interface, and a volatile storage interface; and

[0153] the approved code execution mechanism uses a subset of the bastion interfaces to execute PEEs in the set of PEEs.

[0154] Aspect (48). The system of Aspect (38) wherein the approved code execution mechanism is instantiated at a plurality of privilege levels and in a plurality of memory address spaces.

[0155] Aspect (49). The system of Aspect (33) wherein

[0156] the bastion interfaces include cryptographic operation interfaces; and

[0157] the ICSM includes an approved cryptographic operation mechanism to ensure that only authorized cryptographic keys and the cryptographic operation interfaces are used for encryption and decryption in the computer platform.

[0158] Aspect (50). The system of Aspect (49) wherein the approved cryptographic operation mechanism comprises a provisioning mechanism to provision authorized cryptographic keys. Aspect (51). The system of Aspect (50) wherein the provisioning mechanism provisions authorized cryptographic keys from a local key-signing agent and / or a remote key-signing agent.

[0159] Aspect (52). The system of Aspect (49) wherein the approved cryptographic operation mechanism comprises a cryptographic key enforcement mechanism to enforce that only authorized cryptographic keys and authorized cryptographic operation interfaces are used at all times.

[0160] Aspect (53). The system of Aspect (52) wherein the cryptographic key enforcement mechanism includes cryptographic operation interfaces for one or more of encryption, decryption, digital signatures, hashing, key-exchange, key-derivation, message authentication code, random number generation, and zero-knowledge proofs cryptographic operations.

[0161] Aspect (54). The system of Aspect (52) wherein the cryptographic operations performed by the cryptographic operation interfaces only use authorized cryptographic keys.

[0162] Aspect (55). The system of Aspect (49) wherein the computer platform securely stores authorized cryptographic keys in the at least one non-transitory computer-readable storage medium.

[0163] Aspect (56). The system of Aspect (55) wherein the authorized cryptographic keys are stored securely in the at least one non-transitory computer-readable storage medium in a persistent manner.

[0164] Aspect (57). The system of Aspect (55) wherein

[0165] the set of PEEs includes one or more sentinel PEEs; and

[0166] the authorized cryptographic keys are stored securely in the respective memory address space(s) of the one or more sentinel PEEs.

[0167] Aspect (58). The system of Aspect (49) wherein the approved cryptographic operation mechanism is instantiated at a plurality of privilege levels and in a plurality of memory address spaces. Aspect (59). The system of Aspect (33) wherein the ICSM PEEs include an approved network communication mechanism to ensure that only authorized external computer platforms and authorized network operation interfaces are used for receiving and sending data into and out of the computer platform.

[0168] Aspect (60). The system of Aspect (59) wherein the approved network communication mechanism comprises an approved network communication provisioning mechanism to provision the set of authorized external computer platforms, authorized network operation interfaces and authorized network communication policies.

[0169] Aspect (61). The system of Aspect (60) wherein the approved network communication provisioning mechanism provisions the set of authorized external computer platforms, authorized network operation interfaces and the authorized network communication policies from an approved network communication policy repository.

[0170] Aspect (62). The system of Aspect (60) wherein the authorized network communication policies are stored securely in the at least one non-transitory computer-readable storage medium.

[0171] Aspect (63). The system of Aspect (62) wherein the authorized network communication policies are stored securely in a persistent manner.

[0172] Aspect (64). The system of Aspect (62) wherein

[0173] the set of PEEs includes one or more sentinel PEEs; and

[0174] the authorized network communication policies are stored securely in the respective memory address space(s) of the one or more sentinel PEEs.

[0175] Aspect (65). The system of Aspect (59) wherein the approved network communication mechanism comprises an approved network communication enforcement mechanism that enforces the authorized network operation interfaces and authorized network communication policies on the computer platform at all times. Aspect (66). The system of Aspect (65) wherein the approved network communication enforcement mechanism includes network operation interfaces for one or more of receive, send, bind, and configure operations.

[0176] Aspect (67). The system of Aspect (66) wherein the network operations performed by the network operation interfaces enforce the authorized network communication policies.

[0177] Aspect (68). The system of Aspect (65) wherein the approved network communication enforcement mechanism filters incoming and outgoing network traffic using a packet filtering framework.

[0178] Aspect (69). The system of Aspect (68) wherein

[0179] the approved network communication enforcement mechanism utilizes the network operation interfaces to perform the filtering and to enforce the authorized network communication policies.

[0180] Aspect (70). The system of Aspect (59) wherein the approved network communication mechanism is instantiated at a plurality of privilege levels and in a plurality of memory address spaces.

[0181] Aspect (71). The system of Aspect (33) wherein the ICSM PEEs comprises a memory-safety mechanism to ensure that all memory access operations are valid.

[0182] Aspect (72). The system of Aspect (33) wherein the ICSM PEEs comprises a control-flow integrity mechanism to ensure that execution of instructions by the at least one processor follows authorized patterns.

[0183] Aspect (73). The system of Aspect (33) wherein

[0184] the ICSM PEEs comprises a privilege-separation mechanism to enforce access controls on operations of the computer platform that involve peripheral access, or access to and manipulation of processor state, memory state, or peripheral state; and

[0185] the access controls ensure that each of the operations is executed with a privilege level required to perform the operation. Aspect (74). A system for providing formal verification of a design and operation of a computer platform, the system comprising:

[0186] a processor; and

[0187] a first non-transitory computer-readable storage medium having stored thereon instructions that, when executed, program the processor to perform act(s) of

[0188] evaluating a mathematical model that (i) models the computer platform with a formal representation of a set of processors of the computer platform (“platform processors”), a second non-transitory computer-readable storage medium of the computer platform (“platform memory”), and a set of program execution elements (PEEs) of the computer platform, and (ii) specifies invariants to enforce an interface confined security mechanism (ICSM), with assume-guarantee interface-confined mathematical reasoning; and

[0189] determining from the evaluation that the ICSM holds true for the computer platform,

[0190] wherein each PEE in the set of PEEs is modelled as (i) executable by the platform processors, (ii) having a respective privilege level and (iii) utilizing a respective memory address space in the platform memory.

[0191] Aspect (75). The system of Aspect (74), wherein the ICSM comprises at least one of the group consisting of a trusted path security mechanism, an approved code execution mechanism, an approved cryptographic operations mechanism, and an approved network communication mechanism.

[0192] Aspect (76). The system of Aspect (74), wherein the act of determining comprises determining from the evaluation whether the ICSM holds true for the computer platform regardless of an organization of the PEEs in the set of PEEs of the computer platform.

[0193] Aspect (77). The system of Aspect (74), wherein the act of determining comprises determining from the evaluation whether the ICSM holds true for the computer platform regardless of a composition of the PEEs of the set of PEEs of the computer platform. Aspect (78). The system of Aspect (74), wherein the formal representation in the mathematical model further includes (x) a subset of the set of PEEs that are adversary-controlled and (y) at least one adversary model for each of the adversary-controlled PEEs.

[0194] Aspect (79). The system of Aspect (74) further comprising a mathematical model implementation validation mechanism to validate that the set of PEEs implement the ICSM specified in the mathematical model.

[0195] Aspect (80). The system of Aspect (79), wherein the mathematical model implementation validation mechanism comprises a test generation mechanism to generate test cases from the mathematical model.

[0196] Aspect (81). The system of Aspect (79), wherein the mathematical model implementation validation mechanism comprises a trace capture mechanism to collect accurate and reliable traces of PEE execution.

[0197] Aspect (82). The system of Aspect (79), wherein the mathematical model implementation validation mechanism comprises a trace validation mechanism to evaluate if traces of PEE execution conform to the mathematical model.

[0198] Aspect (83). The system of Aspect (74), wherein

[0199] a first subset of the set of PEEs are implemented in a low-level programming language; a second subset of the set of PEEs are implemented in a high-level programming language; and

[0200] the mathematical model ensures a composition of the ICSM of the union of the PEEs of the first subset and the PEEs in the second subset.

[0201] Aspect (84). The system of Aspect (74), wherein

[0202] the set of PEEs includes a first PEE and a second PEE, having first and second privilege levels, respectively, the first privilege level being a higher privilege level than the second privilege level; and

[0203] the first PEE utilizes a first memory address space and the second PEE utilizes a second memory address space different from the first memory address space. Aspect (85). The system of Aspect (74), wherein the mathematical model contains a formal representation of the set of PEEs, the formal representation comprising (i) an interface defined for each PEE in the set of PEEs, wherein the interface includes conditions that must be met before and after execution of one or more PEE functions of the respective PEE; (ii) a specification of the platform memory and memory regions accessible for each PEE in the set of PEEs; (iii) a representation of conditions as predicates over the platform memory’s state(s) and the platform processors’ state(s), where the predicates indicate whether the platform memory’s state(s) and the platform processors’ state(s) satisfy the conditions; and (iv) enforced invariants of the ICSM at a start and at an end of each PEE function execution.

[0204] Aspect (86). The system of Aspect (74), wherein

[0205] the mathematical model contains a formal representation of the computer platform and operational aspects of the PEEs in the set of PEEs, the formal representation comprising first executable instructions for defining an initial configuration of the platform processors and an initial global platform memory state;

[0206] second executable instructions for executing a series of concurrent steps on each of the platform processors, wherein each step is associated an operation being performed and a first PEE in the set of PEEs associated with the operation; and

[0207] third executable instructions for managing an internal state of each of the platform processors, starting new threads, and assigning memory addresses to each thread; and

[0208] the ICSM is enforced by checking corresponding invariants for each PEE function call.

[0209] Aspect (87). The system of Aspect (86), wherein

[0210] the mathematical model further comprises a formal representation and model of a lock on a PEE function, the lock preventing the PEE function from being called if it is already active; the mathematical model requires waiting until the lock is released before proceeding with the PEE function call;

[0211] the model of the lock ensures that only one instance of the PEE function can be executed at a time across the platform processors. Aspect (88). The system of Aspect (86), wherein the mathematical model contains a formal representation of interrupt handling on the computer platform, the formal representation of interrupt handling comprising:

[0212] fourth executable instructions for executing an interrupt handler function within a first PEE in the set of PEEs for each of the platform processors in response to an interrupt, the interrupt handler function has its own assigned memory address space;

[0213] fifth executable instructions for preemptively executing the interrupt handler function at any point in time with an assigned privilege level; and

[0214] sixth executable instructions for returning control to an original interrupted PEE function after the interrupt handler function terminates.

[0215] Aspect (89). The system of Aspect (74), wherein the mathematical model includes a formal representation of the ICSM that further includes a memory-safety mechanism to ensure that all memory access operations on the computer platform are valid.

[0216] Aspect (90). The system of Aspect (89), wherein the formal representation of memory-safety mechanism comprises (x) a spatial memory safety mechanism that controls memory layout and memory access boundaries to ensure the memory accesses operations are within valid bounds; and (y) a temporal memory safety mechanism that ensures that memory accesses are valid and consistent with respect to the lifetime and state of allocated memory, preventing unauthorized or erroneous memory accesses.

[0217] Aspect (91). The system of Aspect (74) wherein the mathematical model includes a formal representation of the ICSM that further includes a control-flow integrity mechanism that ensures that execution of PEEs by the platform processors follows authorized patterns and do not compromise the integrity of the computer platform.

[0218] Aspect (92). The system of Aspect (91) wherein the formal representation of the control -flow integrity mechanism comprises (i) a code-safety mechanism that ensures that PEE execution by platform processors are immutable in a given memory address space; and (ii) a stack-safety mechanism that enforces the integrity of the platform processors’ state(s) for PEE execution by the platform processors. Aspect (93). The system of Aspect (74) wherein

[0219] the mathematical model includes a formal representation of the ICSM that further includes a privilege-separation mechanism that enforces access controls on operations of the computer platform that involve peripheral access, or access to and manipulation of the platform processors’ state(s), the platform memory’s state(s), or the peripheral’s state(s); and

[0220] the access controls ensure that each of said operations is executed with a privilege level required to perform the operation.

[0221] Aspect (94). The system of Aspect (74), wherein the formal representation in the mathematical model further includes a peripheral of the computer platform (“platform peripheral”).

[0222] Aspect (95). The computer platform of Aspect (74) wherein

[0223] the mathematical model further defines predicates for the ICSM on the computer platform that are translatable to proof obligations; and

[0224] the mathematical model includes a theorem prover to interpret and verify the proof obligations.

[0225] Aspect (96). A computer-implemented method for formal verification of a design and operation of a computer platform, the method comprising acts of:

[0226] evaluating a mathematical model that (i) models the computer platform with a formal representation of a set of processors of the computer platform (“platform processors”), a non-transitory computer-readable storage medium of the computer platform (“platform memory”), and a set of program execution elements (PEEs) of the computer platform, and (ii) specifies invariants to enforce an interface confined security mechanism (ICSM), with assume-guarantee interface-confined mathematical reasoning; and

[0227] determining from the evaluation that the ICSM holds true for the computer platform, wherein each PEE of the set of PEEs are modelled as (a) executable by the platform processor, (b) having a respective privilege level, and (c)utilizing a respective memory address space in the platform memory.

[0228] Aspect (97). The computer-implemented method of Aspect (96), wherein the ICSM comprises at least one of the group consisting of a trusted path security mechanism, an approved code execution mechanism, an approved cryptographic operations mechanism, and an approved network communication mechanism.

[0229] Aspect (98). The computer-implemented method of Aspect (96), wherein the act of determining comprises determining from the evaluation whether the ICSM holds true for the computer platform regardless of an organization of the PEEs in the set of PEEs of the computer platform.

[0230] Aspect (99). The computer-implemented method of Aspect (96), wherein the act of determining comprises determining from the evaluation whether the ICSM holds true for the computer platform regardless of a composition of the PEEs of the set of PEEs of the computer platform.

[0231] Aspect (100). The computer-implemented method of Aspect (96), wherein the formal representation in the mathematical model further includes (x) a subset of the set of PEEs that are adversary-controlled and (y) at least one adversary model for each of the adversary-controlled PEEs.

[0232] Aspect (101). The computer-implemented method of Aspect (96) further comprising an act of validating, with a mathematical model implementation validation mechanism, that the set of PEEs implement the ICSM specified in the mathematical model.

[0233] Aspect (102). The computer-implemented method of Aspect (101) further comprising an act of generating, with a test generation mechanism of the mathematical model implementation validation mechanism, test cases from the mathematical model.

[0234] Aspect (103). The computer-implemented method of Aspect (101) further comprising an act of collecting, with a trace capture mechanism of the mathematical model implementation validation mechanism, accurate and reliable traces of PEE execution.

[0235] Aspect (104). The computer-implemented method of Aspect (101) further comprising an act of evaluating, with a trace validation mechanism of the mathematical model implementation validation mechanism, if traces of PEE execution conform to the mathematical model. Aspect (105). The computer-implemented method of Aspect (96), wherein a first subset of the set of PEEs are implemented in a low-level programming language and a second subset of the set of PEEs are implemented in a high-level programming language, the computer-implemented method further comprising an act of ensuring, with the mathematical model, a composition of the ICSM of the union of the PEEs of the first subset and the PEEs in the second subset.

[0236] Aspect (106). The computer-implemented method of Aspect (96), wherein

[0237] the set of PEEs includes a first PEE and a second PEE, having first and second privilege levels, respectively, the first privilege level being a higher privilege level than the second privilege level; and

[0238] the first PEE utilizes a first memory address space and the second PEE utilizes a second memory address space different from the first memory address space.

[0239] Aspect (107). The computer-implemented method of Aspect (96), wherein the mathematical model contains a formal representation of the set of PEEs, the formal representation comprising (i) an interface defined for each PEE in the set of PEEs, wherein the interface includes conditions that must be met before and after execution of one or more PEE functions of the respective PEE; (ii) a specification of the platform memory and memory regions accessible for each PEE in the set of PEEs; (iii) a representation of conditions as predicates over the platform memory’s state(s) and the platform processors’ state(s), where the predicates indicate whether the platform memory’s state(s) and the platform processors’ state(s) satisfy the conditions; and (iv) enforced invariants of the ICSM at a start and at an end of each PEE function execution.

[0240] Aspect (108). The computer-implemented method of Aspect (96) further comprising acts of providing, through the mathematical model, first executable instructions for defining an initial configuration of the platform processors and an initial global platform memory state; providing, through the mathematical model, second executable instructions for executing a series of concurrent steps on each of the platform processors, wherein each step is associated with a type label indicating an operation being performed and a PEE associated with the operation; and

[0241] providing, through the mathematical model, third executable instructions for managing an internal state of each of the platform processors, including starting new threads, and assigning memory locations to each thread, wherein the ICSM is enforced by checking corresponding invariants for each PEE function call.

[0242] Aspect (109). The computer-implemented method of Aspect (108) further comprising an act of providing, through the mathematical model, a formal representation and model of a lock on a PEE function by preventing the PEE function from being called if it is already active, wherein the mathematical model requires waiting until the lock is released before proceeding with the PEE function call, and the model of the lock ensures that only one instance of the PEE function can be executed at a time across the platform processors.

[0243] Aspect (110). The computer-implemented method of Aspect (108) further comprising acts of providing, through the mathematical model, fourth executable instructions for executing an interrupt handler function within a first PEE in the set of PEEs for each of the platform processors in response to an interrupt, the interrupt handler function has its own assigned memory address space;

[0244] providing, through the mathematical model, fifth executable instructions for preemptively executing the interrupt handler function at any point in time with an assigned privilege level; and

[0245] providing, through the mathematical model, sixth executable instructions for returning control to an original interrupted PEE function after the interrupt handler function terminates.

[0246] Aspect (111). The computer-implemented method of Aspect (96), wherein the mathematical model includes a formal representation of the ICSM that further includes a memory-safety mechanism which ensures that all memory access operations are valid.

[0247] Aspect (112). The computer-implemented method of Aspect (111), wherein the formal representation of memory-safety mechanism comprises (x) a formal representation of a spatial memory safety mechanism that controls memory layout and memory access boundaries ensuring memory accesses are within valid bounds; and (y) a formal representation of a temporal memory safety mechanism that ensures that memory accesses are valid and consistent with respect to the lifetime and state of allocated memory, preventing unauthorized or erroneous memory accesses.

[0248] Aspect (113). The computer-implemented method of Aspect (96), wherein the mathematical model includes a formal representation of the ICSM that further includes a control-flow integrity mechanism that ensures that execution of PEEs by the platform processors follows authorized patterns.

[0249] Aspect (114). The computer-implemented method of Aspect (113), wherein the formal representation of control-flow integrity mechanism comprises (i) a code-safety mechanism that ensures that PEE execution by platform processors are immutable in a given memory address space; and (ii) a stack-safety mechanism that enforces the integrity of the platform processors’ state(s) for PEE execution by the platform processors.

[0250] Aspect (115). The computer-implemented method of Aspect (96), wherein

[0251] the mathematical model includes a formal representation of the ICSM that further includes a formal representation of a privilege-separation mechanism that enforces access controls on operations of the computer platform that involve peripheral access, or access to and manipulation of the platform processors’ state(s), the platform memory’s state(s), or the peripheral’s state(s); and

[0252] the access controls ensure that each of said operations is executed with a privilege level required to perform the operation.

[0253] Aspect (116). The computer-implemented method of Aspect (96), wherein the formal representation in the mathematical model further includes a peripheral of the computer platform (“platform peripheral”).

[0254] Aspect (117). The computer-implemented method of Aspect (96), wherein

[0255] the mathematical model further defines predicates for the ICSM on the computer platform that are translatable to proof obligations; and

[0256] the mathematical model includes a theorem prover to interpret and verify the proof obligations.

[0257] The foregoing is a non-limiting summary of the invention, which is defined by the attached claims.

[0258] BRIEF DESCRIPTION OF DRAWINGS

[0259] The accompanying drawings are not intended to be drawn to scale. In the drawings, each identical or nearly identical component that is illustrated in various figures may be represented by a numeral. For purposes of clarity, not every component may be labeled in every drawing. In the drawings:

[0260] FIG. 1 shows a system 100 for provably secure approved code execution 103, approved cryptographic operations 101, and approved network communication 115 on a computer platform 105, according to some embodiments;

[0261] FIG. 2 shows a system 200 comprising program execution elements (PEE) 113 that execute on a computer platform 105 in a memory address space 201 and consists of multiple functions 208, according to some embodiments;

[0262] FIG. 3 shows a system 300 for enforcing code safety where code regions 305 and procedure linkage table (PLT) regions 306 are protected in a given memory address space 201, according to some embodiments;

[0263] FIG. 4 shows a system 400 for enforcing data safety where data regions 407 containing variables 409 and global offset table (GOT) regions 406 are protected in a given memory address space 201, according to some embodiments;

[0264] FIG. 5 shows a system 500 for enforcing stack safety where code regions 305 of program execution elements 113 are protected with forward-edge CFI 504, backward-edge CFI 505 and stack canary 508, according to some embodiments;

[0265] FIG. 6 shows a time sequence diagram depicting a method 600 for stack safety with Forward Edge CFI, according to some embodiments;

[0266] FIG.7A shows a time sequence diagram depicting a method 700 for stack safety with Backward edge CFI, according to some embodiments;

[0267] FIG.7B shows a time sequence diagram depicting a method 700 for stack safety with Backward edge CFI, according to some embodiments;

[0268] FIG.8 shows a system 800 for enforcing privilege separation among multiple caller PEE 801 and Callee PEE 804 via sentinels 802 and access control matrix 805, according to some embodiments;

[0269] FIG.9 shows a system 900 for providing heap safety 903 consisting of hardened heap management 901 to protect heap memory 902, according to some embodiments;

[0270] FIG.10 shows a system 1000 for Interface Confined Security Mechanism according to some embodiments;

[0271] FIG. 11 shows a system 1100 for Approved Code Execution (ACE) provisioning mechanism, according to some embodiments; FIG. 12 shows a system 1200 for PEE file protection mechanism 1201 to provide approved code execution (ACE), according to some embodiments;

[0272] FIG. 13 shows a system 1300 for PEE load protection mechanism 1301 to provide approved code execution (ACE), according to some embodiments;

[0273] FIG. 14 shows a system 1400 for PEE execute protection mechanism 1401 to provide approved code execution (ACE), according to some embodiments;

[0274] FIG. 15 shows a system 1500 for PEE unload protection mechanism 1501 to provide approved code execution (ACE), according to some embodiments;

[0275] FIG. 16 shows a system 1600 for Approved Cryptographic Operations (ACO) provisioning mechanism according to some embodiments;

[0276] FIG. 17 shows a system 1700 for Approved Cryptographic Operations (ACO) enforcement mechanism, according to some embodiments;

[0277] FIG. 18 shows a system 1800 for Approved Network Communications (ANC) provisioning mechanism, according to some embodiments;

[0278] FIG. 19 shows a system 1900 for Approved Network Communications (ANC) enforcement mechanism, according to some embodiments;

[0279] FIG. 20 shows a system 2000 for mathematical model implementation validation mechanism according to some embodiments; and

[0280] FIG. 21 shows, schematically, an illustrative computer system 2100 on which aspects of the present disclosure may be implemented.

[0281] DETAILED DESCRIPTION

[0282] The inventors have recognized and appreciated the need for a system and methods to achieve provably secure approved code execution (ACE), approved cryptographic operations (ACO), and approved network communications (ANC) on commodity computer platforms. The system security mechanisms (SSMs) of approved code execution, approved cryptographic operations, and approved network communications are defined and proven in the mathematical model of the computer platform at design time, and enforced at runtime on individual functions of the underlying computer platform software stack implementation composed of program execution elements (PEEs).

[0283] The systems and methods may include a trusted path security mechanism (TPSM) that enforces intended patterns of computer platform operations without adversarial influence. Such computer platform operations can be one or more of memory access operations, peripheral access operations, CPU operations including execution of CPU instructions, and operations involving access and manipulation of CPU, memory or peripheral state. TPSM therefore establishes secure code execution and reliable data communication pathways between PEEs and computer platform hardware.

[0284] TPSM encompasses four key mechanisms - temporal memory safety, which ensures that memory accesses are valid and do not compromise the integrity of the system, handled via heap safety mechanisms; spatial memory safety, which ensures that data is accessed and manipulated in a secure and controlled manner, handled via data safety mechanisms; control flow integrity, which ensures that the execution of code follows a predictable and authorized path, handled via code safety and stack safety mechanisms; and privilege separation, which ensures that different components of the system operate with the appropriate level of privilege and access control. These mechanisms may be implemented, for example, in any suitable combination of hardware and software.

[0285] TPSM may be implemented in various embodiments, including combinations of hardware and software components. For example, a TPSM may be established between two software processes (e.g., Process A and Process B) that communicate via shared memory.

[0286] Alternatively, a process may invoke a set of system calls provided by the kernel to establish a TPSM. Additionally, a process may write data to a storage device (such as a disk) and read from it, with the storage device being one example of a peripheral that can be used to establish a TPSM. Other peripherals, such as networks, keyboards, or other input / output devices, may also be used.

[0287] Furthermore, a TPSM may be applied to virtual machines communicating via a hypervisor, containers communicating with each other or the host kernel, or other similar configurations. In general, a TPSM can include either pure software components or a combination of hardware and software components, such as storage devices, peripherals, or other hardware elements. The TPSM is established on the computer platform, providing a secure foundation for approved code execution, approved cryptographic operations, and approved network communications.

[0288] The system and methods may include an “Interface Confined Security Mechanism (ICSM)” that regulates interactions between potentially malicious components and the rest of the system. ICSM achieves this by designating a subset of the set of PEEs (called “Bastion PEEs (BPEE)”), to act as gatekeepers and enforce strict boundaries (called “bastion interfaces”) around computer platform resources. Bastion interfaces prevent unauthorized access to computer platform resources by potentially malicious PEEs. A key aspect of ICSM is the use of mathematical adversary modeling, which involves creating detailed models of potential attackers and their possible actions, allowing for the anticipation and mitigation of all possible non-deterministic adversarial inputs that could be directed at each bastion interface. By tying each bastion interface to a comprehensive set of potential adversarial scenarios, the ICSM can ensure that the system is resilient to even the most sophisticated and unpredictable attacks including zero-day attacks. BPEEs operate at a higher level of privilege than the potentially malicious components, ensuring that they can effectively control and monitor interactions. The overall security of the system is formally proven using a rigorous mathematical model that takes into account the complex interplay between the system's components and the potential adversaries.

[0289] ICSM can be embodied in various forms to protect different layers of a computer system. For example, in a hypervisor-based embodiment, the ICSM can be implemented as a module within the hypervisor, allowing it to regulate interactions between virtual machines and the physical hardware. In another embodiment, the ICSM can be integrated into the firmware of a device, providing an additional layer of security against malicious attacks targeting the device's low-level interfaces. Additionally, the ICSM can be implemented as a kernel module within an operating system, enabling it to enforce strict boundaries around system resources and prevent malicious applications from compromising the system.

[0290] In other embodiments, an ICSM can be applied to virtualization and containerization technologies to enhance their security. For instance, in a virtual machine-based embodiment, the ICSM can be used to regulate interactions between the guest operating system and the host environment, preventing malicious code from escaping the virtual machine and compromising the host. Similarly, in a container-based embodiment, the ICSM can be used to enforce strict boundaries around container interfaces, preventing malicious containers from accessing sensitive data or disrupting other containers within the same host. By applying the ICSM to these various technologies, it is possible to create a robust and comprehensive security framework that protects computer systems against a wide range of threats.

[0291] A subset of the set of PEEs may be implemented in low-level programming languages such as C, C++ and Assembly that offer fine-grained control over hardware resources and performance optimization capabilities, suited for systems programming, embedded systems and high-performance applications. A subset of the set of PEEs may be implemented in a high-level programming language such as Python, Rust and Java that have designed-in features of memory safety guarantees and type systems that help prevent common vulnerabilities and ensure integrity of code execution.

[0292] In some embodiments, the subset of the set of PEEs that are implemented in low-level programming languages may enforce one or more TPSM and optionally one or more of ICSM.

[0293] In some embodiments, the subset of the set of PEEs that are implemented in high-level programming languages may enforce a subset of the TPSM such as temporal memory safety and spatial memory safety.

[0294] In other embodiments, the subset of the set of PEEs that are implemented in high-level programming languages may enforce one or more TPSM and optionally one or more ICSM.

[0295] In one embodiment, a combination of the subset of PEEs implemented in low-level programming language and the subset of PEEs implemented in high-level programming language may enforce one or more TPSM and optionally one or more ICSM.

[0296] In some embodiments, the system comprises a platform including a processor, peripherals, memory, and PEEs modeled mathematically. The SSMs comprise stack safety with PEEs, data safety within PEEs, code safety within PEEs, heap safety within PEEs, privilege separation between PEEs, approved code execution of PEEs, and approved cryptographic operations by PEEs and approved network communications by PEEs.

[0297] In some embodiments, the subset of the set of PEEs that are implemented in low-level programming languages may utilize a mathematical model of the computer platform to define and prove the enforcement of one or more TPSM and optionally one or more ICSM.

[0298] In other embodiments, the subset of the set of PEEs that are implemented in high-level programming languages may utilize a mathematical model of the computer platform to define and prove the enforcement of one or more TPSM and optionally one or more ICSM.

[0299] In one embodiment, a combination of the subset of PEEs implemented in low-level programming language and the subset of PEEs implemented in high-level programming language may utilize a mathematical model of the computer platform to define and prove the enforcement of a one or more TPSM and optionally one or more ICSM.

[0300] The mathematical model specification of a computer platform may define operational aspects of the platform’s hardware elements and software stack elements via PEEs running on one or more computing processors of the computer platform. The PEEs may be composed of functions and instructions within functions as the atomic execution units. Additionally, the mathematical model further specifies the composition of the subset of PEEs implemented in low-level programming language and the subset of PEEs implemented in high-level programming language to collectively enforce one or more TPSM.

[0301] Proving the SSMs comprises analyzing the mathematical invariants to determine whether the SSMs for the computing platform are satisfied, and upon a determination that the SSM are not satisfied, analyzing the mathematical invariants to generate a counter-example that shows that the SSMs do not hold for the computing platform PEEs. In cases where the SSMs do not hold for the computer platform, the counter-example may be used to correct the mathematical model specification such that the SSMs hold for the computer platform. Analyzing the mathematical invariants to determine whether the SSMs of the computer platform are satisfied can be achieved by encoding the SSM into a computer-assisted theorem proving system and using the computer-assisted theorem proving system to analyze the mathematical invariants to determine if the SSM are satisfied.

[0302] The system can encompass a plurality of software stack entities such as firmware, hypervisor, operating system kernel, application, libraries, and extensions thereof. The SSMs can be realized on the PEEs' implementation via hardware capabilities or modifications to the program element source code which is eventually compiled to the program element binary instructions.

[0303] The system can also store platform configuration data and PEE on a non-volatile medium as system packages, which may further comprise one or more PEE source code files, one or more PEE binary executable files (“PEE binaries”), one or more PEE script executable files (“PEE scripts”), one or more configuration files that provide data for PEE and / or platform functionality, and other platform-specific configuration files. Violation of an SSM at runtime can be logged in a secure memory region and transmitted periodically using a platform signing agent to a local or remote machine.

[0304] Some embodiments provide a robust and secure way to achieve approved code execution (ACE), approved cryptographic operations (ACO), and approved network communications (ANC) on computer platforms by leveraging one or more TPSM and optionally one or more ICSM thereby ensuring the integrity and confidentiality of sensitive information. The defined SSMs provide a clear set of guidelines for implementing secure PEEs, and the use of mathematical invariants ensures that these SSMs are satisfied at runtime in the presence of a sophisticated adversary.

[0305] The system and methods described herein may be implemented on various platforms, including but not limited to, Linux, Microsoft Windows, and other operating system environments. The system may also be used to protect sensitive data stored on cloud-based storage services or other distributed computing environments.

[0306] In addition to the technical benefits, this framework provides a clear set of guidelines for developers, which ensures that their software is built with security in mind from the start. This reduces the risk of vulnerabilities and improves the overall trustworthiness of their code.

[0307] The system can be used in various industries where security is paramount, such as finance, healthcare, and government. The use of this technology will provide an added layer of protection for integrity of critical code and sensitive data and ensure that it remains confidential and secure at all times.

[0308] The following nomenclature is used herein:

[0309] Formal Representation: In the context of mathematical modeling, a formal representation refers to a mathematical or logical description of a system, process, or concept that is expressed using a rigorous, unambiguous, and well-defined syntax and semantics, allowing for automated analysis, verification, and validation. A formal representation typically involves the use of mathematical logic such as propositional logic, first-order logic or temporal logic, or other mathematical structures like graphs, automata, or algebraic equations, to describe the behavior, properties, or relationships within a system. This representation is "formal" in the sense that it adheres to a set of predefined rules, axioms, and inference mechanisms, enabling machine-based processing, reasoning, and verification, thereby ensuring accuracy, consistency, and reliability in the modeling and analysis of complex systems.

[0310] Predicate: In the context of mathematical modeling, a predicate refers to a propositional or first-order logical statement that assigns a property or attribute to an object, system, or state. Predicates are used to express conditions, relations, or constraints that must hold true for a particular situation or set of circumstances, and are often used in formal specifications, models, and proofs to reason about the behavior and properties of systems.

[0311] Proof obligations: In the context of mathematical modeling, proof obligations refer to the set of conditions or properties that must be formally proven or verified to ensure the correctness, consistency, and validity of a mathematical model or specification. These obligations typically arise from the axioms, definitions, and inference rules used in the model, and are often discharged using formal proof techniques, such as deductive reasoning, model checking, or theorem proving

[0312] Theorem prover: In the context of mathematical modeling, a theorem prover refers to a software tool or system that assists in the formal proof and verification of mathematical statements or theorems. Theorem provers use logical and mathematical rules to check the validity of a proof, ensuring that it is correct and rigorous, and providing a high degree of confidence in the results. They are often used to verify the correctness of mathematical models, specifications, and algorithms, and to establish the soundness and completeness of formal systems. Theorem provers can be completely automated (i.e., require no user intervention) or interactive (i.e., require some amount of user intervention).

[0313] Model Checker: In the context of mathematical modeling, a model checker refers to a software tool or system that automatically verifies whether a given mathematical model or system specification satisfies certain properties or requirements. Model checkers use algorithms to exhaustively explore all possible states or behaviors of the system, checking if the desired properties hold true in every case. They are often used to detect errors, inconsistencies, or flaws in system designs, protocols, or software code, and to ensure that the system behaves as intended under various operating conditions. Like theorem provers, model checkers can also be completely automated or interactive.

[0314] Assume-guarantee interface confined mathematical reasoning: A way of mathematical reasoning about a computer platform by: (a) defining what each hardware element and software stack element of the computer platform expects from other hardware elements and software stack elements (assumptions); (b) defining what each hardware element and software stack element of the computer platform promises to deliver (guarantees); and (c) ensuring these assumptions and guarantees are clearly defined at the interfaces between hardware elements and software stack elements of the computer platform.

[0315] Invariant: In the context of mathematical modeling, an invariant refers to a property or quantity that remains unchanged or constant despite transformations, changes, or perturbations to the computer platform (an “immutable property”). Invariants are used to describe and analyze the behavior of complex systems, and can include quantities such as security, liveness, energy, time or symmetry, which remain preserved over time or under different conditions.

[0316] Trace: A trace refers to a record or log of the sequence of events, such as function executions, that occur during the execution of a computer program, allowing for the observation and analysis of the program's behavior. Traces are useful in testing and verification, as it enables comparison of the actual program behavior with a mathematical model, helping to ensure that the implementation conforms to the permitted functionality.

[0317] Security Mechanism: In the context of cybersecurity, a security mechanism refers to a specific technique, protocol, or control implemented to enforce or ensure a particular security attribute or characteristic of a system, network, or asset, such as encryption for confidentiality, access controls for integrity, or firewalls for availability. Security mechanisms are designed to protect against threats or vulnerabilities and are often evaluated based on their ability to enforce desired security behavior or constraints, which may be codified in a mathematical model or specification.

[0318] Memory address: refers to a unique identifier for a specific location in memory where data can be stored or retrieved, essentially representing a single point of storage.

[0319] Memory region: is a contiguous range of memory addresses that are allocated for a particular purpose or set of data, effectively grouping multiple individual memory locations together.

[0320] Memory address space: the entire collection of memory regions available to a program or process, encompassing all the possible memory addresses it can access, thereby defining its operational boundary.

[0321] Memory: the overarching concept that encompasses all memory address spaces, representing the total capacity for storing and retrieving data across an entire system or device, including all virtual and physical storage areas.

[0322] Operational aspects: The fundamental capabilities for each of the hardware elements and the software stack elements. The operational aspects of a memory may include, for example, read, write, and execute. The operational aspects of a processor may include executing instructions and manipulating hardware registers, The operational aspects of a peripheral may include input from a keyboard, mouse, camera etc. and output to a printer, disk or other forms of storage media. The operational aspects of a program execution element may include reading file, writing to a file and read / write from / to memory and peripherals.

[0323] Program Code or Code: Program code or simply code refers to the set of instructions written in a programming language that a computer executes to perform a specific task or achieve a desired outcome. Code can either be in binary format (encoded instructions in the computer platform) or source format (encoded in a specific programming language such as C, Assembly, Java, Python or Shell scripts)

[0324] Program Execution Element (PEE): A Program Execution Element (PEE) refers to a self-contained unit of execution on the computer platform that represents a discrete environment for running code and managing computer platform resources, and enforcing security policies. A PEE can comprise a range of components, including applications, libraries, or other executable entities such as functions and objects, and may be implemented in various forms, such as a process, thread, container, virtual machine, or other isolated environment. PEEs can be composed of other PEEs, allowing for hierarchical organization and nested execution environments. Each PEE operates within its own defined boundaries, with its own set of resources, permissions, and security attributes.

[0325] PEE code region: A PEE code region or simple code region refers to a specific section or module within a PEE where certain functionality is implemented, such as data processing, authentication, or encryption, and can be defined by boundaries like functions, classes, objects, or namespaces.

[0326] Domain PEE (DPEE): A Domain PEE refers to a program execution element that operates within a contained environment, potentially executing code that is not entirely trustworthy. Domain PEEs may execute a wide range of code, including applications, services, or other programs, and are designed to be isolated from sensitive system components to prevent potential security breaches.

[0327] Bastion PEE (BPEE): A Bastion PEE (BPEE) refers to a program execution element that is designed to be highly secure and trustworthy, responsible for enforcing system security mechanisms and protecting against adversarial tampering. A BPEE acts as a robust guardian of the system, ensuring the integrity and confidentiality of sensitive data and computations. BPEEs are typically responsible for managing and overseeing other program execution elements, including Domain PEEs.

[0328] Keystone PEE (KPEE): A Keystone PEE refers to a specialized program execution element within the set of Bastion PEEs that is responsible for establishing the fundamental security mechanisms of the system. KPEEs perform critical functions such as setting up memory protections, configuring CPU state, and initializing other essential security mechanisms. These PEEs provide the base layer of security upon which the rest of the system relies, ensuring the integrity and trustworthiness of the environment.

[0329] Trusted Path Security Mechanism (TPSM): A security mechanism that enforces intended patterns of computer platform operations without adversarial influence. Such computer platform operations can be one or more of memory access operations, peripheral access operations, CPU operations including execution of CPU instructions, and operations involving access and manipulation of CPU, memory or peripheral state. TPSM therefore establishes secure code execution and reliable data communication pathways between PEEs and computer platform hardware, ensuring adversary-free, reliable and trustworthy interaction. Interface Confined Security Mechanism (ICSM): An Interface Confined Security Mechanism (ICSM) regulates interactions between potentially malicious components and the rest of the system. ICSM achieves this by designating a subset of the set of PEEs, to act as gatekeepers and enforce strict boundaries (called “bastion interfaces”) around computer platform resources. A key aspect of ICSM is the use of mathematical adversary modeling, which involves creating detailed models of potential attackers and their possible actions, allowing for the anticipation and mitigation of all possible non-deterministic adversarial inputs that could be directed at each bastion interface.

[0330] Low-level programming language: Low-level programming languages, such as C, C++, and Assembly, offer fine-grained control over hardware resources and performance optimization capabilities, making them well-suited for systems programming, embedded systems, and high-performance applications. However, this level of control also comes with inherent security risks due to the lack of built-in memory safety features, type checking, and error handling mechanisms, making them more susceptible to vulnerabilities like buffer overflows, data corruption, and exploitation by malicious code.

[0331] High-level programming language: High-level programming languages such as Rust, Python and Java provide a foundation for building secure software systems by offering features such as memory safety guarantees, type systems, and formal verification mechanisms that help prevent common vulnerabilities and ensure the integrity of code execution. Additionally, many high-level programming languages also incorporate low-level programming language runtime components, such as C or Assembly code, to optimize performance, interact with hardware resources, or leverage existing libraries and frameworks, which can introduce potential security risks if not properly managed and isolated.

[0332] System Package: System packages refer to collections of PEEs, including executables, libraries, scripts, and configuration files, that are necessary for the execution of a program or application on a computer platform. These PEEs may include operating system components, device drivers, firmware, and other software elements that enable the execution of a program or application. System packages provide a structured way to manage and distribute these PEEs, ensuring that all necessary elements are present and correctly configured for PEE execution.

[0333] Some of the disclosed embodiments provide advantages over traditional systems and methods of securing computer platforms:

[0334] 1. Provably secure approved code execution, approved cryptographic operations, and approved network communications: By enforcing SSMs at runtime, the technology ensures that only authorized code is executed on the computer platform, only authorized cryptographic operations are performed, and only authorized network communications are taking place. This provides immunity against ransomware and remote code execution attacks in addition to entire classes of memory and data ex-filteration based attacks. 2. Mathematical Modeling and Provable Security: The use of mathematical modeling incorporating adversarial modeling and computer-assisted theorem proving enables formal verification and validation of the SSMs, ensuring that they are satisfied at runtime in the presence of a sophisticated adversary. This provides a high level of confidence in the correctness and security of the system, reducing the risk of vulnerabilities and improving overall trustworthiness.

[0335] 3. Fine-grained control over code execution and data access: The use of PEEs enables finegrained control over code execution and data access, allowing for more precise enforcement of SSMs and reducing the attack surface. This provides a high level of flexibility and customization in implementing security policies, making it easier to adapt to changing threat landscapes and regulatory requirements.

[0336] 4. Centralized management and configuration of system settings: The technology enables centralized management of authorized configuration of system settings, making it easier to maintain consistency across multiple systems and reduce the risk of misconfiguration. FIGs. 1-20 show diagrams for some embodiments of the systems and methods described herein. For purposes of discussion each of the diagrams is referred to as a system, however, it should be appreciated that discussed systems may also be implemented through corresponding methods. Some embodiments of the disclosed diagrams (whether through systems or methods) may not include all of the blocks shown in the corresponding diagram, or may include other blocks / steps not represented in the diagrams.

[0337] Each of the diagrams include blocks (e.g., blocks 101 and 102 in FIG. 1) and connecting lines (e.g., connecting line 151 in FIG. 1). Each block may represent, for example, stored information (e.g., a definition for a peripheral), an aspect of a method (e.g., a method step), or a module of the corresponding system. A module comprises the hardware and / or software, to implement a defined capability (e.g., the corresponding method step). For example, such a capability may be implemented through a module having one or more processors executing computer code stored on one or more non-transitory computer-readable storage medium. In some embodiments, a capability is implemented at least in part through a module having dedicated hardware (e.g., an ASIC, an FPGA). In some embodiments modules may share components. For example, a first function module and a second function module may both utilize a common processor (e.g., through time-share or multithreading) or have computer executable code stored on a common computer storage medium (e.g., at different memory locations). In some instances, a module may be identified as a hardware module or a software module. A hardware module includes or shares the hardware for implementing the capability of the module. A hardware module may include software, that is, it may include a software module. A software module comprises information that may be stored, for example, on a non-transitory computer-readable storage medium. In some embodiments, the information may comprise instructions executable by one or more processors. In some embodiments, the information may be used at least in part to configure hardware such as an FPGA. The capability of a software module may be implemented, for example, by reading the software module from a storage medium and executing it with one or more processors, or by reading the software module from a storage medium and using the information to configure hardware. “Mechanism” is used herein synonymously with module.

[0338] The relationship between blocks is illustrated by connecting lines. The termination of a connecting line indicates whether there may be multiple instances of a block present in the illustrated embodiment. Specifically, the symbol 002 (FIG. 1) indicates that the connection is to a single functional block while the symbol 003 indicates that the connection may be to multiple functional blocks. For example, connecting line 154 connects a single mathematical model 102 to one or more programs 107. Unless explicitly stated otherwise, a connection with the symbol 002 is the starting point of the flow while the symbol 003 is the ending point of the flow for a given connecting line. For example, the flow of connecting line 154 is from the mathematical model 102 to programs 107. For some connecting lines, the starting point of the flow is indicated via a shaded circle symbol 001. For example, connecting line 159 connects heap safety 106 to code safety 109 and is read as one or more heap safety 106 builds on one or more code-safety 109. Solid connecting lines such as connection line 151 represent flow, interaction and dependency between various functional blocks. The symbol 004 (FIG. 2) indicates that the connection is to zero or more of a nested functional block. For example, connecting line 262 connects Domain PEE 205 to Domain PEE 205 and is read as one or more Domain PEE 205 comprises zero or more nested Domain PEE 205.

[0339] There are several types of connection lines. A “builds-on” connecting line (e.g., connecting line 151, FIG. 1) indicates that one component (e.g., a software module or cryptographic primitive) utilizes, extends, or relies on the functionality, security guarantees, or trust assumptions provided by another component, establishing a dependency or inheritance relationship between them. An "enforces" connecting line (e.g., connecting line 153, FIG. 1) indicates that one component (e.g., a security policy or access control mechanism) imposes restrictions, constraints, or rules on another component, ensuring compliance with specific security requirements or regulations. A "models" connecting line (e.g., connecting line 154, FIG.

[0340] 1) indicates that one component (e.g., a formal specification or mathematical representation) provides an abstract or conceptual representation of another component, capturing its behavior, properties, or characteristics. A "contains" connecting line (e.g., connecting line 165, FIG. 1) indicates that one component (e.g., a data structure or container) holds, includes, or comprises another component, establishing a hierarchical or compositional relationship between them. An "accesses" connecting line (e.g., connecting line 167, FIG. 1) indicates that one component (e.g., a software process or thread) interacts with, retrieves data from, or manipulates another component, establishing a communication or data exchange relationship between them. A "uses" connecting line (e.g., connecting line 152, FIG. 1) indicates that one component (e.g., an application or service) utilizes, invokes, or depends on the functionality, services, or resources provided by another component, establishing a dependency or utilization relationship. A "proves" connecting line (e.g., connecting line 157, FIG. 1) indicates that one component (e.g., a formal proof or verification tool) demonstrates, validates, or establishes the correctness, soundness, or security of another component, providing a guarantee or assurance about its properties or behavior. A "source-embedding" connecting line (e.g., connecting line 162, FIG. 1) indicates that one component (e.g., a software library, capability or framework) is integrated, embedded, or incorporated into the source code of another component, establishing a tight coupling or integration relationship between them. A "binary-embedding" connecting line (e.g., connecting line 163, FIG. 1) indicates that one component (e.g., a cryptographic key, watermark or capability) is embedded, inserted, or encoded into the binary representation of another component, establishing a binding or tamper-evidence relationship between them.

[0341] A "comprises" connecting line (e.g., connecting line 251, FIG. 2) indicates that one component (e.g., a system, module, or framework) is composed of, consists of, or is made up of another component, establishing a whole-part or aggregation relationship between them, where the comprising component is the container or aggregate and the comprised component is the contained part.

[0342] A "loads" connecting line (e.g., connecting line 358, FIG. 3) indicates that one component (e.g., a loader or bootstrapper) initializes, instantiates, or brings into memory another component, such as a software module, library, or executable, making it available for execution or use. A "protects" connecting line (e.g., connecting line 361, FIG. 3) indicates that one component (e.g., a security mechanism, encryption algorithm, or access control system) safeguards, shields, or defends another component from unauthorized access, tampering, or other potential threats, ensuring its confidentiality, integrity, or availability.

[0343] An "encapsulated-by" connecting line (e.g., connecting line 471, FIG. 4) indicates that one component (e.g., a data object, software module, or cryptographic key) is wrapped, enclosed, or hidden by another component, which controls access to it, manages its interactions, and provides a layer of abstraction or isolation, thereby shielding the encapsulated component from external interference or unauthorized access. A “bounded-by” connecting line (e.g., connecting line 473, FIG. 4) indicates that one component (e.g., a data variable or array) is limited or constrained in access by another component (e.g., a security mechanism or an enforcement mechanism).

[0344] A "reference" connecting line (e.g., connecting line 559, FIG. 5) indicates that one component (e.g., a software module, document, or knowledge base) makes a citation, allusion, or pointer to another component, establishing a connection or relationship between them, where the referencing component acknowledges, relies on, or provides additional context about the referenced component. An "embedded-within" connecting line (e.g., connecting line 551, FIG.

[0345] 5) indicates that one component (e.g., a software library, data object, or cryptographic primitive) is intimately integrated, inserted, or interwoven into the internal structure or implementation of another component, such that the embedded component becomes an integral part of the containing component, and its presence is essential to the overall functionality or security of the container.

[0346] A "calls" connecting line (e.g., connecting line 851, FIG. 8) indicates that one component (e.g., a software routine, function, or method) invokes, requests, or triggers the execution of another component, passing control and potentially data to it, in order to leverage its functionality or services. A “transfers-control-to" connecting line (e.g., connecting line 853, FIG. 8) indicates that one component (e.g., a program counter, exception handler, or interrupt handler) relinquishes control or redirects the flow of execution to another component, which then assumes responsibility for continued processing or handling. A "return" connecting line (e.g., connecting line 856, FIG. 8) indicates that one component (e.g., a function, subroutine, or method) passes control back to another component that had previously invoked it, potentially also returning data or results, in order to resume execution or complete a task. An "implemented- by" connecting line (e.g., connecting line 857, FIG. 8) indicates that one component (e.g., a specification, interface, or abstract concept) is concretely realized, instantiated, or put into practice by another component, which provides a tangible implementation or embodiment of the specified behavior or functionality. A "consults" connecting line (e.g., connecting line 854, FIG.

[0347] 8) indicates that one component (e.g., a decision-making process, expert system, or query engine) seeks guidance, advice, or information from another component, which provides input, expertise, or data to inform or influence the consulting component's actions or decisions. An "implemented-in" connecting line (e.g., connecting line 859, FIG. 8) indicates that one component (e.g., an algorithm, protocol, or data structure) is put into practice, coded, or expressed using another component, such as a programming language, hardware platform, or software framework, which provides the underlying infrastructure or medium for implementation.

[0348] A "manages" connecting line (e.g., connecting line 951, FIG. 9) indicates that one component (e.g., a controller, administrator, or orchestrator) oversees, directs, or regulates another component, exercising control over its behavior, configuration, or resources to achieve specific goals or ensure proper functioning. A "provides" connecting line (e.g., connecting line 953, FIG. 9) indicates that one component (e.g., a service, supplier, or repository) makes available, offers, or furnishes something of value, such as data, functionality, or capabilities, to another component, which can then utilize or benefit from the provided resource. An "implemented-as" connecting line (e.g., connecting line 954, FIG. 9) indicates that one component (e.g., an abstract concept, specification, or high-level design) is realized or instantiated in a specific form or manifestation, such as a software implementation, hardware embodiment, or concrete data structure, which embodies the essential characteristics and behaviors of the original component. An "ensures" connecting line (e.g., connecting line 952, FIG. 9) indicates that one component (e.g., a security mechanism, validation protocol, or quality assurance process) guarantees, certifies, or makes certain that another component meets specific requirements, standards, or properties, such as correctness, safety, or compliance, thereby providing confidence or trust in the ensured component's behavior or output.

[0349] A "derives" connecting line (e.g., connecting line 1051, FIG. 10) indicates that one component (e.g., a data object or value) is obtained, calculated, or inferred from another component, which serves as its basis, source, or foundation. A “parameterizes” connecting line (e.g., connecting line 1052, FIG. 10) indicates that one component (e.g., a software module, mathematical model or algorithm) is configured, customized, or controlled by another component, which provides input values, settings, or constraints that influence its behavior or output. An “implement” connecting line (e.g., connecting line 1057, FIG. 10) indicates that one component (e.g., a software module or system) realizes, fulfills, or carries out the functionality, interface, or requirements of another component, which defines its purpose, behavior, or contract.

[0350] An "outputs" connecting line (e.g., connecting line 2072, FIG. 20) indicates that one component produces or provides data, results, or information to another component, which can then use or process this output for further computation or decision-making. An "invokes" connecting line (e.g., connecting line 2059, FIG. 20) indicates that one component activates, triggers, or calls upon another component to perform a specific task, operation, or function, potentially passing input parameters or data to it. A "constrains" connecting line (e.g., connecting line 2070, FIG. 20) indicates that one component limits, restricts, or imposes conditions on the behavior, functionality, or performance of another component, which must then operate within these constraints to achieve its objectives. A "run-on" connecting line (e.g., connecting line 2066, FIG. 20) indicates that one component is executed or operates on a specific platform, infrastructure, or environment provided by another component, which enables the running component to function correctly and efficiently. A "generates" connecting line (e.g., connecting line 2057, FIG. 20) indicates that one component creates, produces, or synthesizes new data, content, or information from input parameters, algorithms, or other sources, which can then be used by other components for further processing or analysis. A "validates" connecting line (e.g., connecting line 2061, FIG. 20) indicates that one component checks, verifies, or ensures the correctness, accuracy, or consistency of data, information, or results produced by another component, which helps to maintain data integrity and prevent errors. An "specifies" connecting line (e.g., connecting line 2068, FIG. 20) indicates that one component defines, describes, or prescribes the requirements, characteristics, or behavior of another component, which must then conform to these specifications to meet its intended purpose or functionality.

[0351] FIG. 1 shows a system 100 for provably secure approved code execution 103, approved cryptographic operations 101, and approved network communication 115 on a computer platform 105.

[0352] In system 100 computer platform 105 contains (see connecting line 169) one or more Program Execution Elements (PEE) 113, one or more devices 111 (see connecting line 165), and one or more memory 112 (see connecting line 166). Computer platform 105 is modeled in a mathematical model 102 (see connecting line 155). Mathematical model 102 enforces one or more SSMs 114 (see connecting line 153) and uses one or more theorem provers 104 (see connecting line 156) to prove SSMs 114 (see connecting line 157). Mathematical model 102 also models PEEs 113 (see connecting line 154). PEE 113 accesses both memory 112 (see connecting line 167) and devices 111 (see connecting line 168). SSMs 114 consist of stack Safety 110, code Safety 109, data safety 108, heap safety 106, Privilege separation 116, Approved code execution 103, approved cryptographic operations 101, and approved network communications 115 (For the sake of readability of FIG. 1, no connecting lines are drawn for these relationships.). Stack safety 110 may be embedded in source into PEE 113 (see connecting line 162) or embedded in binary into PEE 113 (see connecting line 163). Code safety 109 and data safety 108 build on stack safety 110 (see connecting lines 161 and 160, respectively) and the corresponding source or binary embeddings. Heap safety 106 further builds on code safety 109 and data safety 108 (see connecting lines 159 and 158, respectively). Privilege separation 116 builds on heap safety 106 (see connecting line 171). Approved code execution 103 builds on Privilege separation 116 (see connecting line 170). approved cryptographic operations 101 builds on approved code execution 103 (see connecting line 151). Finally, approved network communication 115 builds on approved code execution 103 and approved cryptographic operations 101 (see connecting lines 172 and 173, respectively).

[0353] PEEs 113 are self-contained units of code that execute independently within their own memory address space, providing a sandboxed environment to isolate application code from firmware, hypervisors, and other PEEs. This separation of concerns enables robust security, finegrained control over code execution, and efficient management of program execution, making it an ideal solution for developing secure by design software applications.

[0354] Code Safety 109 ensures that programming instructions constituting the execution flow of the PEE are immutable and cannot be modified or altered after they have been loaded into memory, thereby preventing accidental or malicious modifications that could compromise PEE execution integrity.

[0355] Data safety 108 protects sensitive information stored in global data variables, as well as the integrity of the global offset table (GOT), by surrounding each variable definition with guard memory regions, which serve as a protective layer against unauthorized modifications.

[0356] Stack safety 110 protects PEEs from stack-based attacks by introducing a function typehash comparison, meta-stack mechanism, validating branch or jump targets, and aligning them correctly to prevent attackers from exploiting misaligned jumps. Privilege separation 116 ensures secure execution by segregating and controlling all function calls within a PEE domain, enforcing strict access control policies and validating each function call to prevent unauthorized access or escalation of privileges.

[0357] Heap safety 106 provides a robust defense against malicious activities aimed at compromising the integrity and security of the computer system's heap memory management by implementing various protection mechanisms, including memory block tracking, reference counting, memory pooling, and heap layout randomization. These measures collectively prevent common heap-related vulnerabilities such as use-after-free (UAF), heap overflow (OF), doublefree (DF), heap metadata tampering (MDT), and lazy deallocation (LDA) attacks.

[0358] Approved code execution 103 provides a robust defense against unauthorized code execution and remote code execution attacks by implementing various protection mechanisms, including digital signatures, hash functions, and memory management controls. This approach ensures that only authorized software components are loaded onto the system, executed in a controlled environment, and securely managed to maintain the integrity and security of the system.

[0359] Approved cryptographic operations 101 provides a highly secure solution for protecting sensitive information on computer platforms by utilizing an encryption provisioning PEE to provision and re-provision the platform for authorized encryption, and an encryption enforcement PEE that ensures authorized encryption is enforced at all times during platform runtime. This robust solution safeguards against ransomware attacks and meets compliance requirements with regulatory standards related to data protection and security, such as GDPR, HIPAA, and PCI-DSS.

[0360] Finally, approved network communications 115 provides a secure and trustworthy networking solution by implementing a robust set of controls and protections that ensure all network interactions are authorized and encrypted. This robust solution safeguards against data-exfiltration attacks and various classes of network-based attacks.

[0361] These aspects may make some embodiments an attractive solution for use in a wide range of applications, including but not limited to financial services, healthcare, education, government, and e-commerce.

[0362] Program Execution Elements (PEE)

[0363] In modern computing systems, multiple software components coexist and interact with one another to provide a seamless user experience. At the lowest level, firmware is responsible for initializing and configuring hardware components, such as memory management, VO operations, and clocking. Firmware executes directly on the hardware, providing a bridge between the physical components and the operating system.

[0364] The next layer up is the hypervisor, also known as a virtual machine monitor, which creates and manages multiple virtual machines that run isolated OS instances. A hypervisor can be thought of as a "host" for multiple OS guests, allowing them to share the same physical hardware resources while maintaining separate execution environments. Above the hypervisor, one or more operating systems are installed, which provide a runtime environment for applications and system services. Within these operating systems, additional isolation mechanisms such as containers and namespaces can be used to further segregate applications and services, providing an extra layer of security and resource management.

[0365] However, current computing systems have several limitations and vulnerabilities due to their layered architecture. For instance, firmware and hypervisors can be vulnerable to attacks, as they often rely on outdated code and lack robust security features. Moreover, the complexity of modern operating systems makes it challenging to develop secure and efficient software applications.

[0366] FIG. 2 shows a system 200 comprising PEEs 113 that executes on a computer platform 105 (see FIG. 1) in a memory address space 201. In system 200 each PEE 113 executes across one or more memory address spaces 201 (see connecting line 264). PEE 113 may comprise one or more of Bastion PEE (BPEE) 204 (see connecting line 255) and one or more of Domain PEE (DPEE) 205 (see connecting line 253). DPEEs 205 are PEEs that operate within a memory address space 201 potentially executing code that is not entirely trustworthy. BPEEs 204 are PEEs that are designed to be highly secure and trustworthy, responsible for enforcing system security mechanisms and protecting against adversarial tampering. BPEEs act as a robust guardian of the system, ensuring the integrity and confidentiality of sensitive data and computations. BPEEs are typically responsible for managing and overseeing other program execution elements, including DPEEs 205.

[0367] DPEEs 205 are typically managed and overseen by Bastion PEEs 204, which provide protection and oversight to prevent malicious behavior. Domain PEEs may execute a wide range of code, including applications, services, or other programs, and are designed to be isolated from sensitive system components to prevent potential security breaches.

[0368] One or more BPEEs 204 comprises one or more Keystone PEE (KPEE) 207 (see connecting line 258). KPEEs are PEEs that ensure fundamental security mechanisms of the system. KPEEs perform critical functions such as setting up memory protections, configuring CPU state, and initializing other essential security mechanisms. KPEEs provide the base layer of security upon which the rest of the system relies, and establish and maintain the constrained environment of DPEEs 205, ensuring the integrity and trustworthiness of the environment.

[0369] One or more BPEEs 204, DPEEs 205 and KPEEs 207 may further comprise (see connecting lines 257, 259 and 263 respectively) one or more functions 208 that addresses the aforementioned limitations. PEE functions 208 comprise public and private functions that perform initialization, service interrupts and handle regular processing.

[0370] In addition to containing functions, program execution elements (PEEs) can also be composed of other nested PEEs, allowing for a hierarchical organization of execution environments. One or more DPEEs may comprise zero or more nested DPEEs (see connecting line 262) and may comprise zero or more nested BPEEs (see connecting line 264). One or more BPEE may comprise zero or more nested BPEEs (see connecting line 265) and may comprise zero or more nested DPEEs (see connecting line 252). Similarly, one or more KPEE may comprise zero or more nested DPEEs (see connecting line 266). This nested structure enables complex scenarios where a PEE acts as a host or container for other PEEs, each potentially executing its own set of functions or further nested PEEs. An exemplary embodiment of such an organization is a PEE that represents a host kernel executing another PEE, which in turn is a container under the Linux operating system. This container PEE can then host a set of process PEEs that execute within the confines of the container, illustrating a layered approach to program execution where each layer is a distinct PEE. This capability to embed PEEs within one another facilitates flexible and efficient management of computational resources, enabling the present invention to support a wide range of application scenarios, from simple function executions to complex, distributed computing environments.

[0371] In system 200, each PEE 113 provides a sandboxed environment that isolates application code from firmware, hypervisors, and other PEEs. This separation of concerns enables robust security.

[0372] KPEEs 207 have the highest privilege in a given memory address space 201. BPEE 204 has a lower privilege than a KPEE 207 and may house operating kernels or hypervisors as well as dependent libraries in a given memory address space. Finally, DPEE 205 has a lower privilege level than both KPEE and BPEE and may house applications and supporting libraries. KPEEs 207 are responsible for loading other PEEs in a given memory address space.

[0373] PEEs 113 may further comprise one or more functions 208, which form the atomic unit of functionality of the PEE. Each function can be a standalone entity that performs specific tasks or operations within the PEE. PEE functions 208 further comprises one or more initialization functions that are responsible for initializing the PEE, one or more interrupt functions to handle platform device interrupts, providing a way to interact with hardware elements and a set of regular functions that together accomplish PEE functionality. Public functions can be called from functions of other PEE objects, enabling inter-PEE communication and collaboration. Private functions are only callable from functions within the said PEE object, ensuring secure access control.

[0374] PEE functions 208 can be embodied in various forms depending on the type of PEE. For example, if the PEE is a container, the public initialization function may be the container's first process main function, the public interrupt function may be the namespace interrupt handler, and the public regular functions may be container sockets providing services or named pipes or shared memory for inter-container communication. Similarly, if the PEE is a virtual machine (VM), the public initialization function can be the VM entry point, the public interrupt function can be the VM interrupt handler stubs, and the public regular functions can be VM downcalls or socket endpoints or shared memory. If the PEE is an operating system (OS) kernel, the public initialization function may be the kernel init function, the public interrupt functions may be kernel interrupt handlers, and the public regular functions may be kernel-provided system calls. If the PEE is a hypervisor, then the public initialization function may be the hypervisor init function, the public interrupt functions may be hypervisor interrupt handlers, and the public regular functions may be hypervisor-provided hypercalls. Finally, if the PEE is firmware, the public initialization function may be the firmware init function, the public interrupt functions may be firmware machine interrupt handlers, and the public regular functions may be firmware support calls (e.g., BIOS calls). In all cases, the PEE's private functions are isolated to be only invoked within the PEE and may be a single monolithic function or a group of functions spanning applications, libraries, etc.

[0375] PEE memory regions in a given memory address space 201 comprises one or more code regions that contain PEE functions. PEE global data variables can be accessed by all parts of the PEE, retaining their values even after function execution has completed. Heaps provide dynamic memory areas for allocating memory to store variables whose size may vary. Stacks store temporary data that may be quickly used and discarded such as function parameters, local variables, and return addresses.

[0376] Procedure linkage table (PLT) entries and GOT entries are critical components of a PEE's memory regions. PLT entries contain addresses to functions, allowing for dynamic function resolution at runtime by looking up the correct address in the PLT. GOT entries keep track of the memory locations of global variables and other initialized data symbols within an element program.

[0377] The operational semantics of a PEE functions further comprise reading and / or writing to global variables, reading and / or writing to stack, reading and / or writing to heap, allocating and freeing heaps, calling other PEE functions within the PEE or across PEEs within a memory address space and across memory address spaces, and returning to parent PEE function.

[0378] The randomized PEE memory map in a given address space ensures that the layout of PEE components is randomized each time the PEE loads into memory. This randomization mitigates various types of attacks and vulnerabilities by making it challenging for attackers to predict and exploit specific memory locations.

[0379] The system architecture may be implemented on various computer platforms, including x86, ARM, and RISC-V architectures running various operating systems such as Windows, Linux, FreeBSD etc. For example, on an x86 platform running Windows, the KPEE 207 can provide a secure boot-strapping environment for the Windows operating system and the BPEE 204 can house the Windows kernel, while the KPEE ensures that other applications are loaded and executed in respective DPEEs.

[0380] In some embodiments, the DPEE comprises a banking application that requires secure data storage and retrieval mechanisms. The BPEE provides the secure base operating environment and provides additional security features for the banking application, such as encryption and decryption services. The KPEE can ensure that only authorized DPEEs are loaded into memory to prevent unauthorized access to sensitive data.

[0381] In a further embodiment of the invention, the system architecture can be used to develop distributed applications. For example, a DPEE can comprise a web browser application that requires secure communication mechanisms with a server-side DPEE to retrieve and display web content. The BPEE provides the secure base operating environment on both server and client and provides additional security features for the web browser application, such as encryption and decryption services.

[0382] The system architecture may provide a more secure, efficient, and flexible way to develop secure by design software applications. By separating program execution into different PEEs, mathematically modeling their operational semantics, and ensuring each component's isolation, the proposed system addresses several limitations and vulnerabilities inherent in traditional computing systems. Trusted Path Security Mechanism (TPSM)

[0383] The systems and methods may include a Trusted Path Security Mechanism (TPSM) that enforces permitted patterns of computer platform operations without adversarial influence. Such computer platform operations can be one or more of memory access operations, peripheral access operations, CPU operations including execution of CPU instructions, and operations involving access and manipulation of CPU, memory or peripheral state. TPSM therefore establishes secure code execution and reliable data communication pathways between PEEs and between PEEs and computer platform hardware.

[0384] TPSM may be embodied in various configurations involving PEEs 113, offering a flexible and robust security solution. In different embodiments, TPSM can span multiple PEEs, both within and across individual PEEs, as well as between PEEs and computer platform hardware. For instance, TPSM can be established between public and private functions 208 of Keystone PEEs (KPEEs) 207 or Bastion PEEs (BPEEs) 204, enabling secure communication within these trusted environments. Additionally, TPSM can facilitate secure interactions between public functions 208 of KPEEs 207, BPEEs 204, and Domain PEEs (DPEEs) 205, allowing for protected data exchange across different types of PEEs. Furthermore, TPSM can be implemented between DPEEs 205 themselves, ensuring secure communication among these elements. The scope of TPSM is not limited to interactions between PEEs, as it can also be established between PEE functions 208 and computer platform devices 111, providing an end-to-end security solution that bridges the gap between software and hardware components. By supporting various configurations and spanning multiple PEEs and hardware components, TPSM provides a comprehensive security mechanism that can be tailored to meet the specific needs of different applications and systems.

[0385] TPSM encompasses four key mechanisms - temporal memory safety, which ensures that memory accesses are valid and do not compromise the integrity of the system, handled via heap safety mechanisms; spatial memory safety, which ensures that data is accessed and manipulated in a secure and controlled manner, handled via data safety mechanisms; control flow integrity, which ensures that the execution of code follows a predictable and authorized path, handled via code safety and stack safety mechanisms; and privilege separation, which ensures that different components of the system operate with the appropriate level of privilege and access control. These mechanisms may be implemented, for example, in any suitable combination of hardware and software. TPSM may be implemented in various embodiments, including combinations of hardware and software components. For example, TPSM may be established between two PEEs (e.g., PEE A and PEE B) that communicate via shared memory regions. Alternatively, a PEE at a lower privilege level may invoke a set of functions provided by a PEE executing at a higher privilege level to establish a TPSM. Additionally, a PEE may write data to a storage device (such as a disk) and read from it, with the storage device being one example of a peripheral that can be used to establish a TPSM. Other peripherals, such as networks, keyboards, or other input / output devices, may also be used.

[0386] In one embodiment, TPSM may involve virtual machines communicating via a hypervisor and containers communicating with each other or the host kernel,

[0387] A subset of the set of PEEs may be implemented in low-level programming languages such as C, C++ and Assembly that offer fine-grained control over hardware resources and performance optimization capabilities, suited for systems programming, embedded systems and high-performance applications. A subset of the set of PEEs may be implemented in a high-level programming language such as Python, Rust and Java that have designed-in features of memory safety guarantees and type systems that help prevent common vulnerabilities and ensure integrity of code execution.

[0388] In some embodiments, the subset of the set of PEEs that are implemented in low-level programming languages may enforce one or more TPSM.

[0389] In other embodiments, the subset of the set of PEEs that are implemented in high-level programming languages may enforce one or more TPSM.

[0390] In some embodiments, the subset of the set of PEEs that are implemented in high-level programming languages may enforce a subset of the TPSM such as temporal memory safety and spatial memory safety.

[0391] In one embodiment, a combination of the subset of PEEs implemented in low-level programming language and the subset of PEEs implemented in high-level programming language may enforce one or more TPSM.

[0392] PEE Code Safety mechanism

[0393] PEE code safety mechanism ensures that the programming instructions constituting the execution flow of the PEE cannot be modified or altered after they have been loaded into memory. This mechanism ensures that the original code remains unchanged, preventing accidental or malicious modifications that could compromise PEE execution integrity. PEE code-safety mechanism also facilitates auditing and debugging, as any errors or issues can be traced back to their original source without fear of subsequent modifications obscuring the problem.

[0394] FIG. 3 shows a system 300 for enforcing code safety. System 300 includes code regions 305 and PLT regions 306 that are protected in a given memory address space 201. In system 300, one or more memory address space 201 contains one or more Keystone PEE (KPEE) 207 (see connecting line 353), one or more Bastion PEEs (BPEE) 204 (see connecting line 351), and one or more Domain PEEs (DPEE) 205 (see connecting line 352). One or more KPEE 207 protects one or more PLT regions 306 (see connecting line 361), contains one or more PLT regions 306 (see connecting line 360), loads one or more DPEEs 205 (see connecting line 358), contains one or more code regions 305 (see connecting line 355) and loads one or more BPEEs 204 (see connecting line 356).

[0395] In system 300, the one or more DPEEs 205 contain one or more PLT regions 306 (see connecting line 370) as well as one or more code regions 305 (see connecting line 369). The one or more BPEEs 204 similarly contain one or more PLT regions 306 (see connecting line 368) as well as one or more code regions 305 (see connecting line 367).

[0396] System 300 ensures that only authorized code is loaded and executed from memory and that their code regions 305 are marked read-only. This is accomplished through the use of memory protections for various PEEs 113 (see FIGs. 1 and 2), including the KPEEs 207, BPEEs 204, and DPEEs 205.

[0397] The memory protections may be implemented using hardware capabilities and the configuration of a computer platform memory management unit (MMU) and / or one or more I / O memory management unit (IOMMU) and DMA controllers. IOMMUS are special purpose MMUs that help setting memory protections against Direct Memory Access (DMA) from peripherals. Similarly, DMA controllers are special purpose peripherals accessed from the platform processor that controls DMA from the rest of the peripherals in the computer platform.

[0398] In some embodiments of system 300, a higher privileged KPEE 207 configures the MMU, IOMMU and DMA controllers at a different memory address space to set code regions 305 as read-only, thereby preventing unauthorized modifications to the code regions 305.

[0399] Alternatively, software based verification and / or software fault isolation may be used within the PEE 113 source code or binary code to enforce these protections. This ensures that only authorized modifications are made to the code regions, thereby preventing malicious activities such as malware execution or code tampering. The same approach is applied to the BPEEs 204 and DPEEs 205, where either hardware capabilities and platform MMU, IOMMU and / or DMA controller configuration set by KPEE 207 within the same memory address space 201 or a higher-privileged KPEE 207 within a different memory address space 201 are used to set code regions 305 as read-only. Alternatively, software based verification and / or software fault isolation is enforced within BPEE 204 and DPEE 205 source code or binary code. The aforementioned approach may be applied, for example, to all PEEs 113 in system 300.

[0400] Furthermore, PLT regions 206 of PEEs 113 is also memory -protected to be read-only. A PLT is a data structure in an executable file that contains information about the procedures (herein “functions”) that can be called by the program. From a security perspective, PLTs are crucial because they provide a potential attack vector for malicious code injection and hijacking of control flow. If an attacker can modify the PLT to point to malicious code, they can execute arbitrary instructions within the compromised process, potentially leading to privilege escalation or other serious security vulnerabilities.

[0401] System 300 may accomplish PLT memory protections, for example, through hardware capabilities and platform MMU, IOMMU and / or DMA controller configuration by the KPEE 207 within the same memory address space 201 or a higher-privileged KPEE 207 within a different memory address space 201, or alternatively, through software based verification and / or software fault isolation enforced within the PEE 113 source code or binary code.

[0402] By implementing these memory protections on the PLT of various PEEs 113, including the KPEE 207, BPEE 204, and DPEE 205, system 300 may ensure that authorized code, once loaded into memory, cannot be tampered with.

[0403] PEE Data Safety mechanism

[0404] The GOT and global data variables are critical components of a PEE memory layout, playing a vital role in the execution of functions and access to shared data. The GOT is a special section of the PEE memory region that contains pointers to the locations of external libraries or functions, allowing the PEE to dynamically link to them at runtime. Global data variables, on the other hand, are shared among multiple functions within the same PEE, storing valuable information such as configuration settings, authentication credentials, or sensitive user data. Securing these components is essential because they represent a high-value target for attackers seeking to compromise the integrity of a PEE execution or gain unauthorized access to sensitive information. By modifying GOT entries or tampering with global data variables, an attacker can manipulate function pointers, inject malicious code, or steal confidential data, highlighting the importance of protecting these critical memory regions

[0405] FIG. 4 shows a system 400 for enforcing data safety where data regions 407 containing variables 409 and GOT regions 406 are protected in a given memory address space 201. In system 400, one or more memory address spaces 201 contain one or more KPEEs 207 (see connecting line 452), one or more BPEEs 204 (see connecting line 451), and one or more DPEEs 205 (see connecting line 453). The one or more KPEEs 207 contain one or more data regions 407 (see connecting line 458), load one or more DPEE 205 (see connecting line 459), load one or more BPEEs 204 (see connecting line 461), contain one or more GOT regions 406 (see connecting line 456), protect one or more GOT regions 406 (see connecting line 457), and protect one or more data guard regions 408 (see connecting line 455).

[0406] In system 400, one or more DPEEs 205 contain one or more data regions 407 (see connecting line 468) and one or more GOT regions 406 (see connecting line 467). In system 400, one or more BPEEs 204 similarly contain one or more data regions 407 (see connecting line 469) and one or more GOT regions 406 (see connecting line 472).

[0407] In system 400, one or more data regions 407 contain one or more variables 409 (see connecting line 470). The one or more variables 409 is encapsulated by one or more data guard regions 408 (see connecting line 471) and bounded by one or more data bounds safety mechanisms 410 (see connecting line 473).

[0408] System 400 may employ distinct mechanisms to protect GOT regions 406 and global data variables 409 in the PEEs 113, providing a robust defense against unauthorized data modifications.

[0409] In some embodiments hardware and software are used to memory -protect GOT regions 406 by making them read-only, ensuring that attackers cannot modify or manipulate entries in GOT regions 406. A first mechanism leverages the platform's MMU, IOMMU and / or DMA controller configuration by KPEE 207 within the same memory address space 201 or a higher-privileged KPEE 207 within a different memory address space 201. By configuring the MMU, system 400 ensures that any attempts to write to GOT regions 406 will be trapped and prevented, thereby protecting the integrity of GOT regions 406. A second mechanism involves softwarebased verification and enforcement of the read-only protection of the GOT regions 406 within the PEE 113 source code or binary code. By using code analysis and validation techniques, the system ensures that any modifications to the GOT regions 406 are detected and prevented, maintaining their security and integrity. Another mechanism involves protecting global data variables 409 in objects 207 by surrounding each global variable definition with data guard regions 408 which are essentially dedicated guard memory regions. Each global variable 409 definition is preceded and succeeded by these guard memory regions, which serve as a protective layer around the sensitive data. By adding these guard regions, system 400 ensures that any modifications outside of the bounds of the global variables will be detected and prevented. The protection of guard memory regions 408 involves combining both hardware and software mechanisms, ensuring that they are marked read-only via: (a) hardware capabilities, leveraging the platform's MMU configuration by KPEE 207 within the same memory address space 201 or a higher-privileged KPEE 207 within a different memory address space 201; and / or (b) relying on software-based mechanisms to verify and enforce the read-only protection of guard memory regions 408 within PEE 113 source code or binary code.

[0410] Data bounds safety mechanism 410 ensures that all memory accesses of variables 409 are performed within the valid bounds of the variable, preventing common errors such as buffer overflows and other spatial memory safety violations. Data bounds safety mechanism 410 associates each variable with a bounds metadata structure, which contains information about the variable's size and alignment. For both global and local variables, specific metadata is generated at compile-time and stored in the PEE's binaries. At runtime checks are emitted in the PEE code region to consult the metadata and ensure safe variable memory access. In addition, data bounds safety mechanism 410 handles pointer variables by tracking the pointer's provenance and ensuring that it points to a valid variable within the program's memory space.

[0411] Data bounds safety mechanism 410 provides strong guarantees about the safety of memory accesses for all types of variables, including local, global, and pointer variables. For local variables, mechanism 410 ensures that all accesses are bounded by the variable's stack frame, preventing overflows into adjacent stack frames or other sensitive areas of memory. For global variables, mechanism 410 checks that all accesses are within the bounds of the variable's allocated storage, preventing buffer overflows or other spatial memory safety violations. For pointer variables, mechanism 410 includes a series of checks to ensure that the pointer is valid and points to a legitimate variable, including checking the pointer's type, provenance, and bounds. This mechanism can be applied to a wide range of programming languages including low-level languages such as C, C++ and Assembly.

[0412] By employing the aforementioned distinct mechanisms, system 400 provides a robust defense against unauthorized modifications to GOT regions 406 and PEE variables 409, thereby ensuring the data integrity and security of PEEs 113. The system's flexibility allows different embodiments to adopt a subset of these data safety mechanisms based on the specific requirements of each PEE. For instance, a DPEE that is implemented as a virtual machine or container may only utilize data guard regions mechanisms, whereas a BPEE that is part of a secure kernel may employ both data guard regions and GOT protections. In contrast, a KPEE may employ all three data safety mechanisms - data guard regions, GOT protections, and data bounds safety - to provide comprehensive protection. This tiered approach enables PEE data safety to be enforced at a desired level of granularity, tailored to the trustworthiness of each PEE. For example, a DPEE running untrusted software may only require data guard regions to be enforced, thereby protecting other PEEs from potential security breaches, while a more trusted PEE may warrant additional protections to ensure its integrity and security.

[0413] In some embodiments of the present invention, a PEE operating at a lower privilege level may have its data safety mechanism enforced by a higher privileged PEE. In this embodiment, the first PEE to get control in the computer platform may have the highest privilege level and the PEE data safety mechanism implemented using the data bounds safety mechanism for its initialization function. This highest privileged PEE may in turn set the GOT and data guard memory regions of the PEE with a lower privilege level as read-only. Further, the highest privileged PEE may use hardware capabilities of the computer platform including hardware Memory Management Unit (MMU), IOMMU and / or DMA controller configuration to set the read-only protection of memory regions. Alternatively, software verification and / or software fault isolation mechanisms can be directly employed in the PEE with the lower privilege to set the read-only protection of memory regions.

[0414] PEE Stack Safety mechanism

[0415] The PEE function call stack, or simply "the stack", is a region of memory where function calls are stored during PEE execution. It's a Last-In -First-Out (LIFO) data structure that keeps track of the functions that have been called but not yet returned, allowing the program to properly manage its execution flow and prevent unexpected behavior. Securing the stack is crucial because it can be vulnerable to exploitation by malicious attackers through buffer overflow attacks, which involve overflowing a buffer with more data than it's designed to hold, potentially overwriting sensitive information or executing arbitrary code on the stack. This can lead to security breaches, privilege escalation, or even complete system crashes.

[0416] PEE indirect calls refer to function calls where the destination function's memory address is not directly specified, but rather retrieved from another location in memory, such as a table or an array of function pointers. This mechanism allows for dynamic dispatching and polymorphism in programming languages. However, indirect calls can also introduce security vulnerabilities if not properly secured. If an attacker can manipulate the contents of the target memory location, they may be able to redirect control flow to malicious code, leading to unauthorized execution of functions or even arbitrary code injection. Securing indirect calls is crucial because it prevents attackers from hijacking program flow and executing malicious payloads.

[0417] FIG. 5 shows a system 500 for enforcing stack safety where code regions 305 of PEEs 113 are protected with forward-edge control flow integrity (CFI) 504, backward-edge CFI 505 and stack canary 508 and ensures that PEEs execute safely and securely by preventing unauthorized control flow, modifying return memory addresses, or exploiting misaligned jumps. In system 500 a stack safety security mechanism 501 is embedded within one or more PEEs 113 (see connecting line 551). One or more PEEs 113 contains one or more code regions 305 (see connecting line 552) and one or more stack regions 506 (see connecting line 556). One or more code regions 305 in turn contain one or more forward-edge CFI mechanisms 504 (see connecting line 553), one or more backward-edge CFI mechanisms 505 (see connecting line 555), and one or more direct and indirect calls 509 handlers 509 (see connecting line 554). One or more direct and indirect calls handlers 509 in turn reference one or more stack regions 506 (see connecting line 559). One or more stack regions 506 contains one or more stack frames 507 (see connecting line 557) and finally one or more stack frames 507 contains one or more stack canaries 508 (see connecting line 558).

[0418] Some embodiments include forward edge CFI mechanism 504 for protecting PEE 113 functions. FIG. 6 depicts a method 600 as a time sequence diagram according to some embodiments. Method 600 may be executed, for example, by systems 100, 200, 300, 400, 500, and / or combinations thereof. Though, method 600 may be implemented in any suitable way. In method 600 time flow increases from top to bottom. As mentioned previously a LIFO data structure 604 is used for stack region 506. LIFO data structure 604 ensures that branch or jump operations within a program function point to valid memory addresses. When a branch or jump operation is executed (step 605), method 600 retrieves target instruction memory address at indirect function call (step 607) and validates whether the target instruction memory address is within the valid PEE code region or points to a valid PEE function of an external PEE in the same memory address space 201. This scheme also aligns target function memory addresses correctly to prevent attackers from exploiting misaligned jumps (step 609) and verifies that indirect call targets match the function defined type hash (a hash of the function prototype) (step 612), preventing attacks that exploit mismatched calls (step 613). If the indirect call targets match the function defined type hash, then the target instruction at the indirect call site is executed (step 614).

[0419] FIG. 7A shows a method 700 that uses a backward edge CFI 505 protection mechanism for PEE 113 functions. This mechanism prevents attackers from modifying return memory addresses on the stack, ensuring that control flow returns to a valid memory address in the PEE code upon execution of a return processor instruction. A valid memory address is a memory address of the instruction following a prior branch instruction or to a set of memory addresses that is set up by the PEE to which a return processor instruction is permitted to transfer control to.

[0420] In one embodiment the system achieves backward edge CFI by introducing a meta-stack (MS) mechanism 702, where every PEE 113 function has a local stack memory region 506 for storing local variables and a meta-stack mechanism 702 for storing return memory addresses. As mentioned previously, LIFO data structure 604 is used for the stack region 506. The meta-stack mechanism 702 works by storing return memory addresses for PEE 113 functions (step 706) on meta-stack mechanism 702 and local variables (step 707) on local stack region 506.

[0421] In some embodiments, when a PEE 113 function is called, it stores its return memory address on the meta-stack mechanism 702 (step 708). Upon return from the function, method 700 uses meta stack mechanism 702 to obtain the correct return instruction pointer 712 and returns from the PEE 113 function to restore the original stack frame 507 (step 711). The PEE 113 function writes to local variables using local stack region 506 (step 710).

[0422] The system may include a stack-frame 507 protection mechanism that prevents attackers from modifying the contents and layout of each stack frame. This is achieved by storing magic stack canary 508 values at predetermined locations within the stack frames 507, specifically at the beginning of the stack frames 507 before the memory location of the first local variable (FIG. 7). In some embodiments the stack canary 508 can be a randomized value initialized when a PEE is loaded into a memory address space.

[0423] When a return instruction is executed in the program function, the system compares the canary value associated with the current stack frame to a predetermined magic value (step 713) stored in association with each stack canary value. If the compared values do not match, the system triggers an alert signal to log the stack frame violation (step 715). If the compared values match the system clears the return address from meta-stack mechanism 702 and returns back to the caller.

[0424] In some embodiments of the system, the stack canary 508 is a random value generated once per PEE execution and stored in a dedicated memory address that is again randomly selected once per PEE execution. The stack canary is then loaded from the dedicated memory address and stored at the memory address at the beginning of stack frame when a PEE function starts execution. When the return instruction is executed in the PEE function, the system compares the canary value stored at the memory address at the beginning of the stack frame with the value in the dedicated memory address.

[0425] Another embodiment of the system is illustrated by method 750 shown in FIG. 7B which achieves backward edge CFI 505 using function hashes 704. Every PEE 113 function has a local stack region 506 for storing local variables which is a LIFO data structure 604. The scheme stores function hashes for legitimate return addresses (step 715). Local variables are stored in the local stack region (step 707) and accessed from there (step 710). The location of the return hash value is stored in the code region 305 which secures return addresses to prevent control flow manipulation (step 709). When a function returns, the hash value at the return location in the code region is compared with the stored value on function entry (step 717). If there is a mismatch an alert is triggered (step 718). If the hash values match the original stack frame is restored and control is transferred back to the caller (step 711).

[0426] The aforementioned mechanisms may ensure that control flow is executed correctly within PEE source code or binary code and can be implemented using various techniques, including (a) solely via hardware capabilities, (b) solely via software capabilities and (c) in a hybrid fashion that combines both hardware and software capabilities. In some embodiments the forward edge CFI mechanism and backward edge CFI mechanism can be implemented on the PEE source code leveraging the corresponding programming language constructs (e.g., C, C++ and Assembly). In some embodiments the forward edge CFI mechanism and the backward edge CFI mechanism can be implemented directly on the PEE binary without access to the PEE source code. In this embodiment, binary rewriting mechanisms are used to embed the CFI protections directly into the PEE binary.

[0427] The system ensures that function safety is enforced within the program's code, regardless of whether it's executed from source or compiled into binaries. This is achieved by validating branch or jump targets, aligning them correctly, protecting stack frames, and verifying indirect call targets against function-defined type hashes. The stack safety mechanism and control flow integrity mechanism can manifest in various embodiments, ensuring safety of function calls across different types of PEEs. For instance, in a Bastion PEE (BPEE) 204, which has a set of functions, each function can be equipped with a stack safety mechanism, providing fine-grained protection against control flow attacks. Similarly, in a Keystone PEE (KPEE) 207, which also comprises multiple functions, each function can have a built-in stack safety mechanism, ensuring robust defense against control flow corruption. In contrast, a Domain PEE (DPEE) 205 can implement function safety at a coarser granularity, where a single logical function encapsulates the entire functionality of the DPEE, including nested PEEs and their associated functions running at a lower privilege level. This logical function can be protected using stack safety mechanisms enforced via Memory Management Unit (MMU), IOMMU and DMA controller hardware capabilities and privilege levels, ensuring that even if the DPEE has only coarse-grained protection, it will not compromise the overall system's control flow integrity. For example, a higher-privilege KPEE or BPEE with fine-grained per-function stack safety mechanism can invoke a lower-privilege DPEE with coarse-grained single logical function stack safety, and the system as a whole will still preserve the stack safety mechanism.

[0428] To illustrate this, consider a scenario where the DPEE is a container with multiple processes, the KPEE is the host kernel, and the BPEE is the host OS container runtime and supporting libraries. In this case, the KPEE and BPEE can enforce fine-grained stack safety for each function, while the DPEE, as a container, ensures coarse-grained stack safety for its single logical function, which encompasses all its processes. Similarly, on the hypervisor front, a KPEE can be the hypervisor itself, a BPEE can be a device model or a virtual firmware interface, and a DPEE can be a guest operating system or a virtual machine, with each PEE type implementing control flow integrity mechanisms at varying granularities. Furthermore, in the context of firmware, a KPEE can be the firmware code itself, a BPEE can be a firmware component such as a device driver or a system management module, and a DPEE can be a boot loader or an operating system loader, with each PEE type enforcing control flow integrity mechanisms at different levels of granularity. By allowing for this flexibility in implementation, the stack safety mechanism and control flow integrity mechanism ensures that safety of function calls is preserved across various PEE types and embodiments, providing robust protection against control flow attacks in a wide range of scenarios.

[0429] PEE Privilege Separation mechanism PEE function call privilege separation is a critical aspect of software execution that refers to the mechanism by which different PEE functions are executed with varying levels of privileges or access rights. In conventional computer platform architectures, function calls often involve invoking a specific function from within another function, potentially escalating privileges or accessing sensitive data. However, this privilege separation can be exploited by malicious code to gain unauthorized access to system resources, leading to security vulnerabilities such as privilege escalation and other types of access control exploits.

[0430] To secure function call privilege separation, some embodiments segregate and control all function calls within and across PEEs, enforcing strict access control policies and validating each function call to prevent unauthorized access or escalation of privileges. This ensures that even if a malicious actor were to gain access to a specific function, they would still be unable to execute arbitrary code or access sensitive data without explicit permission.

[0431] FIG.8 shows a system 800 for enforcing privilege separation among multiple caller PEE 801 and callee PEE 804 via sentinels 802 and access control matrix 805. In system 800, one or more caller PEEs 801 calls one or more sentinels 802 (see connecting line 851). Sentinel 802 in turn transfers control to one or more callee PEEs 804 (see connecting line 853). One or more callee PEEs 804 return back to the sentinel 802 (see connecting line 856) which finally resumes PEEs 113 (e.g., FIG. 1) execution after the call. Sentinel 802 consults one or more access control matrices 805 to see if the call to callee PEE 804 is authorized (see connecting line 854). In this system 800, one or more Keystone PEEs (KPEEs) 207 protect one or more access control matrices 805 (see connecting line 860) and use one or more MMUs 806 (see connecting line 855) to do so. One or more access control matrices 805 can be implemented by one or more computer platform hardware 807 (see connecting line 857) or can be implemented by one or more software mechanisms 808 (see connecting line 858). One or more MMUs 806 can similarly be implemented in one or more computer platform hardware 807 (see connecting line 861) or can be implemented in one or more software mechanisms 808 (see connecting line 859).

[0432] In some embodiments, sentinel 802 may be implemented as direct calls where calls to PEE 113 functions from PEE 113 functions within the same PEE can be direct and / or go through the PEE GOT regions 406 (FIG. 4). This means that if a PEE function needs to call another one within the same PEE, it can do so directly without needing to consult an external table. The GOT regions 406 serve as a mapping of symbolic names to memory addresses for functions and variables. In some other embodiments, sentinel 802 can be implemented as calls through PLT regions 306 (FIG. 3) where calls to PEE 113 functions from a caller PEE in its own memory address space 201 to a callee PEE within a caller PEE happen via the caller PEE's PLT regions 306. PLT regions 306 are used when a function call requires transitioning from one function’s memory address space 201 to another. This ensures that the calling context and privileges are properly maintained.

[0433] In yet some other embodiments, sentinel 802 is implemented as calls through KPEE 207 (FIG. 2). Calls to PEE functions to a callee PEE 804 in a callee memory address space 201 from caller PEE 801 functions within a caller PEE 801 memory address space 201 happen via KPEE 207 of the caller PEE process. This means that when transitioning between processes, KPEE 207 takes responsibility for enforcing privileges and ensuring proper function call behavior.

[0434] Some embodiments further comprise a call access control matrix 805, which enforces appropriate caller-callee access control and privilege separation. Call access control matrix 805 dictates whether calls to PEE 113 functions 208 are permitted or denied based on pre-defined access control policies. By enforcing caller-callee access control, access control matrix 805 ensures that privilege separation is maintained across function calls within and across PEEs.

[0435] In some embodiments, access control is implemented through dedicated hardware instructions that leverage computer platform hardware 807, which provides a secure and efficient mechanism for enforcing privileges. In some other embodiments, access control matrix 805 is implemented via software mechanisms 808 embedded within the source or binary code of the PEE 113. In yet other embodiments, access control matrix 805 is implemented through one or more dedicated PEEs, which serve as a separate and isolated environment for enforcing privileges and controlling function calls.

[0436] In summary, system 800 may ensure that privilege separation is enforced throughout the system at all times by (a) providing multiple methods for controlling and validating function calls within the PEE and (b) implementing an access control matrix to enforce caller-callee access control and privilege separation. By combining these features, system 800 may ensure that function calls are properly validated and privileged, preventing unauthorized access or escalation of privileges within and across PEEs.

[0437] PEE Eleap Safety mechanism

[0438] The PEE heap is a region of memory where dynamically allocated data is stored, allowing PEEs to manage large blocks of data efficiently. The heap serves as a temporary storage area for variables, objects, and other data structures, enabling PEEs to allocate and deallocate memory as needed. However, the program heap also presents a significant security risk due to its dynamic nature, making it vulnerable to attacks such as buffer overflows, use-after-free, and double-free vulnerabilities. If left unsecured, an attacker can exploit these weaknesses to inject malicious code, execute arbitrary commands, or even take control of the entire system.

[0439] FIG.9 shows a system 900 for providing heap safety 903 consisting of hardened heap management to protect heap memory 902. In system 900, one or more heap managers 901 manage one or more heap memories 902 (see connecting line 951) and ensure one or more heap safety mechanisms 903 (see connecting line 952). Additionally, one or more heap managers 901 provide one or more heap allocation and free interfaces 904 (see connecting line 953) and is implemented as one or more PEEs 113 (see connecting line 954). Finally, one or more heap managers 901 capabilities are embedded in binary in one or more PEEs 113 (see connecting line 956) and embedded in source code in one or more program execution element 113 (see connecting line 955).

[0440] Some embodiments relate to a system for managing physical and virtual memory mappings within a given memory address space 201, where said system further comprises one or more heap managers 901 per memory address space 201 (see FIGs. 1 and 9). Each heap manager 901 can be a stand-alone PEE 113 invoked by other PEEs 113 or embedded within another PEE 113 via source code modification or binary rewriting.

[0441] This system provides heap allocation and free interface 904 which are a collection of functions 208 that enable various operations on heap memory 902 such as heap configuration, heap allocation, as well as freeing, and re-allocation of heap memory 902 blocks. Heap manager 901 implements base heap protection mechanisms to prevent various types of attacks on the heap by ensuring heap safety 903.

[0442] Base heap protection is a set of measures designed to safeguard against common heap-related vulnerabilities. This includes memory block tracking, reference counting, memory pooling, and heap layout randomization (HLR). Memory block tracking involves marking each dynamically allocated memory block with a unique identifier, allowing the system to track ownership of the memory blocks and verify whether a block has been freed or not. Reference counting ensures that each reference to a memory block is incremented when acquired and decremented when released, preventing dangling pointers. Memory pooling allocates memory in contiguous blocks, reducing fragmentation and hardening heap allocation against attacks. HLR randomizes the layout of the heap memory region, making it more difficult for attackers to predict the location of heap elements.

[0443] The system also includes thread-safe memory allocation, which ensures that allocation and deallocation of heap memory 902 are thread-safe, preventing multiple threads from accessing or modifying the same heap memory location simultaneously.

[0444] Furthermore, the system provides freelist management, block status flags, guard memory regions, redzones, metadata signatures, and immediate deallocation to enforce heap safety property 903 and to prevent various types of attacks such as Use- After-Free (UAF), Over-Flow (OF), Double-Free (DF), Metadata Tampering (MDT), and Lazy Deallocation Attack (LDA). Mitigation of these attacks is described below.

[0445] A UAF attack occurs when an attacker manipulates a program to access memory that has already been freed, resulting in arbitrary code execution. To mitigate this, the system may implement thread-safe memory allocation, which ensures that heap memory allocation and deallocation are thread-safe, preventing multiple threads from accessing or modifying the same heap memory location simultaneously.

[0446] An OF attack occurs when an attacker exploits a buffer overflow vulnerability in a program to overwrite adjacent memory blocks on the heap. To mitigate this, the system may implement guard memory regions and redzones. Guard memory regions use dedicated read-only memory regions to ensure that each heap allocation cannot be accessed under or over the heap object size. Redzones populate unused memory regions within a given heap memory block allocation with special magic values that are checked during allocation and deallocation to detect random heap spray attacks.

[0447] A DF attack occurs when an attacker frees the same memory block twice, resulting in arbitrary code execution. To mitigate this, the system may implement freelist management and block status flags. Freelist management manages a list of freed memory blocks to prevent allocating the same block again before it's actually freed. Block status flags use flags or bitfields to indicate whether a memory block has been freed, deallocated, or recycled, preventing multiple frees on the same block.

[0448] A MDT attack occurs when an attacker manipulates metadata associated with each memory block to compromise its integrity. To mitigate this, the system may implement metadata signatures, which generate and verify signatures for metadata associated with each memory block to ensure its integrity. An LDA attack occurs when an attacker exploits a delay in deallocating memory blocks to execute arbitrary code. To mitigate this, the system may implement immediate deallocation, which implements a mechanism to immediately deallocate memory blocks when they are no longer needed, rather than waiting until the program's runtime or garbage collection cycle.

[0449] These measures collectively provide a robust defense against malicious activities aimed at compromising the integrity and security of the system's heap memory management.

[0450] The described system is designed to operate in various computer platforms ranging from embedded systems, desktop, servers to cloud platforms. Some embodiments may be implemented using programming languages such as C++, Java, or other high-level languages that support memory allocation and deallocation. Though, embodiments may be implemented in any suitable way.

[0451] The system 900 can have various embodiments, providing flexibility in deployment and integration with existing software frameworks. For instance, the heap manager 901 can be implemented as a Keystone PEE (KPEE) 207, responsible for managing memory allocation and deallocation for multiple Domain PEEs (DPEEs) 205. Alternatively, it can be implemented as a Bastion PEE (BPEE) 204, providing an additional layer of security and isolation for the heap management functionality. In some cases, multiple DPEEs can share a single heap manager 901, while in others, each DPEE may have its own heap managers. Furthermore, for untrustworthy DPEEs, heap managers may not be required, as the data safety mechanism is sufficient to ensure that memory issues within these DPEEs do not compromise the overall system security. For example, in a host / container scenario, the host can be implemented as a BPEE, with its own heap manager, while containers, which are DPEEs, are free to use their own heap management or rely on the host's heap manager. Similarly, in a hypervisor / VMs embodiment, the hypervisor can be a BPEE, implementing a heap manager for itself and optionally for the VMs, which are DPEEs, while each VM may also have its own heap management mechanism. Additionally, the heap manager 901 can be invoked by other PEEs or embedded within a PEE via source code modification or binary rewriting, allowing for flexibility in deployment and integration with existing software frameworks. This enables various organizational structures, such as a single heap manager serving multiple DPEEs, each DPEE having its own heap manager, or a combination of both. The choice of implementation depends on the specific use case, security requirements, and performance considerations, highlighting the versatility of the heap management mechanism in supporting diverse embodiments, including host / container, hypervisor / VMs, and other scenarios where multiple PEEs coexist and interact with each other. Overall, embodiments may provide an innovative solution to enhance the security of heap memory management on commodity computer platforms, protecting against various types of attacks that exploit weaknesses in heap allocation and deallocation.

[0452] Interface Confined Security Mechanism (ICSM)

[0453] The system and methods may include an “Interface Confined Security Mechanism (ICSM)” that regulates interactions between potentially malicious components and the rest of the system. ICSM achieves this by designating a subset of the union of the set of Keystone PEEs (KPEEs) 207 and Bastion PEEs (BPEEs) 204 (called “ICSM PEE”), to act as gatekeepers and enforce strict boundaries (called “bastion interfaces”) around computer platform resources. Bastion interfaces are essentially a subset of the union of the set of PEE functions 208 of KPEEs 207 and BPEEs 204 which prevent unauthorized access to computer platform resources by other potentially malicious PEEs. A key aspect of ICSM is the use of mathematical adversary modeling, which involves creating detailed models of potential attackers and their possible actions, allowing for the anticipation and mitigation of all possible non-deterministic adversarial inputs that could be directed at each bastion interface. By tying each bastion interface to a comprehensive set of potential adversarial scenarios, the ICSM can ensure that the system is resilient to even the most sophisticated and unpredictable attacks including zero-day attacks. ICSM PEEs operate at a higher level of privilege than the potentially malicious PEEs, ensuring that they can effectively control and monitor interactions. The overall security of the system is formally proven using a rigorous mathematical model that takes into account the complex interplay between the system's components and the potential adversaries.

[0454] ICSM can be embodied in various forms to protect different layers of a computer system, with each layer represented as a Keystone PEE (KPEE), Bastion PEE (BPEE), or Domain PEE (DPEE). For example, in a hypervisor-based embodiment, the hypervisor can be implemented as a KPEE 207, serving as a trusted environment for regulating interactions between virtual machines, which are represented as DPEEs 205, and the physical hardware. The ICSM can be integrated into the KPEE 207, allowing it to enforce strict boundaries around system resources and prevent malicious DPEEs 205 from compromising the system.

[0455] In another embodiment, the firmware of a device can be represented as a BPEE 204, providing an additional layer of security against malicious attacks targeting the device's low-level interfaces. The ICSM can be integrated into the BPEE 204, enabling it to regulate interactions between the firmware and other components of the system, such as DPEEs 205 representing kernel modules or applications. Additionally, the ICSM can be implemented as a KPEE 207 within an operating system, which is represented as a DPEE 205, enabling it to enforce strict boundaries around system resources and prevent malicious applications, also represented as DPEEs 205, from compromising the system. In this embodiment, the KPEE 207 operates at a higher level of privilege than the DPEEs 205, ensuring that it can effectively control and monitor interactions.

[0456] In other embodiments, the Interface Confined Security Mechanism (ICSM) can be applied to virtualization and containerization technologies to enhance their security. For instance, in a virtual machine-based embodiment, the guest operating system can be represented as a DPEE 205, and the host environment can be represented as a KPEE 207 or BPEE 204. The ICSM can be used to regulate interactions between the DPEE 205 and the KPEE 207 or BPEE 204, preventing malicious code from escaping the virtual machine and compromising the host.

[0457] Similarly, in a container-based embodiment, each container can be represented as a DPEE 205, and the host environment can be represented as a KPEE 207 or BPEE 204. The ICSM can be used to enforce strict boundaries around container interfaces, preventing malicious DPEEs 205 from accessing sensitive data or disrupting other DPEEs 205 within the same host. By applying the ICSM to these various technologies, it is possible to create a robust and comprehensive security framework that protects computer systems against a wide range of threats.

[0458] FIG. 10 shows a system 1000 for Interface Confined Security Mechanism (ICSM). In system 1000 a mathematical model 102 models one or more Bastion PEE 204 (see connecting line 1058) and one or more Keystone PEE 207 (see connecting line 1059). The mathematical model 102 uses one or more theorem provers 104 (see connecting line 1054) to prove system security mechanism 114 (see connecting line 1053). One or more Bastion PEE 204 implement one or more bastion interfaces 1007 (see connecting line 1060). Similarly, one or more Keystone PEE 207 implement one or more bastion interfaces 1007 (see connecting line 1061). One or more Bastion PEE 204 and one or more Keystone PEE 207 implement one or more Interface confined security mechanism (ICSM) 1003 (see connecting lines 1056 and 1057 respectively). One or more ICSM 1003 build on one or more Bastion Interfaces 1007 (see connecting line 1062). One or more Bastion Interfaces 1007 confine one or more devices 111, and one or more memory 112 and one or more Processor 1006 (see connecting lines 1063, 1064 and 1065 respectively). One or more devices 111 contains one or more volatile storage 1004 and one or more non-volatile storage 1005 (see connecting lines 1066 and 1067 respectively). One or more memory 112 contains one or more volatile storage 1004 and one or more non-volatile storage 1005 (see connecting lines 1068 and 1070 respectively). Finally, one or more Processors 1006 contains one or more volatile storage 1004 and one or more non-volatile storage 1005 (see connecting lines 1069 and 1071 respectively).

[0459] The descriptions of the following ICSM are presented below: approved code execution (ACE) mechanism, approved cryptographic operations (ACO) mechanism, and approved network communications (ANC) mechanism.

[0460] Approved Code Execution (ACE) Mechanism

[0461] Unauthorized code execution and remote code execution attacks pose significant threats to modem computing systems, compromising their security and integrity. Unauthorized code execution occurs when an attacker successfully executes malicious code on a victim's system without permission, often through exploiting vulnerabilities in software applications or operating systems. Remote code execution attacks take this threat to the next level by allowing attackers to execute arbitrary commands on remote systems, granting them unfettered access to sensitive data, resources, and control. These types of attacks can lead to devastating consequences, including data breaches, financial losses, and reputational damage.

[0462] Some embodiments of the present invention provide a novel approach to achieving provably secure authorized code execution (ACE) on computer platforms. ACE provides a robust defense against unauthorized code execution and remote code execution attacks by implementing various protection mechanisms, including digital signatures, hash functions, and memory management controls. This approach ensures that only authorized software components are loaded onto the system, executed in a controlled environment, and securely managed to maintain the integrity and security of the system.

[0463] The system comprises an approved code execution (ACE) mechanism that includes four components - (i) ACE provisioning mechanism (see FIG. 11); (ii) ACE PEE load protection mechanism (see FIG. 12); (iii) ACE PEE execute protection mechanism (see FIG. 13); and (iv) ACE PEE unload protection mechanism (see FIG. 14). Each of these components plays a vital role in ensuring the integrity and security of code execution on the computer platform as described further below.

[0464] In some embodiments, the ACE provisioning mechanism, ACE PEE load protection mechanism, ACE PEE execute protection mechanism and ACE PEE unload protection mechanism may be implemented as a set of PEEs, embedded within a set of PEEs either via source code modification or binary rewriting during computer platform provisioning or at runtime. This flexibility enables the system to be integrated with various platform components and software stack components including hypervisors, firmware, operating systems and applications. Further, the set of PEEs can operate at different privilege levels in different memory address spaces. This allows for fine-grained control over authorized code execution at different operating privilege levels (hypervisors, firmware, operating system etc.). This flexibility also enables the system to be deployed on a wide range of platforms, from small embedded systems to large-scale enterprise environments.

[0465] ACE Provisioning Mechanism

[0466] FIG. 11 shows a system 1100 for Approved Code Execution provisioning mechanism, according to some embodiments. In system 1100, the ACE provisioning mechanism 1101 performs a series of steps and checks. As a first step, it performs a check to see if the provisioning is from the local computer platform 1102. If the check at step 1102 is a “YES”, the ACE provisioning mechanism 1101 obtains the ACE ICSM policy from the local computer platform 1103. If the check at step 1102 is a “NO”, the ACE provisioning mechanism 1101 obtains the ACE ICSM policy from the remote computer platform 1104. The ACE provisioning mechanism 1101 then performs another check to see if an ICSM policy is available either in a local or remote computer platform and if it is authentic 1105. If the check in step 1105 is a “NO” then the ACE provisioning mechanism 1101, performs error handling 1109 and ends 1110. If the check in step 1105 is a “YES” then the ACE provisioning mechanism 1101 obtains the PEE details from the ACE ICSM policy 1106 and provisions the corresponding bastion interfaces 1107. The ACE provisioning mechanism 1101 then checks of the bastion interfaces were provisioned correctly 1108. If the check in step 1108 is a “NO” then the ACE provisioning mechanism 1101, performs error handling 1109 and ends 1110. If the check in step 1108 is a “YES” then the ACE provisioning mechanism ends 1110 without any errors.

[0467] In one embodiment of the ACE provisioning mechanism, obtaining the ACE ICSM policy from the local computer platform involves querying a local database or configuration file that stores the ICSM policies. The ACE provisioning mechanism can utilize non-volatile storage media for this purpose to access and retrieve the ICSM policy from the local computer platform. For instance, in a containerized environment, the ACE provisioning mechanism can leverage the container volume mounting feature to access the host's file system and retrieve the ICSM policy from a designated location.

[0468] In another embodiment of the ACE provisioning mechanism, obtaining the ACE ICSM policy from a remote computer platform involves establishing a secure communication channel with the remote platform using protocols such as HTTPS or SSH. The ACE provisioning mechanism can utilize APIs or command-line tools to query the remote platform's configuration management system, such as Ansible or Puppet, to retrieve the ICSM policy. For example, in a cloud-based environment, the ACE provisioning mechanism can use AWS's Systems Manager (SSM) or Azure's Automation service to fetch the ICSM policy from a centralized repository. The retrieved policy is then transmitted back to the local computer platform, where it is processed and used for provisioning.

[0469] In one embodiment of the ACE provisioning mechanism, checking the authenticity of the ICSM policy involves verifying its digital signature or checksum against a trusted source. The ACE provisioning mechanism can utilize cryptographic operations to validate the policy's signature and ensure that it has not been tampered with during transmission or storage.

[0470] Additionally, the mechanism can check the policy's version number and timestamp to ensure that it is up-to-date and not revoked.

[0471] In one embodiment of the ACE provisioning mechanism, error handling involves logging and reporting any errors or exceptions that occur during the provisioning process. The ACE provisioning mechanism can utilize logging frameworks, such as Logstash, to record error messages, PEE identification and policy details including error traces. Additionally, the mechanism can send notifications to system administrators or security teams via email, SMS, or other notification channels. Further, the ACE provisioning mechanism can forward error logs to a centralized logging service, such as ELK Stack or Splunk.

[0472] In one embodiment of the ACE provisioning mechanism, obtaining PEE details from the ACE ICSM policy involves parsing and processing the policy file to extract relevant information. The ACE provisioning mechanism can utilize configuration parsing libraries, such as JSON or XML parsers, to extract PEE-specific data, such as execution parameters, memory constraints, and network settings. For instance, in a cloud-based environment, the ACE provisioning mechanism can use AWS's IAM policies or Azure's Role-Based Access Control (RBAC) to extract PEE details and configure the corresponding bastion interfaces.

[0473] In one embodiment of the ACE PEE provisioning mechanism, provisioning bastion interfaces involves modifying the sources or binaries of PEEs to establish a controlled environment for approved code execution. To achieve this, the ACE provisioning mechanism can utilize eBPF (extended Berkeley Packet Filter) based hooks to inject custom logic into the PEEs, allowing for runtime enforcement of approved code execution policies. For instance, the mechanism can use eBPF programs to attach to specific syscalls, such as execve or mmap, and enforce policies that restrict the execution of unauthorized code. In another embodiment, provisioning bastion interfaces involves employing syscall-based hooks to intercept and modify system calls at the kernel level, ensuring that only approved code is executed. By leveraging syscalls like execve, mmap, ptrace or seccomp, the mechanism can enforce strict control over the execution of PEEs.

[0474] In another embodiment of the ACE provisioning mechanism, local or remote provisioning can be performed using a set of PEEs as part of a system package or a set of system packages. System packages refer to collections of PEEs, including executables, libraries, scripts, and configuration files, that are necessary for the execution of a program or application on a computer platform. These PEEs may include operating system components, device drivers, firmware, and other software elements that enable the execution of a program or application. System packages provide a structured way to manage and distribute these PEEs, ensuring that all necessary elements are present and correctly configured for PEE execution.

[0475] In this embodiment, the ACE provisioning mechanism comprises essential functions for computing a hash for all PEEs in the system package and storing a signed mapping of PEEs to hashes for each element as provisioned, along with the name and location of the package file. To generate hashes for PEEs, a unique digital fingerprint is generated, or a hash computed, for each PEE. This hash is then paired with the corresponding PEE, including its name and location, to create a signed mapping of hashes to PEEs. The provisioning PEE stores these signed mappings in three hashmaps: a hashmap of approved PEE binaries, a hashmap of approved PEE scripts, and a hashmap of approved PEE configuration files.

[0476] In this embodiment, these system packages and their associated information are an integral part of the ACE ICSM policy. The system packages, along with their hashes and signed mappings, are used to enforce the ACE ICSM policy by ensuring that only authorized PEEs are executed on the system. The hashmap of approved PEE binaries, scripts, and configuration files provides a comprehensive record of which PEEs have been installed on the system, allowing for easy verification of compliance with the ACE ICSM policy.

[0477] In this embodiment, the provisioning PEE packages these hashmaps into a single signed "approved-list" of system packages, which is then used to create an unforgeable source bill of material (SBOM) of all system packages. This SBOM provides a high level of assurance regarding the authenticity and integrity of the PEEs and approved software components, ensuring that they comply with the ACE ICSM policy. By integrating the system packages and their associated information into the ACE ICSM policy, the system ensures a secure and compliant environment for execution, with the ability to verify and enforce the integrity, compliance, security, and management of the system at all times.

[0478] ACE PEE File Protection Mechanism

[0479] FIG. 12 shows a system 1500 for ACE PEE file protection mechanism 1201 to provide approved code execution, according to some embodiments. In system 1200, the ACE PEE file protection mechanism 1201 performs a series of steps and checks. As a first step, it performs a probe of the bastion interfaces 1202. It then checks if the bastion interface is one of volatile storage or non-volatile storage bastion interface 1203. If the check at step 1203 is a “NO”, then the ACE PEE file protection mechanism ends 1208. If the check at step 1203 is a “YES”, then another check is performed to see if the bastion interface is writing to PEE files specified in the ACE ICAM policy 1204. If the check in step 1204 is a “YES” then the ACE PEE file protection mechanism disallows the write to PEE files 1205, performs error handling 1207 and ends 1208. If the check in step 1204 is a “NO” then the ACE PEE file protection mechanism carries out the specified bastion interface functionality (for writing to PEE files) 1206 and ends 1208.

[0480] In some embodiments of the system 1200 a probe of the bastion interface 1902 can be implemented using techniques such as EBPF with different types of EBPF probes, via changes to PEE source or binary code performing the bastion interface functionality such as libraries and applications as well as by using callback functions or signal handling. Such probing techniques help identify the type of bastion interface (volatile or non-volatile) for which functionality needs to be handled 1203.

[0481] In other embodiments of the system 1200 the check is bastion interface writing to PEE files specified in ACE ICSM policy 1204 may be performed by parsing the ICSM policy which may be in various formats such as JSON, YAML etc. and the PEE file information may be part of the ACE ICSM policy and can be either PEE binary files, PEE script file and / or PEE configuration files.

[0482] In some embodiments of the system 1200 a specific bastion interface functionality can be carried out 1206 by utilizing Extended Berkeley Packet Filter (EBPF) or syscall hooking to intercept and redirect calls to the original interface implementation that the bastion interface guards. Alternatively, the source code or binary code of the PEE implementing the bastion interface functionality can have a built-in functionality to invoke the original functionality of the interface that the bastion interface guards. In other embodiments of the system 1200 the disallow writes to PEE files 1205 may be implemented by sending back an error code or by invoking an interrupt or signal handler within another PEE or the PEE implementing the ACE PEE file protection mechanism.

[0483] Finally, in some embodiments of the system 1200 the error handling 1207 may be implemented to send out a specific error signal or alert to a set of PEEs in the local computer platform or to a remote computer platform. The alert can be sent out as a message along with other data such as the PEE identification and policy identification details and may be encrypted to protect confidentiality.

[0484] In one embodiment of the system 1200, the ACE PEE file protection mechanism is implemented as a file protection PEE that comprises essential functions and objects for managing files, including opening, writing, and closing files on storage media for purposes of approved code execution. During initialization, the file protection PEE loads an approved list of system packages, which includes signed PEE binaries, scripts, and configuration files, into memory. The file protection PEE then creates a hashmap for each type of package, where each hashmap stores metadata associated with the corresponding package. When a request is made to open a file, the file protection PEE checks if the file belongs to an approved PEE binary, script, or configuration file by searching the respective hashmaps. If the file is found in one of the hashmaps and has a "dirty" attribute set, indicating that it has been modified, the file protection PEE returns an error message to prevent unauthorized modifications. Otherwise, the file is opened, and its file descriptor is stored in the corresponding hashmap. For write operations, the file protection PEE checks if the file descriptor used for writing corresponds to an approved PEE binary, script, or configuration file by searching the respective hashmaps. If the file descriptor matches a configuration file, the provided contents are written to the file, and the "dirty" attribute is set in the hashmap to indicate that the file has been modified. If the file descriptor does not match any of the approved packages, the write operation is allowed. When closing a file, the file protection PEE checks if the file referenced by the file descriptor belongs to an approved PEE binary, script, or configuration file by searching the respective hashmaps. If a match is found, the "closed" attribute is set in the hashmap, and the file descriptor is reset. The file is then closed, and an OK value is returned. By being the only gateway to read and write to persistent media, the file protection PEE ensures that all interactions with storage media regarding PEE files are properly managed and secured.

[0485] In another embodiment of the system 1200, the ACE PEE file protection mechanism is implemented as a file protection PEE which employs a hash tree of the file system on the storage device. The hash tree comprises a root hash and hashes for each block of the file system that represents file and associated metadata. During runtime when a read or write request is made to the storage device, the file protection PEE uses the root hash to check if a particular block has been written to or tampered with and if so performs error handling to disallow the write request and / or signal tampering on the file system.

[0486] In one embodiment of the system 1200, the signed root hash of the file system can be provisioned into the boot-loader, the OS kernel or an initial memory filesystem (e.g., initramfs) which is then decrypted using a public-key and used to enforce integrity protected file system with read-only files that are resistant to tampering both offline and at runtime.

[0487] In some embodiments of the system 1200, a filesystem versioning system such as BTRFS is employed to create automatic backups of a designated set of files each time any file within that set is written to. This ensures that all modifications are tracked and preserved, providing a robust safeguard against unintended or malicious changes. The versioning mechanism may operate seamlessly in the background, maintaining integrity by generating snapshots at specific intervals, thus allowing for recovery to previous states if necessary. The frequency and conditions under which these backups are created may be configured according to system requirements and preferences. For example, system administrators have the flexibility to set parameters such as the number of writes that trigger a backup or the time intervals between successive backups, optimizing performance and storage usage while ensuring data security. This configurability further enhances the adaptability of the file protection mechanism, enabling it to align with different operational contexts and compliance standards. Additionally, the ability to roll back to any previously created version provides a powerful recovery option, facilitating quick restoration in scenarios where malicious modifications or deletions occur.

[0488] ACE PEE Load Protection Mechanism

[0489] FIG. 13 illustrates a system 1300 for implementing ACE PEE load protection mechanism 1301, according to some embodiments. In system 1300 the ACE PEE load protection mechanism 1301 executes a series of steps and checks. Initially, the mechanism performs a probe of the bastion interfaces 1302 to determine the type of interface being accessed. This probe is followed by a check to ascertain whether the bastion interface is one of volatile storage, code execution, or memory bastion interface 1303. If the check at step 1303 yields a "NO" result, the ACE PEE load protection mechanism 1301 terminates its operation 1309. Conversely, if the check at step 1303 returns a "YES" result, an additional verification is conducted to determine whether a load of PEE executable files is permitted by the ACE Interface Confined Security Mechanism (ICSM) policy and if the PEE is authentic 1304. In the event that the check in step 1304 yields a "NO" result, the ACE PEE load protection mechanism 1301 disallows the load of the PEE 1305, performs error handling procedures 1308, and subsequently terminates its operation 1309. On the other hand, if the check in step 1304 returns a "YES" result, the ACE PEE load protection mechanism 1301 loads the PEE executable file into memory 1306, marks the PEE executable code regions and subset of data regions read-only 1307, and then terminates its operation 1309.

[0490] In some embodiments of the system 1300, the probe of the bastion interface 1302 can be implemented using various techniques such as Extended Berkeley Packet Filter (eBPF) with different types of eBPF probes. Alternatively, this probe can be achieved via modifications to PEE source or binary code performing the bastion interface functionality, including libraries and applications, as well as by utilizing callback functions or signal handling mechanisms. For instance, eBPF probes can be used to monitor system calls, volatile storage calls, code execution calls, memory mapping calls, or other events related to the bastion interface. Additionally, in a containerized environment, the probe can be implemented using container-specific hooks, such as container lifecycle callbacks, to monitor container creation, start, and stop events.

[0491] In other embodiments of the system 1300, the check to determine whether a load of PEE executable files is permitted by the ACE ICSM policy and if the PEE is authentic 1304 can be performed by parsing the ICSM policy, which may be formatted in various syntaxes such as JSON or YAML. The authenticity of the PEE can be verified by comparing the hash or signature of the PEE executable file, as specified in the ACE ICSM policy, to the PEE executable residing in the memory address space. This ensures that only authorized and authentic PEEs are allowed to load. Furthermore, in a virtual machine (VM) environment, the check can be performed by leveraging the VM's introspection capabilities to monitor and verify the integrity of the PEE.

[0492] In other embodiments of the system 1300, the loading of the PEE executable to memory 1306 can be accomplished by invoking calls to other PEEs, such as kernel or hypervisor PEEs, or dedicated PEEs responsible for managing memory allocations. Further, the PEE executable files may be PEE binary files or PEE script files.

[0493] In some embodiments of the system 1300, marking PEE code regions and subset of data regions read-only may be accomplished by using a computer platform hardware Memory Management Unit (MMU), or dedicated PEEs responsible for managing memory protections, or by invoking calls to other PEEs, such as kernel or hypervisor PEEs. In other embodiments of the system 1300, the disallowance of load 1305 can be implemented by returning an error code or by invoking an interrupt or signal handler within another PEE or the PEE implementing the ACE unload protection mechanism. This provides a robust and flexible way to handle unauthorized unload attempts. For instance, in a containerized environment, the disallowance can be implemented using container-specific error handling mechanisms and error handling API.

[0494] Finally, in some embodiments of the system 1300, the error handling 1308 may be implemented to send out a specific error signal or alert to a set of PEEs in the local computer platform or to a remote computer platform. The alert can be transmitted as a message along with other relevant data, such as PEE identification and policy identification details, and may be encrypted to protect confidentiality. This ensures that error conditions are properly reported and addressed while maintaining the security and integrity of the system.

[0495] ACE PEE Execute Protection Mechanism

[0496] FIG. 14 illustrates a system 1400 for implementing ACE PEE execute protection mechanism 1401, according to some embodiments. In system 1400 the ACE PEE execute protection mechanism 1401 executes a series of steps and checks. Initially, the mechanism performs a probe of the bastion interfaces 1402 to determine the type of interface being accessed. This probe is followed by a check to ascertain whether the bastion interface is one of volatile storage, code execution, or memory bastion interface 1403. If the check at step 1403 yields a "NO" result, the ACE PEE execute protection mechanism 1401 terminates its operation 1409. Conversely, if the check at step 1403 returns a "YES" result, an additional verification is conducted to determine whether an execution of PEE executable files is permitted by the ACE Interface Confined Security Mechanism (ICSM) policy and if the PEE is authentic 1404. In the event that the check in step 1404 yields a "NO" result, the ACE PEE execute protection mechanism 1401 disallows the execution of the PEE 1405, performs error handling procedures 1408, and subsequently terminates its operation 1410. On the other hand, if the check in step 1404 returns a "YES" result, the ACE PEE execute protection mechanism 1401 loads the PEE executable file into memory 1406, marks the PEE executable code regions and subset of data regions read-only 1407, executes the PEE executable at its entry point function 1409, and then terminates its operation 1410.

[0497] In some embodiments of the system 1400, the probe of the bastion interface 1402 can be implemented using various techniques such as Extended Berkeley Packet Filter (eBPF) with different types of eBPF probes. Alternatively, this probe can be achieved via modifications to PEE source or binary code performing the bastion interface functionality, including libraries and applications, as well as by utilizing callback functions or signal handling mechanisms. For instance, eBPF probes can be used to monitor system calls, volatile storage calls, code execution calls, memory mapping calls, or other events related to the bastion interface. Additionally, in a containerized environment, the probe can be implemented using container-specific hooks, such as container lifecycle callbacks, to monitor container creation, start, and stop events.

[0498] In other embodiments of the system 1400, the check to determine whether an execution of PEE executable files is permitted by the ACE ICSM policy and if the PEE is authentic 1404 can be performed by parsing the ICSM policy, which may be formatted in various syntaxes such as JSON or YAML. The authenticity of the PEE can be verified by comparing the hash or signature of the PEE executable file, as specified in the ACE ICSM policy, to the PEE executable residing in the memory address space. This ensures that only authorized and authentic PEEs are allowed to execute. Furthermore, in a virtual machine (VM) environment, the check can be performed by leveraging the VM's introspection capabilities to monitor and verify the integrity of the PEE.

[0499] In other embodiments of the system 1400, the loading of the PEE executable to memory 1406 can be accomplished by invoking calls to other PEEs, such as kernel or hypervisor PEEs, or dedicated PEEs responsible for managing memory allocations. Further, the PEE executable files may be PEE binary files or PEE script files.

[0500] In some embodiments of the system 1400, marking PEE code regions and subset of data regions read-only may be accomplished by using a computer platform hardware Memory Management Unit (MMU), or dedicated PEEs responsible for managing memory protections, or by invoking calls to other PEEs, such as kernel or hypervisor PEEs.

[0501] In other embodiments of the system 1400, executing PEE executable at its entry point function may be accomplished by using dedicated CPU instruction to perform a call to the PEE entry point function. Alternatively, shared memory can be used to signal execution of a PEE from an entry point function.

[0502] In other embodiments of the system 1400, the disallowance of execution 1405 can be implemented by returning an error code or by invoking an interrupt or signal handler within another PEE or the PEE implementing the ACE unload protection mechanism. This provides a robust and flexible way to handle unauthorized unload attempts. For instance, in a containerized environment, the disallowance can be implemented using container-specific error handling mechanisms and error handling API. Finally, in some embodiments of the system 1400, the error handling 1408 may be implemented to send out a specific error signal or alert to a set of PEEs in the local computer platform or to a remote computer platform. The alert can be transmitted as a message along with other relevant data, such as PEE identification and policy identification details, and may be encrypted to protect confidentiality. This ensures that error conditions are properly reported and addressed while maintaining the security and integrity of the system.

[0503] ACE PEE Unload Protection Mechanism

[0504] FIG. 15 illustrates a system 1500 for implementing an Approved Code Execution (ACE) Program Execution Element (PEE) unload protection mechanism 1501, according to some embodiments. In system 1500 the ACE PEE unload protection mechanism 1501 executes a series of steps and checks. Initially, the mechanism performs a probe of the bastion interfaces 1502 to determine the type of interface being accessed. This probe is followed by a check to ascertain whether the bastion interface is one of volatile storage, code execution, or memory bastion interface 1503. If the check at step 1503 yields a "NO" result, the ACE PEE unload protection mechanism 1501 terminates its operation 1509. Conversely, if the check at step 1503 returns a "YES" result, an additional verification is conducted to determine whether an unload of PEE executable files is permitted by the ACE Interface Confined Security Mechanism (ICSM) policy and if the PEE is authentic 1504. In the event that the check in step 1504 yields a "NO" result, the ACE PEE unload protection mechanism 1501 disallows the unload of the PEE 1505, performs error handling procedures 1508, and subsequently terminates its operation 1509. On the other hand, if the check in step 1504 returns a "YES" result, the ACE PEE unload protection mechanism 1501 unloads the PEE executable file from memory 1506, executes cleanup of the PEE memory as specified in the ACE ICSM policy 1507, and then terminates its operation 1509.

[0505] In some embodiments of the system 1500, the probe of the bastion interface 1502 can be implemented using various techniques such as Extended Berkeley Packet Filter (eBPF) with different types of eBPF probes. Alternatively, this probe can be achieved via modifications to PEE source or binary code performing the bastion interface functionality, including libraries and applications, as well as by utilizing callback functions or signal handling mechanisms. For instance, eBPF probes can be used to monitor system calls, volatile storage calls, code execution calls, memory mapping calls, or other events related to the bastion interface. Additionally, in a containerized environment, the probe can be implemented using container-specific hooks, such as container lifecycle callbacks, to monitor container creation, start, and stop events. In other embodiments of the system 1500, the check to determine whether an unload of PEE executable files is permitted by the ACE ICSM policy and if the PEE is authentic 1504 can be performed by parsing the ICSM policy, which may be formatted in various syntaxes such as JSON or YAML. The authenticity of the PEE can be verified by comparing the hash or signature of the PEE executable file, as specified in the ACE ICSM policy, to the PEE executable residing in the memory address space. This ensures that only authorized and authentic PEEs are allowed to unload. Furthermore, in a virtual machine (VM) environment, the check can be performed by leveraging the VM's introspection capabilities to monitor and verify the integrity of the PEE.

[0506] In other embodiments of the system 1500, the unloading of the PEE executable from memory 1506 can be accomplished by invoking calls to other PEEs, such as kernel or hypervisor PEEs, or dedicated PEEs responsible for managing memory allocations. This approach enables efficient and secure management of memory resources during the unload process.

[0507] In some embodiments of the system 1500, the cleanup of PEE memory as specified in the ACE ICSM policy 1507 may involve parsing the ICSM policy file in JSON or YAML format and executing a specific memory scrubbing scheme to wipe the PEE memory. This ensures that sensitive information is properly sanitized to preserve confidentiality.

[0508] In other embodiments of the system 1500, the disallowance of unload 1505 can be implemented by returning an error code or by invoking an interrupt or signal handler within another PEE or the PEE implementing the ACE unload protection mechanism. This provides a robust and flexible way to handle unauthorized unload attempts. For instance, in a containerized environment, the disallowance can be implemented using container-specific error handling mechanisms and error handling API.

[0509] Finally, in some embodiments of the system 1500, the error handling 1508 may be implemented to send out a specific error signal or alert to a set of PEEs in the local computer platform or to a remote computer platform. The alert can be transmitted as a message along with other relevant data, such as PEE identification and policy identification details, and may be encrypted to protect confidentiality. This ensures that error conditions are properly reported and addressed while maintaining the security and integrity of the system.

[0510] In one embodiment of the present invention, Approved Code Execution (ACE) mechanism may be implemented as binary loader and script loader PEEs, collectively referred to as the loader PEE. In this embodiment, the loader PEE comprises essential functions to load and unload PEE binaries and PEE scripts from storage media into system memory. During initialization, the loader PEE loads an approved list of system packages and generates hashmaps of the approved list, including a hashmap of approved PEE binaries and a hashmap of approved PEE scripts. When loading a new PEE, the loader PEE generates a cryptographic hash of the PEE to be loaded and checks if the hash matches the hashmap of approved PEE binaries or the hashmap of approved PEE scripts. If a match is found, the loader PEE loads and transfers control to the corresponding PEE entry point function and returns an indication of success. If no match is found, the loader PEE returns an error indication. In this embodiment, the loader PEE also manages the unloading of PEEs from memory by freeing and scrubbing the memory region of the PEE, ensuring that system resources are not wasted and maintaining the integrity of the system's memory management. This prevents malicious reuse of previously loaded PEE binary or PEE script logic in system memory. Additionally, the loader PEE uses a heap manager PEE for memory allocation and deallocation, ensuring that system resources are efficiently managed and the integrity of the system's memory management is maintained at all times. In this embodiment, the loader PEE can be implemented at different privilege levels and memory address spaces within the system, and it serves as the only gateway to load new PEE binaries and PEE scripts from persistent media to memory for a given binary or script type, memory address space, and privilege level.

[0511] These various embodiments demonstrate the flexibility and customizability of the ACE PEE unload protection mechanism 1501 in ensuring secure and approved code execution across different scenarios and environments, including containerized, virtualized, and cloud-based systems.

[0512] Overall, the approved code execution (ACE) mechanism according to some embodiments may provide a comprehensive solution for securing PEE code execution and enforcing the use of authorized PEE code execution. By implementing this mechanism in accordance with some embodiments, organizations may ensure the integrity and confidentiality of sensitive business logic and code.

[0513] Approved Cryptographic Operations (ACO) Mechanism

[0514] Ransomware attacks have become a significant threat to individuals and organizations worldwide, causing devastating financial losses and disrupting critical operations. These malicious cyberattacks use encryption libraries to lock and hold sensitive data hostage, demanding exorbitant ransoms in exchange for the decryption key. The consequences of such attacks can be catastrophic, including permanent data loss, reputational damage, and even legal repercussions. Some embodiments of the present invention provide a novel approach to achieving provably secure authorized code execution (ACE) on computer platforms. ACO 101 provides a highly secure solution for protecting sensitive information on computer platforms by ensuring authorized cryptographic operations are performed with authorized cryptographic keys at all times during computer platform runtime. This robust solution safeguards against ransomware attacks and meets compliance requirements with regulatory standards related to data protection and security, such as GDPR, HIPAA, and PCI-DSS.

[0515] The system comprises an approved cryptographic operations (ACO) mechanism that includes two components - (i) ACO provisioning mechanism (see FIG. 16); and (ii) ACO enforcement mechanism (see FIG. 17). Each of these components plays a vital role in ensuring the integrity and security of cryptographic operations on the computer platform as described further below.

[0516] In some embodiments, the ACO provisioning mechanism and ACO enforcement mechanism may be implemented as a set of PEEs, embedded within a set of PEEs either via source code modification or binary rewriting during computer platform provisioning or at runtime. This flexibility enables the system to be integrated with various platform components and software stack components including hypervisors, firmware, operating systems and applications. Further, the set of PEEs can operate at different privilege levels in different memory address spaces. This flexibility enables the system to be deployed on a wide range of platforms, from small embedded systems to large-scale enterprise environments.

[0517] ACO Provisioning Mechanism:

[0518] FIG. 16 shows a system 1600 for Approved Cryptographic Operations (ACO) provisioning mechanism, according to some embodiments. In system 1600, the ACO provisioning mechanism 1601 performs a series of steps and checks. As a first step, it performs a check to see if the provisioning is from the local computer platform 1602. If the check at step 1602 is a “YES”, the ACO provisioning mechanism 1601 obtains the ACO ICSM policy from the local computer platform 1603. If the check at step 1602 is a “NO”, the ACO provisioning mechanism 1601 obtains the ACO ICSM policy from the remote computer platform 1604. The ACO provisioning mechanism 1601 then performs another check to see if an ICSM policy is available either in a local or remote computer platform and if it is authentic 1605. If the check in step 1605 is a “NO” then the ACO provisioning mechanism 1601, performs error handling 1610 and ends 1611. If the check in step 1605 is a “YES” then the ACO provisioning mechanism 1601 obtains the authorized cryptographic keys from the ACO ICSM policy 1606, securely stores the authorized cryptographic keys 1607, and provisions the corresponding bastion interfaces 1608. The ACO provisioning mechanism 1601 then checks if the bastion interfaces were provisioned correctly 1609. If the check in step 1609 is a “NO” then the ACO provisioning mechanism 1601, performs error handling 1610 and ends 1611. If the check in step 1609 is a “YES” then the ACO provisioning mechanism ends 1611 without any errors.

[0519] In one embodiment of the ACO provisioning mechanism, obtaining the ACO ICSM policy from the local computer platform involves querying a local database or configuration file that stores the ICSM policies. The ACO provisioning mechanism can utilize non-volatile storage media for this purpose to access and retrieve the ICSM policy from the local computer platform. For instance, in a containerized environment, the ACO provisioning mechanism can leverage the container volume mounting feature to access the host's file system and retrieve the ICSM policy from a designated location.

[0520] In another embodiment of the ACO provisioning mechanism, obtaining the ACO ICSM policy from a remote computer platform involves establishing a secure communication channel with the remote platform using protocols such as HTTPS or SSH. The ACO provisioning mechanism can utilize APIs or command-line tools to query the remote platform's configuration management system, such as AWS Nitro Trusted Platform Module (TPM), to retrieve the ICSM policy. For example, in a cloud-based environment, the ACO provisioning mechanism can use AWS's Nitro TPM or Azure's Virtual TPM service to fetch the ICSM policy from a centralized repository. The retrieved policy is then transmitted back to the local computer platform, where it is processed and used for provisioning.

[0521] In one embodiment of the ACO provisioning mechanism, checking the authenticity of the ICSM policy involves verifying its digital signature or checksum against a trusted source. The ACO provisioning mechanism can utilize cryptographic operations to validate the policy's signature and ensure that it has not been tampered with during transmission or storage.

[0522] Additionally, the mechanism can check the policy's version number and timestamp to ensure that it is up-to-date and not revoked.

[0523] In one embodiment of the ACO provisioning mechanism, obtaining authorized cryptographic keys from the ACO ICSM policy involves parsing and processing the policy file to extract relevant information. The ACO provisioning mechanism can utilize configuration parsing libraries, such as JSON or XML parsers, to extract cryptographic key-specific data, such as execution parameters, cryptographic operations, encryption standard (RSA, AES etc.) and access tokens. For instance, in a cloud-based environment, the ACO provisioning mechanism can use AWS's IAM policies or Azure's Role-Based Access Control (RBAC) in addition to key management services (KMS) such as AWS KMS or Azure KMS to extract the cryptographic keys. In a local on-premise environment or an embedded platform, the ACO provisioning mechanism can use a Trusted Platform Module (TPM) service to extract the cryptographic keys.

[0524] In another embodiment of the ACO provisioning mechanism, securely storing authorized cryptographic keys 1607 may be done by designating a special memory region in a set of dedicated PEEs. In this embodiment, the authorized cryptographic keys may be stored securely in a local or remote Trusted Platform Module (TPM). Alternatively, the authorized cryptographic keys may be stored in an encrypted fashion on the local computer platform nonvolatile storage.

[0525] In one embodiment of the ACO provisioning mechanism, provisioning bastion interfaces involves modifying the sources or binaries of PEEs to establish a controlled environment for approved cryptographic operations. To achieve this, the ACO provisioning mechanism can utilize eBPF (extended Berkeley Packet Filter) based hooks to inject custom logic into the PEEs, allowing for runtime enforcement of approved cryptographic operations policies. For instance, the mechanism can use eBPF programs to attach to specific cryptographic operation library calls for encryption, decryption and hash computations and enforce policies that only allow the use of authorized cryptographic keys. In another embodiment, provisioning bastion interfaces involves employing library-based hooks to intercept and modify PEE calls to cryptographic libraries (e.g., openssl) ensuring that only authorized operations are allowed with authorized encryption keys.

[0526] In one embodiment of the ACO provisioning mechanism, error handling involves logging and reporting any errors or exceptions that occur during the provisioning process. The ACO provisioning mechanism can utilize logging frameworks, such as Logstash, to record error messages, PEE identification and policy details including error traces. Additionally, the mechanism can send notifications to system administrators or security teams via email, SMS, or other notification channels. Further, the ACO provisioning mechanism can forward error logs to a centralized logging service, such as ELK Stack or Splunk.

[0527] ACO Enforcement Mechanism:

[0528] FIG. 17 shows a system 1700 for Approved Cryptographic Operations (ACO) enforcement mechanism, according to some embodiments. In system 1700, the ACO enforcement mechanism 1701 performs a series of steps and checks. As a first step, it performs a probe of the bastion interfaces 1702. It then checks if the bastion interface is one of volatile storage, non-volatile storage, cryptographic operations or memory bastion interface 1703. If the check at step 1703 is a “NO”, then the ACO enforcement mechanism ends 1709. If the check at step 1703 is a “YES”, then another check is performed to see if the bastion interface deals with cryptographic operations involving keys 1704. If the check in step 1704 is a “YES” then the ACO enforcement mechanism performs another check to see if the cryptographic operations specify keys in the set of authorized keys 1705. If the check in step 1705 is a “NO” then the ACE enforcement mechanism disallows the cryptographic operation 1706, performs error handling 1708 and ends 1709. If the check in step 1705 is a “YES” or if the check in step 1704 is a “NO” then the ACO enforcement mechanism carries out the specified bastion interface functionality using the ACO ICSM policy 1707 and ends 1709.

[0529] In some embodiments of the system 1700 a probe of the bastion interface 1902 can be implemented using techniques such as extended Berkeley Packet Filter (eBPF) with different types of eBPF probes, via changes to PEE source or binary code performing the bastion interface functionality such as libraries and applications as well as by using callback functions or signal handling within PEEs. Such probing techniques help identify the type of bastion interface (volatile storage, non-volatile storage, cryptographic operations and / or memory) for which functionality needs to be handled 1703.

[0530] In other embodiments of the system 1700 the check does bastion interface deal with cryptographic operation involving keys 1704 may be performed by parsing the ACO ICSM policy which may be in various formats such as JSON, YAML etc. and the list of cryptographic operations that involve keys may be part of the ACO ICSM policy.

[0531] In some embodiments of the system 1700 the check does cryptographic operation specify keys in authorized keys 1705 may be performed by parsing the ACO ICSM policy and constructing a list of authorized keys that are specified in the ACO ICSM policy which may be in various formats such as JSON, YAML etc. In this embodiment, the ACO authorized cryptographic keys may be securely stored in non-volatile storage media or volatile storage media.

[0532] In some embodiments of the system 1700, carrying out specified bastion interface functionality using ACO ICSM policy 1707 may be performed utilizing extended Berkeley Packet Filter (eBPF) or library call hooking to intercept and redirect calls to the original cryptographic operations’ implementation that the bastion interface guards. Alternatively, the source code or binary code of the PEE implementing the bastion interface functionality can have a built-in functionality to invoke the original cryptographic function corresponding to the bastion interface. In this embodiment, based on the ACO ICSM policy, a subset of the cryptographic operations may be disallowed for certain PEEs.

[0533] In other embodiments of the system 1700 the disallow cryptographic operation 1706 may be implemented by sending back an error code or by invoking an interrupt or signal handler within another PEE or the PEE implementing the ACO enforcement mechanism.

[0534] Finally, in some embodiments of the system 1700 the error handling 1708 may be implemented to send out a specific error signal or alert to a set of PEEs in the local computer platform or to a remote computer platform. The alert can be sent out as a message along with other data such as the PEE identification and policy identification details and may be encrypted to protect confidentiality.

[0535] An embodiment of an Approved Cryptographic Operations (ACO) mechanism is disclosed herein. This embodiment comprises a system that includes encryption initialization, encryption operation, and decryption operation. A cryptography Bastion PEE (BPEE) provisions and re-provisions the computer platform for authorized encryption. The cryptography BPEE initialization function checks if the provisioning is static or dynamic. If it is static, the function write-protects authorized cryptographic operations keys in memory using a Keystone PEE (KPEE). If it is dynamic, the cryptography BPEE obtains authorized keys from a local or remote signing agent, generates approved cryptographic operations (ACO) keys, and stores them in an approved cryptographic operations (ACO) keys-hashmap.

[0536] In this embodiment, the cryptography BPEE is part of a signed system package that includes the cryptography BPEE binary, scripts, and configuration files. This system package is installed on the computer platform, where it can be used to provision and re-provision the platform for authorized cryptographic operations. The cryptography BPEE itself comprises processor-executable functions that perform encryption operations using the ACO keys-hashmap via an encryption function. The cryptography BPEE checks if a specified key is within the ACO keys-hashmap, and if so, encrypts the data using the provided key. If not, it returns an error. Similarly, the cryptography BPEE performs decryption operation via a decryption function, checking if a specified key is within the ACO keys-hashmap, and if so, decrypts the data using the provided key. In this embodiment, the encryption. In this embodiment, the cryptography BPEE is the only PEE that provides cryptographic operations to the remainder of the PEEs in the system. This ensures that only authorized encryption keys are used for encryption and decryption operations, providing a secure and reliable mechanism for cryptographic operations. Overall, the approved cryptographic operations (ACO) mechanism according to some embodiments may provide a comprehensive solution for securing cryptographic operations and enforcing the use of authorized cryptographic operations and authorized cryptographic keys. By implementing this mechanism in accordance with some embodiments, organizations may ensure the integrity and confidentiality of sensitive resources and data.

[0537] Approved Network Communication (ANC) Mechanism

[0538] Protecting network communications is paramount for the security of computer platforms, as unauthorized access can lead to devastating consequences such as data exfiltration. Data exfiltration, where sensitive information is surreptitiously transferred out of a system, can compromise confidentiality and integrity, causing irreparable harm to individuals and organizations. This is especially true in today's interconnected world, where the threat landscape is further complicated by the increasing use of artificial intelligence (Al) and machine learning (ML) by attackers, which enables them to launch more targeted, evasive, and persistent attacks.

[0539] Some embodiments of the present invention provide a novel approach to achieving provably secure authorized network communications (ANC) 115 on computer platforms. ANC 115 provides a secure and trustworthy networking solution by implementing a robust set of controls and protections that ensure all network interactions are authorized, authenticated and encrypted. This robust solution safeguards against data-exfiltration attacks and various classes of network-based attacks by design.

[0540] The system comprises an approved network communication (ANC) mechanism that includes two components - ANC provisioning mechanism (see FIG. 18) and ANC enforcement mechanism (see FIG. 19). Each of these components plays a vital role in ensuring the integrity and security of network communications on the computer platform as described further below.

[0541] In some embodiments, the ANC provisioning mechanism and ANC enforcement mechanism may be implemented as a set of PEEs, embedded within a set of PEEs either via source code modification or binary rewriting during computer platform provisioning or at runtime. This flexibility enables the system to be integrated with various platform components and software stack components including hypervisors, firmware, operating systems and applications. Further, the set of PEEs can operate at different privilege levels in different memory address spaces. This flexibility enables the system to be deployed on a wide range of platforms, from small embedded systems to large-scale enterprise environments.

[0542] ANC Provisioning Mechanism: FIG. 18 shows a system 1800 for Approved Network Communications (ANC) provisioning mechanism, according to some embodiments. In system 1800, the ANC provisioning mechanism 1801 performs a series of steps and checks. As a first step, it performs a check to see if the provisioning is from the local computer platform 1802. If the check at step 1802 is a “YES”, the ANC provisioning mechanism 1801 obtains the ANC ICSM policy from the local computer platform 1803. If the check at step 1802 is a “NO”, the ANC provisioning mechanism 1801 obtains the ANC ICSM policy from the remote computer platform 1804. The ANC provisioning mechanism 1801 then performs another check to see if an ICSM policy is available either in a local or remote computer platform and if it is authentic 1805. If the check in step 1805 is a “NO” then the ANC provisioning mechanism 1801, performs error handling 1810 and ends 1811. If the check in step 1805 is a “YES” then the ANC provisioning mechanism 1801 obtains the authorized network communication tuple from the ANC ICSM policy 1806, securely stores the authorized network communications tuple 1807, and provisions the corresponding bastion interfaces 1808. The ANC provisioning mechanism 1801 then checks if the bastion interfaces were provisioned correctly 1809. If the check in step 1809 is a “NO” then the ANC provisioning mechanism 1801, performs error handling 1810 and ends 1811. If the check in step 1809 is a “YES” then the ANC provisioning mechanism ends 1811 without any errors.

[0543] In one embodiment of the ANC provisioning mechanism, obtaining the ANC ICSM policy from the local computer platform involves querying a local database or configuration file that stores the ICSM policies. The ANC provisioning mechanism can utilize non-volatile storage media for this purpose to access and retrieve the ICSM policy from the local computer platform. For instance, in a containerized environment, the ANC provisioning mechanism can leverage the container volume mounting feature to access the host's file system and retrieve the ICSM policy from a designated location.

[0544] In another embodiment of the ANC provisioning mechanism, obtaining the ANC ICSM policy from a remote computer platform involves establishing a secure communication channel with the remote platform using protocols such as HTTPS or SSH. The ANC provisioning mechanism can utilize APIs or command-line tools to query the remote platform's configuration management system, such as a firewall configuration database or Kubernetes cluster, to retrieve the ICSM policy. For example, in a cloud-based environment, the ANC provisioning mechanism can use AWS's Elastic Kubernetes Services (EKS) or Azures Kubernetes Services (AKS) to fetch the ICSM policy from a centralized repository. The retrieved policy is then transmitted back to the local computer platform, where it is processed and used for provisioning.

[0545] In one embodiment of the ANC provisioning mechanism, checking the authenticity of the ICSM policy involves verifying its digital signature or checksum against a trusted source. The ANC provisioning mechanism can utilize cryptographic operations to validate the policy's signature and ensure that it has not been tampered with during transmission or storage.

[0546] Additionally, the mechanism can check the policy's version number and timestamp to ensure that it is up-to-date and not revoked.

[0547] In one embodiment of the ANC provisioning mechanism, obtaining authorized network communications tuple from the ICSM policy 1806 may have the network tuple consist of: external computer platform network addresses, authorized network operations and peripherals and authorized network policies. In this embodiment the ACO ICSM policy is parsed and processed to extract relevant information. The ANC provisioning mechanism can utilize configuration parsing libraries, such as JSON, YAML or XML parsers, to extract the network tuple information and access tokens.

[0548] In some embodiments, the network addresses can be IPv4, IPv6, Modbus, DNP3 and other forms of network addresses; the authorized network operations may be send, receive and configure operations; and the authorized network policies can be iptables or nftables rules for incoming and outgoing network packets within the Linux operating system. For instance, in a cloud-based environment, the ANC provisioning mechanism can use AWS's IAM policies or Azure's Role-Based Access Control (RBAC) in addition to container management services such as AWS EKS and Azure AKS to obtain the authorized network tuple. In a local on-premise environment or an embedded platform, the ANC provisioning mechanism can use a signed version of the ANC ICSM policy that includes the network communications tuple and use cryptographic operation to decrypt the network tuple information.

[0549] In another embodiment of the ANC provisioning mechanism, securely storing authorized network communications tuple 1807 may be done by designating a special memory region in a set of dedicated PEEs. In this embodiment, the authorized network communications tuple may be stored securely in a local or remote hardware security module (e.g., Trusted Platform Module). Alternatively, the authorized network communications tuple may be stored in an encrypted fashion on the local computer platform non-volatile storage.

[0550] In one embodiment of the ANC provisioning mechanism, provisioning bastion interfaces involves modifying the sources or binaries of PEEs to establish a controlled environment for approved network communications. To achieve this, the ANC provisioning mechanism can utilize eBPF (extended Berkeley Packet Filter) based hooks to inject custom logic into the PEEs, allowing for runtime enforcement of approved network operations policies. For instance, the mechanism can use eBPF programs to attach to specific networking operations function calls for packet send, receive and network interface configuration operations within a kernel or hypervisor environment and enforce policies that only allow the use of authorized network communications and local and external computer platform network addresses. In another embodiment, provisioning bastion interfaces involves employing library -based hooks to intercept and modify PEE calls to network libraries (e.g., network socket) ensuring that only authorized network operations are allowed with authorized network addresses.

[0551] In one embodiment of the ANC provisioning mechanism, error handling involves logging and reporting any errors or exceptions that occur during the provisioning process. The ANC provisioning mechanism can utilize logging frameworks, such as Logstash, to record error messages, PEE identification and policy details including error traces. Additionally, the mechanism can send notifications to system administrators or security teams via email, SMS, or other notification channels. Further, the ANC provisioning mechanism can forward error logs to a centralized logging service, such as ELK Stack or Splunk.

[0552] ANC Enforcement Mechanism

[0553] FIG. 19 shows a system 1900 for Approved Network Communications (ANC) enforcement mechanism, according to some embodiments. In system 1900, the ANC enforcement mechanism 1901 performs a series of steps and checks. As a first step, it performs a probe of the bastion interfaces 1902. It then checks if the bastion interface is one of volatile storage, non-volatile storage, network communications operations or memory bastion interface 1903. If the check at step 1903 is a “NO”, then the ANC enforcement mechanism ends 1909. If the check at step 1903 is a “YES”, then another check is performed to see if the bastion interface deals with network communications operations 1904. If the check in step 1904 is a “YES” then the ANC enforcement mechanism performs another check to see if the network operations are consistent with the network policy in the authorized network tuple and specify computer platforms in the authorized network tuple 1905. If the check in step 1905 is a “NO” then the ANC enforcement mechanism disallows the network operation 1906, performs error handling 1908 and ends 1909. If the check in step 1905 is a “YES” or if the check in step 1904 is a “NO” then the ANC enforcement mechanism carries out the specified bastion interface functionality using the ANC ICSM policy 1907 and ends 1909. In some embodiments of the system 1900 a probe of the bastion interface 1902 can be implemented using techniques such as extended Berkeley Packet Filter (eBPF) with different types of eBPF probes, via changes to PEE source or binary code performing the bastion interface functionality such as libraries and applications as well as by using callback functions or signal handling within PEEs. Such probing techniques help identify the type of bastion interface (volatile storage, non-volatile storage, network communications operations and / or memory) for which functionality needs to be handled 1903.

[0554] In other embodiments of the system 1900 the check does bastion interface deal with network communications operation 1904 may be performed by parsing the ANC ICSM policy which may be in various formats such as JSON, YAML etc. and the list of network operations may be part of the authorized network tuple in the ANC ICSM policy.

[0555] In some embodiments of the system 1900 the check to see if the network operations are consistent with the network policy in the authorized network tuple and specify computer platforms in the authorized network tuple 1905 may include a network tuple consisting of: external computer platform network addresses, authorized network operations and peripherals and authorized network policies. In this embodiment the ACO ICSM policy is parsed and processed to extract relevant information. The ANC provisioning mechanism can utilize configuration parsing libraries, such as JSON, YAML or XML parsers, to extract the network tuple information and access tokens. The network addresses can be IPv4, IPv6, Modbus, DNP3 and other forms of network addresses. The authorized network operations may be send, receive and configure operations. The authorized network policies can be iptable or nftable rules for incoming and outgoing network packets. For instance, in a cloud-based environment, the authorized network tuple may be obtained from AWS's IAM policies or Azure's Role-Based Access Control (RBAC) in addition to container management services such as AWS EKS and Azure AKS. In a local on-premise environment or an embedded platform, a signed version of the ANC ICSM policy that includes the network communications tuple may be used along with the use of cryptographic operations to decrypt the network tuple information and perform the check. In this embodiment, the ANC authorized network tuple may be securely stored in non-volatile storage media or volatile storage media.

[0556] In some embodiments of the system 1900, carrying out specified bastion interface functionality using ANC ICSM policy 1907 may be performed utilizing extended Berkeley Packet Filter (eBPF) or library call hooking to intercept and redirect calls to the original network communications operations’ implementation that the bastion interface guards. Alternatively, the source code or binary code of the PEE implementing the bastion interface functionality can have a built-in functionality to invoke the original network communications function corresponding to the bastion interface. In this embodiment, based on the ANC ICSM policy, a subset of the network communications operations may be disallowed for certain PEEs.

[0557] In other embodiments of the system 1900 the disallow network operation 1906 may be implemented by sending back an error code or by invoking an interrupt or signal handler within another PEE or the PEE implementing the ANC enforcement mechanism.

[0558] Finally, in some embodiments of the system 1900 the error handling 1908 may be implemented to send out a specific error signal or alert to a set of PEEs in the local computer platform or to a remote computer platform. The alert can be sent out as a message along with other data such as the PEE identification, network tuple identification and policy identification details and may be encrypted to protect confidentiality.

[0559] An embodiment of an Approved Network Communications (ANC) mechanism is disclosed herein, This embodiment comprises a network communications Bastion PEE (BPEE) that comprises network communications initialization and network communications enforcement. The network communications BPEE during initialization determines whether remote ANC provisioning is enabled, and if so, establishing a secure connection to a remote server to retrieve network policies and network addresses. These policies and addresses are then used to initialize a packet filtering framework. If remote ANC provisioning is not enabled, the network communications BPEE loads network policies and network addresses from the local computer platform into a secure memory address space.

[0560] In this embodiment, the network communications BPEE initializes a packet filtering mechanism with the loaded network policies and network addresses, which involves creating rules and chains for incoming and outgoing traffic based on the network policies and network addresses. The runtime enforcement provided by the network communications BPEE involves receiving an incoming packet at the network interface and applying security checks to determine whether it is authorized and compliant with the network policies. If the packet passes all security checks, it is evaluated against filtering rules based on the loaded network policies and network addresses. If the packet matches an allowed rule, it is allowed to pass through to the relevant set of BPEEs or Domain PEEs (DPEEs).

[0561] In this embodiment, the network communications BPEE may employ various techniques to implement the packet filtering including using kernel or hypervisor functionality or a firmware, or using a subset of the computer platform hardware capabilities. The network communications BPEE also logs telemetry events for debugging and troubleshooting purposes, providing valuable information for administrators to monitor and analyze network traffic.

[0562] Examples of packet filtering mechanisms that may be used includes but not limited to rules-based firewalls, iptables, and nftables, and other network access control mechanisms that provide similar functionality.

[0563] Overall, the approved network communication (ANC) mechanism according to some embodiments may provide a comprehensive solution for securing network traffic and preventing unauthorized access. By implementing this mechanism in accordance with some embodiments, organizations may ensure the integrity and confidentiality of sensitive resources and data.

[0564] Mathematical Modeling and Composition of Security Mechanisms

[0565] Some embodiments of the system include a mathematical model of the computer platform where the PEE interfaces are modeled and it is shown that there is composition of trusted path security mechanism (TPSM) (code safety, data safety, stack safety, heap safety, and privilege separation) and interface confined security mechanism (ICSM) (approved code execution mechanism, approved cryptographic operations mechanism and approved network communications mechanism) when multiple PEEs are used in a system. Further, each PEE can be written in a different programming language and still achieve the composition of the aforementioned security mechanisms. In one embodiment of the system, this allows composing PEEs written in high-level languages such as Rust, Python, Java and C# which incorporate a subset of TPSM and ICSM in their programming language by design along with PEEs written in low-level languages such as C, C++ and Assembly which do not incorporate TPSM and ICSM by design.

[0566] The mathematical model may be modeled with existing assume-guarantee interface confined automated modeling mechanisms as discussed in U. S. Patent No. 12,367,328 allowing for computer assisted modeling and proving of system security mechanisms. As discussed in U. S. Patent No. 12,367,328 the assume-guarantee interface confined modeling may employ theorem provers and / or model checkers to prove system security mechanisms. In some embodiments, proving ICSM and TPSM using theorem provers and / or model checkers may generate a counter example in the event the ICSM and TPSM does not hold for a given version of the mathematical model. In such cases, the counter example provides details in terms of what model specifications need changes so that the ICSM and TPSM can hold. The mathematical model specification is then revised using the output of the counter example and the system security mechanisms are proven again using theorem provers and / or model checkers. This allows for an iterative mathematical model specification workflow that allows to ultimately prove that the ICSM and TPSM hold in the mathematical model.

[0567] The high-level mathematical model in accordance with some embodiments of a system of PEEs 113, their functions 208 and their memory state are described and syntax and semantics governing their concurrent execution on a computer platform with multiple CPUs are introduced.

[0568] Model Syntax

[0569] The syntactic constructions for defining a PEE include a system of PEEs, U, that maps a unique identifier to a PEE, which is a tuple consisting of: (1) a language, lang, with which the PEE is implemented; (2) an exclusive memory address space 201 (including the heap), M, owned by the PEE; (3) a set of function 208 declarations, fd; (4) an initialization function, init, that sets up the initial state of the PEE

[0570] Instead of modeling the detailed semantics of the source language (e.g., C) or the target language (e.g., x86 Assembly), it is assumed that each PEE takes in, as a parameter, the intermediate language (lang) in which it gets compiled into (e.g., intermediate representation of compilers such as GCC or a more universal intermediate representation such as LLVM).

[0571] Generalized commands, gcmd, consist of commands in agreement with the syntax of the language in which the PEE is implemented (lang). For example, in a PEE uid with uid.lang = LLVM, the functions declared in uid.fd are implemented using commands in Low Level Virtual Machine (LLVM) intermediate side-effect free machine representation.

[0572] Memory Model

[0573] The layout of the memory for U, with m distinct PEEs includes the heap which is compartmentalized into m separate memory locations [uid _i. M for i <m. Each heap compartment [uid _i. M is a set of addresses defined as [uid _i. M eP(Addr), such that for all i j<m, [uid _i. M Cl [uid J. M=0.

[0574] The syntax for defining memory is summarized below. The memory state model also includes the regions preserved for the stack frames (i.e., freelists):

[0575] Exclusive heap MG P(Addr)

[0576] Freelist stream F::=F, F

[0577] Freelist FGPAi (Addr)

[0578] Memory state oeAddr i->val

[0579] A freelist can be infinitely large and is used by the thread to allocate its local stack locations as needed. It is assumed that a stream of such infinite freelists F is available upon request. The stream of freelists F, is a coinductive definition and consists of freelists of the type FGPAco (Addr) (i.e., infinite sets of memory addresses). It is assumed that all freelists F in the stream F are mutually disjoint from each other and from the heap locations. Memory state c is defined as a mapping from the heap and the allocated parts of the stack to values.

[0580] Runtime constructs

[0581] The runtime constructs consist of multiple CPU cores with the following syntax: thread pool T::= -| tid •— >(uid, mainf, lang, F,p, a), T

[0582] single core state k::=(cid, T)

[0583] multi core state K::=(F;o;k;cid )

[0584] Each CPU core k, is a tuple of a unique core identifier cid and a list of threads T for executing external function calls. A single thread, uniquely identified with tid, consists of: (1) the main function (mainf) that initializes the thread; (2) language of the thread lang, mainf is the language of uid; (3) the freelist F allocated to the thread; (4) the current internal core state p of the thread storing key control flow state; and (5) the instance, a, that satisfied the precondition mainf when the thread was initialized. Each multicore state K consists of a stream of freelists F, a mapping from addresses to values, o, a list of CPU cores and the active (running) core cid. The active core cid in a multicore state can switch non-deterministically.

[0585] Interface specification

[0586] For each PEE uidGdom(U) and every function fGuid.(fd), an interface {P(x)}uid.f{Q(x)} is fixed and collected in the set A u. P(x) and Q(x) are pre- and post-conditions of the function f, respectively. These are also referred to as uid.f.pre(x) and uid.f.post(x). These pre- and postconditions are essentially invariants for security mechanisms that hold at the starting and at the end of function f respectively (e.g., data safety, forward edge CFI, backward edge CFI etc.). The memory footprint of the interface for the PEE uid is specified by (uid. M).

[0587] In line with function specifications in mathematical separation logic, the precondition uid.f.pre(x) is defined to be parametric in x of type A and has a type A^Prop. A universally quantified version of it, Vx: A.uid.f.pre(x), is a first-order predicate defined over a global memory state c (a pair of heap and stack where the heap includes other resources, e.g., CPU control registers), c l=uid.f.pre(a) specifies that the memory a satisfies uid.f.pre(x) when x is instantiated with the instance a. Assume that the predicate is only defined over the heap owned by uid. (i.e., o|_(uid. M)). The same holds for uid.f.post(x). Moreover, for the sake of simplicity, assume that A has a simple base type (e.g., a list of integers or a string). For example, the specifications of the function foo owned by a PEE uid can be enforced:

[0588] foo:= l_l=*l_0

[0589] where:

[0590] uid. M={l_0,l_l };

[0591] uid.pre.foo(x):= l_0^x; and

[0592] uid.post.foo(x):= l_ x

[0593] Local syntax and semantics

[0594] The language parameter, lang, of a PEE dictates the syntax of its internal functions and the semantics by which those functions evaluate. The syntax defines a grammar for commands, gcmd, and describes the internal states, p, that manage the local control flow inside a function and the internal call stack (e.g., control continuations).

[0595] A pair of a memory state, c, and an internal state, p, describes the PEE program state. The semantics - defines a local transition migrating a program state of the form c,p with respect to a given freelist F: F || -- c,p — >_rA6 oAi,pAi. The label 5 indicates the footprint (read and write set) of this step; when 5 is empty, it is omitted. The label i specifies the type of internal step: abt stands for a step that results in an abort, ret stands for function return, and r stands for effectless internal steps.

[0596] The internal and external calls are distinguished as follows: a general command defining internal functions ((fd) ) can make (a) an internal call to the functions defined in fd of the same PEE; or (b) an external call to a function of another PEE. A PEE makes internal steps with internal calls. When an external call is made, it cannot take internal steps until the external call returns.

[0597] The final element of lang, the set func includes four functions for initializing the internal state (initCore) and governing transitions related to external calls and returns (extCall, extRet, and halt). The function extCall is called when an external call is made, extRet is called when an external call returns, and halt is called when the current thread is ready to return to its caller. The semantics of a language specifies the behavior of these four functions as follows:

[0598] Fll-initCore(fv )=p initializes a core giveM function f on arguments v consulting the declarations in the PEE that owns them.

[0599] Fll-extCall(p)=(fvd ^,pA' ) returns a pair (fv ^,pA' ) when p calls an external function f with arguments v and puts p to a waiting state pA'. Fll-extRet(p,v)=pA' updates p, waiting for the return of an external call, to a new state pA', with a return value v.

[0600] Fll-halt(o,p)=(v,pA' ) returns pA' and a return value v iff Fll- c,p^_ret o,pA' with the global memory state G.

[0601] Operational semantics

[0602] The concurrent multicore semantic rules are of the form

[0603] (F; G; k

[0604]

[0605] ). The 5 is inherited from the underlying local internal steps and refers to read / write footprints of the step. The label r is still used to specify the type of multicore step. For instance, load stands for loading a configuration, call stands for an external call, and ret stands for return.

[0606] The execution of a PEE executing on a system with n distinct cores and an initial global state memory G_0, starts with a configuration, C, of the form ([uid _l.init II- -Il [uid _n.init)_(o_0 ), where G_0 assigns initial values to the heap locations. A configuration is well-defined iff for all i<n,[uid _i£dom(U) and for all i j<n, uid _i^ uid J. A well-defined configuration describes a system of PEEs ready to initialize n distinct PEEs on the CPU cores by calling their init (initialization) functions.

[0607] The rule LOAD takes care of this initialization: it (1) initializes the internal core state p_i, for each [uid _i, using the corresponding initCore function; (2) starts a new thread on each core; (3) assigns n disjoint freelists from F to each thread; and (4) checks that G_0 satisfies the precondition of each PEEs main function, [uid _i.init.pre(x), for an instance a_i. instantiating x. These threads are run until they return (via one of the rules). At that point, it is necessary to ensure that the post-condition of the thread holds for the exact same instance a_i. Thus, instance a_i is carried in the thread to be used when checking the post-conditions.

[0608] Moreover, the LOAD rule requires each heap compartment to be closed (i.e., closeduid. M,o_0)) states that any pointer stored in an address in the domain of uid. M has to point to another location in uid. M. In other words, a heap compartment cannot store a pointer to another heap compartment or a stack frame. This property implies an instance of respecting borders on the heap: a PEE function cannot find a pointer on its memory that points to a location not accessible to it.

[0609] The LOAD rule chooses a core identifier cid£dom(k ^ ) as the active core. The active core cid can be switched to any other [cidA'Gdom(k ) any time using the SWITCH rule, allowing modelling of a preemptive concurrent dynamics. The rest of the semantic rules, except the last two handling interrupts, are defined based on the internal state of the top thread on the stack of the running core. For example, the CMD rule is fired when the top thread on the stack of the running core wants to take a local (T) step. The rule ensures that the multicore state also steps accordingly. CMD asserts that the read / write footprint of the internal core state only touches the memory locations the thread has exclusive access to.

[0610] If the top thread on the stack of the running core calls a PEE function, the rule PEE-CALL (1) identifies the callee and the arguments passed to it using the function extCall; (2) updates the comment internal core state to wait for its callee to return; and (3) spawns a new thread on top of the core's stack, initializes its internal core state using the function initCore, and assigns a fresh freelist to it. It also checks that the call respects the specifications by ensuring that c satisfies the pre-condition of the callee for some b.

[0611] To avoid complications of implementing locks in the semantics, they are simulated by adding an extra condition on PEE-CALL that allows initialization of a PEE function of uidAIas a callee if [uidA'does not appear anywhere on the stack of any of the cores in (k_l ) (i.e., uidA'£active((k_l ) "*)). If this criterion is not met then the PEE that has the lock on a different core and thus the caller's thread needs to wait (using the WAIT rule) until the lock is released. Note that the implementation of locks may result in livelock (e.g., two PEEs may mutually wait for each other).

[0612] When the top thread on the stack of the active core halts: If there is at least one other thread on the stack waiting for its result, the rule PEE-RET uses the function extRet to update the internal core p based on the return value v. It also ensures that the post-condition of [mainf]]A' holds for the argument aA'. By construction, aA' is the same argument that satisfies the precondition of [mainf]]A'. If there is no other thread waiting on the core, the core is terminated.

[0613] Interrupts are modelled as an interrupt handler function within the PEE for each core. For the core cid, the interrupt handler function of PEE [uid _cidlnt is appointed. As a PEE, [uid cidint has its own assigned memory location, which consists of the core's interrupt description table and its interrupt flag, describing whether interrupts are allowed for the core or not. [uid cidint has two distinct functions: init, and setCtx. Other PEEs may call the PEE function setCtx to change the interrupt flag of the core.

[0614] The function init (which takes no arguments) checks whether interrupts are available for the core and, if so, it calls an interrupt function of a PEE corresponding to the interrupt service routine. The preemptive model allows init to take control of the core at any point in time, assigning the highest priority to the interrupts. As a result, the init function needs to have an always true pre-condition to ensure that it can always be initialized: [uid _cidlnt.init.pre=true.

[0615] The INTERRUPT rule models the preemptive semantics. To enforce the locks of PEE functions, the extra premise [uidA'£active((k_l ) ) is required. Thus, in this model, an interrupt cannot get interrupted until an end of interrupt acknowledgement is explicitly generated. When the interrupt handler terminates, INTERRUPT-RET hands back the core to the original interrupted thread asserting the post-condition of the interrupt handler's init function. This rule is similar to other return rules, except that the internal state of the interrupted thread is not updated after the return. As a result, this specific return must be distinguished from others (e.g., PEE-RET) A subscript, int, is assigned to the core cid, (i.e., [cid _Int) when the interrupt handler of the core initializes (INTERRUPT), and it is removed it after it returns (INTERRUPT-RET).

[0616] Theory

[0617] A set of theorems will now be presented that, when true, provide the result that the abstract compartmentalization disclosed herein yields sound composition of PEE security mechanisms (e.g., TPSM and ICSM) across multiple PEEs across multiple CPU cores Security mechanisms verified of each PEE in isolation hold on concurrent executions of the whole system. To support this, the property of respecting the interface (i.e., respecting TPSM, ICSM and specified pre- and post-conditions invariants) is shown. A PEE respects the interface iff all of its functions respect the interface. A set of PEEs U respects the interface, if all uidGU respect the interface.

[0618] A guarantee condition of a thread when it evaluates its own code can be defined. The guarantee condition G(5,o, F, M) holds iff M is closed with respect to c and the footprint 5 only touches the memory regions in F and M (i.e., closed (M,c) AB dom(o)£FUM ). For this, each internal step of a thread must satisfy the guarantee condition.

[0619] Any step the thread takes asserts the guarantee condition: it does not leak any references and only changes its own heap and stack. Moreover, the step results in a new configuration that has the same property. Further, if the thread halts, its return value is not a pointer. In the case of an external PEE function call, the caller can assume that its callee only extends the global memory according to the agreed-upon boundaries. The state after the return continues to have the same property. If each PEE respects the interface in isolation, any concurrent run of the whole system respects the interface. In particular, in any concurrent run, when a function returns, the global memory state satisfies the function’s post-condition.

[0620] When all functions respect the interface, a given CPU core invariant is preserved in any concurrent execution. This result shows that under the conditions ensuring that a configuration initializes successfully, the CPU core can always progress by taking a step other than SWITCH.

[0621] Theorem 1 (Preservation of Interface Confined Invariants): If a system of PEE U respects the interface, then every step of the abstract operational semantics, discussed herein, preserves the invariants governing the interface.

[0622] Corollary 1 (Preservation of trusted path security mechanism invariant): If a system of PEE U respects the interface, then every step of the abstract operational semantics, discussed herein, preserves the invariants corresponding to the core trusted path security mechanism.

[0623] Corollary 2 (Preservation of approved code execution mechanism invariant): If a system of PEE U respects the interface, then every step of the abstract operational semantics, discussed herein, preserves the invariants corresponding to the core approved execution mechanism.

[0624] Corollary 3 (Preservation of approved cryptographic operations mechanism invariant): If a system of PEE U respects the interface, then every step of the abstract operational semantics, discussed herein, preserves the invariants corresponding to the core approved cryptographic operations mechanism.

[0625] Corollary 4 (Preservation of approved network communications mechanism invariant): If a system of PEE U respects the interface, then every step of the abstract operational semantics, discussed herein, preserves the invariants corresponding to the core approved network communications mechanism.

[0626] Theorem 2 (Progress). If a system of PEE U respects the interface and is valid with respect to a global memory state c, then the well-defined configuration ([uid _l.init II- -Il [uid _n.init)_(o_0 ), can be successfully initialized and every core in the compositional concurrent run of the configuration enjoys progress, i.e. every core can either take a step other than SWITCH or it terminates (with TERM, DONE, or ABORT).

[0627] Mathematical Model Implementation Validation Mechanism

[0628] A system and methods to perform conformance testing of the mathematical model and the PEE implementations in order to ensure that PEE implementation preserves the security mechanisms that are proven in the mathematical model is discussed herein. In one embodiment of this system the conformance testing between mathematical model and PEE implementation can be done in a Continuous Integration / Continuous Development (CI / CD) software development pipeline.

[0629] FIG. 20 shows a system 2000 for mathematical model implementation validation mechanism 2001 according to some embodiments. In system 2000, mathematical model implementation validation mechanism 2001 comprises (see connecting lines 2077, 2058 and 2051) one or more test generation mechanism 2002, one or more trace capture mechanism 2003, and one or more trace validation mechanism 2004 respectively. The mathematical model implementation validation mechanism 2001 uses (see connecting line 2060) one or more mathematical model 102. Mathematical model 102 models (see connecting line 2067) one or more computer platform 105 and specifies (see connecting line 2068) one or more system security mechanism 114.

[0630] In system 2000, test generation mechanism 2002 outputs (see connecting line 2072 and 2071) one or more state graphs 2005 and one or more test cases respectively. Test generation mechanism 2002 also constrains (see connecting line 2070) one or more state graphs 2005. One or more test cases 2006 run-on (see connecting lines 2065 and 2066) one or more emulated computer platform 2016 and one or more computer platform 105 respectively.

[0631] In system 2000, trace capture mechanism 2003 invokes (see connecting line 2059) one or more test cases 2006 and uses (see connecting line 2064) one or more PEE instrumentation 2009 and generates (see connecting line 2057) one or more trace log. Computer platform 105 contains (see connecting line 2062) one or more PEE implementation 2010. Similarly, emulated computer platform 2016 contains (see connecting line 2069) one or more PEE implementation 2010. mathematical model implementation validation mechanism 2001 validates (see connecting line 2061) one or more PEE implementation 2010. PEE instrumentation is performed-on (see connecting line 2063) one or more PEE implementation 2010.

[0632] In system 2000, trace validation mechanism 2004 uses (see connecting line 2050 and 2052) one or more mathematical model 102 and one or more trace log 2007 respectively. Trace validation mechanism 2004 generates (see connecting line 2053) one or more implementation validation model 2008. Finally, trace validation mechanism 2004 uses (see connecting lines 2075 and 2054) one or more model checkers 2017 and one or more theorem provers 104 respectively. One or more theorem provers 104 uses (see connecting line 2055) one or more implementation validation model and prove (see connecting line 2056) one or more system security mechanism 114. One or more model checkers 2017 uses (see connecting line 2076) one or more implementation validation model and prove (see connecting line 2080) one or more system security mechanism 114.

[0633] In one embodiment of the system 2000 the mathematical model 102 models the computer platform 105 as a state machine. The state machine has a set of variables, and each state is an assignment of specific values to those variables. The variable can represent memory state, CPU state and / or peripheral state with the memory state including state of the PEE memory regions including PEE functions. The state machine also has a set of allowed actions, which are transitions from one state to the next state. State graphs 2005 can be constructed by drawing states as nodes and allowed actions as edges. A behavior is any path through the graph. The mathematical model 102 may be modeled with existing assume-guarantee interface confined automated modeling mechanisms as discussed in U. S. Patent No. 12,367,328.

[0634] In some embodiments of the system 2000, the mathematical model 102 describes the computer platform and PEE execution as a transition system. In this embodiment a so-called “transition predicate” describes how the system may change its state from one state to another. When the predicate says “true” for two states si and s2, the system is allowed to move from state si to s2. If the predicate then also says “true” for s2 and some s3, the system can move from si to s2 to s3, and so on. Given the transition predicate, and another, “initial” predicate that specifies which states are valid starting states, mathematical model checkers 2017 can construct all valid sequences of states. Additionally, the mathematical model can specify a predicate that defines what the “good” and the “bad” states are, and the model checkers 2017 can then raise an alarm if a bad state can be reached through some valid sequence of states.

[0635] In one embodiment of system 2000, the mathematical model 102 of the computer platform 105 comprises one or more PEE implementation 2010 interfaces (formal representation of PEE functions) that change state when they execute. This state can be a memory state, CPU state and / or peripheral state. As mentioned previously for each PEE uid E dom(U) and every function f E uid.(fd), an interface {P(x)}uid.f{Q(x)} is fixed and collected in the set A u. P(x) and Q(x) are pre- and post-conditions of the function f, respectively. The mathematical model 102 models functions by defining the transition predicate to be: the pre-condition P(x) holds and the post-condition Q(x) holds.

[0636] In some embodiments of the system 2000, the mathematical model 102 specification has a set of behaviors Bspec, and the PEE implementation 2010 has a set of behaviors Bimpl.

[0637] Mathematical bisimulation is used to prove the PEE implementation 2010 refines the mathematical model 102 specification if Bimpl c Bspec and the converse is also true if Bspec c Bimpl. mathematical model implementation validation mechanism 2001 checks if the PEE implementation 2010 can produce all possible behaviors described in the mathematical model and vice versa, verifying that the PEE implementation 2010 has preserved all the system security mechanism 114 specified and proven in the mathematical model 102.

[0638] In system 2000, the test generation mechanism 2002 generates test cases 2006 that force a set of PEE implementation 2010 to follow a sequence of transitions specified in a mathematical model, thereby ensuring conformance between the implementation and the model. In particular, for every behavior in the specification (Bspec), the test generation mechanism generates a test case that exercises the implementation in a specific sequence of transitions, such that if there is a behavior in the specification that the implementation cannot follow, then Bspec Bimpl. In one embodiment, mathematical model checkers 2017 are used to output an entire state graph for the mathematical model specification, which may be constrained to interfaces for a set of PEE implementation 2010.

[0639] In one embodiment of system 2000, a Directed Acyclic Graph (DAG) with a finite number of behaviors, each representing a path from an initial state to a final state may be employed to output state graphs 2005. The model checker's 2017 output is then parsed, and a unit test is automatically created for each behavior in the DAG. This parsing process may involve traversing the graph using a depth-first search (DFS) algorithm to identify all possible paths from an initial state to a final state, wherein each path is used to generate a test case that exercises the PEE implementation 2010 in a specific sequence of transitions.

[0640] In some embodiments, fuzzing tools, such as AFL or LibFuzzer, may be employed to create unit tests for each behavior in the DAG. These fuzzing tools are configured to generate random inputs that exercise the implementation in a specific sequence of transitions, and the resulting test cases are then validated against the expected behavior. Alternatively, a Large Language Model (LLM), such as a neural network or a decision tree, may be used to generate fuzzed inputs for each behavior in the DAG, wherein the LLM is trained on a dataset of valid and invalid inputs.

[0641] In one embodiment of system 2000, the test generation mechanism 2002 may also utilize coverage-guided fuzzing tools to create unit tests for each behavior in the DAG. These tools are configured to generate random inputs that maximize code coverage, and the resulting test cases are then validated against the expected behavior. Furthermore, the test generation mechanism may be integrated with existing PEE unit tests in a Continuous Integration / Continuous Deployment (CI / CD) manner, using a test framework such as JUnit or PyUnit to run the automatically generated unit tests.

[0642] In other embodiments, the DAG parsing process involves constraining the state graph 2005 to interfaces for a set of PEEs or a single PEE, by applying interface-specific filters to the state graph 2005. The resulting filtered graph is then used to generate test cases 2006 that exercise the PEE implementation 2010 in a specific sequence of transitions.

[0643] In system 2000, the trace capture mechanism 2003 generates a trace log file that records a PEE implementation's 2010 state transitions, including all implementation variables that match mathematical model specification variables, for every behavior in Bimpl. If the behavior recorded in the trace is not allowed by the spec, then Bimpl Bspec and the test fails. To achieve this, the mechanism involves PEE instrumentation 2009 which modifies PEE functions to detect pre- and post-conditions using two mechanisms: (i) instrumentation interspersed into the PEE functions; and (ii) instrumentation support functions kept in a separate PEE. The instrumentation that is interspersed into the PEE function records the appropriate state details for the pre- and post conditions which involve memory state (heap and stack), CPU state and associated peripheral state. Each collected state pair describes the PEE functions state for a set of PEE functions for a given behavior. The instrumentation support functions allow for obtaining relevant stack, heap and CPU traces and storing those traces in memory to be later stored to a non-volatile storage media such as the disk. Finally, the trace capture mechanism invokes the set of behaviours by executing the test cases 2006 and collects the corresponding state pairs for the PEE functions that are executed as part of the test case in one or more trace log 2007. The PEE instrumentation 2009 technique employed by the trace capture mechanism 2003 may vary depending on the specific requirements of the PEE implementation 2010.

[0644] In some embodiments of system 2000, PEE instrumentation 2009 may be performed using various techniques, including source-level instrumentation by modifying the PEE source code to add logging statements that record pre- and post-conditions, such as through aspect-oriented programming or programming language and compiler plugins. Alternatively, binarylevel instrumentation may be employed using tools like binary rewriting or instrumentation frameworks, such as DynamoRIO, allowing for modification of PEE functions without changing the source code. Additionally, eBPF probes can be utilized to add instrumentation to PEE functions, leveraging extended Berkeley Packet Filter feature for tracing and debugging.

[0645] In certain embodiments of system 2000, instrumentation support functions may be implemented using eBPF to obtain stack, heap, and CPU traces, or utilizing CPU performance registers to collect CPU-state information. These support functions can store collected traces in memory and later stored to non-volatile storage media, such as disk. Furthermore, kernel or hypervisor APIs can be employed to access low-level system information for tracing and debugging purposes.

[0646] In one embodiment of system 2000, the trace capture mechanism 2003 may also involve running test cases within a regular computer platform 105 or an emulated computer platform 2016 including emulators like QEMU, Bochs or dynamic execution engines such as Valgrind or Pin, to collect traces. Moreover, parallel test cases 2006 execution and trace capture can be achieved using containerization technologies, like Docker or Kubemetes, where each test case is executed within its own container for efficient resource utilization.

[0647] In a preferred embodiment, the trace capture mechanism 2003 incorporates unforgeable telemetry mechanisms, such as those discussed in U. S. Patent Application No. 19 / 254,764 filed on June 30, 2025, to collect trustworthy and tamper-proof traces that can be used to detect security vulnerabilities or performance issues. Furthermore, hardware-based tracing technologies, including Intel's Processor Trace (PT) or ARM's Embedded Trace Macrocell (ETM), may be utilized to collect detailed information about CPU execution and memory access patterns.

[0648] In all embodiments, the trace capture mechanism 2003 is designed to collect accurate and reliable traces that can be used to verify the preservation of the system security mechanism 114 of a set of PEE implementation 2010 with respect to a mathematical model specification.

[0649] In system 2000, the trace validation mechanism 2004 ensures that PEE implementation 2010 traces comply with mathematical model specification. The trace validation mechanism 2004 summons the state transition predicate of the mathematical model, and checks if the state pairs that are obtained satisfy the predicate for the invariants corresponding to the security mechanism that is modeled. If it doesn’t, then the implementation has done something that the mathematical model didn’t account for and an alarm is raised (failing the trace validation process). If the state pairs satisfy the predicate for the invariants corresponding to the security mechanism that is modeled, then the implementation preserves all the security mechanism invariants that have been proven in the mathematical model and a success is reported.

[0650] In system 2000, the trace validation mechanism 2004 generates an implementation validation model 2008 for this purpose. The implementation validation model 2008 is another mathematical model that is derived from the original mathematical model but includes the state transition predicate and invariant relation and all the collected traces from the unified trace log 2007. The trace validation mechanism 2004 then uses a combination of theorem provers 104 and model checkers 2017 in order to prove the invariant relation.

[0651] In one embodiment of system 2000, this mathematical model can be specified in temporal logic of actions (TLA+) with the transition relation 'Next(x, y)', and the recorded pre-and post- states s and s'. The implementation validation model is created with 'lnit(x) == x = s' and 'Next2(x, y) == y = s' / \Next(x, y)', and the validation check essentially is a mathematical model checking to see if the implementation validation model deadlocks or not.. If it does, then the state doesn't conform to the transition relation and therefore the implementation does not meet the mathematical model specification an alarm is raised (failing the trace validation process).

[0652] In some embodiments of system 2000, the failure of the trace validation mechanism 2004 may produce a mathematical counter-example which shows the type and details of the failed relation and corresponding states associated with it. This information can be used to fix the PEE implementation 2010 accordingly in order to make it conformant to the mathematical model 102.

[0653] FIG. 21 shows, schematically, an illustrative computer system 2100 on which aspects of the present disclosure may be implemented. For example, computer system 2100 may be used to implement system 100 and / or the subsystems discussed herein. In the example of FIG. 21, the computer system 2100 includes a processing unit 2101 having one or more computer hardware processors and one or more articles of manufacture that comprise at least one non-transitory computer-readable storage medium (e.g., a memory 2102) that may include, for example, volatile and / or non-volatile memory. Memory 2102 may store one or more instructions to program the processing unit 2101 to perform any of the functions described herein. Memory 2102 may also store one or more application programs and / or resources used by application programs (e.g., software libraries). Different portions of memory 2102 may be used for different storage purposes. For example, a non-volatile portion of memory 2102 may be used for long term storage, while volatile memory may be used to facilitate fast access for processing unit 2102. Though, memory 2102 may include any suitable type or combination of types of computer storage media that are able to store data. To perform any of the illustrative functionalities described herein, processing unit 2101 may execute one or more processor-executable instructions stored in memory 2102, which may serve as non-transitory computer-readable media storing processor-executable instructions for execution by the processing unit 2101. The computer system 2100 may have one or more input devices and / or output devices, such as devices 2103 and 2104 illustrated in FIG. 21. These devices may be used, for instance, to present a user interface. Examples of output devices that may be used to provide a user interface include printers, display screens, and other devices for visual output, speakers and other devices for audible output, braille displays and other devices for haptic output, etc. Examples of input devices that may be used for a user interface include keyboards, pointing devices (e.g., mice, touch pads, and digitizing tablets), microphones, etc. For instance, the input devices 2103 may include a microphone for capturing audio signals, and the output devices 2104 may include a display screen for visually rendering, and / or a speaker for audibly rendering, recognized text.

[0654] In the example of FIG. 21, computer system 2100 also includes one or more network interfaces (e.g., a network interface 2105) to enable communication via various networks (e.g., a network 2110). Computer networks include, for example and not limitation, local area networks (e.g., an enterprise network) and wide area networks (e.g., the Internet). Such networks may be based on any suitable technology operating according to any suitable protocol, and may include wireless networks and / or wired networks (e.g., fiber optic networks). It should be appreciated that components of computer system 2100 may be distributed across a computer network; this may be done, for example, to facilitate distributed processing, to achieve connectivity with (e.g., remote) input devices and / or output devices, or for any other suitable reason.

[0655] Having thus described several aspects of at least one embodiment of this invention, it is to be appreciated that various alterations, modifications, and improvements will readily occur to those skilled in the art.

[0656] Such alterations, modifications, and improvements are intended to be part of this disclosure, and are intended to be within the spirit and scope of the invention. Accordingly, the foregoing description and drawings are by way of example only.

[0657] All publications, patents, and patent applications mentioned in this specification are herein incorporated by reference to the same extent as if each individual publication, patent, or patent application was specifically and individually indicated to be incorporated by reference. To the extent publications and patents or patent applications incorporated by reference contradict the disclosure contained in the specification, the specification is intended to supersede and / or take precedence over any such contradictory material.

[0658] The above-described embodiments of the present invention can be implemented in any of numerous ways. For example, the embodiments may be implemented using hardware, software or a combination thereof. When implemented in software, the software code can be executed on any suitable processor or collection of processors, whether provided in a single computer or distributed among multiple computers.

[0659] Further, it should be appreciated that a computer may be embodied in any of a number of forms, such as a rack-mounted computer, a desktop computer, a laptop computer, or a tablet computer. Additionally, a computer may be embedded in a device not generally regarded as a computer but with suitable processing capabilities, including a Personal Digital Assistant (PDA), a smart phone or any other suitable portable or fixed electronic device.

[0660] Also, a computer may have one or more input and output devices. These devices can be used, among other things, to present a user interface. Examples of output devices that can be used to provide a user interface include printers or display screens for visual presentation of output and speakers or other sound generating devices for audible presentation of output.

[0661] Examples of input devices that can be used for a user interface include keyboards, and pointing devices, such as mice, touch pads, and digitizing tablets. As another example, a computer may receive input information through speech recognition or in other audible format.

[0662] Such computers may be interconnected by one or more networks in any suitable form, including as a local area network or a wide area network, such as an enterprise network or the Internet. Such networks may be based on any suitable technology and may operate according to any suitable protocol and may include wireless networks, wired networks or fiber optic networks.

[0663] Also, the various methods or processes outlined herein may be coded as software that is executable on one or more processors that employ any one of a variety of operating systems or platforms. Additionally, such software may be written using any of a number of suitable programming languages and / or programming or scripting tools, and also may be compiled as executable machine language code or intermediate code that is executed on a framework or virtual machine.

[0664] In this respect, the invention may be embodied as a computer readable medium (or multiple computer readable media) (e.g., a computer memory, one or more floppy discs, compact discs, optical discs, magnetic tapes, flash memories, circuit configurations in Field Programmable Gate Arrays or other semiconductor devices, or other tangible computer storage medium) encoded with one or more programs that, when executed on one or more computers or other processors, perform methods that implement the various embodiments of the invention discussed above. The computer readable medium or media can be transportable, such that the program or programs stored thereon can be loaded onto one or more different computers or other processors to implement various aspects of the present invention as discussed above.

[0665] In this respect, it should be appreciated that one implementation of the above-described embodiments comprises at least one computer-readable medium encoded with a computer program (e.g., a plurality of instructions), which, when executed on a processor, performs some or all of the above-discussed functions of these embodiments. As used herein, the term “computer-readable medium” encompasses only a computer-readable medium that can be considered to be a machine or a manufacture (i.e., article of manufacture). A computer-readable medium may be, for example, a tangible medium on which computer-readable information may be encoded or stored, a storage medium on which computer-readable information may be encoded or stored, and / or a non-transitory medium on which computer-readable information may be encoded or stored. Other non-exhaustive examples of computer-readable media include a computer memory (e.g., a ROM, a RAM, a flash memory, or other type of computer memory), a magnetic disc or tape, an optical disc, and / or other types of computer-readable media that can be considered to be a machine or a manufacture.

[0666] As used herein, a “set” may have one or more members. For example, “a set of programs” could have a single program or multiple programs. As used herein “subset” of a set may have the same number of members as the set or fewer members than the set but at least one member of the set. For example, a set of programs consisting of programs A, B, and C could be divided into the following seven subsets A; B; C; A, B; A, C; B, C; and A, B, C. A set may also be formed from other sets. For example, set X may be made up of set Y and set Z; that is set Y and set Z are each a subset of set X.

[0667] As used herein, the term “or” is intended to mean an inclusive “or,” and is used interchangeably with “and / or,” unless the context clearly dictates otherwise. Thus, “A or B” encompasses “A alone,” “B alone,” and “both A and B together.” Only where the specification explicitly describes alternatives as being mutually exclusive, or where such exclusivity is otherwise clearly required by the context, should “or” be construed as an exclusive “or.” The terms “program” or “software” are used herein in a generic sense to refer to any type of computer code or set of computer-executable instructions that can be employed to program a computer or other processor to implement various aspects of the present invention as discussed above. Additionally, it should be appreciated that according to one aspect of this embodiment, one or more computer programs that when executed perform methods of the present invention need not reside on a single computer or processor, but may be distributed in a modular fashion amongst a number of different computers or processors to implement various aspects of the present invention.

[0668] Also, data structures may be stored in computer-readable media in any suitable form. For simplicity of illustration, data structures may be shown to have fields that are related through location in the data structure. Such relationships may likewise be achieved by assigning storage for the fields with locations in a computer-readable medium that conveys relationship between the fields. However, any suitable mechanism may be used to establish a relationship between information in fields of a data structure, including through the use of pointers, tags or other mechanisms that establish relationship between data elements.

[0669] Various aspects of the present invention may be used alone, in combination, or in a variety of arrangements not specifically discussed in the embodiments described in the foregoing and is therefore not limited in its application to the details and arrangement of components set forth in the foregoing description or illustrated in the drawings. For example, aspects described in one embodiment may be combined in any manner with aspects described in other embodiments.

[0670] Also, the invention may be embodied as a method, of which an example has been provided. The acts performed as part of the method may be ordered in any suitable way.

[0671] Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.

[0672] For the purposes of describing and defining the present disclosure, it is noted that terms of degree (e.g., “substantially,” “slightly,” “about,” “comparable,” etc.) may be utilized herein to represent the inherent degree of uncertainty that may be attributed to any quantitative comparison, value, measurement, or other representation. Such terms of degree may also be utilized herein to represent the degree by which a quantitative representation may vary from a stated reference (e.g., about 10% or less) without resulting in a change in the basic function of the subject matter at issue. Unless otherwise stated herein, any numerical values appeared in this specification are deemed modified by a term of degree thereby reflecting their intrinsic uncertainty.

[0673] Use of ordinal terms such as “first,” “second,” “third,” etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed, but are used merely - Ill -as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term) to distinguish the claim elements.

[0674] Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of "including," "comprising," or “having,” “containing,” “involving,” and variations thereof herein, is meant to encompass the items listed thereafter and equivalents thereof as well as additional items.

Claims

CLAIMS1. A system comprising:a computer platform havingat least one processor, andat least one non-transitory computer-readable storage medium having stored thereon a set of program execution elements (PEE), each PEE of the set of PEEs (i) executable by the at least one processor, (ii) having a respective privilege level, (iii) in a respective memory address space, and (iv) enforcing a trusted path security mechanism; anda mathematical model of the computer platform, the mathematical modelhaving a formal representation of the at least one processor, the at least one non- transitory computer-readable storage medium, and the set of PEEs; anddefining and proving the trusted path security mechanism for the set of PEEs, the trusted path security mechanism enforcing permitted patterns of operations of the computer platform, the operations of the computer platform including at least one of (i) memory access operations; (ii) peripheral access operations; (iii) operations of the at least one processor including at least execution of processor instructions; and (iv) operations involving access to and manipulation of a state of the at least one processor (“processor state”), a state of the at least one non-transitory computer-readable storage medium (“memory state”), and / or a state of a peripheral (“peripheral state”).

2. The system of claim 1, wherein the computer platform further comprises at least one peripheral, and the formal representation in the mathematical model further includes the at least one peripheral.

3. The system of claim 1, whereinthe trusted path security mechanism comprises a privilege-separation mechanism that enforces access controls on the operations of the computer platform that involve peripheral access, or access to and manipulation of the processor state, the memory state, or the peripheral state; andthe access controls ensure that each of said operations is executed with a privilege level required to perform the operation.

4. The system of claim 3 whereinthe set of PEEs includes a first subset of PEEs and a second subset of PEEs; and the access controls enforced by the privilege-separation mechanism further comprise an access control policy;a caller PEE to initiate a privileged operation, the caller PEE in the first subset of PEEs and the respective memory address space of the caller PEE being a caller memory address space;a callee PEE to perform the privileged operation, the callee PEE in the second subset of PEE and the respective memory address space of the callee PEE being a callee memory address space; andan access control matrix utilized by the access controls to enforce caller PEE - callee PEE access control by allowing or denying calls per the access control policy.

5. The system of claim 3 wherein the privilege separation mechanism is implemented using at least one of (i) hardware capabilities of the computer platform and (ii) software verification and / or software fault isolation.

6. The system of claim 1, whereinthe operations of the computer platform include memory access operations; and the trusted path security mechanism includes a memory-safety mechanism to ensure that all the memory access operations are valid.

7. The system of claim 6, whereinthe at least one non-transitory computer-readable storage medium includes allocated memory; andthe memory-safety mechanism has(i) a spatial memory safety mechanism to control memory layout and memory access boundaries and to ensure that the memory accesses operations are within valid bounds, and(ii) a temporal memory safety mechanism to ensure that the memory access operations are consistent with respect to a lifetime and state of the allocated memory.

8. The system of claim 7, wherein the spatial memory safety mechanism enforces memory protections for a subset of PEEs within the set of PEEs by utilizing(a) hardware capabilities of the computer platform and platform memory management unit (MMU) configuration to set guard memory regions and global offset table (GOT) as readonly; and / or(b) software-based verification and / or software fault isolation enforced within code of the PEEs within the subset to set the guard memory regions and GOT as read-only.

9. The system of claim 7, wherein the spatial memory safety mechanism adds guard memory regions preceding and succeeding PEE global data variables for a subset of PEEs within the set of PEEs and enforces memory protections by utilizing(a) hardware capabilities of the computer platform and platform memory management unit (MMU) configuration by a higher-privileged PEE outside the subset of PEEs to set the guard memory regions as read-only, the higher-privileged PEE having a higher privilege level than any of the PEEs in the subset of PEEs; and / or(b) software-based verification and / or software fault isolation enforced within code of the PEEs within the subset to set the guard memory regions as read-only.

10. The system of claim 7, whereinthe spatial memory safety mechanism has a data bounds safety mechanism for a subset of PEEs within the set of PEEs,the data bounds safety mechanism (i) associates each of a plurality of PEE variables with information about size and alignment of said PEE variable and (ii) emits runtime checks in a PEE code region to ensure access to said PEE variables are always within the valid bounds.

11. The system of claim 7, wherein the temporal memory safety mechanism further comprises a heap safety mechanism to monitor allocations, deallocations and protection of pre-defined memory regions.

12. The system of claim 11 whereina total memory address space is a union of each of the respective memory address spaces of the PEEs in the set of PEEs; andthe heap safety mechanism comprises (i) one or more heap manager PEEs in the set of PEEs to manage physical and virtual memory mappings within the total memory address space; (ii) said one or more heap manager PEEs execute at one or more privilege levels; and (iii) said one or more heap manager PEEs each have one or more functions that enforces memory protection against heap allocation and deallocation attacks.

13. The system of claim 12 wherein the one or more functions are implemented using at least one of hardware capabilities of the computer platform, software verification, and software fault isolation.

14. The system of claim 1, whereinthe trusted path security mechanism comprises a control-flow integrity (CFI) mechanism to ensure that execution of the processor instructions follows the permitted patterns.

15. The system of claim 14, whereinthe processor instructions include of one or more branch instructions and one or more return instructions that, respectively, transfer control to and return control to specific processor instructions in a processor instruction flow; andthe CFI mechanism comprisesa code-safety mechanism to ensure that the processor instructions, once executed by the at least one processor, are immutable in the respective memory address space of a first PEE in the set of PEEs; anda stack-safety mechanism to enforce integrity of the processor state for both the branch instructions and the return instructions thereby preserving overall integrity of the processor instruction flow.

16. The system of claim 15, wherein the code-safety mechanism enforces memory protections for a subset of PEEs within the set of PEEs by utilizing(a) hardware capabilities of the computer platform and platform memory management unit (MMU) configuration by a higher-privileged PEE outside the subset of PEEs to set PEE code memory regions as read-only, the higher-privileged PEE having a higher privilege level than any of the PEEs in the subset of PEEs; and / or(b) software-based verification and / or software fault isolation enforced within code of the PEEs within the subset to set the PEE code memory regions as read-only.

17. The system of claim 15, wherein the code-safety mechanism further enforces memory protections for a subset of PEEs within the set of PEEs by utilizing(a) hardware capabilities of the computer platform and platform memory management unit (MMU) configuration by a higher-privileged PEE outside the subset of PEEs to set PEE procedure linkage table (PLT) memory regions as read-only, the higher-privileged PEE having a higher privilege level than any of the PEEs in the subset of PEEs; and / or(b) software-based verification and / or software fault isolation enforced within code of the PEEs within the subset to set the PEE PLT memory regions as read-only.

18. The system of claim 15, whereinthe stack-safety mechanism comprisesa forward-edge CFI mechanism to ensure that the processor instructions in the processor instruction flow are valid and authorized; anda backward-edge CFI mechanism to ensure that return instructions from a prior branch instruction occur to valid and authorized processor instructions.

19. The system of claim 18, whereinthe set of PEEs includes a second PEE that is the same or different than the first PEE; the one or more branch instructions include a first branch instruction;the set of PEEs includes an external PEE; andthe forward-edge CFI mechanism further validates that a memory address to which the first branch instruction transfers control to within the second PEE in the set of PEEs(i)(a) is within a valid memory region containing PEE code, (b) points to a valid PEE function of the second PEE, or (c) points to the external PEE;(ii) is aligned correctly; and(iii) matches a signature of a valid PEE function prototype or a signature of the valid PEE code region block.

20. The system of claim 18, whereinthe backward-edge CFI mechanism further validates that a first memory address to which a first return instruction transfers control is (i) within a valid first memory region containing first PEE code, (ii) aligned correctly, (iii) follows the prior branch instruction that invoked a target PEE function or second memory region containing second PEE code; and (iv) contains a hash value adjacent to the first memory address of the prior branch instruction that matches a hash of a prototype of the PEE target function or a hash of a third memory region containing third PEE code;the first return instruction is among the return instructions;the valid first memory region is the same or different as the second memory region; the second memory region is the same or different as the third memory region;the valid first memory region is the same or different as the third memory region; the first PEE code is the same or different as the second PEE code;the second PEE code is the same or different as the third PEE code; andthe first PEE code is the same or different as the third PEE code.

21. The system of claim 18, wherein the backward-edge CFI mechanism comprises a meta-stack mechanism to ensure every PEE function in a first PEE among the set of PEEs (i) has a local stack for storing local variables and a meta stack for storing return instruction addresses, (ii) always executes the return instructions using the meta stack to obtain a return instruction pointer, and (iii) always writes to the local variables using the local stack.

22. The system of claim 18, wherein the backward-edge CFI mechanism further comprises a stack-frame protection canary mechanism to ensure that each PEE function in a first PEE among the set of PEEs (i) stores a random value (the “canary”) at a beginning of a stack frame of the PEE function before a memory location of a first local variable within the stack frame and (ii) before returning from the PEE function, ensures a value currently at the beginning of the stack frame matches the canary.

23. The system of claim 18 wherein the forward edge CFI mechanism and backward edge CFI mechanism are implemented using at least one of (i) hardware capabilities of the computer platform, and (ii) software verification and / or software fault isolation.

24. The system of claim 18 wherein the forward edge CFI mechanism and backward edge CFI mechanism are implemented on PEE code.

25. The system of claim 1, whereinthe set of PEEs includes a first PEE and a second PEE, having first and second privilege levels, respectively, the first privilege level being a higher privilege level than the second privilege level; andthe first PEE utilizes a first memory address space and the second PEE utilizes a second memory address space different from the first memory address space.

26. The system of claim 1 whereinthe mathematical model (i) defines operational aspects of hardware elements and software stack elements, (ii) defines predicates for security mechanisms on the computer platform that are translatable to proof obligations in a composable manner, and (iii) interprets and verifies the proof obligations;the hardware elements comprise the at least one processor, and the at least one non-transitory computer-readable storage medium; andthe software stack elements comprise the set of PEEs.

27. The system of claim 1, whereina first subset of the set of PEEs are implemented in a low-level programming language; a second subset of the set of PEEs are implemented in a high-level programming language;the PEEs in the first subset enforce the trusted path security mechanism; and the PEEs in the second subset enforce the trusted path security mechanism.

28. The system of claim 1, wherein the mathematical model(i) defines a first subset of the set of PEEs are implemented in a low-level programming language;(ii) defines a second subset of the set of PEEs are implemented in a high-level programming language; and(iii) defines and proves the trusted path security mechanism of the union of the PEEs of the first subset and the PEEs in the second subset.

29. The system of claim 1 wherein the at least one non-transitory computer-readable storage medium has stored thereon the mathematical model.

30. The system of claim 1 wherein each of the PEEs in the set of PEEs comprise one or more of the group consisting of a source code file, a binary executable file, a script executable file, a configuration file, and a platform-specific configuration file.

31. The system of claim 1 whereineach PEE in a subset of the set of PEEs includesone or more functions to form an atomic unit of functionality of the PEE; and a memory map in the respective memory address space, the memory map comprising one or more of the group consisting of code regions, global data variables, heaps, stacks, procedure linkage table (PLT) entries, and global offset table (GOT) entries;each of the one or more functions is composed of a set of instructions including return instruction and a return instruction pointer; andthe memory map is randomized at a time the respective PEE is loaded into its respective memory address space.

32. The system of claim 31 wherein each PEE in a subset of the set of PEEs further includes operational semantics for the one or more functions, the operational semantics comprising one or more of the group consisting of semantics for reading and writing to global variables, stack, and heap; allocating and freeing heaps; calling other functions within the PEE; calling functions of another PEE; and returning to a parent PEE function.

33. A system, comprising:a computer platform having:at least one processor; andat least one non-transitory computer-readable storage medium having stored thereon a set of program execution elements (PEEs), each PEE of the set of PEEs being (i) executable by the at least one processor, (ii) having a respective privilege level, (iii) in a respective memory address space, and (iv) enforcing security through an interfaceconfined security mechanism (ICSM) comprising a subset of the set of PEEs (“ICSM PEEs”) that establish boundary limiting interactions (“bastion interfaces”) with resources of the computer platform for a set of adversary-controlled PEEs, wherein said ICSM PEEs are at a higher privilege level than the adversary-controlled PEEs; anda mathematical model of the computer platform to define and prove the ICSM, the mathematical model havinga formal representation of the at least one processor, the at least one non- transitory computer-readable storage medium, and the set of PEEs; andat least one adversary model for each of the bastion interfaces,whereinthe set of PEEs includes the set of adversary-controlled PEEs; andthe ICSM ensures security mechanisms of the computer platform by enforcing the bastion interfaces.

34. The system of claim 33 wherein the resources of the computer platform are one or more of the at least one processor, the at least one non-transitory computer-readable storage medium, memory address space, and peripherals.

35. The system of claim 33, whereinthe set of PEEs includes a first PEE and a second PEE, having first and second privilege levels, respectively, the first privilege level being a higher privilege level than the second privilege level; andthe first PEE utilizes a first memory address space and the second PEE utilizes a second memory address space different from the first memory address space.

36. The system of claim 33, wherein the computer platform further comprises at least one peripheral, and the formal representation in the mathematical model further includes the at least one peripheral.

37. The system of claim 33 whereinthe mathematical model further (i) defines operational aspects of hardware elements and software stack elements, (ii) defines predicates for security mechanisms on the computerplatform that are translatable to proof obligations, and (iii) includes a theorem prover to interpret and verify the proof obligations;the hardware elements comprise the at least one processor, and the at least one non-transitory computer-readable storage medium; andthe software stack elements comprise the set of PEEs.

38. The system of claim 33 wherein the ICSM includes an approved code execution mechanism to ensure that only authorized PEEs are executed in the computer platform.

39. The system of claim 38 wherein the approved code execution mechanism comprises an approved code execution provisioning mechanism to provision authorized PEEs.

40. The system of claim 39 whereinthe computer platform is a first computer platform; andthe approved code execution provisioning mechanism provisions authorized PEEs from a second computer platform that is local or remote to the first computer platform.

41. The system of claim 38 whereinthe at least one non-transitory computer-readable storage medium has stored thereon a set of files; andthe approved code execution mechanism comprises a file protection mechanism to ensure that a subset of the set of files are always read-only.

42. The system of claim 41 wherein the subset of files comprises one or more of PEE executable files and / or one or more PEE configuration files.

43. The system of claim 41 whereinthe bastion interfaces include a subset of bastion interfaces;the subset of bastion interfaces includes one or more non-volatile storage interfaces and one or more volatile storage interfaces; andthe file protection mechanism uses the subset of bastion interfaces to set the subset of the set of files to read-only.

44. The system of claim 38 whereinthe set of PEEs includes a first subset of PEEs;the PEEs in a first subset of PEEs comprises PEE executable files and the approved code execution mechanism further comprises a PEE load protection mechanism that loads authorized PEE executable files from the at least one non-transitory computer-readable storage medium to a memory address space.

45. The system of claim 38 whereinthe set of PEEs includes a subject PEE;the set of PEEs includes a first subset of PEEs;the PEEs in the first subset of PEEs comprises PEE executable files;the PEE executable files include PEE executable code regions and a set of memory regions; andthe approved code execution mechanism further comprises a PEE execute protection mechanism that marks PEE executable code regions of the subject PEE and a subset of the set of memory regions in the respective memory address space of the subject PEE as read-only before executing the PEE executable files in the memory address space.

46. The system of claim 38 whereinthe set of PEEs includes a subject PEE;the set of PEEs includes a first subset of PEEs;the PEEs in the first subset of PEEs comprises PEE executable files; andthe approved code execution mechanism further comprises a PEE unload protection mechanism to unload authorized PEE executable files of the subject PEE from the respective memory address space of the subject PEE and to perform cleanup of the respective memory address space once execution of the subject PEE is complete.

47. The system of claim 38 whereinthe bastion interfaces includes at least one or more of the group consisting of a code execution interface, a memory interface, a non-volatile storage interface, a device interface, a processor interface, and a volatile storage interface; andthe approved code execution mechanism uses a subset of the bastion interfaces to execute PEEs in the set of PEEs.

48. The system of claim 38 wherein the approved code execution mechanism is instantiated at a plurality of privilege levels and in a plurality of memory address spaces.

49. The system of claim 33 whereinthe bastion interfaces include cryptographic operation interfaces; andthe ICSM includes an approved cryptographic operation mechanism to ensure that only authorized cryptographic keys and the cryptographic operation interfaces are used for encryption and decryption in the computer platform.

50. The system of claim 49 wherein the approved cryptographic operation mechanism comprises a provisioning mechanism to provision authorized cryptographic keys.

51. The system of claim 50 wherein the provisioning mechanism provisions authorized cryptographic keys from a local key-signing agent and / or a remote key-signing agent.

52. The system of claim 49 wherein the approved cryptographic operation mechanism comprises a cryptographic key enforcement mechanism to enforce that only authorized cryptographic keys and authorized cryptographic operation interfaces are used at all times.

53. The system of claim 52 wherein the cryptographic key enforcement mechanism includes cryptographic operation interfaces for one or more of encryption, decryption, digital signatures, hashing, key-exchange, key-derivation, message authentication code, random number generation, and zero-knowledge proofs cryptographic operations.

54. The system of claim 52 wherein the cryptographic operations performed by the cryptographic operation interfaces only use authorized cryptographic keys.

55. The system of claim 49 wherein the computer platform securely stores authorized cryptographic keys in the at least one non-transitory computer-readable storage medium.

56. The system of claim 55 wherein the authorized cryptographic keys are stored securely in the at least one non-transitory computer-readable storage medium in a persistent manner.

57. The system of claim 55 whereinthe set of PEEs includes one or more sentinel PEEs; andthe authorized cryptographic keys are stored securely in the respective memory address space(s) of the one or more sentinel PEEs.

58. The system of claim 49 wherein the approved cryptographic operation mechanism is instantiated at a plurality of privilege levels and in a plurality of memory address spaces.

59. The system of claim 33 wherein the ICSM PEEs include an approved network communication mechanism to ensure that only authorized external computer platforms and authorized network operation interfaces are used for receiving and sending data into and out of the computer platform.

60. The system of claim 59 wherein the approved network communication mechanism comprises an approved network communication provisioning mechanism to provision the set of authorized external computer platforms, authorized network operation interfaces and authorized network communication policies.

61. The system of claim 60 wherein the approved network communication provisioning mechanism provisions the set of authorized external computer platforms, authorized network operation interfaces and the authorized network communication policies from an approved network communication policy repository.

62. The system of claim 60 wherein the authorized network communication policies are stored securely in the at least one non-transitory computer-readable storage medium.

63. The system of claim 66 wherein the authorized network communication policies are stored securely in a persistent manner.

64. The system of claim 62 whereinthe set of PEEs includes one or more sentinel PEEs; andthe authorized network communication policies are stored securely in the respective memory address space(s) of the one or more sentinel PEEs.

65. The system of claim 59 wherein the approved network communication mechanism comprises an approved network communication enforcement mechanism that enforces the authorized network operation interfaces and authorized network communication policies on the computer platform at all times.

66. The system of claim 65 wherein the approved network communication enforcement mechanism includes network operation interfaces for one or more of receive, send, bind, and configure operations.

67. The system of 66 wherein the network operations performed by the network operation interfaces enforce the authorized network communication policies.

68. The system of claim 65 wherein the approved network communication enforcement mechanism filters incoming and outgoing network traffic using a packet filtering framework.

69. The system of claim 68 whereinthe approved network communication enforcement mechanism utilizes the network operation interfaces to perform the filtering and to enforce the authorized network communication policies.

70. The system of claim 59 wherein the approved network communication mechanism is instantiated at a plurality of privilege levels and in a plurality of memory address spaces.

71. The system of claim 33 wherein the ICSM PEEs comprises a memory-safety mechanism to ensure that all memory access operations are valid.

72. The system of claim 33 wherein the ICSM PEEs comprises a control-flow integrity mechanism to ensure that execution of instructions by the at least one processor follows authorized patterns.

73. The system of claim 33 whereinthe ICSM PEEs comprises a privilege-separation mechanism to enforce access controls on operations of the computer platform that involve peripheral access, or access to and manipulation of processor state, memory state, or peripheral state; andthe access controls ensure that each of the operations is executed with a privilege level required to perform the operation.

74. A system for providing formal verification of a design and operation of a computer platform, the system comprising:a processor; anda first non-transitory computer-readable storage medium having stored thereon instructions that, when executed, program the processor to perform act(s) ofevaluating a mathematical model that (i) models the computer platform with a formal representation of a set of processors of the computer platform (“platform processors”), a second non-transitory computer-readable storage medium of the computer platform (“platform memory”), and a set of program execution elements (PEEs) of the computer platform, and (ii) specifies invariants to enforce an interface confined security mechanism (ICSM), with assume-guarantee interface-confined mathematical reasoning; anddetermining from the evaluation that the ICSM holds true for the computer platform,wherein each PEE in the set of PEEs is modelled as (i) executable by the platform processors, (ii) having a respective privilege level and (iii) utilizing a respective memory address space in the platform memory.

75. The system of claim 74, wherein the ICSM comprises at least one of the group consisting of a trusted path security mechanism, an approved code execution mechanism, an approved cryptographic operations mechanism, and an approved network communication mechanism.

76. The system of claim 74, wherein the act of determining comprises determining from the evaluation whether the ICSM holds true for the computer platform regardless of an organization of the PEEs in the set of PEEs of the computer platform.

77. The system of claim 74, wherein the act of determining comprises determining from the evaluation whether the ICSM holds true for the computer platform regardless of a composition of the PEEs of the set of PEEs of the computer platform.

78. The system of claim 74, wherein the formal representation in the mathematical model further includes (x) a subset of the set of PEEs that are adversary-controlled and (y) at least one adversary model for each of the adversary-controlled PEEs.

79. The system of claim 74 further comprising a mathematical model implementation validation mechanism to validate that the set of PEEs implement the ICSM specified in the mathematical model.

80. The system of claim 79, wherein the mathematical model implementation validation mechanism comprises a test generation mechanism to generate test cases from the mathematical model.

81. The system of claim 79, wherein the mathematical model implementation validation mechanism comprises a trace capture mechanism to collect accurate and reliable traces of PEE execution.

82. The system of claim 79, wherein the mathematical model implementation validation mechanism comprises a trace validation mechanism to evaluate if traces of PEE execution conform to the mathematical model.

83. The system of claim 74, whereina first subset of the set of PEEs are implemented in a low-level programming language; a second subset of the set of PEEs are implemented in a high-level programming language; andthe mathematical model ensures a composition of the ICSM of the union of the PEEs of the first subset and the PEEs in the second subset.

84. The system of claim 74, whereinthe set of PEEs includes a first PEE and a second PEE, having first and second privilege levels, respectively, the first privilege level being a higher privilege level than the second privilege level; andthe first PEE utilizes a first memory address space and the second PEE utilizes a second memory address space different from the first memory address space.

85. The system of claim 74, wherein the mathematical model contains a formal representation of the set of PEEs, the formal representation comprising (i) an interface defined for each PEE in the set of PEEs, wherein the interface includes conditions that must be met before and after execution of one or more PEE functions of the respective PEE; (ii) a specification of the platform memory and memory regions accessible for each PEE in the set of PEEs; (iii) a representation of conditions as predicates over the platform memory’s state(s) and the platform processors’ state(s), where the predicates indicate whether the platform memory’s state(s) and the platform processors’ state(s) satisfy the conditions; and (iv) enforced invariants of the ICSM at a start and at an end of each PEE function execution.

86. The system of claim 74, whereinthe mathematical model contains a formal representation of the computer platform and operational aspects of the PEEs in the set of PEEs, the formal representation comprising first executable instructions for defining an initial configuration of the platform processors and an initial global platform memory state;second executable instructions for executing a series of concurrent steps on each of the platform processors, wherein each step is associated an operation being performed and a first PEE in the set of PEEs associated with the operation; andthird executable instructions for managing an internal state of each of the platform processors, starting new threads, and assigning memory addresses to each thread; andthe ICSM is enforced by checking corresponding invariants for each PEE function call.

87. The system of claim 86, whereinthe mathematical model further comprises a formal representation and model of a lock on a PEE function, the lock preventing the PEE function from being called if it is already active;the mathematical model requires waiting until the lock is released before proceeding with the PEE function call;the model of the lock ensures that only one instance of the PEE function can be executed at a time across the platform processors.

88. The system of claim 86, wherein the mathematical model contains a formal representation of interrupt handling on the computer platform, the formal representation of interrupt handling comprising:fourth executable instructions for executing an interrupt handler function within a first PEE in the set of PEEs for each of the platform processors in response to an interrupt, the interrupt handler function has its own assigned memory address space;fifth executable instructions for preemptively executing the interrupt handler function at any point in time with an assigned privilege level; andsixth executable instructions for returning control to an original interrupted PEE function after the interrupt handler function terminates.

89. The system of claim 74, wherein the mathematical model includes a formal representation of the ICSM that further includes a memory-safety mechanism to ensure that all memory access operations on the computer platform are valid.

90. The system of claim 89, wherein the formal representation of memory-safety mechanism comprises (x) a spatial memory safety mechanism that controls memory layout and memory access boundaries to ensure the memory accesses operations are within valid bounds; and (y) a temporal memory safety mechanism that ensures that memory accesses are valid and consistent with respect to the lifetime and state of allocated memory, preventing unauthorized or erroneous memory accesses.

91. The system of claim 74 wherein the mathematical model includes a formal representation of the ICSM that further includes a control-flow integrity mechanism that ensures that execution of PEEs by the platform processors follows authorized patterns and do not compromise the integrity of the computer platform.

92. The system of claim 91 wherein the formal representation of the control -flow integrity mechanism comprises (i) a code-safety mechanism that ensures that PEE execution by platform processors are immutable in a given memory address space; and (ii) a stack-safety mechanism that enforces the integrity of the platform processors’ state(s) for PEE execution by the platform processors.

93. The system of claim 74 whereinthe mathematical model includes a formal representation of the ICSM that further includes a privilege-separation mechanism that enforces access controls on operations of the computer platform that involve peripheral access, or access to and manipulation of the platform processors’ state(s), the platform memory’s state(s), or the peripheral’s state(s); andthe access controls ensure that each of said operations is executed with a privilege level required to perform the operation.

94. The system of claim 74, wherein the formal representation in the mathematical model further includes a peripheral of the computer platform (“platform peripheral”).

95. The computer platform of claim 74 whereinthe mathematical model further defines predicates for the ICSM on the computer platform that are translatable to proof obligations; andthe mathematical model includes a theorem prover to interpret and verify the proof obligations.

96. A computer-implemented method for formal verification of a design and operation of a computer platform, the method comprising acts of:evaluating a mathematical model that (i) models the computer platform with a formal representation of a set of processors of the computer platform (“platform processors”), a non-transitory computer-readable storage medium of the computer platform (“platform memory”), and a set of program execution elements (PEEs) of the computer platform, and (ii) specifies invariants to enforce an interface confined security mechanism (ICSM), with assume-guarantee interface-confined mathematical reasoning; anddetermining from the evaluation that the ICSM holds true for the computer platform,wherein each PEE of the set of PEEs are modelled as (a) executable by the platform processor, (b) having a respective privilege level, and (c)utilizing a respective memory address space in the platform memory.

97. The computer-implemented method of claim 96, wherein the ICSM comprises at least one of the group consisting of a trusted path security mechanism, an approved code execution mechanism, an approved cryptographic operations mechanism, and an approved network communication mechanism.

98. The computer-implemented method of claim 96, wherein the act of determining comprises determining from the evaluation whether the ICSM holds true for the computer platform regardless of an organization of the PEEs in the set of PEEs of the computer platform.

99. The computer-implemented method of claim 96, wherein the act of determining comprises determining from the evaluation whether the ICSM holds true for the computer platform regardless of a composition of the PEEs of the set of PEEs of the computer platform.

100. The computer-implemented method of claim 96, wherein the formal representation in the mathematical model further includes (x) a subset of the set of PEEs that are adversary-controlled and (y) at least one adversary model for each of the adversary-controlled PEEs.

101. The computer-implemented method of claim 96 further comprising an act of validating, with a mathematical model implementation validation mechanism, that the set of PEEs implement the ICSM specified in the mathematical model.

102. The computer-implemented method of claim 101 further comprising an act of generating, with a test generation mechanism of the mathematical model implementation validation mechanism, test cases from the mathematical model.

103. The computer-implemented method of claim 101 further comprising an act of collecting, with a trace capture mechanism of the mathematical model implementation validation mechanism, accurate and reliable traces of PEE execution.

104. The computer-implemented method of claim 101 further comprising an act of evaluating, with a trace validation mechanism of the mathematical model implementation validation mechanism, if traces of PEE execution conform to the mathematical model.

105. The computer-implemented method of claim 96, wherein a first subset of the set of PEEs are implemented in a low-level programming language and a second subset of the set of PEEs are implemented in a high-level programming language, the computer-implemented method further comprising an act of ensuring, with the mathematical model, a composition of the ICSM of the union of the PEEs of the first subset and the PEEs in the second subset.

106. The computer-implemented method of claim 96, whereinthe set of PEEs includes a first PEE and a second PEE, having first and second privilege levels, respectively, the first privilege level being a higher privilege level than the second privilege level; andthe first PEE utilizes a first memory address space and the second PEE utilizes a second memory address space different from the first memory address space.

107. The computer-implemented method of claim 96, wherein the mathematical model contains a formal representation of the set of PEEs, the formal representation comprising (i) an interface defined for each PEE in the set of PEEs, wherein the interface includes conditions that must be met before and after execution of one or more PEE functions of the respective PEE; (ii) a specification of the platform memory and memory regions accessible for each PEE in the set of PEEs; (iii) a representation of conditions as predicates over the platform memory’s state(s) and the platform processors’ state(s), where the predicates indicate whether the platform memory’s state(s) and the platform processors’ state(s) satisfy the conditions; and (iv) enforced invariants of the ICSM at a start and at an end of each PEE function execution.

108. The computer-implemented method of claim 96 further comprising acts of providing, through the mathematical model, first executable instructions for defining an initial configuration of the platform processors and an initial global platform memory state; providing, through the mathematical model, second executable instructions for executing a series of concurrent steps on each of the platform processors, wherein each step is associatedwith a type label indicating an operation being performed and a PEE associated with the operation; andproviding, through the mathematical model, third executable instructions for managing an internal state of each of the platform processors, including starting new threads, and assigning memory locations to each thread,wherein the ICSM is enforced by checking corresponding invariants for each PEE function call.

109. The computer-implemented method of claim 108 further comprising an act of providing, through the mathematical model, a formal representation and model of a lock on a PEE function by preventing the PEE function from being called if it is already active, wherein the mathematical model requires waiting until the lock is released before proceeding with the PEE function call, and the model of the lock ensures that only one instance of the PEE function can be executed at a time across the platform processors.

110. The computer-implemented method of claim 108 further comprising acts of providing, through the mathematical model, fourth executable instructions for executing an interrupt handler function within a first PEE in the set of PEEs for each of the platform processors in response to an interrupt, the interrupt handler function has its own assigned memory address space;providing, through the mathematical model, fifth executable instructions for preemptively executing the interrupt handler function at any point in time with an assigned privilege level; andproviding, through the mathematical model, sixth executable instructions for returning control to an original interrupted PEE function after the interrupt handler function terminates.

111. The computer-implemented method of claim 96, wherein the mathematical model includes a formal representation of the ICSM that further includes a memory-safety mechanism which ensures that all memory access operations are valid.

112. The computer-implemented method of claim 111, wherein the formal representation of memory-safety mechanism comprises (x) a formal representation of a spatial memory safety mechanism that controls memory layout and memory access boundaries ensuring memory accesses are within valid bounds; and (y) a formal representation of a temporal memory safetymechanism that ensures that memory accesses are valid and consistent with respect to the lifetime and state of allocated memory, preventing unauthorized or erroneous memory accesses.

113. The computer-implemented method of claim 96, wherein the mathematical model includes a formal representation of the ICSM that further includes a control-flow integrity mechanism that ensures that execution of PEEs by the platform processors follows authorized patterns.

114. The computer-implemented method of claim 113, wherein the formal representation of control-flow integrity mechanism comprises (i) a code-safety mechanism that ensures that PEE execution by platform processors are immutable in a given memory address space; and (ii) a stack-safety mechanism that enforces the integrity of the platform processors’ state(s) for PEE execution by the platform processors.

115. The computer-implemented method of claim 96, whereinthe mathematical model includes a formal representation of the ICSM that further includes a formal representation of a privilege-separation mechanism that enforces access controls on operations of the computer platform that involve peripheral access, or access to and manipulation of the platform processors’ state(s), the platform memory’s state(s), or the peripheral’s state(s); andthe access controls ensure that each of said operations is executed with a privilege level required to perform the operation.

116. The computer-implemented method of claim 96, wherein the formal representation in the mathematical model further includes a peripheral of the computer platform (“platform peripheral”).

117. The computer-implemented method of claim 96, whereinthe mathematical model further defines predicates for the ICSM on the computer platform that are translatable to proof obligations; andthe mathematical model includes a theorem prover to interpret and verify the proof obligations.

Images