HK40061115A - Techniques for call authentication - Google Patents

Description

Techniques for call authentication

Cross Reference to Related Applications

This application claims priority benefits from U.S. patent application No. 16/517,074 entitled "techniques for call authentication" filed on 19.7.2019 (U.S. patent No. 10,506,426 granted on 10.12.2019). The contents of the above-mentioned patent application are incorporated herein by reference in their entirety.

Background

An unknown incoming telephone call presents a nuisance and a security risk to the call recipient. The recipient may be exposed to nuisance calls such as telemarketing, prankful calls, and/or silent calls. Unmistakable calls may also be used to initiate telephone fraud in which an imposter pretends to be a legitimate entity in an attempt to steal information or funds.

Telephone call authentication involves attempting to identify a calling party. However, current methods lack the ability to reliably authenticate the calling device and the calling party. Furthermore, such methods are preferably implemented sparsely and subject to acts such as spoofing, where a caller may use a false identity and/or number to trick the call recipient into answering. As a result, it is best that users often distrust the communication system. The worst case scenario is that they may be subject to nuisance and/or security risks.

Disclosure of Invention

According to one aspect of the invention, a method for performing point-to-point authentication of a call comprises the steps of: an incoming call data stream is received from the first mobile telephony device, the incoming call data stream comprising an incoming call number of the second mobile telephony device, and the encrypted payload comprising payload data encrypted using a private key associated with the first mobile telephony device. In some embodiments, the private key comprises a dynamic key of the first mobile telephony device and the encrypted payload comprises a password. The method may include authenticating the incoming call data stream in response to a match between the encrypted payload and stored information relating to the first mobile telephony device. In various aspects, the authenticating includes forwarding the password to an authentication server, wherein the authentication server maintains and modifies a copy of the dynamic password as stored information about the first mobile phone device concurrently with the first mobile phone device. In some embodiments, the authenticating further comprises receiving a verification of the first mobile telephony device from the authentication server in response to a counter match between a counter extracted from the password using the copy of the dynamic key and an expected counter associated with the first mobile telephony device. The method may further include selectively establishing a call connection between the first mobile telephony device and the second mobile telephony device in response to the step of authenticating.

According to another aspect of the invention, a system for authenticating a call between devices includes an interface configured to receive an incoming call data stream from a first mobile phone device. In some embodiments, the incoming call data stream includes an incoming call number associated with the second mobile telephony device and an encrypted payload containing payload data encrypted using a private key associated with the first mobile telephony device. In some embodiments, the system includes a processor coupled to the interface and a non-volatile memory having program code stored thereon, the program code operable when executed by the processor to authenticate the incoming call data stream in response to a match between the information of the encrypted payload and stored information associated with the first mobile phone device. The system further includes a communication interface coupled with 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 authenticating step.

According to yet another aspect of the invention, a method for authenticating a call between mobile devices includes the steps of: an incoming call data stream is received from a first mobile device. In some embodiments, the incoming call data stream includes an incoming call number associated with the second mobile telephone device, and the encrypted payload includes payload data encrypted using a private key associated with the first mobile telephone device, and the voice message attribute. The method includes retrieving 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 produce a decrypted payload including the identifier. The method includes comparing an identifier of the decrypted payload to an expected identifier associated with the incoming call number to determine a first factor authentication match and comparing an attribute of the voice message to an expected voice message attribute to identify a second factor authentication match. The method further includes selectively establishing a connection between the first mobile phone device and the second mobile phone device in response to the first factor authentication match and the second factor authentication match.

With such an arrangement, a system and method for reliably authenticating an incoming call is provided.

Drawings

FIG. 1 is a first block diagram of a data transmission system configured to authenticate a user call in accordance with an example embodiment;

FIG. 2 is a detailed block diagram illustrating exemplary components that may be used in the system of FIG. 1;

FIG. 3 is a detailed block diagram of components of the system of FIG. 1 that may be utilized to support aspects of the present invention.

Fig. 4 is a diagram illustrating a sequence for providing authenticated access, according to an example embodiment.

Fig. 5 is a second block diagram of a data transmission system configured to authenticate a user call according to an example embodiment.

FIG. 6 is a first logic flow diagram provided to describe exemplary steps that may be performed during one embodiment of a call authentication process; and

fig. 7 is a second logic flow diagram provided to describe exemplary steps that may be performed during one embodiment of a call authentication process.

Detailed Description

