Method, medium and system for verifying secure token

Abstract

The embodiment of the invention relates to a method, a medium and a system for verifying a security token. The disclosed embodiments provide for detection of fraudulent electronic security tokens. The cracked private key allows forgery of the electronic security token, which then allows access to the computer resource. Some embodiments track serial numbers issued by a token issuer, and then can predict serial numbers issued forward by the token issuer. Some embodiments also determine the validity of the token based at least in part on a service or client attempting to access the resource using the token. For example, some disclosed embodiments maintain reputation data for a client or service utilizing an electronic token, and determine whether the token is likely to be valid based on the client or service reputation.

Description

[0001] This application is a divisional application of the Chinese invention patent application with application date of October 21, 2020, application number 202080076540.1, and invention name “Methods, media and systems for verifying security tokens”. Technical Field

[0002] The present disclosure relates generally to the field of computers, and more particularly to false positive reduction in electronic token counterfeit detection. Background Art

[0003] Security tokens are a common mechanism for providing secure access to resources in modern computer systems. To ensure validity, security tokens are usually signed by the issuer of the security token. The issuer maintains a private key that is used to digitally sign the security token. Verification of a security token can include verifying the digital signature of the security token via the issuer's public key. If the security token has been altered or is not signed by the issuer, verification of the digital signature will fail.

[0004] Unscrupulous parties attempt to generate fraudulent security tokens to gain 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 is easily accomplished if the private key of the token issuer is compromised. Once the private key is known, these unscrupulous parties can fraudulently issue tokens that authorize access to resources controlled by the token issuer. In some cases, access to the private key is obtained via other fraudulent techniques, such as gaining access to system administrative accounts, or other backdoor mechanisms that gain unauthorized access to private key data. Therefore, methods are needed to ensure that token issuance processes are not compromised or to detect when they are compromised. Summary of the invention

[0005] In a first aspect of the present disclosure, a computer-implemented method is provided. The method includes: determining a rate of change of a plurality of token serial numbers from a plurality of notifications, the rate of change indicating the number of increments or decrements of a baseline serial number occurring per unit time, the increments or decrements increasing or decreasing the baseline serial number by a determinable amount; receiving a first security token at a first time, the first security token including a token serial number; in response to determining that an issuer of the first security token is offline, determining a token serial number confidence interval of the issuer based on the first time and the rate of change; and verifying the first security token based on determining that the token serial number included in the first security token is within the token serial number confidence interval. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] In the drawings, which are not necessarily drawn to scale, like numbers may describe similar components in different views. Like numbers with different letter suffixes may represent different instances of similar components. The drawings generally illustrate various embodiments discussed in this document by way of example and not limitation.

[0007] Figure 1 is an overview diagram of a system that implements one or more of the disclosed embodiments.

[0008] Figure 2 is an overview diagram of a system that implements one or more of the disclosed embodiments.

[0009] Figure 3 Data structures that may be implemented in one or more of the disclosed embodiments are shown.

[0010] Figure 4 Methods of predicting token sequence numbers implemented in at least some disclosed embodiments are illustrated.

[0011] Figure 5 are example portions of tokens and / or notifications and / or messages that may be implemented in one or more of the disclosed embodiments.

[0012] Figure 6 is a flow diagram of a process for validating a token implemented in one or more of the disclosed embodiments.

[0013] Figure 7 is a flow diagram of a process for validating a token implemented in one or more of the disclosed embodiments.

[0014] Figure 8 A block diagram of an example machine in which one or more disclosed embodiments may be implemented is illustrated. DETAILED DESCRIPTION

[0015] The following description and the accompanying 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 those of other embodiments, or replaced by those of other embodiments. The embodiments set forth in the claims encompass all available equivalents of those claims.

[0016] The disclosed embodiments provide for the detection of fraudulent electronic security tokens. As described above, in some cases, the private key of the token issuing agency is compromised and thus available to unscrupulous parties. These unscrupulous parties can then issue tokens that provide access to computer resources and appear to be valid because they include valid digital signatures.

[0017] Detection of fraudulent security tokens can be performed before providing access based on the token, or after the token has been used to access computer resources. Evaluating the token before using it can reduce unauthorized access to computer resources, but may incur some delay in accessing those resources. Evaluating the token after using it avoids adding additional delays to the access operation but allows some authorized access before the fraudulent token is detected.

[0018] In some disclosed embodiments, security tokens used to access computer resources are evaluated after access has occurred. Thus, these embodiments function as security forensics, identifying compromised tokens after they have been used, but reducing additional future uses of those tokens or tokens generated, for example, using equivalent private keys that may have been compromised. Other embodiments operate before access occurs via the token. These embodiments evaluate tokens for indications of fraudulent activity and prohibit or invalidate tokens that do not meet certain validity criteria.

[0019] Some embodiments track serial numbers issued by a token issuing authority. For example, each token issued by a particular token issuing authority includes a unique serial number. Unique serial numbers ensure that multiple tokens from a token issuing authority are not duplicates of each other and help prevent replay attacks. These disclosed embodiments track serial numbers and are then able to predict serial numbers issued by a particular token issuing authority going forward. If a token issuing authority cannot confirm the validity of a particular token, at least some disclosed embodiments, rather than rejecting the token, compare the token's serial number to a range of serial numbers predicted by tracking serial numbers from this particular authority. In some aspects, a token issuing authority is defined by a private key that the token issuing authority uses to digitally sign tokens. In some aspects, different token issuing authorities may be represented using different private keys.

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

