Patent Description:
With the constant and rapid evolution of technology, automation has penetrated practically every aspect of modem life. One of the most rapidly spreading trends is the deployment of Internet of Things (IoT) devices, sensors, controllers, and/or the like, for numerous applications.

By their very nature, in order to effectively meet the applicative requirements, most, if not all IoT devices, are engineered with challenging limits in terms of power, performance, cost, etc..

Such IoT devices may typically be low-end devices, which are very limited in their computing resources, for example, in their processing power, storage resources, communication resources, and/or the like.

While the computing resources available to the IoT devices are scarce, thereby making their security fragmented at best, these IoT devices, which are often barely maintained and communicate over relaxed networks, may often be exposed to a wide number of network-originated malicious attacks.

The IoT devices may be protected by deploying software integrity protection measures which may be applied at rest, i.e., verify integrity of software stored on a disk, flash, etc., and in transition during download or upload. Popular software (SW) distribution packages such as, for example, open Secure Sockets Layer (SSL) designed for IoT devices may, therefore, include tools and libraries for SW encryption, signing, hashing, etc., to support file integrity protection at rest, in transfer, as well as checks during loading.

However, many of the network-originated malicious attacks are based on malicious agents (malware, virus) which are injected to the attacked device(s), in order to implement malicious functionality by modifying, in runtime, software code segments executed by the processing device, for example, software, firmware, middleware. Such runtime attacks may be known as software (SW)/firmware (FW) tampering.

Due to the very limited computing resources available in the IoT devices, securing and protecting low-end devices with limited computing resources against runtime tampering malicious attacks may present a major challenge and is, therefore, considered difficult and relatively expensive.

<CIT> relates to method for remotely verifying software integrity. <CIT> relates to method of detecting malicious code. <CIT> relates to verify command for a peripheral device. <CIT> relates to method and device for detecting software-tampering. <CIT> relates to server and method for attesting application in smart device using random executable code. <CIT> relates to server and method for attesting application in smart device using random executable code.

<NPL>, relates to securing edge devices in smart grid.

<NPL>, relates to proactive code verification protocol in wireless sensor network.

<NPL>, relates to software-based attestation of embedded devices.

<NPL>, relates to tamper-proof code execution on legacy systems.

<NPL>, relates to soft tamper-proofing via program integrity verification in wireless sensor networks.

An objective of the embodiments of the present disclosure is to provide a solution which mitigates or solves the drawbacks and problems of conventional solutions.

The present disclosure aims at providing a solution for protecting devices, specifically low-end devices with limited resources, by deploying a security controller operatively connected to the protected devices via a network for verifying an integrity and reliability of executable software code executed by the protected devices.

According to a first aspect of the present disclosure, there is provided a security controller comprising a memory and circuitry, the circuitry configured to:.

According to a second aspect of the present disclosure, there is provided a computer-implemented method of detecting a potentially compromised protected device, comprising:.

According to a third aspect of the present disclosure, there is provided a protected device, comprising a memory and circuitry, the circuitry configured to:.

According to a fourth aspect of the present disclosure, there is provided a computer-implemented method of detecting a potential compromise at a protected device, comprising:.

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

According to the claimed disclosure, the generated verification code segment is adapted such that the random manipulation applied by the verification code segment to the second plurality of bytes in the second copy is identical to the random manipulation applied to the first plurality of bytes in the first copy before computing the first security code.

The protected device may be a low-end device having limited resources, which may present major limitations in its ability to prevent malicious malware from infiltrating into its memory and executing in an attempt to compromise the protected device. Deploying the security controller to protect the low-end device may require the protected device to execute a relatively simple process, thus significantly reducing the computing resources required at the protected device. As such, the use of the security controller may be highly suitable for protecting low-end devices which may be effectively protected regardless of their limited computing resources. Moreover, reducing the computing resources required for their protection may further reduce a cost and/or complexity of the protected device. Furthermore, by computing the second security code for the randomly manipulated version of the copy of the executable code segment, malware(s) infecting the second copy of the executable code segment executed by the protected device may be unable to discover the random manipulation, in order to successfully alter the verification code segment to compute a valid second security code for the infected second copy. This advantage may be highly amplified for the low-end protected devices, since the computations of the malware(s), in attempting to discover the random manipulation, may require significant computing resources which may be unavailable in the low-end protected devices with limited resources. It should be noted that the random manipulation of the first and second copies of the executable code segment, specifically the random manipulation of the first and second plurality of bytes, is only done as part of the computation of the first and second security codes, respectively, and is not actually applied in the memory of the security controller and the memory of the protected device, respectively, where the first and second copies of the executable code segment are loaded. Therefore, the loaded copies of the executable code segment are not affected in any way by the random manipulation and may be correctly executed.

In a further implementation form of the first, second, and/or fifth aspects of the present disclosure, a hash value is computed based on the first copy of the executable code segment using at least one hash function, wherein the first security code comprises the hash value. Hash values are highly effective for computing a limited length fixed size string for the copies of the executable code segment and are, therefore, commonly used for a plurality of applications. Moreover, the hash functions are one-way functions, such that it is impossible to recover the input to the hash function, i.e., the executable code segment from the output hash value.

In a further implementation form of the first, second, and/or fifth aspects of the present disclosure, the random manipulation comprises randomly selecting an address of a first plurality of bytes in the first copy of the executable code segment and excluding, for the computation of the first security code, the first plurality of bytes residing at the randomly selected address from the first copy of the executable code segment. By excluding (skipping) bytes of data residing at the randomly selected address, it may be highly difficult and perhaps even impossible for malware(s) potentially residing in the memory of the protected device to discover the random manipulation and produce a valid second security code accordingly. This implementation has not been claimed as such.

According to the claimed disclosure, the random manipulation comprises randomly selecting an address of a first plurality of bytes in the first copy of the executable code segment and altering, for the computation of the first security code, the first plurality of bytes residing at the randomly selected address in the first copy of the executable code segment. By altering data of bytes residing at the randomly selected address, it may be highly difficult and perhaps impossible for malware(s) potentially residing in the memory of the protected device to discover the random manipulation and produce a valid second security code accordingly; or
the random manipulation comprises selecting an address of a first plurality of bytes and randomly inserting, for the computation of the first security code, the first plurality of bytes residing at the randomly selected address into the first copy of the executable code segment. By inserting additional data bytes at the randomly selected address, it may be highly difficult and perhaps impossible for malware(s) potentially residing in the memory of the protected device to discover the random manipulation and produce a valid second security code accordingly.

In an optional implementation form of the first, second, and/or fifth aspects of the present disclosure, the verification code segment is encoded. Encoding the verification code segment may dramatically increase the challenge for the malware(s) to obtain the verification code segment, since decoding or reversing the encoded verification code segment may require extensive computing resources, which may be unavailable in the protected device, thereby making it unfeasible for the malware(s) to recover the random manipulation and maliciously use it in an attempt to disguise its presence.

