WO2019226510A1

WO2019226510A1 - Methods and systems for multiple independent roots of trust

Info

Publication number: WO2019226510A1
Application number: PCT/US2019/033043
Authority: WO
Inventors: Steven Sprague; Michael Sprague; Leonard S. Veil; Darshan B. CHAUDHARI; Gregory J. Kazmierczak; Sean Patrick LAWLESS; Rafael A. Ortiz
Original assignee: Rivetz Corp.
Priority date: 2018-05-21
Filing date: 2019-05-20
Publication date: 2019-11-28

Abstract

A method and system used to execute a secure cryptographic operation while maintaining multiple independent roots of trust. The method and system establish at least two secure execution environments which maintain security containers used for confidential cryptographic operations. The security containers hold private keys or private key portions created and registered by the secure execution environments, the private keys are utilized by a cryptographic protocol for a cryptographic operation. The private keys or private key portions can be enabled or disabled independently from each other and the cryptographic operation will only be completed if a threshold number of private keys or private key portions are enabled. Further, a system and corresponding method establish multiple independent roots of trust to protect from a vulnerability to a single failure of a security domain.

Description

METHODS AND SYSTEMS FOR MULTIPLE INDEPENDENT ROOTS OF TRUST

RELATED APPLICATIONS

[0001] This application claims the benefit of LT.S. Provisional Application No. 62/674,377, filed on May 21, 2018, and claims the benefit of LT.S. Provisional Application No. 62/729,916, filed on September 11, 2018. The entire teachings of the above applications are incorporated herein by reference.

BACKGROUND

[0002] Roots of Trust (RoT) is a set of functions in a trusted computing module that is always trusted by the computer’s operating system (OS). The RoT may serve as a separate compute engine that may control a trusted computing platform’s cryptographic processor on a device, such as a mobile device, or any other suitable electronic device that it is embedded in.

SUMMARY

[0003] According to an example embodiment, a system and associated computer implemented method for executing a secure cryptographic operation while maintaining multiple independent points of control may include at least two secure execution environments. The secure execution environments may be any combination of the following, subscriber identity module (SIM), trusted execution environment (TEE), trusted platform module (TPM), secure element (SE), IS07816 smartcard (SC) and/or hardware security module (HSM), or any similar secure enclave with secure computing capabilities. The secure execution environments may create and register one or more private keys, key splits, distributed key variations, or other secrets such as multi-party cryptographic distributed key protocols. The created private keys, key splits, secrets, or distributed key variations may be held within security containers maintained by the secure execution environments and may be enabled and/or disabled independently from each other.

[0004] According to an example embodiment, a processor may be configured to initiate secure cryptographic operations which may have a corresponding cryptographic protocol. The cryptographic protocol may be performed by the processor utilizing the private keys, key splits, or distributed key variations within the security containers. The secure cryptographic operation may be executed if a threshold number of the private keys, key splits, or distributed key variations are available.

[0005] The secure execution environments maintaining the security containers may be located on at least one security device within one or more platforms. At least two security devices may be located on same or different systems, wherein security devices may be on remote systems.

[0006] The secure cryptographic operation may include construction, reconstruction, or decryption of a private key that is used in a blockchain transaction. Furthermore, a blockchain may be used to maintain reference measurements of the security containers.

[0007] The private keys, key splits, or distributed key variations may be disabled unless each security container maintained by the secure execution environments verifies the integrity of the other security containers. Verifying the integrity of a security container may include verifying proximity. The processor may also be configured to execute the secure cryptographic operation only if the private keys, key splits, or distributed key variations are used by the cryptographic protocol within a set time window or period, for example. Other similar rules or policies may be applied to key usage.

[0008] When utilizing the enabled private keys, key splits, or distributed key variations the processor may apply business logic and record the attestation of the business logic to generate a unique fingerprint. The processor may also update the attestation of the security containers. Furthermore, the updating of a security container’s attestation signature may require the permission from the other security containers.

[0009] The private keys, key splits, or distributed key variations may be migrated from a first set of security containers to a second set of security containers. The private keys, key splits, or distributed key variations may also be provably archived from the security containers to an authenticated third party. The private keys, key splits, or distributed key variations may then also be provably restored from the authenticated third party to one of the security containers of the secure execution environments.

[0010] According to another example embodiment, a computer implemented method for establishing multiple independent roots of trust may comprise: distributing an asset across at least two security domains each associated with a respective original condition at a time of the distributing; verifying integrity of the respective original condition at each of the at least two security domains; enabling release of the asset distributed in an event that each of the at least two security domains attests that its respective current condition matches its respective original condition; and preventing release or reconstruction of the asset distributed in an event that one or more security domains of the at least two security domains does not attest that its respective current condition matches its respective original condition.

[0011] The verifying may include utilizing at least one trusted measurement service to perform one or more integrity measurements and verification of the respective current condition relative to the respective original condition.

[0012] If an event release is enabled, the method may further include releasing the asset from at least one security domain of the at least two security domains to a trusted process.

[0013] The method may further comprise managing control of the asset distributed, independently, within the at least two security domains.

[0014] The asset may include a first portion and a second portion and the method further comprise: controlling, by a user, the first portion of the asset, the first portion residing in a first security domain of the at least two security domains; and controlling, by a Mobile Network Operator (MNO), the second portion of the asset, the second portion residing in a second security domain of the at least two security domains.

[0015] The first security domain may be a Trusted Execution Environment (TEE) and the second security domain may be a Subscriber Identity Module (SIM).

[0016] The asset distributed may be a cryptographic key.

[0017] Alternative system embodiments parallel those described above in connection with the example method embodiment.

[0018] It should be understood that example embodiments disclosed herein can be implemented in the form of a method, apparatus, system, or computer readable medium with program codes embodied thereon.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The foregoing will be apparent from the following more particular description of example embodiments, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments.

[0020] FIG. 1 A is a block diagram of an example embodiment of a digital processing environment in which various embodiments of the present disclosure may be implemented. [0021] FIG. 1B is a block diagram of an example embodiment of an internal structure of a computer/computing node.

[0022] FIG. 1C is a block diagram of an example embodiment of a system within which an example embodiment may be implemented.

[0023] FIG. 2 is a flow diagram of an example embodiment of a process for executing a secure cryptographic operation.

[0024] FIG. 3 A is a block diagram of an example embodiment of a secure execution environment that may be utilized in various embodiments of the present disclosure.

[0025] FIG. 3B is a flow diagram of an example embodiment of a computer implemented method for executing a secure cryptographic operation while maintaining multiple independent points of control.

[0026] FIG. 4 is a flow diagram of an example embodiment of a method for establishing multiple independent roots of trust.

DETAILED DESCRIPTION

[0027] A description of example embodiments follows.

