TWI441025B - Accessory, controller, and method for establishing wireless communication link therebetween - Google Patents

Description

Accessory, controller, and method of establishing a wireless communication link therebetween

The present invention relates generally to wireless communication between electronic devices and, more particularly, to a secure wireless link between two devices.

Wireless networks are ubiquitous. The Institute of Electrical and Electronics Engineers (IEEE) has promulgated the 802.11 family of standards (also known as "WiFi") for enabling electronic devices to communicate with each other. These standards (including 802.11a, 802.11b, 802.11g, and 802.11n) define the frequency, modulation, data rate, and message format used to convey information between devices. In general, in an 802.11-compliant wireless network (also known as a "WiFi network"), there is a designated "access point" for managing the WiFi network, and the designated "access point" often has an access to the Internet. Wired connection. Among other things, the access point can deliver messages between devices connected via the network. The WiFi network has a name (usually configurable by a network administrator interacting with the access point), the access point can periodically broadcast the name and know the name or broadcast discovery from the access point The device of the network name can join the network by sending a "join" request to the access point. In general, an access point will only deliver messages between devices that have joined the network.

Of course, it is easy to intercept wireless signals. Therefore, the WiFi standard provides various security protocols such as Wired Equivalent Privacy ("WEP"), WiFi Protected Access ("WPA"), and IEEE 802.11i (also known as "WPA2"). These agreements specify that information sent over the network is encrypted and specifies the particular encryption technology to be used. The WiFi network access point can be configured for a specific security agreement.

In general, devices that join a secure WiFi network need to know the network-specific password or key that can be used to encrypt and decrypt messages. Although this password or key is typically not communicated wirelessly between devices, an access point in a secure WiFi network may require any device attempting to join the network to prove that it knows the password or key (eg, by correct Encrypt a random challenge). To connect the computer to a secure WiFi network, the user can obtain a password from the network administrator and type it into the computer, for example, in response to a prompt generated by a network configuration program executing on the computer.

However, the range of devices with WiFi capabilities has recently begun to expand beyond computers to include a range of peripheral devices. For example, wireless printers that communicate using the 802.11 standard have been developed. Some peripheral devices have a limited user interface, making it difficult or impossible for a user to type a password or key for a WiFi network into the device. It is often necessary to first connect a peripheral device to a computer via a wired interface (eg, USB) to configure the WiFi interface, and then switch the peripheral device to a wireless mode of operation.

Certain embodiments of the present invention provide for the use of two devices (also referred to herein as "controllers" and "" by means of wireless network protocols for the exchange of information between devices that have not joined the network. The technique of establishing a secure wireless link (referred to herein as "pairing") between the "accessories"). Such messages are referred to herein as "probe requests" and "probe responses" or more generally as "probes". In the case of a wireless network based on the IEEE 802.11 standard, a probe request and a probe response frame can be used as probes. The probes used herein can be used to exchange sequences of messages between two WiFi enabled devices, including computers, mobile devices, peripherals, and other devices. The sequence may include a message that may be used to establish a shared secret between the two devices; once the shared secret is established, the two devices may securely communicate other messages including, but not limited to, one of the devices. Information that can be added to a wireless network (for example, a network name and password or other credentials).

Pairing can be established by any two devices with a suitably configured wireless interface. In some embodiments described herein, a device ("controller") can broadcast an initial probe to announce that it is searching for a device that it can pair with. Another device ("Attachment") can respond to the initial probe by requesting another probe for the pairing. The two devices can establish a shared secret and/or verify that the other has the same shared secret. In some embodiments, the shared secret can be established and/or verified by exchanging additional probes. In other embodiments, all of the information needed to establish the shared secret may be provided in an initial probe exchange, and the shared secret may be verified via another mechanism, such as a user confirmation. Each device can use the shared secret to generate an additional encryption or authentication key. Such additional encryption or authentication keys may be used for security (eg, encryption and/or authentication) to use additional probe requests and probes to respond to message content transmitted between such devices.

In some embodiments, the secured message content exchanged between the devices may include credentials required to join the secure wireless network, such as a network name and password or key. For example, an accessory with a limited user interface (eg, a WiFi-enabled printer) can be paired with a controller (eg, a WiFi-enabled personal computer) and can be obtained via the pairing for the controller The credentials of the wireless network that is currently joined. The accessory can then join the wireless network using such credentials. Once the accessory has joined the wireless network, the accessory and controller can communicate with each other or with other devices via the network. At this point, the pairing can be terminated or the paired link can be maintained as a sideband communication path.

In some embodiments, the pairing procedure can be greatly automated so that little or no user intervention is required. Any user intervention can be as simple as verifying the password match between the accessory and the controller, or typing in a password provided by a device (eg, an accessory) at another device (eg, a controller).

One aspect of the present invention is directed to a method for establishing a wireless communication link between an accessory and a controller. A controller can broadcast a first probe to indicate that the controller is searching for an accessory to pair with. An accessory can receive the first probe and can respond by a second probe providing information about the accessory. The controller and the accessory can establish a common secret by exchanging individual public keys using additional probes, the additional probes including one of the third probes sent by the accessory and one of the fourth probes sent by the controller. The controller and the accessory can each verify that the other device shares the same secret, and each of the shared secrets can be used to generate an additional cryptographic key. Thereafter, any device can transmit the message to another device by encrypting a message using the additional cryptographic key and transmitting the encrypted message within a fifth probe. The receiving device may extract the encrypted message from the fifth probe and decrypt the encrypted message using the additional cryptographic key. In some embodiments, the encrypted message can be sent with the authentication material to allow the receiving end to verify the source and integrity of the message.

Another aspect of the invention pertains to an accessory having a wireless interface. A processor coupled to the wireless interface can be configured to: communicate with a controller to establish a pairing using a probe sequence to obtain credentials for joining a wireless network from the controller via the pairing; and Use these credentials to join the wireless network. Thereafter, assuming that the controller is also on the same wireless network, the accessory and controller can communicate via the wireless network and/or via the pairing. In some embodiments, the accessory may have a minimal user interface or no user interface; if necessary, the user may control the network joining behavior of the pairing and accessory by interacting with the controller.

Another aspect of the invention is directed to a controller having a wireless interface and a user interface. A processor coupled to the wireless interface and the user interface can be configured to communicate with an accessory to establish a pair using a probe sequence. Establishing the pairing can include communicating with a user via the user interface to confirm that the accessory should be allowed to join a wireless network and/or obtain a password for the accessory, wherein the password is used to establish the pairing. Once the pairing is established, the controller can securely send the credentials for joining the wireless network to the accessory (e.g., as one of the encrypted messages included in the probe sent to one of the widgets). Once the accessory is added to the wireless network, the controller and accessory can communicate via the wireless network and/or via the pairing.

The following embodiments, together with the drawings, will provide a better understanding of the nature and advantages of the invention.

