Code integrity protection in devices with limited computing resources

Abstract

Methods and devices are disclosed for protecting a processing device by deploying a security controller to verify the integrity of an executable code segment executed by a protected device. The security controller computes a first security code from a first copy of a random operation of the executable code segment, the first copy of the random operation of the executable code segment loaded into a memory of the security controller; generates a verification code segment for computing a second security code from a second copy of the random operation of the executable code segment, the second copy of the random operation of the executable code segment loaded into a memory of the protected device. The security controller sends the verification code segment to the protected device; receives the second security code from the protected device; compares the first security code and the second security code; determines a compromise suffered by the protected device in response to the second security code not matching the first security code.

Description

TECHNICAL FIELD

[0001] The present invention relates to protecting processing devices from malicious attacks, and more specifically but not exclusively, to using secure devices for protecting processing devices from malicious attacks, the secure devices being used for verifying software code executed by the protected processing devices. BACKGROUND

[0002] With the continued rapid development of technology, automation has almost penetrated into all aspects of modern life. One of the most rapidly developing trends is the deployment of Internet of Things (IoT) devices, sensors, controllers, etc. for numerous applications.

[0003] By its nature, in order to effectively meet application requirements, the design of most, if not all, IoT devices faces challenging limitations in terms of power, performance, cost, etc.

[0004] Such IoT devices can typically be low-end devices with very limited computing resources, such as processing power, storage resources, communication resources, etc.

[0005] Due to the scarcity of available computing resources of IoT devices, their security defenses are very weak, and these IoT devices are often almost unattended and communicate through networks with lenient regulations, so they can often suffer from a large number of network-originated malicious attacks.

[0006] IoT devices can be protected by deploying software integrity protection measures (i.e., verifying the integrity of software stored on disk, flash, etc.) that can be applied in the transition state during hibernation and download or upload. Therefore, the common software (software, SW) distribution package designed for IoT devices, such as Secure Sockets Layer (SSL), etc. can include tools and libraries for SW encryption, signature, hash, etc. to support file integrity protection in the inspection during hibernation, transmission, and loading.

[0007] However, many network-originated malicious attacks are based on malicious agents (malware, viruses) that are injected into the attacked devices to implement malicious functions by modifying software, firmware, middleware, etc. software code segments executed by the processing devices at runtime. Such runtime attacks can be referred to as software (software, SW) / firmware (firmware, FW) tampering.

[0008] Due to the very limited available computing resources in IoT devices, protecting low-end devices with limited computing resources from runtime malicious tampering attacks can face major challenges, thus being difficult and relatively costly to implement. SUMMARY

[0009] An object of embodiments of the application is to provide a solution that reduces or solves the drawbacks and problems of conventional solutions.

[0010] The above and other objects are achieved by the subject-matter of the independent claims. Further advantageous embodiments can be found in the dependent claims.

[0011] The present application aims at providing a solution for protecting a device, in particular a low-end device with limited resources, by deploying a security controller operatively connected to the protected device via a network, to verify the integrity and reliability of executable software code executed by the protected device.

[0012] According to a first aspect of the application, there is provided a security controller comprising a memory and a circuitry; the circuitry being configured to:

[0013] - load a first copy of an executable code segment into the memory;

[0014] - compute a first security code from a first copy of a random operation of the executable code segment;

[0015] - generate a verification code segment configured to cause a protected device to compute a second security code from a second copy of the executable code segment after the second copy of the executable code segment is loaded into a memory of the protected device;

[0016] - send the verification code segment to the protected device;

[0017] - receive the second security code from the protected device;

[0018] - compare the first security code and the second security code;

[0019] - determine a compromise suffered by the protected device in response to the second security code not matching the first security code.

[0020] According to a second aspect of the application, there is provided a computer-implemented method for detecting a protected device that can suffer a compromise, comprising:

[0021] - loading a first copy of an executable code segment into a memory of a security controller;

[0022] - computing a first security code from a first copy of a random operation of the executable code segment;

[0023] - generating a verification code segment, said verification code segment being for causing said protected device to compute a second security code from a second copy of said executable code segment after said second copy of said random operation of said executable code segment is loaded into a memory of said protected device;

[0024] - sending said verification code segment to said protected device;

[0025] - receiving said second security code from said protected device;

[0026] - comparing said first security code and said second security code;

[0027] - in response to said second security code not matching said first security code, determining that said protected device is subject to a compromise.

[0028] According to a third aspect of the application, there is provided a protected device comprising a memory and a circuit, said circuit being for:

[0029] - loading a copy of an executable code segment into said memory;

[0030] - receiving a verification code segment from a security controller, said verification code segment being for causing said protected device to compute a security code from a copy of a random operation of said executable code segment;

[0031] - executing said verification code segment;

[0032] - computing said security code from said copy of said random operation of said executable code segment;

[0033] - sending said security code to said security controller.

[0034] According to a fourth aspect of the application, there is provided a computer- implemented method for detecting a compromise that a protected device can be subject to, comprising:

[0035] - loading a copy of an executable code segment into a memory of said protected device;

[0036] - receiving a verification code segment from a security controller, said verification code segment being for causing said protected device to compute a security code from a copy of a random operation of said executable code segment;

[0037] - computing said security code from said copy of said random operation of said executable code segment;

[0038] - sending said security code to said security controller.

[0039] According to a fifth aspect of the present application, a computer readable medium is provided comprising instructions executable by a computer, which when executed by the computer, cause the computer to perform the method according to the second or fourth aspect.

[0040] The protected device can be a low-end device with limited resources, which has significant limitations in its ability to prevent malware from infiltrating its memory and attempting to compromise the protected device. Deploying the security controller to protect the low-end device can require the protected device to perform a relatively simple process, thereby greatly reducing the computational resources required by the protected device. Thus, using the security controller can be well suited for protecting the low-end device. The low-end device can be effectively protected regardless of whether it has limited computational resources. Furthermore, reducing the computational resources required to protect these devices can further reduce the cost and / or complexity of the protected device. Moreover, by computing the second security code from the copy of the randomly operated version of the executable code segment, malware that infects the second copy of the executable code segment executed by the protected device can not be able to discover the random operation and thereby successfully modify the verification code segment to compute a valid second security code from the infected second copy. This advantage can be highly magnified for the low-end protected device, as the malware can require a large amount of computational resources to attempt to discover the random operation, which can not be available in the low-end protected device with limited resources. It should be noted that the random operation performed on the first and second copies of the executable code segment (specifically, the random operation of the first and second plurality of bytes) is only performed as part of computing the first and second security codes, respectively, and is not actually used in the memory of the security controller and the memory of the protected device, respectively. The first and second copies of the executable code segment are loaded into the memory of the security controller and the memory of the protected device, respectively. Thus, the loaded copies of the executable code segment are not affected by the random operation and can be executed correctly.

[0041] In another implementation form of the first, second and / or fifth aspect of the present application, at least one hash function is used to compute a hash value from the first copy of the executable code segment; the first security code comprises the hash value. Hash values are very effective for computing a string of limited length and fixed size from a copy of the executable code segment, and are thus commonly used in a variety of applications. Furthermore, the hash function is a one-way function, and thus the input to the hash function, i.e. the executable code segment, cannot be recovered from the output hash value.

[0042] In a further implementation form of the first, second and / or fifth aspect of the application, the random operation comprises: randomly selecting addresses of a first plurality of bytes in the first copy of the executable code segment; and for calculating the first secure code, excluding the first plurality of bytes residing at the randomly selected addresses from the first copy of the executable code segment. By excluding (skipping) the data bytes residing at the randomly selected addresses, malware potentially residing in the memory of the protected device can have difficulties or even be unable to discover the random operation and to generate a valid second secure code accordingly.

