Patent Description:
Nefarious actors attempt to generate fraudulent security tokens to obtain unauthorized access to computer resources protected by security tokens; these fraudulent tokens must include a digital signature that appears to be generated by a valid token issuer. This can easily be achieved if the private key of the token issuer becomes compromised. Once the private key is known, these nefarious actors may fraudulently issue tokens that grant access to resources controlled by the token issuer. In some cases, access to the private key is obtained via other fraudulent techniques, such as obtaining access to system administrative accounts, or other back door mechanisms of obtaining unauthorized access to the private key data. Thus, methods for ensuring token issuing processes are not compromised, or detecting when they are compromised, are needed. <CIT> describes techniques for ascertaining legitimacy of communications received during a digital interaction with a client device. The techniques include: receiving a communication; identifying from the communication a first secured token; processing the first secured token by: obtaining, from the first secured token, information indicating a state of the digital interaction; and using the information indicating the state to determine whether the communication is from the client device; and when it is determined that the communication is from the client device, causing at least one action responsive to the communication to be performed; updating the information indicating the state of the digital interaction to obtain updated information indicating the state of the digital interaction; and providing a second secured token to the client device for use in a subsequent communication during the digital interaction, the second secured token comprising the updated information indicating the state of the digital interaction. <CIT> describes systems and methods for synchronizing verification data in a distributed database including client and server databases. The server database may exchange verification data regarding one-time passwords to multiple client databases. An update to the server database may be initiated based on information stored in the client database by pushing updated verification information from the client database to the server database via an SSL tunnel. An update to the client database may be initiated based on information stored in the server database by pulling updated verification data from the server database to the client database via an SSL tunnel. The client database and the server database may include a two-dimensional data field including the verification data and an associated key identifier, and a site ID. The site ID may include a unique identifier to identify the respective database in which it is included. The data field may include a sequence number assigned to each row of data that increases every time the row of information is updated. The client database and the server database may also include a replication tracking table including a record of the last known update to a remote database. Data fields that require updating may be determined based on the site ID and a comparison of the sequence numbers from the replication tracking table and the server's database. <CIT> provides an apparatus comprising a memory configured to store an encryption key and a list of access tokens and at least one processing core configured to select a first access token from the list of access tokens based, at least partly, on at least one of a current time and a sequence number, decide, based at least partly on the first access token, whether to grant a user device access to the apparatus, and cause the apparatus to receive a second list of access tokens from at least one of the user device and a second user device.

The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, electrical, process, and other changes. Portions and features of some embodiments may be included in, or substituted for, those of other embodiments. Embodiments set forth in the claims encompass all available equivalents of those claims.

The disclosed embodiments provide for detection of fraudulent electronic security tokens. As described above, in some cases, a private key of a token issuing authority becomes compromised, and thus available to nefarious actors. These actors can then issue tokens that provide access to computer resources and appear valid, in that they include valid digital signatures.

Detection of fraudulent security tokens can be performed both before access is provided based on the token, or after the token has been used to access computer resources. Evaluating tokens before their use works to decrease the unauthorized access of computer resources, but likely imposes some latency when accessing those resources. Evaluating tokens after their use avoids adding additional latency to access operations while allowing some authorized access before the fraudulent token is detected.

In some of the disclosed embodiments, security tokens used to access computer resources are evaluated after the access has occurred. Thus, these embodiments function as security forensics, identifying compromised tokens after their use but mitigating against additional future use of those tokens or, for example, tokens generated using an equivalent private key that may have been compromised. Other embodiments operate before access via a token occurs. These embodiments evaluate the token for indications of fraudulent activity, and disallow or invalid tokens that fail to meet certain validity criterion.

Some embodiments track sequence numbers issued by a token issuing authority. For example, each token issued by a particular token issuing authority includes a unique sequence number. The unique sequence number ensures that multiple tokens from a token issuing authority are not duplicates of each other, and helps to prevent replay type attacks. These disclosed embodiments track the sequence numbers and are then able to predict sequence numbers issued by a particular token issuing authority going forward. In the event that the token issuing authority is not available to confirm the validity of a particular token, instead of rejecting the token, at least some of the disclosed embodiment compare the token's sequence number with a range of sequence numbers predicted by tracking of sequence numbers from this particular authority. A token issuing authority is defined by, in some aspects, a private key used by the token issuing authority to digitally sign tokens. Use of different private keys may represent different token issuing authorities in some aspects.

