System and method for generating trust binaries

Abstract

Various implementations described herein include methods and devices for creating and using trusted binaries. In one aspect, the method includes obtaining executable code of a program, identifying a plurality of executable functions from the executable code, and for each executable function of the plurality of executable functions, generating a respective function digest based on one or more static components of the respective executable function. The method further includes building a respective trusted binary for each executable function of the plurality of executable functions that includes the respective digest, generating a trusted binary name by applying a hash function to a header of the executable code, and indexing the trusted binary in a trust database using the trusted binary name.

Description

Technical Field

[0003] ,

[0001] Cross - Reference to Related Applications This application is a continuation of (1) U.S. Patent Application No. 17 / 684,363, filed on March 1, 2022, titled "SYSTEMS AND METHODS FOR GENERATING TRUST BINARIES"; (2) U.S. Patent Application No. 17 / 688,878, filed on March 7, 2022, titled "SYSTEMS AND METHODS FOR IMPLEMENTING CYBERSECURITY USING TRUST BINARIES"; (3) U.S. Patent Application No. 17 / 735,087, filed on May 2, 2022, titled "ATA STRUCTURE FOR TRUST STORE"; and (4) U.S. Patent Application No. 17 / 735,101, filed on May 2, 2022, titled "SYSTEMS AND METHODS FOR IMPLEMENTING CYBERSECURITY USING BLOCKCHAIN VALIDATION", each of which is hereby incorporated by reference in its entirety.

[0002] The disclosed implementations generally relate to cybersecurity, and more specifically, to systems and methods for using trustworthy binaries to implement cybersecurity.

Background Art

[0003] Cybersecurity, the practice of protecting systems and networks from digital attacks, is becoming increasingly important in the digital age. Digital attacks are becoming more sophisticated, and traditional endpoint detection and response (EDR) solutions are losing their effectiveness. Many traditional EDR solutions are designed to detect and stop known attacks. However, there can be a significant delay (e.g., days, weeks, or even months) between the time a new attack is deployed and the time the EDR solution is updated to detect and stop the attack. Furthermore, malware is becoming increasingly diverse and its behavioral patterns are constantly changing. This polymorphism further increases the response time of traditional EDR solutions. [Overview of the project]

[0004] The zero-trust (ZT) system described in this disclosure protects a computer from unknown malicious code. Code must first be loaded into memory before it can be executed. As an example, a ZT system has a trust agent (e.g., an OS-specific trust agent) that monitors each program as it is loaded into memory and validates the program's code. The validation procedure in this example uses a trust binary, which is an alternate digital version of the original code. To execute the code in this example, the ZT system requires the corresponding trust binary for the code. If the trust binary is missing or uncorrelated, in this example, the code will not be permitted to run on the system.

[0005] In some implementations, a trusted binary is used by the ZT system to verify that the executable code has not been tampered with before execution. For example, a trusted binary is created for an executable file (e.g., an executable program) by first identifying the code segments of the file. Next, the code segments are scanned and the executable functions within each are identified. In this example, for each identified function, a function digest is created based on the function's starting address and its static components. The function digests of the identified functions are combined into a trusted binary for the file. In this example, the trusted binary name is generated by hashing the file header, and the trusted binary is added to a trusted database (e.g., a trusted store) indexed by the trusted binary name.

[0006] In some implementations, trusted binaries are used to protect all executable code in memory on a protected device. For example, ZT protection is implemented as a kernel agent (e.g., a kernel-level device driver). In this example, the kernel agent runs in ring-0 on the protected device, and the application code runs in ring-3. An exemplary ZT protection procedure involves loading the kernel agent, which loads its trusted binaries from a trusted database and verifies that the code in memory matches the trusted binaries (e.g., has not been tampered with). In this example, the agent performs spot validity verification during execution whenever the code attempts to perform certain system-level operations, such as file I / O operations, registry I / O operations, thread start and stop operations, and image load and unload operations. Additional measures may also be employed to protect against a wide range of attacks, as will be described in more detail later. In this example, if the code does not match the trusted binaries, or if one of the measures detects an attack, the process is either stopped and forensics are captured, or the process is allowed to continue but forensics are captured (e.g., based on device policy).

[0007] In various situations, the ZT system of this disclosure has the following advantages over conventional cybersecurity systems: Firstly, according to some implementations, the ZT system is effective against newly emerging threats because the system blocks all untrusted binary files and therefore there is no vulnerability period while the threat is identified. Secondly, according to some implementations, the ZT system is highly effective because it does not rely on past trends and does not produce false negatives when identifying untrusted binaries. Thirdly, according to some implementations, the ZT system monitors memory and protects against attacks initiated in memory through legitimate processes and applications. Fourthly, the ZT system can operate on off-network (e.g., air-gapped) systems because it can maintain its trust store and authenticate its validity without requiring network access.

[0008] According to several implementations, the method is performed on a computing device having memory and one or more processors. The method includes (i) obtaining the executable code of a program; (ii) identifying multiple executable functions from the executable code; (iii) for each of the multiple executable functions, generating a function digest based on one or more static components of each executable function; (iv) constructing a trust binary containing the digests for each of the multiple executable functions; (v) generating a trust binary name by applying a hash function to the header of the executable code; and (vi) indexing the trust binary in a trust database using the trust binary name.

[0009] According to several implementations, the method is performed on a computing device having memory and one or more processors. The method includes (i) running a trust agent; (ii) detecting future execution of a program on the computing device via the trust agent; (iii) retrieving a trust binary for the program from a trust store in memory in response to the detection; (iv) verifying the authenticity of the program by comparing the executable code of the program with the retrieved trust binary for the program; (v) permitting the execution of the program in accordance with the verified authenticity of the program; (vi) identifying future execution of executable functions within the program by monitoring the execution of the program; (vii) retrieving a function digest corresponding to the executable function from the trust binary in response to identifying the future execution of the executable function; (viii) verifying the authenticity of the executable function by comparing the executable code of the executable function with the retrieved function digest; and (ix) permitting the execution of the executable function in accordance with the verified authenticity of the executable function.

[0010] In some implementations, a computer-readable storage medium includes a trust database that stores multiple trust binaries, each trust binary corresponding to a specific executable program. Each trust binary includes (i) a trust binary name generated by applying a hash function to each header of each executable program, and (ii) a function digest for each executable function identified within each executable program, each function digest generated based on its starting address and one or more static components of each executable function. The multiple trust binaries are indexed in the trust database using their respective trust binary names.

[0011] According to several implementations, the method is performed on a computing device having memory and one or more processors. The method includes (i) accessing a trust store for a computing device, including obtaining a blockchain for the trust store; (ii) identifying a first change to the trust store; (iii) in response to identifying the first change, generating a first block containing a first encrypted digest of the first change and inserting the first block into the blockchain; (iv) identifying a second change to the trust store; and (v) in response to identifying the second change, generating a second block containing a second encrypted digest of the second change and the first encrypted digest and inserting the second block into the blockchain.

[0012] In some implementations, a computing device includes one or more processors, memory, a display, and one or more programs stored in memory. The programs are configured for execution by one or more processors. One or more programs include instructions for performing one of the methods described herein.

[0013] In some implementations, a non-temporary computer-readable storage medium stores one or more programs configured for execution by a computing device having one or more processors, memory, and a display. The one or more programs include instructions for performing any of the methods described herein.

[0014] Therefore, methods and systems for creating and using trusted binaries and blockchains for cybersecurity are disclosed. Such methods and systems may complement or replace conventional methods and systems of cybersecurity.

[0015] To better understand the aforementioned systems, methods, and graphical user interfaces, as well as additional systems, methods, and graphical user interfaces providing data visualization and analysis, refer to the following description of embodiments, where similar reference numbers refer to corresponding parts throughout the drawings. [Brief explanation of the drawing]

[0016] [Figure 1] Several example network architectures based on different implementations are shown. [Figure 2A] Several example executable files representing different implementations are shown. [Figure 2B] Several example executable files representing different implementations are shown. [Figure 3A] This is a block diagram of an exemplary computing device in several implementation forms. [Figure 3B] Here are some example block diagrams of trust stores in various implementation forms. [Figure 3C] This is an illustrative block diagram of a blockchain in several implementation forms. [Figure 4A] This document presents exemplary trusted binary use cases across several implementation configurations. [Figure 4B] This document presents exemplary trusted binary use cases across several implementation configurations. [Figure 5] Several example network architectures based on different implementations are shown. [Figure 6A] This document provides flowcharts illustrating the process for creating a trusted binary using several implementation methods. [Figure 6B] This document provides flowcharts illustrating the process for creating a trusted binary using several implementation methods. [Figure 7A] This document provides flowcharts illustrating the process of using trusted binaries in several implementation forms. [Figure 7B]Provide a flowchart of an exemplary process for using trusted binaries according to some implementations. [Figure 7C] Provide a flowchart of an exemplary process for using trusted binaries according to some implementations. [Figure 7D] Provide a flowchart of an exemplary process for using trusted binaries according to some implementations. [Figure 8A] Provide a flowchart of an exemplary process for using blockchain validity verification according to some implementations. [Figure 8B] Provide a flowchart of an exemplary process for using blockchain validity verification according to some implementations.

[0017] Next, refer to the embodiments, examples of which are illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without these specific details.

Modes for Carrying Out the Invention

[0018] The zero-trust (ZT) system described herein allows known good operating system and application processes to run in memory, preventing anything else from running. According to some implementations, the zero-trust system includes a trust agent installed on a computing device (sometimes called an endpoint). The trust agent monitors and intercepts memory operations. The trust agent validates applications, processes, and functions before allowing them to run. Invalid applications, processes, and functions are blocked or monitored by the trust agent (e.g., depending on the security policy for the computing device). In some implementations, the ZT system utilizes a blockchain identity verification scheme to validate its memory of known good binaries and functions. The ZT system can complement or replace traditional endpoint detection and response (EDR) solutions that deal with known inappropriate operating system and application processes.

[0019] Figure 1 shows a network architecture 100 in several implementation forms. The network architecture 100 includes an information technology (IT) portion 102 and an operational technology (OT) portion 110, which are communicably coupled via a gateway device 108. The IT portion 102 includes user devices 104 (104-1, 104-2, and 104-3) and a hub device 106. In some implementation forms, each user device 104 includes a trust agent. In some implementation forms, the hub device 106 includes a trust store or trust center. In some implementation forms, the hub device 106 includes management software for managing the trust binaries and / or trust policies of the user devices 104. The OT portion 110 includes an audit terminal 118, user terminals 112, a server 114, and a device 116. In some implementation forms, the audit terminal 118, user terminals 112, server 114, and device 116 each include a trust agent. In some implementations, the audit terminal 118 includes software for managing the trust binaries and / or trust policies of the user terminal 112, the server 114, and the device 116. In some implementations, the gateway device 108 provides a demilitarized zone (DMZ) between the IT section 102 and the OT section 110. In some embodiments, the gateway device 108 includes a trust center or trust store for the IT section 102 and / or the OT section 110. In some implementations, the gateway device 108 provides network access to an application store for the IT section 102 and / or the OT section 110. In some implementations, the network architecture 100 implements the Purdue Enterprise Reference Architecture (PERA) model. With respect to the PERA model, the IT section 102 represents levels 4 and 5, the gateway device 108 represents level 3, and the OT section 110 represents levels 0, 1, and 2.

