Source differentiation for fast device replacement

Abstract

A method performed by a computing system of a computing system and a device coupled to a network for performing fast device replacement (FDR) includes storing a set of encryption keys, accessing at least one signed replacement data set provided by a respective one or more sources to a fast device replacement (FDR) storage device, validating a source providing a particular signed replacement data candidate in the at least one signed replacement data set accessed by validating a cryptographic signature for signing the particular signed replacement data candidate using a cryptographic algorithm and a stored cryptographic key set, and to allow for fast device replacement using replacement data of a particular signed replacement data candidate waiting for verification of its associated cryptographic signature, as well as methods performed by a computing system of an FDR storage system and a trusted tool configured to facilitate FDR of multiple devices.

Description

Technical Field

[0001] This disclosure relates to rapid device replacement for networked devices, and more specifically, to source differentiation for rapid device replacement of networked devices. Background Technology

[0002] Fast Device Replacement (FDR) is a service provided by an FDR server that facilitates bringing a modifiable device into a modified state for operation within the system. In response to a trigger, the FDR server automatically retrieves previously stored FDR data (also known as replacement data) using the identifier of the modifiable device and provides the retrieved FDR data to the modifiable device for configuration. The FDR data includes settings for configuring the modifiable device to be in the desired state for operation.

[0003] Although the identity of the FDR service is unknown, the modifiable device trusts the FDR server. Without verifying the identity of the FDR server, there is a risk that the FDR server may accidentally or maliciously provide incorrect replacement settings. When the modifiable device is configured with incorrect replacement settings, it may be improperly modified for operation, rendering it inoperable within its system or failing to perform the tasks it was intended to perform.

[0004] In addition to the risk of accidental or malicious configuration of devices that can be modified, there is a lack of non-repudiation of FDR data. There is also a lack of audit data that can provide information about the source of FDR data, such as when investigating problems. There is also a lack of correlation between how FDR data is handled and the type of FDR source that identifies it. The risks associated with FDR limit how FDR can be used. Summary of the Invention

[0005] The objects and advantages of the illustrated embodiments described below will be set forth in and apparent from the following description. Additional advantages of the illustrated embodiments will be realized and obtained through the devices, systems, and methods particularly pointed out in the written description and its claims, as well as the accompanying drawings. To achieve these and other advantages and according to the objects of the illustrated embodiments, in one aspect, a computer-implemented method for performing Fast Device Replacement (FDR) is disclosed, executed by a device coupled to a network. The method includes storing a set of cryptographic keys, accessing at least one signed replacement dataset provided to the FDR storage device by one or more corresponding sources, verifying the source providing the specific signed replacement data candidate in the accessed at least one signed replacement dataset by verifying a cryptographic signature used to sign the specific signed replacement data candidate using a cryptographic algorithm and the stored set of cryptographic keys, and allowing fast device replacement using the replacement data of the specific signed replacement data candidate, pending verification of its associated cryptographic signature.

[0006] In one or more embodiments, each encryption key in the encryption key set may be associated with a source type, and the source type associated with an encryption key in the encryption key set used to verify the source may be identified as the source type. The method may also include applying rules that define a hierarchy of different types of sources associated with one or more conditions and / or corresponding encryption keys in the encryption key set, wherein allowing fast device replacement using specific signed replacement data candidates may be managed by the rules.

[0007] In one or more embodiments, when one or more conditions include that the device is being newly coupled to the network, the rule may allow replacement if the type of the identified source is the device category to which the device belongs or a trusted tool, and when one or more conditions include that the device has previously been coupled to the network, the rule may allow replacement if the type of the identified source is a device or a trusted tool.

[0008] In one or more embodiments, the device is configured with rules either as factory settings or via user configuration.

[0009] In one or more embodiments, each encryption key in the encryption key set may be associated with an identifier and / or type of a source. The method may also include recording an indication of whether the verification was successful, wherein the identifier and / or type of the source is associated with an encryption key in the encryption key set used to verify the source.

[0010] In one or more embodiments, the type of the identified source can be a source category or a trusted tool, and when the type of the identified source is a source category, verifying the source may further include determining whether the source category belongs to an allowed device category of the device, and when the type of the identified source is a trusted tool, verifying the source may further include determining whether the trusted tool is trusted by the device.

[0011] In one or more embodiments, the method may further include: storing device replacement data, signing the device replacement data using a device key, the device key being unique to the device and included in a set of encryption keys, and configuring the FDR storage device by such that the signed device replacement data is stored together with the signed replacement dataset in the FDR storage device.

[0012] In one or more embodiments, the encryption key set, the key for signing the signed replacement data included in the signed replacement dataset, and the encryption algorithm can be configured to use an asymmetric key or a symmetric key with a key hash.

[0013] In one or more embodiments, the method may further include requesting the execution of the FDR process using replacement data from the FDR storage device, wherein at least one signed replacement dataset may be accessed in response to the request.

[0014] In one or more embodiments, a particular signed replacement data candidate may include an update to a selected data field among a plurality of data fields stored by the device, and enabling rapid device replacement may include updating the selected data field using the particular signed replacement data candidate.

[0015] In one or more embodiments, the device may be a plurality of devices, and the source may be configured to provide a specific signed replacement data candidate to the FDR storage device once to cause an update of the selected data field in each of the plurality of devices.

[0016] In one or more embodiments, the command can enable multiple devices to access a specific candidate replacement dataset via a push (PUSH) action from an FDR storage device or a pull (PULL) action from multiple devices.

[0017] In another aspect, a computer system for the device is disclosed. The computer system includes a memory configured to store a plurality of programmable instructions and a processing device in communication with the memory, wherein the processing device, when executing the plurality of programmable instructions, is configured to perform the disclosed method executed by the device.

[0018] According to another aspect of this disclosure, a non-transitory computer-readable storage medium and one or more computer programs embedded therein are provided, which, when executed by a computer system, cause the computer system to perform the disclosed method executed by the device.

[0019] According to another aspect of this disclosure, a method performed by an FDR storage device for providing replacement datasets to the device when the device is coupled to a network is disclosed. The method includes storing a plurality of signed replacement datasets, each signed by a corresponding source using a source's cryptographic key and having a corresponding data identifier identifying the replacement dataset, and providing the device with one or more candidate signed replacement datasets from the plurality of signed replacement datasets. The corresponding one or more candidate replacement datasets are evaluated by the device using a cryptographic algorithm and a locally stored cryptographic verification key via one or more trials to verify any one of the one or more candidate signed replacement datasets, and the device is configured to allow fast device replacement only when the verified one or more candidate replacement datasets are used.

[0020] In one or more embodiments, the encryption key for the corresponding source may be a private key that identifies the source or source category.

[0021] In one or more embodiments, the method may further include receiving a request for a replacement dataset from a plurality of candidate devices, wherein the request may include an indication of an aspect of the device, and the indication of an aspect of the device is used to select a candidate replacement dataset from the plurality of replacement datasets.

[0022] In one or more embodiments, an aspect of the device may include an identifier of the device or an identifier of the device category.

