1. Field of the Invention
The present invention relates generally to network-based computer security and, more specifically, to methods and systems for authenticating a device and a user for computer network security.
2. Description of the Related Art
Device identification through device keys, i.e., though a collection of hardware and system configuration attributes, has proven to be invaluable in recent years to such technologies as security and digital rights management. In security, authentication of a person can be restricted to a limited number of previously authorized devices that are recognized by their device keys. In digital rights management, use of copyrighted or otherwise proprietary subject matter can be similarly restricted to a limited number of previously authorized devices that are recognized by their device keys.
Device keys can also include information provided by the user to identify and authenticate the user. At the center of user identification is the age-old trade-off between security and the convenience of the user. As an example, it may be helpful to consider some of the most popular passwords users use to protect their information and identity. In October 2012, CBS news reported some of the most commonly used passwords, which included “password”, “123456”, and “12345678”. Other popular passwords in 2012 were “abc123”, “qwerty”, “11111”, “trustnol”, and “letmein”. Other than being easy to guess, what these popular passwords have in common is that they are easy to remember and therefore convenient for the user. In addition, since these passwords are known to be popular, they are highly insecure.
More secure authentication requires significantly more effort from the user. For example, creation of personal certificates for public-key infrastructure (PKI) authentication requires several steps, interacting with a certificate authority, and manual importation of the personal certificate into e-mail readers and other software applications. The current state of certificate creation and use is far more complicated than most casual users of computing devices can manage. And yet authentication of even casual uses of devices is increasingly important as people increasingly conduct financial transactions and access copyrighted media using computing devices.
What is needed is a way to identify and authenticate both a device and a user of the device with increased security without also increasing the inconvenience of the user.
In accordance with the present invention, a dynamic device key that identifies and authenticates a device and its user includes data representing captured sound of the user speaking a disposable pass phrase. The convenient and secure authentication of voice recognition is combined with convenient and secure device authentication by including biometric voice-recognition of the user in the dynamic device key.
During registration, the user speaks all elements of a collection from which disposable pass phrases can be composed, e.g., a collection of one or more of words, letters, and numbers. Audio signals representing the user speaking each element of the collection is captured at registration of the user and are used as references for subsequent authentication. Additional audio signals representing background noise recorded during the user speaking each element may also be captured as a reference for subsequent authentication.
During authentication, a dynamic device key challenge specifies a number of device attributes, including interactive attributes to be provided by the device's user. At least one of the interactive attributes is a disposable pass phrase consisting of one or more elements selected in a randomized manner from the collection of pass phrase elements. The responsive dynamic device key includes data representing an audio signal captured through a microphone of the user speaking the disposable pass phrase obscured with a nonce provide in the challenge.
The result is very rigorous device and user authentication.
Other systems, methods, features and advantages of the invention will be or will become apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the invention, and be protected by the accompanying claims. Component parts shown in the drawings are not necessarily to scale, and may be exaggerated to better illustrate the important features of the invention. In the drawings, like reference numerals may designate like parts throughout the different views, wherein:
In accordance with the present invention, a device authentication server 108 (
Device authentication system 100 includes device 102, a server 106, and device authentication server 108 that are connected to one another through a wide area computer network 104, which is the Internet in this illustrative embodiment. Device 102 can be any of a number of types of networked computing devices, including smart phones, tablets, netbook computers, laptop computers, and desktop computers. Server 106 is a server that provides services to remotely located devices such as device 102 but that is configured to require authentication of device 102 prior to providing those services. Device authentication server 108 is a server that authenticates devices, sometimes on behalf of other computers such as server 106.
Device attributes are described briefly to facilitate understanding and appreciation of the present invention. Known device record 500 (
In this illustrative embodiment, device attributes are categorized according to physical, environment, and interactive dimensions. Those dimensions are described in co-pending U.S. Patent Application 61/694,612 for “Adaptive Device Identification” filed on Aug. 29, 2012 and that description is incorporated herein by reference.
Device attributes of the interactive dimension are provided by the user and therefore identify and authenticate the user of device 102 rather than device 102 itself. In this illustrative embodiment, at least one of the interactive attributes is captured sound of the user speaking pass phrase elements that collectively form a disposable pass phrase.
In the disposable pass phrase, the pass phrase itself does not provide an authentication factor. Instead, the user's voice provides a biometric factor of authentication. The disposable pass phrase, by being different for each act of authentication, avoids repeated use of the same voice sounds for authentication across multiple authentication events. As a result, surreptitious capture and re-use of the user's recorded voice to spoof authentication is particularly difficult. For example, if the pass phrase challenge asks the user to say “bravo charlie delta” and another with malicious intent intercepts the recorded sound, such recorded sound cannot be used to spoof authentication if the subsequent challenge is different, e.g., “x-ray echo golf”.
For subsequent authentication of the user, registration in the manner illustrated in transaction flow diagrams 200 (
The sound samples retrieved may also include background noise that is characteristic of the particular audio capturing and transmission system, and may include ambient noise in the user's environment. In this sense, the background noise may be a physical or an environmental device attribute, or a combination of both. In one implementation, as an enhanced security measure, ambient or artificial background noise may be intentionally introduced during registration when recording the pass phrases.
Transaction flow diagram 200 (
In step 202, device 102 sends a request for registration to device authentication server 108. The request can be in the form of a URL specified by the user of device 102 using a web browser 1220 (
In step 204 (
The request sent to device 102 includes content that causes web browser 1220 (
The content that causes web browser 1220 (
In this illustrative embodiment, web browser plug-in 1222 (
In step 208 (
In step 210, device authentication logic 1120 (
In step 212 (
In one embodiment, device 102 and the user thereof are considered a single entity to be identified and authenticated. In this embodiment, the device attributes gathered in step 206, received in step 208, and stored in step 210 include interactive device attributes that identify device 102 and its user. In an alternative embodiment, interactive attributes of a given user are registered separately as shown in transaction flow diagram 300 (
Steps 302, 304, 306, 308, 310, and 312 are analogous to steps 202 (
In this illustrative embodiment, the interactive attributes include captured sounds, including the background noise, of the user speaking each of a number of pass phrase elements. This retrieval is illustrated in logic flow diagram 306A (
Loop step 802 and next step 808 define a loop in which DDK generator 1240 (
The complete set of pass phrase elements to be processed according to the loop of steps 802-808 is predetermined and included in the device attribute request of step 204 (
During each iteration of the loop of steps 802-808 (
In a more elaborate embodiment that exploits the background noise phenomenon, steps 804 are repeated multiple times for each pass phrase element to provide a more reliable sampling size from which to identify one or more characteristics of background noise that reliably recur with each recording—for example, signals at one or more frequencies that have magnitudes elevated above the noise floor that consistently appear throughout recordings of different pass phrases.
Processing transfers from next step 808 to loop step 802 in which DDK generator 1240 processes the next pass phrase element of the complete set according to steps 804-806. When DDK generator 1240 has processed all pass phrase elements of the complete set according to the loop of steps 802-808, processing by DDK generator 1240 transfers to step 810.
In step 810, DDK generator 1240 stores the captured pass phrase elements in the prepared attribute data to send in step 208 (
Known device record 500 (
Value 514A includes a number of elements 602A, each of which corresponds to a respective element that can be used to produce a disposable pass phrase that the user can be challenged to speak. ID 604A identifies the given element. For example, if elements 602A are all words to be spoken by the user, ID 604A can be a textual representation of a given word. Spoken element 606A is data representing the user's voice speaking the given element. Spoken elements 606A of elements 602A serve as references for voice comparison in identifying and authenticating the user.
Device attribute 504 (
Dimension 508 specifies the dimension of the subject attribute. In this illustrative embodiment, there are three (3) dimensions of device attributes: physical, environmental, and interactive.
Behavior 510 specifies the behavior of the subject device attribute, particularly the manner in which the subject device attribute changes over time. In this illustrative embodiment, there are six (6) types of behavior 510: constant, intermittent, variable, variable-progressive, variable-regressive, and variable-requisite. These six types of behavior are described in the “Adaptive Device Authentication” application previously cited.
Identification class 512 specifies a degree to which the subject device attribute identifies a device. In this illustrative embodiment, there are four (4) identification classes: unique, device-common, platform-common, and common. These four (4) identification classes are described in the “Adaptive Device Authentication” application.
Extraction logic 516 specifies the manner in which the subject device attribute is extracted by device 102. Examples of extraction logic 516 are described in “Adaptive Device Authentication”.
Comparison logic 518 specifies the manner in which the subject device attribute is compared to a corresponding device attribute to determine whether device attributes match one another. Examples of comparison logic 518 are described in “Adaptive Device Authentication”.
Alert logic 520 can specify alerts of device matches or mismatches or other events. Examples of alert logic 520 are described in “Adaptive Device Authentication”.
Adjustment logic 522 specifies the manner in which the subject device attribute is to be adjusted after authentication. Examples of adjustment logic 522 are described in “Adaptive Device Authentication”.
Device attribute 504 is shown to include the elements previously described for ease of description and illustration. However, it should be appreciated that a device attribute 504 for a given device can include only identifier 506 and value 514, while a separate device attribute specification can include dimension 508, behavior 510, identification class 512, extraction logic 516, comparison logic 518, alert logic 520, and adjustment logic 522. In addition, all or part of extraction logic 516, comparison logic 518, alert logic 520, and adjustment logic 522 can be common to attributes of a given dimension, behavior type, or identification class and can therefore be defined for the given dimension, behavior type, or identification class. For example, all interactive device attributes that are text to be entered by the user can share the same extraction logic 516 and comparison logic 518, only differing in the text prompt to be displayed to the user and the format of an acceptable answer (e.g., date, numerical, textual).
In addition, it should be appreciated that interactive attributes identify a user of device 102 and not device 102 itself. For simplicity and clarity of explanation, known device record 500 includes both interactive and non-interactive attributes, representing a one-to-one relationship between a user and a device. In some embodiments, interactive attributes can be stored in a known user record and one or more known device records can be associated with the known user record in known device data 1130.
Transaction flow diagram 400 (
In step 402, device 102 sends a request for a log-in web page to server 106 by which the user can authenticate herself. The request can be in the form of a URL specified by the user of device 102 using web browser 1220 (
In step 404 (
In step 406, web browser 1220 (
In step 408 (
In step 412 (
In response to the request, device authentication server 108 generates and cryptographically signs a session key. Session keys and their generation are known and are not described herein. In addition, device authentication server 108 creates a device key challenge and encrypts the device key challenge using a public key of device 102 and PKI. In step 416, device authentication server 108 sends the signed session key and the encrypted device key challenge to server 106.
In step 418, server 106 sends a “device authenticating” page to device 102 along with the device key challenge. The “device authenticating” page includes content that provides a message to the user of device 102 that authentication of device 102 is underway.
The device key challenge causes web browser 1220 (
The device key challenge specifies the manner in which DDK 1242 is to be generated from the attributes of device 102, including interactive attributes, represented in device attributes 504 (
In particular, the device key challenge specifies items of information to be collected from hardware and system configuration attributes of device 102 and the manner in which those items of information are to be combined to form DDK 1242. The generation of a dynamic device key from a device key challenge is described in U.S. Patent Application Publication US 2011/0009092 and in the “Adaptive Device Authentication” application previously cited. Those descriptions are incorporated herein by reference.
In this embodiment, the challenge specifies one or more interactive attributes, requiring attribute data to be provided by the user. At least one of the interactive attributes challenges the user to speak a disposable pass phrase. The disposable pass phrase is a series of elements randomly or pseudo-randomly selected from the elements represented in value 514A (
To provide greater security, DDK 1242 includes data representing the user's captured voice obfuscated using a nonce included in the challenge. While use of the disposable pass phrase precludes capture of any single voice response by the user to be used in subsequent authentication, use of the nonce thwarts collection of voice responses over time to recreate enough of value 514A (
Once DDK 1242 (
In step 422 (
In step 426, device authentication logic 1120 of device authentication server 108 decrypts and authenticates the received DDK. Step 426 is shown in greater detail as logic flow diagram 426 (
In step 702, device authentication logic 1120 identifies device 102. In this illustrative embodiment, the received DDK includes a device identifier corresponding to device identifier 402 (
In test step 704 (
In step 706, device authentication logic 1120 authenticates the received DDK using the known device record 400 (
In test step 708 (
If the received DDK does not authenticate device 102, processing transfers to step 716 and authentication fails or, alternatively, to step 414 (
In step 710, device authentication logic 1120 authenticates the portion of the received DDK generated from interactive attributes using the known device record 500 (
In test step 712 (
In step 714, device authentication logic 1120 applies adjustment logic to the attributes used to generate the received DDK. In particular, device authentication logic 1120 applies adjustment logic 422 (
After step 714 (
In step 716, device authentication logic 1120 determines that device 102 or the user thereof are not authentic, i.e., that authentication according to logic flow diagram 426 fails.
In step 718, device authentication logic 1120 logs the failed authentication and, in step 720, applies alert logic 420 (
In step 428 (
In step 430, server 106 determines whether to continue to interact with device 102 and in what manner according to the device authentication results received in step 428.
As described above, matches for each attribute are determined according to comparison logic 518 (
Loop step 902 and next step 908 define a loop in which device authentication logic 1120 processes each element of the spoken disposable pass phrase according to steps 904-906. During each iteration of the loop of steps 902-908, the particular disposable pass phrase element processed by device authentication logic 1120 is sometimes referred to as “the subject element.”
In step 904, device authentication logic 1120 compares the captured sound of the user speaking the subject element to the corresponding spoken element 606A. The corresponding spoken element 606A (
In step 906, device authentication logic 1120 accumulates the results of the comparison of step 904. In this illustrative embodiment, comparison by device authentication logic 1120 in step 904 produces a correlation score in the range of 0.0 to 1.0, in which 1.0 represents a perfect match. In one embodiment, device authentication logic 1120 calculates a mean match score for all comparisons in step 904. In an alternative embodiment, device authentication logic 1120 multiplies a running cumulative comparison by the correlation score determined in step 904. In this alternative embodiment, the cumulative comparison is initialized to 1.0. If the first performance of step 904 produces a correlation score of 0.8, multiplying the cumulative comparison (1.0) by 0.8 produces a new cumulative comparison of 0.8. If the second performance of step 904 also produces a correlation score of 0.8, multiplying the cumulative comparison (0.8) by 0.8 produces a new cumulative comparison of 0.64. The correlation score may also be affected, or adjusted, based on a comparison of known background noise characteristics to background noise captured during the user speaking the subject element to the corresponding spoken element 606A.
Processing by device authentication logic 1120 transfers through next step 908 to loop step 902 in which the next element of the disposable pass phrase is processed according to the loop of steps 902-908. When all elements of the disposable pass phrases have been processed, processing transfers to step 910.
In step 910, device authentication logic 1120 multiplies the cumulative match score by the cumulative comparison. In the alternative embodiment in which the cumulative comparison is the product of all correlation scores, the cumulative comparison can be raised to the power of—n, where n is the number of elements of the disposable pass phrase. Such makes the cumulative comparison independent of the length of the disposable pass phrase.
In an alternative embodiment, device authentication logic 1120 forms a reference audio signal by concatenating spoken elements 606A (
After comparison logic 518 for all attributes of the received DDK have been processed, device authentication logic 1120 compares the cumulative match score to a predetermined threshold. If the cumulative match is at least the predetermined threshold, device authentication logic 1120 determines that device 102 is authentic. Conversely, if the cumulative match score is below the predetermined threshold, device authentication logic 1120 determines that device 102 is not authentic.
Server computer 106 is shown in greater detail in
CPU 1202 and memory 1204 are connected to one another through a conventional interconnect 1206, which is a bus in this illustrative embodiment and which connects CPU 1202 and memory 1204 to network access circuitry 1212. Network access circuitry 1212 sends and receives data through computer networks such as wide area network 104 (
A number of components of server 106 are stored in memory 1204. In particular, web server logic 1220 and web application logic 1222, including authentication logic 1224, are all or part of one or more computer processes executing within CPU 1202 from memory 1204 in this illustrative embodiment but can also be implemented using digital logic circuitry.
Web server logic 1220 is a conventional web server. Web application logic 1222 is content that defines one or more pages of a web site and is served by web server logic 1220 to client devices such as device 102. Authentication logic 1224 is a part of web application logic 1222 that causes client devices and their users to authenticate themselves in the manner described above.
Device authentication server 108 is shown in greater detail in
A number of components of device authentication server 108 (
Device 102 is a personal computing device and is shown in greater detail in
CPU 1202 and memory 1204 are connected to one another through a conventional interconnect 1206, which is a bus in this illustrative embodiment and which connects CPU 1202 and memory 1204 to one or more input devices 1208, output devices 1210, and network access circuitry 1212. Input devices 1208 can include, for example, a keyboard, a keypad, a touch-sensitive screen, a mouse, a microphone, and one or more cameras. Output devices 1210 can include, for example, a display—such as a liquid crystal display (LCD)—and one or more loudspeakers. Network access circuitry 1212 sends and receives data through computer networks such as wide area network 104 (
A number of components of device 102 are stored in memory 1204. In particular, web browser 1220 is all or part of one or more computer processes executing within CPU 1202 from memory 1204 in this illustrative embodiment but can also be implemented using digital logic circuitry. As used herein, “logic” refers to (i) logic implemented as computer instructions and/or data within one or more computer processes and/or (ii) logic implemented in electronic circuitry. Web browser plug-ins 1222 are each all or part of one or more computer processes that cooperate with web browser 1220 to augment the behavior of web browser 1220. The manner in which behavior of a web browser is augmented by web browser plug-ins is conventional and known and is not described herein.
Operating system 1230 is all or part of one or more computer processes executing within CPU 1202 from memory 1204 in this illustrative embodiment but can also be implemented using digital logic circuitry. An operating system (OS) is a set of programs that manage computer hardware resources and provide common services for application software such as web browser 1220, web browser plug-ins 1222, and DDK generator 1240.
DDK generator 1240 is all or part of one or more computer processes executing within CPU 1202 from memory 1204 in this illustrative embodiment but can also be implemented using digital logic circuitry. DDK generator 1240 facilitates authentication of device 102 in the manner described above.
Dynamic device key 1242 is data stored persistently in memory 1204 and can be organized as all or part of one or more databases.
The above description is illustrative only and is not limiting. The present invention is defined solely by the claims which follow and their full range of equivalents. It is intended that the following appended claims be interpreted as including all such alterations, modifications, permutations, and substitute equivalents as fall within the true spirit and scope of the present invention.
This application claims priority to U.S. Provisional Application 61/787,453, filed May 31, 2013, which is fully incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
61787453 | May 2013 | US |