Robust computing device identification framework

• US 10,652,365 B2
• Filed: 01/06/2016
• Issued: 05/12/2020
• Est. Priority Date: 01/06/2016
• Status: Active Grant

• Current Assignee: Adobe Inc.
• Original Assignee: Adobe Inc.
• Inventors: Biswas, Sanjeev Kumar, Goyal, Mayank, Srivastava, Sharad
• Primary Examiner(s): Anyan, Barbara B
• Application Number:
  US14/988,954
• Publication Number:
  US 20170195460A1
• Time in Patent Office: 1,588 Days
• CPC Class Codes: G06F 21/305 by remotely controlling device operation
• CPC Class Codes: G06F 21/335 for accessing specific resources, e.g. using Kerberos tickets
• CPC Class Codes: G06F 21/41 where a single sign-on provides access to a plurality of computers
• CPC Class Codes: G06F 21/44 Program or device authentication
• CPC Class Codes: G06F 21/45 Structures or tools for the administration of authentication
• CPC Class Codes: G06F 21/577 Assessing vulnerabilities and evaluating computer system security
• CPC Class Codes: G06Q 20/20 Point-of-sale [POS] network systems
• CPC Class Codes: G06Q 20/382 insuring higher security of transaction
• CPC Class Codes: G06Q 20/3821 Electronic credentials
• CPC Class Codes: H04L 63/0807 using tickets, e.g. Kerberos cryptographic mechanisms or cryptographic arrangements for entity authentication using tickets or tokens H04L9/3213
• CPC Class Codes: H04L 63/0815 providing single-sign-on or federations
• CPC Class Codes: H04L 63/0853 using an additional device, e.g. smartcard, SIM or a different communication terminal cryptographic mechanisms or cryptographic arrangements for entity authentication involving additional secure or trusted devices H04L9/3234
• CPC Class Codes: H04L 63/0861 using biometrical features, e.g. fingerprint, retina-scan cryptographic mechanisms or cryptographic arrangements for entity authentication using biological data H04L9/3231
• CPC Class Codes: H04L 67/01 Protocols
• CPC Class Codes: H04L 9/3213 using tickets or tokens, e.g. Kerberos network architectures or network communication protocols for entities authentication using tickets in a packet data network H04L63/0807
• CPC Class Codes: H04L 9/3236 using cryptographic hash functions

Abstract

A client device is tracked over a period of time using “refresh tokens” that are exchanged in conjunction with routine client-server communications. Each communication cycle between client and server includes a refresh token that is recorded at the server. The recorded refresh tokens are mapped to both server- and client-generated device identifiers. As communications between client and server occur, a chain of tokens, one for each communication cycle, is progressively recorded at the server. If the server receives a token that is outdated with respect to that which is otherwise expected based on the progression of the recorded chain, this suggests that the received communication was transmitted from a device that is a clone of another client device. A more robust device identification framework is therefore achieved by using a combination of device identifiers and tokens exchanged between client and server.

Claims

1. A device identification system that comprises a memory device and a processor that is operatively coupled to the memory device, wherein the processor is configured to execute instructions stored in the memory device that, when executed, cause the processor to carry out a process for identifying multiple client devices in a client-server computing environment, the process comprising:

receiving, by a server from a first client device, an initial identification tuple that includes (a) a device identifier that has been assigned to the first client device and (b) a root random globally unique identifier (RRG) that has been generated by the first client device;

in response to the server receiving the initial identification tuple, acquiring, by the server, a first refresh token;

mapping the initial identification tuple to the first refresh token in a database that is administered by the server;

sending, from the server to the first client device, a response tuple that includes the RRG and the first refresh token;

receiving, by the server from a second client device, the RRG and a second refresh token;

in response to receiving the RRG and the second refresh token from the second client device, using the received RRG to lookup the initial identification tuple in the database;

making a determination, by the server, that the first refresh token included in the response tuple sent to the first client device is outdated with respect to the second refresh token received from the second client device;

in response to making the determination, assigning, by the server, a new RRG (RRG-new) to the second client device;

in response to making the determination, acquiring, by the server, a new refresh token;

mapping a clone identification tuple to the new refresh token in the database, wherein the clone identification tuple includes the device identifier and RRG-new; and

sending the clone identification tuple from the server to the second client device.

2. The system of claim 1, wherein:

the initial identification tuple includes a plurality of different device identifiers; and

the process further comprises generating, by the server, a pseudo-server-side device identifier (PDID) by performing a bitwise OR operation on the plurality of different device identifiers.

3. The system of claim 1, wherein acquiring the new refresh token comprises acquiring the new refresh token from a refresh token pool hosted by the server.

4. The system of claim 1, wherein the process further comprises:

in response to the server receiving the initial identification tuple, acquiring, by the server, a first server issued unique identifier (SIUI-1) that is associated with the first client device;

in response to making the determination, acquiring, by the server, a second server issued unique identifier (SIUI-2) that is associated with the second client device; and

creating a new entry {SIUI-1 →

SIUI-2} in a Clash Detected data structure.

5. The system of claim 1, wherein:

the process further comprises, in response to making the determination, acquiring, by the server, a server issued unique identifier (SIUI-2) that is associated with the second client device; and

mapping the clone identification tuple to the new refresh token further comprises creating a chain entry in the database that comprises a mapping of the clone identification tuple to SIUI-2, which is in turn mapped to a refresh token set that includes the new refresh token.

6. The system of claim 1, wherein:

the process further comprises, in response to the server receiving the initial identification tuple, acquiring, by the server, a first server issued unique identifier (SIUI-1) that is associated with the first client device; and

mapping the initial identification tuple to the first refresh token further comprises creating a chain entry in the database that comprises a mapping of the initial identification tuple to SIUI-1, which in turn is mapped to a refresh token set that includes the first refresh token.

7. The system of claim 1, wherein:

the RRG and the second refresh token are received in a subsequent response tuple that includes the device identifier; and

both the RRG and the device identifier are used to lookup the response tuple.

8. The system of claim 1, wherein the device identifier is assigned by a manufacturer of the first client device.