[0043] In a further implementation form of the first, second and / or fifth aspect of the application, the random operation comprises: randomly selecting addresses of a first plurality of bytes in the first copy of the executable code segment; and for calculating the first secure code, modifying the first plurality of bytes residing at the randomly selected addresses in the first copy of the executable code segment. By modifying the byte data residing at the randomly selected addresses, malware potentially residing in the memory of the protected device can have difficulties or even be unable to discover the random operation and to generate a valid second secure code accordingly.

[0044] In a further implementation form of the first, second and / or fifth aspect of the application, the random operation comprises: selecting addresses of a first plurality of bytes; and for calculating the first secure code, randomly inserting the first plurality of bytes residing at the randomly selected addresses into the first copy of the executable code segment. By inserting the data bytes at the randomly selected addresses, malware potentially residing in the memory of the protected device can have difficulties or even be unable to discover the random operation and to generate a valid second secure code accordingly.

[0045] In an optional implementation form of the first, second and / or fifth aspect of the application, the verification code segment is encoded. Encoding the verification code segment can significantly increase the difficulty for the malware to obtain the verification code segment, since decoding or reversing the encoded verification code segment can require a significant amount of computational resources, which can not be available in the protected device, so that the malware cannot recover the random operation and cannot maliciously use the random operation to try to hide its presence.

[0046] In an optional implementation form of the first, second and / or fifth aspect of the application, the verification code segment is encoded using white-box cryptography. White-Box Cryptography (WBC) is widely used in software protection applications. WBC is well suited and capable of efficiently encoding the verification code segment, since WBC implements encrypted software algorithms in a way that guarantees the security of the encrypted assets when subjected to white-box attacks of malicious software.

[0047] In a further implementation form of the first, second and / or fifth aspect of the application, a verification session is performed to verify the executable code segment; the random operation is unique to the verification session, such that the verification code segment generated during the verification session is valid only for the verification session. The random operation and the verification code segment are unique and valid only for a single verification session, which can result in a verification code segment generated in a previous verification session being useless, thereby making the random operation highly robust and immune to replay attacks.

[0048] In an optional implementation form of the first, second and / or fifth aspect of the application, an action is initiated in response to not receiving the second security code from the protected device before expiration of a predefined timeout period. Applying a timeout mechanism can pose another major obstacle to the malicious software. In order to successfully evade detection, the malicious software can need to discover the random operation and modify the second copy accordingly within the predefined timeout period; the predefined timeout period is a time range determined for the verification session.

[0049] In a further implementation form of the first, second and / or fifth aspect of the application, the initiated action comprises at least one of the following actions: sending a warning message of the compromise; sending a new copy of the executable code segment to the protected device; instructing the protected device to restart; instructing the protected device to disconnect from at least one network. Selecting one or more actions to be initiated in response to the detected compromise in the protected device can highly flexibly take measures to counter a potentially suffered malicious attack. Thus, the actions can be selected in dependence on various aspects, features and / or properties of the detected attack, such as properties and / or operating parameters of the protected device, nature and / or criticality of the application (executable code segment) executed by the protected device, type of detected potential attack, etc.

[0050] In a further implementation form of the third, fourth and / or fifth aspect of the present application, at least one hash function is used to calculate a hash value from the copy of the executable code segment; the secure code comprises the hash value. As described above, hash values are very effective for calculating a limited length and fixed size string from a copy of the executable code segment, and are therefore commonly used in a variety of applications. Furthermore, the hash function is a one-way function, and therefore the input of the hash function, i.e. the executable code segment, cannot be recovered from the output hash value.

[0051] In a further implementation form of the third, fourth and / or fifth aspect of the present application, the random operation comprises: randomly selecting addresses of a plurality of bytes in the copy of the executable code segment; excluding the plurality of bytes residing at the randomly selected addresses from the copy of the executable code segment. As described above, by excluding (skipping) the data bytes residing at the randomly selected addresses, it can be made very difficult or even impossible for malware potentially residing in the memory of the protected device to discover the random operation and to generate a valid second secure code accordingly.

[0052] Other systems, methods, features, and advantages of the present application will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the present application, and be protected by the accompanying claims.

[0053] Unless otherwise defined, all technical and / or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the application pertains. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the application, exemplary methods and / or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

[0054] Implementation of the method and / or system of embodiments of the present application can involve performing or completing selected tasks manually, automatically, or a combination thereof. Moreover, according to actual instrument and equipment of embodiments of the method and / or system of the present application, one or more of the selected tasks could be implemented by hardware, by software, or by firmware or combinations thereof.

[0055] For example, hardware for performing selected tasks according to some embodiments of the application could be implemented. Conversely, the description herein can provide various example embodiments of a data processing system in which selected tasks are performed by a computer, such as a computer implementing a plurality of software instructions. In an exemplary embodiment, one or more tasks performed by a data processing system according to some embodiments of the application are performed by a computing platform for executing a plurality of instructions. Optionally, the data processing system includes a volatile memory for storing instructions and / or data and / or a non-volatile storage, for example, a magnetic hard disk and / or removable media to store instructions and / or data. Optionally, a network connection is provided as well. A user can enter commands and / or data into the data processing system through input device(s) and / or keyboard and / or mouse, for example. Examples of input devices include a keyboard, mouse, pen, voice input device, touch input device, etc. Examples of output devices include speakers, printers, etc. Optionally, the data processing system includes a display for displaying information to the user and / or other output devices. It will be appreciated that the data processing system can be connected to other devices in a network. BRIEF DESCRIPTION OF DRAWINGS

[0056] Some embodiments of the application are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments of the present application. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the application can be practiced.

[0057] In the drawings:

[0058] Figure 1 A flowchart of an exemplary process for protecting a processing device by a security controller for verifying software code executed by the protected processing device is shown, in accordance with some embodiments of the application;

[0059] Figure 2 A schematic diagram of an exemplary system for protecting a processing device by a security controller for verifying software code executed by the protected processing device is shown, in accordance with some embodiments of the application;

[0060] Figure 3A And Figure 3B An exemplary sequence for protecting a processing device by a security controller for verifying software code executed by the protected processing device is shown, in accordance with some embodiments of the application. DETAILED DESCRIPTION

[0061] Some embodiments of the application relate to protecting a processing device from malicious attacks, and more particularly, but not exclusively, to protecting a processing device from malicious attacks using a security device for verifying software code executed by the protected processing device.

[0062] According to some embodiments of the application, there are provided methods, devices and computer program products for verifying the integrity and reliability of executable software code executed by a processing device, to protect said processing device from malicious attacks initiated by infecting malware and executing on said protected device in an attempt to compromise said protected device.

[0063] The protection of said device is based on a security controller for verifying one or more software code segments, such as applications, processes, utilities, tools, programs, agents, scripts, etc., which are typically executed by said protected device having network connectivity and being able to communicate with said security controller.

[0064] In particular, said protected device can be an Internet of Things (IoT) device, a sensor, a controller, etc., low-end device with limited resources, including processing resources, storage resources, communication resources, etc.

[0065] The security controller can generate a verification software code segment for causing the processing circuitry to compute a security code (e.g., a hash value) from a copy of one or more executable code segments stored and executed by said protected device.

[0066] The security controller can locally store and / or access a first copy of said executable code segment targeted at said protected device, said copy being a verified image of said executable code segment verified to be authentic and unaltered from its original creation. The first copy can be stored in one or more secure storage resources, which can be protected using hardware and / or software, such as a Trusted Platform Module (TPM), a designated address space, etc., which can be accessed using cryptographic protection and / or using a secure protocol.

[0067] The security controller can thus load said first copy of said executable code segment into its local memory (e.g., volatile memory) and execute said verification code segment to compute a first security code from the first copy loaded into said memory.

[0068] The security controller can also send said verification code segment to one or more of said protected devices, which execute a second copy of said executable code segment stored locally and loaded into their local memory.