Some embodiments also determine validity of a token based, at least in part, on a service or client attempting to access resources using the token. For example, some of the disclosed embodiments maintain reputation data for "users" of electronic tokens, and make determinations on whether a token is likely valid based on the "users" (e.g. service or client).

Some of the disclosed embodiments utilize one or more of the techniques discussed above to reduce the incidence of false positives with regards to detection of fraudulent tokens. For example, some implementations may initially flag a token as invalid based on factors such as whether the token issuing authority is online and is able to validate the token. These implementations may determine the token is invalid if unable to validate the token with the token issuing authority. However, this approach results in a fair number of valid tokens categorized as invalid. To reduce the number of false positives, additional validations may be performed when these initial indications would otherwise indicate an invalid token. For example, as discussed above, if the token cannot be validated via the original token issuing authority, some of these implementations consider the client or service attempting to access computer resources using the token. If the client/service has a relatively good reputation, the token may not be flagged as invalid even if the token issuing authority is not available to validate the token. Similarly, if the token issuing authority is not available, false positives are reduced by determining whether the token's sequence number is within a confidence interval of possible sequence numbers for the issuing time of the token and a history of token sequence numbers from the token issuing authority as further discussed above. If the sequence number falls within the confidence interval, the token is classified as valid (in at least some embodiments), even if other methods of token validation may not be available. This reduction in false positives can result in improved operational efficiencies. For example, some network operators may devote resources to manual investigations of tokens flagged as invalid. To the extent these resources are allocated to investigating valid tokens falsely classified as invalid, costs associated with validating tokens increases, and fewer resources can be devoted to investigating tokens that are actually forged or otherwise invalid. Thus, the disclosed embodiments not only improve operational efficiency, but also improve computer security, by increasing the resources available to pursue security vulnerabilities, such as invalid tokens resulting from a compromised private key of a token issuing authority.

<FIG> is an overview diagram of a system that implements one or more of the disclosed embodiments. The system <NUM> includes a token issuing server <NUM>, service <NUM>, enterprise server <NUM>, and a token forensics server <NUM>. The system <NUM> also includes a token datastore <NUM>. The token issuing server <NUM> issues tokens and stores information relating to the issued tokens in the token datastore <NUM>. In some embodiments, there is a <NUM>:<NUM> mapping between token issuing servers, generally, and token issuing authorities. In some other aspects, multiple token issuing servers may issue tokens for a single token issuing authority (e.g. to achieve a desired throughput, multiple servers may be necessary). In some embodiments, the token issuing server <NUM>, in some embodiments, issues tokens for a single token issuing authority. In some aspects, each token issuing authority has particular network connection information that provides connectivity to the token issuing authority. For example, a single token issue authority may accept token requests via a particular combination of hostname/Internet Protocol (IP) address and/or destination port number, for example.

The token issuing server provides tokens, on request in some embodiments, to the service <NUM>. The service <NUM> requests particular functions from the enterprise server <NUM>. For example, the service <NUM> requests, in some embodiments, access to files, or the performance of certain computing operations or functions from the enterprise server <NUM>. To accomplish functions requested by the service <NUM>, the enterprise server <NUM> requires a valid electronic security token be provided, such as a valid token provided by the token issuing server <NUM>. The enterprise server <NUM> validates a token provided by the service <NUM> by, in part, consulting with the original token issuing server <NUM> or the token datastore <NUM>. For example, in some embodiments, the token is digitally signed using a private key of the token issuing server. The enterprise server <NUM> identifies a public key of the token issuing server <NUM> in some embodiments, via the token datastore <NUM>. After validating the token, the enterprise server <NUM> performs the service requested by the service <NUM>. As mentioned, the validation of the token by the enterprise <NUM> includes confirmation that the token's digital signature is valid for the token issuing server <NUM>. However, if the token issuing server's private key is compromised, a fraudulent actor may issue tokens and obtain nefarious access to the computer resources provided by the enterprise server <NUM>.

