Patent Application
20080069026
Preferred embodiments of the present invention will be explained in further detail below by way of examples and with reference to the accompanying drawings, in which:
In this specification, reference to the term WUSB should include references to WUSB and WUSB compatible wherever the context is appropriate or permits, and without loss of generality.
An exemplary system of this invention comprising a WUSB compatible host 100, a WUSB compatible repeater 101 and a WUSB compatible device 102, is depicted in
To support data communication between a WUSB host and a WUSB. device, the repeater would consist of at least four endpoints, namely, a default control endpoint, an interrupt endpoint, a bulk OUT endpoint and a bulk IN endpoint. These endpoints are standard WUSB endpoints which have the same transfer characteristics as described in “Wireless Universal Serial Bus Specification (Revision 1.0), 12 May 2005 by Universal Serial Bus Implementers Forum (USBIF), including all published errata, which is incorporated herein by reference.
Specific functions of these endpoints in the WUSB repeater are as follows:
The above endpoints are necessary for the repeater to perform data relay function and can be configured into one or more logical WUSB interfaces for better control management. Of course, more endpoints can be added to support additional control functions without loss of generality.
A block diagram of an exemplary WUSB repeater of this invention is depicted in
The PHY transceiver is adapted to receive and transmit radio frequency signals, and to convert radio-frequency signals into base-band digital outputs and vice versa.
The lower MAC processor 205 is adapted to perform the following functions.
The upper MAC is adapted to perform the following.
The WUSB host controller 203 is adapted to perform the following.
It is adapted to perform the following.
It is used to perform the following
It is used to store application image and data for operations.
A functional block diagram of the WUSB repeater CPU is depicted in
An overview of data transfer across the repeater 400 will be described below with reference to
The above illustrates an overview of an exemplary data flow under which a host 100 can communicate with a device 102 Via a repeater 101 over a common PHY channel in a polled TDMA manner. Further details on the manner by which connection and data transfers between the host and the device are accomplished via the repeater will be described further below.
An exemplary sequence of operations leading to subsequent association or connection between the WUSB host 100 and the WUSB repeater 101 will be described below with particular reference to
In the first example, it will be assumed for the sake of convenience that the host 100, the repeater 101, and the device 102 have been successfully associated or connected previously. In addition, it is assumed that the various system components initially operate on the same physical channel PHY A, although the system components can operate in physical channels PHY A, PHY B, and PHY C to be described in other examples. In such a case, security enumeration and device enumeration procedures between the various system components have been successfully performed, and the necessary connection and/or association data are stored or maintained in the various components, that is, the host 100, the repeater 101, and the device 102.
Initially, the system does not have a repeater in operation. This can be modelled by assuming that the repeater 101 is in a “power off” state, while the host 100 and the device 102 are in a “power on” state. When the host 100 attempts to make connection with the device 102, the host 100 will firstly reserve time slots 402 in each superframe on the channel PHY A and then send out MMC packets repeatedly during the reserved time slots 402. Although the device 102 also listens on channel PHY A, no communication between the host 100 and the device 102 could be made because the host and the device are out of communication range. As a result, the device 102 cannot hear the MMC packets sent by the host 101 on PHY channel A, and the host 100 cannot detect the device 102.
To establish the repeater linked connection between the host and the device, the repeater 101 will be powered on first. After the repeater has been powered on and initialised, the repeater will listen on channel PHY A for a prescribed period for MMC packets and starts a “scan timeout” timer. In the meantime, the host will continue to transmit MMC packets, as depicted at step 501 of
In response, the repeater 101 will reserve a time slot within the specified time intervals and transmit a device connect request in step 502 to the host. Upon reception by the host of the device connect request sent by the repeater 101 at step 502, the effective presence of the repeater 101 is successfully detected by the host 100. The host will then send out MMC packets in step 503 with connection acknowledgement information contained therein. Based on the connection acknowledgement information contained within the MMC packet sent in step 503, the repeater 101 will configure its device address in order to prepare for subsequent receipt of control requests from the host 100. Next, the host 100 and the repeater 101 will go through the usual WUSB security enumeration and device enumeration procedures, as indicated in step 504. After that, the host 100 will send control requests in step 505 to the repeater 101 in order to initialize its buffer queues and its ultra-wide band (UWB) radio platform. Next, the host will send out control requests in step 506 to the repeater 101 to configure encryption settings and communication addressing settings of the repeater 101. Finally, the host 100 will send commands in step 507 to the repeater 101 to request the repeater 101 to scan the PHY A physical channel and to reserve time slots in each superframe to startup communication with the WUSB device. Throughout the above set of operational sequences, it will be appreciated that the repeater appears as a WUSB device to the host and the host treats the repeater as a WUSB device. After the enumeration procedures of 504 have been successfully completed, the repeater 101 will stop the scan timeout timer. If the enumeration procedures of step 504 fail before the scan timeout occurs, the repeater 101 will terminate the connection setup operations and listen again during the next superframe.
In operation steps 505, 506 and 507 described above, the host 100 will send a set of commands and control requests to the repeater 101 in order to configure the control and operation settings of the repeater 101. It will be appreciated that, as an alternative or as an option, the host 100 can also utilise a wire adapter (WA) and/or host wire adapter (HWA) class-specific control requests with the similar functions to control the repeater to perform the operation steps 505, 506 and 507. In response, the repeater will return the replies to these control requests following formats specified in the WA and HWA class. In this way, standard WUSB commands can be utilized and there is no need to define new or specific proprietary WUSB control requests or result codes for controlling the WUSB repeaters to perform the operation steps 505, 506 and 507.
Where the device 102 has not been associated previously, initial association procedures between the repeater and the host, and between the host and the device through the repeater will have to be performed. To associate the repeater 101 with the host 100, the Device Control Manager 300 will commence conventional association procedures. The association procedures are identical to the association procedures between a conventional WUSB host and a WUSB device, except with the repeater 101 appearing as a device to the host 100. Likewise, the Host Control Manager 305 will perform association procedures on behalf of the host with the device, and to the device the repeater is behaving as a host in conventional WUSB terms.
An exemplary sequence of steps for establishing a communication link between the repeater and the device will be described below with reference to
After the host setup procedures have been completed successfully, the repeater 101 will prepare for communication with the device 102. Firstly, the repeater will reserve time slots 403 in each superframe. Next, the repeater 101 will generate MMC packets and then transmit the MMC packets on the physical channel during the reserved time slots 403, as depicted in step 601. The MMC packets generated by the repeater 101 will contain the same host information as that sent by the host 100 originally. Upon receipt of the MMC packets, the device 102 will examine the MMC packs to decide whether the host information carried by the MMC packet is matched to the known host 100. If the host information contains authentication or identification information of the known host, that is, a host which has been previously registered with the repeater (a “pre-registered host”), the device 102 will accept the MMC packet and retrieve the host information from the MMC packet. Thereafter, the device will return a device connect request to the repeater within the time interval specified by the schedule information of the MMC packet, as depicted in step 602. It will be appreciated from the above course of operation that the repeater effectively appears as a WUSB host to the device 102.
Upon receipt of the device connect request sent in step 602, the repeater 101 will respond by sending a device connect notification to the interrupt endpoint of the host 100, as depicted in step 603. With the receipt of the device connect notification by the host from the device, the host 100 will also receive the embedded device connect request, which is originated from the device 102. The host 100 will respond by sending a control request to the repeater 101, as depicted in step 604. The control request will request the repeater 101 to include “connect acknowledgement information” in its MMC packets for subsequent forwarding to the device 102 in step 605.
Similar to the procedures for association between the host 100 and the repeater 101, the device 102 will configure its device address after receipt of the MMC packets 605 from the repeater 101, so that the control request from the host 100 can be received during the forthcoming operations. To complete association, the repeater 101 will go through the usual WUSB security enumeration and device enumeration procedures with the device 102, as depicted in step 606. Upon successful security enumeration and device enumeration procedures between the repeater 101 and the device 102, the repeater would be in a position to begin communication with the device. Consequently, the host 100 will be in a position to begin data communication with the device 102 through the repeater 101 as an intermediary, as depicted more particularly in step 607.
In summary, during the security enumeration procedures 606, and the subsequent data communication exchanges of step 607 through the repeater 101, the host 100 will send transfer requests to the repeater 101 and to control the repeater 101 to forward data packets to the device 102 and/or to retrieve data packets from the device 102.
An exemplary sequence of data communications between the host and the device through the repeater will be explained in more detail below with reference to
To cause transfer of a data packet (or a control request) A to the device 102, the host 100 will first send a transfer request (step 701) on the bulk OUT endpoint of the repeater 101. The transfer request will provide the repeater 101 with various information, (for example, data destination information), so that the repeater is informed of the ultimate destination when a packet is next sent to its bulk OUT endpoint from the host 100. In addition, other transfer information, for example, transfer direction (i.e., whether the transfer is for transfer towards the device or the host), transfer type (i.e., whether the transfer type is bulk, interrupt or isochronous), maximum packet size, transfer speed (e.g. 480 Mbps) and burst size, or the like will be sent.
In the instant example, the data destination information will inform the repeater that the next packet to be sent to its bulk OUT endpoint from the host 100 is destined the endpoint with address EP_x on the device having device ID DEV_ID. Next, the repeater 101 will look up from a logical buffer queue (designated as L), which is assigned for handling packets destined for the addressed device endpoint (DEV_ID, EP_x) and update the corresponding transfer information to its transfer descriptor, if appropriate or necessary.
It will be appreciated from the above, especially with reference to
After the transfer request has been received by the repeater as a result of step 701, the repeater will have received the data packet A from the host 100. As specified by the transfer request 701, the repeater 101 is required to deliver this data packet A to the designated or assigned logical buffer queue L. Next, the repeater 101 will transmit the data packet Ato the device 102 within the time slots 403 already reserved according to the transaction schedules as specified in the MMC packets it generated, as depicted by step 703. Upon receipt of the data packet A, the device 102 will return a handshake packet, as depicted in step 704, and in accordance with the transmission schedule of the received MMC packet. After this, the repeater 101 will send a transfer completion notification packet to the host 100 over its interrupt endpoint, as depicted by step 705. Upon receipt of the transfer completion notification sent at step 705, the host 100 will schedule a transfer poll on the bulk IN endpoint of the repeater 101. In response to the polling, the repeater 101 will return a transfer success result via the bulk IN endpoint in accordance with the schedules set by the host 100 in its MMC packet, as depicted by step 707.
Assuming now that the device 102 has another data packet, or a request result packet, (say, packet B), on its endpoint with endpoint address EP_x, which is pending for transmission to the host 100. The device 102 will wait for the next transfer poll from the repeater with an endpoint address EP_x. As noted above, the Transfer Manager 304 will work with the Host Control Manager 305 to schedule transfer polls on the device 102. Thus, the scheduling is based on transfer information of the logical queues assigned for its endpoints. After the transfer poll on the endpoint EP_x has been received, the device 102 will in accordance with the transmission schedule specified in the MMC packets for the endpoint EP_x transfer the packet B to the repeater 101, as depicted by step 708. Upon receipt of the packet B, the repeater 101 will place the packet B into the logical buffer queue which has been assigned for this device endpoint address (DEV_ID, EP_x) for consequent forwarding to the host.
After the packet B has been placed on the logical buffer queue, the repeater will wait for the next transfer request poll from the host polling for the device endpoint with the specific address (DEV_ID, EP_x). Upon receipt of the transfer request, and as depicted by step 709, the repeater 101 will send a transfer completion success notification to the host 100 via the interrupt endpoint, as depicted by step 710. Next, the host 100 will send a transfer poll on the bulk IN endpoint of the repeater 101, as depicted by step 711. In response, the repeater will return a transfer success result packet, as depicted by step 712. Finally, the data packet B will be retrieved from the logical queue addressed (DEV_ID, EP_x) and forwarded to the host 100 in accordance with the transmission schedule specified in the MMC packets generated from the host 100, as depicted by step 713. It will be appreciated that, in this specific example, the host 100 is required to schedule transfer polls for the endpoints on the repeater 101 and the device 102 according to their respective endpoint characteristics.
The repeater can also operate an alternative scheme for forwarding data packets from the device to the host. An example of such an alternative scheme will be described below with reference to
Likewise, the host 100 can make use of the wire adapter (WA) class-specific transfer request command to inform the repeater 101 about the transfer information and request the repeater 101 to assign logical queues for handling the various forthcoming data transfers, and to perform operation steps 505, 506 and 507. The repeater 101 will operate in accordance with the formats specified in the various WUSB standards to respond to those WA class specified requests. Hence, there is no need to define any proprietary control requests or commands for handling the data transfer operations.
In a preferred embodiment, the system components, namely, the host, the repeater and the device can operate in any one of a plurality of physical channels, namely, say, PHY A, PHY B, or PHY C. Assuming for the sake of convenience that the host is initially operating on PHY A, the host will repeatedly and sequentially send MMC packets on PHY A, PHY B and PHY C during the reserved time slots 402. By the device electing to respond through a specific physical channel, for example, PHY B, and not through other physical channels, the repeater could be the de facto commander with power to determine the preferred physical channel of communication, even though the host is the dominant component in a conventional WUSB environment.
An exemplary control configuration of the host 100 for implementing control of a connected host controller for communicating with the device 102 via the repeater 101 is depicted in
The configuration of
The WUSB Repeater Control Driver 803 is adapted for communication with the WUSB Host Control Driver 804 via the USB bus driver interface during operation. This WUSB Repeater Control Driver 803 is adapted to configure and control the repeater 101 through the WUSB Host Control Driver 804, for example, for performing the operation steps 505, 506 and 507. Moreover, the WUSB Repeater Control Driver 803 is also responsible for configuring the device which is connected to the repeater and for managing all data transfers between the repeater and the device. For instance, the WUSB Repeater Control Driver 803 can control the repeater 101 to go through the procedure steps 605, 606 and 607 to connect and then communicate with the device 102. Similar to the WUSB Host Control Driver 804, the WUSB Repeater Control Driver 803 comprises software interfaces which are compatible with the existing USB bus driver interface. The WUSB Repeater Control Driver 803 uses this interface to communicate with the existing WUSB device drivers and provides the existing WUSB device drivers with necessary data transfer capability to communicate with the devices connected to the repeater. In this example, the WUSB Client Device Driver 802 can utilize this driver interface to communicate with the device 102 through the repeater 101, noting that the repeater 101 can use transfer requests as well as transfer completion notifications for forwarding data between the host 100 and the device 102. The WUSB Repeater Control Driver 803 is responsible for handling data forward control operations, for example, to support data transfer requests from the WUSB Client Device Driver 802. Moreover, the WUSB Repeater Control Driver 803 is also adapted to provide additional software interface functions for the WUSB Repeater Application Software 801 to configure and control the repeater 101. The WUSB Repeater Application Software 801 is an application program which provides user interfaces for controlling and configuring the repeater.
As depicted in
Similar to the loading of a WUSB device driver onto a WUSB host in a host and device arrangement of a conventional WUSB environment, the WUSB Repeater Control Driver 803 of the repeater is loaded to the host software system by the WUSB Host Control Driver 804 after completion of operation step 504. At this instant, the WUSB repeater will be recognized by the host as a WUSB device.
After that, the WUSB Repeater Control Driver 803 will work with the WUSB Host Control Driver 804 to communicate with the repeater 101. The loading of the WUSB Repeater Control Driver is performed by the system kernel function, like, for example, the plug and play manager in the Windows® system. As an alternative implementation scheme, the WUSB Repeater Control Driver 803 can be set to be in constant connection with the WUSB Host Control Driver 804 after its installation. As a further example, the WUSB Repeater Control Driver 803 can include an option whereby a user can disable its function via the WUSB Repeater Application Software. Upon disabling, the WUSB Repeater Control Driver 803 will become a dummy function and the WUSB Client Device Driver 802 will then talk to the WUSB Host Control Driver 804 directly and communicate with the device 102 via the host controller hardware with no repeater function involved, since the host and the device are already mutually recognized.
It will be appreciated from the description above that the repeater of this invention comprises at least one WUSB compatible device, and therefore, the repeater supports at least one WUSB standard compatible association methods. In addition, the repeater also provides means for a WUSB compatible host to perform standard numeric association with a WUSB compatible device indirectly. For brevity, this indirect numeric association will be referred to below as “remote numeric association”. Details of the numeric association are described in the documentation entitled “Association Models Supplement to the Certified Wireless Universal Serial Bus Specification (Revision 1.0) published 2 Mar. 2006, which is incorporated herein by reference.
An exemplary set of remote numeric association between a WUSB host and a WUSB device through a WUSB repeater of this invention will be described below with reference to
Assuming that the repeater 101 has been associated with the host 100 previously but the device 102 is new to the host 100. To associate the repeater 101 with the device 102, it is necessary to condition the host 100 in order to start association via the repeater 101, as depicted in operation step 901. The WUSB Repeater Application Software 801 in the host software system would provide means for a user to command the host 100 to start association on the desired repeater. In particular, the user is required to select which repeater and via which means to establish association.
Initially, the host 100 will send a control request to the repeater 101 so that device association start information is included in its MMC packets (see operation 903). Next, the device 102 is conditioned to start the association process (operation step 902). Of course, it will be appreciated that operation step 902 can be finished before operation step 901. Upon completion of operation step 902, the device 102 will start listening on a physical channel PHY until it has received a MMC packet 904 from the repeater 101. With the received device association start information which is contained in the MMC packet 904, the device 102 will follow the standard WUSB numeric association procedures and send out a device connect request with a new connection bit set within the time interval specified by the MMC packet 904. Similar to the operation 602 described above, the repeater 101 will send a device connect notification to the host 100. Upon detection of the presence of a new device by the host 100, the host 100 will start to go through standard connection acknowledgement and security protocols with the device 102 through the repeater 101 (see operation step 906). The exchange of control requests and results between the host 100 and the device 102 can be achieved using the transfer request control operations described in
After operation step 906 has been completed, the host 100 and the device 102 will have obtained the security information necessary for establishing a secure connection between them. The security key digest will be displayed and a user can examine if they are the same. Of course, the checking can be performed by electronic or software means. If the security key digests are correct, the host 100 and the device 102 will be conditioned to continue the association process (operation 909). The host 100 will then transfer non-private information (e.g. host ID and device ID) to the device 102 using, for example, the assigned security key (operation 910). Afterwards, the related connection information will be saved in their respective local memories (operations 911 and 912). Finally, the host 100 will go through the normal WUSB protocols (as described in operation 606) to connect the device 102. The device 102 is now associated with the host 100 via the repeater 101 and can communicate with it afterwards.
It will be appreciated that, throughout the data forwarding operations described above, the repeater 101 does not need to know the contents of the forwarded packets and the corresponding security key. Thus, operation of the repeater does not require modifications on the existing WUSB security framework.
In addition to the single transceiver architecture presented in
The CPU, the WUSB Device Controller, the WUSB Host Controller and the Upper MAC Processors of
The WUSB repeater of this invention can be connected to more than one device, so that communications can be facilitated between a plurality of devices and the WUSB host, as described below with reference to
Specifically, the device 102 includes three endpoints, with the addresses EP_x, EP_y and EP_z. On the other hand, the device 103 has four endpoints, with addresses EP_a, EP_b, EP_c and EP_d. In this application, the repeater 101 will assign a total of seven logical buffer queues, namely, L—0, L—1, L—2, L—3, L—4, L—5, L—6, where
These logical queues are managed in the same manner as when a single device is connected to the repeater described above. The total number of WUSB devices that can be connected to a repeater is limited by the number of the logical queues supported by the repeater. Moreover, the WUSB repeaters of this invention can be connected in cascade between the host and the device, as depicted in
To set up a communication link between the host 100 and the device 102, the host 100 will connect with the repeater 101 first, following the operations described above, especially with reference to
A typical WUSB packet is depicted in
More particularly, the Security Information 1306 contains keying material, freshness values, and encryption mode information. The WUSB packet payload 1305 contains WUSB protocol data and status information. The Message Integrity Code (MIC) 1304 is an integrity value, which is generated by computing the whole WUSB packet load using an encryption key assigned for the authenticated host to communicate with the authenticated device (which is the destination or source of the frame). The MIC is used by the receiver to check if the WUSB packet payload has been modified by any unauthorized party. Similar to conventional systems, the Security Information 1306 immediately precedes the encrypted data (which is the WUSB Packet Payload 1305). The MIC 1304 field immediately follows the encrypted data. The WUSB Packet Payload 1305 can be encrypted or un-encrypted, depending on the control value setting in the Security Information 1306. A WUSB data packet is said to be in secure encapsulation if the frame containing it has the security information 1306 and the MIC 1304.
In typical WUSB systems, communications between the host and the device are encrypted using keys which are possessed only by the authenticated host and authenticated device. The host maintains a separate or individual key for each connected device. The host then uses an individual key to encrypt all data packets (i.e. WUSB packet payload 1305) which are sent to the corresponding device and to decrypt all packets received from that corresponding device. Therefore, frames containing these data packets must have the correct associated Security Information 1306 and the Message Integrity Code 1304.
It is worth noting that the Security Information 1306 and the Message Integrity Code 1304 are not present in the frame payload 1302 in data exchanges occurring during the association and the authentication phases. Specifically, a WUSB Packet Payload 1305 is transferred in plain text, i.e., not encrypted by any encryption key, during the association and the authentication phase. This is because it is during the association phase and the authentication phase that a host assigns and distributes an encryption key to a device. Hence, a device has no key to encrypt or decrypt when data packets are sent to or are received from a host before the association and the authentication phases have completed. Stated simply, all communications between a host and a device are not encrypted during these phases.
Exemplary steps and/or procedures for performing an exemplary security enumeration phase of the exemplary WUSB repeater system of
As depicted in
On the device side, the device 102 will have been set to listen for MMC packets with device association start information after the device has been conditioned in operation 902. After MMC packet 904, which contains the device association start information, has been received by the device 102, the device 102 will send out a device connect request command with a new connection bit set (as depicted in operation step 905).
Upon receipt of the device connect request command from the device 102, the repeater 101 will send a device connect notification 1401 to the host 100. The host 100 will then respond by sending a control request to the repeater 101 to command the repeater to add a connect acknowledgement response for the device 102 in its own MMC packets, as depicted in step 1402. After that, the repeater 101 will generate a MMC packet with connection acknowledgement response to the device 102, as depicted in step 1403. Upon reception of the MMC packet sent in step 1403, the device 102 will configure its address and control settings to make itself ready to go through the upcoming key exchange procedures. After operation step 1402 has completed, the host 100 will send a control request via the repeater 101 to the device 102 to get the public key of the device 102, as depicted in step 1404. Delivery of the request over the repeater 101 as depicted in step 1404 is performed in the manner as depicted in
In the following, it will be appreciated that data transfers between the host 100 and the device 102 through the repeater 101 are conducted in the same manner.
After the device 102 has received the request of step 1404 to provide a public key, it will generate a random number (“A”) and use the random number to compute a public key PK_D. The public key can be generated by, for example, using the Diffie-Hellman Key Agreement Method, as described in [RFC2631], or other appropriate key generation methods or algorithms known from time to time. Next, the device 102 will compute the hash value of the public key PK_D, which is conveniently denoted as SHA-256(PK_D). The hash value can be computed using, for example, the SHA-256 algorithm, which is a variant of the SHA algorithm which produces a 256-bit message digest as described in [FIPS180-2: Secure Hash Standard], or other appropriate hash computation methods or algorithms known from time to time.
Next, in step 1406, the device 102 will send the hash SHA-256(PK_D) to the host 100 through the repeater 101. In response, the host 100 will generate in step 1407 another random number (“B”) and the random number B will be used to generate an own public key PK_H of the repeater. Similarly, the public key PK_H of the repeater cab be generated by using the Diffie-Hellman Key Agreement Method or other appropriate methods. In step 1408, the host 100 will send the public key PK_H to the device 102 and via the repeater 101. Next, and in step 1409, the host 100 will send a control request to the device 102 to get the public key of the device. In response, the device 102 will send its own public key PK_D to the host 101, as depicted in step 1410. Upon completion of the above procedures, public keys of the host 100 and the device 102 are exchanged via the repeater 101. It will be appreciated that operation steps 1401 to 1410 are expanded from the operation step 906 of
It will be appreciated that as the association and the authentication steps have not been performed, the host 100 and the device 102 are not yet associated at this stage. As no keys are available for encrypting and decrypting data before data transfers take place between the host and the device, data frames transferred between the repeater 101 and the device 102 are not encrypted. Therefore, WUSB packet payloads 1305 are in un-encrypted plain text, and no security information 1306 nor MIC 1304 are present in the frame payload 1302.
An exemplary manner in which the host 100 and the device are mutually authenticated with connection keys exchanged via the repeater 101 will be described in more detail below with reference to
After the public key exchange as described with reference to
Based on the shared secret key, DH_KEY, the host 100 will compute in step 1501 a verification number V_H. The verification number can be computed by, for example, using a keyed-hash message authentication code (HMAC) or other appropriate authentication schemes or algorithms, together with the hash function SHA-256. Details of HMAC are described in [RFC2104: HMAC: Keyed-Hashing for Message Authentication] and are incorporated herein. In step 1502, the verification number has been obtained and the host will cause the verification number V_H to be output for display on a VDU (video display unit), for example, a LED video display. The device 102 will compute its own verification number, namely, V_D, in a similar manner in step 1503 and then output the verification number on its own video display, as depicted in step 1504. Since the host 100 and the device 102 have the same shared secret key DH_KEY, the verification number derived by them should be identical.
After the verification numbers V_H and V_D displayed respectively on the host 100 and the device 102 have been confirmed to be identical, compatible or matched, the user will then proceed to condition the host 100 and the device 102, and then to continue with the remaining key exchange process, as depicted in step 909. After operation step 909 has been completed, the host 100 will send out a connection context to the device 102 via the repeater 101, as more particularly depicted in step 1505. The connection context contains non-private information, such as the host connection ID and the device connection ID, which is assigned by the host 100. Next, the host 100 will generate a random nonce, namely, NONCE_H, in step 1506, and will then send the random nonce to the device 102 together with a key identity (key ID) information as well as a zero value of the message integrity code (MIC) field in the WUSB packet payload 1305. It will be noted that this MIC field is inside the WUSB packet payload 1305, which is different from the one 1304 present in the frame payload 1302 of
Upon receipt of NONCE_H from the packet in step 1507, the device 102 will respond by generating another random nonce, namely, NONCE_D. Next, in step 1508, the device will use the random nonce, NONCE_H and NONCE_D, to compute two separate keys, namely, pair-wise key and confirmation key, based on the shared secret derived in operation step 1503. The device 102 will then use the confirmation key to compute the message integrity code (MIC) for the data field containing the NONCE_D and the key identity (Key ID) information received from the host 100. After that, the device will place the NONCE_D, the Key ID and the resultant MIC field inside the same WUSB data payload 1305 and send the MIC field to the host 100 via the repeater 101, as depicted in operation step 1509. After operation step 1509, the host will have received the WUSB data payload packet 1305. Next, the host 100 will obtain the random nonce NONCE_D and will use it together with the random nonce, namely, NONCE_H, to generate the same pair-wise key and confirmation key, in the same manner as the pair-wise key and confirmation key have been generated by the device 102, and based on the shared secret derived in operation step 1501.
The host 100 will then use the confirmation key to compute the MIC for the data field containing the NONCE_D and the key ID and to check if the generated MIC is equal to the MIC contained in the payload packet obtained in operation step 1509.
If the test result is yes (or positive), the host 100 will send out the NONCE_H and the key ID to the device 102 again, but this time also with the MIC generated for these two fields using the confirmation key derived in operation step 1510. In this case, after the packet sent in step 1511 has been received, the device 102 will check if the MIC contained in the packet received in step 1511 is equal to the one generated for the NONCE_H and key ID fields using its own confirmation key. If the result is yes (or positive), the device 102 will install the pair-wise key it has derived before (in operation step 1503). In such a case, the pair-wise key is ready to be used for decrypting all the data packets received from the host 100 and to encrypt all data packets to be sent to the host 100, via the repeater 101. Therefore, the communications between the host 100 (via the repeater 101) and the device 102 are all in data packets with the WUSB packet payload encrypted, with the MIC and security information present in their corresponding frame payload.
On the other hand, if the host 100 or the device 102 fails to generate a MIC which is matched, i.e., identical or compatible, to the received one, the key exchange process will be aborted and the authentication process declared failed.
The pair-wise key described above is for enabling secured, point-to-point, data communications between the host and the device. In addition, the host also has a group encryption key to protect broadcast communication, for example, the transmission of MMC packets from the host to every device in the same WUSB system. The group encryption key is created by the host and will be distributed to the device upon successful association of the device 102, that is after the pair-wise key exchange procedures (operation steps 1506 to 1511) have been completed and the device 102 authenticated. Specifically, the host 100 will deliver the group encryption key to the device 102 via the repeater 101, as depicted in operation step 1512. Similar to what were depicted in
On the other hand, the communications steps 1505, 15071509 and 1511 between the repeater 101 and the device 102 are unsecured. This means all the data frames which are transferred between the repeater 101 and the device 102 in those steps do not contain the security information 1306 and MIC 1304 in the frame payload 1302, and the WUSB packet payloads 1305 are transferred in plain text, not encrypted.
After the device 102 has successfully validated the MIC received in operation step 1511, the device 102 is ready to begin communication with the host 100 via the repeater using the derived encryption key. Subsequently, when the host 100 wishes to send a data packet, say packet A, to the device 102, it will first encrypt the data packet (packet A) using the key assigned for communications with the repeater 101 and then send the encrypted packet A to the repeater 101, following the forwarding mechanism as described with reference to
While the present invention has been explained by reference to the examples or preferred embodiments described above, it will be appreciated that those are examples to assist understanding of the present invention and are not meant to be restrictive. Variations or modifications which are obvious or trivial to persons skilled in the art, as well as improvements made thereon, should be considered as equivalents of this invention.
Furthermore, while the present invention has been explained by reference to a repeater for WUSB applications, it should be appreciated that the invention can apply, whether with or without modification, to other repeater applications without loss of generality.