[0020] Figures 2A and 2B show exemplary executable files in several implementations. Figure 2A shows a program executable (PE) file 200 in several implementations. The PE file 200 includes a header section 202 and a section section 204. The header section 202 includes a disk operating system (DOS) header 206 and a PE header 208. The header section 202 also includes one or more optional headers 210, a data directory 212, and a section table 214. The data directory 212 includes pointers to additional structures (e.g., imports, exports, etc.) in several implementations. The section table 214 defines how the file is loaded into memory in several implementations. The section section 204 includes code 216, imports 218, and data 220. Imports 218 include links between the PE file 200 and operating system (OS) libraries. Data 220 includes information used by code 216 in several implementations. Figure 2B shows several implementations of an executable and linkable format (ELF) file 250. The ELF file 250 includes an ELF header 252, a program header table 254, a section 256, and a section header table 258.

[0021] Figure 3A is a block diagram of computing device 300 in several implementation forms. Various examples of computing device 300 include desktop computers, laptop computers, tablet computers, and other computing devices (e.g., IT devices or OT devices) having a processor capable of running trust agent 324. Computing device 300 typically includes one or more processing units / cores (CPUs) 302 for executing modules, programs, and / or instructions stored in memory 314 and thereby performing processing operations, one or more network or other communication interfaces 304, memory 314, and one or more communication buses 312 for interconnecting these components. The communication buses 312 may include circuits for interconnecting and controlling communication between system components.

[0022] The computing device 300 optionally includes a user interface 306 which includes a display device 308 and one or more input devices or mechanisms 310. In some implementations, the input device / mechanism includes a keyboard. In some implementations, the input device / mechanism includes a “soft” keyboard which is displayed on the display device 308 as needed, allowing the user to “press keys” that appear on the display 308. In some implementations, the display 308 and the input device / mechanism 310 are touchscreen displays (also referred to as touch-sensitive displays).

[0023] In some implementations, memory 314 includes high-speed random-access memory such as DRAM, SRAM, DDR RAM, or other random-access solid-state memory devices. In some implementations, memory 314 includes non-volatile memory such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state memory devices. In some implementations, memory 314 includes one or more storage devices located away from the CPU 302. Memory 314, or the non-volatile memory device(s) within memory 314, comprises a non-temporary computer-readable storage medium. In some implementations, memory 314, or the computer-readable storage medium of memory 314, stores the following programs, modules, and data structures, or subsets thereof: ●Operating system 316, which handles various basic system services and includes procedures for performing hardware-dependent tasks. ● A communication module 318 used to connect the computing device 300 to other computers and devices via one or more communication network interfaces 304 (wired or wireless) and one or more communication networks such as the Internet, other wide area networks, local area networks, and metropolitan area networks. ● An application 322 (for example, running on Ring-3) that performs special tasks or sets of tasks for the user (e.g., a word processor, media player, web browser, and communication platform), ● A trust agent 324 protects the computing device 300 by validating the code to be executed and by monitoring system-level operations such as file I / O, registry I / O, thread start / stop, and image load / unload. The trust agent 324 includes one or more of the following: ○Kernel agent 326 (e.g., a kernel-level device driver running in ring-0) monitors applications in memory and verifies application binaries and function digests. ○ A driver agent 327 (e.g., a kernel thread) that monitors active device drivers and applies countermeasures. In some implementations, the driver agent 327 verifies the driver and driver functions using trusted binaries for the driver and driver functions. ○A communication service 328 (e.g., a user-mode privileged process) handles internal communication between trust agents (e.g., between kernel agent 326, binary monitor 330, and dashboard module 332), as well as communication between trust agent 324 and trust store 338 and / or trust center. In some implementations, the communication service 328 sends alerts and forensic data to the trust center and receives updates from the trust center. In some implementations, the communication service 328 periodically checks for (e.g., requests) policy and / or software updates (e.g., every 30 seconds, every 30 minutes, or daily). A binary monitor 330 provides static (e.g., non-runtime) file validity authentication, including validating newly installed and modified / updated applications. In some implementations, the binary monitor 330 generates a (provisional) trusted binary and requests a binary validity authentication check from a trust center. ○ Dashboard module 332 provides a user interface for displaying alerts and allows viewing / editing policy and / or trust binary information, and ○ An installer 334 that identifies executable files, installs trust agent components, and requests trust binaries from the trust center(s). In some implementations, the installer 334 is only obtainable from the trust center. In some implementations, the installer 334 can be downloaded from the trust center via a web browser. In some implementations, the installer 334 customizes the installation of trust agent components (for example, based on device type, operating system, and administrator settings), and ● One or more databases 336 used by application 322 and / or trust agent 324. One or more databases 336, including trust store 338, which will be described in more detail below with reference to Figure 3B.

[0024] Each of the sets of executable modules, applications, or procedures identified above may be stored in one or more of the aforementioned memory devices and correspond to a set of instructions for executing the functions described above. The modules or programs (i.e., sets of instructions) identified above do not need to be implemented as separate software programs, procedures, or modules; therefore, various subsets of these modules may be combined in various implementations or rearranged in different ways. In some implementations, memory 314 stores a subset of the modules and data structures identified above (for example, trust agent 324 does not include dashboard module 332). Furthermore, memory 314 may store additional modules or data structures not described above (for example, trust agent 324 further includes policy modules).

[0025] Figure 3A shows a computing device 300, but it is intended not as a schematic diagram of the structure of the implementation described herein, but rather as a functional description of the various features that may exist. In practice, as will be recognized by those skilled in the art, items shown separately may be combined, and some items may be separated.

[0026] Figure 3B is a block diagram of the trust store 338 in several implementations. In some implementations, the trust store 338 is a relational database (e.g., a Structured Query Language (SQL) database). The trust store 338 includes multiple trust binaries 340, including trust binaries 340-1, 340-2, and 340-n. In the example in Figure 3B, each trust binary includes its respective trust binary name and its respective multiple function digests. For example, trust binary 340-1 includes trust binary name 341 and function digests 343-1 through 343-m. In some implementations, each trust binary corresponds to an executable file (e.g., application 322) on the computing device 300. For example, trust binary 340-1 corresponds to a first application having "m" functions, and therefore trust binary 340-1 has "m" function digests. In some implementations, at least one trust binary 340 corresponds to a device driver. For example, trust binary 340-2 corresponds to a first device driver having "p" driver functions, and therefore trust binary 340-2 has "p" function digests. Trust store 338 further includes blocklist 342, blockchain information 344, policy information 346, and one or more forensic logs 348. In some implementations, blocklist 342 includes a list of blocked (corrupted, malicious) files and / or applications. Blockchain information 344 includes a genesis block 345 and multiple transaction blocks 347 (e.g., transaction blocks 347-1, 347-2, and 347-p). In some implementations, blockchain information 344 includes a separate transaction block 347 for each change to trust store 338 (e.g., policy update, trust binary addition, etc.). Further details of blockchain information 344 are described below with reference to Figure 3C.

[0027] In some implementations, policy information 346 includes information about which features of the trust agent 324 are active, such as policies on which measures to apply (and how to apply), which notifications to present (and how to present), and which corrective actions to apply to untrusted binaries. In some implementations, policy information 346 includes client certificates and encryption keys for the trust store 338. In some implementations, programs without a corresponding trust binary are considered untrusted. In some implementations, policy information 346 includes policies for responding to untrusted applications, scripts, programs, and functions. In some implementations, policies include blocking, notifying, or ignoring each instance of untrusted behavior. In some implementations, policy information 346 includes specific settings (e.g., exceptions) for special programs or applications (e.g., identified by program name or headers).

[0028] In some implementations, the forensic log 348 contains information collected in response to threats detected by the trust agent 324, such as the execution of untrusted executable files and / or functions. In some implementations, the information stored in the forensic log 348 is based on the active security policy for the trust agent 324. In some implementations, the forensic log 348 contains information about one or more of the following: the contents of a read buffer, injected memory, untrusted functions, untrusted scripts, untrusted shellcode, modified code, etc. In some implementations, the forensic information about a detected untrusted execution depends on the type of execution. For example, forensic information about an instance of unknown read buffering may include a capture of the contents of the read buffer. As another example, forensic information about an instance of reflective injection may capture the injection information. In some implementations, the forensic log 348 contains information about the computing device (e.g., information about the operating system, version, patch level, hardware, and memory).

[0029] Figure 3C is a block diagram of blockchain 350 in several implementation forms. In some implementation forms, blockchain information 344 includes blockchain 350. Blockchain 350 includes a genesis block 345, a transaction block 347-1, and a transaction block 347-2. The genesis block 345 includes a previous block digest 352 (e.g., an empty or blank digest), a trust binary digest 353, a creation timestamp 354, a block type 355, a block digest 356, a signing certificate 357, and a digital signature 358. In some implementation forms, the trust binary digest 353 includes a digest for each trust binary 340 in the trust store 338. In some implementation forms, the trust binary digest 353 is a secure hash algorithm (SHA) digest (e.g., a SHA-256 digest). In some implementations, the block type 355 of the genesis block 345 is a trusted binary block type (for example, because the genesis block contains a trusted binary digest 353). In some implementations, the block digest 356 is an SHA digest. In some implementations, the block digest 356 is generated by applying the SHA hash function multiple times (for example, applying the SHA-256 hash function twice). In some implementations, the signing certificate 357 contains information about the block creator of the genesis block 345 (for example, a trusted center certificate). In some implementations, the digital signature 358 corresponds to the cryptographic key of the trust store.

[0030] In some implementations, transaction block 347-1 represents the first modification to trust store 338. Transaction block 347-1 includes the previous block digest 360 (corresponding to the block digest 356 of genesis block 345), the transaction digest 364 for the first modification, the creation timestamp 366, the block type 368, the block digest 370, the signing certificate 372, and the digital signature 374. In some implementations, the first modification is a trust binary modification (e.g., the addition of a new trust binary), and the block type 368 is the trust binary block type. In some implementations, the first modification is a policy update, and the block type 368 is the policy block type. In some implementations, the signing certificate 372 is the client certificate for computing device 300. In some implementations, the digital signature 374 corresponds to the encryption key of the client device.

