Techniques for call authentication

Abstract

To provide a method and system for performing peer to peer authentication of calls between a first mobile phone device and a second mobile phone device.SOLUTION: When a call is made in a public switched telephone network (PSTN) or an interactive voice response (IVR) system 300 on a network, an identifying payload encrypted using a private key associated with a user is appended to a call data stream and is decrypted with a public key to be verified. In various embodiments, further authentication methods are performed by using an object such as a contactless card to provide one or more components of the identifying payload and / or keys. The PSTN or the IVR system on the network makes a connection between a sender and an intended recipient of a call on the basis of the verification of the identifying payload.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims priority to U.S. Patent Application No. 16 / 517,074, entitled "Techniques for Call Authentication", filed on Jul. 19, 2019, and issued as U.S. Patent No. 10,506,426 on Dec. 10, 2019. The content of the aforementioned patent application is hereby incorporated by reference in its entirety.

Background Art

[0002] Junk calls pose annoyance and security risks to the recipients of the calls. Recipients can be targeted by junk calls such as telemarketing calls, prank calls, and / or silent calls. Junk calls can also be used to initiate phone fraud. In this case, fraudsters attempt to steal information or funds by posing as legitimate entities.

[0003] Phone authentication involves attempting to identify the caller. However, current methods lack the ability to reliably authenticate the originating devices and the parties calling from them. Furthermore, such methods are implemented sporadically at best and are subject to practices such as spoofing. In this case, the caller can use false identities and / or numbers to deceive the recipient into answering. As a result, users often have a sense of distrust, at best, towards the communication system. In the worst - case scenario, they can be exposed to annoyance and / or security risks.

Summary of the Invention

[0004] According to one aspect of the present invention, a method for performing peer-to-peer authentication of a call includes receiving an incoming call data stream from a first mobile phone device, the incoming call data stream comprising an encrypted payload comprising encrypted payload data using an incoming call number of a second mobile phone device and a secret key associated with the first mobile phone device. In some embodiments, the secret key comprises a dynamic key of the first mobile phone device and the encrypted payload comprises a ciphertext. The method may include authenticating the incoming call data stream in response to a match between the encrypted payload and stored information associated with the first mobile phone device. In various aspects, authentication includes transferring the ciphertext to an authentication server, the authentication server maintaining and changing a copy of the dynamic key simultaneously with the first mobile phone device as stored information associated with the first mobile phone device. In some embodiments, authentication further includes receiving verification of the first mobile phone device from the authentication server in response to a counter match between a counter extracted from the ciphertext using a copy of the dynamic key and an expected counter associated with the first mobile phone device. The method may further include selectively establishing a call connection between the first mobile phone device and the second mobile phone device in response to the authentication step.

[0005] According to another aspect of the present invention, a system for authenticating calls between devices comprises an interface configured to receive an incoming call data stream from a first mobile phone device. In some embodiments, the incoming call data stream comprises an encrypted payload comprising an incoming call number associated with a second mobile phone device and payload data encrypted using a private key associated with the first mobile phone device. In some embodiments, the system includes a processor coupled to the interface and a non-volatile memory storing program code, the program code being operable when executed by the processor to authenticate the incoming call data stream in response to a match between the information in the encrypted payload and stored information associated with the first mobile phone device. The system further includes a communication interface coupled to the processor and configured to selectively establish a call connection between the first mobile phone device and the second mobile phone device in response to the authentication step.

[0006] According to yet another aspect of the present invention, a method for authenticating calls between mobile devices includes receiving an incoming call data stream from a first mobile phone device. In some embodiments, the incoming call data stream comprises an incoming call number associated with a second mobile phone device, and the encrypted payload comprises payload data encrypted using a private key associated with the first mobile phone device and voice message attributes. The method includes obtaining a public key of the incoming call number from a data storage device and decrypting the encrypted payload using the public key of the incoming call number to generate a decrypted payload comprising an identifier. The method includes comparing the identifier of the decrypted payload with an expected identifier associated with the incoming call number to determine a match for the first factor authentication, and comparing the attributes of the voice message with expected voice message attributes to identify a match for the second factor authentication. The method further includes selectively establishing a connection between the first mobile phone device and the second mobile phone device in response to the match for the first factor authentication and the match for the second factor authentication.

[0007] Such a configuration provides a system and method for reliably authenticating an incoming call.

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Modes for Carrying Out the Invention