Some embodiments of the present disclosure are directed to the use of one or more keys that have been incorporated into one or more Contactless Cards, as described in U.S. patent application No. 16/205,119 entitled "Systems and Methods for Cryptographic Authentication of Contactless Cards" filed by Osborn et al on 29.11.2018 and incorporated herein by reference (hereinafter the' 119 application). Contactless cards may be used to perform authentication as well as many other functions that may require a user to carry a separate physical token in addition to the contactless card. By using a contactless interface, contactless cards can be provided with a method of interaction and communication between a user device (e.g. a mobile phone) and the card itself. For example, the Near Field Communication (NFC) protocol that forms the basis of many credit card transactions includes an authentication process that is sufficient to satisfyThe needs of the operating system but for iOS,a challenge is posed that the latter is more critical with respect to the use of NFC, since it can only be used in a read-only manner. Exemplary embodiments of the contactless card described in the' 119 application may utilize NFC technology. Authenticating a user via a contactless card interface may overcome the identity theft problem of the prior art by verifying the endpoint of the call link.

Various embodiments described herein are directed to authenticating a call by using one or more keys associated with a particular user. In an example, the user is the sender of a call. In various embodiments, when a call is placed, the identification payload is encrypted using a private key associated with the user. An encrypted identification payload is appended to the call data stream. The identifying payload may be decrypted using a public key. In an embodiment, the identifying payload may be verified. In various embodiments, further authentication methods may be performed using an object, such as a contactless card, to provide one or more components that identify the payload and/or the key. In an embodiment, a connection may be made between the sender of the call and the intended recipient based on the validation of the payload.

In some embodiments described herein, the private key used to encrypt the identification payload may be stored or published with respect to a particular user device. Such user equipment may be a network-enabled computer. As referred to herein, network-enabled computers may include, but are not limited to: such as a computer device, or a communication device including, 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, a thick client, or other device.

In some embodiments described herein, the private key used to encrypt the identification payload may be stored or published with respect to a separate object associated with the user. For example, as referenced in the incorporated' 119 application and in greater detail herein, the individual objects may be contactless cards. The embodiments are not limited in this context.

In various embodiments described herein, the identification payload may include text data, audio data, digital data, or a combination thereof. For example, the identification payload may include information regarding an association between the user and a communication service provider, a voice message, or a counter associated with the contactless card. The embodiments are not limited in this context.

While calls that are not routed may come from a variety of callers with a variety of purposes, they are often difficult for the recipient to identify, resulting in a poor user experience for the communication system client and user distrust of the communication system.

For example, the caller identification may indicate to the call recipient that the caller is a known contact or display the caller's telephone number so that the recipient may recognize the area code therein. However, the caller identification can be turned off by the caller. Furthermore, in the example, the recipient is still notified of the incoming call and must intentionally reject it. In a further example, a harasser can circumvent the correct identification, for example by spoofing or blocking the caller identification. In further examples, a voice over IP user may send a false caller id or route the call through servers in multiple countries.

For the field of telephone communications, the FCC has advocated implementing "signature-based claim information processing using toKEN" (SHAKEN) and secure telephone identity re-visit (STIR) standards, but these procedures also fail to fully authenticate the identity of the caller. In SHAKEN/STIR, the caller's service provider may create a digital signature based on its knowledge of the origin of the call, such as the customer and its rights to use the number called, the customer (but not the number), or the point at which the call enters its network. An origin identifier may be assigned to uniquely identify the origin of the call. However, in these processes, the final verification is that the caller has the right to appear as a calling party to the recipient. The call may not actually come from a number displayed as a caller. For example, fraud of service provider approval may occur at all times. Even after the implementation of such a method, the recipient will not determine the identity of the other end of the incoming communication. There is a need for an improved system for authenticating the identity of parties initiating a communication.

Various embodiments described herein include components that enable one or more of the following: (1) authentication of a communication originator associated with a device used to initiate a communication, (2) authentication of a communication originator associated with a device used to initiate a communication and separate identification information provided by and/or relating to the communication originator, and (3) authentication of a communication originator associated with a device used to initiate a communication and a separate object (e.g., a contactless card) unique to the communication originator.

Authentication based on communications from the device from which the communication was sent reduces the likelihood of nuisance communications, including fraud attempts, reaching the receiving client, thereby improving the security of its information. In some embodiments, selective connection of the first client device and the second client device for communication based on the results of authentication or multi-factor authentication may reduce the load of unwanted communications on the client, thereby improving the user experience.

Accordingly, embodiments disclosed herein utilize authentication features of at least one client device and/or service provider in actual practice to improve security of network communications and/or to improve client confidence in the authenticity of received communications. In various embodiments, components described herein may provide specific and specific ways of authenticating communications and/or managing communications based on the authentication results. In some embodiments, one or more components described herein may be implemented as a set of rules that enable improved technical results by allowing functions that a computer was previously unable to perform to improve computer-related technology. For example, authenticating a communication based on identification information associated with the communication originator is one such improved technical result. In another example, the functionality may include obtaining multi-factor authentication via utilizing features of the client device and/or a separate object (e.g., a contactless card). In another example, the functions may include managing communications by selectively connecting devices for communication based on results of the multi-factor authentication.

These and other features of the present invention will now be described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout.

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, or software in execution, examples of which are described herein. For example, a component may be, but is not limited to: a process running on a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution and a component can be localized on one computer and/or distributed between two or more computers.

Further, the components may be communicatively coupled to each other by various types of communication media to coordinate operations. The coordination may involve a unidirectional or bidirectional exchange of information. For example, a component may communicate information in the form of signals communicated over the communication media. The information may be implemented as signals assigned to various signal lines. In such an allocation, each message is a signal. However, further embodiments may alternatively employ data messages. Such data messages may be sent over various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

Fig. 1 shows a system 100 that includes 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. In particular, various embodiments include each client device associated with a private key and a public key. In an embodiment, the client device 125 initiating the communication may send a message 140, the message 140 including the phone number and the payload encrypted with its own private key 126. The message may be communicated through authentication router 120 (which is part of network 115). The encrypted payload of the message 140 may be decrypted using a public key 127 associated with the client device 125. The communication may be communicated to the client device 130. The embodiments are not limited in this context.

In various embodiments, the first client device 125 may initiate a communication with intent to reach one or more client devices 130. Although only one device is shown in fig. 1, it will be understood that the communication may have multiple recipients, such as in a group message, conference call, or group video. The embodiments are not limited in this context.

The client devices 125 and 130 may include a processor and memory, and it is understood that the processing circuitry may contain additional components including a processor, memory, error and parity/CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitive, and tamper-resistant hardware, as necessary to perform the functions described herein. Client devices 125 and 130 may further include a display and an input device. The display may be any type of device for presenting visual information, such as computer displays, flat panel displays, and mobile device screens, including liquid crystal displays, light emitting diode displays, plasma panels, and cathode ray tube displays. The input device may include any device for inputting information into the user device that is available to and supported by the user device, such as a touch screen, keyboard, mouse, cursor control device, touch screen, microphone, digital camera, video recorder, or video camera. These devices may be used to input information and interact with the software and other devices described herein.

One or more of client devices 125 and 130 may also be mobile computing devices, e.g., fromiPhone, iPod, iPad or any other device that runs AppleMobile device operating System, any running Microsoft WindowsA mobile operating system device, and/or any other smartphone, or similar wearable mobile device.

The client devices 125 and 130 may include thin client applications specifically adapted for communication with a service provider. The service provider may be a business or other entity that provides computer-related services via a network. The thin client application may be stored in a memory of the client device and operable when executed by the client device to control an interface between the client device and the service provider application to allow a user at the client device to access content and services of the service provider.

In an embodiment, client device 125 is associated with private key 126 and public key 127. Private key 126 and public key 127 may be related to enable encryption and decryption of data, for example, in the form of symmetric key encryption or asymmetric key encryption (also referred to as public key encryption). In embodiments, private key 126 and public key 127 may be different, public key 127 being available to systems external to client device 125 and private key 126 being intended to be known only by client device 125. In such embodiments, system 100 may be directed to using asymmetric key encryption. In some embodiments, the same public key may be used for and/or associated with multiple client devices, such as client device 125 and client device 130.

In various embodiments, private key 126 may be permanent or static. In other embodiments, the private key may be a dynamic key. For example, private key 126 may be a rolling key. Private key 126 may be changed, for example, over time, a counter, or other dynamic conditions. In various embodiments, the counter by which private key 126 is updated may be advanced through the client's use of client device 125 or a separate object (e.g., a contactless card as described in the' 119 application and in more detail herein). It will be readily appreciated that the dynamic key may be updated in response to other events, changes in the environment, and/or any combination of the above.

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

The client device 125 may initiate communication with another client device 130 by generating a message 140. In an embodiment, the message 140 may include an encrypted payload and a phone number. The encrypted payload may be encrypted using private key 126. The telephone number may include a telephone number of client device 125 and/or client device 130. In embodiments, the payload encrypted as the encrypted payload of message 140 may include text, numbers, audio, other data, or a combination thereof. The payload may include unique identifying information for the client, the client device 125, or a combination thereof. Further, the encrypted payload may contain hash data. Such information may be stored in a memory accessible to client device 125, such as a memory local to the client device or accessible via a network connection. In various embodiments, the encrypted payload may include dynamic information related to the client, the client device 125, or a separate object (e.g., a contactless card as described in more detail herein). The dynamic information may change with each communication sent by the client device 125 or at another rate. In some embodiments, public key 127 may be included in message 140.

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

