TECHNICAL FIELD

This disclosure relates generally to security and fraud.

BACKGROUND

Computers and mobile devices are increasingly used to perform transactions.

SUMMARY OF THE DISCLOSURE

Computers and mobile devices are increasingly used to perform transactions. Typically, to safeguard the transaction against fraud, a user who requested the transaction can attach a digital signature to the transaction. This digital signature can be generated using a private encryption key that only the user can access. The transaction and the digital signature are then sent to a server that can validate the digital signature using a public encryption key of the user. After the digital signature is validated, the server processes the transaction.

The private and public encryption keys are issued by a certificate authority. For example, the certificate authority generates and sends the private and public encryption keys to the user. The user can then share the public encryption key with as many servers and services as user desires. The certificate authority tracks the status of the private and public encryption keys. For example, the certificate authority can let others know whether the private and public encryption keys are valid for use. If the user notifies the certificate authority that the private and public encryption keys are no longer valid (e.g., because they have been compromised), then the certificate authority can invalidate the private and public encryption keys and issue new private and public encryption keys to the user.

The process of invalidating and issuing new private and public encryption keys, however, has several drawbacks. First, the process may result in delays that cause a desynchronization to occur. For example, because the certificate authority does not publish or push updates to the private and public encryption keys' status, it is up to users and servers to query the certificate authority when the status of these keys is in question. As a result, servers will not know that a public encryption key is invalid unless the servers query the certificate authority or unless a user sends an updated public encryption key to the servers. Until one of these events happens, the servers are desynchronized from the certificate authority. During this desynchronization period, any server that uses the user's, now-invalid, public encryption key to validate the, now invalid, private encryption key would still determine that the validation was successful, even though these keys are invalid. As a result, a hacker who compromised or stole the private encryption key or even the user himself could use this desynchronization period to perform unauthorized transactions. Then, after the desynchronization period, the user can repudiate the transaction and/or seek a refund.

One solution to protect against fraud and the desynchronization period would be for servers to query the certificate authority about the status of a public encryption key when the user sends a transaction request, but this solution would be practically infeasible for the servers. Servers typically process a large amount (e.g., millions) of transactions daily from a plethora of users. If the servers queried the certificate authority for each transaction in addition to processing the transaction, the servers would become overloaded. Additionally, this solution may violate the privacy of the user because the certificate authority would be able to deduce that the user is performing a transaction each time the servers queried the certificate authority.

This disclosure contemplates a security tool (e.g., a mobile device of a user) that improves security by protecting against fraud and the desynchronization period. The security tool intercepts user transaction requests and re-certifies the private encryption key of the user with the certificate authority before sending the transaction requests to servers. The security tool generates and sends messages to the servers that indicate the transaction and the validity of the private encryption key. In this manner, the servers are assured, for each transaction, that the private and public encryption keys are valid before performing the transaction. Additionally, the servers are not burdened with the task of validating the private and public encryption keys. Moreover, the privacy of the user is not violated because, from the certificate authority's perspective, the user is merely requesting a re-certification of his own private encryption key. Certain embodiments of the security tool are described below.

According to an embodiment, an apparatus includes a memory and a hardware processor. The memory stores a private encryption key. The processor intercepts a first transaction request from a user, communicates a first recertification request to a certificate authority that issued the private encryption key, and receives, from the certificate authority, a first message indicating that the private encryption key is valid for use. In response to the first message, the processor generates a first digital signature using the private encryption key, generates a first non-repudiation message comprising the first digital signature and the first message, generates a second message comprising the first transaction request and the first non-repudiation message, and communicates the second message to a server to process the first transaction request.

According to another embodiment, a method includes storing, by a memory, a private encryption key and intercepting, by a hardware processor communicatively coupled to the memory, a first transaction request from a user. The method further includes communicating, by the processor, a first recertification request to a certificate authority that issued the private encryption key and receiving, by the processor, from the certificate authority, a first message indicating that the private encryption key is valid for use. In response to the first message, the method includes generating, by the processor, a first digital signature using the private encryption key, generating, by the processor, a first non-repudiation message comprising the first digital signature and the first message, generating, by the processor, a second message comprising the first transaction request and the first non-repudiation message, and communicating, by the processor, the second message to a server to process the first transaction request.

According to yet another embodiment, a system includes a certificate authority, a server, and a security tool. The security tool stores a private encryption key from the certificate authority and intercepts a first transaction request from a user. The security tool communicates a first recertification request to the certificate authority and receives, from the certificate authority, a first message indicating that the private encryption key is valid for use. In response to the first message, the security tool generates a first digital signature using the private encryption key, generates a first non-repudiation message comprising the first digital signature and the first message, generates a second message comprising the first transaction request and the first non-repudiation message, and communicates the second message to the server to process the first transaction request.

Certain embodiments provide one or more technical advantages. For example, an embodiment improves security and reduces fraud by using a user's mobile device to re-certify a private encryption key before communicating a transaction request to a server. As another example, an embodiment improves user privacy by using a user's mobile device to re-certify keys instead of using servers to re-certify keys. Certain embodiments may include none, some, or all of the above technical advantages. One or more other technical advantages may be readily apparent to one skilled in the art from the figures, descriptions, and claims included herein.

