Performing cryptographic operations in a secure element platform runtime environment

Abstract

A system performs a set of cryptographic operations at least by utilizing an API to enable execution of a set of one or more secure element (SE) applications within an SE platform runtime environment of a first computing entity. The set of cryptographic operations includes generating a first shared secret, encapsulating the first shared secret at least by utilizing a first public key associated with a second computing entity according to an encapsulation algorithm to generate a ciphertext, and transmitting the ciphertext from the first computing entity to the second computing entity. The second computing entity decapsulates the ciphertext by utilizing a private key corresponding to the first public key to derive the first shared secret. The first computing entity and the second computing entity then exchange at least one encrypted message that is encrypted utilizing an encryption key that includes the first shared secret, or is based at least in part on the first shared secret.

Description

[0001] Incorporate by reference; abandon declaration

[0002] The following applications are hereby incorporated by reference: Application No. 18 / 535,432, filed December 11, 2023; and Application No. 63 / 595,907, filed November 3, 2023. The applicant hereby withdraws any declaration of abandonment of the scope of the claims in (one or more) parent applications or their examination history, and informs the USPTO that the claims in this application may be more extensive than any claims in (one or more) parent applications. Technical Field

[0003] This disclosure relates to performing cryptographic operations in a secure element platform runtime environment. More specifically, this disclosure relates to performing quantum-resistant cryptographic operations in a secure element platform runtime environment. Background Technology

[0004] Encryption keys used to encrypt messages transmitted between computational entities can be generated using various cryptographic operations. These operations can include Key Agreement (KA) algorithms and / or Key Encapsulation Mechanism (KEM) algorithms. KA algorithms enable computational entities to securely establish a shared secret key, ensuring that only these computational entities can derive the same key. Typically, two computational entities generate private keys that are used only for that specific KA session. These private keys are combined with corresponding public keys using a KA algorithm (such as the Diffie-Hellman algorithm). This produces a shared secret that can be used as an encryption key for encrypting and decrypting messages. For KEM algorithms, the computational entities use the KEM algorithm to encapsulate the shared secret with the public key of the receiving computational entity. The output is an encapsulated message containing the encapsulated shared secret. The receiving computational entity holding the corresponding private key can then decapsulate the encapsulated message to retrieve the shared secret. KA and KEM algorithms can be combined to provide a hybrid cryptographic algorithm to generate a combined shared secret that can be similarly used as an encryption key.

[0005] Once a shared secret is established (e.g., through the KA algorithm, KEM algorithm, or a combination of cryptographic algorithms), it can be used as an encryption key in symmetric encryption algorithms for message encryption and decryption. Two computational entities can independently compute the same shared secret, ensuring secure communication between them. Symmetric encryption algorithms, such as AES (Advanced Encryption Standard), can be used. Symmetric encryption algorithms utilize an encryption key to convert plaintext messages into ciphertext and vice versa. Ciphertext can only be decrypted using the same encryption key, ensuring message confidentiality and integrity.

[0006] The content of this background section should not be construed as prior art simply because it appears in this section. Attached Figure Description

[0007] Embodiments are illustrated in the accompanying drawings by way of example rather than limitation. It should be noted that references to "a" or "an" embodiment in this disclosure do not necessarily refer to the same embodiment, and they imply at least one embodiment. In the figures:

[0008] Figure 1 An example message exchange system according to one or more embodiments is illustrated;

[0009] Figures 2A-2C The illustration shows an example architecture of a computing entity according to one or more embodiments;

[0010] Figures 3A-3D A schematic diagram illustrating example cryptographic operations according to one or more embodiments is shown;

[0011] Figures 4A-4G A schematic diagram illustrating an example security element application according to one or more embodiments is shown;

[0012] Figure 5 This is a flowchart illustrating example operations related to encrypted communication between a computing entity according to one or more embodiments;

[0013] Figure 6A and Figure 6B This is a flowchart illustrating example operations related to generating encryption keys according to one or more embodiments; and

[0014] Figure 7 A block diagram illustrating a computer system according to one or more embodiments is shown. Detailed Implementation

[0015] In the following description, numerous specific details are set forth for purposes of explanation to provide a thorough understanding. Detailed examples are described below for clarity. One or more embodiments may be practiced without these specific details. The components and / or operations described below should be understood as a particular example that may not be applicable to some embodiments. Features described in one embodiment may be combined with features described in different embodiments. In some examples, well-known structures and devices are described with reference to block diagrams in order to avoid unnecessarily obscuring the invention. The components and / or operations described below should not be construed as limiting the scope of any of the claims.

[0016] 1. General Overview

[0017] 2. Example Message Exchange System

[0018] 3. Example Computational Entity Architecture

[0019] 4. Example Cryptographic Operations

[0020] 5. Example message encryption operation

[0021] 6. Example operations for generating encryption keys

[0022] 7. Computer Networks and Cloud Computing

[0023] 8. Microservice Applications

[0024] 9. Hardware Overview

[0025] 10. Miscellaneous; Extension

[0026] 1. General Overview

[0027] One or more embodiments utilize a secure element (SE) hardware processor to execute an encapsulation algorithm to generate a shared secret within the SE platform runtime environment. The shared secret is used to encrypt messages transmitted between computing entities. In one example, a cryptographic module is initiated within the SE platform runtime environment, and a group of one or more SE applications (or applets) are selected and executed to perform a set of cryptographic operations within the SE platform runtime environment.

[0028] In one example, the set of cryptographic operations may include operations associated with the KEM key algorithm. In addition to KEM operations, the set of cryptographic operations may include operations associated with the KA algorithm. In one example, the KEM shared secret and the KA shared secret can be combined according to a combination function and combination parameters to generate a combined shared secret. The combined shared secret can be used to encrypt messages transmitted between computational entities. The encapsulation algorithms utilized in the cryptographic operations may include conventional cryptographic algorithms, quantum-resistant cryptographic algorithms, or combinations thereof. A combination of conventional cryptographic algorithms and quantum-resistant cryptographic algorithms can be used to generate combined shared secrets that benefit from both the long-standing robustness of conventional cryptographic algorithms and the enhanced post-quantum security of quantum-resistant cryptographic algorithms.

[0029] In one example, the specific algorithm used in a cryptographic operation can be selected via one or more cryptographic modules. These one or more cryptographic modules can be provided through an application programming interface (API). An SE application object can be initiated within the SE platform runtime environment, and the SE application object can access and execute one or more cryptographic modules. Additionally, or alternatively, the SE application object can cause one or more cryptographic modules to execute within a logically secure element (LSE) of the SE platform runtime environment. Further, one or more cryptographic modules can be incorporated into one or more SE applications (or applets) located within a specific LSE, and these one or more cryptographic modules can be executed separately by the corresponding SE applications within the specific LSE to perform the corresponding cryptographic operations.

[0030] In one example, various SE applications are executed within a specific LSE of the SE platform runtime environment. A specific LSE can be used to execute one or more objects of an SE application. In this way, cryptographic operations are securely contained within a specific LSE. Additionally, or alternatively, separate LSEs can be used to execute separate SE applications, thereby isolating specific cryptographic operations within their respective LSEs. Advantageously, the algorithms and parameters associated with the cryptographic operations are securely kept within the SE platform runtime environment. Furthermore, if an SE application, its algorithm, or its parameters are vulnerable or compromised, the execution of various SE applications within separate LSEs provides an assurance that any resulting security exposure will be confined to the specific LSE where the vulnerability or compromise is located. Therefore, other SE applications, their algorithms, and parameters can remain securely contained within their respective LSEs.

[0031] This general overview section is intended to provide a general overview and does not represent all aspects of this disclosure. The full scope of the subject matter of this disclosure should be understood holistically from the entirety of this disclosure.

[0032] 2. Example of a message exchange system

[0033] For reference Figure 1 This describes an example message exchange system 100. The message exchange system 100 may include multiple computing entities 102, such as computing entity 102a, computing entity 102b, computing entity 102c, and computing entity 102n. One or more computing entities 102a-n may include a security module 104. The security module can be used to exchange encrypted messages between computing entities 102. The security module 104 may include an SE hardware component. The SE hardware component may be as described in reference... Figures 2A-2C The configuration is described below.

[0034] Multiple computing entities 102 can be configured to exchange encrypted messages via wired or wireless connections. In one example, the multiple computing entities 102 can be configured to connect to one or more data communication networks 106. The one or more data communication networks 106 may include a wireless network 108 and / or a wired network 110.

[0035] Example data communication networks include Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), General Packet Radio Service (GPRS), Broadband Global Area Network (BGAN), Wireless Local Area Network (WLAN), Personal Area Network (PAN), Local Area Network (LAN), Metropolitan Area Network (MAN), Wide Area Network (WAN), Internet of Things (IoT) network, satellite network, cloud computing network, or Ethernet. Example PAN networks may include ultra-wideband networks, Bluetooth networks, Zigbee networks, and near-field communication networks. Example LAN networks may include Wi-Fi networks or WLAN networks. Example MAN networks may include Global Microwave Access Interoperability (WiMAX) networks. Example WAN networks may include cellular networks (e.g., 2G, 3G, 4G, or 5G mobile networks). Example IoT networks may include ultra-wideband networks, Matter networks, Zigbee networks, LoRa networks, or Sigfox networks.

[0036] Computing entity 102 can be different devices or different components of a specific device. Computing entity 102 can each include one or more digital devices. The term "digital device" generally refers to any hardware device that includes a processor. A digital device can refer to a physical device that executes an application or virtual machine. Examples of digital devices include computers, tablets, laptops, desktops, netbooks, servers, web servers, network policy servers, proxy servers, general-purpose machines, function-specific hardware devices, hardware routers, hardware switches, hardware firewalls, hardware network address translation (NAT), hardware load balancers, mainframes, televisions, content receivers, set-top boxes, printers, mobile handheld terminals, smartphones, smart cards, personal digital assistants ("PDAs"), wireless receivers and / or transmitters, base stations, communication management devices, routers, switches, controllers, access points, and / or browser devices. In one example, system 100 may include one or more computing entities 102 as smart cards, and one or more computing entities 102 as smart card readers. For example, computing entity 102a and / or computing entity 102b may be smart cards, and computing entity 102n may be a smart card reader.

[0037] In one example, system 100 may include a host device and a client device. The host device and / or client device may include, as referenced... Figure 1 The configuration describes computing entity 102. Client devices may include computing entity 102 configured as a smart card (such as an EMV card or a Universal Integrated Circuit Card (UICC)). A UICC is a smart card conforming to the specifications defined by the European Telecommunications Standards Institute (ETSI) Smart Card Platform Project. A Subscriber Identity Module (SIM) card is an example of a UICC. Host devices may include computing devices such as computing entity 102 that communicate with client devices. The host device may be a payment device, and the client device may be a payment device such as a payment card.

[0038] In one example, the client device can communicate with the host device via a contactless communication protocol, such as a near-field communication protocol. Additionally, or alternatively, the host device may include a slot configured to receive the client device. For example, a client device configured as a payment card can be inserted into a slot in the host device to communicatively couple the client device to the host device. As another example, the client device can be configured as a SIM card that can be inserted into a slot in the host device. In yet another example, the client device can be configured as an embedded SE or an eSIM card wired to the host device. In yet another example, the client device can be integrated into the host device. As a further example, the client device can be configured as at least one of the following: a payment card, an access control card, an ID card, an electronic passport, a security identification card, a health insurance card, a transportation card, a secure USB token, an IoT device, or a mobile communication device.

[0039] 3. Example Computational Entity Architecture

[0040] Now for reference Figures 2A-2C This describes the architecture of example computational entity 200. In one example, refer to... Figure 1 A and Figure 1 The system 100 described in B may include, as referenced Figures 2A-2C Describes one or more compute entities in the configuration. Depending on the specific architecture, compute entities may include more than Figures 2A-2C The diagram shows more or fewer components.