[0028] It should be understood that the term“blockchain” as used herein includes all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction-chain technologies, permissioned and un-permissioned ledgers, shared ledgers and variations thereof. While Bitcoin and Ethereum may be referred to herein for the purpose of convenience and illustration, it should be noted that the disclosure is not limited to use with the Bitcoin or Ethereum blockchains and alternative blockchain implementations and protocols fall within the scope of the present disclosure. Further, while an Android™ embodiment may be disclosed, it should be understood that example embodiments disclosed herein are not limited to an Android mobile device or platform. Android is a trademark of Google LLC.

[0029] Information assurance, or confirmation that information on a device has not changed, is one of the biggest challenges in modern computer science. The nature of the network, common access, and the use of web-based services have evolved rapidly. However,

cybersecurity protections have struggled to keep up with these evolutions. With rapidly evolving computer and mobile systems, old models of software-only cybersecurity are always one step behind the bad guys ( e.g ., hackers).

[0030] Mobile, desktop, and Internet-of-Things (IoT) computer systems generally employ cryptographic operations in devices with a single cryptographic private key which may or may not be protected within a tamper resistant security container. These systems generally protect these keys, and the usage of these keys, under usage rules that are evaluated within a single security container, placing the usage of these keys under a single point of control. Even if a system supports or requires multiple keys and/or multi-signature (multisig) transactions, a single device, such as an edge device, may be used to control the use of a private key in a transaction. An example embodiment overcomes deficiencies of a single device to fully control the execution of a cryptographic operation or transaction including setting and applying usage rules. In order to provide increased protection and better support multi-user control there is a need for the ability to store, register, protect and use cryptographic keys or portions of keys under multiple points of control of at least two security authorities, as disclosed further below.

[0031] In the early days of the cellphone industry, MNOs relied on non-secure devices and open protocols to identify handsets. However, as cellular devices became more prevalent, attacks that compromised an identity of a handset and allowed for easy hijacking of a number and associated authentication credentials began to occur. In order to combat a rise in network usage theft, the European Telecommunications Standards Institute standardized the Subscriber Identity Module (SIM), a small and inexpensive semiconductor device designed to secure identity information and access credentials necessary for a handset to access a permissioned MNO network. The SIM has undergone several specifications changes and has evolved to require a Common Criteria (see ISO/IEC 15408) security certification, but it fundamentally resembles the same protected storage and protected execution environment envisaged originally.

[0032] Correspondingly, as the Internet grew in connectivity and services, traditional Information Technology (IT) equipment began to experience similar identity and access attacks as had previously plagued the MNO environment. Several innovative companies formed the Trusted Computing Platform Alliance (TCP A), which then evolved into the Trusted Computing Group (TCG) (see www.trustedcomputinggroup.org). Amongst the security architectures and standards developed within the TCG was the Trusted Platform Module (TPM). Similarly,

Global Platform (see www.globalplatform.org) has specified the Trusted Execution Environment (TEE) (see Global Platform TEE System Architecture vl. l), an isolated processing environment in which code can be securely executed outside of a normal operating system environment.

These secure enclave technologies brought Strong Machine Identity, Boot Integrity and

Attestation (see for example, TCG Infrastructure Working Group Architecture Part II - Integrity Management Specification Version 1.0 Revision 1.0), and Protected Storage and Protected Execution to a new class of platforms. [0033] The number of cellular devices that are TEE-enabled has grown to over 1 billion. Carriers use the SIM to protect their network and subscriber information, and users and enterprises use a handset OS environment, potentially with some TEE capabilities, to protect their assets. While this is a significant leap forward for the protection of user and enterprise information, imperfect hardware and software implementations, as well as having humans involved in administrative processes such as SIM porting, may create attack surfaces that can compromise assets within a single security domain.

[0034] What is needed is an asset protection system capable of defending against a failure of a single security subsystem in a consumer mobile device. As complexity of implementations increases, it behooves a security architect to achieve distributed asset protection and control, such that sensitive information is not compromised if a class break occurs. According to an example embodiment, a problem of failure of a single security domain may be solved by protecting cryptographic material under multiple independent roots of trust, such as dual independent roots of trust, ensuring that two or more security domains must provably participate in acquiring the use of a key that is protected in a distributed manner, and enabling independent management control of the distributed key within at least two independent security domains.

[0035] Enterprises have transitioned to allowing a user with many different devices to access a corporate network or hosted services. In addition to a corporate-supplied or bring your own device (BYOD) computer, most users can access corporate resources using their tablets, cell phones, vehicles, etc. ETsers may also access personal applications with such same multiple devices. As such, access credentials are often replicated across many devices, operating systems, and security domains. Whereas user assets were formerly located in a single device, such assets have been made available to be compromised across several platforms, providing an ecosystem where these replicated sensitive assets may be subject to attack on any - but most likely the “weakest” - platform.