[0023] In one or more embodiments, one or more candidate replacement datasets may include updates to selected data fields among a plurality of data fields stored by the device, and when the device allows for fast device replacement using a specific signed replacement dataset, a specific candidate signed replacement dataset may be used to cause an update to the selected data field.

[0024] In one or more embodiments, providing one or more candidate signed replacement datasets to a device may include providing one or more candidate signed replacement datasets to multiple devices, wherein the multiple devices may be configured to evaluate one or more candidate signed replacement datasets using a cryptographic algorithm and its corresponding locally stored cryptographic verification key to attempt to verify any one of the one or more candidate replacement datasets, and the respective multiple devices may be configured to allow fast device replacement only when using one or more candidate signed replacement datasets verified by the respective device.

[0025] In one or more embodiments, the method may further include receiving a command, wherein, in response to the command, a push action may be performed to provide one or more candidate replacement datasets to multiple devices.

[0026] In an additional aspect, a storage system for an FDR storage device is disclosed. The storage system includes a memory configured to store a plurality of programmable instructions and a processing device in communication with the memory, wherein the processing device, when executing the plurality of programmable instructions, is configured to perform the disclosed method executed by the storage system.

[0027] According to another aspect of this disclosure, a non-transitory computer-readable storage medium and one or more computer programs embedded therein are provided, which, when executed by a computer system, cause the computer system to perform the disclosed method performed by the storage system.

[0028] In a further aspect, a method executed by a trusted tool is disclosed. The method includes locally storing an encryption key that is unique to or otherwise identifies the trusted tool or the tool group to which it belongs; obtaining or generating a replacement dataset provided by the tool; signing the replacement dataset using the encryption key; and remotely storing the signed replacement dataset in an FDR storage device. A device among multiple devices coupled to a network is configured to access the signed replacement dataset from multiple replacement datasets stored in the FDR storage device, and the device is configured to allow fast device replacement only when the signed replacement dataset is used, provided that the device successfully verifies the signed replacement dataset using an encryption algorithm and a verification encryption key stored locally by the device.

[0029] In one or more embodiments, the replacement dataset provided by the tool may include updates to selected data fields among a plurality of data fields stored by a device, wherein the device may include one or more devices, and the one or more devices may be configured to allow rapid device replacement for updating the selected data fields using the replacement dataset provided by the tool.

[0030] In one or more embodiments, the method may further include instructing the FDR storage device to cause selected data fields of multiple devices to be updated using a replacement set provided by a signed tool.

[0031] In another aspect, a computer system for a trusted tool is disclosed. The computer system for a trusted tool includes a memory configured to store a plurality of programmable instructions, and a processing device in communication with the memory, wherein the processing device, when executing the plurality of programmable instructions, is configured to perform the disclosed method executed by the trusted tool.

[0032] According to another aspect of this disclosure, a non-transitory computer-readable storage medium and one or more computer programs embedded therein are provided, which, when executed by a computer system, cause the computer system to perform the disclosed method performed by a trusted tool.

[0033] These and other features of the systems and methods disclosed herein will become more apparent to those skilled in the art from the following detailed description of preferred embodiments in conjunction with the accompanying drawings. Attached Figure Description

[0034] A more detailed description of this disclosure, which has been briefly summarized above, can be obtained by referring to various embodiments, some of which are illustrated in the accompanying drawings. While the drawings illustrate selected embodiments of this disclosure, they should not be construed as limiting the scope of this disclosure, as other equivalent embodiments are permissible.

[0035] Figure 1 This is a block diagram illustrating a source-differentiated rapid device replacement (FDR) system for performing FDR operations according to an embodiment of the present disclosure;

[0036] Figure 2 This is a flowchart illustrating an instance method performed by a target device during FDR operation for an instance use case according to an embodiment of the present disclosure;

[0037] Figure 3 This is a flowchart illustrating an instance method performed by a target device for another instance use case during FDR operation according to an embodiment of the present disclosure;

[0038] Figure 4A This is a flowchart illustrating an example method executed by a target device to perform FDR operation on the device according to an embodiment of the present disclosure;

[0039] Figure 4B This is a flowchart illustrating an example method for performing FDR operations on a target device by an FDR database according to an embodiment of the present disclosure;

[0040] Figure 4C This is a flowchart illustrating an example method for performing FDR operations on one or more target devices, executed by a trusted engineering tool according to an embodiment of the present disclosure;

[0041] Figure 5-8 This is a flowchart illustrating example methods performed by the source and target devices during FDR operation for different corresponding use cases according to embodiments of this disclosure;

[0042] Figure 9 This is a block diagram of an exemplary processing system that can be used by a data source, target device, or FDR storage device involved in FDR operation, according to embodiments of this disclosure.

[0043] Where possible, the same reference numerals have been used to denote the same elements common in the figures. However, elements disclosed in one embodiment may be advantageously used in other embodiments without specific description. Detailed Implementation

[0044] Reference will now be made to the accompanying drawings, wherein like reference numerals identify similar structural features or aspects of the subject matter disclosed herein. For purposes of explanation and illustration, and not limitation, block diagrams of exemplary embodiments of the Rapid Device Replacement (FDR) system according to this disclosure are shown in... Figure 1 It is shown in the figure and is generally designated by reference numeral 100. Figure 2-9 Other embodiments or aspects thereof of the FDR system 100 according to this disclosure are provided, as will be described.

[0045] 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 this disclosure pertains. Although any methods and materials similar to or equivalent to those described herein may also be used in the practice or testing of this disclosure, exemplary methods and materials are described hereafter.

[0046] It must be noted that, as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural indicators unless the context clearly indicates otherwise. Thus, for example, reference to “stimulus” includes a plurality of such stimuli, and reference to “signal” includes reference to one or more signals and their equivalents known to those skilled in the art, and so on. It should be understood that the embodiments of this disclosure discussed below are implemented using software algorithms, programs, or code that may reside on a computer-usable medium for enabling execution on a machine having a computer processor. The machine may include a memory storage device configured to provide output from the execution of the computer algorithms or programs.

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

[0048] FDR system 100 includes one or more target devices 110, at least one data source 120, and FDR storage device 130. The target devices 110 may belong to one or more systems 150. The target devices 110 are real or virtual devices including hardware, software, and / or firmware, and are capable of verifying cryptographically signed messages. The term "signature" (in its various syntactic forms) used with respect to FDR data refers to a cryptographic signature and is not limited to a specific method of cryptographic signing. The target devices 110 may be coupled to system 150 via wired and / or wireless communication coupling, for example, via private or public networks, local area networks (LANs), wide area networks (WANs), cellular networks, mesh networks, etc.

[0049] One or more target devices 110 and one or more data sources 120 may communicate with the FDR storage device 130 via one or more networks using wired and / or wireless communication coupling. Examples of networks include, but are not limited to, private or public networks, local area networks (LANs), wide area networks (WANs), cellular networks, mesh networks, etc.

[0050] In some embodiments, system 150 is an operational technology (OT) system, such as an industrial system, data center, utility system, or hospital system. Target device 110 may be coupled to system 150 via the Industrial Internet of Things (IIOT). Target device 110 may be an OT device, such as, but not limited to, a circuit breaker, motor control center, gateway, PLC, security system, building management controller, edge device, field device (e.g., sensor, actuator, or alarm), etc.

