GB2544771A

GB2544771A - Blinding data to a person's identity using speech

Info

Publication number: GB2544771A
Application number: GB1520843.2A
Authority: GB
Inventors: Tomlinson Martin; Cheng Andersen; Jung Tjhai Cen; Mathews James
Original assignee: Individual
Current assignee: Individual
Priority date: 2015-11-25
Filing date: 2015-11-25
Publication date: 2017-05-31
Also published as: GB201520843D0

Abstract

Methods and systems are described for binding transmitted data to a persons identity using captured speech. The identity of a person sending original data to a recipient system is verified based on comparison of a sequence of check values derived from the original data, to a received sequence of speech portions and at least one non-speech portion of a determinate duration between two sequential speech portions, where the check values include a plurality of spoken values corresponding to said received speech portions, and at least one pause duration value between two sequential spoken values. Alternatively or additionally, the check values may include utterance durations for each spoken value.

Description

BINDING DATA TO A PERSON S IDENTITY USING SPEECH Field of the Invention [0001] This invention generally relates to electronic data communication, and more particularly to systems and methods for improved verification of parties involved.

Background of the Invention [0002] Much of current day electronic communications involves digital files. In many applications, it is necessary to bind one or more digital files to the identity of an individual who is designated as the originator, owner or administrator of said files. An example of particular importance is the binding of a public encryption key or any shared secret to an individual to prevent impersonations such as Man In The Middle (ΜΓΓΜ) attacks.

[0003] Providing proof that transmitted or stored electronic data was originated by a particular user and has not been tampered with since or substituted with a forgery is not an easy problem to solve. The applicant’s earlier patent GB2487503 and application GB1406081.8 describe techniques for binding digital data to a person's identity using biometric characteristics, such as recognition of a person’s face, voice, distinctive gestures, reading his lips, etc. from recorded image and/or audio data of the person biometrically inputting information derived from the digital data, where the information is implanted into the captured image and/or audio data.

[0004] Other known techniques involve multi-factor authentication as recommended by government regulators (for example the US Federal Financial Institutions Examination Council). The multi-factors are typically something known (a secret number or password), something owned (a device, a computer or piece of equipment) and various types of biometric information. For example, US patent 7,606,768 B2 by Graubart et al, describes a technique where the originator of a document generates a voice message which includes their ID and a secret number, a PIN. The voice message is appended to the document to form a data file. A polynomial hash of the data file is calculated and encrypted using the PIN as the basis of the encryption key. The recipient is able to authenticate the originator's ID by recognising the originator's voice in the voice message. The document is bound to the originator through the PIN encrypted hash. Provided the PIN is kept secret, a forger cannot change the document without invalidating the encrypted hash.

[0005] There is a need for further improvements to techniques for providing an irrefutable association or binding of a person's identity with transmitted data by using biometrics, for even greater security and confidence in data communication systems.

Statements of the Invention [0006] Aspects of the present invention are set out in the accompanying claims.

[0007] According to one aspect of the present invention, a verification method is provided wherein the identity of a person sending original data to a recipient system is verified based on comparison of a sequence of check values derived from the original data, to a received sequence of speech portions and at least one non-speech portion of a determinate duration between two sequential speech portions, wherein the check values include a plurality of spoken values corresponding to said received speech portions, and at least one pause duration value between two sequential spoken values.

[0008] According to another aspect of the present invention, a computer-implemented method is provided for generating data to verify the identity of a sender transmitting original data to a recipient system, comprising, at a computing system of the sender: prompting the sender to record biometric input of check values derived from the original data, the check values including a plurality of values to be spoken and at least one pause duration value between two sequential values to be spoken; capturing audio data of the biometric input of the information by the user in response to the prompting, wherein the audio data includes a sequence of speech portions corresponding to said values to be spoken, and at least one non-speech portion between two sequential speech portions having a duration corresponding to said at least one pause duration value; and transmitting the captured audio data to the recipient system for verification of the speech portions and the at least one non-speech portion duration.

[0009] Alternatively or additionally, the check values may include utterance durations for each spoken value.

[0010] In further aspects, the present invention provides a system comprising one or more processors configured to perform the above methods. In yet other aspects, there is provided a non-transitive computer-readable storage medium storing one or more computer programs arranged to carry out the above methods when executed by a programmable device.

Brief Description of the Drawings [0011] There now follows, by way of example only, a detailed description of embodiments of the present invention, with references to the figures identified below.

[0012] Figure 1 is a block diagram showing the main components of a data communication system according to an embodiment of the invention.

[0013] Figure 2 is a flow diagram illustrating the main processing steps performed by the system of Figure 1 according to an embodiment [0014] Figure 3 is a block flow diagram schematically illustrating a worked example of biometric input file generation.

[0015] Figure 4 shows an example of a user interface to prompt for capture of biometric input.

[0016] Figure 5 is a block diagram of a data communication system according to another embodiment of the invention.

[0017] Figure 6 illustrates an example of a biometric input file based on recorded audio.

[0018] Figure 7 illustrates another example of a biometric input file based on recorded video.

[0019] Figure 8 illustrates another example of a biometric input file further including a written version of the verification sequence.

