WO2022123795A1 - サービス提供システム - Google Patents

サービス提供システム Download PDF

Info

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
Application number
PCT/JP2020/046433
Other languages
English (en)
French (fr)
Inventor
将司 川口
Original Assignee
株式会社野村総合研究所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社野村総合研究所 filed Critical 株式会社野村総合研究所
Priority to CN202080107835.0A priority Critical patent/CN116830181A/zh
Priority to JP2022568031A priority patent/JP7500771B2/ja
Priority to US18/039,011 priority patent/US20230370252A1/en
Priority to PCT/JP2020/046433 priority patent/WO2022123795A1/ja
Priority to EP20965176.9A priority patent/EP4261809A1/en
Publication of WO2022123795A1 publication Critical patent/WO2022123795A1/ja

Links

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、以下では「ＶＣ」と記載する場合がある）とする。これにより、当該利用者に提供することが許された固有のサービスを提供するよう制限することを可能とする。また、サービスプロバイダでは、提供されたデータから利用者本人を特定することができない（利用者本人の特定が不要である）ようにすることで、利用者のプライバシー保護を実現する。
　利用者から提供されたデータに基づいてサービスプロバイダが利用者本人を特定できないようにプライバシーを保護する仕組みとして、本実施の形態では、いわゆる秘密計算の技術を利用する。秘密計算とは、計算対象のデータを暗号化した状態のままで計算して計算結果を得る技術であり、計算対象のデータや計算過程を秘匿することを可能とするものである。
　本実施の形態では、秘密計算の手法としてマルチパーティ計算（Multi-Party Computation、以下では「ＭＰＣ」と記載する場合がある）を用いるものとする。すなわち、利用者のデータを秘密分散法により複数のシェアに分割して異なるサーバに隔離した状態で配置するとともに、サーバ側では、サーバ間で通信を行いながら、データの秘匿性を維持したままの状態で加算・乗算等の計算を行なって計算結果を得る。
　Functional Completenessを備えるＭＰＣは、任意の関数・アルゴリズムを、データを秘匿したまま計算できる。この計算結果もまた秘密分散された状態であることから、ＭＰＣに参加するパーティが互いに、あるいは外部にシェアを提供して復号（Ｒｅｃｏｎｓｔｒｕｃｔ）を許さない限り、復号（Ｒｅｃｏｎｓｔｒｕｃｔ）は、各シェアを集めることが許される人、すなわちデータを提供した利用者本人しかできず、サーバ側では提供されたデータも計算結果も覗き見ることはできない。計算結果が意図されないパーティにより復号（Ｒｅｃｏｎｓｔｒｕｃｔ）されない限り、秘匿された状態を保つことができるため、いわゆる出力プライバシーが問題化することを防ぐことができる。
　これにより、サービスプロバイダにおいて利用者が提供したデータの内容を知ることはもちろん、利用者本人を特定することもなく、利用者本人に対して計算結果（もしくはこれに基づいてパーソナライズされたサービス）を提供することができる。なお、秘密分散法としては、例えば、（ｋ，ｎ）閾値の加法的秘密分散法（ｎ≧ｋ≧２）を用いることができる。
　一方、利用者が提供するデータを検証可能なＶＣとして取り扱うため、各データにはＩＤ（アイデンティティ）を示す情報が関連付けられる。このＩＤの管理基盤として、いわゆる中央集権型ＩＤを用いることもできるが、本実施の形態では、ブロックチェーンと分散台帳の技術を利用した分散型ＩＤ（Decentralized Identity、以下では「ＤＩＤ」と記載する場合がある）の仕組みを用いるものとする。ＤＩＤの仕様については現在標準化が進められているが、各データには利用者本人のＩＤ情報としてブロックチェーンにおけるウォレットアドレス（Wallet Address、以下では「ＷＡ」と記載する場合がある。なお、ウォレットアドレスにはＤＩＤを提供するネットワークやプロトコル等を一意にするメタ情報が付与される場合もある）が関連付けられる。
　なお、ＤＩＤで取り扱うデータの形式は、ＶＣが採り得る全ての形式（データモデルの定義については以下のＷ３Ｃ勧告を参照。https://www.w3.org/TR/vc-data-model/#:~:text=Data%20derived%20from%20one%20or,a%20process%20of%20cryptographic%20verification.）であり、配列あるいは連想配列（Ｍａｐ形式）で表現できるデータ型であればよい。例えば、ＪＳＯＮ（JavaScript Object Notation）、ＹＡＭＬ、ＣＢＯＲ（Concise Binary Object Representation）、ＴＯＭＬなどを用いることができるが、本実施の形態では、特に断らない限りＪＳＯＮ（ＪＳＯＮ－ＬＤ）を用いるものとして説明する。
　ＤＩＤの仕組みを用いることにより、利用者本人の意思で任意の相手に対して身元証明を実施することができる。本実施の形態では、身元証明だけではなく、利用者本人の意思に基づき、任意の相手にデータ収集・活用の許可を与える意思表示の手段としても、ＤＩＤの仕組みを用いる。
　なお、本実施の形態では、データをＶＣとして取り扱う形態を実現する方法の一例としてＤＩＤを用いている。そのため署名が付与されたデータを、ＤＩＤの用語に合わせて「ＶＣ」と表現しているが、本実施の形態を再現する手段はＤＩＤを用いるものに限られないため、ＤＩＤの仕様で定義されるＶＣとは異なるデータ形式においても用いることが可能である。ＤＩＤにおけるＶＣに相当するデータが、以下の条件を全て満たすデータであれば、適宜用いることができる。
　１．データの発行を担う発行者（Ｉｓｓｕｅｒ）が存在し、その発行者
　　　（Ｉｓｓｕｅｒ）が発行したデータであることを証明する手段として
　　　デジタル署名が付与されていること
　２．データにはＩＤ（アイデンティティ）を示す情報（例えば、ＷＡや
　　　マイナンバー、パスポート番号等）が含まれること
　３．発行されたデータは、配列、連想配列、ＪＳＯＮ、ＹＡＭＬ、
　　　ＴＯＭＬなどの構造化されたデータ、または構造化されたデータの
　　　集合であり、フォーマットと要素が分離されても、各要素に割り当て
　　　る配列番号または属性のようなメタ情報が与えられれば、復元可能で
　　　あること
　４．構造化されたデータにおいてＩＤ（アイデンティティ）情報の格納
　　　場所を一意に定めることができること
　５．データにはデジタル署名のアルゴリズムと、公開鍵の入手方法が一意
　　　に定まる情報が含まれていること
　６．デジタル署名は構造化されたデータ、または構造化されたデータの
　　　集合の全体に対して一度に行われていること
　上記の条件３を満たす例としては、例えば、［ａ，ｂ，ｃ］というデータについて、（０，ａ）、（１，ｂ）、（２，ｃ）というように、配列番号と要素との対応が一意であれば、その情報から元の［ａ，ｂ，ｃ］というデータを復元することが可能である。同様に、例えば、｛“ｎａｍｅ”：“ａｌｉｃｅ”，“ａｇｅ”：４２｝というデータは、（“ｎａｍｅ”，“ａｌｉｃｅ”）と（“ａｇｅ”，４２）から復元することが可能である。［［ａ，ｂ，ｃ］，［ｄ，ｅ］，［ｆ］］のように入れ子になっているデータであっても同様であり、（０，０，ａ）、（０，１，ｂ）、（０，２，ｃ）、（１，０，ｄ）、（１，１，ｅ）、（２，０，ｆ）というように配列番号（上位の配列と下位の配列）と要素との対応（マッピング）が一意にできれば元のデータを復元することが可能である。
　上記の条件４を満たす例として、例えば、配列であれば「ゼロ番目の要素がアイデンティティである」、ＤＩＤであれば「ｓｕｂ属性の値がアイデンティティ（特にＷＡ）である」という決まりがある（もしくは決まりを設ける）ことで、ＩＤ情報の格納場所を一意に特定することができる。
　上記の条件６を満たす方法として、構造化されたデータの集合を｛ｘ１，ｘ２，…，ｘｊ｝（ｊは要素の個数）としたとき、署名σは、秘密鍵ｓｋ、構造化されたデータの集合を結合した（ｘ１||ｘ２||…||ｘｊ）を入力値として、署名アルゴリズムＳｉｇｎにより求められなければならない。
　　σ＝Ｓｉｇｎ（ｓｋ，（ｘ１||ｘ２||…||ｘｊ））
なお（ｘ１||ｘ２||…||ｘｊ）の結合部分（||）に用いる値や構造は任意である。
　その結果、署名σ、公開鍵ｐｋ、｛ｘ１，ｘ２，…，ｘｊ｝を入力値とした検証アルゴリズムＶｅｒｉｆｙ（ｐｋ，σ，（ｘ１||ｘ２||…||ｘｊ））の結果が、Ａｃｃｅｐｔを返すことが求められる。ＪＷＳ（JSON Web Signature）を例に挙げると、構造化されたデータの集合はヘッダー部とペイロード部を含み、ヘッダー部（Ｈｅａｄｅｒ）とペイロード部（Ｐａｙｌｏａｄ）とをドット（.）で結合した値を入力値として、署名部（Ｓｉｇｎａｔｕｒｅ）を求めている。
　図２は、本発明の一実施の形態における仕組みの例について概要を説明した図である。利用者４のクライアント２は、ＶＣ２４１を有しているが、このＶＣ２４１は、例えば、街中にあるビデオカメラ等のデータ収集設備６が取得したデータ（この場合はカメラ映像だが、決済サービスの購買履歴等、異なる設備・サービスが収集したデータも該当しうる）を含んでおり、ＰＫＩ（Public Key Infrastructure、公開鍵基盤）、もしくはＤＰＫＩ（Decentralized PKI、分散型公開鍵基盤）５に登録（図中の［１］）した公開鍵の対となる秘密鍵によるデジタル署名を付与して発行（図中の［２］）したものである。このＶＣ２４１は、上述したように、本実施の形態ではＪＳＯＮにより表され、ＩＤ情報としてＤＩＤのＷＡが含まれる。利用者４のクライアント２は、ＶＣ２４１のデジタル署名を、ＤＰＫＩ５に登録した公開鍵により検証（図中の［３］）することで、発行者（データ収集設備６）を認証する。
　本実施の形態では、利用者４は、このＶＣ２４１をサービスプロバイダに提供することに同意（図中の［４］）した上で、利用者４のクライアント２は、ＶＣ２４１を秘密分散することで得られたシェア２６ａ、シェア２６ｂをそれぞれＭＰＣに参加するサーバＡ（３ａ）、サーバＢ（３ｂ）に提供（図中の［５］）する。図２の例ではＶＣ２４１を２つのシェアに秘密分散し、２つのサーバに提供するものとしているが、２つ以上のシェアに秘密分散する、すなわち（ｋ，ｎ）閾値秘密分散法（ｎ≧ｋ≧２）に基づく秘密分散をして、それぞれのシェアを異なるサーバに提供するものであってもよい。
　サービスプロバイダにおいて、これらのシェア２６ａ、シェア２６ｂ（暗号文）と、ＤＰＫＩ５に登録した公開鍵（平文）を入力値として、サーバＡ（３ａ）とサーバＢ（３ｂ）によるＭＰＣを通して検証（図中の［６］）を行なう。利用（図中の［７］）する際にも、サーバＡ（３ａ）とサーバＢ（３ｂ）においてＭＰＣを行うことにより、元のＶＣ２４１の内容を得ることなく計算結果を得て、これに基づいてパーソナライズされたサービスを提供する。
　一方で、サービスプロバイダ側で元のＶＣ２４１や計算結果の内容を知ることができなくても、どの利用者４のデータであるかが分かる、すなわち本人の特定ができる場合には、プライバシーが完全に保護されているとは言えない。そこで本実施の形態では、サービスプロバイダ側に提供した１つ以上のＶＣ２４１について、内容が暗号化された状態のまま、（１）内容が改ざんされていないこと、（２）いずれのＶＣ２４１も同一の利用者４に関連付けられること、を確認した上で、サービスプロバイダ側に提供した各ＶＣ２４１をグループ化してグループＩＤを付与し、このグループＩＤを利用者４に返却する。これにより、サービスプロバイダ側にはどの利用者４のデータであるかを秘匿しつつ、利用者４は返却されたグループＩＤに基づいてパーソナライズサービスを要求し、その提供を受けることができる。
　なお、サービスプロバイダ側でのＭＰＣの処理では、外部の信頼された環境に計算を委託し、計算結果をサーバＡ（３ａ）とサーバＢ（３ｂ）へ秘密分散させた形で返してもらう、もしくは委託先にグループＩＤを渡して計算結果の配信を代理してもらうことも可能である。例えば、計算をＭＰＣで実施するのに代えて、ＴＥＥ内のＴＡ（Trusted Application）に復号（Ｒｅｃｏｎｓｔｒｕｃｔ）を許すことで、ＭＰＣ以外の手段により計算を実施し、その計算結果を改めてサーバＡ（３ａ）とサーバＢ（３ｂ）へ秘密分散する（同時に、委託先に預けた情報をすべて委託先の環境から削除してもよい）。これにより安全性と性能のトレードオフが可能となる。
　図３は、本発明の一実施の形態におけるパーソナライズサービスを提供する仕組みの例について概要を示した図である。図の例では、利用者４ａのウォレット２１１ａには「データ１」、「データ２」、「データ３」のＶＣが保持されており、利用者４ｂのウォレット２１１ｂには「データ４」、「データ５」のＶＣが保持されている状態を示している。
　そして、利用者４ａが、あるサービスの提供を受けるために「データ１」と「データ２」を提供したのに対し、サービスプロバイダ（サーバ）側ではこれらのデータに「グループ１」というグループＩＤを発行してグループ化したことを示している。同様に、利用者４ａが別のサービスの提供を受けるために「データ２」と「データ３」を提供したのに対し、これらのデータに「グループ２」というグループＩＤを発行してグループ化したことを示している。発行された「グループ１」と「グループ２」の各グループＩＤは、対象のデータの提供者である利用者４ａにそれぞれ返却される。同様に、利用者４ｂが「データ４」と「データ５」を提供したのに対し、これらのデータに「グループ３」というグループＩＤを発行してグループ化したことを示している。「グループ３」のグループＩＤは利用者４ｂに返却される。
　この場合、例えばサービスプロバイダ側のデータの管理者７（秘密分散法の復号に要求される閾値ｋ未満の数の環境に対するデータベースへのアクセス権限はある）がデータベースの内容を参照したとしても、いずれのデータも（秘密分散により）暗号化されているため、内容を把握することができない。さらに、いずれのデータも、利用者４ａや利用者４ｂ本人はおろか、各人のウォレット２１１ａやウォレット２１１ｂのＷＡに関連付けられていることも把握することができない。すなわち、管理者７（サービスプロバイダ）においてデータを提供した本人を特定することができない、という特定不可能性を実現することができる。
　一方で、管理者７にとって、例えば、「グループ１」に含まれる「データ１」と「データ２」が“同じ誰か”に関連付けられることは把握できる。すなわち、「グループ１」の“誰か”向けにサービスをパーソナライズするということが可能である。「グループ１」のグループＩＤを返却された利用者４ａは、「グループ１」のデータに基づいてパーソナライズされたサービスを要求するために、このグループＩＤを利用することができる。すなわち、「グループ１」の「データ１」と「データ２」に基づく計算結果についても、この計算結果に対してサービスプロバイダ（サーバ）側で「グループ１」のグループＩＤが紐づけられることにより、利用者４ａが「グループ１」のグループＩＤを利用して要求することが可能である。
　同様に、管理者７にとって、「グループ２」の「データ２」と「データ３」が、それぞれ“同じ誰か”に関連付けられることは把握できるため、「グループ２」の“誰か”向けにサービスをパーソナライズすることが可能である。「グループ１」と「グループ２」のグループＩＤを返却された利用者４ａは、「グループ１」に基づくサービスと、「グループ２」に基づくサービスの提供を個別に受けることが可能となる。なお、管理者７では、「グループ１」と「グループ２」が“同じ誰か”に関連付けられるということは把握できない。つまり同じ利用者４ａに紐づく「データ１」と「データ３」は、名寄せできない。「グループ３」についても同様であり、管理者７では「データ４」と「データ５」が“同じ誰か”に関連付けられることは把握できるため、「グループ３」の“誰か”向けにサービスをパーソナライズすることが可能である。
　図４は、本発明の一実施の形態におけるパーソナライズサービスを提供する仕組みの他の例について概要を示した図である。図の例では、利用者４ｃのウォレット２１１ｃには「データＣ１」、「データＣ２」が保持されており、利用者４ｄのウォレット２１１ｄには「データＤ１」、「データＤ２」が保持されている状態で、利用者４ｃが利用者４ｄのウォレット２１１ｄから「データＤ１」を不正に入手して自身のウォレット２１１ｃに追加した状態を示している。また、利用者４ｃが、あるサービスの提供を受けるために「データＣ１」と「データＣ２」を提供し、これらのデータがグループ化されて「グループ４」というグループＩＤが発行されたことを示している。
　ここで、仮に、利用者４ｃが、別のサービスの提供を受けるために「データＣ２」と「データＤ１」を提供し、これらのデータがグループ化されて「グループ５」というグループＩＤが発行されたとした場合、「グループ５」のように、他者のデータが同じグループの情報として取り扱われてしまうと、これらのデータに基づく計算結果は利用者４ｃの真の情報に基づかない不正なものとなり、提供されるサービスの内容が変質してしまうことになる。しかしながら、上述したように、データの管理者からは暗号化されたデータの内容を把握することができないため、同一のグループ（図４の例では「グループ５」）に属するものとして提供された各データが本当に同一の利用者（図４の例では利用者４ｃ）に関連付けられているものか否かを確認することができない。
　そこで本実施の形態では、利用者が提供するデータを、ＩＤ情報を含むＶＣとすることで、利用者本人のものであることを検証可能とするとともに、サービスプロバイダ（サーバ）側では、同一のグループに属するものとして提供された各データについて全て同一のＩＤ情報であるか否かを、ＭＰＣで検証した上で、全て同一のＩＤ情報であると確認できた場合にこれらのデータをグループ化するものとする。すなわち、図４の例では、「データＣ２」と「データＤ１」についてはグループ化されず、「グループ５」というグループＩＤは発行されないことになる（もしくは、「グループ５」というグループＩＤを“みなしグループＩＤ”として暫定的に発行した上で、後に全て同一のＩＤ情報であると確認できなかった場合に破棄するようにしてもよい）。これにより、あるグループに属するデータについては、全て同一の利用者のものであるとして取り扱うことができる。なお、サービスプロバイダ側では、同一のＩＤ情報を有するデータが“同じ誰か”のデータであるということは把握できても、“誰の”データであるかを把握することはできない。
　＜秘密分散＞
　図５は、本発明の一実施の形態における秘密分散法の適用の例について概要を示した図である。秘密分散法によりシェア化される前の平文（本実施の形態では例えばＪＷＳのヘッダー部とペイロード部がドット（.）で文字列連結されたものであり、Ｂａｓｅ６４ＵＲＬでエンコードされている場合は、事前にデコードする）のＶＣ２４１は、データＤと、これに対するデジタル署名（ＪＷＳの署名部で、Ｂａｓｅ６４ＵＲＬでエンコードされている場合は、事前にデコードする）であるＤｓｉｇからなる。ここで、データＤは、そのフォーマット部分Ｆと、ＩＤ情報ＳＵＢ＿ＷＡ、およびｍ個の属性情報（本実施の形態では例えばＪＷＴ（JSON Web Token））におけるクレーム（キーとバリューの対））Ｃ１～Ｃｍからなる。
　なお、フォーマット部分Ｆは、ＪＳＯＮにおけるフォーマット部分（特にペイロード部のクレームセット（Claims Set）から本実施の形態によりプライバシー保護対象となるバリューを除外した部分）であり、ＪＷＳにおけるペイロード部だけでなくヘッダー部も含むものである。また、ＳＵＢ＿ＷＡについては、上述したように、本実施の形態ではＤＩＤのＷＡ（ウォレットアドレス）とするが、各ＶＣ内のアイデンティティ情報と一致するものであれば、マイナンバーやパスポート番号、その他のアイデンティティ情報であってもよい。
　本実施の形態では、クレームセットにおけるフォーマット部分Ｆと、各クレームＣ１～ＣｍならびにＳＵＢ＿ＷＡがそれぞれが分離できる形で秘密分散する。これは、ＪＷＳであるＶＣ２４１に対してそのまま秘密分散を行ってシェアを生成すると、これを配布したサーバ側においてクレームセットのフォーマット部分Ｆとデータ（本実施の形態ではＳＵＢ＿ＷＡと、各クレームＣ１～Ｃｍのうちプライバシー保護対象となるバリュー）のシェア部分の見分けがつかなくなり、サーバ側でのＭＰＣによるデータの検証および活用に支障をきたす場合があるためである。分離以外の方法としては、例えば、特にクレームセットの暗号文のバイト列のうち、どこからどこまでがプライバシー情報の暗号文にあたるかという情報と、キーの情報を含んだメタ情報を付与することで、後から目的のプライバシー情報のシェアを取得できるようにする、という方法もある。
　なお、フォーマット部分Ｆについては、利用者４のプライバシー情報が含まれないことから、秘匿化が不要であるため、秘密分散によるシェア化をせずに、そのままの平文の状態でＭＰＣに参加するサーバへ配布する。この場合、各シェア２６を対象にしてサーバ側でＭＰＣを行なう際に、フォーマット部分Ｆをシェアとして扱ってＭＰＣの対象とすると、複数のシェアにおいてフォーマット部分Ｆの平文が含まれることから、正しく計算できないことになる。
　そこで、本実施の形態では、フォーマット部分Ｆを平文としておく一方で、このフォーマット部分Ｆに対してもＭＰＣが正しく行えるよう、以下に示す手法で擬似的にシェア化する。具体的には、例えば、フォーマット部分Ｆに実際の内容を全て含んでいるシェア２６を全てのサーバの中で１つのみとし、他のサーバのシェア２６についてはフォーマット部分Ｆの部分を“ゼロ値化”する。“ゼロ値化”とは、たとえば以下の要領で任意のデータＳをＳ’に変換するＺｅｒｏ関数による操作を指す。
　　　Ｓ’＝　Ｚｅｒｏ（Ｓ）
　　　Ｓ　＝　Ｒｅｃｏｎｓｔｒｕｃｔ（Ｓ，Ｓ’，Ｓ’，…，Ｓ’）
すなわち、“ゼロ値化”されたＳ’とは、Ｓが１つだけで、他が全てＳ’であるシェアに基づいて復号（Ｒｅｃｏｎｓｔｒｕｃｔ）した場合にその結果がＳになるというデータであり、この要件を満たすもの（すなわち、復号の際に影響を与えないもの）であれば、Ｓ’はどのような値でもよい。加法的秘密分散法では、Ｓ’は、例えばＳと同サイズの“０”とすることができる。
　i番目のサーバ３（パーティ）をＰｉで表した場合、１＜ｉ≦ｎの各Ｐｉにおいて、
　　　Ｓ’＝Ｚｅｒｏ（Ｓ）
を実施してＳをＳ’に置換することで、１番目のＰ１が保持するＳと、各Ｐｉ（１＜ｉ≦ｎ）が保持するＳ’とにより、
　　　Ｒｅｃｏｎｓｔｒｕｃｔ（Ｓ，Ｓ’，Ｓ’，…，Ｓ’）　＝　Ｓ
となって、復号によりＳを得ることができる。すなわち、ＳとＳ’（ゼロ値）を、Ｓの疑似的なシェアとして取り扱うことができる。
　例えば、「１２３４」で表されるデータの場合、これを“ゼロ値化”すると、
　　　Ｚｅｒｏ（１２３４）　＝　００００
のように、Ｒｅｃｏｎｓｔｒｕｃｔ関数における単位元に置き換わる。したがって、全てのサーバが保持するシェアのうち、１つのシェアのみ「１２３４」で、他の全てのサーバが保持するシェアが「００００」であるシェアに基づいて復号したときに、
　　１２３４＋００００＋００００＋…＋００００　＝　１２３４
もしくは、
　　１２３４＠００００＠００００＠…＠００００　＝　１２３４
　　　　　　　　　　　　　　　　（“＠”は排他的論理和を表す）
となり、元の平文「１２３４」を得ることができる。
　フォーマット部分Ｆを平文としておく際の手法は、上記の“ゼロ値化”に限られない。例えば、シェア２６を保持する全てのパーティ（サーバ３）のうち１つを除くパーティが乱数を発行し、これを１つのパーティに集めて、乱数を集めたパーティ上で各パーティが発行した乱数をシェアとみなした秘密分散法を行ってもよい。例えば、平文から全ての乱数を減算または排他的論理和した結果を新たなシェアとすることで、加法的秘密分散を再現することができる。すなわち、各パーティが発行した乱数をＲｉ（１＜ｉ≦ｎ）としたとき、各パーティから乱数を集めたパーティ上で
　　　Ｓ’＝　Ｓ－（Ｒ２＋Ｒ３＋…＋Ｒｎ）
あるいは、
　　　Ｓ’＝　Ｓ＠Ｒ２＠Ｒ３＠…＠Ｒｎ
とすると、
　　　Ｒｅｃｏｎｓｔｒｕｃｔ（Ｓ’，Ｒ２，Ｒ３，…，Ｒｎ）　＝　Ｓ
となってＳを復元することができる。すなわち、Ｓ’とＲｉ（１＜ｉ≦ｎ）を、Ｓの疑似的なシェアとすることができる。
　本実施の形態では、フォーマット部分Ｆを平文としておく手法として上記の“ゼロ値化”を用いるものとし、以下では、フォーマット部分Ｆを“ゼロ値化”したＺｅｒｏ（Ｆ）をＦ’と記載する。なお、フォーマット部分Ｆ’を計算した場合、フォーマット部分ＦはＭＰＣに使用されないことになるが、キー情報を参照する目的でフォーマット部分Ｆを別途削除せずに保持してもよい。また、詳細は後述するが、フォーマット部分Ｆ の中に、プライバシー情報のシェア（シェア２６に含まれるクレームのバリューのシェア）によって置換する箇所が含まれている場合、その置換対象を表すためのマーカー（例えば、置換対象の文字列）を除く部分のみ、ゼロ値化するものとする。
　図中のシェア２６＿１、シェア２６＿２…シェア２６＿ｎは、それぞれ、上記の条件でＶＣ２４１を秘密分散して得られたｎ個のシェア２6を示している。例えばｎ番目のシェア２６＿ｎは、ＶＣ２４１についてのｎ番目のシェア、すなわち、データＤのｎ番目のシェアＤ＿＄ｎと、デジタル署名Ｄｓｉｇのｎ番目のシェアＤｓｉｇ＿＄ｎを含む。さらに、平文のフォーマット部分Ｆ（またはフォーマット部分Ｆの“ゼロ値化”を行ったパーティではフォーマット部分Ｆ’）と、ＩＤ情報ＳＵＢ＿ＷＡのｎ番目のシェアＳＵＢ＿ＷＡ＿＄ｎおよび各クレームＣ１～Ｃｍのｎ番目のシェアＣ１＿＄ｎ～Ｃｍ＿＄ｎが連結されたものであるＶＣ＿＄ｎが含まれる。
　なお、ここでの連結とは、データＤに含まれた情報の中でもプライバシー情報にあたるクレームのバリュー（平文）を、それぞれのシェア（暗号文）で置き換える操作を指し、これをＲｅｐｌａｃｅ関数として定義する。すなわち、秘密分散されたシェア２６が配布されたi番目のサーバＰｉ（ｉ∈｛１，２，…，ｎ｝）において、以下のように置換が実施される。
　　Ｐ１においては、
　　　ＶＣ＿＄１
　　　　　＝　Ｒｅｐｌａｃｅ（Ｆ，ＳＵＢ＿ＷＡ＿＄ｉ，
　　　　　　　　　　　　　　　　　Ｃ１＿＄ｉ，…，Ｃｍ＿＄ｉ）
　　Ｐｉ（１＜ｉ≦ｎ）においては、
　　　ＶＣ＿＄ｉ
　　　　　＝　Ｒｅｐｌａｃｅ（Ｆ’，ＳＵＢ＿ＷＡ＿＄ｉ，
　　　　　　　　　　　　　　　　　Ｃ１＿＄ｉ，…，Ｃｍ＿＄ｉ）
　このように各シェア２６は、フォーマット部分Ｆ（平文）と、各クレームＣ１～Ｃｍのシェアが分離できる構成を有している。これにより、サーバ側でのＭＰＣの際に、各シェア２６に含まれるフォーマット部分Ｆをシェアと取り扱ったとしても、“ゼロ値化”されているフォーマット部分Ｆ’については、上述したとおりＲｅｃｏｎｓｔｒｕｃｔ関数の結果に影響を与えないことから、全シェアのうち１つだけあるフォーマット部分Ｆの平文を実際に含んでいるシェア２６の内容に基づいて、ＭＰＣを行なうことができる。
　また、上記の“ゼロ値化”を行わずに、全てのシェア２６のフォーマット部分Ｆが実際の内容を含んでいる場合でも、例えば、任意の１つサーバ３（Ｐｉ）が保持するシェア２６のフォーマット部分Ｆのみ使用して、他のシェア２６のフォーマット部分Ｆを無視して“ゼロ”と同様に取り扱うことで検証を行ってもよい。
　なお、上記のような各種の手法により、フォーマット部分Ｆを平文のままにしておくのに加えて、さらにフォーマット部分Ｆを秘密分散によりシェア化したものを併せて配布するようにしてもよい。
　また、図５の例では、ＶＣ２４１について、データ部分とフォーマット部分とに分けて、フォーマット部分（フォーマット部分Ｆ）のみ平文のままとしつつ、他のデータ部分を秘密分散により暗号化してシェア２６を生成している。しかしながら、データ部分のうちクレームＣ１～Ｃｍについても、プライバシー情報（利用者本人が秘匿したい秘密情報）と、非プライバシー情報（利用者本人が公開してもよいと考えている情報）とがあると考えられ、非プライバシー情報に該当するクレームについては、フォーマット部分Ｆと同様に暗号化（シェア化）せずに平文のまま取り扱うようにしてもよい。この場合、各クレームについて、保持するデータ（バリュー）がプライバシー情報であるか否か（シェア化するか否か）の情報を別途保持してもよく、例えばフォーマット部分Ｆに当該データ（バリュー）の平文を含めたままにしてもよい。
　＜システム構成＞
　図１は、本発明の一実施の形態であるサービス提供システムの構成例について概要を示した図である。サービス提供システム１は、例えば、利用者４が保有するクライアント２と複数のサーバ３が図示しないインターネット等のネットワークを介して相互に通信可能な構成を有する。クライアント２は、主に利用者４についてのＶＣ２４１の情報を保持して管理する機能を有する装置（第１の装置）であり、例えば、ＰＣ（Personal Computer）やタブレット型端末、スマートフォンなどの情報処理端末その他の装置により実装される。
　一方、サーバ３は、クライアント２においてＶＣ２４１を秘密分散することにより生成された複数のシェア２６をそれぞれ隔離して保管するとともに、これらのシェア２６に基づいてＭＰＣを行い、パーソナライズサービスを提供するための計算結果を得る機能を有する装置（第２の装置）であり、例えば、サーバ機器やクラウドコンピューティングサービス上に構築された仮想サーバその他の装置により実装される。各サーバ３は、それぞれがシェア２６を不正に操作することを目的とした結託を行うことのない異なる人物・事業者により管理されるものとし、物理的に隔離されているのが望ましいが、同一の人物・事業者により管理される１つのサーバ機器上に構築された複数の仮想サーバ等、論理的に隔離された構成を排除するものではない。
　以下では、クライアント２およびサーバ３のそれぞれの構成について、処理の流れに沿いながら説明する。
　［クライアント］
　クライアント２は、例えば、図示しないＣＰＵ（Central Processing Unit）により、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等の記録装置からメモリ上に展開したＯＳ（Operating System）やＤＢＭＳ（Database Management System）等のミドルウェアや、その上で稼働するＷｅｂブラウザやアプリケーションプログラム等のソフトウェアを実行することで、上述したクライアント２の各種機能を実現する。クライアント２は、例えば、ソフトウェアにより実装されたＶＣ処理部２１ 、シェア提供部２２、およびグループ同期部２３などの各部を有する。また、データベースやファイル等により実装されたＶＣ保管部２４およびＩＤ保管部２５などの各データストアを有する。
　ＶＣ処理部２１ は、利用者４が発行者から発行を受けたデータをＶＣ２４１として取り扱えるようにするための上述したＤＩＤの機能を有する。ＶＣ処理部２１ を介して得られたＶＣ２４１には、上述したように、ＩＤ（アイデンティティ）を示す情報（例えばＤＩＤのＷＡ）と、属性情報（例えば、“購入商品「りんご」”、“金額（円）「１００」”など）が含まれる。得られたＶＣ２４１はＶＣ保管部２４に記録・保管する。利用者４が自身のＶＣ２４１の集合をウォレットに格納して管理できるようにするためのユーザインタフェースの機能を有していてもよい。ＶＣ処理部２１の実装に際しては、例えば、Ｍｉｃｒｏｓｏｆｔ社などの既存のＤＩＤ製品ならびにＳＤＫ（ソフトウェア開発キット）を適宜使用することができる。
　図６および図７は、本発明の一実施の形態におけるＶＣ保管部２４のデータ構成と具体的なデータの例について概要を示した図である。本実施の形態では、例えば、図５の例に示したＶＣ２４１の内容のうち、図６のＶＣ保管部２４ａのテーブルでは、データＤとそのデジタル署名Ｄｓｉｇ、フォーマット部分ＦおよびＩＤ情報ＳＵＢ＿ＷＡの部分をそれぞれ対応するカラムに保管し、図７のＶＣ保管部２４ｂのテーブルでは、クレームＣ１～Ｃｍのキーとバリュー、ならびにバリューのデータタイプ（ｓｔｒｉｎｇ、ｎｕｍｂｅｒ（ｉｎｔ、ｄｏｕｂｌｅ）、ｂｏｏｌｅａｎ、ｎｕｌｌ／ｅｍｐｔｙ、ｏｂｊｅｃｔ（ＪＳＯＮ　ｏｂｊｅｃｔ）、ａｒｒａｙ等が標準的だが、独自の型を定義してもよい）をそれぞれ対応するカラムに保管することを示している。なお、図６のＶＣ保管部２４ａでは、さらに各ＶＣ２４１を一意に特定するＶＣＩＤをキーとして保持し、図７のＶＣ保管部２４ｂでは、さらに各クレームを一意に特定するクレームＩＤをキーとして保持することを示している。
　図６のＶＣ保管部２４ａにおけるデータＤには、ＪＷＳのデータがそのまま保持される。一方、フォーマット部分Ｆには、ＪＷＳに含まれるクレームのうちバリューの部分のみが「＄｛ＳＵＢ＿ＷＡ｝」あるいは「＄｛クレームＩＤ｝」といったマーカーに置換された状態で保管されることが示されている。この部分は、例えば、図７のＶＣ保管部２４ｂにおける対応するクレームのクレームＩＤ（図６、図７の例では“Ｃ００１”）あるいはアイデンティティ情報を表す文字列（図６の例では“ＳＵＢ＿ＷＡ”）の値により表すことで、バリューとの間で置換可能としておく。本実施の形態では「＄｛｝」により囲うことで、クレームのバリュー値と置換対象とを分別可能にしているが、置換後のデータの表記（例えばＪＳＯＮの文法）を正しく解析可能なパーサーが実装可能であれば、どのような表記方法を用いてもよい。
　図１に戻り、クライアント２のシェア提供部２２は、ＶＣ保管部２４に保管されているＶＣ２４１のうち利用者４に指定されたものについて、（ｋ，ｎ）閾値秘密分散法により暗号化して複数のシェア２６を生成し、各シェア２６をいずれかのサーバ３に提供する機能を有する。ＶＣ２４１を秘密分散して複数のシェア２６を生成する手法は、図５の例に示したとおりであるが、この場合、ｎ個のシェア２６が生成されるため、ｎ個のサーバ３にそれぞれ１つずつシェア２６を提供するのが望ましい。一方で、１つのサーバ３にｋ個以上のシェア２６が提供されることがなければ、１つのサーバ３で元のＶＣ２４１が復元されてしまうことはないことから、その限度でｎ個に満たない数のサーバ３に提供する（１つのサーバ３に複数個のシェア２６を提供する）場合も除外されない。
　サーバ３に対してシェア２６の形でデータを提供すると、上述の図３の例に示したように、サーバ３においてグループＩＤ（「クライアント２がサーバ３に対して貸し出したデータに対するグループＩＤ」という意味で、以下では「貸出グループＩＤ」という場合がある）が発行されて、利用者４のクライアント２へ返却される。本実施の形態では、後述するように、貸出グループＩＤに加えて、さらに、サーバ３においてＶＣ２４１の各クレームに対して発行された貸出クレームＩＤと対応するクレームが一意になる情報も返却されるものとしていて、例えばキー、データタイプ、バリューなどの情報が該当する。また、初回の返却時のみ、その後の認証のためのクレデンシャルの情報も返却されるようにしてもよい。図中ではこれらをまとめて貸出情報３５として示している。
　グループ同期部２３は、後述するサーバ３のグループ同期部３３と連携して、サーバ３から返却された貸出情報３５を取得して、その内容をＩＤ保管部２５に記録・保管するとともに、秘密分散法により計算結果を含むデータを復号（Ｒｅｃｏｎｓｔｒｕｃｔ）する機能を有する。以降は、サーバ３から返却された貸出グループＩＤ（および貸出クレームＩＤ）と、必要に応じてクレデンシャル情報をサーバ３に対して送信することで、サーバ３においてグループＩＤによりグループ化されて管理されているシェア２６に基づくＭＰＣの計算結果（シェア）と同期し、取得した計算結果のシェアから復号（Ｒｅｃｏｎｓｔｒｕｃｔ）することで、グループＩＤに紐づくクレームのデータに基づく計算結果（平文）を受け取ることが可能になる。すなわち、サーバ３からグループＩＤに紐づく計算結果のシェアを配信する行為が、パーソナライズされたサービスを配信する手段になる。
　貸出グループＩＤに加えて貸出クレームＩＤも指定することで、当該貸出クレームＩＤに係るデータに基づく処理を行わせることも可能である。例えば、ＧＤＰＲ（General Data Protection Regulation、ＥＵ一般データ保護規則）に規定された「消去権」や「訂正権」にあたる権利行使を、対象データに対して実行できるようにすることも可能である。
　図８は、本発明の一実施の形態におけるＩＤ保管部２５のデータ構成と具体的なデータの例について概要を示した図である。サーバ３から返却された貸出情報３５の内容として、貸出グループＩＤと貸出クレームＩＤ、および対象クレームのキー、データタイプの内容をそれぞれ保管することを示している。また、各クレームにつき、秘密分散法により復号（Ｒｅｃｏｎｓｔｒｕｃｔ）したバリューの内容を保管することを示している。なお、このテーブルには、ＶＣ２４１によって提供したデータ（クレーム）だけではなく、ＶＣ２４１によって提供したデータ（クレーム）に基づくサーバ３側でのＭＰＣの計算結果を復号したデータについても含まれる。計算結果に対しても同様にクレームＩＤを付与することで、ＶＣ２４１によって提供されたデータと同様の操作が可能になる。すなわち、計算結果をさらに別の計算・処理に用いることが可能になる。
　［サーバ］
　図１に戻り、サーバ３は、例えば、図示しないＣＰＵにより、ＨＤＤやＳＳＤ等の記録装置からメモリ上に展開したＯＳやＤＢＭＳ等のミドルウェアや、その上で稼働するソフトウェアを実行することで、上述したサーバ３の各種機能を実現する。サーバ３は、例えば、ソフトウェアにより実装されたシェア取得部３１、検証処理部３２、およびグループ同期部３３などの各部を有する。また、データベースやファイル等により実装されたシェア保管部３４などのデータストアを有する。
　シェア取得部３１は、クライアント２から提供されたシェア２６を受信・取得し、メモリ等の記録装置に一時的に保持する機能を有する。検証処理部３２は、シェア取得部３１により一時的に保持されているシェア２６について、以下の３種類の検証処理をＭＰＣを利用しながら行なう機能を有し、各検証処理を行なうために発行者検証部３２１、包含検証部３２２、およびグルーピング部３２３などの各部をさらに有する。なお、以下の３種類の検証処理を行なう順序は特に限定されない。つまり、３種類すべての検証処理は、並行して実施することも可能である。
　発行者検証部３２１は、第１の検証として、対象のデータの発行者とされる者が正しい発行者であることを検証する機能を有する。この検証処理は、署名の計算に用いられたデジタル署名の署名アルゴリズムの対にあたる検証アルゴリズムを、ＭＰＣにより実施する。この署名アルゴリズムは、フォーマット部分Ｆに含まれた情報により定まる。例えば、ＪＷＳのヘッダー部におけるキー“ａｌｇ”のバリューにより定まる。キー“ｋｉｄ”のバリューに基づいてＰＫＩもしくはＤＰＫＩから取得した公開鍵と、ＶＣ＿＄ｉ、およびＶＣ２４１に含まれるデジタル署名のシェアＤｓｉｇ＿＄ｉを入力値とした、ＭＰＣによる完全性検証のアルゴリズム（ＶｅｒｉｆｙＭＰＣ関数）を実行し、検証結果のシェアを復号（Ｒｅｃｏｎｓｔｒｕｃｔ）することにより結果を確認する。
　包含検証部３３２は、第２の検証として、ＶＣ＿＄ｉに含まれるプライバシー情報のシェアが、ＶＣ２４１に含まれるデータを秘密分散したシェアであることを検証する。具体的には、例えば、図５におけるシェア２６＿ｎを例にすると、フォーマット部分ＦもしくはＦ’と、各クレームＣ１～ＣｍのシェアＣ１＿＄ｎ～Ｃｍ＿＄ｎを連結させた値、すなわちＶＣ＿＄ｉと、ＶＣ２４１全体のシェアＤ＿＄ｎを、ＭＰＣにより等価検証（ＥｑｕａｌＭＰＣ関数）し、検証結果のシェアを復号（Ｒｅｃｏｎｓｔｒｕｃｔ）することにより結果を確認する。
　なお、第１の検証と、第２の検証は、１つの検証により兼ねることが可能である。すなわち、以下に示すように、ＰＫＩもしくはＤＰＫＩから取得した公開鍵と、フォーマット部分ＦもしくはＦ’と各クレームＣ１～ＣｍのシェアＣ１＿＄ｎ～Ｃｍ＿＄ｎを連結させた値、およびＶＣ２４１に含まれるデジタル署名Ｄｓｉｇ＿＄ｉを入力値として、完全性検証のアルゴリズムをＭＰＣで実行し、検証結果のシェアを復号（Ｒｅｃｏｎｓｔｒｕｃｔ）することにより結果を確認すれば、第１の検証と第２の検証を兼ねることができる。
　　　［ｖ］　←　ＶｅｒｉｆｙＭＰＣ（ｐｋ，［Ｄｓｉｇ］，［ＶＣ］）
　　　｛Ａｃｃｅｐｔ，Ｒｅｊｅｃｔ｝
　　　　　　　　　　　　　　　←　Ｒｅｃｏｎｓｔｒｕｃｔ（［ｖ］）
なお、［］内の値は、秘密分散されたシェアを略式的に表している。例えば、任意の値Ｘに関して、
　　　［Ｘ］　＝　｛Ｘ＿＄１，Ｘ＿＄２，…，Ｘ＿＄ｎ｝
である。すなわち、
　　　ＶＣ　＝　Ｒｅｃｏｎｓｔｒｕｃｔ（［ＶＣ］）
　　　　　　＝　Ｒｅｃｏｎｓｔｒｕｃｔ（ＶＣ＿＄１，ＶＣ＿＄２，
　　　　　　　　　　　　　　　　　　　　　　　　…，ＶＣ＿＄ｎ）
である。ＶｅｒｉｆｙＭＰＣ関数は、ＭＰＣによるデジタル署名の完全性検証アルゴリズムを表す。またｖは、ｐｋ、Ｄｓｉｇ、ＶＣにより、キー“ａｌｇ”のバリューにより定められるデジタル署名の完全性検証アルゴリズムによって検証した結果を表す。
　グルーピング部３２３は、第３の検証として、複数のＶＣ２４１に係るシェア２６を取得した場合に、各シェア２６に含まれるＶＣ２４１のＩＤ情報が、他のＶＣ２４１のものと同一か否かを検証し、同一のＩＤ情報であるＶＣ２４１に係るデータをグループ化する機能を有する。
　具体的には、例えば、異なるｐ個のＶＣ２４１をＶＣ２４１ｑ（ｑ∈｛１，２，…，ｐ｝で表し、これらをグループ化する場合、ＶＣ２４１１におけるＩＤ情報ＳＵＢ＿ＷＡのシェアをＲＥＰ＿ＳＵＢ＿ＷＡ＿＄ｉとし、他の（ｐ－１）個のＶＣ２４１におけるＩＤ情報ＳＵＢ＿ＷＡのシェアをｓｕｂｑ＿＄ｉとし、１＜ｑ≦ｐにおいて、ＲＥＰ＿ＳＵＢ＿ＷＡ＿＄ｉとｓｕｂｑ＿＄ｉとをそれぞれＭＰＣで等価検証（ＥｑｕａｌＭＰＣ関数）する。
　　　［ｅｑ］　←　ＥｑｕａｌＭＰＣ（［ＲＥＰ＿ＳＵＢ＿ＷＡ］，
　　　　　　　　　　　　　　　　　　　　　　　　　［ｓｕｂｑ］）
　　　｛Ａｃｃｅｐｔ，Ｒｅｊｅｃｔ｝
　　　　　　　　　　　　　　←　Ｒｅｃｏｎｓｔｒｕｃｔ（［ｅｑ］）
なお、ｅｑは１＜ｑ≦ｐの範囲内のｑ番目のＶＣ２４１に含まれたＳＵＢ＿ＷＡと、ＲＥＰ＿ＳＵＢ＿ＷＡとを等価検証した結果を表す。またＥｑｕａｌＭＰＣ関数はＭＰＣによる等価検証を表す。全てのＶＣ２４１のＩＤ情報が同一の値であれば（１＜ｑ≦ｐにおいて、すべてのＲｅｃｏｎｓｔｒｕｃｔ（［ｅｑ］）がＡｃｃｅｐｔを返せば）グループ化成功とする。
　発行者検証部３２１の処理、包含検証部３２２の処理、グルーピング部３２３の処理において、すべての検証でＡｃｃｅｐｔが返された場合、ＶＣ２４１に対してグループＩＤを発行する。特にグルーピング部３２３の等価検証において、１つでもＩＤ情報が同一の値ではないＶＣ２４１がある場合は、ＩＤ情報が同一の値のＶＣ２４１だけでグループ化してもよいし、破棄して所定の例外処理を行なうようにしてもよい。ＶＣ２４１をグループ化した場合は、さらに各ＶＣ２４１に含まれる値それぞれにクレームＩＤを割り当てる。割り当てたグループＩＤとクレームＩＤは、後述するグループ同期部３３により、それぞれ貸出グループＩＤ、貸出クレームＩＤ（ＶＣ２４１のプロパティ名付き）としてクライアント２に返却される。
　グループ化したＶＣ２４１に係る情報は、シェア保管部３４に保管される。図９および図１０は、本発明の一実施の形態におけるシェア保管部３４のデータ構成と具体的なデータの例について概要を示した図である。本実施の形態では、例えば、図９の例に示したシェア保管部３４ａのテーブルでは、グループＩＤに係る情報として、貸出グループＩＤとＩＤ情報ＳＵＢ＿ＷＡのシェアを保管することを示している。図中で、貸出グループＩＤが“グループ１”のレコードのＩＤ情報ＳＵＢ＿ＷＡの値が“３０１８１Ｂ…”と１６進数の乱数で表されているのは、シェア化（暗号化）された状態であることを示している。
　また、図１０の例に示したシェア保管部３４ｂのテーブルでは、クレームＩＤに係る情報として、貸出グループＩＤと貸出クレームＩＤ、および署名以外のクレームにおけるキーとデータタイプの平文に加えて、バリューのシェアの情報を保管することを示している。図中でクレームのキーが“ｎａｍｅ”のレコードのバリューの値が１６進数の乱数で表されているのは、シェア化（暗号化）された状態であることを示している。さらに、クレームが非プライバシー情報であり、秘密分散によりシェア化せずに平文のままとされたものか否かを判別するフラグの情報についても保持することを示している。なお、上述したように、平文のままとされたクレームについては、バリューに平文の内容を保持するのは１つのサーバ３のみであり、他のサーバ３では当該クレームのバリューは“ゼロ値化”される。
　グループ同期部３３は、クライアント２のグループ同期部２３と連携し、グルーピング部３２３によりグループ化されたＶＣ２４１につき、発行された貸出グループＩＤと、貸出クレームＩＤおよび対応するクレーム（キー、バリュー、データタイプなど）の情報を貸出情報３５としてクライアント２に返却する機能を有する。なお、クライアント２に対する初回の返却時のみ、貸出情報３５にはさらにその後の認証のためのクレデンシャルの情報を含めるようにしてもよい。
　利用者４のクライアント２に返却される貸出情報３５には、利用者４のプライバシー情報自体は含まれないが、例えば、返却先のクライアント２のＩＰアドレスが毎回同じであるなどの場合には、そこから利用者４本人が特定されてしまうリスクも生じ得る。したがって、サーバ３とクライアント２との間の通信については、例えば、Ｔｏｒなどの接続経路を秘匿化できる通信手段を用いることが望ましい。
　＜処理の流れ＞
　図１１は、本発明の一実施の形態におけるクライアント２から各シェア２６がサーバ３に配布されてサーバ３で検証が行われるまでの処理の流れの例について概要を示した図である。まず、クライアント２では、ＶＣ処理部２１により、利用者４が発行者から発行を受けたデータからＶＣ２４１を取得して、ＶＣ保管部２４に保管する（Ｓ０１）。その後、シェア提供部２２により、ＶＣ保管部２４に保管されたＶＣ２４１からｎ個のシェア２６（シェア２６＿ｉ（１≦ｉ≦ｎ））を計算し（Ｓ０２）、これらを合計ｎ個のサーバ３（図中の例では１番目のサーバ３ｃ（Ｐ１）およびｉ番目（１＜ｉ≦ｎ）のサーバ３ｄ（Ｐｉ））にそれぞれ送信する（Ｓ０３）。なお、図中の例ではｎ個のサーバ３（サーバ３ｃおよびサーバ３ｄ）に配布するものとしているが、上述したように、シェア２６を算出した際の秘密分散の閾値ｋよりも多い数のサーバ３であれば、ｎ個に満たない数でもよい。
　シェア２６＿ｉ（１≦ｉ≦ｎ）が送信された各サーバ３（サーバ３ｃおよびサーバ３ｄ）では、シェア取得部３１によりこれを取得して一時保存する（Ｓ０４）。その後、上述した手法によりフォーマット部分Ｆを擬似的にシェア化する際にその平文を保持するサーバ３（これをサーバ３ｃ（Ｐ１）とする）を除く他のサーバ３（すなわちサーバ３ｄ（Ｐｉ（１＜ｉ≦ｎ））では、フォーマット部分Ｆについて上述した手法により“ゼロ値化”する（Ｓ０５）。
　その後、検証処理部３２により、各サーバ３（サーバ３ｃおよびサーバ３ｄ）間でＭＰＣを行なうことで、以下のステップＳ０６～Ｓ０８の３種類の検証処理を行なう。なお、上述したように、３種類の検証処理を行なう順序は特に限定されず、図１１に示した順序は一例である。また、ステップＳ０６とＳ０７の検証処理は１つの検証処理で兼ねることも可能である。
　第１の検証として、発行者検証部３２１により、元のＶＣ２４１のデータの発行者が正しい発行者であることをＭＰＣにより検証する（Ｓ０６）。具体的には、予め、フォーマット部分ＦにおけるＪＷＳのヘッダー部のキー“ｋｉｄ”のバリューに基づいてＰＫＩもしくはＤＰＫＩから公開鍵を取得し、さらにキー“ａｌｇ”のバリューから署名検証アルゴリズムを特定して、このアルゴリズムを各サーバ３（Ｐ１～Ｐｎ）間で合意しておく。そして、各シェア２６＿ｉに含まれるＶＣ＿＄ｉおよびＤｓｉｇ＿＄ｉに基づいて署名の完全性を検証し、検証結果のシェアを復号（Ｒｅｃｏｎｓｔｒｕｃｔ）することで結果を確認する。
　第２の検証として、包含検証部３２２により、ＶＣ＿＄ｉに含まれるプライバシー情報のシェアが、元のＶＣ２４１に含まれるデータを秘密分散したシェアであることをＭＰＣにより検証する（Ｓ０７）。具体的には、例えば、上述したように、各シェア２６＿ｉに含まれるＶＣ＿＄ｉとＤ＿＄ｉをＭＰＣにより等価検証し、検証結果のシェアを復号（Ｒｅｃｏｎｓｔｒｕｃｔ）することで結果を確認する。
　第３の検証として、グルーピング部３２３により、各シェア２６＿ｉに含まれるＩＤ情報が同一のものでＶＣ２４１をグループピングする（Ｓ０８）。具体的には、例えば、シェア２６＿ｉに係るＶＣ２４１におけるＩＤ情報ＳＵＢ＿ＷＡのシェアと、他のＶＣ２４１におけるＩＤ情報ＳＵＢ＿ＷＡのシェアとをそれぞれ等価検証し、全て同一の値であればグループ化成功として、これらのＶＣ２４１に対してグループＩＤを発行する。１つでも同一の値ではないＶＣ２４１がある場合は、同一の値のＶＣ２４１だけでグループ化してもよい。グループＩＤを発行した場合は、さらにシェア２６＿ｉに係るＶＣ２４１に含まれる値それぞれにクレームＩＤを割り当てる。
　その後、上述した３種類の検証処理の結果が全て問題ない（検証結果が全て真（Ａｃｃｅｐｔ）である）か否かを判定し（Ｓ０９）、１つでも問題がある（検証結果に１つ以上偽（Ｒｅｊｅｃｔ）がある）場合は、所定の例外処理を行なう（Ｓ１０）。一方、ステップＳ０９で検証結果が全て問題ない場合は、グループ同期部３３により、発行されたグループＩＤとクレームＩＤおよび対応するクレーム（キー、シェア化されたバリュー、データタイプなど）をシェア保管部３４に保管するとともに、これらを貸出情報３５として（Ｓ１１）、クライアント２に返却する（Ｓ１２）。貸出情報３５の返却を受けたクライアント２では、グループ同期部２３によりこれを取得して、ＩＤ保管部２５に記録する（Ｓ１３）。
　特にステップＳ０６～ステップＳ０８の処理時間によって、利用者４に待ち時間が発生することを避けたい場合、シェア取得部３１またはグループ同期部３３において、ステップＳ０４の直後に全てのＶＣ２４１のＩＤ情報が全て同一の値であると仮定して“みなしグループＩＤ”を発行し、（必要に応じてクレデンシャルを発行し、これと併せて）クライアント２のグループ同期部２３へ“みなしグループＩＤ”を返してもよい。この場合、ステップＳ０６～ステップＳ０８の検証がすべて成功したとき、“みなしグループＩＤ”と貸出クレームＩＤおよび対応するクレーム（キー、シェア化されたバリュー、データタイプなど）をシェア保管部３４に保管する。
　なお、計算の入力値、出力値を問わず、データに割り当てられる貸出グループＩＤと貸出クレームＩＤに不整合が生じないよう、ＭＰＣに参加するサーバ間で通信し、同じデータに対して発行された貸出グループＩＤと貸出クレームＩＤの等価性、あるいは採番方法を合意してもよい。あるいは、貸出グループＩＤ、貸出クレームＩＤはサーバ３毎に異なる採番がなされても良い。この場合、たとえばクライアント２において、図８に示す貸出グループＩＤ、貸出クレームＩＤを、サーバ３毎に保管し、各データ（クレームのバリュー）の復元（Ｒｅｃｏｎｓｔｒｕｃｔ）に用いるシェアの集合を一意にするためのＩＤを、別途採番する。
　図１２は、本発明の一実施の形態におけるサーバ３でシェア２６の検証が行われた後、パーソナライズサービスが提供されるまでの処理の流れの例について概要を示した図である。各サーバ３（Ｐｉ（１≦ｉ≦ｎ））では、グループ同期部３３により、シェア保管部３４に保管された貸出グループＩＤに関連付けられたクレームの情報に基づいてＭＰＣにより計算処理を行う（Ｓ２１）。その後、計算の出力結果（シェア）へ貸出クレームＩＤを発行し、計算の入力値として用いたクレームと同一の貸出グループＩＤを計算結果に関連付けて、この計算結果をクレーム情報としてシェア保管部３４に記録する（Ｓ２２）。このクレーム情報には、発行した貸出クレームＩＤ、計算結果の意味を表すキー情報、計算結果のシェア（バリューのシェア）、計算結果のデータタイプなどが含まれる。
　なお、ステップＳ２１の計算処理については、ＭＰＣの計算処理の負荷や効率等を考慮して、後述するように、例えば、サーバ３において内部的に秘密分散法から異なる計算手法に変換した上で解析し、その結果を改めて秘密分散化することで処理効率を向上させてもよい。
　クライアント２では、パーソナライズサービスを受けるために提供するＶＣ２４１に対応する貸出グループＩＤの情報を、各サーバ３（Ｐｉ（１≦ｉ≦ｎ））に対して送信することで計算結果を要求する（Ｓ３１）。各サーバ３（Ｐｉ（１≦ｉ≦ｎ））では、貸出グループＩＤによりグルーピングされたクレームの情報（上述したステップＳ２１での計算結果も含む）をシェア保管部３４から抽出し、これをクライアント２に応答する（Ｓ３２）。クライアント２では、各サーバ３（Ｐｉ（１≦ｉ≦ｎ））から応答されたクレーム情報におけるバリューのシェアに基づいて秘密分散法により復号（Ｒｅｃｏｎｓｔｒｕｃｔ）することで、貸出グループＩＤに関連付けられたクレームのデータに基づく計算結果を取得する（Ｓ３３）。すなわち、パーソナライズされたサービスの配信を受けることができる。
　＜利用形態＞
　以上に示したような構成において、例えば、ユースケースとして、サービスプロバイダが、「年齢が２０歳以上の利用者にはお酒の広告、２０歳未満の利用者にはジュースの広告」を提供したいという場合を想定する。利用者４が、ＶＣ２４１として年齢の情報を提供していて、サーバ３においてこれに対するグループＩＤが発行されている状態で、サーバ３側では、
　ｉｆ（年齢＞＝２０）
　　　　“ビールの広告”
　ｅｌｓｅ
　　　　“オレンジジュースの広告”
というような処理（ＭＰＣ）を“年齢”のデータを含んだグループに対して実行する。計算結果に対し、計算を適用したグループのグループＩＤを紐づける。
　サーバ３側では、計算結果（“ビールの広告”もしくは“オレンジジュースの広告”）はシェアの形のままとなっており、その内容を把握することはできないが、利用者４のクライアント２では、各サーバ３から返却された計算結果に基づいて秘密分散法のＲｅｃｏｎｓｔｒｕｃｔにより復号することで、計算結果に係るパーソナライズされた広告を受け取ることができる。このときサーバ３側では、グループＩＤを介してＭＰＣでの処理を行っていることから、計算結果の内容を知ることができないだけでなく、ＶＣ２４１を提供した利用者４を特定することもできない。これにより、強固にプライバシー情報を保護した上で利用者４に固有のパーソナライズサービスを提供することが可能となる。
　なお、サーバ３間でのＭＰＣ処理は、計算処理の負荷も大きい上に、通信のオーバーヘッドもあり、処理効率が高いとは言い難い。このため、例えば、サーバ３側において内部的に秘密分散法から異なる計算手法に変換し、処理効率を向上させてもよい。例えば、各サーバ３が取得したＶＣ２４１のシェア２６について、ＭＰＣによりいわゆる準同型暗号に変換した上でこれを計算し、得られた計算結果を改めて秘密分散化して、シェアからＭＰＣにより準同型暗号の復号した結果のシェアを求めるようにしてもよい（環境や条件によって処理性能が向上する場合がある）。また、各サーバ３が取得したシェア２６を、ハードウェアベースのＴＥＥ上で動作するＴＡ（Trusted Application）内で復号（Ｒｅｃｏｎｓｔｒｕｃｔ）した上で計算し、計算結果を改めて秘密分散してシェアを生成して出力してもよい。ただし、特に後者の場合は、プライバシー保護に対する安全性は低下し得る。
　以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。また、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
　また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ等の記録装置、またはＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
　また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。
　本発明は、利用者本人を特定することなくパーソナライズサービスを提供するサービス提供システムに利用可能である。
１…サービス提供システム、２…クライアント、３…サーバ、３ａ…サーバＡ、３ｂ…サーバＢ、３ｃ、３ｄ…サーバ、４、４ａ～４ｃ…利用者、５…ＤＰＫＩ、６…データ収集設備、７…管理者、
２１…ＶＣ処理部、２２…シェア提供部、２３…グループ同期部、２４、２４ａ、２４ｂ…ＶＣ保管部、２５…ＩＤ保管部、２６、２６＿１～２６＿ｎ…シェア、
３１…シェア取得部、３２…検証処理部、３３…検証処理部、３４、３４ａ、３４ｂ…シェア保管部、３５…貸出情報、
２１１ａ～２１１ｄ…ウォレット、２４１…ＶＣ、
３２１…発行者検証部、３２２…包含検証部、３２３…グルーピング部

