Patent Application
20240357346
The following generally relates to a secure unmanaged network switch with integrated hardware and software security.
In Ethernet data networks, switches are used to connect devices together and transmit data between devices. A switch includes data ports and devices are connected to the switch via the data ports. The switch receives incoming data via a data port and outputs the incoming data to another data port based on a media access control (MAC) address, which identifies the destination device.
There are two main categories of switches: managed switches and unmanaged switches. Managed switches can be controlled remotely by a network administrator and include the highest level of management software and security software. Managed switches are used in large enterprise networks for large scale. Due to their complexity, managed switches are the most expensive category of switches. Smart switches and enterprise managed switches are other types of managed switches. For example, using a web or Internet interface, a network administrator can access a smart switch or another type of managed switch, or both. Many managed switches include a transmission control protocol or Internet protocol (TCP/IP) stack or architecture to control how data is communicated. They can be managed from other Ethernet network connected devices.
By contrast, unmanaged switches are plug-and-play and do not have configuration or interface options. Unmanaged switches cannot be controlled remotely by a network administrator or by another device on the Ethernet network. Unmanaged switches lack security features. Unmanaged switches do not have a processing unit and software running on the device. Accordingly, unmanaged switches do not have a TCP/IP stack. Due to their low cost, a large number of unmanaged switches are deployed in the industrial field to connect devices.
Turning to
In the field 101 (which may be a factory, a manufacturing plant, a robotic device in the field, a building, an industrial machine, a mine, a power plant, a farm, etc.), unmanaged switches 103a, 103b are commonly used to connect to connect to one or more of LAN/WAN devices, user/operator terminals, sensor devices, and Internet of Things (IoT) devices. Many unmanaged switches from different locations can be used in the field (e.g., different locations in a factory), and these unmanaged switches are connected to a Layer 2 or Layer 3 switch 102, which is a managed Ethernet switch. The switch 102 is data accessible via a data network 105 (such as the Internet or some other network) by a network administrator computer 106. The network administrator computer 106 can be a desktop computer, laptop, tablet, smartphone, or some other computing device that connects to the data network 105. In this way, the network administrator computer 106 remotely views and manages the switch 102, including the security of the switch 102.
In setup and management, a field technician 107 physically enters the field 101 to connect devices (e.g., user operator terminals, sensor devices, actuators, IoT devices, industrial equipment, etc.) to the unmanaged switches 103a, 103b, and to connect the unmanaged switches to the switch 102. This includes the field technician 107 manually plugging in connecting cables into the data ports of an unmanaged switch. By contrast to the managed switch, the unmanaged switches 103a, 103b are not remotely controllable or manageable by network administrator computer 106.
It is herein recognized that, due to the lack of security and the lack of diagnostics in unmanaged switches, a bad actor or adversary 108 can tamper with the field level devices and the network administrator would not have any knowledge of the tampering. For example, the adversary 108 can unplug a sensor device, which is currently plugged into a data port of an unmanaged switch, and plug into the same data port another sensor device in order to send false sensor data through the network. In another example, the adversary 108 can plug in a new device into a data port of the unmanaged switch to gain access to the network, either to send unwanted data or to obtain data. Unused data ports and data ports with existing plugged devices are both prone to security attacks. In other words, an adversary 108 can conduct man-in-the middle attacks, intercept an existing connection, and cause other security breaches at the level of the unmanaged switches. In another example, the adversary 108 can swap devices amongst data ports. These and other ways of tampering with the devices connected to the unmanaged switch can damage the security of the data network and compromise the security of the data itself.
Furthermore, it is herein recognized that many devices 104 are locally isolated and cannot easily connect to the Ethernet network 104. Examples of these devices include actuator devices, manufacturing devices, industrial devices, and IIOT devices. For example, unmanaged switches using typical Ethernet protocols have a limited distance range. A typical range limit for Ethernet cables is 100 meters. The limited distance can be too short for field devices and, therefore, cannot physically reach an unmanaged switch (or an unmanaged switch that is connected to the switch 102 cannot reach a locally isolated device 104). In another example, the locally isolated device is not Ethernet friendly compatible.
These locally isolated devices 104 are also prone to tampering by the adversary 108. A remotely located network administrator using their computer 106 cannot detect or stop the tampering done in the field 101.
It is herein desirable to address one or more of these technical security problems of the switches.
Embodiments will now be described by way of example only with reference to the appended drawings wherein:
It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the example embodiments described herein. However, it will be understood by those of ordinary skill in the art that the example embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the example embodiments described herein. Also, the description is not to be considered as limiting the scope of the example embodiments described herein.
Within this specification, different structural entities (which may variously be referred to as “component”, “circuit”, “system”, “processor”, “module”, “interface”, “device”, other components, etc.) may be described or claimed as “configured” to perform one or more tasks or operations. This formulation—[entity] configured to [perform one or more tasks]—is used herein to refer to structure (i.e., something physical, such as an electronic circuit). More specifically, this formulation is used to indicate that this structure is arranged to perform one or more tasks during operation. A structure can be said to be “configured to” perform some task even if the structure is not currently being operated. A “biosensor configured to collect biometric information” is intended to cover, for example, an integrated circuit that has circuitry that performs this function during operation, even if the integrated circuit in question is not currently being used (e.g., a power supply is not powering it). Thus, an entity described or recited “configured to” perform some task refers to something physical, such as a device, circuit, memory storing program instructions executable to implement the task, etc. This phrase is not used herein to refer to something intangible. Thus, the “configured to” construct is not used herein refer to a software entity, such as an application programming interface (API).
The term “configured to” is not intended to mean “configurable to.” An unprogrammed Field Programmable Gate Array (FPGA), for example, would not be considered to be “configured to” execute some specific operation, although it may be “configurable to” perform that specific operation and may be “configured to” execute that specific function after programming.
Reciting in the appended claims that a structure is “configured to” perform one or more tasks is intended not to be interpreted as having means-plus-function elements.
Throughout the specification and the claims, the following terms take at least the meanings explicitly associated herein, unless the context clearly dictates otherwise. The term “or” is intended to mean an inclusive “or.” Further, the terms “a,” “an,” and “the” are intended to mean one or more unless specified otherwise or clear from the context to be directed to a singular form.
In this specification, numerous specific details have been set forth. It is to be understood, however, that implementations of the disclosed technology may be practiced without these specific details. In other instances, well-known methods, structures, and techniques have not been shown in detail in order not to obscure an understanding of this description. References to “for example”, “some examples,” “other examples,” “one example,” “an example,” “various examples,” “one embodiment,” “an embodiment,” “some embodiments,” “example embodiment,” “an example aspect”, “various embodiments,” “one implementation,” “an implementation,” “example implementation,” “various implementations,” “some implementations,” etc., indicate that the implementation(s) of the disclosed technology so described may include a particular feature, structure, or characteristic, but not every implementation necessarily includes the particular feature, structure, or characteristic. Further, repeated use of the phrases “in one example,” “in one embodiment,” or “in one implementation” does not necessarily refer to the same example, embodiment, or implementation, although it may.
As used herein, unless otherwise specified the use of the ordinal adjectives “first,” “second,” “third,” etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.
It is herein recognized that networks that use unmanaged switches and managed switches (e.g., Layer 2 or Layer 3 managed switches) are prone to technical security problems at the field level (e.g., also called Level 0 in the Purdue model for industrial control systems) where the unmanaged switches are located. Therefore, a secure unmanaged Ethernet switch is herein provided, which includes a security framework, which can be used at the field level. In an example aspect, the secure unmanaged Ethernet switch is herein considered to be a new category of a network switch, different from a managed switch and different from an unmanaged switch.
In an example embodiment, a secure unmanaged Ethernet switch, also herein interchangeably called a “secure unmanaged switch” and a “SUS”, is a switch equipped with local security hardware and software controls. In an example aspect, the localized security hardware and software controls enable data ports to be locked or unlocked by a field technician in close physical proximity to the SUS. In another example aspect, the localized secured hardware and software enables data ports of the SUS to be automatically locked in a “plug and play” configuration. For example, client devices are plugged into the SUS and, automatically after a predetermined time, the data ports are locked. In another example, a pre-determined lock configuration profile is stored in non-volatile memory of the SUS during manufacturing or production, and the SUS automatically locks the data ports according to the configuration profile after being powered on or booted up. In another example aspect, the localized security hardware and software controls enable firmware to be updated by a field technician in close physical proximity to the SUS.
In an example embodiment, the SUS includes hardware and software that define security and control functions.
An example aspect of a security and control function is locking (or unlocking) an unused data port in the SUS. In a locked configuration of a specified unused port, even if a device is plugged in to the unused port (by an adversary or inadvertently by a field technician), the SUS prohibits data to be transmitted to or from (or both) the device. For example, this prevents an adversary from plugging in a device into the unused port to steal data or corrupt the data.
Another example aspect of a security and control function is locking (or unlocking) a used data port in the SUS to a specific device. In particular, in a locked configuration of a specified used port, the device that is plugged in the used port is locked, so that the MAC address of the device must be associated with the specified used port. No other MAC addresses can be used to send or receive data via the specified used port. For example, this prevents an adversary from intercepting data or switching devices in the port.
Another example aspect of a security and control function is to provide sticky MAC address and control, even after the SUS is rebooted (e.g., as part of power cycle). The previously stored locked and unlocked configurations for used data ports or unused data ports, or both, remains in place.
Another example aspect of a security and control function is a physical port to locally upload new software to upgrade the software of the SUS, or to locally upload predefined locking configurations, or to locally update security data (e.g., parameters, encryption keys, etc.), or to locally download log data, or a combination thereof. It will be appreciated that software includes firmware. In particular, a USB key or other local memory device is plugged into the physical port of the SUS to upload data. For example, this prevents a remotely located adversary from updating the firmware of the SUS as there is no option for a remotely located device on the Ethernet network to manage the SUS.
Another example aspect of a security and control function is a user device authentication process to execute locking and unlocking of ports, and to execute software upgrades. In particular, a user device of an authorized person (e.g., a field technician) and the SUS must be in close physical proximity to communicate with each other, such as over Near Field Communication (NFC) or another very localized communication medium, and to establish a secure communication session. In other words, NFC, or a similar close proximity communication module, ensures that the user device is very close in distance (e.g., within range of several centimeters) to the SUS, which increases security. The secure communication session is established Trust using currently known or future known trust verification protocols. In an example embodiment, the secure communication session is established by key exchange, and the encryption keys are stored on in a hardware security module (HSM) or similar in the SUS. In the secure session, data is encrypted and then transmitted between the user device and the SUS. For example, this prevents an adversary without an authorized user device to change the lock configuration of data ports. This also prevents an adversary without an authorized user device to upload or modify data of the SUS. The user device, for example, is a mobile device, such as a smart phone, tablet, or laptop.
Another example aspect of a security and control function is to limit any changes to the SUS to be performed through an authorized user device that is in close proximity to the SUS (e.g., via NFC or another close proximity communication medium). In particular, changes to switch configurations, encryption keys, authorized software updates, ID assignment, and unpowering the SUS, amongst other changes, are all performed through a secure channel between the authorized user device and the SUS.
It will also be appreciated the SUS is an alternative to the unmanaged switch, while providing security for field level Ethernet critical infrastructure. In another example aspect, a large number of SUS units can be deployed into the field at lower cost compared to managed switches, and at a cost comparable to unmanaged switches.
In another example aspect, the SUS does not have a TCP/IP stack or any other form of network management. In another example aspect, the SUS control and functionality is inaccessible by a remotely located network administrator. In other words, the SUS cannot be remotely managed. These are features similar to an unmanaged switch.
Turning to
Some devices 213 are analog devices and cannot connect directly to the SUS 200, which operates on an Ethernet protocol. Therefore, one more of such devices 213 are plugged into a gateway 212, which processes the data from the devices 213, and the gateway 212 transmits the device data to the SUS 200.
Some devices 215 are also in a different physical layer and such a device 215 is connected to a media converter 214. The media converter interfaces with different physical layers, which is appropriate for the SUS configured for single pair Ethernet, or some other type of physical layer.
The SUS 200 wirelessly communicates with an authenticated user device 201 that is in close distance. The user device 201 is also herein called a mobile device. For example, the field technician 107 has user device 201 that communicates with the SUS 200 over NFC. While Near Field Communication is preferred, other types of currently known and future known close proximity communication can be used, including Bluetooth™ communication. Other types of close proximity communication include other types of radio frequency identification protocols.
In an example embodiment, the mobile device 201 also communicates with a network administrator computer 106 via the data network 105, such as through cellular connection or Wifi connection. For example, the mobile device 201 may be used to obtain security data from the network administrator computer 106, that in turn is used to authenticate the mobile device with the SUS 200. In another example, the mobile device 201 obtains software data from the network administrator computer, which is to be uploaded to the SUS 200. In another example, the mobile device 201 obtains status data and history logs from the SUS 200, and then the mobile device 201 transmits this data to the network administrator computer.
In an example embodiment, the SUS 200 is part of an Ethernet Gateway device. In other words, the function of the SUS 200 is combined with an Ethernet Gateway device.
Turning to
The Ethernet cable 330 between the managed switch 102 and the SUS 200 connects to the SUS 200 using a RJ45 data port 301.
The field devices connect to the SUS 200 using SPE data ports 302. The cabling for the SPE, also called single twisted pair, using the protocol 10BASE-T1L (or another protocol compatible with SPE) can support transmission of data of over 1 kilometer, even reaching a distance of 1.7 kilometers. This allows devices to be placed at considerable distance from the SUS 200, thereby extending the reach of the industrial data network.
For example, a local area network or wide area network hub 310 is connected with a cable 331 to the SUS 200 using a SPE data port. Similarly, wireless router 311 is connected by a cable 332 to the SUS using a SPE data port. Industrial machinery 312 is connected by a cable 333 to the SUS using a SPE data port.
A gauge 313 is connected via a cable 335 to a gateway device 304, and the cable supports the Modbus RTU, which is an open serial protocol. An air flow controller 314 and a light controller 315 are respectively connected via cables 336 and 337 to the gateway device, and these cables support RS485 serial protocols. Liquid sensor 316, chemical sensor 317 and temperature sensor 318 are respectively connected via cables 338, 339, and 340 to the gateway 304, and these cables support analog data. The gateway 304 processes the data from the devices 313, 314, 315, 316, 317, 318 into a format suitable for transmission over SPE. In particular, the gateway 304 includes a SPE data port, which is connected to a cable 334, and the cable 334 is connected to a SPE data port of the SUS.
A fan controller 319 is connected via a cable 342 to a media converter 305, and the cable 342 supports one or more of a 10/100/1000BASE-T protocol. The media converter includes both a RJ45 data port and a SPE data port; the RJ45 data port is connected to cable 342 and the SPE data port is connected to the cable 341. Through the cable 341, the media converter is connected to another SPE data port on the SUS 200. In an example aspect, the media converter converts the data from one or more of a 10/100/1000BASE-T protocol to a 10BASE-T1L protocol.
In an example aspect, a kit of parts is provided that includes one or more SUS devices and one or more media converters.
Turning to
In an example embodiment, the EEPROM 402-1 of the NFC module 402 is populated with configuration data during the manufacturing or production process. The configuration data can be stored (also called “burned”) onto the EEPROM without powering the SUS 200, which makes this data storage process more efficient during manufacturing or production. In an example aspect, after powering on the SUS, the configuration data is automatically processed by the processor and may also be used to automatically affect the multi-port Ethernet switch 407.
For example, configuration data stored on the EEPROM 402-1 includes one or more of: the SUS device ID, SUS device name, designated location of the SUS device, other profile data, and other configuration data. In another example aspect, the configuration data stored on the EEPROM includes a locking configuration. The locking configuration, also herein called locking config or lock config, includes a predefined association of SUS data ports to MAC addresses or device names, or both. The locking configuration can also include a predefined one or more SUS data ports that are to remain unused. The locking configuration can also include a predefined one or more SUS data ports that are to remain unlocked. After the SUS is powered on, the processor chip 401 obtains the locking configuration from the EEPROM and sends the locking configuration to the multi-port Ethernet switch 407. In turn, the multi-port Ethernet switch 407 writes the locking configuration into its hardware.
While the configuration data is described above as being stored in the EEPROM of the NFC module 402, in other example embodiments the configuration data is stored on a non-volatile memory device on the SUS 200. In other words, the configuration data does not have to be stored on the EEPROM of the NFC module 402, but can be pre-loaded during manufacturing or production onto any non-volatile memory device on the SUS 200 that is in data communication with the processor chip 401.
A multi-port Ethernet switch 407 is within the SUS and is connected to the processor chip 401. The multi-port Ethernet switch 407 is connected to data ports 408-1, 408-2, 408-3, . . . , 408-n. In the example shown, the data ports can be of the same connector type. In another example, the data ports are of different types.
The SUS 200 also includes a tamper sensor 411, which is in data communication the processor chip 401. The tamper sensor is configured to detect if the casing or body of the SUS has been tampered. For example, the tamper sensor is a light sensor positioned within the SUS body. In a secure and nominal operation, the space within the body (or casing) of the SUS is dark. However, if the body (or casing) is opened so that the internal hardware components are accessible, then the light sensor will detect the presence or increased presence of light. In another example, the tamper sensor is a mechanical switch that detects if the body (or casing) is opened. Other types of tamper sensors can be used.
A power port 409 receives power, which is transmitted to a power module 410, and the power module distributes the power over a power bus to the components in the SUS.
Turning to
Turning to
A mobile device 201 includes hardware components 601, examples of which include a processor, memory, a communication module (e.g., for communicating via a cell network, WiFi, LAN, WAN, etc.), and a user interface (e.g., display screen, touch interface, keyboard, etc.). These hardware components 601 can vary in type, number and architecture as mobile devices continue to develop. The mobile device 201 also includes a NFC module 602, or another type of close proximity communication module, to communicate with the SUS 200. In an example aspect, the mobile device 201 includes a browser 603a, or a native application (also called a SUS app) 603b, or both. The browser 603a or the SUS app 603b, or both, are more generally herein referred to as the user agent 603. The user agent 603 displays a graphical user interface (GUI) on a display screen to guide the user through the authentication process and the related action (e.g., logging in, executing a command, a transaction, accessing data, etc.).
The mobile device establishes trust with the SUS. For example, the mobile device uses a transport layer security (TLS) framework module 604 to store and manage authentication data on the device in a secure manner. The TLS framework is used to establish a secure communication session with the secure unmanaged switch over NFC, or another close proximity wireless communication protocol. Another example of a close proximity wireless communication protocols includes Bluetooth™.
In an example embodiment, the mobile device 201 also includes a biometric sensor 605 and a device authenticator 606, which can be used to authenticate the user before using the user agent 603 to interact with the SUS 200. In another example aspect, the biometric sensor 605 and the device authenticator 606 are used to authenticate the user before executing certain functions (e.g., locking or unlocking data ports on the SUS, or both).
In an example aspect, the device authenticator 606 includes a secure execution and secure storage environment, which can be implemented using one or more of: a Trusted Execution Environment (TEE); a secure element, a firewall; a software layer; a secure enclave; a Hardware Secure Module (HSM); etc. It will be appreciated that a TEE is a computing chip that, for example, exists on a processor device. It will be appreciated that a HSM is a separated computing appliance. Authentication data about a user 107 can be stored in the device authenticator. The authentication data about the user, for example, includes a device authentication private key (also referred to as a DA private key) associated with the user 107 and the device authenticator 606 of the mobile device 201. The device authenticator 606, for example, interacts with the biometric scanner 605 to obtain identifying data about the user, and compares the scanned identifying data about the user with stored identifying data about the user. For example, the identifying data about the user is biometric authentication data, including and not limited to one or more of: fingerprint scan, eye scan, facial recognition, etc. The scanner 605 includes one or more sensors that can capture the biometric authentication data. While some embodiments use the biometric sensor to authenticate the user, in other embodiments, there is no biometric authentication and the user can access the user agent using alternative authentication or using no authentication.
The mobile device 201 and the SUS 200 use their NFC modules to establish trust. In an example aspect, a key exchange takes place to establish an encrypted session between the mobile device 201 and the SUS 200. The keys of the SUS are stored on the TPM chip 403.
In an example embodiment, a public key infrastructure (PKI) is used to establish the secure communication between the devices. In an example aspect, a PKI private key is securely stored on the TPM chip 403, and it is used to verify incoming data from a mobile device. In an example aspect, PKI key creation occurs during production of the SUS by the equipment supplier. Other currently known and future known encryption and authentication computations can be used to establish a secure communication session and to transmit encrypted data between the mobile device and the SUS.
In another example embodiment, there is no TPM chip 403 on the SUS 200. Instead, the keys that are used for a key exchange are stored on the processor chip 401 or are stored on another memory 404.
Turning to
The power over data line control module 510 obtains power from the power port 409, or, alternatively it can obtain power off another dedicated power port. The power over data line control module 510 converts incoming power into power suitable for delivery into SPE ports 502, now not just data ports but both data and power. The term “suitable power” used herein may mean one or more of: a specified voltage, a specified current limit and power allocation, galvanic isolation, inrush limitation, and noise filtering.
In addition to conversion functionality, the power over data line control module splits incoming power into individual channels each associated with a corresponding SPE port and each having individual associated voltage and current limit. These individual channels may carry power and low-speed communication used to establish power requirements according to an end device connected to SPE port. These individual channels may also transmit status data of the end devices (that are connected to the SUS 200) to the power over data line control module 510. Examples of the status data include: power fault, overheating, and sleep mode.
In order to isolate power with low-speed communication and high-speed data communication, the power coupling modules 511 are used. Each power coupling module comprises passive elements, such as inductors and capacitors.
As can be seen in
A user device can wirelessly transmit commands to the processor chip 401, via the NFC module 402, to control the power over data line control module 510. For example, via NFC, the user device can trigger the processor chip 501 to transmit one or more control commands (as noted above) to the control module 510.
Also shown in
The memory device 404, which is accessible by the processor chip 401, stores the firmware 621 and a diagnostic and history log 622. The diagnostic and history log 622 includes, for example, anomalies, unauthorized MACs (e.g., that where blocked), time stamps and IDs of secure communication sessions with authenticated mobile devices, failed attempts to establish secure communication session with an authenticated device, locking actions associated with time stamps, unlocking actions associated with time stamps, firmware history log, tamper data from the tamper sensor 411, etc.
A destination device 614 having a first MAC address (MAC1) is connected to data port #1 610 of the SUS. A client device 615 having a second MAC address (MAC2) is connected to data port #2 611 of the SUS. The client device sends data to the destination device (and optionally vice versa) via the SUS 200. Data port #3 612 remain unused. An uplink data port 613 sends data to the rest of the IT/OT LAN through a device 616. An example of the device 616 is the L2/L3 managed switch 102.
Turning to
Block 701: One or more devices are connected to the SUS via its one or more data ports.
Block 702: The SUS (or more particularly the multi-port Ethernet switch 407) automatically populates the dynamic MAC address table 619. This is part of the learning process of the multi-port Ethernet switch 407.
Block 703: In an example embodiment, for further verification, the SUS determines if all devices are accessible from the network (for example, from an administrator interface. The interface can be for an operational technology (OT) or information technology (IT) administrator. For example, the SUS sends a listing of all connected devices to the network administrator computer 106, and the network administrator computer 106 sends a message to the field technician's mobile device 201 with the listing of all connected devices. If the listing of all connected devices matches the field technician's expectation of what he or she sees at the SUS, then the field technician has completed verification and can proceed with locking or unlocking ports. After verification is successful, then the process continues to block 704. Alternatively, after verification has filed, the process continues to block 715. It will be appreciated that this verification step is optional.
Block 704: The SUS establishes a session with a mobile device 201 over NFC using the NFC module 402.
Block 705: The mobile device establishes session with the SUS 300 over NFC using its own NFC module 602.
In an example embodiment, as part of the session, the SUS transmits to the mobile device one or more of the following context data: a name or ID of the SUS; a listing of all the data port IDs of the SUS; a listing of the source MAC address of the devices currently plugged in to the data ports where applicable; a listing of the device names or IDs currently plugged into the data ports where applicable; a listing of the locations of devices currently plugged into the data ports where applicable; and a listing of unused data ports, in which no device is plugged in. This context data is viewable in a GUI on the mobile device 201. The field technician can review this information when deciding which one or more data ports should be locked or unlocked. The data port ID is typically a number, but other types of IDs can be used to identify one data port from another.
When a given data port is locked, the MAC address of a given device currently plugged into the given data port is associated with the given data port as rule-based locked configuration in the SUS. In other words, after the given data port with the given device (which is identifiable by the MAC address) is locked, only the given device can send messages or receive messages (or both) via the given data port.
Block 706: The mobile device receives input to specify a lock configuration. For example, a user provides input via graphical user interface of the user agent 603 to specify which one or more data ports on the SUS are to be locked or unlocked. Alternatively, pre-set configurations are stored or accessible on the mobile device, and a pre-set configuration is selected by the user (or is automatically selected by the user agent 603) to lock or unlock the data ports (or both). An example of a pre-set lock configuration is to lock all data ports. Another example of a pre-set configuration is to lock a certain subset of the data ports.
Block 707: The mobile device receives input to issue a lock command, which is based on the specified lock configuration.
Block 708: The mobile device transmits the lock command to the SUS (over NFC or a similar close proximity communication technology) according to the specified lock configuration.
Block 709: The SUS processor chip 401 receives the lock command over NFC according to the lock configuration.
Block 710: The processor chip 401 sends a command to the multi-port Ethernet switch 407 to write and activate ACL rules in the ACL 617, or to write an entry in the static MAC address table 618, or both, according to the specified lock configuration.
Block 711: The multiport Ethernet switch 407 writes and activates the ACL rules or writes entry to static MAC address table, or both, according to the lock configuration.
For example, if a specified data port of the SUS is to be locked, then an ACL rule is written and activated in the ACL (or just activated if it is already predefined and exists in the ACL 617). The ACL rule will specify that an incoming Ethernet message at the specified data port must have a specified source MAC address in order to be transmitted via the SUS. The specified source MAC address and the specified data port are associated with each other in a locked rule. By contrast, if the incoming Ethernet message on the specified data port does not have the specified source MAC address, then the SUS will not transmit the incoming Ethernet message, thereby blocking the incoming Ethernet message.
In addition, or in the alternative, an entry is written on the static MAC address table 618 that specifies the MAC address of the device and the data port ID are associated with each other.
Block 712: The session between the SUS and the mobile device ends.
Block 713: The mobile device ends the secure session with the SUS.
Block 714: The SUS periodically sends status updates to the network administrator. For example, the processor chip 401 generates the updates and sends these updates for transmission via the uplink data port 613.
Block 715: In the event that the verification at block 703 has failed, the field technician provides feedback via the mobile device that that a connected device is inaccessible to the network administrator computer. Alternatively, the mobile device and the SUS establish a secure communication session, and the mobile device transmits the failed verification to the SUS via NFC (or some other close proximity wireless communication).
It will be appreciated that using the process of
Turning to
In particular, blocks 701, 702 and 703 take place. At block 721, the SUS is run for a predetermined amount of time t. For example, the time period t begins after populating the dynamic MAC address table. In another example, the time period t begins after the SUS has been powered on. In another example, the time period t begins after a user input to the SUS has been provided (e.g., via the mobile device 201 via a secure communication session, or via a physical switch on the SUS, etc.). It will be appreciated that different conditions (or combinations of conditions) could be applied to automatically start the time period t. In an example aspect, the time period t is a predetermined amount of time stored in memory 404 of the SUS. In another example aspect, the time period t can be selected by a field technician and transmittable via the mobile device 201 via a secure communication session. In another example aspect, the time period tis self-determined by the SUS according to certain parameters.
In an example aspect, the time period t is 30 minutes. In another example aspect, the time period t is 1 hour. In another example aspect, the time period t is 24 hours.
Continuing with
The process in
Turning to
In
At block 732, after a predetermined setup condition has been detected, the processor chip 401 automatically obtains the lock config from the non-volatile memory.
Using the obtained lock config, the SUS proceeds with blocks 710 and 711 to lock the data ports.
Turning to
The example in
Block 801: The particular data port #2 on the SUS receives an Ethernet Frame. The Ethernet frame includes a source MAC address.
Block 802: A set of instructions or rules are stored in the ACL 617 of the multi-port Ethernet switch 407 that are associated with the particular data port #2. The multi-port Ethernet switch 407 accesses these instructions specific to data port #2, as the Ethernet frame arrived at data port #2.
In an example embodiment, instructions or rules are a list of locked data ports. In an example aspect, a given rule identifying a locked data port is also herein called a locking rule. These sets or instructions or rules are stored as a list on the multi-port Ethernet switch. The list of one or more locked data ports specifies that each of the one or more locked data ports is respectively configured to only communicate with a specified media access control (MAC) address. In another example embodiment, the list includes locked data ports that are respectively prohibited from all communication; in other words, to remain an unused data port. It will be appreciated that a list can include a combination of one or more locked data ports configured to only communicate with a respective specified MAC address, and can include one or more locked data ports that are prohibited from all communication.
In the example of
Block 803: As part of the ACL rule for block 802, the switch 407 looks up or obtains the source MAC address from the Ethernet frame.
Block 804: The switch 407 determines if the obtained source MAC address from the Ethernet frame matches a stored MAC address in the ACL 617. The stored MAC address in the ACL was previously stored as part of the rule and is associated with the particular data port, in this example data port #2.
Block 805: If there is a match, then the switch 407 forwards the MAC address to the static MAC address table 618.
Block 806: If there is no match, then the switch 407 blocks the Ethernet frame (also called an Ethernet message) and does not transmit it via the SUS.
In this example, the obtained source MAC address equals or matches the stored MAC address (e.g., MAC2) associated with data port #2, as per the rule stored in the ACL 617.
Block 807: Therefore, in the example, the SUS forwards the MAC address MAC2 and the data port #2 to the static MAC address table 618 to conduct a check.
Block 808: For example, the check includes the switch 407 determining if there is a match of the MAC address MAC2 and the data port #2 in the static MAC address table (block 809). If there is a match, then the switch 407 uses the static MAC address table to transmit the Ethernet frame (also herein called the Ethernet message) to the destination data port of the SUS (block 811). The destination data port, for example, in the static MAC address table is associated with the source MAC address. In other words, the Ethernet frame is transmitted by the SUS to its associated destination address in the data network.
Alternatively, if there is no match in the static MAC address table, then the MAC address and data port are forwarded to the dynamic MAC address table (block 810).
Block 812: In an example where there is no match at the static MAC address table, the switch 407 forwards the information to the dynamic MAC address table 619. The information includes the MAC address MAC2, the data port #2, and the time stamp for an entry in the dynamic MAC address table.
Block 813: The switch 407, using the dynamic MAC address table, then transmits the Ethernet frame to one or more of the data ports.
Alternatively, if the data port #2 is not locked (or in an unlocked mode), then, responsive to receiving an Ethernet frame, an entry of the Ethernet frame from the device is forwarded and written directly to the dynamic MAC address table 619 (block 809). In an example aspect, in the unlocked mode, the switch 407 does not check the ACL for rules and nor does the switch 407 transmit the Ethernet frame using the static MAC address table.
In an example aspect, all Ethernet frames from the data ports, except from a designated uplink data port, are processed using the operations of
Turning to
More generally, an example embodiment of the secure unmanaged Ethernet switch includes a multi-port Ethernet switch, and the multi-port Ethernet switch includes an ACL and a dynamic MAC table. The multi-port Ethernet switch is configured to at least: receive a source MAC address associated with an Ethernet frame via a given data port of the plurality of data ports; compare the source MAC address with a locking rule stored in the Access Control List, the locking rule specifying that the given data port is configured to only communicate with a specified MAC address; and, after determining that the source MAC address matches the specified MAC address, forward the Ethernet frame and the source MAC address to the dynamic MAC table for transmission to a destination address associated with the Ethernet frame.
Turning to
The rule determination at block 831 is similar to the rule determination at block 802 in
Alternatively, if the data port is unlocked, then the MAC address from the incoming Ethernet frame us written to the dynamic MAC address table and then transmitted.
Turning to
Block 901: The multi-port Ethernet switch 407 detects a blocked Ethernet frame. The blocked Ethernet frame, for example, occurs at block 806.
In an example embodiment, a blocked Ethernet frame refers to an Ethernet frame that comes into a given data port, but the SUS determines there are no conditions that permit forwarding or transmission of the Ethernet frame. As a result, the Ethernet frame is dropped (also called “blocked”), becoming a blocked Ethernet frame. In a further example aspect, the process for determining whether or not to forward or transmit the Ethernet frame is described in the processes with respect to
Block 902: Responsive to detecting the blocked Ethernet frame, the multi-port Ethernet switch 407 transmits the blocked Ethernet frame (or parts of it) and related data to the processor chip 401. The data sent to the processor chip includes, for example, one or more of: the time stamp of when the Ethernet frame; the MAC address; the blocked Ethernet frame; and a source data port ID or number.
Block 903: The processor chip 401 stores the data in the memory 404. For example, it is stored in the history log 622.
Block 904: The processor chip 401 then sends a message indicating an error or risk status about the blocked Ethernet frame. For example, this message is sent via the managed switch 102 and to the network administrator computer 106.
The executable process described in
Turning to
In another example aspect, during the secure session with the mobile device, the SUS can upload or transmits data to the external memory device via the USB port 406.
Alternatively, during a secure session, data from an external device can be sent to the SUS via the GPIO port 405, or can be pulled from the SUS via the GPIO port and stored on the external device.
Block 1001: The SUS establishes a session with the mobile device 201 over NFC (or some other close proximity communication), including using the security processing of the TPM.
Block 1002: The mobile device also establishes the secure session with the SUS over NFC (or some other close proximity communication).
Block 1003: The mobile device receives an input to permit a download function via its USB port 406, or the GPIO port 405, or both.
Block 1004: The mobile device transmits the permission to the SUS.
Block 1005: The SUS receives the permission from the mobile device.
Block 1006: The SUS searches for a connected external memory device in the USB port 406 or the GPIO port 405, or both.
Block 1007: After detecting the connected external memory device (e.g., a USB key), the processor chip 401 initiates downloading data from the external memory device and stores the downloaded data into its memory 404.
Block 1008: In the example embodiment in which the downloaded data is software upgrade, the processor chip uses the downloaded data to upgrade the software of the SUS.
Block 1009 and block 1010: The SUS and the mobile device end the session.
Block 1011: After detecting the session has ended, the SUS ends or closes the data connection with the external memory device. For example, the external memory device is unmounted or ejected from the SUS software system.
In an alternative example, the data connection with the external memory device is closed or stopped before the secure session is ended.
In another example embodiment, the mobile device 201 has the data file for the software upgrade stored in its memory. During the secure session, the mobile device transmits an encrypted data file to the SUS over NFC. The SUS then decrypts the data file and uses it to upgrade the software. In this way, the field technician does not need to carry a USB key to upgrade the software of the SUS.
Turning to
At
In an example embodiment, after authentication is successful, the GUI of the user agent displays the GUI of
The mobile device obtains data about SUS switch #1 and displays the data in
The changes are implemented by transmitting the selected settings for the locked and unlocked data ports from the user device to the SUS switch #1 using NFC 24 communication.
By selecting a “Other” control, more options are displayed in the GUI of
In
The lock/unlock port control, which, after being selected, will display the GUI of
The view log control, after being selected, will display a history log of the SUS switch #1. For example, the history log is obtained from the history log 622 on the SUS memory 404. The history log GUI is shown in
The upload firmware control, after being selected, provides permission for an external memory device (e.g., USB key) to data connect to the SUS via its USB port (or GPIO port), and to upload the firmware from the external memory device onto the SUS. Alternatively, the mobile device transmits the firmware data to the SUS over NFC.
The firmware upgrade control, after being selected, shows the available firmware updates on the SUS to be used for upgrading the SUS. This is shown in
The upload log profile control, after being selected, transmits a log profile to the SUS over NFC communication. It will be appreciated that the SUS transmits the log profile or portions thereof, for example, along with diagnostic and history log data to the network administrator computer.
Returning back to
In other example embodiments, the NFC module 402 of the SUS is used to initiate other functions.
In an example embodiment, the SUS comprises a NFC module and a Bluetooth™ module, and the user device (e.g., of the field technician) also includes a NFC module and a Bluetooth™ module. The user device and the SUS communicate over NFC to initially establish that the user device is a trusted device. After the SUS confirms that the user device is a trusted device by communicating over NFC, the SUS opens a data communication session with the user device over Bluetooth™. Using Bluetooth™, the SUS transmits data files to the user device. For example, these data files are logging data files of the SUS operation (e.g.,, operation details of the data ports), which may be real-time data or historical data, or both.
In another example embodiment, there are different categories of field technicians. A first set of field technicians has a first level of access to controlling a SUS, and a second set of field technicians has a second level of access to controlling the SUS. The levels of access are codified in the field technicians' user devices. In other words, a field technician with a first level of access will be able to use their user device to interact with the NFC module of the SUS, and the SUS will determine a first set of control operations that is permitted when interacting with the user device over NFC. A field technician with a second level of access will be able to use their user device to interact with the NFC module of the SUS, and the SUS will determine a second set of control operations that is permitted when interacting with the user device over NFC. In an example aspect, the first set of control operations, which corresponds to the first level of access, includes a greater number of control operations compared to the second set of control operations, which corresponds to the second level of access. In other words, different privileges or control access to the SUS can be determined over NFC communication.
In another example embodiment, the user device communicates with the SUS, over NFC, to initiate a detection diagnostic on the Ethernet cables to determine if a data port is shorted, or open, or to detect the distance from the SUS to a faulty device.
For example, an end device is expected to be plugged into an Ethernet cable at a first end, and the second end is connected to the SUS via a data port. However, if the first end of the Ethernet cable is not plugged into the end device, the SUS will detect that the cable is open at the actual span of the cable. Otherwise, if the first end of the Ethernet cable is plugged into the end device, it will not be detected as open. This detection will work whether the end device is powered or not.
In another example aspect, the user device can transmit a command to the SUS, via NFC, to run channel quality diagnostic checks.
Below are example embodiments of a secure unmanaged switch.
In an example embodiment, a secure unmanaged Ethernet switch comprises: a processor chip, a close proximity wireless communication module, a trusted platform module (TPM) chip, a memory device, a multi-port Ethernet switch, and a plurality of data ports;
In an example aspect, the close proximity wireless communication module is a Near Field Communication module.
In another example aspect, the TPM chip stores security keys for establishing a secure communication session via the close proximity wireless communication module.
In another example aspect, the secure unamanged Ethernet switch further comprises a list of one or more locked data ports, which are a subset of the plurality of data ports; and wherein each of the one or more locked data ports is respectively configured to only communicate with a specified media access control (MAC) address or is respectively configured to prohibit all communication.
In an example aspect, the list is stored on the muti-port Ethernet switch in a Content Addressable Memory. In a further example aspect, the Content Addressable Memory is at least one of: a static MAC table, a dynamic MAC table, an Access Control List, and a Policy Control List.
In another example aspect, the close proximity wireless communication module is configured to receive a command to lock an additional one of the plurality of data ports, and the processor chip processes the command to write to the list on the multi-port Ethernet switch identifying the additional one as an additional locked data port.
In another example aspect, the list is stored in a memory in the multi-port Ethernet switch.
In another example aspect, the multi-port Ethernet switch comprises an Access Control List and a dynamic Media Access Control (MAC) table; and the multi-port Ethernet switch is configured to at least: receive a source MAC address associated with an Ethernet frame via a given data port of the plurality of data ports; compare the source MAC address with a locking rule stored in the Access Control List, the locking rule specifying that the given data port is configured to only communicate with a specified MAC address; and, after determining that the source MAC address matches the specified MAC address, forward the Ethernet frame and the source MAC address to the dynamic MAC table for transmission to a destination address associated with the Ethernet frame.
In another example aspect, the plurality of data ports comprise a plurality of RJ45 data ports and a plurality of single pair Ethernet (SPE) data ports.
In another example aspect, the secure unmanaged Ethernet switch further comprises a plurality of PHY devices that are respectively connected to the plurality of SPE data ports and to the multi-port Ethernet switch.
In another example aspect, the plurality of data ports comprise a plurality of RJ45 data ports. In another example aspect, the plurality of data ports comprise a plurality of fiber optic Ethernet data ports.
In an example embodiment, a secure unmanaged Ethernet switch comprises:
In an example aspect, the processor chip is configured to transmit the rule to the multi-port Ethernet switch.
In another example aspect, the processor chip is configured to receive the rule via the close proximity wireless communication module.
In another example aspect, the secure unmanaged Ethernet switch further comprises a trusted platform module (TPM) chip that is in data communication with the processor chip, and is used to establish a communication session for the close proximity wireless communication module to receive the rule. In another example aspect, the close proximity wireless communication module is a Near Field Communication (NFC) module
In another example aspect, the processor chip is configured to obtain the rule from a non-volatile memory device, and wherein the non-volatile memory device is an electrically erasable programmable memory (EEPROM) that is part of the close proximity wireless communication module. In another example aspect, the close proximity wireless communication module is a Near Field Communication (NFC) module
In an example embodiment, a secure unmanaged Ethernet switch comprises:
In an example embodiment, a secure unmanaged Ethernet switch comprises:
In an example aspect, the Near Field Communication module is configured to receive a command to lock an additional one of the plurality of data ports, and the processor chip processes the command to write to the list on the multi-port Ethernet switch identifying the additional one as an additional locked data port.
In an example aspect, the Near Field Communication module is configured to receive a command to unlock a given one of the one or more locked data ports, and the processor chip processes the command to remove the given one from the list stored on the multi-port Ethernet switch.
It will be appreciated that, using an app on the user device, the field technician can lock and unlock a given data port in secure unmanaged switch, and these changes to locking and unlocking are communicated from the user device to the secure unmanaged switch via NFC.
In an example aspect, the secure unmanaged Ethernet switch further comprises a power over data line control module to transmit power via a power coupling to a given data port of the plurality of data ports; the power coupling is electrically coupled to the given data port, the power over data line control module, and a PHY device; the PHY device is data connected to the multi-port Ethernet switch; and the processor chip transmits commands to the power over data line control module.
In an example aspect, the secure unmanaged Ethernet switch further comprising a Bluetooth module; wherein the Near Field Communication Module is configured to complete an authorization check with a user device; and, after completing the authorization check, the processor chip is configured to enable the Bluetooth module to communicate with the user device.
It will be appreciated that any module or component exemplified herein that executes instructions may include or otherwise have access to non-transitory computer readable media such as storage media, computer storage media, or data storage devices (removable and/or non-removable) such as, for example, memory chips, magnetic disks, optical disks. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, code, processor executable instructions, data structures, program modules, or other data. Examples of computer storage media include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), read-only memory (ROM), solid-state ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, or any other medium which can be used to store the desired information and which can be accessed by an application, module, or both. Any such computer storage media may be part of the servers or computing devices, or accessible or connectable thereto. Any application or module herein described may be implemented using computer readable/executable instructions that may be stored or otherwise held by such computer readable media.
It will be appreciated that different features of the example embodiments of the system and methods, as described herein, may be combined with each other in different ways. In other words, different devices, modules, operations, functionality and components may be used together according to other example embodiments, although not specifically stated.
The steps or operations in the flow diagrams described herein are just for example. There may be many variations to these steps or operations according to the principles described herein. For instance, the steps may be performed in a differing order, or steps may be added, deleted, or modified.
The elements and screenshots of the GUIs shown herein are just for example. There may be many variations to these GUI elements or operations according to the principles described herein. For instance, the GUI elements and operations may be performed in a differing order, or GUI elements or operations may be added, deleted, or modified.
It will also be appreciated that the examples and corresponding system diagrams used herein are for illustrative purposes only. Different configurations and terminology can be used without departing from the principles expressed herein. For instance, components and modules can be added, deleted, modified, or arranged with differing connections without departing from these principles.
Although the above has been described with reference to certain specific embodiments, various modifications thereof will be apparent to those skilled in the art without departing from the scope of the claims appended hereto.
This patent application claims priority to U.S. Patent Application No. 63/298,616 filed on Jan. 11, 2022, and titled “Secure Unmanaged Network Switch And Related Methods”, the entire contents of which are herein incorporated by reference.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/CA2023/050022 | 1/10/2023 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 63298616 | Jan 2022 | US |