[0020] Figure 9 illustrates an exemplary table of hand gestures alphabet which may be used in biometric file construction.

[0021] Figure 10 is a block diagram schematically illustrating construction of a series of biometric input files in a nested authentication arrangement.

[0022] Figure 11 is a diagram of an example of a computer system on which one or more of the functions of the embodiment may be implemented.

Detailed Description of Embodiments of the Invention [0023] A specific embodiment of the invention will now be described of a system for verifying the identity of a sender transmitting original data to a recipient system. Referring to Figure 1, a data communication system 1 according to the present exemplary embodiment comprises a first computing device 3a in communication with a second device 3b over a data network 5, via respective network interfaces 7. The first computing device 3a has an application 9a for transmitting data, such as one or more data files 11 stored in a memory 13a and/or electronic messages input by a sender, to a corresponding application 9b of the second computing device 3b connected to the network 7. The data may be communicated from the sender computing device 3a to the recipient computing device 3b via one or more intermediary servers (not illustrated).

[0024] The application 9a of the sender computing device 3a includes a biometric file generation module 15 configured to generate a biometric input file 17, such as an audio and/or video recording, based on biometric input by the sender of a verification sequence captured by a microphone 19 and/or camera 21 of the sender computing device 3 a. In this embodiment, a verification sequence generator 23 of the application 9a derives the verification sequence 25 based on some or all of the contents of the data file 11 to be transmitted to the recipient computing device 3b. The verification sequence 25 includes check values that are derived from the original data file 11. In this embodiment, the check values include a plurality of derived values to be spoken by the sender, interspersed by a plurality of derived pause duration values. Each pause duration value may be associated with a position in the verification sequence between respective sequential values to be spoken.

[0025] The sender is prompted to record biometric input of the check values via a user interface 27 of the application 9a, by recording the spoken values of the verification sequence and pausing for the determinate duration between respective identified spoken values. In this embodiment, the biometric file generation module 15 captures audio data 29 of the biometric input of the check values by the sender in response to the prompting via the user interface 27. The audio data 29 includes a sequence of speech portions corresponding to the spoken check values, interspersed by non-speech portions located between respective sequential speech portions, each non-speech portion having a duration corresponding to a respective pause duration value of the derived verification sequence. The biometric input file 17 including the captured audio data 29 is transmitted to the recipient computing device 3b for verification of the speech portions and durations of the interspersed non-speech portions.

[0026] The application 9b of the recipient computing device 3b is configured to receive the one or more data files 11 and the associated biometric input file 17 transmitted by the sender computing device 3a. The received data may be stored in a memory 13b of the recipient computing device 3b. The application 9b includes a verification module 31 configured to automatically verify the identity of the sender of the received data file 11. The verification module 31 includes a candidate sequence deriver 33 configured to derive a candidate sequence 35 from the received biometric file data 19. In this embodiment, the candidate sequence deriver 33 processes the audio data 29 in the received biometric input file 17 to identify a sequence of speech portions and interspersed non-speech portions located between respective sequential speech portions. Each identified speech portion of the candidate sequence 35 may be processed by a speech recognition module 37 to automatically identify the associated spoken utterance(s). The candidate sequence deriver 33 is also configured to determine a duration value of each non-speech portion in the candidate sequence 35.

[0027] The verification module 31 is configured to compare the candidate sequence 35 to a verification sequence 25b generated by a verification sequence generator 23 of the recipient computing device 3b based on the received data file 11, to determine that the data file 11 is received intact and was sent by the person purporting to have sent the data file 11. The verification module 31 determines whether the identified spoken utterances of the derived candidate sequence 35 match the spoken check values of the check verification sequence 25b, and the determined duration values of the identified nonspeech portions of the derived candidate sequence 35 correspond to the respective pause duration values of the check verification sequence 25b. It is appreciated that the verification sequence generators 21 of the computing devices 3 a, 3b will generate the same verification sequence 25b when the data file 11 as transmitted by the sender computing device 3 a is received intact by the recipient computing device 3b.

[0028] The verification module 31 may also be configured to process the audio data 29 of the received biometric file 17 to automatically determine if a voice print of the received audio data 29 matches a stored voice print of the identified sender, for example as provided in a previous/separate data communication session. The verification module 31 may be configured to request the sender’s voice print from a separate trusted data source. Alternatively, by replaying the audio/video recording on the application 9b, the recipient is able to identify the sender of the received data file 11, to verify that the sender is indeed the person purporting to have sent the data file 11, and also to confirm that the original data file is received rather than a fraudulent data file from an impersonator or an interceptor, i.e. a Man in the Middle. The recipient is able to verify the identity of the sender by recognising biometric characteristics of the person in the audio/video recording, for example by recognising distinct features of the sender’s face, voice, gestures, reading his lips, etc. Thus, the biometric input file 17 irrefutably binds biometric characteristics of the sender to the original data 11 that is transmitted and received.

[0029] Figure 6 schematically illustrates an example of the sender/originator of the digital file 11, or a trusted person, producing an audio recording of themselves enunciating the defined portions of the verification sequence 25d derived from original data file, and pausing between each spoken portion for the defined determinate length of time, as prompted. The recipient of the data file and the biometric input file including the audio recording, is able to identify the speaker by recognising his or her voice from the received audio recording. The recipient is also able to check and verify that the contents or features described by the speaker in the audio recording are the same as those of the associated data file as received.

