Encapsulation of payload between a device and an entity outside the device using an authentication framework beyond its intended use

Abstract

Systems and techniques are described herein that provide payload encapsulation techniques for extending rigid device software stacks. For example, a computing device or apparatus can receive an application request from an application and generate data based on the application request. The computing device or apparatus can encapsulate the data in one or more fields of a request message. The request message includes a message format associated with a rigid software stack associated with the application. The computing device or apparatus can transmit the request message to the application for authentication by a secure area or secure element coupled to the application.

Description

ENCAPSULATION OF PAYLOAD BETWEEN A DEVICE AND AN ENTITY OUTSIDETHE DEVICE USING AN AUTHENTICATION FRAMEWORK BEYOND ITSINTENDED USEFIELD

[0001] The present disclosure generally relates to security services for various types of devices and systems. For example, aspects of the present disclosure relate to payload encapsulation techniques for extending rigid device software stacks, such as authentication frameworks, so that a device may exchange data with entities outside of the device.BACKGROUND

[0002] Devices often implement various techniques for device security. Device security may relate to securing devices against physical and / or logical attacks seeking to compromise device security, or provide trust to entities outside of the device. Device security features may be provided to on-device components or entities outside of the device using pre-defined software stacks or frameworks. For example, a device may implement a web-based authentication scheme, to enable entities outside of the device to enroll new users or verify existing users. Such authentication schemes typically define a rigid set of capabilities (which can be referred to herein as a rigid software stack), often aiming at a lowest common denominator, which might limit applications that want to make use of advanced security feature available on the device.

[0003] In some instances, device security techniques may include configuring a device with a secure area / secure element. In some cases, the secure area / secure element can include a Trusted Execution Environment (TEE) and / or a Secure Element, such as defined by the Global PlatformRStandard for Secure Digital Services and Devices. The Secure Element can be an embedded Secure Element or an Integrated Secure Element, which can include or require a Tamper Resistant Element (TRE) / platform. A TRE includes a high-security hardware component. An example of a TRE is a secure processor (e.g., integrated into a system-on-chip (SoC) or connected to the SoC via an interface). The TRE can be in communication with other components of the device, such as one or more processors implementing software applications. For example, a software application can communicate with the TRE for one or more security services provided by the TRE. With rigidsoftware stacks, like an authentication framework, such advanced security capabilities will likely remain out of reach.SUMMARY

[0004] Systems and techniques are described for extending security services for use with one or more systems. According to at least one example, an apparatus for processing one or more application requests is provided. The apparatus includes at least one memory and at least one processor coupled to the at least one memory and configured to: receive an application request from an application; generate data based on the application request; encapsulate the data in one or more fields of a request message, the request message including a message format associated with a rigid software stack associated with the application; and transmit the request message to the application for authentication by a secure area or secure element coupled to the application .

[0005] In another illustrative example, a method for processing one or more application requests is provided. The method includes: receiving an application request from an application; generating data based on the application request; encapsulating the data in one or more fields of a request message, the request message including a message format associated with a rigid software stack associated with the application; and transmitting the request message to the application for authentication by a secure area or secure element coupled to the application.

[0006] In another illustrative example, a non-transitory computer readable medium is provided that has stored thereon instructions that, when executed by one or more processors, cause the processors to: receive an application request from an application; generate data based on the application request; encapsulate the data in one or more fields of a request message, the request message including a message format associated with a rigid software stack associated with the application; and transmit the request message to the application for authentication by a secure area or secure element coupled to the application .

[0007] In another illustrative example, an apparatus for processing one or more application requests is provided that includes: means for receiving an application request from an application; means for generating data based on the application request; means for encapsulating the data in one or more fields of a request message, the request message including a message format associated with a rigid software stack associated with the application; and means for transmitting the requestmessage to the application for authentication by a secure area or secure element coupled to the application.

