HK40125824A - Multi-factor authentication providing a credential via a contactless card for secure messaging - Google Patents

Description

Multi-factor authentication that provides credentials for secure messages via contactless cards

Related applications

This application claims priority to U.S. Patent Application Serial No. 16/727,162, filed December 26, 2019, entitled “MULTI-FACTOR AUTHENTICATION PROVIDING A CREDENTIAL VIA A CONTACTLESS CARD FOR SECURE MESSAGING” (published August 25, 2020, under U.S. Patent No. 10,757,574). The contents of the aforementioned patent application are incorporated herein by reference in their entirety.

Background Technology

Messaging services enable multiple parties to communicate quickly and conveniently via written messages. Messaging services are increasingly used in business contexts. For example, customers can have messaging conversations with a company's customer service representatives. One limitation of traditional messaging services is their lack of security. A party in a traditional messaging session can forge phone numbers or assume a false identity. Therefore, it is difficult to transmit potentially sensitive information, such as confidential information, via traditional messaging services without fear of communicating with imposters.

Summary of the Invention

According to an exemplary embodiment, a method implemented in a computing device is performed. According to this method, a message is received at the computing device from a Short Message Service (SMS) functional device having an associated phone number. The message indicates a desire to initiate an SMS session and contains a security component. The security component is decrypted to obtain a hash of at least a one-time password and an account identifier. The one-time password and the account identifier are extracted. It is determined whether the one-time password is valid. The account associated with the account identifier is determined, and the phone number associated with the determined account is determined. It is determined whether the associated phone number matches the phone number associated with the account. When the SMS password is valid and the associated phone number is a matching phone number, a secure SMS session is initiated by sending an SMS message to the SMS functional device. When the password is invalid and/or the associated password is not a matching phone number, the initiation of a secure SMS session with the SMS functional device is rejected.

Decryption can be performed using a symmetric decryption algorithm. The method may include the following additional steps: checking the geographic location of the SMS-enabled device, and using the geographic location as another authentication factor to determine whether to initiate the secure SMS session. The received message may include receiving SMS information. The one-time password may be a time-based password. The computing device may maintain a counter and may use the value of the counter when determining whether a password has expired. The counter maintained by the computing device may be synchronized with a counter maintained by the contactless card.

According to an exemplary embodiment, a method implemented by a device with Short Message Service (SMS) functionality is performed. According to this method, an encrypted one-time password is received from a contactless card at the SMS-enabled device via near-field communication. The encrypted one-time password includes at least a one-time password and a cryptographic hash of an account identifier. The one-time password is encrypted using a symmetric encryption algorithm and is valid only for a set time period. A message is sent from the SMS-enabled device to a party to request the initiation of a secure SMS session, wherein the message includes the encrypted one-time password, and wherein the SMS-enabled device has an associated phone number. When the password is valid and when the phone number of the SMS-enabled device is associated with an account identified by the account identifier, an SMS message is received from the party at the SMS-enabled device. A chatbot may be used to participate in the secure SMS session when it is initiated.

Sending a message from an SMS-enabled device may include sending an initial SMS message. Sending a message from the SMS-enabled device may include sending a message to the party's website or sending a message directly to the party. The method may also include sending geolocation information from the SMS-enabled device to the party. SMS messages may be received from a chatbot.

According to an exemplary embodiment, a method is performed by a contactless card. According to this method, a Near Field Communication (NFC) session with a computing device is initiated. As part of the NFC session, the contactless card communicates with an application running on the computing device and transmits a password and account identifier at least once via a hash function to create a hash value. The hash value is encrypted. The encrypted hash value is passed to the application running on the computing device. The application is prompted to send a message to a remote computing device to initiate a messaging session with the remote computing device, wherein the message includes the encrypted hash value as evidence of the identity of the party wishing to initiate the messaging session.

The one-time password can be a time-based password. The contactless card maintains a counter whose value can be used to create a cryptographic hash value. The counter value is passed through the hash function. In some cases, the counter value is passed through the hash function along with the one-time password and the account identifier. The one-time password is only valid for a set time period. The NFC session is initiated in response to tapping the contactless card on a card reader in the computing device.

Attached Figure Description

Figure 1 illustrates an environment suitable for implementing exemplary embodiments.