As shown in <FIG> some of the disclosed embodiments provide log records <NUM> indicating use of tokens to a tokens forensics system <NUM>. The token forensics system <NUM> performs one or more validity checks to confirm that a token used to access computer resources of the enterprise server <NUM> is valid. Furthermore, the token forensics system <NUM> implements these validity checks to reduce a probability of false positives being generated. For example, in some environments, the token data store <NUM> and/or the token issuing server <NUM> are inaccessible. This inaccessibility may result from a general network outage between the token forensics system <NUM> and the token datastore <NUM> and/or the token issuing server <NUM>. Alternatively, or more of the token datastore <NUM> and/or the token issuing server <NUM> may be unresponsive, due to an internal problem. Thus, the token forensics server <NUM> is unable to perform some validation functions when one or more of the token data store <NUM> and/or token issuing server <NUM> are unavailable. In some prior implementations, the token forensics server <NUM> would consider this situation to indicate that the token itself is invalid, and would provide the token to an inspection queue <NUM>.

In cases where the validation fails due to the token data store <NUM> and/or the token issuing server <NUM> being unavailable to the token forensics system <NUM>, the inspection queue becomes populated by one or more tokens that are in fact valid, but were falsely flagged as invalid due to the inaccessibility. As described further below, some of the disclosed embodiments reduce the inclusion of valid tokens in the inspection queue <NUM> by performing additional checks when one or more of the token datastore <NUM> and/or token issuing server <NUM> are unavailable. This reduces the number of valid tokens included in the inspection queue <NUM>. In embodiments that rely on manual inspection of tokens in the inspection queue, the reduction in false positives provided by the disclosed embodiments can provide substantial cost and personnel savings when compared to prior methods.

<FIG> is an overview diagram of a system that implements one or more of the disclosed embodiments. The system <NUM> includes a token issuing server <NUM>, service <NUM>, enterprise server <NUM>, and token validation server <NUM>. The system <NUM> differs from the system <NUM> of <FIG> in that with system <NUM>, the validation performed by the token validation server <NUM> occurs before computer resources are made accessible via the token. Thus, upon receiving a request to access computer resources from the service <NUM>, the enterprise server <NUM> provides the token to the token validation server <NUM> via a message 220a. The token validation server <NUM> then performs one or more verifications to determine whether the token is likely valid. The validations performed by the token validation server <NUM> rely on one or more of the token issuing server <NUM> and/or token datastore <NUM>. The token validation server <NUM> provides a result of its validation back to the enterprise server <NUM> via a message 220b. Thus, the implementation of the system <NUM> of <FIG> differs from that of system <NUM> of <FIG> in that the implementation of <FIG> evaluates token validity after the token has been used to access computer resources. The system <NUM> provides for improved response time in access to those computer resources by reducing the amount of validation performed on a token before access is granted. The token forensics are then performed offline, without any latency requirements imposed by the need to access computer resources efficiently and quickly. The embodiment illustrated by system <NUM> and <FIG>, in some embodiments, results in increased latency in access to computer resources by performing additional token validation (e.g. via the token validation server <NUM>), before access to computer resources is granted based on the token. The system <NUM> benefits from this additional token validation via a reduction in access to computer resources provided based on an invalid token.

<FIG> shows data structures that may be implemented in one or more of the disclosed embodiments. While the discussion of the data structures illustrated in <FIG> refers to the data structures as relational database tables, one of skill would understand that a variety of data structure types are implemented in various embodiments. For example, various embodiments may utilize non-relational data stores, traditional in-memory data structures such as linked lists, trees, arrays, or other structures.

<FIG> shows a token table <NUM>, issuing authority table <NUM>, and a client tracking table <NUM>. The token table <NUM> stores records defining fields of a token. The token table <NUM> includes a token identifier field <NUM>, digital signature <NUM>, sequence number <NUM>, issuing authority identifier <NUM>, and issue time <NUM>. The token identifier field <NUM> uniquely identifies a token. The digital signature <NUM> stores a digital signature of the token. In some embodiments, the digital signature <NUM> is generated by a token issuing authority using a private key of the token issuing authority. In these embodiments, the digital signature is decoded via a public key of the token issuing authority as explained further below. The sequence number field <NUM> stores a sequence number of the token. The sequence number is assigned to a token by a token issuing authority. While the sequence number field <NUM> is described as a "number," in some embodiments, the sequence number may not be a number per se, but may include at least both alpha and numeric characters. The issuing authority field <NUM> identifies an issuing authority of the token. For example, some embodiments may include multiple token issuing servers, such as the token issuing servers <NUM> and/or <NUM> discussed above with respect to <FIG> and <FIG> respectively. The issue time field <NUM> stores an issue time for the particular token.

