Computer system and method for providing secure password management for design and manufacturing processes

Abstract

A computer-implemented method for authenticating software loaded in a device during a device manufacturing process having one or more manufacturing stages. A unique identifier first key is generated for encrypting software to be loaded on the manufactured device. The first key is loaded onto the secure device for storage on the server. A unique identifier second key is generated to be included as a parameter with software to be loaded on the manufactured device, whereby the second key is encrypted with the first key. The encrypted second key is incorporated in the device as a software parameter and then decrypted with the first key stored in the computer server to authenticate the software loaded on the device during its manufacture.

Description

TECHNICAL FIELD

[0001] The disclosed embodiments relate generally to verifying software properties of computing devices, and more specifically, to distributing software verification secrets common to a product family into manufacturing environments and processes. BACKGROUND

[0002] During the manufacturing process of a device that includes computer software and / or firmware, it is often necessary to inject cryptographic secrets (e.g., encryption keys or salts used in hash parameters) into the device during the manufacturing process of the device. This often requires that the secrets be securely handled as they are provided to various manufacturing stages, and securely handled at the manufacturing facility and during the manufacturing process. The demand for secure systems and applications is growing. Currently, secure integrated circuits (ICs) are often programmed with secure keys at the factory floor. The secure keys can be used in a variety of ways, such as to protect stored data, control access to digital content, or encrypt / authenticate data used in transactions. Today, these keys can be stored in one-time programmable memory that can hold the keys directly, or hold a base key that is used with a cryptographic function to generate derived keys for various functions.

[0003] Existing solutions for deploying unique secrets (e.g., device authenticity keys and certificates) for each product exist with companies such as PrimeKey. However, such existing solutions are often complex and cumbersome in the manufacturing process of the device. Therefore, there is a need to provide an improved and efficient process for distributing secrets common to a product family into manufacturing environments and processes. SUMMARY

[0004] The purposes and advantages of the illustrated embodiments will be set forth in part in the description which follows, and in part will be obvious from the description or can be learned by practice of the illustrated embodiments. The advantages of the illustrated embodiments will be realized and attained by means of the instrumentalities, systems, and methods particularly pointed out in the written description and claims hereof as well as the appended drawings.

[0005] To achieve these and other advantages, and in accordance with the purposes of the illustrated embodiments, in one aspect, a computer-implemented method and system for distributing secrets (e.g., symmetric cryptographic keys) common to a product / device family into manufacturing / design process environments and processes preferably utilizes a physical device that protects sensitive data while also being tamper-resistant and hardened, such as a hardware security module (HSM).

[0006] In one aspect, there is provided a computer implemented method for authenticating software loaded in a device during a manufacturing process of the device having one or more manufacturing stages, wherein a unique identifier first key is generated for encrypting software to be loaded on a manufactured device. The first key is loaded onto a secure device for storage on a server. A unique identifier second key is generated which is to be included as a parameter with software to be loaded on a manufactured device, whereby the second key is encrypted with the first key. The encrypted second key is incorporated as a software parameter in the device, which is subsequently decrypted with the first key stored in a computer server to authenticate the software loaded on the device during the manufacturing process of the device.

[0007] In another aspect, there is described a computer implemented method for authenticating / verifying software loaded in a manufactured device during its manufacturing process, the manufacturing process comprising a plurality of manufacturing stages, wherein a unique identifier first key is generated which is to be associated with software to be loaded on a device during the manufacturing process of the device. The first key is preferably loaded onto N hardware security modules (first HSMs). A unique identifier second key is then generated which is to be included as a parameter with software to be loaded on a device during the manufacturing process of the device, whereby the second key is encrypted with the first key from one of the first HSMs. The first HSMs are then loaded on a computer server associated with an intermediate manufacturing stage of the device. Access credentials to the first HSM with key 1 are then sent to the computer server associated with the intermediate manufacturing stage. The encrypted second key is then sent to an initial manufacturing stage, such that the encrypted second key is incorporated as a parameter in at least a first software to be loaded in the device, which is then sent to the intermediate manufacturing stage with the incorporated encrypted second key. The software with the incorporated encrypted second key is sent from the intermediate manufacturing stage to a final manufacturing stage, for loading on the device as a software parameter. From the final manufacturing stage to the intermediate manufacturing stage, the first key stored in the first HSM is then requested (preferably via utilization of access credentials to the first HSM) to decrypt the second encrypted key incorporated as a parameter in the software loaded on the device, in order to authenticate the software loaded on the device during the manufacturing process. BRIEF DESCRIPTION OF DRAWINGS

