Service providing system

Abstract

The client (2) has: a share providing section (22) for acquiring a VC from a VC storage section (24), dividing into a plurality of shares (26) by a secret sharing scheme, and distributing to the server (3); a group synchronization section (33) for acquiring information of a group ID related to a VC returned from the server (3), and storing in an ID storage section (25), and acquiring after reconstructing a predetermined secret calculation result related to a service in the server (3) according to the group ID. The server (3) has: a share acquiring section (31) for acquiring a share (26) distributed from the client (2); a verification processing section (32) for grouping a part having the same ID information value included in the VC related to the share (26), issuing a group ID, and storing in a share storage section (34); and a group synchronization section (33) for returning information including the group ID to the client (2).

Description

Technical Field

[0001] This invention relates to a technology for providing personalized services, and more particularly to an effective technology for a service delivery system that provides personalized services when the user is unknown. Background Technology

[0002] With the advancement of IT technology, the demand for personalized services is increasing, not only on the web but also in all scenarios. For users to accept personalized services, they must provide service providers with personal information such as their profile, preferences (interests, hobbies, and areas of interest), browsing or purchasing history, and information related to the disclosure of their personal data or privacy. Whether explicit or implicit, users accept personalized services based on their prior consent to the service provider's acquisition and use of this information. However, there is a risk of service provider information being leaked or misused by malicious individuals.

[0003] In response, mechanisms for providing personalized services while protecting user privacy are being researched. For example, Japanese Patent Publication No. 2015-532737 (Patent Document 1) describes a mechanism that does not restrict the use of applications, provides true protection for the private information of end users by offering anonymity to their private information, and allows the use of any computer device to receive personalized services or other applications or services that require user clustering based on the similarity of private data.

[0004] Prior art literature

[0005] Patent documents

[0006] Patent Document 1: Japanese Patent Publication No. 2015-532737 Summary of the Invention

[0007] The problem that the invention aims to solve

[0008] Based on existing technologies, for example, in cases where targeted advertising is provided to users grouped together based on interests or interests, from the perspective of whether the service can be provided to that user, for services with less stringent requirements, personalized services can be provided while protecting user privacy.

[0009] However, for example, for services that are only permitted to be provided to the target user, there is no consideration of providing personalized services to them while protecting their privacy, even when the user is unknown. Furthermore, for data provided by users to service providers in order to receive personalized services, there is no consideration of verifying that it is legitimate data belonging to that user.

[0010] Therefore, the purpose of this invention is to provide a service delivery system that can provide personalized services that include the user's inherent services while protecting privacy, without requiring identification of the user.

[0011] The description of the present invention and other objects and novel features will become clear from the description and the accompanying drawings.

[0012] Solution for solving the problem

[0013] The invention disclosed in this application is briefly described below for representative general content.

[0014] As a representative embodiment of the present invention, the service provisioning system is a service provisioning system that provides services to a user's first device via a network through one or more second devices, and has the following structure.

[0015] That is, the first device has: a share provisioning unit, which is used to obtain the VC from a VC storage unit that stores data VC that can be verified as the user, divide it into multiple shares through a secret sharing scheme, and distribute the shares to the second device; and a first group synchronization unit, which is used to obtain information of group IDs related to one or more VCs returned from the second device, store it in an ID storage unit, and obtain a predetermined secret calculation result related to the service in the second device by reconstructing it through a secret sharing scheme based on the group ID.

[0016] Furthermore, the second device includes: a share acquisition unit for acquiring the shares distributed from the first device; a verification processing unit for grouping portions of the acquired shares whose ID information values ​​contained in the VC associated with the share are equal, issuing the group ID, and storing the group ID and information associated with the share in a share storage unit; and a second group synchronization unit for returning information containing the group ID to the first device.

[0017] Invention Effects

[0018] The effects that can be obtained through representative content in the invention disclosed in this application are briefly described below.

[0019] That is, according to a representative embodiment of the present invention, personalized services including inherent services can be provided to a user without identifying the user, while protecting privacy. Attached Figure Description

[0020] Figure 1 This is a diagram that schematically illustrates a structural example of a service provision system as an embodiment of the present invention.

[0021] Figure 2 This is a schematic diagram illustrating an example of a mechanism in one embodiment of the present invention.

[0022] Figure 3 This is a schematic diagram illustrating an example of a mechanism for providing personalized services according to one embodiment of the present invention.

[0023] Figure 4 This is a schematic diagram illustrating another example of a mechanism for providing personalized services according to one embodiment of the present invention.

[0024] Figure 5 This is a schematic diagram illustrating an applicable example of a secret sharing scheme according to an embodiment of the present invention.

[0025] Figure 6 This is a diagram that outlines the data structure and specific data examples of the VC storage unit in one embodiment of the present invention.

[0026] Figure 7 This is a diagram that outlines the data structure and specific data examples of the VC storage unit in one embodiment of the present invention.

[0027] Figure 8 This is a diagram that outlines the data structure and specific data examples of the ID storage unit in one embodiment of the present invention.

[0028] Figure 9 This is a diagram that outlines the data structure and specific data examples of the share storage unit in one embodiment of the present invention.

[0029] Figure 10 This is a diagram that outlines the data structure and specific data examples of the share storage unit in one embodiment of the present invention.

[0030] Figure 11 This is a schematic diagram illustrating an example of a processing flow from the client to the server, up to the point of verification on the server, in one embodiment of the present invention.

[0031] Figure 12 This is a schematic diagram illustrating an example of a processing flow from performing share verification in a server to providing personalized services, according to one embodiment of the present invention. Detailed Implementation

[0032] Hereinafter, embodiments of the present invention will be described in detail based on the accompanying drawings. Furthermore, in all the drawings describing the embodiments, the same reference numerals are generally used for the same parts, and repeated descriptions are omitted. On the other hand, there are cases where parts described with reference numerals in a certain drawing may be mentioned in other drawings but not illustrated again, although they are referred to with the same reference numerals.

[0033] <Overview>

