Systems and methods for authenticating user identity based on event chains

Abstract

To provide systems and method for verifying user identity based on a chain of events.SOLUTION: A method comprises: receiving sensor data from at least one sensor; parsing the sensor data to determine a plurality of identifiers of a user authorized to access data via a computing device; generating, for each identifier, an event including the user; intercepting, on the computing device, a data access request including an identifier of the user; verifying whether the data access request is from the user authorized to access data; generating a chain of events for a period of time preceding the data access request; determining a deviation from a target chain of events; and in response to determining the deviation is less than a threshold deviation value, granting the data access request.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present disclosure relates to the field of data security, and more particularly to a system and method for authenticating a user identity based on a chain of events. [Background technology]

[0002] Traditional approaches to identifying users of a system involve verifying the entered username and password. However, this approach does not address a key security problem, as it does not authenticate whether the input is being provided by an authorized person and not a representative. To address this, different parameters such as physical objects (e.g., ID cards) or biometrics (e.g., fingerprints, iris scans, facial recognition, etc.) may be used for authentication and verification. However, even these measures can be circumvented. For example, an unauthorized person may steal an ID card or forge a fingerprint. Summary of the Invention [Means for solving the problem]

[0003] To address these shortcomings, aspects of the present disclosure describe methods and systems for authenticating user identity based on event chains.

[0004] In one exemplary aspect, a method includes receiving sensor data from at least one sensor in an environment. The method includes parsing the sensor data to determine a plurality of identifiers of users authorized to access data via a computing device. The method includes, for each identifier of the plurality of identifiers, generating an event including the user, each event including a respective timestamp. The method intercepts a data access request including an identifier of a user authorized to access data on the computing device. The method includes authenticating whether the data access request is from a user authorized to access data, wherein the authenticating includes generating an event chain for a time period preceding the data access request, the event chain including a plurality of generated events ordered based on each respective timestamp and including the user; determining a deviation of the event chain from a target event chain indicative of authorized access by the user; and, in response to determining that the deviation is less than a deviation threshold, authenticating that the data access request is from the user and granting the data access request.

[0005] In some aspects, the method includes, in response to determining that the deviation is not less than the deviation threshold, not authenticating the data access request as being from the user and blocking the data access request.

[0006] In some aspects, the data access request is a first data access of a plurality of data accesses, and the method includes identifying the target event chain by determining that the target event chain is a target event chain of the first data access.

[0007] In some aspects, the first data access is from a computing device fixed at a particular location, and the target event chain indicates the progress of a user entering the particular location and accessing the computing device.

[0008] In some aspects, the first data access is an access from a portable computing device and the target event chain indicates the progress of a user performing actions on the computing device to initiate the data access request.

[0009] In some aspects, the offset is a function of the event order and the amount of time allocated to each event.

[0010] In some aspects, each respective event in the target event chain is assigned a weight that indicates the importance of the respective event.

[0011] In some aspects, the target event chain is a historical event chain executed by the user prior to the previous data access.

[0012] In some aspects, the method includes identifying a discrepancy in the sequence of the event chain that indicates the user does not have physical access to the computing device, and not authenticating the data access request and blocking the data access request.

[0013] It should be noted that the above-described method may be implemented in a system including a hardware processor. Alternatively, the method may be implemented using computer-executable instructions on a non-transitory computer-readable medium.

[0014] The foregoing simplified summary of exemplary embodiments serves to provide a basic understanding of the present disclosure. This summary is not an extensive overview of all possible embodiments, and is not intended to identify key or critical elements of all embodiments or to delineate the scope of any or all embodiments of the present disclosure. Its sole purpose is to present one or more embodiments in a simplified form as a prelude to the more detailed description of the present disclosure that follows. To accomplish the foregoing, one or more embodiments of the present disclosure comprise the features recited and illustratively pointed out in the claims.

[0015] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one or more exemplary aspects of the disclosure and, together with the detailed description, serve to explain the principles and implementations thereof. [Brief explanation of the drawings]

[0016] [Figure 1] FIG. 1 illustrates a chain of events detected by a security system for data access on a device fixed at a specific location.

[0017] [Figure 2] FIG. 1 illustrates a chain of events detected by a security system for data access on a mobile device.

[0018] [Figure 3] FIG. 1 is a block diagram illustrating a system for authenticating a user identity based on an event chain.

[0019] [Figure 4] 1 illustrates a flow diagram of a method for authenticating a user identity based on an event chain.

[0020] [Figure 5] 1 illustrates a flow diagram of a method for identifying inconsistencies in an event chain.

