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)
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)

Abstract

本開示の一態様による真正性検証システムは、隔離実行環境をそれぞれ備える複数のノードで構成されるクラスタを実現するプラットフォームと、前記クラスタによって提供されるサービスを利用するユーザ装置とが含まれ、前記クラスタの真正性を検証する真正性検証システムであって、前記ユーザ装置は、前記ノードに対してアテステーションレポートの発行依頼を送信する第１の送信部、を有し、前記ノードは、前記発行依頼を受信すると、前記ノードの固有情報が含まれるアテステーションレポートを発行する発行部、を有する。

Description

真正性検証システム、真正性検証方法、及びプログラム
　本開示は、真正性検証システム、真正性検証方法、及びプログラムに関する。
　クラウド事業者にデータ（プログラムも含む。）を秘匿したまま計算を行う従来技術として、例えば、Ｃｏｎｆｉｄｅｎｔｉａｌ　Ｃｏｍｐｕｔｉｎｇ（非特許文献１）やＣｏｎｆｉｄｅｎｔｉａｌ　ＶＭ（非特許文献２）等がある。これらの技術により機密性の高いデータの秘密性を保ったまま計算可能な隔離実行環境を構築することが可能となり、例えば、そのデータの秘密性を保ったままクラウド上で何等かの計算処理をするサービスを実現することができる。
Microsoft Azure Confidential Computing 公式ページhttps://docs.microsoft.com/ja-jp/azure/confidential-computing/overview Google Confidential VM 公式ページhttps://cloud.google.com/compute/confidential-vm/docs?hl=ja
　しかしながら、複数のノードで構成されるクラスタ（例えば、Ｋｕｂｅｒｎｅｔｅｓクラスタ）上で上記のサービスを実現する場合、クラスタ全体の真正性を検証することができない。このため、例えば、或るノードの設定情報の改ざん等を検知できず、安全性を確保することができない。
　本開示は、上記の点に鑑みてなされたもので、隔離実行環境を備える複数のノードで構成されるクラスタ全体の真正性を検証可能な技術を提供する。
　本開示の一態様による真正性検証システムは、隔離実行環境をそれぞれ備える複数のノードで構成されるクラスタを実現するプラットフォームと、前記クラスタによって提供されるサービスを利用するユーザ装置とが含まれ、前記クラスタの真正性を検証する真正性検証システムであって、前記ユーザ装置は、前記ノードに対してアテステーションレポートの発行依頼を送信する第１の送信部、を有し、前記ノードは、前記発行依頼を受信すると、前記ノードの固有情報が含まれるアテステーションレポートを発行する発行部、を有する。
　隔離実行環境を備える複数のノードで構成されるクラスタ全体の真正性を検証可能な技術を提供すること。
本発明の一実施形態におけるシステム構成例を示す図である。 ユーザ装置の機能構成例を示す図である。 マスターノードの機能構成例を示す図である。 ワーカーノードの機能構成例を示す図である。 実施例１における真正性検証処理の流れを示すシーケンス図である。 実施例２における真正性検証処理の流れを示すシーケンス図である。 実施例１におけるデータ分配処理の流れを示すシーケンス図である。 実施例２におけるデータ分配処理の流れを示すシーケンス図である。 実施例３におけるデータ分配処理の流れを示すシーケンス図である。 コンピュータのハードウェア構成例を示す図である。
　以下、本発明の一実施形態について説明する。以下で説明する実施形態は一例に過ぎず、本発明が適用される実施形態は以下の実施形態に限定されるものではない。なお、以下では、隔離実行環境上でデータ（プログラムも含む。）の秘密性を保ったまま何等かの計算処理を実行するサービスのことを「秘匿実行サービス」と呼ぶことにする。ここで、隔離実行環境は、例えば、Ｃｏｎｆｉｄｅｎｔｉａｌ　Ｃｏｍｐｕｔｉｎｇ（非特許文献１）やＣｏｎｆｉｄｅｎｔｉａｌ　ＶＭ（非特許文献２）等の技術により実現可能である。隔離実行環境はＴＥＥ（Trusted Execution Environment）等と呼ばれ、データ処理を既存のＯＳ（Operating System）から独立して実行可能な環境のことである。ＴＥＥは、例えば、ＡＭＤ（登録商標）のＳＥＶ、Ｉｎｔｅｌ（登録商標）のＳＧＸやＴＤＸ、Ａｒｍ（登録商標）のＴｒｕｓｔＺｏｎｅ（登録商標）、ＡＲＭ　Ｃｏｎｆｉｄｅｎｔｉａｌ　Ｃｏｍｐｕｔｅ　Ａｒｃｈｉｔｅｃｔｕｒｅ等といったＣＰＵ（Central Processing Unit）が備えている。なお、隔離実行環境は、例えば、秘密計算機構、秘匿計算機構、サンドボックス等と呼ばれてもよい。
　＜システム構成例＞
　一実施形態におけるシステムの構成例を図１に示す。図１に示すシステムには、ユーザ装置１００と、プラットフォーム２００とが含まれる。また、ユーザ装置１００とプラットフォーム２００は、例えば、インターネット等を含む通信ネットワーク３００に接続される。
　ユーザ装置１００は、秘匿実行サービスのユーザが利用する各種装置（例えば、ＰＣ（パーソナルコンピュータ）、スマートフォン、タブレット端末、ウェアラブルデバイス等）である。秘匿実行サービスのユーザは、当該秘匿実行サービスに用いられるデータ（プログラムも含む。）の所有者であってもよいし、そのサービスの実行結果のみを取得又は利用する者であってもよい。
　プラットフォーム２００は、隔離実行環境をそれぞれ備える複数のノードで構成されるクラスタを実現する物理マシン又は物理マシン群である。ここで、クラスタを構成する各ノードは、例えば、仮想マシン（ＶＭ：Virtual Machine）、コンテナ、ポッド等で実現される。以下では、一例として、クラスタを構成するノードはＫｕｂｅｒｎｅｔｅｓノードであり、各ノードはポッドで実現されることを想定する。ただし、クラスタ及びそれを構成する各ノードの実現方法はこれに限られるものではない。
　また、クラスタを構成するノードには、マスターノードとワーカーノードとが存在するものとする。図１に示す例では、マスターノード２１０と、３つのワーカーノード２２０とが図示されている。ただし、これは一例であって、マスターノードとワーカーノードの区別がなくてもよい。
　マスターノード２１０及び各ワーカーノード２２０はいずれも隔離実行環境を実現しており、ＴＥＥが提供するアテステーションレポート（Attestation Report）と呼ばれるレポートを発行することができる。アテステーションレポートとは、任意の属性情報を含めることが可能な署名付きの情報である。そこで、本実施形態では、このアテステーションレポートを利用してユーザがクラスタの真正性を検証する場合について説明する。より具体的には、ノード固有の情報をアテステーションレポートに含めることにより、ユーザがクラスタの真正性を検証可能とする。
　＜前提＞
　以下、本実施形態の前提となる事項について説明する。
　・各ノードはその生成（起動）時に任意の公開鍵暗号方式により公開鍵と秘密鍵の鍵ペアを作成する。これは、ユーザ装置１００とノード間、各ノード間は必ずしもセキュアであるとは限らないため、それらの間でデータを送信する際の暗号化するため等に用いられる。以下、上記の鍵をサンドボックス鍵と呼び、それぞれサンドボックス秘密鍵、サンドボックス公開鍵と呼ぶことにする。なお、例えば、マスターノード２１０で各ワーカーノード２２０の鍵ペアを生成し、それらの鍵ペアを各ワーカーノード２２０に分配してもよい。
　・各ノード及びユーザ装置１００は通信相手にデータを送信する際の暗号化に必要なサンドボックス公開鍵を所持しているものとする。
　・各ノードに保管されるデータのアクセス制御等のためのポリシーが予め合意され、各ノードは必要なポリシー（ポリシー全体又はその一部）を所持しているものとする。例えば、マスターノード２１０はポリシー全体を所持しており、各ワーカーノード２２０はそのワーカーノード２２０に保管されるデータのアクセス制御等のための部分的なポリシーを所持している。以下、マスターノード２１０が持つポリシーを全体ポリシーと呼び、各ワーカーノード２２０が持つポリシーを部分ポリシーと呼ぶことにする。なお、部分ポリシーは、例えば、マスターノード２１０から各ワーカーノード２２０に配布（分配）される。
　＜ユーザ装置１００の機能構成例＞
　ユーザ装置１００の機能構成例を図２に示す。図２に示すように、ユーザ装置１００は、アテステーションレポート発行依頼部１０１と、アテステーションレポート受信部１０２と、データ提供部１０３とを有する。これら各部は、例えば、ユーザ装置１００にインストールされた１以上のプログラムが、ＣＰＵ等のプロセッサに実行させる処理により実現される。
　アテステーションレポート発行依頼部１０１は、クラスタの真正性を検証するために、マスターノード２１０に対してアテステーションレポート発行依頼を送信する。
　アテステーションレポート受信部１０２は、ノード固有情報が含まれるアテステーションレポートをマスターノード２１０から受信する。また、このとき、アテステーションレポート受信部１０２は、マスターノード２１０がワーカーノード２２０のアテステーションレポートに含まれるノード固有情報を検証した結果（真正性検証の結果）も受信する。
　データ提供部１０３は、秘匿実行サービスに用いられるデータをマスターノード２１０に送信する。このとき、データ提供部１０３は、マスターノード２１０のサンドボックス公開鍵で当該データを暗号化した上で、その暗号化データをマスターノード２１０に送信する。
　＜マスターノード２１０の機能構成例＞
　マスターノード２１０の機能構成例を図３に示す。図３に示すように、マスターノード２１０は、オーケストレーション機能部２１１と、アテステーションレポート発行部２１２と、アテステーションレポート発行依頼部２１３とを有する。これら各部は、例えば、プラットフォーム２００にインストールされた１以上のプログラムが、ＣＰＵ等のプログラムに実行させる処理により実現される。
　オーケストレーション機能部２１１は、ワーカーノード２２０を制御したり、自身のノード固有情報を取得したり、各ワーカーノード２２０からのアテステーションレポートに含まれるノード固有情報を検証したり、他の各部に処理を依頼したりする。
　アテステーションレポート発行部２１２は、ＴＥＥによりアテステーションレポートを発行する。このとき、アテステーションレポート発行部２１２は、自身（マスターノード２１０）のノード固有情報が含まれるアテステーションレポートを発行する。
　アテステーションレポート発行依頼部２１３は、各ワーカーノード２２０に対してアテステーションレポート発行依頼を送信する。
　＜ワーカーノード２２０の機能構成例＞
　ワーカーノード２２０の機能構成例を図４に示す。図４に示すように、ワーカーノード２２０は、エージェント機能部２２１と、アテステーションレポート発行部２２２とを有する。これら各部は、例えば、プラットフォーム２００にインストールされた１以上のプログラムが、ＣＰＵ等のプログラムに実行させる処理により実現される。
　エージェント機能部２２１は、自身のノード固有情報を取得したり、他の各部に処理を依頼したりする。
　アテステーションレポート発行部２２２は、ＴＥＥによりアテステーションレポートを発行する。このとき、アテステーションレポート発行部２２２は、自身（ワーカーノード２２０）のノード固有情報が含まれるアテステーションレポートを発行する。
　＜真正性検証処理＞
　以下、マスターノード２１０及び各ワーカーノード２２０で構成されるクラスタの真正性をユーザが検証とする真正性検証処理の実施例１及び２について説明する。
　　≪真正性検証処理（実施例１）≫
　実施例１における真正性検証処理の流れについて、図５を参照しながら説明する。
　ユーザ装置１００のアテステーションレポート発行依頼部１０１は、マスターノード２１０に対してアテステーションレポート発行依頼を送信する（ステップＳ１０１）。
　マスターノード２１０のアテステーションレポート発行依頼部２１３は、オーケストレーション機能部２１１によってアテステーションレポート発行依頼を受信すると、各ワーカーノード２２０に対してアテステーションレポート発行依頼をそれぞれ送信する（ステップＳ１０２）。
　マスターノード２１０のオーケストレーション機能部２１１は、自身のノード固有情報としてＮＷ管理情報を取得する（ステップＳ１０３）。ここで、ＮＷ管理情報とはクラスタ全体のネットワークに関する情報であり、例えば、各ワーカーノード２２０のＩＰ（Internet Protocol）アドレス、ポート番号、ＦＷ設定、タスク名、イメージ名等が含まれる。ＮＷ管理情報は、例えば、Ｋｕｂｅｒｎｅｔｅｓが提供するコマンド等の機能により取得可能である。
　マスターノード２１０のアテステーションレポート発行部２１２は、上記のステップＳ１０３で取得されたＮＷ管理情報が含まれるアテステーションレポートを発行する（ステップＳ１０４）。
　各ワーカーノード２２０のエージェント機能部２２１は、自身のノード固有情報としてＮＷ情報を取得する（ステップＳ１０５）。ここで、ＮＷ情報とは当該ワーカーノード２２０のネットワークに関する情報であり、例えば、当該ワーカーノード２２０のＩＰアドレス、ポート番号、ＦＷ設定、タスク名、イメージ名等が含まれる。ＮＷ情報は、例えば、Ｋｕｂｅｒｎｅｔｅｓが提供するコマンド等の機能により取得可能である。
　各ワーカーノード２２０のアテステーションレポート発行部２２２は、上記のステップＳ１０５で取得されたＮＷ情報が含まれるアテステーションレポートを発行する（ステップＳ１０６）。
　各ワーカーノード２２０のアテステーションレポート発行部２２２は、上記のステップＳ１０６で発行されたアテステーションレポートをマスターノード２１０に送信する（ステップＳ１０７）。
　マスターノード２１０のオーケストレーション機能部２１１は、上記のステップＳ１０３で取得されたＮＷ管理情報と、各ワーカーノード２２０から受信したアテステーションレポートに含まれるＮＷ情報とを用いて、各ワーカーノード２２０の真正性を検証する（ステップＳ１０８）。すなわち、オーケストレーション機能部２１１は、ＮＷ管理情報を正解として、各ワーカーノード２２０のＮＷ情報が正しいこと（つまり、改ざんされていないこと）を検証する。
　マスターノード２１０のアテステーションレポート発行部２１２は、上記のステップＳ１０４で発行したアテステーションレポートと、上記のステップＳ１０８における真正性検証の結果とをユーザ装置１００に送信する（ステップＳ１０９）。
　以上により、ユーザは、真正性検証の結果から各ワーカーノード２２０の真正性を確認することができる。また、アテステーションレポートに含まれるＮＷ管理情報を用いて、クラスタ全体の真正性を確認することができる。
　　≪真正性検証処理（実施例２）≫
　実施例２における真正性検証処理の流れについて、図６を参照しながら説明する。
　ユーザ装置１００のアテステーションレポート発行依頼部１０１は、マスターノード２１０に対してアテステーションレポート発行依頼を送信する（ステップＳ２０１）。
　マスターノード２１０のアテステーションレポート発行依頼部２１３は、オーケストレーション機能部２１１によってアテステーションレポート発行依頼を受信すると、各ワーカーノード２２０に対してアテステーションレポート発行依頼をそれぞれ送信する（ステップＳ２０２）。
　マスターノード２１０のオーケストレーション機能部２１１は、自身のノード固有情報として全体ポリシーを取得する（ステップＳ２０３）。全体ポリシーには、例えば、各ワーカーノード２２０が保管するデータとそのデータに対するアクセス制御に関する情報等が定義されている。なお、全体ポリシーは、例えば、ポリシー表現言語であるＯＤＲＬ（Open Digital Rights Language）等で定義された情報である。ただし、これは一例であって、全体ポリシーはどのような言語で定義されていてもよい。
　マスターノード２１０のアテステーションレポート発行部２１２は、上記のステップＳ２０３で取得された全体ポリシーが含まれるアテステーションレポートを発行する（ステップＳ２０４）。
　各ワーカーノード２２０のエージェント機能部２２１は、自身のノード固有情報として部分ポリシーを取得する（ステップＳ２０５）。部分ポリシーには、例えば、当該ワーカーノード２２０が保管するデータとそのデータに対するアクセス制御に関する情報等が定義されている。なお、部分ポリシーは、全体ポリシーの一部の情報である。
　各ワーカーノード２２０のアテステーションレポート発行部２２２は、上記のステップＳ２０５で取得された部分ポリシーが含まれるアテステーションレポートを発行する（ステップＳ２０６）。
　各ワーカーノード２２０のアテステーションレポート発行部２２２は、上記のステップＳ２０６で発行されたアテステーションレポートをマスターノード２１０に送信する（ステップＳ２０７）。
　マスターノード２１０のオーケストレーション機能部２１１は、上記のステップＳ２０３で取得された全体ポリシーと、各ワーカーノード２２０から受信したアテステーションレポートに含まれる部分ポリシーとを用いて、各ワーカーノード２２０の真正性を検証する（ステップＳ２０８）。すなわち、オーケストレーション機能部２１１は、全体ポリシーを正解として、各ワーカーノード２２０の部分ポリシーが正しいこと（つまり、改ざんされていないこと）を検証する。
　マスターノード２１０のアテステーションレポート発行部２１２は、上記のステップＳ２０４で発行したアテステーションレポートと、上記のステップＳ２０８における真正性検証の結果とをユーザ装置１００に送信する（ステップＳ２０９）。
　以上により、ユーザは、真正性検証の結果から各ワーカーノード２２０の真正性を確認することができる。また、アテステーションレポートに含まれるＮＷ管理情報を用いて、クラスタ全体の真正性を確認することができる。
　＜データ分配処理＞
　以下、秘匿実行サービスに利用するデータをユーザ装置１００からマスターノード２１０に送信すると共に、更にそのデータを利用するワーカーノード２２０に対して当該データを送信（分配）するデータ分配処理の実施例１～３について説明する。
　　≪データ分配処理（実施例１）≫
　実施例１におけるデータ分配処理の流れについて、図７を参照しながら説明する。
　ユーザ装置１００のデータ提供部１０３は、マスターノード２１０のサンドボックス公開鍵を用いて、送信対象のデータを暗号化する（ステップＳ３０１）。以下、本ステップで暗号化されたデータを暗号化データと呼ぶ。
　ユーザ装置１００のデータ提供部１０３は、上記のステップＳ３０１で暗号化された暗号化データをマスターノード２１０に送信する（ステップＳ３０２）。
　マスターノード２１０のオーケストレーション機能部２１１は、暗号化データを受信すると、自身のサンドボックス秘密鍵を用いて、当該暗号化データを復号する（ステップＳ３０３）。
　マスターノード２１０のオーケストレーション機能部２１１は、ワーカーノード２２０のサンドボックス公開鍵を用いて、上記のステップＳ３０３で復号されたデータを暗号化する（ステップＳ３０４）。以下、本ステップで暗号化されたデータを再暗号化データと呼ぶ。
　マスターノード２１０のオーケストレーション機能部２１１は、上記のステップＳ３０４で暗号化された再暗号化データを当該ワーカーノード２２０に送信する（ステップＳ３０５）。
　ワーカーノード２２０のエージェント機能部２２１は、再暗号化データを受信すると、自身のサンドボックス秘密鍵を用いて、当該再暗号化データを復号する（ステップＳ３０６）。これにより、ワーカーノード２２０は当該データを保管し、秘匿実行サービスで利用することができる。
　　≪データ分配処理（実施例２）≫
　実施例２におけるデータ分配処理の流れについて、図８を参照しながら説明する。
　マスターノード２１０のオーケストレーション機能部２１１とワーカーノード２２０のエージェント機能部２２１は、セキュアチャネルを確立する（ステップＳ４０１）。セキュアチャネルとしては、例えば、ＴＬＳ（Transport Layer Security）、ＩＰｓｅｃ、ＶＸＬＡＮ（ＶＸＬＡＮ　ｏｖｅｒ　ＩＰｓｅｃ）等を確立すればよい。また、このとき、認証又は相互認証が必要な場合にはアテステーションレポートの真正性検証で代替してもよい。
　例えば、セキュアチャネルとしてＴＬＳを確立する場合、マスターノード２１０をサーバ、ワーカーノード２２０をクライアントとして、マスターノード２１０がワーカーノード２２０を認証する際には、図５のステップＳ１０７又は図６のステップＳ２０７のアテステーションレポートの真正性検証をクライアント認証とみなしてもよい。一方で、ワーカーノード２２０がマスターノード２１０を認証する際には、通常と同様に、サーバ証明書（又はそのハッシュ値）を用いる。この場合、マスターノード２１０から当該ワーカーノード２２０に対して、サーバ証明書（又はそのハッシュ値）が含まれるアテステーションレポートを送信すればよい。サーバ証明書（又はそのハッシュ値）をアテステーションレポートに含めることにより、ワーカーノード２２０は、正当なマスターノード２１０からのサーバ証明書であることを検証することが可能となる。
　ユーザ装置１００のデータ提供部１０３は、マスターノード２１０のサンドボックス公開鍵を用いて、送信対象のデータを暗号化する（ステップＳ４０２）。以下、本ステップで暗号化されたデータを暗号化データと呼ぶ。
　ユーザ装置１００のデータ提供部１０３は、上記のステップＳ４０２で暗号化された暗号化データをマスターノード２１０に送信する（ステップＳ４０３）。
　マスターノード２１０のオーケストレーション機能部２１１は、暗号化データを受信すると、自身のサンドボックス秘密鍵を用いて、当該暗号化データを復号する（ステップＳ４０４）。
　マスターノード２１０のオーケストレーション機能部２１１は、上記のステップＳ４０１で確立したセキュアチャネルを用いて、上記のステップＳ４０４で復号されたデータを当該ワーカーノード２２０に送信する（ステップＳ４０５）。これにより、ワーカーノード２２０は当該データを保管し、秘匿実行サービスで利用することができる。
　なお、実施例２におけるデータ分配処理では、セキュアチャネルを利用してマスターノード２１０からワーカーノード２２０に対してデータを送信するため、マスターノード２１０はワーカーノード２２０のサンドボックス公開鍵を保持する必要がない。このため、例えば、実施例１におけるデータ分配処理と比較して、ワーカーノード２２０の起動と削除が頻繁に行われる場合等に鍵管理の煩雑さを削減することが可能となる。
　　≪データ分配処理（実施例３）≫
　実施例３におけるデータ分配処理の流れについて、図９を参照しながら説明する。
　マスターノード２１０のオーケストレーション機能部２１１とワーカーノード２２０のエージェント機能部２２１は、図８のステップＳ４０１と同様に、セキュアチャネルを確立する（ステップＳ５０１）。
　マスターノード２１０のオーケストレーション機能部２１１は、上記のステップＳ５０１で確立したセキュアチャネルを用いて、自身のサンドボックス秘密鍵をワーカーノード２２０に送信する（ステップＳ５０２）。
　ユーザ装置１００のデータ提供部１０３は、マスターノード２１０のサンドボックス公開鍵を用いて、送信対象のデータを暗号化する（ステップＳ５０３）。以下、本ステップで暗号化されたデータを暗号化データと呼ぶ。
　ユーザ装置１００のデータ提供部１０３は、上記のステップＳ５０３で暗号化された暗号化データをマスターノード２１０に送信する（ステップＳ５０４）。
　マスターノード２１０のオーケストレーション機能部２１１は、暗号化データを受信すると、当該暗号化データを当該ワーカーノード２２０に送信する（ステップＳ５０５）。
　ワーカーノード２２０のエージェント機能部２２１は、暗号化データを受信すると、マスターノード２１０のサンドボックス秘密鍵を用いて、当該暗号化データを復号する（ステップＳ５０６）。これにより、ワーカーノード２２０は当該データを保管し、秘匿実行サービスで利用することができる。
　なお、実施例３におけるデータ分配処理では、セキュアチャネルを利用してマスターノード２１０からワーカーノード２２０に対して、マスターノード２１０のサンドボックス秘密鍵を送信するため、マスターノード２１０はワーカーノード２２０のサンドボックス公開鍵を保持する必要がない。このため、例えば、実施例１におけるデータ分配処理と比較して、ワーカーノード２２０の起動と削除が頻繁に行われる場合等に鍵管理の煩雑さを削減することが可能となる。
　＜ハードウェア構成例＞
　上記のユーザ装置１００やプラットフォーム２００を実現する物理マシンは、例えば、図１０に示すコンピュータ５００のハードウェア構成により実現可能である。図１０に示すコンピュータ５００は、入力装置５０１と、表示装置５０２と、外部Ｉ／Ｆ５０３と、通信Ｉ／Ｆ５０４と、ＲＡＭ（Random Access Memory）５０５と、ＲＯＭ（Read Only Memory）５０６と、補助記憶装置５０７と、プロセッサ５０８とを有する。これらの各ハードウェアは、それぞれがバス５０９を介して通信可能に接続される。
　入力装置５０１は、例えば、キーボード、マウス、タッチパネル、物理ボタン等である。表示装置５０２は、例えば、ディスプレイ、表示パネル等である。なお、コンピュータ５００は、例えば、入力装置５０１及び表示装置５０２のうちの少なくとも一方を有していなくてもよい。
　外部Ｉ／Ｆ５０３は、記録媒体５０３ａ等の外部装置とのインタフェースである。記録媒体５０３ａとしては、例えば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード（Secure Digital memory card）、ＵＳＢ（Universal Serial Bus）メモリカード等が挙げられる。
　通信Ｉ／Ｆ５０４は、コンピュータ５００を通信ネットワークに接続するためのインタフェースである。ＲＡＭ５０５は、プログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。ＲＯＭ５０６は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリ（記憶装置）である。補助記憶装置５０７は、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等のストレージ装置（記憶装置）である。プロセッサ５０８は、例えば、ＣＰＵ等の各種演算装置である。
　なお、図１０に示すコンピュータ５００のハードウェア構成は一例であって、これに限られるものではない。例えば、コンピュータ５００は、複数の補助記憶装置５０７や複数のプロセッサ５０８を有していてもよいし、図示したハードウェアの一部を有していなくてもよいし、図示したハードウェア以外の種々のハードウェアを有していてもよい。
　＜変形例＞
　以下、上記の実施形態の変形例について説明する。
　・変形例１
　実施例１における真正性検証処理と実施例２における真正性検証処理とを組み合わせて、ネットワークに関する情報（ＮＷ管理情報及びＮＷ情報）とポリシー（全体ポリシー及び部分ポリシー）の両方により複数のノードで構成されるクラスタの真正性が検証されてもよい。
　・変形例２
　実施例１における真正性検証処理ではマスターノード２１０のユーザ固有情報としてＮＷ管理情報、ワーカーノード２２０のユーザ固有情報としてＮＷ情報をそれぞれ用いたが、これ以外にも、プラットフォーム２００上のＯＳやプラットフォーム２００を実現する情報処理装置（例えば、ＰＣ、サーバ等の物理マシン）等が持つ様々な固有情報が用いられてもよい。例えば、ユーザ固有情報としてスナップショット等が用いられてもよい。ユーザ固有情報としてスナップショットが用いられる場合、例えば、マスターノード２１０が持つスナップショットを正解として、各ワーカーノード２２０が持つスナップショットにより真正性が検証される。ここで、スナップショットとしては、例えば、ＣＰＵのスナップショットやストレージのスナップショット等を用いることが考えられる。なお、上記の変形例１で説明したように、更にポリシーも用いて真正性が検証されてもよい。
　なお、ＣＰＵのスナップショットの具体例としては、ＣＰＵのレジスタ情報等のスナップショットが挙げられる。また、ストレージのスナップショットの具体例としては、ネットワークカードやストレージのデバイス情報のスナップショット、ネットワーク接続しているストレージのネットワーク情報（ｉＳＣＳＩ、ＦｉｂｅｒＣｈａｎｎｅｌ、ＮＡＳ等）のスナップショット等が挙げられる。更に、ＯＳや情報処理装置が持つ固有情報の具体例としては、ＯＳのビルド番号、情報処理装置のシリアル番号、ファームウェア（例えば、ＯＶＭＦ等）のバイナリや初期ＲＡＭディスク（例えば、ｉｎｉｔｒｄやｉｎｉｔｒａｍｆｓ）のハッシュ値等が挙げられる。
　・変形例３
　実施例２における真正性検証処理において、マスターノード２１０が各ワーカーノード２２０の部分ポリシーを検証し、それにより真正性が検証された場合、マスターノード２１０は、その部分ポリシーに対して、当該部分ポリシーを持つワーカーノード２２０のサンドボックス公開鍵を対応付けて保持してもよい。同様に、ユーザが全体ポリシーを検証し、それにより真正性が検証された場合、ユーザ装置１００は、全体ポリシーに対して、マスターノード２１０のサンドボックス公開鍵を対応付けて保持してもよい。これにより、マスターノード２１０は真正性が確認された各ワーカーノード２２０の部分ポリシーとそのサンドボックス公開鍵とを対応付けて保持することができる。同様に、ユーザ装置１００は、真正性が確認されたクラスタに含まれるマスターノード２１０の全体ポリシーとそのサンドボックス公開鍵とを対応付けて保持することができる。このため、データ分配処理で真正性が確認されたノードのサンドボックス公開鍵を利用することが可能となる。
　・変形例４
　上記の実施形態では、マスターノードとワーカーノードとを区別したが、マスターとワーカーの区別がなくてもよい。この場合、ユーザ装置１００は各ノードに対してアテステーションレポート発行依頼をそれぞれ送信し、各ノードは自身のノード固有情報が含まれるアテステーションレポートを当該ユーザ装置１００に送信する。これにより、ユーザは、各ノードからのアテステーションレポートに含まれるノード固有情報からそのノードの真正性を検証することができる。
　・変形例５
　ワーカーノード２２０間で通信可能な場合には、ワーカーノード２２０間で真正性の検証が行われてもよい。例えば、或るワーカーノード２２０から別のワーカーノード２２０に対してアテステーションレポート発行依頼を送信し、当該別のワーカーノード２２０が自身のノード固有情報が含まれるアテステーションレポートを当該或るワーカーノード２２０に送信してもよい。これにより、当該或るワーカーノード２２０は、当該別のワーカーノード２２０の真正性を検証することができる。
　ここで、各ワーカーノード２２０は、自身がアテステーションレポート発行依頼を送信する他のワーカーノード２２０の部分ポリシー及び公開鍵をマスターノード２１０からアテステーションレポートにより取得すればよい。このとき、各ワーカーノード２２０は、例えば、当該他のワーカーノード２２０を一意に識別する名称等を用いて、当該他のワーカーノード２２０の部分ポリシー及び公開鍵をマスターノード２１０に要求すればよい。
　なお、各ワーカーノード２２０は、自身がアテステーションレポート発行依頼を送信する他のワーカーノード２２０の部分ポリシー及び公開鍵をマスターノード２１０から都度取得してもよいし、その部分ポリシー及び公開鍵が事前にマスターノード２１０から配布されてもよい。
　・変形例６
　上記の実施形態のデータ分配処理（実施例１～３）では、ユーザ装置１００のデータ提供部１０３がマスターノード２１０にデータ（暗号化データ）を送信する場合について説明したが、データ提供部１０３は、例えば、ワーカーノード２２０に対して、そのワーカーノード２２０の公開鍵で暗号化した暗号化データを送信してもよい。
　また、ユーザ装置１００のデータ提供部１０３から暗号化データを送信する場合だけでなく、各ノードがデータ提供部１０３からデータ（暗号化データ）を取得するものであってもよい。
　・変形例７
　上記の実施形態では、各ワーカーノード２２０は自身に保管されるデータのアクセス制御等のための部分ポリシーを所持しているものとしたが、これに限られず、例えば、各ワーカーノード２２０が全体ポリシーとすべてのワーカーノード２２０の鍵ペアとを所持していてもよい。なお、この場合、全体ポリシーとすべてのワーカーノード２２０の鍵ペアは、マスターノード２１０から各ワーカーノード２２０に配布される。
　＜まとめ＞
　以上のように、本実施形態に係るユーザ装置１００と隔離実行環境をそれぞれ備える複数のノードで構成されるクラスタを実現するプラットフォーム２００で構成されるシステムによれば、ユーザは、当該クラスタの真正性（つまり、当該クラスタの設定情報等が改ざんされていないこと）を検証することができる。このため、当該クラスタによって提供される秘匿実行サービスを利用する際に、ユーザは、その安全性を確認した上で利用することが可能となる。
　本発明は、具体的に開示された上記の実施形態に限定されるものではなく、請求の範囲の記載から逸脱することなく、種々の変形や変更、既知の技術との組み合わせ等が可能である。
　１００　　　　ユーザ装置
　１０１　　　　アテステーションレポート発行依頼部
　１０２　　　　アテステーションレポート受信部
　１０３　　　　データ提供部
　２００　　　　プラットフォーム
　２１０　　　　マスターノード
　２１１　　　　オーケストレーション機能部
　２１２　　　　アテステーションレポート発行部
　２１３　　　　アテステーションレポート発行依頼部
　２２０　　　　ワーカーノード
　２２１　　　　エージェント機能部
　２２２　　　　アテステーションレポート発行部
　３００　　　　通信ネットワーク
　５００　　　　コンピュータ
　５０１　　　　入力装置
　５０２　　　　表示装置
　５０３　　　　外部Ｉ／Ｆ
　５０３ａ　　　記録媒体
　５０４　　　　通信Ｉ／Ｆ
　５０５　　　　ＲＡＭ
　５０６　　　　ＲＯＭ
　５０７　　　　補助記憶装置
　５０８　　　　プロセッサ
　５０９　　　　バス