In an optional implementation form of the first, second, and/or fifth aspects of the present disclosure, white-box cryptography is applied to encode the verification code segment. White-Box Cryptography (WBC), as known in the art, is widely used for software protection applications. Since WBC implements a cryptographic software algorithm in such a way that cryptographic assets remain secure even when subject to white-box attacks by malware(s), WBC is highly suitable and effective for encoding the verification code segment.

In a further implementation form of the first, second, and/or fifth aspects of the present disclosure, a verification session is performed to verify the executable code segment, wherein the random manipulation is unique for the verification session, such that the verification code segment generated during the verification session is valid only for the verification session. The random manipulation and, hence, the verification code segment being unique and valid for only a single verification session may render useless verification code segment(s) generated in previous verification sessions, thereby making the random manipulation highly robust and immune to replay attacks.

In an optional implementation form of the first, second, and/or fifth aspects of the present disclosure, an action is initiated in reaction to the second security code not being received from the protected device before expiration of a predefined timeout period. Applying the timeout mechanism may form another major hurdle for the malware(s), which, in order to successfully avoid detection, may need to discover the random manipulation and alter the second copy accordingly within the predefined timeout period, which is the time frame defined for the verification session.

In a further implementation form of the first, second, and/or fifth aspects of the present disclosure, the initiated action comprises at least one of transmitting an alert message of the compromise, transmitting a new copy of the executable code segment to the protected device, instructing the protected device to reboot, and instructing the protected device to disconnect from at least one network. Selecting one or more actions initiated in response to a detected compromise of the protected device may allow for high flexibility in the measures applied to counter the possible malicious attack. The action may, thus, be selected according to various aspects, characteristics and/or attributes of the detected attack, for example, attributes and/or operational parameters of the protected device, the nature and/or criticality of the application (executable code segment) executed by the protected device, the type of the detected potential attack, and/or the like.

In a further implementation form of the third, fourth, and/or fifth aspects of the present disclosure, a hash value is computed based on the copy of the executable code segment using at least one hash function, wherein the security code comprises the hash value. As stated herein before, hash values are highly effective for computing a limited length fixed size string for the copies of the executable code segment and are, therefore, commonly used for a plurality of applications. Moreover, the hash functions are one-way functions, such that it is impossible to recover the input to the hash function, i.e., the executable code segment from the output hash value.

In a further implementation form of the third, fourth, and/or fifth aspects of the present disclosure, the random manipulation comprises randomly selecting an address of a plurality of bytes in the copy of the executable code segment and excluding the plurality of bytes residing at the randomly selected address from the copy of the executable code segment. As described herein before, excluding (skipping) bytes of data residing at the randomly selected address may make it highly difficult and perhaps impossible for malware(s) potentially residing in the memory of the protected device to discover the random manipulation and produce a valid second security code accordingly.

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 present disclosure pertains. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the present disclosure, exemplary methods and/or materials are described below.

An implementation of the method and/or system of embodiments of the present disclosure can involve performing or completing selected tasks automatically. Moreover, according to actual instrumentation and equipment of embodiments of the method and/or system of the present disclosure, several selected tasks could be implemented by hardware, by software or by firmware or by a combination thereof using an operating system.

For example, hardware for performing selected tasks according to embodiments of the present disclosure could be implemented as a chip or a circuit. As software, selected tasks according to embodiments of the present disclosure could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In an exemplary implementationof the present disclosure, one or more tasks according to exemplary embodiments of the method and/or system as described herein are performed by a data processor, such as a computing platform for executing a plurality of instructions. Optionally, the data processor 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 for storing instructions and/or data.

Some embodiments of the present disclosure 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 are shown by way of example and for purposes of illustrative discussion of embodiments of the present disclosure. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the present disclosure may be practiced.

The present disclosure, in some embodiments thereof, relates to protecting processing devices against malicious attacks, and, more specifically, but not exclusively, to protecting processing devices against malicious attacks using a security device deployed to verify software code executed by the protected processing devices.

According to some embodiments of the present disclosure, there are provided methods, devices and computer program products for verifying an integrity and reliability of executable software code executed by processing devices, in order to protect the processing devices against malicious attacks initiated by infecting malware and executing at the protected devices in an attempt to compromise the protected devices.

Protection of the devices is based on a security controller deployed to verify one or more software code segments, for example, an application, a process, a utility, a tool, a procedure, an agent, a script and/or the like which are typically executed by the protected devices having network connectivity and capable of communicating with the security controller.

In particular, the protected devices may be low-end devices with limited resources such as, for example, Internet of Things (IoT) devices, sensors, controllers and/or the like comprising limited computing resources, for example, processing resources, storage resources, communication resources, and/or the like.

The security controller may generate a verification software code segment, which is adapted to cause a processing circuit to compute a security code (e.g. a hash value, etc.) for a copy of an executable code segment stored and executed by one or more of the protected devices.

The security controller may locally store and/or have access to a first copy of the executable code segment targeting the protected device(s), which is a validated image of the executable code segment verified to be genuine as originally created and untampered. The first copy may be stored in one or more secure storage resources which may be protected using hardware and/or software means, for example, a Trusted Platform Module (TPM), an Enclave, and/or the like, which may be password-protected, and/or accessed using secure protocol(s).

The security controller may, therefore, load the first copy of the executable code segment into its local memory (e.g., volatile memory) and execute the verification code segment to compute a first security code for the first copy loaded in the memory.

The security controller may further transmit the verification code segment to one or more of the protected devices, which execute a second copy of the executable code segment locally stored and loaded in their local memory.

Each of the protected devices may execute the received verification code segment to compute a second security code for their second copy of the executable code segment and may transmit the computed second security code to the security controller.

The security controller may then compare the second security code computed for the second copy of the executable code segment at the protected device and the first security code computed for the first copy of the executable code segment securely stored by the security controller. In case of a match, the security controller may determine that the second copy is a genuine copy of the executable code segment, since it matches the first copy being the validated image of the executable code segment.

However, in case of no match, the security controller may determine that the second copy may be potentially infected with one or more malware code segments which have been injected and/or infiltrated in the second copy, thus compromising the protected device. In such a case, the security controller may initiate one or more actions, in order to counter the potential compromise of the protected device, for example, transmit an alert message of the potential compromise, transmit 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 the network, and/or the like.

Some malware code segments, which may infect the protected device, may be designed and/or configured to disguise their presence by altering the second copy of the executable code segment in a way that computing the security code for the altered infected second copy is identical to the security code, which would be computed for the original and uninfected second copy.

In order to increase an immunity of the verification process against such malware(s), the security controller may configure and/or adapt the verification code segment to cause computation of the security code for a randomly manipulated version of the copy of the executable code segment, such that the security code is computed after applying a random manipulation to the executable code segment copy.

The random manipulation is based on randomly selecting a plurality of addresses in an address range occupied by the copy of the executable code segment in the memory and manipulating the bytes at these randomly selected addresses in one or more ways. For example, a plurality of bytes residing at the randomly selected addresses may be excluded (discarded) for the computation of the security code. This implementation has not been claimed as such.