[0034] As one embodiment of the present invention, the service provision system implements the following mechanism: users enjoying the service provide data related to themselves to the service provider, who then provides personalized services based on this data. In this embodiment, the data provided by the user is verifiable credentials (hereinafter sometimes referred to as "VCs") that can be verified as the user's own data. This limits the provision of inherent services permitted for that user. Furthermore, the service provider cannot determine the user's identity based on the provided data (there is no need to determine the user's identity), thereby protecting the user's privacy.

[0035] In this embodiment, so-called secret computation technology is used as a privacy protection mechanism to prevent service providers from identifying the user based on the data provided by the user. Secret computation is a technology that performs calculations directly on encrypted computational data and obtains the results, thus hiding the computational data or the calculation process.

[0036] In this embodiment, multi-party computation (MPC) is used as a method for secret computation. That is, user data is divided into multiple shares through a secret sharing scheme and configured in an isolated state on different servers. At the same time, on the server side, while communicating between servers, addition, multiplication and other calculations are performed to obtain the calculation result while maintaining data confidentiality.

[0037] MPC, with its Functional Completeness, can compute arbitrary function algorithms while keeping data hidden. Since the computation results are also secretly shared, as long as the participating parties do not provide shares to each other or external parties and allow reconstruction, reconstruction can only be performed by the person who provided the data—the user who allowed the collection of shares. The server cannot view the provided data or computation results. As long as the computation results are not reconstructed by unintended parties, they remain hidden, thus preventing so-called output privacy from becoming a problem.

[0038] Therefore, calculation results (or personalized services based on them) can be provided to the user directly without knowing the data provided by the user to the service provider, and without needing to identify the user. Alternatively, as a secret-sharing scheme, an additive secret-sharing scheme with a (k, n) threshold (n ≥ k ≥ 2) can be used.

[0039] On the other hand, since user-provided data is processed as a verifiable VC, information representing the ID (identity number) is associated with each piece of data. While a so-called centralized ID could be used as the basis for managing this ID, this implementation uses a mechanism for Decentralized Identity (DID), which utilizes blockchain and shared ledger technology. Standardization of DID specifications is currently underway, but as the user's personal ID information, the wallet address (Wallet Address, sometimes referred to as "WA"; additionally, sometimes unique metadata such as the network or protocol used to provide the DID) in the blockchain is associated with each piece of data.

[0040] Furthermore, the data processed using DID can be in any format that VC can use (for the definition of the data model, refer to the following W3C recommendation: https: / / www.w3.org / TR / vc-data-model / #:~:text=Data%20derived%20from%20one%20or,a%20process%20of%20cryptographic%20verification.), and any data type that can be represented by a sequence or associative sequence (Map format) is acceptable. For example, JSON (JavaScript Object Notation), YAML, CBOR (Concise Binary Object Representation), TOML, etc., can be used, but in this implementation, unless otherwise specified, JSON (JSON-LD) will be used.

[0041] By using the DID mechanism, identity verification can be performed on any object based on the user's intention. In this embodiment, the DID mechanism can be used not only for identity verification, but also as a method to indicate the user's intention to grant permission for data collection and use to any object.

[0042] Furthermore, in this embodiment, DID is used as an example of a method for processing data as a VC. Therefore, signed data is represented as "VC" corresponding to the DID terminology. However, the method of reproducing this embodiment is not limited to using DID, and can therefore be used in data formats different from the VC defined by the DID specification. It can be appropriately used if the data corresponding to the VC in the DID satisfies all of the following conditions.

[0043] 1. There exists an issuer responsible for issuing data, and digital signatures are assigned as a method to prove that the data was issued by the issuer.

[0044] 2. The data contains information used to represent IDs (identity numbers) (e.g., WA or personal identification number, passport number, etc.).

[0045] 3. The data issued is structured data such as sequences, related sequences, JSON, YAML, TOML, or structured data sets. Even if the format and features are separate, it can be restored as long as the meta-information such as the sequence number or attributes assigned to each feature is provided.

[0046] 4. It can uniquely determine the storage location of ID (identity number) information in structured data.

[0047] 5. The data includes information about the algorithm used to uniquely identify the digital signature and the method for obtaining the public key.

[0048] 6. Perform digital signatures on structured data or the entire structured data set simultaneously.

[0049] As an example of satisfying condition 3 above, for data like [a,b,c], such as (0,a), (1,b), (2,c), if the correspondence between the sequence number and the feature is unique, then the original data like [a,b,c] can be reconstructed based on this information. Similarly, for example,

[0050] Data like {"name":"alice","age":42} can be accessed via ("name", "alice", "age":42}.

[0051] "alice" and ("age", 42) can be restored. Even nested data such as [[a,b,c], [d,e], [f]] are the same, as long as it allows for the restoration of (0,0,a), (0,1,b), (0,2,c), etc.

[0052] If the sequence numbers (1,0,d), (1,1,e), (2,0,f) and the elements are uniquely matched (mapping), the original data can be restored.

[0053] As an example of satisfying condition 4 above, for example, if it is a sequence, there is a provision (or setting) that "the zeroth element is an identification number"; if it is a DID, there is a provision (or setting) that "the value of the sub attribute is an identification number (especially WA)", so that the storage location of the ID information can be uniquely determined.

[0054] As a method to satisfy condition 6 above, when the set of structured data is set as

[0055] {x1,x2,...,x j When j is the number of elements, the signature σ must be obtained using the Sign algorithm to combine the private key sk and the structured data set (x1||x2||...||x). j ) as input value.

[0056] σ=Sign(sk,(x1||x2||...||x j ))

[0057] Additionally, for (x1||x2||...||x j The value and structure of the concatenation part (||) of ) are arbitrary.

[0058] The result is that it requires the signature σ, the public key pk, and {x1, x2, ..., x}. j The validation algorithm, Verify(pk,σ,(x1||x2||...||x), uses the input values ​​as input values. j The result of the function is Accept. Taking JWS (JSON Web Signature) as an example, the collection of structured data includes a header and a payload. The value of combining the header and payload with a dot (.) is used as the input value, and the signature is calculated.

[0059] Figure 2This is a schematic diagram illustrating an example of the mechanism in one embodiment of the present invention. User 4's client 2 has a VC241, which contains, for example, data acquired by a data collection device 6 such as a camera located on the street (in this case, although it is camera footage, it could also be data collected by different devices / services, such as purchase history of a billing service), digitally signed and issued (Figure [2]) as the private key of a public key pair logged in in PKI (Public Key Infrastructure) or DPKI (Decentralized PKI) 5 (Figure [1]). As described above, in this embodiment, VC241 is represented by JSON and includes the WA of the DID as ID information. User 4's client 2 authenticates the issuer (data collection device 6) by verifying the digital signature of VC241 using the public key logged in in DPKI 5 (Figure [3]).

[0060] In this embodiment, based on user 4's agreement to provide the VC241 to the service provider ([4] in the figure), user 4's client 2 will provide the shares 26a and 26b obtained through the secret sharing of VC241 to servers A (3a) and B (3b) participating in the MPC ([5] in the figure), respectively. Figure 2 In the example, VC241 is secretly shared into two shares and provided to two servers. However, it can also be secretly shared into more than two shares, that is, a secret sharing scheme based on the (k, n) threshold (n≥k≥2) is performed, and each share is provided to different servers.

[0061] In the service provider, these shares 26a and 26b (ciphertext) and the public key (plaintext) logged in DPKI5 are used as input values ​​and verified by MPC based on server A (3a) and server B (3b) (Figure [6]). When utilizing (Figure [7]), the computation result is obtained without obtaining the contents of the original VC241 by performing MPC in server A (3a) and server B (3b), and personalized services are provided based on this.

[0062] On the other hand, even if the service provider cannot know the content of the original VC241 or the calculation result, it cannot be said that privacy is fully protected if it can know which user 4's data it is, that is, it can identify the user. Therefore, in this embodiment, for more than one VC241 provided to the service provider, under the state of encrypted content, based on confirming (1) that the content has not been tampered with and (2) that each VC241 is associated with the same user 4, the VC241 provided to the service provider is grouped and assigned a group ID, and the group ID is returned to the user 4. Thus, while hiding which user 4's data it is from the service provider, the user 4 requests personalized services based on the returned group ID and accepts them.

[0063] Additionally, in the MPC processing on the service provider side, computation can be delegated to a trusted external environment, with the computation results returned to servers A (3a) and B (3b) in a secretly shared manner. Alternatively, the group ID can be passed to the delegating party, and the transmission of the computation results can be delegated to an agent. For example, instead of performing computation within the MPC, computation can be performed by a method outside the MPC by allowing the TA (Trusted Application) within the TEE to be reconstructed, and the computation results can be secretly shared again to servers A (3a) and B (3b) (while simultaneously, all information stored on the delegating party can be deleted from the delegating party's environment). This allows for a trade-off between security and performance.

[0064] Figure 3 This is a schematic diagram illustrating an example of a mechanism for providing personalized services according to one embodiment of the present invention. In the example shown in the figure, the following states are illustrated: the VCs for “Data 1”, “Data 2”, and “Data 3” are stored in user 4a’s wallet 211a, while the VCs for “Data 4” and “Data 5” are stored in user 4b’s wallet 211b.

[0065] Furthermore, it indicates that user 4a provided "Data 1" and "Data 2" to receive a certain service. In response, the service provider (server) issued a group ID such as "Group 1" and grouped these data. Similarly, it indicates that user 4a provided "Data 2" and "Data 3" to receive other services. In response, a group ID such as "Group 2" was issued and grouped these data. The issued group IDs of "Group 1" and "Group 2" are returned to user 4a, who is the provider of the object data. Similarly, it indicates that user 4b provided "Data 4" and "Data 5". In response, a group ID such as "Group 3" was issued and grouped these data. The group ID of "Group 3" is returned to user 4b.

[0066] In this scenario, for example, even if the administrator 7 (who has access to the database in an environment where the number of accesses is less than the threshold k required for the reconstruction of the secret sharing scheme) on the service provider side references the database content, the content cannot be accessed because any data (through secret sharing) is encrypted. Furthermore, not only is it impossible to know whether user 4a or user 4b is actually present, but even the situation where any data is associated with each person's wallet 211a or wallet 211b's WA is unknowable. That is, it is possible to achieve uncertainty in the administrator 7 (service provider) regarding the identity of the person who provided the data.

[0067] On the other hand, for administrator 7, for example, it is possible to know that "Data 1" and "Data 2" contained in "Group 1" are associated with "the same person". That is, personalized services can be provided to "someone" in "Group 1". User 4a, who has been given the group ID of "Group 1", can use that group ID to request personalized services based on the data of "Group 1". That is, for the calculation result based on "Data 1" and "Data 2" of "Group 1", by associating the group ID of "Group 1" with the calculation result on the service provider (server) side, user 4a can use the group ID of "Group 1" to make a request.

[0068] Similarly, for administrator 7, since they know that "Data 2" and "Data 3" in "Group 2" are associated with "the same person," they can provide personalized services to "someone" in "Group 2." User 4a, who has had their group IDs returned for "Group 1" and "Group 2," can receive services based on "Group 1" and services based on "Group 2," respectively. However, administrator 7 cannot know that "Group 1" and "Group 2" are associated with "the same person." That is, they cannot merge "Data 1" and "Data 3" associated with the same user 4a. The same applies to "Group 3." Because administrator 7 knows that "Data 4" and "Data 5" are associated with "the same person," they can provide personalized services to "someone" in "Group 3."

[0069] Figure 4 This is a schematic diagram illustrating another example of a mechanism for providing personalized services according to one embodiment of the present invention. In the example shown, the following state is illustrated: "Data C1" and "Data C2" are stored in user 4c's wallet 211c, while "Data D1" and "Data D2" are stored in user 4d's wallet 211d. User 4c illegally obtains "Data D1" from user 4d's wallet 211d and adds it to their own wallet 211c. Furthermore, it is shown that user 4c provides "Data C1" and "Data C2" to receive a certain service, groups these data, and issues a group ID such as "Group 4".

[0070] Here, assuming user 4c provides "Data C2" and "Data D1" to receive other services, and these data are grouped and issued with group IDs like "Group 5," when other people's data is processed as information from the same group, the calculation results based on these data will be illegal results generated not based on user 4c's real information, and the content of the provided services will be corrupted. However, as mentioned above, since the data administrator cannot control the encrypted data content, it is impossible to confirm whether the data belongs to the same group (in...). Figure 4 In the example, the data provided (for "Group 5") is not necessarily from the same user (in...). Figure 4 In the example, it is associated with user 4c).

[0071] Therefore, in this embodiment, by setting the user-provided data as a VC containing ID information, it is possible to verify that the data belongs to the user. Simultaneously, on the service provider (server) side, for each piece of data provided as belonging to the same group, after verifying whether all data share the same ID information via MPC, if it can be confirmed that all data share the same ID information, these data are grouped. That is, in Figure 4 In the example, "Data C2" and "Data D1" are not grouped, and a group ID like "Group 5" is not issued (or, a group ID like "Group 5" can be temporarily issued as a "treated group ID" and then discarded if it cannot be confirmed later that all data belongs to the same ID). Therefore, data belonging to a certain group can be treated as data from the same user. Furthermore, on the service provider's side, even if they can determine that data with the same ID belongs to "the same person," they cannot determine "whose" data it is.

[0072] <Secret Sharing>

[0073] Figure 5 This is a schematic diagram illustrating an applicable example of a secret sharing scheme according to an embodiment of the present invention. The plaintext VC241 before being fractionalized by the secret sharing scheme (in this embodiment, for example, the header and payload of the JWS are strings connected by dots (.), and are decoded beforehand if Base64URL encoded) consists of data D and Dsig as its digital signature (in the JWS signature section, it is decoded beforehand if Base64URL encoded). Here, data D consists of its format portion F, ID information SUB_WA, and m attribute information (in this embodiment, for example, declarations (key-value pairs) in JWT (JSON Web Token)) C1 to Cm.

[0074] Additionally, the format part F is the format part in the JSON (specifically, the part after removing the value of the privacy-protected object according to this embodiment from the Claims Set of the payload), including not only the payload in the JWS but also the header. Furthermore, regarding SUB_WA, as mentioned above, in this embodiment it is set to the WA (wallet address) of the DID, but it can be consistent with the identity information within each VC, and can also be a personal identification number, passport number, or other identity information.

[0075] In this embodiment, the format portion F of the declaration set, each declaration C1 to Cm, and SUB_WA are secretly shared in a separable form. This is because when secret sharing is performed on VC241 as a JWS and shares are generated, the server side distributing the shares cannot distinguish between the format portion F of the declaration set and the share portion of the data (in this embodiment, SUB_WA and the values ​​of each declaration C1 to Cm that are privacy-protected objects). This may hinder the server-side MPC from verifying and using the data. As a method other than separation, there is, for example, a method in which the share of the target privacy information can be obtained afterward, particularly by assigning information related to the ciphertext of the privacy information in the byte column of the ciphertext of the declaration set, including information on where the privacy information is located and metadata containing key information.

[0076] Furthermore, regarding the format portion F, since it does not contain user 4's private information, it does not need to be hidden and does not need to be fractionalized based on secret sharing. Instead, it is distributed to the servers participating in MPC in its plaintext state. In this case, when MPC is performed on each share 26 on the server side, if the format portion F is treated as a share and set as an object of MPC, the calculation cannot be performed correctly because the plaintext of the format portion F is included in multiple shares.

[0077] Therefore, in this embodiment, the format portion F is set to plaintext. On the other hand, in order to correctly perform MPC on this format portion F, virtual fractionalization is performed using the method shown below. Specifically, for example, only one fraction 26 containing all the actual content in the format portion F is set among all servers, and for the fractions 26 of other servers, a portion of the format portion F is "zeroed out". "Zeroing out" refers to an operation based on the Zero function, for example, transforming arbitrary data S into S' according to the following principles.

[0078] S' = Zero(S)

[0079] S=Reconstruct(S,S',S',...,S')

[0080] That is, the so-called "zeroed" S' is the data that results in S when reconstructed based on the shares where only one is S and all others are S', and as long as the data meets this requirement (i.e., it has no impact during reconstruction), S' can be any value. In an additive secret sharing scheme, S' can be set to "0" of the same size as S, for example.

[0081] If the i-th server 3 (participant) is denoted as P i , then for each P where 1 < i ≤ n i ,

[0082] Execute S' = Zero(S)

[0083] To replace S with S', so that through the S saved by the first P1 and the S' saved by each P i (1 < i ≤ n),

[0084] Reconstruct(S, S', S',..., S') = S

[0085] Then, S can be obtained through reconstruction. That is, S and S' (zero value) can be treated as the pseudo-shares of S.

[0086] For example, in the case of data represented by "1234", when it is "zeroed",

[0087] Then, like Zero(1234) = 0000

[0088] It is replaced with the identity element in the Reconstruct function. Therefore, among the shares saved by all servers, when reconstructing based on the shares where only one share is "1234" and all other shares saved by the servers are "0000",

[0089] 1234 + 0000 + 0000 +... + 0000 = 1234

[0090] Or,

[0091] 1234 @ 0000 @ 0000 @... @ 0000 = 1234

[0092] (" @" represents the exclusive OR logic)

[0093] , the original plaintext "1234" can be obtained.

[0094] The method of initially setting the format part F to plaintext is not limited to the above-mentioned "zeroing". For example, a secret sharing scheme can be performed. That is, all parties (server 3) that hold share 26 except for one party issue random numbers, and these random numbers are collected by one party. On the party that has collected the random numbers, the random numbers issued by each party are regarded as shares. For example, by taking the result of subtracting all random numbers from the plaintext or performing an exclusive OR operation as the new share, additive secret sharing can be reproduced. That is, when the random numbers issued by each party are set as R i (1 < i ≤ n), then on the party that has collected the random numbers from each party, when

[0095] S’ = S - (R2 + R3 +... + R n )

[0096] Or,

[0097] S’ = S ⊕ R2 ⊕ R3 ⊕... ⊕ R n

[0098] when, then

[0099] Reconstruct(S’, R2, R3,..., R n ) = S

[0100] , S can be restored. That is, S’ and R i (1 < i ≤ n) can be set as the pseudo-shares of S.

[0101] In this embodiment, as the method of initially setting the format part F to plaintext, the above-mentioned "zeroing" is used. Hereinafter, Zero(F) in which the format part F has been "zeroed" is denoted as F’. In addition, when the format part F’ has been calculated, the format part F is not used in the MPC. However, for the purpose of referring to the key information, the format part F may be saved without being deleted separately. Furthermore, as will be described in detail later, when the format part F contains a part replaced by the share of the privacy information (the share of the declared value included in share 26), only the part other than the marker (e.g., the string to be replaced) used to represent the replacement object is zeroed.

[0102] The shares 26_1, 26_2... 26_n in the figure respectively represent the n shares 26 obtained by secretly sharing VC241 under the above conditions. For example, the nth share 26_n includes the nth share of VC241, that is, the nth share D_$n of data D and the nth share Dsig_$n of digital signature Dsig. Further, it also includes: the format part F of the plaintext (or the format part F' of the participating party after "zeroing" the format part F), VC_$n formed by connecting the nth share SUB_WA_$n of ID information SUB_WA and the nth shares C1_$n~Cm_$n of each statement C1~Cm.

[0103] In addition, the connection here refers to the operation of replacing the value (plaintext) of the statement that is equivalent to the private information in the information contained in data D with their respective shares (ciphertext), and it is defined as the Replace function. That is, in the ith server P i (i ∈ {1, 2,..., n}), the following replacement is implemented.

[0104] In P1,

[0105] VC_$1

[0106] = Replace(F, SUB_WA_$i,

[0107] C1_$i,..., Cm_$i)

[0108] In P i (1 < i ≤ n),

[0109] VC_$i

[0110] = Replace(F’, SUB_WA_$i,

[0111] C1_$i,..., Cm_$i)

[0112] In this way, each share 26 has a structure for separating the format part F (plaintext) and the shares of each statement C1~Cm. Thus, during MPC on the server side, even if the format part F included in each share 26 is processed as a share, for the "zeroed" format part F', as described above, it will not affect the result of the Reconstruct function. Therefore, MPC can be performed based on the content of the share 26 that actually includes the plaintext of the format part F which is only one in all the shares.

[0113] Furthermore, even without the aforementioned "zeroing," and assuming all share 26 formatted portions F contain actual content, for example, it is possible to use only any one server 3 (P). i The format part F of the saved share 26 is ignored, and the format parts F of other shares 26 are processed in the same way as "zero" to perform verification.

[0114] In addition, through the various methods described above, besides pre-saving the format part F as plaintext, the portion obtained after fractionalizing the format part F through secret sharing can also be distributed together.

[0115] In addition, Figure 5 In the example, VC241 is divided into a data part and a format part. While only the format part (format part F) is saved as plaintext, the other data parts are encrypted through secret sharing, generating share 26. However, for the claims C1 to Cm in the data part, it is also assumed that there is private information (secret information that the user wants to hide) and non-private information (information that the user believes can be disclosed). For claims that are equivalent to non-private information, they can also be processed directly as plaintext without encryption (shared) in the same way as format part F. In this case, for each claim, information on whether the saved data (value) is private information (whether it is shared) can be saved separately. For example, the plaintext of the data (value) can also be included in format part F.

[0116] <System Composition>

[0117] Figure 1 This is a schematic diagram illustrating an example structure of a service provisioning system as an embodiment of the present invention. The service provisioning system 1, for example, has a structure in which a client 2 held by a user 4 and multiple servers 3 can communicate with each other via a network such as the Internet (not shown). The client 2 is a device (first device) that primarily stores and manages information about the user 4's VC241, and is installed, for example, by an information processing terminal such as a PC (Personal Computer), tablet terminal, or smartphone.

[0118] On the other hand, server 3 is a device (second device) that has the function of isolating and storing multiple shares 26 generated by secretly sharing VC241 in client 2, while performing MPC based on these shares 26 to obtain calculation results for providing personalized services. For example, it is installed by a server device or other device such as a virtual server built on a cloud computing service. Each server 3 is managed by a different person / business entity that will not collude for the purpose of illegally manipulating the shares 26. Preferably, they are physically isolated from each other, but this does not exclude a structure in which multiple virtual servers built on a single server device managed by the same person / business entity are logically isolated from each other.

[0119] The following describes the structure of client 2 and server 3 according to the processing flow.

[0120] [Client]

[0121] Client 2, for example, executes software such as an operating system (OS) or database management system (DBMS) deployed from a recording device such as an HDD (Hard Disk Drive) or SSD (Solid State Drive) on memory, or a web browser or application running thereon, via a CPU (Central Processing Unit) not shown, thereby realizing the various functions of client 2 described above. Client 2 includes, for example, a VC processing unit 21, a share provisioning unit 22, and a group synchronization unit 23, which are installed via software. In addition, it includes data storage units such as a VC storage unit 24 and an ID storage unit 25, which are installed via a database or file.

[0122] The VC processing unit 21 has the aforementioned DID function, which enables user 4 to process data issued by the issuer as VC241. As described above, the VC241 obtained via the VC processing unit 21 includes information representing the ID (identity number) (e.g., the WA of the DID) and attribute information (e.g., "purchased product" Apple), "amount (yen)" 100, etc.). The obtained VC241 is recorded and stored in the VC storage unit 24. User 4 may also have a user interface for storing and managing their own collection of VC241 in a wallet. When installing the VC processing unit 21, existing DID products such as those from Microsoft and SDKs (Software Development Kits) can be appropriately used, for example.

[0123] Figure 6 and Figure 7This is a diagram that schematically illustrates the data structure and specific data examples of the VC storage unit 24 in one embodiment of the present invention. In this embodiment, for example, in... Figure 5 In the example shown in the VC241 content, in Figure 6 In the table of VC Storage Department 24a, it is indicated that data D, its digital signature Dsig, format portion F, and ID information SUB_WA portion are stored in their respective columns; Figure 7 In table 24b of the VC storage section, it indicates that the keys and values ​​declared as C1 to Cm, as well as the data types of the values ​​(string, number (int, double), boolean, null / empty, object (JSON object), array, etc. are standard types, but unique types can also be defined) are stored in corresponding columns. Additionally, in Figure 6 In the VC storage section 24a, it is indicated that the VCID, which uniquely identifies each VC241, will also be saved as a key; Figure 7 In VC Storage 24b, it is stated that the declaration ID that uniquely identifies each declaration will also be saved as a key.

[0124] exist Figure 6 The JWS data is stored as is in the data D of the VC storage section 24a. On the other hand, in the format section F, it indicates that the data is stored in a state where only the value portion of the declaration contained in the JWS is replaced with a marker such as "${SUB_WA}" or "${declaration ID}". This section is stored, for example, by... Figure 7 The declaration ID used to represent the corresponding declaration in VC custody section 24b (in Figure 6 and Figure 7 In the example, it is "C001" or a string of identification information (in... Figure 6 The value (in the example "SUB_WA") represents the ability to substitute between values. In this implementation, the declared value and the substitution object can be distinguished by enclosing it with "${}", but any representation method can be used as long as a parser that can correctly analyze the representation of the substituted data (e.g., JSON syntax) can be installed.

[0125] return Figure 1 The share-providing unit 22 of client 2 has the following function: it encrypts the portion of VC241 stored in VC storage unit 24 designated for user 4 using a (k,n) threshold secret sharing scheme to generate multiple shares 26, and provides each share 26 to any server 3. The method for generating multiple shares 26 by secretly sharing VC241 is as follows: Figure 5As shown in the example, in this case, since n shares 26 are generated, it is preferable to provide one share 26 to each of the n servers 3. On the other hand, if more than k shares 26 are not provided to one server 3, the original VC241 will not be restored in one server 3, so it is not excluded that within this limit, the number of servers 3 is less than n (providing multiple shares 26 to one server 3).

[0126] When providing data to server 3 in the form of share 26, as described above Figure 3 As shown in the example, a group ID (in the sense of "the group ID of the data lent by client 2 to server 3," hereinafter referred to as "the lending group ID") is issued in server 3 and returned to client 2 of user 4. In this embodiment, as described later, in addition to the lending group ID, information that makes the claim unique, such as key, data type, and value, is also returned, corresponding to the lending claim IDs issued in server 3 for each claim of VC241. Furthermore, trust information used for subsequent authentication may also be returned only on the initial return. In the figure, these are summarized and represented as lending information 35.

[0127] The group synchronization unit 23 has the following functions: cooperating with the group synchronization unit 33 of the server 3 (described later), it obtains the lending information 35 returned from the server 3, records / stores its content in the ID storage unit 25, and reconstructs the data, including the calculation results, through a secret sharing scheme. Subsequently, it sends trust information to the server 3 as needed, synchronizing the lending group ID (and lending claim ID) returned from the server 3 with the calculation results (shares) of MPC based on share 26, which are grouped and managed by the group ID in the server 3, and reconstructs the data based on the shares of the obtained calculation results, thereby enabling it to receive calculation results (plaintext) based on the claim data associated with the group ID. That is, the act of the server 3 publishing the shares of the calculation results associated with the group ID is a way of sending personalized services.

[0128] In addition to the lending group ID, processing of data based on the lending claim ID can also be performed by specifying the lending claim ID. For example, rights corresponding to the "deletion right" or "correction right" provided for in the GDPR (General Data Protection Regulation, EU) can be enforced on object data.

[0129] Figure 8This diagram outlines the data structure and specific data examples of the ID storage unit 25 in one embodiment of the present invention. The content of the lending information 35 returned from the server 3 indicates that the lending group ID, lending declaration ID, and the key and data type of the object declaration are stored separately. Furthermore, for each declaration, the content of the value reconstructed through a secret sharing scheme is stored. In addition, this table includes not only the data (declarations) provided by VC241, but also data obtained by reconstructing the calculation results of MPC on the server 3 side based on the data (declarations) provided by VC241. By assigning a declaration ID to the calculation results in the same way, the same operations as those performed on the data provided by VC241 can be performed. That is, the calculation results can be further used for other calculations / processing.

[0130] [server]

[0131] return Figure 1 Server 3, for example, uses a CPU (not shown) to execute middleware such as an OS or DBMS deployed from a recording device such as an HDD or SSD on memory, or software running thereon, thereby realizing the various functions of server 3 described above. Server 3 includes, for example, a share acquisition unit 31, a verification processing unit 32, and a group synchronization unit 33 installed by software. In addition, it has a data storage unit such as a share storage unit 34 installed via a database or file.

[0132] The share acquisition unit 31 has the following functions: receiving / acquiring shares 26 provided by client 2 and temporarily storing them in a recording device such as a memory. The verification processing unit 32 has the function of performing the following three verification processes on the shares 26 temporarily stored by the share acquisition unit 31 while utilizing MPC. To perform these various verification processes, it also includes a publisher verification unit 321, a component verification unit 322, and a grouping unit 323. Furthermore, the order in which the following three verification processes are performed is not particularly limited. That is, all three types of verification processes can be executed in parallel.

[0133] As the first verification, the issuer verification unit 321 has the function of verifying whether the person who issued the object data is the correct issuer. This verification process implements a verification algorithm corresponding to the signature algorithm used for signing the digital signature computation via MPC. The signature algorithm is determined by the information contained in the format section F. For example, it is determined by the value of the key "alg" in the JWS header. An MPC-based integrity verification algorithm (VerifyMPC function) is executed with the public key obtained from PKI or DPKI based on the value of the key "kid", VC_$i, and the share Dsig_$i of the digital signature contained in VC241 as input values, and the result is confirmed by reconstructing the share of the verification result.

[0134] As a second verification, verification unit 332 verifies whether the share of privacy information contained in VC_$i is the share after secretly sharing the data contained in VC241. Specifically, for example, with Figure 5 Taking share 26_n as an example, the value formed by concatenating the format part F or F' with the shares C1_$n to Cm_$n of each declaration C1 to Cm, i.e., VC_$i, is equivalent to the share D_$n of the entire VC241 through the EqualMPC function. The result is confirmed by reconstructing the share of the verification result.

[0135] Furthermore, the first and second verifications can be performed by a single verification. That is, as shown below, if the algorithm for integrity verification in MPC is executed with the public key obtained from PKI or DPKI, the value formed by concatenating the format part F or F' with the shares C1_$n to Cm_$n of each declaration C1 to Cm, and the digital signature Dsig_$i contained in VC241 as input values, and the result is confirmed by reconstructing the shares of the verification result, then both the first and second verifications can be performed.

[0136] [v]←VerifyMPC(pk,[Dsig],[VC])

[0137] {Accept,Reject}

[0138] ←Reconstruct([v])

[0139] Furthermore, the values ​​within [] are simply represented as the shares to be secretly shared. For example, for any value X,

[0140] [X] = {X_$1, X_$2, ..., X_$n}

[0141] .Right now,

[0142] VC = Reconstruct([VC])

[0143] =Reconstruct(VC_$1,VC_$2,

[0144] ...,VC_$n)

[0145] The VerifyMPC function represents the integrity verification algorithm for digital signatures based on MPC. Furthermore, v represents the result of the verification performed by pk, Dsig, and VC using the integrity verification algorithm determined by the value of the key "alg".

[0146] As the third verification, the grouping unit 323 has the following function: when shares 26 related to multiple VC241s are acquired, it verifies whether the ID information of the VC241s included in each share 26 is the same as the ID information of other VC241s, and groups the data related to the VC241s with the same ID information.

[0147] Specifically, for example, when grouping p different VC241s q (q ∈ {1, 2,..., p}), the share of the ID information SUB_WA in VC2411 is set as REP_SUB_WA_$i, and the shares of the ID information SUB_WA in the other (p - 1) VC241s are set as sub q _$i, and when 1 < q ≤ p, EqualMPC (the EqualMPC function) is used to perform equivalence verification on REP_SUB_WA_$i and sub q _$i respectively.

[0148] [e q ← qualMPC([REP_SUB_WA],

[0149] [sub q )

[0150] {Accept, Reject}

[0151] ← Reconstruct([e q )

[0152] In addition, e q represents the result of equivalence verification on SUB_WA and REP_SUB_WA included in the q-th VC241 within the range of 1 < q ≤ p. In addition, the EqualMPC function represents equivalence verification based on MPC. If the ID information of all VC241s is the same value (if all Reconstruct([e q ) returns Accept when 1 < q ≤ p), the grouping is successful.

[0153] In the processing of the issuer verification unit 321, the processing of the inclusion verification unit 322, and the processing of the grouping unit 323, if Accept is returned in all verifications, a group ID is issued to VC241. In particular, in the equivalence verification of the grouping unit 323, even if there is one VC241 with different ID information, it can be grouped using only VC241s with the same ID information, or it can be discarded and a predetermined exception handling is performed. When VC241 is grouped, a declaration ID is further assigned to each value contained in each VC241. The assigned group ID and declaration ID are returned to client 2 as the lending group ID and lending declaration ID (with the attribute name of VC241) respectively by the group synchronization unit 33 described later.

[0154] Information related to the grouped VC241 is stored in the share storage section 34. Figure 9 and Figure 10 This is a diagram that schematically illustrates the data structure and specific data examples of the share storage unit 34 in one embodiment of the present invention. In this embodiment, for example, in Figure 9 In the example shown in the table of the share custody section 34a, the share of the lending group ID and the ID information SUB_WA are stored as information associated with the group ID. In the figure, the value of the ID information SUB_WA of the record with the lending group ID "Group 1" is represented by "30181B..." and a hexadecimal random number, which indicates that it is in the share (encrypted) state.

[0155] In addition, Figure 10 In the table of the share custody section 34b shown in the example, as information related to the claim ID, it indicates that in addition to the plaintext of the keys and data types in the claim (excluding the lending group ID, lending claim ID, and signature), information about the share of the value is also stored. In the figure, the record value of the claim with the key "name" is represented by a hexadecimal random number, which indicates that it is in a share (encrypted) state. Furthermore, it indicates that flag information is stored, which is used to determine whether the claim is non-private information and whether it can be shareized without secret sharing and is in a plaintext state. In addition, as mentioned above, for claims in a plaintext state, only one server 3 stores the plaintext content in the value, and the values ​​of the claim in other servers 3 are "zeroed out".

[0156] Group synchronization unit 33 collaborates with group synchronization unit 23 of client 2, and has the following function: For VC241 grouped by grouping unit 323, it returns the issued lending group ID, lending claim ID, and corresponding claim (key, value, data type, etc.) information as lending information 35 to client 2. Alternatively, it may further include trust information for subsequent authentication in the lending information 35 only during the initial return to client 2.

[0157] In the lending information 35 of the client 2 returned to the user 4, the privacy information of the user 4 itself is not included. However, for example, when the IP address of the destination client 2 is the same each time, there may be a risk of identifying the user 4 himself / herself. Therefore, for the communication between the server 3 and the client 2, for example, it is preferable to use a communication method that can hide the connection path such as Tor.

[0158] <Processing Flow>

[0159] Figure 11 It is a diagram showing an outline of an example of the processing flow from the client 2 to the server 3 for distributing each share 26 until verification in the server 3 in one embodiment of the present invention. First, in the client 2, the VC processing unit 21 obtains the VC 241 from the data received by the user 4 from the issuer and stores it in the VC storage unit 24 (S01). Then, the share providing unit 22 calculates n shares 26 (share 26_i (1 ≤ i ≤ n)) using the VC 241 stored in the VC storage unit 24 (S02), and sends them to a total of n servers 3 (in the example in the figure, the first server 3c (P1) and the i-th (1 < i ≤ n) server 3d (P i )) (S03). In addition, in the example in the figure, it is distributed to n servers 3 (server 3c and server 3d), but as described above, as long as the number of servers 3 is greater than the threshold k of secret sharing when calculating the share 26, the number can also be less than n.

[0160] In each server 3 (server 3c and server 3d) that has sent the share 26_i (1 ≤ i ≤ n), the share acquisition unit 31 acquires the share and temporarily stores it (S04). Then, when the format part F is virtually shared by the above method, in other servers 3 (i.e., server 3d (P i (1 < i ≤ n)) except for the server 3 that stores the plaintext (regarded as server 3c (P1)), the format part F is "zeroed" by the above method (S05).

[0161] Then, the verification processing unit 32 performs MPC between each server 3 (server 3c and server 3d) to perform three types of verification processing in the following steps S06 to S08. In addition, as described above, the order of performing the three types of verification processing is not particularly limited, Figure 11 The shown order is an example. In addition, the verification processing of steps S06 and S07 can also be combined into one verification processing.

[0162] As the first verification, the issuer verification unit 321 verifies whether the issuer of the original VC241 data is the correct issuer via MPC (S06). Specifically, it obtains the public key from PKI or DPKI in advance based on the value of the key "kid" in the JWS header of the format section F, and then determines the signature verification algorithm based on the value of the key "alg", and performs the verification on each server 3 (P1~P2). n The algorithm is pre-agreed upon among the parties. Then, the integrity of the signature is verified based on VC_$i and Dsig_$i contained in each share 26_i, and the result is confirmed by reconstructing the shares of the verification result.

[0163] As a second verification, the verification unit 322 verifies, via MPC, whether the share of privacy information contained in VC_$i is a share of data secretly shared with the original VC241 (S07). Specifically, for example, as described above, the VC_$i and D_$i contained in each share 26_i are equivalently verified via MPC, and the result is confirmed by reconstructing the shares of the verification result.

[0164] As a third verification, the grouping unit 323 groups VC241 using the ID information contained in each share 26_i that has the same information (S08). Specifically, for example, equivalence verification is performed on the shares of VC241 with ID information SUB_WA related to share 26_i and the shares of VC241 with ID information SUB_WA related to share 26_i. If all are the same value, the grouping is considered successful, and a group ID is issued for these VC241s. Even if there is a VC241 with a different value, only VC241s with the same value can be used for grouping. When a group ID is issued, a declaration ID is further assigned to the value contained in the VC241 related to share 26_i.

[0165] Then, it is determined whether all three verification processes are successful (all verification results are true (Accept)) (S09). Even if there is only one problem (more than one verification result is false (Reject)), a predetermined exception is handled (S10). On the other hand, if all verification results are successful in step S09, the issued group ID, claim ID, and corresponding claim (key, share value, data type, etc.) are stored in the share storage unit 34 by the group synchronization unit 33, and then returned to the client 2 as lending information 35 (S11) (S12). Upon receiving the returned lending information 35, the group synchronization unit 23 obtains the lending information and records it in the ID storage unit 25 (S13).

[0166] Especially when it is desirable to avoid waiting time in user 4 due to the processing time of steps S06 to S08, in the share acquisition unit 31 or group synchronization unit 33, assuming that all ID information of VC241 is the same after step S04, a "deemed group ID" can be issued (a trust is issued as needed, and at the same time) and the "deemed group ID" is returned to the group synchronization unit 23 of client 2. In this case, when all verifications in steps S06 to S08 are successful, the "deemed group ID", the lending declaration ID and the corresponding declaration (key, share value, data type, etc.) are stored in the share storage unit 34.

[0167] Furthermore, regardless of the input and output values ​​of the calculation, to prevent inconsistencies between the lending group ID and lending claim ID assigned to the data, communication can be established between the servers participating in the MPC to ensure consistency in the equivalence or numbering method of lending group IDs and lending claim IDs issued for the same data. Alternatively, the lending group ID and lending claim ID can be assigned different numbers for each server 3. In this case, for example, in client 2, each server 3 can maintain... Figure 8 The lending group ID and lending declaration ID shown are used in addition to a set of unique ID numbers for the shares that will be used in each data (declared value) during the reconstruction process.

[0168] Figure 12 This is a schematic diagram illustrating an example of a processing flow from the execution of share 26 verification in server 3 to the provision of personalized services, according to one embodiment of the present invention. In each server 3 (P i In (1≦i≦n)), the MPC performs calculations (S21) via the group synchronization unit 33, based on the declaration information associated with the lending group ID stored in the share custody unit 34. Then, a lending declaration ID is issued to the output result (share) of the calculation, and the same lending group ID used as the input value of the calculation is associated with the calculation result. This calculation result is then recorded as declaration information in the share custody unit 34 (S22). This declaration information includes the issued lending declaration ID, key information indicating the meaning of the calculation result, the share (value share) of the calculation result, and the data type of the calculation result.

[0169] In addition, regarding the calculation process in step S21, considering the load and efficiency of MPC's calculation process, as will be described later, for example, the analysis can be performed internally in server 3 after changing from the secret sharing scheme to a different calculation method, and the results can be secretly shared again, thereby improving processing efficiency.

[0170] In client 2, by sending data to each server 3 (P) i(1≤i≤n)) Send information corresponding to the lending group ID provided for receiving personalized services (VC241) to request the computation result (S31). In each server 3 (P i From (1≤i≤n)), the declaration information grouped according to the lending group ID is extracted from the share custody department 34 (also including the calculation result in step S21 above), and it is responded to the client 2 (S32). In the client 2, according to the declaration information grouped according to the lending group ID from each server 3 (P) i The share of the value in the declaration information of the response (1≤i≤n) is reconstructed through a secret sharing scheme to obtain the calculation result based on the declaration data associated with the lending group ID (S33). That is, the distribution of personalized services can be received.

[0171] <Usage Method>

[0172] In the structure shown above, for example, as a use case, suppose a service provider wants to "show alcohol advertisements to users aged 20 and above, and juice advertisements to users under 20." With user 4 providing age information as VC241, and server 3 issuing a corresponding group ID, on the server 3 side...

[0173] if (age >= 20)

[0174] "Beer Advertisement"

[0175] else

[0176] Orange juice advertisement

[0177] For groups containing "age" data, perform the processing (MPC) as described above. Associate the group ID applicable to the calculation with the calculation result.

[0178] On server 3, the calculation result ("beer ad" or "orange juice ad") remains in fractional form, and its content is unknown. However, in user 4's client 2, based on the calculation results returned from each server 3, it is reconstructed using the secret sharing scheme, thus enabling the user to receive personalized ads related to the calculation results. At this point, on server 3, due to processing in MPC via group ID, not only is the content of the calculation result unknown, but user 4, who provided VC241, cannot be identified. Therefore, inherent personalized services can be provided to user 4 while strongly protecting privacy information.

[0179] Furthermore, the MPC processing between servers 3 is computationally intensive and involves communication overhead, making it difficult to claim high efficiency. Therefore, for example, the internal secret sharing scheme could be changed to a different calculation method on the server 3 side to improve efficiency. For instance, the share 26 of VC241 acquired by each server 3 could be calculated based on the so-called homomorphic encryption transformed by MPC, the calculation result re-secretly shared, and the share of the result after reconstructing the homomorphic encryption through MPC derived from the share (this can sometimes improve performance depending on the environment or conditions). Alternatively, the share 26 acquired by each server 3 could be reconstructed within the TA (Trusted Application) operating on a hardware-based TEE, and the calculation result could be re-secretly shared, generating a share for output. However, especially in the latter case, the security of privacy protection might be reduced.

[0180] The invention described above is based on specific embodiments, but the invention is not limited to the above embodiments, and various modifications can be made without departing from its spirit. Furthermore, the above embodiments are detailed to facilitate understanding of the invention, but are not limited to having all the described components. Additionally, regarding a portion of the above embodiments, other components can be added, deleted, or substituted.

[0181] Furthermore, some or all of the aforementioned components, functions, processing units, and processing methods can be implemented in hardware, such as through design in integrated circuits. Alternatively, the aforementioned components and functions can be implemented in software by a processor interpreting and executing programs that perform their respective functions. The programs, tables, files, and other information implementing each function can be stored in recording devices such as memory, hard disks, and SSDs, or in recording media such as IC cards, SD cards, and DVDs.

[0182] Furthermore, the control lines and information lines shown in the above diagrams are for illustrative purposes only and may not represent all control lines and information lines in the installation. In practice, it can be assumed that almost all components are interconnected.

[0183] Industrial practicality

[0184] This invention can be used in service delivery systems that provide personalized services when the user's identity is unknown.

[0185] Symbol Explanation

[0186] 1. Service Provider System

[0187] 2 Clients

[0188] 3 servers

[0189] 3a Server A

[0190] 3b Server B

[0191] 3C, 3D Servers

[0192] 4. Users 4a to 4c

[0193] 5 DPKI

[0194] 6. Data acquisition equipment

[0195] 7 Administrators

[0196] 21 VC Processing Department

[0197] 22 Share Provision Department

[0198] 23 Synchronization Units

[0199] 24, 24a, 24b VC Storage Department

[0200] 25ID Storage Department

[0201] Shares of 26, 26_1 to 26_n

[0202] 31. Share Acquisition Department

[0203] 32 Verification Processing Department

[0204] 33 Verification Processing Department

[0205] 34, 34a, 34b Share Custody Department

[0206] 35. Loan Information

[0207] 211a~211d Wallets

[0208] 241 VC

[0209] 321 Publisher Verification Department

[0210] 322 includes a verification department

[0211] Group 323

Claims

1. A service provisioning system, specifically a service provisioning system that provides services to a user's first device via a network through one or more second devices, wherein, The first device has: A share provisioning unit is used to obtain one or more VCs from a VC storage unit that stores data VCs verifiable as the user, the VCs containing the user's ID information, and divide them into multiple shares through a secret sharing scheme, and distribute each of the shares to one or more of the second devices. And a first synchronization unit, which is used to obtain information about group IDs related to one or more VCs returned from one or more of the second devices, and store it in an ID storage unit, and obtain the predetermined secret calculation results related to the service in the second device by reconstructing them through a secret sharing scheme based on the group IDs; The second device has: A share acquisition unit, which is used to acquire the share distributed from the first device; The verification processing unit is used to verify, for the acquired share, whether the issuer of the VC is the correct issuer, whether the share is a share after the data contained in the VC is secretly shared, and whether the ID information value contained in the VC associated with the share is equal to the ID information value contained in other VCs. If all verifications pass, the portions with equal ID information values ​​are grouped, the group ID is issued, and the group ID and the information associated with the share are stored in the share storage unit. And a second synchronization unit, which is used to return information containing the group ID to the first device.

2. The service provisioning system according to claim 1, wherein, The share-providing unit of the first device separates private information and non-private information in the VC, and divides the non-private information into shares through a secret sharing scheme while the non-private information is in plaintext.

3. The service provisioning system according to claim 2, wherein, When the share providing unit of the first device divides the VC into multiple shares through a secret sharing scheme, it sets the non-private information for one predetermined share, and fills the other shares with data that does not affect the reconstruction of the VC through the secret sharing scheme.

4. The service provisioning system according to claim 2, wherein, The non-private information includes the formatting information in the VC. The verification processing unit of the second device verifies, for the share distributed from the first device, whether the private information contained in the share is data related to the elements specified in the format information contained in the share.

Images