Patent Description:
It is the object of the present invention to provide an industrial controller module and a corresponding method for backplane authentication.

The following presents a simplified summary in order to provide a basic understanding of some aspects described herein. This summary is not an extensive overview nor is intended to identify key/critical elements or to delineate the scope of the various aspects described herein. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

In one or more embodiments, an industrial controller module is provided, comprising a program execution component configured to execute an industrial control program that controls output signals of an industrial controller based on input signals received by the industrial controller, wherein the output signals and the input signals are conveyed via a backplane of the industrial controller; and a device authentication component configured to detect installation of a modular device on the backplane of the industrial controller, to exchange authentication data with the modular device via the backplane during a device authentication sequence, and to initiate operation of the modular device on the backplane in response to determining, based on a result of the authentication sequence, that the modular device is authorized to operate on the backplane.

Also, according to one or more embodiments, a method for implementing industrial controller security is provided, comprising in response to detecting installation of a modular device on a backplane of an industrial controller, executing, by an industrial controller module comprising a processor, an authentication sequence that determines an authenticity of the modular device based on an exchange of authentication data via the backplane; and in response to determining, based on a result of the authentication sequence, that the modular device is an authorized device, initiating operation of the modular device on the backplane; or in response to determining, based on the result of the authentication sequence, that the modular device is not an authorized device, disabling operation of the modular device on the backplane.

Also, a non-transitory computer-readable medium is provided having stored thereon executable instructions that, in response to execution, cause a, industrial controller module comprising at least one processor to perform operations, the operations comprising detecting installation of a modular device on a backplane of an industrial controller; in response to the detecting, sending a request for security credential data to the modular device via the backplane; in response to receiving the security credential data via the backplane, determining whether the security credential data is authentic; in response to determining that the security credential data is authentic, generating challenge data based on information contained in the security credential data; sending the security challenge data to the modular device via the backplane; and in response to determining that the security credential data is not authentic or that a response to the security challenge data received from the modular device via the backplane is not correct, disable operation of the modular device on the backplane.

To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways which can be practiced, all of which are intended to be covered herein. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.

The subject disclosure is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. It may be evident, however, that the subject disclosure can be practiced without these specific details.

As used in this application, the terms "component," "system," "platform," "layer," "controller," "terminal," "station," "node," "interface" are intended to refer to a computer-related entity or an entity related to, or that is part of, an operational apparatus with one or more specific functionalities, wherein such entities can be either hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical or magnetic storage medium) including affixed (e.g., screwed or bolted) or removable affixed solid-state storage drives; an object; an executable; a thread of execution; a computer-executable program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Also, components as described herein can execute from various computer readable storage media having various data structures stored thereon. The components may communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal). As another example, a component can be an apparatus with specific functionality provided by mechanical parts operated by electric or electronic circuitry which is operated by a software or a firmware application executed by a processor, wherein the processor can be internal or external to the apparatus and executes at least a part of the software or firmware application. As yet another example, a component can be an apparatus that provides specific functionality through electronic components without mechanical parts, the electronic components can include a processor therein to execute software or firmware that provides at least in part the functionality of the electronic components. As further yet another example, interface(s) can include input/output (I/O) components as well as associated processor, application, or Application Programming Interface (API) components. While the foregoing examples are directed to aspects of a component, the exemplified aspects or features also apply to a system, platform, interface, layer, controller, terminal, and the like.

As used herein, the terms "to infer" and "inference" refer generally to the process of reasoning about or inferring states of the system, environment, and/or user from a set of observations as captured via events and/or data. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic-that is, the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources.

Furthermore, the term "set" as employed herein excludes the empty set; e.g., the set with no elements therein. Thus, a "set" in the subject disclosure includes one or more elements or entities. As an illustration, a set of controllers includes one or more controllers; a set of data resources includes one or more data resources; etc. Likewise, the term "group" as utilized herein refers to a collection of one or more entities; e.g., a group of nodes refers to one or more nodes.

Various aspects or features will be presented in terms of systems that may include a number of devices, components, modules, and the like. It is to be understood and appreciated that the various systems may include additional devices, components, modules, etc. and/or may not include all of the devices, components, modules etc. discussed in connection with the figures. A combination of these approaches also can be used.

<FIG> is a block diagram of an example industrial control environment <NUM>, including a number of diverse industrial devices and assets. In this example, a number of industrial controllers <NUM> are deployed throughout an industrial plant environment to monitor and control respective industrial systems or processes relating to product manufacture, machining, motion control, batch processing, material handling, or other such industrial functions. Industrial controllers <NUM> typically execute respective control programs to facilitate monitoring and control of industrial devices <NUM> making up the controlled industrial systems. The control programs executed by industrial controllers <NUM> can comprise any conceivable type of code used to process input signals read from the industrial devices <NUM> and to control output signals generated by the industrial controllers, including but not limited to ladder logic, sequential function charts, function block diagrams, or structured text.

Industrial devices <NUM> may include both input devices that provide data relating to the controlled industrial systems to the industrial controllers <NUM>, and output devices that respond to control signals generated by the industrial controllers <NUM> to control aspects of the industrial systems. Example input devices can include telemetry devices (e.g., temperature sensors, flow meters, level sensors, pressure sensors, etc.), manual operator control devices (e.g., push buttons, selector switches, etc.), safety monitoring devices (e.g., safety mats, safety pull cords, light curtains, etc.), and other such devices. Output devices may include motor drives, pneumatic actuators, signaling devices, robot control inputs, valves, and the like.

Industrial controllers <NUM> may communicatively interface with industrial devices <NUM> over hardwired or networked connections. For example, industrial controllers <NUM> can be equipped with native hardwired inputs and outputs that communicate with the industrial devices <NUM> to effect control of the devices. The native controller I/O can include digital I/O that transmits and receives discrete voltage signals to and from the field devices, or analog I/O that transmits and receives analog voltage or current signals to and from the devices. The controller I/O can communicate with a controller's processor over a backplane - e.g., a backplane installed in the back of the controller's chassis, which serves as a power and data bus between the I/O modules and the controller - such that the digital and analog signals can be read into and controlled by the control programs. Industrial controllers <NUM> can also communicate with industrial devices <NUM> over a network using, for example, a communication module or an integrated networking port. Exemplary networks can include the Internet, intranets, Ethernet, DeviceNet, ControlNet, Data Highway and Data Highway Plus (DH/DH+), Remote I/O, Fieldbus, Modbus, Profibus, wireless networks, serial protocols, and the like. The industrial controllers <NUM> can also store persisted data values that can be referenced by the control program and used for control decisions, including but not limited to measured or calculated values representing operational states of a controlled machine or process (e.g., tank levels, positions, alarms, etc.) or captured time series data that is collected during operation of the automation system (e.g., status information for multiple points in time, diagnostic occurrences, etc.).

Industrial automation systems often include one or more human-machine interfaces (HMIs) <NUM> that allow plant personnel to view telemetry and status data associated with the automation systems, and to control some aspects of system operation. HMIs <NUM> may communicate with one or more of the industrial controllers <NUM> over a plant network <NUM>, and exchange data with the industrial controllers to facilitate visualization of information relating to the controlled industrial processes on one or more pre-developed operator interface screens. HMIs <NUM> can also be configured to allow operators to submit data to specified data tags or memory addresses of the industrial controllers <NUM>, thereby providing a means for operators to issue commands to the controlled systems (e.g., cycle start commands, device actuation commands, etc.), to modify setpoint values, etc. HMIs <NUM> can generate one or more display screens through which the operator interacts with the industrial controllers <NUM>, and thereby with the controlled processes and/or systems. Example display screens can visualize present states of industrial systems or their associated devices using graphical representations of the processes that display metered or calculated values, employ color or position animations based on state, render alarm notifications, or employ other such techniques for presenting relevant data to the operator. Data presented in this manner is read from industrial controllers <NUM> by HMIs <NUM> and presented on one or more of the display screens according to display formats chosen by the HMI developer.