[0031] In some implementations, transaction block 347-2 represents a second change to the trust store 338. Transaction block 347-2 includes the previous block digest 376 (corresponding to the digest 370 of transaction block 347-1), a transaction digest 378 for the second change, a creation timestamp 380, a block type 382, ​​a block digest 384, a signing certificate 386, and a digital signature 388.

[0032] In some implementations, trust agent 324 utilizes blockchain information 344 to validate trust store 338. In some implementations, blockchain 350 is validated using proof-of-identity operations. Transaction block 347-1 contains a previous block digest 360 that should match the block digest 356 of genesis block 345, and transaction block 347-2 contains a previous block digest 376 that should match the block digest 370 of transaction block 347-1. In this way, the validity of blockchain 350 can be checked by comparing the block digest of each block with the previous block digest of the next block in the chain.

[0033] In some situations, blockchain 350 is advantageous over traditional cybersecurity systems because it enables validity verification of trust store 338 without requiring a network connection (e.g., operating on an air-gapped system). In some situations and implementations, using blockchain 350 for validity verification of trust store allows the validity verification procedure to be distributed and secure. In some implementations, trust store 338 and blockchain 350 are verified at deployment (e.g., when installed on a new computing system) and at each subsequent reload of trust agent 324.

[0034] Figures 4A and 4B illustrate exemplary trusted binary use cases in several implementation forms. Figure 4A shows an exemplary communication sequence between a trusted agent 324, a trusted store 338, and a trusted center 402. In the example of Figure 4A, the trusted agent 324 monitors device memory (e.g., memory 314 of computing device 300) (404). The trusted agent 324 detects a binary file launched in memory (e.g., a binary file corresponding to application 322) (406). In response, the trusted agent 324 requests the trusted binary for the binary file from the trusted store 338 (408). The trusted store 338 is searched for the corresponding trusted binary (e.g., searched by components of the trusted agent 324) (410). In the example of Figure 4A, the corresponding trusted binary is not found in the trusted store 338. The trusted agent 324 is notified of the lack of the corresponding trusted binary (412). Therefore, trust agent 324 requests the corresponding trust binary from trust center 402 (414). Trust center 402 searches for the corresponding trust binary (416). In the example in Figure 4A, the corresponding trust binary is not found in trust center 402. Trust center 402 sends a notification to trust agent 324 about the lack of the corresponding trust binary (418). In response, trust agent 324 applies countermeasures (e.g., according to an active policy) (414). In the example in Figure 4A, trust agent 324 generates a provisional trust binary (sometimes called a local trust binary) (420). The provisional trust binary is stored in trust store 338 (422). A block corresponding to the provisional trust binary is created and added to the blockchain (e.g., blockchain 350) (424). Trust agent 324 sends the binary file to trust center 402 for verification (426). Trust Center 402 analyzes the binary file (428). In the example in Figure 4A, the binary file is approved by Trust Center 402 (430) and notified to Trust Agent 324 (431).The provisional trust binary is stored in trust store 338 as a non-provisional (standard) trust binary (432). A block is added to the blockchain to convert the provisional trust binary to a non-provisional trust binary (434).

[0035] Figure 4B shows another exemplary communication sequence between trust agent 324, trust store 338, and trust center 402. In the example of Figure 4B, trust center 402 generates a trust policy (450). In some implementations, the trust policy instructs how the trust agent should respond to untrusted binaries and functions. In some implementations, the trust policy instructs which measures should be active on the computing device. The trust policy is sent to trust store 338 (e.g., via communication service 328) (452). The trust policy is stored in trust store 338 (454). Trust agent 324 loads the trust policy (e.g., as part of a startup procedure) (456). Trust agent 324 monitors device memory (e.g., memory 314 of computing device 300) (458). Trust agent 324 detects function calls (e.g., function calls executed by application 322) (460). In response to a function call, the trust agent compares the function to a function digest in the trust binary (e.g., the corresponding function digest in the trust binary for the application) (462). In the example in Figure 4B, the comparison indicates that the function is untrustworthy (e.g., modified). In accordance with the trust policy, the trust agent 324 blocks the function from executing (464) and generates a forensic log containing information related to the function and the function call (466). The trust agent 324 sends the forensic log to the trust center 402 for analysis (468). The trust center 402 analyzes the forensic log (470) and generates a threat report (72). The trust center 402 sends a notification to the trust agent 324 (e.g., containing at least part of the threat report) (474). The trust agent 324 displays the notification to the device user (476) (e.g., using the dashboard module 332 to display the notification).

[0036] Figure 5 shows a network architecture 500 in several implementation forms. The network architecture 500 includes device group 502-1 and device group 502-2. In the example in Figure 5, device group 502-1 includes three devices (e.g., two user terminals 112 and one audit terminal 118), and device group 502-2 includes two devices (e.g., two user devices 104). Group 502-1 has an associated security policy 504-1, and group 502-2 has an associated security policy 504-2. Therefore, in this example, the same security policy (e.g., security policy 504-1) applies to each device in device group 502-1. The network architecture 500 further includes a trust center 510, trust points 506-1 and 506-2, and trust stores 508-1 to 508-5. In some implementation forms, trust center 510 is an instance of trust center 402. Trust point 506 represents a logical grouping of trust stores in several implementations. In some implementations, trust point 506 contains a search list (index) of connected trust stores 508. For example, trust point 506-1 contains the search lists of trust stores 508-1 and 508-2. As shown in Figure 5, devices within each device group utilize the shared trust store 508. Specifically, device group 502-1 and device group 502-2 are each connected to trust store 508 via trust point 506. In some implementations, trust store 508 is stored separately from device group 502 (e.g., on a separate network device, network server, and / or on a separate network). In some implementations, each trust store 508 corresponds to a specific operating system, device type, or entity (e.g., containing only trust binaries associated with that operating system, device type, or entity). In some implementations, the trust store 508 contains metadata about the trust binaries stored there (e.g., temporary metadata such as vendor, version, and date).

[0037] In some implementations, each security policy 504 represents a policy group. In some implementations, policy settings not specified in a policy group do not apply to device group 502. In some implementations, each security policy 504 includes policy settings for each countermeasure (e.g., enforce, notify, or turn off). In some implementations, countermeasures not included in the policy settings are set to their default values ​​(e.g., turned off). In some implementations, security policy 504 includes one or more named exceptions (e.g., different settings for a particular application). In some implementations, security policy 504 includes dashboard settings to enable or disable the use of dashboard module 332 on the device. In some implementations, security policy 504 includes one or more blacklists (e.g., specifying applications to be prevented from running). In some implementations, security policy 504 includes restrictions on one or more applications (e.g., to prevent one or more applications from running on the device or device group 502). In some implementations, security policy 504 includes a list of one or more blacklisted IP addresses and / or a list of one or more restricted IP addresses. In some implementations, security policy 504 includes application update settings regarding whether to allow updating an application to a new version and whether to generate a local trusted binary for the updated application. In some implementations, security policy 504 includes application installation settings regarding whether to allow installing a new application and whether to generate a local trusted binary for the new application. In some implementations, security policy 504 includes device configuration settings (e.g., based on device type and / or operating system).

[0038] In some implementations, Trust Center 510 includes one or more of the following: policy manager, alert manager, trust database, trust manager, and dashboard manager. In some implementations, Trust Center 510 communicates with one or more other trust centers. In some implementations, Trust Center 510 shares information from its trust store with other trust centers (e.g., to accelerate deployment and provide global compliance). In some implementations, Trust Center includes a web-based dashboard. In some implementations, the dashboard is a controlled access dashboard (e.g., using multi-factor authentication). In some implementations, the dashboard provides an interface for managing one or more of the following: device groups, security policies, trust binaries, trust stores, and trust points. In some implementations, the dashboard provides an interface for inventorying endpoints (e.g., computing devices with trust agents). In some implementations, the dashboard provides an interface for viewing and managing one or more of the following: notifications (alerts), whitelisting, risk assessment, authentication management, and communication configuration (e.g., peer-to-peer networking). In some implementations, the policy manager configures policy groups (for example, to be attached to the corresponding device group 502) and individual policy settings.

[0039] In some implementations, the Trust Center 510 provides policies and updates to endpoint devices (e.g., devices in device group 502). In some implementations, the Trust Center 510 records alerts and forensic data received from device group 502. In some implementations, the Trust Center 510 provides validity authentication for applications and programs and creates corresponding trust binaries (e.g., to be distributed to trust store 508). In some implementations, the Trust Center 510 provides organizational management of trust binaries (e.g., determining which trust store 508 receives and stores which trust binaries). In some implementations, the Trust Center 510 operates on a network gateway or server system. In some implementations, the Trust Center 510 operates on a virtual machine on a server system or gateway device.

[0040] In some implementations, Trust Center 510 validates a trusted binary by determining one or more of the following: (i) whether the application was obtained directly from the manufacturer; (ii) whether the application is signed, whether the signature is valid, whether the signing certificate is valid, and whether the chain of trust is valid; (iii) whether the application digest has been cleared by a virus scanner and / or blacklist checker; (iv) whether the application (or an update to the application) was obtained from a trusted download site; (v) whether the site administrator has authorized the use of the application; and (vi) whether the user has authorized the use of the application locally on the computing system.

[0041] In some implementations, the Trust Center 510 provides administrator functions for one or more trust stores and / or trust points. In some implementations, the administrator functions include functions for creating, duplicating, or deleting trust stores or trust points. In some implementations, the administrator functions include functions for moving trust stores, trust points, and / or trust binaries between devices and the system.

[0042] Figures 6A and 6B provide flowcharts of Method 600 for creating a trusted binary in several implementation forms. Method 600 is executed on a computing system (e.g., computing device 300) having one or more processors and memory. In some implementation forms, the memory stores one or more programs configured for execution by one or more processors.

[0043] The computing system obtains executable code (for example, for a program) (602). In some implementations, a trust agent running on the computing system obtains executable code. In some implementations, executable code is obtained during the program installation process. In some implementations, executable code is obtained during the program download process. In some implementations, executable code is obtained as part of scanning static (e.g., non-executable) applications on the computing system (e.g., executed by a binary monitor 330). In some implementations, the computing system obtains executable code for a device driver.

[0044] In some implementations, executable code is either a program executable file (e.g., as shown in Figure 2A) or an executable or linkable format file (e.g., as shown in Figure 2B) (604). In some implementations, executable code is a file in a specific programming language (e.g., a .NET file, a Java file, a Python file, or a Visual Basic file).

[0045] A computing system identifies multiple executable functions from executable code (606). For example, to identify all functions in a PE file, code 216 is scanned. As another example, to identify all functions in an ELF file, section 256 is scanned. In some implementations, identifying multiple executable functions includes identifying functions in a shared library (e.g., from import 218).

[0046] A computing system generates a function digest for each of several executable functions based on one or more static components of the executable function (608). In some implementations, each function digest is generated by applying a hash function to the executable function (e.g., a secure hash function such as SHA-256).