According to the claimed disclosure, the data of a plurality of bytes residing at the randomly selected addresses is altered (e.g. nullified, filled with a predefined pattern, etc.) for the computation of the security code. Alternatively, according to the claimed disclosure, the additional bytes with a predefined pattern may be inserted at the randomly selected addresses for the computation of the security code.

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 done only for the computation of the security code and is not actually applied in the memory, where the copy of the executable code segment is loaded. For example, the security code may be computed using one or more security code computation functions which sequentially traverse the bytes of the executable code segment loaded in memory and compute the security code accordingly. In such a case, the random manipulation may be applied on the fly rather than by actually manipulating the executable code segment in the memory during the sequential traversing of the bytes of the executable code segment. As such, the random manipulation, for example, excluding, skipping, inserting, duplicating, altering the plurality of bytes at the randomly selected addresses may be done as part of the security code computation without actually altering the copy of the executable code segment loaded in the memory. Therefore, the loaded copy of the executable code segment is not affected in any way and may correctly execute.

Therefore, even if the protected device is infected with malware(s), these malware(s) may be unable to discover the random manipulation and, hence, may be unable to alter the verification code segment to compute the second security code for the infected second copy to match the first security code computed for the manipulated version of the original and uninfected first copy. The security controller may, therefore, detect that the protected device is potentially infected by malware(s) and is, hence, compromised.

The random manipulation applied in each verification session and, hence, the verification code segment generated in each verification session are unique and different from those applied and generated in any other verification session.

Optionally, in order to further increase a security of the verification process and prevent the malicious malware(s) from obtaining the verification code segment, the security controller may encrypt the verification code segment. The verification code segment may be encoded using one or more encoding methods, algorithms and/or technologies. According to a preferred implementationof the present disclosure, White-Box Cryptography (WBC) is a particularly suitable encoding method.

Encoding the verification code segment may further prevent the malware(s) from recovering and obtaining the verification code segment and may, thus, further improve the security of the code verification process against the malware(s) which may infect the protected devices.

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

Protecting the processing devices by verifying the randomly manipulated version of the software code copies executed by the processing devices may present major advantages and benefits compared to existing methods and systems for protecting such devices.

Firstly, since the protected devices may be low-end devices with limited computing resources, such limited resources devices may be incapable to efficiently and effectively execute software integrity protection measures such as, for example, Trusted Execution Environments (TEE), dedicated watchdogs, run time check procedures (e.g. anti-malware, anti-viruses, etc.) and/or the like, as may be done by the existing methods. These software integrity protection measures employed by the existing methods may present major limitation for deployments in the protected devices with limited resources due to one or more reasons. For instance, they require extensive computing resources, and/or dedicated hardware elements, have a major footprint (memory space during runtime), alter execution priorities, and/or the like. Such software integrity protection measures are, therefore, inefficient at best, as they may significantly reduce performance, consume major computing resources, and/or the like, and, in most cases, may be practically unfeasible for the low-end devices due to a lack of sufficient computing resources.

In contrast, deploying the security controller according to the present disclosure to protect the low-end devices may require the protected devices to execute a relatively simple process, thus significantly reducing the computing resources required at the protected devices and making it highly suitable for protecting the low-end devices. Moreover, as the computing resources of the protected devices may be reduced, the cost and/or complexity of the protected devices may also be reduced.

Moreover, by randomly manipulating the copy of the executable code segment, even sophisticated malware(s) designed and configured to alter the local second copy of the executable code segment executed by the protected device may be unable to easily discover the random manipulation in order to alter the second copy accordingly to produce a valid second security code. The computations to discover the random manipulation may require significant computing resources which may be unavailable in the protected devices with limited resources.

Moreover, in case the timeout mechanism is applied, the malware(s) may be unable to discover the random manipulation and alter the second copy accordingly within the time frame defined for the verification session.

Furthermore, since the random manipulation and the verification code segment are unique and valid for only a single verification session, the verification code segment generated in previous verification sessions may not be used and, thus, replay attacks are prevented.

In addition, by encoding the verification code segment, the effort required by the malware(s) to recover is dramatically increased, thereby further reducing the possibility that the malware(s) may obtain the verification code segment and manipulate it to compute a valid second security code for the second copy, while disguising the presence of the malware(s).

Before explaining at least one implementationof the present disclosure in detail, it is to be understood that the present disclosure is not necessarily 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 present disclosure is capable of other embodiments or of being practiced or carried out in various ways.

As will be appreciated by one skilled in the art, aspects of the present disclosure may be embodied as a system, method or computer program product. Accordingly, aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software implementation(including firmware, resident software, micro-code, etc.), or an implementationcombining software and hardware aspects that may all generally be referred to herein as a "circuit", "module", or "system". Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Computer program code comprising computer readable program instructions embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wire line, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

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 computer readable program instructions for carrying out operations of the present disclosure may be written in any combination of one or more programming languages, such as, for example, assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more 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.

In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure.

Referring now to the drawings, <FIG> presents flow charts of exemplary processes of protecting a processing device by a security controller deployed to verify software code executed by the protected processing device, according to some embodiments of the present disclosure.

Exemplary processes <NUM> and <NUM> may be executed by a security controller <NUM> and a protected device <NUM>, respectively, to protect the protected device <NUM> from one or more malicious attacks, in particular attacks directed to cause the protected device <NUM> to execute malicious code in an attempt to compromise the protected device <NUM>. The processes <NUM> and <NUM> interact with each other and are described in conjunction with each other according to the operational sequence of the overall verification process combining the processes <NUM> and <NUM>, in order to provide a clear and complete description of the processes <NUM> and <NUM> executed by the security controller <NUM> and the protected device <NUM>, respectively.

The protected devices <NUM> may include, for example, IoT devices, sensors, controllers and/or the like having network connectivity and capable of communicating with the security controller <NUM>. The protected devices <NUM> may typically include relatively low-end devices having limited resources, for example, processing resources, storage resources, communication resources and/or the like. As such, the protected devices <NUM> may be highly limited and possibly incapable to effectively execute software integrity protection measures such as, for example, anti-malware, anti-virus and/or the like.

The processes <NUM> and <NUM> shown in <FIG> describe a code verification session conducted by a single security controller <NUM> for protecting a single protected device <NUM>. However, this should not be construed as limiting, since the processes <NUM> and <NUM> may be extended to a plurality of verification sessions initiated by one or more security controllers <NUM> to protect a plurality of protected devices <NUM>. Moreover, the processes <NUM> and <NUM> may be extended to a plurality of verification sessions initiated by one or more security controllers <NUM> to support protection against malware compromising multiple executable code segments locally executed by one or more protected devices <NUM>. To this end, one or more security controllers <NUM> may store copies of a plurality of executable code segments typically executed by one or more protected devices <NUM> where each of these copies is a validated image of a respective executable code segment which is verified to be genuine and untampered.

As shown at <NUM>, the process <NUM> starts with the security controller <NUM> loading a first copy of the executable code segment, which is configured for execution by the protected device <NUM>.