[0030] Figure 7 illustrates another example of the sender/originator of the digital file 11, or a trusted person, producing a video recording showing his or her face with their lips clearly visible, and enunciates the spoken values of the verification sequence 25. In such an example, the biometric input file 17 includes a video recording of the sender enunciating the defined portions of the verification sequence 25, pausing between each spoken portion for the defined determinate length of time. On replay of the video recording, from the audio and the images, the recipient is firstly able to identify the person who is claiming to be the sender of the associated data file, and secondly able to discern the said contents or features, namely parts or features of the original data file as implanted into the biometric input file. These identified details may be corroborated with the received data file itself. It will be appreciated that the recipient system may include audio processing and speech recognition functionality to automatically process the received audio data to derive a candidate voice signature as well as the spoken values and pause durations therebetween. The recipient system may also include image processing functionality to automatically process the received video data to determine when the sender’s mouth is closed and/or the lips are not moving, and to thereby determine the portions of the video sequence that correspond to pause durations in the audio data. A further verification of the authenticity of the received biometric input file may be processed by matching pause durations determined from the video data to pause durations determined from the audio data.

[0031] Figure 8 illustrates yet another example where the biometric input file may additionally include a video recording or a photograph of the originator, or trusted third party writing down a portion of the hash value derived from the original data file, and further optionally signing his or her name. It is appreciated that other additional forms and types of biometric input file may be constructed. Some of the contents, features or derived values of the original data file may be communicated by means of gestures of the body recorded in the video recording. As an example, signing using a language utilised by hearing-impaired people may be used. Figure 9 shows an exemplary look up table for hand gestures and letters of the alphabet.

[0032] The computing devices 3 may be of a type that is known per se, such as a desktop computer, laptop computer, a tablet computer, a smartphone such as an iOSR™, BlackberryR™ or AndroidR™ based smartphone, a ‘feature’ phone, a personal digital assistant (PDA), or any processor-powered device with suitable input and display means. The data network 5 may comprise a terrestrial cellular network such as a 2G, 3G or 4G network, a private or public wireless network such as a WiFi™-based network and/or a mobile satellite network or the Internet. Typically, although not necessarily, data communication sessions between the computing devices 3 over the data network 5 are encrypted, for example using TLS or SSL protocols as are well known in the art. It is appreciated that a plurality of computing devices 3 may be operable concurrently within the system 1, as senders and/or recipients of data therebetween. Although not illustrated, the applications 9 would typically also include the complementary data processing modules to generate, send, receive and process received data as described in the present embodiment.

[0033] It is further appreciated that the recipient computing device may be a transaction server providing transaction-based services to users via respective applications 9a provided to and installed on the users’ computing devices 3a. Non-limiting examples of such a transaction-based system include cloud-based information services, internet banking, digital rights management, personal information databases, social networking, point of sale transactions, e-mail applications, secure ticketing, message services, digital broadcasting, digital communications, wireless communications, video communications, magnetic cards and general digital storage. In such a system, the transaction server may be configured with one or more applications 9b to receive and process data associated with a request transaction, and the verification sequence generator 23 may be configured to generate a hash value 43 from predefined portions of the transaction data communicated from the user device 3a to the server 3b.

[0034] The application 9a of the sender computing device 3a may also include an encryption module (not shown) for the device to encrypt data prior to transmission to the recipient computing device 3b. Similarly, the application 9b of the recipient computing device 3b may also include corresponding decryption module (not shown) to decrypt received encrypted data. A symmetric cryptographic key used by the encryption module to generate the encrypted data portion may be retained by the sender until such time that the sensitive or confidential information of the data file 11 is to be disclosed, whereby the decryption module cannot decrypt the encrypted data until the symmetric cryptographic key is received from the sender.

[0035] A brief description has been given above of the components forming part of the data communication system 1 of this embodiment. A more detailed description of the operation of these components in a corresponding embodiment will now be given with reference to the flow diagrams of Figure 2, for an example computer-implemented verification process in a data communication system 1, where the identity of the sender of a data file is verified based on comparison of a sequence of check values that are derived from the data file as received, to a received sequence of speech portions and at least one non-speech portion of a determinate duration between two sequential speech portions, wherein the check values include a plurality of spoken values corresponding to the received speech portions, and at least one pause duration value between two sequential spoken values. Reference is also made to Figure 3, schematically illustrating the data flow of a worked example according to the present embodiment.

[0036] As shown in Figure 2, the verification process begins at step S2-1 where the verification sequence generator 23 of the application 9a generates a verification sequence 25a based on the original data file 11 that is to be transmitted to the recipient computing device 3b. Referring to the example illustrated in Figure 3, the original data is processed by a cryptographic hash function 41 of the verification sequence generator 23, such as a secure hash-based algorithm (e.g. SHA-256), to compute a hash value 43 that will be unique to the original data 11. It is appreciated that a predefined portion or portions of the original data may instead be used to compute the hash value. The computed hash value 43 consists of a sequence of values, {Ho, Hi, ..., Hn}.

