Multi-factor authentication through device and carrier verification

Abstract

This invention provides a multi-factor authentication (MFA) system, method, and computer-readable media using device and carrier authentication. [Solution] The user device generates a certified blob containing an encrypted key and an International Mobile Subscriber Identification Number (IMSI) originating from a Universal Integrated Circuit Card (UICC), and sends it to a cloud-based MFA service. The service verifies this certified blob, coordinates with the original equipment manufacturer (OEM) service, and establishes mutual trust by performing an Enhanced Authentication Protocol - Authentication and Key Agreement (EAP-AKA) process with the carrier network. The authentication data (including a verified phone number independent of the number stored on the device) is securely stored in a cloud wallet.

Description

Background Art

[0001] 1. Field of the Invention

[0002] Embodiments described herein generally relate to security protocols for multi-factor authentication and verifying user identification in digital platforms. More specifically, embodiments described herein relate to systems and methods for improving the reliability of authentication and ensuring secure access to resources by leveraging communication networks and cryptographic techniques and integrating device verification mechanisms and carrier verification mechanisms.

[0003] 2. Brief Description of the Related Art

[0004] Current multi-factor authentication (MFA) systems, especially those that rely on SMS-based one-time passwords (OTP), have significant vulnerabilities that compromise security and reliability. Despite the widespread adoption of SMS-based MFA, it has flaws due to technical constraints and structural weaknesses and is not suitable for applications that require high security.

[0005] One of the most significant drawbacks is the lack of end-to-end encryption in the SMS communication protocol. SMS messages containing OTPs are transmitted without being encrypted at multiple points along the communication path. Attackers can intercept these messages using techniques such as man-in-the-middle attacks (MITM), base station impersonation, or attacks using rogue base stations. Furthermore, the reliance on the legacy Signaling System 7 (SS7) protocol exacerbates these vulnerabilities. SS7 lacks modern security mechanisms and is vulnerable to unauthorized access. Intercepted OTPs are exploited to bypass authentication means, posing serious risks to user accounts and sensitive transactions.

[0006] Another critical vulnerability stems from the fact that phone numbers are used as the primary identifier in SMS-based MFA systems. Attackers often exploit this dependency through SIM swap attacks and number porting attacks. In these attacks, the attacker illegally transfers the victim's phone number to a new SIM card under their control. This allows the attacker to receive all SMS messages addressed to the victim, including OTPs. The fact that mobile carriers' identity verification procedures often rely on easily compromised personal information further increases the risk of such attacks.

[0007] SMS-based MFA also has the problem of not being able to verify the authenticity of the device receiving the OTP itself. Current systems do not verify whether the device is genuine and authorized to receive sensitive authentication information. As a result, attackers can register disposable or virtual phone numbers and use them to bypass authentication. Furthermore, malware present on the user's device may intercept the OTP and transmit it externally without the user's knowledge, exploiting the lack of device-level verification mechanisms.

[0008] A structural reliance on SS7 poses additional risks beyond message interception. Attackers can exploit SS7 vulnerabilities to manipulate message routing, track user location, and impersonate legitimate carriers. These vulnerabilities exist independently of user behavior, demonstrating that SMS as an authentication method is inherently insecure.

[0009] Replay attacks are another weakness in SMS-based multi-factor authentication (MFA). One-time passwords (OTPs) intercepted during transmission can be reused by attackers and used to gain unauthorized access or conduct fraudulent transactions. While many systems impose time limits on OTPs, this is insufficient protection against attackers who can exploit OTPs intercepted within their validity period.

[0010] SMS-based multi-factor authentication (MFA) also presents challenges in terms of usability and accessibility. Delays in OTP delivery due to network congestion, international roaming issues, or communication failures can hinder timely authentication and impede access to critical services. Furthermore, it can exclude users who do not have access to mobile phones, reducing inclusivity and creating barriers for certain user segments.

[0011] From a regulatory standpoint, SMS-based multi-factor authentication (MFA) often fails to meet the stringent security requirements mandated by frameworks such as the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA). The transmission of unencrypted OTPs raises data privacy concerns and could lead to legal and financial liability for organizations.

[0012] Furthermore, SMS-based MFA is extremely vulnerable to phishing and social engineering attacks. Attackers can circumvent intended security measures by deceiving users with fraudulent SMS messages, voice calls, or emails to trick them into voluntarily disclosing their One-Time Password (OTP). These attacks exploit human behavior rather than technical flaws, making them particularly difficult to counter within the existing framework of SMS-based MFA. [Overview of the project]

[0013] This invention relates to a system, method, and computer-readable recording medium for establishing mutual trust between a user device and a carrier network through a robust multi-factor authentication (MFA) framework. By combining cryptographic techniques, device-level verification, and a carrier-integrated authentication process, this invention provides a secure and scalable solution to modern authentication challenges.

[0014] The present invention begins with a user device generating a certified blob. The certified blob is a cryptographically protected data structure containing elements necessary for authentication, including a device MFA public key, a device International Mobile Subscriber Identification Number (IMSI) originating from a Universal Integrated Circuit Card (UICC), and a device token. Optionally, the certified blob may further include a certified signature generated by a device MFA service. The certified signature is generated using a private key securely stored within the device's Trusted Execution Environment (TEE) and certifies the authenticity and integrity of the data contained in the blob. The certified blob is transmitted from the user device to a cloud-based multi-factor authentication (MFA) service, which plays a central role in managing and protecting the authentication process.

[0015] The cloud MFA service verifies the request and sends the certified blob to the original equipment manufacturer (OEM) identification service. The OEM identification service verifies the certified blob by verifying the certified signature, confirming that the data originates from a legitimate and secure device and complies with specified security requirements. This additional verification layer ensures that only authorized devices can participate in the MFA process.

[0016] Following verification by the OEM Identification Service, the Cloud MFA Service transmits the Device IMSI, originating from a Universal Integrated Circuit Card (UICC), contained in the Certified BLOB to a Home Operator Node associated with the carrier network. The Home Operator Node may be implemented as a Home Location Register (HLR) in 2G and 3G networks, and as a Home Subscriber Server (HSS) in LTE and 5G networks. The Home Operator Node initiates the Extensible Authentication Protocol – Authentication and Key Agreement (EAP-AKA) process, in which it generates an aka challenge containing a nonce and other cryptographic elements necessary for mutual authentication. The generated aka challenge is transmitted to the Cloud MFA Service and forwarded to the user device via the Cloud MFA Service.

[0017] Upon receiving the aka challenge, the user device calculates a corresponding aka response using the cryptographic key and algorithm stored on the Universal Integrated Circuit Card (UICC). The aka response and the nonce are sent to the cloud MFA service, which verifies the aka response by checking whether it matches the expected value derived from the aka challenge. In the next step, cryptographic verification is performed using a key provided by the carrier to confirm that the cryptographic function matches that of the UICC. If this verification is successful, the authenticity of the user device is confirmed, and mutual trust is established between the device and the carrier network.

[0018] Once mutual trust is established, the home operator node provides the cloud MFA service with the verified phone number associated with the device. Importantly, the verified phone number is derived directly from the carrier network and is independent of any phone number stored on the device itself. This prevents the authentication process from being compromised by spoofed or tampered device information.

[0019] The cloud MFA service stores the verified phone number, the device token, the device IMSI originating from the Universal Integrated Circuit Card (UICC), and the device MFA public key in a secure cloud wallet. The secure cloud wallet functions as a repository for aggregating and managing critical authentication data and is configured to ensure the integrity, confidentiality, and availability of the stored information. This enables efficient management of authentication sessions and provides reliable reference information for subsequent verification requests.