The process <NUM> may be started by the security controller <NUM> initiating a verification session for verifying a second copy of the executable code segment locally stored at the protected device <NUM> and executed by the protected device <NUM>, as shown at <NUM> of the process <NUM>.

In particular, the verification session is launched to verify the code segment of the second copy after being loaded into the (volatile) memory of the protected device <NUM> at <NUM> of the process <NUM>. The verification is, therefore, carried out to verify the integrity and reliability of the second copy executed by the protected device <NUM> and ensure that the second copy is not infected by one or more malicious malware code segments. Such malicious malware may attempt to compromise the protected device <NUM> by diverting its execution path and cause it to initiate one or more unplanned and/or undesired actions.

The security controller <NUM> may initiate the verification session periodically, continuously, and/or on demand, i.e. upon a trigger from one or more automated tools and/or operators.

As shown at <NUM>, the security controller <NUM> generates a verification code segment.

The security controller <NUM> may configure and/or adapt the verification code segment to cause a security code to be computed for a copy of the executable code segment when loaded in memory, for example, the second copy of the executable code segment loaded in the memory of the protected device <NUM>. Moreover, the verification code segment may be adapted to cause the security code to be computed for the code section of the copy of the executable code segment, since, in case of an infection by one or more malwares, the code section, which is executed by the protected device <NUM>, may typically be the segment, which may contain the malware(s) code.

However, in case the protected device <NUM> is infected with one or more malware code segments, these malware(s) may be configured to alter the verification code segment to compute the security code for the second copy of the executable code segment such that the second security code computed for the infected second copy equals the security code, which would be computed for the original and uninfected second copy.

In order to increase an immunity of the verification process against the malware code segment(s), which may be executed by the protected device <NUM>, the verification code segment may be configured to cause the security code to be computed for the copy of the executable code segment after applying a random manipulation to the copy of the executable code segment.

Therefore, even if the protected device <NUM> is infected with malware(s), such malware(s) may be unable to alter the verification code segment to compute the second security code for the second copy in such a way that the second security code computed for the infected second copy matches the security code that would be computed for the manipulated version of the original and uninfected second copy.

The verification code segment may be configured and/or adapted to apply the random manipulation to a plurality of bytes randomly selected in the copy of the executable code segment which is loaded in the (volatile) memory. Specifically, the random manipulation is applied to bytes located at a randomly selected address in the address range occupied by the copy of the executable code segment in the (volatile) memory, in particular the code section of the executable code segment copy.

The random manipulation may 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 may be selected and a plurality of bytes located at the randomly selected addresses may be excluded and/or discarded. This implementation has not been claimed as such. According to the claimed disclosure, a plurality of addresses in the (volatile) memory storing the copy of the executable code segment may be selected and a plurality of bytes located at the randomly selected addresses may be altered, for example, replaced with bytes containing a certain value, for example, 0x00, 0xFF, 0x55 and/or the like. Alternatively, according to the claimed disclosure, a plurality of addresses in the (volatile) memory storing the copy of the executable code segment may be selected and a plurality of predefined data bytes may be inserted in the randomly selected addresses, for example, 0x00, 0xFF, 0x55 and/or the like.

The verification code segment may be configured to apply a unique random manipulation for every verification session such that a new verification code segment is generated during each verification session and is valid for only the respective verification session. The unique random manipulation and the single session valid verification code segment may prevent replay attacks by one or more malware(s) potentially residing at the protected device <NUM> which may attempt to duplicate and/or imitate the random manipulation applied in one or more previous verification sessions.

The verification code segment is, thus, configured and/or adapted to cause the security code to be computed after applying the random manipulation to the target copy of the executable code segment.

The verification code segment may be configured and/or adapted to cause the security code to be computed using one or more methods, techniques and/or algorithms. For example, the verification code segment may cause execution of one or more hash functions to compute a hash value for the manipulated version of the copy of the executable code segment.

Optionally, the verification code segment is encoded to further increase the immunity of the verification process against the malware code segment(s) which may infect the protected device <NUM>, since such malware(s) may need to first decrypt the verification code segment before it could alter the verification code segment and use it to produce the same security code as the original and uninfected second copy, thus disguising the presence of the malware code segment(s) at the protected device <NUM>.

The verification code segment may be encoded using one or more encoding methods, algorithms and/or technologies (collectively designated as encoding algorithms hereinafter), for example, White-Box Cryptography (WBC) and/or the like.

Moreover, the verification code segment may be encoded using one or more encoding algorithms based on one or more operational parameters of the (target) protected device <NUM>. The encoding algorithms may be selected such that, even if the malware(s) residing at the protected device <NUM> attempt to decrypt the verification code segment in an attempt to alter the verification code segment and produce a valid second security code for the infected second copy, the computing resources (e.g. processing power, storage resources, etc.) available in the protected device <NUM> may be insufficient for successful and/or efficient decryption.

As shown at <NUM>, the security controller <NUM> executes the verification code segment in order to apply the random manipulation to a first plurality of bytes in the first copy loaded in the memory and compute a first security code based on the randomly manipulated version of the first copy.

The security controller <NUM> may store the computed first security code, for example, in the memory.

As shown at <NUM>, the security controller <NUM> transmits the verification code segment to the protected device <NUM> via one or more networks.

As shown at <NUM>, the protected device <NUM> receives the verification code segment from the security controller <NUM>.

As shown at <NUM>, the protected device <NUM> executes the received verification code segment to compute a second security code based on a randomly manipulated version of the second copy of the executable code segment loaded in the memory of the protected device <NUM>.

The verification code segment executed by the protected device <NUM> may cause the protected device <NUM> to compute the second security code after the random manipulation has been applied to a second plurality of bytes in the second copy of the executable code segment <NUM>, which is loaded in the memory of the protected device <NUM>. Since the verification code segment is configured and/or adapted accordingly, the random manipulation applied by the verification code segment to the second plurality of bytes in the second copy is identical to the random manipulation applied to the first plurality of bytes in the first copy before computing the first security code.

It should be emphasized that the verification code segment is configured to cause the protected device <NUM> to compute the second security code after randomly manipulating the second copy of the executable code segment, specifically manipulating the second plurality of bytes residing at the randomly selected addresses only for the computation of the second security code without applying the random manipulation in the actual memory, where the second copy of the executable code segment is loaded. For example, the second security code may be computed using one or more security code computation functions, for example a hash function, which sequentially traverse the bytes of the second copy loaded in the memory of the protected device <NUM> and compute the second security code based on the traversed bytes. In such a case, the random manipulation may be applied on the fly during the sequential traversing of the bytes of the second copy rather than by actually manipulating the second copy. As such, the random manipulation, for example, excluding, skipping, inserting, duplicating, altering, and/or the like may be applied to the second plurality of bytes residing at the randomly selected addresses as part of the second security code computation without actually altering the second copy loaded in the memory of the protected device <NUM>. Therefore, the second copy of the executable code segment loaded in the memory of the protected device <NUM> is not affected in any way by the random manipulation and may be correctly executed by the protected device <NUM>.