[0008] Thus, the device and method of the present subject disclosure will be readily understood by those skilled in the art, and the conventional aspects thereof, without excessive experimentation as to its construction and operation, upon the conceptual understanding of the preferred illustrative embodiments thereof, which will be described in detail hereinafter with reference to certain drawings, wherein:

[0009] Figure 1 An example communication network for use with one or more illustrative embodiments is shown;

[0010] Figure 2 Example network devices / nodes are shown for use with one or more illustrated embodiments; and

[0011] Figure 3 and Figure 4 is a flowchart showing an exemplary computer-implemented method for providing secure password management for manufacturing processes according to an illustrated embodiment. DETAILED DESCRIPTION

[0012] The illustrated embodiments now will be described more fully hereinafter with reference to the accompanying drawings, in which like

[0013] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the application belongs. Although any methods and materials similar or equivalent to those described herein can be used in the practice or testing of the illustrated embodiments, exemplary methods and materials are now described.

[0014] It must be noted that, as used herein and in the appended claims, singular articles "a", "an" and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to "a stimulus" includes multiple such stimuli, reference to "a signal" includes reference to one or more signals and equivalents thereof known to those skilled in the art, and so forth.

[0015] It should be appreciated that the illustrated embodiments discussed below preferably are software algorithms, programs or code that reside on computer usable media, having control logic for enabling execution on a machine having a computer processor. The machine typically includes a memory configured to provide an output of the execution of the computer algorithms or programs according to the illustrated embodiments.

[0016] As used herein, the term "software" is meant to be synonymous with any code or program that can be executed in a processor of a host computer, regardless of whether the implementation is in hardware, firmware, or as a software computer product available on a disk, memory storage device, or for download from a remote machine. The embodiments described herein include such software to implement the above equations, relationships, and algorithms. Based on the above embodiments, those skilled in the art will understand further features and advantages of the illustrated embodiments. Therefore, the illustrated embodiments are not limited to what has been specifically shown and described, except as indicated by the appended claims.

[0017] Turning descriptively now to the drawings, in which like reference numerals represent like elements throughout the several views, Figure 1 An exemplary communication network 100 is depicted in which the embodiments shown below may be implemented. It should be understood that the communication network 100 is a geographically distributed collection of nodes interconnected by communication links and segments for transmitting data between end nodes, such as personal computers, workstations, smart phone devices, tablets, televisions, sensors and / or other devices, such as cars. Many types of networks are available, ranging from local area networks (LANs) to wide area networks (WANs). LANs typically connect nodes via dedicated, proprietary communication links located in the same common physical location, such as a building or campus. On the other hand, WANs typically connect geographically dispersed nodes via long-distance communication links, such as public carrier telephone lines, optical paths, synchronous optical networks (SONET), synchronous digital hierarchy (SDH) links, or power line communications (PLC).

[0018] Figure 1 is a schematic block diagram of an example communication network 100, schematically including nodes / devices 101-108 (e.g., sensors 102, client computing devices 103 (e.g., cryptographic security devices), smart phone devices 105, web servers 106, routers 107, switches 108, databases, etc.) interconnected by various communication methods. For example, link 109 can be a wired link or can include a wireless communication medium, where certain nodes communicate with other nodes based on, for example, distance, signal strength, current operating status, location, etc. In addition, as will be understood by those skilled in the art, each device can communicate data packets (or frames) 142 with other devices using a predefined network communication protocol (e.g., various wired protocols and wireless protocols, etc.) where appropriate. In this case, a protocol consists of a set of rules that define how nodes interact with each other. Those skilled in the art will understand that any number of nodes, devices, links, etc. can be used in a computer network, and the view shown here is for simplicity. In addition, although the embodiments are shown here with reference to a general network cloud, the description here is not limited thereto and can be applied to hardwired networks.

