WO2025102012A1 - Systèmes et procédés de génération de clé distribuée pour déchiffrement à base de quorum - Google Patents

Systèmes et procédés de génération de clé distribuée pour déchiffrement à base de quorum Download PDF

Info

Publication number
WO2025102012A1
WO2025102012A1 PCT/US2024/055279 US2024055279W WO2025102012A1 WO 2025102012 A1 WO2025102012 A1 WO 2025102012A1 US 2024055279 W US2024055279 W US 2024055279W WO 2025102012 A1 WO2025102012 A1 WO 2025102012A1
Authority
WO
WIPO (PCT)
Prior art keywords
trusted
key
data
keys
private
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/US2024/055279
Other languages
English (en)
Inventor
Pavan Gupta
Michael Scott Blum
Mary Elizabeth CHALK
Robert Derward Rogers
Syam Babu Malampati
Sudish MOGLI
Kurian Davy Manavalan
Taljinder Kaur
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BeekeeperAI Inc
Original Assignee
BeekeeperAI Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US18/941,314 external-priority patent/US20250068766A1/en
Application filed by BeekeeperAI Inc filed Critical BeekeeperAI Inc
Publication of WO2025102012A1 publication Critical patent/WO2025102012A1/fr
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H04L9/3073—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves involving pairings, e.g. identity based encryption [IBE], bilinear mappings or bilinear pairings, e.g. Weil or Tate pairing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3257—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using blind signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/46—Secure multiparty computation, e.g. millionaire problem