The issuing authority table <NUM> includes an issuing authority identifier <NUM>, public key field <NUM>, baseline sequence number field <NUM>, baseline time field <NUM>, rate field <NUM>, and an online indicator field <NUM>. The issuing authority identifier field <NUM> uniquely identifies a token issuing authority. Thus, in embodiments implementing multiple token issuing authorities (e.g. token issuing server <NUM> and/or <NUM>), the issuing authority identifier field <NUM> uniquely identifies a particular one of the token issuing authorities. The token issuing authority field <NUM> is cross referenceable with the token issuing authority field <NUM> of the token table <NUM>. The public key field <NUM> stores a public key for the token issuing authority identified via the issuing authority identifier field <NUM>. The baseline sequence number field <NUM> stores a base line sequence number for the token issuing authority.

A baseline sequence number is a sequence number generated by the token issuing authority at a defined baseline time. The particular baseline time is indicated by the time field <NUM>. The rate field <NUM> determines a rate of change for the baseline sequence number. The rate field specifies the rate, in various embodiments, as increments (or decrements) to the baseline sequence number per second, millisecond, or other predetermined time period. The rate field <NUM> stores a value that is, in some embodiments, used in conjunction with the baseline sequence number field <NUM> and the baseline time field <NUM> to extrapolate or predict a sequence number or sequence number range for tokens generated by the issuing authority (identified via <NUM>) at an additional second time. The online flag field <NUM> indicates whether the issuing authority has been detected as being online or offline.

The client tracking table <NUM> includes a client identifier <NUM>, token validation result <NUM>, time field <NUM>, and issuing authority field <NUM>. The client identifier field <NUM> uniquely identifies a particular client. In this context, a client is an entity that seeks access to computer resources via a token. For example, the service <NUM> and/or service <NUM> are identified as a client in the client table <NUM> in at least some embodiments. The validation result field <NUM> stores a result of a token validation provided by the client. Thus, if a valid token is provided, the validity is stored in the validation result field, whereas if an invalid token is provided by the client, that invalidity is also recorded in the validation result field.

The time field <NUM> stores a time when the validation result was recorded. The time field <NUM> is used in some embodiments to provide for a moving average of validation results for a particular client. Older results may be discounted relative to newer results, or may be eliminated from the determination of client reputation entirety and deleted from the client tracking table <NUM> entirely after reaching a threshold age.

The issuing authority field <NUM> stores an issuing authority of a token that provided the token validation result stored in field <NUM>. Storing the issuing authority field <NUM> in the client tracking table allows the client tracking table to perform an additional function, that of tracking validation results for a particular token issuing authority. For example, determinations of a percentage of token validations of tokens from a particular token issuing authority, within a threshold period of time are determined in some aspects to determine whether a token issuing authority is in good standing or not. As explained further below, if a percentage of token validations for tokens issued by the particular token issuing authority is above a threshold (or meets a criterion), the token issuing authority is considered to be in good standing, otherwise they are considered to not be in good standing.

A separate row in the table <NUM> is provided for each token validation result. The client table <NUM> is used in some of the disclosed embodiments to establish a reputation for a particular client. A client with a track record of providing valid tokens may be more trustworthy than an unknown client or one with a history of presenting invalid tokens.

<FIG> illustrates a method of predicting token sequence numbers that is implemented in at least some of the disclosed embodiments. <FIG> shows a series of tokens being issued sequentially in time. Time is shown via horizontal axis <NUM>. Each of the tokens has a sequence number 403a-e. The sequence numbers 403a-e are shown increasing by two (<NUM>) with each issuance, although in some embodiments, how sequence numbers change sequentially may vary. For example, sequence numbers may increment by more or less than the illustrated two (<NUM>) units. In some embodiments, sequence numbers may decrease over time. Issuance of the series of tokens is represented by a series of vertical arrows 404a-e. The vertical arrows represent notifications in some embodiments. Some of the disclosed embodiments store information indicating a time at which each of the tokens is issued, shown as times 406a-e.

Some of the disclosed embodiments determine an elapsed time <NUM> for a series of token issuances, as represented by 404a-e. These embodiments also note a difference <NUM> in token sequence numbers 403a-e that occur during the elapsed time <NUM>. From this information, these embodiments determine a rate at which the sequence numbers 403a-e are changing. This rate information is used, in some embodiments, to predict sequence numbers generated by the token issuing authority. A baseline sequence number (e.g. 403e) is selected in some embodiments, from which additional sequence numbers and their respective issuance time are predicted. <FIG> shows predicted sequence numbers <NUM>, including sequence numbers 403f and <NUM>, based on the determined rate information (e.g. stored in rate field <NUM>) and baseline sequence number (e.g. stored in field <NUM>) information.