[0037] The output hash value 43 is processed according to a predefined algorithm 45 that splits and maps the individual values into a sequence of derived information values 47 corresponding to spoken values to be input by the sender, {Io, Ii, ..., Im), and a sequence of derived interval values 49 corresponding to pause durations values between respective derived information values 47, {Po, Pi, ..., Pm-i}- In the simplified worked example illustrated in Figure 3, the exemplary output hash value 43 is a 32 byte numerical string, starting with the decimal numbers: 82614972342233. It will be appreciated that the derived information data values may include any combination of alpha, numeric or symbolic characters. A subset of the 32 byte hash output 43, four bytes in this worked example, defines eight decimal numbers derived for the spoken values: 83614927. Another subset of the 32 byte hash output 43, a different four bytes in this worked example, defines the pause intervals in seconds between each sequential spoken value that are to be included by the sender, when prompted by the application 9a, to dictate the eight decimal numbers derived for the spoken values. In the worked example, each pair of spoken values is separated by a derived pause interval of a determinate duration, resulting in an output verification sequence 25 identifying an interleaved sequence of spoken values I and pause interval values P: Io —* Po —► Ii —1► Pi —► h ... Im-i —* Pm-i —* Im· Thus, the exemplary verification sequence 25 of the worked example is a two second gap between the spoken value ‘8’ and the spoken value ‘3’, a three second gap between the spoken value ‘3’ and the spoken value ‘6’, and so on.

[0038] At step S2-3, the application 9a outputs a prompt via the user interface 27 for the sender to record biometric input of the check values of the generated verification sequence 25a. Figure 4 is an exemplary user interface 27a prompting the sender to record the sequence of spoken values 47a, with pauses of the derived durations between each spoken value. The user interface 27a may be configured to display a count-down for each pause duration value 49a, before highlighting 48 the next value that the sender is to speak aloud. At step S2-5, the biometric file generation module 15 captures audio data 29 of the biometric input of the check values by the sender in response to the prompting via the user interface 27. As schematically illustrated in the worked example of Figure 3, the audio data 29 includes a sequence of speech portions corresponding to the spoken values, {Io, Ii, ..., Im], interspersed by non-speech portions, {Po, Pi, ..., Pm-i}, located between respective sequential speech portions, each non-speech portion having a duration corresponding to a respective pause duration value of the verification sequence 25.

[0039] At step S2-7, the biometric input file 17 including the captured audio data 29 may be stored in the memory 13a of the sender computing device 3a. At step S2-9, the data file 11 and the associated biometric input file 17 are transmitted to the recipient computing device 3b. The application 9b of the recipient computing device 3b may store the received data file 11 and associated biometric input file 17 in the memory 13b of the recipient computing device 3b at step S2-11. At step S2-13, the verification sequence generator 23 of the recipient computing device 3b generates a check verification sequence 25b based on the received data file 11 that was transmitted by the sender computing device 3b. Similar to the processing described at step S2-1 above, the check verification sequence 25b output by the verification sequence generator 23 identifies an interleaved sequence of spoken check values and pause interval values.

[0040] At step S2-15, the candidate sequence deriver 33 processes the audio data 29 in the received biometric input file 17 to derive a candidate sequence 35 identifying a sequence of speech portions and interspersed non-speech portions located between respective sequential speech portions. The candidate sequence deriver 33 is also configured to determine a respective duration value of each non-speech portion in the candidate sequence 35. The duration value is preferably rounded to the closest decimal value for efficient matching against the original derived pause interval values. It is appreciated that the signal processing to identify speech and non-speech portions in the received audio data 29 is of a type that is known per se, and need not be described further. Each identified speech portion of the candidate sequence 35 may also be processed by the speech recognition module 37 to automatically identify the associated spoken utterance(s).

[0041] At step S2-17, the verification module 31 of the application 9b may automatically verify the identity of the sender of the received data file 11 by comparing the check verification sequence 25b generated at step S2-13, to the candidate sequence 35 determined at step S2-15. The verification module 31 may determine that the data file 11 is received intact and was sent by the person purporting to have sent the data file 11 when the identified spoken utterances of the candidate sequence 35 match the spoken check values of the check verification sequence 25b, and the determined duration values of the identified non-speech portions of the candidate sequence 35 correspond to the respective pause interval values of the check verification sequence 25b. Referring back to the worked example of Figure 3, with the same data file 11 as input, the cryptographic hash function 41 of the verification sequence generator 23 will output exactly the same eight decimal digits, 83614927, and exactly the same interval values, 2, 3, 4, 2, 2, 3, 3 seconds. These may be checked against the derived candidate sequence 25 to determine if there is a close match or not.

[0042] Another embodiment of the invention will now be described with reference to Figure 5, using corresponding reference numerals to those of preceding figures where appropriate for corresponding elements, for a system and method of verifying the identity of a user associated with a computing device in communication with a transaction server providing transaction-based services. The client computing device 3a in the data communication system 51 of this embodiment is associated with a registered user of the transaction server 3b or a user wishing to register (enrol) with the transaction server 3b. The transaction server 3b may store data identifying each registered user, for example in one or more databases 13b. It is appreciated that a plurality of user computing devices 3a are operable concurrently within the system 51.