[0020] The present invention supports several advanced security features to enhance the robustness of the system. For example, the cloud MFA service can periodically re-verify the device IMSI originating from a Universal Integrated Circuit Card (UICC) by repeating the Extended Authentication Protocol - Authentication and Key Agreement (EAP-AKA) process. This ensures that the device maintains compliance with reliability and security standards over the long term. The cloud MFA service also protects communication channels using post-quantum cryptography algorithms to protect sensitive data from emerging computational threats such as quantum computers.

[0021] The present invention also includes a mechanism for responding to specific events that may affect the security of the authentication process. For example, if the device MFA service detects a device event such as the replacement of a Universal Integrated Circuit Card (UICC), removal of a SIM card, or reactivation of the device, it initiates a provisioning process. This process includes the device MFA service generating a new key pair, performing carrier verification, and updating the associated data stored in the secure cloud wallet. The establishment of new keys and carrier verification ensure resilience against potential security breaches resulting from changes in the device environment.

[0022] Furthermore, the cloud MFA service generates a device push notification to enable interaction with the user during authentication. The notification includes transaction details or authentication request encrypted using a key derived from the device MFA public key, which the user reviews and approves. Once the user gives consent, the device MFA service generates an encrypted user consent response, which is sent to the cloud MFA service for verification. This process provides an additional user-driven security layer, ensuring that only authorized operations are performed.

[0023] The present invention further includes additional cryptographic processing. For example, the cloud MFA service can generate a shared key by encapsulating the device MFA public key and store the shared key together with other authentication data in a secure cloud wallet. The shared key is used to encrypt sensitive information such as aka challenges and transaction details, ensuring secure communication between the cloud MFA service and the user device. Similarly, the device MFA service can derive a shared key by decapsulating encrypted data received from the cloud MFA service using its private key, thereby completing the key exchange process.

[0024] This invention also addresses situations where a discrepancy occurs between a verified phone number obtained from a home operator node and a phone number previously stored in a secure cloud wallet. This allows for a change of phone number, and the newly obtained phone number from the home operator node is used. Furthermore, in devices that support multiple lines, individual provisioning is performed for each phone number.

[0025] The present invention can be implemented as a system or as a computer-readable recording medium. The system includes a cloud-based multi-factor authentication (MFA) service configured to execute all the steps described herein, including receiving and verifying a certified BLOB in cooperation with an OEM identification service and a home operator node, and managing authentication data in a secure cloud wallet. The computer-readable recording medium stores instructions that, when executed by a processor, cause the cloud MFA service to execute similar steps, ensuring that the present invention can be deployed in various technical environments.

Brief Description of the Drawings

[0026] To understand the present invention more fully, the following detailed description will be made with reference to the accompanying drawings. In each drawing, the same or corresponding components are denoted by the same reference numerals.

[0027] [Figure 1] FIG. 1 is a diagram showing a call flow for service activation using initial key exchange by ML-KEM.

[0028] [Figure 2] FIG. 2 is a diagram showing a call flow for service activation that lists and shows the AKA process.

[0029] [Figure 3] FIG. 3 is a diagram showing a call flow that lists and shows the integration of an enterprise and an aggregator.

[0030] [Figure 4] FIG. 4 is a diagram showing a call flow that lists and shows the re-keying process.

[0031] [Figure 5] FIG. 5 is a schematic diagram showing a first step in device activation according to the present invention.

[0032] [Figure 6]Figure 6 is a schematic diagram showing the second step in device activation according to the present invention. [Modes for carrying out the invention]

[0033] Figure 1 shows the call flow for service activation, focusing particularly on the initial key exchange process using ML-KEM (Modular Lattice Key Encapsulation Mechanism). The entities involved include the device MFA service (12), the device's Trust Execution Environment (TEE) (14), the cloud MFA service (16), the OEM identification service (18), the device push notification service (20), and the home node (22). Each of these elements plays a different role in establishing mutual trust between the user device and the network.

[0034] The process begins in step (24), when the device MFA service generates a key pair using the ML-KEM-1024 algorithm. This cryptographic key pair ensures secure communication and data encapsulation. The public key is obtained in step (26) from the device's TEE(14), which is a secure environment within the device configured to protect sensitive data.

[0035] In step (28), the device MFA service (12) obtains the International Mobile Subscriber Identification Number (IMSI) from the Universal Integrated Circuit Card (UICC). The IMSI serves as an identifier that uniquely identifies the user device within the carrier network. Subsequently, in step (30), the device MFA service (12) generates a device token used for push notifications and session tracking during the authentication process. In step (32), these elements are combined with the public key to generate a certified blob. The certified blob, containing the public key, IMSI, and device token, is cryptographically signed by the TEE and then returned to the device MFA service in step (34). The certified blob is sent to the cloud MFA service (16) in step (36) as part of the multi-factor authentication activation process.

[0036] In step (36), upon receiving the certified BLOB, the cloud MFA service verifies the request and, in step (38), communicates with the OEM identification service (18) to verify the authenticity of the device by verifying the cryptographic signature of the BLOB. Once the device is verified, elements such as the public key, IMSI, and device token packaged within the BLOB are returned to the cloud MFA service in step (40). In step (42), the cloud MFA service generates a shared key by encapsulating the public key, stores the shared key together with the IMSI and device token in an encrypted form in step (44), and returns the generated ciphertext to the device.

[0037] The process is completed in step (46), and the generated ciphertext and other tracking data are sent to the device MFA service for decapsulation. The device MFA service uses its private key to decapsulate the ciphertext in step (48) and obtain the shared key. Once it is confirmed that this key exchange was successfully completed in step (52), a secure synchronization is established between the device and the network, which will be used for subsequent authentication processes. The decapsulated shared key is stored in the TEE in step (50) for subsequent cryptographic processing.

[0038] Figure 2 further illustrates service activation by detailing the Extensible Authentication Protocol - Authentication and Key Agreement (EAP-AKA) process. This process establishes mutual trust between the user device and the carrier network. Similar to Figure 1, the main components include the device MFA service (12), the device TEE (14), the cloud MFA service (16), the OEM identification service (18), the device push notification service (20), and the home node (22).

[0039] The process begins in step (54), when the device MFA service verifies that the shared key generated in the initial key exchange has been successfully established. In step (56), the cloud MFA service requests the home node (22) to start the AKA process by sending the previously obtained IMSI. In step (58), the home node responds by sending a quintaplet containing the cryptographic parameters required for the AKA process.

[0040] In step (60), the cloud MFA service encrypts the aka challenge using the shared key and forwards it to the device MFA service in step (62). Upon receiving the encrypted aka challenge, the device MFA service decrypts it in steps (64, 66) and calculates the aka response in step (68) using a secure algorithm stored in UICC. Further cryptographic processing is performed using the key stored in UICC, and the result is included in the aka response.

[0041] The aka response is encrypted in steps (70, 72) and sent to the cloud MFA service in step (74). The cloud MFA service decrypts it in step (74), verifies that it matches the expected response in step (78), performs cryptographic verification, and then sends a request to the home node to obtain the MSISDN. The home node obtains the Mobile Communications International Subscriber Number (MSISDN) from its database. The MSISDN functions as a verified telephone number and is sent back to the cloud MFA service in step (80) and stored in the secure cloud wallet in step (82). To complete the provisioning process, a success response is sent back to the device MFA client in step (84).

[0042] Figure 3 illustrates the integration of the cloud MFA service with enterprise systems and aggregators. This figure shows how device push notifications are used for user consent verification and transaction approval.

[0043] The process begins in step (86), when the enterprise / aggregator (84) sends the transaction details to the cloud MFA service. In step (88), the cloud MFA service encrypts the message and nonce using the device's shared key. The encrypted data is sent to the device push notification service in step (90) and delivered as a push notification to the user device in step (94). The user device decrypts the message in step (96) and displays the transaction details to the user in step (100).

[0044] In step (100), the user agrees to or rejects the transaction. The device MFA service encrypts the user's response in step (102) and sends it to the cloud MFA service in step (104). The cloud MFA service decrypts the user's response in step (106) and verifies the consent. The confirmation is sent back to the device in step (108). The result of the user's approval or rejection is forwarded to the enterprise / aggregator in step (110), and the transaction workflow is completed in step (112).

[0045] Figure 4 details the rekeying process, which is performed based on a regular security policy. This process ensures the continuous security of the system. In the event of a device event such as the replacement of a Universal Integrated Circuit Card (UICC), removal of a SIM card, or re-activation of a device, the re-provisioning process is restarted from the initial stage to re-establish trust.

[0046] In step (116), the device MFA service generates a new cryptographic key pair using the ML-KEM-1024 algorithm. The public key is obtained from the device's TEE in step (118) and subsequently sent to the cloud MFA service in step (120). The cloud MFA service generates an updated shared key by encapsulating the new public key in step (122) and securely stores it in step (124).

[0047] In step (126), the generated ciphertext is sent to the device MFA service, and in step (128), it is decapsulated using the private key. Once the updated shared key is successfully stored in step (132), it is confirmed in step (134) that all subsequent communications will be encrypted using the latest cryptographic parameters. The re-keying process is completed in step (136) by a confirmation message sent to the cloud MFA service, and in step (138), the cloud MFA service confirms receipt.

[0048] Figure 5 illustrates the service activation and reverification process on a user device (140), with a focus on the generation and verification of certified blobs. Key components include the device MFA service (142), the Trust Execution Environment (TEE) (154), and the cloud MFA service (16). This figure shows the cryptographic elements of the device and how they interact with the cloud MFA service and the OEM identification service (18).

[0049] The process begins within the user device (140), where the device MFA service (142) generates a device token (146) and a key pair consisting of an MFA public key (144) and an MFA private key (158). These keys are securely managed within the Trust Execution Environment (TEE) (154). Simultaneously, the IMSI (148) is obtained from the UICC (150), which is typically an eSIM (152), providing a unique identifier for the device within the carrier network. An immutable device identifier (156), assigned by the OEM and residing within the TEE, is also used to establish the authenticity of the device.

[0050] At this stage, the certification process is performed within the TEE (160). The TEE combines the MFA public key (144), IMSI (148), and device token (146) to generate a certified blob (162). This cryptographically signed blob contains all the elements necessary for authentication. The certified blob is then sent to the cloud MFA service (16), and its contents are verified via the OEM identification service (18). This ensures that the information received from the user device (140) is legitimate and has not been tampered with.

[0051] Once the cloud MFA service (16) verifies the request, the verified blob is forwarded to the OEM identification service (18) for additional verification (164). The OEM identification service verifies the device's authenticity by comparing the verified blob with an immutable device identifier (156). If the verification is successful, the OEM identification service notifies the cloud MFA service of the device's integrity as an acknowledgment, and the re-verification phase is completed. This process is used to maintain trust within the authentication framework even after events such as SIM removal, device restart, or UICC replacement.

[0052] Figure 6 further extends the service activation process, showing the Enhanced Authentication Protocol - Authentication and Key Agreement (EAP-AKA) process and how verified data is stored in the cloud wallet (166). This figure illustrates the interaction between the device MFA service (142), the cloud MFA service (16), the home node (22), and the cloud wallet.

[0053] The process begins after the re-verification shown in Figure 5 is successful. The cloud MFA service (16) initiates the EAP-AKA process by sending the IMSI (148) to the home node (22). The home node processes the IMSI to generate the aka challenge, nonce, and cryptographic key required for verification, and sends them back to the cloud MFA service (16). The cloud MFA service forwards this challenge to the device MFA service (142) (62).

[0054] Within the user device (140), the device MFA service (142) decrypts and processes the aka challenge using the IMSI (148), MFA secret key (158), and the cryptographic functions of the trusted execution environment (154). The device MFA service calculates the aka response and the encrypted response, encrypts them, and sends them to the cloud MFA service (74).

[0055] The cloud MFA service verifies the aka response and cryptographic functions according to the method indicated by the home node (22). If the verification of the aka response is successful, the cloud MFA service (78) sends a request to the home node to obtain the MSISDN (80). The home node uses its database to obtain the Mobile Communications International Subscriber Number (MSISDN), i.e., the verified telephone number (168), and sends it back to the cloud MFA service.

[0056] Upon receiving a verified phone number, the cloud MFA service securely stores the phone number (168), device token (146), device MFA public key and its shared key (144), and IMSI (148) in a secure cloud wallet (166). The cloud wallet functions as a secure repository for authentication data, enabling subsequent authentication processes.

[0057] Reference number table TIFF2026122920000002.tif117170

[0058] Computer and software technology

[0059] This invention can be implemented on various platforms. The following provides the information technology infrastructure available for realizing the invention.

[0060] Embodiments of the present invention can be implemented as hardware, firmware, software, or a combination thereof. Embodiments of the present invention can also be implemented as instructions recorded on a machine-readable medium, which are read and executed by one or more processors. A machine-readable medium includes any mechanism for storing or transmitting information in a form that can be read by a machine (e.g., a computer device). For example, machine-readable mediums include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical disk storage media, flash memory devices, and other forms including electrical, optical, acoustic or other propagating signals (e.g., carrier waves, infrared signals, digital signals, etc.).

[0061] Furthermore, firmware, software, routines, and instructions are sometimes described as performing specific actions. However, such descriptions are for convenience only, and it should be understood that in reality, such actions are performed by computer devices, processors, controllers, or other devices executing firmware, software, routines, instructions, etc.

[0062] Machine-readable media can be, for example, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or a suitable combination thereof. Specific examples (non-exclusive list) of computer-readable storage media include: electrical connections with one or more wires, portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or a suitable combination thereof. In the context of this document, computer-readable storage media can be any non-temporary tangible medium capable of storing or holding programs for use in an instruction execution system, apparatus, or device. Storage and services may be provided on-premises or remotely, such as in the “cloud” operated by vendors such as Microsoft Azure, Amazon Web Services, Rackspace, and Kamatera.

[0063] A machine-readable signaling medium may contain propagated data signals incorporating machine-readable program code, transmitted, for example, as part of a baseband or carrier wave. Such propagated signals can take various forms, such as electromagnetic, optical, or a suitable combination thereof. A machine-readable signaling medium is not a computer-readable storage medium, but is a machine-readable medium capable of communicating, propagating, or transporting programs for use in an instruction execution system, apparatus, or device. As stated above, due to the limitations on circuit patent coverage, claims of this invention as a software product shall be those incorporated into a non-temporary software medium such as a computer hard drive, flash RAM, or optical disk.

[0064] Program code embedded in machine-readable media can be transmitted using a variety of media for smartphone applications and telecommunications network infrastructure. These media include wireless communication channels such as cellular communication networks (e.g., 4G, LTE, 5G), Wi-Fi®, and Bluetooth®, as well as wired connections such as Ethernet and DSL. Fiber optic cables are also essential for large-volume data transfer in telecommunications backhaul networks due to their high bandwidth and low latency. In addition, radio frequency (RF) transmission, commonly used in satellite communications and base station links, can also serve as a means of transmitting program code. These transmission media can operate independently or in combination, enabling robust, redundant, and high-performance communication that is essential for modern smartphone applications and telecommunications infrastructure.

[0065] Machine-readable program code for implementing aspects of the present invention can be written in a combination of one or more programming languages. Object-oriented programming languages ​​such as Java®, C#, C++, and Rust are particularly well-suited for smartphone application development and telecommunications network systems. In smartphones, object-oriented languages ​​facilitate module design, enabling the development of scalable, maintainable, and efficient applications. These languages ​​also form the basis for frameworks and libraries used to manage device-specific functions such as camera operation, location services, and user interfaces. In telecommunications networks, object-oriented programming plays a crucial role in building module components such as signaling protocols, network management systems, and software-defined networking (SDN) controllers. Rust, with its focus on memory safety and performance, is gaining attention as a valuable language for ensuring safe and efficient operation in both areas.