A message 140 may be sent from the client device 125. In various embodiments, message 140 may pass through authentication router 120. Authentication router 120 may be associated with network 115.

In some examples, the network 115 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks, and may be configured to connect the client device 125 to the service provider 320. For example, the network 115 may include one or more of the following: fiber optic networks, passive optical networks, cable networks, internet networks, satellite networks, wireless Local Area Networks (LANs), global system for mobile communications, personal communication services, personal area networks, wireless application protocols, multimedia message services, enhanced message services, short message services, time division multiplexing-based systems, Code Division Multiple Access (CDMA) -based systems, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b,802.15.1,802.11n and 802.11g, bluetooth, NFC, Radio Frequency Identification (RFID), Wi-Fi, and the like.

Additionally, the network 115 may include, but is not limited to: telephone lines, fiber optics, IEEE ethernet 902.3, wide area network ("WAN"), wireless personal area network ("WPAN"), local area network ("LAN"), or global network such as the internet. Additionally, the network 115 may support an internet network, a wireless communication network, a cellular network, and the like, or any combination thereof. The network 115 may further include one network or any number of the above-described exemplary types of networks that operate as independent networks or cooperate with each other. The network 115 may utilize one or more protocols of one or more network elements communicatively coupled thereto. The network 115 may translate to one or more protocols of the network device or from other protocols to one or more protocols of the network device.

Further, it should be understood that network 115 may be part of a plurality of interconnected networks, such as the internet, a service provider's private network, a cable television network, an enterprise network such as a credit card association network, and a home network, according to one or more examples. In some embodiments, authentication router 120 and/or network 115 may be associated with a communication service provider. In addition, the private network may be implemented as a virtual private network that is layered based on the network 115.

For example, network 115 may include a Public Switched Telephone Network (PSTN), and the authentication router may be associated with a communication service provider used by a customer of client device 125 and/or client device 130.

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

In some embodiments, authentication router 120 accesses a storage device as described above, which includes dynamic information pertaining to the encrypted payload of message 140. For example, dynamic information included in the encrypted payload may be reflected by information that may be used to authenticate the router. For example, if the payload includes current information about the client account and the communication service provider, the memory may include current information about the client account and the service provider that are maintained separately. In another example, if the encrypted payload includes a counter that is incremented each time the client uses the client device 125 to make a call, the counter may be updated in memory accessible to the authentication router 120 each time the client device 125 makes a call.

Such information as pertaining to the client and/or client device 125 may be initially used to authenticate router 120 upon activation of client device 125 or publication of client device 125 to the client. Further, such information should be associated with the client and/or client device. For example, a counter associated with the client device may be set to zero or some other predetermined value in response to activation of the device, or the client's primary account information may be entered by the communication service provider employee in response to the client's account creation. However, this information is updated independently of the content of message 140.

In some embodiments, public key 127 is stored in such memory accessible to authentication router 120. In an embodiment, the public key 127 may be entered with a memory location associated with the client and/or client device 125 once the client device 125 is published to the client and/or serviced by a communication service provider. For example, if the public key is updated to match the updated private key, the public key 127 in memory may be updated. In some embodiments, such updating may be automatic. In other embodiments, such updating may be performed in response to an event, such as sending a message 140 from the client device 125. In some embodiments, public key 127 may be updated in response to being received as part of message 140.

In various embodiments, authentication router 120 may decrypt message 140 using public key 127. In embodiments where the decrypted payload contains hash data, a hash function may be applied to the decrypted payload to extract information, such as an identifier. In an embodiment, the content of the decrypted payload of message 140 may then be compared to information learned by an authentication router subordinate to the client and/or client device. For example, if the payload contains a counter, the counter may be compared to a counter learned by the authentication router. Matching the information of the decrypted payload with information learned by authentication router 120 allows for authentication of message 140 as being actually sent from client device 125.

Since public key 127 is associated with private key 126 (which is known only to client device 125), successful decryption of message 140 using public key 127 is indicative of the fact that message 140 was sent from client device 125. However, a mismatch between the payload of the message sent from the client device and the message available to the authentication router subordinate to the client and/or client device 125 may indicate malicious activity. For example, a hacker or impostor may have obtained access to private key 126 of client device 125, and the message received by the authentication router may not be from the identified client device 125. In the case where the incoming message cannot be decrypted using the public key 127 and/or the decrypted payload of the message cannot be authenticated, the communication may be marked for the recipient client device 130. In some embodiments, the connection for communication between client devices 125 and 130 may not be completed based on such authentication failure. Based on such authentication failures, information pertaining to the client device 125 and/or the message 140 may be tagged, stored in a database, and/or sent to a service provider or other entity (e.g., law enforcement). In some embodiments, client devices 125 and 130 may be connected for communication based on successful authentication of the initiating client device 125.

In some embodiments, the client device 130 has its own associated private key 136 and public key 137. It will be appreciated that these keys may allow return communications from the client device 130 to the client device 125 by the same methods described with respect to communications from the client device 125 to the client device 130.

In various embodiments, the authentication process may occur locally at the recipient client device 130, rather than locally at the authentication router 120. In particular, the message 140 may be routed to the client device 130 by the network 115 while still being encrypted.

In such embodiments, client device 130 may access public key 127 associated with client device 125. In some cases, client device 130 may receive public key 127 from client device 125 via 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 available locally at the client device 130, or otherwise via the network 115.

In some embodiments, the client device 130 accesses a storage as described above, which includes dynamic information pertaining to the encrypted payload of the message 140. For example, dynamic information included in the encrypted payload may be reflected by information that may be used to authenticate the router. For example, if the payload includes current information about the client account and the communication service provider, the memory may include current information about the client account and the service provider that are maintained separately. In another example, if the encrypted payload includes a counter that is incremented each time the client uses the client device 125 to make a call, the counter may be updated in memory accessible to the client device 130 each time the client device 125 makes a call. In such an example, counters associated with client devices 125 local to client devices 125 and 130 local to client devices 125 may be specifically updated in response to communications between client devices 125 and 130.

Such information as pertaining to the client and/or client device 125 may be initially made available to client device 130 upon activation of client device 125 or publication of client device 125 to the client. Further, such information should 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 value in response to activation of the client device 125, or the client's primary account information may be entered by a communication service provider employee in response to the client's account creation. In this example, the information may be stored in a memory external to the client device 130, such as a database located on an internet server. However, this information is updated independently of the content of message 140.