[0019] As those skilled in the art will appreciate, the various aspects of the illustrated embodiments can be embodied as a system, method, or computer program product. Accordingly, aspects of the illustrated embodiments can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects that can all generally be referred to herein as a "device," "apparatus," "module," or "system." Furthermore, aspects of the illustrated embodiments can take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

[0020] Any combination of one or more computer readable medium(s) can be utilized. The computer readable medium can be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium can be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. A computer readable signal medium can include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal can take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium can be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0021] The program code embodied on the computer readable media can be transmitted using any appropriate medium, including but not limited to wireless, wired, optical fiber cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++, Python, etc., and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).‎

[0022] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0023] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0024] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0025] Figure 2is a schematic block diagram of an example network computing device 200 (e.g., a cryptographic security device 103, a server 106, etc.) that can be used with (or components thereof) one or more embodiments described herein (e.g., as one of the nodes shown in network 100) for providing computer-implemented processes for securely distributing secrets (e.g., symmetric cryptographic keys) that are preferably common to a family of products / devices into manufacturing / design process environments (400 in Figure 4 and processes (300 in Figure 3 As described above, in different embodiments, these different devices are configured to communicate with each other in any suitable manner, e.g., via communication network 100.

[0026] Device 200 is intended to represent any type of computer system capable of executing the teachings of the various illustrated embodiments. Device 200 is only one example of a suitable system and is not intended to limit the scope of use or functionality of the illustrated embodiments described herein. Regardless, computing device 200 is capable of implementing and / or executing any of the functionality set forth herein, particularly for securely distributing secrets that are preferably common to a family of products / devices into manufacturing / design process environments, preferably utilizing HSMs for protecting the secrets.

[0027] It is to be appreciated and understood that computing device 200 can operate in many other general purpose or special purpose computing system environments or configurations. Examples of well- known computing systems, environments, and / or configurations that can be suitable for use with computing device 200 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, network PCs, minicomputer systems, and distributed data processing environments that include any of the above systems or devices, and the like. Computing device 200 can be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules can include routines, programs, objects, components, logic, data structures, and the like that perform particular tasks or implement particular abstract data types. Computing device 200 can be practiced in distributed data processing environments where tasks are performed by remote processing devices that are linked through a communications network 100. In a distributed data processing environment, program modules can be located in both local and remote computer system storage media including memory storage devices.‎

[0028] The components of the device 200 can include, but are not limited to, one or more processors or processing units 216, a system memory 228, and a bus 218 that couples various system components including the system memory 228 to the processing unit 216. The bus 218 represents one or more of any of various types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus. The computing device 200 typically includes a variety of computer system readable media. Such media can be any available media that is accessible by the device 200 and it includes both volatile and non- volatile media, removable and non-removable media.

[0029] The system memory 228 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 230 and / or cache memory 232. The computing device 200 can further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 234 can be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown and typically called a "hard drive"). Although not explicitly shown, a magnetic disk drive can also be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive can be provided for reading from or writing to a removable, non-volatile optical disk (such as a CD-ROM, DVD-ROM or other optical media). In such instances, each can be connected to the bus 218 by one or more data media interfaces. As will be further depicted and described below, the memory 228 can include at least one program product having a set (e.g., at least one) of program modules 240 that are configured to carry out the functions of the embodiments, such as for securely distributing secrets, preferably common to a family of products / devices, into a manufacturing / design process environment, preferably utilizing an HSM to protect the secrets (e.g., software signatures).‎

[0030] By way of example, and not limitation, program / utility 240, having a set (at least one) of program modules 215 (e.g., underwriting modules) can be stored in memory 228, along with an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, can include an implementation of a networking environment. Program modules 215 generally carry out the functions and / or methodologies of the illustrated embodiments described herein.

[0031] The device 200 can also communicate with one or more external devices 214, such as a keyboard, a pointing device, a display 224, etc.; one or more devices that enable a user to interact with the computing device 200; and / or any devices (e.g., network card, modem, etc.) that enable the computing device 200 to communicate with one or more other computing devices. Such communication can be facilitated by an input / output (I / O) interface 222. Furthermore, the device 200 can be capable of communicating with one or more networks, such as a Local Area Network (LAN), a General Wide Area Network (WAN), and / or a public network (e.g., the Internet) via a network adapter 220. As pictured, the network adapter 220 communicates with the other components of the computing device 200 via the bus 218. It should be appreciated that although not shown, other hardware and / or software components that can be used in connection with the device 200. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

[0032] Figure 1 and Figure 2 It is intended to provide a brief description of a suitable exemplary environment in which the embodiments described below can be implemented. Figure 1 and 2 are examples of suitable environments and are not intended to suggest any limitation as to the structure, scope of use, or functionality of the illustrated embodiments. Particular environments should not be interpreted as having any dependency or requirement

[0033] With the exemplary communication network 100( Figure 1 ) and computing device 200( Figure 2 ) generally illustrated and discussed above, a description of certain illustrated embodiments will now be provided. It should be appreciated and understood that the exemplary embodiments implementing Figures 1-4 one or more components are directed to computer devices and processes for securely distributing secrets, preferably in device software and / or firmware, which are preferably common to a product / device family, into a manufacturing / design process environment, preferably utilizing an HSM to protect the secrets. It should be appreciated and understood that the manufactured devices referred to herein can be comprised of any suitable manufactured device (e.g., circuit breaker components, non-circuit breaker components, control panel components, smart devices, etc.) having software (S / W) and / or firmware (F / W) embedded therein during its manufacturing process, where the security of such embedded S / W, F / W is important to prevent counterfeiting and / or malicious tampering of the embedded S / W, F / W.

[0034] According to the illustrated embodiments, each HSM used herein can be comprised of any known type of hardware security module suitable for use according to the illustrated embodiments, including, for example, a YubiHSM Crypto Hardware Security Module. It should be understood and appreciated that, Figures 1-4 A brief, general description of an illustrative and / or suitable exemplary environment in which the illustrated embodiments can be implemented is provided herein. In this regard, Figure 1 is shown, which depicts an example of a suitable computing environment 100 in which the illustrated embodiments can be implemented. As will be appreciated, however, embodiments can be practiced according to a variety of computing environments, as well as in other types of environments. Figures 1-4 Further described, the illustrated embodiments include securely distributing secrets, preferably common to a product / device family, through the design / manufacturing process to provide protection of the secrets, such as private or symmetric keys, or secret salts required by the device. It should be understood and appreciated that the process of generating secrets, such as symmetric keys, is known and therefore need not be described herein.

[0035] According to the illustrated embodiment, in the following process (300) for protecting a secret, the actual secret (secret 2) is not provided to the manufacturing phase (400), preferably as a parameter in the Indus firmware (F / W) or production F / W, in encrypted form. A first symmetric key (key 1) for encrypting / decrypting the secret 2 is generated and preferably securely loaded onto N HSMs (with N > 1 for redundancy) with public access credentials, where N-1 HSMs are preferably kept at the research and development (R&D) phase (402) and / or securely maintained in one or more entities (e.g. secure locations) as backups, and one HSM with key 1 is provided to the manufacturing phase (e.g. 406) from which. All unprotected forms of key 1 are permanently shredded / destroyed after loading on the N HSMs with key 1. Preferably, the HSM with key 1 sent to some manufacturing phase (e.g. 406) is installed on a computer server (e.g. 106), preferably in a physically secure location at the manufacturing phase (406) (e.g. manufacturing plant). The credentials for accessing the HSM with key 1 are preferably sent to the manufacturing phase (e.g. via secure network communication channels / apps) with the HSM with key 1 out of band, and loaded in the server application for accessing the HSM with key 1. A second secret (secret 2) is then generated, and where if secret 2 is also a key, it is preferably loaded onto M separate HSMs with access credentials (for redundancy purposes), and these M HSMs with key 2 are also preferably kept by R&D (e.g. 402) and / or the generating entity, and likewise stored in secure or other reliable locations. Secret 2 is then encrypted using the HSM with key 1 loaded thereon. The encrypted key 2 is then preferably provided to the Indus F / W or production F / W team (e.g. 404) to be included as a parameter in the F / W and / or S / W of the device to be manufactured. Preferably, the encrypted key 2 is stored on a USB stick or similar storage device, and preferably kept in the same secure location as the HSM with key 1 kept by the R&D or key / secret generating entity related to the device manufacturing process 400. All unencrypted / unprotected forms of secret 2 are likewise permanently shredded / destroyed.

[0036] During the initial phase (402) of the manufacturing process (400), the Indus or production F / W in the device under production (the device) provides the encrypted secret 2 included as a parameter in the Indus or production F / W via the secure communication network / channel of the manufacturing process 400 to the factory's HSM with key 1, preferably via an API on the server, requesting the HSM with key 1 to decrypt the secret 2. Using the access credentials provided above, the server application accesses the HSM with key 1 which then uses key 1 to decrypt the provided encrypted secret 2. The unencrypted secret 2 is then sent, preferably through the same secure communication network / channel, to the production phase (408) of the manufactured device, so that the unencrypted secret 2 is then stored, preferably in a trusted platform module or other secure element related to the manufactured device.

[0037] It should be understood and appreciated that if the secret 2 is an encrypted key required for encrypting new / additional F / W and / or S / W items, the aforementioned HSM with key 2 will be used to encrypt such new F / W and / or S / W items. Moreover, if the HSM with key 2 fails, R&D (phase 402) preferably utilizes one of its HSMs with key 1 to decrypt the secret 2, preferably stored in encrypted form on a USB stick, in order to then load the unencrypted secret 2 onto the new HSM. The unencrypted / unprotected form of the secret 2 is then again shredded / destroyed.

[0038] By way of a brief description of the illustrated embodiments provided above, and with reference to Figure 3 and 4 ( and continuing with reference to Figure 1 and 2 ), a process 400 for securely distributing a secret, preferably common to a product / device family, into a manufacturing / design process environment according to illustrative embodiments is now described, preferably utilizing HSMs to protect the secret. It should be understood and appreciated that Figures 1-4 is an example of a suitable environment and is not intended to suggest any limitation as to the structure, scope of use, or functionality of illustrated embodiments. Particular environments should not be interpreted as having any dependency or requirement

[0039] Reference is now made to the process 300 of Figure 3 and 4 , a computer-implemented method for authenticating software loaded in a device (e.g. verifying a digital signature) during a device manufacturing process (300) is now described. For purposes of illustration and description, the Figure 4The illustrated device manufacturing process 300 consists of: an R&D generation phase (phase 402) for generating keys; and an Indus software (S / W) phase (phase 404); a device manufacturing phase (phase 406) and a device production phase (phase 408). It should be understood and appreciated that the process 400 is provided for illustrative purposes only and should not be construed as limiting to Figure 4 The illustrated content, as less or more phases can be included, such as provisioning, distribution and other logical phases related to device manufacturing.

[0040] Starting with step 302, a unique identifier first key is generated, preferably by a computer security device (e.g. 103), in relation to at least first software and / or firmware (S / W, F / W) that will be loaded on the device during its manufacturing process 400. The unique identifier is preferably a cryptographic identifier, such as a symmetric key or a cryptographic salt. Next, at phase 304, the key 1 is then loaded onto preferably N hardware security modules (first HSMs), where N is preferably greater than 1. As described herein, only a single first HSM is required, as the rest are for redundancy / back-up purposes. At step 306, after the key 1 is loaded on the N first HSMs, the key 1 is permanently shredded / discarded so that it exists only on the N first HSMs.

[0041] At step 308, the computer security device 103 generates a unique identifier second key (key 2) (e.g. a cryptographic identifier, such as a symmetric key) that is intended to be included as a parameter (step 308) with at least first software and / or firmware (S / W, F / W) that will be loaded on the device during its manufacturing process (400). Next (step 310), the generated key 2 is loaded on M second HSMs (where M is equal to or greater than 1), whereby the key 2 is loaded on the M HSMs (step 310) and encrypted with the first HSM by the key 1 (step 310). As described above, in certain embodiments, the key 2 will be required to encrypt additional F / W and / or S / W items that will also be included on the manufactured device. At step 314, after the key 2 is loaded on the M second HSMs, the key 2 is then permanently shredded / discarded so that it exists only on the M second HSMs.

[0042] Next, at step 316, the single first HSM is preferably sent to the manufacturing stage (e.g. product manufacturing stage 406) for installation on a computer server (e.g. 106), preferably in a physically secure location (406) of the manufacturing stage. The credentials for accessing the HSM with key 1 are preferably sent to the manufacturing stage with the HSM with key 1 via an out-of-band channel (e.g. via a secure network communication channel / app) for being preferably loaded in a computer server application related to the first HSM for enabling access to the HSM with key 1 (step 318). At step 320, the encrypted key 2 is sent to the S / W, F / W manufacturing stage (404) so that the encrypted key 2 is incorporated as a parameter in at least the first software (S / W, F / W) to be loaded in the device. Thereafter, at step 322, the software (S / W, F / W) with the incorporated encrypted key 2 is then sent to the production manufacturing stage (408) for being loaded on the manufactured device (step 328). Next, at step 324, preferably at the aforementioned manufacturing stage (408) of the device, a request is made to the manufacturing stage (e.g. product manufacturing stage 406) for decrypting the second encrypted key (key 2) incorporated as a parameter of the software (S / W, F / W) loaded on the device by utilizing the first key stored in the first HSM. At the manufacturing stage (404), by utilizing the aforementioned access credentials to the first HSM, access to the first HSM related to the computer server is obtained for decrypting the second key (key 2) for preferably authenticating (e.g. verifying a digital signature) the software (S / W, F / W) loaded on the device during the manufacturing process. At step 326, once the software (S / W, F / W) is authenticated / verified. According to certain embodiments, upon successful authentication / verification of the software (step 324), the decrypted second key (key 2) is next sent back to the production manufacturing stage (stage 408) at step 326, preferably via a secure communication channel (100) for being stored in a trusted platform module (TPM) related to the device.

[0043] For certain of the above-described illustrated embodiments, it is to be understood that the various non-limiting embodiments described herein can be used alone or in combination with one another, or selectively combined. Moreover, some of the features of the non-limiting embodiments described above can be used without the corresponding use of other described features. Thus, the foregoing description should be considered as merely illustrative of the principles, teachings and exemplary embodiments of the application, and not in limitation thereof.

[0044] It is to be understood that the above-referenced arrangements are merely illustrative of the application of the principles of this application. Numerous modifications and alternative arrangements can be devised by those skilled in the art without departing from the scope of the illustrated embodiments and the appended claims are intended to cover such modifications and arrangements.

Claims

1. A computer-implemented method for authenticating software loaded in a device during a manufacturing process of the device having one or more manufacturing stages, the method comprising: generating a first key having a unique identifier; loading the first key onto at least one hardware security module (first HSM); generating a second key having a second unique identifier to be included as a parameter with at least first software to be loaded in the device during the manufacturing process of the device; encrypting the second key with the first key from the first HSM; sending the encrypted second key to a manufacturing stage such that the encrypted second key is incorporated as a parameter in the at least first software to be loaded in the device; loading the software having the incorporated encrypted second key onto the device; and requesting decryption of the second encrypted key incorporated as a parameter in the software loaded in the device with the first key stored in the first HSM to authenticate the software loaded in the device.

2. The computer-implemented method of claim 1, further comprising sending the decrypted second key to a final manufacturing stage for storage in one of an HSM or a trusted platform module (TPM) associated with the device after successful decryption of the second key.

3. The computer-implemented method of claim 1, wherein: the first key is loaded onto N first HSMs, where N is greater than 1; one of the N first HSMs is installed on a computer server associated with a manufacturing stage; and an access credential is sent to the first HSM via a secure communication channel for storage on the computer server having the installed first HSM. the second key loaded on the second HSM is unencrypted whereby the second HSM is operable to encrypt additional software to be loaded in the device during the manufacturing process of the device.

5. The computer-implemented method of claim 4, wherein:

4. The computer-implemented method of claim 3, further comprising loading the second key onto M hardware security modules (second HSMs), where M is greater than or equal to 1, wherein, the first key is permanently pulverized after it is loaded onto the first HSM and the second key is permanently pulverized after it is loaded onto the second HSM. the first key is one of a symmetric key or a cryptographic salt. each of the first HSMs is comprised of a YubiHSM cryptographic hardware security module.

6. The computer-implemented method of claim 1, wherein, 8. The computer-implemented method of claim 3, further comprising securely storing a remainder of the N first HSMs in a physical location separate from an intermediate manufacturing stage having the computer server with the installed first HSM.

7. The computer-implemented method of claim 3, wherein, the software loaded in the device is firmware. the device is comprised of a circuit breaker component.

9. The computer-implemented method of claim 1, wherein, the manufacturing process includes a provisioning and distribution stage associated with the manufactured device.

10. The computer-implemented method of claim 1, wherein, 12. A computer-implemented method for authenticating software loaded in a device during a manufacturing process of the device having one or more manufacturing stages, the method comprising:

11. The computer-implemented method of claim 1, wherein, generating a first key having a unique identifier to be associated with at least first software to be loaded in the device during the manufacturing process of the device; loading the first key onto a hardware security module (HSM); ​ ​ generating a second key having a unique identifier that is to be included as a parameter with at least first software to be loaded on the device during the device manufacturing process; encrypting the second key with the first key from the HSM; operatively relating the HSM to a computer server associated with a physical location for the device manufacturing stage; sending the encrypted second key to the device manufacturing stage such that the encrypted second key is incorporated as a parameter in at least first software to be loaded on the device; loading the software having the incorporated encrypted second key on a device in the device manufacturing stage; and in the manufacturing stage having the HSM, decrypting the second encrypted key incorporated as a parameter in software loaded on the device with the first key stored in the HSM to authenticate the software loaded on the device during the manufacturing process.

13. The computer implemented method of claim 12, further comprising sending access credentials to the HSM via a secure communication channel for relating to the computer server operatively related to the HSM.

14. The computer implemented method of claim 1, further comprising storing the decrypted second key in a trusted platform module (TPM) associated with the device in the device manufacturing stage after authenticating at least first software loaded on the device during the manufacturing process.

15. The computer-implemented method of claim 12, wherein, the first key is permanently pulverized after it is loaded on the HSM.

16. The computer-implemented method of claim 12, further comprising loading the second key onto a second HSM, wherein, the second key loaded on the second HSM is unencrypted whereby the second HSM is operable to encrypt additional software to be loaded on the device during the device manufacturing process.

17. The computer-implemented method of claim 16, wherein, the second key is permanently pulverized after it is loaded on the second HSM.

18. The computer-implemented method of claim 12, wherein, the first key is one of a symmetric key or a cryptographic salt.

19. The computer-implemented method of claim 12, wherein, providing a plurality of first HSMs each including the first key and wherein each first HSM consists of a YubiHSM cryptographic hardware security module.

20. A computer implemented method for authenticating software loaded in a device during a device manufacturing process having one or more manufacturing stages, the method comprising: generating a first key having a unique identifier that is to be associated with at least first software to be loaded on the device during the device manufacturing process; loading the first key on a hardware security module (HSM); generating a second key having a unique identifier that is to be included as a parameter with at least first software to be loaded on the device during the device manufacturing process; encrypting the second key with the first key from the HSM; operatively relating the HSM to a computer server associated with a physical location for the device manufacturing stage; sending the encrypted second key to the device manufacturing stage such that the encrypted second key is incorporated as a parameter in at least first software to be loaded on the device; and loading the software having the incorporated encrypted second key on a device in the device manufacturing stage, wherein after the software is loaded on the device, the device automatically initiates decryption of the second encrypted key with the first key stored in the HSM to authenticate the software loaded on the device during the manufacturing process.

Images