As shown at <NUM>, the protected device <NUM> transmits the second security code to the security controller <NUM>.

Optionally, the protected device <NUM> may encrypt the second security code using one or more encryption technologies as known in the art.

As shown at <NUM>, the security controller <NUM> receives the second security code from the protected device <NUM>.

As shown at <NUM>, the security controller <NUM> compares the second security code received from the protected device <NUM>, which was computed for the manipulated version of the second copy, and the first security code computed for the manipulated version of the first copy.

As shown at <NUM>, which is a conditional step, in case the second security code matches, for example, equals the first security code, the security controller <NUM> may verify the reliability and integrity of the second copy executed by the protected device <NUM> and may, thus, determine that the second copy is valid. In such a case, the process <NUM> may branch to <NUM>. However, in case the second security code does not match the first security code, the security controller <NUM> may determine that the second copy executed by the protected device <NUM> may be altered and possibly infected with one or more malware code segments and the protected device <NUM> is potentially compromised. In such a case, the process <NUM> may branch to <NUM>.

As shown at <NUM>, in reaction to the absence of a match between the second security code and the first security code, which indicates that the protected device <NUM> may be potentially compromised, the security controller <NUM> determines that the protected device <NUM> may be compromised and may further initiate one or more actions in order to counter the potential compromise of the protected device <NUM>.

The one or more actions initiated by the security controller <NUM> may include, for example, transmitting an alert message of the potential compromise, transmitting a new copy of the executable code segment to the protected device <NUM>, instructing the protected device <NUM> to reboot and/or reset, instructing the protected device <NUM> to disconnect from one or more networks, and/or the like.

Optionally, the security controller <NUM> may configure, set, and/or initiate one or more timeout timers loaded with a predefined timeout period to define a time frame for the verification session. The security controller <NUM> may initiate the timeout timer at one or more points of the verification session, for example, when transmitting the verification code segment to the protected device <NUM> (step <NUM>).

In case the security controller <NUM> does not receive the second security code from the protected device <NUM> before expiration of the predefined timeout period, the security controller <NUM> may determine that the protected device <NUM> is potentially compromised.

The failure to respond within the predefined time period may be highly indicative of the protected device <NUM> being compromised and infected with one or more malwares, since, in order to avoid detection, such malware(s) may prevent and/or interfere with the execution of the verification process.

Moreover, the malware(s) may be configured to attempt to discover the nature of the random manipulation and alter the verification code segment to produce a valid second security code for the infected second copy, which equals the second security code computed for the original uninfected second copy. However, in order to unravel the random manipulation, such malware(s) may require significant time and significant computing resources, which may be limited in the protected device <NUM>. The malware(s) may, therefore, fail to correctly alter the second copy in a time period sufficient for responding to the security controller <NUM> before expiration of the predefined timeout period.

In case the verification code segment is encoded in the verification code segment, such malware(s) may require significantly more time to decode and/or reverse the encoded verification code segment and alter it accordingly to produce a valid second security code, which may further prevent these malware(s) from producing the second security code in a time period sufficient for responding to the security controller <NUM> before expiration of the predefined timeout period.

As shown at <NUM>, in case of a match between the second security code and the first security code, the security controller <NUM> may determine that the second copy is valid and free of malicious malware code segment(s). In such a case, the security controller <NUM> may take no action or, alternatively, initiate one or more actions to indicate that the integrity and reliability of the second copy executed by the protected device <NUM> is successfully verified, for example, log the verification session, transmit one or more verification success messages and/or the like.

Reference is now made to <FIG>, which is a schematic illustration of an exemplary system for protecting a processing device by a security controller deployed to verify software code executed by the processing device, according to some embodiments of the present disclosure.

The exemplary system may include one or more security controller(s) <NUM>, such as the security controller <NUM> shown in <FIG>, which are deployed to protect one or more protected device(s) <NUM>, such as the protected device <NUM> shown in <FIG>, by validating software code executed by the protected device(s) <NUM>.

The security controller <NUM>, for example, a computer, a controller, a server, a computing node, a cluster of computing nodes, and/or the like, may include a network interface <NUM> for connecting to a network <NUM>, a processing circuit <NUM> for executing a process such as the process <NUM> shown in <FIG>, and a memory <NUM> for storing data and/or a program. The security controller <NUM> may further include an images store <NUM> for storing one or more first copies of one or more executable code segments executed by one or more protected devices <NUM>. Each of the first copies is a validated image of the respective executable code segment as originally created and verified to be untampered.

The network interface <NUM> may include one or more network interfaces for connecting to the network <NUM> comprising one or more wired and/or wireless networks, for example, 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 and/or the like. Via the network interface <NUM>, the security controller <NUM> may communicate with one or more networked resources connected to the network <NUM>, for example, one or more protected devices <NUM>.

The processing circuit <NUM> may include one or more homogenous or heterogeneous processors arranged for parallel processing, as clusters, and/or as one or more multi-core processor(s). The processing circuit <NUM> may, therefore, execute one or more software modules such as, for example, a process, a script, an application, an agent, a utility, a tool and/or the like, each comprising a plurality of program instructions stored in a non-transitory medium (program store) such as the memory <NUM> and executed by one or more processors available in the processing circuit <NUM>.

The processing circuit <NUM> may further include one or more hardware elements, for example, a circuit, a component, an Integrated Circuit (IC), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signals Processor (DSP), a cryptography engine and/or the like.

The memory <NUM> may include one or more non-transitory persistent storage devices, for example, a Read Only Memory (ROM), a Flash array, a hard drive and/or the like. The memory <NUM> may also include one or more volatile devices, for example, a Random Access Memory (RAM) component, a cache memory and/or the like. The memory <NUM> may further include one or more network storage resources, for example, a storage server, a network accessible storage (NAS), a network drive, a cloud storage and/or the like accessible via the network interface <NUM>.

The images store <NUM> may include one or more persistent memory resources for storing one or more local images (copies) of the executable software code executed by one or more protected device <NUM>. For example, an image of an executable code segment <NUM> executed by the protected device <NUM> may be stored in the images store <NUM>.

The images store <NUM> may further include a secure storage protected via hardware and/or software means to prevent unauthorized access and, thus, ensure a reliability and integrity of the stored images. Such secure storage may include, for example, a Trusted Platform Module (TPM), an Enclave and/or the like which may be password protected and/or accessed using secure protocol(s).

Optionally, the images store <NUM> is utilized by one or more attachable storage devices, for example, an attachable memory device (e.g. memory stick) and/or the like, which may be attached to the network interface <NUM> and/or to one or more Input/Output (I/O) interfaces supported by the security controller <NUM>.

One or more images stored in the images store <NUM>, for example, a first copy 420A of the executable code segment <NUM>, may be loaded into the memory <NUM>, for example, into the volatile memory available in the memory <NUM>.

