WO2024252681A1 - 真正性検証システム、真正性検証方法、及びプログラム - Google Patents

真正性検証システム、真正性検証方法、及びプログラム Download PDF

Info

Publication number
WO2024252681A1
WO2024252681A1 PCT/JP2023/021612 JP2023021612W WO2024252681A1 WO 2024252681 A1 WO2024252681 A1 WO 2024252681A1 JP 2023021612 W JP2023021612 W JP 2023021612W WO 2024252681 A1 WO2024252681 A1 WO 2024252681A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
attestation report
authenticity verification
authenticity
user device
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.)
Ceased
Application number
PCT/JP2023/021612
Other languages
English (en)
French (fr)
Japanese (ja)
Inventor
哲矢 奥田
知洋 井上
健治 馬越
啓一郎 柏木
雅巳 泉
弘樹 神谷
大子郎 横関
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.)
NTT Inc
Original Assignee
Nippon Telegraph and Telephone Corp
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
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2025525922A priority Critical patent/JPWO2024252681A1/ja
Priority to PCT/JP2023/021612 priority patent/WO2024252681A1/ja
Publication of WO2024252681A1 publication Critical patent/WO2024252681A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • 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/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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

Definitions

  • This disclosure relates to an authenticity verification system, an authenticity verification method, and a program.
  • Non-Patent Document 1 Confidential Computing
  • Non-Patent Document 2 Confidential VM
  • the present disclosure has been made in consideration of the above points, and provides a technology that can verify the authenticity of an entire cluster consisting of multiple nodes with isolated execution environments.
  • An authenticity verification system includes a platform that realizes a cluster composed of multiple nodes each having an isolated execution environment, and a user device that uses a service provided by the cluster, and is an authenticity verification system that verifies the authenticity of the cluster, the user device having a first transmission unit that transmits a request to issue an attestation report to the node, and the node having an issuing unit that issues an attestation report including unique information of the node upon receiving the issuance request.
  • FIG. 1 is a diagram illustrating an example of a system configuration according to an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating an example of a functional configuration of a user device.
  • FIG. 2 is a diagram illustrating an example of a functional configuration of a master node.
  • FIG. 2 is a diagram illustrating an example of a functional configuration of a worker node.
  • FIG. 11 is a sequence diagram showing the flow of an authenticity verification process in the first embodiment.
  • FIG. 11 is a sequence diagram showing the flow of authenticity verification processing in the second embodiment.
  • FIG. 11 is a sequence diagram showing the flow of a data distribution process in the first embodiment.
  • FIG. 11 is a sequence diagram showing the flow of a data distribution process in the second embodiment.
  • FIG. 13 is a sequence diagram showing the flow of a data distribution process in the third embodiment.
  • FIG. 2 illustrates an example of a hardware configuration of a computer.
  • a service that executes some kind of computational processing while maintaining the confidentiality of data (including programs) in an isolated execution environment will be referred to as a "confidential execution service.”
  • the isolated execution environment can be realized by technologies such as Confidential Computing (Non-Patent Document 1) and Confidential VM (Non-Patent Document 2).
  • the isolated execution environment is called a TEE (Trusted Execution Environment), etc., and is an environment in which data processing can be executed independently of an existing OS (Operating System).
  • the TEE is provided in a central processing unit (CPU) such as AMD's (registered trademark) SEV, Intel's (registered trademark) SGX or TDX, Arm's (registered trademark) TrustZone (registered trademark), ARM Confidential Computing Architecture, etc.
  • CPU central processing unit
  • the isolated execution environment may also be called, for example, a secret computing mechanism, a confidential computing mechanism, a sandbox, etc.
  • FIG. 1 An example of the configuration of a system according to an embodiment is shown in Fig. 1.
  • the system shown in Fig. 1 includes a user device 100 and a platform 200.
  • the user device 100 and the platform 200 are connected to a communication network 300 including, for example, the Internet.
  • User device 100 is any of a variety of devices (e.g., a PC (personal computer), a smartphone, a tablet terminal, a wearable device, etc.) used by users of the confidential execution service.
  • a user of the confidential execution service may be the owner of the data (including programs) used in the confidential execution service, or may be a person who obtains or uses only the results of the execution of the service.
  • Platform 200 is a physical machine or a group of physical machines that realizes a cluster consisting of multiple nodes each having an isolated execution environment.
  • each node that makes up the cluster is realized, for example, as a virtual machine (VM), a container, a pod, etc.
  • VM virtual machine
  • the nodes that make up the cluster are Kubernetes nodes, and each node is realized as a pod.
  • the method of realizing a cluster and each node that makes up the cluster is not limited to this.
  • nodes that make up a cluster are assumed to be a master node and worker nodes.
  • a master node 210 and three worker nodes 220 are illustrated. However, this is just an example, and there is no need to distinguish between master nodes and worker nodes.
  • the master node 210 and each worker node 220 each realize an isolated execution environment and can issue a report called an attestation report provided by the TEE.
  • An attestation report is signed information that can include any attribute information. Therefore, in this embodiment, a case where a user verifies the authenticity of a cluster using this attestation report will be described. More specifically, by including node-specific information in the attestation report, the user can verify the authenticity of the cluster.
  • Each node creates a key pair of a public key and a private key using any public key cryptography method when it is generated (started up). This is used for encrypting data when transmitting between the user device 100 and the node, and between each node, since the communication between them is not necessarily secure.
  • the above keys will be referred to as sandbox keys, and respectively as the sandbox private key and sandbox public key.
  • the master node 210 may generate key pairs for each worker node 220, and distribute these key pairs to each worker node 220.
  • Each node and user device 100 is assumed to possess a sandbox public key required for encryption when sending data to a communication partner.
  • each node possesses the necessary policy (the entire policy or a part of it).
  • the master node 210 possesses the entire policy
  • each worker node 220 possesses a partial policy for access control etc. of data stored in that worker node 220.
  • the policy possessed by the master node 210 will be referred to as the entire policy
  • the policy possessed by each worker node 220 will be referred to as the partial policy.
  • the partial policy is, for example, distributed (distributed) from the master node 210 to each worker node 220.
  • ⁇ Example of Functional Configuration of User Device 100 An example of the functional configuration of the user device 100 is shown in Fig. 2. As shown in Fig. 2, the user device 100 has an attestation report issuance request unit 101, an attestation report receiving unit 102, and a data providing unit 103. Each of these units is realized, for example, by a process in which one or more programs installed in the user device 100 are executed by a processor such as a CPU.
  • the attestation report issuance request unit 101 sends an attestation report issuance request to the master node 210 to verify the authenticity of the cluster.
  • the attestation report receiving unit 102 receives an attestation report including node-specific information from the master node 210. At this time, the attestation report receiving unit 102 also receives the result of the master node 210 verifying the node-specific information included in the attestation report of the worker node 220 (the result of authenticity verification).
  • the data providing unit 103 transmits data used in the confidential execution service to the master node 210. At this time, the data providing unit 103 encrypts the data with the sandbox public key of the master node 210 and transmits the encrypted data to the master node 210.
  • Fig. 3 shows an example of the functional configuration of the master node 210.
  • the master node 210 has an orchestration function unit 211, an attestation report issuing unit 212, and an attestation report issuance request unit 213.
  • Each of these units is realized, for example, by one or more programs installed in the platform 200 causing a program such as a CPU to execute the process.
  • the orchestration function unit 211 controls the worker nodes 220, obtains its own node-specific information, verifies the node-specific information contained in the attestation reports from each worker node 220, and requests processing from other units.
  • the attestation report issuing unit 212 issues an attestation report using the TEE. At this time, the attestation report issuing unit 212 issues an attestation report that includes its own (the master node 210) node-specific information.
  • the attestation report issuance request unit 213 sends an attestation report issuance request to each worker node 220.
  • Fig. 4 shows an example of the functional configuration of the worker node 220.
  • the worker node 220 has an agent function unit 221 and an attestation report issuing unit 222.
  • Each of these units is realized, for example, by one or more programs installed in the platform 200 causing a program such as a CPU to execute the process.
  • the agent function unit 221 acquires its own node-specific information and requests processing from other units.
  • the attestation report issuing unit 222 issues an attestation report using the TEE. At this time, the attestation report issuing unit 222 issues an attestation report that includes its own (the worker node 220's) node-specific information.
  • the attestation report issuance request unit 101 of the user device 100 sends an attestation report issuance request to the master node 210 (step S101).
  • the attestation report issuance request unit 213 of the master node 210 receives the attestation report issuance request from the orchestration function unit 211, it sends an attestation report issuance request to each worker node 220 (step S102).
  • the orchestration function unit 211 of the master node 210 acquires network management information as its own node-specific information (step S103).
  • the network management information is information about the network of the entire cluster, and includes, for example, the IP (Internet Protocol) address, port number, FW settings, task name, image name, etc. of each worker node 220.
  • the network management information can be acquired, for example, by using functions such as commands provided by Kubernetes.
  • the attestation report issuing unit 212 of the master node 210 issues an attestation report including the network management information acquired in step S103 above (step S104).
  • NW information is information related to the network of the worker node 220, and includes, for example, the IP address, port number, FW settings, task name, image name, etc. of the worker node 220.
  • the NW information can be acquired, for example, by a function such as a command provided by Kubernetes.
  • the attestation report issuing unit 222 of each worker node 220 issues an attestation report including the network information acquired in step S105 above (step S106).
  • the attestation report issuing unit 222 of each worker node 220 sends the attestation report issued in step S106 above to the master node 210 (step S107).
  • the orchestration function unit 211 of the master node 210 verifies the authenticity of each worker node 220 using the network management information acquired in step S103 above and the network information included in the attestation report received from each worker node 220 (step S108). That is, the orchestration function unit 211 considers the network management information to be correct and verifies that the network information of each worker node 220 is correct (i.e., has not been tampered with).
  • the attestation report issuing unit 212 of the master node 210 transmits the attestation report issued in step S104 above and the result of the authenticity verification in step S108 above to the user device 100 (step S109).
  • the user can check the authenticity of each worker node 220 from the results of the authenticity verification.
  • the user can check the authenticity of the entire cluster using the network management information contained in the attestation report.
  • the attestation report issuance request unit 101 of the user device 100 sends an attestation report issuance request to the master node 210 (step S201).
  • the attestation report issuance request unit 213 of the master node 210 receives the attestation report issuance request from the orchestration function unit 211, the attestation report issuance request is sent to each worker node 220 (step S202).
  • the orchestration function unit 211 of the master node 210 acquires the overall policy as its own node-specific information (step S203).
  • the overall policy defines, for example, the data stored by each worker node 220 and information regarding access control to that data.
  • the overall policy is information defined in, for example, a policy expression language such as ODRL (Open Digital Rights Language). However, this is just one example, and the overall policy may be defined in any language.
  • the attestation report issuing unit 212 of the master node 210 issues an attestation report including the overall policy obtained in step S203 above (step S204).
  • the agent function unit 221 of each worker node 220 acquires a partial policy as its own node-specific information (step S205).
  • the partial policy defines, for example, the data stored by the worker node 220 and information related to access control to that data. Note that the partial policy is a part of the information in the overall policy.
  • the attestation report issuing unit 222 of each worker node 220 issues an attestation report including the partial policy obtained in step S205 above (step S206).
  • the attestation report issuing unit 222 of each worker node 220 sends the attestation report issued in step S206 above to the master node 210 (step S207).
  • the orchestration function unit 211 of the master node 210 verifies the authenticity of each worker node 220 using the overall policy acquired in step S203 above and the partial policies included in the attestation reports received from each worker node 220 (step S208). That is, the orchestration function unit 211 verifies that the partial policies of each worker node 220 are correct (i.e., have not been tampered with) using the overall policy as the correct answer.
  • the attestation report issuing unit 212 of the master node 210 transmits the attestation report issued in step S204 above and the result of the authenticity verification in step S208 above to the user device 100 (step S209).
  • the user can check the authenticity of each worker node 220 from the results of the authenticity verification.
  • the user can check the authenticity of the entire cluster using the network management information contained in the attestation report.
  • the data providing unit 103 of the user device 100 encrypts the data to be transmitted using the sandbox public key of the master node 210 (step S301).
  • the data encrypted in this step will be referred to as encrypted data.
  • the data providing unit 103 of the user device 100 transmits the encrypted data encrypted in step S301 above to the master node 210 (step S302).
  • the orchestration function unit 211 of the master node 210 When the orchestration function unit 211 of the master node 210 receives the encrypted data, it decrypts the encrypted data using its own sandbox private key (step S303).
  • the orchestration function unit 211 of the master node 210 encrypts the data decrypted in step S303 above using the sandbox public key of the worker node 220 (step S304).
  • the data encrypted in this step will be referred to as re-encrypted data.
  • the orchestration function unit 211 of the master node 210 transmits the re-encrypted data encrypted in step S304 above to the worker node 220 (step S305).
  • the agent function unit 221 of the worker node 220 When the agent function unit 221 of the worker node 220 receives the re-encrypted data, it decrypts the re-encrypted data using its own sandbox private key (step S306). This allows the worker node 220 to store the data and use it in the confidential execution service.
  • the orchestration function unit 211 of the master node 210 and the agent function unit 221 of the worker node 220 establish a secure channel (step S401).
  • the secure channel may be TLS (Transport Layer Security), IPsec, VXLAN (VXLAN over IPsec), etc. If authentication or mutual authentication is required, this may be substituted by authenticity verification of the attestation report.
  • the master node 210 when establishing TLS as a secure channel, the master node 210 is the server and the worker node 220 is the client, and when the master node 210 authenticates the worker node 220, the verification of the authenticity of the attestation report in step S107 of FIG. 5 or step S207 of FIG. 6 may be regarded as client authentication.
  • the server certificate (or its hash value) is used as usual.
  • the master node 210 may send an attestation report including the server certificate (or its hash value) to the worker node 220. By including the server certificate (or its hash value) in the attestation report, the worker node 220 can verify that the server certificate is from a legitimate master node 210.
  • the data provider 103 of the user device 100 encrypts the data to be sent using the sandbox public key of the master node 210 (step S402).
  • the data encrypted in this step will be referred to as encrypted data.
  • the data providing unit 103 of the user device 100 transmits the encrypted data encrypted in step S402 above to the master node 210 (step S403).
  • the orchestration function unit 211 of the master node 210 When the orchestration function unit 211 of the master node 210 receives the encrypted data, it decrypts the encrypted data using its own sandbox private key (step S404).
  • the orchestration function unit 211 of the master node 210 uses the secure channel established in step S401 to transmit the data decrypted in step S404 to the worker node 220 (step S405). This allows the worker node 220 to store the data and use it in the confidential execution service.
  • data is transmitted from the master node 210 to the worker node 220 using a secure channel, so the master node 210 does not need to hold the sandbox public key of the worker node 220. Therefore, for example, compared to the data distribution process in the first embodiment, it is possible to reduce the complexity of key management in cases where the worker node 220 is frequently started and deleted.
  • the orchestration function unit 211 of the master node 210 and the agent function unit 221 of the worker node 220 establish a secure channel (step S501), similar to step S401 in FIG. 8.
  • the orchestration function unit 211 of the master node 210 sends its own sandbox private key to the worker node 220 using the secure channel established in step S501 above (step S502).
  • the data providing unit 103 of the user device 100 encrypts the data to be sent using the sandbox public key of the master node 210 (step S503).
  • the data encrypted in this step will be referred to as encrypted data.
  • the data providing unit 103 of the user device 100 transmits the encrypted data encrypted in step S503 above to the master node 210 (step S504).
  • the orchestration function unit 211 of the master node 210 When the orchestration function unit 211 of the master node 210 receives the encrypted data, it transmits the encrypted data to the worker node 220 (step S505).
  • the agent function unit 221 of the worker node 220 When the agent function unit 221 of the worker node 220 receives the encrypted data, it decrypts the encrypted data using the sandbox private key of the master node 210 (step S506). This allows the worker node 220 to store the data and use it in the confidential execution service.
  • the sandbox private key of the master node 210 is transmitted from the master node 210 to the worker node 220 using a secure channel, so the master node 210 does not need to hold the sandbox public key of the worker node 220. Therefore, for example, compared to the data distribution process in the first embodiment, it is possible to reduce the complexity of key management in cases where the worker node 220 is frequently started and deleted.
  • a physical machine that realizes the above-mentioned user device 100 and platform 200 can be realized, for example, by the hardware configuration of a computer 500 shown in Fig. 10.
  • the computer 500 shown in Fig. 10 has an input device 501, a display device 502, an external I/F 503, a communication I/F 504, a RAM (Random Access Memory) 505, a ROM (Read Only Memory) 506, an auxiliary storage device 507, and a processor 508.
  • Each of these pieces of hardware is connected to each other via a bus 509 so as to be able to communicate with each other.
  • the input device 501 is, for example, a keyboard, a mouse, a touch panel, a physical button, etc.
  • the display device 502 is, for example, a display, a display panel, etc. Note that the computer 500 does not have to have at least one of the input device 501 and the display device 502, for example.
  • the external I/F 503 is an interface with external devices such as a recording medium 503a.
  • recording media 503a include a CD (Compact Disc), a DVD (Digital Versatile Disk), an SD memory card (Secure Digital memory card), and a USB (Universal Serial Bus) memory card.
  • the communication I/F 504 is an interface for connecting the computer 500 to a communication network.
  • the RAM 505 is a volatile semiconductor memory (storage device) that temporarily stores programs and data.
  • the ROM 506 is a non-volatile semiconductor memory (storage device) that can store programs and data even when the power is turned off.
  • the auxiliary storage device 507 is a storage device (storage device) such as a HDD (Hard Disk Drive), SSD (Solid State Drive), flash memory, etc.
  • the processor 508 is, for example, a CPU or other type of computing device.
  • computer 500 may have multiple auxiliary storage devices 507 and multiple processors 508, may not have some of the hardware shown in the figure, or may have various hardware other than the hardware shown in the figure.
  • Modification 1 By combining the authenticity verification process in Example 1 and the authenticity verification process in Example 2, the authenticity of a cluster consisting of multiple nodes may be verified using both information about the network (network management information and network information) and policies (overall policies and partial policies).
  • NW management information is used as the user-specific information of the master node 210
  • NW information is used as the user-specific information of the worker node 220.
  • various unique information possessed by the OS on the platform 200 and the information processing device (e.g., physical machine such as a PC or a server) that realizes the platform 200 may be used.
  • a snapshot or the like may be used as the user-specific information.
  • the snapshot possessed by the master node 210 is taken as the correct answer, and the authenticity is verified by the snapshot possessed by each worker node 220.
  • a snapshot of a CPU or a snapshot of a storage may be used as the snapshot. Note that, as described in the above modification 1, the authenticity may also be verified by using a policy.
  • a specific example of a CPU snapshot is a snapshot of CPU register information, etc.
  • Specific examples of storage snapshots include snapshots of device information for network cards and storage, and snapshots of network information (iSCSI, FiberChannel, NAS, etc.) for storage connected to a network.
  • Specific examples of unique information possessed by an OS or information processing device include the build number of the OS, the serial number of the information processing device, the binary of firmware (e.g., OVMF, etc.), and the hash value of an initial RAM disk (e.g., initrd or initramfs).
  • Modification 3 In the authenticity verification process in the second embodiment, when the master node 210 verifies the partial policy of each worker node 220 and the authenticity is verified, the master node 210 may associate and hold the sandbox public key of the worker node 220 having the partial policy with the partial policy. Similarly, when the user verifies the overall policy and the authenticity is verified, the user device 100 may associate and hold the sandbox public key of the master node 210 with the overall policy. This allows the master node 210 to associate and hold the partial policy of each worker node 220 whose authenticity has been confirmed with its sandbox public key. Similarly, the user device 100 can associate and hold the overall policy of the master node 210 included in the cluster whose authenticity has been confirmed with its sandbox public key. This makes it possible to use the sandbox public key of the node whose authenticity has been confirmed in the data distribution process.
  • the master node and the worker node are distinguished, but the distinction between the master and the worker may not be necessary.
  • the user device 100 transmits an attestation report issuance request to each node, and each node transmits an attestation report including its own node-specific information to the user device 100. This allows the user to verify the authenticity of each node from the node-specific information included in the attestation report from that node.
  • Modification 5 When communication between the worker nodes 220 is possible, authenticity may be verified between the worker nodes 220. For example, a certain worker node 220 may transmit an attestation report issuance request to another worker node 220, and the other worker node 220 may transmit an attestation report including its own node-specific information to the certain worker node 220. This allows the certain worker node 220 to verify the authenticity of the other worker node 220.
  • each worker node 220 may obtain the partial policy and public key of the other worker node 220 to which it sends an attestation report issuance request from the master node 210 via an attestation report. At this time, each worker node 220 may request the partial policy and public key of the other worker node 220 from the master node 210 using, for example, a name that uniquely identifies the other worker node 220.
  • each worker node 220 may obtain the partial policy and public key of another worker node 220 to which it sends an attestation report issuance request from the master node 210 each time, or the partial policy and public key may be distributed in advance by the master node 210.
  • the data providing unit 103 of the user device 100 transmits data (encrypted data) to the master node 210.
  • the data providing unit 103 may transmit encrypted data to the worker node 220, for example, encrypted with the public key of the worker node 220.
  • encrypted data may be transmitted not only from the data providing unit 103 of the user device 100, but also from each node, which may obtain data (encrypted data) from the data providing unit 103.
  • each worker node 220 has a partial policy for access control of data stored therein, but this is not limited thereto, and for example, each worker node 220 may have a total policy and key pairs of all the worker nodes 220. In this case, the total policy and key pairs of all the worker nodes 220 are distributed from the master node 210 to each worker node 220.
  • the system including the user device 100 according to the present embodiment and the platform 200 that realizes a cluster including a plurality of nodes each having an isolated execution environment allows a user to verify the authenticity of the cluster (i.e., that the configuration information of the cluster has not been tampered with). Therefore, when using a confidential execution service provided by the cluster, the user can use the service after confirming its safety.
  • Attestation report issuance request unit 102 Attestation report receiving unit 103 Data providing unit 200 Platform 210 Master node 211 Orchestration function unit 212 Attestation report issuing unit 213 Attestation report issuance request unit 220 Worker node 221 Agent function unit 222 Attestation report issuing unit 300 Communication network 500 Computer 501 Input device 502 Display device 503 External I/F 503a Recording medium 504 Communication I/F 505 RAM 506 ROM 507 Auxiliary storage device 508 Processor 509 Bus

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
PCT/JP2023/021612 2023-06-09 2023-06-09 真正性検証システム、真正性検証方法、及びプログラム Ceased WO2024252681A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2025525922A JPWO2024252681A1 (cg-RX-API-DMAC7.html) 2023-06-09 2023-06-09
PCT/JP2023/021612 WO2024252681A1 (ja) 2023-06-09 2023-06-09 真正性検証システム、真正性検証方法、及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2023/021612 WO2024252681A1 (ja) 2023-06-09 2023-06-09 真正性検証システム、真正性検証方法、及びプログラム

Publications (1)

Publication Number Publication Date
WO2024252681A1 true WO2024252681A1 (ja) 2024-12-12

Family

ID=93795845

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/021612 Ceased WO2024252681A1 (ja) 2023-06-09 2023-06-09 真正性検証システム、真正性検証方法、及びプログラム

Country Status (2)

Country Link
JP (1) JPWO2024252681A1 (cg-RX-API-DMAC7.html)
WO (1) WO2024252681A1 (cg-RX-API-DMAC7.html)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120512305A (zh) * 2025-07-17 2025-08-19 北京火山引擎科技有限公司 分布式大模型服务的安全验证方法、介质、设备及产品

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022537739A (ja) * 2019-06-24 2022-08-29 インターナショナル・ビジネス・マシーンズ・コーポレーション 管理されたコンテナ環境における共有機密情報へのアクセス方法、システム、プログラム
US20230068880A1 (en) * 2021-08-27 2023-03-02 EMC IP Holding Company LLC Function-based service framework with trusted execution platform

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022537739A (ja) * 2019-06-24 2022-08-29 インターナショナル・ビジネス・マシーンズ・コーポレーション 管理されたコンテナ環境における共有機密情報へのアクセス方法、システム、プログラム
US20230068880A1 (en) * 2021-08-27 2023-03-02 EMC IP Holding Company LLC Function-based service framework with trusted execution platform

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
OKUDA, TETSUYA ET AL.: "Proposition and Security Evaluation of Confidential Program Execution", IPSJ SIG TECHNICAL REPORT (CSEC), INFORMATION PROCESSING SOCIETY OF JAPAN, JAPAN, vol. 2021-CSEC-95, no. 17, 1 November 2021 (2021-11-01), Japan, pages 1 - 8, XP009560084, ISSN: 2188-8655 *
OSUKE SUDO, TAKEYA ONDA, TATSUYA NAKAMURA: "3F1-1 Anonify: A Module for Privacy-preserving State Transitions with Veritability", SCIS 2021, THE 38TH SYMPOSIUM ON CRYPTOGRAPHY AND INFORMATION SECURITY; JANUARY 19-22, 2022, IEICE, JP, vol. 38, 19 January 2021 (2021-01-19) - 22 January 2022 (2022-01-22), JP, pages 1 - 8, XP009560917 *
SHINYA TAKUMI, YURIE FUJIMATSU, JUN KANAI: "A Design for Remote Attestation Based on IETF RATS to Protect Firmware Update", SCIS 2022; 2022 SYMPOSIUM ON CRYPTOGRAPHY AND INFORMATION SECURITY; OSAKA, JAPAN & ONLINE, JAN. 18 ― 21, 2022, THE INSTITUTE OF ELECTRONICS, INFORMATION AND COMMUNICATION ENGINEERS, JP, 18 January 2022 (2022-01-18) - 21 January 2022 (2022-01-21), JP, pages 1 - 7, XP009560918, ISBN: 978-1-66549-925-5 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120512305A (zh) * 2025-07-17 2025-08-19 北京火山引擎科技有限公司 分布式大模型服务的安全验证方法、介质、设备及产品

Also Published As

Publication number Publication date
JPWO2024252681A1 (cg-RX-API-DMAC7.html) 2024-12-12

Similar Documents

Publication Publication Date Title
US9246678B2 (en) Secure cloud storage and encryption management system
US11128471B2 (en) Accessibility controls in distributed data systems
JP6165883B2 (ja) 安全な仮想マシン移行
US8977842B1 (en) Hypervisor enabled secure inter-container communications
KR101130415B1 (ko) 비밀 데이터의 노출 없이 통신 네트워크를 통해 패스워드 보호된 비밀 데이터를 복구하는 방법 및 시스템
CA2864347C (en) Cloud-based key management
US9792427B2 (en) Trusted execution within a distributed computing system
US12445441B2 (en) Integration of third-party encryption key managers with cloud services
US20220038442A1 (en) Multi-party computation (mpc) based authorization
CN114091058B (zh) 在第一区域和第二区域间数据安全共享的方法和系统
JP2017515413A (ja) 継続的な所有者アクセスを伴う、暗号化された仮想マシンの安全なトランスポート
CN110999255A (zh) 使用高可用性的可信执行环境检索区块链网络的访问数据
US9529733B1 (en) Systems and methods for securely accessing encrypted data stores
JP2019522412A (ja) 登録・認可方法、装置及びシステム
US12425198B2 (en) Method and apparatus for sharing encrypted data, device and readable medium
JP6669929B2 (ja) シングルサインオンアプリケーション用の暗号化鍵を管理するためのシステム及び方法
WO2022115559A1 (en) Cryptographic key storage system and method
JP2023552421A (ja) ハードウェア・セキュリティ・モジュールのリモート管理
CN111654367A (zh) 密码运算、创建工作密钥的方法、密码服务平台及设备
CN118056200A (zh) 用于漫游数据的分布式可信平台模块密钥管理保护
US12450385B2 (en) Integration of identity access management infrastructure with zero-knowledge services
WO2015107641A1 (ja) 暗号システム、鍵生成装置、再暗号化装置及びユーザ端末
JP2016189527A (ja) 情報処理装置及び情報処理システム及び情報処理方法及び情報処理プログラム
US20250266995A1 (en) Dynamic, control-sensitive data management platform
JP6401875B2 (ja) データ処理システム

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: 23940777

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2025525922

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2025525922

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE