Performing a digital signature operation in a secure element platform runtime environment

Abstract

One or more embodiments perform a set of digitally signed operations in a secure element (SE) platform runtime environment executing on an SE processor of an SE hardware device. The system initializes a signature generation object in the SE platform runtime environment. The system determines, via the signature generation object, a private key corresponding to a hash-based signature protocol. The system generates, via the signature generation object, a digital signature of a message digest by performing the hash-based signature protocol on the message digest using the private key. The system outputs the digital signature to the hardware device.

Description

[0001] Incorporate by reference; abandon declaration

[0002] This application claims the benefit of U.S. non-provisional patent application No. 18 / 756,138, filed June 27, 2024, entitled “Executing Digital Signature Operations In A Secure Element Platform Runtime Environment”; and U.S. provisional patent application No. 63 / 595,907, filed November 3, 2023, entitled “Executing Cryptographic Operations In A Secure Element Platform Runtime Environment”, the entire contents of which are hereby incorporated by reference.

[0003] U.S. Patent Application No. 18 / 535,432, filed on December 11, 2023, entitled “Executing Cryptographic Operations In ASecure Element Platform Runtime Environment,” is hereby incorporated by reference. U.S. Patent Application No. 18 / 535,432 and U.S. Provisional Patent Application No. 63 / 595,907 are collectively referred to herein as the “'432 Application.”

[0004] The applicant hereby withdraws any declaration of abandonment of the scope of the claims in the parent application(s) or its examination history and informs the USPTO that the claims in this application may be broader than any claims in the parent application(s). Technical Field

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

[0006] Various computing entities include Secure Element (SE) platforms, such as the Java Card platform. SE platforms include technologies configured to provide a high level of security, for example, in settings involving sensitive data or operations. As an example, SE platforms are used in computing entities performing operations associated with payment systems, identity verification, or telecommunications. These include smart cards, mobile devices, ID cards, access control systems, payment systems, and other devices where security is critical. Computing entities including SE platforms can transmit messages with other computing entities, including other computing entities that include SE platforms. Computing entities utilize digital signatures to ensure the authenticity, integrity, and / or non-repudiation of messages.

[0007] To generate a digital signature for a message being transmitted from a sending computational entity to a receiving computational entity, the sending computational entity applies a hash function to the message to generate a message digest, and then digitally signs the message digest. The sending computational entity digitally signs the message digest by applying a signing operation to the message digest using its private key. A message digest is a fixed-length hash of the message that represents a unique fingerprint of the message. The signing operation involves applying cryptographic operations to the message digest using the private key to generate a digital signature. The digital signature comprises a cryptographic artifact generated by applying cryptographic operations to the message digest using the private key. The sending computational entity then transmits the message and the digital signature to the receiving computational entity.

[0008] To verify a digital signature, the receiving computational entity derives a message digest from the digital signature by applying a verification operation to the digital signature using the public key corresponding to the private key used to generate the digital signature. The verification operation includes cryptographic operations complementary to the cryptographic operations of the signing operation. Additionally, the receiving computational entity applies a hash function to the message to generate an additional instance of the message digest. The receiving computational entity compares the message digest derived from the verification operation with the message digest derived by applying the hash function. The receiving computational entity determines that the digital signature is valid based at least in part on the fact that the message digest derived by applying the hash function to the message matches the message digest derived by applying the verification operation to the digital signature.

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

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

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

[0012] Figure 2A and Figure 2B The illustration shows an example architecture of a computing entity according to one or more embodiments;

[0013] Figures 3A-3F This is a flowchart illustrating example operations related to generating digital signatures according to one or more embodiments;

[0014] Figures 4A-4H This is a flowchart illustrating example operations related to verifying digital signatures according to one or more embodiments; and

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

[0016] In the following description, numerous specific details are set forth for purposes of explanation in order 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 specific 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 in block diagram form 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.

[0017] 1. General Overview

[0018] 2. Example Message Exchange System

[0019] 3. Example Digital Signature Algorithm

[0020] 4. Example Computational Entity Architecture

[0021] 5. Example digital signature operation

[0022] 6. Computer networks and cloud networks

[0023] 7. Microservice Applications

[0024] 8. Hardware Overview

[0025] 9. Other matters; extension

[0026] 1. General Overview

[0027] One or more embodiments utilize an SE platform (such as the Java Card platform) to generate a digital signature within the SE platform's runtime environment. The digital signature can be used to verify the authenticity or integrity of a message. Additionally or alternatively, one or more embodiments utilize an SE platform (such as the Java Card platform) to verify the digital signature within the SE platform's runtime environment. After verifying the digital signature associated with a message, one or more embodiments determine that the message is authentic, has not been altered or tampered with, and / or the sender cannot deny having sent the message.

[0028] In one example, the system generates a digital signature by performing a digital signature operation within the SE platform runtime environment. The digital signature can include a hash-based digital signature generated based on a hash-based signature protocol, which includes one or more hash-based digital signature algorithms. The hash-based signature protocol can include stateful hash-based signature protocols, stateless hash-based signature protocols, or one-time hash-based signature protocols, as well as combinations thereof. Hash-based digital signatures are resistant to cryptographic attacks from quantum computers with vast computational resources that utilize the principles of quantum mechanics to perform advanced computations exponentially faster than classical computers. Hash-based security protocols utilize hash functions that are inherently resistant to quantum attacks. Additionally, hash-based security protocols can be implemented by providing unique, one-time-use key pairs and stateful structures that are resilient to key corruption.

[0029] The techniques described herein utilize hash-based signature protocols to generate quantum-resistant digital signatures within the context of SE hardware devices with limited computational resources, such as Java Card devices. In one example, the system initializes a signature generation object within the SE platform runtime environment to generate a digital signature based on a hash-based signature protocol. The system generates a private key for generating the digital signature based on a key pair index and a parameter set maintained in persistent memory on the SE hardware. This parameter set stores parameters representing a tree structure of one-time key pairs, allowing the system to generate unique one-time key pairs and authentication paths for those pairs without maintaining the entire tree structure in memory.

[0030] In one example, the system utilizes incremental hashing to perform a hash-based signature protocol while consuming limited computational resources. Incremental hashing allows a signature generation object to generate a set of signature segments, which are then combined to provide a complete digital signature. Signature segments can be combined within or outside the SE platform runtime environment while maintaining the security of the digital signature attributable to hash-based protocols and the quantum resistance of the one-time use key pair.

[0031] In one example, the system generates a digital signature for a message by applying a hash-based signature protocol to the message digest, which includes a hash value generated by applying a hash function to the message. The message digest can be generated outside the SE platform runtime environment while maintaining the security of the digital signature attributable to the hash-based protocol and the quantum resistance of the one-time use key pair. Alternatively or additionally, the system can generate the message digest within the SE platform runtime environment by utilizing incremental hashing.

[0032] In one example, the system utilizes a signature verification object within the SE platform runtime environment to verify a digital signature by performing a signature verification operation within the SE platform runtime environment. The digital signature may include a hash-based digital signature generated based on a hash-based signature protocol, which includes one or more hash-based digital signature algorithms. The signature verification operation may include verifying the digital signature by performing a verification protocol corresponding to the hash-based signature protocol used to generate the digital signature. Additionally or alternatively, the signature verification operation may include performing a verification protocol to verify the authentication path corresponding to the one-time key pair used to generate the digital signature.

[0033] In one example, the system utilizes incremental hashing to perform signature verification operations while consuming limited computational resources. The system can leverage incremental hashing to verify digital signatures. Incremental hashing allows the signature verification object to generate a set of verification segments, which are combined to provide a verification artifact for verifying the digital signature. Verification segments can be combined within or outside the SE platform runtime environment while maintaining the quantum resistance of the digital signature, attributable to hash-based security protocols and the one-time use of the key pair.

[0034] Additionally or alternatively, the system can utilize incremental hashing to verify the authentication path. Incremental hashing allows the signature verification object to generate a set of hash segments, which are combined to provide an intermediate hash value for verifying the authentication path. The system can utilize incremental hashing to generate one or more intermediate hash values ​​for verifying the authentication path. Hash segments can be combined within or outside the SE platform runtime environment while maintaining the quantum resistance of the digital signature, attributable to hash-based security protocols and the one-time use of the key pair.

[0035] In one example, the specific digital signature protocol and / or algorithm used in the digital signature operation and / or signature verification option can be selected via one or more digital signature modules. These one or more digital signature modules can be provided by an application programming interface (API). The system can initiate an SE application object within the SE platform runtime environment, and this SE application object can access and execute one or more digital signature modules. Additionally or alternatively, the system can execute one or more digital signature modules within a logically secure element (LSE) of the SE platform runtime environment. Furthermore, one or more digital signature modules can be incorporated into one or more SE applications or applets located within a specific LSE, and the corresponding SE applications can execute the one or more digital signature modules within that specific LSE to perform the corresponding digital signature operation and / or signature verification operation.

[0036] In one example, various SE applications execute within a specific LSE of the SE platform runtime environment. One or more objects of an SE application can be executed using a specific LSE. In this way, digital signature operations are securely contained within a specific LSE. Alternatively or additionally, separate SE applications can be executed using separate LSEs, thereby isolating specific digital signature operations to their respective LSEs. Advantageously, the algorithms and parameters associated with the digital signature operations are securely retained within the SE platform runtime environment. Furthermore, in the event that an SE application or its algorithm or parameters are vulnerable or compromised, executing various SE applications within a separate LSE provides a guarantee that any resulting security exposure will be confined to the specific LSE where the vulnerability or compromise is located. Therefore, other SE applications and their algorithms and parameters remain securely contained within their respective LSEs.

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

[0038] 2. Example Message Exchange System

[0039] Now for reference Figure 1This describes an example message exchange system 100. The message exchange system 100 may include a set of computing entities 102, such as computing entity 102a, computing entity 102b, computing entity 102c, and / or computing entity 102n. One or more computing entities 102a-n may include a security module 104. Computing entity 102 may utilize security module 104 to exchange digitally signed and / or digitally signed messages with another computing entity 102. Additionally or alternatively, computing entities may utilize security module 104 to exchange encrypted messages with another computing entity 102, for example, as described in application '432'. In one example, computing entities utilize security module 104 to exchange digitally signed encrypted messages with another computing entity 102. Security module 104 may include an SE hardware component. The SE hardware component may be as described in reference... Figure 2A and Figure 2B The configuration is as described. Additionally or alternatively, the SE hardware components may be configured as described with reference to application '432'.

[0040] Computing entity 102 is configured to exchange digitally signed and / or digitally signed messages via a wired or wireless connection. In one example, computing entity 102 is configured to connect to one or more data communication networks 106. These one or more data communication networks 106 may include wireless networks 108 and / or wired networks 110. 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), Universal Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), 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 network. 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 can include cellular networks (e.g., 2G, 3G, 4G, or 5G mobile networks). Example IoT networks can include ultra-wideband networks, Matter networks, Zigbee networks, LoRa networks, or Sigfox networks.

[0041] Computing entity 102 can be a different device or a different component 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 equipment, routers, switches, controllers, access points, and / or browser devices.

[0042] In one example, system 100 includes at least one host device and at least one client device. The host device and / or client device may include, as referenced... Figure 1 The described configuration is computational entity 102. (See reference...) Figure 1 One or more of the computing entities 102 described can be host devices or client devices. In one example, the first computing entity 102 can operate as a host device relative to the second computing entity 102 and as a client device relative to the third computing entity 102.

[0043] In one example, the client device is 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 ETSI Smart Card Platform Project. A Subscriber Identity Module (SIM) card is an example of a UICC. In one example, the host device is configured as a smart card reader. In one example, the host device is a payment terminal, and the client device is a payment device, such as a payment card. In one example, system 100 includes one or more computing entities 102 as smart cards and one or more computing entities 102 as smart card readers. For example, computing entities 102a and / or 102b can be smart cards, and computing entity 102n can be a smart card reader.

[0044] In one example, the client device communicates with the host device via a contactless communication protocol. For example, computing entities 102a and 102b can communicate with each other via a contactless communication protocol. Additionally or alternatively, computing entity 102n can communicate with computing entities 102a and / or 102b via a contactless communication protocol. Example contactless communication protocols include GSM, CDMA, UMTS, LTE, GPRS, UMTS, BGAN, WLAN, PAN, LAN, MAN, WAN, IoT, or satellite communication protocols.

[0045] In one example, the host device includes a slot configured to receive a client device. For example, a client device configured as a payment card can be inserted into a slot of the host device configured as a payment terminal to communicatively couple the client device to the host device. As another example, the host device configured as a mobile communication device includes a slot configured to receive a client device configured as a SIM card, which can be inserted into the slot of the host device. For example, computing entity 102n may include slots configured to receive computing entities 102a and / or 102b. The host device and the client device can communicate with each other via a SIM card communication protocol, such as the ISO / IEC 7816 protocol, the TS 102 221 protocol, or a single-wire protocol.