Other industrial devices or assets can include industrial robots <NUM>, which may operate in accordance with programs executed by their own internal controllers, in conjunction with information exchanged with one or more external controllers (e.g., industrial controllers <NUM>). Some industrial environments may also include a number of sub-systems that perform various production, quality, or safety functions, including but not limited to vision systems, safety systems (e.g., optical presence sensing systems, safety relay systems, etc.), product quality check systems (e.g., leak test systems), or other such assets.

Some industrial environments may also include one or more data historians <NUM> that aggregate and store production information collected from the industrial controllers <NUM> or other data sources, or a device documentation store <NUM> containing electronic documentation for the various industrial devices making up the controlled industrial systems. Other industrial devices or assets may include inventory tracking systems <NUM>, work order management systems <NUM>, enterprise resource planning (ERP) systems, manufacturing execution systems (MES), or other such business-level systems, some or all of which may reside on an office network <NUM> of the industrial environment (e.g., a separately managed network relative to plant network <NUM>). The industrial network environment may also include a number of network architecture devices - such as firewall <NUM>, hubs, routers, or switches - that connect separate networks and/or networked devices and manage data flow between the various devices and networks.

Industrial devices <NUM>, processes, or machines controlled by industrial controllers <NUM> typically comprise one or more I/O devices that are electrically connected to the industrial controller <NUM> via the controller's I/O modules, as illustrated in <FIG>. These I/O devices <NUM> may comprise digital input devices (e.g., push buttons, selector switches, safety devices, proximity switches, photo sensors, etc.), digital output devices (e.g., solenoid values, indicator lights, motor contactors, etc.), analog input devices (e.g., <NUM>-<NUM> mA telemetry devices, <NUM>-10VDC telemetry devices, or other analog measurement devices), or analog output devices (e.g., variable frequency drives, flow control valves, speed control devices, etc.). Typically, each I/O device <NUM> is wired to a terminal of an appropriate I/O module <NUM> of industrial controller <NUM>. I/O modules are generally classified as digital input, digital output, analog input, or analog output modules to accommodate the different types of I/O devices <NUM>.

To suit the needs of each particular control application, some industrial controllers comprise a multi-slot chassis that allows a selected I/O module to be installed in each slot of the chassis. One slot of the chassis is typically dedicated to the controller's processor module <NUM>, although some designs allow the processor module <NUM> to be inserted into any slot of the chassis. When a processor module <NUM>, I/O module <NUM>, or other type of special function module (e.g., a networking module or special function module) is installed in the controller's chassis, the module interfaces with a backplane installed at the rear of the chassis. The backplane serves as a power and data bus that both provides power to the I/O modules - typically sourced by a dedicated power module installed in the chassis <NUM> - and also serves as a path for data exchange between the processor module <NUM> and the I/O modules <NUM>. For example, digital and analog input modules provide their measured input values to the processor module via the backplane, and the processor module sends programmatic digital and analog values to selected digital or analog output modules via the backplane for conversion to electrical output signals.

<FIG> is a diagram illustrating communication between a processor module <NUM> and an I/O module <NUM> within an industrial controller chassis <NUM>. One or more terminals <NUM> of I/O module <NUM> is wired to an I/O device (e.g., I/O devices <NUM>) via field wiring <NUM>, allowing electrical signals to be exchanged between the I/O device and I/O module <NUM>. If the I/O module <NUM> is an input module, each input I/O device provides a discrete (e.g., 24VDC) or analog (e.g., <NUM>-<NUM> mA or <NUM>-<NUM> VDC) electrical signal to the I/O module <NUM> via field wiring <NUM> for processing by processor module <NUM>. If the I/O module <NUM> is an output module, the I/O module <NUM> sends discrete or analog output signals to the I/O devices via field wiring <NUM> in accordance with commands issued by the processor module <NUM>. Processor module <NUM> executes a user-defined control program <NUM> (e.g., a ladder logic program, a sequential function block program, etc.) that controls the output signals sent to the output field devices via the output modules as a function of the received input signals and user-defined control sequences. The I/O module <NUM> exchanges this input and output data with processor module <NUM> via a data bus of the backplane, which is located at the back of the chassis <NUM>. Typically, when an I/O module <NUM> or processor module <NUM> is inserted into a slot of the chassis <NUM>, an interface connector on the rear side of the module plugs into the backplane, thereby providing a means for data exchange between the processor module <NUM> and I/O module <NUM>. The backplane also includes a power bus that provides power to the I/O module <NUM> and the processor module <NUM>.

<FIG> are side and front views, respectively, of an example industrial controller <NUM> that illustrates connectivity of an I/O module <NUM> to the controller's backplane <NUM>. Example industrial controller <NUM> comprises a chassis <NUM>, a processor module <NUM>, and an I/O module <NUM>. For clarity, only a single I/O module <NUM> is illustrated in <FIG>. In this example, processor module <NUM> resides in the right-most slot of the chassis <NUM>, while I/O module <NUM> resides in the fourth slot to the left of processor module <NUM>. The I/O module <NUM> may comprise, for example, a printed circuit board containing the components for carrying out the module's functions (e.g., circuitry for communicating with the processor module <NUM>, circuitry for conditioning input signals from the terminals <NUM> for transfer over the backplane <NUM>, circuitry for generating terminal output signals in accordance with commands from processor module <NUM> received via the backplane <NUM>, etc.). Some I/O modules <NUM> may also comprise a housing that fully or partially encloses the circuit board. In the illustrated example, guide rails 406a and 406b are located at the top and bottom of chassis <NUM> for each slot, and are designed to guide the I/O module <NUM> into the slot and align the backplane connector <NUM> of the I/O module <NUM> with backplane interface port 416a at the rear of chassis <NUM> (the front view of <FIG> shows three unused backplane interface ports 416b). When the I/O module's backplane connector <NUM> is connected to the backplane interface port 416a, the I/O module <NUM> and processor module <NUM> are able to exchange information over the backplane <NUM> (as described above in connection with <FIG>). The backplane <NUM> also provides power to the I/O module <NUM> and processor module <NUM>. Power is typically sourced by a power supply module (not shown) installed in one of the available slots, or in a dedicated power supply slot.

Some I/O modules <NUM> may include a front indicator panel <NUM> with status indicators - e.g., color-coded light emitting diodes (LEDs) - for conveying status information for each of the I/O points of the module <NUM>, and/or general module status information.

Since many industrial devices, systems, and assets reside on plant and/or office networks, system designers often configure network security protocols that prevent unauthorized access to the industrial assets by unauthorized users or devices. Such security measures are required to prevent unauthorized viewing of production data or other sensitive information, or to prevent remote entities from assuming control of the industrial assets and modifying control sequences or device parameters.

However, even with network-level security in place, controller backplanes (e.g., backplane <NUM>) still represent a potential attack vector through which an unauthorized entity can gain low-level access to control system information. Backplane-level security risks have not generally been considered by system designers or equipment vendors, since the unique physical or electrical characteristics of the backplane, proprietary and undocumented messaging protocols often used to exchange data across the backplane, and the outer physical layers of security surrounding the backplane (e.g., the fact that the industrial controller is typically enclosed inside a control cabinet) have discouraged system designers from considering the potential security vulnerabilities associated with the controller backplane. However, despite these inherent security layers, the backplane of an industrial controller - which utilizes little or no access control technology - can potentially be reverse engineered by malicious parties to learn the physical, electrical, and communication characteristics of the backplane. With this information, rogue modules designed to disrupt the control system or record proprietary control system information can be configured and installed in the controller chassis by such malicious parties. These rogue modules could allow such parties to gain access to the user's control system, collect proprietary information about the user's control system, tamper with control system data, interfere with real-time control carried out by the controller resulting in a denial of service, spoof legitimate control devices, or gain unauthorized access to other more secure networks or data busses within the plant.