[0036] A major goal of security professionals is to harden these assets, to ensure that their compromise is as difficult as possible. Phone numbers and carrier bindings may be stored in a SIM, a semiconductor device nominally certified by independent security labs at one of the highest levels available, such as at the Common Criteria Evaluation Assurance Level (EAL) 6 (see https://www.commoncriteriaportal.org/files/ccfiles/CCPART3V3.lR5.pdf). Mobile handset applications store similar assets either in the normal OS environment or utilize a Secure Enclave such as the TEE, when available. [0037] However, recent systemic compromises have exposed vulnerabilities in these solutions. These vulnerabilities may occur due to design and/or implementation flaws, such as Spectre and Meltdown (see https://arstechnica.com/gadgets/20l8/0l/meltdown-and-spectre- every-modern-processor-has-unfixable-security-flaws/), or Foreshadow (see

https://www.wired.com/story/foreshadow-intel-secure-enclave-vulnerability/), or may occur due to failures in human processes, such as cryptocurrency losses due to SIM porting (see https://www.reuters.com/article/us-cryptocurrency-at-t-lawsuit/u-s-investor-sues-att-for-224- million-over-loss-of-cryptocurrency-idUSKBNlLOlAA), or supply-chain issues where an entire network of SIM keys has been stolen (see https://theintercept.com/20l5/02/l9/great-sim-heist/). While some of these vulnerabilities are more difficult to exploit than others, they all create scenarios where an asset can potentially be exposed. As a value of that asset increases, so does the benefit of a compromise.

[0038] Storing an asset exclusively in a single security domain creates a single point of failure. Any compromise of that security domain may result in a loss of that asset,

compromising a user’s ability to uniquely use that asset, or preventing the user from being able to provably assert control over that asset. In addition, the user may not discover the loss of control over that asset for a significant period, further complicating any forensic activities.

[0039] According to an example embodiment, an asset may be distributed across two or more security domains, ensure that all security domains participate in the use of that asset, creating an environment resistant to a failure of one of those security domains. By utilizing integrity measurements and verification, an example embodiment ensures that environments that hold these distributed assets have not been compromised before the sensitive information is released. By provably reconstructing an asset for use in a transaction, an example embodiment enables forensic evidence to be provided in order to assure a higher-quality transaction.

[0040] An example embodiment, such additional security domains also provide for additional points of control for digital asset access and management.

[0041] A root of trust is a set of unconditionally trusted functions that consistently perform a set of security-specific operations in an expected and repeatable manner and are immune to software attack and ideally most hardware attacks. Roots of trust generally perform

measurement, storage, reporting, verification, and/or update. Roots of trust are integral in ensuring a secure boot, performing integrity calculations on the various components of the boot process, and ensuring their compliance to a set of golden reference measurements. Roots of trust enable the platform to attest to the fact that it booted into a known condition. [0042] An example embodiment may utilize trusted measurement and storage services to employ transitive trust properties to measure and store respective conditions of a variety of components in a system. Such resulting measurements may comprise a current state (also referred to interchangeably herein as a condition) of a platform. Further using trusted reporting services, an example embodiment may attest to a separate entity that unique platform’s current state.

[0043] An example embodiment may seal information to a platform state. Trusted verification, combined with other trusted techniques, may enable the root of trust to

confidentially hold information and release that information to a trusted process if - and only if- a current state of the platform is identical to a state when the information was originally stored. This sealing technique allows the platform to dynamically detect system changes and prevent release of information, a core tenet of ensuring that secure enclaves remain in the required state.

[0044] According to an example embodiment, a smartphone handset with a MNO

provisioned SIM and a secure enclave, such as a Global Platform compliant TEE, may be employed as a system with two security domains. An example embodiment may include distributing application secrets across such two security domains, providing an environment whereby a fault-tolerant asset protection solution may be achieved, provably.

[0045] According to an example embodiment, sensitive digital assets may be distributed amongst at least two hardware Roots of Trust, that is, at least two security domains. A cryptographic key may be used as the distributed asset, which can then be used directly as an application key or to protect additional application secrets. Multiple“splitting” mechanisms may be employed, as disclosed further below, wherein a chosen“splitting” mechanism may be chosen based on computational capabilities of the at least two participating security domains.

[0046] A SIM may be under a MNO’s control. As such, the MNO alone may hold authorization credentials needed to provision applications onto the SIM and to configure SIM applications, enabling a MNO to update phone numbers, roaming services, authentication protocols, and other MNO-related data.

[0047] A TEE may be under control of a platform manufacturer. Special considerations may be needed to program services into the TEE, to ensure that the security subsystem is correctly provisioned and to guarantee that only authorized providers are instantiating security capabilities for users and their applications. Such additional security capabilities may be created and made available to applications by provisioning a Trusted Application (TA), which executes within the TEE security domain. Control of TAs within the TEE may be subjugated to the user or may remain under the direct control of the platform OS. By requiring the user to authenticate either to the platform or directly to the trusted application using an asset, an example embodiment may enable a user to assert control over a protected asset.

[0048] Traditional applications that are installed on a handset may give the user (or enterprise) control over the configuration and usage of that application, including the assets used by that application. By distributing an asset across two security domains, an example embodiment enables independent control planes through those two or more distinct security domains. According to an example embodiment, the user remains in control of a portion of the distributed asset that may reside in the TEE, while the MNO gains control of the other portion, which may reside in the SIM. It is incumbent upon the MNO to ensure that they are acting appropriately as a delegate of the digital asset owner.

[0049] According to an example embodiment, the platform application may choose to federate control of the TEE-based portion of the digital asset to an enterprise, and the MNO may choose to federate control of the asset held in a SIM to an enterprise. In most cases, an enterprise should only control one portion of the distributed asset.

[0050] A variety of key“splitting” methods are available for use in a dual root system.

While the inherent security of a method is a primary consideration, computational capabilities of the security domains may be used to dictate which methods are realizable on a particular device. Ideally, a method that does not recombine the“splits” within a single security domain may be chosen, such as a multi-party method. However, the computational requirements of this type of solution can be significantly greater than legacy SIMs can provide.

[0051] According to an example embodiment, distributing assets may include provable attestation of the integrity of the environments in which those assets are stored. According to an example embodiment, using Trusted Computing techniques, a security domain may verify that its condition is identical to when the asset was placed under the security domain’s control.

Releasing the distributed asset may then be done using unsealing techniques, as disclosed above.

[0052] An example embodiment may employ an Anchored Key method. Such an Anchored Key method may include storing a key in one security domain and retrieving the key by another security domain when that key is required. The key stored in the second security domain may be encrypted with a key held by the first security domain, and, thus, is opaque to the second security domain. Any compromise of the second security domain would yield only an opaque asset; any compromise of the first security domain would require access to the second as well. [0053] An example embodiment may employ a Dual Sealed Key method. Such a Dual Sealed Key method may add a sealing property to the Anchored Key solution. For example, the Dual Sealed Key method may include releasing either portion of the distributed asset as a function of provable knowledge that unintended changes were not made to either security domain, providing integrity over the asset’s protection.

[0054] An example embodiment may employ a Secure Multi-Party Symmetric Key method. The Secure Multi-Party Symmetric Key method may include generating and using a symmetric encryption key that is never reconstructed in either security domain. Utilizing advanced cryptographic methods, this multi-party protocol allows for the encryption of sensitive information without the reconstruction of the key in a single security domain.

[0055] An example embodiment may employ a Secure Multi-Party Asymmetric Signature method. The Secure Multi-Party Asymmetric Signature method may include generating and using an asymmetric key to authorize transactions. Advance cryptographic methods may enable a distributed asset to sign without reconstructing that asset in a single security domain.

[0056] From a capabilities perspective, Anchored Keys may use the least amount of resource from the security domains. Dual-Sealed Keys use attestation, and, therefore, the security domains need to offer significantly more services. Multi-party solutions perform significantly more computation, and, therefore, may need a higher-performing execution environment with more memory than the environments used to execute the anchored variants.

[0057] Application Usage

[0058] According to an example embodiment, a dual root implementation can support many keys, each of which is individually addressable. From an application perspective, at least three usage scenarios are possible.

[0059] The first usage scenario would be to use a distributed cryptographic key as an application key. This scenario is best employed when an application requires one and only one key, or when only a portion of an application is intended to be protected.

[0060] The second usage scenario is to use the distributed key to protect the application assets and other sensitive information. This scenario is best employed when an application has more than one required key or additional sensitive data, and where access to those assets should be controlled in a provable fashion.

[0061] The third scenario is launch control , the ability to selectively enable or disable the launching of an application by protecting access rights. This scenario is best considered when the use of an entire application needs the ability to assert provable control from both the user and an enterprise.

[0062] The nominal use of dual root keys provides for a user experience identical to that of a standard key, maintaining a simple yet safer experience. A user who is interacting with a dual root key does not experience any application differences except when the secondary control plane is invoked. Some aspect of remediation may be provided when an application is temporarily or permanently disabled.

[0063] Example Use Cases

[0064] Dual Roots of Trust has an unlimited number of use cases. For example, if a user were to lose a device used to sign into a platform with enterprise access credentials, the enterprise could disable the use of those credentials on that specific lost device, without requiring the user to change their credentials on other devices.

[0065] According to an example use case, if a security flaw were found in an application or a platform security domain, a remote management system could temporarily disable one or more specific applications until remediation was performed.

[0066] Some enterprises require provable participation of a user performing a specific action. In this scenario, the enterprise could remotely enable the corresponding application by enabling a dual root key, allow the user to perform the specified action which is forensically recorded, and then disable the use of that key upon completion.

[0067] According to other example use cases, parents can remotely enable or disable their children’s cryptocurrency wallets or messaging apps; employers could assert control over employee wallets; and platforms could host government certified External Certification

Authority (ECA) medium-assurance identity credentials. It should be understood that the example use cases, disclosed above, are for illustrative purposes, and that example embodiments disclosed herein may be applied to any suitable use case.

[0068] All mobile phones that connect to MNO networks contain a SIM, and more than 1 billion modern Android mobile devices from a variety of vendors have shipped with a TEE. Utilizing these modem handsets, with appropriate authorization from a TEE manufacturer and participation of a MNO, it is possible to construct an Android platform that implements Dual Roots of Trust technology.

[0069] According to an example embodiment, an implementation of the distributed asset is performed by creating a Trusted Application (TA), that is, a Dual Root Controller (DRC). The DRC runs in the TEE and is responsible for the creation of an application key, which is encrypted with a TA Sealing key that the DRC persistently holds. The TA Sealing Key is sealed to the current TEE state to ensure the TEE is in an unaltered condition when that key is desired. The application key is encrypted with the TA Sealing Key, and the resulting opaque blob is sent to the SIM and then deleted along with the application key. The SIM, which creates a Blob Sealing Key, uses that key to seal the opaque blob to the state of the SIM, ensuring the blob is released only if the SIM state has not been altered. The application key and blob are never persistently stored in the TA, and thus the application key must be reconstructed for each use.

[0070] ETse of the application key requires the DRC to read the sealed opaque blob from the SIM, and to decrypt the opaque blob to access the application key. Because each security domain uses a sealed key, integrity checks are automatically performed when these keys are accessed. Optionally, Attestation of the Security Domains may be used to create the provable assertions which can be carried along with any use of the application key.

[0071] The implementation of the key sealing, opaque blob storage, and attestation may be performed through a Java Card application known as Dual Root Application (DRA). DRA implements the SIM side of the Dual Sealed Key method, disclosed above. DRA uses a common sealing key for all opaque blob protection, and stores these opaque blobs within DRA specific secure storage. With current Gemalto Model R8 SIMs, more than 32 unique application keys can be realized.

[0072] Android 5.1 introduced a mechanism based on the Global Platform Secure Element Access Control specification to grant special privileges for application program interfaces (APIs) relevant to the SIM applications (see Global Platform Secure Element Access Control Version 1.1). The Android platform loads certificates stored on a SIM and grants permission to apps signed by these certificates to make calls to a handful of special APIs.

[0073] An example embodiment creates Access Rules Application (ARA) based on Global Platform Secure Element Access Control and Java Card Specifications that can be provisioned on a SIM card. In the example embodiment, the ARA is programmed with the Android app publisher certificate hash, SIM DRA application identifier, and other command filters for tighter control on accessing the SIM applications. An Access Control Enforcer (ACE), a component of the Secure Element Access API, obtains access rules from the SIM and applies those rules to restrict device application access to the various SIM applications.

[0074] A block diagram of an Android embodiment is disclosed in FIG. 1C.

[0075] According to an example embodiment, when a key is provisioned on the SIM, an application identifier (AppID) associated with the application referred to by that key is stored. DRA provides two interfaces for MNO control - enable(AppID) and disable(AppID). The MNO can use these interfaces to over-the-air (OTA) enable or disable that key’s ability to be used, providing for MNO-based independent control operations.

[0076] According to an example embodiment, the system also supports secure migration of the application key blob to another equivalent dual root environment, enabling a user to easily upgrade to a new device. Associated with the migration is a method to securely escrow the application key so it can be recovered to the same or to a different device at a future time. Such capabilities may be based on the Migration Specifications as defined by the Trusted Computing Group.

[0077] Provisioning of the ARA and DRA Java Card applications onto the SIM device may be the responsibility of the MNO. The MNO can order pre-provisioned SIM devices from their manufacturer or can perform OTA provisioning for field-deployed devices. The International Mobile Subscriber ID (IMSI) is uniquely bound to a SIM and an associated control credential is used to authorize the SIM’s update via binary SMS messages the MNO can uniquely issue.

[0078] Further Implementations

[0079] Secure enclaves are currently implemented in a variety of platforms using a variety of technologies. SGX and SEV are some of the secure enclave technologies offered by processor vendors, with more techniques, including certified kernels and virtual machines, bringing similar capabilities to platforms. An example embodiment of multiple roots of trust, such as dual roots of trust, disclosed above, can be implemented in many different configurations; the primary requirement is that the platform have two or more independent security domains which provide Roots of Trust.

[0080] The SIM industry is making a transition from physically replaceable SIMs to more capable and reconfigurable semiconductor devices, embedded Universal Integrated Circuit Cards (eUICCs or eSIMs), which are capable of hosting services from more than one MNO and service provider. These eSIMs have more computational power than currently deployed SIMs and enable next-generation multi-party signature methods as well as the ability to host significantly more cryptographic material due to their larger FLASH memory sizes. It should be understood that a SIM, referred to herein, may be any suitable subscriber identify module and is not limited to SIMs disclosed herein.

[0081] According to an example embodiment, a system for distributing sensitive

cryptographic material, that is, an asset, may be configured such that the asset is provably protected and under control of two or more independent entities. Existing roots of trust on existing mobile platforms, which natively provide for strong asset protection, are susceptible to single failures of either security domain. To overcome this vulnerability, an example

embodiment provides a distributed asset system that requires the provable coordination of two or more roots of trust, wherein the participation of either security domain is independently controllable. An example embodiment employs sealing as a method to ensure that integrity verification on the security domain can be realized before the release of an asset. An example embodiment provably reconstructs an assert ensuring that forensic evidence is available to record at transaction time. Many assets can be protected within the system, the full lifecycle of those assets is supported, and those assets may be protected with increasing levels of trusted operations based on the characteristics of the roots of trust.

[0082] Digital Processing Environment

[0083] FIG. 1 A is a block diagram of an example embodiment of a digital processing environment in which various embodiments of the present disclosure may be implemented. An example implementation of a cryptographic operations system 100 according to an example embodiment for executing secure cryptographic operations with multiple independent points of control may be implemented in a software, firmware, or hardware environment. FIG. 1 A illustrates one such example digital processing environment in which various embodiments of the present disclosure may be implemented. Client computers/devices 150 and server

computers/devices 160 provide processing, storage, and input/output devices executing application programs and the like.

[0084] Client computers/devices 150 may be linked directly or through communications network 170 to other computing devices, including other client computers/devices 150 and server computer/devices 160. The communication network 170 can be part of a wireless or wired network, remote access network, a global network ( e.g ., Internet), a worldwide collection of computers, local area or wide area networks, and gateways, routers, and switches that may use a variety of protocols, such as TCP/IP, Bluetooth®, RTM, etc., or any other suitable protocols, to communicate with one another. The communication network 170 may also be a virtual private network (VPN) or an out-of-band network or both. The communication network 170 may take a variety of forms, including, but not limited to, a data network, voice network (e.g. land-line, mobile, etc.), audio network, video network, satellite network, radio network, and pager network. Other electronic device/computer networks architectures are also suitable.

[0085] Server computers 160 of the device authentication system 100 may be configured to provide an access control server executing an authentication application or website which communicates with computing devices and server provider platforms. The server computers 160 may register a computing device using an established identity (e.g., cryptographic public key of a public/private key pair) of the device and register a service provider using an established identity (e.g., cryptographic public key of a public/private key pair) of the service provider. The server computers 160 may also pair the device and service provider using the established identities, including providing the service provider identity (public key) to the device and providing the device identity to the service provider. The server computers 160 may also monitor access control behavior within the pairing based on an access control list or a measured reference value indicating a known good condition or state of the device. The server computers 160 may also record the registration, pairing, access control list, and measured reference value in a blockchain or other secure global memory. The server computers may not be separate server computers but part of cloud network.

[0086] Client computers 150 of the system 100 may be computing devices configured with a trusted execution environment (TEE) and trusted application to generate the established identity (public/private key pair) of the device. The client computers 150 may also compute signatures, encrypt/decrypt, and execute instructions and instruction results as part of a transaction with a service provider.

[0087] Client computers 150 of the system 100 may be computing devices configured with one or more secure execution environments, such as, but not limited, to Subscriber Identity Module (SIM), Trusted Execution Environment (TEE), Trusted Platform Module (TPM), Secure Element (SE), IS07816 Smartcard (SC), Hardware Security Module (HSM) or similar device or execution environment. These trustworthy computer environments of client computers 150 may contain independent security containers for the creation, authentication, and usage of

cryptographic keys or portions of keys.

[0088] FIG. 1B is a block diagram of an example embodiment of an internal structure of a computer/computing node (e.g., client processor/ device 150 or server computers 160) in the digital processing environment of FIG. 1 A, which may be used to facilitate displaying audio, image, video or data signal information. Each computer 150, 160 in FIG. 1B includes a system bus 110, where a bus is a set of actual or virtual hardware lines used for data transfer among the components of a computer or processing system. The system bus 110 is essentially a shared conduit that connects different elements of a computer system (e.g., processor, disk storage, memory, input/output ports, etc.) that enables the transfer of data between elements. [0089] Attached to the system bus 110 is an I/O device interface 82 for connecting various input and output devices (e.g., keyboard, mouse, touch screen interface, displays, printers, speakers, audio inputs and outputs, video inputs and outputs, microphone jacks, etc.) to the computer 150, 160. A network interface 113 allows the computer to connect to various other devices attached to a network (for example the network illustrated at 170 of FIG. 1 A). Memory 114 provides volatile storage for computer software instructions 115 and data 116 used to implement software implementations of components of some embodiments of the present disclosure. Such device software components 115, 116 of the cryptographic operations system 100 described herein may be configured using any programming language, including any high- level, object-oriented programming language, such as Python.

[0090] In an example embodiment of a mobile implementation, a mobile agent

implementation may be provided. A client server environment can be used to enable mobile security services using the server 160. It can use, for example, the Extensible Messaging and Presence Protocol (XMPP) protocol to tether a device authentication engine/agent 115 on the device 150 to a server 160. The server 160 can then issue commands to the mobile phone on request. The mobile user interface framework to access certain components of the system 100 may be based on XHP, Javelin and WURFL. In another example mobile implementation for OS X and iOS operating systems and their respective APIs, Cocoa and Cocoa Touch may be used to implement the client-side components 115 using Objective-C or any other high-level programming language that adds Smalltalk-style messaging to the C programming language.

[0091] The system 100 may also include instances of server processes on the server computers 160 that may comprise an authentication application, service provider application, or TEE applet, which allow generating keys for a device, registering a device, pairing a device to a service provider, verifying an instruction of a service transaction against an access control list or reference value of health and integrity of the device, signing the instruction,

encrypting/decrypting the instructions, and executing the instruction.

[0092] Disk storage 95 provides non-volatile storage for computer software instructions 92 (equivalently“OS program”) and data 94 used to implement embodiments of the system 100. The system may include disk storage accessible to the server computer 160. The server computer can maintain secure access to records in the blockchain (not shown) related to the device, service provider, pairing of the device and service provider, and access control at the device. Central processor unit 84 is also attached to the system bus 110 and provides for the execution of computer instructions at the device (e.g., in the TEE, or other secure computer environments, of the device).

[0093] In an example embodiment, the processor routines 92 and data 94 are computer program products. For example, if aspects of the authentication system 100 may include both server-side and client-side components.

[0094] In an example embodiment, service providers may communicate with a device via instant messaging applications, video conferencing systems, voice-over-internet-protocol (VOIP) systems, email systems, etc., all of which may be implemented, at least in part, in software 115, 92. In example embodiments, the method of executing secure cryptographic operations may be implemented as an application program interface (API), executable software component, or integrated component of the OS configured to authenticate users on a Trusted Platform Module (TPM) executing on a client computer 150.

[0095] Software implementations 115, 92 may be implemented as a computer readable medium capable of being stored on a storage device 95, which provides at least a portion of the software instructions for system 100. Executing instances of respective software components of the system 100 may be implemented as computer program products 115, and can be installed by any suitable software installation procedure, as is well known in the art. In another embodiment, at least a portion of the system software instructions 115 may be downloaded over a cable, communication and/or wireless connection via, for example, a browser Secure Sockets Layer (SSL) session or through an app (whether executed from a mobile or other computing device).

In other embodiments, the system 100 software components 115, may be implemented as a computer program propagated signal product embodied on a propagated signal on a propagation medium (e.g. a radio wave, an infrared wave, a laser wave, a sound wave, or an electrical wave propagated over a global network such as the Internet, or other networks.

[0096] FIG. 1C is a block diagram of an example Android embodiment, disclosed above, within which an example embodiment may be implemented.

[0097] Executing a Cryptographic Operation

[0098] FIG. 2 is a flow diagram 200 of an example embodiment of a method for executing a secure cryptographic operation. The method begins (202) and creates private keys within secure execution environments (204). The private keys may be whole keys, key splits or distributed key variants. The private keys may be placed within security containers maintained by each secure execution environment. In one example embodiment, the secure execution environments may be a SIM module and a TEE on a separate device. The method initiates a cryptographic operation (206). In an example embodiment, the cryptographic operation is decryption of a private key used in bitcoin transaction. The method receives an independent transaction from each secure execution environment containing the private keys (208). A check is made as to whether or not the private keys are enabled (210). If it is determined that the private keys are disabled, the method stops the cryptographic operation (212) and thereafter ends (216), in the example embodiment. If, however, it is determined that the private keys are enabled, the method completes the cryptographic operation (214), and the method thereafter ends (216), in the example embodiment.

[0099] Independent Roots of Trust

[00100] According to an example embodiment, a method and system may create and register at least two keys within at least two secure execution environments, such as a SIM and a TEE. An application may be used to trigger the formation and registration of the keys. The at least two keys must be whole keys, use to protect a split portion of an application key or split variations of an application key. The created keys may be used to execute cryptographic operations. As an example, the decryption of an application private key that can then be used in a bitcoin transaction. A cryptographic operation may be executed dependent upon independent transactions undertaken with each of the at least two keys created.

[00101] The cryptographic operation may require that all the created keys be used in order for it be fully executed. Alternatively, the cryptographic operation may be executed if a threshold number of the created keys were used. The distribution of keys to multiple secure execution environments allows of multiple independent roots of trust for a single cryptographic operation. Each key can be individually enabled or disabled. A key may be enabled or disabled due to policies/instructions provided to the secure execution environments. Each key may be subject to independent policies. Therefore, the cryptographic operation is subject to the control of each individual key, or portion of a key split, that are subject to the independent roots of trust of the separate and distinct secure execution environments. This provides both additional security and the distribution of control to multiple devices/users without a single device/user, in, for example, an edge device, having complete control over the execution of the operation. Independent roots of trust allow for federation of cryptographic operations providing the ability to apply independent polices across multiple systems that may be located on a range of devices.

[00102] FIG. 3 A is a block diagram of an example embodiment of a secure execution environment 300 that may be utilized in various embodiments of the present disclosure. For example, the secure environment 300 may be employed to establish multiple independent roots of trust, such as disclosed further below with reference to FIG. 4. The secure environment 300 includes a device 350 that may be a computer, mobile device, or any other suitable computing device. The device 350 may be a client processor/device, such as the client/processor/device 150 in the digital processing environment disclosed above with reference to FIG 1A. The device 350 may be configured to establish and maintain at least two independent and separate secure execution environments 301 and 302. The at least two secure execution environments may be any combination of the following, a Subscriber Identity Module (SIM), a Trusted Execution Environment (TEE), a Trusted Platform Module (TPM), a Secure Element (SE), a IS07816 Smartcard (SC), a Hardware Security Module (HSM), or equivalent hardware or software components. In an alternative example embodiment, the secure execution environments 301 and 302 may be located on separate devices or systems, such as 150, 160 of the digital processing environment connected to the network 170 of FIG. 1A, disclosed above.

[00103] The secure execution environments 301 and 302 may be configured to maintain security containers 303A and 303B for confidential cryptographic operations. These security containers 303A and 303B may be configured to hold private keys created and registered by the secure execution environments 301 and 302, respectively. The security containers 303A and 303B are separate and independent from each other and may have different policies for control, different access methods, and/or even different owners/controllers. A user may enable or disable private keys within the security containers independently from each other. For example, a key within container 303A may be enabled without affecting or even notifying container 303B. The separate policies governing the security containers 303A and 303B may each enable or disable the keys within the security containers based upon their own individual requirements and/or parameters.

[00104] The keys within security containers 303A and 303B may be used as part of the cryptographic protocol of a cryptographic operation. If desired, the cryptographic operation may be restricted to execute only if both keys within the security containers 303A and 303B are enabled. Therefore, the independent policies of the security containers 303A and 303B can both determine whether or not a single cryptographic operation is executed. Furthermore, a single cryptographic operation is subject to two roots of trust, in the example embodiment, that is, one established by the security container 303A within secure execution environment 301, and a second established by the security container 303B within the secure execution environment 302. Because the secure execution environments 301 and 302 can be created though a diverse array of hardware and software technologies, the independent roots of trust can be established through numerous different methods and devices allowing for the establishment of numerous different security methods depending upon a user’s preferences and needs.

[00105] The security containers 303A and 303B may be configured to communicate over a communication path 305 using known methods in the art. The communication path 305 may be used by the security containers 303A and 303B to verify the integrity of their respective secure execution environments, which, according to an example embodiment, may include verifying proximity relative to one another. The policies of the security containers 303A and 303B may include a requirement that the other security container’s integrity be positively verified in order to enable the private key contained within them. In this manner, multiple independent integrity verifications, originating from independent roots of trust, may be required to enable all keys used to execute a cryptographic operation. Verifying the integrity of a security container may include verifying proximity and/or whether private keys, key splits, or distributed key variations are used by the cryptographic protocol within a set time window or period, for example. It should be understood that proximity, a set time window, or period are examples of policies and that any suitable policy may be applied to key usage. For example, a policy could be employee status, position of the sun, before a football season starts, or anything that is relevant to a transaction.

[00106] FIG. 3B is a flow diagram 380 of an example embodiment of a computer

implemented method for executing a secure cryptographic operation while maintaining multiple independent points of control. The method begins (382) and establishes at least two secure execution environments which maintain security containers for confidential cryptographic operations (384). The method creates and registers one or more private keys, key splits, or distributed key variations within each secure execution environment, wherein the private keys, or key splits, or distributed key variants can be independently enabled and disabled (386). The method initiates the secure cryptographic operation, the secure cryptographic operation having a cryptographic protocol (388). The method performs the cryptographic protocol utilizing enabled private keys, or key splits, or distributed key variants (390). The method executes the secure cryptographic operation only if a threshold number of the private keys or key splits, or distributed key variants are enabled (392) and the method thereafter ends (394), in the example embodiment.

[00107] Independent Ownership and Policy Control

[00108] The secure execution environments located on client computers 150 of the system 100 may be configured for independent ownership and policy control. Each secure execution environment may be controlled and have its policies set independent of the other secure execution environments either located on other client computers 150 of the system 100 of located on the same client computers 150 of the system 100. Independent security containers and trusted environments for the creation and authenticated usage of integrity protected keys, provide for independent control. By making the usage of keys or subsets of keys dependent on the state of another entity, all entities may able to guarantee parameters of another platform which participates in its transaction.

[00109] The keys, split keys or split key variations located within the secure execution environments may be enabled or disabled separately and through different methods. For example, a device owner may wish to split a bitcoin key across the SIM and a secured bitcoin wallet application on a mobile phone. Under normal operations, the ability to authenticate to their phone and the bitcoin wallet application will allow for normal transactions. If the user loses their device, it is however possible to authorize their MNO to remotely disable the use of the portion of the key stored on the SIM. Without the portion of the key stored on the SIM enabled, the mobile wallet application will be prevented from performing any additional bitcoin transactions even if its portion of the bitcoin key is enabled. By having multiple secure execution environments with independent policy control users of the system 100 are able to have multiple ways to control/restrict the performance of a single digital transaction.

[00110] Access to the secure execution environments may be distributed between multiple users in order to facilitate sharing control and/or ownership of a single digital transaction between multiple entities. For example, one key is held by the users trusted application within a TEE, the other key is held within the SIM of a mobile device. The user may enable or disable the key within the TEE by using the application. Concurrently, a separate user may assert control over the key is held within the SIM of a mobile device by remotely applying policy control to over the MNO network. If both keys are required to perform a digital action, then both users are able exert control over that action.

[00111] Use of Blockchain for Reference Measurements

[00112] A blockchain is a distributed database that includes of a list of records. Each record has a secure timestamp and a cryptographic link to the previous record. The records are called blocks, and the cryptographic links make it easy to read the database and to verify its accuracy but make it extremely difficult for an attacker to alter or change the order of records. Because of these properties, a blockchain is a machine-readable unalterable historical record, which makes it especially suitable for security applications. The best known blockchain is the Bitcoin blockchain, which uses the immutable historical record to record irreversible monetary transactions. Another well-known blockchain is the Ethereum blockchain. Ethereum uses the blockchain to store smart contracts as well as the data those smart contracts need to operate.

[00113] When a device is manufactured, its birth certificate is stored on a blockchain. The birth certificate associates to that physical device a health quote, which may include information such as a hash of firmware. If a device is compromised, its real-time health quote will change.

An adversary who wishes to hide the compromise will have to rewrite the entire history of all transactions on the blockchain back to the time of manufacture of the device, which virtually impossible. Moreover, if the device is configured to write a health quote including reference measurements, to the blockchain regularly, then the blockchain will not only record that the device is compromised but also when it was compromised. By using a blockchain to maintain reference measurements of the security containers, an unalterable history is created that can provide validation of the integrity and health of the security containers. Furthermore, anyone or any device, such as other security containers, can verify the integrity of the blockchain by iterating over it and computing hashes of all the blocks.

[00114] Bidirectional Attestations

[00115] An example embodiment may include bidirectional attestation of the health and integrity of a system, specifically the secure execution environments and their corresponding security containers. In these embodiments, a smart contract may be used, which may be hosted on a distribute app model using the blockchain. To achieve access to the system, an untrusted agent on a cloud server may be contacted to request access. A client device may provide device identity, a real-time hash message address, and a reference hash locator. A server device may be configured in a trusted execution environment, like TXT, to provide an identity real-time hash message address and reference hash locator.

[00116] In an example embodiment, the smart contract may be activated with combined data and an access control challenge token, and messages are sent to both the server device and client device, including real-time hash messages addressed with a nonce. The nonce is hashed with the real-time integrity hash. The smart contract then compares the real-time and reference hashes for the client and server, and if they match, then the contract responds with the correct response to the access challenge issued. An event may be logged independently of the service and access may be granted.

[00117] FIG. 4 is a flow diagram 400 of an example embodiment of a method for establishing multiple independent roots of trust. The method may begin (402) and distribute an asset across at least two security domains each associated with a respective original condition at a time of the distributing (404). The method may verify integrity of the respective original condition at each of the at least two security domains (406). The method may enable release of the asset distributed in an event that each of the at least two security domains attests that its respective current condition matches its respective original condition (408). The method may prevent release of the asset distributed in an event that one or more security domains of the at least two security domains does not attest that its respective current condition matches its respective original condition (410) and the method thereafter ends (412), in the example embodiment.

[00118] Further example embodiments disclosed herein may be configured using a computer program product; for example, controls may be programmed in software for implementing example embodiments. Further example embodiments may include a non-transitory computer- readable medium containing instructions that may be executed by a processor, and, when loaded and executed, cause the processor to complete methods described herein. It should be understood that elements of the block and flow diagrams may be implemented in software or hardware, such as via one or more arrangements of circuitry of FIG. 1B, disclosed above, or equivalents thereof, firmware, a combination thereof, or other similar implementation determined in the future. In addition, the elements of the block and flow diagrams described herein may be combined or divided in any manner in software, hardware, or firmware. If implemented in software, the software may be written in any language that can support the example embodiments disclosed herein. The software may be stored in any form of computer readable medium, such as random access memory (RAM), read only memory (ROM), compact disk read-only memory (CD-ROM), and so forth. In operation, a general purpose or application- specific processor or processing core loads and executes software in a manner well understood in the art. It should be understood further that the block and flow diagrams may include more or fewer elements, be arranged or oriented differently, or be represented differently. It should be understood that implementation may dictate the block, flow, and/or network diagrams and the number of block and flow diagrams illustrating the execution of embodiments disclosed herein. Further, example embodiments and elements thereof may be combined in a manner not explicitly disclosed herein.

[00119] While example embodiments have been particularly shown and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the embodiments encompassed by the appended claims.

Claims

CLAIMS What is claimed is:

1. A computer implemented method for executing a secure cryptographic operation while maintaining multiple independent points of control, the method comprising;

establishing at least two secure execution environments which maintain security containers for confidential cryptographic operations;

creating and registering one or more private keys, key splits, or distributed key variations within each secure execution environment, wherein the private keys, or key splits, or distributed key variants can be independently enabled and disabled;

initiating the secure cryptographic operation, the secure cryptographic operation having a cryptographic protocol;

performing the cryptographic protocol utilizing enabled private keys, or key splits, or distributed key variants; and

executing the secure cryptographic operation only if a threshold number of the private keys or key splits, or distributed key variants are enabled.

2. The method for executing the secure cryptographic operation of Claim 1, wherein the at least two secure execution environments include at least one of the following: a

Subscriber Identity Module (SIM), a Trusted Execution Environment (TEE), a Trusted Platform Module (TPM), a Secure Element (SE), a IS07816 Smartcard (SC), a Hardware Security Module (HSM), or a secure enclave.

3. The method for executing the secure cryptographic operation of Claim 1, wherein the at least two secure execution environments are located on at least two security devices.

4. The method for executing the secure cryptographic operation of Claim 3, wherein the at least two devices may be located on remote systems.

5. The method for executing the secure cryptographic operation of Claim 1, wherein the secure cryptographic operation is decryption or reconstruction of a private key that is used in a blockchain transaction.

6. The method for executing the secure cryptographic operation of Claim 1, further

comprising: disabling the private keys, or key splits, or distributed key variants unless each security container verifies integrity of the other security containers.

7. The method for executing the secure cryptographic operation of Claim 6, wherein

verifying the integrity of the other security containers includes verifying proximity.

8. The method for executing the secure cryptographic operation of Claim 1, wherein a

blockchain is used to maintain reference measurements of the security containers.

9. The method for executing the secure cryptographic operation of Claim 1, wherein the secure cryptographic operation is executed only if the private keys, or key splits, or distributed key variants are used by the cryptographic protocol within a set time window.

10. The method for executing the secure cryptographic operation of Claim 1, further

comprising utilizing business logic when utilizing the enabled private keys, or key splits, or distributed key variants and recording the attestation of that business logic to generate a unique fingerprint.

11. The method for executing the secure cryptographic operation of Claim 10, further

comprising updating the security container’s attestation signatures.

12. The method for executing the secure cryptographic operation of Claim 11, wherein

updating a security container’s attestation signatures requires permission from the other security containers.

13. The method for executing the secure cryptographic operation of Claim 1, wherein the private keys, or key splits, or variants can be migrated from a first of the security containers to a second set of the security containers wherein the first and second set of security containers are composed of one or more security containers maintained by the at least two secure execution environments.

14. The method for executing the secure cryptographic operation of Claim 1, wherein the private keys, or key splits, or variants can be provably archived from one or more security containers to a trusted third party.

15. The method for executing in the cryptographic operation of Claim 14, wherein the private keys, or key splits, or variants can be provably restored from the trusted third party to the one or more security containers.

16. A system for executing a secure cryptographic operation while maintaining multiple independent points of control, the system comprising;

at least two secure execution environments which maintain security containers for confidential cryptographic operations in which one or more private keys, key splits, or distributed key variations are created and registered and the private keys, or key splits, or distributed key variants can be independently enabled and disabled; and

a processor configured to: i) initiate the secure cryptographic operation, the secure cryptographic operation having a cryptographic protocol, ii) perform the cryptographic protocol utilizing enabled private keys, or key splits, or distributed key variants; and iii) execute the secure cryptographic operation only if a threshold of the private keys or key splits, or distributed key variants are enabled.