[0009] The object of some embodiments of the present disclosure is the use of one or more keys incorporated into one or more contactless cards as described in U.S. Patent Application No. 16 / 205,119, filed on November 29, 2018, by Ozborne et al. under the name "System and Method for Encrypted Authentication of Contactless Cards", which is hereby incorporated by reference herein (hereinafter, the '119 application). Contactless cards can be used for authentication and many other functions that require carrying other physical tokens in addition to the contactless card. By adopting a contactless interface, a contactless card can be provided with a way to interact and communicate between a user's device (such as a mobile phone) and the card itself. For example, the Near Field Communication (NFC) protocol that underlies many credit card transactions is sufficient for the Android® operating system but presents more restrictive issues regarding the use of NFC, such as being usable only in read-only mode, in the authentication process of the iOS® operating system. Exemplary embodiments of the contactless card described in the '119 application may utilize NFC technology. When authenticating a user via a contactless card interface, the problem of identity theft in the prior art can be overcome by verifying the endpoints of the call link.

[0010] The various embodiments described herein are directed to call authentication by using one or more keys associated with a particular user. In the example, the user is the sender of the call. In various embodiments, when a call is made, the identification payload is encrypted using a secret key associated with the user. The encrypted identification payload is added to the call data stream. The identification payload can be decrypted using a public key. In an embodiment, the identification payload can be verified. In various embodiments, an additional authentication method can be performed by using an object such as a contactless card to provide one or more components of the identification payload and / or the key. In an embodiment, a connection can be made between the sender and the intended recipient of the call based on the verification of the identification payload.

[0011] In some embodiments described herein, the private key used to encrypt the identification payload may be stored or issued with respect to a particular user device. Such a user device may be a network-enabled computer. As referred to herein, a network-enabled computer may include, for example, a computer device, or, for example, a server, a network appliance, a personal computer (PC), a workstation, a mobile device, a telephone, a handheld PC, a personal digital assistant (PDA), a thin client device, a fat client device, or other devices, but is not limited thereto.

[0012] In some embodiments described herein, the private key used to encrypt the identification payload may be stored or issued with respect to a separate object associated with the user. For example, as referred to in the incorporated '119 application and as referred to in more detail herein, the separate object may be a contactless card. In this context, embodiments are not limited.

[0013] In various embodiments described herein, the identification payload may comprise text data, audio data, numerical data, or combinations thereof. For example, the identification payload may comprise information regarding the association of the user with a communication service provider, a voice message, or a counter associated with a contactless card. In this context, embodiments are not limited.

[0014] Prank calls can be made from various callers for various purposes, but are often difficult for the recipient to identify, resulting in a poor user experience for the communication system client and generating distrust of the user towards the communication system.

[0015] For example, caller ID can indicate to the recipient that the caller is a known contact, or display the caller's phone number so that the recipient can recognize the area code within it. However, the caller can turn off caller ID. Further, in this example, the recipient is still notified of incoming calls and must intentionally reject them. Further, a harasser can avoid proper identification, for example, by spoofing caller ID or blocking incoming calls. In a further example, a Voice over IP user can send a fake caller ID notice or route calls through servers in multiple countries.

[0016] In the field of telephone communications, the FCC requires the implementation of the processing of signature-based asserted information using the KEN (SHAKEN) and Secure Telephone Identity Revisited (STIR) standards, but these procedures have not yet fully authenticated the identity of the caller. In SHAKEN / STIR, the caller's service provider can create a digital signature based on what it knows about the originator, the customer and the originator's number, the customer (not the number), or the right to use the point where the call enters the network. An origination identifier can be assigned to uniquely identify the originator. However, in these procedures, the final verification is that the caller has the right to be presented to the recipient as a specific caller. A call may not actually come from the number presented as the caller. For example, spoofing approved by the service provider can still occur. Even after implementing such a method, the recipient cannot be certain of the identity of the other party to the incoming communication. An improved system for authenticating the identity of the party initiating the communication is needed.

[0017] The various embodiments described herein can include one or more components that enable one or more of: (1) authentication of a communication initiator associated with a device used to initiate a communication, (2) authentication of a communication initiator associated with the device used to initiate a communication and additional identification information provided by and / or associated with the communication initiator, and (3) authentication of a communication initiator associated with the device used to initiate a communication and a separate object uniquely owned by the communication initiator, such as a contactless card.

[0018] Authentication of a communication based on the source device reduces the likelihood that nuisance communications, including fraud attempts, reach the receiving client, thereby improving the security of information. In some embodiments, selective connection of a first client device and a second client device for a communication based on the result of authentication or multi-factor authentication can reduce the load of unwanted communications on the client, thereby improving the client experience.

[0019] Accordingly, the embodiments disclosed herein utilize the authentication functions of at least one client device and / or service provider in an actual application to improve the security of network communication and / or improve the client's trust in the reliability of received communication. In some embodiments, the components described herein may provide specific and particular methods of authenticating communication and / or managing communication based on the result of authentication. In many embodiments, one or more of the components described herein may be implemented as a set of rules that improve computer-related technologies by enabling functions that were previously not executable by a computer to achieve improved technical results. For example, authenticating communication based on identification information related to the communication initiator is such an improved technical result. In other examples, the functions may include secure multi-factor authentication by leveraging the functions of separate objects such as client devices and / or contactless cards. In other examples, the functions may include managing communication by selectively connecting devices for communication according to the result of multi-factor authentication.

[0020] These and other features of the present invention are described with reference to the figures, and like reference numerals are used throughout to refer to like elements.

[0021] As used in this application, the terms "system", "component", and "unit" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are described herein. For example, a component can be a process running on a processor, a processor, a hard disk drive, a plurality of storage drives (optical and / or magnetic storage media), an object, an executable file, an execution thread, a program, and / or a computer, but is not limited thereto. By way of example, both an application running on a server and the server can be components. One or more components can be located within a process and / or an execution thread, and a component can be localized on one computer or distributed between two or more computers.

[0022] Furthermore, components can be communicatively coupled to each other by various types of communication media for purposes of coordinating operations. The coordination can include one-way or two-way information exchange. For example, components can communicate information in the form of signals communicated through the communication media. This information can be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments can alternatively use data messages. Such data messages can be transmitted through various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0023] FIG. 1 shows a system 100 including two or more client devices 125 and 130 coupled via a network 115. In various embodiments, client devices 125 and 130 comprise network-enabled computers and communicate with each other via network 115. Specifically, various embodiments include each client device associated with a private key and a public key. In an embodiment, client device 125 initiating communication may send a message 140 comprising a payload encrypted with a phone number and its own private key 126. The message may be passed through an authentication router 120 that is part of network 115. The encrypted payload of message 140 may be decrypted using the public key 127 associated with client device 125. The communication may be passed to client device 130. In this context, embodiments are not limited.

[0024] In various embodiments, a first client device 125 may initiate communication intending to reach one or more client devices 130. Although only one device is shown in FIG. 1, it is understood that the communication may have multiple recipients, such as, for example, a group message, a conference call, or a group video chat. In this context, embodiments are not limited.

[0025] Client devices 125 and 130 can include a processor and memory, and the processing circuitry can include additional components such as a processor, memory, error and parity / CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitive, and anti-tampering hardware necessary to perform the functions described herein. Client devices 125 and 130 can further include a display and an input device. The display can be any type of device for presenting visual information such as a computer monitor, flat panel display, and mobile device screen including a liquid crystal display, light emitting diode display, plasma panel, and cathode ray tube display. The input device can include any device for inputting information available and supported on the user's device into the user's device such as a touch screen, keyboard, mouse, cursor control device, touch screen, microphone, digital camera, video recorder or camcorder. These devices can be used to input information and interact with the software and other devices described herein.

[0026] One or more client devices 125 and 130 can also be mobile devices such as, for example, Apple's iPhone (registered trademark), iPod (registered trademark), iPad (registered trademark), or any other mobile device running Apple's iOS (registered trademark) operating system, any device running Microsoft's Windows (registered trademark) Mobile operating system, and / or other smartphones or similar wearable mobile devices.

[0027] Client devices 125 and 130 may include a sync client application that is particularly adapted for communication with a service provider. The service provider may be a company or other entity that provides computer-related services over a network. The sync client application is stored in the memory of the client device and is operable when executed by the client device to control the interface between the client device and the service provider application and to enable a user of the client device to access the content and services of the service provider.

[0028] In an embodiment, client device 125 is associated with a private key 126 and a public key 127. The private key 126 and the public key 127 may be associated to enable encryption and decryption of data, such as in symmetric key encryption or asymmetric key encryption (also known as public key encryption). In an embodiment, the private key 126 and the public key 127 may be different, the public key 127 is available to systems external to the client device 125, and the private key 126 is intended to be known only by the client device 125. In such an embodiment, system 100 may be instructed to use asymmetric key encryption. In some embodiments, the same public key may be available to and / or associated with multiple client devices, such as client device 125 and client device 130.

[0029] In various embodiments, the private key 126 can be persistent or static. In other embodiments, the private key can be a dynamic key. For example, the private key 126 can be a rolling key. The private key 126 can be changed, for example, as a function of time, a counter, or other dynamic conditions. In various embodiments, the counter by which the private key 126 is updated can be advanced by use by the client of the client device 125 or other objects such as the contactless card described in more detail in the '119 application and herein. It will be readily understood that the dynamic key can be updated in response to other events, changes in circumstances, and / or any combination of the foregoing.

[0030] In various embodiments, the association of the private key 126 and / or the public key 127 with the client device 125 can be established at or before the issuance of the client device 125 to the client. For example, the keys can be set by the device manufacturer, service provider, or other entity. In other embodiments, the private key 126 and / or the public key 127 can be linked to the device later. For example, the client device 125 can receive the updated keys 126 and 127. In various embodiments, the private key 126 and / or the public key 127 can be stored in memory on the client device 125, or on an external server or database. In various embodiments, the private key 126 and / or the public key 127 can be updated by using an application on the client device and / or by using a separate computer. For example, the private key 126 and / or the public key 127 can be updated or diversified according to dynamic data such as a counter. Such examples are described in the '119 reference, which is incorporated herein by reference.

[0031] Client device 125 may initiate communication with other client devices 130 by generating a message 140. In an embodiment, the message 140 may comprise an encrypted payload and a phone number. The encrypted payload may be encrypted using a private key 126. The phone number may comprise the phone number of the client device 125 and / or the client device 130. In an embodiment, the encrypted payload encrypted as the encrypted payload of the message 140 may comprise text, numerical values, voice, other data, or combinations thereof. The payload may comprise unique identification information for the client, the client device 125, or combinations thereof. Further, the encrypted payload may include hashed data. Such information may be stored in memory accessible to the client device 125, for example, local to the client device or accessible via a network connection. In various embodiments, the encrypted payload may comprise dynamic information related to the client, the client device 125, or a separate object, such as a contactless card described in more detail herein. The dynamic information may be changed by the client device 125 or with each communication transmitted at another rate. In some embodiments, the public key 127 may be included in the message 140.