Certain embodiments of the present invention provide for the use of two devices (referred to herein as "controllers" and "attachments" by means of wireless network protocols for the exchange of information between devices that have not joined the network. A technique for establishing a secure wireless link (referred to herein as "pairing"). Such messages are referred to herein as "probe requests" and "probe responses" or more generally as "probes".

For example, the IEEE 802.11 standard specifies that a message is sent in a structure called a "frame." The standard definitions are: a probe request frame that can be broadcast by a device that searches for a network to join, and a probe response frame that can be sent by an access point that receives the probe request. In this way, the device can automatically identify the available wireless network. According to these criteria, the probe request or probe frame can be incorporated with an "information element" whose content can be defined by a particular vendor.

Some embodiments of the present invention utilize vendor-specific information elements of the IEEE Probe Request and Probe Response frames to support the exchange of messages between any two WiFi enabled devices, including computers and peripherals. The sequence may include a message that may be used to establish a shared secret between the two devices; once the shared secret is established, the two devices may securely communicate other messages including, but not limited to, one of the devices. Ability to join the information on a standard WiFi network.

Pairing can be established by any two devices with a suitably configured wireless interface. In some embodiments described herein, a device ("controller") can broadcast an initial "browse" probe to announce that it is searching for a device that it can pair with. The browsing signal can be included in an information element of an 802.11 probe request frame or in another type of probe request. Another device ("Attachment") can respond to the browsing probe by an identification probe that includes the accessory identification information. The identification information may be included in the information element of the 802.11 probe response frame or in another type of probe. The two devices can establish a common secret and/or verify that the other device has the same shared secret. In some embodiments, the shared secret can be established and/or verified by exchanging additional probes. In other embodiments, all of the information needed to establish the shared secret may be provided in an initial probe exchange, and the shared secret may be verified via another mechanism, such as a user confirmation. Each device can then use the shared secret to generate an additional encryption or authentication key. Such additional encryption or authentication keys may be used for security (eg, encryption and/or authentication) to use additional probe requests and probes to respond to message content transmitted between such devices. For example, the preserved (eg, encrypted) message content can be included in an information element within an IEEE 802.11 probe request or probe response frame.

In some embodiments, the secured message content exchanged between the devices may include credentials required to join a secure wireless network, such as a network name and password or key. For example, an accessory with a limited user interface (eg, a WiFi-enabled printer) can be paired with a controller (eg, a WiFi-enabled personal computer) and can be obtained via the pairing for the control The credentials of the wireless network to which the device is currently connected. The accessory can then use the credentials to join the wireless network. Once the accessory has joined the wireless network, the accessory and controller can communicate with each other or with other devices via the network. At this point, the pairing may be terminated or the paired link may be maintained as a sideband communication path.

In some embodiments, the pairing procedure can be greatly automated so that little or no user intervention is required. Any user intervention can be as simple as verifying the password match between the accessory and the controller, or typing in a password provided by the device (eg, an accessory) at another device (eg, a controller).

Figure 1 illustrates the principle of operation used in certain embodiments of the present invention. Controller 100 (in this case a personal computer) and accessory 110 (eg, a printer) and accessory 120 (eg, a stereo speaker) are shown in FIG. Controller 100 and accessories 110, 120 each include a wireless communication interface (such as a standard WiFi interface card) and various other components (examples of which are described in detail below).

The controller 100 and the accessory 110 can establish a secure, direct communication link (also referred to as pairing) 112 by exchanging messages embedded in the probe request and the probe response. The term "probe" is also used herein interchangeably to include both probe requests and probe responses. Once the pairing 112 is established, the controller 100 and the accessory 110 can send the encrypted message to each other using additional probes. Similarly, controller 100 and accessory 120 can establish pair 122 by exchanging messages embedded in the probe. Once the pairing 122 is established, the controller 100 and the accessory 120 can send the encrypted message to each other using additional probes.

The probes are transmitted wirelessly, and the accessory 110 can detect the probe associated with the pair 122. Similarly, the accessory 120 can detect the detection associated with the pair 112. To provide security, once a pairing is established, the message can be encrypted depending on the particular pairing; thus, for example, pairing 112 can provide a cryptographic key different from pairing 122. As a result, the accessory 110 is not capable of decrypting the message contained in the probe associated with the pair 122. (Similarly, the accessory 120 is not capable of decrypting the message contained in the probe associated with the pair 112). Specific examples of techniques for establishing pairings, including establishing encryption keys that depend on pairing, are described below.

As shown in FIG. 1, in some embodiments, a single controller can be paired with multiple accessories at the same time. In some embodiments, the controller 100 can be in the process of establishing only one pair at a time; however, once a pair is established (eg, pair 112), the controller 110 can establish a second pair (eg, pair 122) A pairing is still available. In other embodiments, for example, if the probe request and the probe response include sufficient identification information so that the controller 100 can reliably determine the source of the received message, and if each accessory can determine the accessory or another device For the purpose of the received message, the controller 100 can establish multiple pairs at the same time. In still other embodiments, the controller 110 can be limited to pairing with one accessory at a time. Thus, for example, if accessory 110 begins to pair with controller 100, accessory 120 may be required to wait until pair 112 is fully established. In an alternate embodiment, if the accessory 120 attempts to initiate pairing with the controller 100 while the accessory 110 is in the process of establishing its pairing, the controller 100 can terminate communication with the accessory 110 to satisfy the from the accessory 120. Pairing request. Other rules for prioritizing pairing operations can also be used.

It will be appreciated that the apparatus shown in Figure 1 is illustrative and that variations and modifications are possible. For example, although the controller 100 is depicted as a personal computer, the controller 100 can be another type of device including, but not limited to, a laptop, tablet, smart phone, mobile communication, or computing device. and many more. Moreover, controller 100 need not have or include significant computing power; any device capable of performing controller operations as described herein can be used as a controller.

Similarly, the accessory 110 and the accessory 120 are depicted as a printer and a pair of stereo speakers, respectively, although other types of accessories may be used, including any device having a wireless communication interface. Other examples of devices that can be used as accessories include peripheral devices, cameras, personal electronic devices including electronic medical devices, and household appliances. As with the controller 100, any device capable of performing the operation of the accessory as described herein can be used as an accessory. As will be apparent, the "accessory" differs from the controller in that the accessory receives and responds to the initial probe request from the controller during the pairing procedure.

In some embodiments, the accessory can be a device that has a limited user interface or does not have any user interface. For example, speaker 120 can produce sound but does not need to have any components (eg, buttons, dials, touch sensitive areas, etc.) that are capable of detecting user motion. Similarly, printer 110 is capable of producing any image on paper (black and white or color depending on implementation) and may have a display capable of displaying a few characters or only a status light; the user input interface may provide only one or two Control buttons. Such limited or non-existent user interfaces may make it difficult or impossible for a user to enter a network name, password, or other credentials that may be required by a conventional secure wireless network. Some embodiments allow the accessory to obtain network credentials wirelessly and securely with little or no interaction with the accessory, thereby simplifying the task of connecting such accessory to the wireless network.

The terms "probe request" and "probe response" (or "probe") as used herein generally refer to messages sent outside of a particular wireless network. Such information may include an identification of the transmitting device and/or a request for information about the receiving device. The messages may be broadcast, or in some embodiments, if the transmitter has identification information for the receiving end, some of the messages may be unicast (i.e., addressed to a particular receiving end). The probe is typically sent in cleartext (although in some embodiments described below, the encrypted message may be embedded in a plain text probe request or probe response). Although the probe request and probe response frame complying with IEEE 802.11 can be used, the present invention is not limited to such a specific frame or a network complying with the IEEE 802.11 standard.

2 is a block diagram of a controller 200 in accordance with an embodiment of the present invention. Controller 200 (e.g., implementing controller 100 of FIG. 1) can include various components, such as processor 202, user interface 204, wireless interface 206, and storage medium 208.

The processor 202, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), may control the operation of the controller 200. In various embodiments, processor 202 can execute various programs in response to the code and can maintain a plurality of programs or programs that are executed simultaneously. At any given time, some or all of the code to be executed may reside in processor 202 and/or in a storage medium such as storage medium 208.

The processor 202 can provide various functionality to the controller 200 via suitable stylization. For example, in response to the user input signal provided by the user interface 204, the processor 202 can launch an application (document processor, web browser, etc.), play the stored media content, and control the wireless interface 206 to establish or terminate. Network connection or sending and receiving data and other signals, and more.

The user interface 204 can include: an input device such as a keyboard, a touch pad, a touch screen, a scroll wheel, a rotary click wheel, a dial, a button, a switch, a keypad, a microphone, or the like; And output devices such as video screens, indicator lights, speakers, headphone jacks, or the like; and supporting electronic devices (eg, digital to analog or analog to digital converters, signal processors, or the like). The user can operate the input device of the user interface 204 to invoke the functionality of the controller 200 and can view and/or listen to the output from the controller 200 via the output device of the user interface 204.

The wireless interface 206 can provide data communication capabilities to the controller 200. In some embodiments, the wireless interface 206 can include a radio frequency (RF) transceiver component for accessing a wireless voice and/or data network (eg, using advanced data network technologies such as 3G, 4G, or EDGE, WiFi (IEEE 802.11 series of standards) or other wireless communication technologies, or any combination thereof. The wireless interface 206 can be implemented using a combination of hardware (e.g., antennas, modulators/demodulators, encoders/decoders, and other analog and/or digital signal processing circuits) and software components.

Storage medium 208 can be implemented, for example, using a disc, flash memory, or any other non-volatile storage medium. In some embodiments, storage medium 208 can store code (including application and operating system programs) to be executed by processor 202. This code may include code for pairing with the accessory as described below. The storage medium 208 can also store data, such as media assets (audio, video, still images, etc.) that can be played or streamed by the controller 200 to another device, personal information electronic files, and/or data files for users and others. News. In some embodiments, storage medium 208 can store network credentials 210 (eg, a network name and password) associated with a particular wireless network to which controller 200 can connect via wireless interface 206.

It should be appreciated that controller 200 is illustrative and that variations and modifications are possible. Controller 200 may have capabilities not specifically described herein (eg, mobile phone technology, satellite-based navigation) and does not require media playback capabilities. The term "controller" as used herein generally refers to any device that can respond to a request for a secure wireless link or pairing and then establish a pair with another device.

In some embodiments, controller 200 can also exchange information with a user or another device using other input/output channels. Examples of other input/output channels include analog signals on an audio line input or output path (eg, an audio jack); a camera, bar code reader, or other imaging device (for input) in combination with an image analyzer; A display screen that produces machine-readable images (for output); sensors such as accelerometers, gyroscopes, or proximity detectors (via sensors that can use the motion, orientation, or position of the device to enter information into Controller 200); non-visible (eg, infrared) photodetectors and/or transmitters; ultrasonic detectors and/or transmitters;

3 is a block diagram of an accessory 300 in accordance with an embodiment of the present invention. The accessory 300 (eg, implementing the printer accessory 110 of FIG. 1) can include a processor 302, a user interface 304, a wireless interface 306, a storage medium 308, and a printing element 310.

The processor 302, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), may control the operation of the accessory 300. In various embodiments, processor 302 can execute various programs in response to the code and can maintain a plurality of programs or programs that are executed simultaneously. At any given time, some or all of the code to be executed may reside in processor 302 and/or in a storage medium such as storage medium 308.