In some embodiments, the public key 127 is stored in such memory accessible to the client device 130. In embodiments, the public key 127 may be entered into a memory associated with the client and/or the client device 125 once the client device 125 is published to the client and/or serviced by a communication service provider. For example, if the public key is updated to match the rolling private key, public key 127 in memory may be updated. In some embodiments, such updating may be automatic. In other embodiments, such updating may be performed in response to an event, such as sending a message 140 from client device 125 to client device 130. In some embodiments, public key 127 may be updated in memory available to client device 130 in response to being received as part of message 140.

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 learned by the client device 130 belonging to the client and/or client device. For example, if the payload contains a counter, the counter may be compared to a counter learned by the client device 130. A match between the information of the decrypted payload and the information learned by the client device 130 allows the message 140 to be authenticated as being actually sent from the client device 125.

Since public key 127 is associated with private key 126 (which is known only to client device 125), successful decryption of message 140 using public key 127 is indicative of the fact that message 140 was sent from client device 125. However, a mismatch between the encrypted payload of the message sent from the client device and information available to an authentication router subordinate to the client and/or client device 125 may indicate malicious activity. For example, a hacker or impostor may have obtained access to private key 126 of client device 125, and the message received by the authentication router may not be from the identified client device 125. In the case where the incoming message cannot be decrypted using the public key 127 and/or the decrypted payload of the message cannot be authenticated, the communication may be marked for the recipient client device 130. In some embodiments, the connection for communication between client devices 125 and 130 may not be completed or continued based on such authentication failure. Based on such authentication failures, information pertaining to the client device 125 and/or the message 140 may be tagged, stored in a database, and/or sent to a service provider or other entity (e.g., law enforcement). In some embodiments, client devices 125 and 130 may be connected for communication based on successful authentication of the initiating client device 125.

Fig. 2 is a block diagram illustrating various exemplary components that may be used to implement the method discussed, for example, with respect to fig. 1. The system 200 may be implemented, for example, to allow encryption and/or decryption of data. Likewise, similar components may be implemented as client device 125, authentication router 120, and/or client device 130. System 200 is particularly directed to communications including telephone calls. The embodiments are not limited in this manner.

In an embodiment, the system 200 may include a processor 210. It will be appreciated that the processing circuitry may contain additional components, including a processor, memory, error and parity/CRC checker, data encoder, anti-collision algorithm, controller, command decoder, security primitive, and tamper-resistant hardware, as necessary to perform the functions described herein. Further, processor 210 may be any of a variety of commercial computer processors, including but not limited to:anda processor;application, embedded and secure processors;andanda processor; IBM anda Cell processor;Core(2)anda processor; and the like. Dual microprocessors, multi-core processors, and other multi-processor architectures may also be utilized as the processor 210. Such a processor may enable the network-enabled devices to communicate with other network-enabled devices via using PSTN interface 215 managed by SS7 network interface 220.

In particular, PTSN interface 215 allows system 200 to connect with network 115 and associated services. Signaling System Seven (SSN) network interfaces are used to manage the use of the system 200 to the network 115 via the PSTN interface 215 by using different paths and facilities than voice channels to establish signals and release communications.

In some instances, memory systems, such as those referenced with respect to client device 125, authentication router 120, and client device 130, may be embodied as memory 225. The memory 225 may be read-only memory, write-once read-many memory, or read/write memory such as RAM, ROM, and EEPROM, and the system 200 may include one or more of these memories. The read-only memory may be vendor programmable to be read-only or one-time programmable. One-time programmability provides the possibility of writing once and then reading multiple times. The write-once/read-many memory may be programmed at some point in time after the memory chip has been shipped from the factory. Once the memory is programmed, it may not be rewritten, but it may be read multiple times. The read/write memory may be programmed and reprogrammed multiple times after leaving the factory. It can also be read multiple times.

The 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 contain a key that is used to encrypt and/or decrypt information, such as a message (such as message 140), an identification payload, or other information. For example, key data 230 may include private key 126 and public key 127.

The encryption/decryption code 235 may include code that encrypts and/or decrypts information, such as a message (such as message 140), an identification payload, or other information using the key data 230.

The key verification code 240 may include a code that verifies the results of encryption and/or decryption of information, such as a message (such as message 140), an identification payload, or other information using the key data 230 in accordance with the encryption/decryption code 235. In some embodiments, key verification code 240 may include a payload identifying the client and/or client device, such as an identifying payload of message 140.

FIG. 3 is a block diagram illustrating a system 300 in which a client device 125 is coupled to a service provider 320 via a network 315. The embodiments are not limited in this manner.

In one embodiment, service provider 320 is a business that provides computer-based services to clients via network 115. Almost all modern service providers use networks to provide service items to potential consumers. The service items are generally provided in the form of software applications that run using dedicated resources of the service provider. The combination of software and hardware that provides a particular service to a client is referred to herein as a 'server'. The server may communicate via a service provider's private network 350 (commonly referred to as a corporate or enterprise network). Private network 350 may include a wireless network, a wired network, or any combination of wireless and wired networks, as described above with respect to network 115.

In system 300, service provider 320 is shown to include authentication server 360. While the servers are shown as discrete devices, it will be understood that applications and servers may be distributed throughout the enterprise, or in the case of distributed resources, such as 'cloud' resources, the applications and servers may be distributed throughout the network 115.

Database 330 includes data storage resources that may be used, for example, to store customer accounts, credit certificates, and other authentication information for use by authentication server 360. Database 330 may be comprised of coupled data resources including any combination of local storage, distributed data center storage, or cloud-based storage.

Contactless card 305 may include a payment card, such as a credit card, debit card, or cash card, issued by a service provider 320 displayed on the front or back of the card 305. In some instances, contactless card 305 is not related to a payment card and may include, but is not limited to, an identification card. In some examples, the payment card may include a dual interface contactless payment card. The contactless payment card 305 may include a substrate that may include a single layer or one or more laminates composed of plastic, metal, and other materials. Exemplary substrate materials include: polyvinyl chloride, polyvinyl chloride-vinyl acetate, acrylonitrile-butadiene-styrene, polycarbonate, polyesters, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, contactless card 305 may have physical characteristics that conform to the ID-1 format of the ISO/IEC 7810 standard, or the contactless card may otherwise conform to the ISO/IEC 14443 standard. However, it is understood that contactless cards 305 according to the present disclosure may have different characteristics, and the present disclosure does not require implementation of the contactless card in a payment card.

Contactless card 305 may also include identification information, as well as contact pads, displayed on the front and/or back of the card. The contact pad may be configured to establish contact with another communication device, such as a user device, a smartphone, a laptop, a desktop, or a tablet computer. Contactless card 305 may also include processing circuitry, an antenna, and other components not shown in fig. 3. These components may be located behind the contact pads or elsewhere on the substrate. Contactless card 305 may also include a magnetic strip or tape, which may be located on the back of the card (not shown in FIG. 3).

