WO2023172419A1

WO2023172419A1 - Multi-domain secure kvm switch

Info

Publication number: WO2023172419A1
Application number: PCT/US2023/014253
Authority: WO
Inventors: Mark A. Nicolas; Albert Cohen
Original assignee: Vertiv It Systems, Inc.
Priority date: 2022-03-07
Filing date: 2023-03-01
Publication date: 2023-09-14

Abstract

In some embodiments, apparatuses, systems, and methods are provided herein useful to secure data flow. In some embodiments, there is provided a system for a secure data flow comprising: a main controlling unit (MCU) configured to: receive data from one or more peripheral devices via an input port; a processor configured to: receive a first output data from the MCU; encode the first output data with a first key; and output a second output data corresponding to the encoded first output data; and one or more target processing units (TPUs) each coupled to the processor and a corresponding output port, wherein a corresponding TPU of the one or more TPUs having a second key that is paired with the first key is configured to: decode the second output data with the second key; and transmit the decoded second output data via the corresponding output port.

Description

MULTI-DOMAIN SECURE KVM SWITCH

Technical Field

[0001] This invention relates generally to a secure data communication between peripheral devices and computers.

Background

[0002] Generally, a conventional KVM switch is used when a user wants to share one set of peripheral devices (for example, keyboard and mouse or pointing device) and monitors with multiple computers. However, if one of the computers attached to the conventional KVM switch is compromised, all computers attached to the conventional KVM switch are at risk of unauthorized data access.

Brief Description of the Drawings

[0003] Disclosed herein are embodiments of systems, apparatuses and methods pertaining to a secure data flow from a peripheral device to a computer. This description includes drawings, wherein:

[0004] FIG. 1 illustrates a simplified block diagram of an exemplary system for a secure data flow in accordance with some embodiments;

[0005] FIG. 2 shows a flow diagram of an exemplary process of a secure data flow in accordance with some embodiments;

[0006] FIG. 3 illustrates a simplified block diagram of an exemplary system for a secure data flow in accordance with some embodiments; and

[0007] FIGS. 4A-4C show a flow diagram of an exemplary process of a secure data flow in accordance with some embodiments.

[0008] Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well- understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. Certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. The terms and expressions used herein have the ordinary technical meaning as is accorded to such terms and expressions by persons skilled in the technical field as set forth above except where different specific meanings have otherwise been set forth herein.

Detailed Description

[0009] Generally speaking, pursuant to various embodiments, systems, apparatuses and methods are provided herein useful for a secure data flow. In some embodiments, a system for a secure data flow from a peripheral device to a computer includes a main controlling unit (MCU) coupled to an input port, the MCU configured to: receive data from one or more peripheral devices via the input port; a processor coupled to the MCU, the processor configured to: receive a first output data from the MCU; encode the first output data with a first key; and output a second output data corresponding to the encoded first output data; and one or more target processing units (TPUs) each coupled to the processor and a corresponding output port, wherein a corresponding TPU of the one or more TPUs having a second key that is paired with the first key is configured to: decode the second output data with the second key; and transmit the decoded second output data via the corresponding output port.

