Abstract: Techniques are described herein for applying access controls to logical secure elements (LSEs) running on the same secure element hardware platform. Embodiments include a firmware component that determines whether a message targeting an LSE is authorized to trigger an operation. For example, the firmware component may verify a signature of the received message using a public key, shared secret, or other access control key. Additionally or alternatively, access control policies may be defined to constrain the load of the LSEs on the SE platform hardware and/or to prioritize LSE access. For example, the access control policies may define usage thresholds, such as maximum threshold memory and/or processor utilization rates. As another example, the access controls may restrict the active time for an LSE to a threshold duration. If access constraints are violated or the message cannot be verified, then the firmware component may delay or deny the operation.

Abstract: A system deploys an instance of a secure element (SE) application object to each of a plurality of secure containers of an SE platform runtime environment. The system generates an SE proxy application that includes an extension component that redirects to an executable component of an SE application installation file. The system additionally generates a secure container in the SE platform runtime environment. The secure container includes a partition that logically isolates the secure container from other secure containers of the SE platform runtime environment. The system deploys an SE application object to the secure container based on the extension component of the SE proxy application. Upon having deployed the SE application object to the secure container, the system executes the SE application object within the secure container.

Abstract: Techniques are described herein for running multiple logical secure elements (LSEs) on the same physical secure element (SE) hardware. For example, embodiments may include running multiple logical Subscriber Identification Modules (SIM) cards on the same physical SIM card or universal integrated circuit card (UICC). Additionally or alternatively, embodiments may include running other secure element applications and services on the same SE hardware. The techniques allow for mobile devices users to access multiple security services, which may originate from different security service providers (SSPs), in a secure manner using the same SE hardware without requiring the integration of multiple physical slots on a mobile device or the physical exchange of different cards within the same slot.

Abstract: Techniques are described herein for applying access controls to logical secure elements (LSEs) running on the same secure element hardware platform. Embodiments include a firmware component that determines whether a message targeting an LSE is authorized to trigger an operation. For example, the firmware component may verify a signature of the received message using a public key, shared secret, or other access control key. Additionally or alternatively, access control policies may be defined to constrain the load of the LSEs on the SE platform hardware and/or to prioritize LSE access. For example, the access control policies may define usage thresholds, such as maximum threshold memory and/or processor utilization rates. As another example, the access controls may restrict the active time for an LSE to a threshold duration. If access constraints are violated or the message cannot be verified, then the firmware component may delay or deny the operation.

Abstract: A system deploys an instance of a secure element (SE) application object to each of a plurality of secure containers of an SE platform runtime environment. The system generates an SE proxy application that includes an extension component that redirects to an executable component of an SE application installation file. The system additionally generates a secure container in the SE platform runtime environment. The secure container includes a partition that logically isolates the secure container from other secure containers of the SE platform runtime environment. The system deploys an SE application object to the secure container based on the extension component of the SE proxy application. Upon having deployed the SE application object to the secure container, the system executes the SE application object within the secure container.

Abstract: A system deploys an instance of a secure element (SE) application object to each of a plurality of secure containers of an SE platform runtime environment. The system generates an SE proxy application that includes an extension component that redirects to an executable component of an SE application installation file. The system additionally generates a secure container in the SE platform runtime environment. The secure container includes a partition that logically isolates the secure container from other secure containers of the SE platform runtime environment. The system deploys an SE application object to the secure container based on the extension component of the SE proxy application. Upon having deployed the SE application object to the secure container, the system executes the SE application object within the secure container.

Abstract: Techniques for implementing and enforcing a security policy in a secure element are disclosed. The secure element enforces the security policy to grant and/or deny access, such as from an application processor, to configuration of the device peripheral components and access to data of the device peripheral components across one or more bus architectures, such as an I3C bus. Implementing an access control policy in a secure element allows execution of code within the isolated secure element hardware processor, preventing software attacks that may emanate from code running in the application processor. This design also benefits from hardware protections against physical attacks.

Abstract: Techniques for implementing and enforcing a security policy in a secure element are disclosed. The secure element enforces the security policy to grant and/or deny access, such as from an application processor, to configuration of the device peripheral components and access to data of the device peripheral components across one or more bus architectures, such as an I3C bus. Implementing an access control policy in a secure element allows execution of code within the isolated secure element hardware processor, preventing software attacks that may emanate from code running in the application processor. This design also benefits from hardware protections against physical attacks.