[0043] In the present embodiment, the client computing device 3 a has an application 59a for interacting with a transaction processing module 59b of the transaction server 53b and communicating transaction data, such as one or more data messages associated with a requested transaction, for handling by the transaction processing module 59b. The transaction data may include information associated with the requested transaction between the client device 45 and the server 43. The system 51 in this embodiment also includes a trusted server 53 configured with a verification sequence generator 23 to respond to requests from the client computing device 3a and the transaction server 3b for a verification sequence based on provided data. In this way, the verification sequence generator 23 need not be included in the applications 9 of the client device 3a and server 3b, thus providing enhanced security in the system 51 as the algorithm(s) used to generate the verification sequences are not exposed outside of the trusted server 53.

[0044] Consequently, verification aspects of the application 59a of the client computing device 53a in this embodiment are similar to the application 9a of the sender computing device 3a in the above embodiment, except that the application 59a includes a verification sequence requestor 55 instead of a verification sequence generator. Likewise, verification aspects of the transaction processing module 59b of the transaction server 59b in this embodiment are similar to the application 9a of the sender computing device 3 a in the above embodiment, except for the verification sequence requestor 55 in place of a verification sequence generator. The verification sequence requestor 55 is configured to generate a transaction digest 57 based on predefined portions of the transaction data 11, such as one or more of a unique identifier of the transaction generated by the application module 59a or the transaction processing module 59b, a time stamp, session ID, etc. and/or auxiliary data such as a digital signature, a current location and/or current time and/or current date and/or identity of the computing device at the time of the transaction, etc. The transaction digest 57 may be generated using a cryptographic hash function 41 of the verification sequence requestor 57 to output a corresponding hash value 43 as described above with reference to Figure 3.

[0045] The verification sequence requestor 55 is also configured to generate and transmit a request to the trusted server 55 for a verification sequence based on the generated transaction digest. The trusted server 55 may be configured to respond to a request by generating and returning a token including a verification sequence 25 for the received transaction digest 57. The trusted server 55 may maintain a database of received transaction digests 57 and associated verification sequences 25 generated by the verification sequence generator 23. Once the verification sequence 25 is received from the trusted server 55, the biometric file generation module of the client computing device 53a and the verification module 31 of the transaction server 53b in this embodiment are configured to continue processing as described in the embodiment above.

[0046] As a further alternative embodiment, the verification sequence generation and storage functionality of the trusted server 55 may instead be securely provided by the transaction server 53b, whereby the client computing device 53a requests a verification sequence from the verification sequence generator 23 of the transaction server 53b.

[0047] As yet a further modification, the captured audio data 29 may be processed by the application 59a of the client computing device 53a before the biometric input file 17 is transmitted to the transaction server 53b, to verify accuracy of the captured biometric characteristics and to ensure that the transaction processing module 59b will be able to confirm the user’s identity from the received audio data. In such a modification, the application 59a may be additionally configured to carry out an initial training process for the user, for example during an enrolment process on initial use of the application 59a. The application 59a may be configured to prompt the user to record a training video and/or audio file that will be used as a base for comparison with subsequently captured audio data. The application 59a may also be configured to obtain a training script from the trusted server 55 to be output to the user via the user interface 27. A copy of the training video and/or audio file may also be stored on the transaction server 53b for use by the verification module 31.

Computer Systems [0048] The computing entities described herein, such as the sender and recipient computing devices and the transaction server, may be implemented by computer systems such as computer system 1000 as shown in Figure 11. Embodiments of the present invention may be implemented as programmable code for execution by such computer systems 1000. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and/or computer architectures.

[0049] Computer system 1000 includes one or more processors, such as processor 1004. Processor 1004 may be any type of processor, including but not limited to a special purpose or a general-purpose digital signal processor. Processor 1004 is connected to a communication infrastructure 1006 (for example, a bus or network). Various software implementations are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and/or computer architectures.

[0050] Computer system 1000 also includes a user input interface 1003 connected to one or more input device(s) 1005 and a display interface 1007 connected to one or more display(s) 1009. Input devices 1005 may include, for example, a pointing device such as a mouse or touchpad, a keyboard, a touchscreen such as a resistive or capacitive touchscreen, etc. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and/or computer architectures, for example using mobile electronic devices with integrated input and display components.

[0051] Computer system 1000 also includes a main memory 1008, preferably random access memory (RAM), and may also include a secondary memory 610. Secondary memory 1010 may include, for example, a hard disk drive 1012 and/or a removable storage drive 1014, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. Removable storage drive 1014 reads from and/or writes to a removable storage unit 1018 in a well-known manner. Removable storage unit 1018 represents a floppy disk, magnetic tape, optical disk, etc., which is read by and written to by removable storage drive 1014. As will be appreciated, removable storage unit 1018 includes a computer usable storage medium having stored therein computer software and/or data.