[0066] In addition to object-oriented languages, traditional procedural programming languages ​​such as C still play a crucial role in communication infrastructure and smartphone firmware development. Because of its direct interface capabilities with hardware, C is widely used in device drivers, protocol stacks, and embedded system implementations. In smartphones, C is used for performance-critical processing and battery optimization, ensuring the smooth operation of applications and core functions. In communication networks, C plays a vital role in real-time data processing, for example, in processing signaling protocols such as SS7 and SCTP, and managing packet switching in routers and switches.

[0067] Scripting languages ​​(such as Python, Lua, and Perl) play a crucial role in smartphone development and telecom systems. Python, with its simplicity and rich libraries, is widely used for automating test frameworks, developing AI-driven smartphone applications, and analyzing mobile usage patterns. Lua, with its lightweight footprint and high execution speed, is used to embed in applications and provide end-user-facing extensions and scripting capabilities. Similarly, Perl is widely used in telecom infrastructure, assisting with log file analysis, automating network configuration tasks, and managing large telecom datasets. These scripting languages ​​provide developers with the flexibility and agility to rapidly prototype, test, and deploy.

[0068] Each aspect of the present invention will be explained using flowcharts and block diagrams. These methods, apparatuses (systems), and computer program products are based on embodiments of the invention. It will be understood that each block in the flowcharts and block diagrams, or any combination thereof, can be executed by machine-readable program instructions.

[0069] Glossary of Patent Claim Terminology

[0070] A certified signature is a cryptographic signature generated by the device MFA service and transmitted to the cloud MFA service to certify the authenticity and integrity of specific device data. This data includes, but is not limited to, the device MFA public key, the International Mobile Communications Subscriber Identification Number (IMSI) originating from the Universal Integrated Circuit Card (UICC), and the device token. The certified signature is created using a private key stored within the user device's Trusted Execution Environment (TEE) and ensures that it originates from a secure and tamper-proof environment. When the certified signature is received by the cloud MFA service as part of a certified blob, the signature is verified using the corresponding public key via the Original Equipment Manufacturer (OEM) Identification Service. This verification step confirms that the certified blob originates from a trusted device and has not been tampered with during transmission. The certified signature ensures that the devices participating in the authentication process are legitimate and authorized. This mechanism plays a crucial role in establishing a secure and reliable communication channel between the user device, the cloud MFA service, and other entities such as the Original Equipment Manufacturer (OEM) Identification Service and home operator nodes. The use of cryptographically secure certificate signatures provides an additional safeguard against devices attempting to impersonate, replay, or gain unauthorized access to a network. By providing a cryptographically secure mechanism for device verification, certificate signatures form the foundation of trust in the multi-factor authentication (MFA) ecosystem, facilitating the subsequent secure exchange of sensitive information such as cryptographic keys and session tokens.

[0071] A certified blob is a cryptographically protected data structure generated by the device MFA service and containing critical information used for device verification during multi-factor authentication. A certified blob includes the device MFA public key, the IMSI originating from the Universal Integrated Circuit Card (UICC), the device token, and a certified signature. The device MFA service creates the certified blob within the user device's trusted execution environment (TEE) to ensure data integrity and security. Once generated, the certified blob is sent to the cloud MFA service for verification. The certified signature within the certified blob provides cryptographic evidence of the authenticity and integrity of the data it contains. The cloud MFA service uses this signature, via the original equipment manufacturer (OEM), to verify that the blob originated from a trusted device and has not been altered during transmission. Once the certified blob is verified, the cloud MFA service forwards it to the OEM identification service for further verification of the device's legitimacy. The certified blob enables the cloud MFA service to establish secure and trusted relationships with the user device, network, and other participating entities. This structure ensures that all subsequent steps in the authentication process, including the execution of the Extended Authentication Protocol – Authentication and Key Agreement (EAP-AKA) procedure, are performed on a verified authorized device. By incorporating cryptographic verification at this stage, the proven blob mitigates the risks associated with device impersonation, unauthorized access, and tampering, enhancing the security of the overall MFA framework.

[0072] An aka challenge is a cryptographic challenge issued by the home operator node during the Extensible Authentication Protocol – Authentication and Key Agreement (EAP-AKA) process. The aka challenge is a core element of mutual authentication between the user device and the network, and typically includes a sequence number, nonce, session-specific data, and other cryptographic elements required for the authentication process. Once an aka challenge is generated, the home operator node sends it to the user device via the cloud MFA service. This challenge is processed using cryptographic keys and algorithms within the Universal Integrated Circuit Card (UICC) installed in the user device. The device generates an aka response, which is a response to the aka challenge, and sends it to the cloud MFA service on behalf of the home operator node for verification. The purpose of the aka challenge is to verify the legitimacy of both the device and the network by requiring the device to perform a cryptographic operation that can only be performed with keys stored in a valid UICC. This ensures that the device attempting authentication is legitimate and authorized to access network resources. The aka challenge also facilitates the establishment of a session key used to secure communication between the device and the network. By incorporating cryptographic principles in this way, the aka challenge ensures resistance to replay attacks, tampering, and unauthorized access. Its role in establishing mutual trust and protecting network sessions makes the aka challenge a fundamental element of secure multi-factor authentication.

[0073] An aka response is a cryptographic response generated by a user device in response to an aka challenge during the Extensible Authentication Protocol – Authentication and Key Agreement (EAP-AKA) process. The aka response is constructed using cryptographic keys and algorithms stored on the user device's Universal Integrated Circuit Card (UICC). Upon receiving an aka challenge, the device processes the nonce and associated cryptographic parameters contained within it and computes an aka response as proof of its authenticity. The aka response is then sent to a cloud MFA service for verification. The cloud MFA service, representing the home operator node, verifies the response against the expected output based on the original aka challenge. A match in the cryptographic function confirms the device's authenticity and establishes mutual trust between the device and the network. The aka response also enables the derivation of a session key used to encrypt and secure subsequent communications between the device and the network. This step is crucial to ensure that only authorized devices can access network resources. The aka response relies on cryptographic principles and a time-dependent nonce, making it resistant to tampering and replay attacks. By requiring the generation and verification of an aka response, the EAP-AKA process ensures that the authentication protocol is robust and secure against impersonation and other malicious activity. The aka response provides a foundation for securely exchanging sensitive information within a secure multi-factor authentication framework and is the cornerstone of the overall security architecture.

[0074] Ciphertext is an encrypted form of data obtained by applying an encryption algorithm to plaintext using an encryption key. In this invention, ciphertext is generated during a key encapsulation process, such as the ML-KEM-1024 algorithm. The ciphertext is securely transmitted between the user device and the cloud MFA service so that sensitive information, such as encryption keys and authentication data, is protected from interception and unauthorized access. Only authorized entities with the appropriate decryption key (e.g., an MFA secret key stored in a Trusted Execution Environment (TEE)) can convert the ciphertext back into its readable plaintext form.