The processing circuit <NUM> may execute one or more functional modules which may be implemented via one or more software modules, one or more hardware elements and/or a combination thereof. For example, the processing circuit <NUM> may apply a session controller <NUM> functional module for executing the process <NUM> shown in <FIG> and a verification code generator <NUM> functional module for generating a verification code segment <NUM> used to verify one or more code segments executed by the protected device <NUM>.

Optionally, the security controller <NUM> executing the session controller <NUM> and the verification code generator <NUM> is implemented as one or more cloud computing services, for example, an Infrastructure as a Service (IaaS), a Platform as a Service (PaaS), a Software as a Service (SaaS), and/or the like.

The protected device <NUM>, for example, an IoT device, a sensor, a controller and/or the like, may include a network interface <NUM>, such as the network interface <NUM>, for connecting to a network <NUM>, a processing circuit <NUM>, such as the processing circuit <NUM>, for executing the process <NUM> and a storage <NUM> for storing data and/or a program.

The network interface <NUM> may include one or more network interfaces, typically wireless interfaces, such as, for example, a WLAN interface, an RF interface, a cellular interface, and/or the like, for connecting to the network <NUM>. Via the network interface <NUM>, the protected device <NUM> may communicate with one or more networked resources connected to the network <NUM>, for example, with the security controller <NUM>.

The memory <NUM> may include one or more non-transitory persistent storage devices, for example, a Read Only Memory (ROM), a Flash array, a hard drive and/or the like. The memory <NUM> may also include one or more volatile devices, for example, a RAM component, a cache memory and/or the like.

As described for the processing circuit <NUM>, the processing circuit <NUM> may also execute one or more functional modules, which may be implemented via one or more software modules, one or more hardware elements, and/or a combination thereof.

For example, one or more copies of one or more executable code segments which may be stored in the memory <NUM>, typically in persistent (non-volatile) memory, may be loaded and stored in one or more volatile memory devices of the memory <NUM>. For example, a second copy 420B of the executable code segment <NUM> may be loaded and (temporarily) stored in the memory <NUM> for execution by the processing circuit <NUM>.

The session controller <NUM> may initiate one or more verification sessions for verifying that the second copy 420B locally stored in the memory <NUM> of the protected device <NUM> and executed by the processing circuit <NUM> of the protected device <NUM> is not infected by one or more malicious malware code segments. The session controller <NUM> may initiate the verification sessions periodically, continuously, and/or on demand, i.e. upon a trigger from one or more automated tools and/or operators.

The session controller <NUM> may start the verification session by loading the first copy 420A of the executable code segment <NUM>, which is configured for execution by the protected device <NUM>. The session controller <NUM> may load the first copy 420A from the images store <NUM> to the memory <NUM>, specifically to the volatile memory of the memory <NUM>. The session controller <NUM> may be configured to load the first copy 420A to the memory <NUM>. However, the session controller <NUM> may be configured to instruct, invoke, and/or use one or more loader agents, tools, and/or applications executed by the processing circuit <NUM> to load the first copy 420A to the memory <NUM>.

The session controller <NUM> may further initiate, invoke, and/or execute the verification code generator <NUM> to generate the verification code segment <NUM>.

The verification code generator <NUM> may configure and/or adapt the verification code segment <NUM> to cause a security code to be computed for a copy of the executable code segment <NUM> when loaded in memory, in particular in volatile memory, for example, the first copy 420A of the executable code segment <NUM> loaded in the memory <NUM> of the security controller <NUM>, and/or the second copy 420B of the executable code segment <NUM> loaded in the memory <NUM> of the protected device <NUM>. Moreover, the verification code segment <NUM> may be adapted to cause the security code to be computed for the code section (code segment) of the executable code segment copy, since, in case of infection by one or more malwares, the code section which is executed by the processing circuit <NUM> may typically be the segment which may contain the malware(s) code.

However, in case the protected device <NUM> is infected with one or more malware code segments, these malware(s) may be configured to alter the second copy 420B such that the security code computed for the infected second copy 420B equals the security code, which would be computed for the original and uninfected second copy 420B.

In order to increase an immunity of the verification process against the malware code segment(s), which may be executed by the protected device <NUM>, the verification code generator <NUM> may configure and/or adapt the verification code segment <NUM> to cause the security code to be computed for the copy of the executable code segment <NUM> after applying a random manipulation to the copy of the executable code segment <NUM>.

Therefore, even if the protected device <NUM> is infected with malware(s), such malware(s) may be unable to alter the verification code segment <NUM> in such a way that the security code computed for the infected second copy 420B matches the security code that would be computed for the manipulated version of the original and uninfected second copy 420B.

The verification code generator <NUM> may configure and/or adapt the verification code segment <NUM> to apply the random manipulation to a plurality of bytes randomly selected in the copy of the executable code segment <NUM>, which is loaded in the volatile memory. Specifically, the random manipulation is applied to bytes located at randomly selected address in the address range occupied by the copy of the executable code segment <NUM> in the volatile memory, in particular the code section of the executable code segment copy.

The random manipulation may be implemented using one or more implementations. For example, the verification code segment <NUM> may be configured to randomly select a plurality of addresses in the volatile memory storing the copy of the executable code segment <NUM> and exclude (discard) the bytes located at the randomly selected addresses. This implementation has not been claimed as such. According to the claimed disclosure, the verification code segment <NUM> may be configured to cause random selection of a plurality of addresses in the volatile memory storing the copy of the executable code segment <NUM> and alter the bytes at these addresses, for example, replace the data of the bytes with a certain value, for example, 0x00, 0xFF, 0x55 and/or the like. Alternatively, according to the claimed disclosure, the verification code segment <NUM> may be configured to randomly select a plurality of addresses in the volatile memory storing the copy of the executable code segment <NUM> and insert predefined data bytes in these randomly selected addresses, for example, 0x00, 0xFF, 0x55 and/or the like.

The verification code generator <NUM> may configure and/or adapt the verification code segment <NUM> to apply a unique random manipulation for every verification session such that a new verification code segment <NUM> generated during each verification session is valid for only the respective verification session. The unique random manipulation and the single session valid verification code segment <NUM> may prevent replay attacks by one or more of the malware(s) potentially residing at the protected device <NUM> which may attempt to duplicate and/or imitate the random manipulation applied in one or more previous verification sessions.

The verification code segment <NUM> is, thus, configured and/or adapted to cause the security code to be computed after applying the random manipulation to the target copy of the executable code segment <NUM>.

The verification code segment <NUM> may be configured and/or adapted to cause the security code to be computed using one or more methods, techniques, and/or algorithms. For example, the verification code segment <NUM> may cause execution of one or more hash functions, which may cause a hash value to be computed for the manipulated version of the copy of the executable code segment <NUM>.

Optionally, the processing circuitry <NUM> executing the verification code generator <NUM> may encode the verification code segment <NUM>. This may further increase an immunity of the verification process against the malware code segment(s) which may infect the protected device <NUM>, since such malware(s) may need to first decrypt the verification code segment <NUM> before it could alter the verification code segment <NUM> to produce the same security code as the security code computed for the original and uninfected second copy 420B.