[0052] In alternative implementations, secondary memory 1010 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 1000. Such means may include, for example, a removable storage unit 1022 and an interface 1020. Examples of such means may include a program cartridge and cartridge interface (such as that previously found in video game devices), a removable memory chip (such as an EPROM, or PROM, or flash memory) and associated socket, and other removable storage units 1022 and interfaces 1020 which allow software and data to be transferred from removable storage unit 1022 to computer system 1000. Alternatively, the program may be executed and/or the data accessed from the removable storage unit 1022, using the processor 1004 of the computer system 1000.

[0053] Computer system 1000 may also include a communication interface 1024 (i.e. network interface 7). Communication interface 1024 allows software and data to be transferred between computer system 1000 and external devices. Examples of communication interface 1024 may include a modem, a network interface (such as an Ethernet card), a communication port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communication interface 1024 are in the form of signals 1028, which may be electronic, electromagnetic, optical, or other signals capable of being received by communication interface 1024. These signals 1028 are provided to communication interface 1024 via a communication path 1026. Communication path 1026 carries signals 1028 and may be implemented using wire or cable, fibre optics, a phone line, a wireless link, a cellular phone link, a radio frequency link, or any other suitable communication channel. For instance, communication path 1026 may be implemented using a combination of channels.

[0054] The terms "computer program medium" and "computer usable medium" are used generally to refer to media such as removable storage drive 1014, a hard disk installed in hard disk drive 1012, and signals 1028. These computer program products are means for providing software to computer system 1000. However, these terms may also include signals (such as electrical, optical or electromagnetic signals) that embody the computer program disclosed herein.

[0055] Computer programs (also called computer control logic) are stored in main memory 1008 and/or secondary memory 1010. Computer programs may also be received via communication interface 1024. Such computer programs, when executed, enable computer system 1000 to implement embodiments of the present invention as discussed herein. Accordingly, such computer programs represent controllers of computer system 1000. Where the embodiment is implemented using software, the software may be stored in a computer program product 1030 and loaded into computer system 1000 using removable storage drive 1014, hard disk drive 1012, or communication interface 1024, to provide some examples.

[0056] Alternative embodiments may be implemented as control logic in hardware, firmware, or software or any combination thereof.

Further Embodiments, Alternatives and Modifications [0057] Further embodiments will now be described using corresponding reference numerals to those of preceding figures where appropriate for corresponding elements.

[0058] In a further embodiment, the derived interval information may instead or additionally be used to prompt the sender to record biometric input of the spoken values derived from the original data, where an utterance duration for each spoken value is defined by a respective interval duration value. For example, the predefined algorithm may be configured to derive check values including a sequence of spoken values {8, 3, 6, 1} and a sequence of utterance duration values {1, 4, 2, 2}. A sequence of interleaving pause durations may also be derived. The sender is then prompted to record biometric input of the check values via the user interface, by recording the reading aloud of each spoken value of the verification sequence for the determinate utterance duration. The duration of each utterance can be determined by the verification module at the recipient computing device or transaction server, from the received audio data, and compared against the utterance duration check values to verify the binding.

[0059] In another embodiment, additional biometric authentication information may be provided by a series of trusted third parties in a nested authentication arrangement which may be useful in cases where the originator of the document is not expected to be known to the intended recipient. As shown in Figure 10 the document file and the originator's biometric information containing the hash value_{partial}(1) are combined together and the hash of this composite file is calculated, with the result denoted as hash value(2). The truncated version of this denoted as hash value_{partial}(2) is included in one or more biometric input files produced by the trusted third party. As described above a biometric input file can consist of a video recording of the trusted third party enunciating the hash value_{partial}(2); or communicating the hash value_(partial}(2) value by bodily gestures, including hand gestures; a video recording or photograph of the trusted third party writing the hash value_{partial}(2) on a piece of paper and signing their name; or a sound recording of the trusted third party enunciating the hash value_{partial}(2) or a combination thereof. It is apparent that the nesting procedure may continue resulting in a series of trusted third parties authenticating previously authenticated composite files, producing biometric input files each conveying a hash value_{partial} authenticating the previous composite file so that at the jth step, the (j-lf trusted third party produces one or more biometric input files (j) each of which include hash value_{partial}(j). This arrangement is similar to the chain-of-trust in Public-Key Infrastructure.

[0060] In another alternative embodiment, a digital signature of the source file is additionally generated using the hash value as input to the signature. Part of the digital signature is appended to the source file and the rest of the digital signature is communicated in one or more biometric input files. This embodiment is described by way of example using the RSA digital signature standard given in the Digital Signature Standard ( FIPS PUB 186-3, Digital Signature Standard (DSS), Federal Information Processing Standards Publication). The public key which is used by the recipient to verify the digital signature consist of integers n and e. The private key used by the originator, or trusted third party consists of the integers n and d. The digital signature is a calculated integer given by σ= hash valued which is split into two parts, σι and σΓ such that sigma is equal to σι appended with σΓ. An example is sigma= 8249567123995334 with σι = 82495671239 and σΓ =95334. The integer σΓ is communicated in one or more biometric input files and σι is appended to the source file. The reason for subdividing σ into two parts is that typically σ is too large an integer to be communicated practically in a biometric input file. The integer σΓ may be communicated directly as an integer or represented as an alphanumeric string which is usually shorter. The recipient determines the integer σΓ from one or more received biometric files and constructs the integer σ using the appended source file and uses the public key to calculate rn= ae modulo n. The source file is verified by the digital signature if rn is equal to hash value calculated by hashing the received source file.