[0008] In some aspects, one or more of the apparatuses described herein is, is part of, and / or includes an extended reality (XR) device or system (e.g., a virtual reality (VR) device, an augmented reality (AR) device, or a mixed reality (MR) device), a mobile device (e.g., a mobile telephone or other mobile device), a wearable device, a wireless communication device, a camera, a personal computer, a laptop computer, a vehicle or a computing device or component of a vehicle, a server computer or server device (e.g., an edge or cloud-based server, a personal computer acting as a server device, a mobile device such as a mobile phone acting as a server device, an XR device acting as a server device, a vehicle acting as a server device, a network router, or other device acting as a server device), another device, or a combination thereof. In some aspects, the apparatus includes a camera or multiple cameras for capturing one or more images. In some aspects, the apparatus further includes a display for displaying one or more images, notifications, and / or other displayable data. In some aspects, the apparatuses described above can include one or more sensors (e.g., one or more inertial measurement units (IMUs), such as one or more gyrometers or gyroscopes, one or more accelerometers, any combination thereof, and / or other sensor.

[0009] This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used in isolation to determine the scope of the claimed subject matter. The subject matter should be understood by reference to appropriate portions of the entire specification of this patent, any or all drawings, and each claim.

[0010] The foregoing, together with other features and aspects, will become more apparent upon referring to the following specification, claims, and accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Illustrative examples of the present application are described in detail below with reference to the following figures:

[0012] FIG. 1 is a diagram illustrating an example of a system including an application programming interface (API) designed to operate with a use case device implementation associated with a rigid software stack;

[0013] FIG. 2 is a diagram illustrating another example of a system including an API designed to operate with a use case device implementation associated with a rigid software stack, in accordance with some aspects;

[0014] FIG. 3 is a flow diagram illustrating an example of a process for processing one or more application requests, in accordance with some aspects; and

[0015] FIG. 4 is a diagram illustrating an example of a computing system, in accordance with some aspects.DETAILED DESCRIPTION

[0016] Certain aspects of this disclosure are provided below. Some of these aspects may be applied independently and some of them may be applied in combination as would be apparent to those of skill in the art. In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of aspects of the application. However, it will be apparent that various aspects may be practiced without these specific details. The figures and description are not intended to be restrictive.

[0017] As used herein, the phrase operatively connected, or operative connection, means that there exists between elements / components / devices, etc. a direct or indirect connection that allows the elements to interact with one another in some way. For example, the phrase ‘operatively connected’ may refer to any direct (e.g., wired directly between two devices or components) or indirect (e.g., wired and / or wireless connections between any number of devices, components, circuitry, etc. connecting the operatively connected devices) connection. Thus, any path through which information of any type may travel may be considered an operative connection. Additionally, operatively connected devices and / or components may exchange things other than information, such as, for example, electrical current, radio frequency signals, etc. Such information may initially be in one form (e.g., an indication of a sensor reading outside of a configured threshold), and, while traversing the operative connection, be transformed into differentinformation (e.g., an operation resulting in an action being taken by and / or to one or more separate components based on one or more sensor readings).

[0018] The ensuing description provides example aspects only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the example aspects will provide those skilled in the art with an enabling description for implementing an example aspect. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the application as set forth in the appended claims.

[0019] Devices often implement various techniques for device security. Device security may relate to securing devices against physical and / or logical attacks seeking to compromise device security. Device security techniques may include configuring a device with security -hardened hardware, such as a secure area / secure element. A secure area / secure element is any security component that includes hardware, software, firmware, middleware, and / or any combination thereof that is configured to provide resistance against logical and / or physical attacks attempting to compromise all or any portion of a computing device including the secure area / secure element. One illustrative example of such an attack is a fault injection attack. Fault injection attacks are designed to disrupt and change expected hardware and software behavior, and modify overall flows of the same.

[0020] In some aspects, the secure area / secure element can include a Trusted Execution Environment (TEE) and / or a Secure Element, such as defined by the Global PlatformRStandard for Secure Digital Services and Devices. As noted previously, the Secure Element can be an embedded Secure Element or an Integrated Secure Element, which can include or require a Tamper Resistant Element (TRE) / platform. In some cases, a secure area / secure element can be a standalone secure element or secure enclave, including hardware and low-level software providing resistance against logical and physical attacks, capable of hosting secure applications and their confidential and cryptographic data. A secure area / secure element may be available in removeable, embedded, and / or integrated form factors, such as be included in and / or operatively connected to one or more subscriber identity modules (SIMs) of any type (e.g., a removable SIM card, eSIM, integrated SIM, payment card chips, etc.) of the computing device.

[0021] An example of a secure area / secure element is a secure processor, which can be integrated into a system-on-chip (SoC) or connected to the SoC via an interface. The secure area / secure element can be in communication with other components of the device, such as one or more processors implementing software environments or applications. For example, a software environment or application can communicate with the secure area / secure element for one or more security features or services provided by the secure area / secure element. Device security features may be provided to on-device components or to entities outside of the device using pre-defined software stacks or frameworks. For example, a device may implement a web-based authentication scheme to enable entities outside of the device to enroll new users or verify existing users. Such authentication schemes typically define a rigid set of capabilities (which can be referred to herein as a rigid software stack) with respect to security functions. For instance, such rigid software stacks often target a lowest common denominator from a security perspective, which can limit applications that want to make use of advanced security features available on the device. One example of such a system including a rigid software stack includes rich execution environments, such as a High-Level Operating System (HLOS). An HLOS is a type of embedded OS, which may be designed and optimized for hardware with limited feature set.

[0022] For devices or systems having such rigid software stacks, APIs may not allow additional functionality other than that which the APIs were designed to operate. In one illustrative example, Web Authentication Application Programming Interface (API), also known as WebAuthn, is a specification defining an API (e.g., an OS platform API). The WebAuthn specification was written by the W3C and The FIDO Alliance, with the participation of various companies. The WebAuthn API allows servers to register and authenticate users (e.g., users of an HLOS, application, or other software environment) using public key cryptography instead of a password. WebAuthn is tightly integrated in a mobile browser (e.g., a Chrome™ browser) with underlying security features (e.g., key attestation, such as that provided by KeyStore or Keymint according to WebAuthn), according to a predefined architecture. It is not possible to use some rigid software stacks (e.g., rich execution environments), such as APIs (e.g., the WebAuthn API) for such environments, for any other purpose than that which it was intended to operate.

[0023] Moreover, there are no ready-made (also referred to as out-of-the-box (OOTB) or commercial-off-the-shelf (COTS)) solutions or tools that allow providers to extend rigid softwarestacks (e.g., HLOS environments), such as those for the mobile web (e.g., WebAuthn), so that higher assurance security services (e g., security services those provided by integrated / embedded secure area / secure elements) can be used directly with the rigid software stacks. Installing additional software encumbers and hinders any potential solution, as it goes beyond what is provided by a standard rigid software stack service (e.g., an HLOS service or other service having a rigid software stack), possibly requiring assistance from an original equipment manufacturer to complete. Systems and techniques are needed that do not require software support from a rigid software stack, yet can make use of integrated / embedded security -hardened hardware (e.g., secure area / secure elements).

[0024] Systems, apparatuses, processes (also referred to as methods), and computer-readable media (collectively referred to as “systems and techniques”) are described herein for encapsulating information for extending security services provided by secure area / secure elements (e.g., integrated / embedded security-hardened hardware) for use with systems (e.g., rich execution environments, such as HLOSs) that have rigid software stacks. For instance, according to some aspects, the systems and techniques can encapsulate data in a way that utilizes existing mechanisms (e.g., existing fields of messages having a message format associated with a rigid software stack, where the message format may be defined by standard-based APIs, such as the WebAuthn API) as a transport mechanism. Such a solution does not require changes to a rigid software stack (e.g., a HLOS or other environment having a rigid software stack) and thus allows a service (e.g., a cloud service or other type of service) to establish a communication channel with a secure area / secure element, without necessarily requiring any support from a from a rigid software stack (e.g., HLOS support or support from other environments having a rigid software stack). In some aspects, the secure area / secure element can include a Trusted Execution Environment (TEE) and / or a Secure Element, such as defined by the Global PlatformRStandard for Secure Digital Services and Devices.

[0025] In some examples, an encapsulation mechanism of the service (e.g., a server computer of the service) can encapsulate data (e.g., a payload) as a request message, such as an API request (e g., a WebAuthn API request). For example, the request message can be an API request having a message format defined by a standard-based API, such as a WebAuthn API request message format defined by WebAuthn. In some cases, the encapsulation mechanism of the service canencapsulate the data in one or more fields of the request message (e.g., the API request), such as by replacing existing information in the one or more fields of the request message with the data. In one illustrative example, the data can be related to a financial transaction and can be included in a field typically used for a username of a user in an API request (e.g., a WebAuthn API request). In some cases, the service can generate the data (e g., the payload) in response to receiving a request from a use case device implementation of a device, such as an application request from an application (e.g., a web browser, such as a mobile web browser, a mobile application, and / or other application) of the device.

[0026] The service can deliver the encapsulated data (e.g., in the request message) to the use case device implementation (e.g., the application such as a mobile web browser etc.). A device authentication framework API of the use case device implementation can propagate the request (e g., via one or more abstraction layers) to be handled by security features provided by the secure area / secure element. In one illustrative example, the security features can be provided by a key attestation (e.g., KeyMint) implementation of the secure area / secure element. Instead of the security features (e.g., the key attestation implementation or other security feature(s)) handling the request, an encapsulation mechanism of the secure area / secure element can decapsulate the data (e.g., by obtaining the information from the one or more fields of the request message). The secure area / secure element can transfer the decapsulated data to supplemental security features of the secure area / secure element providing supplemental functionality, which are not available through the device authentication framework API (e.g., WebAuthn) of the use case implementation and is thus not limited by the architecture of the API architecture (e.g., the Web Authn / Key Mint architecture).

[0027] The supplemental security features of the secure area / secure element can perform one or more functions (e.g., authenticate a financial transaction), and can generate a response including data associated with the one or more functions (e.g., an authentication decision for the financial transaction). The response from the supplemental security features of the secure area / secure element can be returned to the security features provided by the secure area / secure element (e.g., the key attestation implementation, such as the KeyMint implementation). The encapsulation mechanism of the secure area / secure element can encapsulate the data of the response in an API response (e.g., a WebAuthn response). The secure area / secure element can then transmit theencapsulated response through the use case device implementation (e.g., the application), and the use case device implementation can send the API response (e.g., the WebAuthn response) back to the service (e.g., the cloud service). Instead of handling the API response (e.g., the WebAuthn response) as would typically be performed, the encapsulation mechanism of the service can decapsulate the data associated with the response from the supplemental security features of the secure area / secure element (e.g., an authentication decision for a financial transaction) and process the response accordingly.

[0028] Various aspects of the systems and techniques described herein will be discussed below with respect to the figures.

[0029] FIG. 1 is a diagram illustrating an example of a computing device 100 including a device authentication framework API 104 (referred to herein as API 104) designed to operate with a use case device implementation 102 associated with a rigid software stack (e.g., an HLOS or other environment having a rigid software stack). The use case device implementation 102 can include an application, such as a mobile browser, a software application, or other use case device implementation. The API 104 can include any API of a use case device implementation having a rigid software stack, such as the WebAuthn API. In the example of FIG. 1, the API 104 limits functionality of a secure area / secure element 108 for the use case device implementation 102 and a service 106 (e g., a cloud service or other type of service) of an out of device entity 103 (which is a separate device from the computing device 100) including a use case implementation 107 (including a service authentication framework API 115 configured to communicate with a service authentication framework 126 of the computing device 100) utilizing the API service to the intended use of the API 104 due to the API 104 (e.g., WebAuthn API) being tightly integrated in the use case device implementation 102 and underlying security features (e.g., a key attestation implementation, such as KeyMint utilized by WebAuthn) according to the predefined architecture of the API design. For instance, the API 104 only allows security features 111 of the secure area / secure element 108 to be used for the use case device implementation 102, in which case the API 104 does not make the supplemental security features 113 of the secure area / secure element 108 available for the use case device implementation 102 and the service 106.

[0030] Using WebAuthn as an illustrative and non-limiting example of the API 104, a user may attempt to login to a website via the use case device implementation 102. In response, WebAuthn (the API 104) can send a request to the service 106 to authenticate the user. The service 106 can cause the API 104 to send an authentication request message through a device authentication framework 105 to the secure area / secure element 108. Referring to the WebAuthn illustrative example, the service 106 can cause the API 104 to send a WebAuthn authentication request message through a key management container (e.g., Android™ KeyStore key management container) and one or more abstraction layers (ALs), such as a key attestation hardware abstraction layer (HAL) (e.g., an Android™ KeyMint HAL) and a TRE HAL. The authentication request message includes various fields defined by a standard defined for the API 104, such as a WebAuthn authentication request message including fields defined by the WebAuthn standard. Illustrative examples of such fields include a field for a username, a field for a domain for which the user is attempting to login, etc.

[0031] The API 104 allows the security features 111 of the secure area / secure element 108 to be used for the authentication request message (e.g., the WebAuthn authentication request message), but does not allow the supplemental security features 113 to be used. Therefore, the secure area / secure element 108 can support only request messages that are supported by the API 104 (e.g., WebAuthn), such as authentication of users logging into websites or mobile applications. The secure area / secure element 108 will not be able to support other types of requests, such as verification of payment transactions.

[0032] Without additional support for the rigid software stack associated with the use case device implementation 102 (e.g., HLOS support), the functionality of the secure area / secure element 108 available to the service 106 is limited to defined and implemented modules of the API 104 (e.g., defined and implemented WebAuthn and backing KeyMint, KeyStore, etc. modules).

[0033] As noted above, systems and techniques are described herein for encapsulating data in a way that utilizes existing mechanisms (e.g., existing fields of messages defined by standard-based APIs, such as the WebAuthn API), as a transport mechanism for the data, without requiring HLOS changes.

[0034] FIG. 2 is a diagram illustrating an example of a computing device 200 including a device authentication framework API 204 (referred to herein as API 204) designed to operate with a use case device implementation 202 (e.g., an application, such as a mobile browser, a software application, or other use case device implementation) associated with a rigid software stack (e.g., an HLOS or other environment having a rigid software stack). The API 204 can include any API of a use case device implementation having a rigid software stack, such as the WebAuthn API. Using the computing device 200 of FIG. 2, full TRE functionality of a secure area / secure element 208 is available to a service 206 (e.g., a cloud service or other type of service) of an out of device entity 203, unrestricted by the API and security feature architecture (e.g., the WebAuthn and key attestation architecture, such as KeyMint architecture) and without requiring additional support for the rigid software stack associated with the use case device implementation 202 (e.g., HLOS support). For example, the service 206 (e.g., a server computer of the service 206) can establish a communication channel with the secure area / secure element 208 component, without necessarily requiring any support for the rigid software stack associated with the use case device implementation 202. The out of device entity 203 is a separate device from the computing device 200. For instance, the out of device entity 203 may include a server computer (or multiple server computers) implementing a cloud service (as an illustrative example of the service 206).

[0035] In some examples, an encapsulation mechanism 224 of the service 206 (e.g., the server computer of the service 206) can encapsulate data (e.g., a payload) as a request message including a message format associated with a rigid software stack associated with the application. In one illustrative example, the request message can be an API request having a message format defined by a standard-based API (e.g., an WebAuthn API request message format defined by WebAuthn). In some cases, the encapsulation mechanism 224 of the service 206 can encapsulate the data in one or more fields of the request message (e.g., the API request), such as by replacing existing information in the one or more fields of the request message with the data. In one illustrative example, the data can be related to a financial transaction and can be included in a field typically used for a username of a user in an API request (e.g., a WebAuthn API request). For instance, the transaction data can be included in a field that is designated by WebAuthn to include the username of the user.

[0036] In some cases, the service 206 can generate the data (e.g., the payload) in response to receiving an application request from the use case device implementation 202. In one illustrative example, a user can initiate a transaction (e.g., a financial transaction) on a mobile web site (accessed using the use case device implementation 202, such as a mobile browser) that is connected to the service 206. The mobile web site can transmit a request to the service 206 and, in response, the service 206 can generate a payload. The encapsulation mechanism 224 can encapsulate the payload as an API request (e.g., as a WebAuthn request), such as by including the payload data in one or more fields of an API request message. As described previously, the field can be part of a standard-based API request (e.g., a WebAuthn API request) and can be designated by a standard (e.g., WebAuthn) to include another type data, such as a username of a user.

[0037] The service 206 can deliver the request message (e.g., the API request) including the encapsulated data to the use case device implementation 202 and / or to the supplemental security features 222 provided by the secure area / secure element 208. In cases where the service 206 delivers the request message to the use case device implementation 202, the use case device implementation 202 can propagate the request through a device authentication framework 205 to the secure area / secure element 208. Using WebAuthn as an example of the API 204, the use case device implementation 202 can propagate the request though a key management container (e.g., Android™ KeyStore key management container), a key attestation HAL (e.g., an Android™ KeyMint HAL), and a TRE HAL to be handled by a key attestation TRE implementation (e g., a TRE KeyMint implementation) of the secure area / secure element 208. In cases where the service 206 delivers the request message to the supplemental security features 222 provided by the secure area / secure element 208, the supplemental security features 222 can provide the request to an encapsulation mechanism 220 of the secure area / secure element 208.

[0038] As described above with respect to FIG. 1, the secure area / secure element 208 (e.g., the key attestation implementation such as a KeyMint implementation) would typically handle the request message (e.g., the API request) by processing the request message using security features 211, as the API 204 is designed to only allow the security features 211 of the secure area / secure element 208 to be used for the use case device implementation 202 (and associated rigid software stack, such as an HLOS associated with an application). However, in the computing device 200 of FIG. 2, the encapsulation mechanism 220 of the secure area / secure element 208 can decapsulatethe data (e.g., the payload) generated by the service 206 from the request message (e.g., the API request). In some cases, the encapsulation mechanism 220 can be separate from the security features 211. In some aspects, to decapsulate the data, the encapsulation mechanism 220 can obtain (e.g., read, extract, etc.) the information from the one or more fields of the request message (e.g., the API request) including the encapsulated data. For example, the encapsulation mechanism 220 can identify the fields and / or data to decapsulate based on fixed field names (e.g., field names known by the encapsulation mechanism 220 as fields from which data is to be extracted) and / or based on fixed metadata fields (e.g., including metadata describing which fields include data that is to be extracted). In some cases, the data that is to be extracted can be embedded as part of a single field that is known by the encapsulation mechanism 220. The secure area / secure element 208 can output (e.g., transfer, send, transmit, output, etc.) the decapsulated data to the supplemental security features 222 of the secure area / secure element 208. The supplemental security features 222 are not available through the API 204 (e.g., the WebAuthn API) and are thus not limited by the API and security feature architecture (e.g., the Web Authn / Key Mint architecture).

[0039] The supplemental security features 222 can perform additional functions, such as providing attestation for identity of the secure area / secure element 208 (e.g., TRE identity), device security (e.g., cryptographic operations such as hashing, encryption, etc.), among others. For example, an entity outside of the computing device 200 (e.g., the out of device entity 203 or another device or entity) may issue a challenge, for which the secure area / secure element 208 can cryptographically sign with a private key. The supplemental security features 222 can generate a response (e.g., an API response, such as a WebAuthn response) to the decapsulated data in the request message. The response can include data associated with the one or more functions provided by the supplemental security features 222 (e.g., an authentication decision for the financial transaction, data, metadata, device-signature on data and metadata, device certificate, etc.). The response from the supplemental security features 222 can be output to the encapsulation mechanism 220.

[0040] The encapsulation mechanism 220 can encapsulate the data of the response (e.g., the API response, such as the WebAuthn response), such as by including the data in one or more fields of the API response. For instance, the response can be included in a field of the API response (e.g., the WebAuthn response) that is typically reserved (e.g., as defined or designated by a standard,such as WebAuthn) for confirmation that a user is authenticated to login to a mobile website. In some cases, the encapsulation mechanism 220 can then output the encapsulated response (e.g., the WebAuthn response with the data in one or more fields of the WebAuthn response) to the device authentication framework 205. The device authentication framework 205 can process the response (e g., using the key management container, the key attestation HAL, and the TRE HAL) and output the processed response to the use case device implementation 202. The use case device implementation 202 and / or the API 204 can output the response to the service 206 as a reply to the request message (e.g., an API response to the API request). For example, in such cases, the use case device implementation 202 and / or the API 204 can send (e.g., transmit via one or more transceivers of a device in which the use case device implementation 202 is installed) the API response (e.g., the WebAuthn response) to the service 206 (e.g., the server computer of the service 206). In other cases, the encapsulation mechanism 220 can output the encapsulated response through the supplemental security features 222 directly to the service 206.

[0041] As shown in FIG. 2, a service authentication framework 226 of the service 206 (e.g., installed on the server computer of the service 206) can receive the API response. In one illustrative example, the service authentication framework 226 can include an API / key attestation implementation. Instead of handling the API response (e.g., the WebAuthn response) as would typically be performed (e.g., by the service 106 of FIG. 1), the encapsulation mechanism 224 of the service 206 (e.g., the server computer of the service 206) can receive the API response from the service authentication framework 226 and / or from (e.g., directly from) the supplemental security features 222. The encapsulation mechanism 224 can decapsulate the data associated with the response from the supplemental security features 222 (e.g., an authentication decision for a financial transaction). For example, to decapsulate the data, the encapsulation mechanism 224 can obtain (e.g., read, extract, etc.) the information from the one or more fields of the API response including the encapsulated data. An extended use case implementation 228 (e.g., supplemental security functionality) of the service 206 can then process the response accordingly. The extended use case implementation 228 can provide additional features and / or functionality not provided by a use case implementation 207 (including a service authentication framework API 215 configured to operate with the service authentication framework 226) of the service 206, such as device attestation (e.g., signing data with a device private / secret key).

[0042] FIG. 3 illustrates an example of a process 300 for processing one or more application requests, according to techniques described herein. The process 300 may be performed by a computing device, such as a server computer of the cloud server 206 of FIG. 2, or a component (e.g., a chipset, a system-on-chip (SOC), at least one processor such as central processing unit(s) (CPU(s)), graphics processing unit(s) (GPU(s)), neural processing unit(s) (NPU(s)), digital signal processor(s) (DSP(s)), etc., memory, any combination thereof, and / or other component) of the computing device. The operations of the process 300 may be implemented as software components that are executed and run on one or more processors (e.g., a CPU, GPU, DSP, NPU, etc., the processor 410 of FIG. 4, or other processor(s)) and / or partially or fully using one or more hardware components. Further, the transmission and reception of signals by the computing device in the process 300 may be enabled, for example, by one or more antennas, one or more transceivers (e.g., wireless transceiver(s)), and / or other communication components of the computing device.

[0043] At block 302, the computing device (or component thereof) can receive an application request from an application (e.g., the use case device implementation 202 of FIG. 2, such as a web browser or other use case device implementation). In some cases, the application request includes a request for a transaction via the application.

[0044] At block 304, the computing device (or component thereof) can generate data (e.g., a payload) based on the application request.

[0045] At block 306, the computing device (or component thereof) can encapsulate the data in one or more fields of a request message. The request message includes a message format associated with a rigid software stack (e.g., a high-level operating system or other rigid software stack) associated with the application. In some aspects, the message format associated with the rigid software stack is associated with an application programming interface (API) designed to operate with the rigid software stack. In some cases, to encapsulate the data in the one or more fields of the request message, the computing device (or component thereof) can replace existing information in the one or more fields of the request message with the data.

[0046] At block 308, the computing device (or component thereof) can transmit the request message to the application for authentication by a secure area or secure element coupled to the application. In some cases, the computing device (or component thereof) can transmit the request to the application via one or more layers, such as one or more abstraction layers. In some aspects,the secure area or secure element comprises at least one of a tamper resistant element (TRE) or a trusted execution environment (TEE).

[0047] In some cases, the computing device (or component thereof) can receive an encapsulated response message based on the authentication by the secure area or secure element, the encapsulated response message including the message format associated with the rigid software stack. The computing device (or component thereof) can decapsulate the encapsulated response message to obtain a decapsulated response message. For example, to decapsulate the encapsulated response message, the computing device (or component thereof) can obtain information from one or more fields of the encapsulated response message, where the one or more fields of the encapsulated response message are associated with the message format. The computing device (or component thereof) can process the decapsulated response message to generate a response message to the application request; and transmit the response message to the application.

[0048] In some cases, the devices or apparatuses configured to perform the operations of the process 300 and / or other processes described herein may include a processor, microprocessor, microcomputer, or other component of a device that is configured to carry out the steps of the process 300 and / or other process. In some examples, such devices or apparatuses may include one or more sensors configured to capture image data and / or other sensor measurements. In some examples, such computing device or apparatus may include one or more sensors and / or a camera configured to capture one or more images or videos. In some cases, such device or apparatus may include a display for displaying images. In some examples, the one or more sensors and / or camera are separate from the device or apparatus, in which case the device or apparatus receives the sensed data. Such device or apparatus may further include a network interface configured to communicate data.

[0049] The components of the device or apparatus configured to carry out one or more operations of the process 300 and / or other processes described herein can be implemented in circuitry. For example, the components can include and / or can be implemented using electronic circuits or other electronic hardware, which can include one or more programmable electronic circuits (e.g., microprocessors, graphics processing units (GPUs), digital signal processors (DSPs), central processing units (CPUs), and / or other suitable electronic circuits), and / or can include and / or be implemented using computer software, firmware, or any combination thereof, to performthe various operations described herein. The computing device may further include a display (as an example of the output device or in addition to the output device), a network interface configured to communicate and / or receive the data, any combination thereof, and / or other component(s). The network interface may be configured to communicate and / or receive Internet Protocol (IP) based data or other type of data.

[0050] The process 300 is illustrated as a logical flow diagram, the operations of which represent sequences of operations that can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations represent computerexecutable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computerexecutable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement the processes.

[0051] Additionally, the processes described herein (e.g., the process 300 and / or other processes) may be performed under the control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executing collectively on one or more processors, by hardware, or combinations thereof. As noted above, the code may be stored on a computer- readable or machine-readable storage medium, for example, in the form of a computer program including a plurality of instructions executable by one or more processors. The computer-readable or machine-readable storage medium may be non-transitory.

[0052] FIG. 4 is a diagram illustrating an example of a system for implementing certain aspects of the present technology. In particular, FIG. 4 illustrates an example of computing system 400, which can be for example any computing device making up internal computing system, a remote computing system, a camera, or any component thereof in which the components of the system are in communication with each other using connection 405. Connection 405 can be a physical connection using a bus, or a direct connection into processor 410, such as in a chipset architecture. Connection 405 can also be a virtual connection, networked connection, or logical connection.

[0053] In some aspects, computing system 400 is a distributed system in which the functions described in this disclosure can be distributed within a datacenter, multiple data centers, a peer network, etc. In some aspects, one or more of the described system components represents many such components each performing some or all of the function for which the component is described. In some aspects, the components can be physical or virtual devices.

[0054] Example system 400 includes at least one processing unit (CPU or processor) 410 and connection 405 that couples various system components including system memory 415, such as read-only memory (ROM) 420 and random-access memory (RAM) 425 to processor 410. Computing system 400 can include a cache 411 of high-speed memory connected directly with, in close proximity to, or integrated as part of processor 410.

[0055] Processor 410 can include any general-purpose processor and a hardware service or software service, such as services 432, 434, and 436 stored in storage device 430, configured to control processor 410 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. Processor 410 may essentially be a completely self- contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

[0056] To enable user interaction, computing system 400 includes an input device 445, which can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech, etc. Computing system 400 can also include output device 435, which can be one or more of a number of output mechanisms. In some instances, multimodal systems can enable a user to provide multiple types of input / output to communicate with computing system 400. Computing system 400 can include communications interface 440, which can generally govern and manage the user input and system output.

[0057] The communication interface may perform or facilitate receipt and / or transmission wired or wireless communications using wired and / or wireless transceivers, including those making use of an audio jack / plug, a microphone jack / plug, a universal serial bus (USB) port / plug, an Apple® Lightning® port / plug, an Ethernet port / plug, a fiber optic port / plug, a proprietary wired port / plug, a BLUETOOTH® wireless signal transfer, a BLUETOOTH® low energy (BLE) wireless signaltransfer, an IBEACON® wireless signal transfer, a radio-frequency identification (RFID) wireless signal transfer, near-field communications (NFC) wireless signal transfer, dedicated short range communication (DSRC) wireless signal transfer, 802.11 Wi-Fi wireless signal transfer, WLAN signal transfer, Visible Light Communication (VLC), Worldwide Interoperability for Microwave Access (WiMAX), Infrared (IR) communication wireless signal transfer, Public Switched Telephone Network (PSTN) signal transfer, Integrated Services Digital Network (ISDN) signal transfer, 3G / 4G / 5G / long term evolution (LTE) cellular data network wireless signal transfer, ad- hoc network signal transfer, radio wave signal transfer, microwave signal transfer, infrared signal transfer, visible light signal transfer, ultraviolet light signal transfer, wireless signal transfer along the electromagnetic spectrum, or some combination thereof.

[0058] The communications interface 440 may also include one or more GNSS receivers or transceivers that are used to determine a location of the computing system 400 based on receipt of one or more signals from one or more satellites associated with one or more GNSS systems. GNSS systems include, but are not limited to, the US-based Global Positioning System (GPS), the Russiabased Global Navigation Satellite System (GLONASS), the China-based BeiDou Navigation Satellite System (BDS), and the Europe-based Galileo GNSS. There is no restriction on operating on any particular hardware arrangement, and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

[0059] Storage device 430 can be a non-volatile and / or non-transitory and / or computer-readable memory device and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, a floppy disk, a flexible disk, a hard disk, magnetic tape, a magnetic strip / stripe, any other magnetic storage medium, flash memory, memristor memory, any other solid-state memory, a compact disc read only memory (CD-ROM) optical disc, a rewritable compact disc (CD) optical disc, digital video disk (DVD) optical disc, a blu-ray disc (BDD) optical disc, a holographic optical disk, another optical medium, a secure digital (SD) card, a micro secure digital (microSD) card, a Memory Stick® card, a smartcard chip, a Europay, Mastercard and Visa (EMV) chip, a subscriber identity module (SIM) card, a mini / micro / nano / pico SIM card, another integrated circuit (IC) chip / card, RAM, static RAM (SRAM), dynamic RAM (DRAM), ROM, programmable read-only memory (PROM), erasableprogrammable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash EPROM (FLASHEPROM), cache memory (L1 / L2 / L3 / L4 / L5 / L#), resistive random-access memory (RRAM / ReRAM), phase change memory (PCM), spin transfer torque RAM (STT-RAM), another memory chip or cartridge, and / or a combination thereof.

[0060] The storage device 430 can include software services, servers, services, etc., that when the code that defines such software is executed by the processor 410, it causes the system to perform a function. In some aspects, a hardware service that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as processor 410, connection 405, output device 435, etc., to carry out the function. The term “computer-readable medium” includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other mediums capable of storing, containing, or carrying instruction(s) and / or data. A computer-readable medium may include a non-transitory medium in which data can be stored and that does not include carrier waves and / or transitory electronic signals propagating wirelessly or over wired connections.

[0061] The term “computer-readable medium” includes, but is not limited to, portable or nonportable storage devices, optical storage devices, and various other mediums capable of storing, containing, or carrying instruction(s) and / or data. A computer-readable medium may include a non-transitory medium in which data can be stored and that does not include carrier waves and / or transitory electronic signals propagating wirelessly or over wired connections. Examples of a non- transitory medium may include, but are not limited to, a magnetic disk or tape, optical storage media such as compact disk (CD) or digital versatile disk (DVD), flash memory, memory or memory devices. A computer-readable medium may have stored thereon code and / or machineexecutable instructions that may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, or the like.

[0062] In some aspects, the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bit stream and the like. However, when mentioned, non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.

[0063] Specific details are provided in the description above to provide a thorough understanding of the aspects and examples provided herein. However, it will be understood by one of ordinary skill in the art that the aspects may be practiced without these specific details. For clarity of explanation, in some instances the present technology may be presented as including individual functional blocks including devices, device components, steps or routines in a method embodied in software, or combinations of hardware and software. Additional components may be used other than those shown in the figures and / or described herein. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the aspects in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the aspects.

[0064] Individual aspects may be described above as a process or method which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be rearranged. A process is terminated when its operations are completed, but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0065] Processes and methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer- readable media. Such instructions can include, for example, instructions and data which cause or otherwise configure a general-purpose computer, special purpose computer, or a processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, source code. Examples ofcomputer-readable media that may be used to store instructions, information used, and / or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.

[0066] Devices implementing processes and methods according to these disclosures can include hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof, and can take any of a variety of form factors. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks (e.g., a computer-program product) may be stored in a computer-readable or machine- readable medium. A processor(s) may perform the necessary tasks. Typical examples of form factors include laptops, smart phones, mobile phones, tablet devices or other small form factor personal computers, personal digital assistants, rackmount devices, standalone devices, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.

[0067] The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are example means for providing the functions described in the disclosure.

[0068] In the foregoing description, aspects of the application are described with reference to specific aspects thereof, but those skilled in the art will recognize that the application is not limited thereto. Thus, while illustrative aspects of the application have been described in detail herein, it is to be understood that the inventive concepts may be otherwise variously embodied and employed, and that the appended claims are intended to be construed to include such variations, except as limited by the prior art. Various features and aspects of the above-described application may be used individually or jointly. Further, aspects can be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. The specification and drawings are, accordingly, to be regarded as illustrative rather than restrictive. For the purposes of illustration, methods were described in a particular order. It should be appreciated that in alternate aspects, the methods may be performed in a different order than that described.

[0069] One of ordinary skill will appreciate that the less than (“<”) and greater than (“>”) symbols or terminology used herein can be replaced with less than or equal to (“<”) and greater than or equal to (“>”) symbols, respectively, without departing from the scope of this description.

[0070] Where components are described as being “configured to” perform certain operations, such configuration can be accomplished, for example, by designing electronic circuits or other hardware to perform the operation, by programming programmable electronic circuits (e.g., microprocessors, or other suitable electronic circuits) to perform the operation, or any combination thereof.

[0071] The phrase “coupled to” refers to any component that is physically connected to another component either directly or indirectly, and / or any component that is in communication with another component (e g., connected to the other component over a wired or wireless connection, and / or other suitable communication interface) either directly or indirectly.

[0072] Claim language or other language reciting “at least one of’ a set and / or “one or more” of a set indicates that one member of the set or multiple members of the set (in any combination) satisfy the claim. For example, claim language reciting “at least one of A and B” or “at least one of A or B” means A, B, or A and B. In another example, claim language reciting “at least one of A, B, and C” or “at least one of A, B, or C” means A, B, C, or A and B, or A and C, or B and C, A and B and C, or any duplicate information or data (e.g., A and A, B and B, C and C, A and A and B, and so on), or any other ordering, duplication, or combination of A, B, and C. The language “at least one of’ a set and / or “one or more” of a set does not limit the set to the items listed in the set. For example, claim language reciting “at least one of A and B” or “at least one of A or B” may mean A, B, or A and B, and may additionally include items not listed in the set of A and B. The phrases “at least one” and “one or more” are used interchangeably herein.

[0073] Claim language or other language reciting “at least one processor configured to,” “at least one processor being configured to,” “one or more processors configured to,” “one or more processors being configured to,” or the like indicates that one processor or multiple processors (in any combination) can perform the associated operation(s). For example, claim language reciting “at least one processor configured to: X, Y, and Z” means a single processor can be used to perform operations X, Y, and Z; or that multiple processors are each tasked with a certain subset of operations X, Y, and Z such that together the multiple processors perform X, Y, and Z; or that agroup of multiple processors work together to perform operations X, Y, and Z. In another example, claim language reciting “at least one processor configured to: X, Y, and Z” can mean that any single processor may only perform at least a subset of operations X, Y, and Z.

[0074] Where reference is made to one or more elements performing functions (e.g., steps of a method), one element may perform all functions, or more than one element may collectively perform the functions. When more than one element collectively performs the functions, each function need not be performed by each of those elements (e.g., different functions may be performed by different elements) and / or each function need not be performed in whole by only one element (e.g., different elements may perform different sub-functions of a function). Similarly, where reference is made to one or more elements configured to cause another element (e.g., an apparatus) to perform functions, one element may be configured to cause the other element to perform all functions, or more than one element may collectively be configured to cause the other element to perform the functions.

[0075] Where reference is made to an entity (e.g., any entity or device described herein) performing functions or being configured to perform functions (e.g., steps of a method), the entity may be configured to cause one or more elements (individually or collectively) to perform the functions. The one or more components of the entity may include at least one memory, at least one processor, at least one communication interface, another component configured to perform one or more (or all) of the functions, and / or any combination thereof. Where reference to the entity performing functions, the entity may be configured to cause one component to perform all functions, or to cause more than one component to collectively perform the functions. When the entity is configured to cause more than one component to collectively perform the functions, each function need not be performed by each of those components (e.g., different functions may be performed by different components) and / or each function need not be performed in whole by only one component (e.g., different components may perform different sub-functions of a function).

[0076] The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the examples disclosed herein may be implemented as electronic hardware, computer software, firmware, or combinations thereof. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality isimplemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

[0077] The techniques described herein may also be implemented in electronic hardware, computer software, firmware, or any combination thereof. Such techniques may be implemented in any of a variety of devices such as general purposes computers, wireless communication device handsets, or integrated circuit devices having multiple uses including application in wireless communication device handsets and other devices. Any features described as modules or components may be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. If implemented in software, the techniques may be realized at least in part by a computer-readable data storage medium including program code including instructions that, when executed, performs one or more of the methods, algorithms, and / or operations described above. The computer-readable data storage medium may form part of a computer program product, which may include packaging materials. The computer-readable medium may include memory or data storage media, such as random access memory (RAM) such as synchronous dynamic random access memory (SDRAM), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), FLASH memory, magnetic or optical data storage media, and the like. The techniques additionally, or alternatively, may be realized at least in part by a computer-readable communication medium that carries or communicates program code in the form of instructions or data structures and that can be accessed, read, and / or executed by a computer, such as propagated signals or waves.