17. The system for executing in the cryptographic operation of Claim 16, wherein the at least two secure execution environments include at least one of the following: a Subscriber Identity Module (SIM), a Trusted Execution Environment (TEE), a Trusted Platform Module (TPM), a Secure Element (SE), a IS07816 Smartcard (SC), a Hardware Security Module (HSM), or a secure enclave.

18. The system for executing in the cryptographic operation of Claim 16, wherein the at least two secure execution environments are located on at least two security devices.

19. The system for executing the secure cryptographic operation of Claim 18, wherein the at least two security devices are located on remote systems.

20. The system for executing the secure cryptographic operation of Claim 16, wherein the secure cryptographic operation is the decryption or reconstruction of a private key that is used in a blockchain transaction.

21. The system for executing the secure cryptographic operation of Claim 16, wherein the private keys, or key splits, or distributed key variants are disabled unless each security container verifies the integrity of the other security containers.

22. The system for executing the secure cryptographic operation of Claim 21, wherein verifying the integrity of the other security containers includes verifying proximity.

23. The system for executing the secure cryptographic operation of Claim 16, further

comprising a blockchain used to maintain reference measurements of the security containers

24. The system for executing the secure cryptographic operation of Claim 16, wherein the processor is further configured to execute the secure cryptographic operation only if the private keys, or key splits, or distributed key variants are used by the cryptographic protocol within a set time window.