[0021] Some disclosed embodiments utilize one or more of the above-described techniques to reduce the incidence of false positives regarding the detection of fraudulent tokens. For example, some implementations may initially mark a token as invalid based on factors such as whether the token issuing authority is online and able to verify the token. If the token issuing authority cannot be used to verify the token, these implementations may determine that the token is invalid. However, this approach results in a considerable number of valid tokens being classified as invalid. In order to reduce the number of false positives, additional verifications may be performed when these initial indications would otherwise indicate an invalid token. For example, as discussed above, if the token cannot be verified via the original token issuing authority, some of these implementations consider that the client or service attempts to access a computer resource using the token. If the client / service has a relatively good reputation, the token may not be marked as invalid even if the token issuing authority is not available to verify the token. Similarly, if the token issuing authority is unavailable, false positives are reduced by determining whether the token's serial number is within a confidence interval of possible serial numbers for the time of token issuance and the history of token serial numbers from the token issuing authority, as discussed further above. If the serial number falls within the confidence interval, the token is classified as valid (in at least some embodiments), even though other token verification methods may not be available. This reduction in false positives can result in improved operational efficiency. For example, some network operators may dedicate resources to manually investigating tokens that are marked as invalid. To the extent that these resources are allocated to investigating valid tokens that are incorrectly classified as invalid, the costs associated with verifying tokens increase, and fewer resources can be dedicated to investigating tokens that are actually counterfeit or otherwise invalid. Therefore, by increasing the resources available to address security vulnerabilities (such as invalid tokens caused by a compromised private key of a token issuer), the disclosed embodiments not only improve operational efficiency, but also improve computer security.

[0022] Figure 11 is an overview diagram of a system that implements one or more of the disclosed embodiments. System 100 includes a token issuing server 102, a service 104, an enterprise server 106, and a token forensics system 108. System 100 also includes a token data repository 110. The token issuing server 102 issues tokens and stores information related to the issued tokens in the token data repository 110. In some embodiments, there is generally a 1:1 mapping between the token issuing server and the token issuing agency. In some other aspects, multiple token issuing servers can issue tokens for a single token issuing agency (e.g., multiple servers may be required to achieve the desired throughput). In some embodiments, the token issuing server 102 issues tokens for a single token issuing agency in some embodiments. In some aspects, each token issuing agency has specific network connection information that provides connectivity to the token issuing agency. For example, a single token issuing agency can accept token requests, for example, via a specific combination of host name / Internet Protocol (IP) address and / or destination port number.

[0023] In some embodiments, the token issuing server provides a token to the service 104 based on the request. The service 104 requests a specific function from the enterprise server 106. For example, in some embodiments, the service 104 requests access to a file, or the execution of certain computing operations or functions from the enterprise server 106. In order to complete the function requested by the service 104, the enterprise server 106 needs to provide a valid electronic security token, such as a valid token provided by the token issuing server 102. The enterprise server 106 verifies the token provided by the service 104 in part by consulting the original token issuing server 102 or the token data repository 110. For example, in some embodiments, the token is digitally signed using the private key of the token issuing server. In some embodiments, the enterprise server 106 identifies the public key of the token issuing server 102 via the token data repository 110. After verifying the token, the enterprise server 106 performs the service requested by the service 104. As mentioned, the token verification performed by the enterprise server 106 includes: confirming that the digital signature of the token is valid for the token issuing server 102. However, if the private key of the token issuing server is compromised, a fraudulent party can issue tokens and gain malicious access to computer resources provided by the enterprise server 106.

[0024] like Figure 1As shown in , some disclosed embodiments provide a log record 120 indicating the use of a token to a token forensics system 108. The token forensics system 108 performs one or more validity checks to confirm that the token used to access the computer resources of the enterprise server 106 is valid. In addition, the token forensics system 108 implements these validity checks to reduce the probability of generating false positives. For example, in some environments, the token data repository 110 and / or the token issuing server 102 are inaccessible. This inaccessibility may be caused by a general network interruption between the token forensics system 108 and the token data repository 110 and / or the token issuing server 102. Alternatively, one or more of the token data repository 110 and / or the token issuing server 102 may not respond due to internal problems. Therefore, when one or more of the token data repository 110 and / or the token issuing server 102 are unavailable, the token forensics system 108 cannot perform some verification functions. In some previous implementations, the token forensics system 108 would consider this situation to indicate that the token itself is invalid, and would provide the token to the inspection queue 130.

[0025] In the event of a verification failure due to the token data repository 110 and / or the token issuing server 102 being unavailable to the token forensics system 108, the check queue becomes populated with one or more tokens that are actually valid but are incorrectly marked as invalid due to the inaccessibility. As further described below, some disclosed embodiments reduce the inclusion of valid tokens in the check queue 130 by performing additional checks when one or more of the token data repository 110 and / or the token issuing server 102 are unavailable. This reduces the number of valid tokens included in the check queue 130. In embodiments that rely on manual checking of tokens located in the check queue, the reduction in false positives provided by the disclosed embodiments can provide significant cost and personnel savings when compared to existing methods.

[0026] Figure 2 200 is an overview diagram of a system that implements one or more disclosed embodiments of the embodiments. System 200 includes a token issuance server 202, a service 204, an enterprise server 206, and a token verification server 208. System 200 and Figure 1200 is that, with system 200, the verification performed by token verification server 208 occurs before the computer resource is accessible via the token. Thus, upon receiving a request to access a computer resource from service 204, enterprise server 106 provides the token to token verification server 208 via message 220a. Token verification server 208 then performs one or more verifications to determine whether the token is likely to be valid. The verification performed by token verification server 208 relies on one or more of token issuing server 202 and / or token data repository 210. Token verification server 208 provides its verification results back to enterprise server 106 via message 220b. Thus, Figure 2 The implementation of system 200 and Figure 1 The difference of system 100 is that Figure 1 The implementation evaluates token validity after the token has been used to access computer resources. System 100 provides improved response time for access to those computer resources by reducing the amount of validation performed on the token before granting access. Token forensics is then performed offline without any latency requirements imposed by the need to efficiently and quickly access computer resources. In some embodiments, the system 200 and Figure 2 The illustrated embodiment results in increased latency in access to computer resources by performing additional token validation (e.g., via token validation server 208) prior to granting access to computer resources based on the token. System 200 benefits from this additional token validation by reducing access to computer resources provided based on invalid tokens.