The user interface 304 can be a simple interface similar to the interface of conventional printers. For example, some printers provide a minimal interface with a small number of buttons and status indicators. Other printers provide a finer interface (for example, including a character line display or other display, as well as a keypad, touch screen or the like) that support interactive menus to facilitate adjustment of the printer Machine settings, paper or paper path selection, cancel work, troubleshooting, etc. In some embodiments, the display of the user interface 304 can be used to provide information to the user to verify the pairing (eg, as described below).

The wireless interface 306 can provide at least the data communication capability for the accessory 300. In some embodiments, the wireless interface 306 can include a radio frequency (RF) transceiver component for accessing a wireless data network (eg, using 3G, 4G or EDGE, WiFi, or other mobile communication technologies, or any combination thereof) . The wireless interface 306 can be implemented using a combination of hardware (e.g., antennas, modulators/demodulators, encoders/decoders, and other analog and/or digital signal processing circuits) and software components.

Storage medium 308 can be implemented, for example, using a disc, flash memory, or any other non-volatile storage medium. In some embodiments, storage medium 308 can store code (including, for example, a print control program) to be executed by processor 302. This code may include code for pairing with the controller as described below.

Print element 310 can include various electronic and/or mechanical components such as a paper feeder, an inkjet device, a laser printing device, and the like.

4 is a block diagram of an accessory 400 in accordance with another embodiment of the present invention. The accessory 400 (eg, implementing the speaker accessory 120 of FIG. 1) can include a processor 402, a wireless interface 406, a storage medium 408, and a speaker 410.

The processor 402, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), may control the operation of the accessory 400. In various embodiments, processor 402 can execute various programs in response to the code and can maintain a plurality of programs or programs that are executed simultaneously. At any given time, some or all of the code to be executed may reside in processor 402 and/or in a storage medium such as storage medium 408.

The wireless interface 406 can provide at least the data communication capability for the accessory 400. In some embodiments, the wireless interface 406 can include a radio frequency (RF) transceiver component for accessing a wireless data network (eg, using 3G, 4G or EDGE, WiFi, or other mobile communication technologies, or any combination thereof) . The wireless interface 406 can be implemented using a combination of hardware (e.g., antennas, modulators/demodulators, encoders/decoders, and other analog and/or digital signal processing circuits) and software components.

Storage medium 408 can be implemented, for example, using a disc, flash memory, or any other non-volatile storage medium. In some embodiments, storage medium 408 can store code to be executed by processor 402 (including, for example, code for decoding digital audio received via wireless interface 406). This code may include code for pairing with the controller as described below. In some embodiments, storage medium 408 can also store device password 412, which can be part of the device firmware or hard coded into the device. The device password 412 can be used when pairing is established as described below.

Speaker 410 can include various electronic and/or mechanical components such as amplifiers, transducers, speaker cones, output jacks, or the like. In some embodiments, processor 402 can receive digital audio material via wireless interface 406, convert the data to an analog signal, and provide an analog signal to a speaker driver within speaker 410. In some embodiments, the speaker 410 can also include an auxiliary input jack (eg, a standard 3.5 mm audio jack) and can also receive analog audio signals via the path.

Unlike the accessory 300, the accessory 400 is not shown as having a user interface, but is actually shown as an accessory that does not require any user interface. In some embodiments, the user interface can be limited to, for example, a power switch, an input source selector, a volume control, or the like.

It should be understood that the accessories 300 and 400 are illustrative and that variations and modifications are possible. The term "accessory" as used herein generally refers to any device that can be paired with a controller, and the communication link provided by the pairing is used for any purpose, including but not limited to facilitating the addition of accessories to The network to which the controller belongs. In some embodiments, a pairing link can be used to transmit information about the functionality of the accessory and control signals. Thus, the accessory can be used for a variety of purposes, including printing, playing sound, displaying video, providing data (eg, sensor readings) to the controller, receiving and processing data from the controller, and the like. The accessories are not limited to peripheral devices such as speakers or cameras; other examples include household appliances (eg, refrigerators, conventional ovens, microwave ovens, washing machines, etc.) and personal electronic devices (eg, sports exercise monitors, electronic medical devices). Any device with a wireless interface and suitable configuration can be operated as an accessory.

In addition, although the controller and the accessories have been described with reference to the specific blocks shown in FIGS. 2 through 4, it should be understood that such blocks are defined for ease of description and are not intended to suggest a particular physical configuration of the various components. In addition, the blocks do not need to correspond to physically distinct components. The blocks may be configured to perform various operations, for example, by staging the processor or providing appropriate control circuitry, and depending on the manner in which the initial configuration is obtained, the various blocks may be reconfigured or not reconfigurable. Embodiments of the invention may be implemented in a variety of devices including electronic devices implemented using any combination of circuits and software.

As described herein, the controller and the accessory can establish a wireless pairing by exchanging probes. FIG. 5 is a block diagram of a sounding frame structure 500 that may be used in some embodiments of the present invention.

The sounding frame structure 500 includes a number of fields; in some embodiments, some or all of these fields may correspond to a frame structure as defined by the IEEE 802.11 standard. For example, the frame control field 502 can provide general information about the frame, such as a protocol version, a frame type (eg, identifying a frame as a probe request or a probe response frame), and can be used by a receiving device to resolve The translation receives other information about the wireless signal stream. The duration field 504 can provide duration information (eg, as defined in the IEEE 802.11 standard). The address field 506 can specify the address of the transmitter of the frame 500 and the intended recipient, as well as other address information (e.g., as specified in the IEEE 802.11 standard). Sequence field 508 can contain sequence information that can be used to reconstruct frames from multiple received segments. The data field 510 may contain frame content, and the frame content includes data to be processed by the receiving end. The sum check code field 512 may include error detection and/or error correction codes, such as a 32-bit cyclic redundancy check.

The data field 510 for the probe request or probe response frame may include one or more information elements 520. Each information element ("IE") 520 can be a structure containing various fields. Element ID field 522 can identify the type of IE. For example, the information element can be a standard element or a vendor specific element, and the element ID field 522 can be used to indicate that the IE 520 is a standard element or a vendor specific element. In the embodiments described herein, it is assumed to be a vendor specific information element, but it will be appreciated that the information elements described herein may be part of the future standard. Length field 524 indicates the length of IE 520 (eg, in units of bytes). The vendor field 526 can include a unique identifier for the vendor associated with the vendor specific information element 520. The vendor may be, for example, a manufacturer of a controller capable of performing the pairing operation as described herein. In some embodiments, the vendor identifier in field 526 may be a 24-bit unique unique identifier (OUI) assigned by the IEEE; other identifiers may also be used. The subtype field 528 can provide a subtype assigned by the vendor. In some embodiments, the subtype field 528 has a fixed value across all paired correlation probes and is used to indicate that the information element 520 is for pairing.

Sub-IE field 530 may contain one or more sub-IEs 540. As shown, sub-IE 540 provides a type identifier field 542 that indicates the type of information provided in the child element. Examples of types of information that may be provided include operations that identify operations associated with IE 520 (eg, searching for attachments to pair, negotiating keys, authenticating shared secrets, sending encrypted messages such as wireless network credentials) Code (opcode); address of the target device; job stage identifier; serial number; cryptographic key; random nonce; authentication code (authenticator) or digital signature; encrypted data; Capabilities and/or configuration information; device name (manufacturer and/or model name); network credentials (which may be encrypted, for example, as described below). Examples of the use of various types of information are described below.

The length field 544 can be used to indicate the length of the sub-IE 540. Payload field 546 may contain information identified by type identifier field 542.

It should be understood that the detection formats described herein are illustrative and that variations and modifications are possible. In some embodiments, the sound frame follows the IEEE 802.11 standard that defines the probe request and the probe response frame, but other detection formats may also be used. Any data structure that can be used to transfer information between devices without the inclusion of at least one of the devices to the wireless network can be used as a probe.

An example of a procedure that can be used to establish a pairing between an accessory and a controller is now described.

6 is a flow diagram of a procedure 600 that can be used by a accessory to establish a pair with a controller in accordance with an embodiment of the present invention. When the accessory (e.g., accessory 300 or accessory 400) determines that it should attempt to establish a pairing, routine 600 begins at step 602. In some embodiments, this determination is made automatically during the activation procedure of the accessory; in other embodiments, the user can manipulate the control of the accessory to initiate the procedure. In still other embodiments, an attempt is made to automatically establish a pairing at startup or to wait for configurable parameters of a particular command system accessory.

At step 604, the accessory can listen to and receive a "browse" probe request from the controller indicating that the controller is searching (or browsing for) its pairable accessory. In some embodiments, the browse probe request can be received as a probe frame 500 as described above. In this case, the sounding frame 500 can contain (e.g., within the sub-IE field 530) an instruction code indicating that the controller is searching for or browsing for an accessory to be paired. The browsing probe request can be broadcast, for example, by not specifying a receiving end address. In the case of an 802.11 compliant network, typically only the access point listens to and responds to the probe request; other devices ignore the probe request. However, because the probe request is broadcast in plain text, the device other than the access point can detect and respond to the probe request.

