WO2010023506A1

WO2010023506A1 - Methods, apparatuses, computer program products, and systems for providing secure pairing and association for wireless devices

Info

Publication number: WO2010023506A1
Application number: PCT/IB2008/053436
Authority: WO
Inventors: Kaisa Tellervo Nyberg
Original assignee: Nokia Corporation; Nokia Inc.
Priority date: 2008-08-26
Filing date: 2008-08-26
Publication date: 2010-03-04

Abstract

A method, apparatus, computer program product, and system are provided, which may enable use of a fixed secret value and fixed public key in a first device for use in pairing and association of the first device with a second device without compromising forward secrecy. In this regard, the first and second devices may establish a first shared secret key in accordance with a public key agreement protocol based at least in part upon the fixed public key of the first device and a public key associated with the second device. The first shared secret key may be used for verification of a second shared secret key. The second shared secret key may be established based at least in part upon the public key associated with the second device and a fresh public key generated by the first device and may be used to facilitate encrypted communications between the devices.

Description

METHODS, APPARATUSES, COMPUTER PROGRAM PRODUCTS, AND SYSTEMS FOR PROVIDING SECURE PAIRING AND ASSOCIATION FOR

WIRELESS DEVICES

TECHNOLOGICAL FIELD Embodiments of the present invention relate generally to mobile communication technology and, more particularly, relate to methods, apparatuses, computer program products, and systems for providing secure pairing and association for wireless devices.

BACKGROUND

The modern communications era has brought about a tremendous expansion of wireline and wireless networks. Computer networks, television networks, and telephony networks are experiencing an unprecedented technological expansion, fueled by consumer demand. Wireless and mobile networking technologies have addressed related consumer demands, while providing more flexibility and immediacy of information transfer.

Current and future networking technologies continue to facilitate ease of information transfer and convenience to users. One area in which there is a demand to further improve the convenience to users is pairing and association for wireless devices. In the past few years, there have been several advancements in the development of wireless interfaces and protocols that allow multiple devices to communicate wirelessly. Recently new secure pairing and association models have been specified for Bluetooth, Wireless USB, Wimedia and Wi-Fi Alliance. These new mechanisms require that the devices have user interfaces for handling variable verification data and passkeys, or that they can be connected using fixed cable or secure out-of-band (OOB) connection. This requirement may present a problem in that not all devices have sufficient interfaces for handling the necessary authentication data. In this regard, some vendors are reluctant to provide such interfaces due to added cost. Further, from a user perspective, usability of such online interfaces is not always easy.

There is a demand for an association model using a fixed secret, which comes with one of the devices. This association model is in use in many applications, including being the traditional one also for the Bluetooth devices. However, these fixed secret applications may not be secure in that the protocols currently in use do not protect the secrecy of the fixed secret. In this regard, existing pairing and association models utilizing a fixed secret may be vulnerable to passive eavesdropping and man-in-the-middle attacks.

Further, if a fixed secret is hard coded into a first device, then it may be that the public key and the private key of the device must also be fixed. Fixing of the private key may present a problem when a public key agreement protocol, such as the Diffie-Hellman key agreement protocol, is used to establish a shared secret key between the first device and a second device for use to encrypt further communications between the first and second devices. A malicious party may record communications traffic between the first and second devices and may later acquire the first device. The malicious party may then extract the fixed private key and use the fixed private key to recalculate the shared secret key and use it to decrypt the recorded traffic. Thus, communications between the first and second devices may lack perfect forward secrecy.

Accordingly, it may be advantageous to provide computing device users with methods, apparatuses, computer program products, and systems for providing secure pairing and association for wireless devices. These methods, apparatuses, computer program products, and systems may advantageously provide perfect forward secrecy such that devices do not contain any secrets that may be used to decrypt messages from previous communications sessions in spite of the use of a fixed secret value and fixed private key associated with a first device to initiate pairing with the second device. BRIEF SUMMARY OF SOME EXAMPLES OF THE INVENTION A method, apparatus, computer program product, and system are therefore provided, which may provide secure pairing and association for wireless devices. In particular, a method, apparatus, and computer program product may be provided to enable, for example, the use of a fixed secret value and fixed public key in a first device, wherein the fixed secret value and fixed public key are used to initiate pairing of the first device with a second device without compromising forward secrecy. In this regard, the first and second devices may establish a first shared secret key in accordance with a public key agreement protocol based at least in part upon the fixed public key of the first device and a public key associated with the second device. The first shared secret key, however, may only be used for verification of a second shared secret key. The second shared secret key may be established based at least in part upon the public key associated with the second device and a fresh public key generated by the first device. Accordingly, communications between the first and second devices may be encrypted based upon the second shared key and not the first shared key. Thus, neither the first nor the second device contains any secrets that can be used to decrypt messages from previous communications sessions in spite of the use of a fixed secret value and fixed public key associated with the first device to initiate pairing with the second device.

In one exemplary embodiment, a method is provided which may include receiving a fixed shared secret value associated with a remote device. The method may further include receiving a fixed public key from the remote device. The fixed public key may be associated with the remote device. The method may also include verifying authenticity of the fixed public key as being associated with the remote device based at least in part upon the fixed shared secret. The method may additionally include generating a public key associated with a local device and sending the generated public key to the remote device. The method may further include establishing, with the remote device, a first shared secret key in accordance with a public key agreement protocol based at least in part upon the received fixed public key and the generated public key. The method may also include receiving a fresh public key associated with the remote device from the remote device. The fresh public key may be generated by the remote device for establishing a communications session with the local device. The method may additionally include establishing, with the remote device, a second shared secret key in accordance with the public key agreement protocol for use in communications between the local device and the remote device. The establishment of the second shared key may be based at least in part upon the received fresh public key and the generated public key. In another exemplary embodiment, a computer program product is provided. The computer program product includes at least one computer-readable storage medium having computer-readable program instructions stored therein. The computer-readable program instructions may include first, second, third, fourth, fifth, sixth, seventh, and eighth program instructions. The first program instruction is for receiving a fixed shared secret value associated with a remote device. The second program instruction is for receiving a fixed public key from the remote device. The fixed public key may be associated with the remote device. The third program instruction is for verifying authenticity of the fixed public key as being associated with the remote device based at least in part upon the fixed shared secret. The fourth program instruction is for generating a public key associated with a local device. The fifth program instruction is for sending the generated public key to the remote device. The sixth program instruction is for establishing, with the remote device, a first shared secret key in accordance with a public key agreement protocol based at least in part upon the received fixed public key and the generated public key. The seventh program instruction is for receiving a fresh public key associated with the remote device from the remote device. The fresh public key may be generated by the remote device for establishing a communications session with the local device. The eighth program instruction is for establishing, with the remote device, a second shared secret key in accordance with the public key agreement protocol for use in communications between the local device and the remote device. The establishment of the second shared key may be based at least in part upon the received fresh public key and the generated public key.