[0032] In some embodiments, the encrypted payload and / or the message 140 may be appended to a communication from the client device 125. For example, the encrypted payload may be appended to a call data stream. In some embodiments, a communication from the client device 125 may be included in the encrypted payload.

[0033] The message 140 may be transmitted from the client device 125. In various embodiments, the message 140 may pass through an authentication router 120. The authentication router 120 may be associated with a network 115.

[0034] In some examples, network 115 can be one or more of a wireless network, a wired network, or any combination of a wireless network and a wired network, and can be configured to connect client device 125 to service provider 320. For example, network 115 can include one or more of a fiber optic network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a global system for mobile communications, a personal communications service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short message service, a time division multiplexing-based system, a code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE802.11b, 802.15.1, 802.11n, and 802.11g, Bluetooth®, NFC, radio frequency identification (RFID), Wi-Fi, etc.

[0035] Furthermore, network 115 can include, but is not limited to, a telephone line, fiber optic, IEEE Ethernet 902.3, a wide area network (“WAN”), a wireless personal area network (“WPAN”), a local area network (“LAN”), or a global network such as the Internet. Further, network 115 can support an Internet network, a wireless communication network, a cellular network, etc., or any combination thereof. Network 115 can further include one network, or any number of the exemplary types of networks described above, operating as a stand-alone network or cooperating with each other. Network 115 can utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 115 can translate from one or more protocols of network devices to other protocols, or from other protocols.

[0036] Furthermore, according to one or more examples, it should be understood that network 115 can be part of multiple interconnected networks such as, for example, the Internet, a service provider's private network, a cable television network, a corporate network such as a credit card association network, and a home network. In some embodiments, authentication router 120 and / or network 115 can be associated with a communication service provider. Additionally, the private network can be implemented as a virtual private network layered on network 115.

[0037] For example, network 115 can include a public switched telephone network (PSTN), and the authentication router can be associated with the communication service provider used by the clients of client device 125 and / or client device 130.

[0038] Authentication router 120 can access the public key 127 associated with client device 125. In some cases, authentication router 120 can receive the public key 127 from client device 125 via message 140. In other embodiments, authentication router 120 can access a database, table, or other storage or memory where the public key 127 is stored. In these embodiments, the memory can be local to authentication router 120 or otherwise available via network 115.

[0039] In some embodiments, the authentication router 120 has access to storage as described above that includes dynamic information related to the encrypted payload of the message 140. For example, the dynamic information included in the encrypted payload may be reflected in the information available to the authentication router. For example, if the payload comprises current information regarding an account of a client of a communication service provider, the memory may comprise current information maintained separately regarding the account of the client of the service provider. In another example, if the encrypted payload comprises a counter that increases each time the client places a call using the client device 125, the counter may be updated in the memory accessible to the authentication router 120 each time the client device 125 places a call.

[0040] Information such as related to the client and / or the client device 125 may first be made available by the authentication router 120 upon activation of the client device 125 or issuance of the client device 125 to the client. Further, such information needs to be associated with the client and / or the client device. For example, a counter associated with the client device may be set to zero or some other predetermined number in response to activation of the device, or initial account information of the client may be entered by an employee of the communication service provider in response to creation of the client's account. However, such information is updated independently of the content of the message 140.

[0041] In some embodiments, the public key 127 is stored in such memory accessible to the authentication router 120. In an embodiment, the public key 127 can be input at a memory location associated with the client and / or the client device 125 upon issuance of the client device 125 to the client and / or at the start of a service by the communication service provider. The public key 127 in the memory can be updated if, for example, the public key is updated to match an updated private key. In some embodiments, this update can be automatic. In other embodiments, this update can be performed in response to an event, such as the transmission of a message 140 from the client device 125. In some embodiments, the public key 127 can be updated in response to being received as part of the message 140.

[0042] In various embodiments, the authentication router 120 can use the public key 127 to decrypt the message 140. In embodiments where the encrypted payload comprises hashed data, a hash function can be applied to the decrypted payload to extract information, such as an identifier. In an embodiment, the content of the decrypted payload of the message 140 can then be compared with information known by the authentication router associated with the client and / or the client device. For example, if the payload comprises a counter, that counter can be compared with the counter known by the authentication router. Matching the information of the decrypted payload with the information known by the authentication router 120 enables authenticating the message 140 as truly sent from the client device 125.

[0043] Since the public key 127 is associated with the private key 126 known only to the client device 125, the successful decryption of the message 140 using the public key 127 indicates that the message 140 was actually sent from the client device 125. However, a discrepancy between the encrypted payload of a message sent from the client device and the information available to the authentication router associated with the client and / or the client device 125 may indicate fraudulent activity. For example, a hacker or fraudster may gain access to the private key 126 of the client device 125, and the message received by the authentication router may not be from the identified client device 125. If the incoming message cannot be decrypted using the public key 127 and / or the decrypted payload of the message cannot be authenticated, the communication of the receiving client device 130 may be flagged. In some embodiments, the connection for communication between the client devices 125 and 130 may not be completed based on such authentication failures. Information related to the client device 125 and / or the message 140 may be flagged, stored in a database, and / or sent to a service provider or other entity, such as a law enforcement agency, based on such authentication failures. In some embodiments, the client devices 125 and 130 may be connected for communication based on the successful authentication of the initiating client device 125.

[0044] In some embodiments, the client device 130 has its own associated private key 136 and public key 137. It is understood that these keys may enable return communication from the client device 130 to the client device 125 in the same manner as described for communication from the client device 125 to the client device 130.

[0045] In various embodiments, the authentication process may be performed locally with respect to the recipient client device 130, as opposed to being performed locally with respect to the authentication router 120. Specifically, the message 140 may be routed by the network 115 to the client device 130 while remaining encrypted.

[0046] In such embodiments, the client device 130 may access the public key 127 associated with the client device 125. In some cases, the client device 130 may receive the public key 127 from the client device 125 via the message 140. In other embodiments, the client device 130 may access a database, table, or other storage or memory in which the public key 127 is stored. In these embodiments, the memory may be local to the client device 130 or otherwise available via the network 115.

[0047] In some embodiments, the client device 130 has access to storage as described above that includes dynamic information related to the encrypted payload of the message 140. For example, the dynamic information included in the encrypted payload may be reflected in information available to the authentication router. For example, if the payload comprises current information regarding an account of a client of a communications service provider, the memory may comprise current information maintained separately regarding the account of the client of the service provider. In another example, if the encrypted payload comprises a counter that increments each time the client places a call using the client device 125, the counter may be updated in the memory accessible to the client device 130 each time the client device 125 places a call. In such an example, a counter associated with the client device 125 that is local to the client device 125 and local to the client device 130 may be updated in particular in response to communication between the client device 125 and the client device 130.

[0048] Information such as related to the client and / or client device 125 may first become available to the client device 130 upon activation of the client device 125 or issuance of the client device 125 to the client. Further, such information needs to be associated with the client and / or client device. For example, a counter associated with the client device 125 may be set to zero or some other predetermined number in response to activation of the client device 125, or initial account information of the client may be input by an employee of the communication service provider in response to account creation for the client. In this example, the information may be stored in memory external to the client device 130, such as a database located on a network server. However, such information is updated independently of the content of the message 140.