<FIG> is an example portion of a token and/or notification and/or message that may be implemented in one or more of the disclosed embodiments. In some embodiments, one or more of the notification <NUM> and/or the message 220a may include one or more of the fields discussed below with respect to the portion <NUM> and <FIG>.

The portion <NUM> includes a sequence number field <NUM>, issuing authority field <NUM>, digital signature field <NUM> and issuance time field <NUM>. The sequence number field <NUM> stores a sequence number for a token. As discussed above, token issuing authorities may, in some embodiments, include a unique sequence number with each token issued by the token issuing authority. The issuing authority is identified via field <NUM>. The digital signature field <NUM> stores a digital signature. The digital signature is generated based on at least some of the contents of the portion <NUM> (sans the digital signature itself). The digital signature stored in field <NUM> is generated, in some embodiments, using a private key of the issuing authority (identified via field <NUM>). The issuance time field <NUM> stores a value indicating a time that the token was issued.

<FIG> is a flowchart of a process for validating a token that is implemented in one or more of the disclosed embodiments. One or more of the functions discussed below with respect to <FIG> is performed by hardware processing circuitry. For example, in some embodiments, instructions stored in an electronic memory configure the hardware processing circuitry to perform one or more of the functions discussed below with respect to <FIG>. Note that this specification may label multiple determining, or other operations, as, for example, first determining, second determining, third determining in order to distinguish between the different determining (or other operations). However, this labeling using first, second, third, etc, should not be used to imply a particular order of the labeled operations. Instead, this labeling is simply to ensure clear identification of multiple operations with similar names or descriptions.

In operation <NUM>, a plurality of notifications are received. Each of the notifications indicate issuance of a token by a token issuing authority. For example, as discussed above with respect to <FIG>, the enterprise server <NUM> provides notifications <NUM> to the token forensics server <NUM>. In some other embodiments, the notifications are read from a data store, such as the token datastore <NUM>. Similarly, in <FIG>, the enterprise server <NUM> is described as providing a token to the token validation server <NUM> via a message 220a. The message 220a is considered a notification in at least some of the disclosed embodiments.

In operation <NUM>, a token sequence number is decoded from each of the notifications. For example, as discussed above with respect to the example notification <NUM>, in some embodiments the notification includes a token sequence number field <NUM> that may provide for decoding the token sequence number from each of the notification(s)/message(s).

In operation <NUM>, a rate of change of the token sequence numbers is determined. In some embodiments, operation <NUM> determines an elapsed time between issuance of the plurality of tokens. For example, in some embodiments, an issuance time of each token is included in the respective notification for the token (e.g. such as issuance time field <NUM> of notification <NUM>). Alternatively, the elapsed time is determined based on an elapsed time between reception of the notifications themselves. A difference in sequence numbers of the tokens received in the notifications is also determined. For example, with respect to the example token issuances illustrated in <FIG>, a difference between token sequence number 403a and 403e is determined in some embodiments, along with the elapsed time <NUM> between reception of notifications 404a and 404e for the respective token sequence numbers 403a and 403e. A rate of change of the token sequence number is then determined based on the elapsed time of token issuances or notifications and a change in the sequence numbers observed during the elapsed time.

In operation <NUM>, a first security token is received at a first time. For example, as discussed above, the token forensics server <NUM> or the token validation server <NUM> receives token information from enterprise server <NUM> or <NUM> respectively.

In operation <NUM>, a digital signature of the first security token is validated. For example, in some embodiments, operation <NUM> determines a token issuing authority of the token via data included in the token itself (e.g. token/notification <NUM>, field <NUM>). From the issuing authority information, a public key of the issuing authority is determined (e.g. via field <NUM>). Data of the token is then decoded based on the public key to ensure the validity of the digital signature.