In another exemplary embodiment, an apparatus is provided, which may include a processor. The processor may be configured to receive a fixed shared secret value associated with a remote device. The processor may be further configured to receive a fixed public key from the remote device. The fixed public key may be associated with the remote device. The processor may also be configured to verify authenticity of the fixed public key as being associated with the remote device based at least in part upon the fixed shared secret. The processor may additionally be configured to generate a public key associated with a local device and sending the generated public key to the remote device. The processor may further be configured to establish, with the remote device, a first shared secret key in accordance with a public key agreement protocol based at least in part upon the received fixed public key and the generated public key. The processor may also be configured to receive a fresh public key associated with the remote device from the remote device. The fresh public key may be generated by the remote device for establishing a communications session with the local device. The processor may additionally be configured to establish, with the remote device, a second shared secret key in accordance with the public key agreement protocol for use in communications between the local device and the remote device. The establishment of the second shared key may be based at least in part upon the received fresh public key and the generated public key.

In another exemplary embodiment, an apparatus is provided that may include means for receiving a fixed shared secret value associated with a remote device. The apparatus may further include means for receiving a fixed public key from the remote device. The fixed public key may be associated with the remote device. The apparatus may also include means for verifying authenticity of the fixed public key as being associated with the remote device based at least in part upon the fixed shared secret. The apparatus may additionally include means for generating a public key associated with a local device and sending the generated public key to the remote device. The apparatus may further include means for establishing, with the remote device, a first shared secret key in accordance with a public key agreement protocol based at least in part upon the received fixed public key and the generated public key. The apparatus may also include means for receiving a fresh public key associated with the remote device from the remote device. The fresh public key may be generated by the remote device for establishing a communications session with the local device. The apparatus may additionally include means for establishing, with the remote device, a second shared secret key in accordance with the public key agreement protocol for use in communications between the local device and the remote device. The establishment of the second shared key may be based at least in part upon the received fresh public key and the generated public key.

In another exemplary embodiment, a system is provided which may include a first communications device and a second communications device. The first communications device may have a hard coded fixed shared secret value and a hard coded fixed public key and may be configured to generate a fresh public key, send the fixed public key to the second communications device, receive a public key associated with the second communications device from the second communications device, and send the fresh public key to the second communications device. The second communications device may be configured to receive the fixed shared secret value and the fixed public key, generate a public key, send the generated public key to the first communications device, and receive the fresh public key from the first communications device. The first and second communications devices may be configured to establish a first shared secret key in accordance with a public key agreement protocol based at least in part upon the received fixed public key and the public key generated by the second communications device. The first and second communications devices may also be configured to establish a second shared secret key in accordance with the public key agreement protocol based at least in part upon the fresh public key and the public key generated by the second communications device.

The above summary is provided merely for purposes of summarizing some example embodiments of the invention so as to provide a basic understanding of some aspects of the invention. Accordingly, it will be appreciated that the above described example embodiments are merely examples and should not be construed to narrow the scope or spirit of the invention in any way. It will be appreciated that the scope of the invention encompasses many potential embodiments, some of which will be further described below, in addition to those here summarized.

BRIEF DESCRIPTION OF THE DRAWING(S)

Having thus described embodiments of the invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:

FIG. 1 illustrates a block diagram of a system for providing secure pairing and association for wireless devices according to an exemplary embodiment of the present invention;

FIG. 2 is a schematic block diagram of a mobile terminal according to an exemplary embodiment of the present invention;

FIG. 3 is a control flow diagram of communications signals passed between entities of the system of FIG. 1 according to an exemplary embodiment of the present invention; and

FIG. 4 is a flowchart according to an exemplary method for providing secure pairing and association for wireless devices according to an exemplary embodiment of the present invention.

DETAILED DESCRIPTION

Some embodiments of the present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments of the invention are shown. Indeed, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like reference numerals refer to like elements throughout.

FIG. 1 illustrates a block diagram of a system 100 for providing secure pairing and association for wireless devices according to an exemplary embodiment of the present invention. As used herein, "exemplary" merely means an example and as such represents one example embodiment for the invention and should not be construed to narrow the scope or spirit of the invention in any way. It will be appreciated that the scope of the invention encompasses many potential embodiments in addition to those illustrated and described herein. As such, while FIG. 1 illustrates one example of a configuration of a system for providing secure pairing and association for wireless devices, numerous other configurations may also be used to implement embodiments of the present invention.

As used herein, "public key agreement protocol" refers to any number of cryptographic protocols wherein two parties may jointly establish a shared secret key over an insecure communications channel. Such a shared secret key and/or keys derived therefrom may be used to encrypt subsequent communications between the parties over the communications channel. The Diffie-Hellman key agreement protocol may be referred to herein from time to time as an example of a public key agreement protocol that may be used in conjunction with embodiments of the present invention. However, it will be appreciated that embodiments of the present invention are not limited to the use of only the Diffie-Hellman key agreement protocol.

As used herein, "fixed" as used in conjunction with, for example, a "fixed shared secret value" or a "fixed public key" refers to any value that is permanently hard coded into a device. In this regard, "hard coded" refers to the permanent coding of a value into a device. In this regard, hard coded values may be coded and/or stored in a device in hardware, software, firmware, and/or some combination thereof. In contrast, a "fresh key," such as, for example, a "fresh public key" refers to a value that is generated by a first device specifically for the purpose of establishing communications with a second device and which will be discarded by the end of the resulting communications session established with the second device.

Further, the terms "association" and "pairing" are used interchangeably herein and refer to the establishment of a wireless communications session between two devices. In this regard, "associated" or "paired" devices are wirelessly coupled, having formed a trusted pair and may engage in communications over a wireless communications link. Referring now to FIG. 1 , the system 100 may include a host device 102 and client device 104 configured to communicate over a wireless communications link 106. It will be appreciated that the terms "host" and "client" with reference to the host device 102 and client device 104 are merely for purposes of distinguishing the devices in discussion of embodiments of the invention. Embodiments of the invention are not limited to embodiments wherein the host device 102 and client device 104 interface in a client-host relationship or to communications protocols which explicitly refer to a "host" and a "client." Instead, as used herein, a client device 104 is a device having a fixed secret value and a fixed public key hard coded into the device. A host device 102 is a device that securely receives a fixed shared secret associated with a client device 104. In some embodiments, one or both of the host device 102 and client device 104 may be embodied as a mobile computing device, such as, for example a mobile terminal 10 depicted in FIG. 2. In this regard, FIG. 2 illustrates a block diagram of a mobile terminal 10 representative of one embodiment of a host device 102 and/or client device 104 in accordance with embodiments of the present invention. It should be understood, however, that the mobile terminal illustrated and hereinafter described is merely illustrative of one type of host device 102 and/or client device 104 that may benefit from embodiments of the present invention and, therefore, should not be taken to limit the scope of the present invention. While several embodiments of the electronic device are illustrated and will be hereinafter described for purposes of example, other types of electronic devices, such as mobile telephones, mobile computers, portable digital assistants (PDAs), pagers, laptop computers, desktop computers, gaming devices, televisions, and other types of electronic systems, may employ embodiments of the present invention.