At step 606, the accessory can send a probe response to the controller. In some embodiments, the probe response can be sent as a probe frame 500 as described above. In this case, the sounding frame 500 can include (eg, within sub-IE field 530) identification information about the accessory (such as manufacturer name, model name) and specific capability information (such as the accessory can be dynamically or Key negotiation is performed based on the stored password). At step 604, the probe response can be addressed to the controller from which the probe request was received. If multiple probe requests are received at step 604, the accessory can select a controller. In some embodiments, the accessory selects the first controller from which the probe request was received; in other embodiments, the last controller is selected. In other embodiments, other selection rules may be used, or if the accessory has a user interface that prompts the user, the accessory may prompt the user to select a controller to which the accessory should be paired.

At step 608, the accessory and controller can establish and exchange a common cryptographic key. In some embodiments, additional probes are used to exchange public keys. In the case of the use of the sounding frame 500, the keys may be incorporated as sub-IEs in the sub-IE field 530; other formats may also be used. In some embodiments, the key can be negotiated dynamically; in other embodiments, the key generation can be based on a fixed password associated with the accessory. Examples of pairing procedures using each of these techniques are described below.

At step 610, the accessory can calculate a common secret and the controller can be verified by confirming that the controller has the same shared secret. For example, the accessory and the controller can each display some information based on the shared secret. If the two have the same secret, the two displays should match and the user can be verified for the match. Alternatively, the accessory and controller can each use a random challenge to verify that the other has the same shared secret. Examples of pairing procedures using each of these techniques are described below.

At step 612, the accessory can generate additional encryption and authentication keys based on the shared secret. At step 614, the accessory can securely communicate with the controller using the additional keys. For example, the accessory can use the keys to encrypt the message and then send the encrypted message in the information element (or other data item) within the probe. Similarly, the accessory can receive a probe containing the encrypted message from the controller and can use the keys to decrypt and authenticate the message. The communication via pairing can continue indefinitely at step 614; when the communication is complete, the routine 600 can end.

7 is a flow diagram of a process 700 that can be used by a controller to establish a pair with an accessory in accordance with an embodiment of the present invention. When the controller determines at step 702 that an attempt should be made to pair with the accessory, the routine 700 begins. For example, the user can command the controller to search for the accessory to be paired.

At step 704, the controller may broadcast a browse probe request indicating that the controller is browsing to find an accessory that can be paired. In some embodiments, the probe request can be broadcast as the probe frame 500 as described above. In this case, the sounding frame 500 can contain (e.g., within the sub-IE field 530) an instruction code indicating that the controller is searching for or browsing for an accessory to be paired. The probe request may include, for example, an indication broadcasted by not specifying a receiver address.

At step 706, the controller can receive a probe response from the accessory. In some embodiments, the probe response can be sent as a probe frame 500 as described above. In this case, the sounding frame 500 can include (eg, within sub-IE field 530) identification information about the accessory (such as manufacturer name, model name) and specific capability information (such as the accessory can be dynamically or Key negotiation can be performed based on the stored password). The probe response can be addressed to the controller. In some embodiments, at step 706, the controller can receive a plurality of probe responses.

In some embodiments, the controller can prompt the user before proceeding further. For example, the controller may display a message asking the user if the accessory should be connected; this message may include the accessory identification information extracted from the probe request. If the user authorizes the connection, the controller can proceed. In the event that a probe response is received from a plurality of accessories at step 706, the controller may cause the user to select the accessory to be paired. In other embodiments, the controller can continue pairing without first obtaining user authorization.

At step 708, the controller and the accessory can establish and exchange a common cryptographic key. In some embodiments, additional probes are used to exchange public keys. In the case of the use of the sounding frame 500, the keys may be incorporated as sub-IEs in the sub-IE field 530; other formats may also be used. In some embodiments, the key can be negotiated dynamically; in other embodiments, the key generation can be based on a fixed password associated with the accessory. Examples of pairing procedures using each of these techniques are described below.

At step 710, the controller can calculate a common secret and can verify the accessory by confirming that the accessory has the same shared secret. For example, the controller and the accessory can display certain information based on the shared secret. If the two have the same secret, the displayed information should match and the user can verify the match. Alternatively, the controller and the accessory may each use a random challenge to verify that the other has the same shared secret. Examples of pairing procedures using each of these techniques are described below.

At step 712, the controller can generate additional encryption and authentication keys based on the shared secret. At step 714, the controller can securely communicate with the accessory using the additional keys. For example, the controller can use the keys to encrypt the message and then send the encrypted message in the information element (or other data item) within the probe. Similarly, the controller can receive a probe containing the encrypted message from the accessory and can use the keys to decrypt and authenticate the message. The communication of the secure paired link provided at step 714 may continue indefinitely; when the communication is complete, the routine 700 may end.

It should be appreciated that the procedures 600 and 700 are illustrative and that variations and modifications are possible. The steps described as sequential steps may be performed in parallel, the order of the steps may be changed, and the steps may be modified, combined, added or omitted. For example, various sequences of probe requests and probe responses can be used to establish security (keys, shared secrets, etc.) for pairing. Various cryptographic techniques and algorithms can be used; some examples are described below. The probe may be a request to follow the IEEE 802.11 probe request and probe response frame or other format following other wireless network connection protocols. In general, detection is expected to be sent in plain text (i.e., unencrypted); any device with suitable capabilities can read the messages. Within the pairing, security may be provided, for example, in the manner described above by encrypting the message content (eg, as an information element or other material item) before embedding it in the plain text probe.

In some embodiments, as few as two probes can be used to complete the pairing. For example, the initial probe request sent by the controller may include the controller's public key, and the initial probe response sent by the accessory may include the public key of the accessory. (Thus, step 608 can occur with steps 604 and 606; likewise, step 708 can occur with steps 704 and 706.) The verification of the shared secret can also be performed without exchanging additional probes; Example.

Once the secure pairing link is established using the programs 600 and 700, any type of information can be communicated via the join (depending on the implementation of the bandwidth constraints). In some embodiments, the accessory can obtain credentials for the wireless network using the pairing provided at step 614 (eg, for the name and password or key of the protected IEEE 802.11 network); the accessory can Then use these credentials to join the network. Once the accessory joins the wireless network, communication via the paired link can be interrupted, but in some embodiments, the communication can continue to provide a communication sideband.

Other types of information that may be communicated via a paired link include configuration parameters and/or control signals for the accessory, controller, or both. Thus, for example, the paired accessory can act as a remote control for the controller (by sending a command to the controller within the probe) or a paired controller can act as a remote control for the accessory (by transmitting within the probe) Command to attachment). If the bandwidth provided by the probe is sufficient, the data can be streamed between the devices. (For the current IEEE 802.11 standard, the bandwidth provided by the probe request and probe response frames is typically not sufficient for high quality media streaming; other implementations may provide higher bandwidth).

As mentioned above, some embodiments provide dynamic key agreement and verification at steps 608 and 610 (or steps 708 and 710), while other embodiments provide key agreement based on fixed device cryptography and verification. 8A and 8B are flow diagrams of a procedure 800 for providing two alternatives in accordance with an embodiment of the present invention.

At step 802, the controller (eg, controller 200) can receive an instruction to locate an accessory to pair with, for example, from a user. For example, an application executed by the controller can include a user interface with control that the user can manipulate (eg, by a self-selection selection) to command the controller to search for accessories that are available for pairing. In other embodiments, instructions for locating the accessory may be automatically generated (e.g., at regular intervals) during operation of the controller, and the user is not required to initiate. At step 804, the controller may broadcast a probe request (eg, as described above) to browse for an accessory that can be paired. This step can be substantially similar to step 704 of the procedure 700 described above.

At step 806, the accessory can receive the probe request from the controller. At step 808, the accessory can respond to the controller by transmitting a probe response (eg, as described above) to the controller. This step can be substantially similar to step 606 of the procedure 600 described above.

At step 810, the controller can receive the probe response from the accessory. At step 812, the controller can be confirmed by the user whether pairing should continue. As mentioned above, in some embodiments, the controller may display a message asking the user if the accessory should be connected; this message may include the accessory identification information extracted from the probe request. If the controller receives a probe response from a plurality of widgets, step 812 can include prompting the user to select an accessory to pair with. Assuming the user confirms that the corresponding correspondence continues, the controller can proceed. In other embodiments, the controller may continue pairing without first obtaining user authorization, and step 812 may be omitted.

At step 814, the controller may determine that the accessory uses dynamic key negotiation or uses a fixed password based key. If the accessory does not use dynamic key agreement, the sequence shown in Figures 9A-9B and described below can be used, as indicated at step 816.