According to one aspect, contactless card 305 may communicate wirelessly, e.g., NFC, with one or more client devices 125. For example, 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, contactless card 305 may communicate with client device 410 by other means, including but not limited to: bluetooth, satellite, and/or Wi-Fi. As described in the' 119 application, contactless card 305 may be configured to communicate with one of client devices 125 via NFC when contactless card 305 is within range of the respective client device. As will be described in more detail below, contactless card 305 may generate a password that is used by a service provider to authenticate a client device.

Contactless card 305 may be used to generate a Message Authentication Code (MAC) password, which may function as a digital signature for verification purposes. Other digital signature algorithms, such as public key asymmetric algorithms, e.g., digital signature algorithms and RSA algorithms, or zero knowledge protocols may be used to perform this verification.

More specifically, contactless card 305 may be used to generate a session key. The session key may be received via communication between contactless card 305 and client device 125 and act as a private key as described with respect to fig. 1. In embodiments, this process may replace the generation or storage of private keys local to client device 125 as described with respect to fig. 1.

In an embodiment, contactless card 305 may be used to communicate an identifier to client device 125. The identifier may be, for example, a counter. In various embodiments, the private key associated with client device 125 may be diversified using a counter and/or used to encrypt the identifier from contactless card 305 as part of an encrypted identification payload.

Client device 125 may send a message, such as message 140. In an embodiment, the message may be appended to the call data stream. The message may include an encrypted identifier payload associated with the client and/or client device 125. The identifier payload may comprise audio data, such as a voice message. The message may further include at least one telephone number, for example, as found in message 140.

In an embodiment, the audio data may be recorded from a human voice, for example from a customer or from a server provider employee. In some embodiments, the audio data may include a customer voice message. In other embodiments, the audio data may be generated by a computer. In such embodiments, the audio data may be generated in response to interpretation of the text and/or numeric data by the computer device, such as through text-to-speech applications and programs. Interpretation of the textual and/or digital data may be performed locally at client device 125 or on another network-enabled device. The interpreted data may include identifying information for the client and/or the client device. Such information may be stored in a memory accessible to client device 125, such as local to the client device, local to the contactless card, or accessible via a network connection. For example, information for a particular client may be found in a database associated with a phone number of the client device from which the message was sent. In some embodiments, the information may include dynamic information, such as a counter.

In some embodiments, the payload may contain further information, including at least one identifier. Such an identifier may comprise a counter from contactless card 305, for example, as described in more detail herein and in the' 119 application.

In an embodiment, the network 315 may include an Interactive Voice Response (IVR) enabled system. The IVR system may receive and decrypt the encrypted identification payload sent by the client device 125. Encryption may be performed by any necessary method, such as by the method described in the' 119 application or by the method described with respect to FIG. 1.

An identifier of the decrypted payload, such as a counter, may be compared to an expected identifier associated with the client device from which the message was sent. In an embodiment, the expected identifier may be associated with the client device by referencing a phone number associated with the client device. For example, the counter may be incremented upon receipt of a communication from a client device, regardless of the content of the message received from the client device. In another example, when a message contains some type of information, a counter may be incremented for each message received from a client device. The comparison between the identifier of the decrypted payload and the expected identifier may be made by the IVR system, another network-enabled device, by an application on the IVR system, or another capable processor. The embodiments are not limited in this manner.

A match between the identifier of the decrypted payload and the expected identifier may determine a first factor authentication match. This authentication adds a further layer of security than symmetric key or asymmetric key authentication alone, by requiring not only successful decryption, but also a match between the identifier known only by the client device 125 and the memory in which the expected identifier is stored. For example, from a counter value of a number X that the decrypted payload matches the expected value, it may indicate not only that the payload has been able to be decrypted correctly, but also that the sending client device has a record of the same number X of past communications with the server as the record of the server.

In an embodiment, the IVR system may perform the second factor authentication using audio data included in the recognition payload. In particular, the IVR system may interpret the audio data included in the identification payload. In some embodiments, the audio data of the decrypted payload may be interpreted by a speech transcription program, such as a speech-to-text application. In some embodiments, the audio data may be analyzed for characteristics of the audio data itself. In an embodiment, attributes such as voice message attributes may be identified from the audio data. The voice message attributes may include recognized vocabulary, human voice vs. computer generated voice, sound characteristics such as tone, voice, accent, rhythm, background noise, volume, and other characteristics recognizable by the computer in the audio data. Such attributes may be identified using methods well known in the art of language processing, such as keyword recognition or recognition from a model trained by one or more machine learning algorithms, a neural network, or another training method. In some embodiments, the at least one confidence level may be calculated based on a likelihood that the audio data contains the at least one attribute.

In an embodiment, the interpreted audio data may be received by the service provider 320. Service provider 320 may include a private enterprise network 350, an authentication server 360, and a database 330. In an embodiment, aspects of the audio data analysis may occur on the enterprise network 350, rather than the public network 315. In the case where the analysis is performed over the network 315 as described above, the identifying attributes of the audio data may be sent to the enterprise network.

The authentication server 360 may compare the identified attributes of the audio data from the decrypted payload to expected attributes of the audio data from the particular client and/or client device 125. Such attributes may be stored in database 330 in association with the client and/or client device. For example, the customer voice message from the decrypted payload may be compared to previously known customer voice messages stored in database 330 associated with client device 125. In some embodiments, binary analysis of attribute matching may be used. In other embodiments, attributes may be matched according to a range of confidence levels. Such confidence may be calculated, for example, by one or more machine learning methods, keyword recognition methods, and/or other methods well known in the art. Based on the comparison between the identified attributes and the expected attributes of the audio data, the authentication server 360 may or may not be able to establish a second factor authentication match. Since it is this second factor that the authentication match may be based on information and/or audio data that is unique to the intended user of the client device 125, the authentication may provide confidence that the actual user of the client device 125 is the intended user and not an impostor.

In an embodiment, the IVR system may selectively establish a connection between the first client device 125 and the second client device 130 based on the results of the first and/or second factor authentication matches. In some embodiments, the authentication server 360 may transmit the results of the first and/or second factor authentication matches to the IVR system. In some embodiments, authentication server 360 may further transmit instructions to connect or disconnect first client device 125 and second client device 130 based on the result of the one or more factor authentication matches. In other embodiments, based on the results of the one or more factor authentication matches, the PSTN or IVR system on the network 315 may receive the results of the first and/or second authentication matches and determine whether to connect the first client device 125 and the second client device 130 for communication. 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 the at least one known verified caller. For example, such verified callers may be known and/or marked in the system as placing problematic impatient calls.

Fig. 4 is a timing diagram illustrating an example sequence for providing authenticated access in accordance with one or more embodiments of the present disclosure. System 400 may include contactless card 305 and client device 410, which may include application 422 and processor 424. The embodiments are not limited in this manner.

