Patent Grant
RE49012
This application is a reissue of U.S. patent application Ser. No. 13/783,001, filed Mar. 1, 2013, which issued on Sep. 18, 2018 as U.S. Pat. No. 10,078,524.
Embodiments of the disclosure relate to the field of communications, and in particular, to a system, digital device and method that is directed to the configuration of a device on a network.
In recent years, digital communications have spread to ever more digital devices, ranging from remote environmental sensors, appliances, miniature hand-held digital devices (e.g. cameras, dual-mode cellular telephones, etc.) to networking equipment (e.g. controllers, routers, etc.). For instance, digital devices may be connected to a local area network (LAN) through Ethernet adapters for wired network communications, or wireless adapters such as those operating according to the well-known IEEE 802.11a/ac/b/g/n standards. Such connectivity enables information to be communicated with other digital devices directly or indirectly connected to the LAN. Each of these devices must be configured for a particular network before it can operate on that network.
A headless networking device (HD) is a device that lacks a user interface but has a network interface. It can be an industrial device such as a robot. It can be an enterprise device such as a wireless access point, or it can be a home device such as a “smart grid”-enabled water heater.
A device that lacks a user interface has difficulty in obtaining the appropriate credentials and configuration to access or join a secure network. Such a device is typically configured by assuming that it is initially placed on a trusted network and the configuration protocol, therefore, does not need any security. The first device that contacts the HD is able to configure it. It is assumed that the configuration provided to the HD cannot be observed or intercepted by an unauthorized party and that an unauthorized party cannot access the device to provide a different configuration. However, this assumption may often be false. Headless devices can be placed on a medium which cannot be completely trusted. A wireless medium increases the potential for adversaries to observe, interfere or attack the configuration of the HD.
“Wireless Protected Setup (WPS)” from the Wi-Fi Alliance (WFA) is proposed to increase the security of the configuration of a new device on a Wi-Fi network. The device, such as an HD, to be configured has a PIN (Personal Identification Number) or password burned into the device at manufacture. This PIN or password is also written on a label or on documentation accompanying the HD. This PIN or password is then entered into the user interface of a configuring device (CD). The CD and HD perform a handshake proving possession of the PIN or password and the CD can then configure the HD.
Unfortunately, WPS is susceptible to a dictionary attack that attempts to guess the password. It is also susceptible to snooping to detect the password. An adversary might also take the password directly from the label or documentation. Given the PIN or password the adversary can configure, and take control of, the HD. The adversary may also or instead intercept the configuration that the CD provides after the spoofed authentication. The network configuration information allows the adversary the same access to the secured network that the CD is intended to have. This may be more valuable than configuring the HD.
The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the disclosure.
Embodiments of the disclosure relate to a system, a digital device and method for secure configuration of a headless networking device. The objective of secure configuration is to frustrate the interception of the network configuration by an adversary. Another objective is to limit the network to devices that are intended to have access.
Embodiments are described that provide strong authentication of the HD (Headless Device) to the CD (Configuring Device). The authentication ensures that the devices that the CD configures and allows on the network are authentic. As a result, the HD does not need strong authentication of the CD. The HD can accept configuration by any device that proves it has possession of the HD unique credentials. As described herein the CD ensures that only valid devices are configured, and configurable.
Herein, certain terminology is used to describe features for embodiments of the disclosure. For example, the term “digital device” generally refers to any hardware device that includes processing circuitry running at least one process adapted to manage the flow of control traffic into the device. Examples of digital devices include a computer, a tablet, a laptop, a desktop, a netbook, a server, a web server, authentication server, an authentication-authorization-accounting (AAA) server, a Domain Name System (DNS) server, a Dynamic Host Configuration Protocol (DHCP) server, an Internet Protocol (IP) server, a Virtual Private Network (VPN) server, a network policy server, a mainframe, a television, a content receiver, a set-top box, a video gaming console, a television peripheral such as Apple® TV, a printer, a mobile handset, a smartphone, a personal digital assistant “PDA”, a wireless receiver and/or transmitter, an access point, a base station, a communication management device, a router, a switch, and/or a controller. Examples of digital devices also include a sensor, an appliance, a security device, such as a gate, door or window lock, or a physical plant controller such as for a water heater, steam generator, pumping system, or climate control system.
One type of digital device, referred to as a “controller,” is a combination of hardware, software, and/or firmware that is configured to process and/or forward information between digital devices within a network.
It is contemplated that a digital device may include hardware logic such as one or more of the following: (i) processing circuitry; (ii) one or more communication interfaces such as a radio (e.g., component that handles the wireless data transmission/reception) and/or a physical connector to support wired connectivity; and/or (iii) a non-transitory computer-readable storage medium (e.g., a programmable circuit; a semiconductor memory such as a volatile memory such as random access memory “RAM,” or non-volatile memory such as read-only memory, power-backed RAM, flash memory, phase-change memory or the like; a hard disk drive; an optical disc drive; etc.) or any connector for receiving a portable memory device such as a Universal Serial Bus “USB” flash drive, portable hard disk drive, or the like.
Herein, the terms “logic” (or “logic unit”) and process” are generally defined as hardware and/or software. For example, as hardware, logic may include a processor (e.g., a microcontroller, a microprocessor, a CPU core, a programmable gate array, an application specific integrated circuit, etc.), semiconductor memory, combinatorial logic, or the like. As software, logic may be one or more software modules, such as executable code in the form of an executable application, an application programming interface (API), a subroutine, a function, a procedure, an object method/implementation, an applet, a servlet, a routine, source code, object code, a shared library/dynamic load library, or one or more instructions. These software modules may be stored in any type of a suitable non-transitory storage medium, or transitory computer-readable transmission medium (e.g., electrical, optical, acoustical or other form of propagated signals such as carrier waves, infrared signals, or digital signals).
The term “interconnect” is a communication path between two or more digital devices. The communication path may include wired and/or wireless segments. Examples of wired and/or wireless segments include electrical wiring, optical fiber, cable, bus trace, or a wireless channel using infrared, radio frequency (RF), or any other wired/wireless signaling mechanism.
The term “message” is a grouping of data such as a packet, a frame, a stream (e.g., a sequence of packets or frames), an Asynchronous Transfer Mode (ATM) cell, or any other series of bits having a prescribed format. Herein, a message comprises a control payload and a data payload. The control payload is adapted to include control information such as source and destination MAC (Media Access Control) addresses, Internet Protocol (IP) addresses (e.g., IPv4 or IPv6 addressing), protocol, source and destination port information, and/or packet type.
Lastly, the terms “or” and “and/or” as used herein are to be interpreted as inclusive or meaning any one or any combination. Therefore, “A, B or C” or “A, B and/or C” mean “any of the following: A; B; C; A and B; A and C; B and C; A, B and C.” An exception to this definition will occur only when a combination of elements, functions, steps or acts are in some way inherently mutually exclusive.
Certain details are set forth below in order to provide a thorough understanding of various embodiments of the disclosure, albeit the invention may be practiced through many embodiments other that those illustrated. For instance, illustrative embodiments describe configuring a headless device. Such discussions are for illustrative purposes and do not preclude this invention from being conducted on other types of devices and using different encryption and key exchange systems. Also, well-known logic and operations may not be set forth in detail in order to avoid unnecessarily obscuring this description.
I. General Architecture
Referring to
The interface 110 enables the headless device 100 to communicate with other devices supporting wired and/or wireless connectivity. For instance, the interface 110 may be implemented as a wireless adapter (e.g., one or more radios, antenna(s) or the like) adapted to receive ingress messages and/or a wired adapter (e.g. connector) through which ingress messages are received over a wired interconnect. In embodiments, the network interface is a Wi-Fi interface, but the invention is not so limited and other wireless and wired interfaces may be used.
Processing logic 120 is adapted with logic to receive and process ingress packets, and provide any packet processing. The processing logic analyzes ingress packets, interprets any commands or other information, performs any calculations and sends commands to any of the other logic. The processing logic also generates egress packets and provides, for example, (1) destination MAC address, (2) source MAC address, (3) IP (DEST IP) address, (4) source IP (SRC IP) address, (5) protocol, (6) destination port number (DEST PORT), and/or (7) source port number (SRC PORT) for any egress packets as appropriate. The processing logic operates using the received network configuration to receive and send packets to designated nodes on the network through the interface 110.
As further shown in
As further shown in
For a water heater, the sensors may be temperature sensors and the actuator logic may control a heat source. For a thermostat, the sensors may include temperature sensors in different locations as well as humidity, barometric pressure and air particulates or contaminants. The actuator logic may drive heating, cooling, humidifiers, filters, and other device. For a robot, the sensors and actuator logic may correspond to the entire robot. For a wireless access point, there may be no sensors or actuation logic because the device provides only network interfaces and packet processing.
Finally, the headless device has a label 170 with the device's public key on it. The key may be simply printed as numerical, hexadecimal, or alphanumeric text. Alternatively, or in addition, the key may be printed in machine readable form, such a bar code, a QR code, a holographic code, a magnetic code, or a radio code, such as a passive RFID (Radio Frequency Identification) code. The label may be attached to a housing of the device or it may be in separate documentation provided with the device.
In embodiments, a user reads the key from the label and provides it to a configuring device in order to start the authentication of the headless device. Alternatively, the configuring device or a reader attached directly or remotely to the configuring device may read the label. The label may be human or machine-readable or both. The public key on the label 170 may also be stored in the key storage 135.
In the described example, the headless device has no user interface. There is no display and no user input device, no keyboard, mouse, touch screen, touchpad, or other device. However, the invention is not so limited. The headless device as described herein is not required to have no user interface. Some devices, such as a wireless access point or a wired network switch have no user interface and must be configured remotely. In other devices, such as for example a thermostat or a water heater, there may be a display and some type of user interface such as buttons, or a touch screen for controlling the device, however the device must still be configured remotely. Simpler appliances, such as those on a smart grid, a refrigerator, a television set-top box, or a thermostat, may have a user interface, such as a touchscreen, remote control or other interface that allows for network configuration but may still be configured remotely without using the user interface. Still other devices, such as remote computers, handheld smart devices, such as telephones, media players, and tablets may be configured using the user interface. As described herein, each of these devices may be configured without using the user interface. They are headless for purposes of the remote configuration described herein.
Referring to
The interface 210 enables the configuring device 200 to communicate with other devices supporting wired and/or wireless connectivity. For instance, the interface 210 may be implemented as a wireless adapter (e.g., one or more radios, antenna(s) or the like) adapted to receive ingress messages and/or a wired adapter (e.g. connector) through which ingress messages are received over a wired interconnect. In embodiments, the network interface is a Wi-Fi interface, but the invention is not so limited and other wireless and wired interfaces may be used.
Processing logic 220 is adapted with logic to receive and process ingress packets, and provide any packet processing. If the configuring device is a switch, router, or access point, the processing logic may analyzes ingress packets and perform packet processing and routing operations. The processing logic also performs any calculations and drives any operations appropriate for configuring new devices on the network through the interface 210.
As further shown in
As further shown in
Among the nodes, there may be one or more access switches 140 to serve one or more external clients or client ports. Each access switch may include Ethernet ports or a WiFi interface or both. The distribution switch may also be coupled to any of a variety of different client end connections and types, such as trusted or untrusted user data, workstation, and computing terminals 150, wireless access points 151, voice terminals 152, and other devices 153, such as smart displays, appliances, set-top boxes, sensors, and smart grid enabled devices. The end terminals may be connected directly through a single one of the access switches or indirectly through an intermediate switch or access point.
II. Device Configuration
The following description refers to configuring a headless device (HD) using a configuring device (CD). While the described approaches are well-suited to devices that do not have any direct user interface, the HD is only necessarily headless in that no user interface is required for its authentication and configuration. In embodiments, the HD possesses a public/private key pair, based for example on discrete logarithm cryptography. The key pair may be generated at manufacture time for convenience or, if desired, it may be installed later by an administrator or a user.
An identifying label 170 may be attached to or shipped with the HD to allow a user to access the public key. The label may show the public key in plain text or in an encoded or fingerprint form. A bar code, QR code, or other optical or magnetic code may provide the public key on packaging or elsewhere. The public key and its domain parameter set may be affixed to the HD or be part of the documentation or paperwork that accompanies the HD.
At 410, the CD obtains the public key, for example by scanning the QR code, and implicitly trusts it as being the public key of the HD that the CD wishes to configure. The label could be attached to the physical case of the HD or the HD could use another device to display its label, for example, an HD could be a TV set top box that uses a TV to display its label. Alternatively, if the label contains a fingerprint of the HD's public key then the CD obtains the HD's public key in another manner and verifies the fingerprint before trusting it. In either case, the CD obtains the public key and uses the label to provide the trust necessary for subsequent authentication.
At 412, the CD then generates a secret. In one embodiment, the CD derives an ephemeral public/private key pair, such as a Diffie-Hellman public/private key pair, although other anonymous authentication techniques may be used instead. At 414, the CD uses its ephemeral private key and the HD's static public key to generate a shared secret using an ephemeral-static key exchange. An example of such an exchange is described in “Recommendations for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”, by E. Barker, D. Johnson, and M. Smid, National Institute for Standards and Technology, NIST Special Publication 800-56A, March 2007, see especially Section 6.2.2 (hereinafter referred to as “SP 800-56A § 6.2.2”). However, the invention is not so limited.
At 416, a message is sent to the HD. In one embodiment, the CD's ephemeral public key is sent to the HD. As an optimization, in addition to the public key, the CD may also formulate a test word for the HD. As an example, the resulting shared secret derived by the CD may be used to wrap a test word for use in testing the HD. In this example, the test word is wrapped using, for example, an authenticated encryption scheme. The test word may be any of a variety of different test words. In one embodiment the CD generates a random nonce, NCD, of the CD's choosing. At 418, the CD sends its ephemeral public key and the wrapped NCD to the HD.
At 420, the HD receives the message and derives a shared secret with the CD. In one embodiment, the HD uses discrete logarithm cryptography, for example, SP 800-56A § 6.2.2, with the ephemeral public key received from the CD and its own static private key to derive the secret. The HD's static private key may be stored in a secure register as described above with respect to
If the CD sent a wrapped nonce, the HD may then apply a variety of different tests to determine whether the CD knows the HD's public key and whether the exchange should continue. At 424, if the HD cannot unwrap the random nonce, then the HD knows that the CD does not possess the HD's public key and is not a valid device. In this case, the authenticated key exchange fails. The first test for which this test word has been established is failed and the process ends. The HD may apply additional tests, depending on the particular implementation. If the HD is able to unwrap the nonce, or if no nonce was sent, the exchange continues.
If the exchange continues, then at 426, the HD produces its own test word, such as another random nonce, NHD. At 428, the HD combines the two nonces into a single word and then wraps them in the shared secret. In a simple example, the HD concatenates the two nonces as NCD, NHD. While concatenation and wrapping are described herein, any of a variety of different approaches may be used to encrypt integrity protect the two test words with the shared secret, depending on the particular implementation.
The HD then sends the two test words in the encrypted and integrity protected form to the CD at 430. At this stage in the process, the HD still has no assurance that the CD is real or that the message that it received was not a replay of a previous message from a different node or device. For more security, the HD will not yet accept configuration from the sender of the message. If the CD did not send a random nonce, then the HD produces its own test word wraps it in the derived secret and sends it to the CD without any concatenation.
At 432, the CD receives the wrapped concatenation of the two nonces. At 434, the CD uses the shared secret to unwrap the two nonces. At 436, the CD determines whether the two nonces are recoverable by verifying the integrity of the message using the authenticated encryption scheme. If both nonces NCD, NHD, are not recoverable, then at 436 the key exchange fails. The CD knows that there is a security risk. It can assume that the HD does not possess the private analog to the public key that the CD obtained from the label. The HD is therefore an imposter so the authenticated key exchange fails. If the CD has sent only its own nonce, then the same operations are performed with only the one nonce.
At 438, if the one or both nonces are recoverable, depending on how many were received, then the CD checks that its nonce, NCD, was returned accurately. If not, then the CD aborts the exchange and the authenticated key exchange fails. If NCD was unwrapped, however, then at 440, the CD builds a new test word combining the nonces in a way that differs from how the HD combined them, and encrypting and integrity protecting them in some way. In one example, the CD concatenates the two nonces in the reverse order NHD, NCD, wraps the concatenated nonces with the shared secret key and at 442, sends the wrapped concatenation to the HD. In another example, the CD generates a message which proves that it knows NHD the nonce generated by the HD. This could be by adding the value 1 to the nonce or any other technique that results in a different message from the received message but still proves that the CD knows NHD.
At this point, the CD has authenticated the HD. It knows that the HD knows the private analog to the public key whose trust was obtained from access to the HD's label. It has proof that the HD is an active participant in the exchange because the HD proved possession of a shared secret that could only have been generated by the HD, and, in some cases, has returned the CD's random nonce. The CD knows that only one device can complete the protocol, the CD can therefore safely proceed to the configuration step with the assurance that the CD has authenticated the headless device that is being configured (the HD).
The HD, however, does not yet have assurance that the CD can be trusted because the CD has not proven knowledge of the shared secret nor that it is an active participant in the exchange. At 444, the HD obtains the message from the CD and at 446, uses the shared secret to unwrap the two nonces. At 448, if they are not recoverable, then the HD knows the CD was unable to unwrap its nonce, that the CD does not possess the HD's public key, and that the CD is not authorized to configure the HD. The authenticated key exchange fails. Alternatively, if the CD did not send its nonce at 416, then the HD similarly attempts to recover the message which proves the CD was able to determine NHD.
If the HD is able to unwrap the two nonces, or recover the proof of knowledge of the shared secret, then the process continues. At 450, it checks that its nonce, NHD, was returned by the CD, or if the CD demonstrated a proof that it knows NHD. If proof of knowledge of NHD was not returned, then the HD aborts the exchange and again the authenticated key exchange fails. If NHD was successfully returned or knowledge was successfully demonstrated, then the HD has an assurance that the CD is an active participant in the exchange, knows the secret, and is in valid possession of the HD's public key. In the example described herein, access to the HD's public key is used to determine whether a user of the CD has physical possession of the HD or some other valid authorization to configure the HD. The exchange has also confirmed that this CD is the active participant in the exchange and not an interloper, snooper, or other imposter. Returning the HD's random nonce shows the CD's possession of the shared secret. Optionally, for additional security, the CD can check to determine whether the CD's nonce, NCD, was also successfully returned.
At this stage, if all of the tests are passed, then the CD has authenticated the HD and the HD has an assurance that the device that wants to configure it is in physical possession of its label (or is in possession of the HD's public key by some other means) and is therefore allowed to configure it. At 452, the HD allows the CD to configure it and the CD can now begin a separate protocol to configure the HD.
The CD can configure the HD in any of a variety of different ways. In embodiments, a domain parameter 235 will be sent to the HD together with the addresses for domain name servers. The CD may also configure the HD's IP address, DHCP settings, passwords, and provide any host names for use by the HD, Protocols and packet formats for use on the network may also be defined.
There are other variants involving the protected content that is exchanged, or how the exchange is initiated. In the example described above, a label is used for bootstrapping trust of a public key and a static ephemeral Diffie-Hellman key exchange is used to address an asymmetric security problem involving a headless networking device.
The asymmetric security problem relates to a requirement on the CD for strong security. The CD must know that the CD is configuring the right HD and needs proof that the responding HD is the right HD. So in the above example, the CD proves that it is in possession of the public key which the CD has previously trusted through the bootstrapping process. The HD, on the other hand, has low security. It merely needs to know that it is being configured by an entity that controls it, or demonstrates knowledge of its physical characteristics, namely, the label which contains its public key
At 514, the CD performs an ephemeral key exchange with the HD. This may be a Diffie-Hellman key exchange or any other type key pair exchange. This generates a shared secret between the HD and the CD.
At 516, the CD encrypts a first information, for example a nonce with the shared secret. The information may be any test word that is difficult for imposters to guess. A random or pseudorandom number may be used, but the invention is not so limited.
At 518, the CD sends the encrypted and integrity protected information and, the ephemeral public key, to the HD. The HD uses its static private key and the ephemeral public key of the CD to compute the shared secret. At 520, the HD derives the information, e.g. the nonce, using the shared secret.
To prove itself to the CD, at 522, the HD generates a second information to indicate that it possesses the shared secret from the key exchange. In embodiments, the HD encrypts and integrity protects the received nonce using the same shared secret and at 524, the HD sends the encrypted nonce to the CD. For additional security, as mentioned above, the CD may include its own nonce or any other information or test word.
At 526, the CD receives the second information from the HD and then recovers the received nonce using the shared secret. The CD checks whether the received decrypted nonce matches the one that it originally sent. If there is a match, then the CD has determined that the HD possesses the shared secret and has shown that it is an active participant in the exchange by returning the CD's nonce wrapped in the shared secret. The HD has therefore been authenticated to the CD. At 528, the CD configures the HD.
The CD may also produce a third information (not shown) that is composed of the two nonces transposed in a different manner than the second information. In one embodiment, the order of the nonces is swapped. If the CD did not send a nonce at 516 the CD may compute a third information in a way that proves knowledge of the recovered NHD. In one embodiment, the value one is added to NHD to produce the third information. The CD encrypts and integrity protects the third information using the shared secret and sends the encrypted and integrity protected third message to the HD.
If a third information has been produced and sent then the HD receives and unwraps the encrypted and integrity protected third information using the shared secret. If the nonces are unable to be recovered, then the HD knows that the CD was unable to successfully unwrap the second information, does not know NHD, does not know the shared secret and therefore is not authorized to configure it. If the third information was successfully unwrapped and NHD, or knowledge of NHD, was demonstrated, then the exchange completes successfully. The HD has received assurance from the CD that it is in physical possession of the HD or has knowledge of its physical characteristics.
Additional advantages and modifications will readily occur to those skilled in the art. Therefore, the invention in its broader aspects is not limited to the specific details and representative embodiments shown and described herein. Accordingly, various modifications may be made without departing from the spirit or scope of the general inventive concept as determined by the appended claims and their equivalents. For instance, different or additional tests may be performed between the two devices, different forms of key generation and exchange may be used, and different test words may be used, depending on the particular implementation. The description is thus to be regarded as illustrative instead of limiting.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4956863 | Goss | Sep 1990 | A |
| 7711120 | Kimmel | May 2010 | B2 |
| 7716468 | Millet | May 2010 | B2 |
| 7818790 | Burns | Oct 2010 | B1 |
| 7865727 | Zeng | Jan 2011 | B2 |
| 8270603 | Durst et al. | Sep 2012 | B1 |
| 8447987 | Polonsky et al. | May 2013 | B1 |
| 20030046568 | Riddick et al. | Mar 2003 | A1 |
| 20070043946 | Lauter | Feb 2007 | A1 |
| 20120128157 | Braun | May 2012 | A1 |
| 20120137126 | Matsuoka | May 2012 | A1 |
| 20130243194 | Hawkes | Sep 2013 | A1 |
| 20140286491 | Atherton | Sep 2014 | A1 |
| Number | Date | Country |
|---|---|---|
| WO 2013020172 | Feb 2013 | WO |
| Entry |
|---|
| WO 2013/020172: Radio frequency identification technology incorporating cryptographics. |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13783001 | Mar 2013 | US |
| Child | 16443547 | US |