[0027] Figure 3 1 shows a data structure that can be implemented in one or more of the disclosed embodiments. Figure 3 The discussion of the data structures illustrated in the data structures refers to the data structures as relational database tables, but the skilled person will appreciate that various data structure types are implemented in various embodiments. For example, various embodiments may utilize non-relational data storage, traditional in-memory data structures such as linked lists, trees, arrays, or other structures.

[0028] Figure 3A token table 302, an issuer table 311, and a client tracking table 321 are shown. The token table 302 stores records of fields that define a token. The token table 302 includes a token identifier field 304, a digital signature 306, a serial number 308, an issuer identifier field 309, and an issue time 310. The token identifier field 304 uniquely identifies the token. The digital signature 306 stores a digital signature of the token. In some embodiments, the digital signature 306 is generated by the token issuer using a private key of the token issuer. In these embodiments, the digital signature is decoded via the public key of the token issuer, as further explained below. The serial number field 308 stores a serial number of the token. The serial number is assigned to the token by the token issuer. Although the serial number field 308 is described as a "number", in some embodiments, the serial number itself may not be a number, but may include at least alphabetic and numeric characters. The issuer identifier field 309 identifies the issuer of the token. For example, some embodiments may include multiple token issuing servers, such as those described above with respect to Figure 1 and Figure 2 The token issuing server 102 and / or the token issuing server 202 in question. The issue time field 310 stores the issue time for a particular token.

[0029] The issuer table 311 includes an issuer identifier field 312, a public key field 314, a baseline sequence number field 315, a baseline time field 316, a rate field 317, and an online indicator field 318. The issuer identifier field 312 uniquely identifies a token issuer. Therefore, in an embodiment where multiple token issuers (e.g., the token issuing server 102 and / or the token issuing server 202) are implemented, the issuer identifier field 312 uniquely identifies a specific one of the token issuers. The issuer identifier field 312 can be cross-referenced with the issuer identifier field 309 of the token table 302. The public key field 314 stores a public key for the token issuer identified via the issuer identifier field 312. The baseline sequence number field 315 stores a baseline sequence number for the token issuer.

[0030] The baseline sequence number is a sequence number generated by the token issuing authority at a defined baseline time. The specific baseline time is indicated by the time field 316. The rate field 317 determines the rate of change for the baseline sequence number. In various embodiments, the rate field specifies the rate as an increment (or decrement) of the baseline sequence number per second, millisecond, or other predetermined time period. The rate field 317 stores a value that, in some embodiments, is used in conjunction with the baseline sequence number field 315 and the baseline time field 316 to infer or predict a sequence number or sequence number range for a token generated by the issuing authority (identified via the issuing authority identifier field 312) at an additional second time. The online flag field 318 indicates whether the issuing authority has been detected as online or offline.

[0031] The client tracking table 321 includes a client identifier field 322, a token validation result 324, a time field 326, and an issuer field 328. The client identifier field 322 uniquely identifies a particular client. In this context, a client is an entity that seeks access to a computer resource via a token. For example, in at least some embodiments, service 104 and / or service 204 are identified as clients in the client table 321. The validation result field 324 stores the result of the token validation provided by the client. Thus, if a valid token is provided, the validity is stored in the validation result field, and if an invalid token is provided by the client, the invalidity is also recorded in the validation result field.

[0032] The time field 326 stores the time when the verification result was recorded. In some embodiments, the time field 326 is used to provide a moving average of the verification results for a particular client. Older results can be discounted relative to newer results, or can be eliminated from the determination of the client's reputation as a whole and deleted entirely from the client tracking table 321 after reaching a threshold age.

[0033] The issuer field 328 stores the issuer of the token that provided the token validation results stored in field 324. Storing the issuer field 328 in the client tracking table allows the client tracking table to perform an additional function, namely tracking validation results for a particular token issuer. For example, in some aspects, a percentage of token validations for tokens from a particular token issuer within a threshold time period is determined to determine whether the token issuer is reputable. As further explained below, if the percentage of token validations for tokens issued by a particular token issuer is above a threshold (or meets a criteria), then the token issuer is considered reputable, otherwise they are considered to be disreputable.

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

[0035] Figure 4 Methods of predicting token sequence numbers implemented in at least some disclosed embodiments are illustrated. Figure 4 A series of tokens issued in chronological order is shown. Time is shown via horizontal axis 402. Each of the tokens has a serial number 403a to 403e. The serial numbers 403a to 403e are shown as increasing by two (2) with each issuance, although in some embodiments, how the serial numbers change sequentially may be different. For example, the serial numbers may be incremented by more or less than the two (2) units shown. In some embodiments, the serial numbers may decrease over time. The issuance of a series of tokens is represented by a series of vertical arrows 404a to 404e. In some embodiments, the vertical arrows represent notifications. Some disclosed embodiments store information indicating the time at which each of the tokens was issued, as shown by time 406a to 406e.

[0036] Some disclosed embodiments determine the elapsed time 408 for a series of token issuances, as represented by 404a to 404e. These embodiments also indicate the differences 410 in the token sequence numbers 403a to 403e that occur during the elapsed time 408. Based on this information, these embodiments determine the rate at which the sequence numbers 403a to 403e change. In some embodiments, this rate information is used to predict the sequence numbers generated by the token issuing authority. In some embodiments, a baseline sequence number (e.g., 403e) is selected from which additional sequence numbers and their corresponding issuance times are predicted. Figure 4 Predicted sequence numbers 420 based on determined rate information (eg, stored in rate field 317) and baseline sequence number information (eg, stored in field 315) are shown, including sequence numbers 403f and 403g.

[0037] Figure 5 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 107 and / or message 220a may include the following regarding portion 500 and Figure 5 One or more of the fields in question.