[0010] Aspects and advantages of the present disclosure will be set forth in part in the following description, or may be obvious from the description, or may be learned through practice of the present disclosure. For example, one or more of advantages in the systems, apparatuses, and methods described herein include the following: ensuring that there are no data leaks when switching between computers with different classification levels or security authorizations; allowing use of single keyboard and mouse with multiple computers; anti-tamper features that ensure no one can access the data going through the system and apparatuses described herein; maximizing security surrounding the coupled computers; protection against remote update firmware; and disabling the use of a hacker device such as keyboard emulator and USB flash drive, to name a few. [0011] FIG. 1 illustrates a simplified block diagram of an exemplary system 100 for a secure data flow in accordance with some embodiments. The system includes a processor 102 coupled to a main controlling unit (MCU) 104 and one or more target processing units (TPUs) 106. In some embodiments, the MCU 104 is coupled to an input port 108. In some embodiments, an input port 108 includes a USB-A connector and/or any connectors capable of interfacing between one device to another device. In some embodiments, the MCU 104 manages one or more peripheral devices 110. For example, the MCU 104 may receive data from one or more peripheral devices 110 via one or more input ports 108. In an illustrative non-limiting example, the MCU 104 may be connected to a USB controller that connects to two USB ports 108. One of the two USB ports 108 may be connected to one of a keyboard and a mouse. In some embodiments, the MCU 104 periodically scans and verifies that the processor 102 and the TPUs 106 are each running the correct firmware. By one approach, if the firmware of the processor 102 and/or any port processor does not match the correct firmware, the system 100 may enter into a tamper mode to prevent any data from moving through the system 100. In some embodiments, the MCU 104 is flashed with an external read only memory (ROM) to prevent any unwanted and/or unauthorized firmware update. In some embodiments, the MCU 104 may monitor one or more keyboards to ensure keystrokes are from an actual human typing and not from an automated device (for example, keylogger) by, for example, monitoring the timing between keystrokes. For example, typing from an automated system, such as keylogger, could be faster than a human could type. In another example, the time between keystrokes may be too systematic, such that the timing difference between keystrokes is substantially the same.

[0012] Continuing on with FIG. 1, the processor 102 may receive a first output data from the MCU 104 and encode the first output data with a first key. In some embodiments, the processor 102 may store and/or access a memory device to obtain data corresponding to one or more keys. Each of the one or more of keys corresponds to a respective TPU 106. As such, the MCU 104 encodes the first output data with a key that corresponds to the target TPU and/or the TPU that is coupled to the computer 114 that a user intends the corresponding peripheral device 110 to couple to. In some embodiments, the processor 102 outputs a second output data corresponding to the encoded first output data. [0013] In some embodiments, all data that travels between the input port 108 and the corresponding output port 112 goes through the processor 102. The processor 102 may be programmed to parse every bit of data that the processor 102 receives to ensure that nothing that is unauthorized will reach one of computers 114 coupled to the one or more TPUs 106. In an illustrative non-limiting example, USB keyboards and/or mice may correspond to the USB HID (Human Interface Device) specification. By one approach, the USB HID specification defines values for the keys on a 104-keyboard and/or a 5-button wheel mouse. In some embodiments, the processor 102 may be programmed based on at least the USB HID specification to determine that the data the processor 102 receives conform to either an HID keyboard or HID mouse to allow the data to pass through the system 100 and/or the processor 102. In some embodiments, data corresponding to an unauthorized attempt to access one of the computers 114 is deleted. In some embodiments, the parsing of data by the processor 102 enables a secure bidirectional communication between peripherals 110 (e.g., keyboard, mouse, and monitor) and a computer 114. In some embodiments, data communications between peripherals 110 and computers 114 are unidirectional. In an illustrative non-limiting example, the system 100 (for example, a secure KVM switch as described herein) may be configured to only allow a keyboard data and/or a mouse data to flow from a peripheral 100 to a computer 114. In some embodiments, the data may conform to a HID keyboard and/or a HID mouse. In some embodiments, the processor 102 includes a Field Programmable Gate Array (FPGA), a SOC (System on Chip), an Advanced RISC Machine (ARM) with powerful internal coprocessor for quick calculation, and/or an Application Specific Integrated Circuit (ASIC) with preprogrammed logic.

[0014] Continuing on with FIG. 1, each of the one or more TPUs 106 may be coupled to the processor 102 and a corresponding output port 112. A corresponding TPU 106 of the one or more TPUs 106 having a second key that is paired with the first key decodes the second output data with the second key. For example, the processor 102 may output the second output data corresponding to the encoded first output data to the corresponding TPU 106.