[0061] Another method of digitally signing a source file is to use the McEliece public key encryption system, as discussed in A Public-Key Cryptosystem based on Algebraic Coding Theory, R.J. McEliece DSN Progress Report 42-44, 1978, with additional features as described in the applicants’ UK patent GB2473154. This embodiment is described by way of example using a short code length of 32 bits. Practical arrangements may use codes of longer length such as 65536 bits. The public key is a reduced echelon binary generator matrix of a scrambled, permuted Goppa code, an example of length 32 bits is shown below: 10000000000000101 10101010001 1 1 1 1 01000000000010001001000100101 1 10 001000000000001 100101 1 1 1001 10000 0001000000001 1 101010000101000010 00001000000001 101 1 1 1010010001001 00000100000001000100110111111101 0000001000001 10000101 1001001 1001 00000001000011101111110001100111 000000001000000001 101001 101 1001 1 0000000001001001 1 100101 1 10010100 0000000000100001 1010101 1 1 10001 1 1 0000000000010001010101 1 1 1 10101 10 [0062] In this example the binary error correcting code has 20 parity bits and 12 information bits and can correct up to 4 errors in any of the 32 bits. The private key consists of the Goppa code used to generate this generator matrix, the scrambler and permutation matrices. Consider that the source file is appended with an integer index and hashed using a secure hash function such as SHA256 producing a hash value whose first 20 bits are: 0 100101 1 1 100101 100 1 1 [0063] The originator, or trusted third party, uses their private key, considering the 20 bit pattern as a syndrome of the error correcting Goppa code, to find the 4 bit error pattern which produces this syndrome value. This code can correct 4 bit errors so a 4 bit error pattern is determined. In general Goppa codes are represented as an (n,k,t) code and a t bit error pattern is determined. Returning to the example, it is found that errors in the 2nd, 7th, 24th and 30th bit positions produces a syndrome equal to 01001011110010110011 [0064] This may be verified by determining the parity bits from the generator matrix above for an input vector with l's in the error positions: 01000010000000000000000100000100 [0065] It is found that the 20 parity bits are: 01001011110010110011 [0066] The same as the first 20 bits of the hash value.

[0067] Having found the error pattern using the private key, the originator, or trusted third party, produces a biometric input file which contains the information of the bit error positions. For example the originator, or trusted third party could produce a video recording of themselves enunciating the numbers 2, 7, 24 and 30.

[0068] The recipient receives the source file, the index value and one or more biometric input files. From the biometric input files, the recipient determines the digital signature, which is the numbers 2, 7, 24 and 30 and checks the ID of the person doing the authentication. The recipient then uses the public key, the generator matrix to calculate the syndrome for bit errors in positions 2, 7, 24 and 30. The recipient appends the source file with the index value and uses the hash function SHA256 to determine the hash value. The recipient determines that the digital signature is valid if the first 20 bits of the hash value is equal to the calculated syndrome.

[0069] The basis of this digital signing method is that it is practically impossible to determine an error pattern from a syndrome unless it is known from the huge number of possibilities which particular Goppa code was used to construct the generator matrix. That is, it is practically impossible unless the private key is known. However given the digital signature, the error pattern, it is straightforward to calculate the syndrome.

[0070] To construct the digital signature it is necessary to have an integer index appended to the source file because not all syndrome values correspond to error patterns that the Goppa code can correct. In practice different index values are tried until a correctible syndrome is found.

[0071] A more realistic example uses a Goppa code with parameters (131072,130987,11) which can correct 5 errors. With these parameters, the syndrome is 85 bits long giving an 85 bit digital signature and on average 120 different index values need to be tried by the signer before a correctible error pattern is found.

[0072] In the embodiments described above, the spoken values of the * * * can take any known form, such as an alphanumeric passcode or a numeric passcode of varying length. In another embodiment the person providing the biometric authentication information instead of communicating directly the spoken portions of the partial hash value or partial digital signature in a video recording or sound recording, the spoken values are communicated indirectly using a codebook look up table where a prearranged phrase or word is substituted, or used in addition, for each character or symbol representing a spoken value.

[0073] One example is given in the codebook look up table below in Table 1.

Table 1. Example of part of a codebook look up table to be used in constructing and decoding the biometric input file.

[0074] Another example is given for a partial hash value represented as an alphanumeric string qn4c5te9. The codebook look up table for this example may be as in Table 2 below.

Table 2 Codebook look up table [0075] Although this results in larger biometric input files, the increased redundancy reduces the risk of error by the recipient in determining the partial hash value or partial digital signature. It also makes the task of forging a biometric input file that much harder. Using a secret look up table and communicating in the biometric input files only the corresponding phrases of the codebook table and not the characters making up the partial hash value or partial digital signature effectively means that the partial hash value or partial digital signature is encrypted before being communicated in a biometric input file. Again this makes the forging of a biometric input file more difficult. As a further obfuscation technique, randomly selected predefined words or values may be inserted into predetermined positions in the verification sequence, for the sender to include in the spoken input.