Definitions

  • the present invention relates in general to the field of confidential computing, and more specifically to methods, computer programs and systems for distributed key generation for quorum-based content management.
  • Such systems and methods are particularly useful in situations where multiple parties such as algorithm developers, data stewards, trusted computing management service providers, and the like wish to operate in tandem to ensure content is only made available when the various parties arc all in agreement that said data should be decryptable/shared.
  • the data itself may be secret in some manner.
  • the data could also be proprietary, being of a significant asset value.
  • the data may be subject to some control or regulation. This is particularly true in the case of medical information.
  • Protected health information, or PHI for example, is subject to a myriad of laws, such as HIPAA and GDPR, that include strict requirements on the sharing of PHI, and are subject to significant fines if such requirements are not adhered to.
  • data sharing is problematic.
  • data release (regardless of data type) may be subject to numerous ‘mechanical criteria’ such as being performed in a GDPR compliant jurisdiction. Layered on top of these mechanical considerations is often a need for a quorum of parties (full or partial) to agree to the release of data.
  • the present systems and methods relate to the distributed generation of encryption keys. Such systems allow for control over content decryption to situations only when a quorum of entities are in agreement that a decryption event should occur.
  • a public key and a private key are generated using elliptical curve cryptography (ECC) at a group of trusted parties.
  • ECC elliptical curve cryptography
  • Each party also generates a commitment and a blinding factor.
  • the blinding factor may be a randomized polynomial integer.
  • the parties use the commitments from the other parties to validate the public keys before receipt and combining the public keys into a group/aggregate public key.
  • Content encryption keys (CEK) are then encrypted at each of the trusted parties using these aggregate public keys to generate wrapped content encryption keys (WCEK).
  • WEK wrapped content encryption keys
  • Private keys are sharded and a sharded private key is generated at each party using the pieces of shards received by the trusted party.
  • Sharding the private key includes dividing the private key in each trusted party into N pieces, wherein N is an integer corresponding to the number of the trusted parties, generating a schema for which unique piece of each private key is to be sent to each of the trusted parties, and transferring through direct communication between each of the trusted parties the appropriate unique piece of the private key according to the schema.
  • criteria may be received that allows for the release of these sharded private keys back to a trusted environment/enclave.
  • the criteria include a location requirement for the plurality of trusted parties, in some cases.
  • the private keys may then be reassembled as an aggregate private key, and the WCEK can be decrypted using this aggregated private key.
  • Prior to releasing the sharded keys it may be desirable to perform an attestation on the trusted computing environment. This attestation may include an internal attestation and a third-party attestation.
  • Figure 1A and IB are example block diagrams of a system for zero trust computing of data by an algorithm, in accordance with some embodiment
  • Figure 2 is an example block diagram showing the core management system, in accordance with some embodiment
  • Figure 3 is an example block diagram showing an example model for the confidential computing data flow, in accordance with some embodiment
  • Figure 4 is a flowchart for an example process for the operation of the confidential computing data processing system, in accordance with some embodiment
  • Figure 5 a flowchart for an example process of acquiring and curating data, in accordance with some embodiment
  • Figure 6 a flowchart for an example process of onboarding a new host data steward, in accordance with some embodiment
  • Figure 7 is a flowchart for an example process of encapsulating the algorithm and data, in accordance with some embodiment
  • Figure 8 is a flowchart for an example process of algorithm encryption and handling, in accordance with some embodiment.
  • Figure 9 is an example block diagram showing key generation and validation, in accordance with some embodiment;
  • Figure 10 is an example block diagram showing key aggregation, in accordance with some embodiment
  • Figures 11A and 1 IB are example block diagrams showing key sharding and reassembly, in accordance with some embodiment
  • Figure 15 is a flowchart for an example process of key generation and validation, in accordance with some embodiment
  • Figure 16 is a flowchart for an example process of content key encryption, in accordance with some embodiment
  • Figure 17 is a flowchart for an example process of key sharding, in accordance with some embodiment
  • Figure 18 is a flowchart for an example process wrapping content encryption keys, in accordance with some embodiment
  • Figure 20 is a flowchart for an example process of content encryption key decryption, in accordance with some embodiment.
  • Figures 21A and 21B are illustrations of computer systems capable of implementing the confidential computing, in accordance with some embodiments.
  • the present invention relates to systems and methods for the confidential computing application on one or more algorithms processing sensitive datasets.
  • Such systems and methods may be applied to any given dataset, but may have particular utility within the healthcare setting, where the data is extremely sensitive.
  • the following descriptions will center on healthcare use cases.
  • the information processed may include sensitive industry information, financial, payroll or other personally identifiable information, or the like.
  • PHI protected health information
  • the data stewards are generally thought to be a hospital or other healthcare entity, these data stewards may in reality be any entity that has and wishes to process their data within a zero-trust environment.
  • an algorithm may include machine learning (ML) models, neural network models, or other artificial intelligence (Al) models.
  • algorithms may also apply to more mundane model types, such as linear models, least mean squares, or any other mathematical functions that convert one or more input values, and results in one or more output models.
  • node infrastructure
  • enclave may be utilized. These terms arc intended to be used interchangeably and indicate a computing architecture that is logically distinct (and often physically isolated). In no way does the utilization of one such term limit the scope of the disclosure, and these terms should be read interchangeably.
  • Figure 1A is an example of a confidential computing infrastructure, shown generally at 100a.
  • This infrastructure includes one or more algorithm developers 120a-x which generate one or more algorithms for processing of data, which in this case is held by one or more data stewards 160a-y.
  • the algorithm developers are generally companies that specialize in data analysis, and are often highly specialized in the types of data that are applicable to their given models/algorithms. However, sometimes the algorithm developers may be individuals, universities, government agencies, or the like.
  • Al and machine learning (ML) can improve care, increase efficiency, and reduce costs. For example, Al analysis of chest x-rays predicted the progression of critical illness in COVID-19.
  • an image-based deep learning model developed at MIT can predict breast cancer up to five years in advance.
  • an algorithm developed at University of California San Francisco which can detect pneumothorax (collapsed lung) from CT scans, helping prioritize and treat patients with this life-threatening condition — the first algorithm embedded in a medical device to achieve FDA approval.
  • the data stewards may include public and private hospitals, companies, universities, banks and other financial institutions, governmental agencies, or the like. Indeed, virtually any entity with access to sensitive data that is to be analyzed may be a data steward.
  • the generated algorithms are encrypted at the algorithm developer in whole, or in pail, before transmitting to the data stewards, in this example ecosystem.
  • the algorithms are transferred via a core management system 140, which may supplement or transform the data using a localized datastore 150.
  • the core management system also handles routing and deployment of the algorithms.
  • the datastore may also he leveraged for key management in some embodiments that will be discussed in greater detail below.
  • Each of the algorithm developer 120a-x, and the data stewards 160a-y and the core management system 140 may be coupled together by a network 130.
  • the network is comprised of a cellular network and/or the internet.
  • the network includes any wide area network (WAN) architecture, including private WAN’s, or private local area networks (LANs) in conjunction with private or public WANs.
  • WAN wide area network
  • LANs local area networks
  • the data stewards maintain sequestered computing nodes 1 lOa-y which function to actually perform the computation of the algorithm on the dataset.
  • the sequestered computing nodes or “enclaves”, may be physically separate computer server systems, or may encompass virtual machines operating within a greater network of the data steward’s systems.
  • the sequestered computing nodes should be thought of as a vault.
  • the encrypted algorithm and encrypted datasets are supplied to the vault, which is then sealed.
  • Encryption keys 390 as seen in Figure 3, unique to the vault are then provided, which allows the decryption of the data and models to occur. No party has access to the vault at this time, and the algorithm is able to securely operate on the data.
  • the data and algorithms may then be destroyed, or maintained as encrypted, when the vault is “opened” in order to access the report/output derived from the application of the algorithm on the dataset.
  • This system relies upon public -private key techniques, where the algorithm developer utilizes the public key 390 for encryption of the algorithm, and the sequestered computing node includes the private key in order to perform the decryption.
  • the private key may be hardware (in the case of Azure, for example) or software linked (in the case of AWS, for example).
  • the algorithm may be encrypted using a symmetric key, and the symmetric key may be wrapped encrypted by a public key.
  • the algorithm developer has their own symmetrical key (content encryption key) used to encrypt the algorithm.
  • the algorithm developer uses the public key to encrypt or “wrap” the content encryption key. The unwrapping occurs in the vault using the private half of the key, to then enable the content encryption key to decrypt the algorithm.
  • the system sends algorithm models via an Azure Confidential Computing environment to a data steward’s environment.
  • the model and the data entered the Intel SGX sequestered enclave where the model is able to be validated against the protected information, for example PHI, data sets.
  • the algorithm owner cannot see the data
  • the data steward cannot see the algorithm model
  • the management core can see neither the data nor the model.
  • an Intel SGX enclave is but one substantiation of a hardware enabled trusted execution environment. Other hardware and/or software enabled trusted execution environments may be readily employed in other embodiments.
  • the data steward uploads encrypted data to their cloud environment using an encrypted connection that terminates inside an Intel SGX-sequestered enclave.
  • the encrypted data may go into Blob storage prior to terminus in the sequestered enclave, where it is pulled upon as needed.
  • the algorithm developer submits an encrypted, containerized Al model which also terminates into an Intel SGX- sequestered enclave.
  • a key management system in the management core enables the containers to authenticate and then run the model on the data within the enclave. In alternate embodiments, where distributed keys are utilized, there is no need for a key management system.
  • the system is fully distributed among the parties, as shall be described in greater detail below.
  • the data steward never sees the algorithm inside the container and the data is never visible to the algorithm developer. Neither component leaves the enclave.
  • the developer receives a performance report on the values of the algorithm’s performance.
  • the algorithm owner may request that an encrypted artifact containing information about validation results is stored for regulatory compliance purposes and the data and the algorithm are wiped from the system.
  • Figure IB provides a similar ecosystem 100b.
  • This ecosystem also includes one or more algorithm developers 120a-x, which generate, encrypt and output their models.
  • the core management system 140 receives these encrypted payloads, and in some embodiments, transforms or augments unencrypted portions of the payloads.
  • the major difference between this substantiation and the prior figure, is that the sequestered computing node(s) HOa-y are present within a third-party host 170a-y.
  • An example of a third-party host may include an offsite server such as Amazon Web Service (AWS) or similar cloud infrastructure.
  • Other examples can include any network-connected environment, such as traditional data centers.
  • AWS Amazon Web Service
  • the data steward encrypts their dataset(s) and provides them, via the network, to the third party hosted sequestered computing node(s) llOa-y.
  • the output of the algorithm running on the dataset is then transferred from the sequestered computing node in the third-party, back via the network to the data steward (or potentially some other recipient).
  • the system relies on a unique combination of software and hardware available through Azure Confidential Computing.
  • the solution uses virtual machines (VMs) running on specialized Intel processors with Intel Software Guard Extension (SGX), in this embodiment, running in the third-party system.
  • VMs virtual machines
  • SGX Intel Software Guard Extension
  • Intel SGX creates sequestered portions of the hardware’s processor and memory known as “enclaves” making it impossible to view data or code inside the enclave.
  • Software within the management core handles encryption, key management, and workflows.
  • the system may be some hybrid between Figures 1A and IB.
  • some datasets may be processed at local sequestered computing nodes, especially extremely large datasets, and others may be processed at third parties.
  • Such systems provide flexibility based upon computational infrastructure, while still ensuring all data and algorithms remain sequestered and not visible except to their respective owners.
  • the core management system 140 may include a data science development module 210, a data harmonizer workflow creation module 250, a software deployment module 230, a federated master algorithm training module 220, a system monitoring module 240, and a data store comprising global join data 240.
  • the data science development module 210 may be configured to receive input data requirements from the one or more algorithm developers for the optimization and/or validation of the one or more models.
  • the input data requirements define the objective for data curation, data transformation, and data harmonization workflows.
  • the input data requirements also provide constraints for identifying data assets acceptable for use with the one or more models.
  • the data harmonizer workflow creation module 250 may be configured to manage transformation, harmonization, and annotation protocol development and deployment.
  • the software deployment module 230 may be configured along with the data science development module 210 and the data harmonizer workflow creation module 250 to assess data assets for use with one or more models. This process can be automated or can be an interactive search/query process.
  • the software deployment module 230 may be further configured along with the data science development module 210 to integrate the models into a sequestered capsule computing framework, along with required libraries and resources.
  • the federated master algorithm training module may be configured to aggregate the learning from the disjoint data sets into a single master algorithm.
  • the algorithmic methodology for the federated training may be different. For example, sharing of model parameters, ensemble learning, parent-teacher learning on shared data and many other methods may be developed to allow for federated training.
  • the privacy and security requirements, along with commercial considerations such as the determination of how much each data system might be paid for access to data, may determine which federated training methodology is used.
  • the system monitoring module 240 monitors activity in sequestered computing nodes. Monitored activity can range from operational tracking such as computing workload, error state, and connection status as examples to data science monitoring such as amount of data processed, algorithm convergence status, variations in data characteristics, data errors, algorithm/model performance metrics, and a host of additional metrics, as required by each use case and embodiment.
  • data science monitoring such as amount of data processed, algorithm convergence status, variations in data characteristics, data errors, algorithm/model performance metrics, and a host of additional metrics, as required by each use case and embodiment.
  • join data may be transmitted to sequestered computing nodes to be joined with their proprietary datasets during data harmonization or computation.
  • the sequestered computing nodes may include a harmonizer workflow module 250, harmonized data, a runtime server, a system monitoring module, and a data management module (not shown).
  • the transformation, harmonization, and annotation workflows managed by the data harmonizer workflow creation module may be deployed by and performed in the environment by harmonizer workflow module using transformations and harmonized data.
  • the join data may be transmitted to the harmonizer workflow module to be joined with data during data harmonization.
  • the runtime server may be configured to run the private data sets through the algorithm/model.
  • the system monitoring module monitors activity in the sequestered computing node. Monitored activity may include operational tracking such as algorithm/model intake, workflow configuration, and data host onboarding, as required by each use case and embodiment.
  • the data management module may be configured to import data assets such as private data sets while maintaining the data assets within the pre-exiting infrastructure of the data stewards.
  • the Zero-Trust Encryption System 320 manages the encryption, by an encryption server 323, of all the algorithm developer’s 120 software assets 321 in such a way as to prevent exposure of intellectual property (including source or object code) to any outside party, including the entity running the core management system 140 and any affiliates, during storage, transmission and runtime of said encrypted algorithms 325.
  • the algorithm developer is responsible for encrypting the entire pay load 325 of the software using its own encryption keys. Decryption is only ever allowed at runtime in a sequestered capsule computing environment 110.
  • the sequestered computing node 110 receives the encrypted software assets 325 and encrypted data steward dataset(s) 350 and manages their decryption in a way that prevents visibility to any data or code at runtime at the runtime server 330. In different embodiments this can be performed using a variety of secure computing enclave technologies, including but not limited to hardware-based and software-based isolation.
  • the data steward 160 has access to protected health information and/or other sensitive information.
  • the data steward 160 never is required to transfer this data outside of its ecosystem (an if it is, it may remain in an encrypted state) thus ensuring that the data is always inaccessible by any other party by virtue of it remaining encrypted when accessible by any other party.
  • the sensitive data may be encrypted (or remain in the clear) as it is also transferred into the sequestered computing node 110.
  • This data store is made accessible to the runtime server 330 also located “inside” the sequestered computing node 110.
  • the runtime server 330 decrypts the encrypted algorithm 325 to yield the underlying algorithm model.
  • This algorithm may then use the data store to generate inferences regarding the date contained in the data store (not illustrated). These inferences have value for the data steward 110 as well as other interested parties and may be outputted to the data steward (or other interested parties such as researchers or regulators) for consumption.
  • the runtime server 330 may likewise engage in training activities.
  • the runtime server 330 may also perform a number of other operations, such as the generation of a performance model or the like.
  • the performance model is a regression model generated based upon the inferences derived from the algorithm.
  • the performance model provides data regarding the performance of the algorithm based upon the various inputs.
  • the performance model may model for any of algorithm accuracy, Fl score, precision, recall, dice score, ROC (receiver operator characteristic) curve/area, log loss, Jaccard index, error, R 2 , by some combination thereof, or by any other suitable metric.
  • the algorithm developer 120 may be decrypted, and leveraged to validate the algorithm and, importantly, may be leveraged to actively train the algorithm in the future.
  • the algorithm developer provides the algorithm to the system using whichever process they locally employ.
  • at least one algorithm/model is generated by the algorithm developer using their own development environment, tools, and seed data sets (e.g., training/testing data sets).
  • the algorithms may be trained on external datasets instead, as will be discussed further below.
  • the algorithm developer provides constraints (at 410) for the optimization and/or validation of the algorithm(s). Constraints may include any of the following: (i) training constraints, (ii) data preparation constraints, and (iii) validation constraints.
  • constraints define objectives for the optimization and/or validation of the algorithm(s) including data preparation (e.g., data curation, data transformation, data harmonization, and data annotation), model training, model validation, and reporting.
  • the training constraints may include, but are not limited to, at least one of the following: hyperparameters, regularization criteria, convergence criteria, algorithm termination criteria, training/validation/test data splits defined for use in algorithm(s), and training/testing report requirements.
  • a model hyper parameter is a configuration that is external to the model, and which value cannot be estimated from data.
  • the hyperparameters are settings that may be tuned or optimized to control the behavior of a ML or Al algorithm and help estimate or learn model parameters.
  • Regularization constrains the coefficient estimates towards zero. This discourages the learning of a more complex model in order to avoid the risk of overfitting. Regularization, significantly reduces the variance of the model, without a substantial increase in its bias.
  • the convergence criterion is used to verify the convergence of a sequence (e.g., the convergence of one or more weights after a number of iterations).
  • the algorithm termination criteria define parameters to determine whether a model has achieved sufficient training. Because algorithm training is an iterative optimization process, the training algorithm may perform the following steps multiple times. In general, termination criteria may include performance objectives for the algorithm, typically defined as a minimum amount of performance improvement per iteration or set of iterations.
  • the training/testing report may include criteria that the algorithm developer has an interest in observing from the training, optimization, and/or testing of the one or more models.
  • the constraints for the metrics and criteria are selected to illustrate the performance of the models.
  • the metrics and criteria such as mean percentage error may provide information on bias, variance, and other errors that may occur when finalizing a model such as vanishing or exploding gradients.
  • Bias is an error in the learning algorithm. When there is high bias, the learning algorithm is unable to learn relevant details in the data.
  • Variance is an error in the learning algorithm, when the learning algorithm tries to over-learn from the dataset or tries to fit the training data as closely as possible.
  • common error metrics such as mean percentage error and R2 score are not always indicative of accuracy of a model, and thus the algorithm developer may want to define additional metrics and criteria for a more in depth look at accuracy of the model.
  • data assets that will be subjected to the algorithm(s) are identified, acquired, and curated (at 420).
  • Figure 5 provides greater detail of this acquisition and curation of the data.
  • the data may include healthcare related data (PHI).
  • PHI healthcare related data
  • the identification process may be performed automatically by the platform running the queries for data assets (e.g., running queries on the provisioned data stores using the data indices) using the input data requirements as the search terms and/or filters.
  • this process may be performed using an interactive process, for example, the algorithm developer may provide search terms and/or filters to the platform.
  • the platform may formulate questions to obtain additional information, the algorithm developer may provide the additional information, and the platform may run queries for the data assets (e.g., running queries on databases of the one or more data hosts or web crawling to identify data hosts that may have data assets) using the search terms, filters, and/or additional information.
  • the identifying is performed using differential privacy for sharing information within the data assets by describing patterns of groups within the data assets while withholding private information about individuals in the data assets.
  • the process If the assets are not available, the process generates a new data steward node (at 520).
  • the data query and onboarding activity (surrounded by a dotted line) is illustrated in this process flow of acquiring the data; however, it should be realized that these steps may be performed any time prior to model and data encapsulation (step 450 in Figure 6).
  • Onboarding/creation of a new data steward node is shown in greater detail in relation to Figure 6.
  • a data host compute and storage infrastructure e.g., a sequestered computing node as described with respect to Figures 1A-5
  • the provisioning includes deployment of encapsulated algorithms in the infrastructure, deployment of a physical computing device with appropriately provisioned hardware and software in the infrastructure, deployment of storage (physical data stores or cloud-based storage), or deployment on public or private cloud infrastructure accessible via the infrastructure, etc.
  • governance and compliance requirements are performed (at 625).
  • the governance and compliance requirements include getting clearance from an institutional review board, and/or review and approval of compliance of any project being performed by the platform and/or the platform itself under governing law such as the Health Insurance Portability and Accountability Act (HIPAA).
  • HIPAA Health Insurance Portability and Accountability Act
  • the data assets may be transferred from existing storage locations and formats to provisioned storage (physical data stores or cloud-based storage) for use by the sequestered computing node (curated into one or more data stores).
  • the data assets may then be obfuscated (at 645).
  • Data obfuscation is a process that includes data encryption or tokenization, as discussed in much greater detail below.
  • the data assets may be indexed (at 655). Data indexing allows queries to retrieve data from a database in an efficient manner.
  • the indexes may be related to specific tables and may be comprised of one or more keys or values to be looked up in the index (e.g., the keys may be based on a data table's columns or rows).
  • the project may be configured (at 530).
  • the data steward computer and storage infrastructure is configured to handle a new project with the identified data assets.
  • the configuration is performed similarly to the process described of Figure 6.
  • regulatory approvals e.g., IRB and other data governance processes
  • the new data is provisioned (at 550).
  • the data storage provisioning includes identification and provisioning of a new logical data storage location, along with creation of an appropriate data storage and query structure.
  • a query is performed if there is a need for data annotation (at 430). If so, the data is initially harmonized (at 433) and then annotated (at 435).
  • Data harmonization is the process of collecting data sets of differing file formats, naming conventions, and columns, and transforming it into a cohesive data set.
  • the annotation is performed by the data steward in the sequestered computing node.
  • a key principle to the transformation and annotation processes is that the platform facilitates a variety of processes to apply and refine data cleaning and transformation algorithms, while preserving the privacy of the data assets, all without requiring data to be moved outside of the technical purview of the data steward.
  • Another query determines if additional data harmonization is needed (at 440). If so, then there is another harmonization step (at 445) that occurs in a manner similar to that disclosed above.
  • the models and data are encapsulated (at 450). Data and model encapsulation is described in greater detail in relation to Figure 7.
  • the protected data, and the algorithm are each encrypted (at 710 and 730 respectively).
  • the data is encrypted either using traditional encryption algorithms (e.g., RSA) or homomorphic encryption.
  • the encrypted data and encrypted algorithm are provided to the sequestered computing node (at 720 and 740 respectively).
  • There processes of encryption and providing the encrypted payloads to the sequestered computing nodes may be performed asynchronously, or in parallel.
  • the sequestered computing node may phone home to the core management node (at 750) requesting the keys needed. These keys are then also supplied to the sequestered computing node (at 760), thereby allowing the decryption of the assets.
  • a first embodiment of the system for confidential computing processing of the data assets by the algorithm is provided, at 800.
  • the algorithm is initially generated by the algorithm developer (at 810) in a manner similar to that described previously.
  • the entire algorithm, including its container, is then encrypted (at 820), using a public key, by the encryption server within the algorithm developer’s infrastructure.
  • the entire encrypted payload is provided to the core management system (at 830).
  • the core management system then distributes the encrypted payload to the sequestered computing enclaves (at 840).
  • the data steward collects the data assets desired for processing by the algorithm.
  • This data is also provided to the sequestered computing node. In some embodiments, this data may also be encrypted.
  • the sequestered computing node then contacts the core management system for the keys. The system relies upon public-private key methodologies for the decryption of the algorithm, and possibly the data (at 850).
  • the algorithm(s) are run (at 860) against the protected health information (or other sensitive information based upon the given use case).
  • the results are then output (at 870) to the appropriate downstream audience (generally the data steward or algorithm developer, but may include public health agencies or other interested parties).
  • FIG. 9 specifics of distributed key generation and verification for controlled access to content based upon a full or partial quorum is provided.
  • a plurality of trusted computing environments 910a-n each completing key generation and verification activities.
  • the trusted computing environments 910a-n include the algorithm developer, the core management system and one or more data stewards.
  • the trusted computing environments 910a-n are sequestered computing nodes operating within each of these entities.
  • the trusted computing environments 910a- n may comprise different sets of parties, including different combinations of data stewards, data stewards and downstream parties (e.g., regulators and/or researchers), data stewards and the core managements system, or any combination where each party involved is desired to provide key fragments (or “shards”) to the distributed key, and therefore be party to determining if/when/how the end content becomes accessible.
  • the trusted computing environments 910a-n each contain two functional systems, a key generation system 920 and a key verification system 930.
  • the Key generation system utilizes elliptical curve cryptography (ECC) techniques to generate a public key and a private key, at an ECC public key generator 921 and ECC private key generator 922, respectively.
  • ECC elliptical curve cryptography
  • EDSA elliptic curve digital signature algorithm
  • ECC may be leveraged due to the additive properties present in this form of cryptography.
  • ECC public keys may be added together to generate an aggregate group public key which will correspond to a simply added group of private keys in the enclave.
  • ECC curves that sport a bilinear pairing may be particularly useful in the following systems and methods.
  • the ECC generated private key is then combined in a hash with a message 923 at a commitment system 924.
  • the message is a timestamp, but can be any other token.
  • the resulting private key hash is then provided, along with the original private key, to a signing system 925, which adds a signature.
  • the public key, the original message 923 and the commitment are all provided to the interface 931 in the key verification module 930 for each of the trusted computing environments 910a-n. In this manner, the key can be verified for each trusted computing environment 910a-n by all other trusted computing environments 910a-n.
  • the message validator 932 validates the message and a key pair attestation module 933 proves that the counterparties have legitimate key pairs, random blinding factors and commitments. In this manner, each trusted computing environments 910a-n is capable of confirming the authenticity that each other trusted computing environments 910a-n have legitimate key pairs.
  • the public keys are integrated with one another in an aggregation process, as seen generally at 1000 in relation to Figure 10.
  • each party produces a commitment to a shamir secret sharing polynomial.
  • These commitments ensure that there are no bad actors gaming the secret sharing of keys.
  • the commitment process is a more rigorous way of demanding clarity on pre-created-key steps, and is added as an additional step to the core signature process.
  • Equation 1 [0090] Where ’is the shared secret
  • G is a well known generation on an elliptic curve
  • H is another point on the ECC curve
  • each party may distribute their public keys and shares of their secret key. Thresholding in the shamir secret sharing portion of this method can be adjusted. This allows each party to select polynomials in such a way that the curve can be interpolated with fewer participants.
  • a particular entity e.g., the core management system
  • the core management system is not critical per se, but rather the enclave itself is a participant in the process.
  • the enclave when preset, provides an attestation measurement, a signature of its downstream keys, and then it operates as normal. However, if the enclave is absent, this process does not complete. The parties will demand measurements signed by the enclave, thus preventing the process until an enclave is active for the generation of the participant quorum.
  • Each party has likewise generated a commitment 1017a-n, as discussed above.
  • Each party validates the commitment 1017a-n of the other party before accepting the public key 1015a-n.
  • the validation of the commitments 1017a-n is not performed within an enclave.
  • These public keys are collected in a key database 1024 via a key interface 1022 in an escrow enclave 1020.
  • the escrow enclave 1020 may be a sequestered computing node special-built for the purpose of collecting and aggregation the public keys.
  • the escrow enclave may reside within the core management system (a trusted party operating between the algorithm developers and data stewards).
  • the individual keys stored in the key database 1024 may then be aggregated by the key aggregator 1026 ⁇ and the result may be also stored in the key database/repository 1024.
  • the aggregated key may be supplied back to all or a subset of the trusted parties. This aggregated key is then used by these parties to encrypt data.
  • the commitment to the public key is as follows:
  • the ECC private keys may likewise be distributed, but unlike the public key which is aggregated and centrally stored, the private keys are fragmented into shards and sent from each party to the other parties for assembly of sharded keys.
  • Figures 11 A and 11B provide details around this process.
  • each trusted party 11 lOa-n includes it’ s ECC private key 1112, 1113 and 1115 respectively.
  • Each trusted party also includes their commitment 1017a-n, which is corresponds to the value of the polynomial. Each party keeps their binding factors for release secret.
  • the trusted parties break their individual ECC private keys into portions (known as shards).
  • the number of shards the keys are broken into corresponds to the number of parties involved in the transaction.
  • ECC private key A 1112 is split into N shards 1112a-n respectively, as there are N parties involved. When only two parties are present, only two shards would be generated. For a thousand parties, a thousand shards would be generated from each key.
  • the trusted parties 11 lOa-n are each coupled to one another via one or more networks 1150.
  • the networks may include any combination of wide area networks (WANs), local area networks (LANs), corporate networks, and the like.
  • the network 1150 includes at least some component of the Internet and/or cellular networks.
  • the network 1150 enables each of the trusted parties 11 lOa-n to communicate on a peer- to-peer basis to share shards between the given parties.
  • a schema is generated as to which party receives each shard. For example, party B 1110b may receive the shard 2 from each party.
  • Party N 11 lOn may receive, in this example, shard N from each party. As long as all parties know which shard number to provide each other party the exact shard number to party isn’t critical for operations.
  • each party results in a sharded key, as seen in Figure 1 IB at 1100B.
  • each trusted party 11 lOa-n includes a unique sharded key 1116, 1117 and 1118 respectively.
  • Each sharded key is comprised of a single shard from each of the trusted parties 11 lOa-n.
  • sharded key 1 1116 stored in trusted party A 1110a, is comprised of shard 1 from each of the trusted parties 11 lOa-n.
  • each sharded key in each trusted party 11 lOa-n is unique to the party, and includes secret information from each of the other trusted parties 11 lOa-n.
  • each party has the sharded keys
  • the process of wrapping the content encryption keys for each party can be performed, as seen generally at 1200 of Figure 12.
  • each trusted party A-N 11 lOa-n is illustrated.
  • Each party has a content encryption key 1212a-n that is unique to the given party 11 lOa-n, respectively.
  • Each party 11 lOa-n also has access to the aggregate public key 1205 that was generated in reference to Figure 10 and previously stored in the key repository of the escrow enclave.
  • the content encryption key 1212a-n may be provided to an encryption server 1214a-n at each trusted party 11 lOa-n, and is then wrapped (encrypted) using the aggregate key 1205.
  • WCEK wrapped content encryption key
  • This WCEK repository 1250 may reside in the core management system, which is generally viewed by most other parties as a “neutral” third party and is trusted to maintain such data.
  • each of the trusted parties A-N 11 lOa-n arc operating in a trusted execution environment 1310.
  • a trusted execution environment 1310 By operating in a trusted execution environment 1310, it requires that all parties are operating in sequestered computing nodes, as previously noted, and are taking the precautions that any runtime activities are inaccessible outside of these sequestered environments.
  • Each trusted party 11 lOa-n includes their individual wrapped content encryption key 1216a-n.
  • Raw evidence is provided to an internal verifier 1320.
  • the raw evidence verifier 1320 is part of the core management system.
  • the raw evidence verifier 1320 consumes this evidence.
  • This authority 1340 may be external to the trusted execution environment 1310.
  • this authority 1340 may include some third party.
  • the authority 1340 verifies the fidelity of the trusted execution environment 1310.
  • the authority 1340 may instruct the appropriate authority (again, generally the core management system) to release, or to instruct the other parties to release their given sharded keys 116, 117 and 118 respectively.
  • These sharded keys are provided back to an enclave 1350, which in some embodiments may be the trusted execution environment 1310.
  • Each party will share their random blinding values, their commitments as received, and their shards. This will allow the enclave to validate shard values.
  • Figure 14 provides more details on the processing of these sharded keys 1116, 1117 and 1118 respectively, as seen generally at 1400.
  • the sharded keys are disassembled and reconstituted into the ECC private keys 1112, 1113 and 1115 respectively.
  • the shards need to also include private random blinding values that the enclave can use to evaluate each of the commitment values each party is coming with.
  • An aggregator 1410 then takes these individual private keys and generates an aggregate private key.
  • This aggregated private key is provided to each of the trusted parties 1420 which have wrapped content encryption keys 1430.
  • the aggregated private key is used by a decryption module 1440 to unwrap/decrypt the content encryption key 1450 for the given party 1420.
  • This content encryption key 1450 may then be leveraged to release information/content for consumption by the trusted party 1420.
  • Figures 15-20 provide a more detailed description of example processes of distributed key generation.
  • the private and public keys are generated at each party (at 1510).
  • elliptical curve cryptography is utilized for this key generation process.
  • Each party also generates a commitment to the public key (as previously discussed) and a random binding factor (at 1520).
  • the commitment, public key and binding factor are then provided to all parties (at 1530) for verification.
  • Each party evaluates the other public keys associated with the commitment (at 1540). If the public keys are determined to be legitimate, then the aggregate public key can be generated (at 1550). If any of the commitments are gamed in any manner the system detects the issue when determining if the public keys are legitimate, thereby stopping the process. Similarly, upon sharding, the commitments may also be checked and ensure the process is secure.
  • the public keys are aggregated as seen at 1600 of Figure 16. Initially the public keys from each party are provided to an escrow enclave (at 1610), which is generally managed by the core management system. These keys are stored in a database repository (at 1620) and then are aggregated into the aggregate key (at 1630). A set of aggregate key recipients are selected (at 1640), and the aggregate key is provided back to these parties. The parties then utilize the aggregate key for encryption of content (at 1650).
  • each party may shard/fragment their private key according to the quorum type desired (at 1710). Generally, this includes generating a shard for each trusted party, but in some embodiments, only a subset of the trusted parties may receive a shard.
  • the shards are directly shared between the parties (at 1720). The system evaluates each randomly chosen polynomial (based on the threshold desired to reassemble a secret) at a point on the curve (at 1730). Then this value is shared with each party at a known location (at 1740).
  • the secret owner is going to also commit to this value using the standard commitment process above, and only when the enclave is up (at 1750) will the secret owner share the random blinding factor to each party.
  • the binding factor is used for a validation that the polynomial value is legitimate (at 1760). Assuming the legitimacy of each location on each curve, the enclave will then be responsible for assembling each individual party’s secret and will then proceed to assemble the final group secret key (at 1730).
  • content encryption keys for each party are wrapped, as seen at 1800 of Figure 18. This process begins with each party collecting a content encryption key (at 1810). The aggregate public key is then added to the content encryption key (at 1820) and is used to cncrypt/wrap the content encryption key (at 1830). The wrapped content encryption keys for each party involved are then transmitted to a trusted repository (at 1840). Generally, this repository may be part of the core management system, but any trusted party may perform this role.
  • the trusted computing environment may undergo an attestation process for the release and utilization of the sharded private keys, shown generally at 1900 in relation to Figure 19.
  • the raw evidence regarding the trusted computing environment is initially generated (at 1910).
  • the computing environment is verified based upon the raw evidence to generate a refined set of evidence (at 1920).
  • This refined evidence is then passed to a third party for verification of the environment (at 1930).
  • Attestation results, or tokens, are generated to send to the trusted execution environment authority (at 1940).
  • the system may also undergo attestation of other, non-trusted environment “mechanical criteria”.
  • This mechanical criterion may be any desired criteria.
  • a dataset subject to GDPR may include criteria that each of the trusted parties are in GDPR compliant jurisdictions. If attestation is successful and all criteria is met (at 1950) the authority may release and/or signal release of the sharded private keys (at 1960). If any criterion is absent, the system may refrain from releasing the sharded private keys.
  • the sharded keys are then utilized to decrypt the WCEKs, as seen generally at 2000 in relation to Figure 20.
  • the sharded keys after release, are made available to the trusted computing environment along with the blinding factors and the commitments (at 2010).
  • the ECC private keys are the reassembled from the various sharded keys after evaluation of the blinding factors and commitments (at 2020) and these reassembled private keys may be aggregated into a group private key (at 2030).
  • the system may determine if it is desired to undergo a similar attestation process as was performed on the trusted environment (at 2040). If so, attestation may occur (at 2050). After attestation (or if it wasn’t needed/desired) the group private key may be provided to each parly (at 2060). This enables decryption of the wrapped content encryption keys for downstream uses, such as the decryption of data within the environment (at 2070).
  • LLMs Large Language Models
  • a LLM is trained on various sources of data found in each of the trusted parties.
  • the LLM by its nature, “memorizes” some of the underlying training data.
  • an LLM may be a source of data exfiltration, and as such the parties may desire to require a quorum before the LLM is released and made usable by the parties.
  • Figures 21A and 21B illustrate a Computer System 2100, which is suitable for implementing embodiments of the present invention.
  • Figure 21A shows one possible physical form of the Computer System 2100.
  • the Computer System 2100 may have many physical forms ranging from a printed circuit board, an integrated circuit, and a small handheld device up to a huge supercomputer.
  • Computer system 2100 may include a Monitor 2102, a Display 2104, a Housing 2106, server blades including one or more storage Drives 2108, a Keyboard 2110, and a Mouse 2112.
  • Medium 2114 is a computer-readable medium used to transfer data to and from Computer System 2100.
  • Figure 21B is an example of a block diagram for Computer System 2100. Attached to System Bus 2120 are a wide variety of subsystems.
  • Processor(s) 2122 also referred to as central processing units, or CPUs
  • Memory 2124 includes random access memory (RAM) and read-only memory (ROM).
  • RAM random access memory
  • ROM read-only memory
  • RAM random access memory
  • ROM read-only memory
  • Both of these types of memories may include any suitable form of the computer-readable media described below.
  • a Fixed Medium 2126 may also be coupled bi-directionally to the Processor 2122; it provides additional data storage capacity and may also include any of the computer-readable media described below.
  • Fixed Medium 2126 may be used to store programs, data, and the like and is typically a secondary storage medium (such as a hard disk) that is slower than primary storage. It will be appreciated that the information retained within Fixed Medium 2126 may, in appropriate cases, be incorporated in standard fashion as virtual memory in Memory 2124.
  • Removable Medium 2114 may take the form of any of the computer-readable media described below.
  • Processor 2122 is also coupled to a variety of input/output devices, such as Display 2104, Keyboard 21 10, Mouse 2112 and Speakers 2130.
  • an input/output device may be any of: video displays, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, biometrics readers, motion sensors, brain wave readers, or other computers.
  • Processor 2122 optionally may be coupled to another computer or telecommunications network using Network Interface 2140.
  • the Processor 2122 might receive information from the network, or might output information to the network in the course of performing the above-described confidential computing processing of protected information, for example PHI.
  • method embodiments of the present invention may execute solely upon Processor 2122 or may execute over a network such as the Internet in conjunction with a remote CPU that shares a portion of the processing.
  • a software program is assumed to be stored at any known or convenient location (from non-volatile storage to hardware registers) when the software program is referred to as “implemented in a computer-readable medium.”
  • a processor is considered to be “configured to execute a program” when at least one value associated with the program is stored in a register readable by the processor.
  • the computer system 2100 can be controlled by operating system software that includes a file management system, such as a medium operating system.
  • a file management system such as a medium operating system.
  • operating system software with associated file management system software is the family of operating systems known as Windows® from Microsoft Corporation of Redmond, Washington, and their associated file management systems.
  • Windows® is the family of operating systems known as Windows® from Microsoft Corporation of Redmond, Washington, and their associated file management systems.
  • Windows® from Microsoft Corporation of Redmond, Washington
  • Windows® Windows® from Microsoft Corporation of Redmond, Washington
  • Linux operating system is the Linux operating system and its associated file management system.
  • the file management system is typically stored in the non-volatile memory and/or drive unit and causes the processor to execute the various acts required by the operating system to input and output data and to store data in the memory, including storing files on the non-volatile memory and/or drive unit.
  • the machine operates as a standalone device or may be connected (e.g., networked) to other machines.
  • the machine may operate in the capacity of a server or a client machine in a client-server network environment or as a peer machine in a peer-to-peer (or distributed) network environment.
  • the machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a laptop computer, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, an iPhone, a Blackberry, Glasses with a processor, Headphones with a processor, Virtual Reality devices, a processor, distributed processors working together, a telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.
  • PC personal computer
  • PDA personal digital assistant
  • machine-readable medium or machine-readable storage medium is shown in an exemplary embodiment to be a single medium, the term “machine- readable medium” and “machine-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions.
  • the term “machine-readable medium” and “machine-readable storage medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the presently disclosed technique and innovation.
  • routines executed to implement the embodiments of the disclosure may be implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions referred to as “computer programs.”
  • the computer programs typically comprise one or more instructions set at various times in various memory and storage devices in a computer (or distributed across computers), and when read and executed by one or more processing units or processors in a computer (or across computers), cause the computer(s) to perform operations to execute elements involving the various aspects of the disclosure.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Algebra (AREA)
  • General Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne des systèmes et des procédés de génération de clé distribuée. Selon certains modes de réalisation, une clé publique et une clé privée sont générées à l'aide d'une cryptographie à courbe elliptique (ECC) au niveau d'un groupe de parties de confiance. Dans certains cas, un algorithme de signature numérique à courbe elliptique peut être utilisé. Chaque partie génère également un engagement et un facteur de masquage. Le facteur de masquage peut être un nombre entier polynomial aléatoire. Les parties utilisent les engagements des autres parties pour valider les clés publiques avant la réception et la combinaison des clés publiques en une clé publique de groupe/agrégat. Des clés de chiffrement de contenu (CEK) sont ensuite chiffrées au niveau de chacune des parties de confiance à l'aide de ces clés publiques agrégées pour générer des clés de chiffrement de contenu enveloppées (WCEK). Des clés privées sont partitionnées et une clé partitionnée est générée au niveau de chaque partie à l'aide des parties de partitionnement reçues par la partie de confiance. Ensuite, des critères peuvent être reçus qui permettent la libération de ces clés privées partitionnées en retour vers un environnement/enclave de confiance.
PCT/US2024/055279 2023-11-11 2024-11-09 Systèmes et procédés de génération de clé distribuée pour déchiffrement à base de quorum Pending WO2025102012A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202363598086P 2023-11-11 2023-11-11
US63/598,086 2023-11-11
US18/941,314 US20250068766A1 (en) 2021-10-04 2024-11-08 Systems and methods for distributed key generation for quorum based decryption
US18/941,314 2024-11-08

Publications (1)

Publication Number Publication Date
WO2025102012A1 true WO2025102012A1 (fr) 2025-05-15

Family

ID=95696680

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2024/055279 Pending WO2025102012A1 (fr) 2023-11-11 2024-11-09 Systèmes et procédés de génération de clé distribuée pour déchiffrement à base de quorum

Country Status (1)

Country Link
WO (1) WO2025102012A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN121193548A (zh) * 2025-11-25 2025-12-23 韶关学院 基于多方安全计算与可信执行环境协同的隐私统计方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210176062A1 (en) * 2018-08-13 2021-06-10 Visa International Service Association Token keys to generate cryptograms for token interactions
US20210306164A1 (en) * 2019-04-26 2021-09-30 Advanced New Technologies Co., Ltd. Distributed key management for trusted execution environments
US20210390201A1 (en) * 2020-06-15 2021-12-16 Allstate Solutions Private Limited Distributed Ledger Interface System for Background Verification of an Individual
US20220141004A1 (en) * 2019-08-08 2022-05-05 Zettaset, Inc. Efficient Internet-Of-Things (IoT) Data Encryption/Decryption

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210176062A1 (en) * 2018-08-13 2021-06-10 Visa International Service Association Token keys to generate cryptograms for token interactions
US20210306164A1 (en) * 2019-04-26 2021-09-30 Advanced New Technologies Co., Ltd. Distributed key management for trusted execution environments
US20220141004A1 (en) * 2019-08-08 2022-05-05 Zettaset, Inc. Efficient Internet-Of-Things (IoT) Data Encryption/Decryption
US20210390201A1 (en) * 2020-06-15 2021-12-16 Allstate Solutions Private Limited Distributed Ledger Interface System for Background Verification of an Individual

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN121193548A (zh) * 2025-11-25 2025-12-23 韶关学院 基于多方安全计算与可信执行环境协同的隐私统计方法及系统

Similar Documents

Publication Publication Date Title
US12361166B2 (en) Systems and methods for data obfuscation in a zero-trust environment
Sedghighadikolaei et al. Privacy-preserving and trustworthy deep learning for medical imaging
US12339993B2 (en) Synthetic and traditional data stewards for selecting, optimizing, verifying and recommending one or more datasets
US20250005197A1 (en) Systems and methods for zero-trust algorithm deployment and operation on a protected dataset
Tawfik et al. PriCollabAnalysis: privacy-preserving healthcare collaborative analysis on blockchain using homomorphic encryption and secure multiparty computation
US20250068766A1 (en) Systems and methods for distributed key generation for quorum based decryption
WO2025102012A1 (fr) Systèmes et procédés de génération de clé distribuée pour déchiffrement à base de quorum
US12423469B2 (en) Systems and methods for dataset verification in a zero-trust computing environment
US20250005196A1 (en) Systems and methods for multi-algorithm processing of datasets within a zero-trust environment
US20240143794A1 (en) Systems and methods for data exfiltration prevention in a zero-trust environment
US20250053687A1 (en) Systems and methods for modulating outputs of large language models responsive to confidential information
US20250225274A1 (en) Systems and methods for data normalization, algorithm certification and report generation in a trusted computing environment
US12229274B2 (en) Systems and methods for training set obfuscation utilizing an inverted threat model in a zero-trust computing environment
US20250371185A1 (en) Systems and methods for dynamic policy generation and compliance in a trusted computing environment
Hammad Internet of Things-enhanced blockchain technology: an overview of advancements and prospects
US20240037299A1 (en) Systems and methods for algorithm performance modeling in a zero-trust environment
EP4413486A1 (fr) Systèmes et procédés de déploiement et de fonctionnement d'algorithme de confiance nulle sur un ensemble de données protégé
CA3234347A1 (fr) Systemes et procedes de deploiement et de fonctionnement d'algorithme de confiance nulle sur un ensemble de donnees protege
WO2025254981A1 (fr) Systèmes et procédés de génération de politique dynamique et de conformité dans un environnement informatique de confiance
Jatavallabhula Enhancing Healthcare Data Privacy and Security Using Federated Learning, Encryption and Privacy-Preserving Record Linkage (PPRL)

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24889752

Country of ref document: EP

Kind code of ref document: A1