U.S. patent application number 11/479747 was filed with the patent office on 2006-11-02 for method of confirming a secure key exchange.
Invention is credited to Ernie F. Brickell.
Application Number | 20060245590 11/479747 |
Document ID | / |
Family ID | 29734450 |
Filed Date | 2006-11-02 |
United States Patent
Application |
20060245590 |
Kind Code |
A1 |
Brickell; Ernie F. |
November 2, 2006 |
Method of confirming a secure key exchange
Abstract
A key exchange protocol can be performed between components of a
system, such as between a computer program being executed by the
processor of a PC (or other computer system) and a peripheral. A
peripheral with a user input capability and a very limited display
capability, such as a keyboard or a mouse, may be used to confirm a
key exchange between the system components in a way that requires
the user to enter only small amounts of input data (e.g.,
keystrokes or mouse clicks). Security between components may be
enhanced without having a negative impact on usability of the
system. Embodiments of the present invention help to deter "man in
the middle" attacks wherein an attacker gains control of a system
component situated between certain communicating system
components.
Inventors: |
Brickell; Ernie F.;
(Portland, OR) |
Correspondence
Address: |
BLAKELY SOKOLOFF TAYLOR & ZAFMAN
12400 WILSHIRE BOULEVARD
SEVENTH FLOOR
LOS ANGELES
CA
90025-1030
US
|
Family ID: |
29734450 |
Appl. No.: |
11/479747 |
Filed: |
June 30, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10177626 |
Jun 18, 2002 |
|
|
|
11479747 |
Jun 30, 2006 |
|
|
|
Current U.S.
Class: |
380/44 |
Current CPC
Class: |
H04L 63/1466 20130101;
H04L 9/0841 20130101; G06F 21/85 20130101; H04L 2463/062 20130101;
H04L 63/061 20130101 |
Class at
Publication: |
380/044 |
International
Class: |
H04L 9/00 20060101
H04L009/00 |
Claims
1. A method of securely exchanging a symmetric key between first
and second components of a system comprising: performing a public
key exchange to share a symmetric key; committing, by the first
component, to a first value; securely exchanging a shared secret
between the first component and the second component; disclosing,
by the first component, the first value; and verifying, by the
second component, the correctness of the first component's
commitment.
2. The method of claim 1, further comprising: committing, by the
second component, to a second value; disclosing, by the second
component, the second value; and verifying, by the first component,
the correctness of the first component's commitment.
3. The method of claim 1, wherein the first value comprises a value
computed from the shared secret, a random nonce, and a public key
of the first component used in the key exchange.
4. The method of claim 1, wherein the first value comprises a value
computed from the shared secret, a random nonce, and the symmetric
key derived from the key exchange.
5. The method of claim 2, wherein the second value comprises a
value computed from the shared secret, a random nonce, and the
symmetric key derived from the key exchange.
6. The method of claim 2, wherein the second value comprises a
value computed from the shared secret, a random nonce, and a public
key of the second component used in the key exchange.
7. An article comprising: a machine accessible medium having a
plurality of machine accessible instructions, wherein when the
instructions are executed by a processor, the instructions provide
for securely exchanging a symmetric key between first and second
components of a system, the instructions including performing a
public key exchange to share a symmetric key; committing, by the
first component, to a first value; securely exchanging a shared
secret between the first component and the second component;
disclosing, by the first component, the first value; and verifying,
by the second component, the correctness of the first component's
commitment.
8. The article of claim 7, further comprising instructions for
committing, by the second component, to a second value; disclosing,
by the second component, the second value; and verifying, by the
first component, the correctness of the first component's
commitment.
9. The article of claim 7, wherein the first value comprises a
value computed from the shared secret, a random nonce, and a public
key of the first component used in the key exchange.
10. The article of claim 7, wherein the first value comprises a
value computed from the shared secret, a random nonce, and the
symmetric key derived from the key exchange.
11. The article of claim 8, wherein the second value comprises a
value computed from the shared secret, a random nonce, and the
symmetric key derived from the key exchange.
12. The article of claim 8, wherein the second value comprises a
value computed from the shared secret, a random nonce, and a public
key of the second component used in the key exchange.
Description
[0001] This U.S. Patent application is a Divisional of U.S. patent
application Ser. No. 10/177,626 filed Jun. 18, 2002.
BACKGROUND
[0002] 1. Field
[0003] The present invention relates generally to computer security
and, more specifically, to establishing a shared encryption key
between system components.
[0004] 2. Description
[0005] A computer system, such as a personal computer (PC),
workstation, server, mainframe computer and so on, may comprise a
number of different components. Some of the system components may
be peripherals used by the system to communicate with a user or
another system. For example, keyboards and mice are commonly used
by the user to input data into the system. A display may be used to
display information to the user. A network interface device may be
used to connect the computer system to other computer systems or
devices over a network.
[0006] Some system components may be coupled to other components
using protocols known as "plug and play" protocols. For example, by
using a Universal Serial Bus (USB), a system may allow multiple
peripheral devices to be connected to the system. When a new
peripheral is connected to the system, the system detects and
identifies the newly added system component. Such a scheme
typically relies on at least one host controller device (known as a
USB host controller for systems using the USB) to control and
monitor access to the system by the connected peripherals.
[0007] In some cases, it may be desired for various system
components to securely communicate with each other. This may be
accomplished in some systems by using well-known cryptographic
methods. However, difficulties may arise when exchanging
cryptographic keys between system components prior to engaging in
secure communications. Generally, the actions of exchanging keys
may be susceptible to a "man in the middle" attack. That is, an
attacker may interpose an unauthorized component or program in
between two communicating components to intercept one or more of
the exchanged keys. The attacker may also possibly substitute other
information in the communication stream between the components.
[0008] In systems using a USB host controller, an attacker could
gain control of the USB host controller during a "man in the
middle" attack and defeat secure communications between a
peripheral and a processor in the system.
[0009] In a certificate-based key exchange protocol, each party
receives a certificate of the public key of the other party. Each
party then verifies the certificate of the other party. Using this
protocol in the present situation for system components would
require that each peripheral (or other system component) have a
unique public/private key pair stored thereon. This would increase
manufacturing costs of the peripheral. In addition, to ensure that
the certificate has not been revoked, the computer system would
need to be "on-line" and communicatively coupled to another
networked computer storing the certificate revocation information
at the time of the protocol use. This may present usability
problems.
[0010] In a thumbprint-based key exchange protocol, each party
generates a public/private key pair and exchanges a hash of the
public keys over a secured channel (e.g., an "out of band"
channel). In the present situation, there is no mechanism when
using this protocol for the peripheral to send the hash of its
public key to the processor. If the processor were to cause the
display of the complete hash of its public key, the user could
enter it using the peripheral (such as a keyboard), but this would
take at least 27 random keystrokes (when using the well-known hash
algorithm known as Secure Hash Algorithm (SHA-1)). In addition,
there would be no means for the processor to know that the
peripheral had received the correct public key (and not an
illegitimate public key inserted by the "man in the middle"
attacker). Thus, if there were such an attack, the peripheral would
know that the hash entered by the user did not match the hash of
the public key received by the peripheral from the processor, but
the processor would not know this. The traditional way to solve
this problem is for the second party (the peripheral) to generate a
public key, send it to the first party (the processor), and then
have the two parties compare their hashes. This doesn't work in
this case since the peripheral does not have a way to display the
peripheral's hash.
[0011] Accordingly, a better method of exchanging keys between
system components is needed.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] The features and advantages of the present invention will
become apparent from the following detailed description of the
present invention in which:
[0013] FIG. 1 is a diagram of a system according to an embodiment
of the present invention;
[0014] FIGS. 2 and 3 are flow diagrams illustrating establishing a
shared encryption key between system components according to an
embodiment of the present invention;
[0015] FIGS. 4 and 5 are flow diagrams illustrating establishing a
shared encryption key between system components according to
another embodiment of the present invention; and
[0016] FIG. 6 is a flow diagram of another embodiment of the
present invention.
DETAILED DESCRIPTION
[0017] An embodiment of the present invention is a key exchange
protocol that can be performed between components of a system, such
as between a computer program being executed by the processor of a
PC (or other computer system) and a peripheral. In embodiments of
the present invention, a peripheral with a user input capability
and a very limited display capability, such as a keyboard or a
mouse, may be used to confirm a key exchange between the system
components in a way that requires the user to enter only small
amounts of input data (e.g., keystrokes or mouse clicks). With the
present invention, security between components may be enhanced
without having a negative impact on usability of the system.
Embodiments of the present invention do not require any uniqueness
of the peripheral, the user need enter only a few inputs, and if
the peripheral does not receive the correct public key of the other
component (such as the processor) during the key exchange protocol,
the processor can detect this situation. Embodiments of the present
invention help to deter "man in the middle" attacks wherein an
attacker gains control of a system component situated between
certain communicating system components.
[0018] Reference in the specification to "one embodiment" or "an
embodiment" of the present invention means that a particular
feature, structure or characteristic described in connection with
the embodiment is included in at least one embodiment of the
present invention. Thus, the appearances of the phrase "in one
embodiment" appearing in various places throughout the
specification are not necessarily all referring to the same
embodiment.
[0019] FIG. 1 is a high level diagram of a system according to an
embodiment of the present invention. System 10 includes various
well-known components such as processor 12 and memory 14. Other
components are not shown in FIG. 1 for purposes of clarity.
Processor 12 and memory 14 may be communicatively coupled using a
bridge/memory controller 16. The bridge/memory controller may be
coupled to a graphics controller 18. The graphics controller
controls the output of display data on display 20. In one
embodiment, communication between the processor, the graphics
controller and the display comprise a trusted channel, such that an
adversary or attacker cannot read or modify the data displayed on
the display. Bridge/memory controller 16 may be coupled to one or
more buses represented as line 22. One device communicatively
coupled to the one or more buses may be bus host controller 24.
When one of the buses is a Universal Serial Bus (USB), the bus host
controller may be a USB host controller.
[0020] When using a USB, a plurality of devices may be coupled to
the bus. For example, user input devices such as keyboard 26 and
mouse 28 may be included in the system for providing input data.
Although a keyboard and mouse are shown in FIG. 1, it is
contemplated that the present invention may be also applied to the
use of other peripherals. In embodiments of the present invention,
an input device being used to securely communicate with other
system components includes at least one trust indicator. For
example, keyboard 26 may include at least one trust indicator 30,
and mouse 28 may include at least one trust indicator 32. In one
embodiment, the at least one trust indicator comprises a plurality
of colored light emitting diodes (LEDs). In one embodiment, an LED
having three distinct colors (such as amber, green, and red) may be
used to represent three different states. The operational meaning
of illuminating the different colors and the states will be
explained below. In other embodiments, other methods of indicating
a current state of the peripheral may be used in place of a colored
LED, such as multiple audible tones, symbols on a liquid crystal
display (LCD), or other perceptible indicators.
[0021] In embodiments of the present invention, peripherals (e.g.,
keyboard and/or mouse) need not be manufactured with a unique key
or value preset. However, a peripheral according to embodiments of
the present invention must include capabilities for asymmetric
cryptography, symmetric cryptography, and a hash function. A
peripheral that has a random number generator and non-volatile
storage enhances the user experience, but are not necessary.
[0022] In the system described at a high level in FIG. 1, it may be
desired that communications between a program being executed by the
processor and a peripheral such as keyboard 26 be secure. One
mechanism for securing such communication is by using known
symmetric cryptographic methods to encrypt and decrypt data
communicated between the components. Prior to beginning such a
communication, a symmetric key must be exchanged between the
components. As shown in FIG. 1, the communications path between the
peripheral and the processor includes the bus host controller.
However, an attacker may gain control of the bus host controller as
part of a "man in the middle" attack, and may then be able to read
and/or modify bus traffic. The attacker could read the symmetric
key during transmission on the bus and decrypt subsequent traffic
over the bus.
[0023] Asymmetric public key cryptography may be used to protect
the symmetric key during the exchange. A first component may
encrypt a symmetric key using the second component's public key and
send the encrypted symmetric key to the second component. The
second component can then decrypt the encrypted symmetric key using
the second component's private key. In order to use asymmetric keys
in this way to defeat a possible attack on transmission of the
symmetric key, initially the public key of the second component
(e.g., processor) must be securely transmitted to the first
component (e.g. peripheral). If the public key is transmitted on
this communications path using typical methods, the attacker may
intercept and replace the public key with an illegitimate public
key, without being detected. To deter such activity, the key
exchange protocol of embodiments of the -present invention may be
used to initially set up secure communications between the
components.
[0024] FIGS. 2 and 3 are flow diagrams illustrating establishing a
shared encryption key between system components according to an
embodiment of the present invention. In the embodiment shown,
communications between a processor 12 and a peripheral (such as a
keyboard 26 or a mouse 28, for example) are discussed, although the
present method may be applied to communications between other
system components. At block 100, the processor generates a
private/public key pair according to known techniques of asymmetric
cryptography. Note that the actions attributed to the processor
herein may be implemented by a computer program executed by the
processor. Furthermore, the actions attributed to the peripheral
may be implemented by any combination of circuitry, firmware,
and/or software resident in the peripheral. The processor stores
the key pair in memory for later use. At block 102, the processor
generates a short nonce (SN) and a long nonce (LN). A nonce may be
a sequence of bits randomly generated by a random number generator.
In one embodiment, the short nonce may comprise four or more
characters, each character including at least six bits. When the
peripheral is a keyboard, each character may represent any of the
keys on the keyboard. In other embodiments, other numbers of bits
may be used for the short nonce. In one embodiment, the long nonce
may comprise randomly generated 160 bits. In other embodiments,
other numbers of randomly generated bits may be used for the long
nonce. At block 104, the processor generates a first hash value by
applying a hash algorithm using the short nonce, the long nonce,
and the public key generated in block 100 as input parameters. In
one embodiment, the SHA-1 hash algorithm may be employed, although
in other embodiments other hash algorithms may be used (e.g., MD5,
and so on).
[0025] At block 106, the processor sends a first command, the first
hash value and the processor's public key to the peripheral. This
data may be sent to the peripheral in one or more separate
transfers. It is assumed that an adversary could choose to prevent
these data transfers from going to the peripheral, or to modify
them. The remaining actions described herein generally assume that
the data transfers occur (although they may be modified by the
attacker). In one embodiment, this first command may be known as a
"reset-learn" command. Receipt of this command by the peripheral
(such as a keyboard 26 or mouse 28), puts the peripheral in a
"learn" mode and activates one portion of the trust indicator 30
resident in the peripheral. The trust indicator acts as a
perceptible sign to the system user that the peripheral is in
"learn" mode.
[0026] In one embodiment, the trust indicator may be a colored LED.
A selected color of the LED (such as an amber LED) may be
illuminated to indicate to the user that the peripheral is now in a
"learn" mode or state. In the "learn" mode, the peripheral performs
the key exchange protocol described herein, and does not forward
any input data entered by the user to the bus host controller 24
until the protocol is complete, except as noted in the remainder of
the protocol. Note the peripheral includes software, firmware
and/or circuitry to receive the first command, interpret the
command, and activate the trust indicator for perception by the
user.
[0027] At block 108, in response to receiving the "reset-learn"
command, the peripheral generates a symmetric key (used as a
session key for subsequent communications), encrypts the symmetric
key using the processor's public key (received in block 106), and
sends the encrypted symmetric key to the processor. Generation of
the symmetric key may require a random number generator in the
peripheral. During this block, there may be an attacker operating
as a "man in the middle" by controlling the bus host controller. It
is assumed that the attacker could choose to prevent the data
transfer of the encrypted symmetric key to the processor, or to
modify it. The remaining actions assume that the data transfer
occurs (although it could be modified). In one embodiment, the
symmetric key may be an Advanced Encryption Standard (AES) key
having 128 bits, although other symmetric keys of different types
and lengths may also be used.
[0028] At block 110, once the processor receives the encrypted
symmetric key, the processor 12 causes the display of the short
nonce, and possibly instructions, on the display 20 using some form
of trusted output. At block 112, the user sees the display of the
short nonce and the activated trust indicator. For example, the
text on the display may instruct the user on the meaning of the
activated trust indicator and what to do with the displayed short
nonce. At this point the trust indicator still indicates the
"learn" mode or state for the peripheral. Based on the display of
the short nonce and the activated trust indicator, the user inputs
the short nonce using the peripheral. For example, the user may
notice the amber LED is illuminated and follow instructions on the
display to input the short nonce. When the peripheral is a
keyboard, the user types the short nonce. When the peripheral is a
mouse, the user may follow directions to manipulate the mouse to
point to certain areas of the display screen and/or depress one or
more of the mouse buttons in a sequence corresponding to the short
nonce. One skilled in the art will realize that other input
mechanisms may also be used. Since the peripheral is in "learn"
mode, the peripheral does not forward the user's input data to the
bus host controller.
[0029] At block 114, the peripheral generates a peripheral nonce
(PN) and encrypts the peripheral nonce with the symmetric key to
form Encrypt(PN). The peripheral nonce may be any randomly
generated value. This may be accomplished by a random number
generator in the peripheral, or it may be accomplished by asking
the user to enter random keystrokes (when the peripheral is a
keyboard) for a short period of time. For a mouse, the random
number could be generated by asking the user to move the mouse for
a while and capturing input data related to the mouse movement.
Processing continues via connector A at block 116 on FIG. 3. At
block 116, the peripheral generates a second hash value by applying
a hash algorithm using the short nonce (received from the user at
block 112), the peripheral nonce, and Encrypt(PN) as input
parameters. In one embodiment, the SHA-1 hash algorithm may be
used. At block 118, the peripheral sends the second hash value to
the processor. Note that in an effort to defeat this scheme, an
attacker (e.g., the "man in the middle") would have to commit to
the second hash value before it sees the short nonce.
[0030] Next, at block 120, the processor sends the long nonce to
the peripheral after receiving the second hash value. In various
embodiments, implementation of blocks 114 and 120 may be performed
in the order shown or the opposite order. At this point, the
peripheral has received the long nonce and the processor's public
key from the processor, and the short nonce from the user. At block
122, the peripheral checks that the hash of the short nonce, long
nonce, and the processor's public key matches the first hash value
sent to the peripheral by the processor (at block 106). The same
hash algorithms must be used. For example, if the SHA-1 hash
algorithm was used at block 104, then the SHA-1 algorithm must be
used at block 122.
[0031] If the first hash value received from the processor equals
the hash value computed by the peripheral, then the peripheral is
assured that the peripheral actually received the processor's
legitimate public key. When the hash values match, the peripheral
activates the trust indicator to indicate a second mode or state
(e.g., an "OK" state) at block 124. For example, the peripheral may
illuminate a green LED, indicating to the user that processing is
proceeding in an authorized manner and that input from the device
can be trusted. If the hash values do not match, then the
peripheral knows that it did not receive the authentic public key
from the processor. The peripheral may then activate the trust
indicator to indicate a third mode or state (e.g., an error state)
at block 124. For example, the peripheral may illuminate a red LED,
indicating to the user that some unauthorized activity has taken
place and that communications between system components are not
secure. In another embodiment wherein only two colors of LEDs are
used, the amber light may be made to blink when an error is
detected. Error handling operations may then be initiated in the
system.
[0032] At this point, the peripheral knows whether it has received
the authentic public key from the processor, but the processor does
not know if the peripheral received the correct key or not. Thus,
at block 126 the peripheral sends the peripheral nonce generated at
block 114 to the processor. At block 128, the processor computes
the hash value of the short nonce generated at block 102, the
peripheral nonce received from the peripheral at block 126, and
Encrypt(PN) (created by the processor by encrypting the peripheral
nonce with the symmetric key, the symmetric key being available to
the processor by decrypting the encrypted symmetric key received at
block 108 using the processor's private key). If the SHA-1 hash
algorithm was used in block 116, then the processor uses the SHA-1
algorithm in block 128. The processor compares the computed hash
value to the second hash value received from the peripheral at
block 118. If the hash values match, then the processor knows that
the peripheral received the processor's public key and that further
secure communications are enabled. In one embodiment, the processor
may display a key exchange complete message on the display to
inform the user that secure communications are now enabled. If the
hash values do not match, error processing may be initiated and/or
secure communications are disabled. For example, the processor may
refuse to accept any trusted input data from the peripheral. In
addition, a warning message may be output to the display informing
the user that input from the peripheral cannot be trusted.
[0033] If the peripheral includes a non-volatile memory, the above
method needs to be performed only once, and then the symmetric key
may be permanently stored in the peripheral and in memory
accessible to the processor. In one embodiment, the symmetric key
may be used to encrypt and decrypt subsequent communications
between system components. In another embodiment, the symmetric key
may be used to encrypt new session keys that are then used for
actual encrypted communications between the peripheral and the
processor. After a session key has been generated, the peripheral
could create a private/public key pair, encrypt the public key and
a machine authentication code (MAC) with the symmetric key, and
send the encrypted public key and MAC to the processor. Then, if
the peripheral includes a non-volatile memory, the peripheral's
private key may be stored permanently in the peripheral, and the
public key of the peripheral may be stored in memory accessible to
the processor.
[0034] Although a particular sequence of actions has been described
herein, in various embodiments different actions may be performed
in different sequences to achieve the same result.
[0035] In other embodiments, various changes may be made to the
above protocol. For example, the actions at block 104 and the
checking in block 122 may be replaced with a new block after block
108, in which the processor generates a hash value of the short
nonce, the long nonce, and an encryption of the long nonce using
the received symmetric key, and the check in block 122 would be a
check on this revised hash value. In this embodiment, the checks
performed by the processor and the peripheral may be the same.
[0036] A complication may ensue when the peripheral is a mouse.
Because the short nonce generated by the processor and the nonce
entered by the user using a mouse may not be exactly the same,
since the mouse was clicked within a button, and not an exact
location, the processor may send its version of the short nonce
along with the long nonce at block 120, and the mouse may send its
version of the short nonce to the processor at block 126, and each
will check that they are close.
[0037] Assuming the hash algorithm used is trustworthy, the best
approach the attacker can make in attacking the present method is
to try to guess the short nonce. When using the SHA-1 hash
algorithm, the chance of defeating the present method is 1 in 2
(6*v), where v is the number of characters in the short nonce and
assuming that there are six bits per character. Hence, the chance
of defeating the present method when only four characters are used
in the short nonce is one in 16 million. Using four characters as
the short nonce provides good security for the present invention,
yet is a sufficiently small number of characters to require the
user to enter into the system so as to have a negligible effect on
usability.
[0038] In another embodiment, the method of exchanging the
symmetric key may be according to the well-known Diffie-Hellman
method. With the Diffie-Hellman method, the symmetric key is
created from messages sent during the protocol. After the
Diffie-Hellman method is used to create a shared symmetric key, the
processor and the peripheral would confirm that they have the same
symmetric key. FIGS. 4 and 5 illustrate this embodiment.
[0039] In a protocol shown in FIG. 4, at block 208 the processor
forms a commitment to the value of the short nonce, the long nonce,
and the shared symmetric key in that after the peripheral has
received the hashed value, the processor cannot change these
values, so that the processor has "committed" to these values. The
processor opens the commitment by disclosing the secret information
in the commitment to the peripheral. Because the peripheral already
had the shared symmetric key, the peripheral just needs to obtain
the value of the short nonce and the long nonce. Part of this step
is done through a secure method that cannot be observed by any
adversary. This is done at blocks 210 and 212. The long nonce is
revealed at block 220. This gives the peripheral confidence that
the processor has the same symmetric key. Conversely, the
peripheral can commit to a value before the processor has
completely opened the processor's value. This is done at blocks
214, 216, 218. The peripheral then opens this commitment, as seen
in block 226. This gives the processor confidence that the
peripheral has the same symmetric key.
[0040] One embodiment of this more general protocol is described in
FIG. 6. At block 300, the first component and second component
exchange a shared secret (e.g., a symmetric key), through a process
such as the Diffie-Hellman key exchange or using a public key
cryptographic algorithm. At block 302, the first component commits
to a first value to the second component, such as the mechanism
described in blocks 202, 206, and 208. At block 304, the components
securely exchange a shared secret, such as through the mechanism at
block 204. At block 308, the first component discloses the first
value, such as through the mechanisms in blocks 210, 212, and 220.
At block 310, the second component verifies the correctness of the
first component's commitment, such as through the mechanism in
block 222. This embodiment may also include the converse commitment
and disclose of the second component. In block 306, the second
component commits to a second value, such as through the mechanism
used in blocks 214, 216, and 218. Note, if this converse commitment
is used, it is important for the second commitment to occur before
the first component has revealed its commitment. In block 312 the
second component discloses this second value, such as through the
mechanism used in block 226. At block 314, the first component
verifies the correctness of the commitment and disclosure of the
commitment, such as through the mechanism described at block
228.
[0041] As described above, embodiments of the present invention
establish a shared encryption key between a processor and a
peripheral even in the case where there is an attacker in control
of the bus host controller. The key exchange protocol has an
advantage in that it does not require any uniqueness on the
peripheral, the user need only enter a few input choices (e.g.,
keystrokes), and if the peripheral does not receive the correct
public key of the processor, the processor will know that
outcome.
[0042] The techniques described herein are not limited to any
particular hardware or software configuration; they may find
applicability in any computing or processing environment. The
techniques may be implemented in hardware, software, or a
combination of the two. The techniques may be implemented in
programs executing on programmable machines such as mobile or
stationary computers, handheld computers, personal digital
assistants, set top boxes, cellular telephones and pagers, and
other electronic devices, that each include a processor, a storage
medium readable by the processor (including volatile and
non-volatile memory and/or storage elements), at least one input
device, and one or more output devices. Program code is applied to
the data entered using the input device to perform the functions
described and to generate output information. The output
information may be applied to one or more output devices. One of
ordinary skill in the art may appreciate that the invention can be
practiced with various computer system configurations, including
multiprocessor systems, minicomputers, mainframe computers, and the
like. The invention can also be practiced in distributed computing
environments where tasks may be performed by remote processing
devices that are linked through a communications network.
[0043] Each program may be implemented in a high level procedural
or object oriented programming language to communicate with a
processing system. However, programs may be implemented in assembly
or machine language, if desired. In any case, the language may be
compiled or interpreted.
[0044] Program instructions may be used to cause a general-purpose
or special-purpose processing system that is programmed with the
instructions to perform the operations described herein.
Alternatively, the operations may be performed by specific hardware
components that contain hardwired logic for performing the
operations, or by any combination of programmed computer components
and custom hardware components. The methods described herein may be
provided as a computer program product that may include a machine
readable medium having stored thereon instructions that may be used
to program a processing system or other electronic device to
perform the methods. The term "machine readable medium" used herein
shall include any medium that is capable of storing or encoding a
sequence of instructions for execution by the machine and that
cause the machine to perform any one of the methods described
herein. The term "machine accessible medium" shall accordingly
include, but not be limited to, solid-state memories, optical and
magnetic disks, and a carrier wave that encodes a data signal.
Furthermore, it is common in the art to speak of software, in one
form or another (e.g., program, procedure, process, application,
module, logic, and so on) as taking an action or causing a result.
Such expressions are merely a shorthand way of stating the
execution of the software by a processing system cause the
processor to perform an action of produce a result.
[0045] While this invention has been described with reference to
illustrative embodiments, this description is not intended to be
construed in a limiting sense. Various modifications of the
illustrative embodiments, as well as other embodiments of the
invention, which are apparent to persons skilled in the art to
which the invention pertains are deemed to lie within the spirit
and scope of the invention.
* * * * *