In step 402, application 422 communicates with contactless card 405 (e.g., after being brought into proximity of contactless card 305). Communication between application 422 and contactless card 305 may involve contactless card 305 being sufficiently close to a card reader (not shown) of client device 110 to enable NFC data transfer between application 122 and contactless card 105.

In step 404, contactless card 305 generates a Message Authentication Code (MAC) password after communication has been established between client device 410 and contactless card 305. In some examples, this may occur when contactless card 305 is read by application 422. In particular, this may occur when reading (e.g., NFC reading) a near field data exchange (NDEF) tag, which may be created according to an NFC data exchange format. For example, a reader such as application 422 may send a message, such as an applet selection message, with the applet ID of the applet that generated the NDEF. Upon confirmation of the selection, a selected file message sequence of read file messages may then be transmitted. For example, the sequence may include "select volume file", "read volume file", and "select NDEF file". At this point, the counter value maintained by contactless card 305 may be updated or incremented, which may be followed by a "read NDEF file". At this point, a message may be generated that may include a header and a shared secret. A session key may then be generated. The MAC password may be created from the message, which may include a header and a shared secret. The MAC cipher may then be concatenated with one or more blocks of random data, and the MAC cipher and Random Number (RND) may be encrypted using the session key. Thereafter, the password and the header may be concatenated and encoded as ASCII hexadecimal and returned in NDEF message format (in response to the "read NDEF file" message).

In some examples, the MAC password may be transmitted as an NDEF tag, and in other examples, the MAC password may be included with a uniform resource indicator (e.g., as a formatting string).

In some examples, application 422 may be configured to transmit a request to contactless card 105 that includes an instruction to generate a MAC password.

In step 406, contactless card 305 sends a MAC password to application 422. In some examples, the transmission of the MAC password occurs via NFC. However, the present disclosure is not limited thereto. In other examples, the communication may occur via Bluetooth, Wi-Fi, or other means of wireless data communication.

In step 408, application 422 transmits the MAC password to processor 424.

In step 412, the processor 424 verifies the MAC password according to instructions from the application 422. For example, as explained below, the MAC password may be verified.

In some examples, verifying the MAC password may be performed by a device other than the client device 410, such as the server provider 320 in data communication with the client device 410. For example, the processor 424 may output the MAC password for transmission to the service provider 320, which may verify the MAC password.

In some examples, the MAC password may be used as a digital signature for verification purposes. Other digital signature algorithms such as public key asymmetric algorithms (e.g., digital signature algorithms and RSA algorithms) or zero knowledge protocols may be used to perform this verification.

More specifically, according to one aspect, contactless card 305 may be used in conjunction with first authentication credentials provided by a service provider (such as service provider 320) to authenticate communications (e.g., calls) from client device 410. The use of a contactless card as a second factor in authentication enables a particular device/phone number to be associated with a particular individual (e.g., the owner of the card), thereby eliminating the ability of a malicious third party to impersonate (i.e., impersonate a client). According to another aspect of the present invention, the authenticated communication protocol described herein identifies or uses a particular communication channel for call processing, thereby reducing the likelihood of client impersonation.

Security factor authentication may include a number of processes. In some embodiments, the first authentication process may include logging in and verifying the user via one or more applications executing on the device. A second authentication process may be run after successful login and authentication to engage the user in one or more activities associated with one or more contactless cards. In practice, the security factor authentication process comprises a multi-factor authentication process, which may include securely providing user identification and encouraging the user to engage in one or more behaviors, including, but not limited to, one or more tap gestures associated with the contactless card. In some examples, the one or more tap gestures may include a user tapping a contactless card to the device. In some examples, the device may include a mobile device, a terminal, a tablet, or any other device configured to process the received tap gesture.

For example, to provide a first layer of authentication, a client may access an application running on a client device. In other examples, the client may access the service provider's website by linking to the service provider webpage using an internet browser application running on the client device. The browser is a software application, such asInternetEtc., and includes programming code for translating a hypertext markup language (HTML) web page of the service provider application into a format suitable for a client running the client device.

As part of accessing an application or service provider website, the service provider may request first authentication information that includes password information, a response to a pre-stored query, biometric information, an image, or other mechanism to verify that the user of the client device is authenticated to access content and services (including accounts) managed by the service provider. Further, the authentication level provides confidence that the user of the client device 125 is the intended client. In other words, while the above-described method is particularly useful for authenticating at least communications from an authenticated device, these steps may further authenticate that the communications are an authenticated user from the device.

According to one aspect, contactless card 305 may be used to provide a second authentication for the user of the client device. In one embodiment, and as described in more detail below, the contactless card includes a key, a counter, and an encryption processing function that can be used to generate a password that can be used to authenticate a user of a client device. The counter advantageously reflects past behavior of the cardholder. For example, the counter may reflect the number of times the user has previously communicated with a particular party, with information that is less likely to be accurately obtained by a malicious third party.

A further level of authentication may be achieved by using the contactless card 305 (e.g., by tapping or otherwise communicatively coupling the card 305 to one of the client devices 410 as described above). In some embodiments, this constitutes a second authentication. In other embodiments, the second authentication is continued with, for example, an analysis to identify the payload, as described with respect to fig. 3.

After the second authentication, and as described in more detail below, the data may be returned to the client device. For example, the data may include data that allows the client to initiate a communication link with the second client device, or information regarding the success or failure of the authentication attempt.

It should be noted that although in the above description the first authentication is described as using a person, biometric, question or other authentication information, it may be appreciated that in some examples, a client application executing on the device may respond to a tap of the contactless card to initially activate or launch an application of the device. In such an example, both the first and second authentication processes use a key/counter contactless card authentication process described in more detail below.

In some embodiments, if the client-side application is not installed on the client device, a tap of the contactless card near the card reader may initiate a download of the application (e.g., navigate to an application download page). After installation, tapping of the contactless card can activate or launch an application, and then initiate (e.g., via an application or other backend communication) activation of the contactless card. In some examples, one or more applications may be configured to determine that they are launched via one or more tap gestures of the contactless card, such that launching occurs at 3:51 pm and transactions are processed or occur at 3:56 pm in order to verify the identity of the user.

In some examples, data may be collected as authentication of a biometric/gesture by the tap behavior. For example, a unique identifier that is cryptographically protected and not easily intercepted may be communicated to one or more back-end services. The unique identifier may be configured to look up secondary information about the individual. The secondary information may include personally identifiable information about the user. In some examples, the secondary information may be stored within the contactless card.

Fig. 5 illustrates an exemplary system 500 in which an authenticated call may be placed. System 500 includes two or more client devices 125 and 130. As shown, a single client device 125 is a device used to initiate communications and a single client device 130 is a device used to receive communications. However, it will be readily appreciated that communications may be transmitted from client device 130 to client device 125 and/or that each client device as shown may include multiple client devices, such as in a group call. The embodiments are not limited in this manner.

Client device 125 may be associated with private key 126 and 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 one private key and one public key.