[0047] In some implementations, one or more static components of an executable function include one or more instructions and one or more registers (614). In some implementations, one or more static components of an executable function exclude one or more dynamic address fields (616). In some implementations, one or more static components include all immutable (e.g., non-dynamic) components of the function.

[0048] In some implementations, the function digest for each executable function is generated using a secure hash algorithm (618). In some implementations, the function digest for each executable function is generated using a cryptographic hash function. In some implementations, the function digest for each executable function is generated by applying two or more cryptographic hash functions to the executable function. In some implementations, each function digest includes an index of the length of the corresponding function. In some implementations, each function digest includes an index of the start or end address of the corresponding function.

[0049] The computing system constructs a trust binary containing a digest of each of several executable functions (620). In some implementations, the trust binary contains a digest of all executable code in the corresponding file (e.g., a PE file or an ELF file). In some implementations, the trust binary contains a digest of the entropy contained in the corresponding file.

[0050] In some implementations, to construct a trusted binary, the computing system hashs one or more of the following: the program's data directory (e.g., data directory 212), the program's section table (e.g., section table 214), and the program's program table (e.g., program header table 254) (622). In some implementations, constructing a trusted binary involves hashing each section of the program's executable code.

[0051] A computing system generates a trusted binary name by applying a hash function to the header of the executable code (624). In some implementations, the trusted binary name is a digest of the entropy contained in the header of the executable code.

[0052] In some implementations, the executable code is a program executable (PE) file, and generating a trusted binary name involves applying a hash function to the DOS header and / or PE header (or at least one of them) of the PE file (625).

[0053] In some implementations, the executable code is an executable or linkable format (ELF) file, and generating a trusted binary name involves applying a hash function to the ELF header of the ELF file (626).

[0054] In some implementations, the hash function is a secure hash algorithm such as the SHA-256 hash function (628). In some implementations, the hash function is a cryptographic hash function. In some implementations, the same hash function is used to generate a trusted binary name and an executable function digest.

[0055] The computing system uses the trust binary name to index the trust binary in the trust database (e.g., the trust store) (630). For example, trust binary 340 is stored in trust store 338 (indexed by trust binary name 341).

[0056] In some implementations, the trust database is stored in the memory of the computing system (for example, a trust store 338 stored in the memory 314 of computing device 300) (632). In some implementations, the trust database is stored away from the computing device. For example, Figure 5 shows a trust store 508 that is away from the devices in device group 502.

[0057] In some implementations, the computing system sends the trust binary to a server system located away from the computing system (634). For example, the trust binary is generated on a device in device group 502-1, sent to trust point 506-1, indexed, and stored (for example, in one of trust stores 508-1 or 508-2).

[0058] Figures 7A to 7D provide flowcharts of Method 700 for using trusted binaries in several implementation forms. Method 700 is executed on a computing system (e.g., computing device 300) having one or more processors and memory. In some implementation forms, the memory stores one or more programs configured for execution by one or more processors.

[0059] The computing system runs a trust agent (702). For example, computing device 300 runs trust agent 324. In some implementations, the trust agent runs as a kernel-level device driver. In some implementations, the trust agent runs as a ring-0 process on the computing system.

[0060] In some implementations, the computing system (704) verifies the authenticity of the trust agent by (i) loading the trust agent's executable code into memory, (ii) obtaining a trust binary for the trust agent, and (iii) comparing the loaded executable code with the obtained trust binary. In some implementations, as part of the trust agent startup process, the trust agent validates its own trust binary (e.g., to ensure that the trust agent code has not been tampered with). In some implementations, the trust agent uses operating system permissions to protect its associated files and data (e.g., trust store and trust agent component files) from tampering. In some implementations, the trust agent includes (executes) a kernel thread to monitor the files and data associated with the trust agent. In some implementations, the kernel thread continuously verifies that the files and data associated with the trust agent have not been invalidated or tampered with. In some embodiments, when the kernel thread detects write access to the monitored files and data, the process that initiated the write access is stopped (invalidated) by the kernel thread. In some implementations, forensic data is obtained according to the detected write access, and the trust agent uses the forensic data to generate notifications (e.g., to the users of the computing system and / or the trust center).

[0061] In some implementations, the trust agent runs when the computing device starts up (706). In some implementations, the trust agent is configured to run as part of the computing system's boot sequence (e.g., power-on).

[0062] In some implementations, the computing system establishes multiple kernel hooks for input / output (I / O) checking (708). For example, multiple kernel hooks are used to check file I / O operations, registry I / O operations, thread start and stop operations, and image load and unload operations.

[0063] In some implementations, the trust agent includes a kernel-level driver (710). For example, trust agent 324 includes kernel agent 326 to verify the application binary and function digest. In some implementations, kernel agent 326 ensures that the application running in memory is protected from attacks and compromises by validating the function calls and memory buffers associated with the application.