In operation <NUM>, a confidence interval or range of token sequence numbers is determined based on the first time the first security token was received, and the rate of change. As discussed above, some embodiments store a baseline sequence number and baseline time, from which, along with the determined rate of change, can be used to predict or extrapolate a mean predicted sequence number for a first time. Operation <NUM> also determines, in some embodiments, a confidence interval of sequence number values around the mean for tokens issued by the token issuing authority. Alternatively, some embodiments determine a likely range of values for token sequence numbers from a particular token issuing authority at a particular point in time. The mean predicted sequence number may be determined based on Equation <NUM> below: <MAT> where:.

In operation <NUM>, a determination is made as to whether a sequence number of the first security token is within the confidence interval or range for the issuer of the first security token. In some embodiments, operation <NUM> determines the sequence number is within a predetermined threshold confidence interval of a mean of a predicted sequence number at the issue time of the token (or the current time). Various thresholds may be used including <NUM>%, <NUM>%, <NUM>%, <NUM>%, <NUM>%, <NUM>%, <NUM>%, <NUM>% or any confidence interval.

In operation <NUM>, the security token is validated (or invalidated) based on whether the sequence number of the first security token is within a predetermined confidence interval and/or a determined range as discussed above.

<FIG> is a flowchart of a process for validating a token that is implemented in one or more of the disclosed embodiments. One or more of the functions discussed below with respect to <FIG> is performed by hardware processing circuitry. For example, in some embodiments, instructions stored in an electronic memory configure the hardware processing circuitry to perform one or more of the functions discussed below with respect to <FIG>.

In operation <NUM>, a security token is received. For example, as discussed above with respect to each of <FIG> and <FIG>, the token forensics server <NUM> and the token validation server <NUM> respectively receive token information from enterprise servers <NUM> and <NUM>.

In operation <NUM>, an issuer of the token is determined. For example, as discussed above with respect to <FIG>, a notification or token includes an identifier of an issuer of the token in at least some embodiments. The field <NUM> facilitates the determination of operation <NUM> in at least some embodiments. Decision operation <NUM> determines whether the issuer is online. For example, some embodiment monitor connectivity with a token issuer, such as a token issuer running on the token issuing server <NUM> and/or <NUM>. If the monitoring detects that the token issuer is unresponsive, then decision block <NUM> determines the issuer is not online. Otherwise, the token issuer is determined to be online, in which case process <NUM> moves to decision block <NUM>.

Decision block <NUM> determines whether the issuer indicates the token is valid. For example, in some embodiments, a token issuer provides an API that provides for validation of tokens provided by the issuer. Thus, in some embodiments, decision operation <NUM> sends a message or otherwise invokes such an API provided by the token issuing authority to determine validity of the token. If the token is not valid, process <NUM> moves from decision block <NUM> to operation <NUM>, discussed below. If the issuer indicates the token is valid, process <NUM> moves from decision operation <NUM> to decision operation <NUM>, discussed below.

If the issuer is not online, process <NUM> moves from decision operation <NUM> to decision operation <NUM>, which determines whether the issuer is in good standing. Whether the issuer is in good standing or not may relate to whether tokens issued by the issuer are generally determined to be valid. For example, as discussed above with respect to <FIG>, the client table tracks results of token validations and may include, in some embodiments, an identification of an issuer of each token subject to validation (e.g. via field <NUM>). If the number or percentage of token issued by an issuer are determined to meet a predefined criterion (e.g. above a predetermined good standing threshold), then, in some embodiments, the issuer is considered to be in good standing. If the predefined criterion is not met, the issuer is considered to not be in good standing in at least some embodiments. If the issuer is not in good standing, process <NUM> moves from decision operation <NUM> to operation <NUM>, discussed below. Otherwise, process <NUM> moves from decision operation <NUM> to decision operation <NUM> which determines how long the issuer has been down (offline).

As discussed above, some embodiments monitor connectivity to a token issuing authority and track when/if a token issuing authority is available and/or unavailable. If the issuer has been down for longer than a predetermined downtime threshold, process <NUM> moves from decision operation <NUM> to operation <NUM>, discussed below. Otherwise, process <NUM> moves from decision operation <NUM> to decision operation <NUM>.

Decision operation <NUM> determines whether a sequence number of the token is within a range or confidence interval. For example, as discussed above with respect to <FIG>, a confidence interval is determined, in some embodiments, for a token issuer based on a previous history of token issuances (e.g. as discussed above with respect to <FIG>). In some embodiments, decision operation <NUM> implements one or more of the functions discussed above with respect to <FIG>.

