Measurement Device Independent Quantum Digital Signature (MDI-QDS)
The example protocol achieves the functionality of Quantum Digital Signature (QDS) by allowing exchange of messages using the procedure studied in Prepare and Measure Quantum Digital Signature but without trusting one's measurement devices, thus making the protocol device independent. It uses the security proof of MDI-QKD to the QDS scheme for insecure channels (1). This scheme involves three parties and is designed for signing one bit and the authors suggest that longer messages can be signed by iterating the same process. All three properties that define QDS i.e. non-repudiation, transferability and unforgeability are implied by the protocol.
Tags: Multi Party (three), Quantum Enhanced Classical Functionality, Specific Task, Quantum Digital Signature (QDS), Prepare and Measure QDS
Assumptions
- There exists authenticated classical channels between seller and buyer, and, seller and verifier.
- Receiver and verifier share a MDI-QKD link, used to transmit classical messages in full secrecy.
- Adversary is allowed to perform coherent attacks, which is the most general class of attacks QKD protocols are vulnerable to, due to experimental realisation.
Outline
Quantum Digital Signature protocols can be separated into two stages: the distribution stage, where quantum public keys are sent to all recipients, and the messaging stage, where classical messages are sent and verified. Here, we take the case of three parties, one sender (referred to as seller) and two receivers (buyer and verifier) sharing a one bit message.
The following protocol consists of only quantum communication in the distribution phase and only classical communication in the messaging phase. It uses the protocol for QDS with insecure channels (1) and replaces KGP (Key generation protocol) with Measurement Device Independent KGP (MDI-KGP). Distribution phase can be divided into the following steps:
- Key Distribution: Seller uses MDI-KGP twice with buyer and verifier, to generate two different keys with each, one for message bit 0 and one for message bit 1. Seller's signature for a particular message bit is a conjugation/concatenation of corresponding key for message bit sent to the buyer and the verifier. Below is an overview of MGI-KGP extracted from MDI-QKD (page to be visited in case more explanation is required)
- MDI-KGP: MDI-KGP consists of only quantum communication part from MDI-QKD protocol in (2). This protocol requires an untrusted third party sitting in the middle of the participating parties, arbitrator. The following steps are performed with seller and each receiver, pairwise for each possible bit (0 and 1). Seller and receiver, both separately prepare a state in a randomly chosen basis (of the two chosen bases, say rectilinear (X basis) and diagonal (Z basis)), and send it to the arbitrator. The arbitrator performs Bell State Measurement on the two incoming states. A successful BSM entangles the two states and the outcome of the measurement is one of the four Bell States, which is declared by the arbitrator over public channel. This process is repeated until sifting condition is met. In sifting, seller and receiver then exchange the preparation basis chosen for each event, which is neglected if the basis is mismatched. If matched then, depending on the basis chosen, data (classical information of their own states/ classical bits) corresponding to each event is classified into two sets. This is repeated unless cardinality of the two sets is above a certain threshold number of elements. The receiver flips his bits (set elements) for each event according to the table shown in Pseudo Code. It is done to correlate seller's bits with receiver's bits. This marks the end of Sifting. Finally, one of the sets is used for error correction in MDI-QKD (not the concern of this protocol), while the other set is divided into two parts, one to be used as the code key and the other, to calculate the error rate. If error rate is greater than the tolerance value decided, the protocol is aborted by both parties. The signature/private key of seller for a particular message bit is the concatenation of both buyer and verifier's code keys corresponding to that bit.
- Symmetrisation: Buyer and Verifier exchange half of their MGI-KGP keys over MDI-QKD link. These become the final keys of the recipients. This prevents a dishonest seller succeed in cheating by sending dissimilar public keys to the receiver and makes the protocol secure against repudiation. Thus ends the distribution phase.
Similarly, Messaging Phase is divided into the following steps:
- Signing: Sender sends desired message and the corresponding signature to the desired receiver (called buyer). Buyer checks for mismatches, first with his half of the key, received directly from Seller and then, with verifier's half shared with him during symmterisation. If there are fewer mismatches than the decided threshold (to check for repudiation, determined by experimental parameters) then buyer accepts the signature.
- Transfer: Buyer forwards the same message and private key to the other receiver (called verifier) who compares it with his key for this message bit in the same way as the buyer, but with a different threshold value (to check for forgery and repudiation).
Requirements
- Network Stage: Prepare and Measure
- Authenticated quantum channel
- Authenticated classical channel
- Estimated parameters (for security level of order )
- Signature length: for each message bit 0 and 1.
- Transmission distance: 50km
- Estimated time to generate raw keys: 93 minutes (can be improved by using detectors with better efficiency)
- MDI-QKD setup (without error correction and privacy amplification)
Properties
- The strings generated by Sender and Receiver are free from detector side channel attacks as one does not trust measurement devices.
- Implementation of long distance MDI-QKD [Measurement Device Independent Quantum Digital Signature (MDI-QDS)#References|(3)] employs establishes long distance QDS protocol without side channel attacks
- It removes all detector side-channel attacks
- It is valid against repudiation and forging attacks
Pseudocode
Stage 1 Distribution
- Input Key Length, Threshold values (s_a, s_v)
- Output Seller: 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^B_0,S^B_1,S^V_0,S^V_1}
Buyer: 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 B^0,B^1}
; Verifier: 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 V^0,V^1}
- Key Distribution:
- For k = 0,1
- MDI-KGP(Seller, Buyer, Arbitrator)
- 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_V^k=V^k=} MDI-KGP(Seller, Verifier, Arbitrator)
- Symmetrisation
- For k = 0,1
- Buyer chooses
- 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 \forall i\epsilon I} , Buyer sends Verifier
- Verifier chooses
- , Verifier sends Buyer 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 (k,j,V^k_j)}
- For k = 0,1
Stage 2 Messaging
- Input Seller: Message m, Private Key for m:
- Output Buyer: accept or abort, Verifier: accept or abort
- Signing: ’mismatch’ is when Buyer finds an eliminated signature element in Seller’s private key
- Seller sends Buyer (m,)
- For l = 1,2,..,L
- If 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 l\epsilon \{1,2,...,L\}-I}
- Buyer counts the number of mismatches (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 B^m_l!=S^m_l} ), b=b+1
- If 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 l\epsilon J}
- Buyer counts the number of mismatches (), v=v+1
- If 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 l\epsilon \{1,2,...,L\}-I}
- If , Buyer accepts m else he aborts
- Transfer
- Buyer sends Verifier (m,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^B_m,S^V_m} )
- For l = 1,2,..,L
- If 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 l\epsilon \{1,2,...,L\}-J}
- Verifier counts the number of mismatches (), v=v+1
- If
- Verifier counts the number of mismatches (), b=b+1
- If 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 l\epsilon \{1,2,...,L\}-J}
- If 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 (b < s_vL/2)\&\&(v < s_vL/2)} , Verifier accepts m else he aborts
Subroutine: MGI-KGP
MDI-KGP(Seller, Receiver, Arbitrator)
- Seller randomly chooses basis and generates
- Receiver randomly chooses basis and generates 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 |a\rangle}
- Arbitrator performs BSM (C-NOT Failed to parse (unknown function "\tensor"): {\displaystyle H\tensor I|a\rangle|b\rangle} )
Further Information
MDI-QDS is so far the best Prepare and Measure Network Stage QDS protocol. It does not rely on the measurement devices and is easy from implementation point of view. As the platform of widely implemented MDI-QKD is available, MDI-QDS can be implemented most efficiently and provides the best security in the QDS protocols discovered so far. Another approach would be to adapt DI-QKD for key generation. Here one would neither trust the measurement devices nor the source. As seller and buyer both act as an adversary in QDS protocols, we do not want depend on our state preparation devices either. This has not been studied yet due to as QDS protocols discovered so far yet do not match up to the efficiency of classical and post-quantum digital signature schemes in terms of signing time, key length, etc.
References