US20140006781A1

US20140006781A1 - Encapsulating the complexity of cryptographic authentication in black-boxes

Info

Publication number: US20140006781A1
Application number: US13/925,824
Authority: US
Inventors: Francisco Corella; Karen Pomian Lewison
Original assignee: Pomian and Corella LLC
Current assignee: Pomian and Corella LLC
Priority date: 2012-06-23
Filing date: 2013-06-24
Publication date: 2014-01-02
Also published as: US9185111B2; US20140032906A1

Abstract

A method of authenticating a computing device to a back-end subsystem. In one embodiment a prover black-box in the computing device authenticates cryptographically to a verifier black-box in the back-end subsystem by proving possession of a cryptographic credential. The verifier black-box sends an authentication token to the prover black-box as verifiable confirmation of the cryptographic authentication. The prover black-box sends the authentication token to an application front-end in the computing device. The application front-end sends the authentication token to an application back-end in the back-end subsystem, and the application back-end verifies the authentication token.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The subject matter of this application is related to the subject matter of U.S. Provisional Patent Applications No. 61/663,569 (filed on Jun. 23, 2012), No. 61/677,011 (filed on Jul. 30, 2012), No. 61/804,638 (filed on Mar. 23, 2013) and No. 61/809,790 (filed on Apr. 8, 2013), priority to which is claimed under 35 U.S.C. §119(e) and which are incorporated herein by reference.

BACKGROUND

Passwords are commonly used for returning-user authentication to a software application back-end across a network such as the Internet, but they have well known security weaknesses, including vulnerability to phishing attacks, breaches of back-end database security, and reuse at malicious sites. Furthermore, passwords are ill-suited for use on mobile devices such as smart phones and tablets: entering a strong password with letters, digits and punctuation on a small touch screen keyboard is cumbersome, and password characters are exposed to shoulder surfing because they are echoed by the keyboard as they are being typed in an effort to prevent typographical errors.
Cryptography provides alternatives for returning-user authentication that are more secure and better suited for mobile devices. For example, a mobile device could authenticate to an application back-end by proving knowledge of a private key that is part of a key pair pertaining to a public key cryptosystem, a hash of the public key that is part of the same key pair having been previously registered with the application back-end; the user would be indirectly authenticated as the owner of the device. This is more secure than authentication with a password because the private key is not sent to the application back-end or stored in a back-end database; and it is better suited for mobile devices because it does not require typing a password.
Cryptography also allows a user to authenticate to an application back-end as having an identity or attributes asserted by a third-party, without the third-party being involved in the authentication transaction. For example, a computing device owned by the user may generate a key pair pertaining to a public key cryptosystem. The user may ask the third-party to sign a public key certificate binding the public key that is part of the key pair to one or more identifiers and/or attributes that the third-party is authoritative for, and store the public key certificate in the computing device together with the private key that is part of the key pair. The computing device may then authenticate to the application back-end by sending the certificate and proving knowledge of the private key. The user controlling the device is then indirectly authenticated as being entitled to the identifier and/or attributes.
Cryptography is currently used successfully for user authentication in some specific use cases, such as authentication of a US federal employee to the information system of a US federal agency using a public key certificate and its associated private key stored in a Personal Identity Verification (PIV) card connected to a personal computer. But cryptographic authentication is not broadly used outside such specific use cases.
One reason why cryptographic authentication is not broadly used is that it is difficult to implement for application developers. While user authentication with a password simply requires transmission of the password from a user's device to the application back-end, cryptographic authentication requires execution of a cryptographic protocol involving multiple cryptographic operations (such as digital signatures, verification of digital signatures, computation of cryptographic hashes, etc.) by multiple parties, and transmission of multiple messages between those parties. The details of the individual cryptographic operations performed by the parties to a cryptographic protocol are typically hidden from application developers in cryptographic libraries, but application developers must still cope with many difficulties. They must understand the cryptographic protocol, install cryptographic libraries, ensure that all parties agree on the parameters of the protocol, implement the sequence of messages and cryptographic operations required by the protocol, and handle errors and exceptions.
Such difficulties discourage many application developers from using cryptography to authenticate a computing device to an application back-end. Hence there is a need for a method of authenticating a computing device to an application back-end using a cryptographic protocol that is easier to implement for application developers than prior methods.

SUMMARY