[0021] [Figure 6] An example of a general-purpose computer system on which aspects of the present disclosure can be implemented is provided. DETAILED DESCRIPTION OF THE INVENTION

[0022] Exemplary aspects are described herein in the context of systems, methods, and computer program products for authenticating user identity based on event chains. Those skilled in the art will understand that the following description is merely illustrative and is not intended to be limiting in any way. Other aspects will readily suggest themselves to those skilled in the art having the benefit of this disclosure. Reference will now be made in detail to implementations of exemplary aspects, which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers are used throughout the drawings and the following description to refer to the same or similar items.

[0023] User identity is often authenticated in a vacuum. For example, a security system may require only a finite number of inputs from a user to authenticate whether the user is, in fact, an "authorized" user. If the user can provide the input (e.g., a password, a one-time access code, etc.), the user is granted access. However, as previously mentioned, evaluating inputs in a vacuum facilitates unauthorized access. For example, even if a security system requires a one-time access code in addition to a password, an unauthorized person could gain access to a device that receives the one-time access code (e.g., a smartphone belonging to an authorized user) and potentially circumvent the security system.

[0024] Furthermore, the additional inputs make accessing data inconvenient for the actual user. For example, if a security system requires multiple access codes from different devices or multiple biometric data (e.g., face scan, fingerprint, etc.), the authentication process becomes cumbersome. Ideally, to address these issues, a non-invasive and dynamic security system is needed. The physical environment is a crucial tool for creating such a security system.

[0025] This disclosure describes using various external data points and events in the physical world to build a specific picture of reality that is consistent with other objects or events. Therefore, a missing link in this system or chain of events can be evaluated as an attempt at unauthorized access or attack by an intruder. For example, when a user logs into a computer system at work, the login process must be preceded by a series of physical actions and events, such as the user entering the office building, calling an elevator, pressing a button for the desired floor, and entering a room. If, for some reason, at least one action is not detected, the login may be an attempt to break into the system.

[0026] From a bird's-eye view, implementations may include identifying different scenarios based on a particular situation (e.g., verifying that a person is physically present), identifying a set of events associated with the particular situation (e.g., entering a building, moving up from the bottom floor, entering a room, etc.), identifying the sequence of these events (e.g., event A always precedes event B, event C can occur both before and after event B, etc.), and determining the significance (e.g., a weight indicating significance) of the absence or change in the sequence of certain events.

[0027] FIG. 1 illustrates an event chain 100 detected by a security system for data access at a device fixed to a particular location. A person 104 may enter an office building, and the act of entering may be captured by a sensor 106a (e.g., a security camera). To enter their physical office, the person 104 may need to enter an access code or swipe their ID badge. A sensor 106b receives these credentials. As shown in FIG. 1, the person 104 may enter an access code at the sensor 106b to enter the office 324. The person 104 may then sit at their desk and access a computing device 108 (e.g., a workstation consisting of a computer or laptop). The sensor 106c may be another camera that captures video of the person 104. In some aspects, the sensor 106c may be integrated into the computing device 108. For example, the sensor 106c may be a camera on the computing device 108 that performs a facial scan. The person 104 may then enter login credentials into the portal 110 to access the data.

[0028] Each of these actions may be identified as an event in the plurality of events 102. Note that the sequence of the plurality of events 102 (also called an event chain) is important. For example, if event 102d occurs before event 102a (i.e., a user accesses data on a computing device 108 before person 104 enters the building), then even if the login credentials are valid, there is a high probability that the user accessing the data does not have access to the data. Similarly, if event 102c occurs before event 102b, then there is a high probability that the user accessing the data has somehow fooled the sensors.

[0029] 2 illustrates an event chain 200 detected by a security system for data access on a mobile device. In event chain 200, event 202a may include a person 204 powering on a computing device 206 and entering a password or providing a biometric parameter (e.g., a fingerprint, a facial image) from a sleep state. Computing device 206 may be a smartphone. Event 202b includes person 204 performing action 208a (e.g., swiping) on ​​the interface of computing device 206. Event 202c includes person 204 performing action 208b (e.g., launching an application). Event 202d includes person 204 performing action 208c (e.g., entering login credentials into an application).

[0030] Note that this sequence may be a routine way for person 204 to access data on a particular application. Assume different chains of events. For example, event 202a (i.e., starting computing device 206) occurs multiple times because the user continues to provide an incorrect password. Assume event 202b also occurs multiple times because the user cannot find the application. These additional events suggest that unauthorized access has occurred and that login should be prevented regardless of whether the login credentials are correct.

