WO2016111667A1 - Authentification de dispositif dans la couche de liaison avant l'ouverture d'une connexion de données - Google Patents

Authentification de dispositif dans la couche de liaison avant l'ouverture d'une connexion de données Download PDF

Info

Publication number
WO2016111667A1
WO2016111667A1 PCT/US2015/000504 US2015000504W WO2016111667A1 WO 2016111667 A1 WO2016111667 A1 WO 2016111667A1 US 2015000504 W US2015000504 W US 2015000504W WO 2016111667 A1 WO2016111667 A1 WO 2016111667A1
Authority
WO
WIPO (PCT)
Prior art keywords
credential
phy
communication port
authentication process
programmed
Prior art date
Application number
PCT/US2015/000504
Other languages
English (en)
Inventor
Zuo HUANG
Feng Chen
Xinyu Hu
Original Assignee
Intel Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corporation filed Critical Intel Corporation
Publication of WO2016111667A1 publication Critical patent/WO2016111667A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/162—Implementing security features at a particular protocol layer at the data link layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/323—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the physical layer [OSI layer 1]

Definitions

  • Related fields include network security; more particularly, preventing connections between protected devices and unauthorized devices.
  • Security is becoming more and more important in the marketplace for any electronic device that stores or manipulates potentially sensitive or important information.
  • This marketplace includes large servers and mass storage devices; medium-sized client computers, smartphones, and tablets that may connect to the large devices; and smaller interchangeable portable drives and cards that may connect to the medium-sized devices.
  • Many users can no longer assume they always connect their device to an intended partner device, due in part to the advancement of "spoofing" techniques to disguise invasive or otherwise harmful devices as trusted devices.
  • FIG. 1 is a state diagram with illustrations of a connection that uses a handshake procedure.
  • FIG. 2 is a section of a state diagram for a Universal Serial Bus (USB) 3, USB 3.1, or other connection.
  • USB Universal Serial Bus
  • FIGs. 3A-3B illustrate a handshake process that adapts to secured or unsecured partners.
  • FIGs. 4A-4D illustrate examples of securable devices and security functions.
  • FIG. 5 is a flowchart showing embodiments of security functions.
  • FIG. 6 illustrates a device with multiple secure partners.
  • Connection (Interchangeable) a wired or wireless pathway over which at least link-layer signals may be communicated.
  • Data connection A connection allowing operating systems, and applications running on the operating systems, of connected devices to exchange information.
  • a data connection allows OSI abstract layers above the link layer to exchange information.
  • Fully functional data connection Capable of carrying application data and other OS- facilitated information.
  • Handshake Exchange of signals on the link layer of a pair of partnered devices between the initiation and the completion of a connection between them - sometimes called a
  • Partner Connected device; may be master, slave or peer.
  • Physical connection The physical configuration enabling partners to communicate, such as a common cable connecting the partners' communication hardware or, for example in wireless communication, a matching of send and receive frequencies and positioning of the partners within a maximum reception distance limited by the range of the weaker transmitter.
  • Unsecured PHY or device Not equipped with link-layer authentication capability.
  • the handshake process for an extensible Host Controller Interface (XHCI) controller detecting and initializing a Universal Serial Bus (USB) 3.1 connection may include detecting a termination, training a link, detecting a change in the communication port status, and enumeration to discover the properties of hosts and client devices on the network.
  • XHCI Host Controller Interface
  • USB Universal Serial Bus
  • the operating systems and application software of the partner devices may not be involved in the handshake process.
  • the circuits performing link-layer functions on the prospective partner devices take part.
  • some connections have dedicated handshake pins, lines, and circuitry capable of supporting link-layer communications before a full data connection is formed. If the handshake is successful (and, in some cases if other conditions are met), a fully functional data connection is then formed.
  • a PHY may include a transmitter and receiver located on the same component and operating together.
  • a PHY from one device is connected to a PHY from another device by a channel or signal pathway, either wired or wireless.
  • the channel may include two unidirectional differential pairs of wires for a total of four wires.
  • Some PHYs are AC-coupled, with the coupling capacitors associated with the transmitter.
  • a PHY may be a discrete IC, or it may be a macrocell included in an ASIC design.
  • Some PHYs handle low-level protocol and signaling, such as data serialization and deserialization, encoding and decoding, various types of buffers, such as analog buffers elastic buffers, and receiver detection.
  • SATA Serial Advanced Technology Attachment
  • the handshake process offers an opportunity for one (or both) of the devices to authenticate the other before exposing its operating system and data files.
  • the PHYs of the devices may be configured to transmit a credential, or to receive a credential and to compare it with one or more stored credentials accessible to the PHY.
  • a pair of devices establishes a trust connection by confirming the presence of one or more pre-stored credentials during a link-training handshake preceding a connection.
  • the devices may be a controller and a peripheral, or may be peers (e.g., syncing or migrating data from a computer to another computer).
  • the device to be protected acts as a credential-checking device and the device to be authenticated acts as a credential-submitting device. If the correct credential is not submitted on request, the handshake fails and the connection is not completed; the unsuccessful credential-submitting device is effectively "invisible" to the credential-checking device.
  • connection protocols such as USB 3.1 that may not include native security measures.
  • Some embodiments may supplement an existing safeguard that either (1) authenticates the user (whose credentials may have been stolen) rather than the device being used, (2) operates in OS-based software after a fully functional data connection is formed, or (3) establishes, before forming the fully functional data connection, that the physically connected device is a compatible type (e.g., a serial mouse), but does not discriminate between individual units of the type.
  • a compatible type e.g., a serial mouse
  • a number of standard handshake protocols include empty bits or words "reserved" for future capability expansion.
  • Link-layer device authentication would be such a capability expansion. If the authentication functionality could be added wholly in existing reserved space, and there were contingencies for connecting to unsecured but trusted devices, the PHY logic of secured devices could be backward-compatible to interface with unsecured devices, if desired.
  • FIG. 1 is a state diagram with illustrations of a connection that uses a handshake procedure.
  • a generic channel is symbolized by connector 102 with connection pins 104 and connector 1 12 with connection pins 1 14, joined together by pathway 100. Although the various parts are most easily visualized in a wired connection, the generic channel may also represent a wireless connection.
  • Pathway 100 may be completely passive, or may include active elements such as an amplifier, repeater, or sensor.
  • Connecting connector 102 to a mating connector in passive or client device 106 connects pins 104 to device 106's PHY 108. When the other end is not connected, no signal may flow through the channel.
  • connecting connector 1 12 to a mating connector in powered or host device 1 16 connects pins 1 14 to device 1 16's PHY 1 18. When the other end is not connected, in general no signal flows through the channel.
  • the devices' PHYs remain in an idle state 101.
  • PHY 108 and PHY 1 18 make a link-layer connection between device 106 and device 1 16 and their PHYs 108 and 1 18 can begin the handshake procedure.
  • Detection signal 1 10 enables the PHYs to enter a detection state 103 and detect that the physical connection has been made. Having confirmed the presence of the physical connection, PHYs 108 and 1 18 enter an evaluation state 105 to perform the handshake.
  • the handshake procedure determines whether the partners 106 and 1 16 will make a data connection and if so, what kind (e.g., what protocol or what data rate).
  • evaluation state 105 may include link training. If the results of the evaluation are satisfactory, the PHYs 108 and 1 18 enter a data-transfer state 107, in which information from the transfer layer 130 to the application layer 140 may be exchanged between partner devices 106 and 1 16.
  • PHY 108 in the passive or client device 106 would be associated with the term “upstream port,” because from the point of view of device 106 the port faces upstream toward the powered or controlling device.
  • PHY 1 18 in powered or controlling device 1 16 would be associated with the term “downstream port,” because it faces downstream toward the device.
  • This example is similar to USB 3.1, but other protocols that have PHY interfaces and or employ handshakes before fully enabling a connection (e.g., PCE and SATA) may exhibit similar behavior, thus offering similar opportunities to insert an authentication step.
  • the state machine of a given embodiment may have more states or substates before, after, and between the illustrated states and substates, or may have different triggers for the illustrated substates, and still make use of link-layer authentication. Therefore, these variations are still within the scope of the subject matter.
  • FIG. 2 is a section of a state diagram for a Universal Serial Bus (USB 3, USB 3.1 , or other connection.
  • Inactive state 202 persists while there is no connection at any of the OSI layers.
  • the creation of a physical connection triggers state 204, receiver detection.
  • the PHY transmitter sends a signal to detect whether there is a receiver on the other end of the connection.
  • the detection of a receiver triggers state 206, polling.
  • the polling state may have several substates triggered by the remaining steps in the handshake procedure; for example: Substate 216, Polling.LFPS (Low Frequency Periodic Signaling), may be used for initialization and the sharing of power management information.
  • Substate 216 Polling.LFPS (Low Frequency Periodic Signaling)
  • the Polling.LFPS substate may synchronize the operations of the two partners, establish a DC operating point for the PHY, or cause a communication port to identify itself by a Polling.LFPS signature. If one of the communications ports is an upstream port and the other is a downstream port, the two ports may execute different steps during the Polling.LFPS substate. LFPS transmission may continue until the LFPS section of the handshake meets the program criteria of either success or failure.
  • Completion of the Polling.LFPS part of the handshake is the trigger for Poliing.LFPSPIus substate 226.
  • the Poliing.LFPSPIus substate may provide additional confirmation that each of the partners has SuperSpeed Plus capability, as demonstrated by successful SCD2.LFPSPlus handshake.
  • SCD1.LFPS SuperSpeed Plus Capability Declaration type 1
  • a successful SCD2.LFPS handshake triggers the transition to Polling.PortMatch substate 236.
  • the SuperSpeed-ready ports may execute a handshake in LFPS-Based Pulse-width Modulation (LBPM) to announce their capabilities, decode the partner's announcement, and prepare to operate using the highest capability common to them both.
  • LBPM LFPS-Based Pulse-width Modulation
  • each of the ports transmits an initial PHY-Capability LBPM signal representing the port's maximum PHY-Capability to the partner.
  • the port with the higher capability transmits a downward- adjusted PHY-Capability LBPM that matches its partner's initial PHY-Capability LBPM.
  • the partners have agreed on an operating capability.
  • a new authentication substate Polling.PortSecurity 246 is inserted after Polling.PortMatch substate 236.
  • the authentication substate may be inserted between any two suitable substates in the handshake procedure.
  • the partners are synchronized with each other at some point before entering Polling.PortSecurity substate 246.
  • each secured port i.e., each authentication-enabled port announces that it is secured and decodes the partner's response.
  • the credential-submitting port transmits LBPM representing a stored authentication credential.
  • the credential-checking port receives and decodes the credential for comparison with one or more known credentials it has stored.
  • Either or both of the ports may be the credential-submitting port or the credential-checking port, depending on the setup of the system.
  • each of the partners may have independent credentials to submit and may retain independent lists of credentials against which to check a received submission. If each port needs to authenticate the other, they may take turns submitting and checking credentials. If the credential transmitted by the credential-submitting port matches a credential stored on the credential-checking device, the authentication is successful. If there is no match, the authentication fails and, in some embodiments, puts the port into disabled state 296.
  • a successful authentication triggers the next state or substate, which in this illustration is Polling.PortConfig state 256.
  • Polling.PortConfig state 256 follows Polling.PortMatch state 236: If either of the ports needs to be reconfigured to handle the agreed operating capability, it does so. When the reconfiguration is finished (or immediately if no configuration is needed), each of the ports transmits a PHY-Ready LBPM to its partner. When the PHY-Ready LBPMs from both ports match, link training 266 may begin, concluding the Polling state 206. If all of the handshakes in the handshake procedure succeed, this triggers active connection state 208, enabling the transmission of operating-system-dependent data over the connection.
  • USB 3.0 does not include LBPM per se. However, it does include LFPS, which is part of LBPM. Some embodiments involving USB 3.0 may insert the authentication step in the LFPS part of the handshake.
  • FIGs. 3A-3B illustrate a handshake process that adapts to secured or unsecured partners.
  • a secured port may be enabled to communicate with an unsecured port; for instance, to confer backward compatibility.
  • the table of FIG. 3 A shows how the PHY- Capability LBPM signal for a secured port may be tucked into existing reserved space in the unsecured-port signal.
  • Type bits 1 :0 (for protocols putting the least significant bit first) may be identical for secured and unsecured ports.
  • Subtype bits 3:2 may not be affected by the presence or absence of the security signal, but only whether the subtype is 5G or 10G.
  • the secured or unsecured nature of the port is represented in bits 7:4. Historically, these bits have been present, but all set to zero, in unsecured ports. In the illustration, they are all changed to 1, but in various embodiments any four-bit value greater than zero may be used.
  • PHY-Capability LBPM signals are the same length for secured and unsecured ports, a flexibility option exists for a secured port to interact with an unsecured partner port.
  • a logical use case for this flexibility is where a secure device secures other devices for the first time.
  • the secured port connects with the unsecured port, reprograms the identifying bits to reflect security enablement, and passes a credential to the unsecured port for storage. The previously unsecured port is now secured.
  • the flowchart of FIG. 3B illustrates a branched path between the polling substates for embodiments where the secured port may also be enabled to communicate with unsecured ports.
  • the port exits the Polling.PortMatch substate 336, it determines at decision 340 whether or not the final, matched PHY-capability LBPMs include code identifying a secured port— the indication that both ports are secured.
  • the connection may enter the Polling.PortSecurity state 346 to authenticate one or both partners. If the submitted credential(s) do not match the partner's stored credential(s) at decision 350, the failed credential-submitting port enters eSS.Disabled state 396 and, in effect, becomes invisible to the partner with the credential-checking port. However, if one or both of the ports are unsecured, the optional flexibility code skips Polling.PortSecurity 346 and goes directly into Polling.PortConfig 356, the next step for conventional, unsecured connections. For both secured and unsecured partners, if all the polling steps succeed, the partners exchange PHY Ready LBPM signals and begin link training 366, preparing to open a data connection.
  • the flexibility option can allow legacy connections to continue to work after some connections have been secured, or allow a secured partner to initially connect with an unsecured partner (for example, a new device, or an existing device beginning to be used with a secured partner) so that the secured partner may install security capability on the unsecured partner.
  • an unsecured partner for example, a new device, or an existing device beginning to be used with a secured partner
  • a user can access a first secured client device through an unsecured host or vice versa (for example, if the user is traveling, or if the usual host or device is down for maintenance).
  • a user may achieve this by:
  • FIGs. 4A-4D illustrate some examples of securable devices and security functions.
  • FIG. 4A illustrates some of the devices that can be protected by link-layer authentication.
  • Laptop computer 402, desktop computer 404, smartphone 406, and tablet 408 are types of medium-sized devices that may either act as clients or as hosts in partnership with other devices.
  • Flash drive 412, SIM card 414, and SD card 416 are examples of small devices that may need secured interactions with medium-sized devices.
  • FIGs. 4B, 4C, and 4D conceptually illustrate some examples of interactions between pairs of partner devices.
  • the partner devices shown are USB flash drives and a desktop computer tower, any suitable pair of master, slave, controller, peripheral, or peer devices may use the described process or an equivalent when connecting.
  • security on computer 452 has been turned off, putting its ports into unsecured state 456.
  • an authorized user or administrator may unlock computer 452 with a password, or computer 452 may be unlocked by connecting an authorized secure device to trigger access to a screen of special commands.
  • New or otherwise unsecured USB drive 454 is connected to computer 452, which, being in the unlocked state 456, allows the connection.
  • Computer 452 then loads a credential 458 onto USB drive 454.
  • the loading process may use any suitable OSI layer, but the credential will be accessible by the link layer of USB drive 454.
  • USB drive 454 which now carries credential 458, is plugged into the USB port of computer 452. Being in secured state 466, computer 452 executes a link-layer authentication when USB drive 454 is initially connected. Because USB drive 454 now has credential 458 to submit, computer 452 finds a stored match for credential 458. The authentication succeeds, and computer 452 has a positive response 460 and authorizes USB drive 454 to make a full data connection.
  • the user may have an option 461 to remove the credential from USB drive 454 and either leave the drive in an unsecured state or load a different credential onto it.
  • USB drive 464 is plugged in and attempts to connect.
  • USB drive 464 has an unrecognized credential 468 (or, alternatively, no credential at all).
  • unrecognized credential 468 or, alternatively, no credential at all.
  • computer 452 may refuse a data connection to unauthenticated USB drive 464 in different ways.
  • Computer 452 may completely ignore "invisible" USB drive 464, as symbolized by reaction 470.1.
  • USB drive 464 may be blind to the presence of computer 452 after the failed authentication, as symbolized by reaction 470.2.
  • computer 452 may deny USB drive 464 a full data connection and warn the user of what the problem is, e.g., through a displayed error message or alternatively through something as basic as warning light or warning sound.
  • Other equivalent diagnostic user-perceptible indicators may equivalently be used.
  • FIG. 5 is a flowchart showing embodiments of security functions.
  • the process begins with physical connection between partner devices at step 502. First the check covers decision 504 (discovering whether the partner's port is secured). If the partner's port is secured, authentication step 508 follows. If the partner is not secured, some embodiments of the invention may connect for data anyway at step 506 (for instance, if interested user has already authenticated himself or herself to the credential-checking partner device, or if link-layer security is being newly introduced). Alternatively, the credential-checking partner may refuse the connection at step 516 (for instance, in a security-critical environment).
  • the credential-checking device may open an application to secure the unsecured partner device for programming it with a credential (for example, when a new device being introduced to an established secure system).
  • Any of the options 506, 516 or 526 may be accompanied by explanatory messages to the user at step 507, optionally with choices of next action at step 517.
  • the partner devices may complete the handshake procedure and establish a fully functional data connection at step 512.
  • the credential-checking device may refuse to connect to the unauthenticated device at step 514.
  • connection refusal 514 Further behavior of the credential-checking device after connection refusal 514 may vary depending on the embodiment.
  • the credential-checking device may simply ignore the unauthenticated credential-submitting device as if it were invisible at step 536.
  • the credential-checking device may also display an error message at step 546, informing the user that the connection was refused because the authentication failed, and optionally offering instructions or choice of next steps.
  • the credential-checking device may count the number of failed connection attempts by the same unauthenticated device at step 516, and only allow additional attempts at step 556 as long as the number of failed connection attempts is below a threshold value (e.g., 3, 5, or 10).
  • a threshold value e.g. 3, 5, or 10
  • options include transmitting a warning message to the user at step 518, disabling the credential-checking device's transmitter or receiver at step 528 (for example, in a way that they will need to be re-enabled by a manager or system administrator), or deleting all the data from the credential-checking device at step 538 so that no unauthorized user (or anyone else, with the possible exception of a system administrator with access to a secure backup) can access the data.
  • FIG. 6 illustrates a device with multiple secure partners.
  • computer 602 may give all its authorized partner devices 604.1-604.5 the same credential, and optionally use that same credential to authenticate itself to another device, such as a server.
  • computer 602 may be in a secured state 606, and may give all its authorized partner devices 604.1-604.5 credentials 608 that are not identical, but do contain the same sequence 618.
  • computer 602 authenticates credentials that contain sequence 18, treating the other parts as an acceptable margin 628 by which credentials may differ.
  • the marginal parts 628 of the credential 608 that do not affect authentication may identify a particular device, or may identify a "device type" such as a controller or a printer.
  • computer 602 may give a unique credential to each device 04.1-604.5, storing a list or table of all the credentials to compare to those of devices attempting to connect.
  • the authentication portion 618 of credential 608 is sequence "12345.”
  • Computer 602 is configured to represent any credential beginning with “12345” followed by any 2 values (the marginal part 627: "?” is a wildcard for a single character.
  • the credentials of USB drives 604.1 , 604.2, and 604.3 have the required format, so the devices will be allowed to form a data connection with computer 602.
  • USB drives 604.4 and 604.5 do not conform to the " 12345??” format.
  • USB drive 604.4 has the right length, but the beginning sequence is " 12445" instead of " 12345.”
  • USB drive 604.5 has the beginning sequence "12345,” but it is followed by three additional characters instead of two.
  • An alternative embodiment could have computer 602 accept credentials with "12345” followed by any number of characters, in which case USB drive 604.5 would be able to form a data connection with computer 602.
  • Another alternative embodiment could restrict the length of credential but allow the " 12345" sequence to be at the end, in the middle, or at the beginning.
  • Any unauthorized would-be partners of a secured credential-checking device are expected to fail authentication during the handshake process and never be allowed to form a fully functional data connection.
  • the credential-checking device may completely ignore the unauthorized would-be partner, or it may notify the user or a monitoring device that an authentication failed.
  • the credential-checking device's system software e.g., the device driver, the credential-checking device's system software
  • XHCI driver the USB driver
  • the USB driver is never exposed before or during authentication, no potential malware on the credential-submitting device has an opportunity to modify the software stack.
  • the process does not make demands on user skill because the user is not involved.
  • neither the user nor the credential-checking device needs to know anything in advance about the would-be partner.
  • No extra security hardware, such as a dongle, is required to implement the security measure; it is only an additional step in an existing polling stage or other part of a handshake procedure.
  • Example 1 is a communication port comprising logic of a first physical layer (PHY) to execute a handshake procedure with logic of a second PHY before enabling a fully functioning data connection through a physical connection to the second PHY in response to initiation of the physical connection to a receiver of the second PHY in response to initiation of the physical connection; wherein the logic of the first PHY is to cause a transmitter of the first PHY to transmit during the handshake procedure, the information comprising a first code identifying the first PHY as a secured PHY; wherein, if the logic of the second PHY is to cause a transmitter of the second PHY to transmit a second code identifying the second PHY as another secured PHY, the logic of the first PHY and the logic of the second PHY is to perform an authentication process before concluding the handshake procedure; and wherein the logic of the first PHY is to prevent the enabling of the fully functioning data connection in response to a failure of the authentication process.
  • PHY physical layer
  • Example 2 the subject matter of Example 1 can optionally include that if the logic of the first PHY does not cause the transmitter of the first PHY to transmit the first code or the logic of the second PHY does not cause the transmitter of the second PHY to transmit the second code, the handshake procedure proceeds without performing the authentication process, sends a message for an error to be displayed, or initiates an action to delete all data from a first device associated with the first PHY.
  • Example 3 the subject matter of Example 1 can optionally include that if the logic of the first PHY does not cause the transmitter of the first PHY to transmit the first code or the logic of the second PHY does not cause the transmitter of the second PHY to transmit the second code, the handshake is interrupted and the fully functioning data connection is not enabled.
  • the subject matter can optionally include that if the logic of the first PHY is to interrupt the handshake and disable at least one of the transmitter of the first PHY and the receiver of the first PHY in response to the authentication process failing for a threshold number of attempts.
  • Example 5 the subject matter can optionally include that logic of the first PHY is to interrupt the handshake procedure and erases data from a first device in response to the authentication process fails for a threshold number of attempts.
  • the subject matter can optionally include that the logic of the first PHY interrupts the handshake and causes data to be erased from a second device associated with the second PHY in response to the authentication process failing after a threshold number of attempts.
  • the subject matter can optionally include that the fist PHY is capable of removing, disabling, reprogramming, or re- enabling the second code on the second PHY.
  • Example 8 the subject matter can optionally include that during the authentication process, the logic of the first PHY is to: access a known credential and a predetermined margin; read a programmed credential from storage associated with the second PHY; detect whether the programmed credential matches the known credential within a predetermined margin; continue the handshake procedure in response to a match; and interrupt the handshake procedure in response to a mismatch.
  • Example 9 is a system, comprising: a first device having a first communication port; a second device having a second communication port; wherein, in response to a physical connection forming between the first device and the second device, the first device and the second device perform a handshake procedure before fully opening the physical connection for data transfer; the handshake procedure to fail to complete when the first communication port is identified as unsecured or when the second communication port is identified as unsecured; wherein, in response to both the first communication port being identified as secured and the second communication port being identified as secured, the first communication port is to perform an authentication process of at least one of the first device or the second device before concluding the handshake procedure; and wherein in response to failure of the authentication process, the physical connection is not to be fully opened for data transfer; and wherein, in response to success of the authentication process, the physical connection is to be fully opened for data transfer.
  • Example 10 the subject matter can optionally include a protocol of the physical connection comprises Universal Serial Bus.
  • Example 1 1 the subject matter can optionally include that the physical connection is to be formed as a peer-to-peer connection.
  • Example 12 the subject matter can optionally include that the first device comprises a controller to control the second device.
  • Example 13 the subject matter can optionally include that the first communication port is to store a programmed credential; to perform the authentication process, the second communication port is to read the programmed credential and compare the programmed credential, the authentication process to fail if the programmed credential does not match the known credential within a predetermined margin.
  • Example 14 the subject matter can optionally include that the second communication port is to store a programmed credential; to perform the authentication process, the first communication is to read the programmed credential and compare the programmed credential to a known credential; and the authentication process to fail if the programmed credential does not match the known credential within a predetermined margin.
  • each of the first communication port and the second communication port is to store a programmed credential; at least one of the first communication port or the second communication port is to read the programmed credential stored by the other communication port and to compare the programmed credential to a known credential, the authentication process to fail if the programmed credential does not match the known credential within a predetermined margin.
  • Example 16 the subject matter can optionally include that the programmed credential stored by the first communication port is identical to the programmed credential stored by the second communication port.
  • Example 17 is a non-transitory machine-readable information storage medium containing code that, when executed, causes a machine to perform a handshake procedure comprising: to detect a remote receiver through a physical connection that is not fully functional as a data connection; to assess compatibility of a local communication port with a remote communication port associated with the remote receiver; to determine whether both the local communication port and the remote communication port are secured; in response to a determination that both the local communication port and the remote communication port are secured, to perform a device authentication before concluding the handshake procedure; and in response to a failure of the device authentication, to interrupt the handshake procedure before the physical connection becomes fully functional as a data connection.
  • Example 18 the subject matter can optionally include that when executed, causes the machine to perform additional actions comprising: in response to a determination that at least one of the communication ports is unsecured, to complete the handshake procedure without the authentication process and to pass a credential to the remote communication port to secure the remote communication port.
  • Example 19 the subject matter can optionally include that when executed, causes a machine to perform additional actions comprising: in response to a determination that at least one of the communication ports is unsecured, to interrupt the handshake procedure to prevent the physical connection from becoming a fully functional data connection.
  • Example 20 the subject matter can optionally include that, when executed, causes the machine to secure an unsecured remote communication port.
  • Example 21 the subject matter can optionally include that, when executed, causes the machine to enable a fully functional data connection through the physical connection in response to a success of the authentication process.
  • Example 22 the subject matter can optionally include that, when executed, causes the machine to prevent enablement of a fully functional data connection through the physical connection in response to a failure of the authentication process.
  • Example 23 the subject matter can optionally include a data-store comprising at least one known credential; and code that, when executed, causes a machine to compare the at least one known credential to a programmed credential provided by the remote communication port; to identify a successful authentication process by criteria comprising a match between the programmed credential and the at least one known credential; and to identify a failed authentication process by criteria comprising a mismatch between the programmed credential and the at least one known credential.
  • a data-store comprising at least one known credential
  • code that, when executed, causes a machine to compare the at least one known credential to a programmed credential provided by the remote communication port; to identify a successful authentication process by criteria comprising a match between the programmed credential and the at least one known credential; and to identify a failed authentication process by criteria comprising a mismatch between the programmed credential and the at least one known credential.
  • Example 24 the subject matter can optionally include a data-store comprising at least one known credential and a margin definition; and code that, when executed, causes the machine to compare the at least one known credential to a programmed credential provided by the remote communication port while applying the margin definition; to identify a successful authentication process by criteria comprising a match between the programmed credential and the at least one known credential within the margin definition; and to identify a failed authentication process by criteria comprising a mismatch between the programmed credential and the at least one known credential exceeding the margin definition.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Communication Control (AREA)

Abstract

Selon l'invention, les ports de communication d'une paire de dispositifs exécutent une procédure « d'établissement de liaison » après leur connexion physique initiale et avant l'ouverture d'un canal de transfert de données (« connexion de données ») entièrement fonctionnel sur la connexion physique. Une connexion de données n'est pas formée sauf si l'établissement de liaison réussit. La procédure d'établissement de liaison comprend un processus d'authentification de dispositif pour permettre uniquement à des dispositifs partenaires autorisés de former des connexions de données. Les systèmes d'exploitation des dispositifs, et n'importe quel logiciel ou n'importe quelles données qui peuvent uniquement faire l'objet d'un accès par l'intermédiaire de ces derniers, ne peuvent pas intervenir dans l'établissement de liaison ou l'authentification de dispositif en raison du fait que la fonctionnalité d'établissement de liaison et d'authentification de dispositif est séparée, et les systèmes d'exploitation peuvent uniquement interagir après qu'une connexion de données est formée. Beaucoup de logiciels malveillants et beaucoup de fonctions de copie de données dépendent du système d'exploitation. Par conséquent, l'authentification de dispositifs avant de leur permettre de se connecter entièrement est censée ériger la barrière d'entrée pour répandre un logiciel malveillant, voler des données, et d'autres interactions malveillantes ou néfastes.
PCT/US2015/000504 2015-01-06 2015-12-26 Authentification de dispositif dans la couche de liaison avant l'ouverture d'une connexion de données WO2016111667A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201562100082P 2015-01-06 2015-01-06
US62/100,082 2015-01-06

Publications (1)

Publication Number Publication Date
WO2016111667A1 true WO2016111667A1 (fr) 2016-07-14

Family

ID=56356237

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/000504 WO2016111667A1 (fr) 2015-01-06 2015-12-26 Authentification de dispositif dans la couche de liaison avant l'ouverture d'une connexion de données

Country Status (1)

Country Link
WO (1) WO2016111667A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080028225A1 (en) * 2006-07-26 2008-01-31 Toerless Eckert Authorizing physical access-links for secure network connections
US20090217033A1 (en) * 2005-06-29 2009-08-27 Luciana Costa Short Authentication Procedure In Wireless Data Communications Networks
US20140148131A1 (en) * 2009-10-11 2014-05-29 Blackberry Limited Authentication Failure in a Wireless Local Area Network
US20140273833A1 (en) * 2013-03-15 2014-09-18 Gary D. McCormack Physical layer adapted for ehf contactless communication

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090217033A1 (en) * 2005-06-29 2009-08-27 Luciana Costa Short Authentication Procedure In Wireless Data Communications Networks
US20080028225A1 (en) * 2006-07-26 2008-01-31 Toerless Eckert Authorizing physical access-links for secure network connections
US20140148131A1 (en) * 2009-10-11 2014-05-29 Blackberry Limited Authentication Failure in a Wireless Local Area Network
US20140273833A1 (en) * 2013-03-15 2014-09-18 Gary D. McCormack Physical layer adapted for ehf contactless communication

Similar Documents

Publication Publication Date Title
EP2443584B1 (fr) Commande d'accès à distance de dispositifs de mémorisation
US11334510B1 (en) Systems and methods for combination write blocking with connection interface control devices
US7877788B1 (en) Method and apparatus for securing a peripheral data interface
RU2495488C1 (ru) Система и способ контроля устройств и приложений при использовании многофакторной аутентификации
RU2496144C2 (ru) Система контроля доступа и способ управления доступом для системы управления транспортером для перевозки людей
CN101751524B (zh) 一种计算机外接设备管理装置、方法及计算机
KR100881938B1 (ko) 다중 스마트 카드 세션을 관리하는 시스템 및 방법
US20180239727A1 (en) Secure Access to Peripheral Devices Over a Bus
KR102195788B1 (ko) 호스트 컴퓨팅 디바이스와 주변기기의 데이터의 보안을 강화하기 위한 장치 및 방법
US20160373408A1 (en) Usb firewall devices
US20130086695A1 (en) Method and system for remote access to data stored on a host system
US20110016310A1 (en) Secure serial interface with trusted platform module
EP3198518B1 (fr) Prévention d'attaque contre la sécurité par remplacement de câble sur des dispositifs de mémoire
EP3472719B1 (fr) Procédé et appareil permettant de mettre en oeuvre un tunnel de réseau vpn
CN104469736A (zh) 一种数据处理方法、服务器及终端
WO2019130042A1 (fr) Contrôle d'intégrité d'un dispositif périphérique sécurisé
JP2006209762A (ja) プレゼンスベースのアクセスコントロール
AU2020202166B2 (en) Multi-use near field communication front end on a point of sale system
CN101271507B (zh) 一种基于usb设备的文件隐藏的方法、系统及装置
KR101533857B1 (ko) 부정 사용 방지 제어 시스템 및 부정 사용 방지 제어 방법
US8438624B2 (en) Systems and methods of modifying system resources
WO2016111667A1 (fr) Authentification de dispositif dans la couche de liaison avant l'ouverture d'une connexion de données
US20230025979A1 (en) Systems and methods for peripheral device security
KR101382605B1 (ko) 단말기 디버그 시리얼 접속 보안 방법
CN104995635A (zh) 图片发送方法和装置以及终端设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15877233

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15877233

Country of ref document: EP

Kind code of ref document: A1