Claims (4)

  1. 　利用者の第１の装置に対して、１つ以上の第２の装置によりネットワークを介してサービスを提供するサービス提供システムであって、
    　前記第１の装置は、
    　前記利用者のものであるとして検証可能なデータＶＣを保管するＶＣ保管部から前記ＶＣを取得して秘密分散法により複数個のシェアに分割し、前記各シェアを前記第２の装置に配布するシェア提供部と、
    　前記第２の装置から返却された１つ以上の前記ＶＣに係るグループＩＤの情報を取得してＩＤ保管部に保管し、前記グループＩＤに基づいて、前記第２の装置における前記サービスに係る所定の秘密計算の結果を、秘密分散法により復号して取得する第１のグループ同期部を、を有し、
    　前記第２の装置は、
    　前記第１の装置から配布された前記シェアを取得するシェア取得部と、
    　取得した前記シェアにつき、当該シェアに係る前記ＶＣに含まれるＩＤ情報の値が等しいものをグループ化して前記グループＩＤを発行し、前記グループＩＤと当該シェアに係る情報をシェア保管部に保管する検証処理部と、
    　前記グループＩＤを含む情報を前記第１の装置に返却する第２のグループ同期部と、を有する、サービス提供システム。
  2. 　請求項１に記載のサービス提供システムにおいて、
    　前記第１の装置の前記シェア提供部は、前記ＶＣにおけるプライベート情報と非プライベート情報とを分離し、前記非プライベート情報は平文とした状態で秘密分散法により前記シェアに分割する、サービス提供システム。
  3. 　請求項２に記載のサービス提供システムにおいて、
    　前記第１の装置の前記シェア提供部は、秘密分散法により前記ＶＣを複数の前記シェアに分割する際に、所定の１つの前記シェアに前記非プライベート情報を設定し、他の前記シェアについては、秘密分散法により前記ＶＣを復号する際に影響を与えないデータで埋める、サービス提供システム。
  4. 　請求項２に記載のサービス提供システムにおいて、
    　前記非プライベート情報は、前記ＶＣにおけるフォーマット情報を含み、
    　前記第２の装置の前記検証処理部は、前記第１の装置から配布された前記シェアにつき、当該シェアに含まれる前記プライベート情報が、当該シェアに含まれる前記フォーマット情報に規定された要素に係るデータであることを検証する、サービス提供システム。
PCT/JP2020/046433 2020-12-11 2020-12-11 サービス提供システム WO2022123795A1 (ja)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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 アルカテル−ルーセント ユーザ関心プロファイルのプライバシ保護されたクラスタ化のシステムおよび方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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