[0051] In some embodiments, system 150 is an information technology (IT) system. Target device 110 can be coupled to system 150 via the Internet of Things (IoT). Target device 110 can be an IT device, such as a mobile phone, tablet, personal computer, server, etc.

[0052] Each data source 120 is a real or virtual device comprising hardware, software, and / or firmware, and is capable of cryptographically signing messages. Data source 120 includes a source encryption engine 121 and a source storage 122. Source storage 122 includes source replacement data 126 and one or more source private keys 127. Note that during FDR operation, some data sources 120 may operate as target devices 110. Data sources 120 may be mobile or fixed computing devices, such as IT or OT devices. Data sources 120 may each have a different type. Device 110 stores the type of data source associated with its corresponding verification key. When verification is performed using the verification key, the associated type indicates the type of data source.

[0053] Source storage 122 stores source replacement data 126 and the source data source 120's own private key (referred to as source private key 127). Source encryption engine 121 uses an encryption algorithm and source private key 127 to sign source replacement data 126, and then provides source replacement data 126 to FDR storage device 130. Source private key 127 can be unique for a source device or a group of source devices of one or more categories. Therefore, source private key 127 can identify a source device or the class (or group of classes) to which a source device belongs.

[0054] The source replacement data 126 can be obtained from the settings of a configurable feature (not shown) of the data source 120, or it can be entered and stored by an authorized administrator or during manufacturing. The source private key 127 can be entered and stored by an authorized administrator or during manufacturing.

[0055] FDR storage device 130 includes hardware, software, and / or firmware for storing or accessing FDR storage device 132, receiving and storing signed FDR data, selecting signed FDR datasets, and providing the selected signed FDR datasets to target device 110. FDR storage device 132 stores signed FDR data received from one or more data sources 120. FDR storage device 130 can be configured to include a storage device or a programmable logic controller (PLC) for accessing the storage device. FDR storage device 132 can be integrated with FDR storage device 130, or it can be external to FDR storage device 130 and coupled to FDR storage device 130 (via wireless and / or wired coupling).

[0056] Signed FDR data can be provided from data source 120 to FDR storage device 130 via push or pull operations. Push or pull operations can be triggered by user actions or scheduled or unscheduled events. An FDR operation targeting an identified destination device 110 can be initiated by a request from the destination device 110 (which may be in response to a user action or triggered by another condition), a determination by the FDR storage device 130, or an instruction from an external processing device (not shown). Once an FDR operation is initiated, the FDR storage device 130 uses the identifier of the destination device 110 to select signed FDR data from the stored signed FDR data 136 and provides the selected signed FDR data as a signed FDR dataset to the destination device 110. The device identifier identifying the destination device 110 can be determined based on settings established by physical dialing, physical location in the system (e.g., determined by a network topology discovery process), network location (e.g., addresses and information of neighbors in a daisy-chain network), etc. The category identifier that identifies the category to which a device belongs can also be determined similarly to the determination of the device identifier and / or by determining the category identifier associated with the device identifier (e.g., by a lookup process of consulting a data structure (e.g., a table, etc.)). The corresponding set of stored FDR data can have data identifiers, such as indexes, keys, addresses, record locators, etc. Data identifiers can be stored and associated with a replacement dataset of the corresponding signature. Therefore, the stored FDR data can be associated with the target device 110 using either the device identifier or the category identifier of the target device 110.

[0057] The ID of data source 120 can be cryptographically signed. In one or more embodiments, the signature can be performed using the source private key 127 and verified using the corresponding source verification key 117, wherein the device private key 127 and the source verification key 117 are an asymmetric encryption key pair. The source verification key 117 can be a key.

[0058] In one or more embodiments, a hash-based message authentication code (HMAC) function can be used to perform signing, where a hash function is applied to the key and the message. In this embodiment, data source 120 and target device 110 are configured to sign different instances of FDRs within a signed FDR dataset using symmetric keys (meaning the source private key 127 and source verification key 117 used for signing and verifying FDR data are symmetric keys). The management of HMAC specific to target device 110 (including constraints on the design and processes of target device 110) is equivalent to the management of the private key of target device 110. Keys can be provided or created at manufacturing time. The key used for the HMAC function needs to be securely deployed and protected due to its symmetry. References throughout this disclosure to cryptographic signatures and / or keys (e.g., verification and private keys) can be interpreted as referring to the use of HMAC functions, where the verification and private keys stored by data source 120 and target device 110 are symmetric keys.

[0059] In one or more embodiments, the settings can be signed by the source private key 127 and can be verified using the corresponding source verification key 117. In one or more embodiments, the signed FDR data may include the ID and / or settings of the data source 120, wherein at least one of the ID and settings of the data source 120 is signed by the device private key 127.

[0060] Target device 110 includes a device encryption engine 111, a device storage device 112, an acceptable source logic module 113, configurable features 118, and a retrieval module 119. Device storage device 112 includes an encryption verification key set 114, an FDR source log 115, and device replacement data 116. Device storage device 112 stores an encryption verification key set 114 with one or more encryption source verification keys 117, including the target device 110's own verification key (referred to as device verification key 117a) and verification keys for other sources.

[0061] The source verification key 117 is also stored together with the associated source type, which indicates the type of the data source 120 that is the source of the verified signed FDR data when the source verification key 117 is successfully used to verify one of the signed FDR data instances included in the signed FDR dataset received by the target device 110.

[0062] The source type can be, for example (but not limited to), itself (meaning that the target device 110 is also a source of signed FDR data verified using source verification key 117), one or more classes (also referred to as families, meaning that the target device 110 belongs to the same class as the source of signed FDR data verified using source verification key 117), or an engineering tool (meaning that the source of signed FDR data verified using source verification key 117 is an engineering tool trusted by the target device 110). The type associated with device verification key 117a is itself, meaning that a particular target device 110 is a data source 120 that provides the signed FDR dataset.

[0063] Regarding source type classes, data sources 120 or target devices 110 of the same type can be devices included in system 150 that have some of the same characteristics (e.g., the same brand and model, the same function, and / or the same position in the hierarchy). For example, a factory may have multiple actuators of the same brand and model belonging to a first category and multiple controllers of the same brand and model belonging to a second category.

[0064] In another example use case, the OT system requiring high availability can be modular and have replaceable functional units that can be exchanged and configured using FDR operations. One example is a motor control center designed in a removable and replaceable compartment (also called a bucket or drawer). If a bucket in operation needs to be replaced, a spare bucket can be available and put into use. The bucket in the motor control center can be a component with many parts including electrical equipment. Typically, the electrical equipment includes digitally configurable devices such as motor overload relays. The digitally configurable devices can retrieve the settings and information required for proper operation and protection of the loads electrically connected to the bucket. During FDR operations, the entire bucket can be removed and replaced with another (e.g., a spare) bucket having the same parts. When a spare bucket is installed to replace an existing bucket, each of the digitally configurable devices in the spare bucket operates as a target device 110. When retrieving the settings of the digitally configurable devices in the spare bucket, it is determined for each digitally configurable device whether it belongs to the same category or type as the corresponding digitally configurable device it is replacing.

