Home

Abstract

We propose a technology called Zero-Knowledge Evidence that enables a third-party publication verifier to check the issue history online from a data publisher to a data holder. The data's issue history is anonymized with the signatures of the issuer and the holder and stored in the issue history storage area, enabling the issuance verifier to verify the anonymized issuance history using a Zero-Knowledge Proof protocol.

This service provides a web API that enables you to experience a series of actions by publisher, holder, and publication verifier to try out our Zero-Knowledge Evidence technology.

Background

Today's society consists of electronic data being exchanged by individuals and corporations. With the advancement of online services due to the COVID-19 pandemic, not only are companies exchanging data online, but ordinary individuals are also buying apps and goods online daily. The provenance of these data exchanges is usually managed by the platform that exchanges the data. For example, the online purchasing history is managed by the platform responsible for the purchasing system. Therefore, the proof of the transaction, such as purchases, is done at the sole discretion of the platformer. In particular, there is a possibility that a platformer may tamper with the transaction history in its favor.

Such monopolization of information by platforms is often cited as a social problem in the digital society. This technology is a mechanism that enables the party who made the transaction, rather than the platformer, to voluntarily verify the validity of the transaction history in the data exchange.

Related Technologies

A framework called Verifiable Credential [1] is gaining attention as a way to address information monopoly. The W3C promotes this framework as a mechanism for individuals, not controllers, to exercise sovereign control over electronic personal information.The framework consists of three parties:

• The person issuing the data (issuer)
• The person possessing the data (holder)
• The person verifying the data (verifier)

The main application in mind is personal credentials such as student IDs and driver's licenses. For example, in the case of a student ID, the issuer is a school, and the holder is a student. The student who is the holder can use the student ID he/she received to assert to the verifier that he/she is a student.

Now consider the case where an electronic receipt is issued as a Verifiable Credential. In this case, the issuer is the seller, and the holder is the buyer. Holders can use electronic receipts they receive to assert to verifiers what they purchased, independent of the platform.

However, this mechanism still makes it difficult for issuers to assert to verifiers what it sold, because holders has an electronic receipt and issuers does not. Therefore, if an issuer wants to assert its sales history, it must ask the receipt holder, who may not be willing to answer the request and who may have lost the receipt in the first place.

Thus, it is difficult to voluntarily prove the validity of data history in the framework of Verifiable Credentials alone. This technology also augments these related technologies and frameworks.

Technical Overview

This technology can objectively prove that data has been issued. The framework of our technology consists of three parties:

• The person issuing the data (issuer)
• The person possessing the data (holder)
• The person verifying that the data has been issued (issuance verifier)

The issuer publishes the data to the holder, and then prove to the verifier that it has published the data. The exposed APIs allows you to take the role of the issuer or the issuing verifier and experience the issuer handling the issuance, the issuer handling the generation of the issuance proof, and the issuance verifier verifying the issuance proof.

The technical components employed in this technology are described below.

Digital Signature

This technology utilizes electronic signatures to verify the identity of data. The issuer and the holder have signature keys to construct signatures and public keys necessary for verification.

Blockchain

Our technology uses a blockchain to store anonymized transactions in it. A blockchain could be regarded as a kind of database, where you can store anonymized transactions in a tamper-proof way. Specifically, we use blockchain as follows.

• During the publishing process, transactions are anonymized written to the blockchain.
• During the verification process, anonymized transactions are invoked from the blockchain.

Zero-Knowledge Proof

This technology utilizes Zero-Knowledge proofs to verify the integrity of anonymized transactions. Zero-knowledge Proof enables to the issuer that a given anonymized transaction corresponds a (part of) original transaction, which the issuer revealed to the issurance verifier, without giving any additional information to the issuance verifier. In particular, the issuer can prove that it was indeed issued while keeping a part of data hidden.

Local Token (LT) and Global Token (GT)

Local tokens and global tokens are technical terms explicitly used in this technology. A pair of local and global tokens are generated for a single data transmission operation, such as an issue or a transaction.

A local token is a token corresponding to the raw data of a transaction, generated explicitly by the triplet LT = (sn, x, r), where - sn is the ID of the token, - r is a random number, and - x is the raw data. Conceptually, it is equivalent to issuing x/sending x, which is information that the issuer secretly possesses.