To address these and other issues, one or more embodiments of the present disclosure provide industrial controllers configured with backplane-level security protocols. In one or more embodiments, industrial controller processor modules or other supervisory modules can perform security authentication on individual modular devices on the controller's backplane (e.g., I/O modules, networking modules, etc.), and will only allow the installed module to operate on the backplane if the module is authenticated. In response to detection of an unauthorized module, the supervisory module can execute one or more actions to prevent the unauthorized module from functioning on the backplane; e.g., by disabling data connectivity to the module, by disconnecting power to the module or to the backplane as a whole, etc. In some embodiments, the supervisory module can also generate a notification of the detected rogue module directed to a log server, to an HMI, or to one or more specified client devices associated with responsible plant personnel. The supervisory module (e.g., a processor module, and adaptor module, a networking module, or another type of supervisory module) can be configured to authenticate both vendor-approved devices and user- approved devices.

Any suitable technique for authenticating controller modules across the controller's backplane are within the scope of one or more embodiments of this disclosure. For example, in some embodiments modules manufactured by an authorized equipment vendor can be provisioned with digital vendor certificates that are unique to each module, and the supervisory module can authenticate modules or devices plugged into the controller's backplane based on a private key infrastructure (PKI). However, the industrial backplane-level security techniques described herein are not limited to such security protocols, and any suitable security protocol for implementing backplane-level security within industrial controller components are within the scope of one or more embodiments of this disclosure.

<FIG> is a block diagram of an example industrial controller processor module <NUM> with backplane authentication. Although examples described herein assume that the supervisory authentication functionality is embodied in a processor module <NUM> (e.g., such as processor module <NUM>), supervisory authentication functionality can also be embodied in other types of controller modules or devices that interface with the controller's backplane, including but not limited to remote I/O adapter modules, networking modules, dedicated security modules, special function modules, or other types of controller modules. Aspects of the systems, apparatuses, or processes explained in this disclosure can constitute machine-executable components embodied within machine(s), e.g., embodied in one or more computer-readable mediums (or media) associated with one or more machines. Such components, when executed by one or more machines, e.g., computer(s), computing device(s), automation device(s), virtual machine(s), etc., can cause the machine(s) to perform the operations described.

Processor module <NUM> can include a client interface component <NUM>, a program execution component <NUM>, a device authentication component <NUM>, a notification component <NUM>, a backplane control component <NUM>, one or more processors <NUM>, and memory <NUM>. In various embodiments, one or more of the client interface component <NUM>, program execution component <NUM>, device authentication component <NUM>, notification component <NUM>, backplane control component <NUM>, the one or more processors <NUM>, and memory <NUM> can be electrically and/or communicatively coupled to one another to perform one or more of the functions of the processor module <NUM>. In some embodiments, components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> can comprise software instructions stored on memory <NUM> and executed by processor(s) <NUM>. Processor module <NUM> may also interact with other hardware and/or software components not depicted in <FIG>. For example, processor(s) <NUM> may interact with one or more external user interface devices, such as a keyboard, a mouse, a display monitor, a touchscreen, or other such interface devices.

Client interface component <NUM> can be configured to exchange data with a client device interfaced with the processor module <NUM>, such as a desktop, laptop, or tablet computer; a mobile device such as a smart phone; or other such client device. As will be described in more detail below, connectivity between the client device and processor module <NUM> can allow a user to define the control program <NUM> (e.g., ladder logic or other type of industrial control program) to be executed by the processor <NUM>, as well as to define a subset of modular backplane devices that are authorized for communication with the processor module <NUM> over a controller backplane.

Program execution component <NUM> can be configured to execute a control program <NUM> (e.g., a ladder logic program, a sequential function chart program, etc.) stored on the processor module's memory <NUM> to facilitate monitoring and control of an industrial process via other digital, analog, and/or networked I/O modules that share a backplane (or I/O network) with the processor module <NUM>.

Device authentication component <NUM> can be configured to implement backplane-level security for the industrial controller in which the processor module is installed by authenticating all modular devices (e.g., I/O modules, networking modules, special function modules, etc.) installed on the controller's backplane. In some embodiments, authentication of authorized modules can be based on one or both of vendor certificate data <NUM> (issued to the processor module <NUM> during manufacture of the module) or user certificate data <NUM> (issued to the processor module <NUM> by the end user using a trust authority), which can be stored on memory <NUM> of the processor module <NUM>.

Notification component <NUM> can be configured to generate notification data in response to detection of an unauthorized modular device installed on the controller's backplane. This can include, for example, generating a time-stamped log entry identifying detection of the unauthorized modular device, and either storing the log entry locally on memory <NUM> or sending the log entry to a remote server device. In another example, notification component <NUM> can be configured to deliver the notification to one or more client devices associated with suitable plant personnel, e.g., via a text message directed to the client devices, as an email directed to the personnel's email addresses, or by other means.

Backplane control component <NUM> can be configured to modify operation of the controller's backplane based on results of the authentication procedure for a modular device installed on the backplane. For example, in response to a determination by the device authentication component <NUM> that a modular device that has been installed on the backplane is not an authorized device, backplane control component <NUM> can disable backplane communications to and from the slot in which the unauthorized device is installed. This can be achieved by instructing the processor module <NUM> to disable data read and write operations to the unauthorized module. For embodiments in which the backplane is equipped with switches capable of physically isolating the modular devices in each slot from the backplane, the backplane control component <NUM> may also instruct one or more backplane switches associated with the slot to open, thereby disconnecting the unauthorized module from the backplane's power bus and/or data bus. In yet another example, backplane control component <NUM> may be configured to disconnect power from the entire backplane in response to detection of an unauthorized module in any of the controller's slots, thereby deenergizing all modules in the controller. Other countermeasures are also within the scope of one or more embodiments. For example, rather than modifying backplane operation, device authentication component <NUM> may instead instruct program execution component <NUM> to disable run mode for the processor module <NUM> if any of the installed modules are not authorized. This prevents the control program <NUM> from executing until such time as the device authentication component <NUM> authorizes all modular devices installed in the controller.

The one or more processors <NUM> can perform one or more of the functions described herein with reference to the systems and/or methods disclosed. Memory <NUM> can be a computer-readable storage medium storing computer-executable instructions and/or information for performing the functions described herein with reference to the systems and/or methods disclosed.

<FIG> is a block diagram of an example modular device <NUM> that supports backplane authentication. Modular device <NUM> can be substantially any type of industrial controller module that can be installed on the backplane of an industrial controller, including but not limited to a digital or analog input module, a digital or analog output module, a networking module, a special function module, or another type of module.

Modular device <NUM> can include a backplane interface component <NUM>, an authentication response component <NUM>, a module functionality component <NUM>, a client interface component <NUM>, one or more processors <NUM>, and memory <NUM>. In various embodiments, one or more of the backplane interface component <NUM>, authentication response component <NUM>, module functionality component <NUM>, client interface component <NUM>, the one or more processors <NUM>, and memory <NUM> can be electrically and/or communicatively coupled to one another to perform one or more of the functions of the modular device <NUM>. In some embodiments, components <NUM>, <NUM>, and <NUM> can comprise software instructions stored on memory <NUM> and executed by processor(s) <NUM>. Modular device <NUM> may also interact with other hardware and/or software components not depicted in <FIG>. For example, processor(s) <NUM> may interact with one or more external user interface devices, such as a keyboard, a mouse, a display monitor, a touchscreen, or other such interface devices.

Backplane interface component <NUM> can be configured to electrically and communicatively connect the modular device <NUM> to the backplane of an industrial controller (e.g., a backplane installed at the back of the controller chassis). Backplane interface component <NUM> can include, for example, a backplane connector (e.g., similar to backplane connector <NUM>) that plugs into or otherwise interfaces with a backplane interface port (e.g., similar to backplane interface port <NUM>), together with any electronics or software necessary to exchange data with and receive power from the backplane. The authentication response component <NUM> can be configured to respond to requests for authentication information from the processor module <NUM>. In some scenarios, authentication response component <NUM> can generate responses to requests from the processor module <NUM> based on vendor certificate data <NUM> and/or user certificate data <NUM> stored on memory <NUM> of the modular device <NUM>. For example, depending on the nature of the request received from the device authentication component <NUM>, authentication response component <NUM> may provide one or both of vendor certificate data <NUM> or user certificate data <NUM> to the processor module <NUM>, or may provide a hash value that has been decrypted using an encryption key defined by the vendor certificate data <NUM>.