[0015] In some embodiments, the first output data from the MCU 104 includes a header. The header may include data bits corresponding to the computer 114 to which the first output data is intended to be sent and/or may include data bits corresponding to encoder bits. In some embodiments, the encoder bits are particular to a specific TPU 106 and/or a specific computer 114. In some embodiments, the encoder bits corresponds to a unique identifier of a particular TPU 106 and/or a particular computer 114. In some embodiments, the processor 102 parses through the received first output data and scrambles the data with a first key based in part on the encoder bits in the header. In some embodiments, the first key corresponds to the encoder bits. For example, a TPU 106 receiving the second output data from the processor 102 may decode the second output data using a second key. In some embodiments, the second key is stored in a memory 116 separate from the TPU 106 to protect from an unwanted and/or unauthorized firmware update. In some embodiments, each TPU 106 is coupled to a corresponding memory 116. In an illustrative nonlimiting example, each TPU 106 may be coupled to a respective memory 116. For example, only the intended TPU 106 may have access to the respective memory 116 to access a key stored in the respective memory 116 that enables the intended TPU 106 to decode the second output data. Other TPUs are not able to decode the second output data because these TPUs do not have access to the key to decode the second output data. As a result, these TPUs may delete the second output data and/or wait for the next data set to receive. In another illustrative non-limiting example, if the receiving TPU 106 is the intended TPU, the second output data may be decoded with the second key 116 associated with the receiving TPU 106 and the decoded second output data is transmitted to the corresponding computer 114 coupled to the receiving TPU 106. In some embodiments, if the receiving TPU 106 is not the intended TPU, the system 100 shuts down and/or the processor 102 prevents any data from passing through the system 100. In some embodiments, the system 100 and/or the processor 102 sends a message to a user indicating that the system 100 has been compromised and/or that there is a system breach. As such, each TPU 106 may provide an interface to a respective computer 114 via a corresponding output port 112. Data communications between the MCU 104 and each TPU 106 are encoded with a unique corresponding encoding key to ensure only the selected TPU 106 or the intended TPU 106 can decode the data from the MCU 104. In some embodiments, an output port 112 includes a USB-B connector and/or any connectors capable of interfacing between one device to another device.