[0078] The program code may be executed by a processor, which may include one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, an application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Such a processor may be configured to perform any of the techniques described in this disclosure. A general-purpose processor may be a microprocessor; but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality ofmicroprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Accordingly, the term “processor,” as used herein may refer to any of the foregoing structure, any combination of the foregoing structure, or any other structure or apparatus suitable for implementation of the techniques described herein.

[0079] Illustrative aspects of the disclosure include:

[0080] Aspect 1 : An apparatus for processing one or more application requests, the apparatus comprising: at least one memory; and at least one processor coupled to the at least one memory and configured to: receive an application request from an application; generate data based on the application request; encapsulate the data in one or more fields of a request message, the request message including a message format associated with a rigid software stack associated with the application; and transmit the request message to the application for authentication by a secure area or secure element coupled to the application.

[0081] Aspect 2. The apparatus of Aspect 1, wherein the at least one processor is configured to: receive an encapsulated response message based on the authentication by the secure area or secure element, the encapsulated response message including the message format associated with the rigid software stack; and decapsulate the encapsulated response message to obtain a decapsulated response message.

[0082] Aspect 3. The apparatus of Aspect 2, wherein, to decapsulate the encapsulated response message, the at least one processor is configured to obtain information from one or more fields of the encapsulated response message, the one or more fields of the encapsulated response message being associated with the message format.

