Improvements In and Relating to Document Verification
Field of the Invention
The present invention relates to data security methods and to digital computers comprising means for such methods.
Background to the Invention
It is known for digital documents or other message data to be digitally signed. The process of digitally signing a document involves creating a hash of the original file and encrypting the hash using a private key of a public key infrastructure encryption system. The digital signature is sent with the original document, itself usually encrypted. The encryption permits the recipient (with access to the relevant public key) to know that the file was encrypted by a person with access to the corresponding private key. The hash is a one way digest function producing a substantially unique result. The hash enables the recipient to confirm that the document accompanying the digital' signature is the same as that signed because only the original document will generate that hash, and the recipient can repeat the hashing process.
The present inventor has noted, however, that there is a flaw in the process described above. The flaw is that the document signed may not correspond to the document intended to be signed. For instance, if a virus has been placed on the computer of a user signing a document, the virus may be configured to modify the document in memory before digital signing takes place, even between the instruction to sign and the signing itself. Thus, a user
may digitally sign a document that differs materially from that they believe they are signing.
Preferred embodiments of the present invention aim to address the problem referred to above.
Summary of the Invention
According to the present invention in a first aspect, there is provided a data security method for a digital computer comprising a peripheral input device, the method comprising the steps of : in a secure processor environment generating an order specific version of inputs from the peripheral input device and storing the order specific version in a memory.
Suitably, the peripheral input device comprises any of a mouse, a keyboard, a voice input unit, camera, graphic tablet, microphone or digital pen.
Suitably, the secure environment comprises a secure processor. Suitably, the secure processor is separate from a central processing unit (CPU) of the digital computer. Alternatively, the secure processor comprises a secure part of the digital computer CPU. Suitably, the secure environment is external of the operating system of the digital computer.
Suitably, in an application involving a cursor, the cursor is driven to a predetermined location prior to commencement of the inputs storage .
Suitably, the digital computer comprises a CPU for receiving input signals and the secure processor is between the peripheral input device and the CPU, in which input signals from the peripheral input device are stored by the processor independent of the input signals reaching CPU. Suitably, the CPU is associated with an operating system and input signals from the peripheral input device are stored by the processor independent of the input signal reaching the operating system.
Suitably, modified versions of the inputs are stored. Suitably, each input is modified in turn. Alternatively groups of inputs can be modified.
Suitably, the modified version of the inputs comprise a digest function of the inputs.
Suitably, the result of the digest function generation is encrypted, preferably using a public key encryption.
Suitably, a final hash of the completed input differs from the previous hash(es) . Suitably, the final hash is encrypted using a different encryption key than the encryption of the previous hash(es) . Alternatively, an alternative hash can be used. Suitably, a transmitted log of inputs comprises a final hash indicator.
Suitably, the modified version of the inputs comprises a concatenated hash of the inputs . Suitably, an input is modified by concatenation with prior inputs. Suitably, each input is concatenated with prior inputs .
Suitably, the modified version is an encryption of concatenated groups of inputs .
Suitably, the inputs from the peripheral device are stored in a memory in sequence separate from the modified inputs.
Suitably, the inputs modified are those which affect the appearance of a document. This effect may be direct, eg an input that causes an image to appear on a screen, or indirect, eg moving the cursor or pressing a CAPS LOCK key.
Alternatively, the method includes the step of transmitting to another party the modified version of the inputs and an unmodified version of the inputs. Suitably, the another party carries out a verification step by generating a corresponding modified version of the unmodified version of the inputs and comparing this with the received modified version. Suitably, the another party generates a message from the unmodified version of the inputs and compares the generated message with a received message.
According to the present invention in a second aspect, there is provided an executable computer program for operating a method according to the first aspect of the present invention.
According to the present invention in a third aspect, there is provided a digital computer comprising a secure processor environment in communication with a peripheral input device, the secure processor environment processor comprising means for generating an order specific version
of inputs from the peripheral input device and storing the order specific version in a memory.
The processor may be configured to operate according to the method of the first aspect of the present invention.
The present invention also provides a data security method for a digital computer comprising a peripheral input device, the method comprising the steps of in a secure processor generating a hash log of inputs from the peripheral input device and generating a log of inputs from the peripheral input device.
Thus, using embodiments of the present invention, a user can transmit a message to a recipient confident that the user can verify that what was sent was what was intended to be sent. A user can also self-verify.
Brief Description of the Figures
The present invention will now be described, by way of example only, with reference to the Figures that follow,- in which:
Figure 1 is a schematic illustration of a system according to the present invention.
Figure 2 is a schematic illustration of the secure processor of Figure 1.
Figure 3 is a flow diagram illustrating a method according to the present invention.
Figure 4 is a schematic functional diagram corresponding to Figure 3.
Description of the Preferred Embodiments
Referring to Figure 1 of the Figures that follow there is shown, schematically, a digital computer 2, typically a personal computer, comprising a keyboard 4 (a peripheral input device), a visual display unit 6, a central processing unit (CPU) 8 and a Random Access Memory (RAM) 10. The keyboard 4 incorporates a keyboard controller 12 and a secure environment processor 14 (a secure environment) . The secure processor 14 is located between the peripheral input device keyboard controller 12 and the CPU 8 in the sense that signals pass through the secure processor 14 before reaching the CPU 8.
As shown in Figure 2 , the secure processor 14 comprises an on-board processing capability in secure processor CPU 16 and memory in the form of secure processor RAM 18 and instructions in secure processor ROM 20. One such secure processor is the IBM Crypto Device 4758. The processor 14 is configured to receive input signals from the keyboard 4
(via the keyboard controller 12) . The processor 14 is configured to catenate the received input signal with previously encrypted input signals, to encrypt the combination and to store the encrypted result for catenation with subsequent input signals as explained in more detail below.
Thus an order specific version of inputs from the peripheral input device 4 is generated by secure processor 14 and stored in memory 10.
Referring to Figure 3 of the drawings that follow, a method according to a preferred embodiment of the present invention is described by way of a functional flow diagram. Figure 4 is a functional schematic diagram to assist in explaining this embodiment of the present invention further.
Upon activation of the application, the cursor is driven to a predetermined location (step 100) . Typically this is the "HOME" location of the document . This ensures that if an existing document is edited, the cursor location can always be determined. Generally, all inputs begin from a predetermined start point .
In step 102 a keystroke (200 in Figure 4) is entered on keyboard 4 causing (step 104) a signal to be sent to keyboard controller 12 which in turn generates a keyboard controller output signal that is sent (step 106) to secure processor 14 and (step 108) to CPU 8 of the computer 2. The signal to the CPU 8 may be via secure processor 14, but need not be .
The signal received by CPU 8 is acted upon, according to the relevant application in focus (step 110) . For instance, if a word processing application (such as Microsoft Word (trade marks) is in focus, typically a keystroke will generate an alphanumeric character to be displayed (202 in Figure 4) . Further the signal is stored in RAM 10 (step 112) which forms a keystroke log (204 in Figure 4) . Keystroke log 204 is a sequential record of all keystrokes.
The secure processor 14 creates a hash (a one-way function) of the input keystroke (step 114) . The hash is encrypted by the secure processor 14 (step 116) and stored (step 118) (together 206 in Figure 4) this in a hash log 208 in Figure 4.
The hash is created as a concatenation of the current keystroke with a hash of previous keystrokes. Thus if the first few keystrokes are:
H E L O
the secure processor 14 will create a hash of "H" ie Hash (H) , and upon receipt of the signal corresponding to keystroke UE" will create a hash of λΕ" together with the previous hash ie Hash(E+Hash(H) ) and so on to produce a concatenated result in which the resultant hash is determined both by the inputs and their sequence.
The secure processor 14 has a unique public/private key pair for encryption using public key infrastructure and a unique symmetric encryption key (eg DES) . The private key is used to encrypt the hash of the keystrokes.
The hash log 206 can be stored in RAM 10 of computer 2 or in secure processor RAM 18 or both. For convenience the hash log 206 is stored at least in the secure processor RAM 18 for access for the next hash in the concatenated sequence.
Each subsequent input causes the creation of a hash from the previous hash.
It is noted that it is not only alphanumeric inputs that are stored in keystroke log 204 and hash log 206. Other inputs such as cursor movement (eg cursor arrows, home, end, page up, page down) , edit instructions (eg delete, insert, cut, paste, copy etc) . That is the keystroke log, if followed, will recreate the file being created.
For instance, the input described above that appears on the screen as "HOP" may in fact have been input as the follow sequence of keystrokes:
GO<CURSORBACKxBACKSPACE>H<CURSOR FORWARD>P .
The appearance of this sequence in an application is illustrated in tabular form below. In the second column, the cursor location is indicated by a " | " , a hash function is represented by a w#" for ease of reference, a cursor back keystroke is indicated by <CB>, a cursor forward by <CF> and a back space by <BS>.
It must also be specified when a final hash is made. This is because for a document recipient to verify a received
document, the recipient must be able to recreate the hash log from the keystroke log, and therefore must have available the encryption key used by secure processor 14. The same encryption key cannot be used to digitally sign the entire hash because there would be no security in relation to the key and therefore no verification of source .
One way to do this is for the secure processor 14 to use two key pairs for signing: one for signing the keystrokes, and one for signing the final hash - in this case the publication key pair. The final hash (FH) must therefore contain a flag to identify it as the FH in order for secure processor 14 to identify that the publication public key needs to be used to verify the FH.
Alternatively, use of an additional hash to hash the FH of the document (e.g. #7) can be used. The FH will also be hashed with a specific value (e.g. the word "PUBLISHED", etc) . When verifying a document secure processor 14 will identify the FH from its "final hash flag" and then has the FH with the PUBLISHED value. This must ensure that the purpose of each hash within the document (whether used to hash a keystroke, the end of a document session, or the FH) is apparent to secure processor 14. Again, this is achieved through the use of flags to identify the specific purpose of a hash.
When a file (usually a document) is transmitted as a digital file, it is accompanied by the hash log 206 and the keystroke log 204. Both are digitally signed by the sender. To verify the file a recipient uses the sender's final hash public key to decrypt the hash log 206 and the
keystroke log 204. The keystroke log 204 is hashed by the recipient in a concatenated sequence, keystroke by keystroke, as described above and this hash result compared with hash log 204. If the two match, the first stage of verification is accomplished. The second stage of verification executes (or mimics the execution) of the keystroke log in the application and compares the end result with the transmitted file. If the two match, the second stage of verification is accomplished and the document as a whole is verified. That is, it is verified that the document sent matches the keystroke log, and the keystroke log is verified as corresponding to the sender's intended document .
As an alternative using less bandwidth, the file
(document) need not be transmitted at all. It can be recreated from keystroke log 204 once that has been verified by a comparison with hash log 206 as described above. The advantage of transmitting the file is that it leaves it open to the recipient whether they will check the verification.
By hashing and encryption each keystroke in a concatenated function, in effect both the keystrokes and their sequence of input are digitally signed.
In an alternative version of the present invention, keystrokes can be hashed prior to being concatenated. This may be easier in some embodiments.
In an alternative embodiment groups of keystrokes can be hashed. That is several keystrokes can be stored in secure processor 14 and hashed and signed in a group of eg
5 keystrokes. So long as the pattern of keystroke signing is known to the recipient (and it can be sent to them with the file document) a variety of keystroke signing patterns may be used. The grouping of keystrokes in secure processor 14 need not slow their passage to CPU 8. So long as the keystroke group is signed before it is available to another application outside secure processor 14 there is no risk of an attack succeeding. This is order specific in the sense of groups of inputs from the peripheral input device.
Although a preferred embodiment of the present invention has been described in relation to a keyboard, it can be implemented using other peripheral input devices such as a mouse, a voice input etc. Embodiments of the present invention may receive input signals from more than one input device eg a keyboard and a mouse .
In a simplified embodiment of the present invention the public key encryption need not be used. That is the hash log is a concatenated hash of the keystrokes and is not separately encrypted. In this case the hash function is regarded as encrypting the keystrokes.
The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.
All of the features disclosed in this specification (including any accompanying claims, abstract and
drawings) , and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.
Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) , may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.
The invention is not restricted to the details of the foregoing embodiment (s) . The invention extend to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings) , or to any novel one, or any novel combination, of the steps of any method or process so disclosed.