As shown, the mobile terminal 10 may include an antenna 12 (or multiple antennas 12) in communication with a transmitter 14 and a receiver 16. The mobile terminal may also include a controller 20 or other processor(s) that provides signals to and receives signals from the transmitter and receiver, respectively. These signals may include signaling information in accordance with an air interface standard of an applicable cellular system, and/or any number of different wireless networking techniques, comprising but not limited to Wireless- Fidelity (Wi-Fi), wireless local access network (WLAN) techniques such as Institute of Electrical and Electronics Engineers (IEEE) 802.11, and/or the like. In addition, these signals may include speech data, user generated data, user requested data, and/or the like. In this regard, the mobile terminal may be capable of operating with one or more air interface standards, communication protocols, modulation types, access types, and/or the like. More particularly, the mobile terminal may be capable of operating in accordance with various first generation (IG), second generation (2G), 2.5G, third-generation (3G) communication protocols, fourth-generation (4G) communication protocols, and/or the like. For example, the mobile terminal may be capable of operating in accordance with 2G wireless communication protocols IS-136 (Time Division Multiple Access (TDMA)), Global System for Mobile communications (GSM), IS-95 (Code Division Multiple Access (CDMA)), and/or the like. Also, for example, the mobile terminal may be capable of operating in accordance with 2.5G wireless communication protocols General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), and/or the like. Further, for example, the mobile terminal may be capable of operating in accordance with 3 G wireless communication protocols such as Universal Mobile Telecommunications System (UMTS), Code Division Multiple Access 2000 (CDMA2000), Wideband Code Division Multiple Access (WCDMA), Time Division-Synchronous Code Division Multiple Access (TD-SCDMA), and/or the like. The mobile terminal may be additionally capable of operating in accordance with 3.9G wireless communication protocols such as Long Term Evolution (LTE) or Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and/or the like. Additionally, for example, the mobile terminal may be capable of operating in accordance with fourth-generation (4G) wireless communication protocols and/or the like as well as similar wireless communication protocols that may be developed in the future.

Some Narrow-band Advanced Mobile Phone System (NAMPS), as well as Total Access Communication System (TACS), mobile terminals may also benefit from embodiments of this invention, as should dual or higher mode phones (e.g., digital/analog or TDMA/CDMA/analog phones). Additionally, the mobile terminal 10 may be capable of operating according to Wireless Fidelity (Wi-Fi) protocols.

It is understood that the controller 20 may comprise circuitry for implementing audio/video and logic functions of the mobile terminal 10. For example, the controller 20 may comprise a digital signal processor device, a microprocessor device, an analog-to-digital converter, a digital-to-analog converter, and/or the like. Control and signal processing functions of the mobile terminal may be allocated between these devices according to their respective capabilities. The controller may additionally comprise an internal voice coder (VC) 20a, an internal data modem (DM) 20b, and/or the like. Further, the controller may comprise functionality to operate one or more software programs, which may be stored in memory. For example, the controller 20 may be capable of operating a connectivity program, such as a web browser. The connectivity program may allow the mobile terminal 10 to transmit and receive web content, such as location-based content, according to a protocol, such as Wireless