[0065] The encryption verification key set 114 may include multiple source verification keys 117, each having a source type category corresponding to a different category to which the target device 110 belongs. The different categories may be completely or partially overlapping, or they may be disjoint.

[0066] Device replacement data 116 can be obtained from the settings of configurable feature 118, or it can be entered and stored by an authorized administrator or during manufacturing. The encrypted verification key set 114 can be entered and stored by an authorized administrator or during manufacturing.

[0067] The device cryptographic compilation engine 111 uses a cryptographic compilation algorithm and one or more cryptographic source verification keys 117 from the cryptographic compilation verification key set 114 to verify the signed FDR dataset received from the FDR storage device 130. The acceptable source logic module 113 uses the source type associated with any of the cryptographic source verification keys 117 that successfully verified the signed FDR dataset. The acceptable source logic module 113 applies rules that determine how the FDR data from the successfully verified signed FDR dataset can be used, based on the source type of the source or device key used to successfully verify the signed FDR dataset. About Figures 2 to 4C Examples of the logic and application of the FDR storage device 130 and engineering tools (configured to facilitate the use of FDRs for multiple target devices 110) are shown and described.

[0068] The application of this logic allows data source 120 to be distinguished from untrusted data sources and other data sources. This distinction allows for the rejection of signed FDR datasets stored in FDR storage device 130 by untrusted data sources. This distinction also allows for the differentiation of different trusted data sources 120, enabling target device 110 to apply different rules to the corresponding trusted data sources. In this way, target device 110 can behave according to a first rule set associated with a first trusted data source 120 and a second rule set associated with a second trusted data source 120, wherein the first rule set differs from the second rule set.

[0069] When the target device 110 acts as the data source 120, the device encryption engine 111 can also use the device key 117 to sign the device replacement data 116. When operating as the data source 120, the target device signs the device replacement data 116 and then provides it as signed FDR data to the FDR storage device 130.

[0070] In addition to other potentially useful data, the FDR source log 115 also includes a timestamped identifier of the data source 120 that provided the signed FDR data to the target device 110, as indicated by association with the successfully verified source verification key 117. The timestamp may indicate, for example, the time (e.g., date and time) when the signed FDR dataset was received or the time when verification was successfully performed. Successful verification of the signed FDR dataset can lead to verification and determination of the source type.

[0071] Device replacement data 116 is stored 110 for future use when its host target device 110 appears as a data source 120. When the host target device 110 appears as a data source 120, the host target device 110 retrieves the device replacement data 116 from the device storage device 112, signs the retrieved device replacement data 116, and provides the signed device replacement data to the FDR storage device 130 for future FDR operations.

[0072] The configurable feature 118 is a hardware, software, and / or firmware feature of the target device that can be configured with different settings. During FDR operation, the configurable feature 118 is set using an FDR dataset obtained from a signed FDR dataset from FDR storage device 130, depending on the verification of the source of the signed FDR dataset.

[0073] Now for reference Figure 2-8 The diagram illustrates a flowchart showcasing various exemplary embodiments. Note that... Figure 2-8 The order of operations shown is not required; therefore, in principle, various operations may not be performed in the order shown. Furthermore, some operations may be skipped, different operations may be added or substituted, some operations may be performed in parallel rather than strictly sequentially, or selected operations or groups of operations may be performed in separate applications following the embodiments described herein.

[0074] Languages ​​involving the exchange (providing or receiving) of information are not necessarily restrictive and can refer to push or pull operations. Figure 2 and Figure 3 The following are illustrations, respectively, for use by a target device (referred to as a device) according to certain embodiments. Figure 1 The flowcharts 200 and 300 illustrate an example method for the target device 110 to perform an FDR operation. The logic applied in flowcharts 200 and 300 can be derived from... Figure 1 The acceptable source logic module 113 shown is provided. The methods shown in flowcharts 200 and 300 are merely exemplary and are not intended to limit this disclosure to the specific logic shown. Rather, flowcharts 200 and 300 are intended to demonstrate that decisions about which FDR data to apply or not to apply, and about what and when the data source records, can be made based on the logic provided by the acceptable source logic module 113. The logic used by the acceptable source logic module 113 can be customizable and configurable.

[0075] refer to Figure 2 At box 202, the device receives signed FDR data, such as by receiving a signed FDR dataset from an FDR storage device, such as... Figure 1The FDR storage device 130 is shown in the diagram. The received signed FDR data may include multiple FDR data, each generated by a corresponding data source (such as...). Figure 1 The data source 120 shown is signed. At box 204, the signed FDR data is verified using existing technologies such as hashing. These technologies can verify that the signed FDR data has not been tampered with or corrupted, but they do not determine or verify the source of the signed FDR data.

[0076] At box 206, an attempt is made to verify the signature used to sign the FDR data by trying to verify the signed FDR data using a source verification key (also known as a generic key) with an associated generic class type. The generic class type indicates the generic class to which the device belongs. The generic key includes one or more cryptographic source verification keys (such as...) stored by the device. Figure 1 The source verification key 117 shown in the figure.

[0077] At box 208, a determination is made as to whether the validation performed at box 206 was successful. If validation is successful at box 208, the method continues at box 210. At box 210, the successful validation is recorded in a location such as... Figure 1 The FDR source log 115 shown here. The recorded data may include, for example, the results of signature verification and any decisions made based on successful verification. Additionally, FDR data obtained by the application through verifying received signed FDR data, such as settings of device characteristics (such as configuration settings). Figure 1 The settings of configurable feature 118 are shown.

[0078] If the verification fails at box 208, the method continues at box 212. At box 212, the failed verification is logged. FDR data is not applied to the device's characteristics.

[0079] Therefore, any decisions made by the device regarding FDR data signature verification and application can be recorded to allow for future auditing. In scenarios where the device accepts FDR data from its own self-signed data, a verification result and decision point are recorded. In scenarios where the device can accept data from itself or from another device of the same category, verification results are recorded for both the self-signed data and the data from the other device, as well as any subsequent decision points.