[0038] Portion 500 includes a serial number field 504, an issuing authority field 506, a digital signature field 508, and an issue time field 509. Serial number field 504 stores a serial number for a token. As discussed above, in some embodiments, a token issuing authority may include a unique serial number for each token issued by the token issuing authority. The issuing authority is identified via field 506. Digital signature field 508 stores a digital signature. The digital signature is generated based on at least some of the contents of portion 500 (without the digital signature itself). In some embodiments, the digital signature stored in field 508 is generated using a private key of the issuing authority (identified via field 506). Issue time field 509 stores a value indicating the time at which the token was issued.

[0039] Figure 6 is a flow chart of a process for verifying a token implemented in one or more of the disclosed embodiments. Figure 6 One or more of the functions discussed are performed by hardware processing circuitry. For example, in some embodiments, instructions stored in an electronic memory configure the hardware processing circuitry to perform the following Figure 6 One or more of the functions discussed. Note that this specification may label multiple determinations or other operations as, for example, a first determination, a second determination, a third determination, in order to distinguish between different determinations (or other operations). However, such labeling using first, second, third, etc. should not be used to imply a particular order of the labeled operations. Instead, such labeling is only to ensure that multiple operations with similar names or descriptions are clearly identified.

[0040] In operation 610, a plurality of notifications are received. Each of the notifications indicates that a token is issued by a token issuing authority. For example, as described above with respect to Figure 1 As discussed, the enterprise server 106 provides notification 107 to the token forensics system 108. In some other embodiments, the notification is read from a data store such as the token data store 110. Similarly, in Figure 2 , enterprise server 206 is depicted as providing a token to token validation server 208 via message 220a. In at least some disclosed embodiments, message 220a is considered a notification.

[0041] In operation 620, a token serial number is decoded from each of the notifications. For example, as described above with respect to Figure 5 As discussed in the example notification in , in some embodiments, the notification includes a token sequence number field 504, which may be provided for decoding a token sequence number from each of the notification(s) / message(s).