[0046] In yet another example, the client device is configured to be wired to an embedded SE or eSIM card of the host device. For example, security module 104c may be an embedded SE or eSIM card wired to computing entity 102c. Additionally or alternatively, security module 104n may be an embedded SE or eSIM card wired to computing entity 102n. The host device and client device may communicate with each other via embedded communication protocols such as ISO / IEC 7816, ISO / IEC 14443, or GSMA Remote SIM Provisioning Protocol.

[0047] In yet another example, the client device is configured as an iSIM card integrated into the host device. The host device can be a system-on-a-chip device. For example, the security module 104c can be integrated into the computing entity 102c. Alternatively or additionally, the security module 104n can be integrated into the computing entity 102n. The host device and the client device can communicate with each other via integrated communication protocols, such as internally integrated circuit protocols, serial peripheral interface protocols, universal asynchronous receiver / transmitter protocols, or the ISO / IEC 7816 protocol.

[0048] As a further example, the client device can be configured to be at least one of the following: a payment card, access control card, ID card, electronic passport, security identification card, health insurance card, transportation card, secure USB token, IoT device, or mobile telecommunications device. The host device can be configured to exchange information with one or more client devices described herein.

[0049] 3. Example Digital Signature Algorithm

[0050] The computational entities described herein are configured to exchange digitally signed and / or digitally signed messages. To generate a digital signature for a message being transmitted from a sending computational entity to a receiving computational entity, the sending computational entity applies a hash function to the message to generate a message digest, and then digitally signs the message digest using a digital signature algorithm. The digital signature can be generated using one or more digital signature algorithms. In one example, the computational entity may choose a digital signature algorithm from a set of algorithms. The digital signature algorithm may include one or more quantum-resistant digital signature algorithms, one or more legacy digital signature algorithms, or a combination thereof.

[0051] A. Example of a quantum-resistant digital signature algorithm

[0052] In one example, the digital signature algorithm includes a quantum-resistant digital signature algorithm. As used herein, the term "quantum-resistant," when used in conjunction with a digital signature algorithm, refers to a digital signature algorithm designed to resist attacks by quantum computing devices or systems.

[0053] Examples of quantum-resistant digital signature algorithms include: hash-based digital signature algorithms, multivariate quadratic-based digital signature algorithms, lattice-based digital signature algorithms, or zero-knowledge proof-based digital signature algorithms, as well as combinations thereof.

[0054] Hash-based digital signature algorithms use cryptographic hash functions to generate digital signatures. The cryptographic hash functions in hash-based digital signature algorithms utilize a tree structure to derive multiple one-time private keys used to generate the digital signature. Example hash-based digital signature algorithms include one-time hash-based digital signature algorithms, stateful hash-based digital signature algorithms, or stateless hash-based digital signature algorithms, as well as combinations of these.

[0055] One-time hash-based digital signature algorithms generate digital signatures based on private keys designed for one-time use. Hash-based digital signature algorithms can be used as building blocks for more complex digital signature algorithms. Example one-time hash-based digital signature algorithms include: Leighton-Micali One-Time Signature (LM-OTS), Winderitz One-Time Signature (WOTS), or Winderitz One-Time Signature Enhancement (WOTS+).

[0056] Stateful digital signature algorithms utilize state information to manage the use of private keys. Example stateful digital signature algorithms include: the Extended Merkle Signature Scheme (XMSS), the Extended Merkle Signature Scheme Multitree (XMSSMT), the Leighton-Micali Signature Scheme (LMS), or an LMS algorithm with a short signature. Example stateful hash-based digital signature algorithms are further described in Cooper et al.'s "Recommendation for Stateful Hash-Based Digital Signature Scheme," published in NIST Special Publication 800-208, October 2020, by the Information Technology Laboratory of NIST, available at https: / / doi.org / 10.6028 / NIST.SP.800-208, the entire contents of which are hereby incorporated by reference. Example stateful hash-based digital signature algorithms are further described in “XMSS: eXtended Merkle Signature Scheme”, published by Huelsing et al. in Request for Comments No. 8391 of the Internet Research Task Force (IRFT) in May 2018. This document is available at https: / / www.rfc-editor.org / rfc / pdfrfc / rfc8391.txt.pdf, the entire contents of which are hereby incorporated by reference. Example stateful hash-based digital signature algorithms are further described in “Leighton-Micali Hash-Based Signatures”, published by McGrew et al. in Request for Comments No. 8554 of the IRFT in April 2019. This document is available at https: / / www.rfc-editor.org / rfc / pdfrfc / rfc8554.txt.pdf, the entire contents of which are hereby incorporated by reference. Example stateful hash-based digital signature algorithms are further described in “Additional Parameter sets for HSS / LMS Hash-Based Signatures”, published by Fluhrer et al. on September 18, 2023, in the Crypto Forum Research Group. The document is available at https: / / www.ietf.org / archive / id / draft-fluhrer-lms-more-parm-sets-11.html, the full contents of which are hereby incorporated by reference.

[0057] Stateless digital signature algorithms can be implemented without maintaining state information for managing the use of private keys. Example stateless digital signature algorithms include: Stateless Practical Hash-Based Excellent Cryptographic Signature (SPHINCS+), SPHINCS+ Gravity, SPHINCS+ Korean, and the NIST Stateless Digital Signature Algorithm (NIST SL-DSA). The example stateless hash-based digital signature algorithm is further described in the “Stateless Hash-Based Digital Signature Standard” published on August 24, 2023, in Federal Information Processing Standards Publication 205, by the National Institute of Information Technology (NIST), available at https: / / doi.org / 10.6028 / NIST.FIPS.205.ipd, the entire contents of which are hereby incorporated by reference.

[0058] Digital signature algorithms based on multivariate quadratic equations generate digital signatures by transforming the message into a system of multivariate quadratic equations. The private key determines the specific transformation used to generate the digital signature.

[0059] Lattice-based digital signature algorithms are cryptographic schemes that use operations within a high-dimensional lattice structure to generate digital signatures. A digital signature is generated by performing certain transformations on the lattice using a private key, and verified using a public key derived from the lattice structure.

[0060] Zero-knowledge proof-based digital signature algorithms generate digital signatures using zero-knowledge proofs. To generate a digital signature based on zero-knowledge proofs, a private key is used to produce a proof confirming the signature's legitimacy, and a public key is used to verify that proof. Zero-knowledge aspects ensure that even if the proof is observed, it does not expose the underlying private key or compromise the integrity of the signature.

[0061] B. Examples of legacy digital signature algorithms and hash functions

[0062] In one example, the digital signature algorithm includes a legacy digital signature algorithm. As used herein, the term "legacy," when used in conjunction with a digital signature algorithm, refers to a digital signature algorithm that is not specifically designed to resist attacks by quantum computing devices or systems. Legacy digital signature algorithms can include algorithms that have been used for a long time. A particular legacy digital signature algorithm may be suitable for some embodiments, even if that particular legacy digital signature algorithm may have known vulnerabilities in the context of a threat from a quantum computing system.

[0063] Examples of legacy digital signature algorithms include: Digital Signature Standard (DSA) algorithm, Rivest-Shamir-Adleman (RSA) algorithm, Elliptic Curve Digital Signature Algorithm (ECDSA) algorithm, Edwards Curve Digital Signature Algorithm (EdDSA) algorithm, or ElGamal algorithm.

[0064] C. Example Message Digest Hash Function

[0065] A message digest digitally signed using a digital signature algorithm can be generated by applying one or more hash functions to the message. In one example, the computational entity may choose a hash function from a set of hash functions. This hash function may include one or more quantum-resistant hash functions, one or more legacy hash functions, or a combination of these. Example hash functions include: secure hash algorithms (e.g., SHA-1, SHA-2 (e.g., SHA-256 or SHA-512), or SHA-3), message digest algorithms (e.g., MD5), or RACE integrity primitive evaluation message digest (RiPEMED-160).

[0066] 4. Example Computational Entity Architecture

[0067] Now for reference Figure 2A and 2B Further describe the architecture of example computation entity 200. In one example, refer to... Figure 1 A and Figure 1 The system 100 described in B may include, as referenced Figure 2A and Figure 2B The described configuration includes one or more computing entities. Computing entities may include... Figure 2A and Figure 2B The diagram shows more or fewer components. In one example, refer to... Figure 2A and Figure 2B One or more features of the described system 100 may be combined with one or more features of the '432 application.

[0068] like Figure 2A The system architecture of computing entity 200 shown includes SE hardware 202 and device host hardware 204. SE hardware 202 includes an SE processor 206 and a set of LSEs 208, such as LSE 208a and LSE 208n. SE hardware 202 also includes an SE software stack 210 and SE memory 212. Device host hardware 204 includes 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.

[0069] A. Security element hardware and device host hardware

[0070] In one example, SE hardware 202 may include a microprocessor-based chip that includes 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 other types of integrated circuit cards (ICCs) and tamper-proof security chips for controlling access to secure resources.

[0071] In one example, SE hardware 202 represents at least a portion of an SE platform. 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.

[0072] In one example, SE processor 206 is a microprocessor used to execute the SE platform runtime environment and SE applications. The example SE platform runtime environment is the Java Card Runtime Environment (JCRE). JCRE provides a lightweight version of the Java Runtime Environment (JRE) tailored for smart cards and other tamper-proof security chips, allowing these SE hardware platforms to host SE applications, for example, using Java technology. The SE processor and / or JCRE can represent part of the SE platform. For example, JCRE can execute SE applications on SE processor 206 and / or on one or more LSEs 208. JCRE can provide an execution environment for SE applications. JCRE can perform operations associated with SE applications, including, for example, loading and unloading SE applications, scheduling SE application execution, SE application isolation and security, SE application memory management, and / or interaction between SE applications and underlying hardware.

[0073] 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 digital signature operations to be performed. The digital signature operations may include digital signature operations associated with generating digital signatures used to ensure the authenticity, integrity, and / or non-repudiation of messages exchanged between computing entity 200 and another computing entity. The digital signature operations can be performed by executing one or more SE applications within the SE platform runtime environment. In one example, the digital signature operations include operations related to generating digital signatures, such as those described in reference [reference needed]. Figures 3A-3FAs described. Additionally or alternatively, digital signature operations may include operations related to verifying digital signatures, such as those described in the reference. Figures 4A-4H As described.

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

[0075] SE hardware 202 operates multiple LSEs 208a-n, which, from the perspective of a mobile device user, can operate as if multiple Secure Element chips were installed within computing entity 200. For example, LSEs 208a-n can operate as if multiple embedded and / or removable SIM cards were currently operating within computing entity 200. Therefore, LSEs 208a-n can correspond to shared virtual SIM cards and / or other tamper-proof chips running from the same SE hardware component. 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. This isolation mechanism can be separate from and different from the JCRE firewall mechanism mentioned earlier. A firewall mechanism can be applied to a given LSE to maintain separation between different applets installed on the same LSE. Isolation mechanisms can also be implemented at a lower level to maintain isolation between different LSEs, where each LSE can be configured with its own firewall.

[0076] SE software stack 210 may include a set of components for executing SE applications. SE software stack 210 may include code, referred to herein as SESS code, that executes applets and provides a runtime environment for the applets. In some embodiments, SE software stack 210 may include protocol handler firmware 226, access control module 228, and Java Card API (JCAPI) 230. Additionally or alternatively, SE software stack 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 is different 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 applets. Additionally or alternatively, 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 currently running within the runtime environment. SESS code can be generic for LSE 208-an to optimize size and reduce processing overhead.

[0077] In some embodiments, protocol handler firmware 226 is low-level firmware used by the SESS code to manage operations targeting 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 also be integrated into other runtime environments or exist independently.

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

[0079] 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 the message is not successfully verified as originating from an authorized entity that triggered the requested operation, access control module 228 may block the requested operation.

[0080] 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) may vary between different LSEs to provide data integrity and isolation. In some embodiments, SE memory 212 securely stores data for LSE 208a-n.

[0081] 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 transmitting messages from device host hardware 204 to SE hardware 202.

[0082] In some embodiments, modem 216 is a mobile broadband modem that sends and receives messages via a mobile broadband connection. For example, operators, including mobile network operators (MNOs) and mobile virtual network operators (MVNOs), can wirelessly send network messages to mobile phones via a cellular network through modem 216. Different LSEs can be targeted based on which mobile phone operator sent the message. 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 may include payment processing, biometric authentication, identity management, and mobile network communications.

[0083] In some embodiments, the NFC controller 218 receives near-field wireless messages from an external device. NFC communication can transmit data via inductive coupling between the external device and an antenna in the NFC controller 218 when placed within a threshold distance. NFC messages can trigger operations in the LSE. For example, a payment terminal can generate an NFC message 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 include one or more applets for processing secure transactions initiated by 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.

[0084] 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 access to resources already mapped to the LSE.

