WO2022123795A1 - サービス提供システム - Google Patents
サービス提供システム Download PDFInfo
- Publication number
- WO2022123795A1 WO2022123795A1 PCT/JP2020/046433 JP2020046433W WO2022123795A1 WO 2022123795 A1 WO2022123795 A1 WO 2022123795A1 JP 2020046433 W JP2020046433 W JP 2020046433W WO 2022123795 A1 WO2022123795 A1 WO 2022123795A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- share
- data
- group
- information
- server
- Prior art date
Links
- 238000012795 verification Methods 0.000 claims abstract description 68
- 238000004364 calculation method Methods 0.000 claims abstract description 62
- 238000000034 method Methods 0.000 claims abstract description 56
- 238000012545 processing Methods 0.000 claims abstract description 38
- 230000006870 function Effects 0.000 description 26
- 230000008569 process Effects 0.000 description 14
- 230000007246 mechanism Effects 0.000 description 13
- 238000010586 diagram Methods 0.000 description 10
- 230000000717 retained effect Effects 0.000 description 4
- 239000000654 additive Substances 0.000 description 3
- 230000000996 additive effect Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 238000013480 data collection Methods 0.000 description 3
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 2
- 238000003491 array Methods 0.000 description 2
- 235000013405 beer Nutrition 0.000 description 2
- 238000013499 data model Methods 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 239000003550 marker Substances 0.000 description 2
- 235000015205 orange juice Nutrition 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 235000019640 taste Nutrition 0.000 description 2
- LFQSCWFLJHTTHZ-UHFFFAOYSA-N Ethanol Chemical compound CCO LFQSCWFLJHTTHZ-UHFFFAOYSA-N 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 235000011389 fruit/vegetable juice Nutrition 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 244000144985 peep Species 0.000 description 1
- 238000005316 response function Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
- G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
- H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/42—Anonymization, e.g. involving pseudonyms
Definitions
- the present invention relates to a technique for providing a personalized service, and particularly to a technique applicable to a service providing system for providing a personalized service without specifying the user himself / herself.
- Patent Document 1 Japanese Patent Application Laid-Open No. 2015-532737
- Patent Document 1 provides true protection against end-user private information by providing anonymity to each end-user's private information without restricting the use of the application.
- Patent Document 1 allows you to utilize any computer device to receive personalized services or use other applications and services that require user clustering according to the similarity of private data. The mechanism is described.
- an object of the present invention is to realize a service providing system that provides personalized services including those unique to the user while protecting privacy while eliminating the need to identify the user himself / herself.
- the service providing system is a service providing system that provides a service to a user's first device via a network by one or more second devices. , Has the following configurations.
- the first device acquires the VC from the VC storage unit that stores the data VC that can be verified as belonging to the user, divides the VC into a plurality of shares by the secret sharing method, and divides each share into a plurality of shares.
- the information of the group ID related to the share providing unit and the one or more VCs returned from the second device is acquired and stored in the ID storage unit, and stored in the group ID. Based on this, it has a first group synchronization unit that obtains the result of a predetermined secret calculation related to the service in the second device by decoding (Reconstruct) by a secret sharing method.
- the share acquisition unit that acquires the share distributed from the first device and the acquired share have the same value of ID information included in the VC related to the share.
- the group ID is issued, the group ID and the information related to the share are stored in the share storage unit, and the second device returns the information including the group ID to the first device. It has a group synchronization unit.
- the service provision system realizes a mechanism in which a service user provides data related to himself / herself to a service provider, and the service provider provides a personalized service based on the data. Is what you do.
- the data provided by the user at that time is data that can be verified as belonging to the user (Verifiable Credentials, hereinafter may be referred to as "VC").
- VC Verifiable Credentials
- the service provider realizes the privacy protection of the user by making it impossible to identify the user himself / herself from the provided data (it is not necessary to identify the user himself / herself).
- the so-called secret calculation technique is used as a mechanism for protecting privacy so that the service provider cannot identify the user himself / herself based on the data provided by the user.
- Secret calculation is a technique for obtaining a calculation result by calculating the data to be calculated in an encrypted state, and makes it possible to conceal the data to be calculated and the calculation process.
- multi-party calculation (Multi-Party Computation, which may be referred to as "MPC” in the following) is used as a secret calculation method. That is, the user's data is divided into multiple shares by the secret sharing method and placed in a state of being isolated on different servers, and on the server side, the confidentiality of the data is maintained while communicating between the servers. Calculations such as addition and multiplication are performed in the state, and the calculation result is obtained.
- MPC Multi-Party Computation
- MPC with Functional Completeness can calculate any function / algorithm while keeping the data secret. Since this calculation result is also in a secret-shared state, the decryption collects each share unless the parties participating in the MPC provide shares to each other or externally to allow the decryption. Only the person who is allowed to do so, that is, the user who provided the data, can do it, and the server side cannot peep at the provided data or the calculation result. As long as the calculation result is not decoded by an unintended party, it can be kept secret, so that so-called output privacy can be prevented from becoming a problem.
- the service provider does not know the content of the data provided by the user, but also does not identify the user himself / herself, and the calculation result (or the service personalized based on this) is given to the user himself / herself.
- the secret sharing method for example, an additive secret sharing method (n ⁇ k ⁇ 2) with a (k, n) threshold can be used.
- ID information indicating an ID (identity) is associated with each data.
- a so-called centralized ID can be used as the ID management platform, but in the present embodiment, it is described as a decentralized ID (Decentralized Identity, hereinafter referred to as “DID”” using the techniques of the blockchain and the distributed ledger. In some cases), the mechanism shall be used.
- the DID specifications are currently being standardized, but each data may be described as a wallet address in the blockchain (Wallet Address, hereinafter "WA”) as the ID information of the user himself / herself. May be given meta information that makes the network or protocol that provides the DID unique).
- the data formats handled by DID are all formats that VC can take (see the W3C Recommendation below for the definition of the data model.
- Https://www.w3.org/TR/vc-data-model/# : ⁇ : text Data% 20derived% 20from% 20one% 20or, a% 20process% 20of% 20cryptographic% 20verification.), Any data type that can be represented by an array or an associative array (Map format).
- JSON JavaScript Object Notation
- YAML a% 20process% 20of% 20cryptographic% 20verification.
- Any data type that can be represented by an array or an associative array Map format.
- JSON JavaScript Object Notation
- YAML YAML
- CBOR Concise Binary Object Representation
- TOML etc.
- JSON-LD JSON-LD
- the DID mechanism By using the DID mechanism, it is possible to carry out identity verification to any other party at the will of the user himself / herself.
- the DID mechanism is used not only as a means of proof of identity but also as a means of indicating an intention to give permission to collect and utilize data to an arbitrary party based on the intention of the user himself / herself.
- DID is used as an example of a method for realizing a form in which data is handled as a VC. Therefore, the signed data is expressed as "VC" according to the DID term, but since the means for reproducing the present embodiment is not limited to the one using the DID, it is defined in the DID specifications. It can also be used in a data format different from that of the VC. If the data corresponding to VC in the DID is data that satisfies all of the following conditions, it can be appropriately used.
- the issuer responsible for issuing the data, and a digital signature is given as a means to prove that the data is issued by the issuer (Issuer).
- the data includes information indicating ID (identity) (for example, WA, My Number, passport number, etc.).
- ID identity
- the issued data are arrays, associative arrays, JSON, YAML, Structured data such as TOML, or a collection of structured data that can be restored even if the format and elements are separated, given the meta information such as the sequence number or attribute assigned to each element. That is 4. 4. It is possible to uniquely determine the storage location of ID (identity) information in structured data.
- the data should contain information that uniquely determines the digital signature algorithm and how to obtain the public key. Digital signatures must be done at once on structured data, or the entire set of structured data.
- the sequence number and the element such as (0, a), (1, b), (2, c) If the correspondence is unique, it is possible to restore the original data [a, b, c] from that information.
- the data ⁇ “name”: “alice”, “age”: 42 ⁇ can be restored from (“name”, “alice”) and (“age”, 42).
- the storage location of the ID information can be uniquely specified.
- the signature ⁇ is the secret key sk, and the structure is formed. It must be obtained by the signature algorithm Sign with the input value (x 1
- the verification algorithm Verify (pk, ⁇ , (x 1
- JWS JSON Web Signature
- a structured data set includes a header part and a payload part, and a value obtained by combining a header part (Header) and a payload part (Payload) with dots (.).
- a signature unit (Signature) is obtained.
- FIG. 2 is a diagram illustrating an outline of an example of the mechanism in one embodiment of the present invention.
- the client 2 of the user 4 has a VC 241.
- the VC 241 is, for example, data acquired by a data collection facility 6 such as a video camera in the city (in this case, a camera image, but a purchase history of a payment service). Data collected by different facilities and services such as, etc.) is included and registered in PKI (Public Key Infrastructure) or DPKI (Decentralized PKI, Decentralized Public Key Infrastructure) 5 (in the figure). It was issued ([2] in the figure) with a digital signature using a private key that is a pair of the public key that was (1)).
- PKI Public Key Infrastructure
- DPKI Decentralized PKI, Decentralized Public Key Infrastructure
- this VC241 is represented by JSON in this embodiment, and WA of DID is included as ID information.
- the client 2 of the user 4 authenticates the issuer (data collection facility 6) by verifying the digital signature of the VC241 with the public key registered in the DPKI5 ([3] in the figure).
- the user 4 agrees to provide the VC 241 to the service provider ([4] in the figure), and then the client 2 of the user 4 secretly shares the VC 241.
- the shared shares 26a and 26b are provided to the servers A (3a) and the server B (3b) participating in the MPC, respectively ([5] in the figure).
- VC241 is secretly distributed to two shares and provided to two servers, but secretly distributed to two or more shares, that is, (k, n) threshold secret sharing method (n ⁇ k).
- the secret sharing based on ⁇ 2) may be performed to provide each share to a different server.
- these shares 26a and 26b (ciphertext) and the public key (plaintext) registered in DPKI5 are used as input values, and verification is performed through MPC by server A (3a) and server B (3b) (in the figure). [6]) is performed.
- [6]) is performed.
- the calculation result is obtained without obtaining the contents of the original VC241, and based on this. And provide personalized services.
- the service provider cannot know the contents of the original VC241 and the calculation result, if the data of which user 4 can be known, that is, the person can be identified, the privacy is completely complete. Not protected. Therefore, in the present embodiment, the contents of one or more VC241 provided to the service provider are kept encrypted, (1) the contents are not tampered with, and (2) both VC241 are the same. After confirming that it is associated with the user 4, each VC241 provided to the service provider is grouped and given a group ID, and this group ID is returned to the user 4. As a result, the user 4 can request and receive the personalized service based on the returned group ID while keeping the data of which user 4 secret from the service provider side.
- the calculation is outsourced to an external trusted environment, and the calculation result is returned to the server A (3a) and the server B (3b) in a secretly distributed form, or It is also possible to pass the group ID to the outsourcer and have them act as a proxy for the distribution of the calculation results.
- the calculation is performed by a means other than the MPC, and the calculation result is re-calculated on the server A (3a).
- server B (3b) (at the same time, all the information entrusted to the consignee may be deleted from the consignee's environment). This makes it possible to trade off safety and performance.
- FIG. 3 is a diagram showing an outline of an example of a mechanism for providing a personalized service according to an embodiment of the present invention.
- the VCs of "data 1", “data 2", and “data 3" are held in the wallet 211a of the user 4a, and the “data 4" and “data” are held in the wallet 211b of the user 4b. It shows the state where the VC of "5" is held.
- the service provider (server) side assigns a group ID of "group 1" to these data. Indicates that it has been issued and grouped.
- a group ID "group 2” was issued to these data and grouped. It is shown that.
- the issued "Group 1" and “Group 2" group IDs are returned to the user 4a who is the provider of the target data.
- the user 4b provided "data 4" and “data 5", it is shown that the group ID "group 3" was issued to these data and grouped.
- the group ID of "Group 3" is returned to the user 4b.
- the data administrator 7 on the service provider side (who has access authority to the database for the number of environments less than the threshold k required for decryption by the secret sharing method) refers to the contents of the database. Since the data in the database is also encrypted (by secret sharing), the contents cannot be grasped. Furthermore, it cannot be grasped that any of the data is associated with the WA of each person's wallet 211a or wallet 211b, let alone the user 4a or the user 4b himself / herself. That is, it is possible to realize the inability to identify the person who provided the data in the administrator 7 (service provider).
- the administrator 7 can understand that, for example, "data 1" and “data 2" included in "group 1" are associated with “someone who is the same”. That is, it is possible to personalize the service for "someone" in "Group 1".
- the user 4a who has returned the group ID of "group 1” can use this group ID to request a personalized service based on the data of "group 1". That is, the calculation result based on "Data 1" and “Data 2" of "Group 1" is also associated with the group ID of "Group 1" on the service provider (server) side.
- the user 4a can make a request by using the group ID of "group 1".
- FIG. 4 is a diagram showing an outline of another example of the mechanism for providing the personalized service in one embodiment of the present invention.
- “data C1" and “data C2” are held in the wallet 211c of the user 4c
- “data D1” and “data D2” are held in the wallet 211d of the user 4d.
- the user 4c illegally obtains "data D1” from the wallet 211d of the user 4d and adds it to his / her own wallet 211c.
- the user 4c provides "data C1" and "data C2" in order to receive the provision of a certain service, and these data are grouped and a group ID "group 4" is issued. ing.
- the user 4c provides "data C2" and “data D1" in order to receive the provision of another service, and these data are grouped and a group ID "group 5" is issued.
- the data of another person is treated as the information of the same group as in "Group 5", the calculation result based on these data becomes an invalid one that is not based on the true information of the user 4c.
- the content of the service provided will be altered.
- the data administrator cannot grasp the contents of the encrypted data, each provided as belonging to the same group (“Group 5” in the example of FIG. 4). It is not possible to confirm whether the data is really associated with the same user (user 4c in the example of FIG. 4).
- the service provider (server) side has the same data. After verifying with MPC whether or not all the data provided as belonging to the group have the same ID information, if it can be confirmed that all the data have the same ID information, these data are grouped. It shall be. That is, in the example of FIG. 4, "data C2" and “data D1" are not grouped, and the group ID "group 5" is not issued (or the group ID "group 5" is "deemed”. It may be provisionally issued as a "group ID” and then discarded if it cannot be confirmed that all the ID information is the same later). As a result, all the data belonging to a certain group can be treated as belonging to the same user. It should be noted that the service provider side can grasp that the data having the same ID information is the data of "the same someone", but cannot grasp the data of "who".
- FIG. 5 is a diagram showing an outline of an example of application of the secret sharing method in one embodiment of the present invention.
- Plaintext before being shared by the secret sharing method (In this embodiment, for example, the JWS header part and payload part are concatenated with dots (.), And if they are encoded with Base64URL, they are in advance.
- the VC241 (decoded to) consists of data D and Dsig, which is a digital signature for the data (decoded in advance if it is encoded by the Base64 URL in the signature part of JWS).
- the data D includes the format portion F, ID information SUB_WA, and m attribute information (claims (pair of key and value) in, for example, JWT (JSON Web Token) in this embodiment)) C1 to Cm. Consists of.
- the format portion F is a format portion in JSON (particularly, a portion excluding the value subject to privacy protection according to the present embodiment from the claim set (ClaimsSet) of the payload portion), and is not only the payload portion in JWS but also the header. It also includes a part.
- the SUB_WA is the WA (wallet address) of the DID in the present embodiment, but if it matches the identity information in each VC, the My Number, the passport number, and other identities are used. It may be information.
- the format portion F in the claim set, each claim C1 to Cm, and SUB_WA are secretly distributed in a form that can be separated from each other. This is because when the share is generated by secretly sharing the VC241 which is JWS as it is, the format part F and the data of the claim set (SUB_WA and each claim C1 to Cm in this embodiment) are generated on the server side where the share is generated. Of these, the shared portion of the value subject to privacy protection) cannot be distinguished, which may hinder the verification and utilization of data by the MPC on the server side.
- the format part F does not include the privacy information of the user 4, it does not need to be concealed. Therefore, the server that participates in the MPC as it is in plain text without sharing by secret sharing. Distribute to. In this case, when performing MPC on the server side for each share 26, if the format portion F is treated as a share and targeted for MPC, the plaintext of the format portion F is included in a plurality of shares, so the calculation is correct. You will not be able to.
- the format portion F is set as plain text, and the format portion F is also pseudo-shared by the following method so that the MPC can be performed correctly.
- the share 26 containing all the actual contents in the format portion F is set to only one among all the servers, and the share 26 of the other servers is set to the “zero value” part of the format portion F.
- change refers to an operation by the Zero function that converts arbitrary data S into S'in the following manner, for example.
- S' Zero (S)
- S Reconstruct (S, S', S', ..., S') That is, the "zero-valued"S'is data that the result is S when decoding is performed based on the share where there is only one S and all the others are S'.
- the method for setting the format portion F as plain text is not limited to the above-mentioned "zeroing".
- a party other than one of all the parties (server 3) holding the share 26 issues random numbers, collects them in one party, and uses the random numbers issued by each party on the party that collected the random numbers.
- the above-mentioned "zero-valued” is used as a method for setting the format portion F as plaintext, and in the following, Zero (F) in which the format portion F is "zero-valued” is described as F'. ..
- the format portion F' is calculated, the format portion F is not used for the MPC, but the format portion F may be retained without being deleted separately for the purpose of referring to the key information.
- the format portion F includes a part to be replaced by the share of privacy information (share of the value of the claim included in the share 26), a marker for indicating the replacement target. Only the part excluding (for example, the character string to be replaced) shall be zeroed.
- Share 26_1, share 26_1 ... Share 26_n in the figure indicate n shares 26 obtained by secretly sharing VC241 under the above conditions, respectively.
- the nth share 26_n includes the nth share D_$ n for the VC241, that is, the nth share D_$ n of the data D and the nth share Dsig_$ n of the digital signature Dsig.
- the format portion F of the plaintext (or the format portion F'in the party that "zeroed" the format portion F), the nth share SUB_WA_ $ n of the ID information SUB_WA, and the nth of each claim C1 to Cm.
- VC_ $ n which is a concatenation of the shares C1_ $ n to Cm_ $ n, is included.
- the concatenation here refers to an operation of replacing the value (plaintext) of a claim, which is privacy information among the information contained in the data D, with each share (ciphertext), and this is defined as a Response function. That is, in the i-th server Pi ( i ⁇ ⁇ 1, 2, ..., N ⁇ ) to which the secret-shared share 26 is distributed, the substitution is performed as follows.
- each share 26 has a configuration in which the format portion F (plain text) and the shares of the claims C1 to Cm can be separated.
- the format portion F plain text
- the format portion F'that has been "zero-valued" is the same as described above in the Reconstruct function. Since it does not affect the result, the MPC can be performed based on the content of the share 26 that actually includes the plaintext of the format portion F, which is only one of the total shares.
- the format portion F of all the shares 26 contains the actual contents without performing the above "zeroing", for example, the share 26 held by any one server 3 ( Pi ).
- the verification may be performed by using only the format portion F of the above, ignoring the format portion F of the other share 26, and treating it in the same manner as “zero”.
- the VC241 is divided into a data part and a format part, and while only the format part (format part F) remains in plain text, the other data parts are encrypted by secret sharing to generate a share 26. is doing.
- claims C1 to Cm also have privacy information (confidential information that the user wants to keep secret) and non-privacy information (information that the user himself / herself is willing to disclose).
- the claims corresponding to non-privacy information may be handled as plain text without being encrypted (shared).
- information on whether or not the data (value) to be retained is privacy information (whether or not to share) may be separately retained, for example, in the format portion F of the data (value). You may leave the plaintext included.
- FIG. 1 is a diagram showing an outline of a configuration example of a service providing system according to an embodiment of the present invention.
- the service providing system 1 has, for example, a configuration in which a client 2 owned by a user 4 and a plurality of servers 3 can communicate with each other via a network such as the Internet (not shown).
- the client 2 is a device (first device) having a function of mainly holding and managing VC241 information about the user 4, and is, for example, information processing of a PC (Personal Computer), a tablet terminal, a smartphone, or the like. It is implemented by terminals and other devices.
- PC Personal Computer
- the server 3 isolates and stores a plurality of shares 26 generated by secret-sharing the VC 241 in the client 2, and performs MPC based on these shares 26 to provide a personalized service. It is a device (second device) having a function of obtaining a calculation result, and is implemented by, for example, a server device, a virtual server built on a cloud computing service, or other device.
- Each server 3 shall be managed by a different person / business operator who does not collude for the purpose of illegally manipulating the share 26, and it is desirable that they are physically isolated, but they are the same. It does not exclude a logically isolated configuration such as a plurality of virtual servers built on one server device managed by the person / business operator.
- the client 2 is, for example, an OS (Operating System) or a DBMS (Database Management System) developed on a memory from a recording device such as an HDD (Hard Disk Drive) or SSD (Solid State Drive) by a CPU (Central Processing Unit) (not shown). ) Etc., and software such as a Web browser and an application program running on the middleware, etc., realizes the various functions of the client 2 described above.
- the client 2 has, for example, each unit such as a VC processing unit 21 implemented by software, a share providing unit 22, and a group synchronization unit 23. It also has data stores such as a VC storage unit 24 and an ID storage unit 25 implemented by a database, a file, or the like.
- the VC processing unit 21 has the above-mentioned DID function for allowing the user 4 to handle the data issued by the issuer as the VC241.
- the VC241 obtained via the VC processing unit 21 contains information indicating an ID (identity) (for example, WA of DID), attribute information (for example, "purchased product” apple "", and “amount (for example). (Yen) "100" "etc.) is included.
- ID identity
- attribute information for example, "purchased product” apple "", and "amount (for example). (Yen) "100" "etc.
- the obtained VC241 is recorded and stored in the VC storage unit 24.
- an existing DID product such as Microsoft and an SDK (software development kit) can be appropriately used.
- FIGS. 6 and 7 are diagrams showing an outline of the data structure of the VC storage unit 24 and an example of specific data according to the embodiment of the present invention.
- the data D and its digital signature Dsig, the format portion F, and the ID information SUB_WA portion are displayed.
- Each is stored in the corresponding column, and in the table of the VC storage unit 24b of FIG. 7, the key and value of claims C1 to Cm, and the data type of the value (string, number (int, double), boolean, null / object, object) are stored. (JSON object), array, etc. are standard, but you may define your own type).
- the VC storage unit 24a of FIG. 6 further holds a VCID that uniquely identifies each VC241 as a key
- the VC storage unit 24b of FIG. 7 further holds a claim ID that uniquely identifies each claim as a key. It is shown that.
- the JWS data is held as it is in the data D in the VC storage unit 24a of FIG.
- the format portion F it is shown that only the value portion of the claims contained in JWS is stored in a state of being replaced with a marker such as "$ ⁇ SUB_WA ⁇ " or "$ ⁇ claim ID ⁇ ".
- This part is, for example, the claim ID (“C001” in the examples of FIGS. 6 and 7) or the character string representing the identity information (“SUB_WA” in the example of FIG. 6) of the corresponding claim in the VC storage unit 24b of FIG.
- the value value of the claim and the replacement target can be separated by enclosing them in "$ ⁇ ", but a parser that can correctly analyze the notation of the replaced data (for example, JSON grammar) is available. Any notation method may be used as long as it can be implemented.
- the share providing unit 22 of the client 2 encrypts a plurality of VC241 stored in the VC storage unit 24 designated by the user 4 by the (k, n) threshold secret sharing method. It has a function of generating the share 26 of the above and providing each share 26 to any server 3.
- the method of secretly sharing the VC 241 to generate a plurality of shares 26 is as shown in the example of FIG. 5, but in this case, since n shares 26 are generated, one for each of the n servers 3. It is desirable to provide shares 26 one by one. On the other hand, if k or more shares 26 are not provided to one server 3, the original VC241 will not be restored by one server 3, so the limit is less than n.
- the case of providing to a number of servers 3 (providing a plurality of shares 26 to one server 3) is not excluded.
- the group ID (“group ID for the data lent to the server 3 by the client 2” in the server 3 is called.
- a “rental group ID” is issued and returned to the client 2 of the user 4.
- information that makes the claim unique to the lending claim ID issued for each claim of VC241 on the server 3 is also returned.
- information such as key, data type, and value is applicable.
- the credential information for subsequent authentication may be returned only at the time of the first return. In the figure, these are collectively shown as loan information 35.
- the group synchronization unit 23 acquires the loan information 35 returned from the server 3 in cooperation with the group synchronization unit 33 of the server 3, which will be described later, records and stores the contents in the ID storage unit 25, and secretly shares the information. It has a function to decode data including calculation results by the method. After that, by transmitting the lending group ID (and lending claim ID) returned from the server 3 and the credential information to the server 3 as necessary, the server 3 is grouped and managed by the group ID. It is possible to receive the calculation result (plain text) based on the data of the claim associated with the group ID by synchronizing with the calculation result (share) of the MPC based on the share 26 and decoding (Reconstruct) from the share of the acquired calculation result. It will be possible. That is, the act of distributing the share of the calculation result associated with the group ID from the server 3 is a means of distributing the personalized service.
- the lending claim ID in addition to the lending group ID, it is possible to perform processing based on the data related to the lending claim ID. For example, it is possible to exercise the right that corresponds to the "erasure right" or "correction right” specified in the GDPR (General Data Protection Regulation, EU General Data Protection Regulation) for the target data.
- GDPR General Data Protection Regulation, EU General Data Protection Regulation
- FIG. 8 is a diagram showing an outline of a data structure of the ID storage unit 25 and an example of specific data in the embodiment of the present invention.
- the lending group ID, the lending claim ID, the key of the target claim, and the contents of the data type are stored respectively.
- the content of the value decrypted by the secret sharing method is stored for each claim.
- this table includes not only the data (claims) provided by VC241 but also the data obtained by decoding the calculation result of MPC on the server 3 side based on the data (claims) provided by VC241.
- the server 3 is described above by, for example, using a CPU (not shown) to execute middleware such as an OS or DBMS developed on a memory from a recording device such as an HDD or SSD, and software running on the middleware. Realize various functions of the server 3.
- the server 3 has, for example, each unit such as a share acquisition unit 31, a verification processing unit 32, and a group synchronization unit 33 implemented by software. It also has a data store such as a share storage unit 34 implemented by a database, a file, or the like.
- the share acquisition unit 31 has a function of receiving and acquiring the share 26 provided by the client 2 and temporarily holding the share 26 in a recording device such as a memory.
- the verification processing unit 32 has a function of performing the following three types of verification processing on the share 26 temporarily held by the share acquisition unit 31 while using the MPC, and the issuer to perform each verification processing. It further has each unit such as a verification unit 321, an inclusion verification unit 322, and a grouping unit 323.
- the order in which the following three types of verification processes are performed is not particularly limited. That is, all three types of verification processes can be performed in parallel.
- the issuer verification unit 321 has a function to verify that the person who is supposed to be the issuer of the target data is the correct issuer as the first verification.
- a verification algorithm corresponding to a pair of digital signature signature algorithms used in the signature calculation is carried out by the MPC.
- This signature algorithm is determined by the information contained in the format portion F. For example, it is determined by the value of the key "alg" in the header part of JWS.
- An algorithm for integrity verification by MPC (VerifyMPC) using the public key obtained from PKI or DPKI based on the value of the key "kid” and the share Dsig_ $ i of the digital signature included in VC_ $ i and VC241 as input values. The result is confirmed by executing the function) and decoding the share of the verification result.
- the inclusion verification unit 332 verifies that the share of the privacy information contained in VC_ $ i is a share in which the data contained in VC241 is secretly distributed. Specifically, for example, taking the share 26_n in FIG. 5 as an example, the value obtained by concatenating the format portion F or F'and the shares C1_ $ n to Cm_ $ n of each claim C1 to Cm, that is, VC_ $ i. , The share D_ $ n of the entire VC241 is equivalently verified (EqualMPC function) by MPC, and the share of the verification result is decoded (Reconstruct) to confirm the result.
- the first verification and the second verification can be combined by one verification. That is, as shown below, it is included in the value obtained by concatenating the public key obtained from PKI or DPKI, the format portion F or F'and the shares C1_ $ n to Cm_ $ n of each claim C1 to Cm, and VC241. If the result is confirmed by executing the integrity verification algorithm on the MPC with the digital signature Dsig_ $ i as the input value and decoding the share of the verification result, the first verification and the second verification can be performed. be able to.
- the VerifyMPC function represents a digital signature integrity verification algorithm by MPC. Further, v represents the result of verification by the integrity verification algorithm of the digital signature determined by the value of the key “arg” by pk, Dsig, and VC.
- the grouping unit 323 verifies whether or not the ID information of the VC241 included in each share 26 is the same as that of the other VC241 when the shares 26 related to the plurality of VC241 are acquired. It has a function of grouping data related to VC241 which is the same ID information.
- the share of ID information SUB_WA in VC2411 is REP_SUB_WA_ $ i.
- the share of the ID information SUB_$ in the other (p-1) VC241 is sub q _ $ i, and in 1 ⁇ q ⁇ p, REP_SUB_WA_ $ i and sub q _ $ i are respectively verified by MPC (EqualMPC function). )do.
- the group ID is issued to the VC241.
- the VC241 if there is even one VC241 whose ID information is not the same value, it may be grouped only by the VC241 whose ID information is the same value, or it may be discarded and a predetermined exception handling may be performed. May be done.
- a claim ID is further assigned to each value included in each VC241. The assigned group ID and claim ID are returned to the client 2 as a lending group ID and a lending claim ID (with a property name of VC241), respectively, by the group synchronization unit 33 described later.
- the information related to the grouped VC241 is stored in the share storage unit 34.
- 9 and 10 are diagrams showing an outline of a data structure of the share storage unit 34 and an example of specific data according to the embodiment of the present invention.
- the share of the lending group ID and the ID information SUB_WA is stored as the information related to the group ID.
- the value of the ID information SUB_WA of the record whose lending group ID is "Group 1" is represented by "30181B " and a hexadecimal random number in the shared (encrypted) state. Is shown.
- the information related to the claim ID includes the lending group ID and the lending claim ID, and the plain text of the key and data type in the claim other than the signature, as well as the value. Indicates that share information should be stored.
- the value of the record whose claim key is "name” is represented by a hexadecimal random number, indicating that it is in a shared (encrypted) state.
- the information of the flag that determines whether or not the claim is non-privacy information and is left in plain text without being shared by secret sharing is also retained.
- only one server 3 retains the plaintext content in the value, and in the other server 3, the value of the claim is "zeroed”. Will be done.
- the group synchronization unit 33 cooperates with the group synchronization unit 23 of the client 2, and for the VC241 grouped by the grouping unit 323, the issued lending group ID, the lending claim ID, and the corresponding claim (key, value, data type). Etc.) has a function of returning the information as lending information 35 to the client 2. It should be noted that the loan information 35 may further include credential information for subsequent authentication only at the time of the first return to the client 2.
- the lending information 35 returned to the client 2 of the user 4 does not include the privacy information of the user 4, but for example, when the IP address of the client 2 to be returned is the same every time, the lending information 35 does not include the privacy information itself. From there, there may be a risk that the four users will be identified. Therefore, for communication between the server 3 and the client 2, it is desirable to use a communication means such as Tor that can conceal the connection path.
- FIG. 11 is a diagram showing an outline of an example of a processing flow from the client 2 to the distribution of each share 26 to the server 3 and the verification by the server 3 in the embodiment of the present invention.
- the VC processing unit 21 acquires the VC241 from the data issued by the user 4 and stores it in the VC storage unit 24 (S01).
- the share providing unit 22 calculates n shares 26 (share 26_i (1 ⁇ i ⁇ n)) from the VC 241 stored in the VC storage unit 24 (S02), and adds these to a total of n servers 3 (S02).
- transmission is performed to the first server 3c (P 1 ) and the i-th (1 ⁇ i ⁇ n) server 3d (P i )), respectively (S03).
- server 3 is distributed to n servers (server 3c and server 3d), but as described above, the number of servers is larger than the secret sharing threshold k when the share 26 is calculated. If it is 3, the number may be less than n.
- the share acquisition unit 31 acquires this and temporarily stores it (S04). After that, the other servers 3 (that is, the server 3d (P i ) except the server 3 (this is referred to as the server 3c (P 1 )) that holds the plaintext when the format portion F is pseudo-shared by the above-mentioned method). In (1 ⁇ i ⁇ n)), the format portion F is “zeroed” by the above-mentioned method (S05).
- the verification processing unit 32 performs MPC between each server 3 (server 3c and server 3d) to perform the following three types of verification processing in steps S06 to S08.
- the order in which the three types of verification processing are performed is not particularly limited, and the order shown in FIG. 11 is an example. Further, the verification process of steps S06 and S07 can be combined with one verification process.
- the issuer verification unit 321 verifies that the issuer of the original VC241 data is the correct issuer by MPC (S06). Specifically, the public key is acquired from PKI or DPKI based on the value of the key "kid" in the header part of the JWS in the format portion F in advance, and the signature verification algorithm is specified from the value of the key "alg”. , This algorithm is agreed between each server 3 (P1 to Pn). Then, the integrity of the signature is verified based on VC_ $ i and Dsig_ $ i included in each share 26_i, and the result is confirmed by decoding the share of the verification result.
- the inclusion verification unit 322 verifies by MPC that the share of the privacy information contained in VC_ $ i is a share in which the data contained in the original VC241 is secretly distributed (S07). Specifically, for example, as described above, VC_ $ i and D_ $ i included in each share 26_i are equivalently verified by MPC, and the share of the verification result is decoded to confirm the result.
- the grouping unit 323 groups the VC241 with the same ID information included in each share 26_i (S08). Specifically, for example, the share of the ID information SUB_WA in the VC241 relating to the share 26_i and the share of the ID information SUB_WA in the other VC241 are verified for equivalence, and if they are all the same value, the grouping is successful. A group ID is issued to VC241. If there is even one VC241 that does not have the same value, it may be grouped only by the VC241 having the same value. When the group ID is issued, the claim ID is further assigned to each of the values included in the VC241 related to the share 26_i.
- step S09 it is determined whether or not there is no problem in all the results of the above-mentioned three types of verification processing (all the verification results are true (Accept)) (S09), and there is even one problem (one or more in the verification result). If there is a false (Reject)), a predetermined exception handling is performed (S10). On the other hand, if there is no problem in all the verification results in step S09, the group synchronization unit 33 shares the issued group ID and claim ID and the corresponding claim (key, shared value, data type, etc.) in the share storage unit 34. These are stored in the lending information 35 (S11) and returned to the client 2 (S12). The client 2 that has received the loan information 35 acquires it by the group synchronization unit 23 and records it in the ID storage unit 25 (S13).
- the lending group ID assigned to the data and the lending claim ID were communicated between the servers participating in the MPC and issued for the same data so that there would be no inconsistency. You may agree on the equivalence of the lending group ID and the lending claim ID, or the numbering method.
- the lending group ID and the lending claim ID may be numbered differently for each server 3. In this case, for example, in the client 2, the lending group ID and the lending claim ID shown in FIG. 8 are stored for each server 3, and the set of shares used for restoration (Reconstruct) of each data (claim value) is made unique. ID is assigned separately.
- FIG. 12 is a diagram showing an outline of an example of a processing flow from the verification of the share 26 on the server 3 in the embodiment of the present invention to the provision of the personalized service.
- the group synchronization unit 33 performs calculation processing by the MPC based on the information of the claim associated with the lending group ID stored in the share storage unit 34 (Pi (1 ⁇ i ⁇ n)). S21). After that, a lending claim ID is issued to the output result (share) of the calculation, the same lending group ID as the claim used as the input value of the calculation is associated with the calculation result, and this calculation result is used as claim information in the share storage unit 34. Record (S22).
- This claim information includes the issued loan claim ID, key information indicating the meaning of the calculation result, the share of the calculation result (share of the value), the data type of the calculation result, and the like.
- step S21 The calculation process in step S21 is analyzed after internally converting the secret sharing method to a different calculation method in the server 3, for example, as described later, in consideration of the load and efficiency of the calculation process of the MPC. However, the processing efficiency may be improved by secretly sharing the result again.
- the client 2 requests the calculation result by transmitting the information of the lending group ID corresponding to the VC241 provided for receiving the personalized service to each server 3 (Pi (1 ⁇ i ⁇ n)) (Pi (1 ⁇ i ⁇ n)). S31).
- the information of the claims grouped by the lending group ID (including the calculation result in step S21 described above) is extracted from the share storage unit 34, and this is extracted from the client.
- Respond to 2 (S32).
- the client 2 is associated with the lending group ID by decoding by the secret sharing method based on the share of the value in the claim information returned from each server 3 (Pi (1 ⁇ i ⁇ n)).
- the calculation result based on the claim data is acquired (S33). That is, the personalized service can be delivered.
- the calculation result (“advertisement for beer” or “advertisement for orange juice”) is still in the form of share, and its contents cannot be grasped, but on the client 2 of the user 4, the client 2 has.
- the personalized advertisement related to the calculation result can be received.
- the processing by the MPC is performed on the server 3 side via the group ID, not only the content of the calculation result cannot be known, but also the user 4 who provided the VC241 cannot be specified. This makes it possible to provide a personalized service unique to the user 4 while firmly protecting the privacy information.
- the secret sharing method may be internally converted to a different calculation method on the server 3 side to improve the processing efficiency.
- the share 26 of the VC241 acquired by each server 3 is converted into a so-called homomorphic encryption by the MPC, calculated, and the obtained calculation result is secretly shared again, and the share is converted into the homomorphic encryption by the MPC.
- the share of the decrypted result may be obtained (the processing performance may be improved depending on the environment and conditions).
- the share 26 acquired by each server 3 is calculated after being decoded in TA (Trusted Application) operating on the hardware-based TEE, and the calculation result is secretly distributed again to generate the share. May be output. However, especially in the latter case, the security for privacy protection may be reduced.
- TA Trusted Application
- the present invention is not limited to the above embodiment and can be variously modified without departing from the gist thereof. Needless to say. Further, the above-described embodiment has been described in detail in order to explain the present invention in an easy-to-understand manner, and is not necessarily limited to the one including all the described configurations. Further, it is possible to add / delete / replace a part of the configuration of the above embodiment with another configuration.
- each of the above configurations, functions, processing units, processing means, etc. may be realized by hardware by designing a part or all of them by, for example, an integrated circuit. Further, each of the above configurations, functions, and the like may be realized by software by the processor interpreting and executing a program that realizes each function. Information such as programs, tables, and files that realize each function can be placed in a recording device such as a memory, a hard disk, or an SSD, or a recording medium such as an IC card, an SD card, or a DVD.
- a recording device such as a memory, a hard disk, or an SSD, or a recording medium such as an IC card, an SD card, or a DVD.
- control lines and information lines are shown as necessary for explanation, and do not necessarily show all the control lines and information lines in the implementation. In practice, it can be considered that almost all configurations are interconnected.
- the present invention can be used in a service providing system that provides a personalized service without specifying the user himself / herself.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Storage Device Security (AREA)
Abstract
Description
本発明の一実施の形態であるサービス提供システムは、サービスの利用者が、自身に関連するデータをサービスプロバイダに提供し、これに基づいてサービスプロバイダがパーソナライズされたサービスを提供するという仕組みを実現するものである。本実施の形態では、その際に利用者が提供するデータは、利用者本人のものであるとして検証可能なデータ(Verifiable Credentials、以下では「VC」と記載する場合がある)とする。これにより、当該利用者に提供することが許された固有のサービスを提供するよう制限することを可能とする。また、サービスプロバイダでは、提供されたデータから利用者本人を特定することができない(利用者本人の特定が不要である)ようにすることで、利用者のプライバシー保護を実現する。
(Issuer)が発行したデータであることを証明する手段として
デジタル署名が付与されていること
2.データにはID(アイデンティティ)を示す情報(例えば、WAや
マイナンバー、パスポート番号等)が含まれること
3.発行されたデータは、配列、連想配列、JSON、YAML、
TOMLなどの構造化されたデータ、または構造化されたデータの
集合であり、フォーマットと要素が分離されても、各要素に割り当て
る配列番号または属性のようなメタ情報が与えられれば、復元可能で
あること
4.構造化されたデータにおいてID(アイデンティティ)情報の格納
場所を一意に定めることができること
5.データにはデジタル署名のアルゴリズムと、公開鍵の入手方法が一意
に定まる情報が含まれていること
6.デジタル署名は構造化されたデータ、または構造化されたデータの
集合の全体に対して一度に行われていること
なお(x1||x2||…||xj)の結合部分(||)に用いる値や構造は任意である。
図5は、本発明の一実施の形態における秘密分散法の適用の例について概要を示した図である。秘密分散法によりシェア化される前の平文(本実施の形態では例えばJWSのヘッダー部とペイロード部がドット(.)で文字列連結されたものであり、Base64URLでエンコードされている場合は、事前にデコードする)のVC241は、データDと、これに対するデジタル署名(JWSの署名部で、Base64URLでエンコードされている場合は、事前にデコードする)であるDsigからなる。ここで、データDは、そのフォーマット部分Fと、ID情報SUB_WA、およびm個の属性情報(本実施の形態では例えばJWT(JSON Web Token))におけるクレーム(キーとバリューの対))C1~Cmからなる。
S = Reconstruct(S,S’,S’,…,S’)
すなわち、“ゼロ値化”されたS’とは、Sが1つだけで、他が全てS’であるシェアに基づいて復号(Reconstruct)した場合にその結果がSになるというデータであり、この要件を満たすもの(すなわち、復号の際に影響を与えないもの)であれば、S’はどのような値でもよい。加法的秘密分散法では、S’は、例えばSと同サイズの“0”とすることができる。
S’=Zero(S)
を実施してSをS’に置換することで、1番目のP1が保持するSと、各Pi(1<i≦n)が保持するS’とにより、
Reconstruct(S,S’,S’,…,S’) = S
となって、復号によりSを得ることができる。すなわち、SとS’(ゼロ値)を、Sの疑似的なシェアとして取り扱うことができる。
Zero(1234) = 0000
のように、Reconstruct関数における単位元に置き換わる。したがって、全てのサーバが保持するシェアのうち、1つのシェアのみ「1234」で、他の全てのサーバが保持するシェアが「0000」であるシェアに基づいて復号したときに、
1234+0000+0000+…+0000 = 1234
もしくは、
1234@0000@0000@…@0000 = 1234
(“@”は排他的論理和を表す)
となり、元の平文「1234」を得ることができる。
S’= S-(R2+R3+…+Rn)
あるいは、
S’= S@R2@R3@…@Rn
とすると、
Reconstruct(S’,R2,R3,…,Rn) = S
となってSを復元することができる。すなわち、S’とRi(1<i≦n)を、Sの疑似的なシェアとすることができる。
VC_$1
= Replace(F,SUB_WA_$i,
C1_$i,…,Cm_$i)
Pi(1<i≦n)においては、
VC_$i
= Replace(F’,SUB_WA_$i,
C1_$i,…,Cm_$i)
このように各シェア26は、フォーマット部分F(平文)と、各クレームC1~Cmのシェアが分離できる構成を有している。これにより、サーバ側でのMPCの際に、各シェア26に含まれるフォーマット部分Fをシェアと取り扱ったとしても、“ゼロ値化”されているフォーマット部分F’については、上述したとおりReconstruct関数の結果に影響を与えないことから、全シェアのうち1つだけあるフォーマット部分Fの平文を実際に含んでいるシェア26の内容に基づいて、MPCを行なうことができる。
図1は、本発明の一実施の形態であるサービス提供システムの構成例について概要を示した図である。サービス提供システム1は、例えば、利用者4が保有するクライアント2と複数のサーバ3が図示しないインターネット等のネットワークを介して相互に通信可能な構成を有する。クライアント2は、主に利用者4についてのVC241の情報を保持して管理する機能を有する装置(第1の装置)であり、例えば、PC(Personal Computer)やタブレット型端末、スマートフォンなどの情報処理端末その他の装置により実装される。
クライアント2は、例えば、図示しないCPU(Central Processing Unit)により、HDD(Hard Disk Drive)やSSD(Solid State Drive)等の記録装置からメモリ上に展開したOS(Operating System)やDBMS(Database Management System)等のミドルウェアや、その上で稼働するWebブラウザやアプリケーションプログラム等のソフトウェアを実行することで、上述したクライアント2の各種機能を実現する。クライアント2は、例えば、ソフトウェアにより実装されたVC処理部21 、シェア提供部22、およびグループ同期部23などの各部を有する。また、データベースやファイル等により実装されたVC保管部24およびID保管部25などの各データストアを有する。
図1に戻り、サーバ3は、例えば、図示しないCPUにより、HDDやSSD等の記録装置からメモリ上に展開したOSやDBMS等のミドルウェアや、その上で稼働するソフトウェアを実行することで、上述したサーバ3の各種機能を実現する。サーバ3は、例えば、ソフトウェアにより実装されたシェア取得部31、検証処理部32、およびグループ同期部33などの各部を有する。また、データベースやファイル等により実装されたシェア保管部34などのデータストアを有する。
{Accept,Reject}
← Reconstruct([v])
なお、[]内の値は、秘密分散されたシェアを略式的に表している。例えば、任意の値Xに関して、
である。すなわち、
VC = Reconstruct([VC])
= Reconstruct(VC_$1,VC_$2,
…,VC_$n)
である。VerifyMPC関数は、MPCによるデジタル署名の完全性検証アルゴリズムを表す。またvは、pk、Dsig、VCにより、キー“alg”のバリューにより定められるデジタル署名の完全性検証アルゴリズムによって検証した結果を表す。
[subq])
{Accept,Reject}
← Reconstruct([eq])
なお、eqは1<q≦pの範囲内のq番目のVC241に含まれたSUB_WAと、REP_SUB_WAとを等価検証した結果を表す。またEqualMPC関数はMPCによる等価検証を表す。全てのVC241のID情報が同一の値であれば(1<q≦pにおいて、すべてのReconstruct([eq])がAcceptを返せば)グループ化成功とする。
図11は、本発明の一実施の形態におけるクライアント2から各シェア26がサーバ3に配布されてサーバ3で検証が行われるまでの処理の流れの例について概要を示した図である。まず、クライアント2では、VC処理部21により、利用者4が発行者から発行を受けたデータからVC241を取得して、VC保管部24に保管する(S01)。その後、シェア提供部22により、VC保管部24に保管されたVC241からn個のシェア26(シェア26_i(1≦i≦n))を計算し(S02)、これらを合計n個のサーバ3(図中の例では1番目のサーバ3c(P1)およびi番目(1<i≦n)のサーバ3d(Pi))にそれぞれ送信する(S03)。なお、図中の例ではn個のサーバ3(サーバ3cおよびサーバ3d)に配布するものとしているが、上述したように、シェア26を算出した際の秘密分散の閾値kよりも多い数のサーバ3であれば、n個に満たない数でもよい。
以上に示したような構成において、例えば、ユースケースとして、サービスプロバイダが、「年齢が20歳以上の利用者にはお酒の広告、20歳未満の利用者にはジュースの広告」を提供したいという場合を想定する。利用者4が、VC241として年齢の情報を提供していて、サーバ3においてこれに対するグループIDが発行されている状態で、サーバ3側では、
if(年齢>=20)
“ビールの広告”
else
“オレンジジュースの広告”
というような処理(MPC)を“年齢”のデータを含んだグループに対して実行する。計算結果に対し、計算を適用したグループのグループIDを紐づける。
21…VC処理部、22…シェア提供部、23…グループ同期部、24、24a、24b…VC保管部、25…ID保管部、26、26_1~26_n…シェア、
31…シェア取得部、32…検証処理部、33…検証処理部、34、34a、34b…シェア保管部、35…貸出情報、
211a~211d…ウォレット、241…VC、
321…発行者検証部、322…包含検証部、323…グルーピング部
Claims (4)
- 利用者の第1の装置に対して、1つ以上の第2の装置によりネットワークを介してサービスを提供するサービス提供システムであって、
前記第1の装置は、
前記利用者のものであるとして検証可能なデータVCを保管するVC保管部から前記VCを取得して秘密分散法により複数個のシェアに分割し、前記各シェアを前記第2の装置に配布するシェア提供部と、
前記第2の装置から返却された1つ以上の前記VCに係るグループIDの情報を取得してID保管部に保管し、前記グループIDに基づいて、前記第2の装置における前記サービスに係る所定の秘密計算の結果を、秘密分散法により復号して取得する第1のグループ同期部を、を有し、
前記第2の装置は、
前記第1の装置から配布された前記シェアを取得するシェア取得部と、
取得した前記シェアにつき、当該シェアに係る前記VCに含まれるID情報の値が等しいものをグループ化して前記グループIDを発行し、前記グループIDと当該シェアに係る情報をシェア保管部に保管する検証処理部と、
前記グループIDを含む情報を前記第1の装置に返却する第2のグループ同期部と、を有する、サービス提供システム。 - 請求項1に記載のサービス提供システムにおいて、
前記第1の装置の前記シェア提供部は、前記VCにおけるプライベート情報と非プライベート情報とを分離し、前記非プライベート情報は平文とした状態で秘密分散法により前記シェアに分割する、サービス提供システム。 - 請求項2に記載のサービス提供システムにおいて、
前記第1の装置の前記シェア提供部は、秘密分散法により前記VCを複数の前記シェアに分割する際に、所定の1つの前記シェアに前記非プライベート情報を設定し、他の前記シェアについては、秘密分散法により前記VCを復号する際に影響を与えないデータで埋める、サービス提供システム。 - 請求項2に記載のサービス提供システムにおいて、
前記非プライベート情報は、前記VCにおけるフォーマット情報を含み、
前記第2の装置の前記検証処理部は、前記第1の装置から配布された前記シェアにつき、当該シェアに含まれる前記プライベート情報が、当該シェアに含まれる前記フォーマット情報に規定された要素に係るデータであることを検証する、サービス提供システム。
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202080107835.0A CN116830181A (zh) | 2020-12-11 | 2020-12-11 | 服务提供系统 |
JP2022568031A JP7500771B2 (ja) | 2020-12-11 | 2020-12-11 | サービス提供システム |
US18/039,011 US20230370252A1 (en) | 2020-12-11 | 2020-12-11 | Service provision system |
PCT/JP2020/046433 WO2022123795A1 (ja) | 2020-12-11 | 2020-12-11 | サービス提供システム |
EP20965176.9A EP4261809A1 (en) | 2020-12-11 | 2020-12-11 | Service provision system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2020/046433 WO2022123795A1 (ja) | 2020-12-11 | 2020-12-11 | サービス提供システム |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2022123795A1 true WO2022123795A1 (ja) | 2022-06-16 |
Family
ID=81974329
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2020/046433 WO2022123795A1 (ja) | 2020-12-11 | 2020-12-11 | サービス提供システム |
Country Status (5)
Country | Link |
---|---|
US (1) | US20230370252A1 (ja) |
EP (1) | EP4261809A1 (ja) |
JP (1) | JP7500771B2 (ja) |
CN (1) | CN116830181A (ja) |
WO (1) | WO2022123795A1 (ja) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11930074B2 (en) * | 2021-10-26 | 2024-03-12 | King Fahd University Of Petroleum And Minerals | Content distribution over a network |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011248711A (ja) * | 2010-05-28 | 2011-12-08 | Nomura Research Institute Ltd | 秘密分散によるデータ管理システム |
JP2015532737A (ja) | 2012-07-16 | 2015-11-12 | アルカテル−ルーセント | ユーザ関心プロファイルのプライバシ保護されたクラスタ化のシステムおよび方法 |
-
2020
- 2020-12-11 US US18/039,011 patent/US20230370252A1/en active Pending
- 2020-12-11 EP EP20965176.9A patent/EP4261809A1/en active Pending
- 2020-12-11 WO PCT/JP2020/046433 patent/WO2022123795A1/ja active Application Filing
- 2020-12-11 CN CN202080107835.0A patent/CN116830181A/zh active Pending
- 2020-12-11 JP JP2022568031A patent/JP7500771B2/ja active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011248711A (ja) * | 2010-05-28 | 2011-12-08 | Nomura Research Institute Ltd | 秘密分散によるデータ管理システム |
JP2015532737A (ja) | 2012-07-16 | 2015-11-12 | アルカテル−ルーセント | ユーザ関心プロファイルのプライバシ保護されたクラスタ化のシステムおよび方法 |
Non-Patent Citations (1)
Title |
---|
OHIGASHI TOSHIHIRO, GOTO MEGUMI, NISHIMURA KOUJI, AIBARA REIJI: "Implementation and Evaluation of a File Sharing Service with File Name Encryption Using Ciphertex-policy Attribute-based Encryption", TRANSACTIONS OF INFORMATION PROCESSING SOCIETY OF JAPAN (IPSJ), vol. 55, no. 3, 1 February 2014 (2014-02-01), JP , pages 1126 - 1139, XP055948810, ISSN: 1882-7764 * |
Also Published As
Publication number | Publication date |
---|---|
JP7500771B2 (ja) | 2024-06-17 |
EP4261809A1 (en) | 2023-10-18 |
CN116830181A (zh) | 2023-09-29 |
JPWO2022123795A1 (ja) | 2022-06-16 |
US20230370252A1 (en) | 2023-11-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11652608B2 (en) | System and method to protect sensitive information via distributed trust | |
EP2494486B1 (en) | System for protecting an encrypted information unit | |
Yu et al. | Remote data possession checking with enhanced security for cloud storage | |
JP2014002365A (ja) | プライバシーを保護することができる暗号化データの問い合わせ方法及びシステム | |
Hahn et al. | Enabling fast public auditing and data dynamics in cloud services | |
US20220020020A1 (en) | Methods, systems, and devices for managing digital assets | |
CN116830523A (zh) | 阈值密钥交换 | |
CN113569298A (zh) | 一种基于区块链的身份生成方法及身份系统 | |
CN116108410A (zh) | 一种身份凭证生成方法及装置 | |
Sreelatha et al. | Integrity and memory consumption aware electronic health record handling in cloud | |
JP2013150026A (ja) | データ処理システム及び秘匿化装置及び秘密鍵生成装置及び秘匿化方法及び秘密鍵生成方法及びプログラム | |
WO2022123795A1 (ja) | サービス提供システム | |
CN109858283B (zh) | 一种基于Chaum-Pedersen的云存储安全数据共享方法 | |
CN114510734B (zh) | 数据访问控制方法、装置及计算机可读存储介质 | |
Murthy | Cryptographic secure cloud storage model with anonymous authentication and automatic file recovery | |
US11886617B1 (en) | Protecting membership and data in a secure multi-party computation and/or communication | |
US11989325B1 (en) | Protecting membership in a secure multi-party computation and/or communication | |
US20210250337A1 (en) | Method and device for matching evaluation of structured data sets protected by encryption | |
WO2024014017A1 (ja) | メッセージ提示システム、提示用装置、及びメッセージ提示方法 | |
Bindu et al. | Provable Multicopy Dynamic Data Possession in Cloud Computing Systems | |
USHARANI et al. | Enabling Cloud Storage Auditing with Key-Exposure Resistance | |
AZEEMULLAH et al. | Auditing to Stay Online Storage Space Military Frank | |
RAHEEMAN et al. | Dynamic Behaviour of Data for Various Applications in Cloud Storage | |
ANITHA et al. | An Efficient Blowfish Ciphering Based Provable Multicopy Dynamic Data Possession in Cloud Computing Systems | |
KALPANA et al. | Verifiable Multireplica Forceful Data Ownership in Cloud Computing Systems |
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: 20965176 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2022568031 Country of ref document: JP Kind code of ref document: A |
|
WWE | Wipo information: entry into national phase |
Ref document number: 202327038833 Country of ref document: IN |
|
WWE | Wipo information: entry into national phase |
Ref document number: 202080107835.0 Country of ref document: CN |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
ENP | Entry into the national phase |
Ref document number: 2020965176 Country of ref document: EP Effective date: 20230711 |