[0083] Aspect 4. The apparatus of any one of Aspects 2 or 3, wherein the at least one processor is configured to: process the decapsulated response message to generate a response message to the application request; and transmit the response message to the application.

[0084] Aspect 5. The apparatus of any one of Aspects 1 to 4, wherein, to encapsulate the data in the one or more fields of the request message, the at least one processor is configured to: replace existing information in the one or more fields of the request message with the data.

[0085] Aspect 6. The apparatus of any one of Aspects 1 to 5, wherein the at least one processor is configured to transmit the request message to the application via one or more abstraction layers.

[0086] Aspect 7. The apparatus of any one of Aspects 1 to 6, wherein the application includes a web browser.

[0087] Aspect 8. The apparatus of any one of Aspects 1 to 7, wherein the application request includes a request for a transaction via the application.

[0088] Aspect 9. The apparatus of any one of Aspects 1 to 8, wherein the message format associated with the rigid software stack is associated with an application programming interface (API) designed to operate with the rigid software stack.

[0089] Aspect 10. The apparatus of any one of Aspects 1 to 9, wherein the secure area or secure element comprises at least one of a tamper resistant element (TRE) or a trusted execution environment (TEE).

[0090] Aspect 11. A method of processing one or more application requests, the method comprising: receiving an application request from an application; generating data based on the application request; encapsulating the data in one or more fields of a request message, the request message including a message format associated with a rigid software stack associated with the application; and transmitting the request message to the application for authentication by a secure area or secure element coupled to the application.

