Device identification and data deduplication system and method

Abstract

Some embodiments construct a device fingerprint of a target device (e.g., a personal computer, smartphone) by intercepting access requests issued by the target device. A portion of the device fingerprint may be determined according to various characteristics of the access requests, e.g., TLS handshake, TCP header, and / or HTTP header according to the respective access requests. Another portion of the device fingerprint is determined by transmitting a fingerprint recognition probe to the target device in response to the access request and extracting a set of features characterizing a browser executing on the target device using executable code included in the fingerprint recognition probe. Some embodiments then compare the device fingerprint to a reference fingerprint determined for other devices on the same network to determine whether the target device is a familiar device. Exemplary applications include access control, personalized content distribution, and the like.

Description

Background Technology

[0001] This invention relates to computer security, and more particularly to the automatic identification of electronic devices used for access control applications.

[0002] Malware, also known as malware, affects a vast number of computer systems worldwide. In many forms (such as computer viruses, worms, rootkits, unsolicited adware, ransomware, and spyware), malware poses a serious risk to millions of computer users, making them vulnerable to ransomware, loss of data and sensitive information, identity theft, and productivity loss. Malware can further display material that some users perceive as obscene, excessively violent, harassing, or otherwise offensive. The explosive growth of mobile computing only exacerbates exposure and associated risks, as millions of smartphones and tablets are constantly connected to the internet and become potential targets for malware.

[0003] Security software can be used to detect malware that infects a user's computer system and, in addition, remove or block the execution of such malware. Security software can further prevent infection by preventing protected devices from accessing known sources of infection, such as internet domains or specific web pages associated with fraud and / or the distribution of malware. Similarly, some corporate networks restrict access to sensitive data to a limited set of users and devices. Such security methods are often referred to as access control and are typically implemented by network devices such as routers and gateways based on user-specific or device-specific access policies.

[0004] However, correctly implementing access policies presents significant technical challenges. First, the world of electronic devices is extremely heterogeneous and constantly evolving. Therefore, applying the correct access policies may require identification across a vast array of device types and variations. Second, devices themselves may change over time and behave in unfamiliar ways simply due to frequent software updates and the installation of new software. Consequently, network devices responsible for applying personalized access control policies may suddenly fail to recognize them. Furthermore, mobile computing devices, such as smartphones and wearables, are designed to accompany their owners and thus constantly hop between networks. Therefore, implementing a unified access policy may require reliably identifying the appropriate device across multiple networks and access points.

[0005] A robust implementation of access strategies should also be insensitive to deliberate malicious exploitation of network protocols. One such instance is spoofing, where a rogue device impersonates a legitimate device to secretly gain access to specific resources or network locations. Another instance includes Media Access Control (MAC) address randomization, where the same device can expose different MAC addresses on different attempts to join the network in order to ensure privacy, avoid tracking, etc.

[0006] The technical issues described above are not specific to computer security, but are equally applicable to other applications that rely on the reliable identification of users and / or devices. Some such examples include parental controls and targeted content delivery, such as online advertising.

[0007] In light of the above, there remains a sustained interest in developing robust and efficient methods for automatic device identification. Summary of the Invention

[0008] According to one aspect, a computer system includes at least one hardware processor configured to, in response to receiving an access request from a client device, transmit a fingerprint detection to the client device, the fingerprint detection including computer code configured to determine a first set of feature values ​​characterizing a browser executing on the client device. The at least one hardware processor is further configured to receive the first set of feature values ​​from the client device to determine a second set of feature values ​​characterizing the client device based on metadata of the access request, and to determine a device fingerprint of the client device based on the first and second sets of feature values. The at least one hardware processor is further configured to determine a similarity measure quantifying the similarity between the device fingerprint and a reference fingerprint characterizing a reference device, and, in response, if the similarity measure indicates that the client device is identical to the reference device, then set a device identifier of the client device to be equivalent to a device identifier of the reference device.

[0009] According to another aspect, a computer implementation method includes employing at least one hardware processor of a computer system to transmit a fingerprint detection probe to the client device in response to receiving an access request from the client device, the fingerprint detection probe including computer code configured to determine a first set of feature values ​​characterizing a browser executing on the client device. The method further includes receiving the first set of feature values ​​from the client device, determining a second set of feature values ​​characterizing the client device based on metadata of the access request, and determining a device fingerprint of the client device based on the first and second sets of feature values. The method further includes determining a similarity metric quantifying the similarity between the device fingerprint and a reference fingerprint characterizing a reference device, and, in response, if the similarity metric indicates that the client device is identical to the reference device, then setting a device identifier of the client device to be equivalent to a device identifier of the reference device.

[0010] According to another aspect, a non-transitory computer-readable medium storing instructions, which, when executed by at least one hardware processor of a computer system, cause the computer system to transmit a fingerprint detection to the client device in response to receiving an access request from the client device, the fingerprint detection including computer code configured to determine a first set of feature values ​​characterizing a browser executing on the client device. The instructions further cause the computer system to receive the first set of feature values ​​from the client device to determine a second set of feature values ​​characterizing the client device based on metadata of the access request, and to determine a device fingerprint of the client device based on the first and second sets of feature values. The instructions further cause the computer system to determine a similarity metric quantifying the similarity between the device fingerprint and a reference fingerprint characterizing a reference device, and, in response, if the similarity metric indicates that the client device is identical to the reference device, then set the device identifier of the client device to be equivalent to the device identifier of the reference device. Attached Figure Description

[0012] The foregoing aspects and advantages of the invention will become better understood after reading the following detailed description and referring to the drawings, wherein:

[0013] Figure 1 This invention demonstrates several client devices protected from computer security threats according to some embodiments of the invention.

[0014] Figure 2 This describes an exemplary sequence of steps performed by a network device according to some embodiments of the present invention.

[0015] Figure 3 Exemplary communication exchanges are demonstrated according to some embodiments of the present invention.

[0016] Figure 4 An exemplary sequence of steps performed by a fingerprint recognition module according to some embodiments of the present invention is shown.

[0017] Figure 5 This describes the structure of exemplary data packets transmitted over a communication network.

[0018] Figure 6 Demonstrates a sample client-server exchange based on a version of the Transport Layer Security (TLS) communication protocol.

[0019] Figure 7 Demonstrate the content of the TLS “ClientHello” message.

[0020] Figure 8 This displays exemplary content of the Transmission Control Protocol (TCP) header.

[0021] Figure 9 This displays exemplary content of the Hypertext Transfer Protocol (HTTP) header.

[0022] Figure 10 This section describes an exemplary tree browser object model (BOM) and selected BOM subtrees according to some embodiments of the present invention.

[0023] Figure 11 Exemplary device fingerprints are shown according to some embodiments of the present invention.

[0024] Figure 12 An exemplary fingerprint retention window is described according to some embodiments of the present invention.

[0025] Figure 13 Exemplary hardware configurations of computer systems programmed to perform some of the methods described herein are shown. Detailed Implementation