[0041] like Figure 2AThe system architecture of computing entity 200 shown includes SE hardware 202 and device host hardware 204. SE hardware 202 may include an SE processor 206 and multiple LSEs 208, such as LSE 208a and LSE 208n. SE hardware 202 may further include an SE software stack 210 and SE memory 212. Device host hardware 204 may include an SE interface 214, a modem 216, a near-field communication (NFC) controller 218, host memory 220, and a host processor 222. Device host hardware 204 can run host application 224.

[0042] In some embodiments, SE hardware 202 may include a microprocessor-based chip that may include hardware components for protecting secure data from unauthorized access and for running secure applications. SE hardware 202 may include a smart card, such as a UICC (e.g., a SIM card). Additionally, or alternatively, SE hardware 202 may include a tamper-proof security chip and other types of integrated circuit cards (ICCs) for controlling access to secure resources.

[0043] In some embodiments, SE hardware 202 may represent at least a portion of an SE platform. For example, an SE platform may include SE hardware 202 and at least one additional hardware component. An example SE platform is the Java Card platform. An SE platform, such as the Java Card platform, refers to an ecosystem or framework that enables the development, personalization, and / or execution of SE applications. An SE platform may include SE hardware 202, SE software stack 210, and other components for deploying SE applications.

[0044] In some embodiments, the SE processor 206 is a microprocessor for executing the SE platform runtime environment and SE applications. An example SE platform runtime environment is the Java Card Runtime Environment (JCRE). The JCRE provides a lightweight version of the Java Runtime Environment (JRE) tailored for smart cards and other tamper-proof security chips to allow these SE hardware platforms to host SE applications, such as those using Java technology. The SE processor and / or JCRE may represent part of the SE platform. The JCRE may execute SE applications, for example, on the SE processor 206 and / or one or more LSEs 208. The JCRE can provide an execution environment for SE applications. The JCRE can perform operations associated with SE applications, including, for example, loading and unloading SE applications, scheduling SE application execution, isolating and securing SE applications, managing SE application memory, and / or interacting between SE applications and underlying hardware.

[0045] The SE platform runtime environment can be executed on at least one SE processor 206. The SE platform runtime environment may include instructions that, when executed by at least one SE processor 206, cause a set of cryptographic operations to be performed. The cryptographic operations may include operations associated with generating a shared secret and / or encryption key for encrypted communication between computational entity 200 and another computational entity. The cryptographic operations can be performed by executing one or more SE applications within the SE platform runtime environment.

[0046] The SE applications hosted within the JCRE can be referred to as applets, or Java Card applets. The JCRE may include firewall mechanisms 225 to isolate different applets on the smart card and sharing mechanisms that allow applets to explicitly make objects available to other applets. The JCRE may further include a Java Card Virtual Machine (JCVM) that runs bytecode generated using a different encoding scheme than the full JRE. Typically, the JCRE's encoding scheme reduces the application's memory footprint to optimize the application for execution by the SE hardware 202, which typically has more constraints than the host hardware 204. For example, the SE memory 212 may be much smaller than the host memory 220, and the SE processor 206 may be much slower than the host processor 222. Furthermore, the native instruction set architecture (ISA) of the SE processor 206 may be smaller than or otherwise different from the ISA of the host processor 222. One optimization technique to address these constraints is to divide the application's code into packages below a size threshold, and packages constructed using programming languages ​​that restrict the environment. While some of the examples described herein are related to JCRE, the embodiments described herein can also be implemented by other runtime environments that run on smart cards and other tamper-proof chips.

[0047] SE hardware 202 operates multiple LSEs 208a-n, which, from the perspective of a mobile device user, can operate as if multiple security element chips were installed within computing entity 200. For example, LSEs 208a-n can operate as if multiple embedded and / or removable SIM cards are currently operating within computing entity 200. Therefore, LSEs 208a-n can correspond to virtual SIM cards and / or other tamper-proof chips that share the same SE hardware components and run from them. SE hardware 202 and / or the firmware running therein can enforce isolation between different LSEs to prevent one LSE from accessing applets and code in another LSE. The isolation mechanism can be separate from or different from the previously mentioned JCRE firewall mechanism 225. Firewall mechanism 225 can be applied to a given LSE to maintain separation between different applets installed on the same LSE. The isolation mechanism can be implemented at a lower level to maintain isolation between different LSEs, each of which can be configured with its own firewall 225.

[0048] The SE software stack (SESS) 210 may include a set of components for executing SE applications. SESS 210 may include code (referred to herein as SESS code) that executes applets and provides a runtime environment for them. In some embodiments, SESS 210 may include protocol handler firmware 226, access control module 228, and JavaCard API (JCAPI) 230. Additionally, or alternatively, SESS 210 may include other components, such as JCVM, other APIs, and / or other components for hosting Java Card applications. JCAPI may include a set of software libraries, classes, and / or methods provided by the SE platform. SE applications can use JCAPI to interact with the underlying components of SE hardware 202 to perform various functions. In some embodiments, SESS code differs from the code for applets and LSE applications. SESS code provides the program and runtime environment for executing LSE application code. For example, SESS code may provide a virtual machine for running LSE applets. Additionally, or alternatively, the SESS code can manage access to SE hardware components, such as cryptographic accelerators and memory segments, and / or perform memory management operations, including allocating runtime memory for applets running within the currently running runtime environment. The SESS code may be public for LSE 208a-n to optimize for size and reduce processing overhead.

[0049] In some embodiments, protocol handler firmware 226 is a low-level firmware used by SESS code to manage operation for LSE 208a-n. In the case of a Java Card-based Security Element, protocol handler firmware 226 may be part of the JCRE. However, depending on the specific implementation, the firmware may be integrated into other runtime environments or integrated independently.

[0050] In some embodiments, protocol handler firmware 226 manages the routing of messages received from device host hardware 204 to a target LSE. While routing messages, protocol handler firmware 226 may trigger a handover operation to change the LSE currently active and running on SE hardware 202.

[0051] Access control module 228 provides authentication to prevent unauthorized entities from triggering changes between LSEs and / or other operations that access LSE data. Depending on the specific implementation, access control module 228 may be a component of protocol handler firmware 226 or a separate component. If a message is not successfully verified as originating from an entity authorized to trigger the requested operation, access control module 228 may block the requested operation.

[0052] SE memory 212 may include one or more types of volatile and / or non-volatile storage devices, such as read-only memory (ROM) 232, random access memory (RAM) 234, non-volatile memory (NVM) 236, and one-time programmable (OTP) memory 238. SE memory 212 may store data in an encrypted format. As further described below, encryption schemes (such as encryption algorithms and / or key locations) vary between different LSEs to provide data integrity and isolation. In some embodiments, SE memory 212 securely stores data for LSEs 208a-n.

[0053] In some embodiments, switching commands and other messages originate from device host hardware 204. For example, messages may be received wirelessly via modem 216 and / or NFC controller 218. Messages may be routed to SE hardware 202 via SE interface 214. SE interface 214 may convert wirelessly received messages into a format that can be consumed by protocol handler firmware 226. Additionally, or alternatively, SE interface may include a bus or other communication system for transferring messages from device host hardware 204 to SE hardware 202.

[0054] In some embodiments, modem 216 is a mobile broadband modem for sending and receiving messages via a mobile broadband connection. For example, a carrier (including mobile network operators (MNOs) and mobile virtual network operators (MVNOs)) can wirelessly send network messages to a mobile phone via a cellular network through modem 216. Different LSEs can be targeted based on which mobile phone operator the message is sent to. SE hardware 202 can support multiple virtual SIM cards from different mobile phone operators. Additionally, or alternatively, other messages wirelessly received via modem 216 can be targeted to different types of LSEs. Example LSE applications include payment processing, biometric authentication, identity management, and mobile network communications.

[0055] In some embodiments, the NFC controller 218 receives near-field wireless messages from an external device. When within a threshold distance, NFC communication can transmit data via inductive coupling between the antenna in the NFC controller 218 and the external device. NFC messages can trigger operations in the LSE. For example, a payment terminal can generate NFC messages to retrieve credit card information and / or other data during a transaction. The target LSE can securely store the mobile device user's financial information and includes one or more applets for processing secure transactions initiated through the payment terminal. NFC messages can trigger other operations, which may vary depending on the type of LSE application and the SSP associated with the application.

[0056] Additionally, or alternatively, the device host hardware 204 may include other components for receiving messages via a wired or wireless interface. For example, the device host hardware 204 may include a Bluetooth module, a Zigbee chip, a Wi-Fi card, an infrared receiver, a Universal Serial Bus (USB) controller, and / or a serial communication interface. Messages received through such hardware components can be used as external triggers to initiate switching between LSEs 208a-n and to access resources that have been mapped to the LSE.

[0057] The host hardware 204 may further include host memory 220 and host processor 222 for executing host applications 224. For example, a smartphone may include a mobile processor and RAM for executing a mobile operating system and mobile phone applications. The processor 222 and host memory 220 may be physically separated from the SE hardware 202 to protect against attacks should the security of computing entity 200 be compromised. The SE hardware 202 may prevent the processor 222 from accessing secure data stored in the SE memory 212. Requests to access data may be routed via protocol handler firmware 226.

[0058] In other embodiments, the device host hardware 204 may include additional or fewer components. For example, some devices (such as smart credit cards and company badges) may not include a mobile processor, CPU, or memory external to the secure element. These devices may not execute applications other than applets hosted by the SE hardware 202. Therefore, the architecture of the device host hardware 204 can vary depending on the specific type of device in which the SE hardware 202 is integrated.

[0059] Now for reference Figure 2B This further describes an example configuration of SE hardware 202. For example... Figure 2B As shown, the SE hardware may include an SE processor 206 capable of executing JCRE 240 and JCVM 242. JCRE 240 and / or JCVM 242 may be implemented as firmware. JCRE 240 and JCVM 242 may work together to provide a secure and controlled environment for executing SE applications. JCRE 240 may interact with the underlying components of the SE hardware 202 to manage the execution of SE applications. JCRE 240 may provide features supporting the execution of SE applications, including memory management, security mechanisms, loading and unloading of SE applications, and / or scheduling of SE application execution. JCVM 242 may execute the bytecode instructions of the SE applications.

[0060] like Figure 2B As further shown, SE hardware 202 may include SE software stack 210, which includes a cryptographic API 248. Cryptographic API 248 may include a set of cryptographic modules 250, which one or more SE applications can use to perform cryptographic operations. Various parameters utilized by the cryptographic modules 250 can be configured, for example, based on one or more user inputs and / or based on a selected operating mode. One or more cryptographic modules of cryptographic API 248 can be executed by SE applications within JCRE 240 and / or LSE 208. Figure 2A and Figure 2C In one example, a set of cryptographic operations can be performed by executing one or more SE applications within JCRE 240. For example... Figure 2BAs shown, cryptographic API 248 can initialize SE application object 252 within JCRE 240. SE application object 252 can include an SE application configured to execute one or more cryptographic modules 250 within JCRE 240. SE application object 252 can import one or more cryptographic modules from cryptographic API 248 to access and execute one or more cryptographic modules from cryptographic modules 250 within JCRE 240. Additionally, or alternatively, a set of cryptographic operations can be performed by executing one or more SE applications within a specific LSE 208. In one example, SE application object 252 can instruct a specific SE application within a specific LSE 208 to import one or more cryptographic modules 250 to execute that one or more cryptographic modules 250 within that specific LSE 208. SE application object 252 can access, and one or more cryptographic modules of cryptographic API 248 can be executed by an SE application (such as within LSE 208), as referenced. Figure 2C As described.

[0061] like Figure 2B As shown, in one example, one or more cryptographic modules 250 may include at least one of the following: a shared secret generation module 254, a KA module 256, a KEM module 258, or a combination function module 260. The shared secret generation module 254 may generate a shared secret by executing one or more cryptographic algorithms. In one example, the shared secret generated by the shared secret generation module 254 may be used as an encryption key. Additionally, or alternatively, the shared secret generation module 254 may generate an encryption key that includes or is based on the shared secret.