Abstract: Techniques are described herein for running multiple logical secure elements (LSEs) on the same physical secure element (SE) hardware. For example, embodiments may include running multiple logical Subscriber Identification Modules (SIM) cards on the same physical SIM card or universal integrated circuit card (UICC). Additionally or alternatively, embodiments may include running other secure element applications and services on the same SE hardware. The techniques allow for mobile devices users to access multiple security services, which may originate from different security service providers (SSPs), in a secure manner using the same SE hardware without requiring the integration of multiple physical slots on a mobile device or the physical exchange of different cards within the same slot.

Abstract: Techniques are described herein for applying access controls to logical secure elements (LSEs) running on the same secure element hardware platform. Embodiments include a firmware component that determines whether a message targeting an LSE is authorized to trigger an operation. For example, the firmware component may verify a signature of the received message using a public key, shared secret, or other access control key. Additionally or alternatively, access control policies may be defined to constrain the load of the LSEs on the SE platform hardware and/or to prioritize LSE access. For example, the access control policies may define usage thresholds, such as maximum threshold memory and/or processor utilization rates. As another example, the access controls may restrict the active time for an LSE to a threshold duration. If access constraints are violated or the message cannot be verified, then the firmware component may delay or deny the operation.

Abstract: Techniques for implementing and enforcing a security policy in a secure element are disclosed. The secure element enforces the security policy to grant and/or deny access, such as from an application processor, to configuration of the device peripheral components and access to data of the device peripheral components across one or more bus architectures, such as an I3C bus. Implementing an access control policy in a secure element allows execution of code within the isolated secure element hardware processor, preventing software attacks that may emanate from code running in the application processor. This design also benefits from hardware protections against physical attacks.

Abstract: A method and system for receiving from an authenticated user, at an authorization server, via a service provider, an authorization request to perform a sensitive operation on a first device. The method also includes generating, by the authorization server and in response to receiving the authorization request, an authorization token that includes a device constraint and a binding code constraint, which includes a binding code. Additionally, the method includes transmitting the authorization token to an isolated execution environment of the first device, where the sensitive operation is not permitted on the first device unless the first device successfully performs a verification in the isolated execution environment using the authorization token. Furthermore, the method includes permitting the sensitive operation based on the verification.

Abstract: A system and method can support on-device operation management. A token issuer on a backend server, and/or a tool, can generate an authorization token, which is bound to a user of one or more devices using a unique identifier (ID) that is assigned to the user. The unique ID can be known and/or shared between the an on-device authorizing entity and the token issuer. Then, the on-device authorizing entity can verify the authorization token before granting an execution of one or more protected on-device operations. Furthermore, the on-device authorizing entity may not grant the execution of the one or more protected on-device operations, when the unique ID is erased from the device.

Abstract: A method and system for receiving from an authenticated user, at an authorization server, via a service provider, an authorization request to perform a sensitive operation on a first device. The method also includes generating, by the authorization server and in response to receiving the authorization request, an authorization token that includes a device constraint and a binding code constraint, which includes a binding code. Additionally, the method includes transmitting the authorization token to an isolated execution environment of the first device, where the sensitive operation is not permitted on the first device unless the first device successfully performs a verification in the isolated execution environment using the authorization token. Furthermore, the method includes permitting the sensitive operation based on the verification.

Abstract: A system and method can support on-device operation management. A token issuer on a backend server, and/or a tool, can generate an authorization token, which is bound to a user of one or more devices using a unique identifier (ID) that is assigned to the user. The unique ID can be known and/or shared between the an on-device authorizing entity and the token issuer. Then, the on-device authorizing entity can verify the authorization token before granting an execution of one or more protected on-device operations. Furthermore, the on-device authorizing entity may not grant the execution of the one or more protected on-device operations, when the unique ID is erased from the device.

Abstract: The invention relates to a method for accessing a portable device, the portable device being connected to a host device. According to the invention, the host device, as a client, opens a communication channel to the portable device, as a server, according to a first network communication protocol, and the portable device, as a client, uses the communication channel to transport data to the host device, as a server, according to a second network communication protocol, without the implementation of any complex infrastructure. The invention relates also to a corresponding system for accessing a portable device, a corresponding portable device accessible from outside and a corresponding host device for accessing a portable device.