[0080] Figure 3 The illustration shows an embodiment for use by a target device (referred to as a device) (e.g., Figure 1 The flowchart 300 shows another instance method of the target device 110 performing the FDR operation.

[0081] This method includes performing actions such as regarding Figure 2The described boxes are 202, 204, 206, 208, and 212. Following box 208, when successful verification is determined at box 208, the method continues at box 302. At box 302, a determination is made as to whether the device has existing data, meaning that the device configuration was previously performed, making the device's characteristics (such as...)... Figure 1 The settings for the configurable feature 119 shown have been previously provided. When it is determined at box 302 that the device does not have existing data, the method continues to box 210, indicating that the device has not been previously configured, such as for a brand new device after being unpacked or an unformatted device after being unformatted.

[0082] Once it is determined at box 302 that the device does indeed have existing data, the method continues at box 304. At box 304, it attempts to use the device's own key (such as...) Figure 1 The device verification key 117a shown is used as the source verification key to verify the signed FDR data in an attempt to verify the signature used to sign the FDR data.

[0083] At box 306, a determination is made as to whether the validation performed at box 304 was successful. If validation is successful at box 306, the method continues at box 308. At box 308, such as... Figure 1 The FDR source log 115 shown records successful verification and any subsequent decisions. Additionally, the application obtains FDR data by verifying the received signed FDR data, such as by configuring device characteristics (such as configuration settings). Figure 1 The settings of configurable feature 118 are shown.

[0084] If the verification fails at box 306, the method continues at box 310. At box 310, the failed verification is logged. FDR data is not applied to the device's characteristics. Instead, the device's user can be prompted to accept load data for configuring the device from another source.

[0085] refer to Figure 4A A flowchart illustrating an example method for performing FDR, executed by a device coupled to a network, is provided. This example could be a target device (such as...) Figure 1 and Figure 2 The target device 110 shown. At box 402, the encryption key set (such as...) Figure 1 The encryption key set 114 shown is stored by the device.

[0086] At optional box 404, in one or more embodiments, submission is made for using storage devices from FDR (such as...) Figure 1 and Figure 2The FDR storage device 130 shown in the diagram uses replacement data to execute the FDR procedure. This request can be submitted by the device (e.g., in response to a user action or triggered by another condition), and / or can be submitted by a different device or process outside the device.

[0087] At box 406, access at least one signed replacement dataset provided to the FDR storage device by one or more corresponding sources.

[0088] For example, the encryption key set, the key used to sign the signed replacement data included in the signed replacement dataset, and the encryption algorithm can be configured to use an asymmetric key, or can be configured to use a symmetric key with a key hash.

[0089] At box 408, verification is performed on the source of a particular signed replacement data candidate that provides at least one accessed signed replacement dataset. Verification includes verifying the cryptographic signature used to sign the particular signed replacement data candidate using an encryption algorithm and a stored set of encryption keys.

[0090] At optional box 410, in one or more embodiments, the device applies rules defining one or more conditions and / or hierarchical levels of different types of sources associated with corresponding cryptographic keys of the cryptographic key set. The permission for fast device replacement using specific signature data candidates is managed by the rules. In one example, when one or more conditions include that the device is newly coupled to the network, the rules allow replacement if the type of the identified source is the device category to which the device belongs or a trusted tool. In another example, when one or more conditions include that the device was previously coupled to the network, the rules allow replacement if the type of the identified source is a device or a trusted tool.

[0091] In one or more embodiments, the device may be configured using rules as factory settings or via user configuration. In one or more embodiments, the type of the identified source is a category of source, device, or trusted engineering tool. When the type of the identified source is a category of source, verifying the source also includes determining whether the category of the source belongs to an allowed device category of the device. When the type of the identified source is a trusted engineering tool, verifying the source also includes determining whether the trusted engineering tool is trusted by the device.

[0092] In one or more embodiments, the source stores device replacement data in an FDR storage device. Before storing the device replacement data, the source signs the device replacement data using a device key that is unique to the device and included in the device's cryptographic key set. In one or more embodiments, the source is a device. Methods performed by the device may include configuring the FDR storage device by storing the signed device replacement data together with a signed replacement dataset in the FDR storage device.

[0093] Block 412 allows fast device replacement using replacement data of a specific signed replacement data candidate that awaits verification of its associated cryptographic signature; in other words, fast device replacement is only allowed if verification is successful.

[0094] At optional box 414, record the identifier of the source type and indicate whether the source verification was successful or failed.

[0095] Each encryption key in the encryption key set is associated with an identifier and / or type of a source. Therefore, recording an indication of whether verification was successful may include storing an indication having the identifier and / or type of the source associated with an encryption key in the encryption key set used to verify the source. In this way, the recorded indication of successful or unsuccessful verification includes the identifier and / or type of the source associated with the encryption key used to attempt verification.

[0096] In this example, a specific signed replacement data candidate includes an update to a selected data field among multiple data fields stored by the device. In this example, enabling rapid device replacement involves updating the selected data field using a specific signed replacement data candidate.

[0097] In this example, the device is multiple devices. In this instance, the source is configured to provide a specific, signed replacement data candidate to the FDR storage device at a time to cause an update of the selected data field on each of the multiple devices.

[0098] In the example, the command enables multiple devices to access a specific candidate replacement dataset via push actions from the FDR storage device or pull actions from multiple devices.

[0099] refer to Figure 4B Provides an illustration of the storage device (e.g., FDR) Figure 1 and 2 The flowchart illustrates an instance method performed by the FDR storage device 130 (shown in the diagram) for providing one or more candidate signed FDR datasets to a device coupled to a network. This device can be a target device (such as...) Figure 1 and Figure 2 The target device 110 shown is included. At box 420, multiple signed replacement datasets are stored, each signed by a corresponding source using the source's encryption key. The sources can belong to various different categories of specific sources.

[0100] In one or more embodiments, data identifiers such as indexes, keys, addresses, record locators, etc., may be stored and associated with a replacement dataset of corresponding signatures, and may be used to select a replacement dataset of candidate signatures for provision to a device using a device identifier that identifies a device or device class.

[0101] At optional box 422, receive a request or command. This request can be received from one of multiple candidate devices, requesting one or more candidate signature FDR datasets. The request may include an indication of one aspect of the device. The command may optionally be triggered via a push action to provide one or more candidate replacement datasets to multiple devices. The aspect of the device may include, for example, an identifier of the device and / or its category.

[0102] At optional box 424, for example, when a match or other relevance exists, a candidate replacement dataset is selected from multiple replacement datasets using the device or category identifier included in the request and the data identifier associated with the corresponding replacement dataset.

[0103] At box 426, one or more candidate signed replacement datasets, selected from a plurality of signed replacement datasets, are provided to the device. The device(s) evaluate the respective candidate signed replacement datasets by one or more attempts to verify any one of the candidate replacement datasets using an encryption algorithm and a locally stored cryptographic verification key. The device(s) are configured to allow fast device replacement only when using the verified candidate replacement datasets.

[0104] In the example, one or more candidate replacement datasets include updates to selected data fields among a plurality of data fields stored by the device. When the device allows fast device replacement using a specific signed candidate replacement dataset, the use of the specific signed candidate replacement dataset causes an update to the selected data field. The update can be performed by the device itself, or it can be performed by the FDR storage device 130 or other external device (not shown).

[0105] In the example, one or more devices are multiple devices. These multiple devices are configured to evaluate one or more candidate signed replacement sets using a cryptographic algorithm and its corresponding locally stored cryptographic verification key, in an attempt to verify any one of the one or more candidate replacement datasets. The corresponding multiple devices are configured to allow fast device replacement only when using a signed replacement dataset of one or more candidates verified by the corresponding device.

[0106] refer to Figure 4C It provides an example of what can be achieved by trusted tools (such as...) Figure 7 and 8 A flowchart of an example method for facilitating FDR across multiple devices, executed by the engineering tool 514 shown, includes providing a signed FDR dataset to a remote FDR storage device (such as...). Figure 7 and 8 The FDR storage device 520 shown is used to configure one or more devices (such as...) Figure 7 and 8 The device shown is 510B.

[0107] At box 442, the encryption key is stored locally, wherein the encryption key is unique to the trusted tool or the tool group to which the trusted tool belongs, or otherwise identifies the trusted tool or the tool group to which the trusted tool belongs. At box 444, the FDR dataset provided by the tool is obtained or generated. When the FDR dataset provided by the tool is obtained from another source, the trusted tool can verify the source, for example by using an additional encryption key previously stored locally by the trusted tool.

[0108] At box 446, the tool signs the FDR dataset provided by the tool using a locally stored encryption key. At box 448, the signed FDR dataset provided by the tool is remotely stored on an FDR storage device.

[0109] At option 450, the command is sent. This command can be directed to the FDR storage device and / or cause the FDR storage device to use a replacement set provided by a signed tool to cause an update to selected data fields on one or more devices.

[0110] Figure 5-8 Different example use cases based on example logic applied by the target device are shown, such as those by... Figure 1 The target device 110 shown is an application of logic provided by an acceptable source logic module 113. This example use case is not intended to limit this disclosure, but rather to demonstrate one of many possible use cases. Figures 5 to 8 In each of these, the left column of the graph shows the storage stage, where the FDR dataset is generated from a data source (such as...). Figure 1 The data source 120 shown is stored in an FDR storage device (such as...). Figure 1 The FDR storage device 130 shown is located in the FDR storage device. The right column of the figure illustrates the retrieval phase, in which the signed FDR dataset is retrieved from the FDR storage device to the target device (such as...). Figure 1 The target device 110 shown.

[0111] refer to Figure 5 In the first use case, device 510A, labeled as device A, is configured and used as the target device (having... Figure 1 The structure and function of the target device 110 and the source device (with) Figure 1 The structure and function of source device 120 in the document. Device 510A stores multiple encryption keys, including an authentication key (similar to...). Figure 1 The encryption verification key set 114 shown) and private key (similar to) Figure 1The source private key shown is 127. The encryption keys shown in these examples include, but are not limited to, specific encryption keys, device-specific authentication and private key pairs, device-category authentication and private key pairs, and authentication keys for engineering tools. Note that device 510A may store authentication and private key pairs for more than one category and / or authentication keys for more than one engineering tool.

[0112] During the storage phase, device 510A stores a signed set of FDRs in FDR storage device 520, including one or more candidate instances of FDR data. Each instance of FDR data is signed by different private source keys of device 510A, such as the device's individual private key and one or more class-specific private keys of the device. The configuration and function of FDR storage device 520 are similar to... Figure 1 The FDR storage device 132 shown is an example. Different instances of FDR data can be different from each other, or they can be the same. For example, the FDR data of an instance signed by one of the device categories can have different characteristics or provide different settings for characteristics than the FDR data of an instance signed by a different category, such as the device category, the device itself, or an engineering tool.

[0113] During the retrieval phase, device 510A retrieves the signed FDR dataset. Device 510A attempts to verify the signature used to sign the FDR data in the signed FDR dataset using verification keys stored by device 510A. Device 510A may apply logic to determine the hierarchy of verification keys, used to determine the order in which verification keys (individual, category, and / or engineering tool) are used to attempt verification. Figure 5 In the illustrated use case, consistent with the applied logic, the individual private key of device 510A is used to verify the signed FDR data. Therefore, device 510A concludes that it has stored the FDR data and should use it.

[0114] refer to Figure 6 In the second use case, device 510A, labeled as device A, is configured and used as the source device (having... Figure 1 The structure and function of the source device 120 in the middle). Device 510B is used as the target device (with Figure 1 (Structure and function of target device 110). For example, in Figure 5 In the example, device A stores multiple encryption keys, including a private key (similar to...). Figure 1 The source private key 127 is shown in the diagram. Device 510A can also store a verification key paired with the private key in case it is also used as a target device, but this is not necessary for this particular use case. Device 510B can store multiple encryption keys, including a verification key (similar to...). Figure 1The encrypted verification key set 114 is shown. In this example, these verification keys will need to be paired with corresponding private keys stored by device 510A in order to verify the retrieved signed FDR data. Optionally, device 510B may also store a pair of private keys for each verification key.

[0115] During the storage phase, similar to Figure 5 The illustrated first use case shows that device 510A stores a set of signed FDRs in FDR storage device 520, including one or more candidate instances of FDR data, each instance of FDR data being signed by different private source keys of device 510A, such as the device's individual private key and one or more categories of private keys of the device.

[0116] During the retrieval phase, device 510B uses identification information to retrieve the signed FDR dataset. Device 510B attempts to verify the signature used to sign the FDR data in the signed FDR dataset using verification keys stored by device 510B. Device 510B may apply logic to determine the hierarchy of verification keys, used to determine the order in which verification keys (individual, category, and / or engineering tool) are used to attempt verification. Figure 6 In the illustrated use case, consistent with the applied logic, device 510B's class private key is used to verify the signed FDR data. Device 510B therefore concludes that it does not store the FDR data, but different devices in its trusted class do store the FDR data, and device 510B further concludes that it should use the FDR data.

[0117] refer to Figure 7 In the third use case, engineering tool 514 is configured and used as a source device (having similar characteristics to...). Figure 1 The structure and function of the source device 120 in the middle). Device 510B is used as the target device (with Figure 1 The structure and function of the target device 110 in the text). Engineering tool 514 stores one or more encryption keys 516, including at least one private key (similar to...). Figure 1 The source private key shown is 127.

[0118] In one or more embodiments, one or more encryption keys 516 may include a pair of keys, including a key for performing signature verification when retrieving stored information (e.g., the public key of engineering tool 514, which may be kept secret). To protect against the injection of malicious FDR data into engineering tool 514 (such as before engineering tool 514 signs the FDR data), one or more encryption keys 516 may include keys for verifying one or more devices and / or device classes that may be the source of the FDR data stored by engineering tool 514.

[0119] Device 510B can store multiple encryption keys, including an authentication key (similar to...). Figure 1 The encrypted verification key set 114 is shown. In this example, these verification keys will need to be paired with corresponding private keys stored by device 510A in order to verify the retrieved signed FDR data. Optionally, device 510B may also store a pair of private keys for each verification key.

[0120] During the storage phase, engineering tool 514 stores a set of signed FDRs in FDR storage device 520, including one or more candidate instances of FDR data, each instance of FDR data being signed by a different private source key of engineering tool 514.

[0121] During the retrieval phase, device 510B retrieves the signed FDR dataset. Device 510B attempts to verify the signature used to sign the FDR data in the signed FDR dataset using verification keys stored by device 510B. Device 510B may apply logic to determine the hierarchy of verification keys, used to determine the order in which verification keys (individual, category, and / or engineering tool) are used to attempt verification. Figure 7 In the illustrated use case, consistent with the applied logic, the engineering tool private key of device 510B is used to verify the signed FDR data. Device 510B therefore concludes that it did not store the FDR data, but the trusted engineering tool did store the FDR data, and device 510B further concludes that it should use the FDR data.

[0122] refer to Figure 8 It provides something similar to Figure 7 Additional use cases, besides retrieving signed FDR datasets loaded into FDR storage device 520 by engineering tool 514 from multiple target devices 510B, include the use case for further processing. During the storage phase, engineering tool 514 can store signed FDR data in FDR storage device 520. This can be performed with a single storage operation. The signed FDR data can be configured to change one or more characteristics of target device 150B (i.e., device 510B). Figure 8 In the use case shown, an FDR operation is used to update a feature of the corresponding target device 510B.

[0123] Target device 510B can be designed to accept a portion or subset of FDR data. For example, multiple target devices 510B in a site may have one thousand motor control center buckets. These target devices 510B are configured with the same network gateway. An event occurs requiring a change to the gateway's IP address. The FDR dataset with only the network gateway's IP address set can be created and signed by engineering tool 514 using a valid key. The signed FDR dataset can be distributed to all of the multiple target devices to deploy the setting change.

[0124] During the retrieval phase, device 510B retrieves or otherwise obtains a signed FDR dataset from FDR storage device 520. The number of target devices 510B is not limited to a specific number. In this way, there can be 10s, 100s, or 1000s (or more) of target devices that can use the retrieved signed FDR dataset to update this feature. The retrieval can be a push or pull operation.

[0125] Potential advantages provided by this use case include the ability for users to operate engineering tool 514 to store updates for one or more settings by storing signed FDR data in FDR storage device 520 using a single storage operation during the storage phase. This update can be pushed or made available to multiple target devices 510B, thus providing the ability to perform security updates on a small or large number of target devices 510B.

[0126] In the example scenario, the target device 510B can be a TeSys Ts™ device. In some embodiments, updates can be performed autonomously, for example, by pushing updates over a network via TeSys Ts devices or by automatic periodic update checks by TeSys Ts devices. In addition to saving time and manpower, update settings will be consistent across all TeSys Ts devices. Update security is strong because the source device providing the update is trusted and verified, and in this example engineering tool 514, it must be trusted and verified by each TeSys Ts device being updated.

[0127] Additionally, the corresponding target device 510B can be configured with different logic to be applied, for example, where the logic consists of... Figure 1 The acceptable source logic module 113 is shown in the diagram. This allows the corresponding target device 510B to behave according to its individual logic, such as by using different FDR data included in the FDR dataset retrieved (pushed or pulled) by the corresponding target device 510B, or by deciding whether to allow the update settings.

[0128] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions.

[0129] These computer program instructions can be provided to the processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0130] These computer program instructions may also be stored in a computer-readable medium that can instruct a computer, other programmable data processing apparatus, or other device to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of writing comprising instructions that implement the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0131] Computer program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operations 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 a process for implementing the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0132] refer to Figure 9 A block diagram of an example processing system 900 is shown, which provides a processing system consisting of... Figure 1 The target device 120, data source 120, and FDR storage device 130 shown are as follows: Figure 5-8 The illustrated devices 510A and 510B, engineering tool 514, and FDR storage device 520 are examples of computing system configurations used. Additionally, all or part of the computing components of the illustrated FDR system can be configured as software, and processing system 900 can represent such a portion. Processing system 900 is merely one example of a suitable system and is not intended to impose any limitation on the scope or functionality of the embodiments of this disclosure described herein. Processing system 900 can be implemented using hardware, software, and / or firmware. In any case, processing system 900 is capable of being implemented and / or performing the functions set forth in this disclosure.