For dynamic key agreement, the remainder of the routine 800 is shown in Figure 8B. At step 822, the controller can generate its private key ("CPRIV") and public key ("CPUB"). In one embodiment, the controller can generate a 32-bit cipher to compile strongly random data, such as Curve25519 (elliptic curve Diffie-Hellman method, whose documentation is located at http://cr.yp.to/ecdh.html) The cryptographic compilation algorithm converts the data into a private key CPRIV and calculates the public key CPUB based on CPRIV. It can be replaced with other techniques for generating a public-private key pair.

At step 824, the controller may send the public key CPUB to the accessory using the probe request. The public key CPUB can be included as an information element or other data item. The public key can be sent as plain text. The controller may also include other information within one or more of the information elements in the probe request, such as a unique job phase ID associated with the pairing job phase that may be included in all probe requests and probe responses thereafter. The use of the job phase ID can help the controller and the accessory determine the status of the paired link (eg, key negotiation is in progress or completed) and process the received probe request and probe response accordingly. In some embodiments, other information may also include a unique sequence identifier (which is unique within the job phase) that allows the probe response to match a particular probe request.

At step 826, the accessory can receive a probe request containing the controller's public key CPUB. The accessory may generate its own private key ("APRIV") and public key ("APUB") at step 828. In one embodiment, the accessory may generate a 32-bit cryptographically compiled strong random data, convert the data to a private key APRIV using a cryptographic compilation algorithm such as Curve 25519, and calculate the public key APUB from the APRIV. Other techniques for generating a public-private key pair may be substituted; in general, compatible techniques should be used at steps 822 and 828. At step 830, the accessory can send its public key APUB to the controller using a probe response.

At step 832, the controller can receive the probe response and extract the APUB. At this stage, the controller and the accessory each have both a public key APUB and a CPUB.

At steps 834 and 836, the controller and the accessory can calculate the shared secret based on the public key APUB and the CPUB, respectively. In some embodiments, Curve 25519 can be used to calculate a shared secret; it can be replaced with other cryptographic compilation algorithms. In general, two devices should use the same algorithm to provide a shared secret (ie, both devices are aware of one secret).

At steps 838 and 840, the controller and the accessory respectively calculate a password based on the shared secret. For example, a hash algorithm such as SHA-256 can be applied to a shared secret or to a function of a shared secret. A portion of the result or result can be converted into a string of alphanumeric characters (eg, 8 characters) that can be used as a cipher. Although various techniques can be used in the generation of passwords, the accessories and controllers should use techniques that produce matching or related passwords. At steps 842 and 844, the controller and the accessory respectively present their calculated passwords to the user. For example, controller 200 displays a password on its display. The printer accessory (e.g., accessory 300) can display a password or print a page containing the password on its user interface display. The user can compare the two passwords to confirm that the two passwords match (eg, by operating the controller and/or the input controls on the accessory to confirm the match). At steps 846 and 848, the accessory and the controller can each receive the confirmation. In some embodiments, the user may provide an acknowledgment via a user interface of only one device (eg, a controller) that can communicate the acknowledgment to another device (eg, an accessory) by transmitting a probe. If the acknowledgment is not received, the (or such) device that has not received the acknowledgment may interrupt the routine 800.

In some embodiments, the accessory may not be able to display a password. For example, the speaker accessory 120 as shown in Figure 1 does not have a display device. In such a situation, password-based authentication as described below with reference to Figures 9A-9B can be used instead.

Assuming that the password is verified at steps 850 and 852, the controller and the accessory can each generate additional encryption and authentication keys based on the shared secret. For example, use advanced encryption standards ("AES", whose documentation is located at http://en.wikipedia.org/wiki/Advanced_Encryption_Standard) and/or Poly1305-AES message authentication code (its documentation is located at http: //cr.yp.to/mac.html) standard technique to derive such keys.

At this point, it is believed that pairing has been established and that secure communication between the controller and the accessory using the keys established at steps 850 and 852 is possible. Examples of specific programs for securely transmitting and receiving messages are described below.

As mentioned above, the process 800 includes presenting the password to the user by the controller and the accessory and having the user verify that the password matches. In some embodiments, some devices may be inconvenient or impossible to present a password to a user. For example, the speaker accessory 120 as shown in FIG. 1 does not include any display capabilities; although this capability may be added, it may not be necessary to add (eg, for cost or aesthetic reasons). Thus, some embodiments provide password-based authentication in addition to or in lieu of dynamic key agreement.

In some embodiments, the routine 800 can be modified to reduce the number of probes that are exchanged to establish a pair. For example, the initial probe request sent by the controller at step 802 can include the controller public key CPUB, and the initial probe response sent by the accessory at step 808 can include the accessory public key APUB; In the case, additional probes may be omitted at steps 824 and 832. If no probing is used in subsequent steps, for example, if the user can interact with each device individually to verify password matching (at steps 846 and 848), then with as few as two probes (from one of the controllers) Request and response from one of the attachments) to establish a match.

9A-9B are flow diagrams of a procedure 900 for password based authentication, in accordance with an embodiment of the present invention. As indicated in Figure 8A, both program 800 and program 900 are available, wherein the controller determines which program to use based on the information provided by the accessory. In other embodiments, the program 900 can be implemented without implementing the program 800, in which case all of the accessories will support password-based authentication.

Process 900 begins after the controller has received a probe request from the accessory indicating that the accessory is trying to establish a pairing. In this case, the probe request may indicate that the accessory uses password-based authentication. At step 902, the controller may send a probe request containing the job phase ID to the accessory. As mentioned above, the job phase ID is assigned by the controller and depends on the pairing with a particular accessory.

At step 904, the accessory can receive the probe request. In this embodiment, the accessory may have a fixed or pre-set password that is permanently stored in a memory or other storage accessible by the accessory (eg, the accessory 400 of FIG. 4 has been stored in the storage medium 408). Device password 412), and at step 906, the accessory can use this password to generate a public key ("APUB"). In one embodiment, the accessory uses a secure remote password ("SRP" whose file is located at http://srp.standford.edu/) to generate the public key APUB. At step 908, the appendage can generate a random salt (eg, follow SRP). At step 910, the accessory can send a probe response containing the public key APUB and a random salt to the controller. This probe response and all subsequent probe requests or probe responses may also include the job phase ID provided by the controller at step 902.

At step 912, the controller can receive a probe response from the accessory. At step 914, the controller can prompt the user to enter the password for the accessory into the controller. In this embodiment, it is assumed that the user can obtain the password of the accessory. The password can be provided to the user (eg, in a document packaged with the accessory, on a sticker attached to the accessory, as a password stamped on the body of the accessory, or in some other manner). In some cases, the accessory serial number or other unique identification code can be used as the password.

Given the range of options for communicating the password to the user, it may be helpful to prompt or alert the user at step 914 where to find the password for the accessory. In some embodiments, the accessory can provide information to the controller as to where the password is located. For example, different location codes can be defined to indicate "left side", "right side", "top", "bottom", "front", "back" and "file". The accessory may include the appropriate location code in the information element (or other information) of the probe request or probe response (such as the initial probe request sent by the accessory to locate the paired partner, or the probe response sent at step 910 of routine 900). In the project).

Figure 10 illustrates a password prompt that can be displayed on a controller in accordance with an embodiment of the present invention. Window 1000 contains the prompt. The title bar 1002 identifies the accessory to which the controller is attempting to connect, and the prompt 1004 causes the user to type a password in the text box 1006. A tip message 1008 tells the user where the password can be located. In some embodiments, the controller may generate the prompt message 1008 by reading the location code from the probe request or probe response received from the accessory and selecting the appropriate text depending on the location code.

Referring again to FIG. 9A, at step 916, the controller can receive the password via the user input device. In some embodiments, the user can command the controller to cancel or abort the pairing procedure instead of typing in a password. At step 918, the controller can generate its own public key (CPUB); SRP or other techniques can be used. At step 920, the controller may calculate a shared secret (eg, using SRP) based on the public key APUB of the accessory, the public key CPUB of the controller, and the random salt received from the accessory. At step 920, the controller can, for example, use the SRP to calculate a response ("CRESP") indicating that it knows the password of the accessory.

The remainder of the procedure 900 is shown in Figure 9B. At step 924, the controller may send a probe request including the public key CPUB and the response CRESP.

At step 926, the accessory can receive the probe request. At step 928, the accessory may calculate a shared secret (eg, using SRP) based on the public key APUB of the accessory, the public key CPUB of the controller, and the random salt generated at step 908 (FIG. 9A). At step 930, the accessory can verify the response CRESP received from the controller using the calculated shared secret. In some embodiments, if the verification fails, the process 900 can terminate. Assuming the verification is successful, the accessory can calculate its own response (ARESP) at step 932 to indicate that it is also aware of the password of the accessory. At step 934, the accessory can send a response ARESP to the controller in a probe response.

At step 936, the controller can receive the probe response, and at step 938, the controller can verify the response ARES. As at step 930, in some embodiments, the verification failure results in the termination of the process 900. If the verification is successful, then at step 940 the controller can calculate the encryption and authentication key based on the shared secret. As in program 800, these keys can be calculated using AES and Poly1305-AES, respectively.

Similarly, once the accessory has verified the controller's response (CRESP), the accessory may also calculate the encryption and authentication key based on the shared secret at step 942.

At this point, pairing is established and a secure communication using the keys established at steps 940 and 942 is possible. Examples of specific programs for securely transmitting and receiving messages are described below.

It should be understood that the pairing procedures described herein are illustrative and that variations and modifications are possible. The steps described as sequential steps may be performed in parallel, the order of the steps may be changed, and the steps may be modified, combined, added or omitted. For example, the order in which the various keys are generated can be changed. Attachments and controllers can perform certain calculations simultaneously.