[0076] It will be understood that embodiments of the present invention are described herein by way of example only, and that various changes and modifications may be made without departing from the scope of the invention. Alternative embodiments may be envisaged, which nevertheless fall within the scope of the following claims.

Claims

1. A computer-implemented verification method wherein the identity of a person sending original data to a recipient system is verified based on comparison of a sequence of check values derived from the original data, to a received sequence of speech portions and at least one non-speech portion of a determinate duration between two sequential speech portions, wherein the check values include a plurality of spoken values corresponding to said received speech portions, and at least one pause duration value between two sequential spoken values.

2. A computer-implemented verification method wherein the identity of a person sending original data to a recipient system is verified based on comparison of a sequence of check values derived from the original data, to a received sequence of speech portions including at least one speech portion of a determinate duration, wherein the check values include a plurality of spoken values corresponding to said received speech portions, and one or more utterance duration values for respective one or more of said spoken values.

3. The method of claim 1 or 2, further comprising receiving said original data and audio data associated with the original data, and processing the received audio data to identify a sequence of speech portions and at least one non-speech portion between two sequential speech portions.

4. The method of claim 3, further comprising determining a duration value for the or each non-speech portion.

5. The method of claim 4, further comprising determining whether the determined duration values match the pause duration check values.

6. The method of claim 3, further comprising performing speech recognition to determine spoken utterances in the identified sequence of speech portions.

7. The method of claim 6, further comprising determining whether the determined spoken utterances match the spoken check values.

8. A computer-implemented method for generating data to verify the identity of a sender transmitting original data to a recipient system, comprising, at a computing system of the sender: prompting the sender to record biometric input of check values derived from the original data, the check values including a plurality of values to be spoken and at least one pause duration value between two sequential values to be spoken; capturing audio data of the biometric input of the information by the user in response to the prompting, wherein the audio data includes a sequence of speech portions corresponding to said values to be spoken, and at least one non-speech portion between two sequential speech portions having a duration corresponding to said at least one pause duration value; and transmitting the captured audio data to the recipient system for verification of the speech portions and the at least one non-speech portion duration.

9. The method of claim 8, wherein the sender is prompted to pause for the or each duration value using a timer.

10. The method of claim 8 or 9, wherein the check values further comprise one or more utterance duration values for respective one or more of said spoken values, and wherein the sender is prompted to utter the one or more spoken values for each respective utterance duration value.

11. The method of any preceding claim, further comprising deriving check values from the original data to form a verification sequence.

12. The method of any one of claims 1 to 10, further comprising obtaining a verification sequence including said check values based on the original data from a remote server.

13. The method of any preceding claim, wherein the check values are derived from a hash digest computed from at least a portion of the original data.

14. The method of claim 13, wherein a first predefined subset of the hash digest is defined as values to be spoken and a second predefined subset of the hash digest is defined as duration value between respective sequential values to be spoken.

15. The method of any preceding claim, wherein the received sequence of speech portions and at least one non-speech portion of a determinate duration between two sequential speech portions provides an irrevocable binding of the original data to at least one biometric characteristic of the sender.

16. The method of any preceding claim, wherein the original data comprises one or more data files, an encryption or decryption key, an authentication key, a password.

17. The method of any one of claims 1 to 15, wherein the original data comprises at least a portion of data associated with a transaction with the recipient system.

18. The method of claim 17, wherein the recipient device is a transaction server.

19. The method of claim 17 or 18, wherein the information associated with the transaction comprises at least a portion of a unique identifier generated for the transaction.

20. The method of any preceding claim, wherein the check values are further implanted into one or more biometric input files by writing said information, or by hand or body gestures representative of said check values.

21. The method of any preceding claim, wherein the original data comprises an encrypted data portion associated with sensitive information, and wherein the check values are derived from at least the encrypted data portion.

22. The method of claim 21, wherein a symmetric encryption key used to generate the encrypted data portion is retained by the sender until the sensitive information of the original data is to be retrieved.

23. The method of any preceding claim, wherein the additional data is associated with a current location and/or current time and/or current date and/or identity of the computing device.

24. A method according to any preceding claim, wherein the original data comprises a plurality of generated check values in a nested arrangement whereby successive trusted third parties provide authentication data which may be used to provide additional authentication.

25. A method according to any preceding claim, further comprising capturing video data of the person enunciating the spoken values, whereby said at least one pause duration value between two sequential spoken values is further verified by comparing the pause duration values derived from the audio data to corresponding pause duration values derived from image processing of the video data to determine portions where the person’s mouth is not moving.

26. A method according to any preceding claim, wherein the spoken values are alpha, numeric, and/or symbolic characters.

27. A system comprising means for performing the method of any one of claims 1 to 26.

28. A storage medium comprising machine readable instructions stored thereon for causing a computer system to perform a method in accordance with any one of claims 1 to 26.

29. A computer system substantially as hereinbefore described with reference to, or as illustrated in Figure 1 or Figure 5 of the accompanying drawings

30. A verification method substantially as hereinbefore described with reference to, or as illustrated in Figures 2 and 3 of the accompanying drawings.