For each client device, the private key and the public key may be related such that one is decrypted by data encrypted by the other. In some embodiments, the private key and the public key may be the same for one device, enabling it to perform symmetric key encryption. In other examples, the private key and the public key may be different such that they are capable of asymmetric key encryption. The key may be permanent or dynamic. In some embodiments, as described above, the private key may be a session key that is diversified by the use of dynamic information local to the client device, or provided by an external object or device (such as a contactless card).

In various embodiments, client device 125 may initiate communication with client device 130, such as a call data stream. Message 505 may be appended to the communication. The message 505 may include an encrypted payload, at least one phone number including the phone number associated with the recipient client device 130, and a voice memo. In an embodiment, the voice memo may be customizable by the owner of the sending client device 125, such as a phrase or a hello. In some embodiments, message 505 may further include public key 127 of client device 125.

The encrypted payload may be encrypted using a private key of the client device 125. The encrypted payload may include at least one identifier. In some cases, the voice memo may be included in the encrypted payload.

The second client device 130 may access the public key 127 of the first client device 125 associated with the telephone number, or other identifying data for the client device 125. For example, the public key 127 of the first client device 125 may be received with the message 505, stored locally to a memory of the client device 130 after communication between the previous two devices, or available via another memory or database (such as an internet-linked database). Further, the second client device 130 may access the intended identifier associated with 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 the client device 125.

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

Failure to decrypt the payload using public key 127 may indicate potential fraud. As a result, assume that the communication connection from the client device 125 may be denied. In some embodiments, the feedback may be provided to a user of the client device 130, a server provider, or a third party (e.g., law enforcement).

In some embodiments, the voice memo of message 505 may be displayed to the user of client device 130, for example, via a user interface that plays voice memo audio data to the user of client device 130 when the user of client device 130 answers the incoming call. The user interface may be part of an application on the client device 130. In some embodiments, the voice memo of message 505 may be displayed only to the successfully first authenticated user based on the identifier of the encrypted payload.

The client device 130 may receive feedback from its user if the user recognizes or does not recognize the voice memo from the user of the first client device 125. For example, the feedback may be received via a user interface. This verification of the identification of the voice memo from the first client by the second client provides a further layer of authentication. In some embodiments, client device 130 may receive instructions from a user via a user interface to indicate continuation or denial of a communication connection between client devices 125 and 130.

Based on the feedback received from the user regarding the voice memo recognition, the client device 130 may 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 may save the public key 127 of the client device 125 to local memory, or add the client device 125 to a list of recognized and/or trusted devices.

In some embodiments, continuous communication between identified and/or trusted devices may be performed using a streamlined authentication method. For example, authentication of only the first layer may be required.

Fig. 6 is a logic flow diagram 600 illustrating a method for selectively connecting a first client device with a second client device for communication based on authentication results. In particular, fig. 6 shows an example in which both the first and second client devices are mobile telephony devices and the communication is a call data flow. The embodiments are not limited thereto.

In step 610, an incoming call data stream is received from a first mobile telephony device. The incoming call stream includes a telephone number associated with the second mobile telephone 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 appended to the incoming call data stream. The payload data may include information pertaining to the first client and/or the client device.

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, said match between the information of the encrypted payload and the stored information associated with the first mobile telephone device may be determined by a successful decryption of the payload. For example, the payload may have been encrypted with a public key diversified using a counter. In this example, successful decryption of the payload with a public key diversified by an independently maintained counter may indicate proper authentication.

In step 630, the system may establish a call connection between the first mobile telephony device and the second mobile telephony device in response to the step of authenticating.

In some embodiments, failure of the system to properly authenticate the call may prompt rejection of the call or other methods of canceling the call. In some embodiments, the first client device and/or the second client device may be notified of the failed attempt and provided with details of the attempt, such as the telephone number of the caller and/or recipient. In some embodiments, the recipient may be prompted via a user interface of the second client device to add the phone number calling the first client device to the list of numbers to be intercepted. In various embodiments, the system may provide information about the unauthenticated call to a service provider or a third party (e.g., law enforcement).

In some embodiments, successful authentication of the call by the system may prompt establishment of a connection between the first mobile device and the second mobile device. In various embodiments, information about the first mobile device may be saved to/by a second mobile device that identifies the first mobile device as having been engaged via an authenticated call. Such a registration may be referenced in a subsequent communication between two client devices to efficiently check the possible authenticity of the subsequent communication based on the authentication of the previous communication.

In some embodiments, a call connection may be established between the first and second mobile telephony devices in response to the authenticating step, and the result of the authenticating step may be indicated to the recipient, for example via a user interface of the second client device. For example, a call connection may be established despite a failure of authentication, but an alert may be transmitted to the recipient via the user interface of the recipient's mobile phone that the call is unauthenticated. In a further example, in response to the authentication being successful, a call connection may be established in which a verification result that the call has been authenticated is communicated to the recipient via a user interface of the recipient's mobile phone.

Fig. 7 is a logic flow diagram 700 illustrating a method for selectively connecting a first client device with a second client device for communication based on results of multi-factor authentication. In particular, fig. 7 shows an example in which the first and second client devices are both mobile telephony devices and the communication is a call data flow. The embodiments are not limited in this manner.

Step 710 discloses retrieval of a public key of the incoming call number from the 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, such as discussed above with reference to authentication router 120 or database 330.

Step 720 discloses decryption of the encrypted payload using the public key of the incoming call number retrieved in step 710 to produce a decrypted payload comprising the identifier. The encrypted payload may be received along with the incoming call number, such as in message 140. The identifier may be related to the sending client and/or the first client device.

Step 730 discloses a comparison of the identifier of the decrypted payload and an expected identifier associated with the incoming call number to determine a first factor authentication match. In various embodiments, the expected identifier associated with the incoming call number may be retrieved from a memory, which may be the same data storage device as referenced in step 710, or a separate data storage device.

Step 740 discloses comparing the attributes of the voice message to expected voice message attributes to identify a second factor authentication match. The voice message may be associated with or received as part of the encrypted payload.

Step 750 discloses selectively establishing a connection between the first mobile phone device and the second mobile phone device in response to the first factor authentication and the second factor authentication matching.

In some embodiments, failure of the system to authenticate a matching correct authentication call via the first factor and/or the second factor may prompt rejection of the call, interruption of the call, or other methods of canceling the call. In some embodiments, the first client device and/or the second client device may be notified of the failed attempt and provided with details of the attempt, such as the telephone number of the caller and/or recipient. In some embodiments, the recipient may be prompted via a user interface of the second client device to add the phone number calling the first client device to the list of numbers to be intercepted. In various embodiments, the system may provide information about unauthenticated calls to a service provider or third party (e.g., law enforcement). Such a message may specify which factor of authentication failed and include further details of the attempt.