Figure 2 illustrates a flowchart showing the steps for verifying the initiator's executable behavior in an exemplary embodiment.

Figure 3 illustrates a block diagram showing the interaction between a contactless card and a device with messaging functionality in an exemplary embodiment.

Figure 4 illustrates the message flow relative to the server computing device.

Figure 5A depicts an illustrative front view of a contactless card.

Figure 5B illustrates the hardware components of a contactless card.

Figure 5C depicts a block diagram of a messaging computing device.

Figure 5D depicts a block diagram of server computing devices and storage.

Figure 6A depicts an illustration of hashing the input to produce a hash value.

Figure 6B illustrates the different types of inputs to a hash function.

Figure 7 illustrates the encryption operations to generate secure blocks.

Figure 8 illustrates a flowchart showing the steps that can be performed to verify the initiator.

Figure 9 illustrates other types of authentication factors.

Detailed Implementation

An exemplary embodiment may use a contactless card as a secondary form of authentication for secure messaging services in multi-factor authentication. When the message source for the secure messaging service is a device with an associated phone number, that phone number can serve as the primary credential for authentication by the message service recipient. The recipient (such as a server computing device) initiating the message service session request can be programmed to use the originating device's phone number to query records about the party's identity and its associated phone number as the primary credential, and may then require authentication credentials from the contactless card as secondary credentials for the initiator. In some cases, the credential from the contactless card is a one-time password valid only for a specific period. The recipient determines whether the one-time password is valid. If both credentials are valid, a secure messaging session with the initiator can be initiated.

Messaging services can take many forms. For example, a messaging service can be a Short Message Service (SMS). Messaging services can also be instant messaging services, social media messaging services, video messaging services, chat applications, or virtual assistant applications, etc.

Because the messaging service described herein employs multi-factor authentication for the initiator of the messaging session, non-initiators participating in the session have enhanced confidence in communicating with the authenticated party. Therefore, the risk of impersonation in the messaging session is significantly reduced. Consequently, the secure messaging service disclosed herein is well-suited for exchanging potentially sensitive information, such as financial information, health information, business information, driving records, criminal records, and other types of confidential information. The secure messaging service described herein is ideal for communication between clients and financial institution representatives, patients and healthcare providers, insured and insurance company representatives, clients and lawyers, clients and accountants, and company employees. Encryption and secure hashing can be used to protect the content of messages exchanged via the secure messaging service.

One-time passwords can be encrypted as part of a secure packet passed from the initiator of a secure messaging session to the recipient. This secure packet can contain identifying information for the initiator, such as account information. Before adding the one-time password to the packet and encrypting it, it can be hashed using a counter value. This counter serves as a time indicator and helps define the password's lifespan.

As part of authentication, the recipient decrypts the security packet. The recipient can maintain its own counter value, synchronized with the counter value maintained by the initiator. If the counter value used by the initiator in the security packet does not match or differs significantly from the counter value maintained by the recipient, it can be an indication that the one-time password is no longer valid. The recipient checks if the one-time password is correct. Additionally, the recipient can use account information to retrieve the phone number of the party associated with that account. The recipient can check if the retrieved phone number matches the phone number of the device from which the request originated. If the phone number matches and the one-time password is correct and not expired, the recipient can initiate a messaging service by prompting the non-initiator to send a message to the initiator. The non-initiator can be a person or a chatbot and can communicate via a server or a separate client device. If the initiator's authentication fails, no message may be sent from the non-initiator, or a rejection message may be sent from the non-initiator.

Figure 1 illustrates an environment 100 suitable for implementing an exemplary embodiment. This environment includes a contactless card 102 issued by an issuer to an initiator 101. The initiator 101 holds the contactless card 102, and given that the contactless card 102 can generate credentials for verifying the initiator's identity, it is recommended that the initiator 101 keep the contactless card 102 secure and in their possession. The contactless card 102 can be used in conjunction with a messaging-enabled computing device 104. The messaging-enabled computing device 104 supports one or more messaging services, such as those described above. The messaging-enabled computing device 104 can be a smartphone, desktop computer, laptop computer, tablet computer, wearable computing device, or any computing device that supports messaging services and enables the initiator 101 to participate in the secure messaging services described herein.