[0062] In one example, the cryptographic algorithms executed by the shared secret generation module 254 may include one or more KA algorithms and / or one or more KEM algorithms. Additionally, or alternatively, the cryptographic algorithms may include one or more hybrid algorithms. Hybrid algorithms may include combinations of one or more KA algorithms and / or one or more KEM algorithms. A particular cryptographic algorithm may be selected from a set of cryptographic algorithms, such as a set of KA algorithms and / or a set of KEM algorithms. One or more cryptographic algorithms may be incorporated into the shared secret generation module 254. Additionally, or alternatively, one or more cryptographic algorithms may be incorporated into an additional cryptographic module 250 that can be accessed and utilized by the SE application object 252. In one example, multiple cryptographic operations may be incorporated into the shared secret generation module 254 and executed by the SE application object 252. Additionally, or alternatively, the SE application object 252 may cause multiple different cryptographic operations to be executed by separate applets within different LSEs 208.

[0063] In one example, one or more cryptographic modules 250 may include a KA module 256. The KA module 256 can generate a KA shared secret by executing one or more KA algorithms. One or more KA algorithms can be incorporated into the KA module 256. Additionally, or alternatively, one or more KA algorithms can be incorporated into an additional cryptographic module 250, which can be accessed and utilized by an SE application object 252 (e.g., in relation to the KA module 256). In one example, one or more KA algorithms can be selected by the KA module 256 from a set of KA algorithms.

[0064] Additionally, or in an alternative to KA module 256, in one example, one or more cryptographic modules 250 may include KEM module 258. KEM module 258 can generate a KEM shared secret by executing one or more KEM algorithms. One or more KEM algorithms may be incorporated into KEM module 258. Additionally, or alternatively, one or more KEM algorithms may be incorporated into additional cryptographic modules 250 that can be accessed and utilized by SE application object 252 (e.g., in relation to KEM module 258). In one example, one or more KEM algorithms may be selected by KEM module 258 from a set of KEM algorithms.

[0065] In one example, multiple shared secrets can be combined to generate a combined shared secret. In one example, the KA shared secret and the KEM shared secret can be combined to generate a combined shared secret. One or more cryptographic modules 250 may include a combination function module 260. The combination function module 260 can execute one or more combination algorithms to generate a combined shared secret from multiple shared secrets. In one example, the combination function module 260 can generate a combined KA-KEM shared secret by executing one or more combination algorithms. The combination function module 260 can specify the order in which the shared secrets are combined. One or more combination algorithms can be incorporated into the combination function module 260. Additionally, or alternatively, one or more combination algorithms can be incorporated into additional cryptographic modules 250 that can be accessed and utilized by the SE application object 252 (e.g., in relation to the combination function module 260). In one example, one or more combination algorithms can be selected by the combination function module 260 from a set of combination algorithms. In one example, the combined shared secret generated by the combination function module 260 can be used as an encryption key. Additionally, or alternatively, the combination function module 260 can generate a combination of a shared secret or an encryption key based on a combined shared secret.

[0066] In one example, the combination function module 260 can use the KA shared secret and / or the KEM shared secret as input to the combination algorithm. The KA module 256 can generate the KA shared secret, and the combination function module 260 can use the KA shared secret as input to the combination algorithm. Additionally, or alternatively, the KEM module 258 can generate the KEM shared secret, and the combination function module 260 can use the KEM shared secret as input to the combination algorithm.

[0067] In one example, the combination function module 260 may include one or more KA algorithms and / or one or more KEM algorithms. For example, the combination function module 260 may reflect a combination of KA module 256, KEM module 258, and the combination algorithms. In one example, the KA shared secret, the KEM shared secret, and the combined shared secret may be generated by the SE application object 252 within JCRE 240. The combined shared secret may be provided as output from the SE application object 252. The KA shared secret and KEM shared secret used to generate the combined shared secret may be retained within JCRE 240. The KA shared secret and KEM shared secret may be discarded after the combined shared secret is generated.

[0068] In one example, cryptographic API 248 may include a buffer length module 262. Buffer length module 262 can determine the length of the encoded message and / or the length of the shared secret associated with a particular cryptographic algorithm. Buffer length module 262 can define a buffer length for a particular cryptographic operation based on the length of the shared secret and / or the length of the encoded message. Buffer length module 262 can dynamically adjust the buffer length size to suit a particular cryptographic operation. Additionally, or alternatively, buffer length module 262 can determine the buffer length to avoid buffer overflow. Additionally, or alternatively, buffer length module 262 can determine security vulnerabilities and / or data processing errors based on the proportion of the buffer used by a particular cryptographic operation. For example, when the proportion of the buffer used by a particular cryptographic operation meets an upper threshold buffer length, and / or when the proportion of the buffer used by a particular cryptographic operation is lower than a lower threshold buffer length, buffer length module 262 can determine that a security vulnerability and / or data processing error has occurred.

[0069] In one example, cryptographic API 248 may include a result checking module 264. Result checking module 264 may perform one or more result checking operations on the result of a particular cryptographic operation. In one example, the result checking operation may include determining that the result of a particular cryptographic operation has a length that meets one or more criteria. The one or more criteria may include at least one of the following: an upper length threshold, a lower length threshold, a length range, or a length value. When the result of a particular cryptographic operation fails to meet the one or more criteria, result checking module 264 may determine that a vulnerability and / or data processing error has occurred.

[0070] In one example, cryptographic API 248 may include a Temporary Entry Point Object (TEPO) module 266. The TEPO module can generate transient object handles. Transient object handles can be used as references or pointers to objects stored in transient memory. Transient object handles can provide temporary access and use of objects stored in non-persistent (or transient) memory. In one example, SE application object 252 can invoke TEPO module 266 to generate a transient object handle pointing to an object utilized by SE application object 252 in a cryptographic operation. TEPO module 266 can be used to avoid persistent memory writes of data associated with cryptographic operations. In one example, a transient object handle can point to the output of a first cryptographic operation used as input to a second cryptographic operation. In one example, a first transient object handle can point to a KA shared secret utilized by combination function module 260 (e.g., generated by KA module 256), and a second transient object handle can point to a KEM shared secret utilized by combination function module 260 (e.g., generated by KEM module 258). By using the TEPO module 266 to generate transient object handles, JCRE can ensure that it can read and manipulate objects in transient memory without writing any changes back to persistent memory. This avoids unnecessary writes to persistent memory, which improves the security of cryptographic operations.

[0071] In one example, cryptographic API 248 may include a Shared Interface Object (SIO) module 268. SIO module 268 may be executable to generate one or more SIOs that facilitate secure communication and interaction between different SE applications. The corresponding SE applications may be logically isolated (e.g., within LSE 208) to prevent unauthorized access to the corresponding data and / or functionality. SIOs provide a controlled mechanism for sharing data and functionality across SE applications without violating isolation protocols. Access to SIOs may be subject to access control mechanisms defined in the SE platform. Depending on the access control mechanisms, SE applications may be required to have appropriate permissions to access and use SIOs.

[0072] In one example, various parameters can be configured for use by one or more cryptographic modules in cryptographic module 250, including the selection of one or more specific algorithms to be utilized by one or more cryptographic modules in cryptographic module 250. In one example, the specific algorithm to be utilized by one or more cryptographic modules 250 can be determined based on the pattern of the operation passed to cryptographic API 248. Additionally, one or more private keys and one or more public keys to be utilized by cryptographic API 248 can be passed to cryptographic API 248 in a "raw" format (such as as a byte array), allowing the keys to be directly transferred to the operation performed by cryptographic API 248. Additionally, or alternatively, a random data generation object can be passed to cryptographic API 248. Additionally, or alternatively, a shared secret can be passed to cryptographic API 248. Additionally, or alternatively, a keywrapping algorithm can be passed to cryptographic API 248. Random data generation objects, key wrapping algorithms, or key wrapping algorithms can be passed to the Cryptographic API 248 either as JavaCard objects or in a "raw" format (such as as byte arrays). Additionally, or alternatively, multiple shared secrets for use by combination algorithms (e.g., to generate combined KA-KEM shared secrets) can be passed to the Cryptographic API 248. In one example, the Cryptographic API 248 may include functionality for adding one or more additional shared secrets.

[0073] Now for reference Figure 2C This further describes an example configuration of SE hardware 202. For example... Figure 2C As shown, and as referenced above Figure 2A As described, LSE 208a may include one or more SE applications for performing cryptographic operations. Cryptographic API 248 may be used to generate, configure, and / or select one or more cryptographic modules 250 for execution within a specific SE application. Additionally, or alternatively, an SE application may invoke cryptographic API 248 to access and execute one or more cryptographic modules 250. Additionally, or alternatively, one or more cryptographic modules 250 may be incorporated into one or more SE applications.

[0074] In one example, LSE 208a may include a shared secret generation applet 270. Shared secret generation applet 270 may access shared secret generation module 254 from cryptographic API 248. Shared secret generation applet 270 may execute shared secret generation module 254 within LSE 208a. Additionally, or alternatively, shared secret generation module 254 may be incorporated into shared secret generation applet 270. Further, LSE 208a may include shared secret data 272. Shared secret generation applet 270 may generate a shared secret by executing one or more cryptographic algorithms. Shared secret generation applet 270 may use shared secret data 272 as input to generate a shared secret. Additionally, or alternatively, the shared secret generated by shared secret generation applet 270 may be stored as shared secret data 272. In one example, the shared secret generated by shared secret generation applet 270 may be used as an encryption key. Additionally, or alternatively, shared secret generation applet 270 may generate an encryption key that includes or is based on the shared secret.

[0075] In one example, the cryptographic algorithms executed by the shared secret generation applet 270 may include one or more KA algorithms and / or one or more KEM algorithms. Additionally, or alternatively, the cryptographic algorithms may include one or more hybrid algorithms. Hybrid algorithms may include combinations of one or more KA algorithms and / or one or more KEM algorithms. A particular cryptographic algorithm may be selected from a set of cryptographic algorithms, such as a set of KA algorithms and / or a set of KEM algorithms. One or more cryptographic algorithms may be incorporated into the shared secret applet. Additionally, or alternatively, one or more cryptographic algorithms may be stored as shared secret data 272. In one example, multiple cryptographic algorithms may be incorporated into the shared secret generation applet 270 and / or shared secret data 272 and may be executed within LSE 208a. In one example, multiple cryptographic algorithms may be incorporated into different applets executed separately within different LSEs. The specific applet and / or specific cryptographic operation to be executed may be selected by the cryptographic module 250.

[0076] In one example, LSE 208a may additionally or alternatively include KA applet 274. KA applet 274 can access KA module 256 from cryptographic API 248. KA applet 274 can execute KA module 256 within LSE 208a. Additionally or alternatively, KA module 256 can be incorporated into KA applet 274. Further, LSE 208a may include KA data 276. KA applet 274 can generate a KA shared secret by executing one or more KA algorithms. KA applet 274 can generate a KA shared secret using KA data 276 as input. Additionally or alternatively, the KA shared secret generated by KA applet 274 can be stored as KA data 276. One or more KA algorithms can be incorporated into KA applet 274. Additionally or alternatively, one or more KA algorithms can be selected by KA applet 274 from a set of KA algorithms. This set of KA algorithms can, for example, be stored as KA data 276.

[0077] Additionally, or alternatively, in one example, LSE 208a may include KEM applet 278. KEM applet 278 may access KEM module 258 from cryptographic API 248. KEM applet 278 may execute KEM module 258 within LSE 208a. Additionally, or alternatively, KEM module 258 may be incorporated into KEM applet 278. Further, LSE 208a may include KEM data 280. KEM applet 278 may generate a KEM shared secret by executing one or more KEM algorithms. KEM applet 278 may use KEM data 280 as input to generate the KEM shared secret. Additionally, or alternatively, the KEM shared secret generated by KEM applet 274 may be stored as KEM data 280. One or more KEM algorithms may be incorporated into KEM applet 278. Additionally, or alternatively, one or more KEM algorithms may be selected by KEM applet 278 from a set of KEM algorithms. This set of KEM algorithms can be stored, for example, as KEM data 280.