[0026] In the following description, it should be understood that all referenced connections between structures can be direct operational connections or indirect operational connections through intermediate structures. A set of elements comprises one or more elements. Any reference to an element is understood to refer to at least one element. Multiple elements comprise at least two elements. Any use of 'or' signifies non-exclusive or. Unless otherwise required, any described method steps need not necessarily be performed in the specific order described. A first element derived from a second element (e.g., data) encompasses a first element equivalent to the second element, as well as a first element generated by processing the second element and optionally processing other data. Determining or deciding based on parameters encompasses determining or deciding based on parameters and optionally based on other data. Unless otherwise specified, some quantity / data indicators may be the quantity / data itself, or indicators different from the quantity / data itself. A computer program is a sequence of processor instructions that performs a task. The computer program described in some embodiments of the invention may be a separate software entity or sub-entity (e.g., a sub-formula, a library) of other computer programs. The metadata herein represents characteristics of the transport other than the payload itself. Exemplary metadata includes, in particular, the network addresses of the sender and / or receiver, the size of the payload, and a timestamp indicating the real-time nature of the corresponding transmission. Two devices are said to be connected to or belong to the same local network when their network addresses belong to the same subnet and / or when they have the same broadcast address. A local network is a network in which communication hardware is managed locally. The database described herein represents any organized, searchable collection of data. Computer-readable media encompasses non-transitory media, such as magnetic, optical, and semiconductor storage media (e.g., hard disk drives, optical discs, flash memory, DRAM), and communication links, such as conductive cables and fiber optic links. According to some embodiments, the present invention particularly provides a computer system comprising hardware (e.g., one or more processors) programmed to perform the methods described herein, and computer-readable media encoding instructions to perform the methods described herein.

[0027] The following description illustrates embodiments of the invention by way of example and not necessarily by way of limitation. For example, although the disclosure below focuses on computer security embodiments, those skilled in the art will recognize that the described systems and methods are applicable to other applications, such as parental controls and targeted content delivery.

[0028] Figure 1Multiple client devices 12a to e are shown, interconnected by a local network 13 and further connected to an extended network 15 (e.g., the Internet). Client devices 12a to e can represent any physical device having a processor, memory, and a communication interface. Exemplary client devices 12a to e include personal computers, laptop computers, tablet computers, mobile telecommunications devices (e.g., smartphones), media players, televisions, game consoles, home appliances (e.g., refrigerators, thermostats, smart heating and / or lighting systems), and wearable devices (e.g., smartwatches, sports and fitness equipment). Local network 13 can include a local area network (LAN). Exemplary local network 13 can include home networks and corporate networks.

[0029] Network device 14 includes electronic means for enabling and / or controlling communication between client devices 12a to e and / or access to extended network 15 by client devices 12a to e. For example, device 14 may include a router and / or a network switch. In some embodiments, device 14 acts as a gateway between local network 13 and extended network 15 and provides a set of network services to client devices 12a to e. The term 'gateway' is used herein to refer to means configured such that at least a portion of the communication traffic between client devices 12a to e and extended network 15 traverses the gateway device. For example, exemplary network services provided by device 14 include, for example, distributing network configuration parameters (e.g., network addresses) to client devices 12a to e according to Dynamic Host Configuration Protocol (DHCP). Other network services may include protecting clients 12a to e from computer security threats, such as malware and intrusion, configuring dedicated communication channels (e.g., Virtual Private Network—VPN), and selectively controlling client devices 12a to e's access to specific remote resources and / or network locations (e.g., parental controls, targeted advertising, etc.).

[0030] In some embodiments, network device 14 is further configured to perform an automatic device identification procedure, possibly in cooperation with a remote fingerprinting server 40 comprising a set of interconnected computer systems. Device identification as described herein includes determining a device identifier for a given device that uniquely distinguishes the given device from other physical devices. In other words, device identification as described below goes beyond determining the device type or category of a given device (e.g., a Samsung® Galaxy® S21 smartphone running Android® version 13) to actually identify a single physical device.

[0031] In an exemplary use case scenario, device 14 maintains a record of client devices currently or previously connected to local network 13. Such records may be stored in a client policy database 42 communicatively coupled to network device 14. The data format of the client device records may differ in embodiments, but generally, client device records associate device identifiers with access policies applicable to the respective client devices.

[0032] In some embodiments, the device identifier includes a unique token (e.g., a hash) that distinguishes the corresponding physical device from other physical devices 12a to e that can connect to the local network 13. The device identifier may be calculated according to a specially designed algorithm / hash scheme, or may include popular identifiers such as the media access control (MAC) address or International Mobile Equipment Identity (IMEI) number of the corresponding client device. Some privacy-enhancing communication protocols use MAC address randomization, meaning that the same physical device may expose different MAC addresses when attempting to join the local network 13 in separate attempts. To address this situation, in some embodiments of the invention, the device identifier may include multiple MAC addresses, for example, all MAC addresses that the corresponding device has exposed in previous attempts to join the local network 13. Other exemplary device identifiers may include a set of device fingerprints determined for the corresponding device, as described in detail below.

[0033] In some embodiments, the client device record of database 42 includes indicators of access policies applicable to the respective device and / or the user of the respective client device, the access policies indicating the categories of content that the respective device / user is allowed or not allowed to access. Access policies may further specify a set of network locations (e.g., Internet domains, network addresses, etc.) that the respective device / user is allowed or prohibited from accessing, indicators of time intervals during which the respective device / user is allowed / prohibited from accessing specific resources, etc. Each access policy may further be associated with a user account, subscription, and / or service agreement used to provide specific network services (e.g., security, parental controls, etc.) to the respective client device and / or user.

[0034] In some embodiments, the device records a set of device characteristics {C1, C2, ..., C...} that further include the respective client device. n The device characteristics may include, for example, product category (e.g., personal computer, tablet computer, printer, smartwatch, home entertainment system, thermostat, etc.), manufacturer (e.g., Samsung®, Nest®, Sonos®, etc.), hardware model (e.g., iPad® 2, MacBook® Air®, Galaxy® S6, etc.), and the version of the operating system running on the respective device (e.g., Windows®, iOS® 8, Android® Marshmallow, etc.).

[0035] In some embodiments, device identification includes determining a device identifier for a target client device in order to apply an appropriate network access policy. Such identification may include determining whether the target client device is identical to a familiar reference device, i.e., a device with at least one reference fingerprint to be compared. The fingerprint identification procedure is described in detail below. In some embodiments, database 42 stores records of all familiar (i.e., fingerprinted) devices. However, for example, after hardware and / or software updates, some characteristics of a client device (and therefore its device fingerprint) may change over time. Due to such changes, a target device may be incorrectly classified as unfamiliar, resulting in unwanted duplicate device records in the database. Some embodiments prevent this duplication by calculating a fingerprint similarity metric, as described in detail below.

[0036] Device identification may occur in response to a client device attempting to join local network 13. In some such embodiments, network device 14 may allow only familiar devices to join the local network. Alternatively, device 14 may allow all devices to join the local network, but perform a device identification procedure in response to a client device attempting to access extended network 15 (e.g., the Internet). Device 14 may then enforce a device-specific access policy based on the result of the device identification procedure.