[0049] In some embodiments, the public key 127 is stored in such memory accessible to the client device 130. In an embodiment, the public key 127 may be input into the memory in relation to the client and / or client device 125 upon issuance of the client device 125 to the client and / or at the start of service by the communication service provider. If the public key is updated, for example, to match a rolling secret key, the public key 127 in the memory may be updated. In some embodiments, this update may be automatic. In other embodiments, this update may be performed in response to an event, such as the transmission of the message 140 from the client device 125 to the client device 130. In some embodiments, the public key 127 may be updated in the memory available to the client device 130 in response to being received as part of the message 140.

[0050] In various embodiments, the client device 130 may decrypt the message 140 using the public key 127. In an embodiment, the decrypted payload of the message 140 may then be compared to information known by the client device 130 associated with the client and / or the client device. For example, if the payload includes a counter, that counter may be compared to a counter known by the client device 130. Matching the information of the decrypted payload with the information known by the client device 130 enables authenticating the message 140 as having been truly sent from the client device 125.

[0051] Since the public key 127 is associated with the secret key 126 known only to the client device 125, the successful decryption of the message 140 using the public key 127 indicates that the message 140 was actually sent from the client device 125. However, a mismatch between the encrypted payload of a message sent from a client device and the information available to the authentication router associated with the client and / or the client device 125 may indicate unauthorized activity. For example, a hacker or fraudster may gain access to the secret key 126 of the client device 125, and the message received by the authentication router may not be from the identified client device 125. If an incoming message cannot be decrypted using the public key 127 and / or the decrypted payload of the message cannot be authenticated, the communication of the receiving client device 130 may be flagged. In some embodiments, the connection for communication between the client devices 125 and 130 may not be completed or continued based on such authentication failures. Information related to the client device 125 and / or the message 140 may be flagged, stored in a database, and / or sent to a service provider or other entity, such as a law enforcement agency, based on such authentication failures. In some embodiments, the client devices 125 and 130 may be connected for communication based on the successful authentication of the initiating client device 125.

[0052] Figure 2 is a block diagram showing various exemplary components that may be useful in implementing a method as discussed with respect to Figure 1. The system 200 may be implemented, for example, to enable the encryption and / or decryption of data. Accordingly, similar components may be implemented as the client device 125, the authentication router 120, and / or the client device 130. The system 200 is particularly targeted at communications including telephones. Embodiments are not so limited.

[0053] In an embodiment, system 200 may include processor 210. The processing circuitry may include additional components including a processor, memory, error and parity / CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitive, and anti-tampering hardware as necessary to perform the functions described herein. Further, processor 210 may be any of a variety of commercially available computer processors including, but not limited to, AMD® Athlon®, Duron®, and Opteron® processors, ARM® application, embedded, and secure processors, IBM® and Motorola® DragonBall® and PowerPC® processors, IBM and Sony® Cell processors, Intel® Celeron®, Core®, Core(2) Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors, and the like. Dual microprocessors, multi-core processors, and other multiprocessor architectures may also be used as processor 210. Such processors may enable network-enabled devices to communicate with other network-enabled devices through the use of a PSTN interface 215 managed by an SS7 network interface 220.

[0054] Specifically, PSTN interface 215 enables system 200 to connect to network 115 and related services. The Signaling System Number 7 (SSN) network interface is used to manage the use of network 115 by system 200 through the PSTN interface 215 by using a different path and facility than the voice channels to signal the setup and release of communications.

[0055] A memory system, as referred to with respect to client device 125, authentication router 120, and client device 130, may in some examples be embodied as memory 225. Memory 225 may be read-only memory, write-once / read-multiple memory, or read / write memory, such as RAM, ROM, and EEPROM, and system 200 may include one or more of these memories. Read-only memory may be programable as factory-read-only or one-time programmable. With one-time programmability, it can be read many times after a single write. Write-once / read-multiple memory may be programmed at some point after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten but can be read many times. Read / write memory may be programmed and reprogrammed many times after factory shipment. Read / write memory can be read many times after factory shipment.

[0056] Memory 225 may be configured to store one or more of key data 230, encryption / decryption code 235, and key verification code 240. The key data may comprise keys used to encrypt and / or decrypt messages such as message 140, identification payloads, or other information. For example, key data 230 may comprise private key 126 and public key 127.

[0057] Encryption / decryption code 235 may comprise code for encrypting and / or decrypting messages such as message 140, identification payloads, or other information using key data 230.

[0058] The key verification code 240 may comprise code for verifying the encryption and / or decryption of information such as a message, an identification payload, or other information, such as message 140, using the key data 230 according to the encryption / decryption code 235. In some embodiments, the key verification code 240 may comprise a payload that identifies the client and / or the client device, e.g., the identification payload of message 140.

[0059] FIG. 3 is a block diagram showing a system 300 in which a client device 125 is coupled to a service provider 320 via a network 315. Embodiments are not so limited.

[0060] In one embodiment, the service provider 320 is a business that provides computer-based services to clients via the network 115. Almost all modern service providers use the Internet to provide services to potential consumers. Service provision is typically provided in the form of software applications that operate using the service provider's dedicated resources. The combination of software and hardware that provides a particular service to a client is herein referred to as a "server." The server may communicate via the service provider's private network 350, which is often referred to as a corporate network or enterprise network. The private network 350 may comprise a wireless network, a wired network, or any combination of wireless and wired networks, as described above with respect to network 115.

[0061] In system 300, the service provider 320 is shown as including an authentication server 360. Although the server is shown as an individual device, it is understood that the application and the server may be distributed across the entire enterprise or, in the case of distributed resources such as "cloud" resources, across the entire network 115.

[0062] The database 330 may include data storage resources that can be used to store, for example, customer accounts, qualification information, and other authentication information for use by the authentication server 360. The database 330 may be composed of combined data resources that include any combination of local storage, distributed data center storage, or cloud-based storage.

[0063] The contactless card 305 may include a payment card such as a credit card, debit card, or gift card issued by the service provider 320 displayed on the front or back of the card 305. In some examples, the contactless card 305 may include, but is not limited to, an identification card that has no relation to a payment card. In some examples, the payment card may include a dual interface contactless payment card. The contactless card 305 may include a substrate that may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 305 may have physical characteristics that conform to the ID-1 format of the ISO / IEC 7810 standard; otherwise, the contactless card may conform to the ISO / IEC 14443 standard. However, it is understood that the contactless card 305 according to the present disclosure may have different characteristics, and the present disclosure does not require that the contactless card be implemented as a payment card.

[0064] The contactless card 305 may also include identification information displayed on the front and / or back of the card, and contact pads. The contact pads may be configured to establish contact with other communication devices such as user devices, smartphones, laptops, desktops, or tablet computers. The contactless card 305 may also include processing circuitry, antennas, and other components not shown in FIG. 3. These components may be located behind the contact pads or elsewhere on the substrate. The contactless card 305 may also include a magnetic stripe or tape that may be located on the back of the card (not shown in FIG. 3).

[0065] According to one aspect, the contactless card 305 may be capable of wireless communication, such as NFC, with one or more client devices 125. For example, the contactless card 305 may include one or more chips, such as a radio frequency identification chip, configured to communicate via NFC or other short-range protocols. In other embodiments, the contactless card 305 may communicate with the client device 410 via other means including, but not limited to, Bluetooth®, satellite, and / or WiFi. As described in the '119 application, the contactless card 305 may be configured to communicate via NFC with one of the client devices 125 when the contactless card 305 is within the range of each client device. As will be described in more detail below, the contactless card 305 may generate a ciphertext for use by a service provider to authenticate the client device.