Module functionality component <NUM> can be configured to carry out native functions of the modular device <NUM> in accordance with the type of modular device <NUM>. For example, if modular device <NUM> is an analog output module, module functionality component <NUM> can be configured to generate voltage or current output signals (e.g., <NUM>-10VDC or <NUM>-20mA outputs) proportional to analog values defined by the control program <NUM> executing on the processor module <NUM>, and to output the generated signals on the module's output terminals. If the modular device <NUM> is an analog input module, module functionality component <NUM> can be configured to generate analog values for processing by the control program <NUM>, where the analog values are proportional to analog electrical signals received at the module's input terminals. Other types of module functionality are also within the scope of one or more embodiments.

Client interface component <NUM> can be configured to exchange data with a client device interfaced with the modular device <NUM>, such as a desktop, laptop, or tablet computer; a mobile device such as a smart phone; or other such client device. As will be described in more detail below, connectivity between the client device and modular device <NUM> can allow a user provision user certificate data <NUM> to the modular device.

As noted above, one or more embodiments of the architecture described herein supports a backplane authentication protocol that requires modular devices (e.g., I/O modules, special function modules, networking modules, etc.) to prove authenticity in order to gain access to the backplane or to operate on the backplane. In an example implementation, authentication of controller modules (e.g., modular device <NUM>) can rely on vendor certificates to protect access to the backplane. <FIG> is a diagram illustrating issuance of vendor certificate data to both a modular device <NUM> and a processor module <NUM>. In this example configuration, the processor module <NUM>, when installed in an industrial controller chassis and interfaced with the controller's backplane <NUM>, will authenticate any modular device <NUM> that is also installed on the backplane <NUM>. Accordingly, both the processor module <NUM> and all supported modular devices <NUM> are issued with vendor certificate data <NUM> and <NUM>, respectively, at the time of manufacture. The vendor certificate data issued to each authorized device is unique to that device. In some embodiments, the format of vendor certificate data <NUM> and <NUM> can conform to the X. <NUM> standard, or another suitable cryptographic standard. Using vendor certificate data <NUM> and <NUM>, authentication of modular devices installed on the backplane can be performed using techniques similar to public key infrastructure (PKI) authentication. Although examples described herein assume the use of digital certificates and PKI authentication, it is to be appreciated that the backplane-level security features described herein are not limited to such protocols, and that any backplane-level security protocol is within the scope of one or more embodiments.

Vendor certificate data <NUM> and <NUM> can include such information as an identity of the vendor <NUM> of devices <NUM> and <NUM>, device identification information that uniquely identifies the device (e.g., a physical device identifier such as a media access control (MAC) address), indication of a license type specifying a scope of allowed access for the device, public key data used to identify valid license certificates issued by the vendor <NUM> (acting as a certificate authority), and digital signature information. The digital signature contained in the modular device's vendor certificate data <NUM> can be verified by the device authentication component <NUM> of the processor module <NUM> (or another modular supervisory device responsible for verifying authenticity of modular devices <NUM>) using a public key issued to the processor module <NUM> as part of the processor module's vendor certificate <NUM>. By validating the modular device's digital signature in this manner, the processor module <NUM> can confirm that the vendor certificate data <NUM> provided by the modular device <NUM> is valid, authentic, and has not been tampered with.

For the purposes of this example, vendor <NUM> is assumed to be the business entity that manufactures and sells modular devices <NUM> and processor modules <NUM>. However, in some scenarios the certificate authority could be another trusted third-party entity - e.g., a security entity or a partner entity - that has been granted authorization by the equipment vendor to issue licenses for the purposes of backplane-level security.

In the illustrated example, issuance of certificate data <NUM> and <NUM> to the modular device <NUM> and process module <NUM>, respectively, by vendor <NUM> (or another trusted certificate authority) causes private key data <NUM> and <NUM> to be enrolled into the vendor's PKI. Private key data <NUM> corresponds to the public key included in the modular device's vendor certificate data <NUM>, while private key data <NUM> corresponds to the public key included in the processor module's vendor certificate data <NUM>. The private key data <NUM> and <NUM> can be protected in hardware of their respective devices (e.g., using hardware security modules, or using other hardware protection means) to render the private key data impervious to cloning. During authentication, a device's private key data can be used to verify that the device is the authentic holder of its asserted vendor certificate.

As will be described in more detail below, in addition to vendor certificate data <NUM>, processor module <NUM> can also support the use of user certificate data <NUM>, which can be issued to the module <NUM> by the end user using a certificate authority application, as will be described in more detail below.

<FIG> is a diagram illustrating an example authentication sequence between a processor module <NUM> and a modular device <NUM> that shares a backplane with the processor module <NUM>. In this example, it is assumed that the processor module <NUM> has been installed in the controller chassis and is interfaced with the controller backplane. In general, the authentication sequence can be initiated by the processor module <NUM> in response to detecting that modular device <NUM> has also been installed on the backplane. In some embodiments, the authentication sequence can also be initiated in response to initialization of the processor module <NUM>. For example, when the processor module <NUM> is powered on or otherwise initialized, the processor module's device authentication component <NUM> can execute the authentication sequence on each modular device <NUM> currently installed on the backplane. In the sequence illustrated in <FIG>, all data communication between the processor module <NUM> and the modular device <NUM> is performed via the controller backplane (e.g., backplane <NUM>).

When modular device <NUM> is installed on the controller backplane, processor module <NUM> detects the modular device <NUM> across the backplane at <NUM>. In response to detection of the modular device <NUM>, the processor module's device authentication component <NUM> issues a request for the modular device's credentials at <NUM>. In response to receiving the request, the modular device <NUM> responds by sending a copy of its vendor certificate data <NUM> (or user certificate data <NUM>, to be described in more detail below) to the processor module <NUM> at <NUM>. By sending the vendor certificate data <NUM>, the modular device <NUM> provides its vendor-issued digital signature and unique device-specific public key to the processor module <NUM>. Upon receipt of the modular device's vendor certificate data, the processor module <NUM> decodes and verifies the authenticity of the modular device's vendor certificate at <NUM>. For example, processor module's device authentication component <NUM> can verify the modular device's vendor certificate by validating the digital signature included in the certificate data <NUM> using the vendor's public key <NUM>. The vendor's public key <NUM> can be included in the processor module's vendor certificate <NUM> issued to the processor module <NUM> at the time of manufacture (either by the vendor or by another trusted entity that provisions the digital certificates to the devices <NUM> and <NUM>). The digital signature may be encrypted using the vendor's private key, which corresponds to public key <NUM>. Accordingly, the device authentication component <NUM> will attempt to verify the digital signature included in the vendor certificate data <NUM> provided by the modular device <NUM> using public key <NUM>. If the digital signature is recognized by the device authentication component <NUM>, the processor module <NUM> verifies that the vendor certificate is authentic and unmodified, and proceeds to the next step in the authentication process. Alternatively, if the vendor certificate is not valid or is not provided by the modular device <NUM> within a defined timeout period, the device authentication component <NUM> will deny the modular device <NUM> access to the backplane.