[0133] The processing system 900 is shown in the form of a general-purpose computing device. The processing system 900 includes a processing device 902, a memory 904, and an input / output (I / O) interface (I / F) 906, which can communicate with internal components (such as a user interface 910) and optionally external components 908.

[0134] In some embodiments, the processing device 902 may include, for example, a PLOD, a microprocessor, a DSP, a microcontroller, a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and / or other discrete or integrated logic circuits with similar processing capabilities.

[0135] In some embodiments, the processing device 902 and the memory 904 may be included in components provided, for example, in an FPGA, ASIC, microcontroller, or microprocessor.

[0136] Memory 904 may include, for example, volatile and non-volatile memory for temporary or long-term data storage and for storing programmable instructions executable by processing device 902. Memory 904 may be removable (e.g., portable) memory for storing program instructions. I / OI / F 906 may include interfaces and / or conductors for coupling to one or more internal components 910 and / or external components 908.

[0137] In some embodiments, I / OI / F 906 may be a two-wire connection of the APL edge device configured to communicate with components of the APL edge device’s local network and to access a remote network.

[0138] An embodiment of the computing component of an industrial system may be implemented or executed by one or more computer systems, such as microprocessors. Each processing system 900 may be included within the computing component of the industrial system or multiple instances thereof.

[0139] In some embodiments, the processing system 900 is embedded in a host device, such as an edge device. Parts of the processing system 900 may be provided externally, for example, via an interface.