[0075] Cloud MFA service is a cloud-based system that supports multi-factor authentication (MFA) by performing device verification, cryptographic operations, and secure data management. The Cloud MFA service acts as an intermediary between the user device, the original equipment manufacturer (OEM) identification service, and the home operator node, establishing mutual trust and secure communication. This service receives the certified blob generated by the device MFA service and verifies the certified signature to confirm the integrity and legitimacy of the device data. After verification, the Cloud MFA service sends the certified blob to the OEM identification service for device verification. Furthermore, the Cloud MFA service works with the home operator node to initiate the Enhanced Authentication Protocol – Authentication and Key Agreement (EAP-AKA) process, transferring the aka challenge and nonce to the user device and assisting in processing the resulting aka response. This service further verifies the response in coordination with the home operator node, obtains the verified phone number, and stores it in a secure cloud wallet along with other device-specific data. The Cloud MFA service also encrypts sensitive data using post-quantum cryptography algorithms to protect it from tampering and unauthorized access. Furthermore, it can initiate processes such as reprovisioning, device reactivation, and user consent verification, maintaining the security and integrity of the authentication process. By providing centralized management and cryptographic security, the cloud MFA service ensures robust and reliable multi-factor authentication across a variety of devices and networks.

[0076] The Device MFA Public Key is a cryptographic key generated by the Device MFA service for use in a secure authentication process. The Device MFA Public Key is part of a public-private key pair, with the private key stored in the user device's Trusted Execution Environment (TEE). This key is contained within a certified blob sent to the Cloud MFA service, forming the foundation for cryptographic verification and secure communication. Upon receipt, the Cloud MFA service verifies the public key using the certified signature provided within the certified blob to confirm that the key originates from a trusted device. The shared key derived from the Device MFA Public Key is used for various cryptographic functions, including encrypting sensitive data such as transaction details and authentication challenges. Furthermore, this key facilitates secure exchange with other entities such as the Cloud MFA service, OEM identification services, and home operator nodes. The integrity and legitimacy of this Device MFA Public Key are crucial to ensure that only authorized devices participate in the authentication process. This key also plays a vital role in cryptographic operations such as key encapsulation and post-quantum cryptography, further enhancing the security of the multi-factor authentication framework. By leveraging the device MFA public key, the system ensures that all communications related to the user device are encrypted and resistant to tampering, interception, and replay attacks.

[0077] A device MFA service is a software component or module that operates on a user's device and assists in the generation and management of cryptographic keys, as well as the preparation of authentication data for multi-factor authentication (MFA). The device MFA service is responsible for generating a certified blob containing the device MFA public key, the International Mobile Subscriber Identification Number (IMSI) of Universal Integrated Circuit Card (UICC) origin, the device token, and the certified signature. These elements are securely encapsulated and sent to the cloud MFA service for verification. Operating within a Trusted Execution Environment (TEE), the device MFA service ensures that all cryptographic operations and sensitive data are protected from unauthorized access and tampering. The service handles authentication challenges, such as aka challenges received during the Extended Authentication Protocol – Authentication and Key Agreement (EAP-AKA) process, and generates corresponding aka responses. It can also encrypt user consent responses and transaction details and securely send them to the cloud MFA service. Furthermore, the device MFA service supports security features such as reprovisioning, device re-activation, and periodic re-verification of UICC-origin IMSIs. By functioning as a trusted interface between user devices and authentication systems, device MFA services ensure that all device-specific authentication data is securely managed and communicated, forming a critical component of the MFA framework.

[0078] A device token is a unique identifier generated by a device MFA service and contained within a certified blob to enable secure and traceable interactions between the user device and the cloud MFA service. The device token is tied to a specific device and is used to track and manage authentication sessions, verify transactions, or store session-related metadata in a secure cloud wallet. This device token is generated by the device MFA service and identifies the device and application via the appropriate device push notification service. This device token is tied to an MSISDN and used for MFA operations on that MSISDN. Furthermore, the device token supports security operations such as associating devices with cryptographic keys, ensuring that transactions are associated with the correct device. By maintaining the integrity and uniqueness of the device token, the authentication system ensures that device-specific interactions within the MFA ecosystem are managed securely, reliably, and efficiently.

[0079] Device push notifications are secure communications from a cloud MFA service sent to a user's device to facilitate user consent verification and other authentication-related processes. These notifications contain transaction details and authentication requests, encrypted using the shared key of the device MFA public key to ensure confidentiality and integrity. Device push notifications are triggered when user action or confirmation is required, such as approving a transaction, reactivating a device, or verifying a new session. Upon receiving the notification, the user's device decrypts its contents within a Trusted Execution Environment (TEE) and displays it to the user to request approval or action. The user's consent or response is then securely transmitted to the cloud MFA service. By using cryptographically protected device push notifications, the system ensures that sensitive information is protected from tampering and interception, and that only authorized users can interact with authentication requests.

[0080] A device reactivation event refers to an event that triggers the device MFA service to re-verify the trustworthiness and authentication status of a user device. Examples of device reactivation events include replacing a Universal Integrated Circuit Card (UICC), removing or reinserting a SIM card, restarting a device, or a major firmware or software update for a device. During a reactivation event, the device MFA service may need to generate a new key pair, create an updated certified blob, and re-run the verification process associated with the OEM Identity Service and the home operator node. These steps ensure that the device continues to meet the required security standards and remains authenticated within the MFA framework. Reactivation events provide an additional layer of security by ensuring that changes in the device environment do not affect its integrity or authentication credentials.

[0081] Extensible Authentication Protocol – Authentication and Key Agreement (EAP-AKA) is an authentication protocol designed to enable secure communication and mutual authentication between user devices and carrier networks, particularly in 3G, LTE, and 5G environments. Specifically adapted to Universal Integrated Circuit Cards (UICCs), EAP-AKA begins with the user device sending an identifier (e.g., International Mobile Subscriber Identification Number (IMSI)) to a home operator node. The home operator node is often a Home Location Register (HLR) in 2G / 3G networks and a Home Subscriber Server (HSS) in LTE / 5G systems. The home operator node generates an authentication vector containing an aka challenge, a sequence number, and a session key. The aka challenge, along with a nonce, is sent to the device over the network. The device uses its UICC to compute an aka response based on the challenge and a pre-shared key stored in the UICC, and sends this response back to the network for verification. EAP-AKA establishes mutual authentication through mutual verification between the device and the network, protecting against impersonation attacks and unauthorized access. The session key is derived during this process and encrypts subsequent communications to ensure integrity. In this invention, EAP-AKA facilitates the establishment of trust by enabling a cloud-based multi-factor authentication (MFA) service to send the IMSI to the home operator node, receive the aka challenge, and forward it to the device MFA service. The verified aka response allows the Mobile Station International Subscriber Directory Number (MSISDN) or phone number to be retrieved independently of the device and is securely stored in a cloud wallet along with other critical authentication data such as the device token and MFA public key.

[0082] Enterprise / aggregator integration refers to the process by which enterprises and aggregators work with cloud MFA services to manage authentication and transaction verification. This integration enables secure communication between enterprise systems that process user accounts and financial transactions and the cloud MFA service. In this process, transaction details are encrypted with the device's MFA public key and sent to the user's device via push notifications. User responses (such as consent or denial) are sent back to the enterprise or aggregator through the cloud MFA service. This integration enables secure, scalable, and traceable interactions between different entities, guaranteeing user authentication.

[0083] A Home Location Register (HLR) is a database used to manage subscriber information and authentication data for mobile devices on 2G and 3G networks. The HLR stores the International Mobile Subscriber Identification Number (IMSI), telephone number, and service profile associated with each subscriber. During the authentication process, the HLR works with cloud MFA and device MFA services to provide subscriber-specific information necessary to initiate and verify the Enhanced Authentication Protocol – Authentication and Key Agreement (EAP-AKA) process. The HLR generates authentication challenges, verifies aka responses, and helps establish a secure communication channel between the device and the network. While HLRs are specific to older network technologies, their functionality aligns with Home Subscriber Servers (HSSs) in LTE and 5G networks, ensuring compatibility with a wide range of authentication systems.