In response to confirming the authenticity of the vendor certificate data provided by the modular device <NUM>, the processor module's device authentication component <NUM> can issue a challenge to the modular device <NUM> via the backplane at <NUM>. Although the vendor certificate data <NUM> has been found to be authentic, the challenge is designed to confirm that the modular device <NUM> is the authorized owner of the provided vendor certificate. In this way, the processor module <NUM> can determine whether the vendor certificate data <NUM> has been duplicated and installed on an unauthorized device. In an example challenge, the processor module's device authentication component <NUM> can generate a cryptographically random challenge value (e.g., a randomly generated value) and encrypt this random challenge value using the public key provided in the vendor certificate data <NUM> that was provided by the modular device <NUM> at step <NUM>. The processor module <NUM> then sends the encrypted challenge value to the modular device <NUM> via the backplane as the challenge.

At <NUM>, if the modular device <NUM> is authentic, the modular device's authentication response component <NUM> generates a challenge response based on the challenge provided by the processor module <NUM> (e.g., the encrypted session key) and the private key data <NUM> previously issued to the modular device <NUM>. Since the session key was encrypted using the modular device's public key (provided to the processor module <NUM> as part of the modular device's vendor certificate data <NUM>), the encrypted session key will only be properly decrypted using the corresponding private key data <NUM> owned by the modular device <NUM>. Accordingly, in response to receiving the challenge at <NUM>, the modular device's authentication response component <NUM> will decrypt the encrypted session key contained in the challenge using the private key data <NUM> (which is stored and protected in the modular device's hardware), and send the decrypted session key (e.g., a decrypted hash value) to the processor module <NUM> via the backplane as a challenge response at <NUM>.

Upon receipt of the response at <NUM>, the processor module's device authentication component <NUM> verifies the response at <NUM>. For example, the device authentication component <NUM> can compare the response - e.g., the decrypted session key - provided by the modular device <NUM> with the original session key generated previously by the device authentication component <NUM>. If the decrypted session key provided by the modular device matches the original session key, the device authentication component <NUM> assumes that the modular device <NUM> is an authorized device, and authorizes access to the backplane at <NUM>. At this stage, the installed modular device <NUM> is permitted to operate normally on the controller backplane, and data exchange between the modular device <NUM> and the processor module <NUM> is carried out normally in accordance with the control program <NUM> and/or controller configuration. Alternatively, if the response provided by the modular device <NUM> does not correspond to the original session key, access to the backplane will be denied to the modular device <NUM>.

In some embodiments, the degree of access permitted to the modular device <NUM> may be determined based on the license type defined by the vendor certificate data <NUM> issued to the modular device <NUM>. For example, depending on the scope of access permitted by the modular device's vendor certificate data <NUM>, the modular device may be granted full read-write access to the processor module <NUM> via the backplane, read-only access, write-only access, or limited read and/or write access to a defined subset of data registers defined in the process module <NUM>.

The authentication sequence carried out by the device authentication component <NUM> (either a sequence similar to that described above in connection with <FIG> or another suitable device authentication sequence) can be performed in response to detecting that a modular device <NUM> has been installed on the controller backplane, as well as in response to initialization of the processor module <NUM> (e.g., during a power-up sequence of the processor module <NUM>, or when the processor module <NUM> is switched to a run-time operating mode). In some embodiments, the authentication sequence can also be carried out periodically at a default or user-defined defined frequency (e.g., once a day, once an hour, etc.).

Vendor certificate data <NUM> can ensure that only modular devices <NUM> that have been authorized by a valid certification authority - e.g., a vendor of the modular devices or a trusted third-party entity that has been authorized by the vendor - are allowed to communicate across the backplane and operate as part of the industrial controller. As noted above, in addition to authentication of modular devices based on vendor certificate data <NUM>, one or more embodiments can also allow the user to issue user certificate data to one or both of the modular devices <NUM> or the processor module <NUM>. <FIG> is a diagram illustrating provision of user certificate data <NUM> and <NUM> to modular device <NUM> and processor module <NUM>. User certificate data <NUM> and <NUM> can ensure that only modular devices that have been purchased by the owner of the industrial controller and provisioned with user certificates are permitted to operate on the controller's backplane. This can prevent installation of modular devices <NUM> that were manufactured and certified by the device vendor but which have been modified or tampered with for the purposes of unauthorized data collection or monitoring, disruption of the control process, spoofing, or other malicious activities.

In an example configuration technique, a user can interface with the processor module <NUM> or modular device <NUM> via their respective client interface components <NUM> and <NUM>; e.g., by communicatively connecting a client device <NUM> (e.g., a laptop computer, a desktop computer, a tablet computer, a personal mobile device, etc.) to the processor module <NUM> or modular device <NUM> over a wired or wireless connection. Client device <NUM> may execute a configuration program that includes certificate authority functionality capable of generating and issuing user certificate data <NUM> and <NUM> to the controller module <NUM> and/or modular device <NUM>. In some embodiments, the configuration application <NUM> may be a dedicated certificate authority application, or may be a controller configuration application used to develop and download control program <NUM> to the processor module <NUM>, as well as to configure other functional aspects for the controller (e.g., networking or communication settings, I/O module definitions, data ranges for analog inputs and outputs, etc.). In the later scenario, the certificate authority functionality can be an add-on or bundled functionality of the controller configuration application.

User certificate data <NUM> and <NUM> can be leveraged by processor module <NUM> in the same manner as vendor certificate data <NUM> and <NUM> during the authentication sequence described above. For example, if user certificate data <NUM> has been created for the processor module <NUM>, device authentication component <NUM> will use the user certificate data <NUM> in place of (or in conjunction with) the vendor certificate data <NUM> to determine whether an installed modular device <NUM> is to be permitted access to the backplane (if no user certificate data <NUM> has been created, the vendor certificate data <NUM> will be used). At step <NUM> of the sequence described above, the modular device's authentication response component <NUM> will send its user certificate data in response to the modular device's request for credentials, and the processor module's device authentication component <NUM> will verify the validity of the modular device using its own user certificate data <NUM>. When user certificate data is used for to validate the modular device <NUM>, the authentication sequence verifies that the modular device <NUM> is one that has been registered by the user's trust authority (e.g., the certificate authority of configuration application <NUM>).

Some embodiments of processor module <NUM> can also be configured to generate user certificate data <NUM> during a provisioning or enrollment sequence that registers all modular devices currently installed on the controller's backplane. <FIG> is a diagram illustrating enrollment of installed modular devices <NUM> for exclusive access to processor module <NUM> over the backplane. In this example, the system designer has installed a processor module <NUM> and three modular devices 602a-602c (e.g., I/O modules or other types of modular devices) in the controller chassis, causing these devices to be interfaced with the controller's backplane. The modular devices 602a-602c are authorized devices that have been certified by the device vendor (or trusted third-party). The user has also issued user certificate date to the modular devices 602a-602c using the certificate authority functionality of configuration application <NUM>.

If the user wishes to set the three modular devices 602a-602c to be the sole devices permitted to communicate with the processor module <NUM> via the backplane, the user can issue a provisioning command <NUM> to the processor module <NUM> using client device <NUM>. In this regard, the controller configuration application <NUM> executing on the client device <NUM> can include a provisioning or enrollment control that, when selected by the user, issues a provisioning command <NUM> that causes processor module <NUM> to grant exclusive communication rights to all modular devices 602a-602c currently installed on the backplane. In response to receipt of the provisioning command <NUM>, client interface component <NUM> (or another logical component of processor module <NUM>) reads the user certificate data <NUM> from each installed modular device 602a-602c and updates its own user certificate data <NUM> to reflect that only the devices corresponding to the obtained user certificates are to be granted communication privileges on the controller backplane. Subsequently, if a modular device that has not been previously registered in user certificate data <NUM> is installed on the controller backplane, even if this new modular device is a vendor-approved device, device authentication component <NUM> will determine that the new device is not one that has been authorized by the user for use on the controller backplane, and deny the new device access to the backplane. By supporting generation and management of user certificates in addition to vendor certificates, embodiments of the backplane security devices described herein can afford users a highly granular degree of backplane access control.

Although examples described above have considered embodiments in which the device authentication component <NUM> is implemented in the processor module <NUM> and used to authenticate modular devices on the primary controller backplane, the device authentication features described above can also be implemented in other types of supervisory modules, such as remote I/O adapter modules or networking modules. <FIG> is a diagram illustrating a remote I/O configuration that supports backplane-level security. In this example a primary industrial controller <NUM> comprises a processor module <NUM> and one or more local modular devices 602d. Local I/O implemented on the local modular devices 602d is used to exchange control input and output data with industrial devices <NUM> that are local to the industrial controller <NUM>. In addition, a remote I/O rack <NUM> is located at another remote area of the plant relative to local industrial controller <NUM>. Remote I/O rack <NUM> comprises a set of remote modular devices 602e and an adapter module <NUM> that is networked to the processor module <NUM> via a remote I/O network <NUM> (e.g., a common industrial protocol network, an Ethernet/IP network, or another open or proprietary network). Adapter module <NUM> interfaces the remote modular devices 602e with the processor module <NUM>, allowing the remote modular devices 602e to serve as remote expansion modules of industrial controller <NUM> for control of remote industrial devices <NUM>.

In this example, adapter module <NUM> is configured with a device authentication component <NUM>, which authenticates each of the remote modular devices 602e installed in the remote I/O rack (e.g., using a similar authentication sequence as that described above in connection with <FIG>, or using another suitable authentication sequence). Similar to processor module <NUM>, adapter module <NUM> can deny access to the remote rack's backplane - and thus to the processor module <NUM> via the remote I/O network - to any remote modular device 602e that has not been authenticated by the device vendor or trusted third-party, or that has not been registered as a user-authorized device.

In response to detection of an unauthorized module on the backplane, the device authentication component <NUM> (whether implemented on a processor module <NUM>, a remote I/O adapter module <NUM>, or another type of supervisory module) can execute a suitable countermeasure to protect the control system from the potentially rogue device. As a primary countermeasure, device authentication component <NUM> instructs the processor module <NUM> to disallow data communication to and from the unauthorized module via the backplane. In some embodiments, the processor module may also effect a modification to the backplane itself in order to protect the control system from the potentially rogue modular device. <FIG> is a diagram illustrating an embodiment of a processor module <NUM> configured with a backplane control component <NUM> capable of modifying operation of the backplane itself in order to protect the processor module <NUM>, other I/O modules, and the controlled industrial equipment from rogue modular devices. In an example embodiment that supports backplane modification as a countermeasure against unauthorized modular devices, the controller backplane <NUM> may be configured with controllable switches <NUM> associated with each slot of the controller chassis <NUM>, and which are capable of individually disconnecting each slot's interface port <NUM> from the backplane's power and/or data bus.

If device authentication component <NUM> determines that modular device <NUM> is not an authorized device (using techniques described above), the device authentication component <NUM> instructs the processor module <NUM> to disallow communications to and from the modular device <NUM>. In addition, the device authentication component <NUM> can issue a disconnect command <NUM> to the backplane control component <NUM> instructing the backplane control component <NUM> to isolate the modular device <NUM> from the backplane <NUM> by opening the switch <NUM> associated with the interface port <NUM> to which the modular device <NUM> is connected. In this way, the potentially rogue modular device <NUM> can be deenergized by physically disconnecting the device <NUM> from the backplane's power bus, and/or effectively quarantined by physically disconnecting the device <NUM> from the backplane's data bus. To ensure that the correct interface port <NUM> is disconnected, the disconnect command <NUM> can include the slot number corresponding to the modular device <NUM> to be disconnected. In another example embodiment, rather than disconnecting individual interface ports <NUM>, backplane control component <NUM> may be configured to disconnect power to the entire backplane <NUM> in response to detection of an unauthorized module, thereby disabling all power and communication across the backplane. In yet another technique, the device authentication component <NUM> and backplane control component <NUM> can be implemented in the controller's power supply module rather than the processor module <NUM>, and the power supply module can more directly isolate power from the backplane in response to detecting one or more unauthorized modules.

Some embodiments can also be configured generate and deliver notifications in response to detection of an unauthorized module. <FIG> is a diagram illustrating delivery of rogue module notifications. In this example, an industrial controller <NUM> comprising a processor module <NUM> that supports backplane authentication performs monitoring and control of industrial devices <NUM>, via I/O modules <NUM> installed on the controller's backplane. If the processor module's device authentication component <NUM> identifies an unauthorized I/O module <NUM> (or other type of unauthorized modular device) installed on the backplane, the processor module's notification component <NUM> generates a rogue module notification <NUM> and sends the notification to one or more defined target devices. The rogue module notification <NUM> can include data that may assist the recipients in identifying the nature of the potential security breach, including but not limited to an identity of the industrial controller <NUM>, the identity of the slot in which the unauthorized module was detected, a type of the unauthorized device (e.g., analog input, digital output, etc.), a vendor and model number of the unauthorized device, an indication of whether the device is certified by the vendor (e.g., in the case in which the device is a vendor-approved device but has not been approved by the end user for operation on the industrial controller <NUM>), an indication of a countermeasure that was performed by the processor module <NUM> (e.g., disablement of the modular device, disconnection of power to the modular device or to the entire backplane, etc.), or other relevant information.

Target devices for the rogue module notification can be defined by the user (e.g., via the configuration application <NUM> used to configure and program the industrial controller). In an example configuration, processor module <NUM> may log the rogue module notification <NUM> to a log server <NUM> connected to the same plant network <NUM> as the industrial controller <NUM> (or to an office network accessible via the plant network <NUM>). The notification component <NUM> may also be configured to send the rogue module notification to an HMI terminal <NUM>, which renders the notification on an alarm screen for viewing by an operator or engineer. In yet another example, notification component <NUM> may be capable of delivering notifications <NUM> as text messages to defined phone numbers or email addresses associated with appropriate plant personnel. Other types of notifications are also within the scope of one or more embodiments of this disclosure.

By providing industrial controller devices that support backplane-level security protocols, embodiments described herein address a long-standing and generally ignored security gap within the context of industrial automation environments. Recognizing the security vulnerability of the industrial controller's backplane, the systems and methods described herein can protect users' control systems from attacks by rogue controller modules installed on the controller backplane. Left unprotected, the backplane could provide a channel through which such rogue modules could collect sensitive proprietary information, tamper with control data, interfere with controlled industrial processes, or access other networks or data busses within the industrial facility. The industrial controller devices described herein can prevent such attacks using security components built into the devices at the time of manufacture, providing a high level of backplane protection without the need for user configuration. If more selective security is desired, configuration tools associated with the devices can allow a user to assign exclusive security rights to selected devices (e.g., devices known to have been purchased by the end user).

<FIG> illustrate example methodologies in accordance with one or more embodiments of the subject application. While, for purposes of simplicity of explanation, the methodologies shown herein are shown and described as a series of acts, it is to be understood and appreciated that the subject innovation is not limited by the order of acts, as some acts may, in accordance therewith, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all illustrated acts may be required to implement a methodology in accordance with the innovation. Furthermore, interaction diagram(s) may represent methodologies, or methods, in accordance with the subject disclosure when disparate entities enact disparate portions of the methodologies. Further yet, two or more of the disclosed example methods can be implemented in combination with each other, to accomplish one or more features or advantages described herein.

<FIG> illustrates a first part of an example methodology 1400A for authenticating modular devices installed on an industrial controller's backplane. The example methodology can be implemented, for example, on a processor module configured to mount within an industrial controller chassis and execute a user-defined control program (e.g., a ladder logic program, a sequential function chart program, etc.) to facilitate monitoring and control of an industrial automation system or process. The example methodology can also be implemented in other types of industrial controller modules, including but not limited to remote I/O adapter modules, power supply modules, or networking modules.

Initially, at <NUM>, installation of a modular device on a backplane of an industrial controller is detected. The modular device may be, for example, a digital or analog input module, a digital or analog output module, a networking module, a special function module, or another type of module designed to exchange data with the processor module over the controller's backplane. The modular device may be detected, for example, based on receipt of a request from the modular device to be recognized by the processor module, a change in power or data flow across the backplane as a result of connecting the modular device to the backplane, or by another detection technique.

If installation of a modular device is detected (YES at step <NUM>), the methodology proceeds to step <NUM>, where a request for credentials is sent to the modular device via the backplane. At <NUM>, a determination is made as to whether a response is received from the modular device via the backplane in response to the request for credentials. If no response is received within a defined timeout period (NO at step <NUM>), the methodology proceeds to step <NUM>, where operation of the modular device on the backplane is denied. Alternatively, if a response is received (YES at step <NUM>), the methodology proceeds to step <NUM>, where a determination is made as to whether the response comprises vendor certificate data issued by a device vendor or other trusted third-party entity recognized by the processor module.

If the response does not comprise vendor certificate data (NO at step <NUM>), the methodology proceeds to step <NUM> where operation of the modular device on the backplane is denied. Alternatively, if the response comprises vendor certificate data (YES at step <NUM>), the methodology proceeds to step <NUM>, where digital signature data contained in the vendor certificate data is verified using a first public key associated with a vendor (or a trusted third-party entity) and stored on the processor module.

At <NUM>, a determination is made as to whether the digital signature obtained at step <NUM> is valid (that is, that the decrypted digital signature is recognized by the processor module, or matches a known and approved digital signature). If the digital signature is not valid (NO at step <NUM>), the methodology proceeds to step <NUM>, where operation of the modular device on the backplane is denied. Alternatively, if the digital signature is recognized (YES at step <NUM>), the methodology proceeds to step <NUM> of the second part of the example methodology 1400B illustrated in <FIG>.

<FIG> illustrates the second part of the example methodology 1400B. At <NUM>, a cryptographically random challenge value is encrypted using a second public key contained in the vendor certificate data received from the modular device at step <NUM>. The encrypted random challenge value represents a challenge issued to the modular device designed to prove the modular device's authenticity, since only a valid modular device that has been provided with a protected private key corresponding to the second public key will be able to properly decrypt the encrypted random challenge value. It is to be appreciated, however, that other types of authenticity challenges may be implemented at step <NUM> in place of the encrypted random challenge value. At <NUM>, the encrypted random challenge value is sent to the modular device via the backplane.

At <NUM>, a determination is made as to whether a challenge response is received from the modular device via the backplane in response to sending the encrypted random challenge value at step <NUM>. If no challenge response is received at step <NUM> within a defined timeout period (NO at step <NUM>), the methodology proceeds to step <NUM>, where the operation of the modular device on the backplane is denied. Alternatively, if the challenge response is received within the defined timeout period (YES at step <NUM>), the methodology proceeds to step <NUM>, where a determination is made as to whether the challenge response received at step <NUM> matches the random challenge value that was encrypted at step <NUM>. In the regard, the challenge response should include the original random challenge value, obtained by the modular device by decrypting the encrypted random challenge value using the protected private key corresponding to the second public key. If the challenge response does not match the random challenge value (NO at step <NUM>), the methodology proceeds to step <NUM>, where operation of the modular device on the backplane is denied. Alternatively, if the challenge response matches the random challenge value (YES at step <NUM>), the methodology proceeds to step <NUM>, where a determination is made as to whether a user certificate has been defined on the controller module. The user certificate can be configured by the end user to define an exclusive set of device identifiers corresponding to devices that are to be granted exclusive operating privileges on the backplane.

If a user certificate is not defined (NO at step <NUM>), the methodology proceeds to step <NUM>, where normal operation of the modular device on the backplane is authorized and initiated. Alternatively, if a user certificate has been defined (YES at step <NUM>) the methodology proceeds to step <NUM>, where a determination is made as to whether the device identifier of the modular device (received at step <NUM> as part of the modular device's first response) is authorized per the user certificate. The device identifier may be, for example, a physical device identifier such as a MAC address, or another protected identifier that is uniquely associated with the modular device. If the device identifier is not authorized (NO at step <NUM>), the methodology proceeds to step <NUM>, where operation of the modular device on the backplane is denied. Alternatively, if the device identifier is authorized (YES at step <NUM>), the methodology proceeds to step <NUM>, where normal operation of the modular device on the backplane is authorized and initiated.

<FIG> illustrates a first part of an example methodology 1500A for providing authentication credentials to a supervisory modular device - such as an industrial controller processor module, a power supply module, a remote I/O adaptor module, or a networking module - via the backplane of an industrial controller. The example methodology can be implemented on substantially any type of modular device designed to operate on the backplane of an industrial controller, including but not limited to a digital or analog input module, a digital or analog output module, a networking module, a special function module, or another type of controller module.

Initially, at <NUM>, a request to operate on the backplane of an industrial controller is sent via the backplane. The request can be sent by a modular device in response to detecting that the device has been connected to the power and/or data buses of the industrial controller's backplane. At <NUM>, a determination is made as to whether a request for credentials has been received from a supervisory device via the backplane. The supervisory device maybe, for example, the processor module of the industrial controller, a remote I/O adaptor module (in the case in which the modular device is installed in a remote I/O rack), a power supply module of the industrial controller, a networking module of the industrial controller, or another type of supervisory module.

If a request for credentials is received (YES at step <NUM>), the methodology proceeds to step <NUM>, where vendor certificate data - including at least a device identifier, a digital signature of an authorized vendor or trusted third-party entity, and a public key assigned to the modular device - is sent via the backplane. At <NUM>, a determination is made as to whether a challenge is received via the backplane. The challenge may be, for example, an encrypted random challenge value generated by the supervisory module using the public key provided by the modular device as part of the vendor certificate data at step <NUM>. However, other types of challenges designed to verify the authenticity of the modular device are within the scope of one or more embodiments of this disclosure. If no challenge is received within a defined timeout period (NO at step <NUM>), the methodology proceeds to step <NUM>, where the modular device ceases communication via the backplane. Alternatively, if the challenge is received within the defined timeout period (YES at step <NUM>), the methodology proceeds to step <NUM> of the second part of the example methodology 1500B illustrated in <FIG>.

At <NUM>, an encrypted random challenge value contained in the challenge received at step <NUM> is decrypted using a private key corresponding to the public key sent at step <NUM>. At <NUM>, the decrypted random challenge value obtained at step <NUM> is sent via the backplane. At <NUM>, a determination is made as to whether an instruction to begin operation on the backplane is received via the backplane. The instruction may be issued by the supervisory module in response to confirming that the decrypted random challenge value sent at step <NUM> matches the random challenge value originally generated by the supervisory module. If the instruction is not received within a defined timeout period (NO at step <NUM>), the methodology proceeds to step <NUM>, where the modular device ceases communication via the backplane. Alternatively, if the instruction is received (YES at step <NUM>), the methodology proceeds to step <NUM>, where the modular device initiates normal operation on the controller's backplane.

Embodiments, systems, and components described herein, as well as industrial control systems and industrial automation environments in which various aspects set forth in the subject specification can be carried out, can include computer or network components such as servers, clients, programmable logic controllers (PLCs), automation controllers, communications modules, mobile computers, wireless components, control components and so forth which are capable of interacting across a network. Computers and servers include one or more processors-electronic integrated circuits that perform logic operations employing electric signals-configured to execute instructions stored in media such as random access memory (RAM), read only memory (ROM), a hard drives, as well as removable memory devices, which can include memory sticks, memory cards, flash drives, external hard drives, and so on.

Similarly, the term PLC or automation controller as used herein can include functionality that can be shared across multiple components, systems, and/or networks. As an example, one or more PLCs or automation controllers can communicate and cooperate with various network devices across the network. This can include substantially any type of control, communications module, computer, Input/Output (I/O) device, sensor, actuator, instrumentation, and human machine interface (HMI) that communicate via the network, which includes control, automation, and/or public networks. The PLC or automation controller can also communicate to and control various other devices such as standard or safety-rated I/O modules including analog, digital, programmed/intelligent I/O modules, other programmable controllers, communications modules, sensors, actuators, output devices, and the like.

The network can include public networks such as the internet, intranets, and automation networks such as control and information protocol (CIP) networks including DeviceNet, ControlNet, and Ethernet/IP. Other networks include Ethernet, DH/DH+, Remote I/O, Fieldbus, Modbus, Profibus, CAN, wireless networks, serial protocols, near field communication (NFC), Bluetooth, and so forth. In addition, the network devices can include various possibilities (hardware and/or software components). These include components such as switches with virtual local area network (VLAN) capability, LANs, WANs, proxies, gateways, routers, firewalls, virtual private network (VPN) devices, servers, clients, computers, configuration tools, monitoring tools, and/or other devices.

In order to provide a context for the various aspects of the disclosed subject matter, <FIG> and <FIG> as well as the following discussion are intended to provide a brief, general description of a suitable environment in which the various aspects of the disclosed subject matter may be implemented.

With reference to <FIG>, an example environment <NUM> for implementing various aspects of the aforementioned subject matter includes a computer <NUM>. The computer <NUM> includes a processing unit <NUM>, a system memory <NUM>, and a system bus <NUM>. The system bus <NUM> couples system components including, but not limited to, the system memory <NUM> to the processing unit <NUM>. The processing unit <NUM> can be any of various available processors. Multi-core microprocessors and other multiprocessor architectures also can be employed as the processing unit <NUM>.

The system bus <NUM> can be any of several types of bus structure(s) including the memory bus or memory controller, a peripheral bus or external bus, and/or a local bus using any variety of available bus architectures including, but not limited to, <NUM>-bit bus, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association bus (PCMCIA), and Small Computer Systems Interface (SCSI).

The system memory <NUM> includes volatile memory <NUM> and nonvolatile memory <NUM>. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer <NUM>, such as during start-up, is stored in nonvolatile memory <NUM>. By way of illustration, and not limitation, nonvolatile memory <NUM> can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable PROM (EEPROM), or flash memory. Volatile memory <NUM> includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM).

Computer <NUM> also includes removable/non-removable, volatile/nonvolatile computer storage media. <FIG> illustrates, for example a disk storage <NUM>. Disk storage <NUM> includes, but is not limited to, devices like a magnetic disk drive, floppy disk drive, tape drive, Jaz drive, Zip drive, LS-<NUM> drive, flash memory card, or memory stick. In addition, disk storage <NUM> can include storage media separately or in combination with other storage media including, but not limited to, an optical disk drive such as a compact disk ROM device (CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive (CD-RW Drive) or a digital versatile disk ROM drive (DVD-ROM). To facilitate connection of the disk storage <NUM> to the system bus <NUM>, a removable or non-removable interface is typically used such as interface <NUM>.

It is to be appreciated that <FIG> describes software that acts as an intermediary between users and the basic computer resources described in suitable operating environment <NUM>. Such software includes an operating system <NUM>. Operating system <NUM>, which can be stored on disk storage <NUM>, acts to control and allocate resources of the computer <NUM>. System applications <NUM> take advantage of the management of resources by operating system <NUM> through program modules <NUM> and program data <NUM> stored either in system memory <NUM> or on disk storage <NUM>. It is to be appreciated that one or more embodiments of the subject disclosure can be implemented with various operating systems or combinations of operating systems.

A user enters commands or information into the computer <NUM> through input device(s) <NUM>. Input devices <NUM> include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit <NUM> through the system bus <NUM> via interface port(s) <NUM>. Interface port(s) <NUM> include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) <NUM> use some of the same type of ports as input device(s) <NUM>. Thus, for example, a USB port may be used to provide input to computer <NUM>, and to output information from computer <NUM> to an output device <NUM>. Output adapters <NUM> are provided to illustrate that there are some output devices <NUM> like monitors, speakers, and printers, among other output devices <NUM>, which require special adapters. The output adapters <NUM> include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device <NUM> and the system bus <NUM>. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s) <NUM>.

Computer <NUM> can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) <NUM>. The remote computer(s) <NUM> can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer <NUM>. For purposes of brevity, only a memory storage device <NUM> is illustrated with remote computer(s) <NUM>. Remote computer(s) <NUM> is logically connected to computer <NUM> through a network interface <NUM> and then physically connected via communication connection <NUM>. Network interface <NUM> encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE <NUM>, Token Ring/IEEE <NUM> and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL). Network interface <NUM> can also encompass near field communication (NFC) or Bluetooth communication.