[0066] A message authentication code (MAC) ciphertext that may function as a digital signature for verification purposes may be generated using the contactless card 305. To perform this verification, a public key asymmetric algorithm, such as the Digital Signature Algorithm and the RSA algorithm, or other digital signature algorithms such as zero-knowledge protocols, may be used.

[0067] More specifically, a session key can be generated using the contactless card 305. The session key can be received via communication between the contactless card 305 and the client device 125 and functions as a secret key as described with respect to FIG. 1. In an embodiment, this process can be an alternative to the generation or storage of a secret key local to the client device 125 as described with respect to FIG. 1.

[0068] In an embodiment, an identifier can be passed to the client device 125 using the contactless card 305. The identifier can be, for example, a counter. In various embodiments, the secret key associated with the client device 125 can be diversified using the counter and / or used to encrypt the identifier from the contactless card 305 as part of an encrypted identifier payload.

[0069] The client device 125 can send a message, e.g., message 140. In an embodiment, the message can be added to a call data stream. The message can comprise an encrypted identifier payload associated with the client and / or the client device 125. The identifier payload can comprise voice data, e.g., a voice message. The message can further comprise at least one telephone number, e.g., as seen in message 140.

[0070] In an embodiment, the voice data can be recorded from a human voice, for example, from a client or from an employee of a service provider. In some embodiments, the voice data can comprise a custom voice message. In other embodiments, the voice data can be generated by a computer. In such embodiments, the voice data can be generated, for example, by a text-to-speech application or program in response to the computer device interpretation of text and / or numerical data. The interpretation of the text and / or numerical data can be performed locally with respect to the client device 125 or on another network-enabled device. The data to be interpreted can comprise identification information of the client and / or the client device. Such information can be stored, for example, in a memory accessible to the client device 125 that is local to the client device, local to a contactless card, or accessible via a network connection. For example, information about a particular client can be found in a database associated with the telephone number of the client device that is the source of the message. In some embodiments, the information can comprise dynamic information such as a counter.

[0071] In some embodiments, the payload can comprise additional information including at least one identifier. Such an identifier can comprise, for example, a counter from the contactless card 305 as described in more detail in this specification and the '119 application.

[0072] In an embodiment, the network 315 can comprise a system enabled for interactive voice response (IVR). The IVR system can receive and decrypt an encrypted identification payload transmitted by the client device 125. The decryption can be performed by a required method, for example, the method described in the '119 application or the method described with respect to FIG. 1.

[0073] The identifier of the decrypted payload, e.g., a counter, can be compared to the expected identifier associated with the client device of the message's originator. In embodiments, the expected identifier can be associated with the client device by referring to the phone number associated with that client device. In embodiments, the expected identifier can be updated independently of the content of incoming communications from the associated device. For example, upon receiving a communication from the client device, the counter can be incremented regardless of the content of the message received from the client device. In other examples, if the message contains a particular type of information, the counter can be incremented for each message received from the client device. The comparison of the identifier of the decrypted payload to the expected identifier can be performed by an IVR system, other network-enabled devices, applications thereon, or other compatible processors. Embodiments are not so limited.

[0074] A match between the identifier of the decrypted payload and the expected identifier can determine a match for the first factor authentication. This authentication adds an additional layer of security over symmetric or asymmetric key authentication by requiring not only successful decryption but also a match between the identifier known only to client device 125 and the memory storing the expected identifier. For example, a counter value of numerical value X that matches the expected value from the decrypted payload can indicate that not only was the payload properly decrypted, but also that the sending client device had a record of numerical value X of past communications with the same server as the server's record.

[0075] In an embodiment, the IVR system may perform a second factor authentication using the voice data included in the identification payload. In particular, the IVR system may interpret the voice data included in the identification payload. In some embodiments, the voice data of the decoded payload may be interpreted by a speech-to-text conversion program such as an application from voice to text. In some embodiments, the voice data may be analyzed for characteristics of the voice data itself. In an embodiment, attributes such as voice message attributes may be identified from the voice data. The attributes of the voice message include recognized words, human voice and computer-generated voice, tone, language, accent, cadence, background noise, voice characteristics such as volume, and other characteristics that the computer can recognize in the voice data. Such attributes can be identified using methods known in the field of language processing, for example, keyword identification or recognition according to a model trained by one or more machine learning algorithms, neural networks, or other training methods. In some embodiments, at least one confidence level may be calculated according to the likelihood that the voice data includes at least one attribute.

[0076] The interpreted voice data may, in an embodiment, be received by the service provider 320. The service provider 320 may include a private enterprise network 350, an authentication server 360, and a database 330. In an embodiment, the manner of analyzing the voice data may be performed on the enterprise network 350 as opposed to the public network 315. When the analysis is performed on the network 315 as described above, the identified attributes of the voice data may be transmitted to the enterprise network.

[0077] The authentication server 360 can compare the identified attributes of the voice data from the decrypted payload with the expected attributes of the voice data from a particular client and / or client device 125. Such attributes can be stored in relation to the client and / or client device within the database 330. For example, a custom voice message from the decrypted payload can be compared with a known custom voice message associated with the client device 125 within the database 330. In some embodiments, a binary analysis of the attribute matching can be used. In other embodiments, the attributes can be matched according to a confidence level within a particular range. Such confidence levels can be calculated, for example, by one or more machine learning methods, keyword identification methods, and / or other methods known in the art. Based on the comparison of the identified attributes with the expected attributes of the voice data, the authentication server 360 may or may not be able to establish a match for the second factor authentication. Since such a match for the second factor authentication can be based on information unique to the expected user of the client device 125 and / or the voice data, the authentication can provide confidence that the actual user of the client device 125 is the expected user rather than an impostor.

[0078] In some embodiments, the IVR system may selectively establish a connection between a first client device 125 and a second client device 130 based on the result of a match of the first and / or second factor authentication. In some embodiments, the authentication server 360 may communicate the result of the match of the first and / or second factor authentication to the IVR system. In some embodiments, the authentication server 360 may further communicate an instruction to connect or not connect the first client device 125 and the second client device 130 based on the result of a match of one or more factor authentications. In other embodiments, a PSTN or IVR system on the network 315 may receive the result of the match of the first and / or second authentication and determine whether to connect the first client device 125 and the second client device 130 for communication based on the result of a match of one or more factor authentications. In some embodiments, the IVR system may be used to restrict access of the first client device 125 to the second client device 130 based on the first client device 125 being authenticated as one of at least one known and verified caller. For example, such a verified caller may be recognized and / or marked within the system as making an uncommitted call in question.

[0079] FIG. 4 is a timing diagram showing an exemplary sequence for providing authenticated access according to one or more embodiments of the present disclosure. The system 400 may comprise a contactless card 305 and a client device 410 that may include an application 422 and a processor 424. Embodiments are not so limited.

[0080] In step 402, the application 422 communicates with the contactless card 305 (e.g., after being brought close to the contactless card 305). The communication between the application 422 and the contactless card 305 may include the contactless card 305 being close enough to a card reader (not shown) of the client device 410 to enable NFC data transfer between the application 422 and the contactless card 305.