[0084] A Home Operator Node (HOP) refers to a network entity that manages subscriber authentication and authorization within a mobile carrier network. HOPs include systems such as Home Location Registers (HLRs) in 2G and 3G networks, and Home Subscriber Servers (HSSs) in LTE and 5G networks. During the authentication process, the HOP works with the Cloud MFA service to initiate and validate the Enhanced Authentication Protocol – Authentication and Key Agreement (EAP-AKA) process. This process includes generating an aka challenge, validating the aka response, and providing session keys and other cryptographic materials. The HOP also provides the Cloud MFA service with a verified phone number associated with the device, independent of the phone number stored on the device itself. By supporting these critical functions, the HOP ensures secure and reliable interaction between devices, networks, and multi-factor authentication systems.

[0085] A Home Subscriber Server (HSS) is a central database for managing subscriber authentication, authorization, and service profiles in LTE and 5G networks. While similar in function to the Home Location Register (HLR) in 2G and 3G networks, the HSS offers additional features tailored to advanced network architectures. The HSS integrates with cloud and device MFA services to facilitate the Enhanced Authentication Protocol – Authentication and Key Agreement (EAP-AKA) process. Specifically, it provides authentication challenges, verifies aka responses, and issues session keys. It also provides information necessary for network operations, such as subscriber location tracking and service delivery. The HSS ensures that devices participating in the authentication process meet network security and operational standards.

[0086] IMSI stands for International Mobile Subscriber Identification Number, a unique identifier stored on the Universal Integrated Circuit Card (UICC) of a mobile device. IMSI is used by mobile networks to authenticate and identify subscribers during network access and other operations. During the Extensible Authentication Protocol – Authentication and Key Agreement (EAP-AKA) process, the IMSI is sent to the home operator node, which then generates an aka challenge and verifies the device's aka response. The IMSI is also included in the attestation blob sent from the device MFA service to the cloud MFA service, allowing for verification of the device's identity. By utilizing IMSI as a critical element of the authentication process, systems ensure accurate and secure identification of subscribers within a multi-factor authentication (MFA) framework.

[0087] Metadata refers to supplemental data that describes or provides information about a device's operational status and configuration during the authentication process. Metadata may include information about the device's firmware version, UICC status, cryptographic key status, or previous authentication events. Metadata is often included in verified challenge responses generated by device MFA services and sent to cloud MFA services. This data is securely stored in a cloud wallet and used for future reference, enabling systems to monitor device integrity, detect anomalies, and enforce security policies. Including metadata in the authentication process enhances the system's ability to identify and respond to potential security risks.

[0088] ML-KEM (Modular Lattice Key Encapsulation Mechanism) is a cryptographic algorithm for secure key exchange and encapsulation, utilizing lattice-based cryptography that is resistant to quantum computing attacks. In the context of this invention, ML-KEM plays a crucial role in the initial key exchange process when activating multi-factor authentication (MFA) services. Its use ensures that sensitive cryptographic keys are securely transferred and stored, maintaining resistance to conventional and quantum computing threats. The ML-KEM process begins with the creation of an encryption key pair generated by the device MFA service. This key pair consists of an encapsulated MFA public key that is transmitted and an MFA private key that is securely stored in a trusted execution environment (TEE) on the user's device. The encapsulation process enabled by ML-KEM generates a shared key along with a ciphertext that can only be decrypted if the recipient possesses the corresponding private key. This shared key is then used to encrypt subsequent communications between the device and the cloud MFA service. The lattice-based foundation of ML-KEM offers inherent security advantages, such as resistance to mathematical attacks that exploit vulnerabilities in conventional cryptography, such as elliptic curves and integer factorization. By employing ML-KEM, the system ensures the confidentiality and integrity of cryptographic operations even in a post-quantum environment. In this invention, ML-KEM is integrated into a broad authentication framework to securely initiate cryptographic relationships between user devices and networks. This initial exchange enables more secure processes, including attestation, verification, and encryption of sensitive data such as authentication challenges and user credentials.

[0089] A nonce is a cryptographically generated random or pseudo-random value intended for one-time use, incorporated into authentication and encryption processes to ensure uniqueness and prevent replay attacks. In this invention, the nonce is a critical element of the aka challenge generated during the EAP-AKA process. This ensures that each authentication session is unique and provides protection against attempts by attackers to reuse intercepted data. The nonce is incorporated into attested blobs and encrypted communications, enhancing the security of the key exchange and verification processes.

[0090] The OEM Identification Service is a service operated by the original equipment manufacturer (OEM) of a device, and its role is to verify the authenticity and integrity of the device during the multi-factor authentication (MFA) process. The OEM Identification Service receives an attested blob sent from the cloud MFA service. This blob contains the device MFA public key, the International Mobile Subscriber Identification Number (IMSI) originating from the UICC (Universal Integrated Circuit Card), the device token, and the attestation signature. Upon receiving the attested blob, the OEM Identification Service verifies the attestation signature and other data to confirm that the device has not been tampered with and originates from a legitimate OEM source. The service provides the verification results to the cloud MFA service, which then proceeds with further authentication procedures and interacts with the home operator node. By acting as a trusted intermediary in the authentication process, the OEM Identification Service enhances security and prevents unauthorized or compromised devices from accessing sensitive network resources.

[0091] Periodic reverification refers to a scheduled or event-driven, recurring authentication process to continuously verify the authenticity of a device. Periodic reverification involves the cloud MFA service working with the device MFA service and home operator node to re-execute the Enhanced Authentication Protocol – Authentication and Key Agreement (EAP-AKA) process. This process includes generating a new aka challenge, verifying the aka response, and checking the integrity of stored cryptographic keys. Reverification can be triggered by predefined time intervals, changes in the device environment (e.g., SIM card replacement), or system-flagged security events. This process ensures that the device continues to comply with security standards and allows for the rapid detection of unauthorized changes or anomalies. Periodic reverification enhances the long-term reliability and fault tolerance of the authentication framework.

[0092] A phone number refers to a verified number associated with a device, obtained from the home operator node during the authentication process. The phone number is derived independently of any numbers stored on the device and is stored in a secure cloud wallet along with other authentication data. Using carrier-verified phone numbers enhances the integrity of the authentication process and reduces the risk of impersonation and fraud by reflecting the actual subscriber records maintained by the network operator.

[0093] Post-quantum cryptography algorithms refer to cryptographic techniques designed to be resistant to attacks by quantum computers, which can pose a threat to traditional public-key cryptography systems. In the context of multi-factor authentication (MFA) frameworks, post-quantum cryptography algorithms are used by cloud MFA services to protect the transmission of sensitive information, such as aka challenges, device tokens, and session key encryption. These algorithms include lattice-based key encapsulation methods such as Kyber and other standards approved by the National Institute of Standards and Technology (NIST). By incorporating post-quantum cryptography algorithms, systems can ensure that authentication and data exchange remain secure even against attackers with quantum computing capabilities.

[0094] A private key is the cryptographic key in a public-private key pair that is securely stored in the Trusted Execution Environment (TEE) of the user device. The private key is used by the device MFA service to perform cryptographic operations, such as signing authentication data (e.g., certificate signatures) or decrypting encrypted data received from the cloud MFA service. The private key is never transmitted outside the device and is therefore protected from unauthorized tampering or interception. The private key plays a crucial role in enabling secure communication between the device MFA service, the cloud MFA service, and other entities in the network (e.g., home operator nodes or OEM identification services). The confidentiality of the private key forms the foundation of security for the entire multi-factor authentication (MFA) framework.

[0095] A ProvID is a unique identifier assigned during the provisioning or key exchange process and used to track a specific authentication or rekeying session. In this invention, the ProvID is used by the cloud MFA service to associate the ciphertext, key, and associated metadata with a specific user device and authentication session. This enables efficient management of the authentication workflow and ensures that session-specific data is handled securely and stored in a cloud wallet.