[0042] In operation 625, the rate of change of the token serial number is determined. In some embodiments, operation 625 determines the elapsed time between issuance of multiple tokens. For example, in some embodiments, the issuance time of each token is included in a corresponding notification for the token (e.g., such as Figure 5 Alternatively, the elapsed time is determined based on the elapsed time between receipt of the notification itself. The difference in the serial number of the token received in the notification is also determined. For example, Figure 4 In some embodiments, the difference between token serial numbers 403a and 403e and the elapsed time 408 between the receipt of notifications 404a and 404e of the respective token serial numbers 403a and 403e is determined. The rate of change of the token serial number is then determined based on the elapsed time of the token issuance or notification and the observed change in the serial number during the elapsed time.

[0043] In operation 630, a first security token is received at a first time. For example, as discussed above, the token forensics system 108 or the token verification server 208 receives token information from the enterprise server 106 or 206, respectively.

[0044] In operation 635, the digital signature of the first security token is verified. For example, in some embodiments, operation 635 verifies the digital signature of the first security token via data included in the token itself (e.g., Figure 5 The token issuing authority of the token is determined by the token / notification in the token / notification field 508. Based on the issuing authority information, the public key of the issuing authority is determined (e.g., via field 314). The data of the token is then decoded based on the public key to ensure the validity of the digital signature.

[0045] In operation 640, a confidence interval or range of a token serial number is determined based on the first time and the rate of change at which the first security token is received. As discussed above, some embodiments store a baseline sequence number and a baseline time, from which, along with the determined rate of change, can be used to predict or infer a mean predicted sequence number for the first time. In some embodiments, operation 640 also determines a confidence interval around a mean sequence number value for tokens issued by a token issuing authority. Alternatively, some embodiments determine a range of possible values ​​for a token serial number from a particular token issuing authority at a particular point in time. The mean predicted sequence number can be determined based on the following equation 1:

[0046] Mean sequence number = BSN + (rate * issuance time – baseline time), (1)

[0047] in:

[0048] The mean sequence number is the predicted sequence number at the time of issuance.

[0049] The BSN is a baseline sequence number (e.g., field 315) that can be used in conjunction with the rate to predict the sequence number.

[0050] IssueTime is the time at which the token was issued (e.g., (alternatively, the current time or receipt time of the token may be used),

[0051] Baseline Time is the baseline time used in conjunction with Rate and BSN to predict the sequence number (eg, field 316).

[0052] In operation 650, it is determined whether the serial number of the first security token is within a confidence interval or range for the issuer of the first security token. In some embodiments, operation 650 determines whether the serial number is within a predetermined threshold confidence interval of the mean of the predicted serial numbers at the time of issuance of the token (or the current time). Various thresholds may be used, including 80%, 85%, 90%, 95%, 96%, 97%, 98%, 99%, or any confidence interval.

[0053] In operation 660, the security token is validated (or invalidated) based on whether the serial number of the first security token is within a predetermined confidence interval and / or within a range determined as discussed above.

[0054] Figure 7 is a flow chart of a process for verifying a token implemented in one or more disclosed embodiments. Figure 7 One or more functions discussed are performed by hardware processing circuits. For example, in some embodiments, instructions stored in an electronic memory configure the hardware processing circuits to perform the following Figure 7 The feature or features being discussed.

[0055] In operation 710, a security token is received. For example, as described above with respect to Figure 1 and Figure 2 As discussed in each of the figures in , the token forensics system 108 and the token verification server 208 receive token information from the enterprise servers 106 and 206, respectively.

[0056] In operation 720, the issuer of the token is determined. For example, as described above with respect to Figure 5 As discussed, in at least some embodiments, the notification or token includes an identifier of the issuer of the token. In at least some embodiments, field 506 facilitates the determination of operation 720. Decision operation 730 determines whether the issuer is online. For example, some embodiments monitor connectivity with a token issuer, such as a token issuer running on a token issuing server 102 and / or 202. If the monitoring detects that the token issuer is not responding, then decision operation 730 determines that the issuer is not online. Otherwise, the token issuer is determined to be online, in which case process 700 moves to decision operation 735.

[0057] Decision operation 735 determines whether the issuer indicates that the token is valid. For example, in some embodiments, the token issuer provides an API that provides verification of the token provided by the issuer. Therefore, in some embodiments, decision operation 735 sends a message or otherwise calls such an API provided by the token issuing authority to determine the validity of the token. If the token is invalid, process 700 moves from decision operation 735 to operation 790, as discussed below. If the issuer indicates that the token is valid, process 700 moves from decision operation 735 to decision operation 770, as discussed below.

[0058] If the issuer is not online, process 700 moves from decision operation 730 to decision operation 740, which determines whether the issuer is reputable. Whether the issuer is reputable may be related to whether tokens issued by the issuer are generally determined to be valid. For example, as described above with respect to Figure 3 As discussed, the client table tracks the results of token validation and may include, in some embodiments, an identification of the issuer of each token that was validated (e.g., via field 328). If it is determined that the number or percentage of tokens issued by the issuer meets predetermined criteria (e.g., is above a predetermined good reputation threshold), then in some embodiments, the issuer is considered to be reputable. If the predefined criteria are not met, the issuer is considered to be in disreputable in at least some embodiments. If the issuer is in disreputable, process 700 moves from decision operation 740 to operation 790, as discussed below. Otherwise, process 700 moves from decision operation 740 to decision operation 750, which determines how long the issuer has been down (offline).

[0059] As discussed above, some embodiments monitor connectivity with the token issuing authority and track when / whether the token issuing authority is available and / or unavailable. If the issuing authority has been down for more than a predetermined downtime threshold, the process 700 moves from decision operation 750 to operation 790, as discussed below. Otherwise, the process 700 moves from decision operation 750 to decision operation 760.

[0060] Decision operation 760 determines whether the token's serial number is within a confidence interval or range. Figure 6 As discussed, in some embodiments, based on the previous history of token issuance (e.g., as discussed above with respect to Figure 4 In some embodiments, the determination operation 760 implements the above Figure 6 One or more of the features in question.

[0061] If the serial number of the token falls outside the issuer's confidence interval or predetermined range, process 700 moves from decision operation 760 to operation 790, as discussed below. If the serial number of the token falls within the confidence interval, process 700 moves from decision operation 760 to decision operation 770, which determines whether the caller is trustworthy.

[0062] As mentioned above Figure 3 As discussed, some embodiments determine a percentage of successful and / or failed caller token validation impacts. If the percentage meets the criteria or is above a trust threshold, some embodiments determine that the caller (e.g., service 104 and / or service 204) is untrustworthy. In some embodiments, the percentage is determined based on the number of validation events that occurred during the time that the move has passed (e.g., within the last minute, two minutes, three minutes, four minutes, or five minutes). If the caller is determined to be untrustworthy, process 700 moves from determination operation 770 to operation 990, otherwise, process 700 moves from determination operation 770 to 780.

[0063] Operation 780 determines that the token is valid, while operation 790 determines that the token is invalid. In some embodiments, the invalid token is added to a check queue (e.g., 130 or 230). If the token is determined to be invalid, some embodiments cause a reset and / or regeneration of the private key / public key pair for the token issuing authority. In other words, if the digital signature of the token is valid, but the token itself is invalid (e.g., as determined by one or more of the decision operations 735, 740, 750, or 760 in the decision operation), it can indicate that the private key of the token issuing authority has been compromised and that fraudulent or other unscrupulous parties are generating fraudulent tokens.

[0064] Figure 8 A block diagram of an example machine 800 on which one or more of any of the techniques discussed herein (e.g., methods) may be performed is illustrated. In alternative embodiments, the machine 800 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine 800 may operate in the capacity of a server machine, a client machine, or both in a server-client network environment. In an example, the machine 800 may act as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. The machine 800 may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile phone, a smart phone, a web appliance, a network router, a switch or a bridge, a server computer, a database, a meeting room device, or any machine capable of executing instructions (sequentially or otherwise) that specify actions to be taken by the machine. In various embodiments, the machine 800 may perform the above-described Figures 1 to 7Further, while only a single machine is illustrated, the term “machine” shall also be understood to include any collection of machines that individually or jointly execute (or multiple) sets of instructions to perform one or more of any of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), and other computer cluster configurations.

[0065] As described herein, examples may include or may operate on a logic or multiple components, modules, or mechanisms (hereinafter all referred to as "modules"). A module is a tangible entity (e.g., hardware) that is capable of performing a specified operation and may be configured or arranged in a certain manner. In an example, a circuit may be arranged as a module in a particular manner (e.g., internally or relative to an external entity such as other circuits). In an example, all or part of one or more computer systems (e.g., independent, client or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application parts, or applications) as a module that operates to perform a specified operation. In an example, the software may reside on a machine-readable medium. In an example, the software causes the hardware to perform a specified operation when executed by the underlying hardware of the module.

[0066] Thus, the term "module" is understood to encompass a tangible entity, i.e., an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., temporarily) configured (e.g., programmed) to operate in a particular manner or to perform any part or all of the operations described herein. Considering the example of a temporarily configured module, each module in the module does not need to be instantiated at any time. For example, in the case where the module includes a general-purpose hardware processor configured using software, the general-purpose hardware processor can be configured as corresponding different modules at different times. For example, the software can configure the hardware processor accordingly to constitute a particular module at one time instance and another module at another time instance.

[0067] The machine (e.g., computer system) 800 may include a hardware processor 802 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 804, and a static memory 806, some or all of which may communicate with each other via an interconnection link (e.g., a bus) 808. The machine 800 may also include a display unit 810, an alphanumeric input device 812 (e.g., a keyboard), and a user interface (UI) navigation device 814 (e.g., a mouse). In an example, the display unit 810, the input device 812, and the UI navigation device 814 may be a touch screen display. The machine 800 may additionally include a storage device (e.g., a drive unit) 816, a signal generating device 818 (e.g., a speaker), a network interface device 820, and one or more sensors 821, such as a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensors. The machine 800 may include an output controller 828, such as a serial (e.g., Universal Serial Bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate with or control one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0068] The storage device 816 may include a machine-readable medium 822 on which is stored one or more data structure sets or instructions 824 (e.g., software) embodied or used by any one or more of the techniques or functionality described herein. The instructions 824 may also reside, completely or at least partially, within the main memory 804, within the static memory 806, or within the hardware processor 802 during execution thereof by the machine 800. In an example, one or any combination of the hardware processor 802, the main memory 804, the static memory 806, or the storage device 816 may constitute a machine-readable medium.

[0069] Although the machine-readable medium 822 is illustrated as a single medium, the term “machine-readable medium” may include a single medium or multiple media (eg, a centralized or distributed database, and / or associated caches and servers) configured to store one or more instructions 824 .

[0070] The term "machine-readable medium" may include any medium capable of storing, encoding, or carrying instructions for execution by the machine 800 and causing the machine 800 to perform one or more of any of the technologies of the present disclosure, or any medium 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 memory 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; 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, the machine-readable medium may include non-transitory machine-readable media. In some examples, the machine-readable medium may include machine-readable media that is not a transient propagation signal.

[0071] The instructions 824 may also be transmitted or received over a communication network 826 via the network interface device 820 using a transmission medium. The machine 800 may communicate with one or more other machines using any of a variety of transmission 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), a mobile telephone network (e.g., a cellular network), a plain old telephone (POTS) network, and a wireless data network (e.g., the Institute of Electrical and Electronics Engineers (IEEE) 802.11 series of standards, known as IEEE 802.16 series of standards, known as ), IEEE 802.15.4 family of standards, Long Term Evolution (LTE) family of standards, Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, and the like. In an example, the network interface device 820 may include one or more physical jacks (e.g., Ethernet, coaxial, or telephone jacks) or one or more antennas to connect to the communication network 826. In an example, the network interface device 820 may include multiple antennas to use at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) technology for wireless communication. In some examples, the network interface device 820 may use multi-user MIMO technology for wireless communication.