A method is provided for authenticating a computing device to a back-end subsystem using a prover black-box in the computing device and/or a verifier black-box in the back-end subsystem to encapsulate cryptographic functionality.
In one embodiment the prover black-box authenticates cryptographically to the verifier black-box by proving possession of a cryptographic credential. The verifier black-box sends an authentication token to the prover black-box as verifiable confirmation of the cryptographic authentication. The prover black-box sends the authentication token to an application front-end in the computing device. The application front-end sends the authentication token to an application back-end in the back-end subsystem, and the application back-end verifies the authentication token.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are included to provide a further understanding of embodiments and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments and together with the description serve to explain principles of embodiments. Other embodiments and many of the intended advantages of embodiments will be readily appreciated as they become better understood by reference to the following detailed description. Reference numerals consist of a concatenation of a one- or two-digit number referring to a figure, followed by a two-digit number that locates the referenced part within the figure. A reference numeral introduced in a figure may be used in other figures to refer to the same part or a similar part.

FIG. 1 is a block diagram generally illustrating a system for authenticating a computing device using a prover black-box and a verifier black-box, according to embodiments described herein.

FIG. 1A is a block diagram illustrating embodiments that feature a prover black-box but no verifier black-box.

FIG. 1B is a block diagram illustrating embodiments that feature a verifier black-box but no prover black-box.

FIG. 2 is a flow diagram illustrating a process for authenticating a computing device using a prover black-box and a verifier black-box.

FIG. 2A is a flow diagram illustrating a process for authenticating a computing device using a prover black-box.

FIG. 2B is a flow diagram illustrating a process for authenticating a computing device using a verifier black-box.

FIG. 3 is a block diagram illustrating embodiments where the verifier black-box is a virtual appliance.

FIG. 4 is a flow diagram illustrating a process for authenticating a computing device using an authentication token that uniquely identifies an authentication object comprising authentication data.

FIG. 5 is a block diagram illustrating embodiments where the authentication token is used as a login session identifier.

FIG. 6 is a flow diagram illustrating a process that creates a session record upon successful cryptographic authentication.

FIG. 7 is a flow diagram illustrating a process for using an authentication token as a login session identifier.

FIG. 8 is a block diagram illustrating an authentication token comprising signed authentication data.

FIG. 9 is a flow diagram illustrating a process for authenticating a computing device using an authentication token comprising signed authentication data.

DETAILED DESCRIPTION