A global token is a token that corresponds to data in a secret transaction. Specifically, it is generated by the triplet GT=(sn, C, pk), where - sn is the ID of the token, which equals to sn of the corresponding LT, - C is a commitment, which is the anonymization, under a random number r, of the raw data x of the corresponding LT, and - pk is the public key of the issuer.

Flow of Protocols and APIs

The flow of API in this technology is shown below. This API is based on a scenario where some data x is being passed from the issuer to the holder. The goal is for the issuer to record an anonymized transaction of "passing data x to holder" in the ledger, and later prove to the verifier that "passing data x to holder" was done.

Try our APIs

APIs for publishers

The publisher first anonymize transactions and registers them on the blockchain in the following sequence:

1-1 Serial Number Generation API

— Generates the serial number sn. This is a unique identifier for the raw data possessed by the issuer, the data registered in the blockchain, and so on.

1-2. Create Token API

• Creates a local token LT = (sn, x, r) and a global token GT=(sn, C, pk) corresponding to the serial number sn and the raw data x.
• r is a random number.
• C is the commitment generated from x, r, in this case a hash of the string combining x and r.
• pk is the public key of the issuer's digital signature.

1-3. Holder Signature API

• An API that presents a global token registered by the issuer and a local token, which contains the raw data x, to the holder for signature.
• This allows the holder to verify the data to be registered in the ledger so that the issuer can claim that it is not registering arbitrary data.

1-4. Get Holder's Public Key API

• An API to get the holder's public key. This is required to verify the signature generated in 1-3.

1-5. Issuer Signature API

• An API that verifies the signature provided by the holder and allows the issuer to generate a signature. The signature is done on the global token, the holder's signature, and the holder's public key.
• This quadruple of signature by holder, public key by holder, signature by issuer, and public key of issuer is called an evidence in this technology.

1-6. Asset Registration API

• An API to register global tokens and evidences in blockchain. This allowed issuers to store transaction processing in a hidden blockchain.

In the above processes, 1-1 registers the serial number in the blockchain, and 1-6 registers the global token and the evidence in the blockchain. The raw data x used in 1-2 will not be registered in the blockchain. The global token can be regarded as an anonymization of the raw data x.

APIs for Issuers: Zero-Knowledge Proof Processes

The above APIs allowed the issuer to keep an anonymized transaction of "the issuer passed x to the holder" in the ledger. Next, let us see APIs which enables to prove that "the issuer passed x to the holder", which may execute as in the following sequence.

2-1. Create Zero Knowledge Proof API

• This API creates a Zero-Knowledge Proof that certifies that C is made from x, using a commitment C, the raw data x that generated it, and a random number r.

The generated proof proves that "the issuer know the local token LT corresponding to the anonymized data GT recoded in the blockchain". This information is known by only the issuer. The registered evidence also confirms that the transaction was agreed upon between the issuer and the holder, thus proving that data x was passed to the holder.

APIs for publish verifiers

The issuance verifier verifies zero-knowledge proof that C was indeed generated from x by having the global token GT=(sn, C, pk) recorded in the ledger and the corresponding the raw data x presented by the issuer. This verification makes it possible to verify that an agreed-upon transaction between the issuer and the holder actually took place. Zero-knowledge proof techniques can operate to perform the above verification tasks while keeping the local token itself secure.

3-1. Get Verification Key API

• An API to get the verification key, which is required for the verification process.

3-2. Verification of Zero-Knowledge Proof API

• An API that takes a proof generated in 2-1, a commitment C (a component of GT), and raw data x (a component of LT) as parameters, and outputs the verification result of that proof.

As a result, the issurance verifier can verify that the global token GT = (sn,C,pk) corresponding to the raw data x is registered in the blockchain by being presented with the serial number sn, the raw data x, and a zero-knowledge proof. This verification process allows one to verify that an agreed-upon transaction between the issuer and the holder has actually taken place. Zero-Knowledge Proof technology works to perform the above verification while keeping the local token itself secure.

API Function Details

Try our APIs

Serial Number Generation API

path	method	explanation
/request_serial_number	POST	Generate a serial number

Parameters

None

Responses

{ 
    "serialNumber":<serial number> 
} 

parameter	type	explanation
serialNumber	string	a serial number

LT and GT Generation API

path	method	explanation
/create_tokens	POST	Generate a local token and a global token