Claims (8)

  1. 　隔離実行環境をそれぞれ備える複数のノードで構成されるクラスタを実現するプラットフォームと、前記クラスタによって提供されるサービスを利用するユーザ装置とが含まれ、前記クラスタの真正性を検証する真正性検証システムであって、
    　前記ユーザ装置は、
    　前記ノードに対してアテステーションレポートの発行依頼を送信する第１の送信部、を有し、
    　前記ノードは、
    　前記発行依頼を受信すると、前記ノードの固有情報が含まれるアテステーションレポートを発行する発行部、を有する、
    　真正性検証システム。
  2. 　前記複数のノードは、１つのマスターノードと、前記マスターノード以外の１以上のワーカーノードとで構成されており、
    　前記第１の送信部は、
    　前記マスターノードに対してアテステーションレポートの発行依頼を送信し、
    　前記マスターノードは、
    　前記発行依頼を受信すると、前記ワーカーノードに対してアテステーションレポートの発行依頼を送信する第２の送信部と、
    　前記マスターノードの固有情報を用いて、前記ワーカーノードから受信したアテステーションレポートに含まれる前記固有情報の真正性を検証する検証部と、
    　前記マスターノードの固有情報が含まれるアテステーションレポートと、前記真正性の検証結果とを前記ユーザ装置に送信する第３の送信部と、を有する、請求項１に記載の真正性検証システム。
  3. 　前記検証部は、
    　前記マスターノードの固有情報を正解として、前記ワーカーノードから受信したアテステーションレポートに含まれる前記固有情報の改ざん有無を検証する、請求項２に記載の真正性検証システム。
  4. 　前記固有情報は、ネットワークに関する情報、前記ノードが保持するデータのアクセス制御に関するポリシー、前記プラットフォーム上のＯＳの固有情報、前記プラットフォームを実現する情報処理装置の固有情報、の少なくとも１つである、請求項１乃至３の何れか一項に記載の真正性検証システム。
  5. 　前記ユーザ装置は、
    　前記ノードの公開鍵により暗号化した暗号化データを前記ノードに送信するデータ提供部、を有し、
    　前記ノードは、
    　他のノードから受信したアテステーションレポートを前記他のノードの認証とみなして事前に確立したセキュアチャネルを介して、前記暗号化データを自身の秘密鍵で復号したデータを前記他のノードに送信する第４の送信部、を有する、請求項１に記載の真正性検証システム。
  6. 　前記ユーザ装置は、
    　前記ノードの公開鍵により暗号化した暗号化データを前記ノードに送信するデータ提供部、を有し、
    　前記ノードは、
    　他のノードから受信したアテステーションレポートを前記他のノードの認証とみなして事前に確立したセキュアチャネルを介して、前記暗号化データを復号するための自身の秘密鍵を前記他のノードに送信する第５の送信部と、
    　前記暗号化データを前記他のノードに送信する第６の送信部と、を有する、請求項１に記載の真正性検証システム。
  7. 　隔離実行環境をそれぞれ備える複数のノードで構成されるクラスタを実現するプラットフォームと、前記クラスタによって提供されるサービスを利用するユーザ装置とが含まれ、前記クラスタの真正性を検証する真正性検証システムにおける真正性検証方法であって、
    　前記ユーザ装置が、
    　前記ノードに対してアテステーションレポートの発行依頼を送信する第１の送信手順、を実行し、
    　前記ノードが、
    　前記発行依頼を受信すると、前記ノードの固有情報が含まれるアテステーションレポートを発行する発行手順、を実行する、
    　真正性検証方法。
  8. 　隔離実行環境をそれぞれ備える複数のノードで構成されるクラスタを実現するプラットフォームと、前記クラスタによって提供されるサービスを利用するユーザ装置とが含まれ、前記クラスタの真正性を検証する真正性検証システムを実現するプログラムであって、
    　前記ユーザ装置に、
    　前記ノードに対してアテステーションレポートの発行依頼を送信する第１の送信手順、を実行させ、
    　前記ノードに、
    　前記発行依頼を受信すると、前記ノードの固有情報が含まれるアテステーションレポートを発行する発行手順、を実行させる、
    　プログラム。
PCT/JP2023/021612 2023-06-09 2023-06-09 真正性検証システム、真正性検証方法、及びプログラム Ceased WO2024252681A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2025525922A JPWO2024252681A1 (ja) 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 (ja)
WO (1) WO2024252681A1 (ja)

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 (ja) 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