Patent Application
20050289344
1. Field of the Invention
The present invention concerns security against replay attacks of messages transmitted over a network. More particularly, the present invention concerns security against replaying an intercepted message by comparing a unique message enabling code included with the message with a listing of unique message enabling codes stored in a receiving device, in order to determine whether or not to enable processing of the message.
2. Description of the Related Art
Replay attacks of messages transmitted over a network have, unfortunately, become a common occurrence. A replay attack typically consists of a hacker intercepting a message transmitted over a network and then, at some later time, re-transmitting the message to the intended device a second time (or replaying the message). As an example, a message may be transmitted over the Internet from a home or business user to a financial institution for the transfer of money from one account to another. A hacker who intercepts the message may, at some later time, send the message to the financial institution a second time, thereby resulting in a second transfer of funds. As another example, the transmission of a confidential print job over a network to a printer may be intercepted by a hacker, who then may replay (i.e., re-transmit) the print job to the printer at a later time, thereby obtaining the confidential information.
While many transmissions over the network, like the foregoing, may utilize some type of security, such as a digital signature, to verify that the message is genuine, such a signature does little to prevent a replay attack. In this regard, by intercepting the message, the hacker can obtain the necessary signature to replay the message at a later time. Since the signature was validated in the first play of the message, it is also likely to be validated in the second play (playback) of the message.
One technique (known as Kerberos) that has been proposed to address replay attacks involves adding a ticket and a time stamp to a transmitted message. When a message is received by a receiving device, the ticket and time stamp are temporarily retained in the receiving device for a specified time (e.g., 5 minutes). When additional messages are received, the ticket and time stamp of the newly-received messages are extracted to determine whether they are the same as any temporarily retained ticket and time stamp. If so, then an error message is returned. Thus, while this system provides some security against replay attacks, it does however suffer from some problems.
One problem with the foregoing system is an increase in overhead due to each receiving device having to provide sufficient storage space to store used tickets and time stamps. As more and more messages are received, a greater amount of storage space is needed to maintain the used tickets. Moreover, as the number of tickets grows larger and larger, more processing time is required to search for the used tickets, thereby degrading the performance of the system with time.
Additionally, a hacker may be able to delete a temporarily retained ticket and time stamp from the receiving device and then replay the message. Thus, although a ticket and time stamp may have been used once, since the ticket and time stamp are removed from the temporarily retained information, the replayed message will be perceived as being valid; presuming that the message is replayed within an allowable timeframe of the time stamp. As a result, the Kerberos process of temporarily retaining used tickets and time stamps, while providing some protection, still has some weakness in the prevention of replay attacks.
The present invention addresses the foregoing by storing a list of valid codes or tokens in a device that receives and processes jobs, comparing a unique message enabling code (token) included with a received message to the stored list to determine whether or not the code (token) is valid, and then deleting the received code (token) from the stored list. Thus, according to the invention, a list of unique message enabling codes is stored a receiving device. A message generated in a host device, which includes at least one of the unique message enabling codes from the generated list, is transmitted to the receiving device. The receiving device, upon receiving the message, compares the unique message enabling code included with the received message with the codes contained in the stored list to determine whether or not to reject processing of the message. If the unique message enabling code received with the message is included in the stored list, then the message is considered to be valid and the corresponding unique message enabling code is deleted from the stored list. If, however, the unique message enabling code received with the message is not included in the stored list, processing of the message is rejected.
As a result, if a hacker were to intercept the message and attempt to playback the message a second time by re-transmitting the message to the receiving device at a later time, the receiving device will reject the message since the unique enabling code is no longer contained in the stored list. Moreover, unlike the above-described Kerberos system, if a hacker were to delete the stored list of codes from the receiving device, the replayed message would be rejected since the code is not included in the list. Of course, in this case, the first play of the message would also be rejected, but the sender of the message could simply obtain a new code and transmit a new message with the new code. Additionally, a device can be built into the system to automatically obtain a new list of codes should the hacker delete the currently stored list. Thus, by providing a listing of unique message enabling codes in the receiving device that is specific to the receiving device and deleting used codes from the list, security against the playback of intercepted messages can readily be provided.
Thus, in one aspect, the invention provides security against replay of a message transmitted from a first device to a second device by comparing a unique message enabling code of a message received by the second device from the first device with a list of unique message enabling codes stored in the second device to determine whether the unique message enabling code received with the message is included in the stored list. Based on the comparison, a determination is made whether or not to reject processing of the message by the second device. In a case where it is determined that the unique message enabling code received with the message is included in the stored list, processing of the message is not rejected and the corresponding unique message enabling code is deleted from the stored list. On the other hand, in a case where it is determined that the unique message enabling code received with the message is not included in the stored list, processing of the message is rejected.
The list of unique message enabling codes is preferably generated by either a third device or the first device, with the generated list being transmitted to the second device and stored therein. Alternatively, the unique message enabling codes may be mutually generated by the second and third devices rather than transmitting the list between devices. Thus, the message can be generated in the first device such that the message includes at least one of the unique message enabling codes from the generated list. Of course, the message and the unique message enabling code can then be transmitted from the first device to the second device.
As part of generating the message, the first device may request, from the third device, a unique message enabling code to be included in the message, whereby the third device transmits the unique message enabling code to be included in the message to the first device. With this aspect, a secure server can maintain the list of valid codes for the second device and multiple first devices can request a code for the use with sending messages to the second device.
In another aspect of the invention, the second device may determine whether a predetermined number or less of the unique message enabling codes are contained in the stored list. If it is determined that the list contains the predetermined number or less of the unique message enabling codes, the second device can then obtain additional unique message enabling codes for the list. For example, the second device can notify either the first device or the second device that additional codes are needed once the list is depleted to a predetermined number or less. Thus, additional unique message enabling codes can be transmitted to the second device, whereby the second device can either start a new list in place of the currently stored list, or can simply add the additional codes to the current list to form a cumulative list. Alternatively, the second device may simply generate a new list itself, if an embodiment in which mutual generation of the codes is employed.
While the foregoing describes a case where three devices are utilized in the invention, it can readily be recognized that less or more devices could be used instead. For example, a system that utilizes only the first and second devices could be employed, where the list of codes is generated in the first device itself and list is transferred to the second device. Then, when the first device wants to send a job to the second device, it can simply obtain a code to be included with the job from its own internal list, without having to communicate with a third device to obtain the code.
This brief summary has been provided so that the nature of the invention may be understood quickly. A more complete understanding of the invention can be obtained by reference to the following detailed description of the preferred embodiments thereof in connection with the attached drawings.
The present invention is generally directed to preventing replay attacks of messages. As will be described in more detail below, the invention is implemented in a network computing environment in which various devices, such as personal computers, multi-function devices, and servers, communicate with one another over the network. The detailed description provided below, while being directed toward performing a printing operation in which a print job is transmitted from a host computer to a multi-function device and replay of the print job on the multi-function device is to be prevented, is not limited to such an embodiment. Rather, the invention can be implemented in any of various environments in which the replay of messages by unauthorized users is to be prevented. As such, the claims appended hereto are not to be limited to the printing environment, but are to be interpreted broadly as encompassing any environment in which a replay attack of an electronic communication is to be prevented.
Desktop computer 10 is preferably a personal computer, such as an IBM PC-compatible computer having a windowing environment such as Microsoft Windows 2000®, Windows ME®, etc. operating system. As is typical with personal computers, desktop computer 10 preferably has a display 11 (such as a color monitor), a keyboard 12, mouse 13 or other pointing device, and a storage medium 14, such as a floppy disk, hard disk, CD-ROM, etc.
Also shown connected to network 100 is multi-function device 30, which is capable of receiving commands and data over network 100 to be processed by the device 30. For example, device 30 may receive a print job from personal computer 10 for processing the print job to print an image. Multi-function device 30 may also be capable of receiving and transmitting facsimiles, performing photocopying operations, or scanning images. Multi-function device 30 communicates with other devices over network 100 via a network interface (not shown) so that device 30 can receive and process commands and data from other devices on the network. One feature of the present invention which involves multi-function device 30 is for device 30 to store a listing of unique message enabling codes (also referred to hereinafter as “tokens” or “TATs”) that, as will be described in more detail below, are provided to the device 30 by, for example, server 40, and are utilized to prevent the replay of messages or transmissions sent to device 30 by other devices on the network. Thus, device 30 includes the ability to communicate with, not only personal computer 10, but also server 40.
In this regard, server 40 is also connected to network 100. Server 40 preferably comprises a server-type computer having any one of various types of server operating systems, such as DOS, Microsoft Windows 2000 Server, Novell, UNIX, Linux, etc. Server 40 has a storage device 480 which is preferably a large fixed disk for storing numerous files. Server 40 can therefore be utilized by other devices on network 100 as a file server. Server 40 may also act as a gateway for other devices on network 100 to another network such as the Internet. More specific to the present invention, server 40 preferably includes a Security Application (SA) which generates unique message enabling codes, or TATs (Transaction Access Tokens), that are to be utilized in practicing the present invention. That is, the Security Application of server 40 includes the ability to generate a list of TATs that can be transmitted to other devices on the network (such as multi-function device 30) in a secure manner, which may be, for example, an SSL connection or by being encrypted. These processes will be described in more detail below with regard to the server's Security Application.
Printer 50 is also connected to network 100 and is preferably a laser or bubble-jet printer. Printer 50 includes functionality along the lines of multi-function device 30, but is directed more specifically to performing only printing operations. Thus, printer 50 operates, as it relates to the present invention, in the same manner as multi-function device 30 and therefore, the description of device 30 applies equally to printer 50.
Fixed disk 280 is an example of a computer-readable medium that stores program instruction sequences executable by central processing unit (“CPU”) 210. Some of the stored program instructions include windowing operating system 281, printer drivers 282, local peripheral device drivers 283, encryption/decryption logic 284, application programs 285, and network peripheral device drivers 286. As mentioned above, operating system 281 is preferably a windowing operating system, although other types of operating systems may be used with the present invention. Printer drivers 282 are utilized to prepare image data for printing on at least one image forming device, such as multi-function device 30 or printer 50. Local peripheral device drivers 283 are utilized to drive and control local peripheral device interface 265 for interfacing with local (i.e., devices connected locally to computer 10) peripheral devices. Encryption/decryption logic 284 provides for performing encryption of data to be transmitted by computer 10 to other devices on the network, as well as to perform decryption of encrypted data received by computer 10 from other devices on the network. Application programs 285 can include, for example, a typical word processor program for creating documents and images, such as Microsoft Word, PowerPoint, or Corel WordPerfect. Network peripheral device drivers 286 contains drivers necessary for computer 10 to communicate with network peripheral devices, such as performing remote operations on multi-function device 30 (e.g., remote scanning, copying, facsimile, etc.).
Fixed disk 480 is an example of a computer-readable medium that stores program instruction sequences executable by CPU 410. In particular, software applications such as operating system 411, network interface driver 412, Security Application 413, and Directory Service 414, may be stored on fixed disk 480. Network interface driver 412 is utilized to drive network interface 460 for interfacing server 40 to network 100. Security Application 413, which will be described in more detail below, provides various security functionality for practicing the invention. Briefly however, Security Application 413 receives commands from various devices on the network, including computer 10, multi-function device 30 and printer 50, and processes the commands accordingly. For example, Security Application 413 may receive commands from multi-function device 30 to publish device information into Directory Service 414, or to request downloading of a block of TATs. Security Application 413 may also receive commands from computer 10 to request authorization to send a job to device 30 (described in more detail below). The authorization request may include a request for any necessary security related information (also described in more detail below) for computer 10 to be able to submit a job to multi-function device 30 in a manner in which replay of the job can be prevented. Directory Service 414 is preferably an LDAP (Lightweight Directory Access Protocol) based directory service which performs various directory functions, such as storing device information of the various devices connected to the network. It should be noted that, while Directory Service 414 is shown as being within fixed disk 480, the Directory Service could be located outside of server 40 instead. For instance, the Directory Service could be implemented in another server (not shown in
A description will now be made of the software architecture utilized in practicing the invention. Briefly, the architecture includes components of a function user (referred to hereinafter as an “FU”), such as computer 10, a function provider (referred to hereinafter as an “FP”), such as multi-function device 30, a Security Application (referred to hereinafter as an “SA”), such as security application 413, and a Directory Service (referred to hereinafter as a “DS”), such as directory service 414. Each component includes various modules that provide functionality for performing a job submission process according to the invention. For example, in performing a printing operation, a function user, wanting to send a print job to multi-function device 30, transmits a job authorization request command to the Security Application. The request may be for the Security Application to provide the function user with an authorization response, which includes a TAT (Transaction Authorization Token), where the response is to be utilized for transmitting the print job to the device 30. As will be described in more detail below, the TAT included in the authorization response is utilized in preventing a replay attack of the print job. The Security Application processes the authorization request and responds to the function user with the authorization response. The function user, after receiving the authorization response, submits the print job to the device 30 together with the authorization response, where the function provider (device 30) processes the print job accordingly. As will be described in more detail below, processing of the print job by the function provider may include verifying that the TAT included in the authorization response received with the print job is valid so as to prevent a replay attack. These processes will now be described in more detail.
As seen in
Command Processing Component 121 handles incoming calls to the SA. The main functionality of the Command Processing Module is to translate the incoming commands from different sources to appropriate components in the SA. An example of a command that the Command Processing Module may recognize is a Device Publishing Command. The Device Publishing Command is for publishing device information (i.e., MIB (Management Information Base) information, etc.) of a new device into the DS 114. The Command Processing Component communicates with the Directory Component 123 and the Security Component 122 for this command.
The Security Component 122 performs various operations, including generation and delivery of security information to new devices, such as the generation and delivery of TATs to devices on the network, and applying a digital signature to a TAT to be included in an Authorization Response (described in more detail below). TATs are utilized in the present invention to prevent replay attacks by ensuring that a given transaction, whether a print job or any other type of transaction, will only be processed once. The basic application of the TAT in replay prevention is as follows.
A single TAT or a list of TATs is generated by the SA. Preferably, the TAT possesses characteristics (such as a simple random value or a random value combined with a representation of the time and date) that guarantee that it is both unique (never repeated) and that it cannot be reasonably predicted or guessed by an attacker. The TAT is delivered securely to the FP (e.g., via SSL or by being encrypted), preferably together with other TATs as part of a block of TATs, where they are stored in the FP. That is, a block of TATs are generated by the SA and pre-distributed to the FP, or at convenient intervals, such that the FP maintains a block of TATs that will be used for future operations. Thus, the SA can generate a block of TATs in advance and send them to the FP, where they will be securely stored until needed. An FU, wanting to send a job to the FP, transmits an authorization request to the SA. The SA processes the request and generates an authorization response. One of the TATs delivered with the block of TATs to the FP is included in the authorization response by the SA, whereby the response is then returned to the FU that transmitted the authorization request. The FU delivers the job, together with the authorization response which includes the TAT, to the FP. The FP confirms that the TAT included with the job is valid by matching it with the list of TATs that it received earlier from the SA. If the TAT is found to be valid (i.e., it is contained in the stored block), the FP processes the job and then deletes the TAT from the stored list such that any future jobs containing the same TAT will not be honored. This token-based authorization system ensures that each transaction will only be processed once. Thus, if a bit image of the transaction is replayed by an attacker, the FP will fail to find a matching TAT in its local store, and will reject the transaction. An added advantage of this implementation is that there is no need for the FP to store copies of used tokens for future reference. This approach prevents attacks that might be mounted by destroying tokens stored by the FP, as may occur during a power cycle to the device, and then sending a replay of the transaction to the device, where a used token would not be found. On the other hand, it might be necessary to re-distribute active TATs to the device, following a power cycle, depending of the volatility of the token store. Any such distribution can be easily managed within the bounds of the normal distribution mechanism as will be described in more detail below.
A brief description will now be provided with regard to TAT generation and distribution by the SA to the FP, as well as mutually independent generation of the TATs by the SA and the FP.
In a preferred embodiment, all tokens are generated by the SA and are either generated on an as-needed basis and transferred individually to the FP, or are generated as a block of tokens and transferred to the FP in a single operation. Regardless of whether they are generated individually or as a block, the same method can be used for token construction. In this regard, the SA may generate the TAT by simply generating a cryptographically strong random value (rv) of adequate length, or by combining the time-of-day, to the finest resolution available, and the random value. The resulting output of the generator (e.g., rv, tod in combination with rv, etc.) may be used directly as a TAT. Thus, if the TAT simply comprises a random value (rv), the SA generates a cryptographically strong random value utilizing any known generator. In the combination embodiment, each TAT could be individually generated by the SA, using the following method:
TATn=tod∥rv
where: tod is the time-of-day,
rv is a cryptographically strong random value, and
∥ represents concatenation.
For the initial token, a simple generator can be implemented as:
TAT0=tod∥rv
where: tod is the time-of-day,
rv is a cryptographically strong random value, and
∥ represents concatenation.
With a fine enough resolution in the real-time clock on the SA, uniqueness could be guaranteed.
Once the TATs are generated, they may be securely distributed by the SA to the FP, either individually on an as-needed basis, or more preferably, as a block of TATs. As mentioned above, the TATs can be distributed by the SA to the FP via an SSL connection, or the block can be digitally signed by the SA, with the block then being encrypted and transmitted by the SA to the FP.
As an alternative to the foregoing, the TATs may be mutually independently generated by the SA and the FP. That is, the SA may independently generate a block of TATs and the FP may also independently generate a corresponding block of TATs. This method eliminates the need to transmit the block of TATs over the network from the SA to the FP, thereby reducing the possibility of an attacker intercepting the block. The mutual generation may, for example, employ hashing or encryption during the generation process. Using this embodiment, the SA and the FP independently generate an identical series of TAT values, which cannot be predicted by an attacker, even if the attacker has knowledge of a series of previous values. One way to accomplish this task is to use a simple generator which uses a hash function to mix the inputs. Using this approach, the initial token in the combination embodiment can be generated by the SA as follows:
TAT0=tod ∥rv
where: tod is the time-of-day, and
rv is a cryptographically strong random value.
Subsequent, identical tokens can be generated independently by-both the SA and the FP, using:
TATn=tod ∥Hk(TATn−1∥n)
where: H is a keyed hash function, such as HMAC-SHA1,
tod is the time-of-day provided by the SA in the initial token,
k is the random key generated by the SA, during initialization of the current block, and
n is the value of a counter, where n>0.
With this embodiment, since all the variables on the right side of the equation may be known to an attacker, the presence of the hash key is required. Without knowledge of k, an attacker is unable to generate TATn, despite possession of tod, TATn−1, and n.
Thus, as can be seen from the foregoing, the TATs may be generated and distributed between the SA and FP in any of various implementations. Preferably, however, the TATs are generated by the SA as a block, with the block of TATs being distributed to the FP where they are stored for future use. Of course, the block of TATs are also maintained by the SA so that when an FU requests to perform an operation on the FP, the SA can determine which TATs correspond to the FP that the FU wants to use and can provide an appropriate TAT to the FU for the FU to include in a job sent to the FP.
Returning to
As seen in
In the present invention, when the print driver is activated, job data is generated by the print driver for the print job. For instance, the print driver may generate job data that includes the type of operation to be performed (i.e., printing), the number of pages of the job, as well as various printing options (color printing, duplex printing, etc.). In addition, information of the FU (computer 10) and the FP (multi-function device 30) may be included in the job data. For instance, identification information such as MAC addresses or IP addresses of the FU and FP may be obtained and included in the job data. Once the job data has been obtained, it is packaged for transmission to the SA, preferably in the form of an authorization request message.
The FU then establishes a connection with the SA to transmit the authorization request to the SA (step S902). The connection is preferably a secure connection, such as SSL. This can be seen to correspond to arrows 1 and 2 of
After the FU receives the authorization response from the SA, the FU builds an FP command package in the form of a job request, which includes job data and the authorization response. That is, the authorization response received by the FU from the SA is merely inserted into the job request in the same form that it is received. The job request (which includes the job data and the authorization response) is preferably encrypted utilizing a session key, with the encrypted job then being sent by the FU to the FP (step S906). Upon receiving the encrypted job request, the FP decrypts the received data utilizing the session key and extracts the TAT from the authorization response. The FP determines whether the extracted TAT is valid (step S907), and if so, processes the job data accordingly (step S908) (i.e., the job is printed out if it is a print job). If the TAT is determined to be invalid, the job is rejected (step S909). The TAT validation process of step S907 is described in more detail below with regard to
Thus, as can be seen from the foregoing description of FIGS. 9 to 12, an FU sends an authorization request to an SA. The SA processes the request and generates an authorization response, which includes a TAT, and transmits the authorization response to the FU. The FU, upon receiving the authorization response, sends a job to the FP, where the job includes the authorization response. The FP, upon receiving the job and authorization response, extracts the TAT and compares the received TAT with a stored listing of TATs to determine whether or not the TAT is valid. If the received TAT is not included in the stored list, then the job is rejected. That is, the FP determines that the present job request is a replay of a previously submitted job due to the inclusion of a TAT that has already been received and deleted from the list. If, however, the received TAT is found to be included in the stored list, then the TAT is considered to be valid and the job is processed accordingly. The TAT is then deleted from the stored list so that any attempt to replay the job request using the same TAT will be rejected. As can readily be seen, the foregoing process provides a relatively automated way for preventing replay attacks of messages.
The foregoing process steps may be implemented as computer-executable process steps that are executed by one or more computer devices. The computer-executable process steps may be stored on a computer-readable medium, such as a floppy disk, magnetic disk, CD-ROM, hard disk, etc. Thus, the invention may be implemented as the computer-executable process steps themselves, or the computer-readable storage medium that stores the computer-executable process steps. Moreover, an apparatus, such as a computer, which has the computer-executable process steps stored therein may comprise the invention.
The invention has been described with particular illustrative embodiments. It is to be understood that the invention is not limited to the above-described embodiments and that various changes and modifications may be made by those of ordinary skill in the art without departing from the spirit and scope of the invention.