Application Protocol (WAP), hypertext transfer protocol (HTTP), and/or the like. The mobile terminal 10 may be capable of using a Transmission Control Protocol/Internet Protocol (TCP/IP) to transmit and receive web content across the internet or other networks. The mobile terminal 10 may also comprise a user interface including, for example, an earphone or speaker 24, a ringer 22, a microphone 26, a display 28, a user input interface, and/or the like, which may be operationally coupled to the controller 20. As used herein, "operationally coupled" may include any number or combination of intervening elements (including no intervening elements) such that operationally coupled connections may be direct or indirect and in some instances may merely encompass a functional relationship between components. Although not shown, the mobile terminal may comprise a battery for powering various circuits related to the mobile terminal, for example, a circuit to provide mechanical vibration as a detectable output. The user input interface may comprise devices allowing the mobile terminal to receive data, such as a keypad 30, a touch display (not shown), a joystick (not shown), and/or other input device. In embodiments including a keypad, the keypad may comprise numeric (0-9) and related keys (#, *), and/or other keys for operating the mobile terminal.

As shown in Figure 2, the mobile terminal 10 may also include one or more means for sharing and/or obtaining data. For example, the mobile terminal may comprise a short-range radio frequency (RF) transceiver and/or interrogator 64 so data may be shared with and/or obtained from electronic devices in accordance with RP techniques. The mobile terminal may comprise other short-range transceivers, such as, for example, an infrared (IR) transceiver 66, a Bluetooth™ (BT) transceiver 68 operating using Bluetooth™ brand wireless technology developed by the Bluetooth™ Special Interest Group, a wireless universal serial bus (USB) 70 and/or the like. The Bluetooth transceiver 68 may be capable of operating according to ultra-low power Bluetooth technology (e.g., Wibree™) radio standards. In this regard, the mobile terminal 10 and, in particular, the short- range transceiver may be capable of transmitting data to and/or receiving data from electronic devices within a proximity of the mobile terminal, such as within 10 meters, for example. Although not shown, the mobile terminal may be capable of transmitting and/or receiving data from electronic devices according to various wireless networking techniques, including Wireless Fidelity (Wi-Fi), WLAN techniques such as IEEE 802.11 techniques, and/or the like. The mobile terminal 10 may comprise memory, such as a subscriber identity module (SIM) 38, a removable user identity module (R-UIM), and/or the like, which may store information elements related to a mobile subscriber. In addition to the SIM, the mobile terminal may comprise other removable and/or fixed memory. The mobile terminal 10 may include volatile memory 40 and/or non-volatile memory 42. For example, volatile memory 40 may include Random Access Memory (RAM) including dynamic and/or static RAM, on-chip or off-chip cache memory, and/or the like. Non-volatile memory 42, which may be embedded and/or removable, may include, for example, read-only memory, flash memory, magnetic storage devices (e.g., hard disks, floppy disk drives, magnetic tape, etc.), optical disc drives and/or media, non- volatile random access memory (NVRAM), and/or the like. Like volatile memory 40 non-volatile memory 42 may include a cache area for temporary storage of data. The memories may store one or more software programs, instructions, pieces of information, data, and/or the like which may be used by the mobile terminal for performing functions of the mobile terminal. For example, the memories may comprise an identifier, such as an international mobile equipment identification (IMEI) code, capable of uniquely identifying the mobile terminal 10.

Returning to FIG. 1, the host device 102 and client device 104 are not limited to being embodied as a mobile terminal 10 and may be embodied as any computing device, mobile or fixed, and may be embodied as a server, desktop computer, laptop computer, mobile terminal 10, and/or the like. The wireless communications link 106 may comprise any wireless link in accordance with any wireless communications protocol over which the host device 102 and client device 104 are configured to communicate. Example protocols that may be implemented for communication over the wireless communications link 106 include, but are not limited to, Bluetooth™, wireless USB, and/or the like. The host device 102 may include various means, such as a processor 110, memory 112, communication interface 114, user interface 116, and host cryptography unit 118 for performing the various functions herein described. These means of the host device 102 as described herein may be embodied as, for example, hardware elements (e.g., a suitably programmed processor, combinational logic circuit, and/or the like), computer code (e.g., software or firmware) embodied on a computer-readable medium (e.g. memory 112) that is executable by a suitably configured processing device (e.g., the processor 110), or some combination thereof. The processor 110 may, for example, be embodied as various means including a microprocessor, a coprocessor, a controller, or various other processing elements including integrated circuits such as, for example, an ASIC (application specific integrated circuit) or FPGA (field programmable gate array). In an exemplary embodiment, the processor 110 may be configured to execute instructions stored in the memory 112 or otherwise accessible to the processor 110. Although illustrated in FIG. 1 as a single processor, the processor 110 may comprise a plurality of processors operating in parallel, such as a multiprocessor system. The memory 112 may include, for example, volatile and/or non- volatile memory. The memory 1 12 may be configured to store information, data, applications, instructions, or the like for enabling the host device 102 to carry out various functions in accordance with exemplary embodiments of the present invention. For example, the memory 112 may be configured to buffer input data for processing by the processor 110. Additionally or alternatively, the memory 112 may be configured to store instructions for execution by the processor 110. The memory 112 may comprise one or more databases that store information in the form of static and/or dynamic information. In this regard, the memory 112 may store, for example, public keys, private keys, shared secret keys, cryptography keys, session keys, and/or intermediate values calculated for derivation thereof that may be generated by the host cryptography unit 118 and/or received from the client device 104. This stored information may be stored and/or used by the host cryptography unit 118 during the course of performing its functionalities. The communication interface 114 may be embodied as any device or means embodied in hardware, software, firmware, or a combination thereof that is configured to receive and/or transmit data from/to a network and/or any other device, such as a client device 104, or module in communication with the host device 102. In one embodiment, the communication interface 114 may be at least partially embodied as or otherwise controlled by the processor 110. The communication interface 114 may include, for example, an antenna, a transmitter, a receiver, a transceiver and/or supporting hardware or software for enabling communications with other entities of the system 100, such as a client device 104 via the wireless communications link 106. The communication interface 114 may be configured to receive and/or transmit data using any protocol that may be used for communications between the host device 102 and client device 104 over the wireless communications link 106. The communication interface 114 may additionally be in communication with the memory 112, user interface 116, and/or host cryptography unit 118. The user interface 116 may be in communication with the processor 110 to receive an indication of a user input and/or to provide an audible, visual, mechanical, or other output to the user. As such, the user interface 116 may include, for example, a keyboard, a mouse, a joystick, a display, a touch screen display, a microphone, a speaker, and/or other input/output mechanisms. Accordingly, the user interface 116 may facilitate the input of a fixed shared secret value associated with the client device 104. The user interface 116 may further be in communication with the memory 112, communication interface 116, and/or host cryptography unit 118.

The host cryptography unit 118 may be embodied as various means, such as hardware, software, firmware, or some combination thereof and, in one embodiment, may be embodied as or otherwise controlled by the processor 110. In embodiments where the host cryptography unit 118 is embodied separately from the processor 110, the host cryptography unit 118 may be in communication with the processor 110. The host cryptography unit 118 may be configured to provide means for secure pairing and association of the host device 102 with the client device 104. In this regard, the host cryptography unit 118 may be configured to provide means for facilitating the establishment of a shared secret key in accordance with a public key agreement protocol and encrypted communications based thereon between the host device 102 and client device 104 with perfect forward secrecy.

The host cryptography unit 118 may be configured to provide means for receiving a fixed shared secret value associated with the client device 104. The "fixed shared secret value" may comprise one or more fixed secret values that are hard coded into the client device 104 and which may be required to facilitate association of the client device 104 with the host device 102. The host cryptography unit 118 may receive fixed shared secret value(s) by any secure means. For example, the host cryptography unit 118 may be configured to receive a fixed shared secret value over the user interface 116. In this regard, the fixed shared secret value may be provided by a user of the host device 102 via, for example, a keyboard input. Additionally or alternatively, the host cryptography unit 118 may be configured to receive a fixed shared secret value over a secure communication link (not illustrated in FIG. 1) from a remote device, such as the client device 104, privy to the fixed shared secret. In an exemplary embodiment, such a secure communication link may be a secure communications cable connecting the client device 102 to the device providing the fixed shared secret.

The host cryptography unit 118 may be further configured to provide means for receiving a fixed public key (PK) from the client device 104 over the wireless communications link 106. This received fixed public key may be associated with the client device 104 and may be hard coded into the client device 104. The host cryptography unit 118 may additionally be configured to provide means for verifying the authenticity of the received PK as being associated with the client device 104 based at least in part upon the fixed shared secret. In this regard, for example, the fixed shared secret may have been calculated based at least in part upon the fixed public key of the client device 104. Accordingly, since the fixed shared secret was received securely and is known to be associated with the client device 104, the host cryptography unit 118 may be configured to calculate a value based at least in part upon the received PK and verify that the calculated value is equal to the fixed shared secret value.

The host cryptography unit 118 may also be configured to generate a fresh private key value (B) and then generate a fresh public key (PK_H ) based at least in part upon the fresh private key value. The host cryptography unit 118 may be further configured to send the PK_H to the client device 104 over the wireless communications link 106. The host cryptography unit 118 may then be configured to establish a first shared secret key with the client device 104 in accordance with a public key agreement protocol, such as, for example, the Diffie-Hellman key agreement protocol. The first shared secret key may be established based at least in part upon the received fixed public key of the client device 104 and PK_H. In this regard, the host cryptography unit 104 may be configured to calculate the first shared secret key based at least in part upon the received PK and generated B. The client device 104 may, as will be described further below, calculate the same first shared secret key based at least in part on PK_H and a fixed private key hard coded into the client device 104. The host cryptography unit 118 may additionally be configured to calculate a check value based at least in part upon the first shared secret key and the fixed shared secret and send the calculated check value to the client device 104 so that the client device 104 may verify its locally calculated first shared secret key so as to authenticate the first shared secret key.

The host cryptography unit 118 may further be configured to receive a fresh public key (PK_D) from the client device 104 over the wireless communications link 106. PK_D may be generated by the client device 104 specifically for association with the host device 102 and establishment of a new communications session. Accordingly, PK_D is not generated based upon the fixed shared secret value or PK. The host cryptography unit 118 may then be configured to establish a second shared secret key with the client device 104 in accordance with a public key agreement protocol, such as, for example, the Diffϊe-Hellman key agreement protocol. The second shared secret key may be established based at least in part upon the received PK_D and locally generated PK_H. In this regard, the host cryptography unit 118 may be configured to calculate the second shared secret key based at least in part upon the received PK_D and generated B. The client device 104 may, as will be described further below, calculate the same second shared secret key based at least in part on PK_H and a fresh secret value generated by the client device 104, which was used by the client device 104 to generate the fresh public key PK_D.

The host cryptography unit 118 may additionally be configured to authenticate the second shared secret key based at least in part upon one or more of the first shared secret key and the fixed shared. In an exemplary embodiment, the host cryptography unit 118 may be configured to receive a check value from the client device 104. The check value received from the client device 104 may have been calculated by the client device 104 based at least in part upon the second shared secret key and the fixed shared secret. The host cryptography unit 118 may then be configured to locally calculate a value based at least in part upon the second shared secret key and the fixed shared secret and compare that the calculated value is equivalent to the received check value so as to authenticate the second shared key. The client device 104 may include various means, such as a processor 120, memory 122, communication interface 124, user interface 126, and client cryptography unit 128 for performing the various functions herein described. These means of the client device 104 as described herein may be embodied as, for example, hardware elements (e.g., a suitably programmed processor, combinational logic circuit, and/or the like), computer code (e.g., software or firmware) embodied on a computer-readable medium (e.g. memory 122) that is executable by a suitably configured processing device (e.g., the processor 120), or some combination thereof. The processor 120 may, for example, be embodied as various means including a microprocessor, a coprocessor, a controller, or various other processing elements including integrated circuits such as, for example, an ASIC (application specific integrated circuit) or FPGA (field programmable gate array). In an exemplary embodiment, the processor 120 may be configured to execute instructions stored in the memory 122 or otherwise accessible to the processor 120. Although illustrated in FIG. 1 as a single processor, the processor 120 may comprise a plurality of processors operating in parallel, such as a multiprocessor system. The memory 122 may include, for example, volatile and/or non- volatile memory. The memory 122 may be configured to store information, data, applications, instructions, or the like for enabling the client device 104 to carry out various functions in accordance with exemplary embodiments of the present invention. For example, the memory 122 may be configured to buffer input data for processing by the processor 120. Additionally or alternatively, the memory 122 may be configured to store instructions for execution by the processor 120. The memory 122 may comprise one or more databases that store information in the form of static and/or dynamic information. In this regard, the memory 122 may store, for example, public keys, private keys, shared secret keys, cryptography keys, session keys, and/or intermediate values calculated for derivation thereof that may be generated by the client cryptography unit 128 and/or received from the host device 102. This stored information may be stored and/or used by the client cryptography unit 128 during the course of performing its functionalities.

The communication interface 124 may be embodied as any device or means embodied in hardware, software, firmware, or a combination thereof that is configured to receive and/or transmit data from/to a network and/or any other device, such as a host device 102, or module in communication with the client device 104. In one embodiment, the communication interface 124 may be at least partially embodied as or otherwise controlled by the processor 120. The communication interface 124 may include, for example, an antenna, a transmitter, a receiver, a transceiver and/or supporting hardware or software for enabling communications with other entities of the system 100, such as a host device 102 via the wireless communications link 106. The communication interface 124 may be configured to receive and/or transmit data using any protocol that may be used for communications between the host device 102 and client device 104 over the wireless communications link 106. The communication interface 124 may additionally be in communication with the memory 122, user interface 126, and/or client cryptography unit 128.

The user interface 126 may be in communication with the processor 120 to receive an indication of a user input and/or to provide an audible, visual, mechanical, or other output to the user. As such, the user interface 126 may include, for example, a keyboard, a mouse, a joystick, a display, a touch screen display, a microphone, a speaker, and/or other input/output mechanisms. However, in some embodiments of the client device 104, the user interface 126 may be limited or even absent. Further, in some embodiments, the client device 104 may function as a user interface, such as, for example, a headset, keyboard, mouse, and/or the like upon successful completion of pairing of the client device 104 with the host device 102 over the wireless communications link 106. The user interface 126 may further be in communication with the memory 122, communication interface 124, and/or client cryptography unit 128.

The client cryptography unit 128 may be embodied as various means, such as hardware, software, firmware, or some combination thereof and, in one embodiment, may be embodied as or otherwise controlled by the processor 120. In embodiments where the client cryptography unit 128 is embodied separately from the processor 120, the client cryptography unit 128 may be in communication with the processor 120. The client cryptography unit 128 may be configured to provide means for secure pairing and association of the host device 102 with the client device 104. In this regard, the client cryptography unit 128 may be configured to provide means for facilitating the establishment of a shared secret key in accordance with a public key agreement protocol and encrypted communications based thereon between the host device 102 and client device 104 with perfect forward secrecy.

The client device 104 may have a fixed random private key (F), fixed public key (PK), and one or more fixed shared secrets hard coded into the device. These fixed values may have been generated and hard coded into the client device 104 at time of manufacture, or may have been generated and hard coded by the client cryptography unit 128, such as during a device initialization phase. The client cryptography unit 128 may be configured to listen for a host device 102 that is accepting connections and initiate a new connection by sending PK to the host device 102 over the wireless communications link 106.

The client cryptography unit 128 may be configured to receive a public key (PK_H) from the host device 102. This received public key may be a fresh public key generated by the host device 102 specifically for establishing a new communications session with the client device 104. The client cryptography unit 128 may then be configured to establish a first shared secret key with the host device 102 in accordance with a public key agreement protocol, such as, for example, the Diffϊe-Hellman key agreement protocol. The first shared secret key may be established based at least in part upon the fixed public key and PK_H. In this regard, the client cryptography unit 128 may be configured to calculate the first shared secret key based at least in part upon the received PKH and the fixed private key, F. The host device 102 may, as described above, calculate the same first shared secret key based at least in part on PK and a random private key generated by and known only to the host device 102. The client cryptography unit 128 may additionally be configured to receive a check value from the host device 102. The host device 102 may have calculated the check value based at least in part upon the first shared secret as calculated at the host device and the fixed shared secret as described above. The client cryptography unit 128 may then be configured to calculate a value based at least in part upon the first shared secret key as calculated by the client cryptography unit 128 and the fixed shared secret key. The client cryptography unit 128 may additionally be configured to compare the calculated value with the received check value to ensure that the values are equivalent so as to authenticate the first shared secret key.

The client cryptography unit 128 may further be configured to generate a fresh private key (A) and generate a fresh public key (PK_D) based at least in part upon A. The client cryptography unit 128 may additionally be configured to send PK_D to the host device 102 over the wireless communications link 106. PK_D may be generated specifically for association with the host device 102 and establishment of a new communications session. Accordingly, PK_D is not generated based upon the fixed shared secret value or PK. The client cryptography unit 128 may then be configured to establish a second shared secret key with the host device 102 in accordance with a public key agreement protocol, such as, for example, the Diffie-Hellman key agreement protocol. The second shared secret key may be established based at least in part upon the generated PK_D and the received PK_H. In this regard, the client cryptography unit 128 may, calculate the second shared secret key based at least in part on PK_H and the fresh private key A. As described above, the host device 102 may calculate the same second shared secret key based at least in part upon the received PKD and generated B.

The client cryptography unit 128 may additionally be configured to facilitate authentication of the second shared secret key by the host device 102 based at least in part upon one or more of the first shared secret key and the fixed shared secret. In an exemplary embodiment, the client cryptography unit 128 may be configured to calculate a check value based at least in part upon the second shared secret key and the fixed shared secret. The client cryptography unit 128 may then be configured to send the calculated check value to the host device 102 so that the host device 102 can calculate its own check value and verify that the two values are equivalent as described above.

FIG. 3 illustrates a control flow diagram of communications signals passed between a host device 102 and a client device 104 according to an exemplary embodiment of the present invention. Initially, the client device 104 may have a fixed secret value and a fixed public key (PK) hard coded into the device. At operation 302, the host device 102 may receive the fixed shared secret value. At operation 304, the host device may receive PK from the client device 104. Operation 306 may comprise the host cryptography unit 118 of the host device 102 generating a public key PK_H for use in establishing communications with the client device 104. The host device 102 may then send PK_H to the client device at operation 308. The host cryptography unit 118 and the client cryptography unit 128 may then establish a first shared secret key using a public key agreement protocol based at least in part upon PK and PK_H at operation 310. Operation 312 may comprise the host cryptography unit 118 and/or the client cryptography unit 128 authenticating the first shared secret key. This authentication may be performed by any appropriate method, such as, for example, the calculation and exchange of check values. Operation 314 may comprise the client cryptography unit 128 generating a fresh public key PK_D for use in establishing communications with the host device 102. The client device 104 may then send PK_D to the host device 102 at operation 314. Operation 318 may comprise the host cryptography unit 118 and client cryptography unit 128 establishing a second shared secret key based at least in part upon PK_D and PK_H. The host cryptography unit 118 and client cryptography unit 128 may then authenticate the second shared secret key based at least in part upon one or more of the first shared secret key and the fixed shared secret or both, such as, for example, through the use of check values as described above, at operation 320. Operation 322 may comprise the host device 102 and client device 104 engaging in encrypted communications based at least in part upon the second shared secret key. In this regard, the second shared secret key or one or more session keys derived therefrom may be used to encrypt/decrypt communications sent between the host device 102 and client device 104.

An exemplary embodiment of the present invention may be implemented into the wireless USB specification. A client device 104 in accordance with the wireless USB standard may have two fixed shared secret values (denoted "PIN" and "CV") as well as a fixed private key (F) and a fixed public key (PK). CV may be calculated based at least in part upon PK and PIN and in this way may function as a check value that a host device 102 may use to verify PK as belonging to a specific client device 104 for which the client device's shared secret PIN is known. For example, CV may be calculated as 3 digits of SHA-256(PK || PIN || "fixed tag") where SHA-256 is a standard cryptographic hash function. Below is a list of operations that may be performed by the host device 102 and client device 104 to establish a shared private key with perfect forward secrecy in wireless USB wherein the client device 104 has a fixed shared secret and fixed public key. The example uses the Diffie-Hellman key agreement protocol for purposes of example. As is known in the art, "g" is a generating element known to the devices and "p" is a prime number known to the devices for use in a modulo function for purposes of key derivation.

I . User conditions the host device 102 to allow new associations and the client device 104 to start a new association. 2. User may enter PIN and CV into the host device 102.

3. Client device 104 may listen for a host device 102 accepting new client device 104 connections and initiate a "new" connection when one is found.

4. Client device 104 may generate a fresh random secret A and compute PK_D = g^A mod p .

5. Host device 102 may generate a fresh random secret B and compute PK_H = g^B mod p.

6. Client device 104 may send PK to the host device 102.

7. Host device 102 may compute 3 digits of SHA-256(PK || PIN || "fixed tag") and verify that it is the same as CV. Host device

102 may abort the association if the verification fails.

8. Host device 102 may compute the first shared secret key DHKeyA = SHA-256(PK⁶ mod p).

9. Host device 102 may compute PC_H = SHA-256(DHKeyA || PIN Il "host check")

10. Host device 102 may send PK_H and PC_H to the client device 104.

I I. Client device 104 may compute the first shared secret key DHKeyA = SHA-256(PK_H mod p). 12. Client device 104 may compute SHA-256(DHKeyA || PIN |

"host check") and verify that it is equal to PC_H- Client device may abort the association if the verification fails. 13. Client device 104 may compute the second shared secret key

DHKeyC = SHA-256(PK_H ^X mod p). 14. Client device 104 may compute PC₀ = SHA-256(DHKeyC ||

PIN Il "device check").

15. Client device 104 may send PK_D and PC_D to the host device 102.

16. Host device 102 may compute the second shared secret key DHKeyC = SHA-256(PK_D ^B mod p).

17. Host device 102 may compute SHA-256(DHKeyC || PIN || "device check") and verify that it is equal to PC_D- Host device 102 may abort the association if the verification fails. 18. The host device 102 and client device 104 may both compute the connection key CK = the first 128 bits of HMAC-SHA- 256DHKeyc("connection key").

Alternatively, the check value PC_D in step 14 may be computed as PC_D = SHA- 256(DHKeyC || DHKeyA || "device check") or PC₀ = SHA-256(DHKeyC || DHKeyA || PIN || "device check").

As will be appreciated, the above operations are merely an example of one potential implementation of an embodiment of the invention for use in facilitating an association between a host device 102 and client device 104 communicating over a wireless USB communications link. Other implementations are possible within the scope of the invention. Further, it will be appreciated, that embodiments of the invention may similarly be implemented in other wireless communications protocols, such as for example, the Bluetooth™ Secure Simple Pairing, Wi-Fi Protected Set-Up and WiMedia Association Model protocols.

FIG. 4 is a flowchart of a system, method, and computer program product according to an exemplary embodiment of the invention. It will be understood that each block or step of the flowchart, and combinations of blocks in the flowchart, may be implemented by various means, such as hardware, firmware, and/or software including one or more computer program instructions. For example, one or more of the procedures described above may be embodied by computer program instructions. In this regard, the computer program instructions which embody the procedures described above may be stored by a memory device of a mobile terminal, server, or other computing device and executed by a processor in the computing device. In some embodiments, the computer program instructions which embody the procedures described above may be stored by memory devices of a plurality of computing devices. As will be appreciated, any such computer program instructions may be loaded onto a computer or other programmable apparatus to produce a machine, such that the instructions which execute on the computer or other programmable apparatus create means for implementing the functions specified in the flowchart block(s) or step(s). These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart block(s) or step(s). The computer program instructions may also be loaded onto a computer or other programmable apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block(s) or step(s).

Accordingly, blocks or steps of the flowchart support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that one or more blocks or steps of the flowcharts, and combinations of blocks or steps in the flowchart, may be implemented by special purpose hardware-based computer systems which perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.

In this regard, one exemplary method for providing secure pairing and association for wireless devices according to an exemplary embodiment of the present invention is illustrated in FIG. 4. The method illustrated in FIG. 4 describes operations that may take place at a host device 102 during the process of associating the host device 102 with a client device 104. The method may include the host cryptography unit 118 receiving a fixed shared secret value associated with a remote device, such as, for example, a client device 104, at operation 400. Operation 410 may comprise the host cryptography unit 118 receiving a fixed public key from the remote device, wherein the fixed public key is associated with the remote device. The host cryptography unit 118 may then verify the authenticity of the fixed public key as being associated with the remote device based at least in part upon the fixed shared secret value at operation 420. Operation 430 may comprise the host cryptography unit 118 generating a public key. The generated public key is associated with a local device, such as, for example, a host device 102. Operation 440 may comprise the host cryptography unit 118 sending the generated public key to the remote device. The host cryptography unit 118 may then establish, with the remote device, a first shared secret key in accordance with a public key agreement protocol based at least in part upon the received fixed public key and the generated public key at operation 450. Operation 460 may comprise the host cryptography unit 118 calculating and sending an additional value, such as a check value, to the remote device. The remote device may authenticate the first shared secret key based at least in part upon this additional value. Operation 470 may comprise the host cryptography unit 118 receiving, from the remote device, a fresh public key associated with the remote device. The fresh public key is generated by the remote device for establishing a communications session with the local device. Operation 480 may comprise the host cryptography unit 118 establishing, with the remote device, a second shared secret key in accordance with the public key agreement protocol for use in communications between the local device and the remote device. Establishment of the second shared key may be based at least in part upon the received fresh public key and the generated public key. Operation 490 may comprise the host cryptography unit 118 authenticating the second shared secret key based at least in part upon one or more of the first shared secret key and the fixed shared secret.

The above described functions may be carried out in many ways. For example, any suitable means for carrying out each of the functions described above may be employed to carry out embodiments of the invention. In one embodiment, a suitably configured processor may provide all or a portion of the elements of the invention. In another embodiment, all or a portion of the elements of the invention may be configured by and operate under control of a computer program product. The computer program product for performing the methods of embodiments of the invention includes a computer-readable storage medium, such as the non-volatile storage medium, and computer-readable program code portions, such as a series of computer instructions, embodied in the computer-readable storage medium.

As such, then, some embodiments of the invention may provide several advantages to a user of a computing device, such as a mobile terminal 10.

Embodiments of the invention may provide for association of two devices, one of the devices having a fixed shared secret value and a fixed public key, over a wireless communications link with perfect forward secrecy. Accordingly, embodiments of the invention may reduce the possibility of a brute force attack wherein a malicious party may intercept encrypted communications and then acquire the device having fixed values to extract the hard coded fixed values and decrypt the previously recorded communications. In this regard, embodiments of the invention may require minimal computational overhead and may be implemented in any wireless communications protocol while providing perfect forward secrecy.

Many modifications and other embodiments of the inventions set forth herein will come to mind to one skilled in the art to which these inventions pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the embodiments of the invention are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Moreover, although the foregoing descriptions and the associated drawings describe exemplary embodiments in the context of certain exemplary combinations of elements and/or functions, it should be appreciated that different combinations of elements and/or functions may be provided by alternative embodiments without departing from the scope of the appended claims. In this regard, for example, different combinations of elements and/or functions than those explicitly described above are also contemplated as may be set forth in some of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

WHAT IS CLAIMED IS:

1. A method comprising: receiving a fixed shared secret value associated with a remote device; receiving a fixed public key from the remote device, wherein the fixed public key is associated with the remote device; verifying authenticity of the fixed public key as being associated with the remote device based at least in part upon the fixed shared secret value; generating a public key, wherein the public key is associated with a local device; sending the generated public key to the remote device; establishing, with the remote device, a first shared secret key in accordance with a public key agreement protocol based at least in part upon the received fixed public key and the generated public key; receiving a fresh public key associated with the remote device from the remote device, wherein the fresh public key is generated by the remote device for establishing a communications session with the local device; and establishing, with the remote device, a second shared secret key in accordance with the public key agreement protocol for use in communications between the local device and the remote device, wherein the establishment of the second shared key is based at least in part upon the received fresh public key and the generated public key.

2. A method according to Claim 1 , further comprising authenticating the second shared secret key based at least in part upon the first shared secret key or the fixed shared secret value.

3. A method according to Claim 2, wherein authenticating the second shared secret key comprises: receiving a first check value from the remote device; calculating a second check value based at least in part upon the received fixed shared secret value and the second shared secret key; and verifying that the first check value equals the second check value.

4. A method according to Claim 1, further comprising: calculating a session key based at least in part upon the second shared secret key; and engaging in encrypted communications with the remote device based at least in part upon the calculated session key.

5. A method according to Claim 1, wherein the public key agreement protocol is Diffie-Hellman key agreement protocol.

6. A method according to Claim 1 , wherein establishment of the first and second shared secret keys occurs over an unsecured wireless communications link between the local and remote devices and further comprising: engaging in encrypted wireless communications with the remote device over the unsecured wireless communications link based at least in part upon the second shared secret key.

7. A method according to Claim 1, wherein receiving the fixed shared secret value comprises receiving the fixed shared secret value over a user interface.

8. A method according to Claim 1, wherein the fixed shared secret value and the fixed public key are hard coded into the remote device.

9. A method according to Claim 1, wherein establishment of the first and second shared keys occurs over a wireless communications link between the local and remote devices, the wireless communications link implementing wireless universal serial bus protocol or Bluetooth protocol.

10. A computer program product comprising at least one computer- readable storage medium having computer-readable program instructions stored therein, the computer-readable program instructions comprising: a first program instruction for receiving a fixed shared secret value associated with a remote device; a second program instruction for receiving a fixed public key from the remote device, wherein the fixed public key is associated with the remote device; a third program instruction for verifying authenticity of the fixed public key as being associated with the remote device based at least in part upon the fixed shared secret value; a fourth program instruction for generating a public key, wherein the public key is associated with a local device; a fifth program instruction for sending the generated public key to the remote device; a sixth program instruction for establishing, with the remote device, a first shared secret key in accordance with a public key agreement protocol based at least in part upon the received fixed public key and the generated public key; a seventh program instruction for receiving a fresh public key associated with the remote device from the remote device, wherein the fresh public key is generated by the remote device for establishing a communications session with the local device; and an eighth program instruction for establishing, with the remote device, a second shared secret key in accordance with the public key agreement protocol for use in communications between the local device and the remote device, wherein the establishment of the second shared key is based at least in part upon the received fresh public key and the generated public key.

11. A computer program product according to Claim 10, further comprising: a ninth program instruction for authenticating the second shared secret key based at least in part upon the first shared secret key or the fixed shared secret value.

12. A computer program product according to Claim 11 , wherein the ninth program instruction includes instructions for: receiving a first check value from the remote device; calculating a second check value based at least in part upon the received fixed shared secret value and the second shared secret key; and verifying that the first check value equals the second check value.

13. A computer program product according to Claim 10, further comprising: a ninth program instruction for calculating a session key based at least in part upon the second shared secret key; and a tenth program instruction for engaging in encrypted communications with the remote device based at least in part upon the calculated session key.

14. A computer program product according to Claim 10, wherein the public key agreement protocol is Diffϊe-Hellman key agreement protocol.

15. A computer program product according to Claim 10, wherein: the sixth program instruction includes instructions for establishing the first shared secret key over an unsecured wireless communications link between the local and remote devices; and the eighth program instruction includes instructions for establishing the second shared secret key over the unsecured wireless communications link; and further comprising: a ninth program instruction for engaging in encrypted wireless communications with the remote device over the unsecured wireless communications link based at least in part upon the second shared secret key.

16. A computer program product according to Claim 10, wherein the first program instruction includes instructions for receiving the fixed shared secret value over a user interface.

17. A computer program product according to Claim 10, wherein the fixed shared secret value and the fixed public key are hard coded into the remote device.

18. An apparatus comprising a processor configured to: receive a fixed shared secret value associated with a remote device; receive a fixed public key from the remote device, wherein the fixed public key is associated with the remote device; verify the authenticity of the fixed public key as being associated with the remote device based at least in part upon the fixed shared secret value; generate a public key, wherein the public key is associated with a local device; send the generated public key to the remote device; establish, with the remote device, a first shared key in accordance with a public key agreement protocol based at least in part upon the received fixed public key and the generated public key; receive a fresh public key associated with the remote device from the remote device, wherein the fresh public key is generated by the remote device for establishing a communications session with the local device; and establish, with the remote device, a second shared key in accordance with the public key agreement protocol for use in communications between the local device and the remote device, wherein the establishment of the second shared key is based at least in part upon the received fresh public key and the generated public key.

19. An apparatus according to Claim 18, wherein the processor is further configured to authenticate the second shared secret key based at least in part upon the first shared secret key or the fixed shared secret value.

20. An apparatus according to Claim 19, wherein the processor is configured to authenticate the second shared secret key by: receiving a first check value from the remote device; calculating a second check value based at least in part upon the received fixed shared secret value and the second shared secret key; and verifying that the first check value equals the second check value.

21. An apparatus according to Claim 18, wherein the processor is further configured to: calculate a session key based at least in part upon the second shared secret key; and engage in encrypted communications with the remote device based at least in part upon the calculated session key.

22. An apparatus according to Claim 18 wherein the public key agreement protocol is Diffie-Hellman key agreement protocol.

23. An apparatus according to Claim 18 wherein the processor is configured to establish the first and second shared secret keys over an unsecured wireless communications link between the local and remote devices; and wherein the processor is further configured to engage in encrypted wireless communications with the remote device over the unsecured wireless communications link based at lest in part upon the second shared secret key.

24. An apparatus according to Claim 18 wherein processor is configured to receive the fixed shared secret value over a user interface.

25. An apparatus according to Claim 18, wherein the fixed shared secret value and the fixed public key are hard coded into the remote device.

26. An apparatus according to Claim 18, wherein the processor is further configured to establish the first and second shared keys over a wireless communications link between the local and remote devices, the wireless communications link implementing wireless universal serial bus protocol or Bluetooth protocol.

27. An apparatus comprising: means for receiving a fixed shared secret value associated with a remote device; means for receiving a fixed public key from the remote device, wherein the fixed public key is associated with the remote device; means for verifying authenticity of the fixed public key as being associated with the remote device based at least in part upon the fixed shared secret value; means for generating a public key, wherein the public key is associated with a local device; means for sending the generated public key to the remote device; means for establishing, with the remote device, a first shared secret key in accordance with a public key agreement protocol based at least in part upon the received fixed public key and the generated public key; means for receiving a fresh public key associated with the remote device from the remote device, wherein the fresh public key is generated by the remote device for establishing a communications session with the local device; and means for establishing, with the remote device, a second shared secret key in accordance with the public key agreement protocol for use in communications between the local device and the remote device, wherein the establishment of the second shared key is based at least in part upon the received fresh public key and the generated public key.

28. An apparatus according to Claim 27, further comprising means for authenticating the second shared secret key based at least in part upon the first shared secret key or the fixed shared secret value.

29. A system comprising: a first communications device and a second communications device; wherein the first communications device has a hard coded fixed shared secret value and a hard coded fixed public key and wherein the first communications device is configured to generate a fresh public key, send the fixed public key to the second communications device, receive a public key associated with the second communications device from the second communications device, and send the fresh public key to the second communications device; wherein the second communications device is configured to receive the fixed shared secret value and the fixed public key, generate a public key, send the generated public key to the first communications device, and receive the fresh public key from the first communications device; wherein the first and second communications devices are configured to establish a first shared secret key in accordance with a public key agreement protocol based at least in part upon the received fixed public key and the public key generated by the second communications device; and wherein the first and second communications devices are configured to establish a second shared secret key in accordance with the public key agreement protocol based at least in part upon the fresh public key and the public key generated by the second communications device.