[0081] In step 404, after communication is established between the client device 410 and the contactless card 305, the contactless card 305 generates a MAC ciphertext. In some examples, this may occur when the contactless card 305 is read by the application 422. In particular, this may occur upon reading, such as NFC reading, of a Near Field Data Exchange (NDEF) tag that may be created according to the NFC data exchange format. For example, a reader such as the application 422 may send a message such as an applet selection message using the applet ID of the NDEF generation applet. When the selection is confirmed, a series of selection file messages followed by a read file message may be sent. For example, the sequence may include "selection of function file", "reading of function file", and "selection of NDEF file". At this point, the counter value maintained by the contactless card 305 may be updated or incremented, and then "reading of NDEF file" may be performed. At this point, a message that may include a header and a shared secret may be generated. Thereafter, a session key may be generated. The MAC ciphertext may be created from the message, which may include the header and the shared secret. Next, the MAC ciphertext may be concatenated with one or more blocks of random data, and the MAC ciphertext and the random number (RND) may be encrypted with the session key. Thereafter, the ciphertext and the header may be concatenated and encoded as ASCII hexadecimal and returned in the NDEF message format (in response to the "reading of NDEF file" message).

[0082] In some examples, the MAC ciphertext can be transmitted as an NDEF tag, and in other examples, the MAC ciphertext can be included along with a Uniform Resource Indicator (e.g., a formatted string).

[0083] In some examples, the application 422 can be configured to send a request to the contactless card 305, and the request comprises instructions for generating a MAC ciphertext.

[0084] In step 406, the contactless card 305 sends the MAC ciphertext to the application 422. In some examples, the transmission of the MAC ciphertext is performed via NFC, but the present disclosure is not limited thereto. In other examples, this communication can be performed via Bluetooth®, Wi-Fi, or other wireless data communication means.

[0085] In step 408, the application 422 communicates the MAC ciphertext to the processor 424.

[0086] In step 412, the processor 424 verifies the MAC ciphertext according to instructions from the application 422. For example, as described below, the MAC ciphertext can be verified.

[0087] In some examples, the verification of the MAC ciphertext can be performed by a device other than the client device 410, such as the service provider 320 in the data communication with the client device 410. For example, the processor 424 can output the MAC ciphertext for transmission to the service provider 320 that can verify the MAC ciphertext.

[0088] In some examples, the MAC ciphertext can function as a digital signature for verification purposes. To perform this verification, a public-key asymmetric algorithm, such as the Digital Signature Algorithm and the RSA algorithm, or other digital signature algorithms such as zero-knowledge protocols, can be used.

[0089] More specifically, according to one aspect, the contactless card 305 can be used in combination with first authentication credentials provided to a service provider such as service provider 320 for communication from the client device 410, e.g., to authenticate a call. Using the contactless card as a second element of authentication can associate a particular device / phone number with a particular individual (i.e., the owner of the card), thus precluding a malicious third party from impersonating the client, i.e., spoofing. According to another aspect of the invention, the authentication communication protocol described herein identifies or uses a particular communication channel for call processing, thereby reducing the opportunity for client spoofing.

[0090] Security element authentication can comprise multiple processes. In some embodiments, the first authentication process can comprise logging in via one or more applications executed on the device and verifying the user. The second authentication process can operate after successful login and verification to cause the user to perform one or more operations associated with one or more contactless cards. In effect, the security element authentication process can comprise a multi-factor authentication process that both securely proves the identity of the user and prompts the user to engage in one or more types of operations, including but not limited to one or more tap gestures associated with the contactless card. In some examples, the one or more tap gestures can comprise tapping a contactless card against the device by the user. In some examples, the device can comprise a mobile device, a terminal, a tablet, or any other device configured to process received tap gestures.

[0091] For example, to provide a first layer of authentication, a client can access an application operating on a client device. In other examples, a client can access a service provider's website by using an Internet browser application running on the client device to link to the service provider's web page. The browser is a software application such as Google (TM) Chrome (TM), Internet Explorer (TM), Safari (TM), and includes programming code for converting a hypertext markup language (HTML) web page of a service provider application into a format suitable for a client operating the client device.

[0092] As part of accessing an application or a service provider's website, the service provider may request first authentication information including password information, pre-stored answers to queries, biometric information, images, or other mechanisms to verify that the user of the client device is authorized to access content and services including an account managed by the service provider. Further, this level of authentication provides confidence that the user of client device 125 is the expected client. In other words, the above method may be particularly useful for at least authenticating that the communication is coming from an authenticated device, but these steps may further authenticate that the communication is coming from an authenticated user of the device.

[0093] According to one aspect, the contactless card 305 can be used to provide a second authentication to the user of the client device. In one embodiment, as will be described in more detail below, the contactless card can be used to generate a ciphertext that can be used to verify the user of the client device, and includes a key, a counter, and an encryption processing function. The counter advantageously reflects the previous actions of the card owner. For example, the counter can reflect the number of times the user has communicated with a particular counterpart before, and this information is virtually impossible for a malicious third party to accurately collect.

[0094] A further level of authentication can be performed by using the contactless card 305, for example, by communicatively coupling the card 305 to one of the client devices 410 by tapping or other means as described above. In some embodiments, this constitutes the second authentication. In other embodiments, the second authentication continues with further analysis of the identification payload, as described, for example, with respect to FIG. 3.

[0095] Following the second authentication and as described in more detail herein, the data can be returned to the client device. For example, the data can include data that enables the client to initiate a communication link with a second client device, or information regarding the success or failure of the authentication attempt.

[0096] In the above description, the first authentication is described as using personal, biometric, question, or other authentication information, but note that in some examples, the client application running on the device can be recognized as being able to respond to a contactless tap to first activate or launch the application on the device. In such examples, the key / counter contactless card authentication process, described in detail below, is used in both the first and second authentication processes.