[0096] A public key is part of a public-private key pair, a cryptographic key shared with external entities and used for secure communication and verification. In a multi-factor authentication (MFA) system, the public key is generated by the device MFA service and included in a certified blob sent to the cloud MFA service. The public key is used to verify certified signatures, encrypt sensitive data such as aka challenges and transaction details, and enable secure communication between the device and the cloud MFA service. The integrity and reliability of the public key are verified as part of the device verification process to ensure that it originates from a trusted source. By using asymmetric cryptography, the public key ensures that sensitive information remains secure during transmission and processing.

[0097] Push notifications are secure messages sent from a cloud MFA service to a user's device to prompt user action during an authentication or transaction authorization process. These notifications are encrypted with the device's MFA public key to protect sensitive data such as transaction details and authentication requests. Upon receipt, the user's device decrypts the notification within a Trusted Execution Environment (TEE) and displays it to the user. The user's response is encrypted and sent back to the cloud MFA service for verification. Push notifications ensure secure and seamless user engagement in multi-factor authentication workflows.

[0098] A quintaplet refers to a set of cryptographic parameters generated by the home operator node during the EAP-AKA process. A quintaplet typically includes a random number (RAND), an expected response (XRES), a cryptographic key (CK), an integrity key (IK), and an authentication token (AUTN). These parameters are sent to the cloud MFA service and then forwarded to the user device to complete the mutual authentication process. The quintaplet ensures that all necessary cryptographic elements are securely exchanged between the device and the network for session establishment and encryption.

[0099] A reactivation request is a secure command sent from the cloud MFA service to the user device when a device reactivation event is detected. This reactivation request prompts the device MFA service to generate a new key pair, create an updated certified blob, and execute the EAP-AKA process to re-establish mutual trust with the system. The request ensures that the device continues to meet security standards after changes such as SIM card replacement or firmware updates. By requiring the device to respond to reactivation requests, the system maintains a high level of security and prevents unauthorized devices from remaining within the authentication framework.

[0100] Rekeying is the process of updating cryptographic keys to maintain security, especially after events such as UICC replacement, SIM card removal and reinsertion, or device reactivation. Rekeying is initiated by the cloud MFA service, which instructs the device MFA service to generate a new key pair using the ML-KEM-1024 algorithm. The generated public key is encapsulated and sent to the cloud MFA service, where the shared key is updated and the new key data is securely stored in the cloud wallet. Rekeying ensures that past sessions remain secure and that future communications use updated cryptographic parameters.

[0101] A secure cloud wallet is a secure, cloud-based repository managed by a cloud MFA service for storing device-specific authentication data. The secure cloud wallet stores verified information such as the phone number obtained from the home operator node, the device token, the International Mobile Subscriber Identification Number (IMSI) of UICC origin, and the device MFA public key. The secure cloud wallet is designed using encryption and access control to ensure the integrity, confidentiality, and availability of stored data, providing a trusted reference for verifying device authentication credentials and managing session-related data. This functionality enables the multi-factor authentication (MFA) process to run efficiently and securely.

[0102] A shared key is a symmetric cryptographic key derived during the key exchange process between a device MFA service and a cloud MFA service. The shared key is used to encrypt and decrypt sensitive data sent and received between these entities, ensuring the confidentiality and integrity of the communication. In a multi-factor authentication (MFA) framework, the shared key is derived using post-quantum cryptography algorithms (such as lattice-based methods) to ensure resistance to evolving computational threats. By using a shared key to securely exchange data, the system provides protection against tampering, interception, and retransmission attacks, enhancing the overall robustness of the authentication process.

[0103] Shared key updating refers to the process of securely replacing or updating the symmetric encryption key used for communication between the cloud MFA service and the user device. This process is performed during rekeying or when cryptographic integrity needs to be maintained. In the rekeying process, a new shared key is generated in the cloud MFA service, and the ciphertext generated as part of the encapsulation is sent back to the device MFA service. The ciphertext is decapsulated using the MFA private key stored in the Trusted Execution Environment (TEE), and the new shared key is obtained. Shared key updating strengthens encryption and ensures that sensitive communications are protected from evolving threats.

[0104] Transaction details are specific information about actions or requests initiated by a user, such as financial transactions, login attempts, or configuration changes, that require verification by an MFA system. Transaction details are encrypted using the shared key of the device's MFA public key and sent to the user's device via device push notification for user approval. The user's device decrypts the details within a Trusted Execution Environment (TEE), giving the user the opportunity to approve or reject the action. The verified response is then securely returned to the cloud MFA service. By incorporating transaction details into the authentication process, the system allows users to control sensitive actions, reducing the risk of fraudulent activity and misconduct.

[0105] A Device International Mobile Subscriber Identification Number (IMSI) originating from the Universal Integrated Circuit Card (UICC) is a unique identifier stored in the UICC and used for device authentication with the carrier network. This UICC-originating device IMSI is generated by the device MFA service and included in a verified blob sent to the cloud MFA service. This IMSI is also provided to the home operator node during the Extensible Authentication Protocol - Authentication and Key Agreement (EAP-AKA) process, where it is used to generate an aka challenge and verify the aka response. By trusting the UICC-originating device IMSI, the system ensures that the authentication process is tied to the identity of the device recognized by the carrier network, mitigating risks associated with impersonation and tampering.

[0106] A user consent response is a cryptographically protected representation of a user's recognition or denial of a device push notification. The response contains information indicating that the user has approved or denied a specific transaction or authentication request. This response is encrypted using the device's private key and sent to a cloud MFA service for verification. Upon receiving the response, the cloud MFA service decrypts and verifies it to ensure the action reflects the user's intent. User consent responses provide a crucial layer of user-driven security by ensuring that only actions approved within the authentication framework are performed.

[0107] A user device refers to a mobile or computer device equipped with a Universal Integrated Circuit Card (UICC) that can participate in the multi-factor authentication (MFA) process. The user device hosts the device MFA service, which handles encryption key generation, verified blob creation, authentication challenge processing, and communication with the cloud MFA service. Examples of user devices include smartphones, tablets, and IoT devices. By acting as a trusted endpoint in the authentication process, the user device plays a crucial role in ensuring the security and integrity of the MFA framework.

[0108] The advantages described above, and those evident from the preceding description, are efficiently achieved. Since the above configuration can be modified without departing from the scope of the invention, all matters shown in the preceding description or accompanying drawings are intended to be descriptive and not to be interpreted in a restrictive sense.

Claims

1. A method for establishing mutual trust between a user device and a carrier network, The aforementioned method is performed by a cloud-based multi-factor authentication service (cloud MFA service), and the method includes the following: a. The cloud MFA service receives a certified blob generated by the device MFA service, wherein the certified blob includes: i. Device MFA public key; ii. Device International Mobile Subscriber Identification Number (UICC-origin Device IMSI) of Universal Integrated Circuit Card origin; and iii. Device token; b. The cloud MFA service transmits the certified BLOB to the original equipment manufacturer identification service (OEM identification service) for verification of the user device; c. After receiving verification from the OEM Identification Service, the Cloud MFA Service transmits the UICC-origin device IMSI to a home operator node associated with the carrier network, the home operator node initiating an Extensible Authentication Protocol – Authentication and Key Agreement (EAP-AKA) process and generating an aka challenge and nonce to establish mutual trust between the user device and the carrier network; d. Transferring the aka challenge and nonce to the device MFA service via the cloud MFA service; e. The cloud MFA service receives verified aka challenge response and nonce from the device MFA service; f. The cloud MFA service sends the verified aka challenge response to the home operator node for verification; g. The cloud MFA service receives a verified telephone number associated with the user device from the home operator node, wherein the verified telephone number is derived independently of any telephone numbers stored on the user device; and h. The cloud MFA service stores the verified phone number, the device token, the UICC-origin device IMSI, and the device MFA public key in a secure cloud wallet.