As will be described in more detail below, the contactless card 102 can be used for authentication of the initiator 101 by first interfacing with the messaging computing device 104. The messaging computing device 104 has a near-field communication (NFC) reader that can read the contactless card 102 and communicate bidirectionally with it. The messaging computing device 104 interfacing with a network 106. The network 106 may include a wired network and/or a wireless network. The network 106 may include a local area network (LAN) and/or a wide area network (WAN), including the Internet. A server computing device 108 is connected to the network 106. The server computing device 108 (e.g., the receiver) receives a request to initiate a secure messaging system from the initiator 101 via the messaging computing device 104 through a messaging service and is responsible for performing authentication. The non-initiator 110 may be a party accessing the server computing device 108 or a client of the server computing device participating in a chat session using another computing device. The non-initiator 110 may be a person, a chatbot, or a smart agent.

Figure 2 illustrates a flowchart of the steps that can be performed in an example embodiment to authenticate an initiator who wishes to initiate a secure messaging service session with a non-initiator. These steps are described below with respect to Figures 3 and 4. The process can begin with one party tapping a contactless card 302 (see Figure 3) against a reader 307 in a messaging functional computing device 306 (202). In some embodiments, the contactless card 302 and the reader 307 communicate via a Near Field Communication (NFC) protocol. The tap initiates NFC communication between the contactless card and the reader 307 in the messaging functional computing device 306. In other cases, the contactless card 302 does not need to tap the reader 307, but may only need to be close enough to the reader 307 to initiate an NFC communication session. In the NFC communication session, a secure packet 304 is sent from the contactless card 302 to the messaging functional computing device 306, which includes the secure packet. The contactless card 302 may then prompt an application running on the messaging functional computing device 306 to generate a message for the recipient. In a direct approach, the application is a chat application, such as an SMS messaging application or an application used for one of various other messaging services. As described below, the messaging-enabled computing device 306 generates an authentication to attempt to initiate a secure messaging session. In an indirect approach, a contactless card 302 provides the server with a unified resource locator (URL) including the phone number of the server contacted from the messaging-enabled computing device 306 to attempt to initiate a secure messaging service. The messaging-enabled computing device 306 generates a message 308 encapsulating a secure packet 310, which is sent to the server computing device 406 (see Figure 4) (204) as a request to initiate the secure messaging system.

The request can be sent to server computing device 406 via a messaging service or via another channel. As described above, security packet 310 may include a one-time password and identification information for the initiator. These will be discussed in more detail below. Server computing device 406 receives message 402 and extracts the one-time password and other information (such as identification information and counter values) from security packet 404 (206). Based on the extracted information, server computing device 406 successfully authenticates the initiator or fails to authenticate the initiator (208). If the initiator is successfully authenticated, a response message 410 from non-initiator 408 is sent to the initiator (212) via the messaging service. Response message 410 may notify the initiator that they have been authenticated, or, for example, may simply greet the initiator and may inquire about the content of their communication with non-initiator 408. Conversely, if the initiator is not successfully authenticated, a response message 410 rejecting the request from the secure messaging system is sent to the initiator (210). In some alternative exemplary embodiments, no message is sent back to the initiator in this case.

The contactless card 500 shown in Figure 5A can be a payment card issued by a service provider 505 (displayed on the front or back of the card 500), such as a credit card, debit card, or gift card. In some exemplary embodiments, the contactless card 500 is independent of the payment card and may include, but is not limited to, an identification card. In some cases, the payment card may include a dual-interface contactless payment card. The contactless card 500 may include a substrate 510, which may include a single layer or laminate composed of plastics, metals, and other materials. Typical substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 500 may have physical characteristics conforming to the ID-1 format of the ISO/IEC 7810 standard, and the contactless card 500 may conform to the ISO/IEC 14443 standard. However, it should be understood that the contactless card 500 according to this disclosure may have different characteristics, and this disclosure does not require the contactless card to be implemented in a payment card.

The contactless card 500 may also include identification information 515 displayed on the front and/or back of the card and a contact pad 520. The contact pad 520 may be configured to establish contact with another communication device, such as a user equipment, smartphone, laptop, desktop computer, or tablet computer. The contactless card 500 may also include processing circuitry, an antenna, and other components not shown in Figure 5A. These components may be located behind the contact pad 520 or elsewhere on the substrate 510. The contactless card 500 may also include a magnetic stripe or magnetic tape (not shown in Figure 5A) located on the back of the card.