25. The system for executing the secure cryptographic operation of Claim 16, wherein the processor is further configured to apply business logic when utilizing the enabled private keys, or key splits, or distributed key variants and record the attestation of that business logic to generate a unique fingerprint.

26. The system for executing the secure cryptographic operation of Claim 25, wherein the processor is further configured to update the attestation signatures of the security containers.

27. The system for executing the secure cryptographic operation of Claim 26, wherein

updating a security container’s attestation signatures requires the permission of the other security containers.

28. The system for executing the secure cryptographic operation of Claim 16, further

comprising:

a first and second set of security containers composed of one or more security containers maintained by the at least two secure execution environments, wherein the private keys, or key splits, or variants can be migrated from the first set of the security containers to the second set of the security containers.

29. The system for executing the secure cryptographic operation of Claim 16, further

comprising:

a trusted third party, wherein the private keys, or key splits, or variants can be provably archived to or from the one or more security containers.

30. The system for executing in the cryptographic operation of Claim 29, wherein the private keys, or key splits, or variants can be provably restored from the trusted third party to the one or more security containers.

31. A computer implemented method for establishing multiple independent roots of trust, the method comprising:

distributing an asset across at least two security domains each associated with a respective original condition at a time of the distributing;

verifying integrity of the respective original condition at each of the at least two security domains;