[0072] As described herein, examples may include or may operate on logic or multiple components, modules, or mechanisms. A module is a tangible entity (e.g., hardware) that is capable of performing a specified operation and may be configured or arranged in some manner. In an example, a circuit arrangement may be used as a module in a particular manner (e.g., internally or relative to an external entity such as other circuits). In an example, all or part of one or more computer systems (e.g., independent, client or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application parts, or applications) as a module that performs a specified operation. In an example, the software may reside on a machine-readable medium. In an example, the software causes the hardware to perform a specified operation when executed by the underlying hardware of the module.

[0073] Example 1 is a method performed by a hardware processing circuit, comprising: receiving multiple notifications, each notification indicating the issuance of a security token, wherein the issuer of each security token is a first token issuing agency; decoding corresponding multiple token serial numbers from the multiple notifications; first determining the rate of change of the multiple token serial numbers from the multiple notifications; receiving a first security token at a first time; second determining that the issuer of the first security token is the first token issuing agency; third determining that the digital signature of the first security token is valid; based on the first time and the rate of change, fourth determining a token serial number confidence interval of the first security token issuing agency; fifth determining that the token serial number included in the first security token is within the token serial number confidence interval; and verifying the first security token based on the fifth determination.

[0074] In Example 2, the subject matter of Example 1 optionally includes: a sixth determination that a second security token issuing authority is offline during a time period; receiving a second security token during the time period; a seventh determination that the issuer of the second security token is the second security token issuing authority; and verifying the second security token based on the sixth determination and the seventh determination.

[0075] In Example 3, the subject matter of any one or more of Examples 1 to 2 may optionally include: receiving a third security token from the first service; a sixth determination that a verification rate of the token received from the first service meets a criterion; and verifying the third security token based on the sixth determination.

[0076] In Example 4, the subject matter of Example 3 optionally includes: wherein the first security token is received from a second service, the method further comprising: storing an indication of an association between verification of the first security token and the second service; determining a verification rate of tokens received from the second service based on the stored indication; and verifying a fourth security token based on the verification rate.

[0077] In Example 5, the subject matter of any one or more of Examples 1 to 4 may optionally include: receiving a second security token at a second time; verifying a second digital signature of the second security token; sixthly determining a second token serial number of the second security token; seventhly determining a second range of the token serial number based on the second time and the rate of change; eighthly determining that the second token serial number is outside the determined second range; and, via the eighth determination, generating a notification indicating that the private key of the first security token issuing agency has been cracked.

[0078] In Example 6, the subject of Example 5 optionally includes: receiving a third security token from a service; a ninth determination that a verification rate of the token received from the service meets a standard; a tenth determination that the issuer of the third security token is a second security token issuing agency; and based on the tenth determination, generating a notification indicating that a private key of the second security token issuing agency is included.

[0079] In Example 7, the subject matter of any one or more of Examples 1 to 6 optionally includes: monitoring connectivity with a first security token issuing authority; and based on the monitoring, determining that the first security token issuing authority is not online, wherein the fourth determination of the token serial number confidence interval is responsive to determining that the first security token issuing authority is not online.

[0080] In Example 8, the subject matter of Example 7 may optionally include determining a percentage of valid tokens indicating that the issuer of the corresponding valid tokens is the first security token issuing authority, wherein the fourth determination of the token serial number confidence interval is responsive to the percentage satisfying a criterion.

[0081] Example 9 is a system comprising: a hardware processing circuit; one or more hardware memories comprising instructions, which when executed configure the hardware processing circuit to perform operations, the operations comprising: receiving multiple notifications, each notification indicating the issuance of a token, wherein the issuer of each security token is a first security token issuing agency; decoding corresponding multiple token serial numbers from the multiple notifications; first determining the rate of change of multiple token serial numbers from the multiple notifications; receiving a first security token at a first time; second determining that the issuer of the first security token is the first security token issuing agency; third determining that the digital signature of the first security token is valid; based on the first time and the rate of change, fourth determining the token serial number confidence interval of the first security token issuing agency; fifth determining that the token serial number included in the first security token is within the token serial number confidence interval; and verifying the first security token based on the fifth determination.

[0082] In Example 10, the subject matter of Example 9 optionally includes that the operation further includes: a sixth determination that the second security token issuing authority is offline during a time period; receiving a second security token during the time period; a seventh determination that the issuer of the second security token is the second security token issuing authority; and verifying the second security token based on the sixth determination and the seventh determination.

[0083] In Example 11, the subject matter of any one or more of Examples 9 to 10 optionally includes that the operation also includes: receiving a third security token from the first service; a sixth determination that a verification rate of the token received from the first service meets a criterion; and verifying the third security token based on the sixth determination.

[0084] In Example 12, the subject matter of Example 11 optionally includes: wherein the first security token is received from a second service, the operation further includes: storing an indication of an association between verification of the first security token and the second service; determining a verification rate of tokens received from the second service based on the stored indication; and verifying a fourth security token based on the verification rate.

[0085] In Example 13, the subject matter of any one or more of Examples 9 to 12 optionally includes that the operation also includes: receiving a second security token at a second time; verifying a second digital signature of the second security token; fifthly determining a second token serial number of the second security token; sixthly determining a second range of the token serial number based on the second time and the rate of change; seventhly determining that the second token serial number is outside the determined second range; and based on the seventh determination, generating a notification indicating that the private key of the first security token issuing agency has been cracked.

[0086] In Example 14, the subject matter of Example 13 optionally includes that the operation also includes: receiving a third security token from a service; an eighth determination that a verification rate of the token received from the service meets a standard; a ninth determination that the issuer of the third security token is a second token issuing agency; and based on the eighth determination, generating a notification indicating that a private key of the second token issuing agency is included.

[0087] In Example 15, the subject matter of any one or more of Examples 9 to 14 optionally includes that the operation also includes: monitoring connectivity with the first security token issuing authority; and based on the monitoring, determining that the first security token issuing authority is not online, wherein the fourth determination of the token serial number confidence interval is responsive to determining that the first security token issuing authority is not online.

[0088] In Example 16, the subject matter of Example 15 optionally includes that the operations further include: determining a percentage of valid tokens indicating that the issuer of the corresponding valid tokens is the first security token issuing authority, wherein the fourth determined confidence interval of the token serial number is responsive to the percentage satisfying a criterion.

[0089] Example 17 is a non-transitory computer-readable storage medium comprising instructions, which, when executed, configure the hardware processing circuit to perform operations, the operations including: receiving multiple notifications, each notification indicating the issuance of a token, wherein the issuer of each security token is a first security token issuing agency; decoding corresponding multiple token serial numbers from the multiple notifications; first determining the rate of change of multiple token serial numbers from the multiple notifications; receiving a first security token at a first time; second determining that the first security token is issued by the first security token issuing agency; third determining that the digital signature of the first security token is valid; based on the first time and the rate of change, fourth determining the token serial number confidence interval of the first security token issuing agency; fifth determining that the token serial number included in the first security token is within the token serial number confidence interval; and verifying the first security token based on the fifth determination.

[0090] In Example 18, the subject matter of Example 17 optionally includes: a sixth determination that the second security token issuing authority is offline during a time period; receiving a second security token during the time period; a seventh determination that the issuer of the second security token is the second security token issuing authority; and verifying the second security token based on the sixth determination and the seventh determination.

[0091] In Example 19, the subject matter of any one or more of Examples 17 to 18 may optionally include: receiving a third security token from the first service; a sixth determination that a verification rate of the token received from the first service meets a criterion; and verifying the third security token based on the sixth determination.

[0092] In Example 20, the subject matter of Example 19 optionally includes: wherein the first security token is received from a second service, and the operation further includes: storing an indication of an association between the verification of the first security token and the second service; determining a verification rate of the token received from the second service based on the stored indication; and verifying a fourth security token based on the verification rate. Therefore, the term "module" is understood to include a tangible entity, that is, an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., temporarily) configured (e.g., programmed) to operate in a specified manner or perform part or all of any operation described herein. Considering the example of a temporarily configured module, each module does not need to be instantiated at any time. For example, in the case where the module includes a general-purpose hardware processor configured using software, the general-purpose hardware processor can be configured as various different modules at different times. The software can configure the hardware processor accordingly, for example, to constitute a specific module at one time instance and to constitute different modules at different time instances.

[0093] Various embodiments may be implemented in whole or in part in software and / or firmware. The software and / or firmware may take the form of instructions contained in or on a non-transitory computer-readable storage medium. Those instructions may then be read and executed by one or more processors to enable the operations described herein to be performed. The instructions may be in any suitable form, such as, but not limited to, source code, compiled code, interpreted code, executable code, static code, dynamic code, etc. Such computer-readable media may include any tangible, non-transitory media for storing information in one or more computer-readable forms, such as, but not limited to, read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory; etc.

Claims

1. A method performed by a hardware processing circuit, comprising: determining a rate of change of a plurality of token sequence numbers from the plurality of notifications, the rate of change indicating a number of increments or decrements of a baseline sequence number occurring per unit time, the increments or decrements increasing or decreasing the baseline sequence number by a determinable amount; receiving, at a first time, a first security token, the first security token comprising a token serial number; In response to determining that the issuer of the first security token is offline, determining a token serial number confidence interval for the issuer based on the first time and the rate of change; as well as The first security token is authenticated based on determining that the token serial number included in the first security token is within the token serial number confidence interval.

