Patent Publication Number: US-2021176073-A1

Title: Providing security in an intelligent electronic device

Description:
PRIORITY 
     This application is a continuation application of U.S. patent application Ser. No. 15/386,766, filed Dec. 21, 2016, which claims priority to U.S. Provisional Patent Application No. 62/270,340, filed Dec. 21, 2015, entitled “PROVIDING SECURITY IN AN INTELLIGENT ELECTRONIC DEVICE”, the contents of which are hereby incorporated by reference in its entirety. 
    
    
     BACKGROUND 
     1. Field 
     The present disclosure relates generally intelligent electronic devices (IED), such as metering devices, and more particularly to providing security in an intelligent electronic device. 
     2. Description of the Related Art 
     Security is becoming a major issue with meters, also known as intelligent electronic devices (IEDs), especially as the interfaces to communicate with them transitions from being primarily serial to over networks. Since meters have been traditionally kept internal to networks, the security applied to them is often minimal, especially when compared to the security found in most modern servers. However, as attacks become more sophisticated and meters become more globally accessible, these old paradigms are no longer sufficient. 
     Additionally, an unfortunate side effect of the commercialization of a meter is reverse engineering and copying of both hardware and the software that runs on it. While methods such as locking the software inside of the chip, so that it cannot be easily read back out, can help prevent this, it only easily works with small code bases, which limit the features and power of the software. 
     SUMMARY 
     The present disclosure provides for various measures for improving security in a meter or an intelligent electronic device (IED). In one implementation, security in a meter can be improved by utilizing a hash function to create a hash value for a digital signature transmitted along with an unencrypted file for upgrading the software or firmware operating on the meter. The hash function may be executed at both the sending and receiving ends, e.g., on the unencrypted file for upgrading the software or firmware operating on the meter. When the meter or IED at the receiving end extracts the hash value from the digital signature, the determined hash value of the unencrypted file is compared with the expected hash value from the digital signature to determine if there is a match, which indicates an authentic file. 
     Another embodiment for improving security in a meter includes keeping a log of the changes made to, for example, the software and firmware in the meter, configurations settings, etc. The configuration settings may be stored in a meter profile file. The log may be maintained in the meter or IED to record and track changes in the meter profile for recording information related to the types of changes that were made in the meter, a person or persons responsible for authorizing the changes, the times and dates of the changes, etc. 
     According to another exemplary embodiment, a random seed value may be used to calculate a hash value of the firmware running on the meter. The hash value can be retrieved by a remote computer to compare the hash value with a hash value of the proper firmware that should be operating on the meter. The comparison is used to determine if the proper or authorized firmware is running on the meter. For example, the authorized firmware may be the firmware issued by the meter manufacturer. 
     One embodiment to improving security in a meter may include monitoring the working memory (e.g., RAM) of the intelligent electronic device. In this embodiment, sectors of the memory are analyzed to determine which sectors are being used by the software and/or firmware and which sectors are not being used. The unused space is filled with random numbers to prevent a hacker from figuring out where a program ends. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       These and other objects, features and advantages of the present disclosure will be apparent from a consideration of the following Detailed Description considered in conjunction with the drawing Figures, in which: 
         FIG. 1  is a block diagram of an intelligent electronic device (IED), according to an embodiment of the present disclosure. 
         FIGS. 2A-2H  illustrate exemplary form factors for an intelligent electronic device (IED) in accordance with an embodiment of the present disclosure. 
         FIG. 3  illustrates an example of a meter or an intelligent electronic device (IED) with security key storage in accordance with an embodiment of the present disclosure. 
         FIG. 4  is an example of functional separation security in an IED in accordance with an embodiment of the present disclosure. 
         FIG. 5  is a block diagram of another IED according to an embodiment of the present disclosure. 
         FIG. 6A  is an illustration of an exemplary communication to be received by an IED in accordance with an embodiment of the present disclosure. 
         FIG. 6B  is an illustration of encrypting a digital signature for a firmware file in accordance with an embodiment of the present disclosure. 
         FIG. 6C  is an illustration of decrypting the digital signature of  FIG. 6A  in accordance with an embodiment of the present disclosure. 
         FIG. 6D  is a flow diagram showing a method for providing security in an IED in accordance with an embodiment of the present disclosure. 
         FIG. 7  is a flow diagram showing a method for providing security in an IED using at least one remote computer in accordance with an embodiment of the present disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     Embodiments of the present disclosure will be described herein below with reference to the accompanying drawings. In the following description, well-known functions or constructions are not described in detail to avoid obscuring the present disclosure in unnecessary detail. The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any configuration or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other configurations or designs. Herein, the phrase “coupled” is defined to mean directly connected to or indirectly connected with through one or more intermediate components. Such intermediate components may include both hardware and software based components. 
     It is further noted that, unless indicated otherwise, all functions described herein may be performed in either hardware or software, or some combination thereof. In one embodiment, however, the functions are performed by at least one processor, such as a computer or an electronic data processor, digital signal processor or embedded micro-controller, in accordance with code, such as computer program code, software, and/or integrated circuits that are coded to perform such functions, unless indicated otherwise. 
     It should be appreciated that the present disclosure can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer readable medium such as a computer readable storage medium or a computer network where program instructions are sent over optical or electronic communication links. 
     Embodiments of the present disclosure will be described herein below with reference to the accompanying drawings. 
     As used herein, intelligent electronic devices (“IEDs”) can be any device that senses electrical parameters and computes data including, but not limited to, Programmable Logic Controllers (“PLC&#39;s”), Remote Terminal Units (“RTU&#39;s”), electric power meters, panel meters, protective relays, fault recorders, phase measurement units, serial switches, smart input/output devices and other devices which are coupled with power distribution networks to manage and control the distribution and consumption of electrical power. A meter is a device that records and measures power events, power quality, current, voltage waveforms, harmonics, transients and other power disturbances. Revenue accurate meters (“revenue meter”) relate to revenue accuracy electrical power metering devices with the ability to detect, monitor, report, quantify and communicate power quality information about the power that they are metering. 
     The present disclosure provides for improving security in a meter or an intelligent electronic device (IED) through the use of a security key which is unique to each meter or IED. Such a key may be used to prevent password reuse among multiple meters. Such a key may also be used to encrypt critical components of the software, such that only when running on the correct meter can the components of the software be decrypted. Such a key may also be used to uniquely identify the device in a larger data collection and management system. 
       FIG. 1  is a block diagram of an intelligent electronic device (IED)  10  for monitoring and determining power usage and power quality for any metered point within a power distribution system and for providing a data transfer system for faster and more accurate processing of revenue and waveform analysis. 
     The IED  10  of  FIG. 1  includes a plurality of sensors  12  coupled to various phases A, B, C and neutral N of an electrical distribution system  11 , a plurality of analog-to-digital (A/D) converters  14 , including inputs coupled to the sensor  12  outputs, a power supply  16 , a volatile memory  18 , an non-volatile memory  20 , a multimedia user interface  20 , and a processing system that includes at least one central processing unit (CPU)  50  (or host processor) and one or more digital signal processors, two of which are shown, i.e., DSP1  60  and DSP2  70 . The IED  10  also includes a Field Programmable Gate Array  80  which performs a number of functions, including, but not limited to, acting as a communications gateway for routing data between the various processors  50 ,  60 ,  70 , receiving data from the A/D converters  14  performing transient detection and capture and performing memory decoding for CPU  50  and the DSP processor  60 . In one embodiment, the FPGA  80  is internally comprised of two dual port memories to facilitate the various functions. It is to be appreciated that the various components shown in  FIG. 1  are contained within housing  90 . Exemplary housings will be described below in relation to  FIGS. 2A-2H . 
     The plurality of sensors  12  sense electrical parameters, e.g., voltage and current, on incoming lines, (i.e., phase A, phase B, phase C, neutral N), from an electrical power distribution system  11  e.g., an electrical circuit. In one embodiment, the sensors  12  will include current transformers and potential transformers, wherein one current transformer and one voltage transformer will be coupled to each phase of the incoming power lines. A primary winding of each transformer will be coupled to the incoming power lines and a secondary winding of each transformer will output a voltage representative of the sensed voltage and current. The output of each transformer will be coupled to the A/D converters  14  configured to convert the analog output voltage from the transformer to a digital signal that can be processed by the CPU  50 , DSP1  60 , DSP2  70 , FPGA  80  or any combination thereof. 
     A/D converters  14  are respectively configured to convert an analog voltage output to a digital signal that is transmitted to a gate array, such as Field Programmable Gate Array (FPGA)  80 . The digital signal is then transmitted from the FPGA  80  to the CPU  50  and/or one or more DSP processors  60 ,  70  to be processed in a manner to be described below. 
     The CPU  50  or DSP Processors  60 ,  70  are configured to operatively receive digital signals from the A/D converters  14  (see  FIG. 1 ) to perform calculations necessary to determine power usage and to control the overall operations of the IED  10 . In some embodiments, CPU  50 , DSP1  60  and DSP2  70  may be combined into a single processor, serving the functions of each component. In other embodiments, functions of either of the DSPs  60 ,  70  may be incorporated into the CPU  50 , thus eliminating the need to have two separate DSPs. In some embodiments, it is contemplated to use an Erasable Programmable Logic Device (EPLD) or a Complex Programmable Logic Device (CPLD) or any other programmable logic device in place of the FPGA  80 . In some embodiments, the digital samples, which are output from the A/D converters  14  are sent directly to the CPU  50  or DSP processors  60 ,  70 , effectively bypassing the FPGA  80  as a communications gateway. 
     The power supply  16  provides power to each component of the IED  10 . In one embodiment, the power supply  16  is a transformer with its primary windings coupled to the incoming power distribution lines and having windings to provide a nominal voltage, e.g., 5 VDC, +12 VDC and −12 VDC, at its secondary windings. In other embodiments, power may be supplied from an independent power source to the power supply  16 . For example, power may be supplied from a different electrical circuit or an uninterruptible power supply (UPS). 
     In one embodiment, the power supply  16  can be a switch mode power supply in which the primary AC signal will be converted to a form of DC signal and then switched at high frequency, such as, for example, 100 Khz, and then brought through a transformer to step the primary voltage down to, for example, 5 Volts AC. A rectifier and a regulating circuit would then be used to regulate the voltage and provide a stable DC low voltage output. Other embodiments, such as, but not limited to, linear power supplies or capacitor dividing power supplies are also contemplated. 
     The multimedia user interface  22  is shown coupled to the CPU  50  in  FIG. 1  for interacting with a user and for communicating events, such as alarms and instructions to the user. The multimedia user interface  22  may include a display for providing visual indications to the user. The display may be embodied as a touch screen, a liquid crystal display (LCD), a plurality of LED number segments, individual light bulbs or any combination. The display may provide information to the user in the form of alpha-numeric lines, computer-generated graphics, videos, animations, etc. The multimedia user interface  22  further includes a speaker or audible output means for audibly producing instructions, alarms, data, etc. The speaker is coupled to the CPU  50  via a digital-to-analog converter (D/A) for converting digital audio files stored in a memory  18  or non-volatile memory  20  to analog signals playable by the speaker. An exemplary interface is disclosed and described in commonly owned pending U.S. application Ser. No. 11/589,381, entitled “POWER METER HAVING AUDIBLE AND VISUAL INTERFACE”, which claims priority to expired U.S. Provisional Patent Appl. No. 60/731,006, filed Oct. 28, 2005, the contents of which are hereby incorporated by reference in their entireties. 
     The IED  10  will support various file types including but not limited to Microsoft Windows Media Video files (.wmv), Microsoft Photo Story files (.asf), Microsoft Windows Media Audio files (.wma), MP3 audio files (.mp3), JPEG image files (.jpg, .jpeg, .jpe, .jfif), MPEG movie files (.mpeg, .mpg, .mpe, .m1v, .mp2v .mpeg2), Microsoft Recorded TV Show files (dvr-ms), Microsoft Windows Video files (.avi) and Microsoft Windows Audio files (.wav). 
     The IED  10  further comprises a volatile memory  18  and a non-volatile memory  20 . In addition to storing audio and/or video files, volatile memory  18  will store the sensed and generated data for further processing and for retrieval when called upon to be displayed at the IED  10  or from a remote location. The volatile memory  18  includes internal storage memory, e.g., random access memory (RAM), and the non-volatile memory  20  includes removable memory such as magnetic storage memory; optical storage memory, e.g., the various types of CD and DVD media; solid-state storage memory, e.g., a CompactFlash card, a Memory Stick, SmartMedia card, MultiMediaCard (MMC), SD (Secure Digital) memory; or any other memory storage that exists currently or will exist in the future. By utilizing removable memory, an IED can be easily upgraded as needed. Such memory will be used for storing historical trends, waveform captures, event logs including time-stamps and stored digital samples for later downloading to a client application, web-server or PC application. 
     In a further embodiment, the IED  10  will include a communication device  24 , also known as a network interface, for enabling communications between the IED or meter, and a remote terminal unit, programmable logic controller and other computing devices, microprocessors, a desktop computer, laptop computer, other meter modules, etc. The communication device  24  may be a modem, network interface card (NIC), wireless transceiver, etc. The communication device  24  will perform its functionality by hardwired and/or wireless connectivity. The hardwire connection may include but is not limited to hard wire cabling e.g., parallel or serial cables, RS232, RS485, USB cable, Firewire ( 1394  connectivity) cables, Ethernet, and the appropriate communication port configuration. The wireless connection will operate under any of the various wireless protocols including but not limited to Bluetooth™ interconnectivity, infrared connectivity, radio transmission connectivity including computer digital signal broadcasting and reception commonly referred to as Wi-Fi or 802.11.X (where x denotes the type of transmission), satellite transmission or any other type of communication protocols, communication architecture or systems currently existing or to be developed for wirelessly transmitting data including spread spectrum 900 MHz, or other frequencies, Zigbee, Wi-Fi, or any mesh enabled wireless communication. 
     The IED  10  may communicate to a server or other computing device via the communication device  24 . The IED  10  may be connected to a communications network, e.g., the Internet, by any means, for example, a hardwired or wireless connection, such as dial-up, hardwired, cable, DSL, satellite, cellular, PCS, wireless transmission (e.g., 802.11a/b/g), etc. It is to be appreciated that the network may be a local area network (LAN), wide area network (WAN), the Internet or any network that couples a plurality of computers to enable various modes of communication via network messages. Furthermore, the server will communicate using various protocols such as Transmission Control Protocol/Internet Protocol (TCP/IP), File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), etc. and secure protocols such as Hypertext Transfer Protocol Secure (HTTPS), Internet Protocol Security Protocol (IPSec), Point-to-Point Tunneling Protocol (PPTP), Secure Sockets Layer (SSL) Protocol, etc. The server will further include a storage medium for storing a database of instructional videos, operating manuals, etc., the details of which will be described in detail below. 
     In an additional embodiment, the IED  10  will also have the capability of not only digitizing waveforms, but storing the waveform and transferring that data upstream to a central computer, e.g., a remote server, when an event occurs such as a voltage surge or sag or a current short circuit. This data will be triggered and captured on an event, stored to memory, e.g., non-volatile RAM, and additionally transferred to a host computer within the existing communication infrastructure either immediately in response to a request from a remote device or computer to receive said data in response to a polled request. The digitized waveform will also allow the CPU  50  to compute other electrical parameters such as harmonics, magnitudes, symmetrical components and phasor analysis. Using the harmonics, the IED  10  will also calculate dangerous heating conditions and can provide harmonic transformer derating based on harmonics found in the current waveform. 
     In a further embodiment, the IED  10  will execute an e-mail client and will send e-mails to the utility or to the customer direct on an occasion that a power quality event occurs. This allows utility companies to dispatch crews to repair the condition. The data generated by the meters are used to diagnose the cause of the condition. The data is transferred through the infrastructure created by the electrical power distribution system. The email client will utilize a POP3 or other standard mail protocol. A user will program the outgoing mail server and email address into the meter. An exemplary embodiment of said metering is available in U.S. Pat. No. 6,751,563, which all contents thereof are incorporated by reference herein. 
     The techniques of the present disclosure can be used to automatically maintain program data and provide field wide updates upon which IED firmware and/or software can be upgraded. An event command can be issued by a user, on a schedule or by digital communication that will trigger the IED  10  to access a remote server and obtain the new program code. This will ensure that program data will also be maintained allowing the user to be assured that all information is displayed identically on all units. 
     It is to be understood that the present disclosure may be implemented in various forms of hardware, software, firmware, special purpose processors, or a combination thereof. The IED  10  also includes an operating system and micro instruction code. The various processes and functions described herein may either be part of the micro instruction code or part of an application program (or a combination thereof) which is executed via the operating system. In one non-limiting exemplary embodiment, the IED  10  includes a general purpose operating system, e.g., Linux™, although other general purpose operating systems are contemplated to be within the scope of the present disclosure. 
     It is to be further understood that because some of the constituent system components and method steps depicted in the accompanying figures may be implemented in software, or firmware, the actual connections between the system components (or the process steps) may differ depending upon the manner in which the present disclosure is programmed. Given the teachings of the present disclosure provided herein, one of ordinary skill in the related art will be able to contemplate these and similar implementations or configurations of the present disclosure. 
     Furthermore, it is to be appreciated that the components and devices of the IED  10  of  FIG. 1  may be disposed in various housings depending on the application or environment. For example, the IED  10  may be configured as a panel meter  900  as shown in  FIGS. 2A and 2B . The panel meter  900  of  FIGS. 2A and 2B  is described in more detail in commonly owned U.S. Pat. No. 7,271,996, the contents of which are hereby incorporated by reference. As seen in  FIGS. 2A and 2B , the IED  900  includes a housing  902  defining a front surface  902   a , a rear surface  902   b , a top surface  902   c , a bottom surface  902   d , a right side surface  902   e , and a left side surface (not shown). Electrical device  900  includes a face plate  904  operatively connected to front surface  902   a  of housing  902 . Face plate  904  includes displays  906 , indicators  908  (e.g., LEDs and the like), buttons  910 , and the like providing a user with an interface for visualization and operation of electrical device  100 . For example, as seen in  FIG. 2A , face plate  904  of electrical device  900  includes analog and/or digital displays  906  capable of producing alphanumeric characters. Face plate  904  includes a plurality of indicators  908  which, when illuminated, indicate to the user the “type of reading”, the “% of load bar”, the “parameter designation” which indicates the reading which is being displayed on displays  906 , a “scale selector” (e.g., Kilo or Mega multiplier of Displayed Readings), etc. Face plate  904  includes a plurality of buttons  910  (e.g., a “menu” button, an “enter” button, a “down” button, a “right” button, etc.) for performing a plurality of functions, including and not limited to: viewing of meter information; enter display modes; configuring parameters; performing re-sets; performing LED checks; changing settings; viewing parameter values; scrolling parameter values; and viewing limit states. The housing  902  includes voltage connections or inputs  912  provided on rear surface  902   b  thereof, and current inputs  914  provided along right side surface  902   e  thereof. The IED  900  may include a first interface or communication port  916  for connection to a master and/or slave device. Desirably, first communication port  916  is situated in rear surface  902   b  of housing  902 . IED  900  may also include a second interface or communication port  918  situated on face plate  904 . 
     In another embodiment, the IED  10  may be configured as a socket meter  920 , also known as an S-base type meter or type S meter, as shown in  FIGS. 2C and 2D . The socket meter  920  of  FIGS. 2C and 2D  is described in more detail in commonly owned application Ser. No. 12/578,062 (U.S. Publication No. 2010/0090680), the contents of which are hereby incorporated by reference. Referring to  FIGS. 2C and 4D , the meter  920  includes a main housing  922  surrounded by a cover  924 . The cover  924  is preferably made of a clear material to expose a display  926  disposed on the main body  922 . An interface  928  to access the display and a communication port  930  is also provided and accessible through the cover  924 . The meter  920  further includes a plurality of current terminals  932  and voltage terminals  934  disposed on backside of the meter extending through a base  935 . The terminals  932 ,  934  are designed to mate with matching jaws of a detachable meter-mounting device, such as a revenue meter socket. The socket is hard wired to the electrical circuit and is not meant to be removed. To install an S-base meter, the utility need only plug in the meter into the socket. Once installed, a socket-sealing ring  936  is used as a seal between the meter  920  and/or cover  924  and the meter socket to prevent removal of the meter and to indicate tampering with the meter. 
     In a further embodiment, the IED  10  of  FIG. 1  may be disposed in a switchboard or draw-out type housing  940  as shown in  FIGS. 2E and 2F , where  FIG. 2E  is a front view and  FIG. 2F  is a rear view. The switchboard enclosure  942  usually features a cover  944  with a transparent face  946  to allow the meter display  948  to be read and the user interface  950  to be interacted with by the user. The cover  944  also has a sealing mechanism (not shown) to prevent unauthorized access to the meter. A rear surface  952  of the switchboard enclosure  942  provides connections for voltage and current inputs  954  and for various communication interfaces  956 . Although not shown, the meter disposed in the switchboard enclosure  942  may be mounted on a draw-out chassis which is removable from the switchboard enclosure  942 . The draw-out chassis interconnects the meter electronics with the electrical circuit. The draw-out chassis contains electrical connections which mate with matching connectors  954 , 956  disposed on the rear surface  952  of the enclosure  942  when the chassis is slid into place. 
     In yet another embodiment, the IED  10  of  FIG. 1  may be disposed in an A-base or type A housing as shown in  FIGS. 2G and 2H . A-base meters  960  feature bottom connected terminals  962  on the bottom side of the meter housing  964 . These terminals  962  are typically screw terminals for receiving the conductors of the electric circuit (not shown). A-base meters  960  further include a meter cover  966 , meter body  968 , a display  970  and input/output means  972 . Further, the meter cover  966  includes an input/output interface  974 . The cover  966  encloses the meter electronics  968  and the display  970 . The cover  966  has a sealing mechanism (not shown), which prevents unauthorized tampering with the meter electronics. 
     As described above, IED  10  may be coupled to a communication network (such as the Internet) via communication device  24  in multimedia interface  22 . Although it is advantageous for IED  10  to be coupled to the Internet, there are many security risks associated with devices coupled to the Internet. For example, IEDs (such as IED  10 ) often contain valuable and/or private information accessible through the Internet. Also, many functions (i.e., “secure functions”) of the IED may be controlled via the Internet. To protect IEDs, such as IED  10 , from unauthorized use via the Internet, improved security measures may be implemented as will be described below in accordance with the present disclosure. 
     I. Security Key 
     One security problem faced by many networked devices, including IEDs such as IED  10 , is default password reuse. Users often forget to change the default passwords, choose not to change them for ease of use, or worse yet, security is oft times left disabled. However, these defaults are often published, which makes it easy to scan for devices which still use the defaults. 
     In one embodiment, to avoid default password reuse, IED  10  is configured to force the user to configure a new password before any secure functionality is enabled, such as relay control, logging, metering, or settings configuration. For example, the first access to a web server executing on the IED may present a meter initialization page, which allows the user to enter initial settings, such as CT/PT ratios, logging configuration, energy scaling, limits, communications settings, and an initial password. Such an interface would require an external method of resetting those settings, in the event that someone unauthorized was able to access the IED before first use. 
     Another embodiment to avoid default password reuse is to generate a unique security key for each IED. This would prevent a single password from being used to scan and access multiple IEDs. For example, one IED may have a default password of ‘1234’, and another may have a default password of ‘1324’. The user would have to know what the default password for that device was specifically to access it. The user would still be able to configure their own password to override the default password. 
     One embodiment of a unique security key is to use the serial number of the IED. This has the advantage of being easy to remember on the user&#39;s part, but makes breaking the default password easier. This unique security key embodiment may be improved by generating the security key from the serial number of the IED, rather than using it directly. For example, an algorithmic permutation of the serial number, such as reversing the characters, shifting them, or bit OR-ing them with the model number of the IED, may be used. 
     Another embodiment of a unique security key is to randomly generate a key when the IED is built, and store that key in the IED, e.g., in memory  20 , and in a production database. Since the key is random, the password would have to be intercepted or stolen to break. For example, as part of the process of building the IED, a random unique key is generated, programmed into the IED using a hardware interface or IED software which is only accessible in production, and then stored in the production database for later use. 
     A key generated in production may be improved by tying it directly to the customer that ordered the IED. Such a link between the customer and key may be used to verify that a valid user is requesting the default password from the manufacturer when they have forgotten it. Such a key may also be used to prevent the resale of the IED through third parties, as only the original purchaser would have legitimate access to the default key. 
     Since it is generated in the production of the IED, such a unique security key would have to be transferred to the owner of the IED. One way to perform this is to put the key on a sticker on the side of the IED (for example, on the outside of any of the housing described in reference to  FIGS. 2A-H ), such that the user must have physical access to the IED to determine the default password. The security of using a sticker may be improved by placing the sticker on the inside of the housing of the IED, such that a casual passerby would not be able to read the key. 
     Another way to transfer the password to the user would be to include it in paperwork which comes with the IED when the IED is purchased, such as brochures, certificates, calibration reports, or a user key insert. Such a method would have the advantage that the security key may be stored separate from the IED, and may be easily destroyed by the user if they desired. 
     It is envisioned that such a method may also be used to recover a lost default security key for a customer, by cross referencing the customer&#39;s ID with the serial number. The security key may then be mailed or emailed to the customer using an address configured separate from the password request, to prevent invalid users from faking a request. 
     Storing the security key on a replaceable or removable media would allow the security key to be easily determined, as well as copied across multiple IEDs. In one embodiment, the security key is stored on an external processor or memory coupled to a first or “core” processor. The core processor is configured such that for the core processor to execute a request or a software application, the core processor must send the request or software application to the external processor to be decrypted using a security key that is only accessible on the external processor. Therefore, the core processor, which may be accessible by multiple clients outside of the IED containing the core processor, will never have access to the security key and cannot be compromised by unauthorized users. For example, referring to  FIG. 3 , an IED  300  configured to store a security key on an external processor, e.g., processor B  304 , is shown in accordance with an embodiment of the present disclosure. It is to be appreciated that, although not shown in  FIG. 3 , IED  300  includes similar components to IED  10 . 
     As shown in  FIG. 3 , IED  300  includes processor A  302 , processor B  304 , storage device  306 , and security key  308 . More specifically, processor A  302  is coupled to storage device  306  and processor B  304  and processor B  304  is coupled to security key  308 . Processor A  302  is configured to execute software and retrieve information stored in storage device  306  of IED  300 . Furthermore, processor A  302  is configured such that processor A cannot execute certain software or requests (i.e., secure functions) unless the software or requests are first decrypted. Processor A  302  cannot decrypt secure software or requests without the aid of processor B  304 ; therefore, processor A  302  will send any secure software or requests received by processor A  302  to processor B  304 . Processor B  304  is configured to receive requests and software from processor A  302  and attempt to decrypt the request or software using security key  308 . It is to be appreciated that, in certain embodiments, processor B is the only component in IED  300  that has access to security key  308 . Also, it is to be appreciated that security key  308  may be stored in processor B  304 , or alternatively, security key  308  may be stored on either volatile or non-volatile memory coupled to IED  300  (not shown). 
     The above-described embodiment allows the software running on processor A  302  to be dynamically loaded from storage  306 , such that even if storage  306  is replaced, the security key  308  is still tied to IED  300 . It is to be appreciated that, although it is not required, it is preferable that if security key  308  cannot be read, all secure functionality should be shut down. 
     Alternatively, security key  308  may serve as an “internal password” to verify that only secure software is being executed on processor A  302 . For example, a user may transmit software to IED  300  (e.g., via the Internet) to be executed on processor A  302  to perform a secure function. When processor A  302  receives the software to be executed, processor A  302  will determine the size of the software to be executed. If the size of the software to be executed is below a predetermined threshold, processor A  302  will transmit the software to processor B  304 . Processor B  304  will then attempt to decrypt the software using security key  308 . If processor B  304  is able to decrypt the software using security key  308 , processor B  304  will send the decrypted software to processor A and processor A will execute the decrypted software. However, if processor B  304  cannot decrypt the software, processor B  304  will transmit an error message to processor A  302  indicating that the software cannot be decrypted and therefore cannot be executed. In an alternative embodiment, when processor B  304  fails to decrypt the software, processor B  304  will transmit the software to processor A  302  and processor A  302  will attempt to run the software and fail. It is to be appreciated that the security key  308  is configured such that, only software that is desired by the manufacturer to be executed on IED  300  will be able to be decrypted by processor B  304  using security key  308 . 
     Alternatively, if processor A  302  determines that the software received is above a predetermined threshold, processor A  302  will send a “payload key” (that is received with the software and is part of the software package) to processor B  304  for a key allowing processor A  302  to decrypt the software. When processor B  304  receives the payload key from processor A  302 , processor B  304  will attempt to decrypt the payload key using security key  308  to produce a decrypted payload key. If processor B  304  is able to decrypt the payload key using security key  308  to produce a decrypted payload key, processor B  304  will transmit the decrypted payload key to processor A  302  and processor A  302  will use the decrypted payload key to decrypt the software and then execute the decrypted software. However, if processor B  304  is unable to decrypt the payload key using security key  308 , processor B  304  will transmit an error message to processor A indicating that the payload key cannot be decrypted and therefore the software cannot be executed. 
     As described above, processor A  302  is also configured to receive requests, such as requests to read data stored in storage device  306 . Processor A  302  is configured such that processor A  302  cannot decrypt any requests to read data stored in storage device  306 . Therefore, when processor A  302  receives a request, processor A  302  transmits the request to processor B  304 . Processor B  304  will then attempt to decrypt the request using security key  308 . If processor B  304  is able to decrypt the request using security key  308 , processor B  304  will transmit the decrypted request to processor A, and processor A will then be able to execute the request and read the requested data stored in storage device  306 . Alternatively, if processor B  304  is unable to decrypt the request using security key  308 , processor B  304  will transmit an error message to processor A, indicating that the request could not be decrypted and therefore will not be executed. It is to be appreciated that security key  308  is configured such that only legitimate requests (i.e., requests from users authorized to access the requested data) can be decrypted by processor B  304  using security key  308 . 
     It is to be appreciated that, in one embodiment, to decrypt software or requests received from processor A  302 , processor B  304  includes a cryptographic module (not shown in  FIG. 3 ). The cryptographic module includes stored instruction signals that can be executed by processor B  304 . 
     Preferably, the cryptographic module allows for the encryption and/or decryption of provided data (i.e., software and requests received from processor A  302 ). Preferably, the cryptographic module allows for both symmetric and asymmetric (e.g., Pretty Good Protection (PGP)) encryption and/or decryption. Preferably, the cryptographic module allows conventional cryptographic techniques such as, but not limited to: digital certificates (e.g., X.509 authentication framework), digital signatures, dual signatures, enveloping, password access protection, public key management, and/or the like. Preferably, the cryptographic module will facilitate numerous (encryption and/or decryption) security protocols such as, but not limited to: checksum, Data Encryption Standard (DES), Elliptical Curve Encryption (ECC), International Data Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash function), passwords, RC5 (Rivest Cipher), Rijndael, RSA (which is an Internet encryption and authentication system that uses an algorithm developed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA), Secure Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), and/or the like. The cryptographic module facilitates the process of “security authorization” whereby access to a resource is inhibited by a security protocol wherein the cryptographic module effects authorized access to the secured resource. 
     Preferably, the cryptographic module supports encryption schemes allowing for the secure transmission of information across a communications network to enable a client to engage in secure transactions if so desired by users. Most frequently, the cryptographic module communicates with information servers, operating systems, other program modules, and/or the like. The cryptographic module may contain, communicate, generate, obtain, and/or provide program module, system, user, and/or data communications, requests, and/or responses. In one non-limiting example embodiment, such a cryptographic tool may be provided as a library within the operating system accessible to all other modules in a module collection through an application program interface (API), as will be described in an embodiment below. The cryptographic tool enables local processing of authentication information. 
     In one embodiment, the cryptographic module employs transport level encryption, for example, STARTTLS. STARTTLS is a TLS (SSL) layer over the plaintext communication, allowing email servers to upgrade their plaintext communication to encrypted communication. Assuming that the email servers on both the sender and the recipient side support encrypted communication, an eavesdropper snooping on the communication between the mail servers cannot see the email contents. 
     In another embodiment, the cryptographic module employs end-to-end encryption. In end-to-end encryption, the data is encrypted and decrypted only at the end points. In other words, encrypted requests or software are unreadable by processor A  302 , and are only decrypted at processor B  304  (i.e., the request or software end point) using security key  308 . 
     It is to be appreciated that the teachings of the embodiment shown in  FIG. 3  may be implemented with IED  10  shown in  FIG. 1 . For example, in one embodiment, CPU  50  in IED  10  may contain multiple processors, including processor A  302  and processor B  304 . Furthermore, security key  308  may be included in volatile memory  18 , non-volatile memory  20 , or in one of the processors in IED  10 . Also, storage device  306  may be volatile memory  18 . Alternatively, in another embodiment, DSP1  60  in IED  10  may include one of processor A  302  or processor B  304 , and DSP2  70  in IED  10  may include whichever of processor A  302  or processor B  304  is not included in DSP1  60 . In yet another embodiment, CPU  50  may include processor A  302  and either DSP1  60  or DSP2  70  may include processor B  304 . 
     For example, in one embodiment, IED  10  is configured such that CPU  50  includes both processor A  302  and processor B  304 , and security key  308  is in non-volatile memory  20 . Communications device  24  may receive a request or software to be executed on IED  10 . The request or software will then be transmitted to CPU  50 . In CPU  50 , processor A  302  will send the request or software (or a payload key if the software is too large, as described above) to processor B  304  so that processor B  304  can decrypt the request or software (or payload key) using security key  308 . If processor B  304  is able to decrypt the request or software (or payload key), then the decrypted request or software will be transmitted to processor A  302 , where it will be executed. However, if processor B  304  is unable to decrypt the request or software (or payload key), the request or software will not be executed. 
     Storing the security key  308  externally (i.e., on a separate processor from the processor that executes secure functions) may be improved by splitting the security key  308  into multiple components, each of which comes from a different location, such that it would be harder to copy or manipulate the key  308 . For example, security key  308  may be broken into 3 components, 4 bytes each, with each component coming from a different location, such as a compact flash file, a key compiled into the core software, and an external processor. It is to be appreciated that this approach can be used with IED  10 . For example, one component of security  308  may be stored in processor B, another may be stored in non-volatile memory  20 , and another may be stored in volatile memory  18 . As another non-limiting example, the security key  308  is generated by iteratively encrypting the key with the next layer&#39;s key component, such as encrypting an external processor key with a firmware key, then encrypting the result with the file key, giving the final security key. 
     In another embodiment, splitting the security key  308  into multiple components may be improved by changing the components of security key  308 , such that the total security changes over time in a controllable manner. For example, the component of the security key  308  which comes from firmware may be changed in every firmware version, allowing the security key  308  to be changed by the manufacturer at will. As another non-limiting example, one component of the security key  308  may come from a time chip, such that the generated security key  308  changes with time, such as every hour. It is to be appreciated that the time chip may be a real time clock (RTC) coupled to the processor B  304  or integrated into processor B  304 . Furthermore, in the context of IED  10 , the time chip may be integrated into CPU  50 . 
     Dynamic security keys could be extended to apply to user programmed passwords. One embodiment of this would be to have a timeout on user programmed passwords, such that after the timeout expires, the password reverts to the default dynamic security key. In this embodiment, the user programmed password may be stored, for example, in volatile memory  18 , while the default dynamic security key is stored in non-volatile memory  20  or CPU  50 . 
     In another embodiment using dynamic security keys, the user may configure a list of multiple passwords, which the IED will change between at predetermined time intervals. For example, a list of 7 passwords is configured, one of which is used for each day of the week. As another example, a list of 24 passwords may be configured, one used for each hour of the day. 
     In yet another embodiment, a static portion and a dynamic portion of the password are configured, using either a password list, or value replacement. For example, a base passphrase of “the $ walked across the street” may be configured, and a list of 7 dynamic passwords may be configured, such as ‘cat’, ‘dog’, ‘elephant’, ‘rain’, ‘7u&amp;r’, ‘Y#!l’, ‘umbrella’. The resultant password for each day of the week would then be a combination of the base passphrase and the day&#39;s key, such as ‘the cat walked across the street’, or ‘the Y#!l walked across the street’. In the context of IED  10 , the base passphrase and dynamic passwords can be stored in non-volatile memory  20  or volatile memory  18 , while the resultant password is stored in volatile memory  18 . As another example, a base password of ‘yU63##hq’ may be configured, where the ‘##’ is replaced with the hour of the day, the minute of the hour, day of the year, number of waveform records, or some other value. It is to be appreciated a combination of the above may also be used, as well as multiple dynamic lists, as well as using a dynamic list to generate each key in another dynamic list used in the primary dynamic key. 
     Security key  308  could be further extended by separating the security key  308  from the default password, such as using the security key  308  to generate the default password, or using the default password to generate the security key  308 . Alternatively, multiple security keys may be stored, such that a public key and a private key are stored. The private key may be used for encryption and password generation purposes, and the public key may be used for unique identification. 
     The use of a public key allows for unique identification of the IED on a network, or for logging into a service. For example, the public key may be used as part of the certificate in Transport Layer Security (TLS) identification of the web server executing on the IED, allowing clients to be assured that they are communicating to the correct IED. As another example, the public key may be combined with the private key to generate a unique signature to be transmitted to a data collection server when uploading log data, to verify the origin of the data. As another example, a challenge and response protocol may require the unique signature to be transmitted to the client before they entered the password, to prevent them from sending a valid password to a fake meter trying to steal the password. As another example, the public key of the meter may be the TLS certificate. 
     II. Isolation of Security Features from External Interfaces 
     Along with more IEDs becoming network accessible, the interest in the use of common protocols to access IEDs, such as Web Servers, DNP, and IEC61850, has increased. However, many of these interfaces require the ability to perform secure actions. Additionally, many of these interfaces are well known protocols and services, making it easier to target flaws in the code. 
     In one embodiment, to prevent exposing secure actions on a networked interface, the security features are isolated from these external interfaces, such that the external interface, such as a web page, does not contain the ability to perform the secure action, but instead acts as a proxy and instructs an internal software to perform the secure action. In such an embodiment, the processing of the message and parameters are separated from the actual execution of the action. This prevents malformed messages from causing unintended side effects. Let such a configuration, where communication and security features are in separate software components, be called “functional layers.” 
     It is to be appreciated that functional layers may include internal and external software components. The ‘functional’ part references the ability of such a configuration to provide a set of functional actions, such as requesting web pages on the external layer, and resetting the device on internal layers. The ‘layer’ part references the ability of the external layers to ‘hide’ the internal layers from the outside. It is also to be appreciated that in the presently described embodiment internal and external layers can only communicate with each other through a limited API, further restricting the access from one layer to another, to only that which has been granted access to. Let the secure internal component, which has access to security features, but cannot be accessed from outside the IED, be called the “secure layer.” Let the external interface software, which cannot access the secure features, but can be accessed from outside the IED, be called the “insecure layer.” 
     Turning to  FIG. 4 , an IED  400  with a secure and insecure layer is shown in accordance with an embodiment of the present disclosure. IED  400  includes internal security component  402  (i.e., the secure layer), web server  404  (i.e., the insecure layer), security state  406 , and secure resource  408 , where web server  404  is coupled to internal security component  402  and internal security component  402  is coupled to security state  406  and secure resource  408 . It is to be appreciated that, in some embodiments, security component  402  and web server  404  may be included in a single processor  405  (as shown in  FIG. 4 ), while in other embodiments security component  402  and web server  404  may be on separate processors. Also, it to be appreciated that internal security component  402  may also include a cryptographic module (not shown in  FIG. 4 ) as described above in relation to processor B  304 . The cryptographic module can perform the same functions as those performed by the cryptographic module in processor B  304 . 
     IED  400  executes a plurality of instructions to implement a general purpose operating system, e.g., Linux™ operating system, for executing the security component  402  and the web server  404 , among other components. IED  400  is coupled to network  412  (e.g., the Internet) via web server  404 . Client  410  is coupled to network  412  to allow a user to access certain functions of IED  400 . It is to be appreciated that IED  400  includes many other components (not shown), such as those described in IED  10 , however, these additional components will not be described again in reference to IED  400  in the interest of clarity. Furthermore, it is to be appreciated that the components of IED  400  may be included in IED  10 . For example, processor  405  may be included in CPU  50 , and security state  406 . Additionally, secure resource  408  may be included in volatile memory  18  or non-volatile memory  20  or some combination thereof. Web server  404  may communicate with network  412  and client  410  via communication device  24 . 
     Turning again to  FIG. 4 , as an example of IED  400  in use, the web server  404  of the IED  400  may receive a message requesting a reset from client  410 . The web server  404  parses the parameters to do the reset, validates them, and passes the command on to an internal security component  402  that has permission to actually perform the action. As another example, a malformed request for historical logs may contain an exploit that overruns the internal buffers of the web server  404 . Because the web server  404  does not contain the ability to execute any secure action, it may crash, but it would be much harder to trigger a secure action. 
     As yet another example, a request for a secure resource  408  in IED  400 , such as, but not limited to, the list of users, may be passed through the internal security component  404 , such that the user sending the request from client  410  must first login. When the resource is requested, if the user sending the request from client  410  is not in the list of allowed users (where the list of allowed users is stored in security state  406 ) for that resource  408 , the request is denied. Since the web server  404  doesn&#39;t have access to the security list stored in security state  406 , it cannot be exploited to access it. 
     One embodiment of functional layers is to implement the internal security component  402  as a software running separately from the external interface software (i.e. web server)  404 . In such an embodiment, the layers may use network sockets, files, pipes, shared memory, mail slots, or other Inter-Process Communications, or IPC methods, to transfer information between the layers. For example, a kernel such as a Linux™ kernel, which supports functional isolation of executing software, and a security server may be used, such that only the security server (i.e., internal security component  402 ) has permission to access secure resources  408 , and all software in the insecure layers (e.g., web server  404 ) would have to communicate with the security server software  402  to gain access to these resources  408 . 
     In another embodiment of functional layers, the secure layer software  402  may be implemented on a separate component of the hardware, where such a configuration was described above in reference to  FIG. 3 . For example, the insecure software, such as a web server  404 , may be running on processor A  302 , which is connected to processor B  304  by communications lines. Processor B  304  would be running the secure software  402 , and would be the only processor that had physical connection to the secure resources  408 , such as a compact flash media (e.g., storage device  306 ) with sensitive data on it, or hardware reset lines. No communications lines, other than those for processor A  302 , would be attached to processor B  304 , preventing it from being influenced externally. 
     In addition to preventing malicious or inadvertent modifications to the system, the functional layers described in accordance with the present disclosure can also be used to enforce user security. One embodiment to enforce user security would be to keep all awareness of user permissions and states, as well as all user actions, in the secure layer, e.g., internal security component  402 . For example, updating the programmable settings may require that a user be logged in. In this embodiment, the secure layer  402  keeps track of the user state, and only allows the secure update programmable settings action to be performed if the user state is valid. It is to be appreciated that valid user states may be stored in security state  406  and secure layer  402  can determine whether the user state is valid by comparing a user state with a valid user state stored in security state  406 . If the user state is invalid, then secure layer  402  rejects the update request. As another non-limiting example, secure data, such as, but not limited to, energy data may be restricted to only certain users. User A may be allowed to read energy, but User B may not. If User A requests energy data, then the secure layer  402  returns the data values. If User B requests energy data, then the secure layer  402  returns an error value. It is to be appreciated that the users that have access to secure data may be stored in security state  406  and secure layer  402  may determine if a user attempting to access secure data is a user that is authorized to view the data. 
     Functional layers can also be used to ensure data and configuration integrity. For example, web server  404 , which provides the ability to update certain configurations of IED  400 , such as programmable settings, firmware, or software, may take a configuration file as input, and pass the configuration file to the secure layer  402  to update. The secure layer  402  then verifies the configuration is valid before continuing with the action, such as checking for valid programmable settings, or verifying the software is for the proper IED model, or has not been corrupted. As another example, another internal layer may be introduced, such as a conversion layer (not shown in  FIG. 4 ), which is configured to transform the internal stored data into a more convenient format to be used by the top layer (i.e., web server  404 ), such as converting binary historical data to text csv data to be displayed on a web page. 
     The communications between layers may be improved by encrypting the messages between the secure layer  402  and the insecure layer (e.g., web server)  404 , using the IED&#39;s unique security key, password, or some other key stored in security state  406 , and building the password security directly into the message system. For example, if web server  404  used the wrong password to encrypt a settings update request to the secure layer  402 , the secure layer  402  would reject the command as invalid. As another example, when a Modbus server requests energy readings, the secure layer  402  responds to the request with encrypted values, but the Modbus server would be unable to decrypt the values if it did not have the password. 
     III. Prevent Device Copying and Direct Application Manipulation 
     Along with external security issues, IEDs also must deal with internal security issues, such as tampering, reverse engineering, and copying. However, as IED functionality becomes more complex and feature rich, it becomes easier to tamper with and copy the software. 
     In one embodiment to preventing copying and tampering, the software loaded onto the main processor of an IED is encrypted with a security key, such that only the IED which contained the proper security key would be able to run the software. For example, a small unencrypted bootloader may load the encrypted core software, decrypt it using the security key, and load the resultant code. If the decryption failed, due to an invalid key, the software would fail to run. As another example, the core software once running, loads, decrypts, and runs functional software, where any invalid decryptions would fail to run, or crash the whole system. 
     One embodiment of encrypted software would be to store the software encrypted, and use a kernel to perform the decryption and execution of the software. In such a system, the kernel would be running on the processor, load the application from a storage media, such as CompactFlash, SDRAM, flash, or other long term storage media, and use the security key to decrypt those software to run. In addition to decrypting the software, the kernel may also provide the functionality to encrypt and store the software to be run later, though this may also be implemented through an external software available only to the manufacturer. 
     Another embodiment of encrypted software would be to use a secure layer to request the software to run, for example, using a configuration such as that described in relation to IED  400  in  FIG. 4 . In such a system, secure layer  402  would perform the decryption and verification of the software. 
     In another embodiment, the individual feature software, such as a web server or logger, are stored in a single encrypted block, such that only software which had the ability to decrypt the block would be able to determine what software and features were available. 
     In another embodiment, a second processor is used to load and decrypt the software, for example, using a configuration such as that described in relation to IED  300  in  FIG. 3 . For example, the kernel running on processor A  302  may request from processor B  304  the software for the web server. Processor B  304  would load the software from the storage media  306 , and decrypt it using the key  308  supplied by processor B  304 , and return the decrypted data. If the decryption fails, processor B  304  would return an error. In such a system, processor B  304  supplies the security key  308 . In such a system, multiple hardware component could also be replaced with multiple software components. 
     Using a security layer, such as a software (e.g., internal security component  402 ) or second processor (e.g., processor B  304 ), to decrypt and load the software would be improved by using a challenge and response to prevent direct querying of the software component. For example, if the requesting software does not respond to the challenge properly, the security layer (e.g., internal security component  402  or processor B  304 ) would respond with an error. As another example, the software challenges the security layer, and if the security layer doesn&#39;t respond properly, the software would assume the security layer is fake, and not send any secure information. 
     In addition to encrypting software, software may also be digitally keyed, such as placing a certificate in the binary, which would be verified before allowing the software to run. Such a verification could be performed as part of the decryption procedure. Additionally, since the binary is encrypted, the certificate can be reasonably assumed to be valid. 
     Digitally keying software can be extended by also keeping a manifest of software signatures, and comparing the signature of the software against the manifest before allowing it to run. Such a signature may be a checksum of the software binary, a certificate, or a pattern of known bytes in the binary. For example, referring to  FIGS. 3 and 4  the security layer  402  or processor B  304  keeps a database of the checksums (the database may be stored in security state  406  or storage device  306 ) of all known software to be run on the IED, and when a software is loaded, the checksum is compared against the stored checksum. It is to be appreciated that the comparison may be made by processor B  304  if IED  300  is being used, or by internal security component  402  if IED  400  is being used. If the comparison fails, the software is assumed to be fake, and not run. It is to be appreciated that although the components of IEDs  300  and  400  can be implemented into IED  10 , as described above, the components of IEDs  300  and  400  may be implemented into other IEDs as well, as will be described below. 
     Referring to  FIG. 5  a block diagram of a measuring unit  510 , i.e., an IED, including a network communication network card  533  for responding to user data and information requests regarding power usage and power quality for any metered point within a power distribution system  11  is shown. Furthermore, the communication card  533  is configured for sending/receiving alarm and/or notification messages. 
     The measuring unit  510  includes at least one sensor &amp; analog front end  520 , at least one analog processing and analog-to-digital (A/D) converter  522 , at least one non-volatile log memory  524 , at least one volatile work memory  526 , a power supply  528 , display and user buttons interface  530 , and a central processing unit (CPU)  532 . The CPU  532  may be a processor, the functions of which may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, read only memory (ROM) for storing software, random access memory (RAM), and nonvolatile storage. 
     The network communication card  533  may be coupled to or disposed into the measuring unit  510  to extend communication capabilities of the measuring unit  510 . These capabilities include: a Web Server that allows any Internet browser to connect to the measuring unit  510 , a Modbus Server that allows a Modbus RTU client to connect to the measuring unit  510  for transferring data and operation parameters; and other supporting services. In one embodiment, the network communication card  533  implements an email alarm/notification feature to send emails when selected events occur. When an event is retrieved or identified by the network communication card  533 , the event is classified according with user settings (as an Alarm or Notification), and an email body is created and placed into a buffer for later processing. If the event is an Alarm, the email is sent as soon as possible, for example, within a 1-minute window. If the event is a Notification, the email is sent within a user-programmed window, for example, which can range from about 5 minutes to about 24 hours. 
     The network communication card  533  is shown to include, in one embodiment, a serial communication interface  534  to communicate with the measuring unit  510  unit, a CPU  536 , non-volatile memory  538 , volatile memory  540 , an Ethernet physical interface  542  and a power supply  544 . The Ethernet physical interface  542  couples the measuring unit  510  to at least one network, e.g., the Internet, via an Ethernet link  1283 . Also, power supply  544  in the network card, for example, is a block that represents the conversion of the host provided voltage (5 VDC) from power supply  528  into a voltage suited for the network card components, and electric isolation between both power rails. 
     It is to be appreciated that, as stated above, the components of IED  300  and  400  may be implemented with other IEDs as well. For example, IED  300  may be implemented with IED  510 . Referring to  FIGS. 3 and 5 , in one embodiment, processor A  302  and processor B  304  may both be included in CPU  532 , storage device  306  may be non-volatile log memory  524  and security key  308  may be either volatile work memory  526  or non-volatile log memory  524 . It is to be appreciated that, in an alternative embodiment, processor A  302  may also be included in CPU  536 . 
     Additionally, IED  400  may be implemented with IED  510 . Referring to  FIGS. 4 and 5 , in one embodiment, web server  404  is included in CPU  536 , internal security component  402  is included in CPU  532  and security state  406  and secure resource  408  are included in non-volatile log memory  524 . In an alternative embodiment, internal security component  402  may be included in CPU  536  with web server  404  and security state  406  may be included in non-volatile work memory  524 . 
     To prevent unauthorized access to the IEDs  10 ,  300 ,  400 ,  510  several different security methods and scheme may be employed within the scope of the present disclosure. In one embodiment, Multi-factor authentication (MFA) is employed. MFA is a method of access control which a user can pass by successfully presenting several separate authentication stages which include knowledge factors, possession factors and inherence factors. Knowledge factors include a password or secret word, a personal identification number (PIN), secret questions, among others. Possession factors include a key or device, e.g., a disconnected or connected token, which only the user has. Inherence factors are factors associated with the user, and are usually biometric methods, including fingerprint readers, retina scanners or voice recognition. It is to be appreciated that the MFA may include at least one factor or any combination thereof to authenticate a user. 
     In one embodiment, a security token is used to prevent unauthorized access to IEDs  10 ,  300 ,  400 , and  510 . A security token (also known as a hardware token, authentication token, USB token, cryptographic token, software token, virtual token, or key fob) may be a physical device that an authorized user of a computer service or device is given to gain access to the information stored therein. Security tokens are used to prove one&#39;s identity electronically. Some tokens may store cryptographic keys, such as a digital signature, or biometric data, such as fingerprint minutiae. Some designs feature tamper resistant packaging, while others may include small keypads to allow entry of a PIN or a simple button to start a generating routine with some display capability to show a generated key number. Special designs include a USB connector, RFID functions or Bluetooth wireless interface to enable transfer of a generated key number sequence to a client system. 
     Security tokens include password types and physical types. Password token types include some secret information that are used to prove identity. There are four different ways in which this information can be used 1.) Static password token—The device contains a password which is physically hidden (not visible to the possessor), but which is transmitted for each authentication; 2.) Synchronous dynamic password token—A timer is used to rotate through various combinations produced by a cryptographic algorithm, where the token and the authentication server must have synchronized clocks; 3.) Asynchronous password token—A one-time password is generated without the use of a clock, either from a one-time pad or cryptographic algorithm; and 4.) Challenge response token—Using public key cryptography, it is possible to prove possession of a private key without revealing that key, the authentication server encrypts a challenge (typically a random number, or at least data with some random parts) with a public key; the device proves it possesses a copy of the matching private key by providing the decrypted challenge. 
     Password token types include time-synchronized one-time passwords and mathematical-algorithm-based one-time passwords. Time-synchronized one-time passwords change constantly at a set time interval, e.g. once per minute. Another type of one-time password uses a complex mathematical algorithm, such as a hash chain, to generate a series of one-time passwords from a secret shared key. 
     Physical token types include disconnected tokens, connected tokens, contactless tokens, Single sign-on software tokens and mobile device tokens. Disconnected tokens have neither a physical nor logical connection to the client computer or device. Disconnected tokens typically do not require a special input device, and instead use a built-in screen to display the generated authentication data, which the user enters manually themselves via a keyboard or keypad. Connected tokens are tokens that must be physically connected to the computer with which the user is authenticating. Tokens in this category automatically transmit the authentication information to the client computer or device once a physical connection is made, eliminating the need for the user to manually enter the authentication information. However, in order to use a connected token, the appropriate input device must be installed. The most common types of physical tokens are smart cards and USB tokens, which require a smart card reader and a USB port respectively. 
     Unlike connected tokens, contactless tokens form a logical connection to the client computer or device but do not require a physical connection. The absence of the need for physical contact makes them more convenient than both connected and disconnected tokens. An exemplary contactless token uses RFID to transmit authentication info from a keychain token. Another exemplary contactless token is a Bluetooth token, which is often combined with a USB token, thus working in both a connected and a disconnected state. Bluetooth authentication works when closer than 32 feet (10 meters). If the Bluetooth is not available, the token must be inserted into a USB input device to function. In the USB mode of operation sign off required care for the token while mechanically coupled to the USB plug. The advantage with the Bluetooth mode of operation is the option of combining sign-off with a distance metrics. 
     Some types of Single sign-on (SSO) solutions, like enterprise single sign-on, use the token to store software that allows for seamless authentication and password filling. As the passwords are stored on the token, users need not remember their passwords and therefore can select more secure passwords, or have more secure passwords assigned. Additionally, a mobile computing device such as a smartphone or tablet computer can also be used as the authentication device. This provides secure two-factor authentication that does not require the user to carry around an additional physical device. Some vendors offer a mobile device authentication solution that uses a cryptographic key for user authentication. This provides a high level of security protection including protection from a Man-in-the-middle attack, which can occur from a rogue Hotspot (Wi-Fi). 
     Token designs meeting certain security standards are certified in the United States as compliant with FIPS (Federal Information Processing Standard)  140 - 2 , a federal security standard. The standard provides four increasing, qualitative levels of security intended to cover a wide range of potential applications and environments. The security requirements cover areas related to the secure design and implementation of a cryptographic module. These areas include cryptographic module specification; cryptographic module ports and interfaces; roles, services, and authentication; finite state model; physical security; operational environment; cryptographic key management; electromagnetic interference/electromagnetic compatibility (EMI/EMC); self-tests; design assurance; and mitigation of other attacks. FIPS  140 - 2  defines four levels of security as follows: 
     Level 1 
     Security Level 1 provides the lowest level of security. Basic security requirements are specified for a cryptographic module (e.g., at least one Approved algorithm or Approved security function shall be used). No specific physical security mechanisms are required in a Security Level 1 cryptographic module beyond the basic requirement for production-grade components. An example of a Security Level 1 cryptographic module is a personal computer (PC) encryption board. 
     Level 2 
     Security Level 2 improves upon the physical security mechanisms of a Security Level 1 cryptographic module by requiring features that show evidence of tampering, including tamper-evident coatings or seals that must be broken to attain physical access to the plaintext cryptographic keys and critical security parameters (CSPs) within the module, or pick-resistant locks on covers or doors to protect against unauthorized physical access. 
     Level 3 
     In addition to the tamper-evident physical security mechanisms required at Security Level 2, Security Level 3 attempts to prevent the intruder from gaining access to CSPs held within the cryptographic module. Physical security mechanisms required at Security Level 3 are intended to have a high probability of detecting and responding to attempts at physical access, use or modification of the cryptographic module. The physical security mechanisms may include the use of strong enclosures and tamper detection/response circuitry that zeroes all plain text CSPs when the removable covers/doors of the cryptographic module are opened. 
     Level 4 
     Security Level 4 provides the highest level of security. At this security level, the physical security mechanisms provide a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access. Penetration of the cryptographic module enclosure from any direction has a very high probability of being detected, resulting in the immediate zero-ization of all plaintext CSPs. 
     IV. Decrypting Files in the Meter 
     Regarding security within a meter or IED, it can be important to determine whether the programs running on the meter contain the proper software and firmware. If someone has tampered with the meter and installed software or firmware that has not been authorized, or modified the firmware in such a way to cause the meter to operate improperly, then such a condition should be detected. 
     According to some embodiments of the present disclosure, the IED  10 ,  300 ,  400 , or  510  may be configured to check the legitimacy of the software and firmware at various stages. For example, in one embodiment, an IED, such as IED  10  is configured to a self-check at different times, such as when the IED is initially put in operation for the first time, when the IED is rebooted or powered up after a power down procedure, after a firmware update, or after other events when the IED is started up. 
     During manufacture, various security components can be loaded onto the IED. For example, a hash function and an encryption algorithm, as will be described below, may be implemented as a part of a code belonging to a firmware stored in a memory of the IED. As will be described in greater detail below, the hash function and encryption algorithm may be configured for use with a digital signature to test the authenticity and integrity of certain communications received by the IED. Also, the IED may contain (e.g., in a memory) a public key that corresponds to a private key that is kept separately from the public key by a sender. These hash functions, public and private keys, encryption/decryption algorithms, and digital signatures are security components that may operate in coordination with corresponding security components on authorized remote devices throughout the system described below in accordance with the present disclosure. Loading these security components on the various devices throughout the system when the system is created allows the devices to communicate with each other securely and to ensure that devices have not been improperly tampered with. 
     The IED  10 ,  300 ,  400 ,  510  of the present disclosure is configured to test the integrity and authenticity of firmware updates before installing firmware updates on the IED. The communication interface or network interface  22 ,  542  may be configured to receive firmware update files or packages in the form of one or more network packets from a remote computer (e.g., a server in communication with the IED). In this example, a received firmware package or update file may include an unencrypted file and a digital signature, among other things. 
     For example, referring to  FIG. 6A , an exemplary received communication or firmware package  650  is shown in accordance with the present disclosure. It is to be appreciated that communication or package  650  may be received as one or more network packets. Communication  650  may include a header  652 , cyclic redundancy check (CRC)  653 , unencrypted file or firmware raw data  654 , digital signature  656 , and footer  658 . It is to be appreciated that communication  650  may include other data or information not shown in  FIG. 6A  for the sake of clarity. 
     The communication  650  is received by a processor of an IED (e.g., processor  50 ) via a communication interface of the IED (e.g., interface  22 ). The communication  650  received by the IED is configured to be in a predetermined format (e.g., a format associated with a firmware update) that is recognizable by the processor of the IED. In this way, if the processor of the IED does not recognize the format of the communication  650  as being the predetermined format, the processor is configured to determine that the integrity of the communication  650  has been compromised (e.g., some of the data that is supposed to be in communication  650  has not been received by the processor of the IED) and the processor will not use the firmware raw data in file  654  to update the firmware installed on the memory of the IED. In one embodiment, if the processor determines the communication  650  is not in the predetermined format, the processor is configured to output an error message. 
     The CRC  653  in the communication  650  is also used by the processor of the IED to determine the integrity of the communication  650 . After receiving the communication  650 , the processor of the IED is configured to compute a CRC associated with the received communication  650 . Then, the processor is configured to determine whether the CRC computed by the processor of the IED matches the CRC  653  included in the communication  650 . If the processor of the IED determines the CRC  653  does not match the CRC computed by the IED, then the processor is configured to determine that the integrity of the communication  650  has been compromised and the processor will not use the firmware raw data in file  654  to update the firmware installed on the memory of the IED. In one embodiment, if the processor determines the computed CRC does not match the CRC  653 , the processor is configured to output an error message. 
     The unencrypted file  654  may include any firmware data needed to upgrade a firmware package installed on a memory of an IED, such as memory  20  of IED  10 . As opposed to the unencrypted file  654 , the digital signature  656  may be an encrypted hash value. The hash value may be encrypted by the sender using any suitable encryption algorithm that is known by both the sender (e.g., the remote computer sending the communication  650  to the IED) and receiver (e.g., IED  10 ) to create the digital signature  656 . For example, in one embodiment, the hash value is encrypted using Elliptic Curve Digital Signature Algorithm (ECDSA) secp256r1 to create digital signature  656 . 
     At least one processor of the IED, such as CPU  50  of IED  10 , is configured to decrypt the digital signature  656  using the known encryption algorithm to obtain a specific value (i.e., the hash value used to create the digital signature  656 ), which is described in greater detail below. In addition to decrypting the digital signature  656  to obtain the specific value, the processor is also configured to apply a hash function to the unencrypted file  654  to obtain a hash value. It is intended that the specific value obtained by decrypting the digital signature  656  is the same as the hash value obtained from hashing the unencrypted file  654  to ensure the authenticity of the firmware raw data in unencrypted file  654 . Therefore, the specific value from the digital signature  656  is the expected hash value. If the processor of the IED determines that the hash value of the unencrypted file  654  matches the expected hash value (i.e., the value obtained by decrypting digital signature  656 ), then the processor is configured to determine that the unencrypted file  654  is authentic or legitimate and is safe to use the file  654  to upgrade a firmware stored on a memory of the IED, such as memory  20 . 
     The processor of the IED is configured to perform the decrypting of the digital signature  656  to obtain the expected hash value in one step and execute the hash function on the unencrypted file  654  to obtain the hash value in another step. According to various embodiments, the steps may be performed in either order or simultaneously. After these steps are executed by the processor, the processor is configured compare the two values to determine whether the two values match. 
     It is to be appreciated that the header  652  and footer  658  may include relevant information used by the processor of the IED to perform the integrity and authenticity tests (e.g. comparing hash values of the file  654  and signature  656 ) of the firmware raw data in unencrypted file  654 . For example, the header  652  may include information indicating what firmware is embedded in unencrypted file  654 , the location of the firmware within file  654  (i.e., where the firmware begins and ends within file  654 ), etc. 
     For security, any reliable cryptographic hash function or hash algorithms may be used by the processor of the IED to hash the unencrypted file  654 . As mentioned above, this same cryptographic hash function is executed at the sender&#39;s end to create the digital signature  656  and at the receiver&#39;s end (i.e., at the IED) to obtain the hash value of the unencrypted file  654 . For example, some exemplary, reliable hash functions may include Secure Hash Algorithm (SHA) 0, SHA-1, SHA-2, SHA-256, Message-Digest Algorithm (MD)2, MD4, or MD5. In some embodiments, the hash value may be a 160-bit value. In some embodiments, the digital signature may be used to authenticate both the sender and receiver for security purposes. 
     The package or communication  650  containing the unencrypted file  654  and digital signature  656  may be sent to the IED, e.g., via communication interface  22  in one or more transmissions or network packets. Multiple transmissions may be performed to increase security. For example, one transmission may include the unencrypted file  654  and another transmission may include the digital signature  656 . 
     One or more of the processors  50 ,  60 ,  70 ,  80 ,  302 ,  304 ,  532  of the IED may be configured to decrypt the digital signature  656  and perform the hash function on unencrypted file  654 . The processor or processors then compare(s) the decrypted value from the digital signature  656 , which is the expected hash value, with the actual hash value obtained from executing the hash function on the unencrypted file  654 . If the processor(s) determine(s) the expected hash value obtained from decrypting the digital signature  656  and the hash value obtained from executed the hash function on the encrypted file  656  are the same, then the processor(s) determines that the firmware raw data in unencrypted file  654  is authentic. When it is determined by the processor that there is a match, the processor is configured to use the firmware raw data in the unencrypted file  654  to upgrade the firmware stored within a memory of the IED, such as memory  20 , as needed. 
     If it is determined by the processor that the calculated hash value does not match the expected hash value, then the processor is configured to determine that the firmware raw data in file  654  is not authentic. In this scenario, the processor does not install the upgrade or modify the firmware when the values do not match. Instead, the processor is configured to generate an error message that may be outputted by the processor for display on the front panel interface or user display. For example, in IED  10 , CPU  50  may generate an error message, including a description of the nature of the error, and output the error message to multimedia interface  22  to be displayed on the front panel of IED  10 . In some embodiments, an error message may be sent to a client device via the Ethernet link  1283  or some other suitable communication can be transmitted to an authorized person to indicate the nature of the error. 
     Regarding the encryption and decryption of the digital signature  656 , the embodiments of the present disclosure may utilize public-key cryptography using a set of cryptographic algorithms. The IED of the present disclosure pre-stores the public key in a memory, such as memory  20 . The sender of the communication  650  (e.g., a remote computer) stores a private key corresponding to the public key. In one embodiment, the IED is configured, such that, the public key may only be updated after certain security measures have been taken. In other embodiments, the IED is configured, such that, the public key cannot be updated at all. It is to be appreciated that methods for securely accessing and updating the public key are described below. 
     For use in the system described in the present disclosure, corresponding pairs of public keys and private keys can be computationally obtained. As with hash function cryptography that produces hash values, public-key cryptography uses a one-direction type of algorithm for obtaining the public keys. Even if the public key is received by an unauthorized person, it is nearly impossible for a hacker to reverse engineer the public key to determine the private key. 
     In some implementations, authentication of the unencrypted file  654  may involve hashing the file  654  to produce a hash value and encrypting the hash value with the private key to produce the digital signature  656 . The processor of the IED is configured to verify the digital signature  656  by computing the hash value of the file  654 , decrypt the digital signature  656  with the public key, and comparing the computed hash value with the decrypted hash value. If the processor determines they are the same, the processor of the IED determines that the file  654  in a received communication  650  is authentic. 
     The difference between hash function processing and public key processing is that the same hash function must be used at both ends of a communication (e.g., by both the sender and receiver), whereas public keys utilize asymmetric algorithms in which a key used by one party to perform either encryption or decryption is not the same as the one used by the other party. In this form of cryptography, each user has a pair of cryptographic keys—a public encryption key and a private decryption key. When transmitting digital signatures, such as digital signature  656 , a private signing key and a public verification key may be used. It is to be appreciated that on the part of the sender (i.e., the remote computer sending communication  650 ), the private key is never to be published. Furthermore, on the part of the receiver (i.e., an IED, such as IED  10 , that receives communication  650 ), the public key is never to be published, and may only be updated if certain levels of security are met (as will be described below). 
     Referring to  FIG. 6B , an illustration of how digital signature  656  is encrypted by a remote computer is shown in accordance with the present disclosure. As shown in  FIG. 6B , a hash function  660  is executed on firmware raw data (i.e., in unencrypted file  654 ) by a remote computer to produce a hash value  662 . Then, the remote computer uses an encryption algorithm  666  and a private key  664  on the hash value  662  to produce the digital signature  656 . The digital signature  656  is then sent to the an IED, such as any of IEDs  10 / 300 / 400 / 510  along with the unencrypted firmware raw data file  654 . 
     Referring to  FIG. 6C , an illustration of how the digital signature created in  FIG. 6B  by a remote computer is decrypted by an IED, such as any of IEDs  10 / 300 / 400 / 510  in accordance with the present disclosure is shown. As shown in  FIG. 6C , the digital signature  656  is received by the IED (e.g., via a communication interface). The IED then uses a public key (stored in a memory of the IED) and encryption algorithm  666  to unencrypt the digital signature  656  to recover the hash value  662  used to originally create the digital signature  656 . Although not shown in  FIG. 6C , the IED may also be configured to apply the hash function  660  to the unencrypted firmware raw data file  654  to obtain the hash value  662 . 
     Referring to  FIG. 6D  a flow diagram is shown illustrating an embodiment of a method  600  for providing security to an IED (e.g., IED  10 ,  300 ,  400 ,  510 ) in accordance with the present disclosure. The method  600  includes a first step  602  that may be performed during the manufacturing of the IED. Step  602  includes pre-storing a public key in a memory of the IED, such as, memory  20  of IED  10 . 
     In step  604 , a processor of the IED, such as CPU  50 , receives a communication (e.g., communication  650 ) via a communication interface, such as interface  22 , from a remote device configured for communication with the IED, e.g., a computer, server, etc. The received communication includes a firmware package containing a CRC  653 , an unencrypted file  654 , and a digital signature  656 . 
     As described above, the received communication  650  may be configured in a predetermined format. In step  606 , the processor of the IED checks the file format of the received communication  650  to determine if the received communication  650  is in the predetermined format. If the processor determines that the received communication  650  is not in the predetermined format, in step  608 , the processor is configured to generate and provide an error message indicating the firmware of the IED was not updated, in step  622 . In one embodiment, the processor generates the error message and provides or outputs the error message for display on a display of the IED itself and/or sends the error message via a communication interface to a responsible party or authorized user for following up with the error. It is to be appreciated that the processor of the IED is configured such that the message may be sent by the processor to the responsible party in any one of a plurality of communication modalities, such as, but not limited to, e-mail, text message, etc. 
     If the processor determines that the received communication  650  is in the predetermined format, in step  608 , the processor is configured to calculate a CRC based on the received communication  650 , in step  610 . In step  612 , the processor is configured to determine if the calculated CRC matches the CRC  653  received in communication  650 . If the processor determines that the calculated CRC does not match the received CRC  653 , in step  612 , the processor is configured to provide an error message and not update the firmware of the IED (as described above), in step  620 . 
     If the processor determines that the calculated CRC matches the received CRC  653 , in step  612 , the processor is configured to decrypt the digital signature  656  using the public key  668  to obtain a first value, in step  614 . It is to be appreciated that if the digital signature  656  is valid, the first value represents the expected hash value of the unencrypted file  654 . In step  616 , the processor is configured to execute a specific hash function (e.g., included as part of a firmware stored in a memory of the IED) on the unencrypted file  654  to obtain a second value, which is the hash value of the unencrypted file  654 . 
     In step  618 , the processor is configured to determine whether the first and second values match. If it is determined by the processor that the first and second values are the same, in step  618 , the processor is configured to update or upgrade firmware stored in a memory of the IED using the unencrypted file  654  (e.g., the firmware raw data in file  654 ), in step  620 . However, if it is determined by the processor of the IED that the first and second values do not match, in step  618 , then the processor is configured to generate and provide the error message and not update the firmware of the IED, in step  622  (as described above). 
     In one embodiment, if the processor determines that the file format of communication  650  does not match the predetermined file format (in step  606 ) or that the calculated CRC does not match the received CRC  653  (in step  612 ) or that the first value does not match the second value (in step  618 ), the processor is configured to initiate a lockout timer to prevent a user from attempting to upgrade the IED for a predetermined period of time. While the lockout timer is active, the processor is configured such that any received communications, packages or messages are ignored for the predetermined lockout period. 
     The processor of the IED may be configured to check the integrity (i.e., steps  608 ,  610 ,  612  described above) and/or the authenticity (i.e., steps  614 ,  616 ,  618  described above) of a firmware package (i.e., communication  650 ) used to update firmware stored in the memory of the IED at various stages. For example, in one embodiment, the IED is configured to check or test the integrity and/or authenticity of a firmware package when the IED or meter is rebooted or powered up after a power down procedure, or after other events when the IED is started up. It is to be appreciated that in these and other scenarios, the processor of the IED may only perform steps  606  through  622  of method  600  during a bootup of the IED. For example, the storing of the hash function and/or public key may be stored in a memory of the IED when the IED is manufactured and not upon a reboot. Additionally, upon reboot, the IED may not necessarily receive a new package. Although upon reboot, the IED will perform steps  606  through  622  before properly entering run mode. 
     In another embodiment, upon a reboot, if it is determined by the processor of the IED in step  618  that the first and second values are not the same, the processor may be configured to stay in boot mode continuously, i.e., in an infinite loop, rendering the IED useless. 
     V. Logging Changes Made in the IED 
     Another example of security that may be used to authenticate transmission of files between a remote computer and the IED  10 ,  300 ,  400 ,  510  includes an embodiment where a processor of the IED, such as CPU  50 , is configured to maintain a log of any changes that are made to the software, firmware and/or the configuration settings in the IED. In this respect, the processor is configured to store the log of changes made to the IED&#39;s firmware and/or configuration settings that may be referred to as a meter profile in a memory of the IED, such as, the memory  20 ,  524 ,  538 . In this embodiment, the processor is configured to continuously update the meter profile stored in the memory of the IED whenever changes to the IED are made. 
     According to various embodiments of the present disclosure, the meter profile may include various parameters and various configuration settings (e.g., Potential Transformer and Current Transformer ratios). The processor of the IED (e.g., any of  50 ,  60 ,  70 ,  80 ,  302 ,  304 ,  532 ,  536 ) may be configured to record various changes to the configuration settings in the IED in the meter profile. For example, whenever a file in the IED is updated, upgraded, or modified in any manner, the processor stores details of the changes that were made, a person responsible for making the changes, times and dates of changes, etc. A log of the changes to the meter profile can then be generated and stored by the processor having records of the details of any changes made during the life of the IED. In some embodiments, the meter profile may be password protected. In other embodiments, additional security measure may be taken to protect the meter profile, as will be described in greater detail below. 
     The list of events that enable the addition of a new entry to the meter profile by the processor of the IED is shown in the table below: 
     
       
         
           
               
            
               
                   
               
               
                 Register Type 
               
            
           
           
               
               
               
            
               
                   
                 Name 
                 Code 
               
               
                   
                   
               
               
                   
                 Runtime status 
                 00H 
               
               
                   
                 Password 
                 01H 
               
               
                   
                 Device profile update 
                 02H 
               
               
                   
                 Firmware update 
                 03H 
               
               
                   
                 Clock change 
                 04H 
               
               
                   
                 Test Mode 
                 05H 
               
               
                   
                 Log download 
                 06H 
               
               
                   
                 Reset 
                 07H 
               
               
                   
                 System initialization fail 
                 08H 
               
               
                   
                 Serial number change 
                 09H 
               
               
                   
                 Boards bio-byte update 
                 0AH 
               
               
                   
                 Vswitch change 
                 0BH 
               
               
                   
                 Security 
                 0CH 
               
               
                   
                 Clock compensation 
                 000DH 
               
               
                   
                 SCL file update 
                 000EH 
               
               
                   
                 User&#39;s access 
                 000FH 
               
               
                   
                 Meter re-initialization 
                 0010H 
               
               
                   
                 TOU profile update 
                 0011H 
               
               
                   
                 “Watchdog” events 
                 0012H 
               
               
                   
                 Device profile update details 
                 0013H 
               
               
                   
                   
               
            
           
         
       
     
     VI. Remote Firmware Verification 
     According to some implementations, an IED, such as IED  10 , may further be configured to enable a remote computer (e.g., client device or server) to verify whether the firmware running on the IED is authentic. The processor of the IED may be configured to calculate a hash value of the firmware operating on the device. The hash value for the firmware can be obtained using any suitable hash function as described above. In one embodiment, the remote computer is configured to communicate with the IED via a communication interface, such as interface  22 , to request the hash value of the firmware calculated by the processor of the IED. In some embodiments, the processor of the IED is configured to send the calculated hash value to the remote computer in response to a request from the remote computer. 
     In one embodiment, after receiving the calculated hash value from the IED, the remote computer is configured to compare the received hash value with an expected hash value representing an authentic version of the firmware that should be operating on the IED. The expected hash value is calculated by the remote computer by executing the same hash function executed by the IED over an authentic version of the firmware. It is to be appreciated that in some embodiments, only a portion of the firmware raw data is tested by executing a hash function on the portion of the firmware raw data, where the portion is called a block of data. It is further to be appreciated that the IED and remote computer execute the hash function on the same block of data to compare whether the hash values match and if the firmware on the IED is authentic. 
     If the remote computer determines that the values do not match, the remote computer determines that the firmware running on the IED is not the proper version and that the firmware has been compromised. The remote computer is then configured to send a message to the processor of IED indicating the firmware running on the IED is not the proper version or has been altered. Once the message is received by the processor (via the communication interface), the processor may be configured to take appropriate action (e.g., initiate a lockout timer or send an error message to authorized personnel, as described above). 
     It is to be appreciated that in certain embodiments, the hash value calculated by the processor of the IED is not enough to determine the firmware and/or software is authentic, since if the hash results become known to an unauthorized third party user (or hacker) and/or IED can send the “hash” results without performing the hash. In one embodiment, to prevent this, a random seed number (e.g., a 32-byte random seed number or hexadecimal value) may be sent to the processor of the IED by the remote computer, where the processor of the IED incorporates the seed into the hash calculation making the hash value a unique result. The remote computer then retrieves this unique hash result from the IED and compares the unique hash result to an expected hash value which was determined by the remote computer using the same seed originally sent to the IED. If the remote computer determines that the values do not match, it is determined by the remote computer that the firmware is not the proper version or is not authentic and that the firmware has been compromised. As stated above, the remote computer may then generate and a send a message to the processor of the IED to inform the processor of the IED that the firmware is not authentic or is not the proper version so that the processor may take necessary action. 
     As described above, in some embodiments, the processor of the IED may be configured to perform the hash function on only a portion of the firmware in the memory of the IED to obtain the hash value. The portion of the firmware selected to execute the hash function on may be selected by the processor of the IED, or alternatively, may be selected in response to a command from the remote computer (i.e., chosen by a remote user or randomly selected by the remote computer). 
     VII. Preventing the Detection of Programs Operating on the IED 
     The present disclosure further describes other security measures that can be taken to protect IEDs from third party attacks. For instance, a hacker may attempt to determine the various software and/or firmware programs being executed by the processor on the IED. To protect the IED from such hacking attempts, security can be added to the working memory, such as the volatile memory or RAM  18 ,  526 ,  540 . It is to be appreciated that the techniques described below may also be incorporated non-volatile memory of the IED, such as non-volatile memory  20  of IED  10 . 
     According to this example, the processor of the respective IEDs described in the present disclosure may be configured to execute various steps to impede a hacker in an unauthorized pursuit to determine the programs running in the working memory  18 ,  526 ,  540 . The processor is configured to first determine which of the sectors in the working memory are being utilized by the software/firmware programs to perform its various functions and which ones are not being utilized. Alternatively, the processor may be configured to determine how many of the sectors in the overall memory space are not being utilized. For example, it may be determined by the processor that the firmware only utilizes about a third of the overall working memory. Knowing the unused sectors, the processor may be configured to fill these unused sectors with random, arbitrary values. In this way, the extra values may impede a hacker trying to determine which parts of the memory contain the software/firmware code or where the programs start and end within the memory. 
     In one embodiment, the processor may be configured to find unused sectors of memory that result from areas of a firmware data of the IED that are populated with zeroes (e.g., unused memory). Knowledge of these unused areas within the memory of the IED may aid a hacker in faking hash values obtained by performing hash functions over portions of the firmware that are unused. Therefore, by filing these unused areas, the hacker&#39;s objective of faking the correct hash values is made more difficult. 
     It is to be appreciated that, in one embodiment, the processor of the IED is configured to determine unused areas of the firmware raw data in unencrypted file  654  after receiving a communication  650 . Furthermore, the IED is configured to fill the unused areas within the firmware raw data before using the firmware raw data to update the firmware of the IED. In another embodiment, the remote computer sending the communication  650  to the IED is configured to determine the unused areas of the firmware raw data in unencrypted file  654  and fill the unused areas within the firmware raw data before sending the communication  650  to the IED. 
     In some implementations, the processor of the IED or the remote computer may simply insert random numbers into the empty sectors of memory or the empty sectors of the firmware. In other implementations, the processor of the IED or the remote computer may fill the unused sectors with scrambled lines of code from the software/firmware, slightly altered code, or even code intentionally designed to perform arbitrary calculations, such as code that does not correspond to any meter functions. In some implementations, the processor of the IED or the remote computer will insert random numbers so no empty sectors remain, i.e., completely filling the memory; while in others, the processor of the IED or the remote computer may insert random numbers in just a portion of the empty sectors to obscure where a firmware or software ends. 
     It is to be appreciated that other housings and mounting schemes for the IED, e.g., circuit breaker mounted, panel mounted, socket or S-based mounted, etc., are contemplated to be within the scope of the present disclosure. Metal seals and security labels may be employed to prevent tampering with the IED itself or may be employed to indicate tampering. In one embodiment, a sealing switch is provided in, for example, a recess of the housing of the IED. The sealing switch may be disposed behind a door or cover which is secured with, for example, a metal seal. In certain embodiments, the sealing switch may be used to add an additional layer of security to sensitive information stored in the memory of the IED, e.g., memory  20  of EID  10 . In one embodiment, IED  10  includes a sealing switch  25  (shown in  FIG. 1 ), where sealing switch  25  is included in the housing of IED  10  and may be pressed to send a signal a processor of IED, such as any of CPU  50 , DSP1  60 , DSP2  70 , or FPGA  80 . It is to be appreciated that any of the processor of IED  10  may be configured to determine based on receiving one or more signals from sealing switch  25 , whether sealing switch  25  has been pressed and how long sealing switch  25  has been pressed for. 
     For example, in one embodiment, a request may be received from a user via a communication interface of the IED (e.g., a USB port, optical port, Ethernet port, etc.) to access and/or make changes to sensitive information stored in a memory of the IED or to access a specific feature of the IED. In some embodiments, the IED may be configured such that to access some or all of this sensitive information stored in the memory of the IED or a specific feature of the IED, the sealing switch must be pressed. In one embodiment, the sealing switch is coupled to the processor of the IED, such that, when the sealing switch is pressed, a signal is sent to the processor from the sealing switch. In response to the signal from the sealing switch, the processor is configured to allow a user access to some or all of the sensitive information stored in the memory of the IED. In some embodiments, in addition to requiring the sealing switch to be pressed, the processor may be configured to require a password to be entered to access the sensitive information stored in memory. In some embodiments, the processor is configured to provide access to the sensitive information only for a predetermine period of time after the sealing switch has been pressed. 
     In one embodiment, the processor may be configured such that the sealing switch must be pressed to enable changes to be made to the meter profile described above. When a change to the meter profile is desired, the seal securing the sealing switch is broken and the door or cover opened to expose the sealing switch. The sealing switch is then depressed to send a signal to the processor, where, in response to the signal received by the processor, the processor is configured to activate a timer to allow changes to the meter profile for a predetermined period of time. After the timer runs out, the processor is configured to require the user to depress the sealing switch again to make further changes. 
     In one embodiment, the processor of the IED may be configured such that passwords to the IED may only be changed locally at the IED after the sealing switch has been activated. For example, as described above, the public key may be stored in a memory of the IED, such as memory  20 . In some embodiments, the processor of the IED is configured such that to change the public key, the processor must first receive a signal from the sealing switch indicating the sealing switch has been pressed. After receiving the signal indicating the sealing switch has been pressed, the processor is configured to allow the public key to be changed. 
     In another embodiment, the sealing switch and/or a password may be used to protect one or more communication ports of the communication interface of the IED. For example, as described above, IED  10  includes communication interface  22 . Interface  22  may include multiple ports, e.g., USB, Ethernet, optical, 485 serial, etc., for communication. In one embodiment, the processor or CPU  50  of IED  10  may be configured to require the sealing switch to be pressed and/or a password to be entered for communication to be received through one or more of the ports of interface  22 . For example, to send communication to CPU  50  via the USB port of interface  22 , CPU  50  may be configured to require either or both the sealing switch to be pressed and/or a password to be entered. 
     The IED of the present disclosure may also be configured to employ several modes or levels of security using the sealing switch and one or more passwords. For example, in one embodiment, the IED may include four different modes of security based on the states of the password and the security switch: (1) No Security—In this mode, the processor of the IED is configured such that it does not require the sealing switch to be pressed or for a password to be entered for a user to gain access to the IED; (2) Minimum Security—In this mode, the processor is configured to require a password to be entered to gain access to some or all of the sensitive information and/or functions of the IED; (3) High Security—In this mode, the processor is configured to require both a password and for the sealing switch to be pressed to gain access to some or all of the sensitive information and/or functions of the IED; (4) Maximum High Security—In this mode, the processor is configured to require both a password and for the sealing switch to be pressed to gain access to some or all of the sensitive information and/or function of the IED (like the High Security mode). Additionally, in Maximum High Security mode, the processor is configured such if the IED is currently in this security mode, the processor does not allow the user to change to a different security mode. In this mode, to change to a different security mode, the IED must be returned to the factory. In some embodiments, when the IED is in Maximum High Security, the processor is configured such that the public key cannot be changed. 
     In another embodiment, the processor of the IED may be configured to simultaneously support multiple user accounts (e.g., 8 different accounts), where each account has different user privileges to different features of the IED (e.g., changing a clock value, accessing various metering data, enabling or disabling a feature, etc.). For example, a first user may access the IED by providing a first password to the processor of the IED. The first user&#39;s account may only be configured to have access to revenue data or other information, without having the ability to make any changes to the configuration of the IED. A second user may access the IED by providing a second password to the processor of the IED. The second user&#39;s account may allow changes to be made to the configuration (e.g., metering profile described above) of the IED or to change the public key or other stored passwords within the IED. It is to be appreciated that for each of the different privileges or features associated with a user&#39;s account, the processor of the IED may additionally require the user to press the sealing switch before accessing a certain feature of the IED. It is to be appreciated that the passwords and user privileges for each different account may be stored in a memory of the IED, such as memory  20  of IED  10 . 
     It is to be appreciated that in any of the above described embodiments where the processor requires a password to be entered by a user so that the user can gain access to the IED, the processor may further be configured to keep track of the amount of times a user attempts to access the IED by entering an incorrect password. In one embodiment, if the user enters an incorrect password a predetermined number of times, the processor is configured to initiate a lockout period where the IED is rendered inaccessible by the user. 
     In some embodiments of the present disclosure, the IED may be configured to employ a test clock mode of operation to verify operation of an internal clock. During a test clock mode of operation, the IED may be configured to periodically generate a light pulse through a light emitting diode (LED), where the light pulse generated is synchronized with the IED&#39;s internal clock. The generated light pulse can be used by a user to compare the IED&#39;s internal clock to an external reference clock to test the accuracy of the IED&#39;s internal clock. The processor of the IED may be configured to enable test mode of operation in response to a user request. In one embodiment, IED  10  includes front panel interface  23 , where interface  23  includes an LED disposed on the front panel of the IED  10  designed as an internal clock indicator. In this embodiment, a processor of IED  10  (e.g.,  50 ,  60 ,  70 ,  80 ) is configured to initiate the test clock mode of operation and generate pulses of light via interface  23  and the LED disposed on the front panel of the IED, where the pulses of light are synchronized with the internal clock of IED  10 . In one embodiment, the processor of IED  10  is configured to emit pulses of light continuously every 5 minutes on the minute mark. It is to be appreciated that if the pulses of the internal clock indicator do not match the external clock reference this may be an indication that the IED has been tampered with and that certain calculations may be inaccurate, for example, revenue metering calculations. 
     In one embodiment, an IED, such as IED  10 , may be configured to employ certain “hardening” techniques to provide additional security to the IED and reduce vulnerabilities. For example, in some embodiments, the processor of the IED (e.g., CPU  50 ) may be configured such that after a user has gained access to the IED, the processor allows the user to disable communication with the IED via one or more ports of the communication interface of the IED. For example, in one embodiment, communication interface  22  of IED  10  includes a plurality of communication ports, e.g., USB port, optical port, Ethernet port, etc. In this embodiment, CPU  50  is configured to allow a user with access to the IED to disable one or more of the ports of communication interface  22 . For example, a user may disable the USB port of interface  22 , while leaving the other ports of interface  22  active. Alternatively, a user may disable all ports of communication interface  22 . It is to be appreciated that the privilege or ability to disable communication through a port of the communication interface of the IED may be granted only to certain users. For example, the processor of the IED may be configured to only allow users of certain accounts, i.e., having varying levels of access, to disable communication through a port of the communication interface of the IED. Additionally, the processor of the IED may require an additional password to be entered (separate from a user account password) to allow a user to disable a communication port of the IED. In other embodiments, the processor of the IED may require the sealing switch (described above) to be pressed before allowing a user to disable communication through a port of the communication interface of the IED. In other embodiments, the processor of the IED may be configured such that a predetermined password and a press of the sealing is required to disable a communication port of the IED. It is to be appreciated that the input from the user to disable one or more of the ports of the IED may be entered at the IED, e.g., via a keypad of the IED, a touchscreen of the IED, etc., or remotely from an external device coupled to the IED by a cable or over a network, e.g., the Internet. 
     VIII. Intelligent Electronic Device Firmware Integrity and Authentic Operation 
     In one embodiment, the IED  10  shown in  FIG. 1  of the present disclosure contains four embedded firmware for 3 different hardware components: FPGA  80 , DSP  60  or  70  and PowerPC (PPC)  50  Two of the four firmware running in IED  10  are running inside PPC  50  and are called PPC boot and PPC runtime. In one embodiment, the IED  10  loads the FPGA  80 , DSP  60  and/or  70  and PPC&#39;s  50  runtime firmware from a file saved into compact flash memory  20 . The PPC&#39;s boot firmware is loaded from a flash that may be part of the PPC  50 . 
     It is to be appreciated that all firmware has a file, and there is a file for each version released. Those files are the files used to upgrade the firmware inside the IED  10 . In one embodiment, all firmware versions are mapped into a Modbus register to be exposed outside of the IED. But how does the meter or IED guarantee that the firmware running in the meter or IED are each the actual, authentic firmware represented by their version number? In other words, how to guarantee the firmware authenticity? In one embodiment to ensure firmware authenticity, the PPC runtime and boot firmware has included a cryptography function to be executed over either firmware file (FPGA and DSP), SDRAM (PPC runtime) and/or Flash (PPC boot) to generate a number, which is unique for each firmware version. That number can be exposed through Modbus to outside the IED and be compared with a returned number from the same function executed outside of the IED by a remote computer (as described above) over firmware files. If those numbers match (as determined by the remote computer and/or a processor of IED  10 ), then it is determined that the software running inside the IED is the one represented by their versions numbers (i.e., the firmware is authentic and has not been compromised). In one embodiment, the cryptography function used by the IED is SHA-256. 
     But in the real world, a hacker still may be able to modify the code of the firmware stored on the IED while still guaranteeing that the IED returns the correct hash number, then the cryptography function also need to be modified by the hacker. For doing this modification, the hacker is going to need memory space for this modification. To make the hacker&#39;s intention in modifying the code on the IED more difficult and to give more reliability for the firmware code running on the IED, a processor of the IED, where it is applicable (e.g., PPC runtime and boot), is configured to populate unused area of the code in memory with random or arbitrary numbers and code. 
     In one embodiment, a processor of IED  10  (e.g.,  50 ,  60 ,  70 ,  80 ) is configured to communicate with a remote computer via communication interface  22  to test if the firmware running on IED  10  is authentic. As will be described below, in some embodiments, a user on the remote computing device may choose or configure various aspects of the authenticity test of the firmware running on the IED  10 , such as, but not limited to, which firmware is tested, which blocks within the firmware are tested, random seed number used, etc. 
     The test consists of randomly selecting a data area inside a firmware file of the IED, called a block, which is represented by a start address (e.g., absolute position, in bytes, inside the firmware file, started from the beginning of the file) and a length (e.g., number of block of 128 bytes) then concatenating a random seed (e.g., a 32-byte seed, although other byte sizes may be employed) in the beginning of this block and computing the hash. A processor of IED  10 , such as CPU  50 , computes and returns a hash evaluated over a seed concatenated within a memory area representing the block. This hash is provided to the remote computer and the remote computer employs the test to compare the hash calculated by the IED with an expected hash of the remote computer and gives a result that it is either approved (if both hashes match) or not approved (if both hashes do not match). Below a method  700  executed on a remote computer for testing the authenticity of the firmware on an IED is described. 
     Referring to  FIG. 7 , method  700  for testing the authenticity of a firmware on the IED is shown in accordance with the present disclosure. Initially, a remote computer (e.g., in one embodiment, client  410 ) in communication with an IED, such as IED  10 , is configured to enable a user to select a firmware included in a memory of the IED, in step  702 . In one embodiment, the remote computer includes software with a user interface that is configured to enable a user to browse the firmware on the IED and select a firmware. For example, the software may include a mapping to one or more memory components of an IED, such as IED  10 , e.g., memory  20 . In one embodiment, the user may select from FPGA  80 , Blackfin  70 , PowerPC  50  runtime, PowerPC  50  boot as the available firmware of the IED. In one embodiment, the software of the remote computer is configured to display each firmware name and its current version running on the IED. In step  704 , the remote computer is configured to enable a user to select a firmware stored in a local memory of the remote computer, where the firmware selected from the local memory of the remote computer is a known authentic version of the firmware and firmware version selected from the memory of the IED in step  702 . 
     It is to be appreciated that in some embodiments, the entire raw firmware data of the selected firmware in step  702  and  704  may be configured to be tested. In one embodiment, the software of the remote computer is configured to allow a user to select a data block of the selected firmware to be tested, where a data block is a subset of the raw firmware data of the selected firmware. In one embodiment, the software of the remote computer is configured to allow a user to select a number of data blocks of the selected firmware to be tested, where each block will be tested separately. Referring again to  FIG. 7 , in step  706 , the software of the remote computer is configured to allow a user to select the number of data blocks of the selected firmware (from steps  702  and  704 ) to be tested. It is to be appreciated that if a user does not select a number of blocks to be tested (e.g., within the software the user leaves this field blank), in one embodiment, the software of the remote computer is configured to automatically select the entire firmware raw data to be tested or the entirety of the portions of the firmware raw data that may be validly tested (as described below). 
     While for some firmware, all of the data inside the firmware raw data of the firmware is configured to be tested, in some embodiments, some of the firmware raw data may be configured such that only certain portions of the firmware raw data may be tested. In these embodiments, the software of the remote computer may be configured to only allow a user to select the data blocks within the portions of the firmware raw data that are configured to be tested and return an error if a block other than those blocks are selected by the user. Additionally, if the user does not make any selection of blocks to be tested, the software of the remote computer may be configured to automatically select one or more of the blocks that are configured to be tested. 
     For example, in one embodiment, PPC runtime firmware is configured such that only two portions of data within the firmware raw data of PPC runtime may be tested. In this embodiment, the software of the remote computer may be configured to only allow a user to select the data blocks within the PPC runtime firmware that are within the portions of data that are configured to be tested. Alternatively, the software remote computer may be configured to automatically select blocks that are configured to be tested if the user does not make any selection as to which blocks of the PPC runtime firmware should be tested. It is to be appreciated that, in each new version of a firmware, for example, PPC runtime, the portion of the firmware raw data that is configured to be tested may be different, i.e., having a different location within the firmware raw data and being of a different size for each firmware version. The software of the remote computer is configured to determine the location and size of the portions of the firmware, e.g., PPC runtime, that are configured to be tested for each version of the firmware and only allow a user to select data blocks within those testable portions. 
     Referring again to  FIG. 7 , after selecting the number of data blocks of the selected firmware to be tested, in step  706 , the software of the remote computer may be configured to allow a user to select a start address within the firmware raw data for each block of the number of data blocks selected, in step  708 . In step  710 , the software of the remote computer may be configured to allow a user to select a length in bytes for each block of the number of blocks selected. In this way, in steps  708  and  710  the user may define the exact location of the block of data within the firmware raw data to be tested. It is to be appreciated that, in some embodiments, the software of the remote computer may be configured to randomly select a location for each data block within the firmware raw data (e.g., a random start address and length for each block in step  708  and  710 ). Furthermore, if the user leaves the fields for the start address and length of each block blank, the software may be configured to pick a default start address and length for each block. Also, the software is configured such that, the software prevents the user from typing a start address and length for a block that results in a block size that is larger than the firmware file size or that is not a valid block that can be hashed. The software further prevents the user from typing an invalid length, such as zero for a block. It is to be appreciated that in one embodiment, the length of a block is represented by the number of 128 byte blocks (1=128 bytes, 8=1024 bytes). 
     In step  712 , the software of the remote computer is configured to allow a user to select a seed number for each block of data. The software is configured such that if the user leaves the seed field blank, the software can pick a random seed number to populate the field. In one embodiment, the seed number may be a 32-byte number that is entered/displayed in hexadecimal. In one embodiment, the software is configured to allow the user to edit the seed field, but the software prevents the user from typing any digits out of hexadecimal value representation. In one embodiment, in step  712 , the software of the remote computer is configured to automatically select a random seed number. 
     It is to be appreciated that in one embodiment, the software of the remote computer may include a selection of a feature by the user that directs the software to automatically perform each of steps  708 - 712 . For example, in one embodiment, the software includes a refresh button that is selectable by the user. The user may press the refresh button when the user wants the software to generate a random set of start address, length and seed for each block. It is to be appreciated that, for this feature, the software is configured to only select blocks within the firmware raw data that are valid to be tested (e.g., if PPC runtime is selected the software will only select from the two valid blocks within power PPC runtime firmware that are configured to be tested). 
     In step  714 , the software of the remote computer is configured to concatenate each seed number with the corresponding firmware block for the firmware stored in the local memory of the remote computer. In one embodiment, each seed is concatenated with the beginning of the start address of each block selected in step  708 . In step  716 , the software of the remote computer is configured to execute a hash function over each block of data (i.e., defined in steps  708  and  710 ) and seed for the corresponding block (i.e., selected in step  712 ) to obtain hash values for each block of data/corresponding seed for the selected firmware stored in the local memory of the remote computer. For example, if three blocks for a selected firmware were defined and selected in steps  706 - 710 , and three seeds were selected in step  712  for each of the three blocks, then the software of the remote computer will obtain three hash values in step  716  for the blocks within the selected firmware stored in the local memory of the remote computer. 
     In step  718 , the remote computer will send a request to the IED (e.g., IED  10 ) to execute the same hash function executed by the remote computer on the selected firmware stored in the memory of the IED. It is to be appreciated that the hash function is to be executed by the IED on the same block locations in the selected firmware of the IED as the block locations that were selected in the firmware stored in the local memory of the remote computer using the same seed numbers used by the remote computer. To achieve this, the request sent to the IED by the remote computer includes the name and version of the firmware that is to be tested, the location of each block to be tested, and the seed number to be concatenated to each block to be tested. 
     The request is received by the processor of the IED (e.g., processor  50 ) via a communication interface of the IED (e.g., interface  22 ). In response to the request, the processor of the IED will execute the hash function on the selected blocks of the firmware stored in the memory of the IED concatenated with the selected seeds to obtain hash values for each block/seed concatenation. The processor of the IED is then configured to transmit these hash values (i.e., via a communication interface, such as interface  22 ) to the remote computer. In step  720 , the remote computer will receive the hash values from the IED. It is to be appreciated that in one embodiment, the software of the remote computer is configured such that if the remote computer determines after receiving the hash values from the IED, that some of the blocks requested to be tested have not been tested by the IED, the remote computer will periodically resend the request of step  718  to the IED until each of the hash values for each block to be tested by the IED have been received by the remote computer. 
     After receiving the hash values from the IED, in step  720 , the software of the remote computer is configured to compare the hash values received from the IED with the hash values calculated by the remote computer (i.e., in step  716 ), in step  722 . In one embodiment, the software of the remote computer is configured to generate a report that is displayed to the user with the results and parameters all tests performed by the IED and the software of the remote computer, in step  724 . It is to be appreciated that the report may be generated before receiving the hash values from the IED in step  720  and may be updated as more results and information is received. It is to be appreciated that the software of the remote computer may contain an option the save the report generated. In one embodiment, the report may contain:
         Test number: This is related with the number of blocks to be tested   Timestamp: When the test starts with an accuracy of msec   Address: The start and end address of each block   Input/Output: seed+hash computed over the firmware file(input), hash returned by the IED (output)   Status: In progress, finished with failure, finished with match if the hash computed over each block by the remote computer matches with the one computed by the IED over the same block, finished with mismatch if the hash computed over one of the blocks by the remote computer does not match with the hash computed by the IED over the same block.   Duration (msec): Time to send request to the meter to perform the hash until it gets back with finished status       

     In step  726 , if the software of the remote computer determines that some or all of the hash values received by the IED do not match the hash values calculated by the remote computer, the software of the remote computer is configured to send a message to the IED indicating the hash values do not match, in step  728 . In one embodiment, after receiving this message sent by the remote computer in step  728 , the processor of the IED is configured to determine the selected firmware in the memory of the IED is not authentic and appropriate action may be taken. Alternatively, in step  728 , if the software of the remote computer determines that all of the hash values received by the IED match the hash values calculated by the remote computer, the software of the remote computer is configured to send a message to the IED indicating the hash values match, in step  730 . After receiving the message sent in step  730 , the processor of the IED is configured to determine that the selected firmware in the memory of the IED is authentic. 
     The IED  10  is configured to test the firmware authenticity of a downloaded firmware file before using it to update an existing firmware on the IED. As described above, each firmware file that is downloaded includes a digital signature embedded (i.e., as described above in relation to  FIGS. 6A, 6B, 6C ). In one embodiment, that digital signature is a 64-byte number obtained when the remote computer that sends the firmware file to the IED uses, for example, an ECDSA secp192r1 or secp256r1 encryption algorithm and a private key over a 32-byte hash number, described above. When a firmware file is sent to the IED for updating an existing firmware on the IED, the IED is configured to evaluate a SHA-256 function over the received file and decrypt the digital signature using a public key burned into the IED inside its FLASH memory, e.g., flash memory  20 . If a processor of the IED, e.g., CPU  50 , determines that the hash value obtained from SHA-256 matches the hash value obtained from the decryption, then the processor of the IED determines that it is allowed to update the firmware using the downloaded firmware file. 
     The PPC boot is a firmware residing in on-board flash memory of the IED comprising of two parts: boot-loader and pre-runtime. The boot is the first code executed when the IED starts up. The boot-loader configures processor registers to map memory, set system clock, etc. It also copies pre-runtime from on-board flash to on-board SDRAM memory, where the pre-runtime is executed. The pre-runtime is the core of the boot where firmware/hardware initialization/diagnostic and/or firmware/file updates are performed and PPC runtime firmware is called and executed. The PPC runtime is the core of the IED. A processor of the IED, e.g., CUP  50 , is configured such that unused areas of memory are populated with random numbers. Those random numbers may populate either code or data unused area. 
     It is to be appreciated that the various features shown and described are interchangeable, that is a feature shown in one embodiment may be incorporated into another embodiment. 
     While non-limiting embodiments are disclosed herein, many variations are possible which remain within the concept and scope of the present disclosure. Such variations would become clear to one of ordinary skill in the art after inspection of the specification, drawings and claims herein. The present disclosure therefore is not to be restricted except within the spirit and scope of the appended claims. 
     Furthermore, although the foregoing text sets forth a detailed description of numerous embodiments, it should be understood that the legal scope of the present disclosure is defined by the words of the claims set forth at the end of this patent. The detailed description is to be construed as exemplary only and does not describe every possible embodiment, as describing every possible embodiment would be impractical, if not impossible. One could implement numerous alternate embodiments, using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims. 
     It should also be understood that, unless a term is expressly defined in this patent using the sentence “As used herein, the term ‘______’ is hereby defined to mean . . . ” or a similar sentence, there is no intent to limit the meaning of that term, either expressly or by implication, beyond its plain or ordinary meaning, and such term should not be interpreted to be limited in scope based on any statement made in any section of this patent (other than the language of the claims). To the extent that any term recited in the claims at the end of this patent is referred to in this patent in a manner consistent with a single meaning, that is done for sake of clarity only so as to not confuse the reader, and it is not intended that such claim term be limited, by implication or otherwise, to that single meaning. Finally, unless a claim element is defined by reciting the word “means” and a function without the recital of any structure, it is not intended that the scope of any claim element be interpreted based on the application of 35 U.S.C. § 112, sixth paragraph.