[0031] 3 is a block diagram illustrating a system 300 for authenticating user identity based on an event chain. The system 300 includes a computing device 302 (which may be computing device 108 or computing device 206). In some aspects, the computing device 302 executes a security module 306 to authenticate the user identity. In other aspects, the security server 318 executes a thick client application of the security module 306 (e.g., determines whether to allow or block access), and the computing device 302 executes a thin client application of the security module 306 (e.g., receives a score from the thick client and enables or blocks access). In some aspects, the security module 306 is a component of a firewall application.

[0032] Security module 306 may communicate with multiple sensors 304, which may be distributed in the physical environment around computing device 302. For example, sensor 304a may be sensor 106a, sensor 304b may be sensor 106b, sensor 304c may be sensor 106c, and sensor 304N may be an embedded sensor within computing device 302 (e.g., a touchscreen).

[0033] The security module 306 includes multiple components, such as a data parser 308 that acquires information from multiple sensors 304 and converts the information into a format compatible with the event linking module 310. The event linking module 310 identifies authorized individuals associated with the computing device 302 and tracks their presence in the parsed data provided by the data parser 308. In particular, the event linking module 310 generates an event chain that includes the authorized user. The authentication module 316 is configured to determine whether the authorized user is the user who requested data access. In some aspects, the authentication module 316 utilizes data in the historical event database 312 to determine whether a historical event chain performed by the authorized user matches a current event chain. In some aspects, the authentication module 316 utilizes data in the event mapping database 314 to identify discrepancies in a current event chain relative to an expected event chain (which may be derived from the historical event database 312). Using the event mapping database 314, the security module 306 may identify which events are missing in the current event chain, the length of time it takes each event to occur, and the importance of the events (e.g., the weight of the events).

[0034] In an exemplary aspect, security module 306 detects a login attempt to access an application or data on computing device 302 listed in protected data identifier 320. For example, security module 306 may intercept login credentials entered into computing device 302 for an email client, and may include the name of the email client in identifier 320. In some aspects, security module 306 receives notification (e.g., from a web application to which the login credentials were provided) whether the login credentials are correct. In response to receiving the notification, security module 306 determines whether the user who provided the login credentials is an authorized user of the application and / or computing device 302.

[0035] In some embodiments, login credentials do not need to be provided to initiate security module 306. Security module 306 may intercept any attempt to access protected data. For example, a user may attempt to access a folder called "My Documents," and security module 306 may intercept the action and prevent access until the user's identity has been authenticated.

[0036] The security module 306 then obtains an identifier for the user based on the intercepted information (e.g., the login credentials). For example, the security module 306 may obtain a username from the login credentials. The security module 306 then obtains all other identifiers for the user available in authorized user identifiers 322. The other identifiers may be biometric data (e.g., a facial image, a fingerprint scan, etc.), an alternative username, an access code, a badge, personal information (e.g., an address, a phone number, etc.), or any other information unique to a particular user.

[0037] The security module 306 (particularly the event linking module 310) retrieves information captured within a certain period of time from the data parser 308. This information may be associated with all of the retrieved identifiers and stored in the historical events database 312. This information may include video of an individual (e.g., clips tagged using facial recognition, i.e., clips captured by sensor 106a or sensor 106c), access code entry records at a particular sensor (e.g., a PIN code provided on sensor 106b), fingerprint entry records, badge scan entries, etc. This information may be divided into multiple events, and each event may have at least one timestamp associated with it. For example, a video clip may be used to generate an event, and the video clip may have multiple timestamps indicating when the video clip started and ended.

[0038] The data parser 308 may continuously receive information from multiple sensors 304 and store the parsed data as events in the historical event database 312. For example, sensor 304a may send a video stream / clip to the data parser 308. The data parser 308 may utilize computer vision techniques and / or machine learning algorithms (e.g., image classifiers) to identify individuals in the video stream and assign identifiers to the individuals. For example, if a person is present in a video clip, the data parser 308 may identify that person based on common images (e.g., matching facial images) in authorized user identifiers 322 and generate an event indicating that the person was in the video within a specific time period (e.g., Monday 10:00 AM to Monday 10:01 AM EST). If the sensor that captured the video is associated with a specific location (e.g., the entrance to an office building), the data parser 308 may further include location information in the event. Thus, an event generated by data parser 308 from data captured by sensor 304a may indicate that a person was located at the office entrance from 10:00 AM on Monday to 10:01 AM on Monday, Eastern Standard Time.