2. The method according to claim 1, further comprising: determining that the second issuer was offline during the first time period; receiving a second security token during a second time period; determining that the provider of the second security token is the second issuer; as well as The second security token is verified.

3. The method according to claim 1, further comprising: receiving a third security token from the first service; determining that a verification rate of tokens received from the first service meets a criterion; as well as The third security token is validated based on determining that the validation rate of tokens received from the first service meets the criterion.

4. The method of claim 3, wherein the first security token is received from a second service, the method further comprising: storing an indication of an association between the verification of the first security token and the second service; determining a validation rate of tokens received from the second service based on the stored indication; as well as A fourth security token is validated based on the validation rate of the token received from the second service.

5. The method according to claim 1, further comprising: receiving a second security token at a second time; verifying a second digital signature of the second security token; determining a second token serial number of the second security token; determining a second range of token serial numbers based on the second time and the rate of change; determining that the second token serial number is outside the determined second range; as well as Based on determining that the second token serial number is outside of the determined second range, generating a notification indicating that a private key of the issuer has been compromised.

6. The method according to claim 5, further comprising: receiving a third security token from the service; determining that a validation rate of tokens received from the service satisfies a criterion; as well as Based on determining that the provider of the third security token is the second issuer, a notification is generated indicating that a private key of the second issuer has been compromised.

7. The method according to claim 1, further comprising: receiving the plurality of notifications, each notification indicating the issuance of a security token, wherein the provider of each security token is the issuer; as well as The plurality of token serial numbers are decoded from the plurality of notifications.

8. The method according to claim 1, further comprising: A percentage of valid tokens indicating that a provider of corresponding valid tokens is the issuer of the first security token is determined, wherein the determination of the token serial number confidence interval is responsive to the percentage satisfying a criterion.

9. A system comprising: Hardware processing circuit; One or more hardware memories comprising instructions that, when executed, configure the hardware processing circuit to perform operations comprising: determining a rate of change of a plurality of token sequence numbers from the plurality of notifications, the rate of change indicating a number of increments or decrements of a baseline sequence number occurring per unit time, the increments or decrements increasing or decreasing the baseline sequence number by a determinable amount; receiving, at a first time, a first security token from an issuer, the first security token comprising a token serial number; In response to determining that the issuer is offline, determining a token serial number confidence interval for the issuer based on the first time and the rate of change; and The first security token is authenticated based on determining that the token serial number included in the first security token is within the token serial number confidence interval.

10. The system of claim 9, the operations further comprising: determining that the second issuer was offline during the first time period; receiving a second security token during a second time period; determining that the issuer of the second security token is the second issuer; as well as The second security token is verified.

11. The system of claim 9, the operations further comprising: receiving a third security token from the first service; determining that a verification rate of tokens received from the first service meets a criterion; as well as The third security token is validated based on determining that the validation rate of tokens received from the first service meets the criterion.

12. The system of claim 11, wherein the first security token is received from a second service, the operations further comprising: storing an indication of an association between the verification of the first security token and the second service; determining a validation rate of tokens received from the second service based on the stored indication; as well as A fourth security token is validated based on the validation rate of the token received from the second service.

13. The system of claim 9, the operations further comprising: receiving a second security token at a second time; verifying a second digital signature of the second security token; determining a second token serial number of the second security token; determining a second range of token serial numbers based on the second time and the rate of change; determining that the second token serial number is outside the determined second range; as well as Based on determining that the second token serial number is outside of the determined second range, generating a notification indicating that a private key of the issuer has been compromised.

14. The system of claim 13, wherein the operations further comprise: receiving a third security token from the service; determining that a validation rate of tokens received from the service satisfies a criterion; as well as Based on determining that the provider of the third security token is the second issuer, a notification is generated indicating that a private key of the second issuer has been compromised.

15. The system of claim 9, the operations further comprising: receiving the plurality of notifications, each notification indicating the issuance of a security token, wherein the provider of each security token is the issuer; as well as The plurality of token serial numbers are decoded from the plurality of notifications.

16. The system of claim 9, the operations further comprising: A percentage of valid tokens indicating that providers of corresponding valid tokens are the issuer is determined, wherein the determination of the token serial number confidence interval is responsive to the percentage satisfying a criterion.

17. A non-transitory computer-readable storage medium comprising instructions that, when executed, configure a hardware processing circuit to perform operations comprising: determining a rate of change of a plurality of token sequence numbers from the plurality of notifications, the rate of change indicating a number of increments or decrements of a baseline sequence number occurring per unit time, the increments or decrements increasing or decreasing the baseline sequence number by a determinable amount; receiving, at a first time, a first security token from an issuer, the first security token comprising a token serial number; In response to determining that the issuer is offline, determining a token serial number confidence interval for the issuer based on the first time and the rate of change; as well as The first security token is authenticated based on determining that the token serial number included in the first security token is within the token serial number confidence interval.

18. The non-transitory computer readable storage medium of claim 17, the operations further comprising: determining that the second issuer was offline during the first time period; receiving a second security token during a second time period; determining that the provider of the second security token is the second issuer; as well as The second security token is verified.

19. The non-transitory computer readable storage medium of claim 17, the operations further comprising: receiving a third security token from the first service; determining that a verification rate of tokens received from the first service meets a criterion; as well as The third security token is validated based on determining that the validation rate of tokens received from the first service meets the criterion.

20. The non-transitory computer-readable storage medium of claim 19, wherein the first security token is received from a second service, the operations further comprising: storing an indication of an association between the verification of the first security token and the second service; determining a validation rate of tokens received from the second service based on the stored indication; as well as A fourth security token is validated based on the validation rate of the token received from the second service.

Images