[0091] Aspect 12. The method of Aspect 11, further comprising: receiving an encapsulated response message based on the authentication by the secure area or secure element, the encapsulated response message including the message format associated with the rigid software stack; and decapsulating the encapsulated response message to obtain a decapsulated response message.

[0092] Aspect 13. The method of Aspect 12, wherein decapsulating the encapsulated response message comprises obtaining information from one or more fields of the encapsulated response message, the one or more fields of the encapsulated response message being associated with the message format.

[0093] Aspect 14. The method of any one of Aspects 12 or 13, further comprising: processing the decapsulated response message to generate a response message to the application request; and transmitting the response message to the application.

[0094] Aspect 15. The method of any one of Aspects 11 to 14, wherein encapsulating the data in the one or more fields of the request message comprises: replacing existing information in the one or more fields of the request message with the data.

[0095] Aspect 16. The method of any one of Aspects 11 to 15, further comprising transmitting the request message to the application via one or more abstraction layers.

[0096] Aspect 17. The method of any one of Aspects 11 to 16, wherein the application includes a web browser.

[0097] Aspect 18. The method of any one of Aspects 11 to 17, wherein the application request includes a request for a transaction via the application.

[0098] Aspect 19. The method of any one of Aspects 11 to 18, wherein the message format associated with the rigid software stack is associated with an application programming interface (API) designed to operate with the rigid software stack.