[0085] The device host hardware 204 may also include a host processor 222 and host memory 220 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 host processor 222 and host memory 220 may be physically separated from the SE hardware 202 to prevent attacks if the security of computing entity 200 is compromised. The SE hardware 202 may prevent the host processor 222 from accessing secure data stored in the SE memory 212. Requests to access this data may be routed via protocol handler firmware 226.

[0086] 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 located outside 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.

[0087] 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 that can execute JCRE 240 and JCVM 242. JCRE 240 and / or JCVM 242 may be implemented as firmware. JCRE 240 and JCVM 242 can work together to provide a secure and controlled environment for executing SE applications. JCRE 240 can interact with the underlying components of the SE hardware 202 to manage the execution of SE applications. JCRE 240 can provide features to support 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 can execute the bytecode instructions of the SE applications.

[0088] B. Digital Signature API

[0089] As in Figure 2BAs further shown, SE hardware 202 may include an SE software stack 210 containing a digital signature API 248. The digital signature API 248 may include a set of one or more digital signature modules 250, which one or more SE applications may use to perform digital signature operations. Various parameters utilized by the set of one or more digital signature modules 250 may be configured, for example, based on one or more user inputs and / or based on a selected operating mode. The one or more digital signature modules of the digital signature API 248 may be contained within JCRE 240 and / or LSE 208 (…). Figure 2A The SE application within JCRE 240 is executed. In one example, a set of digital signature operations can be performed by executing one or more SE applications within JCRE 240. Figure 2B As shown, the Digital Signature API 248 can initialize an SE application object 252 within a JCRE 240. The SE application object 252 can include an SE application configured to execute one or more digital signature modules 250 within the JCRE 240. The SE application object 252 can import one or more digital signature modules from the digital signature modules 250 from the Digital Signature API 248 to access and execute those modules within the JCRE 240. Additionally or alternatively, a set of digital signature operations can be performed by executing one or more SE applications within a specific LSE 208. In one example, the SE application object 252 can instruct a specific SE application within a specific LSE 208 to import one or more digital signature modules 250 and execute those modules within the specific LSE 208. The SE application object 252 can access one or more digital signature modules 250 of the Digital Signature API 248, and those modules 250 can be executed by an SE application such as within an LSE 208.

[0090] like Figure 2B As shown, the group of one or more digital signature modules 250 may include at least one of the following: a signature generation module 254, a signature verification module 256, a result checking module 258, or a message digest generation module 260. The signature generation module 254 includes operations that can be performed by an SE application object to generate a digital signature. The signature verification module 256 includes operations that can be performed by an SE application object to verify a digital signature. The result checking module 258 includes operations that can be performed by an SE application object to check the result generated by the digital signature operations. The message digest generation module 260 includes operations that can be performed by an SE application object to generate and / or identify a message digest for the message used in the digital signature operations.

[0091] The signature generation module 254 may include one or more of the following: a key generation submodule 262, a signature submodule 264, or an authentication path generation submodule 266. The key generation submodule 262 includes operations that can be executed by an SE application object to generate a private key, public key, and / or key pair used in the digital signature operation. The key pair may include a one-time key pair used according to a hash-based signature protocol. The signature submodule 264 includes operations that can be executed by an SE application object to generate a digital signature using the private key of the key pair by performing a signature generation algorithm according to a digital signature protocol. The authentication path generation submodule 266 includes operations that can be executed by an SE application object to generate an authentication path corresponding to the key pair used for the digital signature.

[0092] In one example, a hash-based signature protocol utilizes a set of one-time key pairs. A specific one-time key pair is used once to generate a digital signature. Key generation submodule 262 includes operations for tracking the use of one-time key pairs, such as identifying a specific one-time key pair to be used for a specific digital signature, ensuring that the specific one-time key pair is used once and not reused, and / or determining whether the set of one-time key pairs has additional one-time key pairs, or whether these one-time key pairs have been fully utilized. The set of one-time key pairs is associated with a set of leaf nodes in a tree structure. A specific one-time key pair is associated with a specific leaf node in the tree structure. In one example, a specific leaf node in the set of nodes includes a specific public key for a specific one-time key pair. Additionally or alternatively, a specific leaf node in the set of nodes includes a hash value corresponding to the specific public key. The tree structure includes a root node. The root public key or the hash value corresponding to the root public key is associated with the root node of the tree structure. The authentication path includes a sequence of hash values ​​associated with nodes in the tree structure, which are used to recalculate the root public key. The authentication path generation submodule 266 includes operations that can be performed to determine a sequence of hash values ​​for the authentication path. The authentication path allows the recipient of a digital signature to verify that the one-time key pair used for the digital signature is associated with a leaf node of a tree structure rooted at the root public key. The root public key is a hash value representing the tree structure. The tree structure includes a set of intermediate nodes containing a set of child nodes. The intermediate hash value associated with an intermediate node is computed by performing a hash function on the concatenation of that set of child nodes of the intermediate node.

