U.S. patent application number 16/687919 was filed with the patent office on 2020-06-25 for method and process for blockchain implementation with third party devices.
This patent application is currently assigned to Rolls-Royce North American Technologies Inc.. The applicant listed for this patent is Rolls-Royce North American Technologies Inc. Rolls-Royce Corporation. Invention is credited to John J. Costello, Robert T. Duge, Richard J. Skertic.
Application Number | 20200198797 16/687919 |
Document ID | / |
Family ID | 71096955 |
Filed Date | 2020-06-25 |
![](/patent/app/20200198797/US20200198797A1-20200625-D00000.png)
![](/patent/app/20200198797/US20200198797A1-20200625-D00001.png)
![](/patent/app/20200198797/US20200198797A1-20200625-D00002.png)
![](/patent/app/20200198797/US20200198797A1-20200625-D00003.png)
![](/patent/app/20200198797/US20200198797A1-20200625-D00004.png)
![](/patent/app/20200198797/US20200198797A1-20200625-D00005.png)
![](/patent/app/20200198797/US20200198797A1-20200625-D00006.png)
![](/patent/app/20200198797/US20200198797A1-20200625-D00007.png)
![](/patent/app/20200198797/US20200198797A1-20200625-D00008.png)
![](/patent/app/20200198797/US20200198797A1-20200625-D00009.png)
![](/patent/app/20200198797/US20200198797A1-20200625-D00010.png)
United States Patent
Application |
20200198797 |
Kind Code |
A1 |
Skertic; Richard J. ; et
al. |
June 25, 2020 |
METHOD AND PROCESS FOR BLOCKCHAIN IMPLEMENTATION WITH THIRD PARTY
DEVICES
Abstract
A method for controlling an engine having a control module and
smart nodes. The method includes maintaining a block chain ledger,
which includes an information block from at least a preceding
engine start, may be at the control module of the aircraft engine.
The method also includes maintaining a hash of at least a digital
certificate and data at one of the smart nodes; transmitting a
message including the hash to the control module; receiving the
message at the control module; determining a control hash based
upon the information from at least a preceding engine start at the
control module; module comparing the hash to the control hash at
the control; and based upon the comparison, starting the engine and
updating the block chain ledger as a function of the received
message.
Inventors: |
Skertic; Richard J.;
(Carmel, IN) ; Costello; John J.; (Indianapolis,
IN) ; Duge; Robert T.; (Carmel, IN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Rolls-Royce North American Technologies Inc.
Rolls-Royce Corporation |
Indianapolis
Indianapolis |
IN
IN |
US
US |
|
|
Assignee: |
Rolls-Royce North American
Technologies Inc.
Indianapolis
IN
Rolls-Royce Corporation
Indiannapolis
IN
|
Family ID: |
71096955 |
Appl. No.: |
16/687919 |
Filed: |
November 19, 2019 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62785601 |
Dec 27, 2018 |
|
|
|
62783017 |
Dec 20, 2018 |
|
|
|
62782984 |
Dec 20, 2018 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 2463/062 20130101;
H04L 12/437 20130101; H04L 9/0637 20130101; H04L 9/0825 20130101;
H04L 63/062 20130101; F02C 7/26 20130101; H04L 63/12 20130101; H04L
63/123 20130101; B64D 31/06 20130101; H04L 9/3242 20130101; H04L
9/3239 20130101; H04L 9/0643 20130101; G06F 12/1018 20130101; G06F
16/2379 20190101; G06F 16/182 20190101; H04L 9/0618 20130101; H04L
2209/38 20130101; G05B 19/0425 20130101; H04L 63/0823 20130101;
G06F 21/575 20130101; H04L 63/0435 20130101; H04L 9/006 20130101;
G06F 21/125 20130101; H04L 9/3263 20130101 |
International
Class: |
B64D 31/06 20060101
B64D031/06; H04L 9/06 20060101 H04L009/06; H04L 9/32 20060101
H04L009/32 |
Claims
1. A method for controlling an engine having a control module and
smart nodes comprising: maintaining a block chain ledger at the
control module of the aircraft engine, wherein the block chain
comprises an information block from at least a preceding engine
start; maintaining a hash of at least a digital certificate and
data at one of the smart nodes; transmitting a message including
the hash to the control module; receiving the message at the
control module; at the control module determining a control hash
based upon the information from at least a preceding engine start;
at the control module comparing the hash to the control hash; based
upon the comparison, starting the engine and updating the block
chain ledger as a function of the received message.
2. The method of claim 1, further comprising maintaining a second
hash of at least the digital certificate and data at another of the
smart nodes; wherein the message includes the second hash; and
wherein the step of comparing the hash to the control hash, further
comprises comparing the second hash to the control hash.
3. The method of claim 1, wherein the step of transmitting the
message also includes encrypting the message with one of a private
key or public key.
4. The method of claim 1, wherein the step of receiving the message
also comprises decrypting the message with one of a private key or
public key.
5. The method of claim 1, further comprising at the one of the
smart nodes maintaining a local block chain ledger, wherein the
local block chain comprises a digital certificate and data from at
least the preceding engine start and wherein the step of
transmitting further comprises updating the local block chain
ledger.
6. The method of claim 1, wherein the data is selected from the
group consisting of manufacturer, serial number of the smart node,
software configuration, date of manufacture, date of qualification,
public key and a preceding hash.
7. The method of claim 5, wherein the step of updating the local
block chain ledger further comprises deleting the preceding block
from the local block chain ledger.
8. The method of claim 1, further comprising updating the digital
certificate.
9. The method of claim 8, wherein the digital certificates are
updated annually.
10. The method of claim 1, wherein the step of determining a
control hash further comprises updating the block chain ledger with
a digital certificate and data associated with the one smart node
prior to the comparison.
11. The method of claim 10, wherein the data includes a hash from a
preceding smart node message.
12. The method of claim 1, wherein the control module and smart
nodes are arranged in a DCS architecture.
13. The method of claim 1, wherein the control module and smart
nodes are arranged in a CCS architecture.
14. The method of claim 1, wherein the control module maintains
block chain ledgers for each of the smart nodes.
15. A method of authentication of a smart node in a gas turbine
engine, comprising: determining the required operational
characteristics for the smart node; generating a hash at a control
module reflective of required operational characteristics for the
smart node; storing the hash in a block chain; receiving a second
hash at the control module from the smart node; comparing the hash
in the block chain with the second hash; authenticating the
operation of the smart node based upon the comparison; and,
updating the block chain with the second hash.
16. The method of claim 15, further comprising generating the
second hash at the smart node as at least a reflection of
operations characteristics of the smart node.
17. The method of claim 16, wherein the second hash is further
reflective of a preceding hash contained in a local block chain at
the smart node.
18. The method of claim 15, further comprising starting a gas
turbine subsequent to the authentication of the smart node.
19. The method of claim 16, wherein the generation of the second
hash is performed upon installation of the smart node on the gas
turbine.
20. A method for authenticating a component on a gas turbine prior
to operation, comprising: maintaining a block chain ledger at a
control module of the gas turbine, wherein the block chain
comprises successive information blocks; wherein the information
blocks include information reflective of at least the component;
receiving a message at the control module from the component; at
the control module determining a control hash based upon the
information reflective of at least the component; determining a
hash based at least upon the received message and at the control
module comparing the hash to the control hash; based upon the
comparison, authenticating the component, updating the block chain
ledger as a function of the receive message; and, operating the gas
turbine.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present application is a non-provisional application of,
and claims priority to, U.S. Provisional Application No.
62/785,601, filed Dec. 27, 2018, title: A METHOD AND PROCESS FOR
BLOCKCHAIN IMPLEMENTATION WITH THIRD PARTY DEVICES. This
application also claims priority to co-pending U.S. Provisional
Application No. 62/783,017, filed Dec. 20, 2018, title: BLOCKCHAIN
BASED VEHICLE CONTROL and U.S. Provisional Application No.
62/782,984, filed Dec. 20, 2018, title: SECURE ENGINE
COMMUNICATION. The present application is also related to
co-pending U.S. application Ser. No. 16/283,644, filed Feb. 22,
2019, title: A METHOD AND PROCESS FOR SECURING AN EXECUTABLE IMAGE.
The entireties of each of these applications are incorporated
herein by reference.
BACKGROUND
[0002] Aircrafts, such as commercial and military aircraft, include
aerospace control systems that control and monitor aircraft
engines. The aerospace control systems may control and/or monitor
aerospace control system components such as, for example, aircraft
engine pressure sensors, temperature sensors, solenoids, and
actuators. The aerospace control systems may also control and/or
manage other aircraft engine parts and/or functionality. For
example, aerospace control systems may assist in ensuring optimum
aircraft engine efficiencies during flight are achieved by
receiving various flight condition information and controlling
various aircraft engine operations, such as fuel flow, valve
positions, and others. Aerospace control systems may include a full
authority digital engine controller ("FADEC") that includes an
electronic engine controller ("EEC") or engine control unit
("ECU"). The FADEC may further include a central processing unit
("CPU"), memory, and a data bus to communicate with other aircraft
engine components, such as aircraft engine sensors and actuators.
In addition, the FADEC may include maintenance ports and/or
communication ports. These ports include connector interfaces for
various connector types such as Ethernet ports, serial ports,
and/or universal serial bus ("USB") ports, among others, that may
connect with different parts of the aircraft.
[0003] Aerospace control systems may be implemented as a
centralized (or federated) control system ("CCS") architecture
design or a distributed control system ("DCS") architecture design.
Aerospace control systems incorporating a CCS architecture design
include a FADEC with a CPU that handles all processing functions as
generally shown in FIG. 1A. The FADEC also includes additional
electronic circuitry required for data acquisition (such as from
the various sensors) as well as signal conditioning. In addition,
interface (e.g., wire) harnesses may be used to connect the various
aerospace control system components, such as sensors and/or
actuators to the FADEC.
[0004] An aerospace control system incorporating a DCS architecture
design, however, may not require a FADEC with this additional
circuitry. Instead, the various aerospace control system components
(e.g., sensors and/or actuators) include local processing
capabilities that can relay information to the FADEC's CPU as shown
in FIG. 1B. In addition, a DCS architecture design includes digital
communication between the FADEC and the various sensors and/or
actuators, rather than interface harnesses. Aerospace control
systems with a DCS architecture design may also employ a data
concentrator (e.g., concentrator node) that provides for
communication with both components that do not include local
processing capabilities as well as components that do include local
processing capabilities. The data concentrator facilitates the
communications between the FADEC and the nodes.
[0005] These aerospace architectures, however, have vulnerabilities
during operation in a cyber-hostile environment. For example,
threats from a cyber-attack can come from software loaded onto the
FADEC via one of the FADEC's maintenance or communication ports.
Threats may also come from hacking into access points over
communication links between the FADEC and other parts of the
aerospace control system, such as sensors and actuators. In
addition, aerospace architectures are vulnerable to "hardware
hacks," where hardware, such as the FADEC or a communication link,
is physically altered to allow access to the aerospace control
system. Cyber threats may also include passively extracting
executable code or software images via software, JTAG and serial
interfaces (e.g. RS 232, USB, etc . . . ). Offensively extracting
executable code or software images via direct accessing or removal
of flash memory; Extraction, analysis and decompiling firmware
images and manipulation of firmware images to gain access and
exploit communications or controls, or to attack some other area of
functionality.
[0006] Engine manufacturers are the type certificate holder for all
aspects of each engine, engine controls, communications network,
power distribution, etc. The certification framework of FAA and
EASA requires for new engine programs, these systems must be
demonstrated to be cyber secure. Thus the engine manufacturer is
responsible for the security of the data and controls used in the
engine network to process sensor data, operate actuators, handle
communications with the airframe, monitor safety and criticality
issues, etc. Engine manufacturers typically work with external
suppliers (third party vendors) to manufacture smart sensors or
other similar products/components. These electronic interface poses
a new risk for cyber hacking via a third party interaction.
[0007] To address potential weaknesses with the authenticity of
each part, confirmation of the software configuration, and
provenance of the part, a methodology to validate that the third
party components are the ones designed, developed, qualified and
certified for the manufacturers engines using a block chain ledger
becomes advantageous.
[0008] As used herein a block chain or distributed ledger being a
cryptographically secure ledger containing many different
transactions, which may be used to provide secure communication
within the engine. The transactions may be grouped into blocks. The
blocks may be linked (i.e., chained) together with cryptographic
algorithms to form a block chain. An advantage of block chain is
its integrity. Once appended to the block chain for a sufficient
amount of time, revising blocks to add, modify, and/or remove
transactions becomes intractable (i.e., substantially
impossible).
SUMMARY
[0009] Presented is a method for controlling an engine having a
control module and smart nodes. The method includes maintaining a
block chain ledger may be at the control module of the aircraft
engine, where the block chain may include an information block from
at least a preceding engine start. The method may also include
maintaining a hash of at least a digital certificate and data at
one of the smart nodes; transmitting a message including the hash
to the control module; receiving the message at the control module;
determining a control hash based upon the information from at least
a preceding engine start at the control module; module comparing
the hash to the control hash at the control; and based upon the
comparison, starting the engine and updating the block chain ledger
as a function of the received message.
[0010] The method may further include maintaining a second hash of
at least the digital certificate and data at another of the smart
nodes; wherein the message includes the second hash; and wherein
the step of comparing the hash to the control hash, further
comprises comparing the second hash to the control hash. The step
of transmitting the message also includes encrypting the message
with one of a private key or public key. The step of receiving the
message also comprises decrypting the message with one of a private
key or public key. The method may further include at the one of the
smart nodes maintaining a local block chain ledger, the local block
chain may include a digital certificate and data from at least the
preceding engine start, and the step of transmitting may further
include updating the local block chain ledger. The data may be
selected from the group consisting of manufacturer, serial number
of the smart node, software configuration, date of manufacture,
date of qualification, public key and a preceding hash. The step of
updating the local block chain ledger further comprises deleting
the preceding block from the local block chain ledger. The method
may further include updating the digital certificate. The digital
certificates are updated annually. The step of determining a
control hash further comprises updating the block chain ledger with
a digital certificate and data associated with the one smart node
prior to the comparison. The data may include a hash from a
preceding smart node message. The control module and smart nodes
may be arranged in a DCS architecture. The control module and smart
nodes may be arranged in a CCS architecture. The control module
maintains block chain ledgers for each of the smart nodes.
[0011] A method of authentication of a smart node in a gas turbine
engine, may include: determining the required operational
characteristics for the smart node; generating a hash at a control
module reflective of required operational characteristics for the
smart node; storing the hash in a block chain; receiving a second
hash at the control module from the smart node; comparing the hash
in the block chain with the second hash; authenticating the
operation of the smart node based upon the comparison; and,
updating the block chain with the second hash.
[0012] The method may further include generating the second hash at
the smart node as at least a reflection of operations
characteristics of the smart node. The second hash is further
reflective of a preceding hash contained in a local block chain at
the smart node. The method may further include starting a gas
turbine subsequent to the authentication of the smart node. The
generation of the second hash may be performed upon installation of
the smart node on the gas turbine.
[0013] A method for authenticating a component on a gas turbine
prior to operation, may include: maintaining a block chain ledger
at a control module of the gas turbine, the block chain includes
successive information blocks; the information blocks may include
information reflective of at least the component; receiving a
message at the control module from the component; at the control
module determining a control hash based upon the information
reflective of at least the component; determining a hash based at
least upon the received message and at the control module comparing
the hash to the control hash; based upon the comparison,
authenticating the component, updating the block chain ledger as a
function of the receive message; and, operating the gas
turbine.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] The following will be apparent from elements of the figures,
which are provided for illustrative purposes.
[0015] FIGS. 1A and 1B are respective illustrations of a
Centralized Control System and a Distributed Control System for of
an engine.
[0016] FIG. 2 is an illustration of an aircraft engine employing an
engine control system in accordance with some embodiments.
[0017] FIG. 3 illustrates a block diagram of an engine control
system in accordance with some embodiments;
[0018] FIG. 4 illustrates a block diagram of an engine control
system in accordance with embodiments of the disclosed subject
matter.
[0019] FIG. 5. illustrates a block diagram of another engine
control system in accordance with embodiments of the disclosed
subject matter.
[0020] FIG. 6 lists examples of data sent in messages in accordance
with embodiments of the disclosed subject matter.
[0021] FIG. 7 illustrates a smart node creating and transmitting a
hash to the control module in accordance with embodiments of the
disclosed subject matter.
[0022] FIGS. 8A and 8B illustrate the 1:N and 1:1 relationship
respectively between a central block chain ledger and smart nodes
in accordance with embodiments of the disclosed subject matter.
[0023] While the present disclosure is susceptible to various
modifications and alternative forms, specific embodiments have been
shown by way of example in the drawings and will be described in
detail herein. It should be understood, however, that the present
disclosure is not intended to be limited to the particular forms
disclosed. Rather, the present disclosure is to cover all
modifications, equivalents, and alternatives falling within the
spirit and scope of the disclosure as defined by the appended
claims.
DETAILED DESCRIPTION
[0024] For the purposes of promoting an understanding of the
principles of the disclosure, reference will now be made to a
number of illustrative embodiments in the drawings and specific
language will be used to describe the same.
[0025] FIG. 1A illustrates a Centralized Control System (CCS), the
control system has been optimized to run the engine and to process
the data from the sensors and/or to transmit control signals to the
actuators. These signals are either analog or digital
communications. In this topology, the data bus connecting the
controller to the sensors and actuators provides a major point of
entry for a potential cyberattack to the CPU and memory within the
Engine Control Unit (ECU). In addition to the data bus, the
external hardware interfaces are also points of ingress for a
cyber-attack.
[0026] FIG. 1B illustrates a Distributed Control System (DCS).
Although the DCS shown in FIG. 1B offers some control advantages
over the CCS noted in FIG. 1A, both control architectures have
vulnerabilities during operation in cyber hostile environments. The
DCS shown in FIG. 1B has additional access points over the
communications link between the FADEC and the Control/Actuation
nodes where a cyber-attack may gain entrance to the control system.
Obvious areas of susceptibility are the maintenance ports,
connector interfaces for traditional connectors, Ethernet and
serial communications ports. When combined with the potential for
smart sensors or smart nodes, the cyber threats are even more
significant as these nodes will have integral microprocessors and
software for functionality.
[0027] FIG. 2 illustrates the aircraft engine 102. The aircraft
engine 102 includes an engine control system 202 that includes a
control node 204 and a concentrator node 206. The control node may
be, for example, a FADEC. Each of the control node 204 and
concentrator node 206 includes electronic circuitry. The electronic
circuitry may include one or more processing units 208, 210. A
processing unit can be, for example, a microprocessor, an execution
unit or "core" on a microprocessor chip, a digital signal processor
(DSP), a soft or hard core within a field-programmable gate arrays
(FPGA), a processor within an application-specific integrated
circuit (ASIC), a general processing unit (GPU), a commercial off
the shelf (COTS) processor, or any other suitable processor.
[0028] Each of the control node 204 and concentrator node 206 may
include instruction memory 212, 214, respectively. Instruction
memory 212, 214 can store instructions that can be accessed (e.g.,
read) and executed by processing units 208, 210, respectively. For
example, each of instruction memory 212, 214 can be a
non-transitory, computer-readable storage medium such as a
read-only memory (ROM), an electrically erasable programmable
read-only memory (EEPROM), flash memory, a removable disk, CD-ROM,
any non-volatile memory, or any other suitable memory.
[0029] Each of the control node 204 and concentrator node 206 may
also include working memory 216, 218, respectively. Processing
units 208, 210 can store data to, and read data from, working
memory 216, 218, respectively. For example, processing units 208,
210 can store a working set of instructions to working memory 216,
218, such as instructions loaded from instruction memory 212, 214,
respectively. Processing units 208, 210 can also use working memory
208, 210, respectively, to store dynamic data.
[0030] FIG. 2 further illustrates, as part of aircraft engine 102,
a fan 213, a first compressor 216, a second compressor 217,
turbines 220, 221, 222, propulsion nozzle 223, and fan duct 211.
The fan duct 211 is supported by guide vanes 215 extending from
engine platform 250. The fan 213 is driven by a first shaft 224
connected to fan 213. First compressor 216 is driven by turbine 221
via a second shaft 225, and second compressor 217 is driven by
turbine 220 via a third shaft 226. Engine control system 202 may
also be communicatively coupled to one or more engine control
devices 227, 228, 232 such as sensors (e.g., pressure or speed
transducer) or actuators.
[0031] FIG. 3 illustrates a block diagram of an engine control
system 300 that includes a control node 302, a concentrator node
304, one or more sensors 306, one or more actuators 308, and one or
more smart sensors 310. Concentrator node 304 is communicatively
coupled to each of one or more sensors 306, one or more actuators
308, and one or more smart sensors 310 over communication link 312.
For example, concentrator node 304 may communicate with each of one
or more sensors 306, one or more actuators 308, and one or more
smart sensors 310 over communication link 312, which may be a fiber
optic communication link, an Ethernet link, or any other suitable
link. Communication link 312 may employ, for example, an
interconnect bus architecture. Communication between the control
node 302 and the sensor 306, 310 and the actuator 308 in the
embodiment shown in FIG. 3 is via the concentrator node.
[0032] Sensor 306 may be, for example, an optical sensor, a
pressure sensor, a temperature sensor, or any other suitable
sensor. Sensor 306 may provide sensor readings over communication
link 312 to concentrator node 306. Smart sensor 310 may be a sensor
that also provides processing capability. For example, rather than
merely providing raw sensor readings, smart sensor 310 may provide
calibrated readings over communication link 312 and/or may bypass
the concentrator node 304 and communicate with the control node 302
using the same methodology as employed by the concentrator node
304.
[0033] In FIG. 4 the components of a smart sensor 410 and smart
actuator 420 (smart nodes) are shown. Smart nodes complete the
analog to digital signal processing, use digital device drivers,
complete data translation, and other functions that are required
for efficient engine control. These sensors, actuators and
processing nodes are considered "smart" since they have the ability
to evaluate the sensed value or drive an actuator to provide a
digital output. Another variant of the smart node is the data
concentrator to process the analog to digital conversion, signal
processing, encryption, communications, etc. The sensing device 412
passes the analog signal to the signal conditioning device 414
which scales or as noted previously calibrates the analog signal,
the calibrated signal is then operated on by the signal processing
and encryption device 416. The output of the signal processing and
encryption process is transferred digitally from the smart sensor
410 over a digital network. Likewise, is the operation of smart
actuator 420, where the actuator device 422, receives calibrated
and scaled signal from the signal conditioning device 424, which
receives an analog signal from a signal processing and de
Encryption device 426. The smart actuator device also sends digital
signals back to the control module, such as position data of the
actuator in the same manner as the smart sensor 410.
[0034] Returning to FIG. 3, in some examples, concentrator node 306
includes drivers that can connect via a direct link (or over a bus
architecture), such as an optical or electrical harness, to one or
more actuators 308.
[0035] Concentrator node 304 is also communicatively coupled to
control node 302 over at least a first communication link 314. The
first communication link 314 may be fiber optic, Ethernet,
hardwired and/or wireless. First communication link 314 may be a
fiber optic link, such as one using multi-mode optical fiber (e.g.,
a multi-mode fiber optic link), for example. Control node 302 is
operable to transmit to, and receive data from, concentrator node
304 over first communication link 314. For example, concentrator
node 304 may send sensor readings, such as from one or more sensors
306 or one or more smart sensors 310, to control node 302 over
first communication link 314. In addition, control node 302 may
send control messages to concentrator node 304, such as control
messages to control one or more actuators 308, over first
communication link 314. In some examples, communications over first
communication link 314 are encrypted.
[0036] In some examples, first communication link 314 includes
multiple fiber optic links, such as in a braided ring. In some
examples, concentrator node 304 is also communicatively coupled to
control node 302 over a second communication link 316. Second
communication link 316 may also be a fiber optic link, a hardwired
link, such as an Ethernet link or wireless. In some examples,
control node 302 is operable to transmit to, and receive data from,
concentrator node 304 over second communication link 316. In some
examples, communications over second communication link 316 are
encrypted.
[0037] FIG. 5 illustrates an example of a Distributed Control
System (DCS) according to embodiments of the disclosed subject
matter. The components, control node 302, concentrator node 305,
smart sensors 310 and smart actuators 308 preform similar functions
as described above with respect to the CCS system, but in a
distributed architecture.
[0038] To address potential weaknesses with the authenticity of
each part in the control system architectures, confirmation of the
software configuration, and provenance of the part, as well as
protect against a cyber-attack, a methodology to use block chain
(i.e. a distributed ledger) with digital certificates to validate
that the parts are the ones designed, developed, qualified and
certified for respective engine is presented. Third parties
offering smart sensor/actuator or smart nodes for a respective
architecture are required to use a block chain encryption protocol
with manufacturer's issued digital certificate. The methodology
allows externally provided smart devices to communicate within the
architecture after confirming the identity and authenticity of the
parts. With this block chain integration the suppliers may develop
a unique block chain ledger for the control module and each smart
sensor, smart actuator or smart node.
[0039] According to embodiments of the disclosed subject matter,
the master or control node (control module) undertakes the method
to ensure the third party supplied nodes are authorized, properly
configured and operable with the control architecture irrespective
of whether the architecture is a CCS or a DCS. The method is
illustrated with respect to the architecture of FIGS. 3 and 5, but
is envisioned to be equally as beneficial to other
architectures.
[0040] The control module 302 polls each of the nodes upon startup
of the engine, or other regularly repeating operation or event, the
nodes respond by transmitting a message to the control module. The
control module polling may simply be an initial command to start or
sequence of commands. The transmitted message may include a hash of
a digital certificate maintained at the node, the hash may further
include data related to the node, as well as a preceding hash. FIG.
6 notes some of the basic information that may be included in the
digital certificate and/or data from each smart device.
[0041] For example, the data may include the manufacturer of the
node, the serial number/model of the smart node, the specific
software configuration of the node, date of manufacture of the
node, date of qualification of the component, date of installation,
a public key and/or a preceding hash (i.e. the hash of the
preceding message sent by the node). Additionally, other data, such
as engine run time, time stamps etc. may also be included. The
digital certificate, data and hash may be maintained at the node
using a local block chain ledger, and upon transmission of the
message the local block chain ledger may be updated. In accordance
with embodiments described herein, the nodes may additionally
encrypt the message with one of a private or public key from an
asymmetric key pair. The local block chain may also be truncated to
conserve memory space.
[0042] Upon receiving the hash from each of the nodes, the control
module using a corresponding public or private key from the key
pair, decrypts the message from each of the nodes. The control
module 302 then determines control hashes for each of the nodes
(306, 308 and 310) based upon information stored in a block of the
central block chain ledger associated with the preceding
start/event. Each block in the central block chain ledger may
include the digital certificate, data and/or hashes from the
messages sent by the nodes in the preceding start up.
[0043] The control module 302 may compare the determined control
hash with the hash of the message or the preceding hash. In some
embodiments, the control hash may be a collection of hashes from
each of the nodes, such that the components are validated as a
whole rather than individually. The control hash may be determined
by information stored in the central block chain ledger and/or from
the data received in the message from each of the nodes. For
example, the control node 302, may use the information known about
the smart node, such as serial number, date of install, previous
hash etc. to generate the control hash, or the control node 302 may
use the same data received in the message along with the previous
hash to determine the control hash, this latter example ensures the
data has not been tampered with subsequent the hashing.
[0044] Based upon the comparison, the authenticity and other
features of the smart node may be confirmed and the startup
operation may proceed. In addition, the central block chain as well
as the local node block chains may be updated as a function of the
received message. Given the limited memory typically associated
with the smart nodes, the local block chain ledger may delete a
preceding block from the local block chain ledger, such that the
local block chain ledger maintains a limited number of block,
whereas the larger central block chain may advantageously maintain
a more complete log as its memory is typically not as limited.
[0045] Upon installation of a new node or upon a regularly
occurring period, it may be necessary to update the central block
chain ledger, in addition to the local block chains. These updates
may be required as a result of the issuance of a new digital
certificate, a new asymmetric key pair, or other event. For
example, a new digital certificate may be issued annually to the
manufacturer, a new manufacturer for a component is established,
and/or software is updated. The updates may be accomplished with
new nodes, or updated nodes broadcasting changes to the control
module during an initialization step. The initialization
advantageously results in an updated central block chain which
contains an immutable record of the changes.
[0046] While it is advantageous to use asymmetric encryption, the
disclosed subject matter may also be practiced without asymmetric
encryption. Hashes reflective of the necessary operation of the
smart nodes may also be used (e.g. software version, inputs,
outputs of the smart node may be incorporated into a hash), and
only smart nodes expressing the hash would be authenticated. FIG. 7
illustrates the smart node 708 creating a hash from the software
version and sensor type. In FIG. 7, the smart node is a temperature
sensor for the T.sub.4 (turbine inlet temperature) running a second
version of software, thus the smart node creates a hash reflective
of the turbine inlet temperature sensor and the second version of
software, as well as the previous hash. This hash is then
transmitted to the control module 702, which likewise has generated
a hash from the properties of the sensor it expects to receive,
e.g. turbine inlet temperature sensor running a version two
software. Upon confirmation the hashes match, the properties (if
not also the manufacturer) are authenticated and the central block
chain is updated.
[0047] Referring to FIGS. 8A and 8B, the central block chain ledger
850 maintained at the control module may be a single block chain
used for each of the smart nodes, e.g. a 1-N relationship with the
smart nodes 806, 808, 810, or the block chain ledger may include
several block chains 851, 852 that each have a 1 to 1 relationship
with a particular smart node, such that a specific central block
chain ledger corresponds to one of the smart nodes 806, 808 as
shown in FIGS. 8A. and 8B.
[0048] Although the methods are described with reference to
illustrated flowcharts, it will be appreciated that many other ways
of performing the acts associated with the methods may be used. For
example, the order of some operations may be changed, and some of
the operations described may be optional.
[0049] Among other advantages, the control system and methods
described herein may provide for data security and cyber security
countermeasures within the control system. The disclosed method
advantageously: confirms part authenticity and configuration,
qualification information, validates part numbers, serial numbers,
dates of manufacture, configuration, software build, etc.;
guarantees external suppliers smart transducers can communicate
over the network; provides assurances that the smart transducers
can still function even under attack; reduces maintenance burden by
capturing the date of engine installation and other engine relevant
data; ensures financial support for maintainability. Also the
disclosed method ensures both original equipment manufacturer and
aftermarket parts meet original design intent as part certificates
may be routinely updated including on an annual basis.
[0050] Persons of ordinary skill in the art having the benefit of
the disclosures herein would recognize these and other benefits as
well.
[0051] Although examples are illustrated and described herein,
embodiments are nevertheless not limited to the details shown,
since various modifications and structural changes may be made
therein by those of ordinary skill within the scope and range of
equivalents of the claims.
* * * * *