Although the embodiments described herein identify a particular sequence that can be used to establish a paired probe request and probe response, other embodiments may use different sequences of probes. (Thus, any use of ordinal numbers such as "first", "second", etc., used to distinguish between probes should be understood to be only for distinguishing purposes, and does not require a specific time sequence between probes.) Additional probe requests and probe responses not explicitly shown or described above may also be used. For example, in some agreements such as IEEE 802.11, the device transmitting the probe request expects to receive a probe response within a certain period of time; if no response is received, the program waiting for the response may be timed out. In some embodiments, the means for receiving the probe request may send a first probe response confirming receipt of the probe request and indicating (eg, via an information element) how long the sender of the probe request should wait for a response . The requesting device can use the specified timeout to determine how long to wait for a response before resending the request or aborting the program. This allows the response device to perform calculations that take longer than the preset timeout period; the responding device can send a probe response within the timeout period to indicate that the requesting device should wait for a full response.

It should also be noted that program 800 and program 900 can be implemented such that the controller only sends probe requests without transmitting probe responses; and the accessory only sends probe responses without sending probe requests. Thus, the controller does not need to be able to detect or respond to probe requests.

The identification of specific encryption and authentication techniques (AES, SRP, etc.) is illustrative and may be replaced by other techniques. It is contemplated that the controller and the accessory use compatible techniques within the pairing such that any device can successfully authenticate and decrypt messages sent by another device.

In some embodiments, the second accessory may attempt to pair with the controller while the controller is in the process of establishing a pair with the first accessory. For example, in the embodiment of FIG. 1, while the controller 100 is in the process of establishing a pair with the speaker 120, the printer 110 can send a probe request to initiate a pairing procedure. Controller 100 can be configured to handle this situation in a variety of ways.

In some embodiments, once the first pairing procedure is initiated, the controller remains in the first program and ignores additional probe requests attempting to initiate pairing until the first program is completed or aborted. In other embodiments, if a second request for the initial pairing is received while the first program is still continuing, the controller may abort the first program and begin the second pairing procedure based on the second request. The latter design choice may be helpful if the user makes a mistake during the pairing process or changes his mind and wants to start again; the user does not have to wait for the first program to complete or time out. In other embodiments, the controller can be configured to manage multiple pairing programs simultaneously.

Similarly, it is possible that the accessory can receive browsing probes from multiple controllers. In some embodiments, the accessory can respond to the first controller from which it received the browsing probe and ignore any subsequent browsing probes until the pairing with the first controller ends. In other embodiments, if a browsing probe is received while the pairing is in progress (already established or in the process of being established), the accessory may terminate the current pairing and start a new one by responding to the most recent browsing probe. Pairing procedure. In embodiments where the accessory has a user interface, the accessory can prompt the user whether to terminate the current pairing in response to a new browsing probe.

As mentioned above, the procedure 800 and the procedure 900 cause pairing (secure wireless link) between the controller and the accessory. Each device can verify another device, and both devices can establish a shared secret that may be difficult for any good person monitoring the wireless communication to determine. Once established, pairing can be used for secure (encrypted and/or authenticated) communications. 11 and 12 are flowcharts of a procedure for transmitting and receiving a secure message via wireless pairing, in accordance with an embodiment of the present invention.

11 illustrates a procedure 1100 for a transmitter (which may be an accessory or controller) to transmit a message to a sink device that is paired with the transmitter, in accordance with an embodiment of the present invention. After pairing is established, for example, using any of the procedures described above, the routine 1100 begins (step 1102). At step 1104, the sender can prepare a message to be sent securely. This preparation may include, for example, generating data, extracting stored information, formatting or encoding the data, and the like. At step 1106, the sender can encrypt the message using an encryption key associated with the pairing (eg, using an AES key generated by any of the procedures described above). At step 1108, the sender may generate random data (e.g., 16 bytes) to be used as a temporary random number for authentication purposes. At step 1110, the sender can generate based on the message, the temporary random number, and an authentication key associated with the pairing (eg, using the Poly1305-AES code generated by any of the procedures described above) Identification code (data block).

At step 1112, the sender can transmit a probe (which can be a probe request or a probe response) including the encrypted message, the temporary random number, and the authentication code data block. These items can be stored in the probe as information elements or other data elements. The transmitter may also include the job phase ID associated with the pairing in the probe. In some embodiments, only the message itself is encrypted; other items such as the job phase ID and the temporary random number are not encrypted. (The cryptographic technique can be used to generate the authentication code without further encrypting the authentication code.) Once the probe request is sent, the program 1100 can end (step 1114).

Figure 12 illustrates a procedure 1200 for receiving a message from a transmitter device that is paired with the receiver, which may be a receiver (which may be a controller or an accessory), in accordance with an embodiment of the present invention. In this example, it is assumed that the message 1100 is used to send the message. After pairing is established, for example, using any of the procedures described above, the process 1200 begins (step 1202). At step 1204, the receiving end can receive a probe (which can be a probe request or a probe response) that includes a job phase identifier associated with the pairing. At step 1206, the receiving end may extract the encrypted message, the temporary random number, and the authentication code block from the probe. At step 1208, the receiving end can verify the reliability of the message using the authentication code and the temporary random number and its own authentication key (eg, its Poly1305-AES code as described above). If the reliability is verified at step 1210, the receiving end may continue to decrypt the encrypted message at step 1212. In this embodiment, if the reliability is not verified at step 1210, the receiving end can directly ignore the message.

The process 1200 ends at step 1214. Assuming that the message is authenticated and decrypted, the receiving end can act on the message by a specific action depending on the content of the message. As mentioned previously, any type of configuration information, control signals, or other material may be included in the encrypted message sent using the probe. In some embodiments, responding to the message can include using the probe to send the encrypted message back to the sender. In this case, the receiving end becomes the transmitter using the program 1100; thus, the same device can operate as a transmitter at one time and as a receiving end at another time.

It should be understood that the communication procedures described herein are illustrative and that variations and modifications are possible. The steps described as sequential steps may be performed in parallel, the order of the steps may be changed, and the steps may be modified, combined, added or omitted. The techniques identified in this article can be replaced with other encryption techniques.

As mentioned, the program 1100 and the program 1200 can be used to communicate any desired information between the accessory and the controller. In some embodiments, the controller can be added to a conventional wireless network (eg, an IEEE 802.11 compliant network) while paired with the accessory. Once the pairing is established, the controller can use the secure join to provide the accessory with the credentials (eg, network name and password) needed to join the wireless network.

13 is a flow diagram of a procedure 1300 for accessing a wireless network by an accessory (eg, accessory 110 or accessory 120 of FIG. 1) in accordance with an embodiment of the present invention. In this procedure, it is assumed that the wireless network is managed by an access point that determines whether other devices can join the network and access various resources (e.g., the Internet) via the access point.

The process 1300 begins at step 1302 where the accessory determines that it should attempt to join the wireless network. This determination can be made automatically at device startup, in response to user input, or otherwise. At step 1304, the accessory may listen to a browse probe request from a controller capable of establishing a pair with the accessory. The controller can be (but need not be) a network access point and does not require the accessory to have any information about the existence of access credentials for any wireless network.

At step 1306, the accessory can determine if a browsing probe is detected. If no browsing probes are detected, the accessory may continue to listen (step 1304) or end program 1300. If a browse probe is detected, the accessory can communicate with the controller (e.g., using additional probes) to establish a pairing at step 1308. For example, the procedure 800 and the procedure 900 described above can be used.

Once the pairing is established, at step 1310, the accessory can obtain credentials for the wireless network (e.g., network name and password) from the controller via the pairing link. For example, the procedure 1100 and the procedure 1200 described above can be used in which the wireless network credentials are included in an encrypted message sent by the controller to the accessory (eg, in a probe request). The controller can (but need not) join the wireless network when the controller supplies the credentials to the accessory. In some embodiments, the accessory does not explicitly request the network credential; the controller can be configured to automatically send the credential once the pairing is established (eg, in the probe request). In other embodiments, step 1310 can include transmitting a request for a credential to the controller (eg, using probing).

At step 1312, the accessory can send the wireless network credentials to the network access point. The voucher or information derived from the voucher can be securely transmitted to the access point using conventional techniques such as WEP, WPA or WPA2 (in the context of an IEEE 802.11 compliant network).

At step 1314, the accessory can wait for an acknowledgment as to whether it has successfully joined the network. If not, the routine 1300 may end at step 1316, or the accessory may be retried (eg, return to step 1312 to resend the credentials or return to step 1310 to obtain a new credential).

After joining the network, the accessory can communicate with other devices on the network using a wireless network protocol (step 1318). In some embodiments, pairing with the controller can be terminated once the accessory has joined the wireless network. In other embodiments, the pairing phase can remain infinitely open, allowing the controller and accessories to communicate in the sideband regardless of whether any device remains attached to the wireless network.

In some embodiments, the user can control the process of pairing and joining the network by interacting with the controller. 14 is a flow diagram of a process 1400 that may be executed by a controller to facilitate the addition of an accessory to a wireless network, in accordance with an embodiment of the present invention.

When the controller is ready to pair with the wireless accessory, the process 1400 begins (step 1402). For example, a user can launch an application on the controller that provides a control interface for communicating with the wireless device. In some embodiments, the program can be a program for playing media assets that can stream digital media data to an accessory via a wireless network (for example, provided by Apple, the assignee of the present application) Media asset management program).

At step 1404, the controller can receive an instruction from the user to locate the wireless accessory. For example, the user can interact with the application to command the controller to search for wireless accessories. At step 1406, the controller can broadcast a browsing probe, for example, indicating that the controller is searching for a probe request for the accessory to be paired.