The verification code segment <NUM> may be encoded using one or more encoding methods, algorithms, and/or technologies, for example, White-Box Cryptography (WBC), and/or the like.

Moreover, the verification code segment <NUM> may be encoded using one or more of the encoding algorithms based on one or more operational parameters of the (target) protected device <NUM>. The encoding algorithms may be selected such that, even if the malware(s) residing at the protected device <NUM> attempt(s) to decrypt the randomly selected addresses in an attempt to alter the infected second copy 420B to produce a valid security code, the computing resources (e.g. processing power, storage resources, etc.) available in the protected device <NUM> may be insufficient for successful and/or efficient decryption.

The session controller <NUM> may cause the processing circuit <NUM> to execute the verification code segment <NUM> generated by the verification code generator <NUM>, in order to apply the random manipulation to a first plurality of bytes in the first copy 420A loaded in the memory <NUM> and compute a first security code based on the randomly manipulated version of the first copy 420A.

The session controller <NUM> may store the computed first security code, for example, in the memory <NUM>.

Optionally, the session controller <NUM> may cause the processing circuit <NUM> to apply the random manipulation to the first copy 420A loaded in the memory <NUM> and compute the first security code for the manipulated version of the first copy <NUM>. The session controller <NUM> may then cause the cause the processing circuit <NUM> to initiate the verification code generator <NUM> to generate the verification code segment <NUM> adapted to cause an identical random manipulation as applied to the first copy 420A by the processing circuit <NUM> executing the session controller <NUM> and compute the security code for the manipulated version of the copy of the executable code segment <NUM>.

The session controller <NUM> may transmit the verification code segment <NUM> to the protected device <NUM> via the network <NUM>.

The protected device <NUM>, specifically the processing circuit <NUM>, may execute the verification code segment <NUM> received from the security controller <NUM> to compute a second security code based on a randomly manipulated version of the second copy 420B of the executable cod segment.

The verification code segment <NUM> may cause the processing circuit <NUM> to first apply the random manipulation to a second plurality of bytes in the second copy 420B of the executable code segment <NUM>, which is loaded in the memory <NUM> and potentially executed by the processing circuit <NUM>. Since the verification code segment <NUM> is configured and/or adapted accordingly, the random manipulation applied by the processing circuit <NUM> executing the verification code segment <NUM> to the second plurality of bytes in the second copy 420B is similar (identical) to the random manipulation applied to the first plurality of bytes in the first copy 420A before computing the first security code.

The processing circuit <NUM> may apply the verification code segment <NUM> to compute the second security code for the manipulated version of the second copy 420B in the same manner applied to compute the first security code for the manipulated version of the first copy 420A.

It should be emphasized that the verification code segment <NUM> may cause the processing circuit <NUM> to compute the second security code after randomly manipulating the second copy 420B, specifically manipulating the second plurality of bytes residing at the randomly selected addresses only for the computation of the second security code without actually applying the manipulation in the memory <NUM>, where the second copy 420B is loaded. For example, the second security code may be computed using one or more security code computation functions, for example a hash function, which sequentially traverse the bytes of the second copy 420B loaded in the memory <NUM> and compute the second security code based on the traversed bytes. In such a case, the random manipulation may be applied on the fly during the sequential traversing of the bytes of the second copy 420B rather than by actually manipulating the second copy 420B. As such, the random manipulation, for example, excluding, skipping, inserting, duplicating, altering, and/or the like may be applied to the second plurality of bytes residing at the randomly selected addresses of the second copy 420B as part of the security code computation without actually altering the second copy 420B loaded in the memory <NUM>. Therefore, the second copy 420B loaded in the memory <NUM> is not affected by the random manipulation in any way and may be correctly executed by the processing circuit <NUM>.

The protected device <NUM> may transmit the second security code to the security controller <NUM>.

The security controller <NUM>, specifically the processing circuitry <NUM> executing the session controller <NUM>, may receive the second security code from the protected device <NUM>.

The session controller <NUM> may cause the processing circuitry <NUM> to compare the second security code received from the protected device <NUM>, which was computed for the manipulated version of the second copy 420B, and the first security code computed for the manipulated version of the first copy 420A with each other.

In case the second security code matches, for example, equals, the first security code, the session controller <NUM> may cause the processing circuitry <NUM> to verify the reliability and integrity of the second copy 420B executed by the protected device <NUM> and may, thus, determine that the second copy 420B is valid. However, in case the second security code does not match the first security code, the session controller <NUM> may cause the processing circuitry <NUM> to determine that the second copy 420B executed by the protected device <NUM> may be altered and possibly infected with one or more malware code segments and the protected device <NUM> is potentially compromised.

In reaction to the absence of a match between the second security code and the first security code, thereby indicating that the protected device <NUM> may be potentially compromised, the session controller <NUM> may cause the processing circuitry <NUM> to further initiate one or more actions in order to counter the potential compromise of the protected device <NUM>. The actions initiated by the processing circuitry <NUM> executing the session controller <NUM> may include, for example, transmitting an alert message of the potential compromise, transmitting a new copy of the executable code segment <NUM> to the protected device <NUM>, instructing the protected device <NUM> to reboot and/or reset, instructing the protected device <NUM> to disconnect from the network <NUM>, and/or the like.

Optionally, the session controller <NUM> may cause the processing circuitry <NUM> to configure, set, and/or initiate one or more timeout timers loaded with a predefined timeout period to define a time frame for the verification session. The session controller <NUM> may cause the processing circuitry <NUM> to initiate the timeout timer at one or more points of the verification session, for example, when transmitting the verification code segment <NUM> to the protected device <NUM>.

In case the processing circuitry <NUM> executing the session controller <NUM> does not receive the second security code from the protected device <NUM> before expiration of the predefined timeout period, the session controller <NUM> may cause the processing circuitry <NUM> to determine that the protected device <NUM> is potentially compromised.

In case of a match between the second security code and the first security code, the session controller <NUM> may cause the processing circuitry <NUM> to determine that the second copy 420B may be valid and free of malicious malware code segment(s). In such a case, the session controller <NUM> may cause the processing circuitry <NUM> to take no action or alternatively initiate one or more actions to indicate that the integrity and reliability of the second copy <NUM> executed by the protected device <NUM> is successfully verified, for example, log the verification session, transmit one or more verification success messages and/or the like.

Reference is now made to <FIG> and <FIG>, which present an exemplary sequence of protecting a processing device by a security controller deployed to verify software code executed by the protected processing device, according to some embodiments of the present disclosure. An exemplary code verification sequence <NUM> may be executed by a security controller, such as the security controller <NUM> shown in <FIG>, and a protected device, such as the protected device <NUM> shown in <FIG>, to verify an integrity and reliability of one or more copies of executable code segments, such as the second copy 420B of the executable code segment <NUM> executed by the protected device <NUM>.