This Detailed Description refers to the accompanying drawings, which are a part hereof and illustrate examples of embodiments of the invention. It is to be understood that other embodiments are possible, and that the features of different exemplary embodiments can be combined together unless otherwise stated.
FIG. 1 is a block diagram generally illustrating a system 100 for authenticating a computing device 110, which makes it easy for application developers to use cryptography by encapsulating cryptographic complexity in a prover black-box 120 and a verifier black-box 130.
(The term “black-box” refers to a hardware or software component that is dedicated to a specific purpose and can be used without an understanding of its internal workings The term “prover black-box” refers to a black-box whose purpose is to prove possession of one or more cryptographic credentials to a verifier. The term “verifier black-box” refers to a black-box whose purpose is to verify possession of one or more cryptographic credentials by a prover.)
The computing device 110 authenticates to a back-end subsystem 140 over a network such as the Internet. Authentication of the device indirectly authenticates a user controlling the device as the owner of the device. The user interacts with an application front-end 150 running on the device, which communicates over the network with an application back-end 160 that is part of the back-end subsystem. The prover black-box 120 runs on the computing device and communicates with the verifier black-box 130 over the network. In some embodiments the application back-end and the verifier black-box communicate over the same network that connects the device to the application back-end and the verifier black-box, while in other embodiments they communicate over a separate network such as a private network, and in yet other embodiments they are implemented by software running on the same machine.
Within the device 110 the application front-end and the prover black-box communicate with each other by exchanging messages.
In one embodiment the computing device 110 is a mobile device equipped with the iOS operating system, the prover black-box 120 and the application front-end 150 are separate iOS apps, and messages exchanged between the prover black-box and the application front-end are implemented as “URLs with custom schemes,” as explained in the sections entitled “Communicating with Other Apps” and “Implementing Custom URL Schemes” of the “iOS App Programming Guide”.
(The terms “iOS app” and “Android app” are used herein, with their usual meanings, to refer to computer programs running on computing devices equipped with the iOS and Android operating systems respectively. The unabbreviated term “application,” on the other hand, is used more broadly to refer to a computer program that may be distributed over multiple computers. For example, an application may have a front-end component running on mobile device and back-end component running on a server connected to the device over a network. Different components of an application may be developed and deployed by different organizations.)
In one embodiment the computing device 110 is a mobile device equipped with the Android operating system, the prover block-box 120 and the application front-end 150 are separate Android apps, and messages exchanged between the prover black-box and the application front-end are implemented as “Intent objects” as explained in the Android developer guide entitled “Intents and Intent Filters”. In an alternative embodiment the computing device 110 is also equipped with the Android operating system, and the messages exchanged between the prover black-box and the application front-end are also implemented as “Intent objects”, but the prover black-box and the application front-end are parts of the same Android app, each comprising one or more “components” of the app.
In one embodiment the prover black-box 120 is a software library linked to the application front-end, messages from the application front-end 150 to the prover black-box being implemented as Application Programming Interface (API) function calls, and messages from the prover black-box to the application front-end as callbacks.
FIG. 1A illustrates embodiments that feature a prover black-box 120 but no verifier black-box. The functionality of verifying possession of cryptographic credentials exists in the back-end subsystem 140 but is not encapsulated in a verifier black-box. No distinction is made within the back-end subsystem 140 between an application back-end and a verifier black-box.
FIG. 1B illustrates embodiments that feature a verifier black-box but no prover black-box. The functionality of proving possession of cryptographic credentials exists in the device 110 but is not encapsulated in a prover black-box. No distinction is made within the device 110 between an application front-end and a prover black-box.
FIG. 2 is a flow diagram that generally illustrates a process 200 followed by system 100 for authenticating the computing device 110 to the back-end subsystem 140.
At 210 the application front-end 150 asks the prover black-box 120 to authenticate cryptographically to the verifier black-box 130.
At 220 the prover black-box authenticates cryptographically to the verifier black-box 130 by proving possession of one or more cryptographic credentials. Then the process continues at 230.
At 230 the process fails if cryptographic authentication failed at 220. Otherwise the process continues at 240.
At 240 the verifier black-box sends to the prover black-box an authentication token providing verifiable confirmation of the cryptographic authentication. Then the process continues at 250.
At 250, the prover black-box sends the authentication token to the application front-end. Then the process continues at 260.
At 260 the application front-end authenticates to the application back-end 160 by sending the authentication token. Then the process continues at 270.
At 270 the application back-end attempts to verify the authentication token as being confirmation of a cryptographic authentication. Then the process continues at 280.
At 280 the process succeeds if the authentication token was verified. Otherwise the process fails.
Thus application-specific functionality is embodied in the application front-end and the application back-end, which are developed by developers skilled in the art of application development, whereas cryptographic authentication functionality is encapsulated in the prover black-box and the verifier black-box, which are developed by developers skilled in the art of cryptographic protocol development, and which are made available for use by any number of different applications. This allows application developers to implement cryptographic authentication easily by making use of pre-existing prover and verifier black-boxes.
FIG. 2A illustrates a process followed by embodiments illustrated in FIG. 1A for authenticating the computing device 110 to the back-end subsystem. FIG. 2A differs from FIG. 2 in that the back-end subsystem plays in FIG. 2A the roles played by the application back-end and the verifier black-box in FIG. 2.
FIG. 2B illustrates a process followed by embodiments illustrated in FIG. 1B for authenticating the computing device to the back-end subsystem 140. FIG. 2B differs from FIG. 2 in that steps 210 and 250 are omitted and the computing device plays in FIG. 2B the roles played by the application front-end and the prover black-box in FIG. 2.
FIG. 3 is a block diagram illustrating embodiments where the prover black-box 120 uses a key pair for cryptographic authentication to the verifier black-box 130 and the verifier black-box is a virtual appliance, i.e. a virtual server pre-configured as a generic verifier black-box, whose functionality is not specific to a particular application.
In one embodiment the verifier black-box 130 and the application back-end 160 are virtual servers known as Elastic Computing Cloud EC2 machine instances, made available for rent by the hour by Amazon Web Services (AWS), and located within a Virtual Private Cloud (VPC) 310 internal to the back-end subsystem 140, so that they communicate securely over a virtual private network. The verifier black-box virtual server is pre-configured by developers skilled in the art of implementing cryptographic protocols, and made available as a virtual appliance on the AWS Marketplace. The application back-end virtual server has access to a relational database 320 provided by the AWS Relational Database Service (RDS).
(The term “appliance” is to be understood as referring to a physical or virtual machine that has been pre-configured as a black-box dedicated to a specific purpose and made generally available for use by applications to that purpose.)
The database 320 comprises a table of user records 330 and a table of device records 340. Each user record corresponds to an application user, and comprises a USER RECORD HANDLE field 332 that uniquely identifies the record within the table, as well as a collection of fields 334 containing user data. Each user record is indexed by the value of the USER RECORD HANDLE field 332 for efficient retrieval of the record given that value. Each device record corresponds to a device that an application user has registered for use with the application, and comprises a DEVICE RECORD HANDLE field 342 that uniquely identifies the record, a HASH OF PUBLIC KEY field 344, and a USER RECORD HANDLE field 346. The value of the USER RECORD HANDLE field 346 refers to the user record for the user who registered the device. Each device record is indexed by the value of the DEVICE RECORD HANDLE field 342 for efficient retrieval of the record given that value.
(The term “handle” is used herein as a synonym for the term “primary key” of database terminology, to avoid confusion between database keys and cryptographic keys.)
The prover black-box 120 has a credential 350 comprising a device record handle 352 and a key pair 354 pertaining to a digital signature public key cryptosystem such as one of the public key cryptosystems, DSA, ECDSA or RSA, specified in the Digital Signature Standard (DSS), publication FIPS PUB 186-3 of the National Institute of Standards and Technology (NIST). The device record handle identifies a device record in the database 320, viz. the device record that contains the device record handle 352 as the value of the DEVICE RECORD HANDLE field 342. That record is expected to contain a hash of the public key that is part of the key pair 354 as the value of the HASH OF PUBLIC KEY field 344.
(The key pair 354 consists a collection of cryptographic parameters. The terms “private key” and “public key” are used herein to refer to the key pair parameters needed to sign and verify a signature, respectively. For example, with the notations of Section 4.1 of the DSS, a DSA key pair consists of the parameters p, q, g, x and y. The private key is (p,q,g,x) and the public key is (p,q,g,y). This usage of the terms “private key” and “public key” is different from the usage in the DSS, which does not consider “domain parameters” as being part of the private and public keys. For example, in the case of the DSA cryptosystem, the DSS refers to x as the private key and y as the public key, omitting the domain parameters p, q and g.)
FIG. 4 is a flow diagram showing an authentication process 400 followed by embodiments illustrated in FIG. 3.
At 405 the application front-end 150 sends a message to the prover black-box 120 asking it to authenticate cryptographically to the verifier black-box 130. Then the process continues at 410.
At 410 the prover black-box authenticates cryptographically to the verifier black-box. To that purpose it establishes a TLS connection to a cryptographic authentication endpoint of the verifier black-box. (The acronym TLS refers to the Transport Layer Security protocol of the Internet Engineering Task Force, which is a successor to the Secure Sockets Layer protocol.) During the TLS handshake, the verifier black-box authenticates to the prover black-box by sending a TLS server certificate and proving knowledge of the corresponding private key. After the TLS connection has been established, the verifier black-box sends a random high-entropy nonce to the prover black-box over the TLS connection. The verifier black-box and the prover black-box separately construct a challenge by computing a cryptographic hash of the nonce and the TLS server certificate. The prover black-box signs the challenge using the private key that is part of the key pair 354, and sends the signature, the public key that is part of the key pair, and the device record handle 352 to the verifier black-box over the TLS connection; by signing the challenge, the prover black-box proves knowledge of the private key; by sending the device record handle and proving knowledge of the private key the prover black-box proves possession of the credential 350. Then the process continues at 415.
At 415 the verifier black-box verifies the signature using the public key that is part of the key pair. If the verification of the signature succeeds, cryptographic authentication is successful and the process continues at 420. Otherwise the process fails.
At 420 the verifier black-box creates an authentication object 360, shown in FIG. 3, containing an authentication token 362, a timestamp 363 and authentication data 364. The authentication token is generated by the verifier black-box as a high entropy random string. The authentication data comprises the device record handle 352 received from the prover black-box at step 410 and a cryptographic hash 365 computed by applying a cryptographic hash function to the public key also received at step 410. In one embodiment the cryptographic hash function is the hash function SHA-1 specified in the Secure Hash Standard (SHS), published by NIST as FIPS PUB 180-4; in alternative embodiments it is one of the other hash functions specified in the SHS. The authentication object is an element of an array 366 of such authentication objects. Since the authentication token is a high-entropy random string, the authentication object is uniquely identified with high probability by the authentication token, and hence is retrievable by the authentication token. In one embodiment the array of objects 366 is stored in shared memory allocated in the verifier black-box virtual server 130; in an alternative embodiment the array of authentication objects is implemented as a table of authentication records within a relational database internal to the verifier black-box virtual server, each authentication object being referred to as an authentication record and being indexed by the authentication token. Then the process continues at 425.
(The term “random string” is meant to encompass both a truly random string, and a string generated by a pseudo-random string generator or an entropy accumulator such as the /dev/urandom facility of Linux and other Unix systems.)
At 425 the verifier black-box sends the authentication token to the prover black-box over the TLS connection established at step 410, as confirmation that cryptographic authentication was successful at 410. This confirmation is verifiable by using the authentication token to retrieve the authentication object 360 created at 420 (as is done at step 445). Then the process continues at 430.
At 430 the prover black-box sends a message to the application front-end containing the authentication token. Then the process continues at 435.
At 435 the application front-end authenticates to the application back-end 160 by sending the authentication token over a TLS connection. Then the process continues at 440.
At 440 the application back-end sends the authentication token to an authentication data retrieval endpoint of the verifier black-box for verification, over the virtual private network provided by the VPC 310. Then the process continues at 445.
At 445 the verifier black-box attempts to retrieve an authentication object 360 containing the authentication token received at step 440 and being recent enough, i.e. having an age, determined by the timestamp 363, that is less than an age limit set by a security policy. If there is no such object, the process fails. Otherwise the authentication token is deemed to have been verified as a confirmation of the cryptographic authentication that resulted in the creation of the object, and the process continues at 450.
At 450 the verifier black-box sends the authentication data contained in the authentication object to the application back-end over the virtual private network. The authentication data comprises the device record handle 352 and the hash of a public key 365. Then the process continues at 455.
At 455 the application back-end looks in the database 320 for a device record containing the device record handle 352 in the DEVICE RECORD HANDLE field 342 and the hash of a public key 365 in the HASH OF PUBLIC KEY field 344. If no such record is found, the process fails. Otherwise the process continues at 460.
At 460 the application back-end looks in the database 320 for a user record whose USER RECORD HANDLE field 332 that has the same value as the USER RECORD HANDLE field 346 of the device record found at step 455. If no such record is found, the process fails. Otherwise the process continues at 465.
At 465 the application back-end sends user data contained in the user data fields 334 of the user record found at step 460 to the application front-end over a TLS connection. Then the process terminates successfully: the device has been successfully authenticated to the application back-end as being the device corresponding to the device record found at step 455, owned by the user corresponding to the user record found at step 460.
In one embodiment, steps 455 and 460 are combined and implemented together using a join of the table of device records 340 and the table of user records 330, in a manner well known to developers skilled in the art of relational database query processing.
FIG. 5 is a block diagram illustrating embodiments where the authentication token is used repeatedly by the application front-end 150 as a login session identifier for intra-session authentication to the application back-end 160 while a login session is in progress, following an initial cryptographic authentication. The database 320 comprises a table of login session records 510. Each login session record represents a login session and comprises a SESSION ID field 520 that uniquely identifies the record, a DEVICE RECORD HANDLE field 530 that refers to a device record, and an EXPIRATION TIME field 540 that specifies a time at which the login session will expire. Each login session record is indexed by the value of the SESSION ID field 520 for efficient retrieval of the record given that value. Upon initial cryptographic authentication, a login session record is created and the authentication token is stored in the record as the value of the SESSION ID field. The authentication token is also stored by the application front-end in a memory location 550 for use as a login session identifier.
FIG. 6 is a flow diagram illustrating an extension of the authentication process 400, followed by embodiments illustrated in FIG. 5, to accommodate the creation of a session record upon successful cryptographic authentication. Two additional steps are inserted into the process 400. Step 610 is inserted between steps 430 and 435 and step 620 between steps 460 and 465.
At 610 the application front-end 150 stores a copy of the authentication token, received at step 430, in the memory location 550, before forwarding it to the application back-end at step 435.
At 620 the application back-end 160 creates a login session record in the table of login session records 510, comprising the authentication token, received at step 430, as the value of the SESSION ID field 520, the device record handle, contained in the authentication data received at step 450, as the value of the DEVICE RECORD HANDLE field 530, and an expiration time as the value of the EXPIRATION TIME field 540.
FIG. 7 is a flow diagram illustrating a process 700, followed by embodiments illustrated in FIG. 5, to use an authentication token as a login session identifier.
At 710 the application front-end 150 sends the authentication token stored in the memory location 550 to the application back-end 160 over a TLS connection. Then the process continues at 720.
At 720 the application back-end looks in the database 320 for a login session record where the value of the SESSION ID field 520 is the authentication token. If no such record is found, the process fails. Otherwise the process continues at 730.
At 730 the application back-end checks if the current time is past the expiration time specified by the EXPIRATION TIME field of the login session record found at step 720. If so, the process fails. Otherwise the process continues at 740.
At 740 the application back-end looks in the database 320 for a device record whose DEVICE RECORD HANDLE field 342 that has the same value as the DEVICE RECORD HANDLE field 530 of the login session record found at step 720. If no such record is found, the process fails. Otherwise the process continues at 750.
At 750 the application back-end looks in the database 320 for a user record whose USER RECORD HANDLE field 332 that has the same value as the USER RECORD HANDLE field 346 of the device record found at step 740. If no such record is found, the process fails. Otherwise the process terminates successfully: the device has been successfully authenticated to the application back-end as being the device corresponding to the device record found at step 740, owned by the user corresponding to the user record found at step 750.
In one embodiment, steps 740, 750 and 760 are combined and implemented together using a join of the table of login session records 510, the table of device records 340 and the table of user records 330, in a manner well known to developers skilled in the art of relational database query processing.
FIG. 8 is a block diagram illustrating an authentication token 800 that comprises digitally signed authentication data. Instead of uniquely identifying an authentication object 360 that comprises authentication data 364 including the device record handle 352 and the public key hash 365, the authentication token itself comprises the authentication data 364 with the device record handle 352 and the public key hash 365, a creation timestamp 363, and a signature 810 computed by the verifier black-box 130 on the authentication data and the timestamp.
FIG. 9 is a flow diagram illustrating a process 900 for authenticating a computing device using an authentication token comprising signed authentication data. Embodiments using process 900 are illustrated in FIG. 3, except that the verifier black-box 130 does not use an array 366 of authentication objects.
The process 900 is a modification of the process 400 of FIG. 4. Steps 420, 440 and 445 are replaced by steps 920, 940 and 945 respectively.
At 920 the verifier black-box constructs authentication data 364 as at step 420 of process 400. But instead of storing the data in an authentication object, it creates the authentication token 800 comprising the authentication data 364, a creation timestamp 363, and a signature on the authentication data and the timestamp. In one embodiment the signature is computed using a private key pertaining to a digital signature public key cryptosystem such as those specified in the DSS (DSA, ECDSA or RSA).
At 940, instead of sending the authentication token to the verifier black-box for verification as at step 440 of process 400, the application back-end checks that the timestamp 363 is not older than an age limit set by a security policy, and verifies the signature 810 using the public key associated with private key that the verifier black-box used to compute the signature at step 920.
At 945, the process fails if the verification of the signature failed at 940. Otherwise the process continues at 450.
In some embodiments the credential 350 shown in FIG. 3 is created when a user registers the computing device 110 with the application back-end 160. In one embodiment the key pair 354 pertains to one of the digital signature public key cryptosystems specified by the DSS (DSA, ECDSA or RSA) and is generated by the prover black-box as specified in the DSS. In one embodiment the prover black-box generates the device record handle 352 as a high entropy random string so that it is distinct with high probability from handles of other device records in the table of device records 340. As in process 400, the prover black-box proves possession of the newly created credential to the verifier black-box, which creates an authentication object retrievable by an authentication token and sends the authentication object to the prover black-box, which forwards it to the application back-end via the application front-end. The application back-end uses the authentication token to retrieve the authentication data from the verifier black-box, then creates a device record, using the device record handle in the authentication data as the value of the DEVICE RECORD HANDLE field 342 and the hash of the public key in the authentication data as the value of the HASH OF PUBLIC KEY field 344.
If no user record has been created yet for the user who registers the device, the user provides user data to the application front-end, which sends the user data to the application back-end over the same TLS connection that it uses to send the authentication token. The application back-end creates a user record containing the user data in the user data fields 334 and containing a new user record handle distinct from those of other user records in the USER RECORD HANDLE field 332. (In one embodiment the new user record handle is obtained by incrementing a counter of user record handles; in an alternative embodiment it is generated as high entropy random string, which is distinct from existing user record handles with high probability.) Then the application back-end stores the new user record handle in the USER RECORD HANDLE field 346 of the newly created device record.
If a user record already exists for the user who registers the device, the user provides a registration code, which the user has obtained via another computing device, to the application front-end. The registration code is a reference to a short-lived registration record that contains a user record handle that identifies the user record. The application front-end sends the registration code to the application back-end over the same TLS connection that it uses to send the authentication token. The application back-end finds the user record referenced by the registration record and stores the user record handle of that record in the USER RECORD HANDLE field 346 of the newly created device record.