[0099] Aspect 20. The method of any one of Aspects 11 to 19, wherein the secure area or secure element comprises at least one of a tamper resistant element (TRE) or a trusted execution environment (TEE).

[0100] Aspect 21 : A non-transitory computer-readable medium having stored thereon instructions that, when executed by one or more processors, cause the one or more processors to perform operations according to any of Aspects 11 to 20.

[0101] Aspect 22: An apparatus for processing one or more application requests, including one or more means for performing operations according to any of Aspects 11 to 20.

Claims

CLAIMSWHAT IS CLAIMED IS:

1. An apparatus for processing one or more application requests, the apparatus comprising: at least one memory; and at least one processor coupled to the at least one memory and configured to: receive an application request from an application; generate data based on the application request; encapsulate the data in one or more fields of a request message, the request message including a message format associated with a rigid software stack associated with the application; and transmit the request message to the application for authentication by a secure area or secure element coupled to the application.

2. The apparatus of claim 1, wherein the at least one processor is configured to: receive an encapsulated response message based on the authentication by the secure area or secure element, the encapsulated response message including the message format associated with the rigid software stack; and decapsulate the encapsulated response message to obtain a decapsulated response message.

3. The apparatus of claim 2, wherein, to decapsulate the encapsulated response message, the at least one processor is configured to obtain information from one or more fields of the encapsulated response message, the one or more fields of the encapsulated response message being associated with the message format.