[0078] In one example, multiple shared secrets can be combined to generate a combined shared secret. In one example, the KA shared secret and the KEM shared secret can be combined to generate a combined shared secret. LSE 208a can generate the combined shared secret. LSE 208a may include a combination function applet 282. Combination function applet 282 can access combination function module 260 from cryptographic API 248. Combination function applet 282 can execute combination function module 260 within LSE 208a. Additionally, or alternatively, combination function module 260 may be incorporated into combination function applet 282. Further, LSE 208a may include combination function data 284. Combination function applet 282 can generate the combined KA-KEM shared secret by executing one or more combination algorithms. Combination function applet 282 can use combination function data 284 as input to generate the combined KA-KEM shared secret. Additionally, or alternatively, the combined KA-KEM shared secret generated by the combination function applet 282 can be stored as combination function data 284. One or more combination algorithms can be incorporated into the combination function applet 282. Additionally, or alternatively, one or more combination algorithms can be selected by the combination function applet 282 from a set of combination algorithms. This set of combination algorithms can, for example, be stored as combination function data 284. In one example, the combined shared secret generated by the combination function applet 282 can be used as an encryption key. Additionally, or alternatively, the combination function applet 282 can generate an encryption key that includes the combined shared secret or is based on the combined shared secret.

[0079] In one example, the combination function applet 282 can use the KA shared secret and / or the KEM shared secret as input to the combination algorithm. The KA applet 274 can generate the KA shared secret, and the combination function applet 282 can use the KA shared secret as input to the combination algorithm. Additionally, or alternatively, the KEM applet 278 can generate the KEM shared secret, and the combination function applet 282 can use the KEM shared secret as input to the combination algorithm.

[0080] In one example, the combination function applet 282 may include one or more KA algorithms and / or one or more KEM algorithms executed within LSE 208a. For example, combination function applet 282 may reflect a combination of KA applet 274, KEM applet 278, and the combination algorithm. In one example, the KA shared secret, KEM shared secret, and combined shared secret may be generated within LSE 208a. The combined shared secret may be provided as output from LSE 208a. The KA shared secret and KEM shared secret used to generate the combined shared secret may be retained within LSE 208a. The KA shared secret and KEM shared secret may be stored as combination function data 284, and / or may be discarded after the generation of the combined shared secret.

[0081] In one example, SE hardware 202 may include one or more SIOs 286. These one or more SIOs may be generated by SIO module 268. In one example, combination function applet 282 may use SIO 286a instruction KA applet 274 to generate a KA shared secret and / or obtain a KA shared secret from KA applet 274. Additionally, or alternatively, combination function applet 282 may use SIO 286n instruction KEM applet 278 to generate a KEM shared secret and / or obtain a KEM shared secret from KEM applet 278.

[0082] Further reference Figures 2A-2C In one example, the SE hardware 202 can be configured to provide domain separation to prevent unintended interactions or interference. Domain-separated data can be input via cryptographic API 248. Domain-separated data may include protocol information. Additionally, or alternatively, domain-separated data may include a pre-shared key. Protocol information may include header information or specific fields within packets indicating the specific protocol being used. The pre-shared key can be used for different separated domains. In one example, multiple computational entities may use different pre-shared keys to interact with the SE hardware for each interaction or for each different computational entity. The use of different pre-shared keys helps ensure that data associated with a specific computational entity and data associated with other computational entities remain separate and secure. Therefore, the SE hardware 202 can properly route, process, and protect data within its intended domain without interference or disruption from other domains.

[0083] 4. Example cryptographic operations and algorithms

[0084] Now for reference Figures 3A-3DThe example cryptographic operation 300 is further described. Example cryptographic operation 300 can be performed using one or more cryptographic algorithms. In one example, cryptographic operation 300 may include selecting one or more cryptographic algorithms from a set of cryptographic algorithms.

[0085] A. Example of cryptographic operations.

[0086] refer to Figures 3A-3D The described cryptographic operations 300 can be found in the reference. Figure 1 One or more components of the system 100 described and / or by reference Figures 2A-2C The computational entity 200 described is executed by one or more components. For example, cryptographic operation 300 can be executed in the SE platform runtime environment and / or in one or more LSEs within the SE platform runtime environment, for example, by utilizing a reference. Figures 2A-2C One or more cryptographic modules 250 are described. (Reference) Figures 3A-3D One or more cryptographic operations 300 described may be modified, rearranged, or omitted together. Therefore, refer to Figures 3A-3D The specific sequence of operations described should not be construed as limiting the scope of one or more embodiments. Figures 3A-3D As shown, cryptographic operation 300 is described with reference to computational entity A (CE-A) 302 and computational entity B (CE-B) 304. In one example, cryptographic operation 300 described with reference to CE-A 302 and CE-B 304 can be reversed.

[0087] refer to Figure 3A This describes 300 example cryptographic operations related to the KA algorithm. Figure 3A As shown, CE-A302 can generate a public-private key pair "A" (operation 306). The public-private key pair "A" may include a public key "A" and a private key "A". CE-A 302 can transmit the public key "A" to CE-B 304 (operation 308). Simultaneously, CE-B 304 can generate a public-private key pair "B" (operation 310). The public-private key pair "B" may include a public key "B" and a private key "B". CE-A 304 can transmit the public key "B" to CE-A 302 (operation 312). The public-private key pair "A" can be a long-term or static key pair used for extended periods or for multiple cryptographic operations 300. Alternatively, the public-private key pair "A" can be a temporary key pair used for short periods or for a single cryptographic operation 300. Additionally, or alternatively, the public-private key pair "B" can be a static key pair used for extended periods or for multiple cryptographic operations 300. Alternatively, the public-private key pair "B" can be a temporary key pair used for a short period of time or for a single cryptographic operation 300.

[0088] CE-A 302 can combine the private key "A" and the public key "B" to generate the KA shared secret (operation 316). Simultaneously, CE-B 304 can combine the private key "B" and the public key "A" to generate the KA shared secret (operation 320). CE-A 302 and CE-B 304 can use the KA shared secret to participate in secure communication (operation 322). The KA shared secret can be used as an encryption key to encrypt messages transmitted between CE-A 302 and CE-B 304. Additionally, or alternatively, CE-A 302 and CE-B 304 can generate an encryption key that includes or is based on the KA shared secret.

[0089] refer to Figure 3B This describes 300 example cryptographic operations related to the KEM algorithm. Figure 3B As shown, CE-A302 can generate a public-private key pair "C" (operation 330). The public-private key pair "C" may include a public key "C" and a private key "C". CE-A 302 can transmit the public key "C" to CE-B 304 (operation 332). CE-B 304 can generate a KEM shared secret (operation 334), and CE-B 304 can use the public key "C" to encapsulate the KEM shared secret to generate ciphertext (operation 336). CE-B 304 can transmit the ciphertext to CE-A 302 (operation 338). CE-A 302 can use the private key "C" to decapsulate the ciphertext to obtain the KEM shared secret (operation 340). CE-A 302 and CE-B 304 can use the KEM shared secret to participate in secure communication (operation 342). The KEM shared secret can be used as an encryption key to encrypt messages transmitted between CE-A 302 and CE-B 304. Additionally, or alternatively, CE-A 302 and CE-B 304 may generate encryption keys that include or are based on the KEM shared secret.

[0090] refer to Figure 3C-1 and Figure 3C-2 300 example cryptographic operations related to the hybrid KA-KEM algorithm are described.

[0091] like Figure 3C-1As shown, CE-A 302 can generate a public-private key pair "A1" (operation 350). The public-private key pair "A1" can include a public key "A1" and a private key "A1". CE-A 302 can transmit the public key "A1" to CE-B 304 (operation 352). Additionally, CE-A 302 can generate a public-private key pair "A2" (operation 354). The public-private key pair "A2" can include a public key "A2" and a private key "A2". CE-A 302 can transmit the public key "A2" to CE-B 304 (operation 356). Simultaneously, CE-B 304 can generate a public-private key pair "B" (operation 358). The public-private key pair "B" can include a public key "B" and a private key "B". CE-A 304 can transmit the public key "B" to CE-A 302 (operation 360).

[0092] CE-A 302 can combine the private key "A" and the public key "B" to generate a shared secret "1" (e.g., the KA shared secret) (operation 364). Simultaneously, CE-B 304 can combine the private key "B" and the public key "A1" to generate a shared secret "1" (e.g., the KA shared secret) (operation 368).

[0093] continue Figure 3C-2 CE-B 304 can generate shared secret "2" (e.g., KEM shared secret) (operation 370), and CE-B 304 can encapsulate shared secret "2" using public key "A2" to generate ciphertext (operation 372). CE-B 304 can transmit the ciphertext to CE-A 302 (operation 374). CE-A 302 can decapsulate the ciphertext using private key "A2" to obtain shared secret "2" (operation 376). CE-A 302 can perform a combination function using shared secret "1" (e.g., KA shared secret), shared secret "2" (e.g., KEM shared secret) and combination parameters to generate a combined shared secret (operation 378). Simultaneously, CE-A 304 can perform a combination function using shared secret "1" (e.g., KA shared secret), shared secret "2" (e.g., KEM shared secret) and combination parameters to generate a combined shared secret (operation 380). CE-A 302 and CE-B 304 may use a combined shared secret to participate in secure communication (Operation 382). The combined shared secret can be used as an encryption key to encrypt messages transmitted between CE-A 302 and CE-B 304. Additionally, or alternatively, CE-A 302 and CE-B 304 may generate an encryption key that includes or is based on the combined shared secret.

[0094] refer to Figure 3DThis describes an example cryptographic operation 300 involving the use of an encryption key to encrypt and / or decrypt data. In one example, CE-A 302 may use an encryption algorithm to encrypt data “A” (using the encryption key as input to the encryption algorithm) to generate an encrypted message “A” (operation 388). The encryption key may be, may include, or may be based on at least one of the following: a combined shared secret, a KA shared secret, or a KEM shared secret. CE-A 302 may transmit the encrypted message “A” to CE-B 304 (operation 390). CE-B 304 may use a decryption algorithm to decrypt the encrypted message “A” (using the encryption key as input to the decryption algorithm) to obtain data “A” (operation 392). Additionally, or alternatively, CE-B 304 may use an encryption algorithm to encrypt data “B” (using the encryption key as input to the encryption algorithm) to generate an encrypted message “B” (operation 394). As previously stated, the encryption key may include or may be based on at least one of the following: a combined shared secret, a KA shared secret, or a KEM shared secret. CE-B 304 can transmit the encrypted message "B" to CE-A 302 (operation 396). CE-A 302 can use a decryption algorithm to decrypt the encrypted message "B" (using the encryption key as input to the decryption algorithm) to obtain the data "B" (operation 392).

[0095] B. Example Cryptographic Algorithms

[0096] Cryptographic operation 300 can be performed using one or more cryptographic algorithms. The one or more cryptographic algorithms utilized in cryptographic operation 300 may include one or more quantum-resistant cryptographic algorithms, one or more conventional cryptographic algorithms, or a combination thereof.

[0097] As used in this article, when used in conjunction with cryptographic algorithms, the term "quantum-resistant" or "post-quantum" refers to a cryptographic algorithm designed to resist attacks by quantum computing devices or systems.

[0098] Examples of quantum-resistant cryptographic algorithms include: lattice-based cryptographic algorithms (e.g., Kyber's algorithm, CRYSTALS algorithm, NTRUEncrypt algorithm, fault-tolerant learning (LWE) algorithm), code-based cryptographic algorithms (e.g., McEliece algorithm, Niederreiter cryptosystem algorithm), multivariate polynomial cryptographic algorithms (e.g., Rainbow algorithm), quantum-resistant hash-based cryptographic algorithms (e.g., Extended Merkel Signature Scheme (XDMSS) algorithm, Stateful Hash-Based Signature (SPHINCS) algorithm), and homology-based cryptographic algorithms or cryptographic primitive algorithms (e.g., Round5 algorithm).

[0099] As used herein, when used in conjunction with cryptographic algorithms, the term "traditional" refers to a cryptographic algorithm that is not specifically designed to resist attacks by quantum computing devices or systems. Traditional cryptographic algorithms can include algorithms that have been used for extended periods of time. For example, even if a particular traditional cryptographic algorithm may have known limitations against vulnerabilities in the context of threats from quantum computing systems, that particular traditional algorithm may still be suitable for some cryptographic operations.

[0100] Examples of traditional cryptographic algorithms include: Data Encryption Standard (DES), RSA (Rivest-Shamir-Adleman), Elliptic Curve Cryptography (ECC), Diffie-Hellman (DH), Edwards Curve Digital Signature Algorithm (EdDSA), Triple DES (3DES), Advanced Encryption Standard (AES), Digital Signature Algorithm (DSA), traditional hash function algorithms (e.g., MD5, SHA-1, SHA-2 (e.g., SHA-256 or SHA-512), and SHA-3), and stream cipher algorithms. Traditional hash function algorithms can be configured as concatenated or cascading hash functions.

[0101] In one example, the cryptographic algorithm may include a KA algorithm. Example KA algorithms include one or more cryptographic algorithms mentioned above, such as one or more conventional cryptographic algorithms mentioned above and / or one or more quantum-resistant cryptographic algorithms. In one example, the KA algorithm may include a conventional KA algorithm, such as: the DH algorithm, the Elliptic Curve Diffie-Hellman (ECDH) algorithm (e.g., the X25519 elliptic curve algorithm, the X488 elliptic curve algorithm), or the RSA algorithm. In one example, the KA algorithm may include a quantum-resistant cryptographic algorithm, such as: the supersingular isongeny Diffie-Hellman (SIDH) algorithm.

[0102] In one example, the cryptographic algorithm may include the KEM algorithm. The example KEM algorithm may include one or more of the quantum-resistant cryptographic algorithms mentioned above. In one example, the KEM algorithm may include quantum-resistant cryptographic algorithms such as: lattice-based cryptography, code-based cryptography, multivariate polynomial cryptography, quantum-resistant hash-based cryptography, homology-based cryptography, or cryptographic primitive algorithms.

[0103] In one example, the cryptographic algorithm may include a hybrid algorithm. An example hybrid algorithm may include the KA algorithm and the KEM algorithm. The KA and KEM algorithms can be combined using a combinatorial algorithm. The KA algorithm may include a conventional cryptographic algorithm or a quantum-resistant cryptographic algorithm. The KEM algorithm may include a quantum-resistant cryptographic algorithm.

[0104] 5. Example application of secure elements

[0105] Now for reference Figures 4A-4G The example cryptography module 400 is further described. (See references.) Figures 4A-4G The described cryptographic module 400 may be included in the reference Figures 2A-2C The described set of cryptographic modules is in 250. Additionally, or alternatively, see reference [link to reference]. Figures 4A-4G The described cryptographic module 400 can be incorporated into the reference. Figures 2A-2C In one or more SE applications or applets as described. (Reference) Figures 4A-4G The described cryptographic module 400 can be used in SE runtime environments (such as references) Figures 2A-2C This is described in JCRE 240. In one example, the system may include multiple cryptographic modules 400. One or more cryptographic operations can be performed by executing one or more cryptographic modules 400 within the SE platform runtime environment. In one example, a specific cryptographic module 400 may be executed and / or incorporated into a specific LSE. A set of cryptographic operations can be performed by executing a specific cryptographic module 400. Additionally, or alternatively, each specific cryptographic operation may also be performed by a separate cryptographic module 400. A cryptographic module 400 may include one or more submodules. Each submodule may perform a cryptographic operation, a portion of a cryptographic operation, and / or other operations related to the cryptographic operation. Cryptographic API 248 can be used to generate, configure, and / or select one or more cryptographic modules among the cryptographic modules 400 for use, for example, within JCRE 240 (…). Figure 2B ) and / or one or more LSE 208a-n ( Figure 2C ) is executed.

[0106] A. Example key pair module.

[0107] like Figure 4AAs shown, cryptographic module 400 may include key pairing module 402. Key pairing module 402 can generate key pairs for use in cryptographic operations. Key pairing module 402 may include key pairing algorithm submodule 404 and key pair generation submodule 406. Key pairing algorithm submodule 404 may provide cryptographic algorithms to key pair generation submodule 406 for generating key pair 408. In one example, the cryptographic algorithm used to generate key pair 408 may be stored in key pairing algorithm submodule 404. Additionally, or alternatively, key pairing algorithm submodule 404 may select a cryptographic algorithm from a set of cryptographic algorithms for generating key pair 408. The cryptographic algorithm may be a quantum-resistant cryptographic algorithm or a conventional cryptographic algorithm. Key pair generation submodule 406 may use the cryptographic algorithm provided by key pairing algorithm submodule 404 to generate key pair 408. Key pair 408 may include public key 410 and private key 412.

[0108] The key pair module 402 may further include a key pair storage submodule 414 and / or a key transmission submodule 416. The key pair storage submodule 414 may store key pairs 408 for future reference, for example, by one or more cryptographic modules 400. For example, the key transmission submodule 416 may transmit the public key 410 and / or the private key 412 to another cryptographic module 400, or to another component of the computational entity being performed within the cryptographic module 400.

[0109] B. Example KA shared secret module.

[0110] like Figure 4B As shown, the cryptographic module 400 may include a KA shared secret module 420. The KA shared secret module 420 can generate a KA shared secret for use as an encryption key and / or for use in subsequent cryptographic operations. The KA shared secret module 420 may include a KA shared secret algorithm submodule 430 and a KA shared secret generation submodule 432. The KA shared secret algorithm submodule 430 can provide a cryptographic algorithm to the KA shared secret generation submodule 432 for generating a KA shared secret 434.

