Quantum Cheque
This example protocol is a private-key protocol which allows trusted banks to issue perfectly secure and verifiable quantum cheque books to account holders and also enables them to undertake monetary transactions with other parties. This quantum cheque is secure against non-signalling adversaries and cannot be counterfeited.
Tags: Quantum Digital Signature, Private key protocol.
Outline
This protocol allows a quantum cheque to be issued using quantum chequebooks to the bank customers. The customers can then carry forward transactions in a perfectly secure manner and these cheques can be en-cashed after being verified by the trusted bank or its branches, which communicate with the main branch securely. The quantum cheque follows all the property of a classical cheque - verifiable by a trusted bank, cannot be disavowed by the issuer and cannot be counterfeited by an adversary.
The entire bank transaction process can be divided into three stages, Gen, where the cheque book is generated for the account holder, Sign, where the account holder prepares a cheque and issues it to the third party and Verify, where the third party en-cashes the cheque depending upon its validity.
- Gen
- In this method the cheque book and a key is created for the account holder by the bank.
- The bank and the account holder create a shared key using Quantum Key Distribution. Both parties agree upon the Quantum Digital Signature. The account holder stores their private key safely with himself and shares the private key with the bank.
- The bank then prepares GHZ triplet states (link to page) and stores only the third entangled qubit of every GHZ in the database, while handing over the first two qubits of every GHZ state to the account holder. Along with this, the bank also creates and shares a corresponding unique serial number for this cheque.
- Finally, the account holder has stored their identity, shared key, private key, public key, serial number and first two entangled qubits of every GHZ triplet state whereas the bank has stored account holder's identity, shared key, public key, serial number and third entangled qubit of every GHZ triplet states in their respective databases.
- Sign
- In this method, the issuer's key and amount to be signed is taken as input to produce a quantum state which acts like a cheque.
- The account holders prepare quantum states to issue a check worth some amount . This quantum state is prepared by the quantum one-way function (Link to the page) which takes the shared key, identity of the account holder, a random number and the amount of money Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle M} to be signed as the input. Every state from these Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle n} quantum states is individually encoded with one of the account holder's entangled qubit of the GHZ states using Quantum Secret Sharing: Splitting of quantum information (Link to the page). The account holder then signs the serial number with their digital signature.
- The quantum cheque thus produces by the account holder contains the information - the identity of the account holder, serial number, generated a random number, digital signature, amount of money signed and the other entangled qubit of the GHZ state.
- Verify
- In this method, the quantum cheque is verified by the trusted bank or its branches and the validity is checked.
- When the quantum cheque is produced at any valid branches of the bank by a third party, the information is securely communicated to the main branch. At the branch, an initial verification is carried by considering the identity of the issuer of the cheque, the serial number of the cheque and the digital signature of the issuer. If the cheque is valid, the verification process is continued, otherwise, the cheque is destroyed and the process is discontinued.
- The main branch performs a measurement on its copy of third entangled qubit of every GHZ triplet state which was stored in the database and securely communicates this result to the branch.
- The branch recovers the quantum state that was prepared by the account holder to issue the cheque, using the information received from the main branch. The branch also computes this same quantum states using the stored account holder's information like the shared key, the identity of the account holder, a random number and the amount of money as input for verification. A swap test(Link to the page) is performed on both these states and if the cheque is only accepted if this test passes, else it is destroyed and aborted.
This scheme is proven to be impossible to counterfeit and impossible to repudiate. The quantum cheque is a quantum state and thus it cannot be copied or stolen by any eavesdropper, ensuring that only one copy of the quantum cheque exists.
Hardware Requirements
- Secure quantum channel to connect the branches of the bank to the main branch.
- Secure quantum channel to connect the bank to the account holder and to connect any other third party to the bank.
- This protocol required quantum memory to store issuer's quantum state of the cheque if the protocol is not running in real time.
- Private database for both account holder and bank.
- Measurement devices for the account holder and the main branch of the bank.
Properties
- The protocol assumes perfect state preparation, transmissions, and measurements.
- The protocol assumes the account holder and the bank, to be honest. The bank is a trusted party, however, the branches may or may not be trusted.
- The protocol takes the assumption that the Quantum Digital Signature scheme and the Quantum key distribution is unconditionally secure.
- In the signing process, the quantum one-way function used to create the cheque for the account holder is assumed to take polynomial time to compute and is hard to invert.
- In the verification process, the bank sets a thresholding security parameter Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \kappa} . The swap test is passed if
- No quantum memory would be required for the account holder to store the quantum check if the transaction is occurring in real time.
Notation
- : Shared key between account holder and bank where .
- : Digital signature scheme, where Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \Pi=(Gen, Sign, Vrfy)} .
- Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle id} : Account holder's identity.
- : Account holder's public key.
- : Account holder's private key.
- : Unique serial number where .
- : Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle n} GHZ triplet states where,
- : First entangled qubit from every GHZ triplet state which is given to account holder.
- : Second entangled qubit from every GHZ triplet state which is given to account holder.
- : First entangled qubit from every GHZ triplet state which stays with bank.
- Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle r} : Generated random number where Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle r \in \{0,1\}^L} .
- : Amount of money account holder signs on the cheque.
- Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle f} : Quantum one way function.
- y: concatenation of two bit strings and .
- : quantum state prepared by the account where,
. This quantum state is also denoted as Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \alpha_i|0\rangle + \beta_i|1\rangle} .
- : Bell state
- Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle |\Psi^\pm\rangle} : Bell state
- : In Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \chi} , output of signing with Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle s} .
- : Quantum cheque where,
- Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \kappa} : Threshold constant set as a security parameter by the bank in the swap test.
- : Quantum state prepared by the bank for verification.
Pseudocode
Stage 1: Gen
Output: Account holder now holds and Bank now holds Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle (id, pk, k, s, {\|\phi^{(i)}\rangle_{B}\}_{i=1:n})}}
in their private databases.
- Account holder and Bank create .
- Account holder and Bank agree on .
- Account holder submits to Bank.
- Account holder secretly stores .
- For :
- Bank generates GHZ triple state
- Bank stores in their private database.
- Bank gives to account holder.
- Bank prepares and shares it with the account holder.
- For :
- Account holder stores privately.
- Account holder now holds
- Bank now holds
Stage 2: Sign
Output: Account holder produces
- Account holder generates .
- For :
- Account holder prepares .
- Account holder encodes with by combining with and performing a bell measurement on the two.
- Based on the measurement, account holder performs the suitable error correction, by applying the corresponding Pauli matrix, on :
- Account holder signs the serial number using , as .
- Account holder produces .
Stage 3: Verify
Output: Cheque gets accepted or the process is aborted and the cheque is destroyed.
- Third party produces the at a valid branch of the bank.
- Branch communicates with main branch of the bank and checks validity of and runs .
- If invalid:
- Bank aborts the process and destroys the cheque.
- else:
- Bank continues the verification process.
- If invalid:
- Main branch of the bank performs the measurement in Hadamard basis on its copy of and obtains outcome or .
- Main branch communicates this result with the local branch.
- For :
- Based on outcome, branch performs the corresponding Pauli matrix operation on to recover :
- For :
- Bank computes , where,
- For :
- Bank performs swap test on and .
- If :
- Bank aborts the process and destroys the cheque.
- else:
- Bank continues the verification process.
- If :
- Bank performs swap test on and .
- Bank accepts the cheque.