Claims

1-13. (canceled)

14. A method of authenticating a computing device to a back-end subsystem, comprising:

a prover black-box in the computing device authenticating cryptographically to a verifier black-box in the back-end subsystem by proving possession of a cryptographic credential;

the verifier black-box sending an authentication token to the prover black-box as verifiable confirmation of the cryptographic authentication;

the prover black-box sending the authentication token to an application front-end in the computing device;

the application front-end sending the authentication token to an application back-end in the back-end subsystem; and

the application back-end verifying the authentication token.

15. The method of claim 14, wherein the verifier black-box is a virtual appliance.

16. The method of claim 14, wherein the device uses the authentication token as a login session identifier.

17. The method of claim 14, wherein the authentication token uniquely identifies an object comprising authentication data.

18. The method of claim 14, wherein the authentication token comprises digitally signed authentication data.

19. The method of claim 14, wherein the cryptographic credential comprises a key pair pertaining to a public key cryptosystem and a public key that is part of the key pair is stored in a database within the back-end subsystem.

20. The method of claim 14, wherein the cryptographic credential comprises a key pair pertaining to a public key cryptosystem and a hash of a public key that is part of the key pair is stored in a database within the back-end subsystem.

21. The method of claim 14, wherein the cryptographic credential comprises a private key that is part of a key pair pertaining to a public key cryptosystem, and proving possession of the cryptographic credential includes proving knowledge of the private key.