[0097] In some embodiments, if the client - side application is not installed on the client device, a tap of a contactless card in proximity to the card reader may initiate the download of the application (such as navigation to the application's download page). Following the installation, tapping the contactless card may activate or launch the application, and for example, the activation of the contactless card may be initiated via the application or other backend communication. In some examples, one or more applications may be configured to determine, for verifying the user's identity, that the activation occurred at 3:51 PM and the transaction was processed or performed at 3:56 PM, etc., via one or more tap gestures of the contactless card.

[0098] In some examples, data may be collected about the tap operation as biometric / gesture authentication. For example, a unique identifier that is cryptographically secure and resistant to eavesdropping may be sent to one or more backend services. The unique identifier may be configured to search for secondary information about the individual. The secondary information may include information that can identify the individual regarding the user. In some examples, the secondary information may be stored within the contactless card.

[0099] FIG. 5 shows an exemplary system 500 that can make authenticated calls. System 500 includes two or more client devices 125 and 130. As shown, a single client device 125 is the device used to initiate communication, and a single client device 130 is the device used to receive communication. However, it is readily understood that communication can be sent from client device 130 to client device 125, and / or each of the illustrated client devices may include multiple client devices in a group call, etc. Embodiments are not so limited.

[0100] Client device 125 may be associated with a private key 126 and a public key 127. Client device 130 may be associated with a private key 136 and a public key 137. In embodiments where at least one of client device 125 or client device 130 represents multiple client devices, each client device may be associated with a private key and a public key.

[0101] For each client device, a private key and a public key may be associated so that one can decrypt data encrypted by the other. In some embodiments, the private key and the public key of a device may be the same, enabling symmetric key encryption. In other embodiments, the private key and the public key may be different, enabling asymmetric key encryption. The keys may be persistent or dynamic. In some embodiments, the private key may be diversified by using dynamic information local to the client device as described above, or may be a session key provided by an external object or device such as a contactless card.

[0102] In various embodiments, client device 125 may initiate communication with client device 130, for example, a call data stream. Message 505 may be added to the communication. Message 505 may include an encrypted payload, at least one telephone number, at least one telephone number associated with the recipient client device 130, and a voice memo. In an embodiment, the voice memo may be customized by the owner of the sending client device 125, for example, by a phrase or a greeting. In some embodiments, message 505 may further include the public key 127 of client device 125.

[0103] The encrypted payload may be encrypted using the private key of client device 125. The encrypted payload may include at least one identifier. Optionally, the voice memo may be included in the encrypted payload.

[0104] The second client device 130 may access the public key 127 of the first client device 125 in relation to the phone number or other identification data of the client device 125. For example, the public key 127 of the first client device 125 may be received together with the message 505, stored locally in the memory of the client device 130 after a previous communication between the two devices, or made available via another memory or database such as a database linked to the Internet. Further, the second client device 130 may access the identifier expected in relation to the client device 125. For example, the same database may be used to store at least one client device 125, the associated public key, and the expected identifier associated with that client device 125.

[0105] The message 505 may be received by the client device 130. The client device 130 may obtain the public key 127 associated with the client device 125 and use the public key 127 to decrypt the encrypted payload of the message 505.

[0106] Failure to decrypt the payload using the public key 127 may indicate potential wrongdoing. As a result, the communication connection that appears to come from the client device 125 may be rejected. In some embodiments, feedback may be provided to the user of the client device 130, the service provider, or a third party, such as a law enforcement agency.

[0107] In some embodiments, the voice memo of the message 505 may be presented to the user of the client device 130 via the user interface, for example, by playing the voice memo audio data when the user of the client device 130 answers an incoming call. The user interface may be part of an application on the client device 130. In some embodiments, the voice memo of the message 505 may be presented to the user only based on a successful first authentication of the identifier of the encrypted payload.

[0108] Next, the client device 130 can receive feedback from the user of the first client device 125 when or if the voice memo from the user of the first client device 125 is recognized. For example, the feedback can be received via a user interface. This verification of the recognition of the voice memo from the first client by the second client provides an additional layer of authentication. In some embodiments, the client device 130 can receive instructions from the user via a user interface that indicates the continuation or rejection of the communication connection between the client devices 125 and 130.

[0109] Based on the feedback regarding the voice memo recognition received from the user, the client device 130 can selectively establish a connection between the client device 125 and the client device 130. In some embodiments, based on the feedback, the client device 130 can save the public key 127 of the client device 125 in local memory or add the client device 125 to a list of recognized and / or trusted devices.

[0110] In some embodiments, the continuous communication between recognized and / or trusted devices can be performed with a streamlined authentication method. For example, only a first level of authentication may be required.

[0111] FIG. 6 is a logical flow 600 showing a method for selectively connecting a first client device and a second client device to communicate based on the result of authentication. Specifically, FIG. 6 shows an example where both the first and second client devices are cellular phone devices and the communication is a voice data stream. The embodiments are not limited to this specification.

[0112] In step 610, an incoming call data stream is received from the first mobile phone device. The incoming call stream comprises a phone number associated with the second mobile phone device and an encrypted payload. The encrypted payload is encrypted using a private key associated with the first mobile device. In an embodiment, the encrypted payload may be added to the incoming call data stream. The payload data may comprise information regarding the first client and / or client device.

[0113] In step 620, the incoming call data stream may be authenticated in response to a match between the information of the encrypted payload and stored information associated with the first mobile phone device. In various embodiments, the match between the information of the encrypted payload and the stored information associated with the first mobile phone device may be determined by a successful decryption of the payload. For example, the payload may be encrypted using a diversified public key using a counter. In this example, a successful decryption of the payload using the diversified public key maintained independently by a counter may indicate proper authentication.

[0114] In step 630, the system may establish a call connection between the first mobile phone device and the second mobile phone device in response to the authentication step.

[0115] In some embodiments, if the system cannot properly authenticate the call, it may prompt for rejection of the call or other means of declining the call. In some embodiments, the first client device and / or the second client device may be notified about the failed attempt and provided with details of the attempt, such as the phone numbers of the caller and / or the recipient. In some embodiments, the recipient may be prompted to add the phone number of the calling first client device to a list of blocked numbers via the user interface of the second client device. In various embodiments, the system may provide information related to unauthenticated calls to a service provider or a third party, such as a law enforcement agency.

[0116] In some embodiments, successful authentication of a call of the system may facilitate the establishment of a connection between a first mobile device and a second mobile device. In various embodiments, information regarding the first mobile device may be stored at and / or by a second mobile device that identifies the first mobile device as the one engaged via the authenticated call. Such registration may be referred to in subsequent communications between the two client devices to efficiently check the likely reliability of subsequent communications based on the authentication of previous communications.

[0117] In some embodiments, a call connection may be made between a first cellular phone device and a second cellular phone device in response to an authentication step, and the result of the authentication step may be presented to the recipient, for example, via the user interface of the second client device. For example, a call connection may be made even if authentication fails, but a warning that the call is not authenticated may be communicated to the recipient via the cellular phone's user interface. In a further example, a call connection is made in response to successful authentication, and verification that the call is authenticated may be communicated to the recipient via the cellular phone's user interface.

[0118] FIG. 7 is a logical flow 700 showing a method of selectively connecting a first client device and a second client device for communication based on the result of multi-factor authentication. Specifically, FIG. 7 shows an example where both the first and second client devices are cellular phone devices and the communication is a call data stream. Embodiments are not so limited.

[0119] Step 710 discloses obtaining a public key of an incoming call number from a data storage device. In some embodiments, the data storage device may be local to the second client device. In other embodiments, the data storage device may be an external memory as discussed above with reference to, for example, authentication router 120 or database 330.

[0120] Step 720 discloses decrypting a payload encrypted using the public key of the incoming call number obtained in step 710 and generating a decrypted payload with an identifier. The encrypted payload may be received together with the incoming call number, for example, like message 140. The identifier may be associated with the sending client and / or the first client device.

[0121] Step 730 discloses comparing the identifier of the decrypted payload with an expected identifier associated with the incoming call number to determine a match for the authentication of the first element. In various embodiments, the expected identifier associated with the incoming call number may be obtained from memory, which may be the same data storage device or a separate data storage device referenced in step 710.

[0122] Step 740 discloses comparing the attributes of the voice message with the expected attributes of the voice message to identify a match for the second element authentication. The voice message may be received in relation to or as part of the encrypted payload.

[0123] Step 750 discloses selectively establishing a connection between the first cellular phone device and the second cellular phone device in response to a match for the first element authentication and the second element authentication.

[0124] In some embodiments, a failure of the system to properly authenticate a call via a match of the first element and / or the second element authentication may prompt a rejection of the call, a drop of the call, or other ways to decline the call. In some embodiments, the first client device and / or the second client device may be notified about the failed attempt and provided with details of the attempt, such as the phone numbers of the caller and / or the recipient. In some embodiments, the recipient may be prompted via the user interface of the second client device to add the phone number of the first client device on the originating side to a list of blocked numbers. In various embodiments, the system may provide information related to an unauthenticated call to a service provider or a third party, such as a law enforcement agency. Such information may specify which element of the authentication has failed and may include further details of the attempt.

[0125] In some embodiments, the system may facilitate the establishment of a connection between the first mobile device and the second mobile device upon successful authentication of a call via a match of the first element and / or the second element authentication. In various embodiments, information about the first mobile device may be stored at and / or by the second mobile device to identify the first mobile device as having engaged in a multi-factor authenticated call. Such registration may be referenced in subsequent communications between the two client devices and may efficiently check the likelihood of the reliability of subsequent communications based on the multi-factor authentication of previous communications.

[0126] In some embodiments, in response to a match in the first element and / or second element authentication, a call connection may be made between the first mobile phone device and the second mobile phone device, and the result of the authentication step may be presented to the recipient, for example, via the user interface of the second client device. For example, a call connection may be made even if multi-factor authentication fails, but a warning that the call is not authenticated or only partially authenticated may be communicated to the recipient via the user interface of the mobile phone. In a further example, a call connection may be made in response to a successful multi-factor authentication, and verification that the call has been authenticated via multi-factor authentication may be communicated to the recipient via the user interface of the mobile phone.

[0127] Various embodiments may be implemented using hardware elements, software elements, or a combination of both. Examples of hardware elements can include processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), logic gates, registers, semiconductor devices, chips, microchips, chip sets, and the like. Examples of software can include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. The determination of whether an embodiment is implemented using hardware elements and / or software elements can vary according to any number of factors such as desired computational speed, power level, heat tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints.