[0016] In some embodiments, video data flows from a computer 114 to a peripheral device 110, such as a display monitor not shown in FIG. 1. For example, the video data may conform to EDID and/or video protocol, such as High-Definition Multimedia Interface (HDMI), Display Port (DP), etc., to name a few. [0017] Turning to FIG. 2, FIG. 2 shows a flow diagram of an exemplary process/method 200 of a secure data flow in accordance with some embodiments. In some embodiments, one or more elements in the system 100 of FIG. 1 perform and/or execute one or more steps in the method 200. The method 200 at step 202 may include coupling a USB computer with a TPU via USB. In some embodiments, data from a computer 114 are attached to a TPU 106 via port 112. The method 200 at step 204 may include coupling USB keyboard and/or mouse devices with an MCU via USB. In some embodiments, the one or more peripheral devices 110 (for example, a keyboard and a mouse devices) are attached to the MCU 104 via the input port 108. The method 200 at step 206 may include decoding, by each TPU, communications from the processor 102 using its own key. In an illustrative non-limiting example, a TPU 106 may not receive data directly from a MCU 104. Instead, data destined for the TPU 106 may be parsed by the processor 102 prior to the TPU 106 receiving the data. In some embodiments, each TPU 106 has its own key used to decode communications from the processor 102. The key may be read from an external device (Key #l..Key #N), for example, the memory 116, to allow each TPU 106 to run the same code and/or firmware and/or software code while preventing a TPU from communicating with other TPUs 106. The method 200 at step 208 may include, when the MCU receives USB keyboard and mouse data, decoding, by the MCU, the USB data; serializing the decoded USB data, and/or sending the serialized data to a processor. In some embodiments, the MCU 104 receives data from one or more peripheral devices 110 (for example, keyboard and mouse data by a user pressing/releasing keyboard keys or moving or clicking the button on the mouse). The MCU 104 may then decode the received data, serialize the decoded data, and send the serialized data to the processor 102 (for example, an FPGA processor).

[0018] The method 200 at step 210 may include validating, by processor 102, whether the serialized data is a valid keyboard and/or mouse data. In some embodiments, the processor 102 determines and/or validates that the serialized data is a valid data from one or more peripheral devices 110. In some embodiments, invalid data are deleted by processor 102 and the system 100 may enter into a tamper mode to prevent any data from moving through the system 100. In some embodiments, multiple invalid data attempts may lock the system 100 which may require a special manufacturer’s override code to unlock. Valid data may be encoded with the key that corresponds to the selected TPU 106 and sent to the selected TPU by processor 102 at step 212 of method 200. The method 200 at step 214 may include transmitting, by the selected TPU 106, the keyboard/mouse data to a corresponding computer 114. For example, the selected TPU 106 may receive the encoded data. Only the intended TPU 106 is able to decode the data from the one or more peripheral devices 110 using the intended TPU’s 106 own key 116 ensuring that even if data was misrouted to the wrong TPU, only the selected/intended TPU 106 can decode the data. If the decoded data are valid, the TPU 106 may transmit the data from the one or more peripheral devices 110 to the computer 114.

[0019] In an illustrative non-limiting example, USB protocol by nature is bi-directional. It is a host/device interface where the host controls the interface and asks a device for its data. For example, the computer 114 may be the host and the TPU 106 may be the device. Alternately or in addition to, the MCU 104 may be the host and the peripheral device/s 110 (for example, keyboard/mouse) are the device. In such examples, each of these interfaces may be bi-directional. However, the present disclosures described herein enforce unidirectional data flow from a peripheral device 110 to a computer 114 via the processor 102. For example, an enabling and/or a disabling signal associated with keyboard lock indicators, such as CAP, NUM, or SCROLL lock, from the computer 114 to a keyboard may not be turned on and/or allowed to pass through by the processor 102. For example, the processor 102 may parse through the data received from the TPU 106 and determine that the data are one of those data not allowed to be transmitted to peripheral devices 110. As such, in some embodiments, the processor 102 may enforce a unidirectional data flow on interfaces that are bi-directional by nature.

[0020] Turning to FIG. 3, FIG. 3 illustrates a simplified block diagram of an exemplary system 300 for a secure analog audio data flow in accordance with some embodiments. The system 300 includes a first processor 302. In some embodiments, the first processor 302 includes an FPGA multiplexer (MUX) and encoder with channel identifier bits. In some embodiments, the first processor 302 includes an FPGA, a SOC (System on Chip), an ARM with powerful internal coprocessor for quick calculation, or an ASIC with preprogrammed logic. The system 300 may include a second processor 304. In some embodiments, the second processor 304 includes an FPGA decoder with selected channel identified. In some embodiments, the second processor 304 includes an FPGA, a SOC (System on Chip), an ARM with powerful internal coprocessor for quick calculation, or an ASIC with preprogrammed logic. [0021] In some embodiments, the system 300 may include I²S decoder/Digital-to- Analog Converter (DAC), and one or more Analog to Digital Converter (ADC) Codec I²S. In an illustrative non-limiting example, an analog audio output of a computer 310 may be coupled to an ADC (Analog to Digital Converter) Codec I²S 308. In some embodiments, the coupling may be via an audio cable (for example, 3.5mm audio cable and/or any cable capable of coupling audio output from a computer to an ADC Codec I²S 308). The computer 310 analog audio output may send an analog audio signal to an ADC Codec I²S 308 to encode the analog audio to digital codec that physically limits data to audio bandwidth signal. In an illustrative non-limiting example, the computer 310 analog audio output may be coupled to an off-the-shelf ADC chip (ADC Codec I²S 308) that converts analog audio to I2S (Inter-IC Sound), which is an electrical serial bus interface standard used for connecting digital audio devices. In some embodiments, the digital audio data is sent to the first processor 302. The first processor 302 may validate the digital audio data as audio data. In an illustrative non-limiting example, the ADC Codec I²S 308 may support a number of audio types, sampling frequency, and/or data bitrate. In some embodiments, the system 300 operates at a single, specific audio sampling rate or frequency. The first processor 302 may determine that the I2S data output from the ADC Codec I²S 308 conforms to the expected audio type and/or sampling rate prior to outputting data to the second processor 304. In some embodiments, the first processor 302 deletes invalid data that do not conform to the expected audio type and/or sampling rate. Valid data may be encoded internally by the first processor 302 using a non-conventional I²S data stream and sent to the second processor 304. In an illustrative nonlimiting example, the first processor 302 may encode data by selecting a channel and/or adding a channel identifier to the I2S data packet received from the ADC Codec I²S 308 and generate a new data packet different from the 12 S data packet.

[0022] In some embodiments, the second processor 304 decodes the non-conventional I²S data stream to ensure that only properly encoded audio data (for example, FPGA-encoded audio data) is valid. In an illustrative non-limiting example, the second processor 304 may determine the selected channel and only decode data from that channel. In some embodiments, if the data received by the second processor 304 is determined to be not encoded using an expected channel identifier, the second processor 304 may determine the data to be invalid and deleted by the second processor 304. As a result, the second processor 304 may determine that the system 300 has been tampered with or compromised. Alternatively, or in addition, the second processor 304 may decode valid data to standard I2S data and sent to the I2S Audio DAC 306. In some embodiments, all other data that are not determined to be valid may be deleted and the system 300 may enter into a tamper mode to prevent any data from moving through the system 300. In some embodiments, valid data (for example, FPGA-decoded data) is decoded to standard I2S data then sent to the I²S Audio DAC (Digital-to-Analog Converter) 306 to be converted from I2S to analog audio. The analog signal may then be sent to an output connector on a speaker 312. An advantage to the above embodiments is that encoded digitized audio may prevent reverse audio because the audio input is connected to an encoder and the audio output is a decoder only. In some embodiments, the I2S Audio DAC 306 may include off the shelf electronic component (e.g., off the shelf DAC) to convert I2S to analog audio direct line level compatible with any analog speaker and/or headset

[0023] Another advantages and/or beneficial features of the above one or more embodiments include an audio setup function that permits only an admin to allow/disallow analog audio. To disable analog audio, the system 300 simply does not select a computer audio channel. When audio is disabled, the speaker is not connected to anything, thus no audio will pass.

[0024] In some embodiments, displays or display monitors/devices communicate with computers with two different channels: video channel and data channel. In an illustrative nonlimiting example, the video channel may be unidirectional from the computer to the display and includes video information only. In some embodiments, the data channel is bidirectional and includes all communications between video source, such as personal computer (PC), and the display. In such embodiments, this communication may include all information about the display’s capabilities such as data type, resolutions, or audio. In some embodiments, the PC uses this information to choose the correct video drivers. In such embodiments, this is the only bidirectional communication between PC and display. In an illustrative non-limiting example, the bidirectional nature of the data channel may pose a security risk; therefore, to secure the PC, the data channel may need to be fully controlled and emulated so there is no direct PC to display communication. As such, for example, EDID emulation may replace direct data channel access with two unidirectional communications as described by one or more embodiments herein.

[0025] Another advantage and/or beneficial feature of the above one or more embodiments is that an admin can disable any EDID (Electronic Display Identification) learning. One of the key elements of a secure KVM system is that it does not allow any computer to read the EDID directly from the display; therefore, separate EDID emulators are programmed for each computer based on the peripheral display’s EDID. FIGS. 4A-4C illustrate how a secure KVM system 400 reads EDID data from the peripheral display immediately following power on, parses the EDID data, and builds new EDID data packets to emulate to the connected computers. By parsing the EDID data, the system allows the administrator to enable or disable certain elements from the EDID. For example, the administrator can disable digital audio by simply removing all audio formats from the EDID packet so the computer will not utilize digital audio or limit audio volume by adjusting the audio format data in the EDID packet. In some illustrative non-limiting examples, an administrator can also limit resolution and/or set a single resolution and/or set screen intensity, color, and/or other video configuration parameters available in the EDID packet. In such embodiments, these limits can be applied to all computers or different parameters to different computers.

[0026] Those skilled in the art will recognize that a wide variety of other modifications, alterations, and combinations can also be made with respect to the above described embodiments without departing from the scope of the invention, and that such modifications, alterations, and combinations are to be viewed as being within the ambit of the inventive concept.

Claims

CLAIMS What is claimed is:

1. A system for a secure data flow from a peripheral device to a computer comprising: a main controlling unit (MCU) coupled to an input port, the MCU configured to: receive data from one or more peripheral devices via the input port; a processor coupled to the MCU, the processor configured to: receive a first output data from the MCU; encode the first output data with a first key; and output a second output data corresponding to the encoded first output data; and one or more target processing units (TPUs) each coupled to the processor and a corresponding output port, wherein a corresponding TPU of the one or more TPUs having a second key that is paired with the first key is configured to: decode the second output data with the second key; and transmit the decoded second output data via the corresponding output port.

2. The system of claim 1, wherein the one or more peripheral devices comprise at least one of: a USB controller, a USB port, a keyboard, a mouse, and a display.

3. The system of claim 1, wherein the MCU is further configured to verify that the processor and the one or more TPUs are each running respective firmware.

4. The system of claim 1, wherein the MCU is further configured to flash a memory to prevent unauthorized firmware update.

5. The system of claim 1, wherein the MCU is further configured to monitor one or more activities associated with the one or more peripheral devices.

6. The system of claim 5, wherein the one or more activities comprise keystrokes.

7. The system of claim 1, wherein the first output data comprises the first key associated with the corresponding TPU.

8. The system of claim 1, further comprising a respective memory coupled to the corresponding TPU, wherein the respective memory is configured to store the second key accessible by the corresponding TPU.

9. The system of claim 8, wherein the second key is not accessible to other TPUs of the one or more TPU.

10. The system of claim 1, wherein data flow from the one or more peripheral devices to the one or more TPUs is unidirectional controlled by the processor.

11. A method for a secure data flow from a peripheral device to a computer comprising: receiving, at a main controlling unit (MCU) coupled to an input port, data from one or more peripheral devices via the input port; receiving, at a processor coupled to the MCU, a first output data from the MCU; encoding, by the processor, the first output data with a first key; outputting, by the processor, a second output data corresponding to the encoded first output data; decoding, by a corresponding TPU of one or more target processing units (TPUs) having a second key that is paired with the first key, the second output data with the second key, wherein the one or more TPUs each coupled to the processor and a corresponding output port; and transmitting, by the corresponding TPU, the decoded second output data via the corresponding output port.

12. The method of claim 11, wherein the one or more peripheral devices comprise at least one of: a USB controller, a USB port, a keyboard, a mouse, and a display.

13. The method of claim 11, further comprising verifying, by the MCU, that the processor and the one or more TPUs are each running respective firmware.

14. The method of claim 11, further comprising flashing, by the MCU, a memory to prevent unauthorized firmware update.

15. The method of claim 11, further comprising monitoring, by the MCU, one or more activities associated with the one or more peripheral devices.

16. The method of claim 15, wherein the one or more activities comprise keystrokes.

17. The method of claim 11 , wherein the first output data comprises the first key associated with the corresponding TPU.

18. The method of claim 11, further comprising storing, by a respective memory coupled to the corresponding TPU, the second key accessible by the corresponding TPU.

19. The method of claim 18, wherein the second key is not accessible to other TPUs of the one or more TPU.

20. The method of claim 11, further comprising controlling, by the processor, data flow to be unidirectional from the one or more peripheral devices to the one or more TPUs.