22. The method of claim 21, wherein the public key cryptosystem is a digital signature cryptosystem, and proving knowledge of the private key includes using the private key to sign a challenge.

23. A prover black-box included in a computing device and used in authenticating the device to a back-end subsystem, configured to:

receive a request from an application front-end running on the device to perform a cryptographic authentication to the back-end subsystem;

authenticate cryptographically to the back-end subsystem by proving possession of a credential;

receive an authentication token from the back-end subsystem as confirmation of the cryptographic authentication; and

send the authentication token to the application front-end.

24. The prover black-box of claim 23, wherein the credential comprises a private key that is part of a key pair pertaining to a public key cryptosystem, and proving possession of the credential includes proving knowledge of the private key.

25. The prover black-box of claim 24, wherein the public key cryptosystem is a digital signature cryptosystem, and proving knowledge of the private key includes using the private key to sign a challenge.

26. A verifier black-box configured to:

authenticate cryptographically a computing device by verifying possession of a cryptographic credential by the device;

return an authentication token to the device as verifiable confirmation of the cryptographic authentication;

receive the authentication token from an application back-end; and

send authentication data to the application back-end.

27. The verifier black-box of claim 26, wherein the credential comprises a private key that is part of a key pair pertaining to a public key cryptosystem, and verifying possession of the credential includes verifying knowledge of the private key.

28. The verifier black-box of claim 27, wherein the public key cryptosystem is a digital signature cryptosystem, and verifying possession of the private key includes verifying that a signature made with the private key is valid.

29. The verifier black-box of claim 26, further configured to create an authentication object that comprises authentication data and is uniquely identified by the authentication token.

30. The verifier black-box of claim 29, wherein the authentication data comprises a hash of a public key that is part of the credential.

31. The verifier black-box of claim 26, wherein the authentication token comprises digitally signed authentication data.

32. The verifier black-box of claim 26, implemented as a virtual server made available for rent by a cloud service provider.

33. The verifier black-box of claim 32, located together with the application back-end within a virtual private cloud.