Patent Application
20070269040
The same numbers are used throughout the disclosure and figures to reference like components and features.
The following document describes tools capable of enabling secure communication between commonly controlled devices. These tools may do so using a cryptographic protocol where each of the devices generate fresh public/private key pairs, publish a cryptographic hash of their public keys before publishing those public keys, publish and receive each other's public keys once they have received the other device's hash, and authenticate the other device's public key using the received hash. Once authenticated, each of the devices may present an identifier to a user based on a session key of its private key and the other device's public key. The user may indicate that both identifiers are the same; if he or she does so, then the devices may communicate with a very high probability that the communication is secure.
An environment in which the tools may enable these and other actions is set forth below in a section entitled Exemplary Operating Environment. This section is followed by another section describing an exemplary way in which two particular wireless devices may act to enable secure communication and is entitled Example Using Devices A and B. A final section describes various other embodiments and manners in which the tools may enable secure communication between commonly controlled devices, whether wireless or otherwise, and is entitled Other Embodiments of the Tools. This overview, including these section titles and summaries, is provided for the reader's convenience and is not intended to limit the scope of the claims or the entitled sections.
Before describing the tools in detail, the following discussion of an exemplary operating environment is provided to assist the reader in understanding ways in which various inventive aspects of the tools may be employed. The environment described below constitutes but one example and is not intended to limit application of the tools to any one particular operating environment or device type. Other environments and device types may be used without departing from the spirit and scope of the claimed subject matter.
Each of the devices comprises one or more processor(s) 104a or 104b and computer-readable media 106a or 106b, respectively. Wireless device A is illustrated as a laptop and wireless device B as a personal digital assistant (PDA), though other types of devices such as a smart phone, desktop, or tablet PC (to name just a few) may also be used. The tools may be used with devices that communicate non-wirelessly as well, such as devices that communicate through wires to a communication network (not shown).
Each device's processors are capable of accessing and/or executing computer-readable instructions on their computer-readable media. Each computer-readable media comprises or has access to a protocol module 108a or 108b. At least one of the protocol modules is capable of providing public/private key pairs, computing cryptographic hashes, and computing a session key based on its own private key and a received public key, as will be described in greater detail below.
Each device (and its media) may also comprise a wireless transmitter/receiver 110a or 110b, an output-to-user element 112a or 112b, and an input-from-user element 114a or 114b. Each of the transmitter/receiver and elements 112 and 114 may be integral with each other or the protocol module in any combination. Each may also comprise hardware and software. The transmitter/receiver, for instance, may comprise a physical device to send and receive wireless communications and software resident on the computer-readable media and used to manage the physical device; this software may operate integrated with or separate from the protocol module.
Each output-to-user element is capable of indicating text to a user, such as a four-digit number through a visual display. In some cases one of the devices may not have an output-to-user element, such as in cases where only one of the devices displays a number and the other receives the number from the user but does not display it. Each input-from-user element is capable of receiving input from a user, such as text input through a keyboard or a selection through a button.
In this section the two wireless devices A and B of
This example is illustrated with two parallel processes 200a and 200b of
At blocks 202a and 202b each device's protocol module 108a or 108b creates fresh public/private key pairs: Pa and Sa by device A and Ph and Sb by device B. In this embodiment, each attempt by the devices to set up secure communication between these devices uses new public/private key pairs.
At blocks 204a and 204b each device's protocol module computes a SHA-256 (Secure Hash Algorithm 256) of the device's created public key: device A computes a hash of Pa to provide HPa and device B computes a hash of Pb to provide HPb.
At blocks 206a and 206b each device's wireless transmitter/receiver 110a or 110b publishes (e.g., transmits wirelessly) its respective hashes HPa or HPb. These hashes are assumed to be receivable by the other device, though an active interloper could intercept each. The active interloper, however, would have to provide the devices with its own hash to interlope between them but does not yet have the public keys on which the devices' hashes were made because each public key has not yet been transmitted.
At blocks 208a and 208b each device's wireless transmitter/receiver receives the other device's published hashes: device A receives HPb and device B receives HPa. Once each has received the other device's hash, they may then wirelessly transmit the public keys. The devices may also check to make sure that the hash received is not equal to the hash that was sent. If they are the hash received may have been reflected from a malicious interloper and so the devices abort.
At blocks 210a and 210b each device's wireless transmitter/receiver publishes (e.g., transmits wirelessly) its public keys: device A wirelessly transmits Pa and device B wirelessly transmits Pb.
At blocks 212a and 212b each device's wireless transmitter/receiver receives the other device's published public keys: device A receives Pb and device B receives Pa.
At blocks 214a and 214b each device's protocol module computes a SHA-256 hash of the public key received to check that the hash received matches the public key received. Thus, device A computes a SHA-256 hash of Pb and compares it with the hash HPb previously received. If they match, the process continues. If they do not, the process aborts. Device B does the same with Pa and HPa.
At blocks 216a and 216b each device's protocol module computes a session key Sk of its own private key and the received public key. Thus, device B computes a session key Sk(b) of Pa and Sb. Likewise, device A computes a session key Sk(a) of Pb and Sa. In this embodiment, each device does so using Elliptic Curve Diffie-Helman as will be understood by the skilled artisan.
At blocks 218a and 218b each device's protocol module computes a four-digit hash of its session key, its public key, and the other device's public key. Here device A computes a four-digit hash (e.g., “2048”) of Sk(a), Pa, and Pb and device B computes a four-digit hash (e.g., “2048”) of Sk(b), Pb, and Pa. Four digits are generally easy for a user to compare with a low probability of error and irritation to the user. If each device's session key is the same, the four-digit hash will also be the same. The session keys will be the same if the public key received from the other device is authentic. The authenticity of the public key received is proven to a very high probability by computing the SHA-256 hash of the received public key and comparing it with the previously received hash of that public key. At this point, however, the devices do not yet know if their four-digit hashes 4Ha and 4Hb are equivalent.
At blocks 220a and 220b each device's output-to-user element 112a or 112b displays its four-digit hash to a user. Thus, device A will display “2048” and device B will display “2048”. If the session keys of the devices were different, the odds of them both showing the same four-digit hash would be very low.
The user may look at both of the displays and determine if the displayed numbers match. If they do the user may indicate this. If they don't the user can abort the process and start over. Here the displayed numbers are the same, so the user indicates this through the input-from-user element 114a or 114b (e.g., presses an enter key on a laptop's keyboard and some button on a PDA). Note that the user's input is received out-of-band; his or her input is independent of the device's wireless communication with each other and so may not be intercepted by a malicious device or software. The devices do not need to have a shared secret before the protocol or share a secret with each other wirelessly during the protocol.
At blocks 222a and 222b each device receives through its input-from-user element the user's indication that the four-digit hashes match. If the user does not indicate this the process aborts before reaching blocks 224a or 224b.
At blocks 224a and 224b both devices communicate securely with each other.
In the above section one exemplary way is described in which the tools may act to enable secure communication between commonly controlled devices. Other embodiments of the tools are provided below as part of a process 300 shown in
Process 300 is illustrated as a series of blocks representing individual operations or acts performed by the tools. Process 300 may be performed by devices attempting to set up secure communications with help from one or more users. These devices may include devices 102a and 102b of
At block 302 each device creates a fresh public/private key pair. A fresh public key enables the tools to trust a received public key based on a previously received hash of that public key. It is possible for the devices to use public/private key pairs that are not just created, but those keys may not have been previously exposed to possible interlopers.
At block 304 at least one of the devices commits to its fresh public key, which is received by the other device. The tools may commit to a fresh public key by publishing a cryptographic hash of that public key so long as the cryptographic hash is not reversible. This publication may be wireless or otherwise, such as communication through a telephone or broad-band wired connection to the Internet. In the above example of
At block 306 each device publishes its public key and receives another device's public key. At least one of these public keys was committed to at block 304. This public key may be committed to because a hash of it was sent and will later be used to authenticate this public key. The probability of an interloper finding a fake public key having this same hash is extremely low based on the security of the cryptographic hash (e.g., SHA-256). And, even if the interloper could find such a fake public key, a session key of the fake public key would not match-also to a high probability.
At block 308 at least one of the devices authenticates the other device's public key based on the other device's commitment. The commitment, such as the above example of a SHA-256 hash of the public key, may be used to check that the public key is authentic. The tools may compute a same cryptographic hash of the public key as was received, such as computing a SHA-256 of the received public key and making sure that it matches the previously received cryptographic hash.
At block 310 each device computes an identifier. The identifier will be identical if the public keys received by each device are authentic. The identifier may be a hash of the session key alone or with other information to generate a number or text that may easily be handled by a user, such as three-to-seven alpha and/or numeric digits. More than seven digits are often difficult for users to accurately compare. Fewer than three digits (e.g., two) provide a potential interloper at least a 1% chance of success. The identifier need not be a particular type of hash or session key so long as it will, with a high probability, be identical only if the pubic keys received by each device are authentic. In the above example illustrated in
At block 312 at least one of the devices provides the identifier in a form that is intelligible to a user. The user can confirm or disallow that the identifiers are the same for both devices. The user can also enable one or more of the devices to determine if the identifiers are identical. For example, one device may display its identifier and the other wait for the user to enter the identifier displayed. If the entered identifier is the same as the identifier calculated by the device in which it was entered, the device may determine that the identifiers are the same. In the above example of
At block 314 the devices receive a user's input confirming or enabling confirmation (or a disallow) that the identifiers are the same.
If the identifiers are the same, the devices at block 316 may commence communication with a very high probability that their communication is secure. Note that this probability is not subject to a cryptographic attack based on the size of the identifier presented to the user. If the identifier is a four-digit number the probability that an interloper has intercepted and breached the security protocol is related to the size of this number but the interloper is not able to create collisions or make some other cryptographic attack based on the size of this four-digit number. Rather, an interloper's cryptographic attack will have to successfully break the cryptographic hash of the public key or keys—which with SHA-256 or other currently used hashes is believed to be nearly impossible.
The above-described tools enable secure communication between commonly controlled devices. The tools may do so without requiring a shared secret or complex user interaction with the devices. By so doing, users may more easily and/or securely use commonly controlled devices. Although the tools have been described in language specific to structural features and/or methodological acts, it is to be understood that the tools defined in the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the tools.