Communication connection(s) <NUM> refers to the hardware/software employed to connect the network interface <NUM> to the system bus <NUM>. While communication connection <NUM> is shown for illustrative clarity inside computer <NUM>, it can also be external to computer <NUM>. The hardware/software necessary for connection to the network interface <NUM> includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.

<FIG> is a schematic block diagram of a sample computing environment <NUM> with which the disclosed subject matter can interact. The sample computing environment <NUM> includes one or more client(s) <NUM>. The client(s) <NUM> can be hardware and/or software (e.g., threads, processes, computing devices). The sample computing environment <NUM> also includes one or more server(s) <NUM>. The server(s) <NUM> can also be hardware and/or software (e.g., threads, processes, computing devices). The servers <NUM> can house threads to perform transformations by employing one or more embodiments as described herein, for example. One possible communication between a client <NUM> and servers <NUM> can be in the form of a data packet adapted to be transmitted between two or more computer processes. The sample computing environment <NUM> includes a communication framework <NUM> that can be employed to facilitate communications between the client(s) <NUM> and the server(s) <NUM>. The client(s) <NUM> are operably connected to one or more client data store(s) <NUM> that can be employed to store information local to the client(s) <NUM>. Similarly, the server(s) <NUM> are operably connected to one or more server data store(s) <NUM> that can be employed to store information local to the servers <NUM>.