At step 1408, the controller can receive a probe response from the accessory. As described above, this probe response can include information about the accessory. At step 1410, the controller can display information about the accessory (eg, information extracted from the probe response) to the user. At step 1412, the controller can receive confirmation from the user that the corresponding correspondence continues. If an acknowledgment is not received, the routine 1400 may end (step 1414) or return to step 1406 to search for probe requests from different widgets.

Once the acknowledgment is received at step 1412, the controller may begin a key agreement procedure with the accessory (e.g., the procedure 800 described above) at step 1416. At step 1418, as part of the key negotiation, the controller can display the password for user confirmation (eg, as described above). At step 1420, the user can confirm the password. If the password is not confirmed, the routine 1400 may end at step 1422 or return to the earlier step and try again. If the password is confirmed, the controller can complete the pairing at step 1424 (eg, complete the routine 800). In some embodiments, completing the pairing can include sending a probe to the accessory to confirm that the pairing has been established.

Once the pairing is established, at step 1426, the controller can send the wireless network credentials to the accessory via the pairing link, for example, using the procedure 1100 and the procedure 1200 described above, wherein the wireless network credentials are included in the controller. Sended to the encrypted message of the attachment (for example, in the probe request). In some embodiments, the controller may obtain user input to select a network for the accessory to join; or the controller may automatically select a wireless network to which the controller has joined or previously identified (eg, by the user) The preferred wireless network. In some embodiments, the controller can be configured to automatically send the credential to the accessory (eg, in the probe request) once the pairing is established. In other embodiments, step 1426 can include receiving a request for credentials from the accessory; the request can be sent via the paired link using the probe.

At step 1428, the controller can determine if the accessory has joined the network. If not, the routine 1400 may end at step 1430 or return to an earlier stage and retry, or the routine 1400 may wait at step 1428 until the accessory joins or until other user instructions are received. Once the accessory has joined the network, the controller can communicate with the accessory via the wireless network, for example, at step 1432 to stream the media data to the accessory.

As mentioned above, in some embodiments, pairing can be established using password based authentication instead of key negotiation. 15 is a flow diagram of a procedure 1500 that may be used by a controller to facilitate the addition of an accessory that supports password-based authentication to a wireless network, in accordance with an embodiment of the present invention.

When the controller is ready to pair with the wireless accessory, the process 1500 begins (step 1502). At step 1504, the controller can receive an instruction from the user to locate the wireless accessory. At step 1506, the controller can broadcast a browse probe; and at step 1508, the controller can receive a probe response from the accessory. These steps can be substantially similar to the corresponding steps in the procedure 1400 described above.

At step 1510, the controller can display information about the accessory to the user. In this example, the probe response received from the accessory at step 1508 can include an indication of the use of password-based authentication for the accessory, and at step 1512, the controller can, for example, use the prompt screen of FIG. Prompt the user to type the accessory password. At step 1514, the keystroke can serve as an acknowledgment that the controller should continue; if the password is not typed (eg, the user cancels the operation), the routine 1500 can end at step 1516.

At step 1518, the controller may establish a pairing with the accessory based in part on the password supplied by the user at step 1510 (eg, according to the procedure 900 described above).

Once the secure pairing link is established, the controller can send the wireless network credentials to the accessory via the join at step 1520. This step can be substantially similar to step 1426 of the procedure 1400 described above.

At step 1522, the controller can determine if the accessory has joined the network. If not, the routine 1500 may end at step 1524 or return to the earlier process and retry, or the controller may wait at step 1522 until the accessory joins or until other user instructions are received. Once the accessory has joined the network, the controller can communicate with the accessory via the wireless network, for example, at step 1526 to stream the media data to the accessory.

It should be understood that the network joining procedures described herein are illustrative and that variations and modifications are possible. The steps described as sequential steps may be performed in parallel, the order of the steps may be changed, and the steps may be modified, combined, added or omitted. The accessory and controller can use various techniques to establish a pairing, allowing the accessory to obtain credentials for the wireless network, and the accessory can then join the network. In addition, although the controller is described as providing wireless network credentials to the accessory, it should be understood that the pairing described herein can support two-way communication and that the accessory may also provide network credentials (or other configuration information or controls). Signal) to the controller.

Although the invention has been described in terms of specific embodiments, those skilled in the art will recognize that many modifications are possible. For example, although it is contemplated that a probe request and probe response frame defined for such a network can be used to practice the invention in the context of an IEEE 802.11 compliant wireless network, including vendor specific information elements to provide the above The various data items described, but it is also contemplated that other wireless protocols (existing or future) may include message formats that may be used to convey information between devices that have not joined the network. Embodiments of the invention may also be adapted for use in such agreements. Thus, although specific information is described herein as being included in probe requests or probe responses, this use is illustrative and the general term "probe" can be understood to include probe requests and probe responses and can be added to the common Other message formats exchanged between the two wireless devices on the network.

In the embodiment described above, the pairing procedure can be initiated by the controller broadcasting a browse probe request, and the paired accessory is required to respond to the browse probe request. As mentioned above, the controller need not be able to receive probe requests or respond to probe requests in such embodiments. In some alternative embodiments, the pairing procedure can be initiated by the accessory broadcasting a probe request, and the controller can respond to the probe request to indicate that the controller is available to pair with the accessory.

Additionally, although specific cryptographic techniques are referenced for purposes of illustration, it should be understood that the present invention is not limited to any particular cryptographic techniques, with the limitation that the controller and the accessory use compatible techniques.

Although the embodiments described above refer to specific hardware and software components, those skilled in the art will appreciate that different combinations of hardware and/or software components can also be used and are described as specific operations implemented in hardware. Specific operations that can also be implemented in software and described as being implemented in software can also be implemented in hardware.

Circuitry, logic modules, processors, and/or other components can be configured to perform the various operations described herein. Those skilled in the art will appreciate that depending on the implementation, this configuration can be accomplished through the design, setup, interconnection, and stylization of specific components, and again depending on the implementation, the configured components may or may not be reconfigurable. For different operations. For example, a programmable processor can be configured by providing suitable executable code; dedicated logic can be configured by suitably connecting logic gates and other circuit components;

Computer programs incorporating the various features of the present invention can be encoded on a variety of computer readable storage media; suitable for media including magnetic or magnetic tape, optical storage media such as compact disc (CD) or DVD (digital audio and video discs), fast Flash memory and similar. A computer readable storage medium encoded with a code may be packaged with a compatible device or separately from other devices. In addition, the code can be encoded and transmitted via wired optical and/or wireless networks that follow various protocols, including the Internet, allowing for dissemination, for example, via the Internet.

Accordingly, while the invention has been described with respect to the specific embodiments thereof, it is understood that the invention is intended to cover all modifications and equivalents

100. . . Controller

110. . . Accessories / printer

112. . . pair

120. . . Accessories / Speakers

122. . . pair

200. . . Controller

202. . . processor

204. . . user interface

206. . . Wireless interface

208. . . Storage medium

210. . . Network credentials

300. . . Accessory

302. . . processor

304. . . user interface

306. . . Wireless interface

308. . . Storage medium

310. . . Print component

400. . . Accessory

402. . . processor

406. . . Wireless interface

408. . . Storage medium

410. . . speaker

412. . . Device password

500. . . Probe frame

502. . . Frame control field

504. . . Duration field

506. . . Address field

508. . . Sequence field

510. . . Data field

512. . . Sum check code field

520. . . Information element

522. . . Element ID field

524. . . Length field

526. . . Vendor field

528. . . Subtype field

530. . . Sub-IE field

540. . . Sub-IE

542. . . Type identifier field

544. . . Length field

546. . . Payload

600. . . program

700. . . program

800. . . program

900. . . program

1000. . . Windows

1002. . . title

1004. . . prompt

1006. . . text box

1008. . . Prompt message

1100. . . program

1200. . . program

1300. . . program

1400. . . program

1500. . . program

Figure 1 illustrates the principle of operation used in certain embodiments of the present invention.

2 is a block diagram of a controller in accordance with an embodiment of the present invention.

3 is a block diagram of an accessory in accordance with an embodiment of the present invention.

4 is a block diagram of an accessory in accordance with another embodiment of the present invention.

Figure 5 is a block diagram of a probe frame structure that can be used in some embodiments of the present invention.

6 is a flow diagram of a procedure by which an accessory can be used to establish a pair with a controller in accordance with an embodiment of the present invention.

7 is a flow diagram of a procedure that can be used by a controller to establish a pair with an accessory in accordance with an embodiment of the present invention.

8A-8B are flow diagrams of a procedure for establishing pairing between a controller and an accessory in accordance with an embodiment of the present invention.

9A-9B are flow diagrams of a procedure for establishing pairing between a controller and an accessory in accordance with an embodiment of the present invention.

Figure 10 illustrates a password prompt that can be displayed on a controller in accordance with an embodiment of the present invention.

Figure 11 illustrates a procedure that can be used by a transmitter (which can be an accessory or controller) to send a message to a sink device that is paired with the transmitter, in accordance with an embodiment of the present invention.

Figure 12 illustrates a procedure for receiving a message from a receiving device (which may be a controller or an accessory) from a transmitter device paired with the receiving end, in accordance with an embodiment of the present invention.