As shown in Figure 5B, the contact 520 of Figure 5A may include processing circuitry 525 for storing and processing information, including a microprocessor 530 and a memory 535. It should be understood that the processing circuitry 525 may include additional components, including a processor, memory, error and parity/CRC checkers, a data encoder, an anti-collision algorithm, a controller, a command decoder, security components, and tamper-proof hardware, as necessary for performing the functions described herein.

Memory 535 can be read-only memory, write-multiple-read memory, or read/write memory, such as RAM, ROM, and EEPROM, while the contactless card 500 may include one or more of such memories. Read-only memory can be programmed at the factory to be read-only or one-time programmable. One-time programmability provides the opportunity to write once and then read multiple times. Write-multiple-read memory can be programmed at some point after the memory chip leaves the factory. Once programmed, the memory may not be overwritten, but it can be read multiple times. Read/write memory can be programmed and reprogrammed many times after leaving the factory. It can also be read multiple times.

Memory 535 may be configured to store one or more applets 540, one or more counters 545, and a customer identifier 550. The one or more applets 540 may include one or more software applications configured to execute on one or more contactless cards, such as Java card applets. However, it should be understood that applet 540 is not limited to Java card applets, but may be any software application that can operate on a contactless card or other device with limited memory. The one or more counters 545 may include numeric counters sufficient to store integers. The customer identifier 550 may include a unique alphanumeric identifier assigned to a user of the contactless card 500, and the identifier may distinguish the user of the contactless card from other contactless card users. In some examples, the customer identifier 550 may simultaneously identify a customer and the account assigned to that customer, and may further identify the contactless card associated with that customer account.

The processor and memory elements of the exemplary embodiments described above are described with reference to the contact pad, but this disclosure is not limited thereto. It should be understood that these elements may be implemented outside of the contact pad 520, or completely separate from it, or as further elements in addition to the processor 530 and memory 535 elements located within the contact pad 520.

In some examples, the contactless card 500 may include one or more antennas 555. The one or more antennas 555 may be positioned within the contactless card 500 and around the processing circuitry 525 of the contact pad 520. For example, the one or more antennas 555 may be integrated with the processing circuitry 525, and the one or more antennas 555 may be used in conjunction with an external boost coil. As another example, the one or more antennas 555 may be located outside the contact pad 520 and the processing circuitry 525.

In one embodiment, the coil of the contactless card 500 can serve as the secondary winding of an air-core transformer. The terminal can communicate with the contactless card 500 by disconnecting the power supply or by amplitude modulation. The contactless card 500 can infer data transmitted from the terminal using gaps in the contactless card's power connection, which can be functionally maintained through one or more capacitors. The contactless card 500 can perform reverse communication by switching the load or modulating the load on the contactless card's coil. Load modulation can be detected in the terminal coil by interference.