[0069] Each of the protected devices can execute the received verification code segment to compute a second security code from a second copy of the executable code segment, and can send the computed second security code to the security controller.

[0070] The security controller can then compare the second security code to the first security code; the second security code is computed from the second copy of the executable code segment located at the protected device, and the first security code is computed from the first copy of the executable code segment securely stored by the security controller. If a match, the security controller can determine that the second copy is a genuine copy of the executable code segment, since the second copy matches the first copy that is the verified image of the executable code segment.

[0071] However, if a mismatch, the security controller can determine that the second copy can potentially be injected and / or infected with one or more malware code segments that compromise the protected device. In this case, the security controller can initiate one or more actions to counter the potential compromise of the protected device, e.g., send a warning message of the potential compromise, send a new copy of the executable code segment to the protected device, instruct the protected device to reboot and / or reset, instruct the protected device to disconnect from a network, etc.

[0072] Some malware code segments that can infect the protected device can be designed and / or used to hide their existence by modifying the second copy of the executable code segment such that the security code computed from the modified infected second copy is the same as the security code computed from the original and uninfected second copy.

[0073] To improve the robustness of the verification process against such malware, the security controller can configure and / or modify the verification code segment to compute a security code from a copy of a randomly manipulated version of the executable code segment, such that the security code is computed after the copy of the executable code segment is randomly manipulated.

[0074] The random manipulation is based on randomly selecting a plurality of addresses in the address range occupied by the copy of the executable code segment in the memory and manipulating the bytes at the randomly selected addresses in one or more ways. For example, a plurality of bytes residing at the randomly selected addresses can be excluded (discarded) for the calculation of the security code. In another example, the data of a plurality of bytes residing at the randomly selected addresses can be modified (e.g., invalidated, filled with a predefined pattern, etc.) for the calculation of the security code. In another example, additional bytes having a predefined pattern can be inserted in the randomly selected addresses for the calculation of the security code.

[0075] It should be emphasized that the random manipulation of the copy of the executable code segment (specifically, the manipulation of the plurality of bytes residing at the randomly selected addresses) is performed for the purpose of calculating the security code only, and is not actually applied in the memory where the copy of the executable code segment is loaded. For example, the security code can be calculated using one or more security code calculation functions that sequentially iterate through the bytes of the executable code segment loaded into the memory and accordingly calculate the security code. In this case, the random manipulation can be applied dynamically, rather than by actually manipulating the executable code segment in the memory during the sequential iteration through the bytes of the executable code segment. Likewise, the random manipulation of excluding, skipping, inserting, modifying, etc. the plurality of bytes at the randomly selected addresses can be done as part of calculating the security code, without actually modifying the copy of the executable code segment loaded into the memory. Thus, the loaded copy of the executable code segment is not affected in any way and can execute correctly.

[0076] Thus, even if the protected device is infected with malware, these malware can not discover the random manipulation and thus can not modify the verification code segment to calculate the second security code from the infected second copy, matching the first security code calculated from the original and uninfected first copy of the random manipulation. Thus, the security controller can detect that the protected device can be infected with malware and thus compromised.

[0077] The random manipulation applied in each verification session and thus the verification code segment generated in each verification session is unique and different from the verification code segments used and generated in any other verification session.

[0078] Optionally, to further improve the security of the verification process and prevent the malware from obtaining the verification code segment, the security controller can encrypt the verification code segment. The verification code segment can be encoded using one or more encoding methods, algorithms and / or techniques. According to a preferred embodiment of the present invention, White-Box Cryptography (WBC) is a particularly suitable encoding method.

[0079] Encoding the verification code segment can further prevent the malware from recovering and obtaining the verification code segment, and thus can further improve the security of the code verification process against the malware that can infect the protected device.

[0080] Optionally, the security controller can initiate one or more timeout timers loaded with a predefined timeout period to define a time frame of the verification session. If the security controller does not receive the second security code from the protected device before the expiration of the timeout period, the security controller can determine that the protected device can be compromised by one or more malware code segments.

[0081] Compared to existing methods and systems for protecting the processing device, protecting the processing device by verifying the copy of the randomly operated version of the software code executed by the processing device can embody major advantages and benefits.

[0082] First, since the protected device can be a low-end device with limited computing resources, such a low-end device with limited resources can not be able to efficiently and effectively perform software integrity protection measures, e.g., Trusted Execution Environment (TEE), dedicated watchdog, runtime checkers (e.g., anti-malware, anti-virus, etc.), etc., which can be implemented by existing methods. These software integrity protection measures employed by existing methods can pose significant limitations to deployment in the protected device with limited resources for one or more reasons. For example, they require significant computing resources and / or dedicated hardware elements, have a large footprint (storage space at runtime), modify execution priority, etc. Thus, such software integrity protection measures are at best inefficient protection measures, as these measures can significantly degrade performance, consume major computing resources, etc.; and in most cases, these measures can actually be infeasible for low-end devices due to lack of sufficient computing resources.

[0083] Conversely, deploying the security controller provided by the present application to protect the low-end device can require the protected device to perform a relatively simple process, thereby significantly reducing the computational resources required by the protected device and making it well suited to protect the low-end device. Moreover, since the computational resources of the protected device can be reduced, the cost and / or complexity of the protected device can also be reduced.

[0084] Moreover, by randomly operating the copy of the executable code segment, even sophisticated malware designed and used to modify the native second copy of the executable code segment executed by the protected device can not easily discover the random operation in order to modify the second copy accordingly to generate a valid second secure code. Discovering the random operation can require a significant amount of computational resources that can not be available in the resource-limited protected device.

[0085] Moreover, in case a timeout mechanism is applied, the malware can not be able to discover the random operation and modify the second copy accordingly within the time frame defined for the verification session.

[0086] Moreover, since the random operation and the verification code segment are unique and valid only for a single verification session, the verification code segment generated in a previous verification session can not be used and, therefore, a replay attack is prevented.

[0087] Moreover, by encoding the verification code segment, the amount of work required to recover the malware is significantly increased, thereby further reducing the likelihood that the malware obtains the verification code segment and operates the verification code segment to compute a valid second secure code from the second copy while hiding the malware.

[0088] Before one or more embodiments of the application are explained in detail, it is to be understood that the application is not limited in its application to the details of construction and the arrangement of the components and / or methods set forth in the following description and / or illustrated in the drawings and / or the Examples. The application is capable of other embodiments or of being practiced or carried out in various ways.

[0089] Those skilled in the art will appreciate that the various aspects of the present application can be implemented in a system, a method, or a computer program product. Accordingly, the various aspects of the present application can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.) or combinations of software and hardware aspects that can all generally be referred to herein as a "circuit," "module" or "system." Furthermore, the various aspects of the present application can take the form of a computer program product on one or more computer readable medium(s) having computer readable program code embodied in the medium.

[0090] Any combination of one or more computer readable medium(s) can be utilized. The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0091] Computer program code embodied in a computer readable medium can be sent directly from one computer to another, for example over a communication medium or through a broadcasting or casting process via transmission media. Alternatively, computer program code embodied in a computer readable medium can be sent from one computer to another via a computer network, over a computer network, or via a broadcasting or casting process via transmission media.

[0092] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission cables, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions to a computer readable storage medium within the respective computing / processing device for execution by the computing device.

[0093] The computer readable program instructions for carrying out operations of the present application can be written in any combination of one or more programming languages, including an assembly language, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or any combination thereof, and can be written in any combination of one or more high-level programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages.

[0094] The computer readable program instructions can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), and can also be connected to a

[0095] The computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission cables, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions to a computer readable storage medium within the respective computing / processing device for execution by the computing device.

[0096] The flow and block diagrams in the figures illustrate the architecture, functionality, and operations of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flow and block diagrams can represent a module, segment, or portion of instructions which are implemented in one or more of the possible implementations of the present application. In some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession can in fact be executed substantially concurrently or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations thereof, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0097] Referring now to the drawings, Figure 1 A flowchart illustrating an exemplary process for protecting a processing device by a security controller for verifying software code executed by the protected processing device is shown.