What has been described above includes examples of the subject innovation. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the disclosed subject matter, but one of ordinary skill in the art may recognize that many further combinations and permutations of the subject innovation are possible. Accordingly, the disclosed subject matter is intended to embrace all such alterations, modifications, and variations that fall within the scope of the appended claims.

In particular and in regard to the various functions performed by the above described components, devices, circuits, systems and the like, the terms (including a reference to a "means") used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (e.g., a functional equivalent), even though not structurally equivalent to the disclosed structure, which performs the function in the herein illustrated exemplary aspects of the disclosed subject matter. In this regard, it will also be recognized that the disclosed subject matter includes a system as well as a computer-readable medium having computer-executable instructions for performing the acts and/or events of the various methods of the disclosed subject matter.

In addition, while a particular feature of the disclosed subject matter may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms "includes," and "including" and variants thereof are used in either the detailed description or the claims, these terms are intended to be inclusive in a manner similar to the term "comprising.

In this application, the word "exemplary" is used to mean serving as an example, instance, or illustration. Any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the word exemplary is intended to present concepts in a concrete fashion.

Claim 1:
An industrial controller module (<NUM>), comprising:
memory (<NUM>) that stores executable components;
one or more processors (<NUM>), operatively coupled to the memory, that executes the executable components, the executable components comprising:
a program execution component (<NUM>) configured to execute an industrial control program (<NUM>) that controls output signals of an industrial controller based on input signals received by the industrial controller, wherein the output signals and the input signals are conveyed via a backplane (<NUM>) of the industrial controller; and
a device authentication component (<NUM>) configured to:
detect installation of a modular device on the backplane of the industrial controller;
exchange authentication data with the modular device via the backplane during a device authentication sequence;
initiate operation of the modular device on the backplane in response to determining, based on a result of the authentication sequence, that the modular device is authorized to operate on the backplane; and
disable the operation of the modular device on the backplane in response to determining, based on the result of the authentication sequence, that the modular device is not authorized to operate on the backplane, characterized in that operation of the modular device is disabled by disabling a run mode of the industrial controller module, thereby preventing the industrial control program from executing until such time as the device authentication component authorizes all modular devices installed in the industrial controller.