13 is a flow diagram of a process by which an accessory can be used to join a wireless network, in accordance with an embodiment of the present invention.

14 is a flow diagram of a process executable by a controller to facilitate the joining of an accessory to a wireless network, in accordance with an embodiment of the present invention.

15 is a flow diagram of a process that can be used by a controller to facilitate the joining of an accessory to a wireless network, in accordance with an embodiment of the present invention.

100. . . Controller

110. . . Accessories / printer

112. . . pair

120. . . Accessories / Speakers

122. . . pair

Claims (24)

A method for establishing a wireless communication link between an accessory and a controller, the method comprising: receiving, by the accessory, a first probe from a controller, the first probe indicating the control Is searching for one of the accessories to be paired; the accessory sends a second probe to the controller in response to the first probe; the accessory establishes a shared secret with the controller, wherein the shared secret is established Including exchanging a public key with the controller using a plurality of additional probes, the plurality of additional probes including at least one third probe transmitted by the accessory and a fourth probe received by the accessory, wherein the third probe and The fourth detection system is at least one of a probe request frame or a probe response frame, wherein the corresponding public key is included in a predetermined information element; and the common secret is verified by the accessory. Used by the accessory to generate an additional cryptographic key using the common secret; the accessory receives a fifth probe from the controller, the fifth probe containing an encrypted Message; and the use of additional cryptographic key for decoding of the encrypted message. The method of claim 1, wherein the establishing a shared secret from the controller by the accessory comprises: receiving the fourth probe from the controller, the fourth probe comprising a controller public key; Generating an accessory private key and an accessory public key from the accessory; the third probe is sent to the controller by the accessory, the third probe includes the accessory public key; and based on the The controller public key and the accessory public key calculate a common secret. The method of claim 2, wherein verifying, by the accessory, the shared secret is shared by the controller comprises: calculating, by the accessory, a password based on the shared secret; and presenting the password to a user by the accessory. The method of claim 1, wherein the establishing a shared secret from the controller by the accessory comprises: generating, by the accessory, a fixed public key using a fixed password; generating an optional salt from the accessory; Transmitting the third probe to the controller, the third probe comprising the accessory public key and the random salt; receiving, by the accessory, the fourth probe from the controller, the fourth probe comprising a controller A public key and a controller response based on the one of the random salts; and the common key is calculated by the accessory using the controller public key, the controller private key, and the random salt. The method of claim 4, wherein verifying, by the accessory, that the shared secret is shared by the controller comprises: verifying, by the accessory, the common secret to verify the controller response; An attachment response is calculated by the accessory using the shared secret; and a sixth probe is sent by the accessory to the controller, the sixth probe including the accessory response. The method of claim 1, wherein the encrypted message comprises a credential associated with a wireless network having an access point, the method further comprising: requesting, by the accessory, to join the wireless network Transmitted to the access point, the request is based at least in part on the credential. An accessory comprising: a wireless interface; and a processor coupled to the wireless interface, the processor configured to: receive, by the wireless interface, a browsing probe request sent by a controller, the browsing Detecting that the controller is available for pairing; transmitting an identified probe response via the wireless interface in response to the browse probe request, the identified probe response including accessory identification information; establishing a pair with the controller; using a plurality of additional probes Exchanging a public key with the controller, the plurality of additional probes including at least one third probe transmitted by the accessory and a fourth probe received by the accessory, wherein the third probe and the fourth probe are At least one of a probe request frame or a probe response frame, wherein the corresponding public key is included in a predetermined information element; and the wireless interface is received from the controller via the wireless interface One of the credentials, wherein the voucher is received as an encrypted information element in one of the additional probe requests received from the controller; and the voucher is used to join the wireless network. The accessory of claim 7, wherein each of the browsing probe request and the additional probe request includes a probe request frame conforming to one of the IEEE 802.11 series standards and the frame response is in accordance with the IEEE 4 802.11 series of standards One of the probe response frames. The accessory of claim 7, further comprising: a speaker, wherein the processor is further configured to: receive the streamed audio material from the controller via the wireless network, wherein the receiving is in the wireless After the network occurs; converting the streamed audio data into an analog signal; and using the analog signal to drive the speaker. The accessory of claim 7, further comprising: a printing element, wherein the processor is further configured to: receive data from the controller via the wireless network, wherein the receiving occurs after joining the wireless network; And in response to the data, the printing element is driven to produce a printed product. A method for establishing a wireless communication link between an accessory and a controller, the method comprising: Broadcasting, by the controller, a first probe indicating that the controller is browsing to find an accessory to be paired; receiving, by the controller, a second probe from an accessory, the second probe including the accessory Identification information of the device; a common secret is established by the controller and the accessory, wherein the shared secret includes using the first probe and the second probe or receiving a fourth probe by the controller and sending by the controller One of the fifth probes exchanges a public key with the accessory, wherein each of the probes is at least one of a probe request frame or a probe response frame, wherein the corresponding public key system Included in a predetermined information element; the controller verifies that the shared secret is shared by the accessory; the controller uses the shared secret to generate an additional cryptographic key; the controller compiles with the additional cipher The key encrypts a message; and the controller sends a third probe to the accessory, the third probe including the encrypted message. The method of claim 11, wherein the establishing the shared secret comprises: extracting, by the controller, the public key of the accessory from the second probe; and the public key based on the accessory and the common to the controller The key is used to calculate a secret. The method of claim 11, wherein the encrypted message comprises a credential that can be used by the accessory to join a wireless network. The method of claim 13, further comprising: communicating, by the controller, the accessory via the wireless network after transmitting the encrypted message including the credential. The method of claim 14, wherein communicating with the accessory via the wireless network comprises streaming media content to the accessory via the wireless network. The method of claim 11, further comprising: receiving, by the controller, a sixth probe from the accessory, the sixth probe including another encrypted message. A controller, comprising: a wireless interface; a user interface; and a processor coupled to the wireless interface and the user interface, the processor configured to: detect from the wireless interface via the wireless interface a first detection of the accessory, the first detection comprising accessory identification information; communicating via the user interface to confirm that the accessory is to join a wireless network; communicating with the accessory via the wireless interface to establish a pairing, The establishing the pairing includes: exchanging information with the accessory using a plurality of additional probes, the plurality of additional probes comprising receiving, by the controller, a third probe and a fourth probe sent by the controller, the third probe And each of the fourth detections is at least one of a probe request frame or a probe response frame, wherein the information is included in a predetermined information Within the element; and obtaining a confirmation of a shared secret via the user interface; and after establishing the pairing, transmitting a voucher associated with the wireless network to the accessory via the wireless interface, wherein The voucher is sent in one of the five probes in the encrypted message. The controller of claim 17, wherein the processor is further configured to communicate via the user interface to confirm that the accessory is to join the wireless network comprises: extracting the accessory identification information from the first probe; The user interface presents at least a portion of the extracted accessory identification information to a user; and receives, via the user interface, the accessory to join the wireless network for confirmation. The controller of claim 17, wherein the processor is further configured to communicate with the accessory via the wireless interface to establish the pairing comprising: generating a controller public key by the controller; The fourth probe is sent to the accessory, the fourth probe includes the controller public key; the third probe is received by the controller, the third probe includes an accessory public key; at least part of the controller Calculating the shared secret based on the controller public key and the accessory public key; calculating, by the controller, a password according to the shared secret; the controller presents the password to a use via the user interface Receiving, by the controller, the password through the user interface to match a confirmation of a password calculated by the accessory; and calculating an additional encryption key using the shared secret, wherein the additional encryption key is used for encryption The voucher. The controller of claim 17, wherein the processor is further configured to: after transmitting the credential, confirm that the accessory has joined the wireless network; and after confirming that the accessory has joined the wireless network, via The wireless network sends the data to the accessory. The controller of claim 17, wherein each of the probes comprises a probe request frame or a probe response frame that conforms to one of the IEEE 802.11 family of standards. A controller, comprising: a wireless interface; a user interface; and a processor coupled to the wireless interface and the user interface, the processor configured to: detect from the wireless interface via the wireless interface First detection of one of the attachments, the first detection comprising attachment identification information; communicating via the user interface to confirm that the accessory is to join a wireless network, comprising receiving an accessory password via the user interface; The wireless interface communicates with the accessory to establish a pairing Establishing the pairing includes exchanging information with the accessory using a plurality of additional probes, the plurality of additional probes including at least one of the third probes received by the controller and a fourth probe transmitted by the controller, the third probe And each of the fourth detections is at least one of a probe request frame or a probe response frame, wherein the information is included in a predetermined information element, and the exchanged information includes a password based on the accessory password. And after the pairing is established, a voucher associated with the wireless network is sent to the accessory via the wireless interface, wherein the voucher is sent in an encrypted message included in a fifth probe. The controller of claim 22, wherein the processor is further configured to communicate via the user interface comprising: extracting the accessory identification information from the first probe; and attaching the extracted via the user interface At least a portion of the piece identification information is presented to a user. The controller of claim 23, wherein the processor is further configured to communicate via the user interface further comprising: extracting password location information from the first probe indicating that the user can find the location of an accessory password And providing a password prompt to the user, the password prompt containing a location indicator based on the password location information.