[0098] Exemplary process 200 and exemplary process 300 can be performed by security controller 102 and protected device 104, respectively, to protect protected device 104 from one or more malicious attacks, particularly attacks intended to cause protected device 104 to execute malicious code in an attempt to compromise protected device 104. Processes 200 and 300 interact and are described in conjunction with one another according to the order of operations of the overall verification process incorporating processes 200 and 300 in order to provide a clear and complete description of processes 200 and 300 performed by security controller 102 and protected device 104, respectively.

[0099] Protected device 104 can include an IoT device, a sensor, a controller, etc. having a network connection and capable of communicating with security controller 102. Protected device 104 can generally include a relatively low-end device having limited resources (e.g., processing resources, storage resources, communication resources, etc.). As such, protected device 104 can have highly limited capabilities and can not be able to effectively perform integrity protection measures such as anti-malware, anti-virus software, etc.

[0100] Figure 1The processes 200 and 300 described in the middle describe a code verification session performed by a single security controller 102 for protecting a single protected device 104. However, this should not be construed as limiting, as the processes 200 and 300 can be extended to multiple verification sessions initiated by one or more security controllers 102 for protecting multiple protected devices 104. Moreover, the processes 200 and 300 can be extended to multiple verification sessions initiated by one or more security controllers 102 for protecting multiple executable code segments executed locally by one or more protected devices 104 from malware. To this end, one or more security controllers 102 can store copies of multiple executable code segments that are typically executed by one or more protected devices 104, where each of the copies is a verified image of a respective executable code segment that is verified to be authentic and untampered.

[0101] As shown at 202, the process 200 begins with the security controller 102 loading a first copy of the executable code segment, the first copy of the executable code segment being configured to be executed by the protected device 104.

[0102] As shown at 302 of the process 300, the process 200 can begin with the security controller 102 initiating a verification session for verifying a second copy of the executable code segment that is stored locally at the protected device 104 and executed by the protected device 104.

[0103] In particular, the verification session is initiated to verify the second copy of the code segment after the second copy of the code segment is loaded into the (volatile) memory of the protected device 104 at 302 of the process 300. Thus, the verification is performed to verify the integrity and reliability of the second copy executed by the protected device 104 and ensure that the second copy is not infected by one or more malware code segments. Such malware can attempt to compromise the protected device 104 by modifying the execution path of the protected device 104 and cause it to initiate one or more unexpected and / or unnecessary actions.

[0104] The security controller 102 can initiate the verification session periodically, continuously, and / or on-demand, i.e., upon a trigger by one or more automated tools and / or operators.

[0105] As shown at 204, the security controller 102 generates a verification code segment.

[0106] The secure controller 102 can configure and / or modify the verification code segment such that, after a copy of the executable code segment is loaded into memory, a secure code is computed from the copy of the executable code segment (e.g., the second copy of the executable code segment that is loaded into the memory of the protected device 104). Moreover, since the code segment executed by the protected device 104 in case of infection by one or more malware can typically be the segment that can contain the malware code, the verification code segment can be used to compute the secure code from the code region of the copy of the executable code segment.

[0107] However, in case the protected device 104 is infected by one or more malware code segments, these malware can be used to modify the verification code segment to compute a secure code from the second copy of the executable code segment such that the second secure code computed from the infected second copy is identical to the secure code computed from the original and uninfected second copy.

[0108] To improve the robustness of the verification process against the malware code segments that can be executed by the protected device 104, the verification code segment can be used to compute the secure code from the copy of the executable code segment after applying a random operation on the copy of the executable code segment.

[0109] Thus, even if the protected device 104 is infected by malware, such malware can not be able to modify the verification code segment to compute a second secure code from the second copy such that the second secure code computed from the infected second copy matches the secure code computed from the original and uninfected second copy.

[0110] The verification code segment can be used to apply the random operation on a random selection of bytes in the copy of the executable code segment that is loaded into the (volatile) memory. In particular, the random operation is applied on bytes at a random selection of addresses in the address range occupied by the copy of the executable code segment in the (volatile) memory, in particular the code region of the copy of the executable code segment.

[0111] The random operation can be implemented using one or more implementations. For example, a plurality of addresses in the (volatile) memory storing the copy of the executable code segment can be selected, and a plurality of bytes located at the randomly selected addresses can be excluded and / or discarded. In another example, a plurality of addresses in the (volatile) memory storing the copy of the executable code segment can be selected, and a plurality of bytes located at the randomly selected addresses can be modified, e.g., replaced with bytes containing a specific value, such as 0x00, 0xFF, 0x55, etc. In another example, a plurality of addresses in the (volatile) memory storing the copy of the executable code segment can be selected, and a plurality of predefined data bytes, such as 0x00, 0xFF, 0x55, etc., can be inserted into the randomly selected addresses.

[0112] The verification code segment can be used to apply a unique random operation for each verification session, such that a new verification code segment is generated during each verification session, and the new verification code segment is valid only for the corresponding verification session. The unique random operation and the single-session valid verification code segment can prevent a replay attack initiated by one or more malware that can reside at the protected device 104, which can attempt to replicate and / or mimic the random operation applied in one or more previous verification sessions.

[0113] Thus, the verification code segment is used to calculate the security code after applying the random operation to the target copy of the executable code segment.

[0114] The verification code segment can be used to calculate the security code using one or more methods, techniques, and / or algorithms. For example, the verification code segment can cause one or more hash functions to be executed to calculate a hash value from the copy of the operational version of the executable code segment.

[0115] Optionally, the verification code segment is encoded to further improve the robustness of the verification process against the malware code segment that can infect the protected device 104, since such malware can need to first decrypt the verification code segment before being able to modify the verification code segment and use the verification code segment to generate the same security code as the original and uninfected second copy, thereby hiding the presence of the malware code segment in the protected device 104.

[0116] The verification code segment can be encoded using one or more encoding methods, algorithms, and / or techniques (hereinafter collectively referred to as encoding algorithms), such as White-Box Cryptography (WBC), etc.

[0117] Further, the verification code segment can be encoded using one or more encoding algorithms in accordance with one or more operational parameters of the (target) protected device 104. The encoding algorithms can be selected such that even if the malware residing at the protected device 104 attempts to decrypt the verification code segment in an attempt to modify the verification code segment and generate a valid second security code in accordance with the infected second copy, the computing resources (e.g., processing power, storage resources, etc.) available in the protected device 104 can be insufficient to perform a successful and / or efficient decryption.

[0118] As shown at 206, the security controller 102 executes the verification code segment in order to apply the random operations to a first plurality of bytes in the first copy loaded into the memory and compute a first security code in accordance with the randomly operated first copy.

[0119] For example, the security controller 102 can store the computed first security code in the memory.

[0120] As shown at 208, the security controller 102 transmits the verification code segment to the protected device 104 over one or more networks.

[0121] As shown at 304, the protected device 104 receives the verification code segment from the security controller 102.

[0122] As shown at 306, the protected device 104 executes the received verification code segment in order to compute a second security code in accordance with a second copy of the randomly operated version of the executable code segment, the second copy of the executable code segment being loaded into the memory of the protected device 104.

[0123] The verification code segment executed by the protected device 104 can cause the protected device 104 to compute the second security code after applying the random operations to a second plurality of bytes in the second copy of the executable code segment 420, the second copy of the executable code segment 420 being loaded into the memory of the protected device 104. As the verification code segment is correspondingly configured and / or modified, the random operations applied by the verification code segment to the second plurality of bytes in the second copy are the same as the random operations applied to the first plurality of bytes in the first copy prior to computing the first security code.