[0140] The processing system 900 is merely one example of a suitable system and is not intended to impose any limitation on the scope or functionality of the embodiments described herein. In any case, the processing system 900 can be implemented to perform any of the functions set forth above.

[0141] The processing system 900 can be described within the general context of executing executable instructions (such as program modules) of a computer system. Typically, program modules can include routines, programs, objects, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types.

[0142] Various embodiments have been referenced in the foregoing. However, the scope of this disclosure is not limited to the specifically described embodiments. Rather, any combination of the described features and elements, whether or not associated with different embodiments, is contemplated to achieve and practice the contemplated embodiments. Furthermore, while embodiments may provide advantages over other possible solutions or over the prior art, whether a particular advantage is achieved by a given embodiment does not limit the scope of this disclosure. Therefore, the foregoing aspects, features, embodiments, and advantages are merely illustrative and should not be considered as elements or limitations of the appended claims unless expressly stated in the claims.

[0143] The various embodiments disclosed herein can be implemented as systems, methods, or computer program products. Therefore, aspects can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects, all of which are generally referred to herein as “circuit,” “module,” or “system.” Furthermore, aspects can take the form of computer program products embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0144] Any combination of one or more computer-readable media may be used. The computer-readable medium may be a non-transitory computer-readable medium. A non-transitory computer-readable medium may be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof. More specific examples of non-transitory computer-readable media (a non-exhaustive list) may include the following: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, RF, etc., or any suitable combination thereof.

[0145] Computer program code used to perform the operations of various aspects of this disclosure can be written in any combination of one or more programming languages. Furthermore, such computer program code can be executed using a single computer system or multiple computer systems communicating with each other (e.g., using a local area network (LAN), wide area network (WAN), the Internet, etc.). While the various features described above are illustrated with reference to flowcharts and / or block diagrams, those skilled in the art will understand that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer logic (e.g., computer program instructions, hardware logic, combinations of both, etc.). Typically, computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus. Furthermore, using one or more processors to execute such computer program instructions produces a machine capable of performing one or more functions or actions specified in one or more blocks of the flowcharts and / or block diagrams.

[0146] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and / or operation of various implementations of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a non-linear order. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It will also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a system based on dedicated hardware or a combination of dedicated hardware and computer instructions that performs the specified function or action.

[0147] It should be understood that the above description is intended to be illustrative and not restrictive. Many other implementation examples will become apparent after reading and understanding the above description. Although specific examples are described in this disclosure, it should be recognized that the systems and methods of this disclosure are not limited to the examples described herein but can be practiced with modifications within the scope of the appended claims. Therefore, the specification and drawings should be regarded as illustrative rather than restrictive. Consequently, the scope of this disclosure should be determined by reference to the appended claims and the full scope of their equivalents.