[0093] In one example, the tree structure is defined by a set of parameters associated with the digital signature protocol. This set of parameters can be maintained in SE hardware 202 ( Figure 2AThe persistent storage of the tree structure. This parameter set can include one or more of the following: hash length, hash function, public key seed, private key seed, Winternitz parameter, height of the tree structure, or number of layers or subtrees in the tree structure. Hash length can define the length of one or more of the following: digital signature element, public key, private key, or hash value corresponding to a node in the tree structure. The hash function can be used to compute the node values ​​of the tree structure. The public seed can be used to generate pseudo-random values ​​for the tree structure. The private seed can be used to generate the private key for a one-time key pair. The Winternitz parameter is a parameter that balances the trade-off between signature size and computational efficiency. The total number of leaf nodes in the tree structure is based on the height of the tree structure. The tree structure can include one or more layers or subtrees. In one example, the XMSS algorithm utilizes a single tree structure. In one example, the XMSSMT algorithm utilizes multiple tree structures.

[0094] The signature submodule 264 can implement a digital signature protocol that includes one or more digital signature algorithms. The digital signature protocol may include a hash-based signature protocol that includes one or more hash-based digital signature algorithms. The hash-based signature protocol may include a stateful hash-based signature protocol, a stateless hash-based signature protocol, or a one-time hash-based signature protocol. A stateful hash-based signature protocol may include one or more stateful hash-based digital signature algorithms. A stateless hash-based signature protocol may include one or more stateless hash-based digital signature algorithms. A one-time hash-based signature protocol may include one or more one-time hash-based digital signature algorithms. A particular digital signature protocol can be selected from a set of digital signature protocols. Additionally or alternatively, a particular digital signature algorithm included in the digital signature protocol may be selected from a set of digital signature algorithms. Example digital signature algorithms are further described in Section 3 above, titled "Example Digital Signature Algorithms".

[0095] One or more digital signature protocols and / or one or more digital signature algorithms can be incorporated into the signature generation module 254. The one or more digital signature protocols and / or one or more digital signature algorithms can be accessed and utilized by the SE application object 252 to perform digital signature operations. Additionally or alternatively, the SE application object 252 can enable various applets to perform different digital signature operations, for example, within one or more LSEs 208.

[0096] The signature verification module 256 may include a signature verification submodule 268 and / or an authentication path verification submodule 270. The signature verification submodule 268 includes operations for verifying digital signatures. These operations may include calculating an operation to verify the artifact by applying a verification protocol corresponding to the digital signature protocol used to generate the digital signature. The authentication path verification submodule 270 includes operations for verifying authentication paths. These operations may include calculating a root hash value corresponding to the root of the tree structure corresponding to the digital signature protocol used to generate the digital signature.

[0097] The message digest generation module 260 may include operations that can be performed by an SE application object to generate a message digest for a message. Additionally or alternatively, the message digest generation module 260 may include operations that can be performed by an SE application object to receive a message digest generated outside the SE platform runtime environment. The message digest may include a fixed-size digital representation of the message's content. The message digest is generated by applying a hash function to the message. In one example, digitally signing the message digest instead of the message itself reduces computational overhead and / or ensures the digital signature has a fixed length. Additionally or alternatively, for example, when the message content is relatively small, the message may be digitally signed.

[0098] In one example, the result checking module 258 performs one or more result checking operations on the results of one or more digital signature operations. In one example, the result checking operation may include determining that the result of a particular digital signature operation has a length that meets one or more criteria. These 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 digital signature operation fails to meet these one or more criteria, the result checking module 258 may determine that a security vulnerability and / or data processing error has occurred. In one example, the result checking operation verifies whether the length of the hash value generated by the digital signature operation matches the length specified in the parameter set. The length of the hash value generated by the digital signature may depend on the digital signature protocol used to generate the hash value. The hash value checked by the result checking operation may include a public key, a private key, a digital signature, or a node in a tree structure.

[0099] In one example, the digital signature API 248 includes a Temporary Entry Point Object (TEPO) module 272. 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, the SE application object 252 can invoke the TEPO module 272 to generate a transient object handle that points to an object utilized by the SE application object 252 in a digital signature operation. The TEPO module 272 can be used to avoid persistent memory writes of data associated with a digital signature operation. In one example, the transient object handle can point to the output of a first digital signature operation used as input to a second digital signature operation. In one example, the TEPO module can generate transient object handles for use in incremental hashing processes used to generate and / or verify digital signatures. The transient object handle can point to a first segment stored in transient memory after being generated by the incremental hashing process. The first segment can be combined with the second segment, for example, by accessing the first segment from transient memory via a transient object handle. In one example, the TEPO module can generate a transient object handle for generating an authentication path. The transient object handle can point to a first hash value of the authentication path, which is stored in transient memory after being generated by the authentication path generation submodule 266. The authentication path generation submodule 266 can access the first hash value via the transient object handle to combine it with a second hash value of the authentication path. Additionally or alternatively, the TEPO module can generate a transient object handle for verifying the authentication path. The transient object handle can point to a first intermediate hash value, which is stored in transient memory after being generated by the authentication path verification submodule 270. The authentication path verification submodule 270 can access the first intermediate hash value via the transient object handle to generate subsequent intermediate hash values. By using the TEPO module 272 to generate transient object handles, the SE platform runtime environment ensures that it can read and manipulate objects in transient memory without writing changes back to persistent memory. This avoids unnecessary writes to persistent memory, which improves the security and efficiency of digital signature operations.

[0100] In one example, the digital signature API 248 may include a Shared Interface Object (SIO) module 274. The SIO module 274 may be executable to generate one or more SIOs that facilitate secure communication and interaction between different SE applications. Individual SE applications may be logically isolated, for example, within LSE 208, to prevent unauthorized access to their respective 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 mechanism, SE applications may be required to have appropriate permissions to access and use SIOs.

[0101] In one example, various parameters that can be configured for use by one or more digital signature modules in digital signature module 250 may include the selection of one or more specific algorithms to be utilized by one or more digital signature modules in digital signature module 250. In one example, the one or more specific algorithms to be utilized by the one or more digital signature modules 250 may be determined based on the operation mode passed to digital signature API 248. Additionally, the private and public keys to be utilized by the respective digital signature modules 250 of digital signature API 248 may be passed to the respective digital signature modules 250 of digital signature API 248 in a "raw" format (such as as byte arrays), thereby allowing the keys to be directly transferred to the operations performed by the respective digital signature modules 250 of digital signature API 248. Additionally or alternatively, a random data generation object may be passed to digital signature API 248.

[0102] 5. Example digital signature operation

[0103] Now for reference Figures 3A-3F and Figures 4A-4H This describes example operations related to generating and verifying digital signatures. (Reference) Figures 3A-3F Describes example operations related to generating digital signatures. (Reference) Figures 4A-4H Describe example operations related to verifying digital signatures. (Reference) Figures 3A-3F and Figures 4A-4H The described operations can be referenced. Figure 1 One or more components of the described system 100 and / or utilizing references Figure 2A and Figure 2B The computational entity 200 described herein may be executed by one or more components. For example, the operation may be performed within an SE platform runtime environment, such as one or more LSEs within the SE platform runtime environment. (See reference) Figures 3A-3F and Figures 4A-4H One or more operations described may be modified, rearranged, or omitted entirely. Accordingly, refer to... Figures 3A-3F and Figures 4A-4H The specific sequence of operations described should not be construed as limiting the scope of one or more embodiments. In one example, reference... Figures 3A-3F and Figures 4A-4H The one or more operations described may be combined with one or more operations described in reference '432 application'.

[0104] A. Example signature generation operation

[0105] refer to Figures 3A-3F The example signature generation operation 300 is further described. Figure 3A As shown, the system receives a selection of a digital signature protocol from a set of digital signature protocols for digitally signing messages (operation 302). The digital signature protocol can be a hash-based digital signature protocol. The digital signature protocol can be selected based on input from the computing entity. The input from the computing entity can include input from an input device representing a user selection. The system can receive the selection via the SE interface. Additionally or alternatively, the digital signature protocol can be selected based on one or more parameters associated with the computing entity, such as one or more parameters associated with the SE platform runtime environment.

[0106] Additionally or alternatively, the system receives a request to generate a digital signature for the message (operation 304). The request to generate a digital signature may be based on input from a computing entity. Input from the computing entity may include input from an input device representing user input. The system may receive the request via the SE interface. Additionally or alternatively, the request may be initiated based on one or more operations associated with the computing entity (such as one or more operations associated with the SE platform runtime environment). In one example, the request to generate a digital signature may be generated in conjunction with the generation and / or receipt of a message.

[0107] In at least a partial response to the request, the system generates a digital signature for the message using a digital signature protocol (Operation 306). See below for reference. Figures 3B-3F The operations related to generating a digital signature are further described. After a digital signature has been generated, the system transmits the digital signature to a hardware device (operation 308). In one example, the system transmits the digital signature from a first part of the computational entity that generated the digital signature to a second part. For example, the system may transmit the digital signature from SE hardware to device host hardware. Additionally or alternatively, the system may transmit the digital signature from a first computational entity to a second computational entity. The first and second computational entities may represent different devices and / or different components of the same device. In one example, the system, for example, refers to... Figures 4A-4H The described one or more signature verification operations transmit the digital signature to the computational entity that verifies the digital signature.

[0108] i. Generate digital signatures

[0109] refer to Figure 3B The document further describes operations 300 related to generating digital signatures. In one example, refer to... Figure 3B One or more of the operations described may be included in the reference. Figure 3A The operation described in 306. For example... Figure 3B As shown, to generate a digital signature, the system initializes at least one SE application object in the SE platform runtime environment (operation 310). The system can utilize the digital signature API to initialize one or more SE application objects. The SE application object initialized in the SE platform runtime environment includes a signature generation element for generating the digital signature. The SE application object is executed in the SE platform runtime environment to perform one or more digital signature operations for generating the digital signature. The digital signature can be a hash-based digital signature. The system can utilize a specific SE application object to perform multiple digital signature operations. Additionally or alternatively, the system can utilize multiple SE application objects to perform different digital signature operations.

[0110] The system obtains the message digest to be digitally signed via the SE application object (Operation 312). The message digest is a fixed-size digital representation (hash) of the message content. The message digest is generated by applying a hash function to the message. In one example, the message digest is generated outside the SE platform runtime environment. In one example, the computing entities include SE hardware and device host hardware. The message digest can be generated by the device host hardware and transmitted to the SE hardware. Additionally or alternatively, the SE application object can generate the message digest. The message digest can be stored in the persistent or transient memory of the SE hardware. The SE application object can identify and access the message digest based on commands from the Digital Signature API. Commands can be provided in the form of Application Protocol Data Units (APDUs). In one example, the system identifies and accesses the message digest based on one or more commands, such as APDUs from the signature generation module of the Digital Signature API. Based on one or more commands, the system extracts specific bytes or segments from a command buffer, such as an Application Protocol Data Unit (APDU) buffer. Additionally or alternatively, the system can access the message digest based on object fields or arrays identified through an index or parameter of the signature generation module of the Digital Signature API.

[0111] In one example

[0112] The system determines the digital signature protocol (Operation 314) used to generate the digital signature for the message digest via the SE application object. The digital signature protocol may include hash-based signature protocols. The SE application object determines the digital signature protocol based on commands from the digital signature API (such as a signature generation module from the digital signature API). Commands may be provided in the form of APDUs. Commands may include specific instructions specifying the digital signature protocol to be utilized. Based on one or more commands, the system follows the digital signature protocol when performing digital signature operations, thereby ensuring that correct operations are performed according to the specific digital signature protocol.

[0113] In one example, before performing an operation according to a specific digital signature protocol, the system verifies that the digital signature protocol is supported by the digital signature API. The system can determine whether it supports the digital signature protocol by comparing it to a list of supported digital signature protocols. When the system determines that the digital signature protocol is supported, it proceeds with the digital signature operation to generate a digital signature according to that protocol. When the system determines that the digital signature protocol is not supported, it can throw an error or generate an error message. Additionally or alternatively, the system can initiate a set of operations to add the unsupported digital signature protocol to the list of supported digital signature protocols.

[0114] After the digital signature protocol for generating the digital signature has been determined, the system determines a key pair, including a private key and a public key, via an SE application object for generating the digital signature according to the digital signature protocol (operation 316). In one example, the system uses the SE application object to identify the key pair already generated for the digital signature to be generated. In one example, the system uses a first SE application object to generate the key pair and a second SE application object to generate the digital signature. In one example, the key pair is a one-time key pair corresponding to a tree structure associated with the hash-based signature protocol. See below for reference. Figure 3C Further describe the operations related to generating key pairs.

[0115] After the key pair used to generate the digital signature has been determined, the system generates an authentication path corresponding to that key pair via the SE application object (operation 318). The authentication path includes a sequence of hash values ​​associated with nodes in the tree structure, which are used to recalculate the root hash value or root public key corresponding to the root node of the tree structure. The authentication path includes the public key corresponding to the key pair used to generate the digital signature. This public key corresponds to the first leaf node of the tree structure as defined according to the hash-based signature protocol. Additionally, the authentication path includes the hash value corresponding to the second leaf node, which is a sibling node of the first leaf node. Additionally, the authentication path includes one or more sets of hash values ​​corresponding to one or more intermediate nodes of the tree structure. The root public key or root hash value can be calculated based on the authentication path. See below for reference. Figure 3D Further describe the operations related to generating the authentication path.

[0116] After the key pair used to generate the digital signature has been determined, and / or after the authentication path corresponding to the key pair has been generated, the system uses the SE application object to generate a digital signature for the message (Operation 320). To generate the digital signature, the system uses the private key of the key pair to perform a signature generation algorithm on the message digest according to the digital signature protocol. See below for reference. Figure 3E and Figure 3F Further describe the operations related to generating digital signatures.

[0117] ii. Generate key pairs

[0118] refer to Figure 3C The document further describes operation 300 related to generating a key pair for digital signature operations. In one example, refer to... Figure 3C The described one or more operations may be included in the reference Figure 3B The operation described in 316. For example... Figure 3C As shown, to generate a key pair, the system accesses a key pair index (operation 322) that indicates the utilization status of a set of key pairs associated with a digital signature protocol. This key pair index may include an index value that identifies the next available key pair in the set. In one example, the key pair index identifies a leaf node of a tree structure associated with a hash-based signature protocol. The system can generate a key pair corresponding to a leaf node based on the key pair index. As a key pair is utilized, the system can increment the index value to indicate the next available key pair and / or a leaf node of the key structure corresponding to the next available key pair. When the system uses the key pair to generate a digital signature, the system may include the index value along with the digital signature. The index value may be appended to the digital signature or provided separately in association with the digital signature. When the system transmits the digital signature and index value to a receiving computational entity for verification, the receiving computational entity uses the index value to retrieve the public key used to verify the digital signature.

[0119] The system determines whether the key pair index indicates that the key pair can be used to generate a digital signature (operation 324). In one example, the key pair index may include a value specifying whether the key pair is available. In one example, the set of key pairs may include (N) key pairs corresponding to (N) leaf nodes of the tree structure. The index value (V) of the key pair index can indicate whether the key pair is available. When the key pair is available, the index value (V) is less than (N). When the key pair is unavailable, for example because the set of key pairs has already been used, then the index value (V) is equal to the number of key pairs (N).

[0120] When the system determines that a key pair can be used to generate a digital signature based on the key pair index, the system determines the next available key pair in that set (operation 326). In one example, the system determines the index value (V) of the key pair index, and based on the index value (V), the system determines the leaf node of the tree structure that identifies the next available key pair. Additionally, the system increments the index value (V) of the key pair index to the next index value (V+1) to indicate that the next available key pair is being used to generate a digital signature (operation 328).

[0121] The system determines a set of parameters corresponding to the digital signature protocol for generating key pairs (Operation 330). This parameter set may include one or more parameters used to generate the key pairs. These parameters may include one or more of the following: hash length, hash function, public key seed, private key seed, Winternitz parameter, height of the tree structure, or the number of levels or subtrees in the tree structure. The system can access the parameter set in the persistent memory of the SE hardware. The system can access the parameter set based on commands, such as APDUs from the key generation module of the digital signature API. Based on one or more commands, the system can access the parameter set by extracting specific bytes or segments from a command buffer, such as an APDU buffer. Additionally or alternatively, the system can access the parameter set based on object fields or arrays identified by the key generation module of the digital signature API.

[0122] After accessing the parameter set corresponding to the digital signature protocol, the system executes a key generation algorithm to generate a key pair (Operation 332). To generate the key pair, the system generates a private key and a public key. The private key is generated based on a private key seed, and the public key is generated based on a public key seed. The public and private key seeds are generated based on a master seed. The system can generate a pseudo-random seed by applying a pseudo-random function to the private key seed, and then generate the private key of the key pair by applying a hash function to the pseudo-random seed. The system can also generate a pseudo-random seed by applying a pseudo-random function to the public key seed, and then generate the public key of the key pair by applying a hash function to the pseudo-random seed. The pseudo-random function used to generate the pseudo-random seed can include a keyed hash function or a cryptographic key derivation function. An example keyed hash function is a hash-based Message Authentication Code (HMAC) function. An example cryptographic key derivation function is an HMAC-based Key Derivation Function (HKDF). The hash function applied to the pseudo-random seed can include a secure hash algorithm or other hash algorithms described above.

[0123] The system generates metadata that associates key pairs with leaf nodes of a tree structure. This metadata can identify leaf nodes by node number or index number. The metadata can be embedded in the public and private keys. Alternatively, the metadata can be stored in association with the public and private keys. The metadata ensures that the private key can be used once to generate a digital signature associated with a leaf node and ensures that the public key can be used to verify the digital signature.

[0124] Referring again to operation 324, when the system determines, based on the key pair index, that the key pair cannot be used to generate a digital signature, the system determines that the key pair has been exploited (operation 334). In response to determining that the key pair has been exploited, the system initiates the execution of a key pair exhaustion protocol (operation 336). In one example, the key pair exhaustion protocol includes throwing an exception indicating that the key pair has been exploited and / or the key pair cannot be used to generate a digital signature. Additionally or alternatively, the key pair exhaustion protocol may include generating or obtaining a new master seed, a new private seed, and / or a new public seed for generating a new set of key pairs. The system may generate the master seed based on a physical random source and / or a pseudo-random number generator.

[0125] iii. Generate authentication path

[0126] refer to Figure 3D The document further describes operations 300 related to generating the authentication path corresponding to the key pair used for generating and authenticating digital signatures. In one example, refer to... Figure 3D One or more of the operations described may be included in the reference. Figure 3B The operation described in 318. For example... Figure 3D As shown, to generate an authentication path, the system initializes an SE application object (operation 338) in the SE platform runtime environment, including authentication path generation elements for generating authentication paths for digital signatures. The SE application object executes in the SE platform runtime environment to perform one or more digital signature operations for generating the authentication path. The system may utilize the same SE application object for generating the authentication path, key pair, and digital signature. Alternatively, the system may utilize a first SE application object to generate the authentication path and at least a second SE application object to generate the key pair and digital signature.

[0127] The system determines a parameter set corresponding to the digital signature protocol, which is used to generate a key pair for digital signatures (Operation 340). This parameter set may include parameters as referenced above. Figure 3CAt least a portion of the parameters described for generating the key pair. In one example, the parameter set includes one or more parameters defining at least a portion of the tree structure corresponding to the digital signature protocol. In one example, the parameter set includes the height of the tree structure and / or the number of leaf nodes in the tree structure. Additionally, the system determines the public key of the key pair and the leaf nodes of the tree structure corresponding to the digital signature protocol associated with that public key (operation 342). The system can determine the public key from persistent or transient memory of the SE hardware. The system can determine the leaf nodes based on metadata associated with or embedded in the public key.

[0128] Based on the parameter set, the system generates a set of hash values ​​for the authentication path. As the system generates hash values ​​for the authentication path, these hash values ​​are incrementally added to the authentication path, for example. With the generation of additional hash values ​​for the authentication path, the authentication path and / or hash values ​​can be stored in persistent or transient memory of the SE hardware. Initially, the system selects a leaf node as the current node of the tree structure, and the system selects the public key corresponding to the leaf node as the current hash value corresponding to the current node (operation 344). The system adds the current hash value of the current node to the authentication path (operation 346). The system determines the sibling node of the current node (operation 348). Initially, since the current node is the leaf node corresponding to the key pair, the sibling node is another leaf node. In one example, the first leaf node is the current node, and the second leaf node is the sibling node. The system determines the sibling node based on the parameter set. The system generates a sibling hash value for the sibling node at least by applying a hash function to the data elements of the sibling node (operation 350). In one example, when the sibling node is a leaf node, the sibling hash value is the public key corresponding to that sibling node. The system can generate sibling node data elements by applying a pseudo-random function to a public key seed determined from the parameter set to generate a pseudo-random seed. The sibling node data elements can be the pseudo-random seed. The system can generate a sibling hash value by applying a hash function to the pseudo-random seed, for example, in a manner similar to generating the public key. After the sibling hash value has been generated, the system adds the sibling hash value to the authentication path (Operation 352). See below for reference. Figure 3D Further described, the system adds additional sibling hash values ​​to the authentication path to provide a set of hash values ​​sufficient to compute the root hash value corresponding to the root node of the tree structure.

[0129] like Figure 3DAs shown, the system determines whether the parent node of the current node and its sibling nodes is the root node of the tree structure (operation 354). The determination of whether the parent node is the root node indicates whether to add additional nodes to the authentication path. When the parent node is the root node, the root node can be calculated based on the current hash value corresponding to the current node and the sibling hash value corresponding to the sibling node. When the parent node is not the root node, the system continues to add additional hash values ​​to the authentication path to provide a set of hash values ​​sufficient to calculate the root hash value. The system can determine whether the parent node is the root node of the tree structure based on the height of the tree structure and the level of the tree structure corresponding to the current node, sibling nodes, and / or parent node. When the level of the tree structure corresponding to the parent node matches the height of the tree structure, the system can determine that the parent node is the root node. When the level of the tree structure corresponding to the parent node is less than the height of the tree structure, the system can determine that the parent node is not the root node.

[0130] When the system determines that the parent node of the current node and its sibling nodes is not the root node of the tree structure, the system generates a parent hash value for the parent node by at least concatenating the current hash value and the sibling hash value and applying a hash function (operation 356). The system concatenates the current hash value and the sibling hash value to obtain this concatenation. The system applies a hash function to the concatenation obtained by concatenating the current hash value and the sibling hash value. The parent hash value represents the intermediate hash value corresponding to an intermediate node in the tree structure. The tree structure may include one or more intermediate nodes. The number of intermediate nodes depends on the height of the tree structure.

[0131] The system selects a parent node as the current node, and selects a parent hash value (e.g., an intermediate hash value) as the current hash value corresponding to the current node (operation 358). After selecting a parent node as the current node and a parent hash value as the current hash value, the system returns to operation 346, where the system adds the current hash value to the authentication path. Because the system has already selected a parent hash value (e.g., an intermediate hash value) as the current hash value, it adds the parent hash value (e.g., an intermediate hash value) to the authentication path. An additional parent hash value (e.g., an additional intermediate hash value) is added to the authentication path as the current hash value for continuous iteration of operation 346. Continuing with the current hash value of the parent hash value added to the authentication path, the system determines the sibling node of the current node (operation 348). Because the system has already selected a parent node (e.g., an intermediate node) as the current node, it determines the sibling node of the parent node (e.g., the sibling node of the intermediate node). The system determines the sibling node based on a set of parameters. The system generates a sibling hash value for the sibling node by applying a hash function to the data elements of the sibling node (operation 350). When the sibling node is a parent node (e.g., an intermediate node), the sibling hash value is the intermediate hash value corresponding to that sibling node. The system can generate an intermediate hash value corresponding to the sibling node by applying a hash function to the concatenation of the sibling node's child hash values. The child hash values ​​can be generated based on consecutive child nodes and / or leaf nodes located below the sibling node in the tree structure. After the sibling hash value has been generated, the system adds the sibling hash value to the authentication path (operation 352). After the sibling hash value has been added to the authentication path, the system again determines whether the parent node of the current node and the sibling node is the root node of the tree structure. When the system determines that the parent node of the current node and the sibling node is the root node of the tree structure, the system determines that the authentication path includes a set of hash values ​​sufficient to compute the root hash value (operation 360).

[0132] iv. Incrementally generate digital signatures

[0133] refer to Figure 3E and Figure 3F The document further describes operations 300 related to generating digital signatures using incremental hashing. In one example, refer to... Figure 3E and / or Figure 3F One or more of the operations described may be included in the reference. Figure 3B The described operation is in 320. For example... Figure 3EAs shown, in order to generate a digital signature using incremental hashing operations, the system determines the signature length corresponding to the digital signature (operation 362). The system may determine the signature length based at least in part on the private key used to generate the digital signature for the message digest according to the digital signature protocol. Additionally or alternatively, the system may determine the signature length based at least in part on the hash function used to generate the digital signature.

[0134] The length of a digital signature depends on the specific algorithm used to generate it. In one example, the system determines the signature length based on the key length of the private key used to generate it. This length can be expressed in bits or bytes. In one example, for the RSA algorithm, the signature length is directly related to the length of the private key (in bytes). In one example, for a 2048-bit RSA key, the signature length is 2048 bits, or 256 bytes. As another example, for the DSA algorithm, the signature length is determined by the private key's key length and the hash function used in the algorithm. In one example, for a 2048-bit DSA key paired with the SHA-256 algorithm, the signature length is 512 bits (64 bytes).

[0135] The system determines the signature segment length, representing a portion of the signature length, at least in part based on the signature length (Operation 364). In one example, the signature segment length is determined by dividing the signature length by a divisor that ensures the signature segment length satisfies at least one threshold. In one example, the at least one threshold includes an upper limit threshold. This upper limit threshold may represent the maximum signature segment length. Additionally or alternatively, the at least one threshold includes a lower limit threshold. The lower limit threshold may represent the minimum signature segment length. In one example, the signature segment length and / or one or more thresholds for the signature segment length are determined at least in part based on the key length of the private key and / or the hash function used to generate the digital signature.

[0136] After the signature segment length has been determined, the system provides a buffer with a length corresponding to the segment length (operation 366). The system uses this buffer to generate a signature segment representing a portion of the digital signature (operation 368). To generate the signature segment, the system performs a digital signature protocol on a portion of the message digest using a private key. The signature segment is generated in the buffer. When the signature segment reaches its length, the system outputs the signature segment (operation 370) and flushes the buffer (operation 372). The signature segment can be output to a memory element of the SE hardware for temporary storage before combining a set of signature segments, for example, as referenced below. Figure 3FFurther described. Additionally or alternatively, the signature segments may be output to a location outside the SE hardware. The system may combine the set of signature segments at a location outside the SE hardware. In one example, the SE hardware represents a first part of the computing entity, and the signature segment is output to a second part of the computing entity separate from the SE hardware. In one example, the second part of the computing entity includes device host hardware. In one example, the signature segment is output to the device host hardware. In one example, the set of signature segments is combined in the device host hardware to provide a digital signature. In one example, the signature segments are transferred from a first computing entity (such as from the device host hardware of the first computing entity) to a second computing entity. In one example, the second computing entity combines the signature segments to obtain a digital signature. In one example, the second computing entity may be the entity requesting the digital signature. Additionally or alternatively, the second computing entity may verify the digital signature.

[0137] After the signature segment has been output and the buffer has been flushed, the system increments the signed length corresponding to the generated portion of the digital signature by adding the signature segment length to the signed length (operation 374). The signature segment length corresponds to the latest signature segment generated by the system. When this signature segment is the first signature segment generated by the system, the signed length is zero. After the signed length has been incremented, the system determines whether the signed length matches the signature length (operation 376). When the signed length matches the signature length, the system determines that the message digest is digitally signed (operation 378). When the signed length does not match the signature length (e.g., when the signed length is less than the signature length), the system determines that the message digest has not been fully digitally signed. The system returns to operation 368, in which the system uses the buffer to generate an additional signature segment representing the additional portion of the digital signature. The system continues to generate additional signature segments until the signed length matches the signature length.

[0138] refer to Figure 3F The document further describes operations 300 related to generating digital signatures using incremental hashing. In one example, refer to... Figure 3F One or more of the operations described may be included in the reference. Figure 3E The operation described is in 370. (See reference...) Figure 3F As described, while additional signature segments are being generated, the system can temporarily store one or more signature segments in the transient memory of the SE hardware before combining a set of signature segments to provide a digital signature.

[0139] like Figure 3FAs shown, the system stores a set of signature segments in a set of memory elements of the SE hardware (operation 380). As the system generates corresponding signature segments, this set of signature segments can be incrementally stored in the set of memory elements. The signature segments can be generated by a first SE application object executed in the SE platform runtime environment. The system can initialize a second SE application object in the SE platform runtime environment (operation 382). The second SE application object can include signature segment combining elements for combining the signature segments generated by the first SE application object. Additionally, the system can initialize a set of temporary entry point objects in the SE platform runtime environment. These temporary entry point objects include pointers to the set of memory elements storing the set of signature segments. The system uses the temporary entry point objects to access and combine the set of signature segments to provide a digital signature.

[0140] like Figure 3F As shown, the system initializes a temporary entry point object in the SE platform runtime environment. This temporary entry point object includes pointers to memory elements in the set of memory elements that correspond to the signature segments in the set of signature segments (operation 384). The system accesses the signature segments via the temporary entry point object (operation 386). Additionally, the system adds the signature segment to the signature segment combination element (operation 388). After the signature segment has been added to the signature segment combination element, the system determines whether the digital signature includes another signature segment (operation 390). The system can determine whether the digital signature includes another signature segment by comparing the number of signature segments accessed via the temporary entry point object with the number of signature segments stored in the set of memory elements. When the system determines that the digital signature includes another signature segment, the system returns to operation 384, in which the system initializes an additional temporary entry point object to access the additional signature segment. When the system determines that the signature segment combination element includes the set of signature segments used to generate the digital signature, the system generates the digital signature by at least combining the set of signature segments in the signature segment combination element (operation 392). After the digital signature has been generated, the system outputs the digital signature from the signature segment combination elements (Operation 394).

[0141] B. Example signature verification operation

[0142] refer to Figures 4A-4H The example signature verification operation 400 is further described. Figure 4AAs shown, the system receives a selection (operation 401) of a set of signature verification protocols for verifying digital signatures. The system uses this signature verification protocol to verify the digital signature by performing one or more signature verification operations. Signature verification operations may include verifying the digital signature and / or verifying the authentication path of the digital signature. The signature verification protocol used in signature verification operation 400 may correspond to a digital signature protocol used to generate the digital signature. The signature verification protocol may be configured to verify digital signatures generated according to a hash-based digital signature protocol. The signature verification protocol may be selected based on input from a computing entity. Input from the computing entity may include input from an input device representing a user selection. The system may receive this selection via an SE interface. Additionally or alternatively, the signature verification protocol may be selected based on one or more parameters associated with the computing entity (such as one or more parameters associated with the SE platform runtime environment). Additionally or alternatively, the signature verification protocol may be selected based on a request to perform verification processing for verifying the digital signature. The request may include an indication of the signature verification protocol for the system to use to verify the digital signature.

[0143] like Figure 4A As shown, the system receives a request (operation 402) to perform verification processing to verify a digital signature generated according to a hash-based signature protocol. The request to perform verification processing may be based on input from a computing entity. Input from the computing entity may include input from an input device representing user input. The system may receive the request via an SE interface. Additionally or alternatively, the request may be initiated based on one or more operations associated with the computing entity, such as one or more operations associated with the SE platform runtime environment. In one example, the request to perform verification processing may be generated by combining the receipt of a digital signature and / or a message associated with that digital signature.

[0144] In response to the request, the system performs verification processing. In one example, the verification processing includes steps to verify the digital signature. Additionally or alternatively, the verification processing may include steps to verify the authentication path corresponding to the digital signature. The system may perform steps to verify the digital signature and / or to verify the authentication path.

[0145] In one example, the system performs processing to verify the digital signature (Operation 403). See below for reference. Figures 4B-4D Further describe the operations related to the processing used to verify the digital signature. After the processing for verifying the digital signature has been performed, the system determines whether the digital signature has been successfully verified (Operation 404).

[0146] In one example, the system performs processing to verify the authentication path corresponding to the digital signature (operation 405). In another example, the system performs processing to verify the authentication path, at least in part, in response to determining that the digital signature has been successfully verified. See below for reference. Figures 4E-4H Further describe the operations related to the processing used to verify the authentication path.

[0147] After the processing for verifying the authentication path has been performed, the system determines whether the authentication path has been successfully verified (operation 406). In response to determining that both the digital signature and the authentication path have been successfully verified, the system determines that the digital signature is valid (operation 407). In response to determining that either the digital signature or the authentication path has not been successfully verified, the system determines that the digital signature is invalid (operation 408).

[0148] In one example, the system receives the digital signature at a first part of the computational entity from a second part of the computational entity where the digital signature has been generated. For example, the system may receive the digital signature at the SE hardware. The digital signature can be transferred from the device host hardware to the SE hardware. Additionally or alternatively, the system may receive the digital signature at a first computational entity from a second computational entity. The first and second computational entities may represent different devices and / or different components of the same device. In one example, the system, for example, according to reference... Figures 3A-3F The described one or more signature generation operations receive the digital signature from the computational entity that generated it.

[0149] i. Verify digital signature

[0150] refer to Figure 4B The document further describes operations 400 related to verifying digital signatures. In one example, refer to... Figure 4B One or more of the operations described may be included in the reference. Figure 4A The operation described is 403.

[0151] like Figure 4B As shown, to verify the digital signature, the system initializes at least one SE application object in the SE platform runtime environment (operation 410). The system can utilize the digital signature API to initialize one or more SE application objects. The SE application object initialized in the SE platform runtime environment includes signature verification elements for verifying the digital signature. The SE application object executes in the SE platform runtime environment to perform one or more signature verification operations for verifying the digital signature. The digital signature can be a hash-based digital signature. The system can utilize a specific SE application object to perform multiple signature verification operations. Additionally or alternatively, the system can utilize multiple SE application objects to perform different signature verification operations.

[0152] The system obtains a digital signature and a public key corresponding to the private key used to generate the digital signature via an SE application object (Operation 411). The digital signature can be stored in persistent or transient memory of the SE hardware executing the SE platform runtime environment. The SE application object can identify and access the digital signature based on commands from the digital signature API. Commands can be provided in the form of APDUs. In one example, the system identifies and accesses the digital signature based on one or more commands, such as APDUs from the signature verification module of the digital signature API. Based on the one or more commands, the system extracts specific bytes or segments from a command buffer, such as an APDU buffer. Additionally or alternatively, the system can access the digital signature based on object fields or arrays identified by an index or parameter of the signature verification module of the digital signature API. In one example, the system obtains the public key based on the index value of a key pair index. The index value can be embedded in the digital signature or provided in conjunction with the digital signature. The computational entity that generates the digital signature and the computational entity that verifies the digital signature can each maintain an instance of the key pair index. Additionally or alternatively, the system can maintain separate instances of the key pair indexes used to generate and verify the digital signature. Based on the index value, the system can identify the leaf nodes of the tree structure associated with the hash-based signature protocol and execute a key generation algorithm to generate a public key corresponding to the leaf node based on the key pair index value. Alternatively or additionally, the public key can be embedded in the digital signature. Alternatively or additionally, the key pair index and / or public key can be included in the authentication path of the digital signature. Alternatively or additionally, the public key can be stored in persistent or transient memory of the SE hardware. When the receiving computational entity determines the public key based on the index value, the public key does not need to be transmitted between computational entities, thus avoiding the security risks associated with the transmission and potential interception of the public key.

[0153] The system determines the verification protocol used to verify the digital signature via an SE application object (operation 412). The verification protocol can be configured to verify a digital signature generated using a digital signature protocol corresponding to that digital signature. In one example, the digital signature is generated using a hash-based signature protocol, and the verification protocol is configured to verify a digital signature generated using a hash-based signature protocol. The SE application object can determine the verification protocol based on metadata associated with the digital signature and / or information included in the request to verify the digital signature. Additionally or alternatively, the SE application object can determine the verification protocol based on commands from a digital signature API (such as a signature verification module from the digital signature API). Commands can be provided in the form of APDUs. Commands can include specific instructions specifying the verification protocol to be utilized. Based on one or more commands, the system follows the verification protocol when performing a signature verification operation, thereby ensuring that the correct operation is performed according to the specific verification protocol.

[0154] In one example, before performing an operation according to a specific verification protocol, the system verifies that the digital signature API supports that verification protocol. The system can determine if a verification protocol is supported by comparing it to a list of supported verification protocols. When the system determines that the verification protocol is supported, it proceeds with the verification operation to verify the digital signature according to that protocol. When the system determines that the verification protocol is not supported, it can throw an error or generate an error message. Additionally or alternatively, the system can initiate a set of operations to add the unsupported verification protocol to the list of supported verification protocols.

[0155] After a verification protocol for verifying digital signatures has been determined, the SE application object computes the verification artifact (Operation 413) by applying the verification protocol to the digital signature and public key. This verification protocol utilizes a verification algorithm that applies a hash function to the digital signature and public key to compute the verification artifact. See below for reference. Figure 4C and Figure 4D Further describe the operations related to calculating and verifying the workpiece.

[0156] In addition to calculating the verification artifact, the SE application object obtains a message digest version calculated independently of the digitally signed message digest version (Operation 414). By independently calculating the message digest, the system ensures that the message digest used in the verification operation is based on an accurate and unchanged representation of the original message. A message digest is a fixed-size digital representation (hash) of the message content. The message digest is generated by applying a hash function to the message received in conjunction with the digital signature. In one example, the message digest is generated outside the SE platform runtime environment. In one example, the computation entities include SE hardware and device host hardware. The message digest can be generated by the device host hardware and transmitted to the SE hardware. Additionally or alternatively, the SE application object can generate the message digest. The message digest can be stored in the persistent or transient memory of the SE hardware. The SE application object can identify and access the message digest based on commands from the digital signature API.

[0157] After calculating the verification artifact and message digest, the SE application object verifies the verification artifact against the message digest (operation 415). The SE application object compares the verification artifact with the message digest. When the verification artifact matches the message digest, the SE application object determines that the digital signature has been successfully verified. When the verification artifact does not match the message digest, the SE application object determines that the digital signature is invalid.

[0158] ii. Incrementally verify digital signatures

[0159] refer to Figure 4C and Figure 4DThe document further describes operations 400 related to verifying digital signatures using incremental hashing operations. In one example, refer to... Figure 4C and / or Figure 4D One or more of the operations described may be included in the reference. Figure 4B The operation described in 413.

[0160] like Figure 4C As shown, in order to verify digital signatures using incremental hash operations, the system determines the length of the verification artifact corresponding to the verification artifact (operation 420). The system may determine the length of the verification artifact at least in part based on the public key used to generate the verification artifact for verifying digital signatures according to the verification protocol. Additionally or alternatively, the system may determine the length of the verification artifact at least in part based on the hash function used to generate the verification artifact.

[0161] The length of the verification artifact depends on the specific algorithm used to generate it. In one example, the system determines the artifact length based on the key length of the public key used to generate it. The corresponding length can be expressed in bits or bytes. In one example, for the RSA algorithm, the artifact length is directly related to the length of the public key (in bytes). In one example, for a 2048-bit RSA key, the artifact length is 2048 bits or 256 bytes. As another example, for the DSA algorithm, the artifact length is determined by the public key's key length and the hash function used in the algorithm. In one example, for a 2048-bit DSA key paired with the SHA-256 algorithm, the artifact length is 512 bits (64 bytes).

[0162] The system determines the verification segment length (operation 421) representing a portion of the verification artifact length, at least in part, based on the verification artifact length. In one example, the verification segment length is determined by dividing the verification artifact length by a divisor such that the verification segment length satisfies at least one threshold. In one example, the at least one threshold includes an upper limit threshold. The upper limit threshold may represent the maximum verification segment length. Additionally or alternatively, the at least one threshold includes a lower limit threshold. The lower limit threshold may represent the minimum verification segment length. In one example, the verification segment length and / or one or more thresholds for the verification segment length are determined at least in part based on the key length of the public key and / or the hash function used to generate the verification artifact.

[0163] After the verification segment length has been determined, the system provides a buffer with a length corresponding to the verification segment length (operation 422). The system uses this buffer to generate a verification segment representing a portion of the verified artifact (operation 423). To generate this verification segment, the system performs a verification protocol on a portion of the digital signature using the public key. The verification segment is generated in the buffer. When the verification segment reaches its length, the system outputs the verification segment (operation 424) and flushes the buffer (operation 425).

[0164] The verification segment can be output to a memory element of the SE hardware for temporary storage before combining a set of verification segments, for example, as referenced below. Figure 4D Further description. Additionally or alternatively, the verification segment can be output to different SE application elements for combining these verification segments.

[0165] After the verification segment has been output and the buffer has been flushed, the system increments the generated length corresponding to a portion of the already generated verification artifact by adding the verification segment length to the generated length (operation 426). The verification segment length corresponds to the latest verification segment generated by the system. When this verification segment is the first verification segment generated by the system, the generated length is zero. After the generated length has been incremented, the system determines whether the generated length matches the verification artifact length (operation 427). When the generated length matches the verification artifact length, the system determines that the verification artifact has been generated (operation 428). When the generated length does not match the verification artifact length (e.g., when the generated length is less than the verification artifact length), the system determines that the verification artifact has not been fully generated. The system returns to operation 423, in which the system uses the buffer to generate additional verification segments representing additional portions of the verification artifact. The system continues to generate additional verification segments until the generated length matches the verification artifact length.

[0166] refer to Figure 4D The document further describes operations 400 related to generating a verification artifact using incremental hashing. In one example, reference... Figure 4D One or more of the operations described may be included in the reference. Figure 4C The operation described in 424. See reference [link / reference]. Figure 4D As described, while additional verification segments are being generated, the system can temporarily store one or more verification segments in the transient memory of the SE hardware before combining a set of verification segments to provide a verification artifact.

[0167] like Figure 4DAs shown, the system stores a set of verification segments in a set of memory elements of the SE hardware (operation 430). As the system generates corresponding verification segments, this set of verification segments can be incrementally stored in this set of memory elements. Verification segments can be generated by a first SE application object executed in the SE platform runtime environment. The system can initialize a second SE application object in the SE platform runtime environment (operation 431). The second SE application object can include verification segment combining elements for combining the verification segments generated by the first SE application object. Additionally, the system can initialize a set of temporary entry point objects in the SE platform runtime environment. These temporary entry point objects include pointers to the set of memory elements storing the set of verification segments. The system uses the temporary entry point objects to access the set of verification segments and combine them to provide a verification artifact.

[0168] like Figure 4D As shown, the system initializes a temporary entry point object in the SE platform runtime environment. This temporary entry point object includes pointers to memory elements in the set of memory elements that correspond to the verification segments in the set of verification segments (operation 432). The system accesses the verification segments via the temporary entry point object (operation 433). Additionally, the system adds the verification segments to the verification segment combination element (operation 434). After the verification segment has been added to the verification segment combination element, the system determines whether the verification artifact includes another verification segment (operation 435). The system can determine whether the verification artifact includes another verification segment by comparing the number of verification segments accessed via the temporary entry point object with the number of verification segments stored in the set of memory elements. When the system determines that the verification artifact includes another verification segment, the system returns to operation 432, in which the system initializes an additional temporary entry point object to access the additional verification segment. When the system determines that the verification segment combination element includes the set of verification segments used to generate the verification artifact, the system generates the verification artifact by at least combining the set of verification segments in the verification segment combination element (operation 436). After the verification artifact has been generated, the system outputs the verification artifact from the verification segment combination elements (operation 437). The system can, for example, refer to... Figure 4B The described SE application element outputs the verification artifact to verify the digital signature at least by comparing the verification artifact with the message digest.

[0169] iii. Verify the authentication path

[0170] refer to Figure 4E and Figure 4F The document further describes the operation 400 related to verifying the authentication path. In one example, refer to... Figure 4E and / or Figure 4F One or more of the operations described may be included in the reference. Figure 4BThe described operation is 405. For example... Figure 4E As shown, to verify the authentication path, the system initializes at least one SE application object in the SE platform runtime environment (operation 440). The system can utilize the digital signature API to initialize one or more SE application objects. The SE application object initialized in the SE platform runtime environment includes an authentication path verification element for verifying the authentication path of the key pair used to generate the digital signature. The SE application object executes in the SE platform runtime environment to perform one or more verification operations for verifying the authentication path.

[0171] The system obtains an authentication path via an SE application object. This authentication path includes a set of hash values ​​corresponding to a set of nodes in a tree structure associated with a hash-based signature protocol used to generate digital signatures (Operation 441). The authentication path can be stored in persistent or transient memory of the SE hardware executing the SE platform runtime environment. The SE application object can identify and access the authentication path based on commands from the Digital Signature API. Commands can be provided in the form of APDUs. In one example, the system identifies and accesses the authentication path based on one or more commands, such as APDUs from the signature verification module of the Digital Signature API. Based on these one or more commands, the system extracts specific bytes or segments from a command buffer, such as an APDU buffer. Additionally or alternatively, the system can access the authentication path based on object fields or arrays identified by an index or parameter of the signature verification module of the Digital Signature API. In one example, the authentication path is embedded in the digital signature. Additionally or alternatively, the authentication path can be provided separately from the digital signature.

[0172] The system determines the verification protocol used to verify the authentication path via the SE application object (Operation 442). The verification protocol can be configured to verify the authentication path generated using the digital signature protocol corresponding to the digital signature. In one example, the system verifies that the digital signature API supports the verification protocol before performing any operation according to that specific verification protocol.

[0173] After the verification protocol used to verify the authentication path has been determined, the SE application verifies the authentication path by at least calculating the root hash value (operation 443) and verifying the root hash value against the root public key associated with the digital signature (operation 444). The root hash value corresponds to the root node of the tree structure. The SE application calculates the root hash value based on this set of hash values ​​of the authentication path. See below for reference. Figure 4F Further describe the operations related to calculating the root hash value.

[0174] The SE application verifies the root hash against the root public key by comparing the root hash value with the root public key. When the root hash value matches the root public key, the SE application determines that the authentication path has been successfully verified. When the root hash value does not match the root public key, the SE application determines that the authentication path is invalid.

[0175] refer to Figure 4F The document further describes the operation 400 related to calculating the root hash value to verify the authentication path. In one example, refer to... Figure 4F One or more of the operations described may be included in the reference. Figure 4E In the described operation 443, the root hash value is calculated based on (a) the public key corresponding to the private key used to generate the digital signature in the hash-based signature protocol, and (b) the set of hash values ​​for the authentication path. The hash value represents the sibling hash value corresponding to a node in the tree structure. The public key corresponds to the first leaf node of the tree structure, and the first hash value in this set corresponds to the second leaf node, which is the sibling node of the first leaf node in the tree structure. Additional hash values ​​correspond to the sibling nodes of intermediate nodes in the tree structure. The second hash value corresponds to the sibling node of the parent node of both the first and second leaf nodes.

[0176] To calculate the root hash value, the system can perform a reference... Figure 4F One or more operations as described. For example... Figure 4FAs shown, the system determines the public key corresponding to the private key used to generate the digital signature in the hash-based signature protocol (operation 450). The system can determine the public key based on the index value of the key pair index. In one example, the index value is included in the authentication path. Alternatively or additionally, the index value can be embedded in the digital signature or provided separately in combination with the digital signature and / or the authentication path. Based on the index value, the system can identify the leaf nodes of the tree structure associated with the hash-based signature protocol and can execute a key generation algorithm to generate the public key corresponding to the leaf node based on the key pair index value. Alternatively, the public key can be included in the authentication path or the digital signature. The system selects this public key as the current hash value (operation 451). In one example, when a computational entity generates a digital signature and transmits the digital signature and authentication path to another computational entity for verification, the transmitting computational entity can provide the index value instead of the public key. Because the receiving computational entity can determine the leaf value and the corresponding public key based on the index value, it is not necessary to transmit the public key between computational entities, thereby avoiding the security risks associated with the transmission and potential interception of the public key. In addition to determining the public key, the system also determines the sibling hash value of the current hash value from the set of hash values ​​in the authentication path (operation 452). This set of hash values ​​can be arranged in the string, for example, in an order corresponding to the hierarchy of a tree structure. The first sibling hash value used can be placed at the beginning of the string. The last sibling hash value used can be placed at the end of the string.

[0177] After the sibling hash values ​​have been determined, the system generates a concatenation of the current hash value and the sibling hash value (operation 453). This concatenation is generated by linking the current hash value and the sibling hash value end-to-end to form a consecutive hash value. For example, the concatenation of the first hash value of 12a3b4 and the second hash value of 56c7d8 is: 12a3b456c7d8. The system calculates the intermediate hash value based at least in part on the concatenation of the current hash value and the sibling hash value (operation 454). The system calculates the intermediate hash value by applying a hash function to the concatenation of the current hash value and the sibling hash value. See below for reference. Figure 4G and 4H Further describe the operations related to calculating the intermediate hash value.

[0178] After the intermediate hash values ​​have been calculated, the system determines whether the set of hash values ​​for the authentication path includes hash values ​​that have not yet been used in the calculation of the root hash value (Operation 455).

[0179] The system can determine whether the authentication path includes another hash value by comparing the number of hash values ​​to be used with the number of hash values ​​included in the set of hash values. When the system determines that the authentication path includes another hash value, it selects that intermediate hash value as the current hash value (operation 456), and returns to operation 452, where the system determines the sibling hash value of the current hash value (e.g., the sibling hash value of the intermediate hash value selected as the current hash value). The system computes additional intermediate hash values ​​until it determines that the set of hash values ​​has already been used in the computation of the root hash value and / or the authentication path does not include another hash value. When the system determines that the set of hash values ​​has already been used and / or the authentication path does not include another hash value, it selects an intermediate hash value as the root hash value (operation 457). The system verifies the root hash value selected at operation 457 against the root public key to determine whether the root hash value matches the root public key. When the root hash value matches the root public key, the system determines that the authentication path has been successfully verified.

[0180] iv. Incrementally verify the authentication path

[0181] refer to Figure 4G and Figure 4H The document further describes operation 400 related to verifying the authentication path using incremental hash operations. In one example, refer to... Figure 4G and / or Figure 4H One or more of the operations described may be included in the reference. Figure 4F The described operation is in 454. For example... Figure 4G As shown, in order to compute an intermediate hash value for verifying the authentication path using incremental hashing operations, the system determines the hash length corresponding to the intermediate hash value (operation 460). The system may determine this hash length based at least in part on the hash function used to compute the intermediate hash value. Additionally, the system determines the hash segment length representing a portion of the hash length based at least in part on this hash length (operation 461).

[0182] In one example, the hash segment length is determined by dividing the hash length by a divisor that ensures the hash segment length satisfies at least one threshold. In one example, this at least one threshold includes an upper limit threshold. The upper limit threshold may represent the maximum hash segment length. Additionally or alternatively, the at least one threshold includes a lower limit threshold. The lower limit threshold may represent the minimum hash segment length. In one example, the hash segment length and / or one or more thresholds for the hash segment length are determined at least in part based on the hash function used to generate intermediate hash values.

[0183] After the verification segment length has been determined, the system provides a buffer with a length corresponding to that hash segment length (operation 462). The system uses this buffer to generate a hash segment representing a portion of the intermediate hash value (operation 463). To generate the hash segment, the system performs a hash function on a portion of the intermediate hash value. The hash segment is generated in the buffer. When the hash segment reaches its length, the system outputs the hash segment (operation 464) and flushes the buffer (operation 465).

[0184] The hash segment can be output to a memory element of the SE hardware for temporary storage before combining a set of hash segments, for example, as referenced below. Figure 4H Further description. Additionally or alternatively, the hash segment can be output to different SE application elements for combining the set of hash segments.

[0185] After the hash segment has been output and the buffer flushed, the system increments the generated length corresponding to the generated portion of the intermediate hash value by adding the hash segment length to the generated length (operation 466). The hash segment length corresponds to the latest hash segment generated by the system. When this hash segment is the first hash segment generated by the system, the generated length is zero. After incrementing the generated length, the system determines whether the generated length matches the hash length (operation 467). When the generated length matches the hash length, the system determines that the intermediate hash value has been generated (operation 468). When the generated length does not match the hash length (e.g., when the generated length is less than the hash length), the system determines that the intermediate hash value has not been fully generated. The system returns to operation 463, in which the system uses the buffer to generate an additional hash segment representing the additional portion of the intermediate hash value. The system continues to generate additional hash segments until the generated length matches the hash length.

[0186] refer to Figure 4H The document further describes operations 400 related to generating intermediate hash values ​​using incremental hashing operations. In one example, refer to... Figure 4H One or more of the operations described may be included in the reference. Figure 4E The described operation is in 464. (See reference...) Figure 4H As described, while additional hash segments are being generated, the system can temporarily store one or more hash segments in the transient memory of the SE hardware before combining a set of hash segments to provide an intermediate hash value.

[0187] like Figure 4HAs shown, the system stores a set of hash segments in a set of memory elements of the SE hardware (operation 470). As the system generates corresponding hash segments, this set of hash segments can be incrementally stored in the set of memory elements. Hash segments can be generated by a first SE application object executed in the SE platform runtime environment. The system can initialize a second SE application object in the SE platform runtime environment (operation 471). The second SE application object can include hash segment combining elements for combining hash segments generated by the first SE application object. Additionally, the system can initialize a set of temporary entry point objects in the SE platform runtime environment. The temporary entry point objects include pointers to the set of memory elements storing the set of hash segments. The system uses the temporary entry point objects to access the set of hash segments and combine them to provide intermediate hash values.

[0188] like Figure 4H As shown, the system initializes a temporary entry point object in the SE platform runtime environment. This temporary entry point object includes pointers to memory elements in the set of memory elements that correspond to the hash segments in the set of hash segments (operation 472). The system accesses the hash segments via the temporary entry point object (operation 473). Additionally, the system adds the hash segments to a hash segment combination element (operation 474). After the hash segment has been added to the hash segment combination element, the system determines whether the intermediate hash value includes another hash segment (operation 475). The system can determine whether the intermediate hash value includes another hash segment by comparing the number of hash segments accessed via the temporary entry point object with the number of hash segments stored in the set of memory elements. When the system determines that the intermediate hash value includes another hash segment, the system returns to operation 472, in which the system initializes an additional temporary entry point object to access the additional hash segment. When the system determines that the hash segment combining element includes the set of hash segments used to generate the intermediate hash value, the system generates the intermediate hash value by at least combining the set of hash segments in the hash segment combining element (operation 476). After the intermediate hash value has been generated, the system outputs the intermediate hash value from the hash segment combining element (operation 477). The system can, for example, refer to... Figure 4F The described method outputs the intermediate hash value to an SE application element that verifies the authentication path by calculating the root hash value based on one or more intermediate hash values.

[0189] 6. Computer networks and cloud networks

[0190] 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. Nodes are connected via a set of links. Examples of links include coaxial cables, unshielded twisted-pair cables, copper cables, fiber optic cables, and virtual links.

[0191] 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.

[0192] 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.

[0193] 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.

[0194] 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 transmit requests to the computer network. Requests may be transmitted through interfaces such as client interfaces (such as web browsers), program interfaces, or application programming interfaces (APIs).

[0195] 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 allocated to requesting and / or clients on an on-demand basis. The network resources allocated to each requesting and / or client may be scaled up or down based on, for example, the following: (a) computing services requested by a specific client, (b) aggregated computing services requested by a specific tenant, and / or (c) aggregated computing services requested by the computer network itself. Such a computer network may be referred to as a "cloud network".

[0196] 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 offers end users the ability to use applications running on the service provider's network resources. In PaaS, the service provider offers end users 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 offers end users the ability to provision processing, storage, networking, and other basic computing resources provided by network resources. Any application, including operating systems, can be deployed on network resources.

[0197] In embodiments, computer networks can implement various deployment models, 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 one or more entities (as used herein, "entity" refers to a business, organization, individual, or other entity). Network resources can be located locally or remotely from the premises of the specific entity group. In a public cloud, cloud resources are provisioned to 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 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 the portability of data and applications. 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 be dependent on each other. You can use the interface to make calls from an application in a private cloud to an application in a public cloud (and vice versa).

[0198] 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.

[0199] 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.

[0200] 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 access to a specific network resource if the tenant and the specific network resource are associated with the same tenant ID.

[0201] 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 allowed access to a specific application, data structure, and / or dataset only if the tenant and the specific application, data structure, and / or dataset are associated with the same tenant ID.

[0202] 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.

[0203] 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.

[0204] In this embodiment, network resources (such as digital devices, virtual machines, application instances, and threads) corresponding to different tenants are isolated from tenant-specific overlay networks maintained by the multi-tenant computer network. As an example, packets from any source device in a tenant overlay network can be sent only to other devices within the same tenant overlay network. Encapsulation tunnels are used to prevent any transmission from a source device on a 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 sent 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 sent by the source device. The original packet is then sent from the second encapsulation tunnel endpoint to the destination device within the same specific overlay network.

[0205] 7. Microservice Applications

[0206] 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 various 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, different microservices can be deployed independently as separate executables. Microservices can communicate using Hypertext Transfer Protocol (HTTP) messages and / or via API endpoints according to other communication protocols. Microservices can be managed and updated separately, written in different languages, and executed independently of other microservices.

[0207] Microservices offer flexibility in managing and building applications. Different applications can be built by connecting different groups of microservices without changing the source code of the microservices. Therefore, microservices act as logical building blocks that can be arranged in various ways to build different applications. Microservices can provide monitoring services that notify the microservice manager when a trigger event occurs in a set of trigger events exposed to the microservice manager (such as If-This-Then-That (IFTTT), Zapier, or Oracle Self-Service Automation (OSSA)). Microservices exposed to an application can additionally or alternatively provide action services that perform actions within 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 occurring 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 integrated into the microservice manager, for example, by using application credentials provided to the manager by the user, without requiring re-authentication each time a managed application is used alone or in combination with other applications.

[0208] 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 areas of the GUI 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 validation tests to verify that the output and input are compatible (e.g., by checking data types, size limits, etc.).

[0209] trigger

[0210] 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 above-described techniques 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 exceeded. For example, when a microservice application detects that a value has exceeded a trigger threshold, a user can request a trigger in the microservice manager.

[0211] In one embodiment, the trigger, when satisfied, can output data for the target microservice to consume. In another embodiment, the trigger, when satisfied, outputs a binary value indicating that the trigger has been satisfied, or outputs the field name or other contextual information that the trigger condition was met. Additionally or alternatively, the target microservice can connect to one or more other microservices, enabling alerts to be sent to those other microservices. Other microservices can perform response actions based on the above techniques, including but not limited to deploying additional resources, adjusting system configurations, and / or generating a GUI.

[0212] action

[0213] In one or more embodiments, pluggable microservice applications can expose actions to a microservice manager. The exposed actions can receive data, the identifier of a data object, or the location of the data as input, which allows the data to be moved into a data cloud.

[0214] 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 the threshold. 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, instead of being triggered to the user by another application plugged into the microservice manager.

[0215] In one or more embodiments, a microservice application may generate and provide output based on inputs that identify, locate, or provide historical data and define the degree or scope of the requested output. When triggered, the action causes the microservice application to provide, store, or display output, for example, as a data model or as aggregated data describing the data model.

[0216] 8. Hardware Overview

[0217] 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 permanently 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 implement the technology by combining custom hardwired logic, ASICs, FPGAs, or NPUs with custom programming. 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.

[0218] For example, Figure 5 This is a block diagram illustrating a computer system 500 on which embodiments of the present disclosure may be implemented. The computer system 500 includes a bus 502 or other communication mechanism for transmitting information and a hardware processor 504 coupled to the bus 502 for processing information. The hardware processor 504 may be, for example, a general-purpose microprocessor.

[0219] Computer system 500 also includes main memory 506, such as random access memory (RAM) or other dynamic storage devices, coupled to bus 502 for storing information and instructions to be executed by processor 504. Main memory 506 can also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 504. When such instructions are stored in non-transitory storage media accessible to processor 504, such instructions make computer system 500 a dedicated machine customized to perform the operations specified in the instructions.

[0220] The computer system 500 also includes a read-only memory (ROM) 508 or other static storage device coupled to the bus 502 for storing static information and instructions of the processor 504. A storage device 510, such as a hard disk, optical disk, or solid-state drive (SSD), is provided and coupled to the bus 502 for storing information and instructions.

[0221] Computer system 500 can be coupled via bus 502 to a display 512, such as a cathode ray tube (CRT), for displaying information to the computer user. Input device 514, including alphanumeric keys and other keys, is coupled to bus 502 to transmit information and command selections to processor 504. Another type of user input device is a cursor control 516, such as a mouse, trackball, or arrow keys, used to transmit directional information and command selections to processor 504 and to control cursor movement on display 512. Such input devices typically have two degrees of freedom on two axes (a first axis (e.g., x) and a second axis (e.g., y)) to allow the device to specify a position in a plane.

[0222] Computer system 500 may implement the techniques described herein using custom hard-wired logic, one or more ASICs or FPGAs, firmware, and / or program logic, which, in combination with the computer system, enable computer system 500 to become a special-purpose machine or to program computer system 500 as a special-purpose machine. According to one embodiment, the techniques herein are executed by computer system 500 in response to processor 504 executing one or more sequences of one or more instructions contained in main memory 506. These instructions may be read into main memory 506 from another storage medium, such as storage device 510. Execution of the sequence of instructions contained in main memory 506 causes processor 504 to perform the processing steps described herein. In alternative embodiments, hard-wired circuitry may be used instead of software instructions or in combination with software instructions.

[0223] As used herein, the term "storage medium" refers to any non-transitory medium that stores data and / or instructions that enable a machine to operate in a particular manner. Such storage media can include non-volatile media and / or volatile media. Non-volatile media include, for example, optical discs or magnetic disks, such as storage device 510. Volatile media include dynamic memory, such as main memory 506. 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 cassette tapes, content-addressable memory (CAM), and ternary content-addressable memory (TCAM).

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

[0225] Various forms of media can involve carrying one or more sequences of one or more instructions to processor 504 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 500 may receive data over the 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 502. Bus 502 carries the data to main memory 506, from which processor 504 retrieves and executes the instructions. Instructions received by main memory 506 may optionally be stored on storage device 510 before or after execution by processor 504.

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

[0227] Network link 520 typically provides data communication to other data devices via one or more networks. For example, network link 520 may provide a connection to host computer 524 or to data devices operated by Internet Service Provider (ISP) 526 via local network 522. ISP 526 then provides data communication services via a global packet data communication network now commonly referred to as the "Internet" 528. Both local network 522 and Internet 528 use electrical, electromagnetic, or optical signals that carry digital data streams. Signals through various networks, as well as signals on network link 520 and through communication interface 518, are example forms of transmission media that carry digital data to or from computer system 500.

[0228] Computer system 500 can send messages and receive data, including program code, through one or more networks, network links 520, and communication interfaces 518. In the Internet example, server 530 can transmit requested code for the application through the Internet 528, ISP 526, local network 522, and communication interface 518.

[0229] The received code can be executed by processor 504 when it is received, and / or stored in storage device 510 or other non-volatile storage device for later execution.

[0230] 9. Other matters; extension

[0231] Unless otherwise defined, all terms (including technical and scientific terms) shall be given their common and customary meaning to a person skilled in the art, and shall not be limited to any particular or customary meaning, unless expressly defined herein.

[0232] This application may include references to certain trademarks. While the use of trademarks is permitted in a patent application, the proprietary nature of trademarks should be respected, and every effort should be made to prevent their use in any way that may adversely affect their validity as trademarks.

[0233] 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. The described components may be implemented using software and / or hardware. Each component may be distributed across multiple applications and / or machines. Multiple components may be combined into a single application and / or machine. Operations described for one component may instead be performed by another component.

[0234] In an embodiment, one or more non-transitory computer-readable storage media include instructions that, when executed by one or more hardware processors, cause to perform any operation described herein and / or recited in any of the claims.

[0235] In an embodiment, a method includes the operations described herein and / or recited in any of the claims. The method is performed by at least one device including a hardware processor.

[0236] 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 implementation. Accordingly, the specification and drawings should be considered illustrative rather than restrictive. The sole and exclusive measure of the scope of this disclosure, and what the applicant intends to define as the scope of this disclosure, is the literal and equivalent scope of the set of claims claimed in this application, in the specific form claimed by such claims, including any subsequent corrections.

Claims

1. One or more non-transitory computer-readable media, including instructions that, when executed by one or more hardware processors, cause to perform operations including: Initialize the signature generation object in the Secure Element (SE) platform runtime environment, wherein the SE platform runtime environment is executed on at least one SE processor of the SE hardware device; The private key corresponding to the hash-based signature protocol is determined via the signature generation object; A digital signature for the message digest is generated by performing the hash-based signature protocol on the message digest using the private key via the signature generation object. The digital signature is output to the hardware device.

2. The one or more non-transitory computer-readable media as claimed in claim 1, wherein the digital signature for generating the message digest comprises: The first signature segment is generated by performing the hash-based signature protocol on a first digest segment representing a first part of the message digest; as well as The second signature segment is generated at least by performing the hash-based signature protocol on a second digest segment representing the second part of the message digest; The digital signature mentioned therein includes a first signature segment and a second signature segment.

3. The one or more non-transitory computer-readable media as described in claim 2, wherein the digital signature generating the message digest further comprises: Combine the first signature segment and the second signature segment.

4. The one or more non-transitory computer-readable media as described in claim 3, wherein the digital signature generating the message digest further comprises: Initialize the signature segment combination object in the SE platform runtime environment; The first signature segment is directed from the first SE application corresponding to the signature generation object to the second SE application corresponding to the signature segment combination object via a shareable interface object. The second signature segment is routed from the first SE application to the second SE application via the shared interface object; A combined digital signature is generated by combining at least the first signature segment and the second signature segment via the signature segment combination object. Outputting the digital signature to the hardware device includes outputting the combined digital signature to the hardware device.

5. One or more non-transitory computer-readable media as described in claim 2, wherein outputting the digital signature to a hardware device comprises: Output the first signature segment to the hardware device; as well as Output the second signature segment to the hardware device; The hardware device obtains the digital signature by at least combining a first signature segment and a second signature segment.

6. The one or more non-transitory computer-readable media as described in claim 2, wherein the digital signature generating the message digest further comprises: Before generating the second signature segment: The first signature segment is stored in the first transient memory element of the SE hardware device; Initialize a temporary entry point object containing a pointer to the first transient memory element; After generating the second signature segment: Access the first signature segment via the temporary entry point object; Combine the first signature segment and the second signature segment.

7. The one or more non-transitory computer-readable media as described in claim 2, wherein the digital signature for generating the message digest comprises: Before generating the first and second signature segments: The signature length corresponding to the digital signature is determined at least in part based on the private key; The length of the signature segment representing a portion of the signature length is determined, at least in part, based on the signature length. Determine at least one of the following: (a) A first digest segment based at least in part on the signature segment length, wherein the first digest segment includes a first digest segment length corresponding to the signature segment length, or (b) A second digest segment based at least in part on the signature segment length, wherein the second digest segment includes a second digest segment length corresponding to the signature segment length.

8. The one or more non-transitory computer-readable media of claim 7, wherein the digital signature for generating the message digest comprises: Determine the signed length corresponding to the combination of the first signature segment and the second signature segment; Determine that the already signed length matches the signature length; The message digest is determined to be digitally signed, at least in part, based on the match between the signed length and the signature length.

9. One or more non-transitory computer-readable media as claimed in claim 1, wherein determining the private key includes: Access a key pair index, which includes the utilization status of a set of key pairs associated with the hash-based signature protocol; Based on the key pair index, determine an index value that includes an indication of the next available key pair in the set of key pairs; Increment the index value of the key pair index to indicate that the next available key pair is being utilized; Execute a key generation algorithm corresponding to the hash-based signature protocol to generate the key pair at least in part based on the index value, wherein the key pair includes the private key and the public key.

10. The one or more non-transitory computer-readable media as described in claim 9, wherein determining the private key further comprises: Determine the parameter set corresponding to the hash-based signature protocol, the parameter set including hash length and tree structure height; The key generation algorithm is further executed, at least in part, based on the parameter set, to generate the key pair.

11. The one or more non-transitory computer-readable media as claimed in claim 10, wherein the set of signature generation operations further comprises: Before determining the private key: Initiate a parameter object that includes the parameter set; The parameter object is maintained in a persistent memory element of the SE hardware device; Determining the parameter set includes: In the persistent memory element, the parameter object including the parameter set is accessed; The parameter set is determined at least in part based on the parameter object.

12. The one or more non-transitory computer-readable media as claimed in claim 1, wherein the operation further comprises: Generate an authentication path corresponding to the digital signature. The private key used to generate the digital signature corresponds to the public key associated with the first leaf node of the tree structure defined according to the hash-based signature protocol. The authentication path includes: (a) The public key, (b) A first hash value associated with the second leaf node of the tree structure, wherein the second leaf node is a sibling node of the first leaf node, and (c) At least a second hash value associated with an intermediate node of the tree structure, The root hash value corresponding to the root node of the tree structure can be calculated based on the authentication path; The authentication path is output to the hardware device.

13. The one or more non-transitory computer-readable media of claim 1, wherein the hash-based signature protocol includes at least one of the following: a stateful hash-based signature protocol, a stateless hash-based signature protocol, or a one-time hash-based signature protocol.

14. One or more non-transitory computer-readable media as claimed in claim 1, wherein the operation further comprises: Determine the protocol selection parameters corresponding to the signature generation object; as well as The hash-based signature protocol is determined based on the protocol selection parameters corresponding to the signature generation object.

15. One or more non-transitory computer-readable media as claimed in claim 1, wherein the operation further comprises: Receive the message digest, wherein the message digest is generated by the hardware device by applying a hash function to the first message; or The second message is received and the message digest is generated by applying the hash function to the second message.

16. The one or more non-transitory computer-readable media of claim 1, wherein the operation further comprises: The first SE application receives a digital signature request from the second SE application via a shareable interface object, requesting the first SE application to digitally sign the message digest. The first SE application initializes the signature generation object in at least part of its response to receiving the digital signature request.

17. One or more non-transitory computer-readable media as claimed in claim 1, wherein outputting the digital signature to the hardware device comprises: The digital signature is routed from the first SE application to the second SE application via a shareable interface object. The digital signature is routed from the second SE application to the hardware device.

18. One or more non-transitory computer-readable media as claimed in claim 1, wherein the hardware device uses a public key corresponding to the private key to verify the digital signature.

19. A method comprising: Initialize the signature generation object in the Secure Element (SE) platform runtime environment. The SE platform runtime environment is executed on at least one SE processor of the SE hardware device; The private key corresponding to the hash-based signature protocol is determined via the signature generation object; A digital signature for the message digest is generated by performing the hash-based signature protocol on the message digest using the private key via the signature generation object. The digital signature is output to the hardware device.

20. A system comprising: At least one security element (SE) hardware processor; The system is configured to perform operations including the following: Initialize the signature generation object in the Secure Element (SE) platform runtime environment. The SE platform runtime environment is executed on at least one SE processor of the SE hardware device; The private key corresponding to the hash-based signature protocol is determined via the signature generation object; A digital signature for the message digest is generated by performing the hash-based signature protocol on the message digest using the private key via the signature generation object. The digital signature is output to the hardware device.

Images