[0039] The event linking module 310 can thus access multiple events in the historical event database 312 without having to initiate a parsing process after receiving login credentials or a data access request. This accessibility minimizes delays for authorized users to access the data they want to access. The event linking module 310 retrieves all events within a time period (e.g., a day) associated with the authorized user. If no events are available within that time period, the data request is likely malicious. For example, if a data request is made at the computing device 108 and no events indicating the presence of a person 104 (i.e., an authorized user) are found in the historical event database 312, the authentication module 316 may determine that the data access request should be blocked.

[0040] The historical event database 312 may be organized based on authorized user identifiers. This allows for fast and efficient searches through the historical event database 312. Additionally, each event may be in a compact format (e.g., multiple characters) to minimize the size of the historical event database 312. In some aspects, events may be deleted if they are not accessed beyond a threshold period of time. For example, events older than one week may be deleted. In some aspects, events generated by the data parser 308 are only associated with authorized users of the computing device 302 or applications stored on the computing device 302. Thus, if a person is identified in video captured by the sensor 304a and that person is not an authorized user of the computing device 302 or an application (e.g., an email client) on the computing device 302, the event is not recorded.

[0041] The event linking module 310 generates an event chain by organizing each of the captured events associated with an authorized user based on a timestamp. For example, the event linking module 310 may generate an event chain 100 including events 102a, 102b, 102c, and 102d.

[0042] The authentication module 316 is configured to determine whether data access should be granted based on the event chain. The authentication module 316 may refer to the event mapping database 314. The event mapping database 314 may include multiple target event chains of events that indicate authorization to access the requested data. An exemplary target event chain may be stored as follows: [Table 1]

[0043] This example shows that to request a particular type of data, the following events must be detected for an authorized user: entering the building, entering the office, accessing a computing device, and providing login credentials. The order is defined by sequence numbers. In some aspects, certain events may have multiple sequence numbers, indicating that certain events may occur in different orders. The action time represents the time difference between an event and the previous event. For example, the time difference between event 1 and event 2 is at most 5 minutes. This indicates that the action time of the event of entering the office is at most 5 minutes after entering the building.

[0044] In some embodiments, these target values ​​may be set based on historical behavior data of authorized users. For example, based on the authorized user's daily habits, it may be determined that the authorized user never spends more than five minutes traveling from the building entrance to the office entrance. In other embodiments, these target values ​​may be predetermined based on population studies. In the latter case, the target event chain is applicable to any authorized user. In the former case, the target event chain is tailored to a specific authorized user.

[0045] The validation module 316 then compares the determined event chain 100 with the target event chain. In particular, the validation module 316 determines whether the sequence is correct, whether any events are missing, and / or the difference between the respective operation times in each chain. Each chain may be formatted as a data structure. For example, the event chain 100 may look like this: [Table 2]

[0046] In some embodiments, the authentication module 316 executes an algorithm that is a function of sequence number and / or action time. The algorithm may result in a quantitative or qualitative output that the authentication module 316 compares to a threshold. For example, the authentication module 316 may compare sequence values. For each event, if the sequence values ​​are the same, the output is 0. If the sequence values ​​are different, the output is 1. The authentication module 316 may then evaluate the action time. If the time difference in the determined event chain is within the action time in the target event chain, the output is 0. If it is outside the action time, the output is a function of the time difference. The authentication module 316 may then combine the outputs and apply a weight. An example function is shown below: Deviation = |Σ(sequence number difference at event i + time difference at event i) * weight at event i| Here, the deviation for event chain 100 is |[(1-1)+(0)]×1.5+[(2-2)+(0)]×1.2+[(3-3)+(0)]*1+[(4-4)+(0)]×1|=0.

[0047] Suppose an event is missing, say a user does not enter the office. The deviation is: |[(0-1)+(0)]×1.5+[(1-2)+(0)]×1.2+[(2-3)+(0)]×1+[(3-4)+(0)]×1|=1.5+1.2+1+1=4.7.

[0048] If the threshold for comparing this value is 3, the authentication module 316 may determine that in the first instance, the user should be allowed access, and in the second instance, the user should not be allowed access.

[0049] In some aspects, the threshold for comparison is specific to a given target event chain, while in other aspects the threshold is universal and applies to all target event chains.

[0050] It should be noted that the authentication module 316 may compare the determined event chain to one or more target event chains. The authentication module 316 may specifically narrow down the target event chains for these comparisons based on the type of data access request being made. The type of data access request may be based on the computing device being used. For example, some computing devices are fixed to a particular location while others are portable. The type of data access request may also be based on the application being accessed. For example, logging in to a video streaming application may be associated with a different context than logging in to a work-related application.