[0124] It should be emphasized that the verification code segment is used to cause the protected device 104 to calculate the second security code after randomly operating the second copy of the executable code segment, specifically, operating the second plurality of bytes residing at the randomly selected addresses for the sole purpose of calculating the second security code, without applying the random operation in the actual memory where the second copy of the execution code segment is loaded. For example, the second security code can be calculated using one or more security code calculation functions (e.g., hash functions) that sequentially iterate through the bytes of the second copy loaded into the memory of the protected device 104 and calculate the second security code from the iterated bytes. In this case, the random operation can be dynamically applied during the sequential iteration through the bytes of the second copy, rather than applying the random operation by actually operating the second copy. Likewise, the random operation of excluding, skipping, inserting, duplicating, modifying, etc. the second plurality of bytes residing at the randomly selected addresses can be applied as part of calculating the second security code, without actually modifying the second copy loaded into the memory of the protected device 104. Thus, the second copy of the executable code segment loaded into the memory of the protected device 104 is not affected by the random operation in any way and can be properly executed by the protected device 104.

[0125] As shown at 308, the protected device 104 sends the second security code to the security controller 102.

[0126] Optionally, the protected device 104 can encrypt the second security code using one or more encryption techniques known in the art.

[0127] As shown at 210, the security controller 102 receives the second security code from the protected device 104.

[0128] As shown at 212, the security controller 102 compares the second security code to the first security code; the second security code is received from the protected device 104 and calculated from a second copy of the operating edition, the first security code is calculated from a first copy of the operating edition.

[0129] As shown at 214, this is a conditional step. If the second security code matches (e.g., is identical to) the first security code, the security controller 102 can verify the reliability and integrity of the second copy executed by the protected device 104, and thus can determine that the second copy is valid. In this case, the process 200 can branch to 218. However, if the second security code does not match the first security code, the security controller 102 can determine that the second copy executed by the protected device 104 can be modified and can be infected by one or more malware code segments, and that the protected device 104 can be compromised. In this case, the process 200 can branch to 216.

[0130] As shown at 216, in response to the second security code not matching the first security code (indicating that the protected device 104 can be compromised), the security controller 102 determines that the protected device 104 can be compromised, and can further initiate one or more actions to counter the potential compromise of the protected device 104.

[0131] For example, the one or more actions initiated by the security controller 102 can include sending a warning message of the potential compromise, sending a new copy of the executable code segment to the protected device 104, instructing the protected device 104 to reboot and / or reset, instructing the protected device 104 to disconnect one or more network connections, etc.

[0132] Optionally, the security controller 102 can configure, set, and / or initiate one or more timeout timers loaded with a predefined timeout period to define a time range of the verification session. The security controller 102 can initiate the timeout timer at one or more time points of the verification session, e.g., when sending the verification code segment to the protected device 104 (step 208).

[0133] If the security controller 102 does not receive the second security code from the protected device 104 before the predefined timeout period expires, the security controller 102 can determine that the protected device 104 can be compromised.

[0134] Failing to respond within the predefined period can be largely indicative of the protected device 104 being compromised and infected by one or more malware, as such malware can prevent and / or interfere with the execution of the verification process in order to evade detection.

[0135] Furthermore, the malware could be used to attempt to discover the nature of the random operation and modify the verification code segment to generate a valid second security code for the infected second copy, the second security code being identical to the second security code calculated based on the original, uninfected second copy. However, to determine the random operation, such malware might require significant time and computational resources, which could be limited in the protected device 104. Therefore, the malware might fail to correctly modify the second copy within a sufficient timeframe to respond to the security controller 102 before the predefined timeout period terminates.

[0136] If the verification code segment is encoded within the verification code segment, such malware may require significantly more time to decode and / or reverse the encoded verification code segment and modify the verification code segment accordingly to generate a valid second security code. This can further prevent such malware from generating the second security code within a time period sufficient to respond to the security controller 102 before the predefined timeout period terminates.

[0137] As shown at 218, if the second security code matches the first security code, the security controller 102 can determine that the second copy is valid and does not contain malicious code segments. In this case, the security controller 102 may take no action, or initiate one or more actions (e.g., record the verification session, send one or more verification success messages, etc.) to indicate that the integrity and reliability of the second copy executed by the protected device 104 has been successfully verified.

[0138] refer to Figure 2 The illustration shows a schematic diagram of an exemplary system for protecting a processing device via a security controller, which is provided by some embodiments of the present invention. The security controller is used to verify software code executed by the processing device.