Parameters

{ 
    "serialNumber":<serial number>, 
    "x":<raw data> 
} 

parameter	type	explanation
serialNumber	string	a serial number
x	string	raw data

Responses

{
    "localToken":<local token>, 
    "globalToken":<global token>, 
    "r":<random number>, 
    "comm":<commitment> 
}

parameter	type	explanation
localToken	string	a local token
globalToken	string	a global token
r	string	a random number
comm	string	a commitment generated from x and r

Holder's Signature Generation API

path	method	explanation
/create_gsign	POST	generate the holder's signature

Parameters

{
    "localToken":<local token>, 
    "globalToken":<global token>, 
    "x":<raw data> 
}

parameter	type	explanation
localToken	string	a local token
globalToken	string	a global token
x	string	raw data

Responses

{
    "gsign":<holder's signature> 
}

parameter	type	explanation
gsign	string	the holder's signature

Get Holder's Public Key API

path	method	explanation
/get_okey	GET	get the holder's public key

Responses

{ 
    "okey":<holder's public key>
} 

path	method	explanation
okey	string	the holder's public key

Issuer's Signature API

path	method	explanation
/create_owner_signature	POST	Generate an evidence

Parameters

{ 
    "globalToken":<global token>, 
    "gsign":<signature by holder>, 
    "okey":<holder's public key> 
} 

path	method	explanation
globalToken	string	a global token
gsign	string	a signature by the holder
okey	string	The holder's public key

Responses

{ 
    "globalToken":<global token>, 
    "evidence":<evidence> 
} 

parameter	type	explanation
globalToken	string	a global token
evidence	string	an evidence containing of the holder's public key, a signature by the holder, the issuer's public key, and a signature by the issuer

Register Assets API

path	method	explanation
/register_assets	POST	Register an asset consisting of a serial nujmber, a global token, and an evidence

Parameters

{
    "serialNumber":<serial number>, 
    "globalToken":<global token>, 
    "evidence":<evidence> 
}

path	method	explanation
serialNumber	string	a serial number
globalToken	string	a global token
evidence	string	an evidence containing of the holder's public key, a signature by the holder, the issuer's public key, and a signature by the issuer

Responses

{
    "serialNumber":<serial number>, 
    "globalToken":<global token>, 
    "evidence":<evidence> 
}

path	method	explanation
serialNumber	string	a serial number
globalToken	string	a global token
evidence	string	an evidence containing of the holder's public key, a signature by the holder, the issuer's public key, and a signature by the issuer

Get Asset API

path	method	explanation
/get_asset	POST	get assets recorded on the blockchain by serial number

Parameters

{
    "serialNumber":<serial number>
}

path	method	explanation
serialNumber	string	a serial number

Responses

{
    "serialNumber":<serial number>, 
    "globalToken":<global token>, 
    "evidence":<evidence> 
}

path	method	explanation
serialNumber	string	a serial number
globalToken	string	a global token
evidence	string	an evidence containing of the holder's public key, a signature by the holder, the issuer's public key, and a signature by the issuer

Zero-Knowledge Proof Generation API

path	method	explanation
/create_proof	POST	generate a proof

Parameters

{ 
    "x":<raw data>, 
    "r":<random number>, 
    "comm":<commitment>
} 

path	method	explanation
x	string	raw data
r	string	a random number
comm	string	a commitment generated from x and r

Responses

{
    "proof":<proof>
}

path	method	explanation
proof	string	a proof

Get Verification Key API

path	method	explanation
/client/get_zkp_verification_key	GET	get the verification key

Responses

{ 
    "verificationKey":<verification key>
} 

path	method	explanation
verificationKey	string	the verification key

Zero-Knowledge Proof Verification API

path	method	explanation
/verify_proof	POST	verify a given proof

Parameters

{ 
    "verificationKey":<verification key>, 
    "comm":<commitment>, 
    "x":<raw data>, 
    "proof":<proof> 
} 

path	method	explanation
verificationKey	string	the verification key
comm	string	a commitment generated from x and r
x	string	raw data
proof	string	a proof

Responses

{ 
    "result":<verification result> 
} 

path	method	explanation
result	string	verification result

References

[1]: Verifiable Credentials Data Model v1.1., W3C Recommendation 03 March 2022.