[0051] For example, in the case of event chain 200, authentication module 316 may determine that the data request occurred on a mobile device and that the event is closely associated with a particular application. Thus, the target event chain for comparison selected by authentication module 316 is associated with access to a particular application on the mobile device.

[0052] In some aspects, the event linking module 310 may exclude events that are not "key" events from the determined chain. For example, if a person enters a building and then goes to the cafeteria, the act of going to the cafeteria may not be included in the event chain. Instead, the event linking module 310 may include events that are directly related to accessing a computing device (e.g., entering a location where a computing device is located).

[0053] In some embodiments, the authentication module 316 may identify inconsistencies in the sequence of events. For example, if the determined event chain 100 indicates that an authorized person entered and then exited a building, data access from the point at which the authorized person is no longer present in the building is deemed malicious and blocked by the security module 306. Similarly, in FIG. 2 , if, in event 202a, person 204 enters an incorrect PIN code at least a threshold number of times and has difficulty finding the application from which the data request was made (e.g., person 204 continues swiping without selecting an application), the authentication module 316 may identify that behavior as inconsistent with normal use. Other examples of inconsistencies may include data access after the mobile device is reported as lost (e.g., the “Find My iPhone” feature is initiated) and data access from an IP address not associated with an authorized user.

[0054] 4 shows a flow diagram of a method 400 for authenticating user identity based on an event chain. At 402, a data parser 308 of a security module 306 receives sensor data from at least one sensor (e.g., sensor 304) in an environment. At 404, the data parser 308 parses the sensor data to determine multiple identifiers of users authorized to access the data via the computing device. For example, the data parser 308 may identify the user's face in video and the user's badge scan in an input record. At 406, the data parser 308 generates an event involving the user for each identifier of the multiple identifiers, each event including a respective timestamp. For example, the data parser 308 may generate event 102a in response to detecting a face of person 104 and event 102b in response to detecting a badge scan at sensor 106b.

[0055] At 408, the security module 306 intercepts the data access request, which includes an identifier of a user authorized to access data on the computing device 108. For example, the security module 306 may detect that the person 104 is attempting to log in to the computing device 108. The identifier may be the login credentials of the authorized user of the computing device 108. Thus, the security module 306 authenticates whether the data access request is from a user authorized to access the data (e.g., whether the person 104 is actually accessing the computing device 108 or an impersonation).

[0056] At 410, the event linking module 310 generates an event chain (e.g., event chain 100) for a period (e.g., one hour) preceding the data access request, the event chain including the generated events, including the user, ordered based on each respective timestamp. The event chain may include all events generated by the data parser 308 that include an identifier of the authorized user (e.g., person 104).

[0057] At 412, the authentication module 316 determines a deviation (e.g., 2) of the event chain from a target event chain indicative of an authenticated access by the user. The target event chain may be obtained from the event mapping database 314. In some aspects, the data access request is a first data access of multiple data accesses, and the authentication module 316 selects the target event chain for comparison in response to determining that the target event chain is also the first data access.

[0058] In some aspects, the first data access is an access from a computing device (e.g., computing device 108) fixed at a particular location, and the target event chain indicates the user's progress entering the particular location and accessing the computing device. In other aspects, the first data access is an access from a portable computing device (e.g., computing device 206), and the target event chain indicates the user's progress performing actions on the computing device (e.g., swipes and other navigation inputs received by a touchscreen sensor on computing device 206) to initiate the data access request. In some aspects, the target event chain is a historical event chain performed by the user prior to the previous data access.

[0059] At 414, the authentication module 316 determines whether the deviation is less than a deviation threshold (e.g., 3). In some aspects, each respective event in the target event chain, where the deviation is a function of the event order and the length of time assigned to each event, is assigned a weight indicating the importance of the respective event. In response to determining that the deviation is less than the deviation threshold, method 400 proceeds to 416, where the authentication module 316 authenticates that the data access request is from an authorized user and grants the data access request (e.g., enables the login).

[0060] Alternatively, in response to determining that the deviation is not less than the deviation threshold, method 400 proceeds to 418, where the authentication module 316 does not authenticate that the data access request is from an authorized user and blocks the data access request. For example, the security module 306 may generate an alert on a user interface of the computing device indicating that access has been denied. In some aspects, the security module 306 may further send an alert to another computing device of the authorized user associated with the identifier found in the data access request. This notifies the authorized user that data access has been attempted by an unauthorized person. The authorized user may then confirm the access request (to enable access or to deny the access request). Depending on the response, the security module 306 may update the target event chain in the event mapping database 314. For example, if the blocked data access request is actually genuine, the security module 306 may include the detected event chain in the event mapping database 314 to prevent similar event chains from being denied in the future.