In some embodiments, successful authentication of the system to authenticate the matching call via the first factor and/or the second factor may prompt establishment of a connection between the first mobile device and the second mobile device. In various embodiments, information about a first mobile device may be saved to/by a second mobile device that identifies the first mobile device as having been engaged in a call authenticated via a multi-factor authentication. Such a registration may be referenced in a subsequent communication between two client devices to efficiently check the possible authenticity of the subsequent communication based on the authentication of the previous communication.

In some embodiments, a call connection may be established between the first and second mobile telephone devices in response to the first factor and/or the second factor authenticating the match, and the result of the authenticating step may be indicated to the recipient, for example via a user interface of the second client device. For example, a call connection may be established despite a multi-factor authentication failure, but an alert may be transmitted to the recipient via the user interface of the recipient's mobile phone that the call is unauthenticated. In a further example, in response to the multi-factor authentication being successful, a call connection may be established, wherein the call is communicated to the recipient via a user interface of the recipient's mobile phone that has been verified by the multi-factor authentication.

Various embodiments may be implemented using hardware elements, software elements, or a combination of both. Examples of hardware elements may include: processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, Application Specific Integrated Circuits (ASIC), Programmable Logic Devices (PLD), Digital Signal Processors (DSP), Field Programmable Gate Array (FPGA), logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth. Examples of software elements may 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 (API), instruction sets, computing code, computer code, code segments, computer code segments, characters, values, symbols, or any combination thereof. However, determining whether an embodiment is implemented using hardware elements and/or software elements may vary depending on a number of factors, such as desired computational rate, power levels, thermal tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints.

One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium which represent various logic within a memory which, when read by a machine, cause the machine to fabricate logic to perform the techniques described herein. Such representations, known as "IP cores" may be stored on a tangible, machine-readable medium and provided to various users or production facilities for loading into the fabrication machines that actually make the logic or processor. For example, some embodiments may be implemented using a machine-readable medium or article which may store an instruction or a set of instructions that, if executed by a machine, may cause the machine to perform a method and/or operations in accordance with the embodiments. Such a machine may include, for example, any suitable processing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, and may be implemented using any suitable combination of hardware and/or software. The machine-readable medium or article may 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, for example, memory, removable or non-removable media, erasable or non-erasable media, writeable or re-writeable media, digital or analog media, hard disk, floppy disk, compact disk read Only memory (CD-ROM), compact disk recordable (CD-R), compact disk Rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of Digital Versatile Disk (DVD), a tape cartridge, a cassette, or the like. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, and the like, implemented using any suitable high-level, low-level, object-oriented, visual, compiled or interpreted programming language.

Claims (20)

1. A method for performing point-to-point authentication of a call, comprising the steps of:

receiving an incoming call data stream from a first mobile telephony device, the incoming call data stream comprising an incoming call number of a second mobile telephony device, and an encrypted payload comprising payload data encrypted using a private key associated with the first mobile telephony device, wherein the private key comprises a dynamic key of the first mobile telephony device, the encrypted payload comprising a password retrieved from a contactless card associated with the first mobile telephony device;

authenticating the incoming call data stream in response to a match between the encrypted payload and stored information relating to the first mobile telephony device, comprising:

forwarding the password to an authentication server, wherein the authentication server maintains and modifies a copy of the dynamic password as the stored information about the first mobile phone device concurrently with the first mobile phone device; and is

Receiving a verification of the first mobile telephony device from the authentication server in response to a counter match between a counter extracted from the password using the copy of the dynamic key and an expected counter associated with the first mobile telephony device; and

selectively establishing a call connection between the first mobile telephony device and the second mobile telephony device in response to the authenticating step.

2. The method of claim 1, wherein the authenticating step further comprises the steps of:

retrieving a public key of the incoming call number from a data storage device;

decrypting the encrypted payload using a public key of the incoming call number to produce a decrypted payload containing an identifier; and

comparing the identifier of the decrypted payload to an expected identifier associated with the incoming call number to determine the match.

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

4. The method of claim 3, wherein the steps of retrieving, decrypting, comparing, and selectively establishing the call connection are performed by an interactive voice response system disposed between the first mobile telephony device and the second mobile telephony device.

5. The method of claim 3, wherein the steps of retrieving, decrypting, comparing, and selectively establishing the call connection are performed by the second mobile telephone device.

6. The method of claim 1, further comprising the steps of: pre-adding a voice message to the incoming call data stream, the voice message comprising information uniquely associated with the holder of the first mobile telephony device.

7. The method of claim 1, further comprising the steps of: pre-adding biometric information associated with the first mobile telephony device to the incoming call data stream, the biometric information comprising information uniquely associated with a holder of the first mobile telephony device.

8. The method of claim 2, wherein the encrypted payload comprises hash data, and wherein the method comprises the steps 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. 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 and comprising a password retrieved from a contactless card associated with the first mobile phone device;

a processor coupled with the interface;

a non-volatile memory having program code stored thereon, the program code when executed by the processor being operable to authenticate the incoming call data stream in response to a match between information of the encrypted payload and stored information relating to the first mobile phone device; and

a communication interface coupled with the processor and configured to selectively establish a call connection between the first mobile telephony device and the second mobile telephony device in response to the step of authenticating.

11. The system of claim 10, wherein the non-volatile memory is further configured to store a public key associated with the incoming call number, and wherein the program code is further operable to:

decrypting the encrypted payload using the public key of the incoming call number to produce a decrypted payload comprising an identifier; and is

Comparing the identifier of the decrypted payload to an expected identifier associated with the incoming call number to determine the match.

12. The system of claim 11, wherein the system comprises an interactive voice response system disposed between the first mobile phone device and the second mobile phone device to restrict access of the second mobile phone device to an authenticated caller.

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

14. The system of claim 11, further comprising: pre-adding a voice message to the incoming call data stream, the voice message comprising information uniquely associated with the holder of the first mobile telephony device.

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

16. The system of claim 10, wherein the private key comprises a dynamic key of the first mobile phone device, the encrypted payload comprises the password, and wherein the program code is further configured to:

forwarding the password to an authentication server, wherein the authentication server maintains and modifies a copy of the dynamic password as the stored information about the first mobile phone device concurrently with the first mobile phone device; and

receiving a verification of the first mobile telephony device from the authentication server in response to a counter match between a counter extracted from the password using the copy of the dynamic key and an expected counter associated with the first mobile telephony device.

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. A method for authenticating a call between mobile devices, comprising the steps of:

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, an encrypted payload comprising payload data encrypted using a private key associated with the first mobile phone device, the encrypted payload comprising a password retrieved from a contactless card associated with the first mobile phone device, and a voice message attribute;

retrieving a public key of the incoming call number from a data storage device;

decrypting the password using the public key of the incoming call number to produce 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; and

selectively establishing a connection between the first mobile phone device and the second mobile phone device in response to the first factor authentication match and the second factor authentication match.

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

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