[0139] The exemplary system may include one or more security controllers 152 (e.g., Figure 1 The security controller 102 shown is used to verify the actions of the protected device 154 (e.g., Figure 1 The software code executed by the protected device 104 shown is used to protect one or more protected devices 154.

[0140] The security controller 152 (e.g., a computer, controller, server, computing node, computing node cluster, etc.) may include: a network interface 400 for connecting to the network 150; and a processing circuit 402 for executing... Figure 1The process 200, etc., shown; a memory 404 for storing data and / or programs. The security controller 152 can also include an image memory 406 for storing one or more first copies of one or more executable code segments executed by the protected device 154. Each of the first copies is a verified image of the respective executable code segment that was originally created and verified to be untampered.

[0141] The network interface 400 can include one or more network interfaces for connecting to the network 150, which includes one or more wired and / or wireless networks, such as a Local Area Network (LAN), a Wireless LAN (WLAN), a Wide Area Network (WAN), a Municipal Area Network (MAN), a Radio Frequency (RF) network, a cellular network, the Internet, etc. The security controller 152 can communicate with one or more networked resources connected to the network 150, such as one or more protected devices 154, via the network interface 400.

[0142] The processing circuit 402 can include one or more homogeneous or heterogeneous processors arranged for parallel processing as a cluster and / or as one or more multi-core processing devices. Thus, the processing circuit 402 can execute one or more software modules, such as processes, scripts, applications, agents, utilities, tools, etc.; each software module including a plurality of program instructions stored in the memory 404 or other non-transitory medium (program memory) and executed by one or more processors available in the processing circuit 402.

[0143] The processing circuit 402 can also include one or more hardware elements, such as circuits, components, Integrated Circuits (ICs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), Digital Signals Processors (DSPs), encryption engines, etc.

[0144] The memory 404 can include one or more non-transitory persistent storage devices, such as read only memory (ROM), flash array, hard drive, etc. The memory 404 can include one or more volatile devices, such as random access memory (RAM) component, cache memory, etc. The memory 404 can also include one or more network storage resources, such as a storage server accessible through the network interface 400, network accessible storage (NAS), network drive, cloud storage, etc.

[0145] The image memory 406 can include one or more persistent storage resources for storing one or more local images (copies) of the executable software code executed by one or more protected devices 154. For example, an image of the executable code segment 420 executed by the protected device 154 can be stored in the image memory 406.

[0146] The image memory 406 can also include a secure storage device protected by hardware and / or software means to prevent unauthorized access and thus ensure the reliability and integrity of the stored images. Such secure storage device can include a trusted platform module (TPM) that can be accessed with password protection and / or using a secure protocol, a designated address space, etc.

[0147] Optionally, the image memory 406 is used by one or more attachable storage devices, such as an attachable memory device (e.g., a memory stick), etc., that can be attached to one or more input / output (I / O) interfaces supported by the network interface 400 and / or the security controller 152.

[0148] One or more images stored in the image memory 406, such as the first copy 420A of the executable code segment 420, can be loaded into the memory 404, such as into the volatile memory available in the memory 404.

[0149] The processing circuitry 402 can execute one or more functional modules that can be implemented by one or more software modules, one or more hardware elements, and / or a combination thereof. For example, the processing circuitry 402 can use the functional modules of the session controller 430 to perform Figure 1The process 100 is illustrated and a verification code segment 440 is generated using a functional module of the verification code generator 432, which is used to verify one or more code segments executed by the protected device 154.

[0150] Optionally, the security controller 152 executing the session controller 430 and the verification code generator 432 is implemented as one or more cloud computing services, e.g., Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), etc.

[0151] The protected device 154 (e.g., an IoT device, a sensor, a controller, etc.) can comprise a network interface 410 (e.g., the network interface 400) for connecting to the network 150, a processing circuitry 412 (e.g., the processing circuitry 402) for executing the process 300, and a storage device 414 for storing data and / or programs.

[0152] The network interface 410 can comprise one or more network interfaces for connecting to the network 150, typically a WLAN interface, an RF interface, a cellular interface, etc. wireless interface. The protected device 154 can communicate with one or more networked resources connected to the network 150, e.g., the security controller 152, via the network interface 410.

[0153] The storage 414 can comprise one or more non-transitory persistent storage devices, e.g., a Read Only Memory (ROM), a flash memory array, a hard disk drive, etc. The storage 414 can comprise one or more volatile storage devices, e.g., a RAM component, a cache memory, etc.

[0154] As described for the processing circuitry 402, the processing circuitry 412 can also execute one or more functional modules, which can be implemented by one or more software modules, one or more hardware elements, and / or a combination thereof.

[0155] For example, one or more copies of one or more executable code segments, which can be stored in the storage 414 (typically a persistent (non-volatile) storage), can be loaded and stored into one or more volatile storage devices of the storage 414. For example, a second copy 420B of the executable code segment 420 can be loaded and (temporarily) stored in the storage 414 for execution by the processing circuitry 412.

[0156] The session controller 430 can initiate one or more verification sessions to verify that the second copy 420B of the executable code segment 420, which is locally stored in the memory 414 of the protected device 154 and executed by the processing circuitry 412 of the protected device 154, is not infected by one or more malicious malware code segments. The session controller 430 can initiate the verification sessions periodically, continuously, and / or on-demand, i.e., upon a trigger by one or more automated tools and / or operators.

[0157] The session controller 430 can initiate the verification sessions by loading the first copy 420A of the executable code segment 420, which is configured to be executed by the protected device 154. The session controller 430 can load the first copy 420A from the image memory 406 into the memory 404, in particular into the volatile memory of the memory 404. The session controller 430 can be configured to load the first copy 420A into the memory 404. However, the session controller 430 can be configured to instruct, invoke, and / or use one or more loading program agents, tools, and / or applications executed by the processing circuitry 402 to load the first copy 420A into the memory 404.

[0158] The session controller 430 can further initiate, invoke, and / or execute the verification code generator 432 to generate the verification code segment 440.

[0159] The verification code generator 432 can configure and / or modify the verification code segment 440 so as to compute a security code from a copy of the executable code segment 420 when the copy of the executable code segment 420 is loaded into the memory, in particular the volatile memory, e.g., the first copy 420A of the executable code segment 420 loaded into the memory 404 of the security controller 152 and / or the second copy 420B of the executable code segment 420 loaded into the memory 414 of the protected device 154. Moreover, as the code region executed by the processing circuitry 412 can generally be the segment that can contain the malware code in case of infection by one or more malware, the verification code segment 440 can be configured to compute the security code from the code region (code segment) of the executable code segment copy.

[0160] However, in case the protected device 154 is infected with one or more malware code segments, these malware can be used to modify the second copy 420B so that the security code computed from the infected second copy 420B is the same as the security code computed from the original and uninfected second copy 420B.

[0161] To improve the robustness of the verification process against the malware code segments that can be executed by the protected device 154, the verification code generator 432 can configure and / or modify the verification code segment 440 so as to compute the security code from the copy of the executable code segment 420 after applying the random operation on the copy of the executable code segment 420.

[0162] Thus, even if the protected device 154 is infected with malware, such malware can not be able to modify the verification code segment 440 so that the security code computed from the infected second copy 420B matches the security code computed from the original and uninfected second copy 420B.

[0163] The verification code generator 432 can configure and / or modify the verification code segment 440 to apply the random operation on a plurality of bytes that are randomly selected in the copy of the executable code segment 420 loaded into the volatile memory. In particular, the random operation is applied on the bytes at randomly selected addresses in the address range occupied by the copy of the executable code segment 420 in the volatile memory, in particular the code section of the executable code segment copy.

[0164] The random operation can be implemented using one or more implementations. For example, the verification code segment 440 can be used to randomly select a plurality of addresses in the volatile memory storing the copy of the executable code segment 420 and exclude (discard) the bytes at the randomly selected addresses. In another example, the verification code segment 440 can be used to randomly select a plurality of addresses in the volatile memory storing the copy of the executable code segment 420 and modify the bytes at these addresses, e.g., replace the byte data with specific values such as 0x00, 0xFF, 0x55, etc. In another example, the verification code segment 440 can be used to randomly select a plurality of addresses in the volatile memory storing the copy of the executable code segment 420 and insert predefined data bytes such as 0x00, 0xFF, 0x55, etc. into these randomly selected addresses.

[0165] The verification code generator 432 can configure and / or modify the verification code segment 440 to apply a unique random operation for each verification session, such that the new verification code segment 440 generated during each verification session is valid only for the corresponding verification session. The unique random operation and the single-session valid verification code segment 440 can prevent a replay attack initiated by one or more malware that can reside at the protected device 154, which can attempt to replicate and / or mimic the random operation applied in one or more previous verification sessions.

[0166] Accordingly, the verification code segment 440 is configured to calculate the security code after applying the random operation on the target copy of the executable code segment 420.

[0167] The verification code segment 440 can be configured to calculate the security code using one or more methods, techniques, and / or algorithms. For example, the verification code segment 440 can be configured to execute one or more hash functions to calculate a hash value from the copy of the operational version of the executable code segment 420.

[0168] Optionally, the processing circuitry 402 executing the verification code generator 432 can encode the verification code segment 440. This can further improve the robustness of the verification process against the malware code segments that can infect the protected device 154, since such malware can need to first decrypt the verification code segment 440 before it can modify the verification code segment 440 to generate the same security code as calculated from the original and uninfected second copy 420B.

[0169] The verification code segment 440 can be encoded using one or more encoding methods, algorithms, and / or techniques, such as White-Box Cryptography (WBC) and / or the like.

[0170] Furthermore, the verification code segment 440 can be encoded using one or more encoding algorithms in accordance with one or more operational parameters of the (target) protected device 154. The encoding algorithm can be selected such that even if the malware residing at the protected device 154 attempts to decrypt the randomly selected address in an attempt to modify the infected second copy 420B to generate a valid security code, the computing resources (e.g., processing power, storage resources, and / or the like) available at the protected device 154 can be insufficient for a successful and / or efficient decryption.

[0171] The session controller 430 can cause the processing circuitry 402 to execute the verification code segment 440 generated by the verification code generator 432 in order to apply the random operations to a first plurality of bytes in the first copy 420A loaded into the memory 404 and to compute a first security code from the randomly operated version of the first copy 420A.

[0172] For example, the session controller 430 can store the computed first security code in the memory 404.

[0173] Optionally, the session controller 430 can cause the processing circuitry 402 to apply the random operations to the first copy 420A loaded into the memory 404 and to compute the first security code from the operated version of the first copy 420. Then, the session controller 430 can cause the processing circuitry 402 to initiate the verification code generator 432 to generate the verification code segment 440 for applying the same random operations to the first copy 420A by executing the processing circuitry 402 of the session controller 430 and to compute the security code from the operated version of the copy of the executable code segment 420.

[0174] The session controller 430 can send the verification code segment 440 to the protected device 154 via the network 150.

[0175] The protected device 154, in particular the processing circuitry 412, can execute the verification code segment 440 received from the security controller 152 in order to compute a second security code from the randomly operated version of the second copy 420B of the executable code segment.

[0176] The verification code segment 440 can cause the processing circuitry 412 to first apply the random operations to a second plurality of bytes in the second copy 420B of the executable code segment 420 loaded into the memory 414 and possibly executed by the processing circuitry 412. Due to the verification code segment 440 being correspondingly configured and / or modified, the random operations applied by the processing circuitry 412 executing the verification code segment 440 to the second plurality of bytes in the second copy 420B are similar (identical) to the random operations applied to the first plurality of bytes in the first copy 420A prior to computing the first security code.

[0177] The processing circuitry 412 can use the verification code segment 440 for computing the second security code from the second copy 420B of the operational version in the same way that the first security code is computed from the first copy 420A of the operational version.

[0178] It should be emphasized that the verification code segment 440 can cause the processing circuitry 412 to compute the second security code after randomly operating the second copy 420B, specifically, to operate the second plurality of bytes residing at the randomly selected addresses only for the purpose of computing the second security code, without actually applying that operation in the memory 414 loaded with the second copy 420B. For example, the second security code can be computed using one or more security code computation functions (e.g., hash functions) that sequentially iterate through the bytes of the second copy 420B loaded into the memory 414 and compute the second security code from the iterated bytes. In this case, the random operations can be dynamically applied during the sequential iteration through the bytes of the second copy 420B, rather than by actually operating the second copy 420B. Likewise, the random operations of exclusion, skipping, insertion, duplication, modification, etc. can be applied to the second plurality of bytes residing at the randomly selected addresses of the second copy 420B as part of computing the security code, without actually modifying the second copy 420B loaded into the memory 414. Thus, the second copy 420B loaded into the memory 414 is not affected by the random operations in any way and can be executed correctly by the processing circuitry 412.

[0179] The protected device 154 can send the second security code to the security controller 152.

[0180] Optionally, the protected device 154 can encrypt the second security code using one or more encryption techniques known in the art.

[0181] The security controller 152, specifically the processing circuitry 402 executing the session controller 430, can receive the second security code from the protected device 154.

[0182] The session controller 430 can cause the processing circuitry 402 to mutually compare the second security code received from the protected device 154 and computed from the second copy 420B of the operational version, and the first security code computed from the first copy 420A of the operational version.

[0183] If the second security code matches (e.g., is the same as) the first security code, the session controller 430 can cause the processing circuitry 402 to verify the reliability and integrity of the second copy 420B executed by the protected device 154, and thus can determine that the second copy 420B is valid. However, if the second security code does not match the first security code, the session controller 430 can cause the processing circuitry 402 to determine that the second copy 420B executed by the protected device 154 can be modified and can be infected by one or more malware code segments, and that the protected device 154 can be compromised.

[0184] In response to the second security code not matching the first security code (indicating that the protected device 154 can be compromised), the session controller 430 can cause the processing circuitry 402 to further initiate one or more actions to counteract the compromise that the protected device 154 can be subject to. For example, the actions initiated by the processing circuitry 402 executing the session controller 430 can include sending a warning message of the potential compromise, sending a new copy of the executable code segment 420 to the protected device 154, instructing the protected device 154 to restart and / or reset, instructing the protected device 154 to disconnect from the network 150, and the like.

[0185] Optionally, the session controller 430 can cause the processing circuitry 402 to configure, set, and / or initiate one or more timeout timers loaded with a predefined timeout period to define a time range for the verification session. The session controller 430 can cause the processing circuitry 402 to initiate the timeout timer at one or more time points of the verification session, e.g., when the verification code segment 440 is sent to the protected device 154.

[0186] If the processing circuitry 402 executing the session controller 430 does not receive the second security code from the protected device 154 before the predefined timeout period expires, the session controller 430 can cause the processing circuitry 402 to determine that the protected device 154 can be compromised.

[0187] If the second security code matches the first security code, the session controller 430 can cause the processing circuitry 402 to determine that the second copy 420B is likely valid and does not contain malicious code segments. In this case, the session controller 430 can cause the processing circuitry 402 to take no action, or initiate one or more actions (e.g., record the verification session, send one or more verification success messages, etc.) to indicate that the integrity and reliability of the second copy 420 executed by the protected device 154 has been successfully verified.

[0188] For reference Figure 3A and Figure 3B The illustration shows exemplary sequences for protecting a processing device via a security controller, provided by some embodiments of the present invention. The security controller is used to verify software code executed by the protected processing device. The exemplary code verification sequence 500 can be generated by a security controller (e.g., Figure 2 The safety controller 152 shown) and the protected device (e.g., Figure 2 The protected device 154 shown executes the verification of the integrity and reliability of one or more copies of the executable code segment (e.g., the second copy 420B of the executable code segment 420 executed by the protected device 154).

[0189] The security controller 152 (specifically the processing circuit 402) can execute one or more functional modules, which are implemented and / or used through one or more software modules, one or more hardware elements, and / or combinations thereof. For example, the processing circuit 402 can execute a scheduler 502 for scheduling one or more verification sessions to verify the second copy 420B of the executable code segment 420 executed by the protected device 154, the session controller (e.g., the session controller 430), and the verification code generator (e.g., the verification code generator 432).

[0190] The protected device 154 (specifically the processing circuit 412) may also execute one or more functional modules, which are implemented and / or utilized through one or more software modules, one or more hardware elements, and / or combinations thereof. For example, the processing circuit 412 may execute a code loader 510 to load one or more code segments from the memory (e.g., the memory 414) of the protected device 154, as well as verification code segments (e.g., the verification code segment 440 generated by the verification code generator 432).

[0191] The verification sequence 500 begins with the scheduler 502 triggering the session controller 430 at 602, which causes the processing circuitry 402 to initiate a code verification session. The scheduler 502 triggers one or more verification sessions periodically, continuously, and / or in response to one or more requests received from one or more automation tasks, through one or more initiation messages received at the security controller 152, and / or in response to one or more operator manual triggers.

[0192] At 612, in response to the trigger at 602, the session controller 430 causes the processing circuitry 402 to initiate the code verification session. The session controller 430 causes the processing circuitry 402 to first load a first copy of the executable code segment into memory (e.g., the memory 404), which is stored (as shown at 632) in an image cache device (e.g., the image memory 406). The first copy is a verified image of the executable code segment that is verified to be authentic and unaltered.

[0193] The session controller 430 also causes the processing circuitry 402 to perform the following steps.

[0194] As shown at 622, a plurality of addresses are randomly selected within an address range of the memory 404 into which the first copy of the executable code segment is loaded. According to one example, this is performed as described in step 202 of the process 200. The verification code segment 440 is then generated to compute a security code from the executable code segment after operating on the first plurality of bytes at the randomly selected addresses, as shown at 624. According to one example, this is performed as described in step 204 of the process 200. As shown at 626, the generated verification code segment 440 is executed to compute the first security code from the first copy loaded into the memory. According to one example, this is performed as described in step 206 of the process 200. Optionally, the verification code segment 440 can be encoded, as shown at 628.

[0195] As previously described, the verification code segment 440 is used to cause the processing circuitry 402 to compute the security code using one or more methods, techniques, and / or algorithms. For example, the verification code segment 440 causes the processing circuitry 402 to use one or more hash functions to compute a first hash value from the first copy, which can be used as the first security code for the first copy.

[0196] The session controller 430 causes the processing circuitry 402 to receive and store the computed first security code (e.g., first hash value), as shown at 614. According to one example, this operation is performed as described in step 206 of the process 200.

[0197] The session controller 430 causes the processing circuitry 402 to send the verification code segment 440 to the protected device 154, as shown at 616. According to one example, this operation is performed as described in step 208 of the process 200.

[0198] The protected device 154 receives the verification code segment 440 from the security controller 152. According to one example, this operation is performed as described in step 304 of the process 300. Upon receiving the verification code segment 440 from the security controller 152, the protected device 154 (and specifically the processing circuitry 412) can initiate the code loader 510 to load (as shown at 644 in FIG. 6B) the verification code segment 440 into the memory for execution by the processing circuitry 412. If the verification code segment 440 is encoded by the processing circuitry 402 of the security controller 152, the processing circuitry 412 can first decode and / or invert the encoded verification code segment 440 before loading the verification code segment 440 into the memory. Figure 3B

[0199] Upon loading the verification code segment 440, the processing circuitry 412 executes the verification code segment 440 to compute a second security code (e.g., second hash value) from the second copy loaded into the memory of the protected device 154 after operating on the second plurality of bytes residing at the randomly selected address, as shown at 652. According to one example, this operation is performed as described in step 306 of the process 300.

[0200] The protected device 154 sends the second security code (e.g., second hash value) to the security controller 152, as shown at 654. According to one example, this operation is performed as described in step 308 of the process 300.

[0201] ​As shown at 618, after receiving the second security code (e.g., the second hash value) from the protected device 154, the session controller 430 causes the processing circuit 402 to mutually compare the second security code (e.g., the second hash value) with the first security code (e.g., the first hash value); the second security code is computed from the second copy, and the first security code is computed from the first copy. According to one example, this operation is performed as described in step 214 of the process 200.

[0202] As shown at 620, if the second security code (e.g., the second hash value) matches the first security code (e.g., the first hash value), the session controller 430 causes the processing circuit 402 to determine that the second copy is valid and not infected by a malicious code segment (normal). According to one example, this operation is performed as described in step 218 of the process 200.

[0203] However, as shown at 619, in response to the second security code (e.g., the second hash value) not matching the first security code (e.g., the first hash value), the session controller 430 causes the processing circuit 402 to determine that the protected device 154 can be compromised, and further causes the processing circuit 402 to initiate one or more actions to counteract the compromise of the protected device 154. According to one example, this operation is performed as described in step 216 of the process 200.

[0204] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any implementation described as "exemplary" is not necessarily to be construed as preferred or advantageous over other implementations.

[0205] The word "optionally" is used herein to mean "may or can not be present." Any particular embodiment of the application can include a plurality of the "optional" features, unless such features conflict.

[0206] It should be understood that some features of the application described in the context of separate embodiments can be provided in a combined embodiment. Conversely, various features of the application described in the context of a combined embodiment can also be provided in separate embodiments. Certain features described in the context of various embodiments are not to be construed as essential features of those embodiments, unless explicitly stated otherwise.

[0207] While the application has been described in connection with specific embodiments thereof, it will be understood that many modifications, substitutions and changes will be apparent to those skilled in the art in light of the foregoing description. Accordingly, it is intended to embrace all alternatives, modifications and variations to the claimed application within the scope of the appended claims.

Claims

1. A safety controller, characterized by, comprising: a memory; circuitry to: load a first copy of an executable code segment into the memory; compute a first secure code from a randomly operated first copy of the executable code segment; generate a verification code segment for causing a protected device to compute a second secure code from a randomly operated second copy of the executable code segment after the randomly operated second copy of the executable code segment is loaded into a memory of the protected device; send the verification code segment to the protected device; receive the second secure code from the protected device; compare the first secure code and the second secure code; determine a compromise suffered by the protected device in response to the second secure code not matching the first secure code; the randomly operating comprises: randomly selecting addresses of a first plurality of bytes in the first copy of the executable code segment; to compute the first secure code, modifying the first plurality of bytes residing at the randomly selected addresses in the first copy of the executable code segment, or randomly inserting the first plurality of bytes residing at the randomly selected addresses into the first copy of the executable code segment.

2. The safety controller of claim 1, wherein, the circuitry is further to compute a hash value from the first copy of the executable code segment using at least one hash function; the first secure code comprises the hash value.

3. The safety controller of claim 1, wherein, the circuitry is further to encode the verification code segment.

4. The safety controller of claim 3, wherein, the circuitry is further to encode the verification code segment with white-box cryptography.

5. The safety controller according to any one of claims 1 to 4, characterized in that the circuitry is further to perform a verification session to verify the executable code segment; the randomly operating is unique to the verification session such that the verification code segment generated during the verification session is valid only for the verification session.

6. The safety controller according to any one of claims 1 to 4, characterized in that the circuitry is further to initiate an action in response to not receiving the second secure code from the protected device before expiration of a predefined timeout period.

7. The safety controller of claim 6, wherein, the initiated action comprises at least one of: sending a warning message of the compromise; sending a new copy of the executable code segment to the protected device; instructing the protected device to restart; instructing the protected device to disconnect from at least one network.

8. A computer-implemented method for detecting a protected device that can be subject to harm, the method comprising: comprising: loading a first copy of an executable code segment into a memory of a secure controller; computing a first secure code from a randomly operated first copy of the executable code segment; generating a verification code segment for causing a protected device to compute a second secure code from a randomly operated second copy of the executable code segment after the randomly operated second copy of the executable code segment is loaded into a memory of the protected device; sending the verification code segment to the protected device; receiving the second secure code from the protected device; comparing the first secure code and the second secure code; in response to the second security code not matching the first security code, determining that the protected device is compromised; the random operation comprising: randomly selecting an address of a first plurality of bytes in the first copy of the executable code segment; to compute the first security code, modifying the first plurality of bytes residing at the randomly selected address in the first copy of the executable code segment, or randomly inserting the first plurality of bytes residing at the randomly selected address into the first copy of the executable code segment.

9. A protected device, characterized by comprising: a memory; circuitry to: load a copy of an executable code segment into the memory; receive a verification code segment from a security controller, the verification code segment to cause the protected device to compute a second security code from a second copy of a random operation of the executable code segment; execute the verification code segment; compute the second security code from the second copy of the random operation of the executable code segment; send the second security code to the security controller; the second security code to cause the security controller to compare a first security code and the second security code, and in response to the second security code not matching the first security code, determine that the protected device is compromised; the first security code to be computed by the security controller from a first copy of the random operation of the executable code segment; the random operation comprising: randomly selecting an address of a second plurality of bytes in the second copy of the executable code segment; to compute the second security code, modifying the second plurality of bytes residing at the randomly selected address in the second copy of the executable code segment, or randomly inserting the second plurality of bytes residing at the randomly selected address into the second copy of the executable code segment.

10. The protected device of claim 9, wherein, the circuitry to further compute a hash value from the copy of the executable code segment using at least one hash function; the security code to comprise the hash value.

11. The protected device according to claim 9 or 10, characterized in that, the random operation comprising: randomly selecting an address of a plurality of bytes in the copy of the executable code segment; excluding the plurality of bytes residing at the randomly selected address from the copy of the executable code segment.

12. A computer-implemented method for detecting a compromise of a protected device, the method comprising: the method comprising: loading a copy of an executable code segment into a memory of a protected device; receiving a verification code segment from a security controller, the verification code segment to cause the protected device to compute a second security code from a second copy of a random operation of the executable code segment; executing the verification code segment; computing the second security code from the second copy of the random operation of the executable code segment; sending the second security code to the security controller; the second security code being configured to cause the security controller to compare the first security code and the second security code, and in response to the second security code not matching the first security code, determine that the protected device is subject to a compromise; the first security code being computed by the security controller from the first copy of the randomly manipulated executable code segment; the randomly manipulating comprises: randomly selecting addresses of a second plurality of bytes in the second copy of the executable code segment; and in order to compute the second security code, modifying the second plurality of bytes residing at the randomly selected addresses in the second copy of the executable code segment, or randomly inserting the second plurality of bytes residing at the randomly selected addresses into the second copy of the executable code segment.

13. A computer readable medium characterized by instructions executable by a computer, which upon execution by the computer, cause the computer to perform the method according to claim 8 or 12. instructions executable by a computer, which upon execution by the computer, cause the computer to perform the method according to claim 8 or 12.

Images