2. A method for establishing mutual trust between a user device and a carrier network as described in claim 1, The certified BLOB further includes a certified signature generated by the device MFA service, The certificate signature is cryptographically verified by the OEM identification service, and the secure cloud wallet is configured to associate the stored verified phone number, the device token, the UICC-origin device IMSI, and the device MFA public key with a unique device identifier in order to respond to subsequent authentication requests.

3. A method for establishing mutual trust between a user device and a carrier network as described in claim 1, The system further includes periodically re-verifying the UICC-derived device IMSI by repeating the EAP-AKA process between the cloud MFA service and the home operator node.

4. A method for establishing mutual trust between a user device and a carrier network as described in claim 1, Before the cloud MFA service transfers the aka challenge and nonce to the device MFA service, it encrypts the aka challenge and nonce with the shared key associated with the device MFA public key.

5. A method for establishing mutual trust between a user device and a carrier network as described in claim 1, The verified aka challenge response received from the device MFA service includes metadata indicating the operating status of the user device, and this metadata is stored in the secure cloud wallet along with other stored data.

6. A method for establishing mutual trust between a user device and a carrier network as described in claim 1, The cloud MFA service uses a post-quantum cryptography algorithm to protect communication between the cloud MFA service, the OEM identification service, and the home operator node.

7. A method for establishing mutual trust between a user device and a carrier network as described in claim 1, When the cloud MFA service detects a device event, it initiates a reprovisioning process for the device MFA public key stored in the secure cloud wallet, and the device event is selected from one of the following: replacement of the universal integrated circuit card (UICC), removal of the SIM, or reactivation of the device.

8. A method for establishing mutual trust between a user device and a carrier network as described in claim 1, The cloud MFA service further includes encapsulating the device MFA public key and generating a shared key, The shared key is stored in the secure cloud wallet along with the UICC-derived device IMSI and device token.

9. A method for establishing mutual trust between a user device and a carrier network as described in claim 1, The device MFA service further includes the steps of decapsulating encrypted data received from the cloud MFA service using a private key associated with the device MFA service, verifying the shared key, and completing the key exchange process.

10. A method for establishing mutual trust between a user device and a carrier network as described in claim 1, The cloud MFA service further includes encrypting the aka challenge received from the home operator node using the shared key and transferring the encrypted data to the device MFA service.

11. A method for establishing mutual trust between a user device and a carrier network as described in claim 1, The cloud MFA service further includes decrypting the encrypted aka response received from the device MFA service and verifying the calculation of the aka response by the device MFA service.

12. A method for establishing mutual trust between a user device and a carrier network as described in claim 1, The cloud MFA service further includes initiating a device push notification to the user device to verify user consent, The device push notification includes transaction details encrypted using a shared key derived from the device MFA public key.

13. A method for establishing mutual trust between a user device and a carrier network as described in claim 1, The cloud MFA service further includes receiving an encrypted user consent response from the device MFA service, decrypting it, and verifying the user's authorization for the transaction.

14. A method for establishing mutual trust between a user device and a carrier network as described in claim 1, The device MFA service further includes generating a reactivation request to the cloud MFA service when it detects a device reactivation event, The aforementioned reactivation request triggers the generation of a new key pair by the device MFA service.

15. A method for establishing mutual trust between a user device and a carrier network as described in claim 1, The aforementioned home operator node includes the following: a. Home Location Register (HLR) in 2G and 3G networks; b. Home subscriber server (HSS) in LTE and 5G networks; Here, the home operator node performs authentication and authorization of the user device based on the device IMSI originating from UICC.

16. A system for managing authentication and authorization processes in user devices and carrier networks, The aforementioned system includes a cloud-based multi-factor authentication service (cloud MFA service) configured as follows: a. Receive a certified blob containing cryptographic information from the user device, the certified blob containing: i. Device MFA public key; ii. Device International Mobile Subscriber Identification Number (UICC-origin Device IMSI) of Universal Integrated Circuit Card origin; and iii. Device token; b. Send the certified BLOB to the original equipment manufacturer identification service (OEM identification service) for verification of the user device; c. The OEM Identification Service receives verification of the user device, transmits the UICC-origin IMSI to a home operator node associated with the carrier network, and the home operator node is configured to perform the Enhanced Authentication Protocol – Authentication and Key Agreement (EAP-AKA) process and generate an aka challenge and nonce; d. Transfer the aka challenge and nonce to the user device and receive the verified aka challenge response and nonce from the user device; e. Send the verified aka challenge response to the home operator node for verification; f. The home operator node receives a verified telephone number associated with the user device, and the verified telephone number is derived from the Mobile Communications International Subscriber Number (MSISDN) independently of the telephone numbers stored on the user device; and g. Store the verified phone number derived from the MSISDN, the device MFA public key, the UICC-origin IMSI, and the device token in a secure cloud wallet.

17. A system for managing authentication and authorization processes in a user device and carrier network as described in claim 16, The aforementioned device MFA service is configured to generate a shared key as follows: a. Send the device MFA public key to the cloud MFA service; b. The cloud MFA service encapsulates the device MFA public key and generates a ciphertext and a shared key; c. Send the ciphertext back to the device MFA service, decapsulate the ciphertext to obtain the shared key; and d. The shared key generated by the cloud MFA service as part of the encapsulation is securely stored in the secure cloud wallet together with the verified phone number, the UICC-origin device IMSI, and the device token.

18. A system for managing authentication and authorization processes in a user device and carrier network as described in claim 16, The device MFA service is configured to initiate periodic reprovisioning by sending a request to the cloud MFA service. The aforementioned request triggers a new Enhanced Authentication Protocol – Authentication and Key Agreement (EAP-AKA) process with the home operator node, During this process, newly acquired Mobile Communications International Subscriber Numbers (MSISDNs) are verified.

19. A non-temporary, computer-readable medium that stores instructions to be executed by a processor and, when executed, causes a cloud-based multi-factor authentication service (cloud MFA service) to perform the following: a. Receiving a certified blob containing cryptographic information from a user device, wherein the certified blob includes: i. Device MFA public key; ii. Device International Mobile Subscriber Identification Number (UICC-origin Device IMSI) of Universal Integrated Circuit Card origin; and iii. Device token; b. Sending the certified BLOB to the original equipment manufacturer identification service (OEM identification service) for verification of the user device; c. After receiving verification of the user device from the OEM identification service, transmitting the UICC-origin device IMSI to a home operator node associated with the carrier network, the home operator node being configured to perform the Extended Authentication Protocol – Authentication and Key Agreement (EAP-AKA) process and generate an aka challenge and a nonce; d. Transferring the aka challenge and nonce to the user device and receiving the verified aka challenge response and nonce from the user device; e. Send the verified aka challenge response to the home operator node for verification; f. Receiving a verified telephone number associated with the user device from the home operator node, wherein the verified telephone number is derived from a Mobile Communications International Subscriber Number (MSISDN) independently of any telephone numbers stored on the user device; and g. Storing the verified telephone number derived from the MSISDN, the device MFA public key, the UICC-originating device IMSI, and the device token in a secure cloud wallet.

20. A non-temporary computer-readable medium according to claim 19, The above instructions further cause the device MFA service to do the following: a. Generating a shared key by decapsulating a ciphertext received from a cloud MFA service, wherein the ciphertext is generated as a result of the cloud MFA service encapsulating the device MFA public key, and the encapsulated shared key is associated with the verified phone number, the UICC-origin device IMSI, and the device token and is securely stored in a secure cloud wallet; and b. Initiating periodic reprovisioning by sending a request to the Cloud MFA service, the request triggering a new Enhanced Authentication Protocol – Authentication and Key Agreement (EAP-AKA) process with the Home Operator node, which includes verification of a newly acquired Mobile Communications International Subscriber Number (MSISDN).

Images