Claims

1. A method for performing Fast Device Replacement (FDR) by a device coupled to a network, the method comprising: Store the encryption key set; Access to at least one signed replacement dataset provided to the FDR storage device by one or more corresponding sources; The source of a particular signed replacement data candidate in at least one accessed signed replacement dataset is verified by using an encryption algorithm and a stored set of encryption keys to verify the cryptographic signature used to sign a particular signed replacement data candidate. and Allows for rapid device replacement using specific signed replacement data candidates that await verification of their associated cryptographic signatures.

2. The method according to claim 1, in, Each encryption key in the encryption key set is associated with the type of the source, and the type of the source associated with the encryption key in the encryption key set used to verify the source is identified as the type of the source. The method further includes applying rules that define one or more conditions and / or hierarchical levels of different types of sources associated with corresponding encryption keys in the encryption key set, and The rule that allows for rapid device replacement using replacement data from the specific signed replacement data candidates is managed by the rule itself.

3. The method according to claim 2, wherein, When one or more of the conditions include the device being newly coupled to the network, the rule allows the replacement if the type of the identified source is a device category or trusted tool to which the device belongs; and The rule allows the replacement when the identified source is a device or a trusted tool, provided that one or more of the conditions include that the device was previously coupled to the network.

4. The method according to claim 2, wherein, The device is configured with the rules either as a factory setting or via user configuration.

5. The method according to claim 1, wherein, Each encryption key in the encryption key set is associated with an identifier and / or type of the source, wherein the method further includes recording an indication of whether the verification was successful, wherein the identifier and / or type of the source is associated with an encryption key in the encryption key set used to verify the source.

6. The method according to claim 2, wherein, The type of the identified source is either a source category or a trusted tool, and when the type of the identified source is a source category, verifying the source further includes determining whether the source category belongs to an allowed device category of the device, and when the type of the identified source is a trusted tool, verifying the source further includes determining whether the trusted tool is trusted by the device.

7. The method according to claim 2, further comprising: Data replacement in storage devices; The device replacement data is signed using a device key, which is unique to the device and included in the encryption key set; and The FDR storage device is configured such that the signed device replacement data is stored together with the signed replacement dataset in the FDR storage device.

8. The method according to claim 1, wherein, The encryption key set, the key used to sign the signed replacement data included in the signed replacement dataset, and the encryption algorithm are configured to use an asymmetric key or a symmetric key with a key hash.

9. The method of claim 1, further comprising requesting the execution of the FDR process using replacement data from the FDR storage device, wherein, The at least one signed replacement dataset is accessed in response to the request.

10. The method according to claim 1, wherein, The specific signed replacement data candidate includes an update of a selected data field among a plurality of data fields stored by the device, and allows the fast device replacement to include updating the selected data field using the specific signed replacement data candidate.

11. The method according to claim 10, wherein, The device is a plurality of devices, and the source is configured to provide the particular signed replacement data candidate to the FDR storage device once to cause an update of the selected data field in each of the plurality of devices.

12. The method according to claim 11, wherein, The command enables the plurality of devices to access the specific candidate replacement dataset via a push action from the FDR storage device or a pull action from the plurality of devices.

13. A method performed by a Fast Device Replacement (FDR) storage device for providing a replacement dataset to the device when the device is coupled to a network, the method comprising: Store multiple signed replacement datasets, each replacement dataset being signed by a corresponding source using the source's cryptographic key and having a corresponding data identifier that identifies the replacement dataset; and The device is provided with one or more candidate signed replacement datasets from the plurality of signed replacement datasets. The corresponding one or more candidate replacement datasets are evaluated by the device using an encryption algorithm and a locally stored encryption verification key through one or more attempts to verify any one of the one or more candidate signed replacement datasets, and the device is configured to allow fast device replacement only when the verified one or more candidate replacement datasets are used.

14. The method according to claim 13, wherein, The encryption key for the corresponding source is a private key that identifies the source or the category of the source.

15. The method of claim 13, further comprising: Receive a request for a replacement dataset from a plurality of candidate devices, the request including indications of aspects of the device; and The selection of the candidate replacement dataset from the plurality of replacement datasets uses the indication of the aspect of the device.

16. The method according to claim 15, wherein, The aspects of the device include the identifier of the device or the identifier of the category of the device.

17. The method according to claim 13, wherein, The one or more candidate replacement datasets include updates to selected data fields among a plurality of data fields stored by the device, and when the device allows for fast device replacement using a specific candidate signed replacement dataset, the specific candidate signed replacement dataset is used to cause an update to the selected data fields.

18. The method according to claim 17, wherein, Providing one or more candidate signed replacement datasets to the device includes providing the one or more candidate signed replacement datasets to multiple devices, wherein the multiple devices are configured to evaluate the one or more candidate signed replacement datasets using the cryptographic algorithm and its corresponding locally stored cryptographic verification key to attempt to verify any one of the one or more candidate replacement datasets, and the respective multiple devices are configured to allow fast device replacement only when using the one or more candidate signed replacement datasets verified by the corresponding device.

19. The method of claim 18, further comprising receiving a command, wherein, In response to the command, a push action is performed to provide the one or more candidate replacement datasets to the plurality of devices.

20. A method executed by a trusted tool, the method comprising: The encryption key is stored locally, and the encryption key is unique to the trusted tool or the tool group to which the trusted tool belongs, or otherwise identifies the trusted tool or the tool group to which the trusted tool belongs; Obtain or generate replacement datasets provided by the tool; The replacement dataset provided by the tool is signed using the encryption key; and The replacement dataset provided by the signed tool is stored remotely in a Fast Device Replacement (FDR) storage device. In this configuration, a device among multiple devices coupled to the network is configured to access the replacement dataset provided by the signed tool from multiple replacement datasets stored by the FDR storage device, and the device is configured to allow fast device replacement only when the replacement dataset provided by the signed tool is used if the device successfully verifies the replacement dataset provided by the signed tool using an encryption algorithm and a verification encryption key stored locally by the device.

21. The method according to claim 20, wherein, The replacement dataset provided by the tool includes updates to selected data fields among a plurality of data fields stored by the device, wherein the device includes one or more devices and the one or more devices are configured to allow the fast device replacement for updating the selected data fields using the replacement dataset provided by the tool.

22. The method of claim 21, further comprising instructing the FDR storage device to cause the update of the selected data field of the plurality of devices using a replacement set provided by the signed tool.

23. A computer system for the apparatus according to claim 1, the computer system comprising: A memory configured to store multiple programmable instructions; and A processing device communicating with the memory, wherein the processing device is configured to perform the method according to claim 1 when executing the plurality of programmable instructions.

24. A storage system for an FDR storage device according to claim 13, the storage system comprising: A memory configured to store multiple programmable instructions; and A processing device communicating with the memory, wherein the processing device is configured to perform the method according to claim 13 when executing the plurality of programmable instructions.

25. A computer system for a trusted tool according to claim 20, the computer system comprising: A memory configured to store multiple programmable instructions; and A processing device communicating with the memory, wherein the processing device is configured to perform the method according to claim 20 when executing the plurality of programmable instructions.

Images