4. The apparatus of claim 2, wherein the at least one processor is configured to: process the decapsulated response message to generate a response message to the application request; and transmit the response message to the application.

5. The apparatus of claim 1, wherein, to encapsulate the data in the one or more fields of the request message, the at least one processor is configured to: replace existing information in the one or more fields of the request message with the data.

6. The apparatus of claim 1, wherein the at least one processor is configured to transmit the request message to the application via one or more abstraction layers.

7. The apparatus of claim 1, wherein the application includes a web browser.

8. The apparatus of claim 1, wherein the application request includes a request for a transaction via the application.

9. The apparatus of claim 1, wherein the message format associated with the rigid software stack is associated with an application programming interface (API) designed to operate with the rigid software stack.

10. The apparatus of claim 1, wherein the secure area or secure element comprises at least one of a tamper resistant element (TRE) or a trusted execution environment (TEE).

11. A method of processing one or more application requests, the method comprising: receiving an application request from an application; generating data based on the application request; encapsulating the data in one or more fields of a request message, the request message including a message format associated with a rigid software stack associated with the application; and transmitting the request message to the application for authentication by a secure area or secure element coupled to the application.

12. The method of claim 11, further comprising:receiving an encapsulated response message based on the authentication by the secure area or secure element, the encapsulated response message including the message format associated with the rigid software stack; and decapsulating the encapsulated response message to obtain a decapsulated response message.

13. The method of claim 12, wherein decapsulating the encapsulated response message comprises obtaining information from one or more fields of the encapsulated response message, the one or more fields of the encapsulated response message being associated with the message format.

14. The method of claim 12, further comprising: processing the decapsulated response message to generate a response message to the application request; and transmitting the response message to the application.

15. The method of claim 11, wherein encapsulating the data in the one or more fields of the request message comprises: replacing existing information in the one or more fields of the request message with the data.

16. The method of claim 11, further comprising transmitting the request message to the application via one or more abstraction layers.

17. The method of claim 11, wherein the application includes a web browser.

18. The method of claim 11, wherein the application request includes a request for a transaction via the application.

19. The method of claim 1 1, wherein the message format associated with the rigid software stack is associated with an application programming interface (API) designed to operate with the rigid software stack.

20. The method of claim 11, wherein the secure area or secure element comprises at least one of a tamper resistant element (TRE) or a trusted execution environment (TEE).

Images