[0128] One or more aspects of at least one embodiment can be implemented by representative instructions stored on a machine-readable medium that represents various logic within a processor, which, when read by a machine, causes the machine to fabricate the logic for performing the techniques described herein. Such representations, known as “IP cores,” are stored on tangible machine-readable media and provided to various users or manufacturing facilities for loading onto a manufacturing machine that actually creates the logic or processor. Some embodiments may be implemented using, for example, a machine-readable medium or article that can store instructions or instruction sets that, when executed by a machine, can cause the machine to perform methods and / or operations according to the embodiments. Such machines can include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and can be implemented using any suitable combination of hardware and / or software. The machine-readable medium or article can include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium, and / or storage unit, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disks, floppy disks, compact disc read-only memory (CD-ROM), compact disc recordable (CD-R), compact disc rewritable (CD-RW), optical discs, magnetic media, magneto-optical media, removable memory cards or disks, various digital versatile discs (DVDs), tapes, cassettes, etc. The instructions can include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc., and can be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

Claims

1. 1. A method for performing peer-to-peer authentication of a call, comprising: receiving an incoming call data stream from a first mobile phone device, the incoming call data stream comprising an incoming call number of a second mobile phone device and an encrypted payload comprising payload data encrypted using a private key associated with the first mobile phone device, the private key comprising a dynamic key of the first mobile phone device, the encrypted payload comprising a ciphertext obtained from a contactless card associated with the first mobile phone device; authenticating the incoming call data stream in response to a match of the encrypted payload with stored information associated with the first mobile phone device; forwarding the cryptogram to an authentication server, the authentication server maintaining and changing a copy of the dynamic key concurrently with the first mobile phone device as the stored information associated with the first mobile phone device; receiving validation of the first mobile phone device from the authentication server in response to a counter match between a counter extracted from the cryptogram using the copy of the dynamic key and an expected counter associated with the first mobile phone device; selectively establishing a call connection between the first mobile phone device and the second mobile phone device in response to the step of authenticating; A method comprising the steps of:

2. The step of authentication comprises: obtaining a public key for the incoming call number from a data storage device; decrypting the encrypted payload using the public key of the incoming call number to generate a decrypted payload comprising an identifier; comparing the identifier of the decoded payload to an expected identifier associated with the incoming call number to determine a match; The method of claim 1 further comprising the steps of:

3. The method of claim 2 , wherein the encrypted payload is appended to the incoming call number.

4. 4. The method of claim 3, wherein the steps of obtaining, decoding, comparing, and selectively establishing are performed by an interactive voice response system disposed between the first and second mobile phone devices.

5. The method of claim 3 , wherein the steps of obtaining, decoding, comparing, and selectively establishing the call connection are performed by the second mobile phone device.

6. The method comprises: adding a voice message to the incoming call data stream, the voice message including information uniquely associated with an owner of the first mobile phone device; The method of claim 1 further comprising the steps of:

7. The method comprises: adding biometric information associated with the first mobile phone device to the incoming call data stream, the biometric information including information uniquely associated with an owner of the first mobile phone device; The method of claim 1 further comprising the steps of:

8. 3. The method of claim 2, wherein the encrypted payload comprises hashed data, the method including the step of applying a hash function to the decrypted payload to extract the identifier.

9. The method of claim 1 , wherein the dynamic key associated with the first mobile phone device is received from the contactless card associated with the first mobile phone device.

10. 1. A system for authenticating a call between devices, comprising: an interface configured to receive an incoming call data stream from a first mobile phone device, the incoming call data stream comprising an incoming call number associated with a second mobile phone device, and an encrypted payload comprising payload data encrypted using a private key associated with the first mobile phone device, the payload data including ciphertext obtained from a contactless card associated with the first mobile phone device; a processor coupled to the interface; a non-volatile memory having program code stored thereon, the program code being operable, when executed by the processor, to authenticate the incoming call data stream in response to a match between information in the encrypted payload and stored information associated with the first mobile phone device; a communications interface coupled to the processor and configured to selectively establish a call connection between the first mobile phone device and the second mobile phone device in response to the step of authenticating; A system comprising:

11. The non-volatile memory is further configured to store a public key associated with the incoming call number, and the program code comprises: decrypting the encrypted payload using the public key of the incoming call number to generate a decrypted payload comprising an identifier; comparing the identifier of the decoded payload to an expected identifier associated with the incoming call number to determine a match; The system of claim 10 , further operable to:

12. 12. The system of claim 11, wherein the system comprises an interactive voice response system disposed between the first and second mobile phone devices that limits access to the second mobile phone device to verified callers.

13. The system of claim 11 , wherein the second mobile phone device comprises the interface, the non-volatile memory, the program code, and the communications interface.

14. The system comprises: adding a voice message to the incoming call data stream, the voice message including information uniquely associated with an owner of the first mobile phone device; The system of claim 11 further comprising the steps of:

15. 15. The system of claim 14, wherein the encrypted payload comprises hashed data, and the program code is configured to apply a hash function to the decrypted payload to extract the identifier.

16. the private key comprises a dynamic key of the first mobile phone device, the encrypted payload comprises the ciphertext, and the program code comprises: forwarding the cryptogram to an authentication server, the authentication server maintaining and changing a copy of the dynamic key concurrently with the first mobile phone device as the stored information associated with the first mobile phone device; receiving validation of the first mobile phone device from the authentication server in response to a counter match between a counter extracted from the cryptogram using the copy of the dynamic key and an expected counter associated with the first mobile phone device; The system of claim 10 , further configured to:

17. 17. The system of claim 16, wherein the dynamic key associated with the first mobile phone device is received from the contactless card associated with the first mobile phone device.

18. 1. A method for authenticating a call between mobile devices, comprising: receiving an incoming call data stream from a first mobile phone device, the incoming call data stream comprising an incoming call number associated with a second mobile phone device, and an encrypted payload comprising payload data encrypted using a private key associated with the first mobile phone device, the encrypted payload comprising ciphertext and voice message attributes obtained from a contactless card associated with the first mobile phone device; obtaining a public key for the incoming call number from a data storage device; decrypting the ciphertext using the public key of the incoming call number to generate a decrypted payload comprising an identifier; comparing the identifier of the decrypted payload to an expected identifier associated with the incoming call number to determine a first factor authentication match; comparing the voice message attributes to expected voice message attributes to identify a second factor authentication match; selectively establishing a connection between the first mobile phone device and the second mobile phone device in response to a match of the first factor authentication and a match of the second factor authentication; A method comprising the steps of:

19. The method of claim 18 , wherein the identifier comprises a unique identifier associated with a user of the first mobile telephone device.

20. The method of claim 18 , wherein the identifier comprises a dynamic key associated with the first mobile telephone device.

Images