[0061] 5 shows a flow diagram of a method 500 for identifying inconsistencies in an event chain. At 502, the verification module 316 identifies whether an inconsistency exists in the sequence of the event chain. At 504, the verification module 316 determines whether the event order is an illogical sequence. For example, an illogical sequence would indicate that a person entered a building after entering their office within the building. The order issue is determined using sequence numbers in the target event chain. If the event order includes an illogical sequence, the method 500 proceeds to 418.

[0062] If the event order does not have an illogical sequence, method 500 continues at 506, where authentication module 316 determines whether an action performed on the computing device is inconsistent with normal use. Examples of inconsistent actions may include entering incorrect login credentials more than a threshold number of times (e.g., five incorrect entries), using blacklisted web applications (e.g., websites that may download malicious activity), changing security settings, etc. If such actions are detected, authentication module 316 may block 418 the data access request.

[0063] If no such activity is detected, method 500 proceeds to 508, where authentication module 316 determines whether an event is detected indicating that an authorized user is not physically accessing the computing device. For example, the event may include an authorized person leaving the office. A subsequent data access attempt requires an event in which the person returns to the office, or the person is not physically present. Therefore, the data access request should be denied at 418. Another example may be accessing a computing device that has been confirmed lost. If no such event is detected, authentication module 316 may determine that no discrepancy exists and therefore data access should be allowed at 416.

[0064] 6 is a block diagram illustrating a computer system 20 on which aspects of systems and methods for authenticating user identity based on event chains may be implemented according to exemplary aspects. The computer system 20 may be in the form of multiple computing devices or a single computing device, such as a desktop computer, a notebook computer, a laptop computer, a portable computing device, a smartphone, a tablet computer, a server, a mainframe, an embedded device, and other forms of computing devices.

[0065] As shown, computer system 20 includes a central processing unit (CPU) 21, a system memory 22, and a system bus 23 that connects various system components, including the memory associated with central processing unit 21. System bus 23 may include a bus memory or bus memory controller, a peripheral bus, and a local bus that can interface with any other bus architecture. Examples of buses include PCI, ISA, PCI-Express, HyperTransport™, InfiniBand™, Serial ATA, I2C, and the like. 2 The system may include a CPU, a ROM, a ROM 24, a ROM 32, a ROM 40, a ROM 50, a ROM 60, a ROM 70, a ROM 80, a ROM 90, a ROM 100, a ROM 120, a ROM 140, a ROM 160, a ROM 180, a ROM 182 ...

[0066] Computer system 20 may include one or more storage devices, such as one or more removable storage devices 27, one or more non-removable storage devices 28, or a combination thereof. The one or more removable storage devices 27 and non-removable storage devices 28 are connected to system bus 23 via storage interface 32. In one aspect, the storage devices and corresponding computer-readable storage media are power-independent modules for storing computer instructions, data structures, program modules, and other data for computer system 20. System memory 22, removable storage device 27, and non-removable storage device 28 may use a variety of computer-readable storage media. Examples of computer-readable storage media include machine memory such as cache, SRAM, DRAM, Zero Capacitor RAM, Twin Transistor RAM, eDRAM, EDO RAM, DDR RAM, EEPROM, NRAM, RRAM, SONOS, PRAM, etc.; flash memory or other memory technologies such as solid-state drives (SSDs) or flash drives; magnetic disk storage such as magnetic cassettes, magnetic tapes, and hard disk drives or floppy disks; optical storage such as compact discs (CD-ROMs) or digital versatile discs (DVDs); and any other medium that may be used to store desired data and that can be accessed by computer system 20.

[0067] The system memory 22, removable storage device 27, and non-removable storage device 28 of the computer system 20 may be used to store an operating system 35, additional program applications 37, other program modules 38, and program data 39. The computer system 20 may also include a peripheral interface 46 for communicating data from input devices 40, such as a keyboard, mouse, stylus, game controller, voice input device, touch input device, or other peripheral devices, such as a printer or scanner, via one or more I / O ports, such as a serial port, parallel port, universal serial bus (USB), or other peripheral interface. A display device 47, such as one or more monitors, projectors, or integrated displays, may be connected to the system bus 23 via an output interface 48, such as a video adapter. In addition to the display device 47, the computer system 20 may also include other peripheral output devices (not shown), such as speakers and other audiovisual devices.