As described above, the contactless card 500 can be built on a software platform that operates on smart cards or other devices with limited memory, such as Java cards, and can securely execute one or more applications or applets. Applets can be added to the contactless card to provide a one-time password (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. The appletter can be configured to respond to one or more requests from a reader (such as a mobile NFC reader), such as a near-field data exchange request, and generate an NDEF message that includes an encrypted secure OTP encoded as an NDEF text tag.

Figure 5C depicts a block diagram illustrating the components of a messaging-enabled computing device 540. The messaging-enabled computing device 540 may include a processor 542. The processor 542 may be a microprocessor, such as a central processing unit (CPU), a graphics processing unit (GPU), etc. The processor 542 may be implemented as a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a controller, circuitry, or the like, providing the functionality described herein to a processor of the messaging-enabled computing device 540. The messaging-enabled computing device 540 may include a memory 544. The memory 544 may include volatile and/or non-volatile memory. The memory 544 may include optical and/or magnetic storage devices and may include a non-transitory computer-readable storage medium storing instructions executed by the processor 542. The memory 544 may include a disk drive, an optical disk drive, solid-state storage, read-only memory, random access memory, flash memory, and the like. As depicted in Figure 5C, the memory 544 stores an application 546, such as a messaging application or an application providing the functionality described herein. Memory 544 may also store computer-executable instructions for providing proximity protocol support 208 for NFC communication. Furthermore, memory 544 may store a web browser 551 for convenient web access. It should be understood that memory 204 may store other programs and data not described.

The messaging computing device 540 may include an NFC reader 561 for participating in NFC communications. The messaging computing device 540 may also include a display 552, such as a light-emitting diode (LED) display, a liquid crystal display (LCD), or a retina display. The messaging computing device 540 may include a wireless modem 554 for communicating over a wireless network, such as a cellular telephone network. The computing device 540 with messaging capabilities may include a camera 556 for capturing images and/or video. The camera 556 may also be used to scan optical codes.

Figure 5D depicts a block diagram of a server computing device 560. The server computing device 560 can take many forms, including but not limited to desktop computers, workstations, or servers. The server computing device 560 may include a processor 562. The processor 562 can take any of many forms, such as those discussed in relation to the messaging function computing device in Figure 5C. The server computing device 560 may include or have access to memory 564. Memory 564 may include various forms of storage associated with the messaging function computing device in Figure 5C. Memory 564 may store programs, applets, and/or executable code that can be executed by the processor 562. For example, memory may store a synchronization counter 566 as described below. Memory 564 may also store decryption software 568 for decrypting secure packets and hashed content, as well as encryption/decryption keys 571. Memory 564 may store messaging service software 573 for secure messaging services. Memory 564 may store software for a web server 572 and a chatbot 574. Memory 564 may store account information 576 for clients or customers. In some example embodiments, the account information 576 may be stored in a database.

Typically, the server computing device 560 (or another computing device) and the contactless card 500 can be configured with the same master key (also known as a master symmetric key). More specifically, each contactless card 500 is programmed with a different master key, which has a corresponding pair within the server computing device 560. For example, when manufacturing the contactless card 500, a unique master key can be programmed into the memory 535 of the contactless card 500. Similarly, the unique master key can be stored in the customer records associated with the contactless card 500 in the account information 576 of the server computing device 560 (and/or stored in a different secure location). The master key can be kept confidential from all parties except the contactless card 500 and the server computing device 560, thereby improving system security.

The master key can be used in conjunction with counter 104 to enhance security through key diversification. Counters 545 and 566 contain values synchronized between the contactless card 500 and the server computing device 560. These counter values may include numbers that change each time data is exchanged between the contactless card 500 and the server computing device 560 (and/or the contactless card 500 and the messaging computing device 540). To enable NFC data transfer between the contactless card 500 and the messaging computing device 540, application 546 can communicate with the contactless card 500 when the contactless card 500 is sufficiently close to the NFC reader 561 of the messaging computing device 540. The NFC reader 561 can be configured to read from and/or communicate with the contactless card 500.

For example, a user can tap a contactless card 500 against a messaging computing device 540, bringing the card close enough to the NFC reader 561 of the device to allow NFC data transfer between the devices to trigger the NFC reader 561 via an API call. Additionally and/or alternatively, the messaging computing device 540 can also trigger the NFC reader 561 by periodically polling it. More generally, the messaging computing device 540 can trigger the NFC reader 561 for communication using any feasible method. After communication is established between the messaging computing device 540 and the contactless card 500, the contactless card 500 can generate a Message Authentication Code (MAC) message. In some examples, this may occur when the contactless card 500 is read by an application 546. In particular, this can occur during the reading of Near Field Data Exchange (NDEF) tags, such as NFC reads, which can be created according to the NFC data exchange format. For example, a card reader (such as application 546 and/or NFC card reader 561) can transmit a message (such as a mini-program selection message) with a mini-program ID generated by the NDEF. After confirming the selection, a series of select file messages can be transmitted, followed by read file messages. For example, the sequence could include "select capability file", "read capability file", and "select NDEF file". At this point, a counter value maintained by the contactless card 500 can be updated or incremented, followed by "read NDEF file". At this point, a message containing a header and a shared secret can be generated. A session key can then be generated. A MAC message can be created from the message, which can include a header and a shared secret. The MAC message can then be concatenated with one or more random data blocks, and the MAC message and random number (RND) can be encrypted with the session key. Subsequently, the message and header can be concatenated, encoded into ASCII hexadecimal, and returned in NDEF message format (in response to the "read NDEF file" message). In some examples, the MAC message can be transmitted as an NDEF tag, and in other examples, the MAC message can contain a uniform resource indicator (e.g., as a formatted string). The contactless card 500 can then transmit the MAC message to the messaging function computing device 540, which can then forward the MAC message to the server computing device 560 for verification, as explained below. However, in some embodiments, the messaging function computing device 540 can verify the MAC message itself.

More typically, when ready to send data (e.g., to server 560 and/or messaging-enabled computing device 540), contactless card 540 may increment counter 545. Contactless card 500 then provides a master key and the counter value as input to a cryptographic algorithm, which produces a variety of keys as output. The cryptographic algorithm may include encryption algorithms, hash-based message authentication code (HMAC) algorithms, password-based message authentication code (CMAC) algorithms, etc. Non-limiting examples of cryptographic algorithms may include symmetric encryption algorithms such as 3DES or AES128; symmetric HMAC algorithms such as HMAC-SHA-256; and symmetric CMAC algorithms such as AES-CMAC. Contactless card 500 can then encrypt data (e.g., customer identifier 107 and any other data) using the variety of keys. Contactless card 500 can then transmit the encrypted data to application 546 of messaging-enabled computing device 546 (e.g., via NFC connection, Bluetooth connection, etc.). Then, application 546 of the messaging-enabled computing device 540 can transmit encrypted data to the server computing device 560 via network 106. In at least one embodiment, the contactless card 500 transmits a counter value containing encrypted data. In these embodiments, the contactless card 500 may transmit either an encrypted counter value or an unencrypted counter value.

While a counter is used as an example, other data can also be used to secure communication between the contactless card 500, the messaging computing device 540, and/or the server computing device 560. For example, the counter could be replaced with a random unauthorized code, a new diversified key generated each time, the full value of the counter sent from the contactless card 500 and the server computing device 560, a portion of the counter value sent from the contactless card 500 and the server computing device 560, a counter maintained independently by the contactless card 500 and the server computing device 560 but not sent between them, a one-time password exchanged between the contactless card 500 and the server computing device 560, and an encrypted hash of the data. In some examples, parties can use one or more portions of a diversified key to create multiple diversified keys.

The generation of secure block 404 (Figure 4) can employ a cryptographic hash function, such as MD5 or SHA-1. Figure 6A shows block diagram 600, which illustrates how a cryptographic hash function can be used in an exemplary embodiment. In the example shown in Figure 6A, three inputs 602, 604, and 606 are passed together through hash function 608. The choice to describe three inputs is for illustrative purposes rather than limiting. In some cases, other numbers of inputs may be used. Hash function 608 produces an output hash value 610. Due to the characteristics of hash function 608, it is computationally difficult to derive inputs 602, 604, and 606 from hash value 610 without knowing the key 607 used by hash function 608. Key 609 is kept secret. Key 607 can be dynamically generated for each session and can be specific to the contactless card. Therefore, hash function 608 provides a layer of security for the contents contained in secure block 404 (e.g., inputs 602, 604, and 606).

In exemplary embodiments, inputs 602, 604, and 606 may vary depending on the information the parties wish to exchange and the protocol used to verify the initiator. Figure 6B shows Figure 640 of possible types of input 642 that can be hashed in an example embodiment. In these exemplary embodiments, a one-time password 644 generated by a contactless card may be included as input. An account identifier 646 may be provided to the initiator. This may be a number or other identifier that uniquely identifies the initiator's account. As mentioned above, the account identifier may be a telephone number used by the initiator. In some cases, the initiator's telephone number may not be included in the hash value 610 but may be derived from a message sent from the messaging function computing device 540. Input 642 may include the initiator's name 650.

As an additional security measure, hash value 610 can be encrypted. Figure 7 shows a block diagram 700 illustrating this encryption. The hash value 702 generated as described above is passed to encryption engine 704, which encrypts the hash value using encryption key 706. The resulting output is a secure block 708. Encryption engine 704 can use any of a variety of encryption algorithms, such as DES, AES, RSA, DSA, or similar algorithms. These can be symmetric cryptographic algorithms, such as DES and AES, or asymmetric cryptographic algorithms, such as RSA and DSA. It is assumed that server computing device 406 (Figure 4) possesses a suitable key to decrypt the secure block. Although not shown in Figure 7, other content can be encrypted along with hash value 702.

Figure 8 illustrates a flowchart of steps 800 performed to authenticate the initiator once the server computing device, as the receiving party, receives an authentication message with a secure packet. Initially, the server computing device decrypts the secure packet using a decryption key. Furthermore, the decryption key is used to decrypt the hash to extract the input hashed together by the hash function (801). The extracted password and counter value can be compared with a valid password and a valid counter value (802). It is determined whether the password and counter value match, or whether the extracted counter value indicates that the password has not expired (804). Based on the extracted counter value, if the password matches and the extracted password has not expired, other extracted information can be compared (806).

Other information may be other authentication factors 902, such as those shown in Figure 9, Appendix 900. Other authentication factors 902 may include the telephone number of the messaging function computing device, which can be compared with the telephone number recorded by the initiator. Other authentication factors 902 may include the geographic location 906 for the initiator. Geographic location 906 may be information such as GPS information, area code, and exchange prefix information, which can be compared with information about the party's place of residence. Other authentication factors 902 may include a shared secret shared between the verified party and the server computing device.

If the other information is valid (808), the initiator can be verified (812). If not, the initiator is not verified (810). Similarly, if the retrieved counter value indicates that the password does not match or the password has expired, the initiator is not verified (810).

While the invention has been described with reference to exemplary embodiments herein, it should be understood that various changes may be made to the scope and details without departing from the intended scope as defined in the appended claims.

Claims (10)

1. A method implemented in a computing device, comprising: A message is received at the computing device from a Short Message Service (SMS) device with an associated telephone number, wherein the message indicates a desire to initiate an SMS session, and wherein the message includes a security component; The security component is decrypted to obtain a hash of at least a one-time password and an account identifier; Extract the one-time password and the account identifier; Determine whether the one-time password is valid; Identify the account associated with the account identifier; Access the phone number associated with the identified account; Determine whether the relevant phone number matches the phone number associated with the account; When the password is valid and the associated phone number is a matching phone number, a secure SMS session is initiated by sending an SMS message to the SMS-enabled device; and If the password is invalid and/or the associated password does not match the phone number, a secure SMS session with the SMS-enabled device is refused. 2. The method according to claim 1, wherein the decryption uses a symmetric decryption algorithm. 3. The method according to claim 1, further comprising: Check the geographical location of the SMS-enabled device; and The geographic location is used as another authentication factor to determine whether to initiate the secure SMS session. 4. The method according to claim 1, wherein receiving the message includes receiving an SMS message. 5. The method according to claim 1 further includes using a chatbot to participate in the secure SMS session when initiating the secure SMS session. 6. The method according to claim 1, wherein the one-time password is a time-based password. 7. The method of claim 1, wherein the computing device maintains a counter, and wherein the computing device uses the value of the counter when determining whether a password has expired. 8. The method of claim 7, wherein the counter maintained by the computing device is synchronized with the counter maintained by the contactless card. 9. A method for implementing Short Message Service (SMS) functionality on a device, comprising: The device receives an encrypted, secure one-time password from the contactless card via near-field communication, wherein: The encrypted secure one-time password includes at least a one-time password and an encrypted hash of the account identifier. The one-time password is encrypted using a symmetric encryption algorithm, and The one-time password is only valid for the specified time period; The SMS-enabled device sends a message to one party to request the initiation of a secure SMS session, wherein the message includes the encrypted one-time password, and wherein the SMS-enabled device has an associated phone number; and When the password is valid and when the phone number of the SMS-enabled device is associated with an account identified by the account identifier, an SMS message is received from the party at the SMS-enabled device. 10. A method performed by a contactless card, comprising: Initiate a near field communication (NFC) session with the computing device; As part of the NFC session Communicating with applications running on the computing device; A hash value is created by passing at least a one-time password and an account identifier through a hash function; Encrypt the hash value; The encrypted hash value is passed to the application running on the computing device; and The application is prompted to send a message to a remote computing device to initiate a messaging session with the remote computing device, wherein the message includes an encrypted hash value as evidence of the identity of the party wishing to initiate the messaging session.