System, device, method, and program
The system enables secure and authenticated data processing across multiple services by implementing mutual authentication and attestation, ensuring data confidentiality and improving auditability through signed logs.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-09-04
- Publication Date
- 2026-03-12
AI Technical Summary
There is no mechanism to safely combine and use multiple services managed by different entities, which poses a security risk in data confidentiality and authenticity verification.
A system with entities having authentication, attestation, and processing execution units that perform mutual authentication and attestation to ensure secure data communication and service execution, accompanied by the creation of signed execution trails for auditability.
Ensures safe combination and execution of services across different entities by authenticating and verifying their authenticity, providing secure data processing and enhancing auditability through signed logs.
Smart Images

Figure JP2024031681_12032026_PF_FP_ABST
Abstract
Description
System, device, method, and program
[0001] The present disclosure relates to a system, an apparatus, a method, and a program.
[0002] A mechanism for securely performing calculations called a Trusted Execution Environment (TEE) is known (see, for example, Non-Patent Document 1), and in recent years, services that provide a calculation environment using a TEE have emerged. By using such services, users can perform calculations securely while keeping data confidential even from the platform provider that provides the service.
[0003] Also, a mechanism called remote attestation is known, which allows a user to verify whether or not the configuration of a TEE has been tampered with by verifying an attestation report signed by a hardware module that serves as a root of trust (for example, Non-Patent Document 2). By using this mechanism, a user can exchange data only with a verified, safe environment.
[0004] On the other hand, in addition to services that provide computing environments, there are various other services (e.g., storage services, key management services, etc.) that may be managed by different entities, and users generally use a combination of any number of services.
[0005] AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More, January, 2020. Internet <URL: https: / / www.amd.com / content / dam / amd / en / documents / epyc-business-docs / white-papers / SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf> AMD SEV-SNP Attestation: Establishing Trust in Guests, Sep., 2022. Internet <URL: https: / / www.amd.com / content / dam / amd / en / documents / developer / lss-snp-attestation.pdf>
[0006] However, when multiple services that may be managed by different entities are used in combination, there is no mechanism to safely use them.
[0007] The present disclosure has been made in consideration of the above points, and aims to provide a technology that enables multiple services, which may be managed by different entities, to be combined and used safely.
[0008] A system according to one aspect of the present disclosure is a system including a plurality of entities each providing a specified service, wherein the entities have an authentication unit that performs mutual authentication with other entities, an attestation unit that performs mutual attestation with the other entities if the mutual authentication is successful, and a processing execution unit that, if the attestation is performed, executes specified processing to realize the service with the other entities.
[0009] A technology is provided that enables multiple services, which may be managed by different entities, to be combined and used safely.
[0010] Fig. 1 is a diagram illustrating an example of the overall configuration of a system according to an embodiment; Fig. 2 is a diagram illustrating an example of the functional configuration of a user device according to an embodiment; Fig. 3 is a diagram illustrating an example of the functional configuration of an entity according to an embodiment; Fig. 4 is a diagram illustrating an example of the operation of a system according to an embodiment; and Fig. 5 is a diagram illustrating an example of the hardware configuration of a computer.
[0011] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. However, the embodiment described below is merely an example, and the embodiments to which the present invention is applied are not limited to the following embodiment.
[0012] <Example of Overall System Configuration> An example of the overall configuration of a system in one embodiment is shown in Fig. 1. As shown in Fig. 1, the system in one embodiment includes a user device 100 and multiple platforms 200. Furthermore, the user device 100 and each platform 200 are communicatively connected via a communication network 300 including, for example, the Internet.
[0013] The user device 100 is a device of any type (e.g., a personal computer (PC), a smartphone, a tablet terminal, a wearable device, etc.) used by a user to combine and use multiple services that may be managed by different entities.
[0014] The platform 200 is a physical machine or a group of physical machines that provides services through entities 210 realized in an isolated execution environment. The isolated execution environment, also known as a TEE, is an environment in which data processing can be executed independently from an existing operating system (OS). The isolated execution environment can be realized, for example, by AMD (registered trademark) SEV, Intel (registered trademark) SGX or TDX, Arm (registered trademark) TrustZone (registered trademark), Arm Confidential Compute Architecture, etc. An entity is a process realized by data including programs and the like necessary to provide a service. Examples of entities include a virtual machine (VM), a container, and a pod. The isolated execution environment may also be called, for example, a secure computing mechanism, a secure computing mechanism, a sandbox, etc.
[0015] For simplicity, it is assumed below that each platform 200 has one entity 210, and that the entity 210 provides a specific service. It is also assumed that each platform 200 is managed by a different platform provider. In other words, it is assumed that the services provided by the entity 210 of each platform 200 are managed by different entities.
[0016] Furthermore, when distinguishing between the multiple services provided by each entity 210, they will be referred to as "service A," "service B," etc., and the entity 210 providing service A will be referred to as "entity 210A," and the entity 210 providing service B will be referred to as "entity 210B," etc.
[0017] Here, each entity 210 creates a key pair of a public key and a private key using any public key cryptography method (e.g., RSA cryptography) at the time of its generation. This is used to encrypt data communication between entities 210, or between an entity 210 and a user device 100, since such communication is not necessarily secure. The above public key and private key are sometimes referred to as a "sandbox public key" and a "sandbox private key," respectively.
[0018] Furthermore, each entity 210 creates a key pair of a signature key and a verification key using any digital signature method (e.g., a signature method based on RSA encryption, a DSA signature method, an ECDSA signature method, etc.) at the time of its creation. The signature key and verification key are used to sign and verify logs (authentication log, attestation log, communication log) described below.
[0019] <Example of Functional Configuration of User Device 100> An example of the functional configuration of the user device 100 in one embodiment is shown in Fig. 2. As shown in Fig. 2, the user device 100 in one embodiment has a processing request unit 101 and a processing result management unit 102. These units are realized, for example, by processing that one or more programs installed in the user device 100 cause a processor such as a CPU (Central Processing Unit) to execute.
[0020] When using a combination of multiple services that may be managed by different entities, the processing request unit 101 sends a processing request to an entity 210 that provides a certain service among the multiple services to realize the combined use of the multiple services.
[0021] The processing result management unit 102 stores in an arbitrary storage area the processing results for the processing request sent by the processing request unit 101. The storage area in which the processing results are stored may be, for example, a storage area of an auxiliary storage device included in the user device 100 (e.g., a storage area of an auxiliary storage device such as a hard disk drive (HDD), a solid state drive (SSD), or a flash memory).
[0022] <Example of Functional Configuration of Entity 210> An example of the functional configuration of the entity 210 in one embodiment is shown in Fig. 3. As shown in Fig. 3, the entity 210 in one embodiment includes an authentication unit 211, an attestation unit 212, a process execution unit 213, and an execution trail creation unit 214. Each of these units is realized, for example, by a process executed by a processor such as a CPU by one or more programs installed in the platform 200.
[0023] The authentication unit 211 performs mutual authentication with the authentication unit 211 of another entity 210 using any authentication method (for example, authentication using a digital certificate, token-based authentication, session-based authentication, etc.).
[0024] The attestation unit 212 performs mutual attestation with the attestation unit 212 of another entity 210. That is, in response to a request for issuing an attestation report from the attestation unit 212 of another entity 210, the attestation unit 212 issues an attestation report that includes the public key and configuration information of the entity 210. Furthermore, upon receiving an attestation report from the attestation unit 212 of the other entity 210, the attestation unit 212 verifies the authenticity of the other entity 210 based on the configuration information included in the attestation report. Here, the configuration information refers to the configuration information of the isolated execution environment that realizes the entity 210. The configuration information includes, for example, a CPU chip identifier, virtual machine boot firmware (OVMF (Open Virtual Machine Firmware)), an initialization RAM (Random Access Memory) disk (initrd), a kernel image file (kernel-image), a command line executed by the kernel (kernel-cmdline), and the like.
[0025] The processing execution unit 213 executes various processes between the user device 100 or another entity 210 to realize the services provided by that entity 210, and transmits the processing results to the user device 100 or the other entity 210. The processing execution unit 213 also requests the other entity 210 to execute various processes to realize the services provided by that entity 210, and receives the processing results.
[0026] The execution trail creation unit 214 creates a log (hereinafter referred to as an authentication log) containing information about the authentication party authenticated by the authentication unit 211, and then creates a signed authentication log by adding a signature to the authentication log using the signature key of the entity 210. Similarly, the execution trail creation unit 214 creates a log (hereinafter referred to as an attestation log) containing configuration information verified by the attestation unit 212, and then creates a signed attestation log by adding a signature to the attestation log using the signature key of the entity 210. Similarly, the execution trail creation unit 214 creates a log (hereinafter referred to as a communication log) containing information about the communication content when the process execution unit 213 executes processing, and then creates a signed communication log by adding a signature to the communication log using the signature key of the entity 210.
[0027] Furthermore, the execution trail creation unit 214 stores the signed authentication log, signed attestation log, and signed communication log as execution trails in any storage area of the platform 200. The storage area in which the execution trails are stored may be, for example, a storage area outside the isolated execution environment (e.g., a storage area of an auxiliary storage device such as an HDD, SSD, or flash memory).
[0028] <Operation Example> Hereinafter, as an example, service A will be referred to as a "secret computation execution service" and service B as a "storage service." Here, the secure computation execution service is a service that executes computation processing on data while keeping the data confidential even from the platform provider (management entity) of the service (hereinafter, such computation processing will also be referred to as "secret computation processing").
[0029] In the following, as an example of using a combination of multiple services that may be managed by different entities, a case will be described in which data stored in service B is used, calculation processing is performed on the data by service A, and the processing results are obtained by the user. An example of the operation of the system in this case will be described below with reference to Figure 4.
[0030] In the following, the authentication unit 211, attestation unit 212, process execution unit 213, and execution trail creation unit 214 of entity 210A will be referred to as "authentication unit 211A," "attestation unit 212A," "process execution unit 213A," and "execution trail creation unit 214A," respectively. Similarly, the authentication unit 211, attestation unit 212, process execution unit 213, and execution trail creation unit 214 of entity 210B will be referred to as "authentication unit 211B," "attestation unit 212B," "process execution unit 213B," and "execution trail creation unit 214B," respectively.
[0031] The processing request unit 101 of the user device 100 transmits a processing request to the entity 210A for calculation processing on data stored in service B (step S101). The processing request includes, for example, information on the storage location of the data in service B.
[0032] The authentication unit 211A of the entity 210A and the authentication unit 211B of the entity 210B perform mutual authentication (step S102). That is, the authentication unit 211A of the entity 210A authenticates the entity 210B using an arbitrary authentication method. Similarly, the authentication unit 211B of the entity 210B authenticates the entity 210A using an arbitrary authentication method.
[0033] The following description will be continued assuming that the mutual authentication in step S102 is successful. However, if the mutual authentication in step S102 fails, the subsequent processing will not be executed.
[0034] The execution trail creation unit 214A of entity 210A creates a signed authentication log and saves the signed authentication log in a memory area as an execution trail (step S103). That is, the execution trail creation unit 214A creates an authentication log that includes information about entity 210B (e.g., the date and time when entity 210B was authenticated, identification information for entity 210B, the name of the service provided by entity 210B, etc.), and then creates the signed authentication log by signing the authentication log using the signature key of entity 210A. The execution trail creation unit 214A then saves the signed authentication log in a memory area as an execution trail.
[0035] The execution trail creation unit 214B of entity 210B creates a signed authentication log and saves the signed authentication log in a storage area as an execution trail (step S104). That is, the execution trail creation unit 214B creates an authentication log that includes information about entity 210A (e.g., the date and time when entity 210A was authenticated, identification information for entity 210A, the name of the service provided by entity 210A, etc.), and then creates the signed authentication log by signing the authentication log using the signature key of entity 210B. The execution trail creation unit 214B then saves the signed authentication log in a storage area as an execution trail.
[0036] The attestation unit 212A of the entity 210A and the attestation unit 212B of the entity 210B perform attestation with each other (step S105). That is, the attestation unit 212A of the entity 210A sends an attestation report issuance request to the entity 210B, and verifies the authenticity of the entity 210B based on the configuration information included in the attestation report sent from the entity 210B in response to the attestation report issuance request. Similarly, the attestation unit 212B of the entity 210B sends an attestation report issuance request to the entity 210A, and verifies the authenticity of the entity 210A based on the configuration information included in the attestation report sent from the entity 210A in response to the attestation report issuance request. Note that the authenticity of the entity 210 may be verified by a known method (e.g., whether or not a hash value of the configuration information included in the attestation report matches a hash value of the actual configuration information of the entity 210). Additionally, the attestation report is signed by a hardware module that serves as the root of trust, and the signature is verified before the authenticity of entity 210 is verified.
[0037] The following description will be continued assuming that both parties have successfully verified the authenticity of the entities 210 in step S105. If the verification of the authenticity of either one of the entities 210 fails in step S105, the subsequent processing will not be executed.
[0038] The execution trail creation unit 214A of entity 210A creates a signed attestation log and then saves the signed attestation log in a memory area as an execution trail (step S106). That is, the execution trail creation unit 214A acquires the configuration information included in the attestation report sent from entity 210B, creates an attestation log including that configuration information, and then creates the signed attestation log by signing the attestation log using the signature key of entity 210A. The execution trail creation unit 214A then saves the signed attestation log in a memory area as an execution trail.
[0039] The execution trail creation unit 214B of entity 210B creates a signed attestation log and then saves the signed attestation log in a memory area as an execution trail (step S107). That is, the execution trail creation unit 214B acquires the configuration information included in the attestation report sent from entity 210A, creates an attestation log including that configuration information, and then creates the signed attestation log by signing the attestation log using the signature key of entity 210B. The execution trail creation unit 214B then saves the signed attestation log in a memory area as an execution trail.
[0040] When the mutual authentication in step S102 and the mutual attestation in step S105 are performed, each entity 210 executes any process to realize the service provided by that entity 210, and creates and saves a signed communication log if communication occurs in that process. In the following, as an example, it is assumed that entity 210A obtains data from entity 210B and then executes secure computation processing on the data.
[0041] The processing execution unit 213A of the entity 210A sends to the entity 210B a request to acquire the data stored in the storage location indicated by the storage location information included in the processing request sent in step S101 (step S108).
[0042] When the process execution unit 213B of the entity 210B receives the acquisition request sent in step S108, it acquires the data requested in the acquisition request (step S109).
[0043] The processing execution unit 213B of the entity 210B transmits the data acquired in step S109 to the entity 210A (step S110). At this time, the processing execution unit 213B encrypts the communication path between the entity 210A and the entity 210A or the data itself based on the public key included in the attestation report transmitted from the entity 210A, and then transmits the data to the entity 210A.
[0044] The encryption method in step S110 is not limited to a specific method. For example, the public key may be used to share a common key (e.g., a random number) with entity 210A, and the communication path to entity 210A or the data itself may be encrypted using the common key. Furthermore, mechanisms such as TLS (Transport Layer Security) and SSL (Secure Sockets Layer) may be used to encrypt the communication path to entity 210A. On the other hand, when encrypting the data itself, a method called object encryption may be used, in which data is divided into predetermined units and then encrypted for each unit.
[0045] The execution trail creation unit 214A of entity 210A creates a signed communication log and saves the signed communication log in a memory area as an execution trail (step S111). That is, the execution trail creation unit 214A creates a communication log including the acquisition request sent in step S108 above and a communication log including the data received in step S110 above, and then creates the signed communication logs by attaching a signature to each of these communication logs using the signature key of entity 210A. The execution trail creation unit 214A then saves the signed communication logs in a memory area as execution trails.
[0046] The execution trail creation unit 214B of entity 210B creates a signed communication log and saves the signed communication log in a memory area as an execution trail (step S112). That is, the execution trail creation unit 214B creates a communication log including the acquisition request received in step S108 above and a communication log including the data transmitted in step S110 above, and then creates the signed communication logs by attaching a signature to each of these communication logs using the signature key of entity 210B. The execution trail creation unit 214B then saves the signed communication logs in a memory area as execution trails.
[0047] The processing execution unit 213A of the entity 210A executes the secure computation process on the data received in the above step S110 (step S113). At this time, if the data received in the above step S110 is encrypted, the processing execution unit 213A decrypts the data and then executes the secure computation process on the decrypted data.
[0048] The processing execution unit 213A of the entity 210A transmits the processing result of the secure computation processing in the above step S113 to the user device 100 (step S114). At this time, the communication path of the user device 100 or the processing result itself may be encrypted.
[0049] The processing result manager 102 of the user device 100 stores the processing result transmitted from the entity 210A in a storage area (step S115). At this time, if the processing result itself is encrypted, the processing result manager 102 decrypts the processing result and stores the decrypted processing result in a storage area. This allows the user to obtain the result of the secure computation for the desired data.
[0050] 4, the case where service A is a "secure computation execution service" and service B is a "storage service" and these two services are used in combination has been described, but this is just one example. The system according to this embodiment can also be applied to the case where a plurality of various services, each managed by a different entity, are used in combination.
[0051] Furthermore, even if a process for realizing a service between two entities 210 is executed multiple times, it is sufficient to perform mutual authentication and mutual attestation only once.
[0052] <Hardware Configuration Example> A physical machine that realizes the above-described user device 100 and platform 200 can be realized, for example, by the hardware configuration of a computer 500 shown in Fig. 5. The computer 500 shown in Fig. 5 has an input device 501, a display device 502, an external I / F 503, a communication I / F 504, RAM 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.
[0053] 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 necessarily have to have at least one of the input device 501 and the display device 502, for example.
[0054] The external I / F 503 is an interface with an external device such as a recording medium 503 a. Examples of the recording medium 503 a 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.
[0055] The communication I / F 504 is an interface for connecting 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 an HDD, SSD, or flash memory. The processor 508 is an arithmetic device such as a CPU.
[0056] 5 is an example and is not intended to be limiting. For example, the computer 500 may have multiple auxiliary storage devices 507 or multiple processors 508, may not have some of the hardware shown in the figure, or may have various types of hardware other than the hardware shown in the figure.
[0057] <Modifications> Modifications of the above embodiment will be described below. Note that the following modifications can be combined with multiple modifications as long as they do not contradict each other.
[0058] Modification 1 In the above embodiment, for simplicity, it is assumed that one entity 210 exists in each platform 200, but multiple entities 210 may exist in a certain platform 200. In this case, the multiple entities 210 existing in the platform 200 may be managed by the same or different entities.
[0059] Modification 2 In the above embodiment, for simplicity, authentication or mutual authentication between the user device 100 and the entity 210 to which the user device 100 makes a processing request is omitted, but this authentication or mutual authentication may also be performed.
[0060] Modification 3 In the above embodiment, it is assumed that the user device 100 trusts the entity 210 to which it issues a processing request. However, the user device 100 may, for example, send an attestation report issuance request to the entity 210 before issuing a processing request, and verify the attestation report issued by the entity 210. This allows the user device 100 to verify whether the entity 210 has been tampered with, and issue a processing request only if the verification is successful.
[0061] <Summary> As described above, in the system of this embodiment, when a user uses multiple services that may be managed by different entities, mutual authentication and mutual attestation are performed between the entities 210 that provide each service, and then various processes for realizing the service are executed. This enables each entity 210 to authenticate other entities 210 with which it communicates and to verify their authenticity, thereby achieving safety.
[0062] Furthermore, in the system according to this embodiment, a signature is added to the log when mutual authentication, mutual attestation, processing execution, etc. are performed between entities 210, and the log is saved as an execution trail. This provides an execution trail that cannot be tampered with, which improves auditability in the event of, for example, data leakage or information leaks, and makes it possible to clarify the demarcation point of responsibility for each entity 210.
[0063] The present invention is not limited to the above-described specifically disclosed embodiments, and various modifications, changes, and combinations with known technologies are possible without departing from the scope of the claims.
[0064] 100 User device 101 Processing request unit 102 Processing result management unit 200 Platform 210 Entity 211 Authentication unit 212 Attestation unit 213 Processing execution unit 214 Execution trail creation 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
Claims
1. A system including a plurality of entities each providing a specified service, wherein the entities have: an authentication unit that performs mutual authentication with other entities; an attestation unit that performs mutual attestation with the other entities if the mutual authentication is successful; and a processing execution unit that, if the attestation is performed, executes specified processing to realize the service with the other entities.
2. The system of claim 1, wherein the entity is a virtual machine, a container, or a pod that implements an isolated execution environment.
3. The system of claim 1 or 2, wherein the entity further comprises an execution trail creation unit that creates and stores a signed first log regarding the mutual authentication, a signed second log regarding the attestation, and a signed third log regarding the processing as execution trails.
4. The system described in claim 3, wherein the execution trail creation unit creates the signed first log by signing a first log containing information about the other entity with the entity's signature key, creates the signed second log by signing a second log containing configuration information of the other entity with the entity's signature key, and creates the signed third log by signing a third log containing the contents of communications generated in the processing with the entity's signature key.
5. A device that realizes an entity that provides a specified service, the device having: an authentication unit that performs mutual authentication with another entity that provides another service; an attestation unit that performs mutual attestation with the other entity if the mutual authentication is successful; and a processing execution unit that executes specified processing to realize the service with the other entity if the attestation is successful.
6. A method used in a system including multiple entities each providing a specified service, wherein the entity executes an authentication procedure for mutual authentication with another entity, an attestation procedure for mutual attestation with the other entity if the mutual authentication is successful, and a processing execution procedure for executing a specified process to realize the service with the other entity if the attestation is successful.
7. A program that causes a device realizing an entity that provides a specified service to execute an authentication procedure for performing mutual authentication with another entity that provides another service, an attestation procedure for performing mutual attestation with the other entity if the mutual authentication is successful, and a processing execution procedure for executing a specified process to realize the service with the other entity if the attestation is successful.
Citation Information
Patent Citations
Distributed Key Management for Trusted Execution Environments
JP2020524421A
Methods for constructing trusted grid, trusted grids, and application interaction methods thereon
US20240205224A1
Verifying network elements
WO2016085517A1