[0068] Computer system 20 may operate in a networked environment using network connections to one or more remote computers 49. The remote computer(s) 49 may be a local computer workstation or server, comprising most or all of the elements described above in describing the nature of computer system 20. Other devices, such as, but not limited to, routers, network stations, peer devices, or other network nodes, may also be present in the computer network. Computer system 20 may include one or more network interfaces 51 or network adapters for communicating with remote computers 49 over one or more networks, such as a local area computer network (LAN) 50, a wide area computer network (WAN), an intranet, and the Internet. Examples of network interfaces 51 may include an Ethernet interface, a frame relay interface, a SONET interface, and a wireless interface.

[0069] Aspects of the present disclosure may be systems, methods, and / or computer program products, which may include one or more computer-readable storage media having computer-readable program instructions for causing a processor to perform aspects of the present disclosure.

[0070] A computer-readable storage medium may be a tangible device capable of holding and storing program code in the form of instructions or data structures that can be accessed by a processor of a computing device, such as computer system 20. A computer-readable storage medium may be an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. By way of example, such a computer-readable storage medium may comprise a random access memory (RAM), a read-only memory (ROM), an EEPROM, a compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a flash memory, a hard disk, a portable computer diskette, a memory stick, or a floppy disk, or even a mechanically encoded device such as a punch card or a ridge-in-a-groove structure having instructions recorded thereon. As used herein, a computer-readable storage medium should not be interpreted as a transitory signal itself, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or transmission medium, or an electric signal transmitted over a conductor.

[0071] The computer-readable program instructions described herein can be downloaded to each computing device from a computer-readable storage medium or can be downloaded to an external computer or external storage device over a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network interface in each computing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage on a computer-readable storage medium in the respective computing device.

[0072] Computer-readable program instructions for carrying out the operations of the present disclosure may be either assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​and traditional procedural programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a LAN or WAN, or may be connected to an external computer (e.g., via the Internet). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute the computer-readable program instructions by utilizing state information from the computer-readable program instructions to personalize the electronic circuit to carry out aspects of the present disclosure.

[0073] In various aspects, the systems and methods described in this disclosure may address modules. As used herein, the term "module" refers to a real-world device, component, or arrangement of components implemented using hardware, such as an application-specific integrated circuit (ASIC) or FPGA, or as a combination of hardware and software, such as a microprocessor system and an instruction set that (when executed) implements the module's functionality, turning the microprocessor system into a dedicated device. Modules may also be implemented as a combination of the two, with certain functions facilitated solely by hardware and other functions facilitated by a combination of hardware and software. In particular implementations, at least a portion, and possibly all, of the modules may execute in a processor of a computer system. Thus, each module may be realized in a variety of suitable configurations and should not be limited to the particular implementation illustrated herein.

[0074] For clarity, not all routine functions of the above aspects are disclosed herein. It will be understood that in the development of any actual implementation of the present disclosure, numerous implementation-specific decisions must be made to achieve the particular goals of the developer, and that these particular goals will vary from implementation to implementation and from developer to developer. While such a development effort may be complex and time-consuming, it will nevertheless be understood to be a routine undertaking of engineering for those of ordinary skill in the art having the benefit of this disclosure.

[0075] Furthermore, it is to be understood that the phrases or terms used herein are for purposes of description and not of limitation, and that the terms or phrases herein should be interpreted by one of ordinary skill in the art in light of the teachings and guidance presented herein, in combination with the knowledge of such persons. Moreover, it is not intended that any term in the specification and claims be ascribed an uncommon or special meaning unless expressly so stated.

[0076] The various aspects disclosed herein encompass presently known and future known equivalents to the known modules referenced herein by way of example. Moreover, while aspects and applications have been shown and described, it will be apparent to those skilled in the art having the benefit of this disclosure that many more modifications thereof are possible without departing from the inventive concepts disclosed herein.

Claims

1. 1. A method for authenticating a user identity based on an event chain, comprising: receiving sensor data from at least one sensor in an environment; Parsing the sensor data to determine a plurality of identifiers of users authorized to access the data via a computing device; generating, for each identifier of the plurality of identifiers, an event that is an action performed by a user corresponding to the identifier at a specific location, in association with a timestamp that is a time when the action was performed; intercepting a data access request that includes an identifier of the user authorized to access data on the computing device; and authenticating whether the data access request is from the user who has authority to access data, wherein the authenticating includes: generating an event chain for a period preceding the data access request, the event chain including a plurality of events generated for an identifier of the user, the plurality of events being ordered based on a timestamp associated with each event; determining a deviation of the event chain from a target event chain indicative of authorized access by the user, the deviation being a function of event order and the length of time allocated to each event from the end of the previous event; and authenticating that the data access request is from the user and permitting the data access request in response to determining that the deviation is less than a deviation threshold and that the order of events in the event chain is not an illogical sequence, that operations performed on the computing device are not inconsistent with normal use, and that no events indicating that a person is not physically accessing the computing device are detected.

2. 2. The method of claim 1, further comprising: in response to determining that the deviation is not less than the deviation threshold, not authenticating the data access request as being from the user and blocking the data access request.

3. the data access request is a first data access of a plurality of data accesses; The method of claim 1 , further comprising identifying the target event chain by determining that the target event chain is a target event chain of the first data access.

4. 4. The method of claim 3, wherein the first data access is from a computing device fixed at a particular location, and the target event chain indicates the user's progress through the particular location and accessing the computing device.

5. 4. The method of claim 3, wherein the first data access is from a portable computing device and the target event chain indicates the user's progress in performing actions on the computing device to initiate the data access request.

6. The method of claim 1 , wherein each respective event in the target event chain is assigned a weight indicating the importance of the respective event.

7. The method of claim 1 , wherein the target event chain is a historical event chain executed by the user prior to a previous data access.

8. 1. A system for authenticating a user identity based on an event chain, comprising: receiving sensor data from at least one sensor in the environment; Parsing the sensor data to determine a plurality of identifiers of users authorized to access the data via the computing device; For each identifier of the plurality of identifiers, an event is generated, which is an action performed by a user corresponding to the identifier at a specific location, in association with a timestamp indicating the time at which the action was performed; intercepting a data access request that includes an identifier of the user authorized to access data on the computing device; determining whether the data access request is from the user who has the authority to access the data; generating an event chain for a period preceding the data access request, the event chain including a plurality of events generated for the user's identifier, the plurality of events being ordered based on a timestamp associated with each event; determining a deviation of the event chain from a target event chain indicative of authorized access by the user, the deviation being a function of the event order and the length of time allocated to each event from the end of the previous event; 1. A system comprising: a hardware processor configured to authenticate the data access request by authenticating that the data access request is from the user and granting the data access request in response to determining that the deviation is less than a deviation threshold, and that the order of events in the event chain is not an illogical sequence, that operations performed on the computing device are not inconsistent with normal use, and that no events indicating that a person is not physically accessing the computing device are detected.

9. 9. The system of claim 8, wherein the hardware processor is further configured to, in response to determining that the deviation is not less than the deviation threshold, not authenticate the data access request as being from the user and block the data access request.

10. 9. The system of claim 8, wherein the data access request is a first data access of a plurality of data accesses, and the hardware processor is further configured to identify the target event chain by determining that the target event chain is a target event chain of the first data access.

11. 11. The system of claim 10, wherein the first data access is from a computing device fixed at a particular location, and the target event chain indicates the user's progress through the particular location and accessing the computing device.

12. 11. The system of claim 10, wherein the first data access is from a portable computing device and the target event chain indicates the user's progress in performing actions on the computing device to initiate the data access request.

13. The system of claim 8 , wherein each respective event in the target event chain is assigned a weight indicating the importance of the respective event.

14. The system of claim 8 , wherein the target event chain is a historical event chain executed by the user prior to a previous data access.

15. 1. A non-transitory computer-readable medium storing computer-executable instructions for authenticating a user identity based on an event chain, the non-transitory computer-readable medium comprising: instructions for receiving sensor data from at least one sensor in the environment; instructions for parsing the sensor data to determine a plurality of identifiers of users authorized to access the data via a computing device; instructions for generating, for each identifier of the plurality of identifiers, an event representing an action performed by a user corresponding to the identifier at a specific location, in association with a timestamp representing the time at which the action was performed; instructions on the computing device for intercepting a data access request that includes an identifier of the user authorized to access data; determining whether the data access request is from the user who has the authority to access the data; generating an event chain for a period preceding the data access request, the event chain including a plurality of events generated for the user's identifier, the event chain being ordered based on a timestamp associated with each event; determining a deviation of the event chain from a target event chain indicative of authorized access by the user, the deviation being a function of the event order and the length of time allocated to each event from the end of the previous event; and instructions for authenticating the data access request as being from the user and granting the data access request in response to determining that the deviation is less than a deviation threshold and that the order of events in the event chain is not an illogical sequence, that operations performed on the computing device are not inconsistent with normal use, and that no events indicating that a person is not physically accessing the computing device are detected.

16. 16. The non-transitory computer-readable medium of claim 15, further comprising instructions for not authenticating the data access request as being from the user and blocking the data access request in response to determining that the deviation is not less than the deviation threshold.

Images