enabling release of the asset distributed in an event that each of the at least two security domains attests that its respective current condition matches its respective original condition; and

preventing release of the asset distributed in an event that one or more security domains of the at least two security domains does not attest that its respective current condition matches its respective original condition.

32. The method of Claim 31, wherein the verifying includes utilizing at least one trusted measurement service to perform one or more integrity measurement and verification of the respective current condition relative to the respective original condition.

33. The method of Claim 31, wherein, in an event release is enabled, the method further includes releasing the asset from at least one security domain of the at least two security domains to a trusted process.

34. The method of Claim 31, further comprising managing control of the asset distributed, independently, within the at least two security domains.

35. The method of Claim 31, wherein the asset includes a first portion and a second portion and the method further comprises:

controlling, by a user, the first portion of the asset, the first portion residing in a first security domain of the at least two security domains; and

controlling, by a MNO, the second portion of the asset, the second portion residing in a second security domain of the at least two security domains.

36. The method of Claim 35, wherein the first security domain is a Trusted Execution Environment (TEE) and the second security domain is a Subscriber Identity Module (SIM).

37. The method of Claim 31, wherein the asset distributed is a cryptographic key.

38. A system for establishing multiple independent roots of trust, the system comprising:

at least two security domains; and

a processor, the processor configured to distribute an asset across the at least two security domains, the at least two security domains each associated with a respective original condition at a time that the asset is distributed, wherein each of the least two security domains is configured to:

verify integrity of its respective original condition;

enable release of the asset distributed in an event that each of the at least two security domains attests that its respective current condition matches its respective original condition; and

prevent release of the asset distributed in an event that one or more security domains of the at least two security domains do not attest that its respective current condition matches its respective original condition.

39. The system of Claim 38, wherein, to verify integrity, each of the at least two security domains is further configured to utilize at least one trusted measurement service to perform one or more integrity measurement and verification of the respective current condition relative to the respective original condition.

40. The system of Claim 38, wherein, in an event release is enabled, at least one security domain of the at least two security domains is further configured to release the asset to a trusted process.

41. The system of Claim 38, wherein each security domain of the at least two security

domains is further configured to manage control of the asset distributed, independently.

42. The system of Claim 38, wherein the asset includes a first portion and a second portion and wherein: a first security domain of the at least two security domains is configured to enable control, by a user, of the first portion of the asset, the first portion residing in the first security domain; and

a second security domain of the at least two security domains is configured to enable control, by a MNO, of the second portion of the asset, the second portion residing in the second security domain.

43. The system of Claim 42, wherein the first security domain is a Trusted Execution

Environment (TEE) and the second security domain is a Subscriber Identity Module (SIM).

44. The system of Claim 38, wherein the asset distributed is a cryptographic key.