[0064] In some implementations, the trust agent includes a driver agent (e.g., driver agent 327) that monitors device drivers. In some implementations, the driver agent verifies device drivers by comparing a digest of the device driver with a trusted binary for the device driver. In some implementations, if a trusted binary for the device driver is not found, or if the digest of the device driver does not match the trusted binary, the device driver is not allowed to load or is taken offline (disabled). In some implementations, the driver agent monitors functions and kernel threads that run within the device driver. In some implementations, the driver agent verifies driver functions by comparing a digest of the function with a function digest in the trusted binary for the device driver. In some implementations, if a kernel thread is detected attempting to execute a function within a device driver and the function does not have a matching function digest in the trusted binary, the driver agent stops the kernel thread and / or disables the device driver. In some implementations, the driver agent obtains (e.g., generates or captures) forensic data by detecting unverified device drivers or unverified functions running within a device driver. In some implementations, the driver agent generates a notification (e.g., to the computing system's user and / or trust center) upon detecting an unverified device driver or an unverified function running on a device driver. In some implementations, the notification includes forensic data. In some implementations, the driver agent causes the operating system to power off (e.g., restart or reboot) upon detecting an unverified device driver or an unverified function running on a device driver.In some implementations, the driver agent recommends that the user of the computing system shut down the operating system upon detecting an unverified device driver or an unverified function being executed by a device driver.

[0065] In some implementations, the trust agent includes a communication service, a file monitor, an installer, and a dashboard manager (712). For example, trust agent 324 includes a communication service 328, a binary monitor 330, a dashboard module 332, and an installer 334.

[0066] The computing system detects future execution of a program (e.g., application 322) on the computing system via a trust agent (714). For example, the trust agent detects when a binary file is being launched in memory. In some implementations, in addition to detecting binary files being launched in memory, the trust agent also detects programs and / or binary files being downloaded.

[0067] In some implementations, the computing system identifies memory requests corresponding to a program (716). For example, trust agent 324 identifies file I / O operations or registry I / O operations. In some implementations, trust agent 324 identifies application threads attempting to start or detects scripts, JavaScript, or shellcode in a memory buffer.

[0068] The computing system, in response to detection, retrieves a trusted binary for the program from a trusted store in memory (720). For example, trusted agent 324 retrieves trusted binary 340 from trusted store 338.

[0069] The computing system verifies the authenticity of a program by comparing the program's executable code with a trusted binary for the program obtained (722). For example, a trusted agent 324 generates a digest of the executable code and compares the generated digest with a trusted binary.

[0070] The computing system permits the execution of a program according to its verified authenticity (724). For example, a trusted agent 324 intercepts a binary file being loaded into memory and prevents the binary file from being loaded (e.g., by suspending the process) until the authenticity of the binary file is verified (based on trusted binaries).

[0071] The computing system identifies future executions of executable functions of a program by monitoring the program's execution (726). For example, a trust agent 324 detects function calls associated with a program (e.g., functions in the program or functions in a shared library).

[0072] In some implementations, the computing system monitors the system-level operation of a program (728). For example, trust agent 324 monitors file I / O operations, registry I / O operations, thread start and stop operations, and image load and unload operations.

[0073] In some implementations, the computing system intercepts library function calls made by the program (730). For example, kernel agent 326 monitors the program (application) throughout its lifetime in memory, including loading, execution, and termination. In some implementations, kernel agent 326 verifies the program against a trusted binary and verifies functions in any loaded shared libraries. In some implementations, trusted agent 324 retrieves a trusted binary for the shared library and compares a digest of the library functions with a function digest in the trusted binary.

[0074] In response to identifying future executions of an executable function, the computing system obtains a function digest corresponding to the executable function from the trusted binary (732). For example, trusted agent 324 obtains function digest 343-1 corresponding to the executable function.

[0075] The computing system verifies the authenticity of an executable function by comparing its executable code with a function digest obtained from that function (734). For example, trust agent 324 generates a digest by applying a hash to the static portion of the executable function and then compares the digest with a function digest from a trust binary.

[0076] The computing system permits the execution of an executable function according to the verified authenticity of the executable function (736). For example, trust agent 324 permits the execution of a function according to the hash of the function that matches the function digest in the trust binary.

[0077] In some implementations, the computing system detects the upcoming execution of a second program via a trust agent (738). For example, trust agent 324 detects the binary file for the second application 522 that is loaded into memory.

[0078] In some implementations, the computing system determines that the trust store does not contain a corresponding second trust binary for a second program (740). For example, the second program is one for which no trust binary has been created, or the second program has been modified so that the hash of the header portion of the second program does not match the name of a previously generated trust binary for the second program.

[0079] In some implementations, the computing system, in response to detection, retrieves a second trust binary for the second program from the trust store (744). For example, trust binary 340-1 corresponds to the first program, and trust binary 340-2 corresponds to the second program.

[0080] In some implementations, the computing system identifies one or more changes to the executable code of a second program based on comparison with a second trusted binary (746). For example, the trusted binary name matches the hash of the header portion of the second program, but the hash of the code portion (e.g., code 216) does not match the digest of the trusted binary.

[0081] In some implementations, the computing system initiates a corrective action (742) (for example, according to a decision (740) or identification (746)). In some implementations, the corrective action includes collecting forensic data for analysis by a trust center (e.g., trust center 402). In some implementations, the corrective action includes generating a notification (e.g., presented to a user of the computing system and / or sent to a trust center) about an untrustworthy second program.

[0082] In some implementations, the corrective action includes one or more of the following: preventing the execution of the second program; storing information about the second program in a forensic log (e.g., forensic log 348); and generating a provisional trust binary for the second program (748). In some implementations, preventing the execution of the second program includes intercepting the binary file of the second program that is loaded into memory.

[0083] In some implementations, the corrective action includes generating a provisional trust binary, and the computing system sends the executable file of the second program to the trust center for validity verification (750). In some implementations, following the generation of the provisional trust binary, the second program is allowed to run on the computing system for a limited period (e.g., one day, two days, or one week). In some implementations, the second program is allowed to run on the computing system until a response regarding the executable file of the second program is received from the trust center. In some implementations, forensic data is sent to the trust center along with the executable file of the second program, and the forensic data includes information about the state of the computing system and the conditions under which the second program was executed. In some implementations, the trust center analyzes the executable file of the second program and, optionally, any received forensic data to determine whether to trust the second program. In some implementations, validating the executable file of a second program involves one or more of the following: checking the digital signature, checking the signature certificate path, checking the executable file against one or more blacklists (e.g., local and external), and checking the executable file against one or more whitelists.

[0084] In some implementations, the corrective action includes applying one or more countermeasures (752). In some implementations, the countermeasures include detecting and preventing one or more of the following: heap spraying, reflective injection, unknown read buffering, blocked address communication, malfunctions, malicious scripts, privilege escalation, function tampering, unknown shellcode, and trust tampering. In some implementations, each countermeasure is individually enabled via policy settings (for example, within policy information 346). In some implementations, policy information 346 includes enforce parameters, notification parameters, or off parameters for each countermeasure.

[0085] In some implementations, detecting and preventing heap spraying involves detecting that dynamic memory has been allocated for executable code insertion. In some implementations, trust agent 324 blocks the executable code insertion and / or sends information about the executable code insertion to the trust center for analysis. In some implementations, a copy of the sprayed memory is stored in the forensic log of events.

[0086] In some implementations, detecting and preventing reflective injection involves detecting that another process has injected an executable object into a process. In some implementations, trust agent 324 blocks the injection of the executable object and / or sends information about the executable object to the trust center for analysis. In some implementations, a copy of the injected memory is stored in the forensic log of events.

[0087] In some implementations, detecting and preventing unknown read buffering includes detecting that an executable file is being loaded into memory and that the executable file does not have a corresponding trusted binary. In some implementations, trust agent 324 prevents the executable file from being loaded into memory and / or sends information about the executable file to the trust center for analysis. In some implementations, a copy of the buffer contents is stored in the forensic log of events.

[0088] In some implementations, detecting and preventing blocked address communication involves detecting when a process attempts to connect to a restricted or blocked Internet Protocol (IP) address. In some implementations, trust agent 324 prevents communication with restricted or blocked IP addresses.

[0089] In some implementations, detecting and preventing a malicious function involves detecting that a thread is about to start and that the associated function does not have a corresponding trust binary (or a corresponding function digest within the trust binary). In some implementations, trust agent 324 prevents the thread from starting or terminates the thread in response to the determination that a corresponding trust binary does not exist, and / or sends information about the thread and the associated function to the trust center for analysis. In some implementations, a copy of the malicious function is stored in the forensic log of events.

[0090] In some implementations, detecting and preventing malicious scripts involves detecting scripts in process buffers (e.g., batch files (BAT), Javascripts, or PowerShell files) (e.g., during file operations) and determining that the script contains one or more suspicious behaviors, such as encrypted or compressed script sections. In some implementations, Trust Agent 324 prevents the script from being executed and / or sends information about the script to the Trust Center for analysis. In some implementations, a copy of the script is stored in the forensic log of events.

[0091] In some implementations, detecting and preventing privilege escalation involves detecting when a process attempts to increase its privilege level within the computing system (e.g., raising its privilege level to system level). In some implementations, trust agent 324 prevents the process from increasing its privilege level and / or sends information about the privilege escalation to the trust center for analysis.

[0092] In some implementations, detecting and preventing function tampering includes detecting if a function in the program has been modified after it has been loaded into memory. In some implementations, trust agent 324 blocks the execution of the modified function and / or sends information about the modified function to the trust center for analysis. In some implementations, information about the original and modified functions is sent to the trust center for analysis. In some implementations, detecting and preventing unknown shellcode includes detecting shellcode in a memory buffer.

[0093] In some implementations, detecting and preventing unknown shellcode involves detecting that a buffer has been allocated to a process and that its page permissions are set to read / write / execute without the corresponding image or trusted binary. In some implementations, Trust Agent 324 blocks the shellcode from executing and / or sends information about the shellcode to the Trust Center for analysis. In some implementations, the shellcode memory image is stored in the forensic log of events.

[0094] In some implementations, detecting and preventing trust tampering involves detecting when a process attempts to modify one or more files in the trust agent or trust store. In some implementations, the trust agent 324 blocks the process from modifying one or more files and sends information about the trust tampering to the trust center for analysis.

[0095] In some implementations, the corrective action includes sending a query to the trust center for a trust binary for a second program (754). For example, if trust agent 324 requests a trust binary from trust store 338 and is notified that trust store 338 does not contain the requested trust binary, trust agent 324 requests a trust binary from the trust center.

[0096] In some implementations, the corrective action is based on a trust policy obtained for the computing device (756). For example, the corrective action is based on a trust policy (e.g., security policy 504-1) stored in policy information 346.

[0097] In some implementations, the computing system monitors the execution of a program and identifies upcoming executions of a second executable function of the program (758). For example, kernel agent 326 identifies a call to a second executable function.

[0098] In some implementations, the computing system, in response to identifying future executions of the second executable function, decides that the trusted binary does not contain a corresponding second function digest for the second program (760). For example, the second function may have either no corresponding function digest created, or the second function may have been modified since the corresponding function digest was created.

[0099] In some implementations, the computing system initiates corrective actions in accordance with the decision (762). In some implementations, the corrective action includes collecting forensic data for analysis by a trust center (e.g., trust center 402). In some implementations, the corrective action includes generating a notification (e.g., presented to the user of the computing system and / or sent to the trust center) about an untrustworthy second executable function.

[0100] In some implementations, the corrective action includes one or more of the following: preventing the execution of the second executable function, stopping the execution of the program, storing information about the second executable function in a forensic log, and generating a provisional function digest for the second executable function (764). In some implementations, generating a provisional function digest includes generating a provisional trust binary for the program. In some implementations, the executable code of the program is sent to a trust center for validity verification. In some implementations, following the generation of the provisional function digest, the second function may be executed on the computing system for a limited period (e.g., one day, two days, or one week). In some implementations, the second program may be executed on the computing system until a validity verification response is received from the trust center.

[0101] Figures 8A and 8B provide flowcharts of Method 800 for using blockchain validity authentication in several implementation forms. Method 800 is executed on a computing system (e.g., computing device 300) having one or more processors and memory. In some implementation forms, the memory stores one or more programs configured for execution by one or more processors.

[0102] The computing system obtains a blockchain for the trust store (802). In some implementations, the computing system receives a trust store from a trust center, and the trust store contains a blockchain. For example, computing device 300 receives a trust store 338 from a trust center as part of the installation process of trust agent 324. In this example, the trust store 338 contains at least some blockchain information (e.g., a genesis block) when received.

[0103] In some implementations, the computing system obtains the blockchain's genesis block (804). In some implementations, a trust store containing the genesis block (e.g., genesis block 345) is received from the trust center.

[0104] In some implementations, the genesis block includes an encrypted digest of the trusted binary (e.g., trusted binary digest 353), a block type (e.g., block type 355), a signing certificate (e.g., signing certificate 357), a digital signature (e.g., digital signature 358), and an encrypted block digest (e.g., block digest 356) (806). In some implementations, the genesis block has a trusted binary block type. In some implementations, the genesis block has a signing certificate from the trust center. In some implementations, the genesis block further includes a creation timestamp (e.g., creation timestamp 354).

[0105] In some implementations, the blockchain is stored in a table within a trust store, where each row in the table corresponds to a block in the blockchain (808). For example, blockchain information 344 includes a table with a row corresponding to transaction block 347.

[0106] In some implementations, each block in the blockchain contains its own signature certificate and its own digital signature (810). For example, the genesis block contains a signature certificate 357 and a digital signature 358 (e.g., from a trust center), and the transaction block 347-1 contains a signature certificate 372 and a digital signature 374 (e.g., from a computing device 300).

[0107] The computing system identifies the first change to the trust store (812). In some implementations, the trust agent 324 monitors the trust store for changes. In some implementations, the trust agent 324 modifies (e.g., updates) the trust store. In some implementations, the first change to the trust store is one of the following: a policy update, a trust binary update, a blocklist update, and a provisional trust binary update.

[0108] The computing system generates a first block and inserts the first block into the blockchain, the first block containing a first encrypted digest of the first change (e.g., transaction digest 364) and a first block digest (e.g., block digest 370) (814). For example, computing device 300 generates transaction block 347-1 in response to a first transaction, the transaction block 347-1 containing transaction digest 364.

[0109] In some implementations, the first block further includes an encrypted block digest of the genesis block (816). For example, transaction block 347-1 includes a preceding block digest 360 that corresponds to the block digest 356 of the genesis block 345.

[0110] In some implementations, the first block has a block type selected from a group consisting of trust binary type, blocklist type, policy type, and local trust binary type (818). In some implementations, each type of change to the trust store has a corresponding block type. In some implementations, the block type further includes a forensic type corresponding to a forensic change to the trust store (e.g., an update to forensic log 348).

[0111] In some implementations, the first change to the trust store is a change to the trust binary of the trust store, and the first block has a trust binary block type (820). For example, a new trust binary is retrieved (e.g., from a trust center), and in response, transaction block 347-1 is generated with a trust binary block type.

[0112] In some implementations, the first change to the trust store is a change to the trust store's policy, and the first block has a policy block type (822). For example, a new policy is retrieved (e.g., from a trust center or from a user of a computing system), and in response, transaction block 347-1 is generated with a policy block type.

[0113] In some implementations, the first change to the trust store is a change to the trust store's blocklist, and the first block has a blocklist block type (824). For example, when an update to the blocklist is obtained (e.g., from a trust center), transaction block 347-1 is generated in response with a blocklist block type.

[0114] In some implementations, the first change to the trust store is the addition of a local trust binary to the trust store, and the first block has a local trust binary block type (826). For example, a new provisional trust binary is generated by the computing system, and in response, transaction block 347-1 is generated with a local trust binary block type.

[0115] In some implementations, the first block digest is generated using two or more secure hash algorithms (828). For example, the first block digest is generated by applying two or more secure hash algorithms (e.g., SHA-256 hash functions) to the contents of the first block.

[0116] The computing system identifies a second change to the trust store (830). In some implementations, the second change is of a different type than the first change. For example, the first change is a trust binary update and the second change is a policy update. In some implementations, the second change is of the same type as the first change. For example, the first change is a first trust binary update and the second change is a second trust binary update.

[0117] The computing system generates a second block and inserts the second block into the blockchain, the second block containing a second encrypted digest of the second change (e.g., transaction digest 378), a second block digest (e.g., block digest 384), and a first block digest (e.g., previous block digest 376) (832).

[0118] In some implementations, the computing system verifies the integrity of the trust store, including using the blockchain to authenticate the validity of the contents of the trust store (834). For example, the computing system compares a digest of trust binary 340 with a digest of one or more trust binary blocks in blockchain 350 and authenticates the validity of the trust store according to the match. In another embodiment, the computing system compares a digest of policy information 346 with a digest of one or more policy blocks in blockchain 350 and authenticates the validity of the trust store according to the match.

[0119] In some implementations, the computing system validates the blockchain using a proof-of-identity operation that includes comparing the previous block digest in a second block with the first block digest in a first block (836). In some implementations, verifying the integrity of the trust store includes validating the blockchain. In some implementations, the proof-of-identity operation includes, for each transaction block 347, comparing the previous block digest of transaction block 347 with the block digest of the previous block in blockchain 350. For example, comparing the previous block digest 360 in transaction block 347-1 with the block digest 356 of genesis block 345.

[0120] Next, we will describe some example implementations.

[0121] (A1) In one embodiment, several implementations include a method for creating a trusted binary (e.g., method 600). The method is performed on a computing system (e.g., computing device 300) having memory (e.g., memory 314) and one or more processors (e.g., CPU 302(or more)). The method includes (i) obtaining the executable code of a program (e.g., application 322), (ii) identifying a plurality of executable functions from the executable code, (iii) for each of the plurality of executable functions, generating a function digest based on one or more static components of the respective executable function, (iv) constructing a trusted binary for each of the plurality of executable functions, containing the respective digest, (v) generating a trusted binary name by applying a hash function to the header of the executable code, and (vi) indexing the trusted binary in a trusted database (e.g., trusted store 338) using the trusted binary name.

[0122] (A2) The method in A1 for generating a function digest for each function is further based on the respective start address of each executable function. In some implementations, the end address is obtained and used instead of, or in addition to, the start address. In some implementations, the digest is generated using the end address or offset address instead of the start address. In some implementations, the trusted binary name is based on the determined entropy of the executable code header.

[0123] (A3) Executable code is a program executable file or an executable and linkable format (ELF) file, as described in A1 or A2. In some implementations, executable code is a programming language file such as a .NET file, Java file, Python file, or Visual Basic file.

[0124] (A4) The method in A3, wherein the executable code is a program executable (PE) file, and generating a trusted binary name involves applying a hash function to the DOS header (e.g., DOS header 206) and PE header (e.g., PE header 208) of the PE file. In some implementations, the hash function is a cryptographic hash function (e.g., SHA-256 hash function).

[0125] (A5) The executable code is an executable and linkable format (ELF) file, and generating a trusted binary name is the method in A3, which involves applying a hash function to the ELF header of the ELF file (e.g., ELF header 252). In some implementations, the hash function is a cryptographic hash function (e.g., SHA-256 hash function).

[0126] (A6) One or more static components of each executable function include one or more instructions and / or one or more parts representing static data, as described in any of A1 to A5. In some implementations, one or more static components include all static components of the executable function.

[0127] (A7) One or more static components of each executable function, excluding dynamic address fields, as described in any of A1-A6. In some implementations, one or more static components of an executable function include all components of the executable function except for any dynamic address fields.

[0128] (A8) Constructing a trusted binary is the method of any of A1-A7, which includes hashing one or more of the program's data directory, the program's section table, and the program's program table. In some implementations, constructing a trusted binary includes hashing the executable code's code, data, and import sections (e.g., sections 216, 218, and 220).

[0129] (A9) The hash function is a secure hash algorithm (e.g., the SHA-256 hash function), or a method of any of A1-A8 that includes a secure hash algorithm. In some implementations, the same hash function is used to construct the trusted binary and generate the trusted binary name. In some implementations, different hash functions are used to construct the trusted binary and generate the trusted binary name (e.g., using different levels of encryption).

[0130] (A10) The function digest for each executable function of a set of executable functions is generated using a secure hash algorithm, as described in any of A1-A9. In some implementations, generating a function digest for an executable function involves applying a secure hash algorithm to all static components of the executable function.

[0131] (A11) The trust database is stored in the memory of the computing device (e.g., as part of the trust store 338) according to any of the methods in A1 to A10. In some implementations, the trust database is a relational database (e.g., a Structured Query Language (SQL) database). In some implementations, the trust store includes a trust binary (e.g., trust binary 340), a blocklist (e.g., blocklist 342), a blockchain for validity authentication (e.g., blockchain information 344), and one or more security policies (e.g., policy information 346). In some implementations, the trust store operates on a virtual machine (e.g., a virtual machine in the memory of computing device 300).

[0132] (A12) The method of any of A1 to A11, further comprising sending the trust binary to a server system located away from the computing device (e.g., Trust Center 402). In some implementations, the server system adds the trust binary to a whitelist of trust binaries. In some implementations, the server system sends the trust binary to one or more other trust stores.

[0133] (A13) The method of any of A1 to A12, further comprising sending executable code to a server system located away from the computing device. In some implementations, the trusted binary is a provisional trusted binary, and the computing system sends the executable code to the server system for validation of the executable code. In some implementations, validation of the executable code includes one or more of the following: checking the digital signature, checking the signature certificate path, checking the executable file against one or more blacklists (e.g., local and external), and checking the executable file against one or more whitelists. In some implementations, the computing system receives a notification from the server system in response to sending the executable code. In some implementations, in accordance with the notification validating the executable code, the computing system changes the provisional trusted binary to a (non-provisional) trusted binary. In some implementations, in accordance with the notification invalidating the executable code, the computing system removes the program or prevents the program from being executed in the future. In some implementations, in accordance with the notification invalidating the executable code, the program (or executable code) is added to blocklist 342. In some implementations, in accordance with a notification that invalidates the executable code, the provisional trust binary is removed from the trust store and / or added to the blocklist information.

[0134] (A14) A method according to any of A1 to A13, further comprising: (i) obtaining executable code for a device driver program; (ii) identifying a plurality of executable functions from the executable code; (iii) for each of the plurality of executable functions, generating a function digest based on one or more static components of the respective executable function; (iv) for each of the plurality of executable functions, constructing a trust binary containing the respective digest; (v) generating a trust binary name by applying a hash function to the header of the executable code; and (vi) using the trust binary name to index the trust binary in a trust database (e.g., trust store 338).

[0135] (B1) In another embodiment, some implementations include a method for using a trusted binary (e.g., method 700). The method is performed on a computing system (e.g., computing device 300) having memory (e.g., memory 314) and one or more processors (e.g., CPU 302(or more)). This method includes (i) running a trust agent (e.g., trust agent 324), (ii) detecting the upcoming execution of a program (e.g., application 322) via the trust agent, (iii) retrieving a trust binary (e.g., trust binary 340) for the program from a trust store in memory (e.g., trust store 338) in response to the detection, (iv) verifying the authenticity of the program by comparing the program's executable code with the retrieved trust binary for the program, (v) authorizing the execution of the program according to the verified authenticity of the program, (vi) identifying the upcoming execution of an executable function within the program by monitoring the program's execution, (vii) retrieving a function digest (e.g., function digest 343) corresponding to the executable function from the trust binary in response to identifying the upcoming execution of the executable function, (viii) verifying the authenticity of the executable function by comparing the executable code of the executable function with the retrieved function digest, and (ix) authorizing the execution of the executable function according to the verified authenticity of the executable function. In some implementations, verifying the authenticity of a program involves verifying the authenticity of one or more shared libraries used by the program (for example, by comparing them with their corresponding trusted binaries). In some implementations, obtaining a trusted binary involves generating a binary name for the program and using that generated binary name to search for the trusted binary in the trusted store. In some implementations, comparing the executable code of a program with a retrieved trusted binary for the program involves generating a digest of the executable code and comparing the generated digest with the retrieved trusted binary.In some implementations, comparing the executable code of an executable function with a retrieved function digest involves generating a digest of the executable code of the executable function and comparing the generated digest with the retrieved function digest.

[0136] (B2) The method of B1, which involves running a trust agent, including establishing multiple kernel hooks for input / output (I / O) inspection. For example, kernel agent 326 of trust agent 324 establishes multiple kernel hooks as part of the boot procedure.

[0137] (B3) The method of B1 or B2, wherein detecting future execution of a program includes identifying memory requests corresponding to the program. For example, kernel agent 326 detects the binary file for a program loaded into a memory buffer.

[0138] (B4) Identifying future executions of program executable functions is any method of B1-B3, including intercepting library function calls made by the program. For example, a call to a function in a shared library. In some implementations, in response to detecting a call to a function in a shared library, the trust agent retrieves a trust binary for the shared library and compares the digest of the called function with the corresponding function digest in the trust binary for the shared library.

[0139] (B5) Monitoring the execution of a program is any method described in B1-B4, which includes monitoring the program's system-level behavior. In some implementations, system-level behavior includes one or more of the following: file I / O behavior, registry I / O behavior, thread start and stop behavior, and image load and unload behavior.

[0140] (B6) The method described in any of B1 to B5, wherein the trust agent is executed when the computing system starts up. In some implementations, the trust agent is specific to the computing system's operating system. For example, the first type of trust agent is used for the Windows operating system, the second type for the Android operating system, the third type for the iPhone operating system (iOS), and the fourth type for the Linux operating system.

[0141] (B7) A trust agent is a method of any of B1 to B6, including a kernel-level driver (e.g., kernel agent 326). In some implementations, the kernel-level driver is a device driver that operates in ring-0 on the computing system.

[0142] (B8) The method according to any of B1 to B7, wherein the trust agent includes a communication service (e.g., communication service 328), a file monitor (e.g., binary monitor 330), an installer (e.g., installer 334), and a dashboard manager (e.g., dashboard module 332). In some implementations, the communication service includes a user-mode privileged process that handles communication between the kernel driver, file monitor, dashboard manager, and trust center. In some implementations, the communication service communicates with the trust center (e.g., periodically) to receive policy updates, trust binary updates, and / or software updates. In some implementations, the file monitor creates, stores, and validates trust binaries. In some implementations, the file monitor monitors the memory of the computing device to validate programs and functions (and generate corresponding alerts). In some implementations, the file monitor runs as a privileged service with a low priority (e.g., using spare kernel cycles). In some implementations, the dashboard manager allows viewing and exporting alerts, creating new (provisional) trust binaries, configuring trust agents, and / or modifying policies. In some implementations, the installer probes the computing system, discovers executable files and code, requests trust binaries (e.g., from Trust Center 402), and installs other components of the trust agent (e.g., kernel agent 326).

[0143] (B9) A method according to any of B1 to B8, wherein executing a trust agent comprises (i) loading the trust agent's executable code into memory, (ii) obtaining a trust binary for the trust agent, and (iii) verifying the authenticity of the trust agent by comparing the loaded executable code with the obtained trust binary. In some implementations, verifying authenticity includes checking for unauthorized access to the trust agent's files, folders, registry settings, and configuration settings (e.g., by performing an identity verification operation on the trust store's blockchain). In some implementations, comparing the loaded executable code with the obtained trust binary includes generating a digest of the loaded executable code and comparing the generated digest with the obtained trust binary.

[0144] (B10) A method according to any of B1 to B9, further comprising: (i) detecting the future execution of a second program via a trust agent; (ii) determining that the trust store does not contain a trust binary corresponding to the second program; and (iii) initiating a corrective action in accordance with the determination (for example, operations 738, 740, and 742 described above with reference to Figure 7C).

[0145] (B11) A method according to B10, wherein the corrective action includes one or more of the following: (i) preventing the second program from running on the computing system; (ii) storing information about the second program in a forensic log; and (iii) generating a provisional (local) trusted binary for the second program. In some implementations, the forensic log and corresponding notices are sent to a trust center. In some implementations, a copy of the second program is sent to the trust center for analysis and verification. In some implementations, verification includes one or more of the following: virus scanning, blocklist checking, signature verification, certificate chain verification, and vulnerability analysis. In some implementations, the trust center sends a response to the computing system based on the results of the verification. In some implementations, in accordance with a notice validating the second program, the computing system changes the provisional trusted binary to a (non-provisional) trusted binary. In some implementations, in accordance with a notice invalidating the second program, the computing system deletes the second program or prevents the second program from running in the future. In some implementations, the second program is added to the blocklist in accordance with a notification that invalidates the second program. In some implementations, the provisional trust binary is removed from the trust store and / or added to the blocklist information in accordance with a notification that invalidates the second program.

[0146] (B12) The method according to B10 or B11, wherein the corrective action comprises generating a provisional trust binary, and the method further comprises sending the executable code of a second program to a trust center (e.g., trust center 510) for validity authentication. In some implementations, in response to sending the executable code to the trust center, the trust agent receives a validity authentication response indicating whether the provisional trust binary should be converted to a trust binary.

[0147] (B13) A corrective action is any method of B10 to B12, which includes applying one or more countermeasures (for example, the countermeasures described above with respect to operation 752 of method 700). In some implementations, the countermeasures include monitoring for heap spraying, reflective injection, read buffering, access to blocked IP addresses, malicious function calls, execution of malicious scripts (JavaScript), privilege tampering, shellcode buffering, and trust agent tampering.

[0148] (B14) The corrective action is the method of any of B10-B13, which includes sending a query to the Trust Center (e.g., Trust Center 510) about the trust binary for the second program. In some implementations, in response to the query, the Trust Center either sends the trust binary for the second program or sends an indicator that the Trust Center does not contain the trust binary for the second program.

[0149] (B15) The method of any of B10-B14, further comprising obtaining a trust policy for the computing device, wherein initiated corrective actions are selected according to the trust policy. For example, the computing device is an OT device, and the trust policy instructs it to prevent any untrusted execution. Another example is that the computing device is an IT device, and the trust policy instructs it to allow untrusted execution but to apply countermeasures and / or conditions (e.g., monitoring and recording). In some implementations, the trust policy includes corrective action settings, update settings, and deployment settings.

[0150] (B16) A method according to any of B1 to B15, further comprising: (i) detecting the upcoming execution of a second program (e.g., application 322) via a trust agent; (ii) retrieving a second trust binary for the second program (e.g., trust binary 340-2) from a trust store in response to the detection; (iii) identifying one or more changes to the executable code of the second program based on a comparison with the second trust binary (e.g., a comparison of the hash of the executable code with the digest of the second trust binary); and (iv) initiating a corrective action in accordance with the identification of one or more changes.

[0151] (B17) A method according to any of B1 to B16, further comprising: (i) monitoring the execution of the program and identifying a future execution of a second executable function of the program; (ii) in response to identifying a future execution of a second executable function, determining that the trust binary does not contain a function digest for the second executable function; and (iii) initiating a corrective action in accordance with the determination.

[0152] (B18) A method relating to B17, wherein the corrective action includes one or more of the following: (i) preventing the execution of a second executable function; (ii) stopping the execution of a program; (iii) storing information about the second executable function in a forensic log; and (iv) generating a provisional function digest for the second executable function.

[0153] (B19) A method according to any of B1 to B18, further comprising: (i) identifying a future execution of a second executable function of a program; (ii) obtaining a second function digest corresponding to the second executable function from a trust binary in response to identifying a future execution of the second executable function; (iii) identifying one or more changes to the second executable function based on a comparison with the second function digest; and (iv) initiating a corrective action in accordance with the identification of one or more changes to the second executable function.

[0154] (B20) A method according to any of B1 to B19, further comprising: (i) detecting future execution of a device driver via a trust agent; (ii) retrieving a trust binary for the device driver from a trust store in memory in response to the detection; (iii) verifying the authenticity of the device driver by comparing the executable code of the device driver with the retrieved trust binary for the device driver; (iv) permitting execution within the device driver in accordance with the verified authenticity of the device driver; (v) identifying future execution of an executable function within the device driver by monitoring the execution of the device driver; (vi) comparing a function digest of the executable function with one or more function digests in the trust binary in response to identifying a future execution of the executable function; and (vii) preventing execution of the executable function based on the result of the comparison (for example, by not identifying a match between the function digest of the executable function and one or more function digests in the trust binary).

[0155] (C1) In another embodiment, several implementations include a method for using blockchain validity authentication (e.g., method 800). The method is performed on a computing system (e.g., computing device 300) having memory (e.g., memory 314) and one or more processors (e.g., CPU 302(or more)). The method includes (i) accessing the trust store for the computing system, including obtaining a blockchain (e.g., blockchain 350) for the trust store (e.g., trust store 338), (ii) identifying a first change (e.g., a first transaction) to the trust store, and (iii) in response to identifying the first change, a first block (e.g., transaction block 347-1) which includes a first encrypted digest (e.g., transaction digest 364) and a first block digest (e.g., block digest 370) of the first change. The implementation includes (iv) generating a first block and inserting it into the blockchain, (iv) identifying a second change (e.g., a second transaction) to the trust store, and (v) generating a second block (e.g., transaction block 347-2) in response to identifying the second change, which includes a second encrypted digest (e.g., transaction digest 378), a second block digest (e.g., block digest 384), and a first block digest (e.g., previous block digest 376) of the second change, and inserting the second block into the blockchain. In some implementations, each block includes a block digest for the block and a previous block digest for the previous block in the chain (e.g., as shown in Figure 3C).

[0156] (C2) Acquiring the blockchain is the method described in C1, which includes acquiring the blockchain's genesis block (e.g., genesis block 345). In some implementations, the trust store and genesis block are acquired from the trust center (e.g., as part of the trust agent installation process).

[0157] (C3) A genesis block is the method described in C2, comprising an encrypted digest of a trust binary (e.g., a trust binary pre-installed by a trust center), a block type, a signing certificate, a digital signature, and an encrypted block digest. In some implementations, the genesis block further includes a creation timestamp. In some implementations, the genesis block further includes an empty previous block digest. In some implementations, the signing certificate includes identification of the block creator (e.g., trust center 510).

[0158] (C4) The method according to C3, wherein the first block further includes an encrypted block digest of the genesis block. For example, transaction block 347-1 includes a preceding block digest 360 corresponding to the block digest 356 of the genesis block 345.

[0159] (C5) The method according to any of C1 to C4, wherein the first block has a block type selected from the group consisting of trusted binary type, blocklist type, policy type, and local trusted binary type.

[0160] (C6) The first change to the trust store is the method described in any of C1 to C5, wherein the first block has a trust binary block type. In some implementations, the first change is the addition of a trust binary to the trust store. In some implementations, the first change is the removal of a trust binary (or provisional trust binary) from the trust store.

[0161] (C7) The first change to the trust store includes a change to the trust store policy (e.g., a change to policy information 346), and the first block is a method of any of C1 to C5 having a policy block type.

[0162] (C8) A first change to the trust store includes a change to the blocklist of the trust store, the first block being any of the methods in C1 to C5, wherein the first block has a block type in the blocklist. For example, a first change is the addition of a program, application, script, or function to blocklist 342.

[0163] (C9) The method of any of C1 to C5 wherein the first change to the trust store includes the addition of a local (provisional) trust binary to the trust store, and the first block has a local (provisional) trust binary block type.

[0164] (C10) The method of any of C1-C9, further including verifying the integrity of the trust store, including using the blockchain to authenticate the validity of the contents of the trust store after generating the second block. In some implementations, verification occurs according to the trust agent's activation procedure.

[0165] (C11) The method of C10, further comprising validating the blockchain using a proof-of-identity operation, which includes verifying the integrity of the trust store by comparing a first block digest in a second block (e.g., previous block digest 376) with a first block digest in a first block (e.g., block digest 370).

[0166] (C12) The first encrypted digest is generated using two or more secure hash algorithms (e.g., consecutive SHA-256 operations) in any of the methods described in C1 to C11.

[0167] (C13) The blockchain is stored in a table in the trust store, and each row in the table corresponds to a block in the blockchain, as described in any of C1 to C12. For example, blockchain 350 is stored in the table of trust store 338.

[0168] (C14) Each block in the blockchain is one of the methods in C1-C13, including its own signing certificate and its own digital signature. In some implementations, the signing certificate of the first block (e.g., signing certificate 372) corresponds to a client certificate stored in the policy table of the trust store. In some implementations, the digital signature of the first block (e.g., digital signature 374) corresponds to an encryption key stored in the policy table of the trust store.

[0169] In another embodiment, some implementations include a computing system comprising one or more processors and memory coupled to one or more processors, the memory storing one or more programs configured to be executed by one or more processors, and the one or more programs comprising instructions for executing any of the methods described herein (e.g., A1-A14, B1-B20, and C1-C14 above, and E1-E11 below).

[0170] In yet another embodiment, some embodiments include a non-temporary computer-readable storage medium that stores one or more programs for execution by one or more processors of a computing system, the one or more programs including instructions for executing any of the methods described herein (e.g., A1-A14, B1-B20, and C1-C14 above, and E1-E11 below).

[0171] (D1) In yet another embodiment, some implementations include a non-temporary computer-readable storage medium containing a trust database (e.g., trust store 338) that stores a plurality of trust binaries (e.g., trust binary 340), each trust binary corresponding to a respective executable program, and each trust binary of the plurality of trust binaries includes (a) a respective trust binary name (e.g., trust binary name 341) generated by applying a hash function to the respective header (e.g., ELF header 252) of the respective executable program, and (b) a respective function digest (e.g., function digest 343) for each executable function identified within the respective executable program, each function digest being generated based on the respective start address and one or more respective static components of the respective executable function, and the plurality of trust binaries are indexed in the trust database using their respective trust binary names. In some implementations, memory 314 includes a non-temporary computer-readable storage medium.

[0172] (D2) The trust database is a non-temporary computer-readable storage medium as described in D1, which further stores policy information. In some implementations, the policy information includes one or more security policies (e.g., security policy 504-2). In some implementations, the policy information includes a policy table (e.g., including client certificates and encryption keys for computing devices).

[0173] (D3) The trust database is a non-temporary computer-readable storage medium as described in D1 or D2, which further stores one or more forensic logs (e.g., forensic log 348). For example, the forensic log includes memory buffer information, state information, and process information in cases where untrusted applications and functions are detected.

[0174] (D4) Each function digest is a non-temporary computer-readable storage medium described in any of D1-D3, representing a hashed version of the corresponding executable function. In some implementations, each function digest is generated by applying a secure hash algorithm to the static portion of the corresponding executable function.

[0175] (D5) The trust database is a non-temporary computer-readable storage medium described in any of D1 to D4, which further stores blockchain information for authenticating the trust database. In some implementations, the blockchain information includes a blockchain (e.g., Blockchain 350) which has a block for each change to the trust database.

[0176] (D6) A non-temporary computer-readable storage medium as described in D5, wherein the blockchain information includes multiple blocks (e.g., transaction block 347), and each of the multiple blocks includes a block type (e.g., block type 368), a signing certificate (e.g., signing certificate 372), a digital signature (e.g., digital signature 374), and a digest (e.g., transaction digest 364).

[0177] (D7) A non-temporary computer-readable storage medium as described in D6, wherein the multiple blocks include a genesis block (e.g., genesis block 345) and blocks corresponding to each respective change that occurred in the trust store (e.g., transaction block 347).

[0178] (D8) A non-temporary computer-readable storage medium according to D6 or D7, wherein each block of a plurality of blocks has a block type selected from the group consisting of trusted binary type, blocklist type, policy type, and local binary type.

[0179] (D9) A non-temporary computer-readable storage medium as described in any of D6-D8, wherein each digest of a plurality of blocks is encrypted using at least two secure hash algorithms. In some implementations, each digest is encrypted by applying a sequence of secure hash algorithms. In some implementations, each digest is encrypted by applying a secure hash algorithm twice in a row.

[0180] (D10) A non-temporary computer-readable storage medium as described in any of D6-D9, wherein each block in a plurality of blocks further contains the block digest of the previous block in the blockchain. For example, transaction block 347-2 contains the previous block digest 376, which corresponds to the block digest 370 of transaction block 347-1.

[0181] (D11) A non-temporary computer-readable storage medium described in any of D1 to D10, wherein the trust database further stores a second plurality of trust binaries, each of the second plurality of trust binaries corresponds to a respective device driver, and each of the plurality of trust binaries includes (a) a respective trust binary name (e.g., trust binary name 341) generated by applying a hash function to the respective header of the respective device driver, and (b) a respective function digest (e.g., function digest 343) for each executable function identified by the respective device driver, each function digest being generated based on the respective start address and one or more respective static components of the respective executable function, and the second plurality of trust binaries are indexed in the trust database using their respective trust binary names.

[0182] (E1) In other embodiments, several implementations include a method for monitoring network traffic. The method is performed on a computing device (e.g., gateway device 108) having memory and one or more processors. In some implementations, the method is performed on a computing system (e.g., computing device 300) having memory (e.g., memory 314) and one or more processors (e.g., CPU 302(or more)). The method includes (i) monitoring network packets, (ii) identifying executable files (e.g., executable file 200) within network packets, (iii) determining whether a trust store (e.g., trust store 338) contains a trust binary (e.g., trust binary 340) corresponding to the executable file, and (iv) performing a corrective action in accordance with the determination that the trust store does not contain a trust binary corresponding to the executable file.

[0183] (E2) The method described in E1, wherein a remedial action includes one or more of the following: isolating the executable file, rejecting the executable file, dropping the packet(s) containing the executable file, and redirecting the packet(s) containing the executable file. In some implementations, the remedial action is performed in accordance with the active policy (e.g., policy information 346).

[0184] (E3) The method of E1 or E2, further comprising performing a malware check on network packets, identifying malware within network packets, and performing a remedial action. In some implementations, the remedial action includes one or more of the following: isolating malware, rejecting malware, dropping the packet(s) containing malware, and redirecting the packet(s) containing malware.

[0185] (E4) The method of any of E1 to E3, further comprising identifying restricted information in one or more network packets and rejecting network packets containing restricted information. In some implementations, restricted information includes personally identifiable information (PII), confidential information, financial information, etc.

[0186] (E5) The method of any of E1 to E4, further comprising profiling network packets and taking action on the network packets based on the profiling, including one or more of prioritizing, filtering, and redirecting. In some implementations, taking action includes filtering attacks and / or deprioritizing video data. In some implementations, the action is performed in accordance with an active policy (e.g., policy information 346).

[0187] (E6) The method of E5, further comprising presenting the user with a dashboard containing information on profiling and corresponding actions. In some implementations, the dashboard is a user interface. In some implementations, the dashboard allows the user to set or adjust policy rules (e.g., corrective actions and / or filtering, prioritizing, and redirecting network packets).

[0188] (E7) The method of any one of E1 to E6, further comprising identifying a subset of network packets as corresponding to a special application, and performing a policy action on the subset of network packets in accordance with a policy for the special application.

[0189] (E8) The method according to any of E1 to E7, wherein the computing device is a gateway device (e.g., gateway device 108).

[0190] (E9) The method according to E8, wherein the gateway device includes a network-on-chip (NIC) component. For example, the gateway device includes a smart NIC. In some implementations, the NIC component is a secure intelligent adapter (SIA) network card.

[0191] (E10) A gateway device is an instruction on an x86 appliance or virtual machine, as described in E8 or E9.

[0192] (E11) Network packets are monitored using one or more machine learning algorithms as described in any of the methods from E1 to E10. For example, Appendix A describes using machine learning to identify unknown attacks in network data.

[0193] The terms used in this description of the invention are for the sole purpose of describing specific implementations and are not intended to limit the invention. Where used in the description of the invention and the accompanying claims, the singular forms “a,” “an,” and “the” are also intended to include plural forms unless the context clearly indicates otherwise. The term “and / or,” where used herein, will also be understood to refer to and include any and all possible combinations of one or more of the enumerated items relating to the invention. The terms “comprises” and / or “comprising,” where used herein, specify the presence of the described features, steps, actions, elements, and / or components, but will not be understood to exclude the presence or addition of one or more other features, steps, actions, elements, components, and / or groups thereof.

[0194] For explanatory purposes, the above description is based on reference to specific implementations. However, the above illustrative discussion is not intended to be exhaustive, nor is it intended to limit the invention to the exact form disclosed. Many modifications and variations are possible in light of the above teachings. The implementations are selected and described to best illustrate the principles of the invention and its practical applications, thereby enabling those skilled in the art to best utilize various implementations with various modifications suitable for the invention and the specific use it is intended for.

Claims

1. A method performed on a computing device having memory and one or more processors, wherein the method is Obtaining the program's executable code, Identifying multiple executable functions from the aforementioned executable code, For each of the aforementioned multiple executable functions, one or more static components of each executable function are identified. For each of the aforementioned multiple executable functions, a function digest is generated based on the identified one or more static components. To construct a trusted binary for the aforementioned program, Combining the respective function digests of each of the multiple executable functions, and The construction includes generating a trusted binary name by applying a hash function to the header of the aforementioned executable code, A method comprising indexing the trust binary in a trust database using the trust binary name.

2. The method according to claim 1, wherein generating the respective function digest for each executable function is further based on the respective starting address of each executable function.

3. The method according to claim 1, wherein the executable code is one of a program executable file or an executable and linkable format (ELF) file.

4. The method according to claim 1, wherein the one or more static components of each executable function include one or more parts representing one or more instructions and / or static data.

5. The method according to claim 1, wherein the one or more static components of each executable function exclude the dynamic address field.

6. The method according to claim 1, further comprising hashing one or more of the data directory of the program, the section table of the program, and the program table of the program, for constructing the trusted binary.

7. The method according to claim 1, wherein the function digest for each of the plurality of executable functions is generated using a secure hash algorithm.

8. The method according to claim 1, wherein the trust database is stored in the memory of the computing device.

9. The method according to claim 1, further comprising transmitting the trusted binary to a server system located away from the computing device.

10. A computing device, One or more processors, Memory and The display and The memory includes one or more programs that are stored in the memory and configured for execution by one or more processors, and the one or more programs are Obtaining the program's executable code, Identifying multiple executable functions from the aforementioned executable code, For each of the aforementioned multiple executable functions, one or more static components of each executable function are identified. For each of the aforementioned multiple executable functions, a function digest is generated based on the identified one or more static components. To construct a trusted binary for the aforementioned program, Combining the respective function digests of each of the multiple executable functions, and The construction includes generating a trusted binary name by applying a hash function to the header of the aforementioned executable code, A computing device that includes instructions for indexing the trust binary in a trust database using the aforementioned trust binary name.

11. The computing device according to claim 10, wherein generating the respective function digest for each executable function is further based on the respective starting address of each executable function.

12. The computing device according to claim 10, wherein the one or more static components of each executable function include one or more parts representing one or more instructions and / or static data.

13. The computing device according to claim 10, wherein the one or more static components of each executable function exclude the dynamic address field.

14. The computing device according to claim 10, wherein constructing the trusted binary further comprises hashing one or more of the program's data directory, the program's section table, and the program's program table.

15. The computing device according to claim 10, wherein the function digest for each of the plurality of executable functions is generated using a secure hash algorithm.

16. The computing device according to claim 10, wherein the trust database is stored in the memory of the computing device.

17. The computing device according to claim 10, wherein the one or more programs further include instructions for transmitting the trusted binary to a server system located away from the computing device.

18. A non-temporary computer-readable storage medium for storing one or more programs configured for execution by a computing device having one or more processors, memory, and a display, wherein the one or more programs are Obtaining the program's executable code, Identifying multiple executable functions from the aforementioned executable code, For each of the aforementioned multiple executable functions, one or more static components of each executable function are identified. For each of the aforementioned multiple executable functions, a function digest is generated based on the identified one or more static components. To construct a trusted binary for the aforementioned program, Combining the respective function digests of each of the multiple executable functions, and The construction includes generating a trusted binary name by applying a hash function to the header of the aforementioned executable code, A non-temporary computer-readable storage medium comprising instructions for indexing the trust binary in a trust database using the trust binary name.

19. The non-temporary computer-readable storage medium according to claim 18, wherein the function digest for each of the plurality of executable functions is generated using a secure hash algorithm.

20. The non-temporary computer-readable storage medium according to claim 18, wherein the one or more static components of each executable function exclude dynamic address fields.

Images