DESC:TECHNICAL FIELD
[0001] The present disclosure generally relates to the electrical industry. In particular, the present disclosure relates to making firmware image(s) used in design of electrical substation automation relays secure.
BACKGROUND
[0002] Background description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.
[0003] Use of personal computing devices such as personal computers, laptop computers and notebook computers, among other devices continues to grow. Such systems are used for entertainment, business, maintaining financial records, among numerous other purposes. Such systems are also targets for attacks by malicious actors. For instance, such attacks may include placing malicious software on a computing system. Such malicious software (malware) may compromise the security of the computing system by collecting personal information from the computing system, such as from memory or by using programs such as key-loggers, to collect passwords and other information entered into the computing system, as some examples. In other instances, the malware may be a computer virus or other malicious code.
[0004] Such attacks can be accomplished in a number of ways. For example, a malicious actor may gain access to a user's system in a public setting, such as at a conference, or a coffee shop. In other situations, a malicious actor may deliver malware over a network connection, such as via a website, for example.
[0005] One way to accomplish such malicious acts is to modify a “boot path” of a computing system to include malware in the boot path or to place the computing system in a vulnerable state where it can be accessed or attached remotely. In such a situation, a malicious actor may corrupt or replace instructions that are used to boot, or start-up, a computing system with malicious instructions. For instance, instructions in firmware of a computing system may be modified and/or replaced with malware.
[0006] In many computer architectures, firmware is the lowest level of software that is executed on a computing system. The firmware may include instructions that initialize a main processor, random access memory and chipsets, among other system components. Typically, the firmware is read-write and can be modified in the field, such as to allow for updates that may correct defects or address security vulnerabilities. However, because such firmware is writeable, it can be modified, which makes associated computing systems subject to attack.
[0007] In such a system, the system may “boot” or start-up by first executing instructions of the firmware, and then executing instructions of an operating system kernel (which may be stored on a hard-disk or other mass storage device, such as a flash disk). This sequence of instructions may be referred to as a “boot path” for the system. Malicious acts may be accomplished, for example, by corrupting/modifying one or more portions of the boot path.
[0008] For a given system, updates may be made to elements of the boot path (e.g., firmware and/or operating system kernel). Such updates may be made to address known security concerns with previous versions. This, however, provides another way to accomplish malicious acts, such as by reverting elements of the boot path of a system to a previous version, where that previous version has a known security issue that can be readily exploited by the malicious actor.
[0009] Verification plays an important role before uploading an image into device. Verification of software loaded into a computing device during the boot process is done to ensure that the software is authorised and correct for the computing device. Verification process extends from the moment the system is reset to as far as the user/administrators wishes into the boot process. The firmware may include instructions for implementing a verified boot process, such as cryptographic algorithms, one or more cryptographic keys and boot instructions for implementing the verified boot path and initializing the computing system. The instructions in the firmware may be executed by a processor to implement the verified boot process, wherein the processor may be a main application processor of the system or can be a special purpose processor that is used by the system to execute the instructions stored in the firmware to initialize the system and verify the boot path is secure. It is noted that the exact approach used to execute instructions stored in the firmware depends on the particular embodiment. In still other embodiments, firmware may be provided to a computing system from a remote, or network location, such as using, for example, a Preboot Execution Environment (PXE). In such approaches, signed images (e.g., including a R/W firmware portion, a kernel and/or an operating system) may be provided to a computing system from a network location.
[0010] A key point however is that existing architectures do not make it possible to field-upgrade the software on computing devices that use verified boot. Since a computing device only runs software that has been correctly signed, it is safe to read software from an updatable/upgradable medium, which the present environments do not provide. Existing architectures also do not make it possible to add a secondary signed firmware image in read-write memory so that firmware can easily be upgraded in a secure manner.
[0011] There is therefore a need in the art for systems and methods that allow the verified boot to use means such as cryptographic algorithms to sign software images to make such images secure for use.
[0012] All publications herein are incorporated by reference to the same extent as if each individual publication or patent application were specifically and individually indicated to be incorporated by reference. Where a definition or use of a term in an incorporated reference is inconsistent or contrary to the definition of that term provided herein, the definition of that term provided herein applies and the definition of that term in the reference does not apply.
[0013] In some embodiments, the numbers expressing quantities of ingredients, properties such as concentration, reaction conditions, and so forth, used to describe and claim certain embodiments of the invention are to be understood as being modified in some instances by the term “about.” Accordingly, in some embodiments, the numerical parameters set forth in the written description and attached claims are approximations that can vary depending upon the desired properties sought to be obtained by a particular embodiment. In some embodiments, the numerical parameters should be construed in light of the number of reported significant digits and by applying ordinary rounding techniques. Notwithstanding that the numerical ranges and parameters setting forth the broad scope of some embodiments of the invention are approximations, the numerical values set forth in the specific examples are reported as precisely as practicable. The numerical values presented in some embodiments of the invention may contain certain errors necessarily resulting from the standard deviation found in their respective testing measurements.
[0014] As used in the description herein and throughout the claims that follow, the meaning of “a,” “an,” and “the” includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
[0015] The recitation of ranges of values herein is merely intended to serve as a shorthand method of referring individually to each separate value falling within the range. Unless otherwise indicated herein, each individual value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g. “such as”) provided with respect to certain embodiments herein is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention otherwise claimed. No language in the specification should be construed as indicating any non-claimed element essential to the practice of the invention.
[0016] Groupings of alternative elements or embodiments of the invention disclosed herein are not to be construed as limitations. Each group member can be referred to and claimed individually or in any combination with other members of the group or other elements found herein. One or more members of a group can be included in, or deleted from, a group for reasons of convenience and/or patentability. When any such inclusion or deletion occurs, the specification is herein deemed to contain the group as modified thus fulfilling the written description of all Markush groups used in the appended claims.
OBJECTS OF THE INVENTION
[0017] It is an object of the present disclosure to provide a safe embedded device that runs only on signed software/firmware.
[0018] It is an object of the present disclosure to provide an electrical substation automation relay device that runs verified software images.
[0019] It is an object of the present disclosure to provide an electrical substation automation relay device that runs verified software images that can be field-upgraded.
[0020] It is an object of the present disclosure to provide a mechanism that ensures that only a software signed by a vendor is used on an embedded device.
[0021] It is an object of the present disclosure to provide a mechanism that verifies software during/post loading to ensure that the software is authorized during boot.
SUMMARY
[0022] The present disclosure generally relates to the electrical industry. In particular, the present disclosure relates to making firmware image(s) used in design of electrical substation automation relays secure.
[0023] The present disclosure relates to a system to verify an image to be loaded during booting of an electrical substation automation relay device, wherein the system can include a verification module that is configured to receive the image to be loaded, and further configured to hash the image to confirm if the hashed image matches with a signature provided with the image, and wherein the signature is generated based on a private key during a signature generation module.
[0024] In an aspect, the electrical substation automation relay device is a numerical relay. In another aspect, the private key can be stored on a memory card such as a SD card, and wherein matching by the verification module can be performed using a public key that can be stored on the electrical substation automation relay device.
[0025] In another aspect, the signature generation module can be configured to create the image of a software/firmware to be loaded, and further configured to hash the created image and sign with a first half of the private key, wherein the other half of the private key is stored on a memory device.
[0026] In yet another aspect, the image can include one or more kernels along with one or more device tree files for devices supported by the one or more kernels. In yet another aspect, the system can further enable field-up gradation of the verified images. In yet another aspect, the electrical substation automation relay device can be an embedded device used in electrical substations.
[0027] Other features of embodiments of the present invention will be apparent from accompanying drawings and from detailed description that follows.
BRIEF DESCRIPTION OF THE DRAWINGS
[0028] FIG. 1 illustrates an exemplary architecture showing signing and verification of software image by a verified boot in accordance with an embodiment of the present disclosure.
[0029] FIG. 2 illustrates an exemplary block diagram illustrating verification of an image at an electrical substation automation relay device in accordance with an embodiment of the present disclosure..
[0030] FIG. 3 illustrates an exemplary flow diagram illustrating verification of an image at an electrical substation automation relay device in accordance with an embodiment of the present disclosure.
DETAILED DESCRIPTION
[0031] The following is a detailed description of embodiments of the disclosure depicted in the accompanying drawings. The embodiments are in such detail as to clearly communicate the disclosure. However, the amount of detail offered is not intended to limit the anticipated variations of embodiments; on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure as defined by the appended claims.
[0032] Each of the appended claims defines a separate invention, which for infringement purposes is recognized as including equivalents to the various elements or limitations specified in the claims. Depending on the context, all references below to the "invention" may in some cases refer to certain specific embodiments only. In other cases it will be recognized that references to the "invention" will refer to subject matter recited in one or more, but not necessarily all, of the claims.
[0033] Various terms as used herein are shown below. To the extent a term used in a claim is not defined below, it should be given the broadest definition persons in the pertinent art have given that term as reflected in printed publications and issued patents at the time of filing.
[0034] The present disclosure generally relates to the electrical industry. In particular, the present disclosure relates to making firmware image(s) used in design of electrical substation automation relays secure.
[0035] The present disclosure relates to a system to verify an image to be loaded during booting of an electrical substation automation relay device, wherein the system can include a verification module that is configured to receive the image to be loaded, and further configured to hash the image to confirm if the hashed image matches with a signature provided with the image, and wherein the signature is generated based on a private key during a signature generation module.
[0036] In an aspect, the electrical substation automation relay device is a numerical relay. In another aspect, the private key can be stored on a memory card such as a SD card/flash memory, and wherein matching by the verification module can be performed using a public key that can be stored on the electrical substation automation relay device.
[0037] In another aspect, the signature generation module can be configured to create the image of a software/firmware to be loaded, and further configured to hash the created image and sign with a first half of the private key, wherein the other half of the private key is stored on a memory device.
[0038] In yet another aspect, the image can include one or more kernels along with one or more device tree files for devices supported by the one or more kernels. In yet another aspect, the system can further enable field-up gradation of the verified images. In yet another aspect, the electrical substation automation relay device can be an embedded device used in electrical substations.
[0039] The present disclosure relates to systems and methods that allow verified boot to use means such as cryptographic algorithms to sign software images to make such images secure for use. In an aspect of the present invention, verified boot can be configured to use one or more cryptographic algorithms to 'sign' software images, wherein the software images can be signed using a private key known only to the signer/signatory but can be verified using a public key. Public key can be made available to the public without any risk to the verification process, wherein the private key and public key are mathematically related. Few exemplary cryptographic algorithms include but are not limited to "public key cryptography" and "RSA".
[0040] During the signing process of the software image by the verified boot, the signature algorithm relies only on the public key to do its work. Using this key, the algorithm checks the signature that it finds in the image to verify/confirm the image to be acceptable. Public key from the signer allows verification of the software and therefore trust the software from updatable memory. A private key is a component of public-key cryptography where a private key is maintained as a secret and a public key is maintained as public. One key locks or encrypts information and the other key unlocks or decrypts information. Neither key performs both functions of encrypting and decrypting.
[0041] In an aspect, it is important for the public key to be secure and not tampered with, wherein, for instance, the public key can be stored in read-only memory or perhaps protected by other on-chip cryptographic algorithms.
[0042] FIG. 1 illustrates an exemplary architecture 100 showing signing and verification of a software image 102 by a verified boot. As shown, the software image 102 can be signed by a signer 104 based on a public-private key combination 102, wherein the public key can be stored in a trusted place such as 108 for use during verification of the software image 106 at the verification unit 110. In an aspect, the verification is U-Boot signature verification, wherein if the signed software image is verified, the software image 102can be used by the computing device on which it is configured to enable secure and flexible booting, in applications such as numerical relays. On the other hand, the firmware will not load or launch the software image 102 if the signature key associated with the software image 102 fails validation/verification.
[0043] According to one embodiment, the software image 102 is loaded after the boot module such that boot module is first loaded/executed on the host processor, and then a security processor confirms whether a plurality of software images 102 are to be loaded after the boot module and if such software images 102 are authorized to be loaded on the host processor, and when one of the plurality of software images is authorized, then loading the one of the plurality of software images on the host processor for execution.
[0044] In existing industrial systems, open protocol such as MODBUS, Profinet are used to control industrial plants. LINUX is the one of the commonly used operating systems in the embedded systems. Systems that are used to boot from unsecure boot media such as SD-card are prone to be hijacked by means of booting from secure media, and therefore integrity of entire system is a questioned mark. The present disclosure/invention therefore addresses this problem by securing BOOT media and BOOT process.
[0045] Most of the LINUX based systems use unsecure SD card one of the BOOT media for field up gradation, which can be easily reverse engineered using simple tools such as protocol analyzer and oscilloscope. The proposed disclosure addresses this limitation by proposing encryption of the LINUX kernel image and the file system by using an encryption key to address this problem. In embedded Linux systems, the problem of storing encryption key is a major problem, and hence the proposed architecture also address this issue by putting encryption key into DT attribute and modifying the device driver code.
[0046] Aspects of the present disclosure enable secure firmware image to be generated/processed/loaded by using cryptography algorithm in, for instance, embedded Linux development. Aspects also enable security of U-boot image, Kernel Image inside embedded device such as numerical relay, among others. The present disclosure provides a way to ensure that only software signed by a vendor can be used on a given embedded device, making it possible to field upgrade the software. The present disclosure is also targeted to verify the loaded software to ensure that it is authorized during boot. Further aspects of the present disclosure enable safe embedded device to be loaded as it runs only signed software, providing authorized read access.
[0047] Aspects of the present disclosure further provides mechanisms for verifying software images while still allowing them to be field-upgraded. In an embodiment, verified boot can be generated based on any or a combination cryptographic hashing (e.g. SHA-1) and/or public key cryptography (e.g. RSA). Using such verified boot, it is possible to distribute software images and have them verified on a device. In an implementation, a key can be created to hash an image, sign the hash, and publish the public key. On the device, an image can be retrieved/obtained and verified that it is signed by a corresponding private key. There can be an initial trusted image that can start the process. In an embodiment, hashing key can be stored in a SD card for authentication.
[0048] According to one implementation, a private key can be created on a secure/safe SD card, and it can be made sure that the public key is distributed on each device in a tamper-proof place such as read-only memory or a verified key store. Next, an image of a software is created, which is the image that is desired to be loaded onto the device. The image can be hashed and the hash can be signed with half private key, wherein, the other half can be accessed from the SD card to complete the algorithm. This signature can be sent to the device along with the image, wherein the image can typically contain one or more kernels and say one or more device tree files for devices supported by that kernel. Once the device receives the image, it can also hash the image, and then verify that the hash agrees with the signature provided with the image. If it matches then the image can be known to be signed as in the second step, and it can be concluded that the image is safe for use.
[0049] FIG. 2 illustrates an exemplary block diagram 200 illustrating verification of a software/firmware image at an electrical substation automation relay device 202. As can be seen, the proposed system can include a signature generation module 204 that can be configured to generate a signed image, and then send it to a verification module 206 to verify the received signed image. In an aspect, signature generation module 204 can be configured to, at block 208, create an image of a software/firmware, which is the image that is desired to be loaded onto the device202. The image can then, at block 210, be hashed and the hash can, at block 212, be signed with half private key, wherein, the other half can be accessed from the SD card 214to complete the algorithm.
[0050] At the verification module 206, once the device 202 receives the image, it can also, at block 216, hash the image, and then, at block 218, verify that the hash agrees with the signature provided with the image. If it matches then the image can be known to be signed as in the second step, and it can be concluded that the image is safe for use.
[0051] FIG. 3 illustrates an exemplary flow diagram 300 illustrating verification of an image at an electrical substation automation relay device in accordance with an embodiment of the present disclosure. At step 302, an image of a software/firmware that is desired to be loaded onto the electrical substation automation relay device is created. At step 304, the image can be hashed, and at step 306, the hash can be signed with half private key, wherein, the other half can be accessed from, for instance, a SD card to generated a signed image, which can then, at step 308, be sent for verification.
[0052] At step 310, once the device receives the image, hash of the image is generated, post which, at step 312, the method can include verification of the hash with the received image signature to determine if the image is safe for use.
[0053] In an aspect, signature generation and/or verification modules can be implemented using non-transient, tangible computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such non-transient, tangible computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. Non-limiting examples of non-transient, tangible computer-readable media include physical storage and/or memory media such as RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. When information is transferred or provided over a network or another communications connection (hardwired and/or wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a non-transient, tangible computer-readable media computer-medium. Thus, any such connection is properly termed a non-transient, tangible computer-readable medium. Combinations of the above should also be included within the scope of non-transient, tangible computer-readable media.
[0054] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.
ADVANTAGES OF THE INVENTION
[0055] The present disclosure provides a safe embedded device that runs only on signed software/firmware.
[0056] The present disclosure provides an electrical substation automation relay device that runs verified software images.
[0057] The present disclosure provides an electrical substation automation relay device that runs verified software images that can be field-upgraded.
[0058] The present disclosure provides a mechanism that ensures that only a software signed by a vendor is used on an embedded device.
[0059] The present disclosure provides a mechanism that verifies software during/post loading to ensure that the software is authorized during boot.
,CLAIMS:1. A system to verify an image to be loaded during booting of an electrical substation automation relay device, said system comprising:
a verification module configured to receive the image to be loaded, and further configured to hash the image to confirm that the hashed image matches with a signature provided with the image, wherein the signature is generated based on a private key during a signature generation module.

2. The system of claim 1, wherein the electrical substation automation relay device is a numerical relay.

3. The system of claim 1, wherein the private key is stored on a memory card, and wherein matching by the verification module is performed using a public key that is stored on the electrical substation automation relay device.

4. The system of claim 1, wherein the signature generation module is configured to create the image of a software to be loaded, and further configured to hash the created image and sign with a first half of the private key, wherein the other half of the private key is stored on a memory device.

5. The system of claim 1, wherein the image comprises one or more kernels along with one or more device tree files for devices supported by the one or more kernels.

6. The system of claim 1, wherein the system further enables field-up gradation of the verified images.

7. The system of claim 1, wherein the electrical substation automation relay device is an embedded device used in electrical substations.

8. The system of claim 1, wherein the system is configured in the electrical substation automation relay device.

9. An electrical substation automation relay device configured to verify an image to be loaded into the device during booting, said device comprising:
a verification module configured to receive the image to be loaded, and further configured to hash the image to confirm that the hashed image matches with a signature provided with the image, wherein the signature is generated based on a private key during a signature generation module.

10. The system of claim 1, wherein the signature generation module is configured to create the image of a software to be loaded, and further configured to hash the created image and sign with a first half of the private key, wherein the other half of the private key is stored on a memory device.