The security controller <NUM>, specifically the processing circuit <NUM>, may execute one or more functional modules implemented and/or utilized via one or more software modules, one or more hardware elements, and/or a combination thereof. For example, the processing circuit <NUM> may execute a scheduler <NUM> for scheduling one or more verification sessions for verifying the second copy 420B of the executable code segment <NUM> executed by the protected device <NUM>, a session controller, such as the session controller <NUM>, and a verification code generator, such as the verification code generator <NUM>.

The protected device <NUM>, specifically the processing circuit <NUM>, may also execute one or more functional modules implemented and/or utilized via one or more software modules, one or more hardware elements, and/or a combination thereof. For example, the processing circuit <NUM> may execute a code loader <NUM> for loading one or more code segments in a memory of the protected device <NUM>, such as the memory <NUM>, and a verification code segment, such as the verification code segment <NUM> generated by the verification code generator <NUM>.

The verification sequence <NUM> starts with the scheduler <NUM> triggering, at <NUM>, the session controller <NUM>, which causes the processing circuitry <NUM> to initiate a code verification session. The scheduler <NUM> triggers one or more verification session(s) periodically, continuously, and/or in response to one or more requests received from one or more automated tasks, via one or more initiation messages received at the security controller <NUM>, and/or in response to manual triggering by one or more operators.

In response to the trigger <NUM>, the session controller <NUM> causes the processing circuitry <NUM> to initiate the code verification session at <NUM>. The session controller <NUM> causes the processing circuitry <NUM> to first load into a memory, such as the memory <NUM>, a first copy of the executable code segment stored, as shown at <NUM>, in an images cache, such as the images store <NUM>. The first copy is a validated image of the executable code segment, which is verified as being genuine and untampered.

The session controller <NUM> further causes the processing circuitry <NUM> to perform the following steps.

A plurality of addresses is randomly selected, as shown at <NUM>, in an address range of the memory <NUM>, in which the first copy of the executable code segment is loaded. According to an example, this is carried out as described in step <NUM> of the process <NUM>. The verification code segment <NUM> is then generated for computing a security code for the executable code segment after manipulating the first plurality of bytes at the randomly selected addresses, as shown at <NUM>. According to an example, this is performed as described in step <NUM> of the process <NUM>. The generated verification code segment <NUM> is executed to compute the first security code, as shown at <NUM>, for the first copy loaded in memory. According to an example, this is carried out as described in step <NUM> of the process <NUM>. Optionally, the verification code segment <NUM> may be encoded, as shown at <NUM>.

As described herein before, the verification code segment <NUM> is configured to cause the processing circuitry <NUM> to apply one or more methods, techniques, and/or algorithms for computing the security code. For example, the verification code segment <NUM> causes the processing circuitry <NUM> to apply one or more hash functions to compute a first hash value for the first copy, which may be used as the first security code for the first copy.

The session controller <NUM> causes the processing circuitry <NUM> to receive the computed first security code, for example, the first hash value, and store it, as shown at <NUM>. According to an example, this is performed as described in step <NUM> of the process <NUM>.

The session controller <NUM> causes the processing circuitry <NUM> to transmit the verification code segment <NUM> to the protected device <NUM>, as shown at <NUM>. According to an example, this is carried out as described in step <NUM> of the process <NUM>.

The protected device <NUM> receives the verification code segment <NUM> from the security controller <NUM>. According to an example, this is performed as described in step <NUM> of the process <NUM>. After receiving the verification code segment <NUM> from the security controller <NUM>, the protected device <NUM>, specifically the processing circuit <NUM>, may initiate the code loader <NUM> to load, as shown at <NUM> in <FIG>, the verification code segment <NUM> into a memory for execution by the processing circuit <NUM>. In case the verification code segment <NUM> was encoded by the processing circuitry <NUM> of the security controller <NUM>, the processing circuit <NUM> may first decode and/or reverse the encoded verification code segment <NUM> and then load the verification code segment <NUM> into the memory.

Once loaded, the processing circuit <NUM> executes the verification code segment <NUM> to compute a second security code, as shown at <NUM>, for example, a second hash value, for the second copy loaded in the memory of the protected device <NUM> after manipulating the second plurality of bytes residing at the randomly selected address. According to an example, this is performed as described in step <NUM> of the process <NUM>.

The protected device <NUM> transmits the second security code, for example, the second hash value, as shown at <NUM>, to the security controller <NUM>. According to an example, this is carried out as described in step <NUM> of the process <NUM>.

After receiving the second security code, for example, the second hash value, from the protected device <NUM>, the session controller <NUM> causes the processing circuit <NUM> to compare, as shown at <NUM>, the second security code, for example, the second hash value, computed for the second copy, and the first security code, for example, the first hash value, computed for the first copy with each other. According to an example, this is performed as described in step <NUM> of the process <NUM>.

In case of a match between the second security code, for example, the second hash value, and the first security code, for example, the first hash value, as shown at <NUM>, the session controller <NUM> causes the processing circuit <NUM> to determine that the second copy is valid and uninfected (OK) by malware code segment(s). According to an example, this is performed as described in step <NUM> of the process <NUM>.

However, in reaction to an absence of a match between the second security code, for example, the second hash value, and the first security code, for example, the first hash value, as shown at <NUM>, the session controller <NUM> causes the processing circuit <NUM> to determine that the protected device <NUM> may be compromised and further causes the processing circuit <NUM> to initiate one or more actions to counter the potentially compromise of the protected device <NUM>. According to an example, this is carried out as described in step <NUM> of the process <NUM>.

The word "exemplary" is used herein to mean "serving as an example, an instance or an illustration". Any implementationdescribed as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude the incorporation of features from other embodiments.

Any particular implementationof the disclosure may include a plurality of "optional" features unless such features conflict.

Claim 1:
A security controller (<NUM>), comprising:
a memory (<NUM>); and
circuitry (<NUM>) configured to:
load a first copy of an executable code segment to the memory,
compute a first security code based on a randomly manipulated first copy of the executable code segment,
generate a verification code segment adapted to cause a protected device to compute a second security code based on a randomly manipulated second copy of the executable code segment upon the second copy of the executable code segment being loaded in a memory of the protected device,
transmit the verification code segment to the protected device,
receive the second security code from the protected device,
compare the first security code and the second security code, and
determine a compromise of the protected device in reaction to the second security code not matching the first security code;
characterized in that
the random manipulation comprises randomly selecting an address of a first plurality of bytes in the first copy of the executable code segment and altering, for the computation of the first security code, the first plurality of bytes residing at the randomly selected address in the first copy of the executable code segment; or
wherein the random manipulation comprises randomly selecting an address of a first plurality of bytes in the first copy of the executable code segment and inserting, for the computation of the first security code, a plurality of predefined data bytes at the randomly selected address into the first copy of the executable code segment.;
wherein the generated verification code segment is adapted such that the random manipulation applied by the verification code segment to the second plurality of bytes in the second copy is identical to the random manipulation applied to the first plurality of bytes in the first copy before computing the first security code.