[0037] Figure 2 An exemplary sequence of steps performed by network device 14 according to some embodiments of the present invention is shown. Step 202 includes intercepting attempts by client devices on local network 13 to access resources located outside the local network. For example, step 202 may include detecting Hypertext Transfer Protocol (HTTP) requests issued by the respective client devices, on remote content server 16 ( Figure 1 HTTP requests addressed at the specified location are paused, and the delivery of the corresponding request to its intended destination is suspended. Placing device 14 at the gateway location facilitates the interception and analysis of this traffic between the client device and the remote party.

[0038] In response to the intercepted access request, in step 206, some embodiments may initiate a device fingerprinting procedure, including redirecting the intercepted access request to the fingerprinting module / service and receiving a device identification report from the fingerprinting module / service (step 208). The operation of the fingerprinting module / service will be described in more detail below.

[0039] When the identification report indicates that the device requesting access is a familiar device (step 210 returns Yes), in step 212, some embodiments identify the device record in the client policy database 42 and associate the source of the current access request with the corresponding device record. In embodiments described below where the identification report contains a device identifier, step 212 may include identifying the device record based on the received device identifier. Step 212 may further include, for example, adding the MAC address currently exposed by the corresponding device and / or the content of the identification report (e.g., the latest device fingerprint) to the corresponding device record.

[0040] In the sequence of steps 214 to 216, device 14 may identify and apply an access policy associated with the corresponding client device, i.e., forward the intercepted request to its intended destination or block the intercepted request according to the corresponding access policy. To determine the applicable access policy, some embodiments may identify an account / service agreement associated with the corresponding client device and further identify the access policy based on the corresponding account / service agreement. Step 214 may include performing a set of database lookups based on the device identifier of the corresponding client device.

[0041] When the identification report received from the fingerprint recognition module indicates an unfamiliar device (step 210 returns No), some embodiments may create a new device record for the corresponding device and store the new device record in database 42 (step 218). In embodiments where the identification report includes a device identifier, network device 14 may use the received device identifier when creating a new database record. Some embodiments may then proceed to configure an access policy associated with the corresponding device, for example by returning a proxy response to the intercepted access request, the proxy response including a set of user interfaces that enable the user of the corresponding device to log in to an existing account, etc. Alternatively or additionally, in step 220, some embodiments may apply a default access policy to the unfamiliar device. An exemplary default access policy includes denying access to the extended network 15 and granting access to a limited set of resources and locations outside the local network 13.

[0042] Figure 3 This describes exemplary data exchange between client device 12, network device 14, and fingerprint recognition module 20 during a fingerprint recognition process, according to some embodiments of the present invention. Client device 12 generally represents... Figure 1The client device 12a to e is one of the client devices in the network. The fingerprint recognition module 20 is configured to determine a device fingerprint that distinguishes client device 12 from other clients 12a to e, the device fingerprint comprising a unique set of feature values ​​for the respective device. In some embodiments, some components of the device fingerprint are determined by module 20 and / or network device 14 based on an access request initiated by the respective client device, while other components are determined based on how device 12 responds to fingerprint recognition detection, as described below.

[0043] Module 20 can be embodied, for example, by fingerprint recognition server 40 ( Figure 1 The hardware processor of module 20 may execute a set of computer programs, or alternatively, the hardware processor of network device 14 or another electronic device connected to local network 13. Those skilled in the art will also know that, in alternative embodiments, at least some of the functionality of module 20 may be implemented in dedicated hardware, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs).

[0044] As described above, network device 14 may be configured to intercept access request 22 issued by a client device. Access request 22 may include, for example, an HTTP request for access to a specific resource hosted by content server 16. Instead of forwarding request 22 to server 16, some embodiments of network device 14 redirect request 22 to fingerprinting module 20 (e.g., to initiate a fingerprinting process) to initiate fingerprinting. Figure 1 (Server 40 in the context of the server). In order to redirect request 22, some embodiments of device 14 are configured to intercept DNS proxy queries used to resolve domain name services (DNS) queries for the domain name of server 16. Instead of returning the network address of server 16, the DNS proxy may return a proxy address pointing to the location of fingerprinting module 20 (e.g., server 40), thus effectively redirecting subsequent HTTP requests from client 16 to module 20.

[0045] Figure 4An exemplary sequence of steps performed by the fingerprint recognition module 20 according to some embodiments of the present invention is shown. Steps 232 to 234 listen for access requests from a client. In response to receiving access request 22, in step 236, some embodiments generate a proxy response to access request 22 in the form of a fingerprint probe 24 and transmit probe 24 to the client device 12. Fingerprint probe 24 may contain a set of data formatted for interpretation by a web browser executing on the client device 12, such as a specification of a document defined in a version of Hypertext Markup Language (HTML) or Extensible Markup Language (XML). In some embodiments, fingerprint probe 24 further includes executable code (i.e., a computer program) configured to be executed by the client's web browser and further configured to determine a set of device characteristics characterizing the client device 12, as detailed below. Exemplary executable code included in probe 24 includes code defined in a scripting language (e.g., a version of JavaScript®).

[0046] In step 238, module 20 may determine a set of device characteristics characterizing client device 12 based on request 22. Such characteristics may form part of a device fingerprint, as further detailed below. In most modern communication protocols, such as the electronic message of access request 22, it is typically divided into multiple parts, which are generally referred to herein as "packets," and these packets can travel independently of each other. Figure 5 Exemplary communication packet 32 ​​includes a payload (i.e., the content of the corresponding message, in...) Figure 5 The packet (represented as application data) and a set of headers containing various communication metadata, such as those used for routing and error checking. Packet 32 ​​can be intercepted and / or inspected at various layers of the network protocol suite, where the layers referred to herein are the Open Systems Interconnection (OSI) model. Therefore, the type and content of the packet headers can vary depending on the implementation. When intercepted at the application layer, the HTTP request may consist of a set of application data preceded by HTTP header 38. However, at the transport layer of the OSI layer, the same packet can be further encapsulated with Transmission Control Protocol (TCP) header 36. Similarly, when intercepted at the network layer, the packet can be further encapsulated with Internet Protocol (IP) headers, etc. Such headers are given only as examples herein and can vary depending on the communication protocol and network architecture.

[0047] Most modern browsers and other software that rely on communication with remote servers use encryption to prevent third parties from accessing the content of such communications. Encryption adds an extra layer of complexity to network communication and can further divide access requests into multiple parts / packets, such as... Figure 6 As explained in the text, Figure 6This demonstrates a typical encrypted communication session performed according to a version of the Transport Layer Security (TLS) protocol, such as that used to implement secure HTTP (HTTPS) requests. Those skilled in the art will recognize that the use of TLS in this document is illustrative only and is not intended to be limiting.

[0048] As explained, Transport Access Request 22 may actually include the exchange of multiple messages / packets 32, also known in the field as TLS records. Packets 32 may be grouped into a handshake portion and a payload portion. For example, the "ClientHello" handshake packet is sent to prepare for the transmission of the payload, typically in plaintext (unencrypted), and includes metadata such as various parameter values ​​used to establish a connection between the corresponding communicating parties, and various cryptographic parameter values ​​required to encrypt and / or decrypt the payload. Following the handshake is typically the transmission of the payload, encrypted according to the parameter values ​​determined and / or exchanged during the handshake.

[0049] Figure 7 This describes exemplary application data for the "ClientHello" TLS record 34, including multiple metadata fields such as the TLSVersion field, CipherSuites field, and Extensions field. The TLSVersion field indicates which version of the TLS protocol is used in the current encrypted communication. The CipherSuites field lists multiple cipher suites (encryption algorithms) that can be used to encrypt the current payload. The content of the Extensions field varies across protocols and implementations and is used to extend TLS functionality and / or for various optimizations. The Extensions field may contain multiple subfields. In some embodiments of the invention, step 328 includes the fingerprinting module 20 identifying the "ClientHello" packet of access request 22 (e.g., based on the content of the RecordHeader field) and extracting the following features from the corresponding "ClientHello" packet:

[0050] The content of the -TLSVersion field, for example, '771' (corresponding to TLS version 1.2);

[0051] - The content of the CipherSuites field, for example, {4865, 4866, 4867, 49196, 49195, 52393, 49200};

[0052] - Compliance indicator, which indicates whether the corresponding group complies with the Generate Random Extensions and Maintain Scalability (GREASE) requirements as defined in the Internet Engineering Task Force Request for Comments RFC 8701, for example, 'Yes';

[0053] - A list of supported groups (a specific subfield of the Extensions field), for example, {29, 23, 24, 25};

[0054] - A list of application layer protocol negotiation (ALPN) protocols supported by client device 12 (a specific subfield of the Extensions field), for example, {'h2', 'http / 1.1'};

[0055] - A list of available certificate compression algorithms (a specific subfield of the Extensions field), for example, '1';

[0056] - A list of available signature algorithms (a specific subfield of the Extensions field), for example, {1027, 2052, 1025, 1283, 515, 2053, 2053 and 1281};

[0057] - A list of available compression methods (a specific subfield of the Extensions field), for example, {0, 1};

[0058] - A list of supported TLS versions (a specific subfield of the Extensions field), for example, {769, 770, 771, 772}.

[0059] Some embodiments rely on the observation that, because the content of the Extensions field is not standardized, such data can vary across different hardware and software implementations of the communication stack, and therefore can be used to identify devices. Therefore, some embodiments use some of the features described above extracted from the “ClientHello” TLS record as device fingerprint features, as further described below. Some embodiments further rely on the observation that list features are ordered according to the preferences of the initiator of the corresponding “ClientHello” (i.e., client device 12), such as the list of available signature algorithms shown above. As confirmed by extensive experiments using various device types, operating systems, and browser types, such lists differ not only in content but also in the order of the listed items between physical devices. Therefore, some embodiments use such lists as a whole (i.e., preserving the original order of the items) as fingerprint features for device identification, as detailed below.

[0060] Figure 8This describes an exemplary TCP header 36 known in the field. Header 36 includes a concatenation of multiple metadata fields, such as source port, destination port, a set of flags / control bits, and an Options field. For example, TCP header flags can be used to set the priority of the current data packet, reset, or complete a connection / session. A specific TCP header flag named SYN is used to mark the packet that initiates a TCP session, i.e., the first step in establishing a connection between the communicating parties. Some embodiments specifically analyze data packets for which their SYN flag is set. The contents of the Options field vary in protocol versions and implementations and are used to extend TCP functionality and / or various optimizations. The Options field may contain multiple subfields. In some embodiments, step 238 ( Figure 4 This includes a fingerprint recognition module 20 that identifies packets with SYN flag groups and extracts the following features from the TCP header of the corresponding packets:

[0061] - A list of option types that indicates the order in which the various subfields of the Option field are listed and the type of each individual option / subfield, for example, {2, 1, 3, 1, 1, 8, 4, 0, 0};

[0062] - Content of specific flags that appear as subfields of the Options field, such as the content of the Explicit Congestion Notification Echo (ECE) and Congestion Window Reduction (CWR) flags;

[0063] - Maximum segment size (a specific subfield of the Options field), for example, 1460;

[0064] - Window scaling (a specific subfield of the Options field), for example, 6.

[0065] Some embodiments again rely on the observation that, because the contents of the Options field in the TCP header are not standardized, such data can vary across different hardware and software implementations of the communication stack, and therefore can be used to identify devices. Consequently, some embodiments use some of the features described above extracted from the TCP header as device fingerprint features, as further described below.

[0066] Figure 9 This section demonstrates exemplary content of HTTP Header 38, as known in the field. Header 38 includes a set of fields, such as cache control fields and user agent fields. The content of some HTTP header fields specifies various capabilities and / or preferences of the browser issuing the corresponding HTTP request, such as what types of documents it can display, what data compression methods it can handle, and how it handles cached data. Exemplary HTTP headers are shown below:

[0067]

[0068] The format and content of HTTP header 38 are not standardized and depend on hardware specifications, operating system type, and the brand and version of the web browser currently running on device 12. For example, as revealed by extensive experimentation, the types of fields included in an HTTP request, and the order in which the corresponding fields appear in the HTTP header, vary across devices. Some embodiments rely on the observation that this variability can be used for device identification. However, some embodiments do not simply rely on the content of individual fields, but instead use the entire HTTP header as a fingerprint feature. For example, in step 238, some embodiments calculate a string feature that includes the concatenation of all fields of HTTP header 38, containing the field names and values ​​in the order listed in the respective headers. In addition to individual field values, this string further captures both the type and order of the header fields in a single fingerprint feature.

[0069] In response to receiving fingerprint detection 24 ( Figure 3 The web browser software running on the client device 12 can interact with the probe 24, for example, by presenting a webpage to the user of the corresponding device notifying them that the fingerprint recognition process is in progress. Then, executing the fingerprint recognition code contained in the probe 24 enables the corresponding web browser to determine a set of device fingerprint data 26 and further transmit the data 26 back to the fingerprint recognition module 20. In step 240 ( Figure 4 In this process, module 20 receives such data from device 12.

[0070] The fingerprint data of the exemplary device extracted from the web browser can contain various features of the browser object model (BOM). Figure 10 This describes a portion of an exemplary BOM 50 according to some embodiments of the present invention. The BOM includes a hierarchical data structure specifying software objects exposed by a browser. The multi-level tree-like data structure includes multiple nodes, each representing a different object or a different attribute of an object. Some nodes represent content displayed by the browser, while other nodes relate to various functional aspects of the browser (e.g., how the browser handles encryption). For example, the document node, as illustrated, may include a tree-like Document Object Model (DOM) specifying the content and appearance of the webpage currently displayed by the corresponding browser window. Some nodes of the BOM have child nodes, i.e., in... Figure 10 This is defined as a node belonging to a lower level of the object hierarchy and connected to its corresponding parent node. Such child nodes represent the object attributes of their parent node, such as properties of the parent node or methods / functions that act on it. Some child nodes may themselves contain complex software objects.

[0071] In some embodiments, the fingerprint recognition code included in probe 24 is configured to construct at least a portion of BOM 50 and parse the corresponding BOM to extract various features characterizing the browser running on client device 12. As revealed by computer experiments, the BOM is not standardized, and therefore its structure and content vary depending on the browser brand and version. In one instance, two smartphones run the same version of the Android® operating system but different versions of the Chrome® browser. Compared to older versions of the BOM, newer versions of the BOM have several additional nodes, such as new properties of the window.navigator node: navigator.Bluetooth, navigator.XRSystem, and navigator.SpeechSynthesis. Therefore, some embodiments explicitly use the BOM for device fingerprint recognition.

[0072] The exemplary fingerprint features identified by BOM 50 include the attribute values ​​of selected BOM nodes, particularly those encoding browser functionality. Specifically, computer experiments have shown that the attributes of the window, navigator, and screen nodes in the BOM are effective in device identification. In contrast, the attribute values ​​of nodes (such as navigation and history) essentially encode the content displayed by the browser and are therefore not reliable device identifiers.

[0073] Another exemplary fingerprint feature includes a text string determined by a recursive traversal of the selected subtrees of the BOM 50. The subtrees in this paper represent selected connected subsets of the nodes of the BOM 50, as shown by... Figure 10 The subtree is illustrated in section 52. A subtree can be selected based on its root node (e.g., all descendants of the navigator node, etc.). Subtrees can be further selected to exclude specific nodes (e.g., the document node) and / or can be further limited in size, such as a maximum tree depth and a maximum tree width. Figure 10 As explained herein, tree depth can be defined as the number of levels of the BOM hierarchy measured from the root of the corresponding subtree. Meanwhile, tree width can represent the count of child nodes at each level of the subtree. Limiting a subtree to a maximum width can include excluding some of the corresponding child nodes from the corresponding subtree when the count of child nodes of a selected node exceeds the maximum width. In some embodiments, recursive traversal of the selected subtree includes enumerating all nodes in the selected subtree listed in a predetermined order, for example, for each selected node, citing its child nodes before moving to another node at the same level as the selected node. Exemplary BOM traversal feature 54 may include an ordered list of node names of the selected subtree 52.

[0074] Other exemplary device features extracted from the code contained in fingerprint detector 24 include a set of fonts available to the browser and a set of media codecs supported by the respective browser. When such data is not included in BOM 50, some embodiments use fingerprint code to determine available fonts through trial and error, for example, by attempting to format text using each of a predetermined set of fonts and determining whether the font is available based on whether the formatting is successful. Similarly, fingerprint detector 24 may contain a simulated media container configured to access using a specific reference media codec. The fingerprint code can then determine whether the browser supports the corresponding codec based on how the browser interprets the content, for example, based on error messages generated by the browser when attempting to access the corresponding media file.

[0075] Another exemplary device feature extracted via fingerprint identification code includes an indicator of the date format used by the corresponding browser and / or client device 12. In one such example, the fingerprint identification code included in probe 24 may instruct the browser to display a reference date and / or time, such as 12:29:04 on May 26, 1999, and record the result as a text string. The format in which the browser displays the date and time depends on the current location (time zone, local cultural preferences) and the preferences of the user of the corresponding device (e.g., between AM / PM and 24h formats, between using month names and numbers, etc.). Therefore, some embodiments use date / time format indicators for device identification purposes.

[0076] Another exemplary device feature extracted from the fingerprint recognition code includes indicators of whether the corresponding browser integrates various third-party application programming interfaces (APIs). Examples of such APIs include online payment APIs, such as Apple Pay® and the W3C Payment Request API. To detect whether the browser supports the corresponding library, some embodiments of the fingerprint detection 24 include calls to selected functions of the corresponding API, and determine the device feature based on the results of attempting the corresponding function calls.

[0077] Other exemplary APIs include network credential management APIs configured to handle user credentials such as passwords. Some embodiments of fingerprinting detection 24 involve calls to API functions, such as attempting to create a set of simulated credentials using a valid reference set of user parameter values ​​(username, public key, etc.). The fingerprinting code can then determine device characteristics including a text string determined based on the result of the attempt. In one such instance, an empty string can indicate success (i.e., the corresponding API is supported), while a non-empty string containing error message content can indicate that the corresponding API is not supported. Computer experiments have shown that the content of such error messages varies across device brands, models, and OS versions, as well as browser brands and versions, and can therefore be used for device identification.

[0078] In another instance, where the features are determined by fingerprinting code executed within the browser, probe 24 may be configured to intentionally cause errors and collect error messages generated by the browser in response to the corresponding errors. For example, probe 24 may contain incorrectly formatted API calls or API calls with invalid parameter values ​​(e.g., out of range, mismatch, etc.). In an exemplary experiment using the Network Credentials Management API, attempting to create a set of credentials using invalid algorithm identifiers generates the error message "NotSupportedError: None of the algorithms specified in 'pubKeyCredParams' are supported by this device." on an Android® smartphone and another error message "NotAllowedError: Operation failed." on an iPhone®. In some embodiments, probe 24 is configured to cause multiple errors and determine a composite fingerprint feature that includes a concatenation of individual error messages generated by the browser in response to each error.

[0079] In some embodiments, in step 242 ( Figure 4 In the fingerprint recognition module 20, the fingerprint recognition module 20 can construct a device fingerprint based on locally extracted features (step 238) and further based on fingerprint data 26 received from the client device 12 (step 240). Figure 11 This section describes an exemplary device fingerprint 60 according to some embodiments of the present invention. The fingerprint 60 includes a data structure comprising a timestamp 62 and a plurality of feature fields 64. The timestamp 62 indicates the time at which the corresponding fingerprint is evaluated. In some embodiments, each feature field 64 corresponds to a different device feature. Let i = 1, ..., N, where N represents the total number of features used to characterize the corresponding device. It includes the characteristics of access request 22 (e.g., characteristics extracted from TLS ClientHello packets, TCP headers, and HTTP headers) and the client browser characteristics (e.g., BOM characteristics) determined by the fingerprint code included in probe 24.

[0080] Some feature fields 64 contain multiple feature values. This includes the corresponding features observed during the fingerprint recognition process. Different values. As mentioned above, due to network optimization and / or routing protocols, and due to encryption, a single access request 22 can be divided into multiple individual packets. Furthermore, some devices can transmit multiple access requests, such as transmitting concurrent access requests to different services and / or locations. Therefore, the fingerprint recognition module 20 can observe the same feature during a single fingerprint recognition session. Multiple values In one instance, two consecutive packets may differ in the contents of the Options field in their TCP headers. Some embodiments may then record two distinct values ​​for the corresponding TCP header characteristics. and Eigenvalues It can be a string, a number, or a more complex data object, depending on the corresponding characteristics. The type. In some embodiments, feature field 64 may further include a count. This indicates that the corresponding feature value was encountered during the corresponding fingerprint recognition process / session. The number of times.

[0081] In some embodiments, the fingerprint recognition module 20 maintains a fingerprint database 44 that associates client devices with device fingerprints. For example, the database 44 may include a set of records, each different record including an identifier of the client device and a set of device fingerprints calculated for the corresponding device. (The above refers to...) Figure 1 The client access database 42 describes exemplary device identifiers. In some embodiments, database 44 maintains multiple device fingerprints calculated for a given device, each fingerprint being calculated at a different time. Some embodiments utilize, for example... Figure 12 The moving fingerprint retention window described herein refers to the gradual discarding of fingerprints older than a predetermined maximum age from database 42 or their removal from fingerprint similarity calculations as described below.

[0082] In the sequence of steps 248 to 250, the fingerprint recognition module 20 may further determine whether the device fingerprint (referred to herein as the target fingerprint) determined in step 242 is similar to the previously determined device fingerprint. Therefore, step 242 may include selecting a record from the database 44 and a reference fingerprint associated with the selected record, and determining a similarity metric that quantifies the degree of similarity between the target fingerprint and the reference fingerprint.

[0083] A demonstrative similarity measure is determined based on the following:

[0084]

[0085] Where i is the index of the device features, and N represents the count of different features i. Indicates features in the reference fingerprint All observations The set, Representing features in the target fingerprint All observations The set (see example) Figure 11 (and related descriptions above), Describes the union of sets. Denotes the set difference, and The cardinality is represented by the count of elements in the corresponding set. Intuitively, equation [1] estimates how many values ​​of a device feature appear in the target fingerprint or the reference fingerprint (but not both), and averages the estimate by dividing the set of features by the fingerprint count in the fingerprint retention window. When the set and When the sets contain essentially the same values, S is relatively large (close to 1), and when the set contains essentially the same values... and When there are significant differences, S is relatively small (close to 0).

[0086] Alternative similarity measures can be determined based on the following:

[0087]

[0088] Where i is the index of the device features, and N represents the count of different features i. Represents a set and union, Features observed in the reference fingerprint The number of times the value w is counted, and Features observed in the target fingerprint The number of times the value w is counted. Intuitively, when the number of times the same value w is observed in both the reference and target fingerprints is approximately the same, the similarity measure determined by equation [2] is relatively large (close to 1), and otherwise relatively small (close to 0).

[0089] Some embodiments further divide the similarity value by the fingerprint retention window, that is, by averaging multiple reference fingerprints evaluated for the same selected device at different recent times:

[0090]

[0091] The T index retains the corresponding reference fingerprint within the window. A set of numerical weights. , making It can be used to emphasize the recent importance of older reference fingerprints.

[0092] In some embodiments, step 250 ( Figure 4This includes comparing a determined similarity metric S with a predetermined threshold and determining, based on the comparison, whether the device currently undergoing fingerprint recognition is familiar. For example, some embodiments may determine that the device currently being fingerprinted is familiar when S exceeds a threshold. The threshold can be determined experimentally; some exemplary values ​​of S determined for real devices are further given below.

[0093] When the device under test is deemed familiar (step 250 returns "Yes"), in step 252, module 20 can update the existing database record of the corresponding device by adding the currently determined fingerprint to the corresponding record. Therefore, step 252 may include determining the identifier of the device currently being fingerprinted based on a determined similarity metric. For example, in response to determining that the similarity between the target fingerprint and the reference fingerprint exceeds a threshold, some embodiments may determine that the device currently being fingerprinted is actually the same as the device characterized by the reference fingerprint. Therefore, some embodiments may use the same device identifier associated with the reference fingerprint to identify the current device.

[0094] When step 250 returns no, indicating that no reference device has a fingerprint sufficiently similar to the target fingerprint, some embodiments conclude that the device currently being identified is unfamiliar / a previously unseen device. Therefore, step 254 may create a new record for the corresponding device and insert the newly created record into the fingerprint database 44. Creating a new database record may include calculating a device identifier for the corresponding device and associating the new device identifier with the target fingerprint.

[0095] In another step 256, the fingerprint recognition module 20 may transmit the recognition report 26 to the network device 14 (see [link]). Figure 3 In some embodiments, report 26 includes a device identifier for the corresponding client device, i.e., an identifier familiar to the device or a new identifier calculated in step 254. Identification report 26 may further include a device fingerprint recently determined for the corresponding device.

[0096] Figure 12 Exemplary hardware configurations of a computer system 80, programmed to perform some of the methods described herein, are shown. Computer system 80 typically represents... Figure 1 Any client devices 12a to d, as well as fingerprint recognition server 40 and network device 14. The described devices are personal computers; other devices such as servers, mobile phones, tablet computers and wearable devices may have slightly different configurations.

[0097] Processor 82 includes physical means (e.g., a microprocessor, i.e., a multi-core integrated circuit formed on a semiconductor substrate) configured to perform computational and / or logical operations with a set of signals and / or data. Such signals or data may be encoded in the form of processor instructions (e.g., machine code) and delivered to processor 82.

[0098] Memory unit 84 may include volatile computer-readable media (e.g., dynamic random access memory - DRAM) that stores data / signals / instructions encoded by processor 82 during the execution of operations. Input device 86 may include a computer keyboard, mouse, microphone, etc., and includes corresponding hardware interfaces and / or adapters that allow users to introduce data and / or instructions into computer system 80. Output device 88 may include a display device such as a monitor and speakers, and hardware interfaces / adapters such as a graphics card, enabling the corresponding computing device to communicate data to the user. In some embodiments, input and output devices 86 to 88 share a common piece of hardware (e.g., a touchscreen). Storage device 92 includes non-volatile computer-readable media that implements the storage, reading, and writing of software instructions and / or data. Exemplary storage devices include magnetic disks and optical disks, flash memory devices, and removable media such as CDs and / or DVDs and drives. Network adapter 94 includes components that enable computer system 80 to connect to electronic communication networks (e.g., Figure 1 Network 15) and / or other dedicated hardware for computer systems.

[0099] Controller hub 90 typically represents multiple systems, peripheral devices, and / or chipset buses and / or all other circuitry that enables communication between processor 82 and the remaining hardware components of computer system 80. For example, controller hub 90 may include memory controllers, input / output (I / O) controllers, and interrupt controllers. Depending on the hardware manufacturer, some of these controllers may be incorporated into a single integrated circuit and / or integrated with processor 82. In another example, controller hub 90 may include a northbridge connecting processor 82 to memory 84 and / or a southbridge connecting processor 82 to devices 86, 88, 92, and 94.

[0100] The exemplary systems and methods described above enable efficient device identification for applications such as access control and targeted content distribution.

[0101] In an exemplary use case scenario, a network device (e.g., a router) provides access control services for a collection of electronic devices belonging to a household. The router could enforce parental control policies, for example, by disallowing access to specific categories of online content (e.g., adult content, gambling websites, etc.) by a particular smartphone typically used by children. However, these smartphones may occasionally leave the room and thus disconnect from the local network. When the device returns, the router must automatically identify it to apply the correct access policy to avoid a cumbersome network reconfiguration process.

[0102] Such automatic identification is hampered by several factors, such as the increasing use of privacy-enhancing strategies like MAC address randomization, where devices can expose different MAC addresses to network regulators when attempting to join a network individually. In other words, MAC addresses are increasingly becoming unreliable device identifiers. Another factor complicating device identification is the frequent software updates and installations of new software on modern electronic devices, which subtly and effectively alter their behavior. Even updates to non-essential software (such as web browsers) can change how a device communicates with the outside world.

[0103] Some conventional device identification methods categorize devices into relatively broad groups based on device type and operating system. One exemplary method of this kind could identify the smartphone in the example above as a Samsung® Galaxy® S21 running Android® version 13. However, such methods might not be able to distinguish between two identical smartphones, one used by the child and the other by her mother.

[0104] Some more sophisticated methods identify a device based on communications received from it. One example analyzes the 'User-Agent' field of HTTP requests issued by the corresponding device. However, as the browser undergoes updates, the content of this field may change, and the corresponding device may no longer appear familiar.

[0105] Some embodiments of the present invention directly address such technical problems by: determining a device fingerprint of a target device and determining whether the target device is the same as a familiar reference device by comparing the device fingerprint with a reference fingerprint determined for a reference device. In other words, some embodiments identify a device by comparing it with a known device and determining whether the two devices are the same.

[0106] The device fingerprint calculated as disclosed herein includes multiple (approximately 10 to 100) different device features, which are combined with features extracted from intercepted access requests issued by the respective device and features extracted from fingerprint identification probes (e.g., forced portals) performed on the respective device.

[0107] Exemplary features extracted from access requests include features determined based on the content of the TLS “Client Hello” handshake message, the content of the TCP header, and / or the content of the HTTP header of the intercepted data packet. Some embodiments preferentially extract features from the 'Extensions' field of the HTTP header and / or the 'Options' field of the TCP header, based on the observation that such fields are not standardized and therefore may vary significantly across different device types, operating systems, and browser models, allowing for reliable device identification.

[0108] Other exemplary fingerprint feature sets characterize the browser executing on the corresponding device. These features are extracted via code (e.g., JavaScript®) contained within the fingerprint detection / enforcement portal. Instances contain the contents of the corresponding browser's Browser Object Model (BOM), which, based on the observation that the BOM is not standardized, varies significantly in content and structure across different browser brands and versions.

[0109] By combining a relatively wide range of device features into a single fingerprint, some embodiments achieve reliable device identification, particularly addressing the problem of software updates. In some embodiments, different parts of the device fingerprint are sensitive to different types of updates. For example, an update to browser software or the installation of a new application may affect the features of the BOM and HTTP headers, but is unlikely to affect TCP header metadata. Conversely, an OS update may affect changes to the network stack and thus affect the features extracted from the TCP headers, while keeping the BOM features unchanged. Therefore, compared to conventional methods using a minimal set of features, in some embodiments of the invention, a single software update is relatively unlikely to change the device fingerprint to the extent that it leads to misidentification. Furthermore, the types of features included in the device fingerprint enable efficient differentiation of a device from other devices.

[0110] Some of the device identification procedures described herein can be further applied to computer security, such as in combating hacking attacks. One exemplary intrusion method involves deception, where a rogue device masquerades as a legitimate device (e.g., by using its MAC address) to gain access to a target network and / or resources. Access control systems implementing device fingerprinting according to some embodiments of the invention will be likely to detect intrusive devices because their device fingerprints contain significantly more than a MAC address and are therefore likely to be quite different from the device fingerprints of legitimate devices. Furthermore, the type of device features contained in the fingerprint are considerably difficult to forge without a deep understanding of the device being imitated.

[0111] To illustrate some of the methods described herein, a series of computer experiments were performed on a test setup consisting of mobile phones of various brands and models. Device 1 was a Huawei® P smartZ running Android® 10. Device 2 was a Google® Pixel® 5a running Android® 13. Device 3 was a Google® Pixel® 6 running Android 13. Device 4 was a Samsung® Galaxy® S22 running Android® 13. Devices 5 and 6 were the same examples of Apple® iPhones running iOS® 16.6.

[0112] Device fingerprints include features extracted from TCP headers, TLS handshakes, HTTP headers, BOM strings, available font groups, date formatting, and attributes of the 'window', 'navigator', and 'screen' nodes in the BOM. Test devices were repeatedly fingerprinted over an extended period, during which some devices received various types of updates, while others did not.

[0113] Tables 1 and 2 show the device similarity metrics calculated for the test device using versions of equations [1] and [2], respectively.

[0114] Table 1

[0115]

[0116]

[0117] Table 2

[0118]

[0119] The test results above demonstrate that the two methods for assessing device similarity are qualitatively similar, because self-similarity measures (i.e., the similarity between different fingerprints determined for the same device) are generally significantly greater than inter-device similarity. This shows that the method described in this paper can be reliably used for device identification, and in particular for distinguishing between iOS® and Android® devices.

[0120] The observed self-similarity metric is not exactly equal to 1.0 as one might expect when comparing a device to itself. The slight deviation from 1.0 may be due to differences in network parameters (e.g., congestion) between the two corresponding fingerprinting sessions, and changes in various characteristics of the corresponding devices during the time elapsed since the most recent fingerprinting. The most significant changes occurred in devices 2 and 6, which underwent operating system upgrades immediately prior to their most recent fingerprint evaluations. Notably, even these fundamental changes, which could affect both network stack software and browser characteristics, did not cause the self-similarity metric determined for the corresponding devices to drop below 0.8. This observation illustrates the advantage of using a large number of device features (including features extracted from access requests and features characterizing the browser), as using a larger number of features and a more diverse set of features may mitigate the impact of updates.

[0121] A slight anomaly was observed in devices 5 and 6, where the self-similarity of device 6 was less than the similarity between devices 5 and 6. This could cause network device 14 to mistakenly identify device 6 as device 5 and thus apply an incorrect access policy. However, the observed situation may be accidental and temporary. After an operating system update, fingerprinting of device 6 was performed again, and the self-similarity increased from 0.844 to 1.0, while the cross-similarity between devices 5 and 6 decreased from 0.880 to 0.770, thus achieving correct identification of the corresponding device.

[0122] To further illustrate the advantages of using a relatively large and diverse set of device features when computing device fingerprints, Table 3 shows the similarity measure calculated using the same fingerprint recognition examples as those used in Tables 1 and 2, but only using device features extracted through fingerprint recognition probe 24 (e.g., forced portal method):

[0123] Table 3

[0124]

[0125] The test results shown in Table 3 are qualitatively similar to those in Tables 1 and 2, as the self-similarity score is significantly higher than the inter-device similarity score, allowing for reliable device identification. This demonstrates the ability of some browser features (such as BOM traversal strings and forced error messages) to distinguish between devices. However, the observed variability of the self-similarity measure is much greater than that shown in Tables 1 and 2, which could lead to unexpected misidentification.

[0126] Those skilled in the art will understand that the embodiments described above can be modified in many ways without departing from the scope of the invention. Therefore, the scope of the invention should be determined by the appended claims and their legal equivalents.

Claims

1. A computer system including at least one hardware processor, said at least one hardware processor being configured to: In response to receiving an access request from a client device, a fingerprint detection is transmitted to the client device, the fingerprint detection including computer code configured to determine a first set of characteristic values ​​representing a browser executing on the client device; Receive the first set of feature values ​​from the client device; A second set of characteristic values ​​representing the client device is determined based on the metadata of the access request; The device fingerprint of the client device is determined based on the first and second sets of feature values; Determine a similarity measure that quantifies the similarity between the device fingerprint and a reference fingerprint characterizing the reference device; and In response, if the similarity metric indicates that the client device is the same as the reference device, then the device identifier of the client device is set to be equivalent to the device identifier of the reference device.

2. The computer system of claim 1, wherein the access request includes a request for access to a remote resource, and wherein the at least one hardware processor is further configured to, in response to determining the device identifier, transmit the device identifier of the client device to a network device configured to control the client device's access to the remote resource based on the device identifier.

3. The computer system of claim 1, wherein the computer code is configured to: Construct a selected subtree of a browser object model (BOM) comprising a hierarchical representation of a set of software objects exposed by the browser; Construct an ordered list of node names that includes the names of all nodes in the selected subtree; and The ordered list containing node names in the first set of feature values.

4. The computer system of claim 3, wherein the selected subtree is selected to include the 'navigator' node or 'screen' node of the BOM.

5. The computer system of claim 1, wherein the computer code is configured to determine a set of attributes of a selected node of a browser object model (BOM) comprising a hierarchical representation of a set of software objects exposed by the browser, and wherein the first set of feature values ​​includes the set of attributes.

6. The computer system of claim 5, wherein the selected node comprises a 'navigator' node or a 'screen' node.

7. The computer system of claim 1, wherein the computer code is configured to intentionally cause an error in the browser, and the first set of features is determined based on the content of an error message generated by the browser in response to the error.

8. The computer system according to claim 1, wherein determining the second set of feature values ​​includes: Determine whether the access request includes a Transport Layer Security (TLS) handshake message; and In response, if so, the second set of feature values ​​is determined based on the content of the 'Extensions' field in the TLS handshake message.

9. The computer system according to claim 1, wherein determining the second set of feature values ​​includes: The packet that includes a portion of the access request is selected based on whether the SYN flag in the packet's Transmission Control Protocol (TCP) header is set. and In response, the second set of feature values ​​is determined based on the contents of the 'Options' field in the TCP header.

10. The computer system according to claim 1, wherein: The access request includes multiple data packets; and The at least one hardware processor is configured to determine the similarity measure based on the number of times the selected feature values ​​of the second set of feature values ​​occur within the plurality of data groups.

11. The computer system of claim 1, wherein the at least one hardware processor is configured to determine the similarity metric according to: ， Where V represents the first or second set of feature values, and U represents the third set of feature values ​​characterizing the reference device. Denotes the set difference, and This represents the element count of the corresponding set.

12. A computer-implemented method comprising employing at least one hardware processor of a computer system to: In response to receiving an access request from a client device, a fingerprint detection is transmitted to the client device, the fingerprint detection including computer code configured to determine a first set of characteristic values ​​representing a browser executing on the client device; Receive the first set of feature values ​​from the client device; A second set of characteristic values ​​representing the client device is determined based on the metadata of the access request; The device fingerprint of the client device is determined based on the first and second sets of feature values; Determine a similarity measure that quantifies the similarity between the device fingerprint and a reference fingerprint characterizing the reference device; and In response, if the similarity metric indicates that the client device is the same as the reference device, then the device identifier of the client device is set to be equivalent to the device identifier of the reference device.

13. The method of claim 12, wherein the access request includes a request for access to a remote resource, the method further comprising, in response to determining the device identifier, transmitting the device identifier of the client device to a network device configured to control the client device's access to the remote resource based on the device identifier.

14. The method of claim 12, wherein the computer code is configured to: Construct a selected subtree of a browser object model (BOM) comprising a hierarchical representation of a set of software objects exposed by the browser; Construct an ordered list of node names that includes the names of all nodes in the selected subtree; and The ordered list containing node names in the first set of feature values.

15. The method of claim 14, wherein the selected subtree is selected to include the 'navigator' node or 'screen' node of the BOM.

16. The method of claim 12, wherein the computer code is configured to determine a set of attributes of a selected node of a browser object model (BOM) comprising a hierarchical representation of a set of software objects exposed by the browser, and wherein the first set of feature values ​​includes the set of attributes.

17. The method of claim 16, wherein the selected node comprises a 'navigator' node or a 'screen' node.

18. The method of claim 12, wherein the computer code is configured to intentionally cause an error in the browser, and the first set of features is determined based on the content of an error message generated by the browser in response to the error.

19. The method of claim 12, wherein determining the second set of feature values ​​comprises using the at least one hardware processor to: Determine whether the access request includes a Transport Layer Security (TLS) handshake message; and In response, if so, the second set of feature values ​​is determined based on the content of the 'Extensions' field in the TLS handshake message.

20. The method of claim 12, wherein determining the second set of feature values ​​comprises using the at least one hardware processor to: The packet that includes a portion of the access request is selected based on whether the SYN flag in the packet's Transmission Control Protocol (TCP) header is set; and In response, the second set of feature values ​​is determined based on the contents of the 'Options' field in the TCP header.

21. The method according to claim 12, wherein: The access request includes multiple data packets; and The method includes determining the similarity measure based on the number of times the selected feature values ​​of the second set of feature values ​​occur within the plurality of data groups.

22. The method of claim 12, further comprising determining the similarity metric based on: ， Where V represents the first or second set of feature values, and U represents the third set of feature values ​​characterizing the reference device. Denotes the set difference, and This represents the element count of the corresponding set.

23. A non-transitory computer-readable medium storing instructions that, when executed by at least one hardware processor of a computer system, cause the computer system to: In response to receiving an access request from a client device, a fingerprint detection is transmitted to the client device, the fingerprint detection including computer code configured to determine a first set of characteristic values ​​representing a browser executing on the client device; Receive the first set of feature values ​​from the client device; A second set of characteristic values ​​representing the client device is determined based on the metadata of the access request; The device fingerprint of the client device is determined based on the first and second sets of feature values; Determine a similarity measure that quantifies the similarity between the device fingerprint and a reference fingerprint characterizing the reference device; and In response, if the similarity metric indicates that the client device is the same as the reference device, then the device identifier of the client device is set to be equivalent to the device identifier of the reference device.

Images