Source: http://patents.com/us-8171292.html
Timestamp: 2018-11-16 07:48:31
Document Index: 417729070

Matched Legal Cases: ['Application No. 09157671', 'Application No. 09157670', 'Application No. 09157671', 'Application No. 09157671', 'Application No. 09157671', 'Application No. 09157671', 'Application No. 09157671', 'Application No. 09157670', 'Application No. 09157670', 'Application No. 09157670', 'Application No. 09157670', 'Application No. 09157670']

US Patent # 8,171,292. Systems, devices, and methods for securely transmitting a security parameter to a computing device - Patents.com
United States Patent 8,171,292
Brown , et al. May 1, 2012
Inventors: Brown; Michael S. (Waterloo, CA), Little; Herbert A. (Waterloo, CA)
Appl. No.: 12/420,387
Current U.S. Class: 713/171 ; 380/223; 380/228; 380/259; 380/278; 380/279
Current International Class: H04L 9/32 (20060101); H04N 7/167 (20110101); H04L 9/00 (20060101); H04L 9/08 (20060101)
Field of Search: 713/171 380/223,228,259,278,279
5946377 August 1999 Wolf
6405922 June 2002 Kroll
6442692 August 2002 Zilberman
7230945 June 2007 Yeom
7886345 February 2011 Kaliski et al.
2003/0136837 July 2003 Amon et al.
2005/0273609 December 2005 Eronen
2007/0198837 August 2007 Koodli et al.
2010/0030642 February 2010 Huffman et al.
2010/0074443 March 2010 Ishii et al.
1469372 Oct., 2004 EP
1650894 Apr., 2006 EP
1659894 May., 2006 EP
2239918 Oct., 2008 EP
2239919 Oct., 2010 EP
Co-pending U.S. Appl. No. 12/420,421. "Systems, Devices, and Methods for Securely Transmitting a Security Parameter to a Computing Device", filed Apr. 8, 2009. cited by other .
Office Action. Co-pending U.S. Appl. No. 12/420,421. Dated: Aug. 31, 2011. cited by other .
Response. Co-pending U.S. Appl. No. 12/420,421. Dated: Nov. 30, 2011. cited by other .
Decision to grant a European Patent pursuant to article 97(1) EPC. Application No. 09157671.0. Dated: May 12, 2011. cited by other .
Decision to grant a European Patent pursuant to article 97(1) EPC. Application No. 09157670.2. Dated: Jul. 14, 2011. cited by other .
Extended European Search Report. Application No. 09157671.0. Dated: Aug. 14, 2009. cited by other .
Communication Pursuant to article 94(3) EPC. Application No. 09157671.0. Dated: Nov. 4, 2009. cited by other .
Summons to Attend Oral Proceedings Pursuant to Rule 115(1) EPC. Application No. 09157671.0. Dated: Apr. 23, 2010. cited by other .
Provision of the Minutes in accordance with Rule 124(4) EPC. Application No. 09157671.0. Dated: Oct. 26, 2010. cited by other .
Communication Under Rule 71(3) EPC. Application No. 09157671.0. Dated: Nov. 19, 2010. cited by other .
"Using a Two Dimensional Colorized Barcode Solution for Authentication in Pervasive Computing" by William Claycomb and Dongwan Shin (2006 ACS/IEEE International Conference on Pervasive Services; Jun. 26-29, 2006; pp. 173-180). cited by other .
"Talking to strangers: Authentication in ad-hoc wireless networks" by D. Balfanz, D. K. Smetters, P. Stewart, and H. C. Wong (Proceedings of Network and Distributed System Security Symposium 2002 (NDSS02); San Diego, CA; Feb. 2002). cited by other .
"Securing Spontaneous Communications in Wireless Pervasive Computing Environments" by Dongwan Shin (Seventh IEEE International Symposium on Multimedia; Dec. 12-14, 2005; 6 pp.). cited by other .
Extended European Search Report. Application No. 09157670.2. Dated: Aug. 14, 2009. cited by other .
Communication Pursuant to article 94(3) EPC. Application No. 09157670.2. Dated: Nov. 4, 2009. cited by other .
Summons to Attend Oral Proceedings Pursuant to Rule 115(1) EPC. Application No. 09157670.2. Dated: Apr. 23, 2010. cited by other .
Provision of the Minutes in accordance with Rule 124(4) EPC. Application No. 09157670.2. Dated: Nov. 10, 2010. cited by other .
Communication Under Rule 71(3) EPC. Application No. 09157670.2. Dated: Jan. 24, 2011. cited by other .
"Visual device identification for security services in ad-hoc wireless networks" by D. Shin and S. Im (Proceedings of 20th International Symposium on Computer and Information Sciences (ISCIS'05); Istanbul, Turkey; Oct. 2005). cited by other.
1. A method of transmitting one or more security parameters from a first computing device to a second computing device, the method being performed at the first computing device, the method comprising: generating an image for transmission to the second computing device, wherein the image is a representation of first data, the first data comprising a password, wherein the password is not derived from the one or more security parameters; transmitting the image to the second computing device at which the password is determinable from the image; and performing a key exchange with the second computing device over a communication channel between the first and second computing devices, wherein second data is exchanged between the first and second computing devices in accordance with a key exchange protocol, such that a key is derived at each of the first and second computing devices using the password, and wherein the one or more security parameters is transmitted to the second computing device during the key exchange; wherein said performing further comprises computing a confirmation value based on at least the one or more security parameters and the key derived at the first computing device, and transmitting the confirmation value to the second computing device, wherein the one or more security parameters are authenticated when the confirmation value is successfully verified at the second computing device; and wherein the one or more security parameters comprise one or more public keys stored on the first computing device.
13. A first computing device comprising a processor and a memory, the processor configured to perform a method of transmitting one or more security parameters to a second computing device by executing one or more application modules, said one or more application modules comprising: a module configured to generate an image for transmission to the second computing device, wherein the image is a representation of first data, the first data comprising a password, wherein the password is not derived from the one or more security parameters; a module configured to transmit the image to the second computing device at which the password is determinable from the image; and a module configured to perform a key exchange with the second computing device over a communication channel between the first and second computing devices, wherein second data is exchanged between the first and second computing devices in accordance with a key exchange protocol, such that a key is derived at each of the first and second computing devices using the password, and wherein the one or more security parameters is transmitted to the second computing device during the key exchange; wherein said module configured to perform a key exchange is further configured to compute a confirmation value based on at least the one or more security parameters and the key derived at the first computing device, and to transmit the confirmation value to the second computing device, wherein the one or more security parameters are authenticated when the confirmation value is successfully verified at the second computing device and wherein the one or more security parameters comprise one or more public keys stored on the first computing device.
15. A non-transitory computer readable storage medium comprising instructions that, when executed by a processor of a first computing device, cause the first computing device to perform acts of a method of transmitting one or more security parameters to a second computing device, the method performed at the first computing device, the acts comprising: generating an image for transmission to the second computing device, wherein the image is a representation of first data, the first data comprising a password, wherein the password is not derived from the one or more security parameters; transmitting the image to the second computing device at which the password is determinable from the image; and performing a key exchange with the second computing device over a communication channel between the first and second computing devices, wherein second data is exchanged between the first and second computing devices in accordance with a key exchange protocol, such that a key is derived at each of the first and second computing devices using the password, and wherein the one or more security parameters is transmitted to the second computing device during the key exchange; wherein said performing further comprises computing a confirmation value based on at least the one or more security parameters and the key derived at the first computing device, and transmitting the confirmation value to the second computing device, wherein the one or more security parameters are authenticated when the confirmation value is successfully verified at the second computing device; and wherein the one or more security parameters comprise one or more public keys stored on the first computing device.
Mobile device 100 may send and receive communication signals over network 200 after network registration or activation procedures have been completed. Network access may be associated with a subscriber or user of a mobile device 100. To identify a subscriber, mobile device 100 may provide for a Subscriber Identity Module ("SIM") card 126 (or e.g. a USIM for UMTS, or a CSIM or RUIM for CDMA) to be inserted in a SIM interface 128 in order to communicate with a network. SIM 126 may be one example type of a conventional "smart card" used to identify a subscriber of mobile device 100 and to personalize the mobile device 100, among other things. Without SIM 126, mobile device 100 may not be fully operational for communication with network 200. By inserting SIM 126 into SIM interface 128, a subscriber may access all subscribed services. Services may include, without limitation: web browsing and messaging such as e-mail, voice mail, Short Message Service (SMS), and Multimedia Messaging Services (MMS). More advanced services may include, without limitation: point of sale, field service and sales force automation. SIM 126 may include a processor and memory for storing information. Once SIM 126 is inserted in SIM interface 128, it may be coupled to microprocessor 102. In order to identify the subscriber, SIM 126 may contain some user parameters such as an International Mobile Subscriber Identity (IMSI). By using SIM 126, a subscriber may not necessarily be bound by any single physical mobile device. SIM 126 may store additional subscriber information for a mobile device as well, including datebook (or calendar) information and recent call information.
Short-range communications subsystem 122 provides for communication between mobile device 100 and different systems or devices, without the use of network 200. For example, subsystem 122 may include an infrared device and associated circuits and components for short-range communication. Examples of short-range communication include standards developed by the Infrared Data Association (IrDA), Bluetooth.RTM., and the 802.11 family of standards (Wi-Fi.RTM.) developed by IEEE.
One component that may be present but not directly part of the wireless router 26 is an Internet firewall 27, which may be off-the-shelf and would protect the wireless router 26 at a lower IP-layer type protocol. Once through the firewall, the host system 250 may connect to one of a plurality of host interface handlers (HIHs) 30. There can be any number of HIHs depending on the number of hosts that are configured and required in the system. The HIH 30 may use various parts of the database 31 to confirm and register the incoming host connection. The known hosts 31a sub-component of the database may provide a way of validating that the host is known and marking its state as `present` once the host is connected and authorized. Once the host connection is established, a secure and authenticated point-to-point communication connection may be ready for the exchange of data between the host system 250 or service and the wireless router 26. There may be a plurality of such communication connections between the wireless router 26 and a plurality of host systems 250 (e.g. as identified by 250a, 250b, 250c) or services.
The next component is the network interface adapter (NIA) 38, which could have a communications link directly to the WTH 36, or the NIA 38 could be accessible via the network backbone 37. The NIA 38 may provide a direct interface to the wireless network 200 being supported. Since many of the current wireless data networks 200 may have unique communication connection requirements, this component can buffer the other wireless router components from many of the specific nuances of the particular wireless network it is in communication with. The NIA 38 may be used to isolate the WTH 36 from much of the details of communication links and physical interface requirements of each wireless network 200. There could be any number of wireless networks 200, all with their own connection methods (e.g. shown as 200a, 200b, 200c). In some cases, a proprietary protocol over X.25 may be employed, in the Mobitex or Datatac networks, for example. In other cases, a proprietary protocol over TCP/IP may be employed, like in newer version of the Datatac network, for example. In other cases, an IP connection may be employed, supporting either a TCP or UDP data exchange method, like the CDMA, W-CDMA, and GPRS networks.
LAN 250 comprises a number of network components connected to each other by LAN connections 260. For instance, a user's desktop computing device ("desktop computer") 262a with an accompanying cradle 264 for the user's mobile device 100 may be situated on LAN 250. Cradle 264 for mobile device 100 may be coupled to computer 262a by a serial or a Universal Serial Bus (USB) connection, for example. Other user computers 262b are also situated on LAN 250, and each may or may not be equipped with an accompanying cradle 264 for a mobile device. Cradle 264 facilitates the loading of information (e.g. PIM data, private symmetric encryption keys to facilitate secure communications between mobile device 100 and LAN 250) from user computer 262a to mobile device 100, and may be particularly useful for bulk information updates often performed in initializing mobile device 100 for use. The information downloaded to mobile device 100 may include S/MIME certificates or PGP keys used in the exchange of messages.
Message server 268 typically acts as the primary interface for the exchange of messages, particularly e-mail messages, within the organization and over the shared network infrastructure 224. Each user in the organization that has been set up to send and receive messages is typically associated with a user account managed by message server 268. One example of a message server 268 is a Microsoft Exchange.TM. Server. In some implementations, LAN 250 may comprise multiple message servers 268. Message server 268 may also be configured to provide additional functions beyond message management, including the management of data associated with calendars and task lists, for example.
While Simple Mail Transfer Protocol (SMTP), RFC822 headers, and Multipurpose Internet Mail Extensions (MIME) body parts may be used to define the format of a typical e-mail message not requiring encoding, Secure/MIME (S/MIME), a version of the MIME protocol, may be used in the communication of encoded messages (i.e. in secure messaging applications). S/MIME enables end-to-end authentication and confidentiality, and provides data integrity and privacy from the time an originator of a message sends a message until it is decoded and read by the message recipient. Other standards and protocols may be employed to facilitate secure message communication, such as Pretty Good Privacy.TM. (PGP) and variants of PGP such as OpenPGP, for example. It will be understood that where reference is generally made to "PGP" herein, the term is intended to encompass any of a number of variant implementations based on the more general PGP scheme.
When reference is made to the application of encoding to message data, this means that the message data is encoded using an encoding technique. As noted above, an act of encoding message data may include either encrypting the message data or signing the message data. As used in this disclosure, "signed and/or encrypted" means signed or encrypted or both.
Mobile device 100 may also be configured to store the private key of the public key/private key pair associated with the user, so that the user of mobile device 100 can sign outgoing messages composed on mobile device 100, and decrypt messages sent to the user encrypted with the user's public key. The private key may be downloaded to mobile device 100 from the user's computer 262a through cradle 264, for example. The private key may be exchanged between the computer 262a and mobile device 100 so that the user may share one identity and one method for accessing messages.
A first computing device, such as a mobile device (e.g. mobile device 100 of FIG. 1 represented as mobile device 100a), begins by communicating a password 510 to a second computing device, such as a mobile device (e.g. mobile device 100 of FIG. 1 represented as mobile device 100b). An out-of-band communication path may be used for communicating the password between the two computing devices to provide greater security. Once both computing devices have the password, a key exchange may then be performed between the first computing device and the second computing device over a communication channel between the two computing devices, which may be different from the path used to communicate the password, in accordance with a key exchange protocol 520.
In this embodiment, as part of the key exchange protocol 520, an encryption key is derived at each of the first computing device and the second computing device using password 510. The encryption key or a session key derived from the encryption key 530a, 530b, may then be used to encrypt one or more security parameters (e.g. one or more public keys) or other data to be communicated, thereby establishing an encrypted session 540 over the communication channel between the two computing devices.
In the example embodiments described herein, for illustrative purposes, it is assumed that a first computing device, such as a mobile device (e.g. mobile device 100 of FIG. 1 represented as mobile device 100a), initiates the transmittal of security parameters. However, persons skilled in the art will appreciate that another computing device, such as a different mobile device (e.g. mobile device 100 of FIG. 1 represented as mobile device 100b), may initiate the transmittal of security parameters and, therefore, the acts of method 600 performed at the first computing device may alternatively be performed by a different computing device.
The password may be a password generated specifically for this instance (e.g. this may be referred to as a "short-term" or "ephemeral" password) or it may be a password that is also used for some other purpose (e.g. this may be referred to as a "long-term" password). Unlike long-term passwords that may be repeatedly used (e.g. for some other purpose such as user authentication), a short-term password may be generated afresh for each instance in which a computing device is to initiate acts of a method for securely transmitting a security parameter to another computing device, in accordance with an embodiment described herein. As compared with long-term passwords, short-term passwords may prevent an attacker from using the previous communication history of a computing device to reconstruct the password, since the password is generated afresh for each new instance. Furthermore, since short-term passwords are generated afresh for each new instance, the password will not typically be pre-stored on the computing device (e.g. in a non-volatile memory). This may prevent an attacker from hacking into the computing device to obtain the password.
First data may also optionally comprise additional identifying information of the first computing device or a user thereof. For example, such identifying information may include, but is not limited to, the name of the user of the first computing device, the name of a group of which the user of the first computing device is a member and is seeking to invite the user of the second computing device to join, the type of the group (e.g. "friend", "family", or "work"), a unique identifier for the particular key exchange request (e.g. as initiated at 615), or a timestamp or expiry data (e.g. to indicate when a key exchange must be completed by), or some combination of the above, for example.
For example, the user of the first computing device can better ensure that the intended recipient, the user of the second computing device, has received the image or audio signal (e.g. the acts of a method in accordance with an embodiment described herein may be initiated when the user of the first and second computing devices are "face-to-face"), and reduce the risk that the image or audio signal will be unknowingly intercepted. Similarly, the user of the second computing device can ensure that the image or audio signal is received from the intended sender, the user of the first computing device, and not from the computing device of an attacker posing as the user of the first computing device. Accordingly, authenticity and confidentiality of the password can be generally maintained, as the authenticity and confidentiality of the image or audio signal that is a representation of first data comprising the password can be maintained.
In some embodiments, the key exchange protocol performed at 630 and 640 may comprise the SPEKE protocol. The SPEKE protocol is one example of a cryptographic method for password-authenticated key agreement, which on the basis of a shared password, allows parties to derive the same encryption key (i.e. a SPEKE established key) for sending secure and authenticated communications to each other, over what may be an otherwise insecure communication channel. The SPEKE protocol may involve a password-authenticated Diffie-Hellman exchange, where the password forms the base or "generator" of the exchange.
Optionally, at 650, where the first computing device (or a user thereof) wishes to transmit one or more security parameters (e.g. one or more public keys) to a second computing device (or a user thereof), the one or more security parameters may be encrypted with the encryption key derived at 635 or a session key derived from the encryption key derived at 635. Accordingly, at 660a, the one or more encrypted security parameters may be transmitted from the first computing device to the second computing device. At 665a, the one or more encrypted security parameters may be received at the second computing device from the first computing device. Upon receiving the one or more encrypted security parameters from the first computing device, the second computing device may decrypt the one or more encrypted security parameters using the encryption key derived at 645 or a session key derived from the encryption key derived at 645 to retrieve the one or more security parameters of the first computing device.
Optionally, at 655, where the second computing device (or a user thereof) wishes to transmit one or more security parameters (e.g. one or more public keys) to a first computing device (or a user thereof), the one or more security parameters may be encrypted with the encryption key derived at 645 or a session key derived from the encryption key derived at 645. Accordingly, at 665b, the one or more encrypted security parameters may be transmitted from the second computing device to the first computing device. At 660b, the one or more encrypted security parameters may be received at the first computing device from the second computing device. Upon receiving the one or more encrypted security parameters from the second computing device, the first computing device may decrypt the one or more encrypted security parameters using the encryption key derived at 635 or a session key derived from the encryption key derived at 635 to retrieve the one or more security parameters of the second computing device.
Persons skilled in the art will appreciate that in different situations, one or more security parameters may be transmitted from the first computing device to the second computing device (e.g. acts 660a and 665a are performed), from the second computing device (e.g. acts 660b and 665b are performed) to the first computing device, or both ways (e.g. acts 660a, 660b, 665a and 665b are performed).
In one variant embodiment, the security parameters are transmitted in unencrypted form. The present inventors recognized that where the one or more security parameters to be transmitted comprises one or more public keys, there would be no need to keep the data secret (and therefore encrypt it) because it is already "public" information (i.e. anyone may have access to it). However, when one or more security parameters are received at a given computing device, it is still typically desirable to ensure that the received security parameters are authentic. In this variant embodiment, although a key is derived at each computing device in accordance with a key exchange protocol (e.g. the SPEKE protocol), this key is not used as an encryption key per se (as in method 600 of FIG. 6), but is instead used as a key for deriving a value that may be verified in order to authenticate the security parameters being exchanged.
For example, at 738, an HMAC may be computed at the first computing device using the key derived at 736, and a hash computed based on the following data: at least some of the first data transmitted to the second computing device at 715 (e.g. a group name, group type, invitation ID, a PIN associated with the first computing device), although the password need not be included in the hashed data; one or more security parameters (e.g. one or more public keys for message encoding) received from the second computing device at 734; and one or more security parameters (e.g. one or more public keys for message encoding) to be transmitted from the first computing device to the second computing device at 750. Those skilled in the art will appreciate that the data included in the hash may not include all of the information identified above, and may include additional data not identified above. Generally, the confirmation value derived at the first computing device may be derived as an HMAC computed by hashing all of the data exchanged in the protocol, in combination with the SPEKE established key derived at the first computing device.
For example, at 754, an HMAC may be computed at the second computing device using the key derived at 748, and a hash computed based on the following data: at least some of the first data received from the first computing device at 720 (e.g. a group name, group type, invitation ID, a PIN associated with the first computing device), although the password need not be included in the hashed data; one or more security parameters (e.g. one or more public keys for message encoding) transmitted to the first computing device at 744; and one or more security parameters (e.g. one or more public keys for message encoding) received from the first computing device at 746. Those skilled in the art will appreciate that the data included in the hash may not include all of the information identified above, and may include additional data not identified above. Generally, the confirmation value derived at the second computing device may be derived as an HMAC computed by hashing all of the data exchanged in the protocol, in combination with the SPEKE established key derived at the second computing device.
FIG. 8 is an example screen capture 800 of the display of the first computing device prompting a user with an option to generate either an image (e.g. a barcode) or an e-mail message (e.g. act 610 of FIG. 6 or act 710 of FIG. 7). For example, in the user interface 800, the user may select a first option 810, "Show them a barcode", to generate an image (e.g. a barcode), or a second option 820, "Send them a message".
FIG. 11 is an example screen capture 1100 of the display of the second computing device prompting a user with an option to receive the transmission of an image (e.g. a barcode) from the first computing device (see e.g. act 620 of FIG. 6 or act 720 of FIG. 7). For example, in a user interface of the second computing device, the user may select an option 1110, "Join a group by scanning a barcode", to begin receiving the image (e.g. a barcode).
FIG. 13 is an example screen capture 1300 of the display of the second computing device upon receiving an image (e.g. a barcode) transmitted from the first computing device, and upon determining first data from the image, such as a barcode for example (see e.g. act 625 of FIG. 6 or act 725 of FIG. 7). For example, a user interface of the second computing device may provide a prompt 1310 to a user to confirm whether to continue with the key exchange. The prompt may show the routing data associated with the first computing device (e.g. a PIN associated with the first computing device). The prompt may also show other identifying information of the first computing device or a user thereof (e.g. that the user of the first computing device is a member of the Work group "Group C"). Where the user wishes to continue, the user may indicate his/her acceptance by selecting a confirmation option 1320, "Join Group", for example. This may allow the user to communicate with other members who have joined the group securely, using the security parameter(s) to be exchanged. Where the user does not wish to continue with the remaining acts of method 600 or method 700, the user may abort by selecting a cancellation option 1330, "Cancel", for example.
By way of further illustration, FIG. 14 is an example screen capture 1400 of a display of the first computing device wherein a user has selected an option to generate a message, instead of an image or audio signal, in accordance with a variant embodiment previously described herein. For example, in a user interface of the first computing device, the user of the first computing device may be prompted to enter in a text field 1410 either the name, email address or PIN, for example, of the second computing device or a user thereof. The user of the first computing device may be prompted to enter in a text field 1420 the password itself and/or a hint for the password in a text field 1430. An e-mail message or PIN message or other types of message addressed to a user of the second computing device may then be sent (e.g. in response the user of the first computing device selecting a send option 1440, "Send invitation").
Previous Patent US 8,171,291 | Next Patent US 8,171,293