If the sequence number of the token falls outside the confidence interval or predetermined range for the issuer, process <NUM> moves from decision operation <NUM> to operation <NUM>, discussed below. If the sequence number of the tokens falls within the confidence interval, process <NUM> moves from decision operation <NUM> to decision operation <NUM>, which determines whether a caller is trustworthy.

As discussed above with respect to <FIG>, some embodiments determine a percentage of caller token validation affects that succeed and/or fail. If the percentage meets a criterion or otherwise is above a trust threshold, some embodiments conclude that the caller (e.g. service <NUM> and/or service <NUM>). In some embodiments, the percentage is determined based on a number of validation events that occur within a moving elapsed time (e.g. in the last one, two, three, four, or five minutes). If the caller is not determined to be trustworthy, process <NUM> moves from decision operation <NUM> to operation <NUM>, otherwise, process <NUM> moves from decision operation <NUM> to <NUM>.

Operation <NUM> determines the token is valid while operation <NUM> determines the token is invalid. In some embodiments, invalid tokens are added to an inspection queue (e.g. <NUM> or <NUM>). If the token is confirmed to be invalid, some embodiments cause a reset and/or regeneration of a private/public key pair for the token issuing authority. In other words, if the digital signature of a token is valid, but the token itself is invalid (e.g. as determined by one or more of the decision operations <NUM>, <NUM>, <NUM>, or <NUM>), it may indicate the private key of the token issuing authority has been compromised, and a fraudulent or otherwise nefarious actor is generating fraudulent tokens.

<FIG> illustrates a block diagram of an example machine <NUM> upon which any one or more of the techniques (e.g., methodologies) discussed herein may perform. The machine <NUM> may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile telephone, a smart phone, a web appliance, a network router, switch or bridge, a server computer, a database, conference room equipment, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. In various embodiments, machine <NUM> may perform one or more of the processes described above with respect to <FIG> above.

Examples, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms (all referred to hereinafter as "modules").

The term "machine readable medium" may include any medium that is capable of storing, encoding, or carrying instructions for execution by the machine <NUM> and that cause the machine <NUM> to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting machine readable medium examples may include solid-state memories, and optical and magnetic media. Specific examples of machine readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; Random Access Memory (RAM); Solid State Drives (SSD); and CD-ROM and DVD-ROM disks. In some examples, machine readable media may include non-transitory machine readable media. In some examples, machine readable media may include machine readable media that is not a transitory propagating signal.

The instructions <NUM> may further be transmitted or received over a communications network <NUM> using a transmission medium via the network interface device <NUM>. The machine <NUM> may communicate with one or more other machines utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks (e.g., Institute of Electrical and Electronics Engineers (IEEE) <NUM> family of standards known as Wi-Fi®, IEEE <NUM> family of standards known as WiMax®), IEEE <NUM>. <NUM> family of standards, a Long Term Evolution (LTE) family of standards, a Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, among others. In an example, the network interface device <NUM> may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network <NUM>. In an example, the network interface device <NUM> may include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniques. In some examples, the network interface device <NUM> may wirelessly communicate using Multiple User MIMO techniques.

In an example, the whole or part of one or more computer systems (e.g., a standalone, client, or server computer system) or one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software may reside on a machine-readable medium.

Claim 1:
A method performed by hardware processing circuitry (<NUM>), comprising:
receiving a plurality of notifications (<NUM>), each notification indicating issuance of a security token, wherein an issuer (<NUM>) of each security token is a first token issuing authority;
decoding, from the plurality of notifications (<NUM>), a corresponding plurality of token sequence numbers (<NUM>);
determining, from the plurality of notifications, a rate of change (<NUM>) of the plurality of token sequence numbers (<NUM>), the rate of change (<NUM>) indicating a number of increments or decrements of a baseline sequence number that occur per unit time;
receiving a first security token (<NUM>) at a first time;
determining an issuer of the first security token is the first token issuing authority;
determining a digital signature (<NUM>) of the first security token (<NUM>) is valid;
determining the first token issuing authority is offline;
responsive to determining the first token issuing authority is offline, determining, based on the first time and the rate of change (<NUM>), a token sequence number confidence interval of the first security token issuing authority (<NUM>);
determining a token sequence number (<NUM>) included in the first security token is within the token sequence number confidence interval; and
validating the first security token (<NUM>) based on determining the token sequence number (<NUM>) included in the first security token (<NUM>) is within the token sequence number confidence interval.