[0111] In one example, the cryptographic algorithm used to generate the KA shared secret 434 can be stored in the KA shared secret algorithm submodule 430. Additionally, or alternatively, the KA shared secret algorithm submodule 430 can select the cryptographic algorithm used to generate the KA shared secret 434 from a set of cryptographic algorithms. The cryptographic algorithm can be a quantum-resistant cryptographic algorithm or a conventional cryptographic algorithm. The KA shared secret generation submodule 432 can generate the KA shared secret 434 using the cryptographic algorithm provided by the KA shared secret algorithm submodule 430, the private key 412 corresponding to the first computational entity, and the public key 410 corresponding to the second computational entity. The private key 412 used by the KA shared secret algorithm submodule 430 can be obtained from the key pair module 402 corresponding to the first computational entity (…). Figure 4A ) is provided. In one example, the key transfer submodule 416 ( Figure 4A The private key 412 can be transmitted to the KA shared secret module 420, such as to the KA shared secret generation submodule 432. The public key 410 used by the KA shared secret algorithm submodule 430 can be provided by the second computing entity. In one example, the public key 410 can be provided by the key pair module 402 corresponding to the second computing entity. Figure 4A The second computing entity can transmit the public key 410 to the first computing entity. In one example, the key transmission submodule 416 corresponding to the second computing entity ( Figure 4A The public key 410 can be transmitted to the first computing entity, such as to the KA shared secret module 420 or the KA shared secret generation submodule 432 of the first computing entity.

[0112] The KA shared secret module 420 may further include a KA shared secret storage submodule 436 and / or a KA shared secret transmission submodule 438. The KA shared secret storage submodule 436 may store the KA shared secret 434 for future reference, for example, by one or more cryptographic modules 400. For example, the KA shared secret transmission submodule 438 may transmit the KA shared secret 434 to another cryptographic module 400, or to another component of a computational entity being performed within the cryptographic module 400.

[0113] C. Example KEM module example.

[0114] like Figure 4CAs shown, cryptographic module 400 may include KEM module 440. KEM module 440 can generate a KEM shared secret for use as an encryption key and / or for use in subsequent cryptographic operations. KEM module 440 may include a KEM shared secret algorithm submodule 442 and a KEM shared secret generation submodule 444. KEM shared secret algorithm submodule 442 can provide a cryptographic algorithm to KEM shared secret generation submodule 444 for generating KEM shared secret 446. In one example, the cryptographic algorithm used to generate KEM shared secret 446 may be stored in KEM shared secret algorithm submodule 442. Additionally, or alternatively, KEM shared secret algorithm submodule 442 may select a cryptographic algorithm from a set of cryptographic algorithms for generating KEM shared secret 446. The cryptographic algorithm may be a quantum-resistant cryptographic algorithm or a conventional cryptographic algorithm. KEM shared secret generation submodule 444 may use the cryptographic algorithm provided by KEM shared secret algorithm submodule 442 to generate KEM shared secret 446.

[0115] KEM module 440 may further include a KEM shared secret storage submodule 448 and / or a KEM shared secret transport submodule 450. KEM shared secret storage submodule 448 may store KEM shared secret 446 for future reference, for example, by one or more cryptographic modules 400. For example, KEM shared secret transport submodule 450 may transmit KEM shared secret 446 to another cryptographic module 400, or to another component of a computational entity being performed within the cryptographic module 400.

[0116] like Figure 4C As further illustrated, KEM module 440 can generate ciphertext. In one example, KEM module 440 can generate both a KEM shared secret and ciphertext simultaneously. The ciphertext may include an encapsulated KEM shared secret. For example, the ciphertext can be used to securely transmit the KEM shared secret to another computing entity. The computing entity receiving the ciphertext can decapsulate the ciphertext to obtain the KEM shared secret, and the KEM shared secret can be used as an encryption key, or an encryption key including or based on the KEM shared secret can be generated. Additionally, or alternatively, the KEM shared secret can be used for subsequent cryptographic operations.

[0117] KEM module 440 may include an encapsulation algorithm submodule 454 and a KEM ciphertext generation submodule 456. The encapsulation algorithm submodule 454 may provide a cryptographic algorithm to the KEM ciphertext generation submodule 456 for generating ciphertext 458. In one example, the cryptographic algorithm used to generate ciphertext 458 may be stored in the encapsulation algorithm submodule 454. Additionally, or alternatively, the encapsulation algorithm submodule 454 may select a cryptographic algorithm from a set of cryptographic algorithms for generating ciphertext 458. The cryptographic algorithm may be a quantum-resistant cryptographic algorithm or a conventional cryptographic algorithm. The KEM ciphertext generation submodule 456 may use the cryptographic algorithm provided by the encapsulation algorithm submodule 454 to generate ciphertext 458 from the KEM shared secret 446, encapsulating the KEM shared secret with public key 410.

[0118] The public key 410 used by the KEM ciphertext generation submodule 456 can be used by the key pair module 402 ( Figure 4A The public key 410 used by the KEM ciphertext generation submodule 456 can be referred to as the encapsulation key. In one example, the key transmission submodule 416 ( Figure 4A The encapsulation key can be transmitted to KEM module 440, such as to KEM ciphertext generation submodule 456. The KEM shared secret 446, utilized by KEM ciphertext generation submodule 456, can be used by KEM module 440 (…). Figure 4C Provided by ). In one example, KEM shares the secret transport submodule 450 ( Figure 4C The KEM shared secret 446 can be transmitted to the KEM module 440, such as to the KEM ciphertext generation submodule 456.

[0119] KEM module 440 may further include a ciphertext storage submodule 460 and / or a ciphertext transmission submodule 462. Ciphertext storage submodule 460 may store ciphertext 458 for future reference, for example, by one or more cryptographic modules 400. For example, ciphertext transmission submodule 462 may transmit ciphertext 458 to another cryptographic module 400, or to another component of a computational entity being performed within a cryptographic module 400.

[0120] D. Example KEM decapsulation module.

[0121] like Figure 4D As shown, the cryptographic module 400 may include a KEM decapsulation module 464. The KEM decapsulation module 464 can obtain the KEM shared secret by decapsulating ciphertext (such as ciphertext received from another computing entity). The KEM shared secret obtained by decapsulating the ciphertext can be used as an encryption key, or can be used to generate an encryption key that includes or is based on the KEM shared secret. Additionally, or alternatively, the KEM shared secret can be used for subsequent cryptographic operations.

[0122] KEM decapsulation module 464 may include a decapsulation algorithm submodule 466 and a KEM ciphertext decapsulation submodule 468. The decapsulation algorithm submodule 466 may provide a cryptographic algorithm to the KEM ciphertext decapsulation submodule 468 to obtain the KEM shared secret 470. In one example, the cryptographic algorithm used to obtain the KEM shared secret 470 from ciphertext 458 may be stored in the decapsulation algorithm submodule 466. Additionally, or alternatively, the decapsulation algorithm submodule 466 may select a cryptographic algorithm from a set of cryptographic algorithms, and the selected cryptographic algorithm may be used by the KEM ciphertext decapsulation submodule to obtain the KEM shared secret 470. The cryptographic algorithm may be a quantum-resistant cryptographic algorithm or a conventional cryptographic algorithm. The KEM ciphertext decapsulation submodule 468 can decapsulate ciphertext 458 using the cryptographic algorithm provided by the decapsulation algorithm submodule 466, utilizing the private key 412 corresponding to the public key 410 used to generate ciphertext 458, to obtain the KEM shared secret 470 from ciphertext 458.

[0123] The private key 412 used by the KEM ciphertext decryption submodule 468 can be used by the key pair module 402 ( Figure 4A The private key 412 used by the KEM ciphertext decryption submodule 468 can be referred to as the decryption key. In one example, the key transmission submodule 416 ( Figure 4A The private key 412 can be transmitted to the KEM decapsulation module 464, such as to the KEM ciphertext decapsulation submodule 468. The ciphertext 458 decapsulated by the KEM ciphertext decapsulation submodule 468 can be provided by another computing entity. In one example, the ciphertext 458 can be generated by the KEM module 440 of another computing entity.

[0124] KEM decapsulation module 464 may further include KEM shared secret storage submodule 472 and / or KEM shared secret transmission submodule 474. KEM shared secret storage submodule 472 may store KEM shared secret 470 for future reference, for example, by one or more cryptographic modules 400. For example, KEM shared secret transmission submodule 474 may transmit KEM shared secret 470 to another cryptographic module 400, or to another component of a computational entity being performed within the cryptographic module 400.

[0125] E. Example of a combined module.

[0126] like Figure 4EAs shown, the cryptographic module 400 may include a combination module 476. The combination module 476 can generate a combined shared secret 477 from one or more shared secrets, such as from KA shared secret 434 and KEM shared secret 446. The combined shared secret 477 generated from KA shared secret 434 and KEM shared secret 446 may be referred to as the KA-KEM combined shared secret. The combined shared secret can be used as an encryption key, or an encryption key including or based on the combined shared secret can be generated.

[0127] Combination module 476 may include combination function submodule 478 and combined shared secret generation submodule 479. Combination function submodule 478 may provide cryptographic algorithms to combined shared secret generation submodule 479 for generating combined shared secret 477. In one example, the cryptographic algorithm for generating combined shared secret 477 may be stored in combination function submodule 478. Additionally, or alternatively, combination function submodule 478 may select a cryptographic algorithm from a set of cryptographic algorithms for generating combined shared secret 477. The cryptographic algorithm may be a quantum-resistant cryptographic algorithm or a conventional cryptographic algorithm. Combined shared secret generation submodule 479 may generate combined shared secret 477 from multiple shared secrets and combination parameters 480. For example, combined shared secret 477 may be generated from KA shared secret 434, KEM shared secret 446, and combination parameters 480 using the cryptographic algorithm provided by combination function submodule 478.

[0128] The KA shared secret 434, utilized by the combined shared secret generation submodule 479, can be obtained by the KA shared secret module 420 ( Figure 4B ) is provided. In one example, KA shares the secret transport submodule 438 ( Figure 4B The KA shared secret can be transmitted to the combination module 476, such as to the combined shared secret generation submodule 479. The KEM shared secret 446 used by the combined shared secret generation submodule 479 can be used by the KEM module 440 ( Figure 4C Provided by ). In one example, KEM shares the secret transport submodule 450 ( Figure 4C The KEM shared secret 446 can be transmitted to the combination module 476, such as to the combined shared secret generation submodule 479.

[0129] Combination module 476 may further include a combined shared secret storage submodule 481 and / or a combined shared secret transmission submodule 482. The combined shared secret storage submodule 481 may store the combined shared secret 477 for future reference, for example, by one or more cryptographic modules 400. For example, the combined shared secret transmission submodule 482 may transmit the combined shared secret 477 to another cryptographic module 400, or to another component of a computational entity being performed within a cryptographic module 400.

[0130] F. Example message encryption module.

[0131] like Figure 4F As shown, cryptographic module 400 may include encryption module 483. Encryption module 483 may, for example, encrypt message 486 before transmitting the message to another computational entity. Encryption module 483 may generate encrypted message 488 from encryption key 487. In one example, one or more shared secrets may be used as encryption key 487. Additionally, or alternatively, encryption key 487 may include one or more shared secrets, or may be generated based on one or more shared secrets. In one example, a combined shared secret 477 may be used as encryption key 487. Additionally, or alternatively, encryption key 487 may include a combined shared secret 477, or may be generated based on a combined shared secret 477.

[0132] Encryption module 483 may include encryption algorithm submodule 484 and message encryption submodule 485. Encryption algorithm submodule 484 may provide a cryptographic algorithm to message encryption submodule 485 for generating encrypted message 488. In one example, the cryptographic algorithm used to generate encrypted message 488 may be stored in encryption algorithm submodule 484. Additionally, or alternatively, encryption algorithm submodule 484 may select a cryptographic algorithm from a set of cryptographic algorithms for generating encrypted message 488. The cryptographic algorithm may be a quantum-resistant cryptographic algorithm or a conventional cryptographic algorithm. Message encryption submodule 485 may generate encrypted message 488 by encrypting message 486 using encryption key 487. In one example, encryption key 487 may be a combined shared secret 477 provided by combination module 476. Figure 4E In one example, the combined shared secret transport submodule 482 ( Figure 4E The combined shared secret can be transmitted to encryption module 483, such as to message encryption submodule 485. Additionally, or alternatively, encryption key 487 can be, for example, from KA shared secret transmission submodule 438 ( Figure 4B The KA shared secret 434 provided, or for example from the KEM shared secret transmission submodule 450 ( Figure 4CThe KEM shared secret 446 is provided.

[0133] Encryption module 483 may further include an encrypted message storage submodule 489 and / or an encrypted message transmission submodule 490. The encrypted message storage submodule 489 may store encrypted messages 488 for future reference, for example, by one or more cryptographic modules 400. For example, the encrypted message transmission submodule 490 may transmit the encrypted messages 488 to another cryptographic module 400, or to another component of a computational entity being executed within the cryptographic module 400. Encrypted messages generated by cryptographic module 400 may be transmitted to another computational entity, which may decrypt the encrypted messages.

[0134] G. Example message decryption module.

[0135] like Figure 4G As shown, the cryptographic module 400 may include a decryption module 491. The decryption module 491 can decrypt the encrypted message 488. The encrypted message 488 can be transmitted from another computing device to a computing device executing the SE application. The decryption module 491 can decrypt the encrypted message 488 by utilizing the encryption key 487 used to generate the encrypted message 488. Figure 4F The corresponding decryption key 493 is used to decrypt the encrypted message 488 to generate the decrypted message 492. In one example, one or more shared secrets can be used as the decryption key 493. Additionally, or alternatively, the decryption key 493 may include one or more shared secrets, or may be generated based on one or more shared secrets. In one example, a combined shared secret 477 can be used as the decryption key 493. Additionally, or alternatively, the decryption key 493 may include a combined shared secret 477, or may be generated based on a combined shared secret 477.

[0136] Decryption module 491 may include decryption algorithm submodule 494 and message decryption submodule 495. Decryption algorithm submodule 494 may provide a cryptographic algorithm to message decryption submodule 495 for decrypting encrypted message 488 to obtain decrypted message 492. In one example, the cryptographic algorithm used to decrypt encrypted message 488 may be stored in decryption algorithm submodule 494. Additionally, or alternatively, decryption algorithm submodule 494 may select a cryptographic algorithm from a set of cryptographic algorithms for decrypting encrypted message 488. The cryptographic algorithm may be a quantum-resistant cryptographic algorithm or a conventional cryptographic algorithm. Message decryption submodule 495 may obtain decrypted message 492 by decrypting encrypted message 488 using decryption key 493. In one example, decryption key 493 may be generated by combination module 476 ( Figure 4EThe combined shared secret 477 is provided. In one example, the combined shared secret transport submodule 482 ( Figure 4E The combined shared secret can be transmitted to decryption module 491, such as to message decryption submodule 495. Additionally, or alternatively, decryption key 493 can be, for example, from KA shared secret transmission submodule 438 ( Figure 4B The KA shared secret 434 provided, or for example, the KEM shared secret transmission submodule 450 ( Figure 4C The KEM shared secret 446 is provided.

[0137] The decryption module 491 may further include a decrypted message storage submodule 496 and / or a decrypted message transmission submodule 497. The decrypted message storage submodule 496 may store the decrypted message 492 for future reference, for example, by one or more cryptographic modules 400. For example, the decrypted message transmission submodule 497 may transmit the decrypted message 492 to another cryptographic module 400, or to another component of the computational entity being executed within the cryptographic module 400. The decrypted message generated by the cryptographic module 400 may be utilized by another component of the computational entity.

[0138] 6. Example message encryption operation

[0139] Now for reference Figure 5 This describes example operation 500 related to encrypted messages. (Reference) Figure 5 The described operation 500 can be used as a reference. Figure 1 One or more components and / or references of the described system 100 Figures 2A-2C The computational entity 200 described is executed by one or more components. For example, operation 500 can be executed at least partially within an SE platform runtime environment, such as one or more LSEs within the SE platform runtime environment. (See reference) Figure 5 One or more of the described operations 500 can be modified, rearranged, or omitted together. Therefore, refer to Figure 5 The specific sequence of operations described should not be construed as limiting the scope of one or more embodiments. In one example, reference... Figure 5 The described operation 500 is as follows (see references). Figures 3A-3D The described entity A (CE-A) 302 and compute entity B (CE-B) 304 are executed.

[0140] like Figure 5As shown, operation 500 may include, at block 502, detecting an electromagnetic field generated by a near-field communication element associated with the second computing entity at the first computing entity. At block 504, operation 500 may include broadcasting the presence of the first computing entity. At block 506, operation 500 may include determining whether a response has been received from the second computing entity. When a response is received, operation 500 may proceed to block 508. When no response is received, operation may return to block 504, where broadcasting the presence of the first computing entity may continue.

[0141] At box 508, operation 500 may include initializing the SE platform runtime environment within the SE hardware of the first computing entity, at least in part, via energy from an electromagnetic field generated by a near-field communication element. At box 510, operation 500 may include receiving at least one public key from the second computing entity. At box 512, operation 500 may include determining whether the at least one public key is valid. If the at least one public key is valid, operation 500 proceeds to box 513. If one of the at least one public keys is invalid, the operation may return to box 506.

[0142] At box 514, operation 500 may include performing a set of cryptographic operations to generate an encryption key. The cryptographic operations may be performed, at least by executing one or more SE applications within the SE platform runtime environment. At box 516, operation 500 may include transmitting at least one encrypted message, encrypted using the encryption key, from a first computing entity to a second computing entity. The cryptographic operation performed at box 514 may include one or more of the cryptographic operations described herein. In one example, the cryptographic operation may include one or more KA cryptographic operations, one or more KEM cryptographic operations, and / or one or more hybrid cryptographic operations.

[0143] 7. Example operations for generating encryption keys

[0144] Now for reference Figure 6A and Figure 6B This describes example operation 600 related to generating encryption keys. (Reference) Figure 6A and Figure 6B The described operation 600 can be referenced. Figure 1 One or more components of the described system 100 and / or utilizing references Figures 2A-2C The described computational entity 200 is executed by one or more components. For example, operation 600 can be executed in an SE platform runtime environment, such as one or more LSEs within the SE platform runtime environment. (See reference) Figure 6A and Figure 6B One or more operations 600 described may be modified, rearranged, or omitted together. Therefore, refer to Figure 6A and 6B The specific sequence of operations described should not be construed as limiting the scope of one or more embodiments. In one example, reference... Figure 6A and Figure 6B The described operation 600 is as follows (see references). Figures 3A-3D The computational entities A (CE-A) 302 and B (CE-B) 304 described herein shall perform this action. Additionally, the generation of encryption keys is described separately (as per reference). Figure 5 The box 514 described may include references Figure 6A and Figure 6B One or more of the operations described in operation 600.

[0145] like Figure 6A As shown, operation 600 may include, at block 602, selecting an encapsulation algorithm from a set of encapsulation algorithms at the first computational entity. At block 604, operation 600 may include generating a first shared secret. At block 606, operation 600 may include generating ciphertext by encapsulating the first shared secret using a first KEM public key associated with the second computational entity according to the encapsulation algorithm. At block 608, operation 600 may include transmitting the ciphertext to the second computational entity. At block 610, operation 600 may include selecting the first shared secret as an encryption key, or generating an encryption key based on the first shared secret. The ciphertext transmitted to the second computational entity at block 608 may be used by the second computational entity to obtain the first shared secret by decrypting the ciphertext. The second computational entity may then generate an encryption key using the first shared secret. The first and second computational entities may exchange encrypted messages that are encrypted and decrypted using the shared secret as an encryption key or using an encryption key generated based on the shared secret.

[0146] like Figure 6B As shown, operation 600 may include generating a combined shared secret from a first shared secret and a second shared secret. The combined shared secret may be generated from the first and second shared secrets in a single operation, or the generation of the first shared secret, the second shared secret, and the combined shared secret may represent separate operations. The first shared secret may be derived from a reference... Figure 6A Operation 600 is generated in boxes 602-608. Additionally, operation 600 may include, at box 612, generating a first KA private key at a first computational entity. At box 614, operation 600 may include selecting a KA algorithm from a set of KA algorithms.

[0147] At box 616, operation 600 may include generating a second shared secret by combining a first KA private key and a second KA public key associated with a second computing entity according to the KA algorithm. At box 618, operation 600 may include selecting a combination function from a set of combination functions. At box 620, operation 600 may include generating a combined shared secret by combining the first shared secret, the second shared secret, and combination parameters associated with the combination function according to the combination function. At box 622, operation 600 may include selecting the combined shared secret as an encryption key, or generating an encryption key based on the combined shared secret.

[0148] The second computational entity can generate a combined shared secret similar to that described in reference boxes 612-622. The first and second computational entities can exchange encrypted messages that use the combined shared secret as an encryption key or an encryption key generated based on the combined shared secret for encryption and decryption.

[0149] 8. Computer networks and cloud networks

[0150] In one or more embodiments, a computer network provides connectivity among a set of nodes. Nodes may be local to each other and / or geographically distant from each other. Nodes are connected by a set of links. Examples of links include coaxial cable, unshielded twisted pair, copper cable, fiber optic cable, and virtual links.

[0151] A subset of nodes implements a computer network. Examples of such nodes include switches, routers, firewalls, and Network Address Translation (NAT). Another subset of nodes uses a computer network. Such nodes (also referred to as "hosts") can execute client processes and / or server processes. Client processes make requests for computing services (such as the execution of a specific application and / or the storage of a specific amount of data). Server processes respond by performing the requested service and / or returning the corresponding data.

[0152] A computer network can be a physical network, including physical nodes connected by physical links. A physical node is any digital device. A physical node can be a function-specific hardware device, such as a hardware switch, hardware router, hardware firewall, and hardware NAT. Additionally or alternatively, a physical node can be a general-purpose machine configured to run various virtual machines and / or applications performing corresponding functions. A physical link is the physical medium connecting two or more physical nodes. Examples of links include coaxial cable, unshielded twisted-pair cable, copper cable, and fiber optic cable.

[0153] Computer networks can be overlay networks. An overlay network is a logical network implemented on top of another network, such as a physical network. Each node in an overlay network corresponds to a corresponding node in the underlying network. Therefore, each node in an overlay network is associated with both an overlay address (to address the overlay node) and an underlying address (to address the underlying node that implements the overlay node). Overlay nodes can be digital devices and / or software processes (such as virtual machines, application instances, or threads). The links connecting overlay nodes are implemented as tunnels through the underlying network. Overlay nodes at either end of the tunnel treat the underlying multi-hop path between them as a single logical link. Tunneling is performed through encapsulation and decapsulation.

[0154] In this embodiment, the client may be located locally on the computer network and / or remotely on the computer network. The client may access the computer network via other computer networks, such as a private network or the Internet. The client may use a communication protocol such as Hypertext Transfer Protocol (HTTP) to convey requests to the computer network. Requests may be conveyed through interfaces such as client interfaces (such as web browsers), program interfaces, or application programming interfaces (APIs).

[0155] In this embodiment, a computer network provides connectivity between clients and network resources. Network resources include hardware and / or software configured to execute server processes. Examples of network resources include processors, data storage devices, virtual machines, containers, and / or software applications. Network resources are shared among multiple clients. Clients independently request computing services from the computer network. Network resources are dynamically assigned to requesting and / or clients on an on-demand basis. The network resources assigned to each requesting and / or client may be scaled up or down based on, for example, (a) computing services requested by a particular client, (b) aggregated computing services requested by a particular tenant, and / or (c) aggregated computing services requested by the computer network. Such a computer network may be referred to as a "cloud network."

[0156] In this embodiment, the service provider offers a cloud network to one or more end users. Various service models can be implemented via the cloud network, including but not limited to Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). In SaaS, the service provider provides end users with the ability to use the service provider's applications running on network resources. In PaaS, the service provider provides end users with the ability to deploy custom applications onto network resources. Custom applications can be created using programming languages, libraries, services, and tools supported by the service provider. In IaaS, the service provider provides end users with the ability to provision processing, storage, networking, and other basic computing resources provided by the network resources. Any application, including operating systems, can be deployed on network resources.

[0157] In embodiments, computer networks can be deployed in various ways, including but not limited to private clouds, public clouds, and hybrid clouds. In a private cloud, network resources are provisioned for exclusive use by a specific group of entities (as used herein, "entity" refers to a company, organization, individual, or other entity). Network resources can be located locally and / or remotely from the premises of the specific group of entities. In a public cloud, cloud resources are provisioned for multiple entities (also referred to as "tenants" or "clients") that are independent of each other. The computer network and its network resources are accessed by clients corresponding to different tenants. Such a computer network can be referred to as a "multi-tenant computer network." Several tenants can use the same specific network resource at different times and / or simultaneously. Network resources can be located locally and / or remotely from the tenant's premises. In a hybrid cloud, the computer network includes both private and public clouds. The interface between the private and public clouds allows for data and application portability. Data stored in the private cloud and data stored in the public cloud can be exchanged through the interface. Applications implemented in the private cloud and applications implemented in the public cloud may have dependencies on each other. Calls from applications in the private cloud to applications in the public cloud (and vice versa) can be performed through the interface.

[0158] In this embodiment, the tenants of a multi-tenant computer network are independent of each other. For example, one tenant's business or operations may be separate from those of another tenant. Different tenants may have different network requirements for the computer network. Examples of network requirements include processing speed, data storage capacity, security requirements, performance requirements, throughput requirements, latency requirements, resilience requirements, quality of service (QoS) requirements, tenant isolation, and / or consistency. The same computer network may need to meet different network requirements mandated by different tenants.

[0159] In one or more embodiments, tenant isolation can be implemented in a multi-tenant computer network to ensure that applications and / or data from different tenants are not shared with each other. Various tenant isolation methods can be used.

[0160] In this embodiment, each tenant is associated with a tenant ID. Each network resource in a multi-tenant computer network is tagged with a tenant ID. A tenant is only allowed to access a specific network resource if the tenant and the specific network resource are associated with the same tenant ID.

[0161] In this embodiment, each tenant is associated with a tenant ID. Each application implemented by the computer network is tagged with a tenant ID. Additionally or alternatively, each data structure and / or dataset stored by the computer network is tagged with a tenant ID. A tenant is only allowed to access a specific application, data structure, and / or dataset if the tenant and the specific application, data structure, and / or dataset are associated with the same tenant ID.

[0162] As an example, each database implemented in a multi-tenant computer network can be identified by a tenant ID. Only the tenant associated with the corresponding tenant ID can access the data in a specific database. As another example, each entry in a database implemented in a multi-tenant computer network can be identified by a tenant ID. Only the tenant associated with the corresponding tenant ID can access the data in a specific entry. However, the database can be shared by multiple tenants.

[0163] In this embodiment, the subscription list indicates which tenants are authorized to access which applications. For each application, a list of tenant IDs of tenants authorized to access that application is stored. A tenant is only allowed to access a specific application if its tenant ID is included in the subscription list corresponding to that specific application.

[0164] In this embodiment, network resources corresponding to different tenants (such as digital devices, virtual machines, application instances, and threads) are isolated from tenant-specific overlay networks maintained by the multi-tenant computer network. As an example, packets from any source device within a tenant overlay network may only be transmitted to other devices within the same tenant overlay network. Encapsulation tunneling is used to prevent any transmission from a source device on one tenant overlay network to devices in other tenant overlay networks. Specifically, packets received from the source device are encapsulated within an outer packet. The outer packet is transmitted from a first encapsulation tunnel endpoint (communicating with the source device in the tenant overlay network) to a second encapsulation tunnel endpoint (communicating with the destination device in the tenant overlay network). The second encapsulation tunnel endpoint decapsulates the outer packet to obtain the original packet transmitted by the source device. The original packet is transmitted from the second encapsulation tunnel endpoint to the destination device within the same specific overlay network.

[0165] 9. Microservice Applications

[0166] According to one or more embodiments, the techniques described herein are implemented in a microservices architecture. In this context, a microservice refers to software logic designed to be deployed independently, with endpoints that can be logically coupled to other microservices to build a wide variety of applications. Applications built using microservices differ from monolithic applications, which are designed as a single, fixed unit and typically consist of a single logical executable. With microservices applications, different microservices can be deployed independently as separate executables. Microservices can communicate using Hypertext Transfer Protocol (HTTP) messages and / or according to other communication protocols via API endpoints. Microservices can be managed and updated separately, written in different languages, and executed independently of other microservices.

[0167] Microservices provide flexibility in managing and building applications. Different applications can be built by connecting different sets of microservices without changing their source code. Therefore, microservices act as logical building blocks that can be arranged in a wide variety of ways to build different applications. Microservices can provide monitoring services that notify the microservice manager (such as If-This-Then-That (IFTTT), Zapier, or Oracle Self-Service Automation (OSSA)) when a trigger event occurs in a set of trigger events exposed to the microservice manager. Microservices exposed to an application can alternatively or additionally provide action services that perform actions in the application based on data received from the microservice manager (which can be controlled and configured via the microservice manager by passing values, connecting actions to other triggers, and / or data passed from other actions in the microservice manager). Microservice triggers and / or actions can be chained together to form recipes for actions that occur in alternative, different applications that are otherwise unaware of or have no control or dependency on each other. These managed applications can be authenticated or plugged into the microservice manager, for example, by using the application certificates provided by the manager's users, without requiring re-authentication each time a managed application is used alone or in combination with other applications.

[0168] In one or more embodiments, microservices can be connected via a GUI. For example, a microservice can be displayed as a logical block within a window, frame, or other element of the GUI. Users can drag and drop microservices into GUI areas used to build the application. Users can use directed arrows or any other GUI element to connect the output of one microservice to the input of another. The application builder can run verification tests to confirm that the output and input are compatible (e.g., by checking data types, size limits, etc.).

[0169] trigger

[0170] According to one or more embodiments, the above-described techniques can be encapsulated within microservices. In other words, a microservice can trigger notifications (entering the microservice manager for optional use by other pluggable applications referred to herein as the "target" microservice) based on the techniques described above, and / or can be represented as a GUI block and connected to one or more other microservices. Triggering conditions may include absolute or relative thresholds for values, and / or absolute or relative thresholds for the amount or duration of data to be analyzed, such that a trigger to the microservice manager occurs whenever a pluggable microservice application detects that a threshold has been crossed. For example, a user can request a trigger in the microservice manager when a microservice application detects that a value has crossed a trigger threshold.

[0171] In one embodiment, the trigger, when satisfied, can output data for consumption by the target microservice. In another embodiment, upon satisfaction, the trigger can output a binary value indicating that the trigger condition has been met, or it can output a field name or other contextual information indicating that the trigger condition has been met. Additionally or alternatively, the target microservice can connect to one or more other microservices, allowing alerts to be input to those other microservices. These other microservices can then perform response actions based on the techniques described above, including but not limited to deploying additional resources, adjusting system configurations, and / or generating a GUI.

[0172] action

[0173] In one or more embodiments, pluggable microservice applications can expose actions to the microservice manager. The exposed actions can receive as input the identifier or location of data or data objects that cause data to be moved to the data cloud.

[0174] In one or more embodiments, the exposed action can receive a request as input to increase or decrease an existing alert threshold. The input can identify an existing alert threshold in the application and whether to increase, decrease, or delete it. Additionally, or alternatively, the input can request the microservice application to create a new alert threshold in the application. Alerts in the application can be triggered to the user upon login to the application, or they can use a default or user-selected alerting mechanism available within the microservice application itself, rather than triggering alerts to the user through another application plugged into the microservice manager.

[0175] In one or more embodiments, a microservice application can generate and provide output based on input that identifies, locates, or provides historical data and defines the extent or scope of the requested output. When triggered, an action causes the microservice application to provide, store, or display the output, such as as a data model or aggregated data describing a data model.

[0176] 10. Hardware Overview

[0177] According to one embodiment, the technology described herein is implemented by one or more dedicated computing devices. The dedicated computing device may be hardwired to execute the technology, or may include digital electronic devices persistently programmed to execute the technology, such as one or more application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or network processing units (NPUs), or may include one or more general-purpose hardware processors programmed to execute the technology according to program instructions in firmware, memory, other storage devices, or combinations thereof. Such a dedicated computing device may also combine custom hardwired logic, ASICs, FPGAs, or NPUs with custom programming to implement the technology. The dedicated computing device may be a desktop computer system, a portable computer system, a handheld device, a networking device, or any other device that combines hardwired and / or program logic to implement the technology.

[0178] For example, Figure 7 This is a block diagram illustrating a computer system 700 on which embodiments of the present invention can be implemented. The computer system 700 may include a bus 702 or other communication mechanism for conveying information, and a hardware processor 704 coupled to the bus 702 to process information. The hardware processor 704 may be, for example, a general-purpose microprocessor.

[0179] Computer system 700 also includes main memory 706, such as random access memory (RAM) or other dynamic storage device, coupled to bus 702, to store instructions and information to be executed by processor 704. Main memory 706 can also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 704. When such instructions are stored in a non-transitory storage medium accessible to processor 704, computer system 700 presents itself as a dedicated machine tailored to perform the operations specified in the instructions.

[0180] Computer system 700 may further include read-only memory (ROM) 708 or other static storage device coupled to bus 702 to store static information and instructions for processor 704. Storage device 710, such as a magnetic disk or optical disk, is provided and coupled to bus 702 to store information and instructions.

[0181] Computer system 700 can be coupled to display 712, such as a cathode ray tube (CRT), via bus 702 to display information to the computer user. Input device 714, including alphanumeric keys and other keys, is coupled to bus 702 to transmit information and command selections to processor 704. Another type of user input device is a cursor control 716, such as a mouse, trackball, or cursor arrow keys, used to transmit directional information and command selections to processor 704 and to control cursor movement on display 712. This input device typically has two degrees of freedom in two axes (a first axis (e.g., x) and a second axis (e.g., y)), which allows the device to specify positioning in a plane.

[0182] Computer system 700 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware and / or program logic (which, when combined with the computer system, make computer system 700 a special-purpose machine or program it as such)

[0183] As used herein, the term "storage medium" refers to any non-transitory medium that stores instructions and / or data that cause a machine to operate in a particular manner. Such storage media can include non-volatile media and / or volatile media. Non-volatile media can include, for example, optical discs or magnetic disks, such as storage device 710. Volatile media include dynamic memory, such as main memory 706. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or tape cartridges, content-addressable memory (CAM), and ternary content-addressable memory (TCAM).

[0184] Storage media differ from transmission media but can be used in conjunction with them. Transmission media participate in transferring information between storage media. For example, transmission media can include coaxial cables, copper wires, and optical fibers, including lines containing bus 702. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communication.

[0185] Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor 704 for execution. For example, the instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and transmit them over a telephone line using a modem. A modem local to computer system 700 may receive data over a telephone line and convert the data into an infrared signal using an infrared transmitter. An infrared detector may receive the data carried in the infrared signal, and appropriate circuitry may place the data on bus 702. Bus 702 carries the data to main memory 706, from which processor 704 retrieves and executes the instructions. Instructions received by main memory 706 may optionally be stored on storage device 710 before or after execution by processor 704.

[0186] Computer system 700 also includes a communication interface 718 coupled to bus 702. Communication interface 718 provides bidirectional data communication coupled to network link 720 connected to local network 722. For example, communication interface 718 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem providing a data communication connection to a corresponding type of telephone line. As another example, communication interface 718 may be a local area network (LAN) card providing a data communication connection to a LAN-compatible network. A wireless link may also be implemented. In any such implementation, communication interface 718 transmits and receives electrical, electromagnetic, or optical signals carrying digital data streams representing various types of information.

[0187] Network link 720 typically provides data communication to other data devices via one or more networks. For example, network link 720 may provide a connection to host 724 or to data equipment operated by Internet Service Provider (ISP) 726 via local network 722. ISP 726 then provides data communication services via a global packet data communication network now commonly referred to as the "Internet" 728. Both local network 722 and Internet 728 use electrical, electromagnetic, or optical signals that carry digital data streams. Signals through various networks, as well as signals on network link 720 and through communication interface 718 (which carry digital data to and from computer system 700), are example forms of transmission media.

[0188] Computer system 700 can send messages and receive data, including program code, through one or more networks, network links 720, and communication interfaces 718. In the Internet example, server 730 can transmit the requested code of the application through the Internet 728, ISP 726, local network 722, and communication interface 718.

[0189] The received code may be executed by processor 704 upon receipt and / or stored in storage device 710 or other non-volatile storage device for later execution.

[0190] 11. Miscellaneous; Extension

[0191] The embodiments relate to a system having one or more devices, the one or more devices including a hardware processor and configured to perform any operation described herein and / or recited in any of the following claims. In the embodiments, a non-transitory computer-readable storage medium includes instructions that, when executed by the one or more hardware processors, cause the performance of any operation described herein and / or recited in any of the claims.

[0192] In one or more embodiments, the system described herein may include more or fewer components than those described. The described components may be local or remote to each other. The described components may be implemented in software and / or hardware. Each component may be distributed across multiple applications and / or machines. Multiple components may be combined into one application and / or machine. Operations described with respect to one component may instead be performed by another component.

[0193] Any combination of the features and functions described herein may be used according to one or more embodiments. In the foregoing specification, embodiments have been described with reference to numerous specific details that may vary depending on the implementation. Therefore, the specification and drawings are to be considered illustrative rather than restrictive. The unique and exclusive indication of the scope of this invention, and what the applicant intends to be within the scope of this invention, is the literal and equivalent scope of the set of claims claimed herein, in the specific form claimed by such claims, including any subsequent corrections.

Claims

1. A method comprising: An SE platform runtime environment is executed on at least one security element (SE) hardware processor included in a first computing entity, wherein the SE platform runtime environment includes instructions that, when executed by the at least one SE hardware processor, cause the following operations to be performed: A set of cryptographic operations is performed by executing one or more SE applications within the SE platform runtime environment, wherein the set of cryptographic operations includes: Generate the first shared secret; At least by generating ciphertext by encapsulating a first shared secret using a first KEM public key associated with a second computational entity according to an encapsulation algorithm; and The ciphertext is transmitted to the second computing entity. After the ciphertext is transmitted to the second computing entity: The second computing entity decrypts the ciphertext using the KEM private key corresponding to the first KEM public key to derive the first shared secret; and The first computing entity and the second computing entity exchange at least one encrypted message. The at least one encrypted message is encrypted using an encryption key. The encryption key mentioned therein includes a first shared secret, or is at least based in part on the first shared secret.

2. The method of claim 1, wherein the encapsulation algorithm comprises at least one of the following: a conventional cryptographic algorithm, or a quantum-resistant cryptographic algorithm.

3. The method of claim 1, wherein the group of one or more SE applications includes a key encapsulation mechanism module; as well as Executing the group of one or more SE applications within the SE platform runtime environment includes: At least by executing the key encapsulation mechanism module to encapsulate the first shared secret using the first KEM public key according to the encapsulation algorithm; The output of the key encapsulation mechanism module includes the ciphertext.

4. The method of claim 1, wherein the set of cryptographic operations further comprises: Generate the first key negotiation (KA) private key; The second shared secret is generated at least by combining the first KA private key and the first KA public key associated with the second computing entity according to the KA algorithm; The combined shared secret is generated at least by combining the first shared secret, the second shared secret, and the combination parameters associated with the combination function according to the combination function; The second computational entity derives the second shared secret by at least the following means: Generate the second KA private key, and The second KA private key and the second KA public key associated with the first computing entity are combined according to the KA algorithm. The second computing entity derives the combined shared secret by combining the first shared secret, the second shared secret, and the combination parameters associated with the combination function according to the combination function; The encryption key includes the combined shared secret, or is at least based in part on the combined shared secret.

5. The method of claim 4, wherein the operation further comprises: Select the combined function from a set of combined functions.

6. The method of claim 4, wherein the operation further comprises: Receive the first KEM public key and the first KA public key from the second computing entity; Verify the first KEM public key and the first KA public key; In response to verifying the first KEM public key and the first KA public key, the set of cryptographic operations is performed; as well as The first encrypted message is transmitted to the second computing entity, wherein the first encrypted message is encrypted using the encryption key.

7. The method of claim 1, further comprising: The SE platform runtime environment is initialized at least in part via an electromagnetic field generated by a near-field communication element associated with the second computing entity; as well as After initializing the SE platform runtime environment, the first KEM public key is received from the second computing entity.

8. The method of claim 1, wherein the first computing entity and the second computing entity are communicatively coupled via a wired or wireless network.

9. The method of claim 1, wherein the operation further comprises: Initiate the cryptographic module within the SE platform runtime environment; as well as The cryptographic module selects one or more SE applications from the set for execution within the SE platform runtime environment.

10. The method of claim 1, wherein the operation further comprises: Use an application programming interface to select the wrapper algorithm from a set of wrapper algorithms.

11. The method of claim 1, wherein the set of one or more SE applications is generated, configured, and / or selected using an application programming interface.

12. The method of claim 1, wherein the operation further comprises: Based on one or more user input configurations, one or more parameters are associated with the set of cryptographic operations. The one or more parameters mentioned above include at least one of the following: a first KEM public key, or a selection of the encapsulation algorithm. At least one of the parameters is provided as a byte array.

13. One or more non-transitory computer-readable media, including instructions that, when executed by one or more hardware processors associated with a first computing entity, cause to perform the operation as described in any one of claims 1-12.

14. A system comprising: At least one security element (SE) hardware processor associated with the first computing entity; An SE platform runtime environment capable of executing on the at least one SE hardware processor; The SE platform runtime environment is configured to perform the operation as described in any one of claims 1-12 using the at least one SE hardware processor.

Images