# CSUM: A Novel Mechanism for Updating CubeSat while Preserving Authenticity
and Integrity

Ankit Gangwal, Aashish Paliwal
International Institute of Information Technology Hyderabad, India
<EMAIL_ADDRESS><EMAIL_ADDRESS>
###### Abstract

The recent rise of CubeSat has revolutionized global space explorations, as it
offers cost-effective solutions for low-orbit space applications (including
climate monitoring, weather measurements, communications, and earth
observation). A salient feature of CubeSat is that applications currently on-
boarded can either be updated or entirely replaced by new applications via
software updates, which allows reusing in-orbit hardware, reduces space
debris, and saves cost as well as time. Securing software updates employing
traditional methods (e.g., encryption) remains impractical mainly due to the
low-resource capabilities of CubeSat. Therefore, the security of software
updates for CubeSats remains a critical issue.

In this paper, we propose CubeSat Update Mechanism (CSUM), a lightweight
scheme to provide integrity, authentication, and data freshness guarantees for
software update broadcasts to CubeSats using a hash chain. We empirically
evaluate our proof of concept implementation to demonstrate the feasibility
and effectiveness of our approach. CSUM can validate 50,000 consecutive
updates successfully in less than a second. We also perform a comparative
analysis of different cryptographic primitives. Our empirical evaluations show
that the hash-based approach is at least 61$\times$ faster than the
conventional mechanisms, even in resource-constrained environments. Finally,
we discuss the limitations, challenges, and potential future research
directions for CubeSat software update procedures.

###### Index Terms:

Authentication, CubeSat, Data Freshness, Integrity, Secure Software Update.

##  I Introduction

Space exploration and deployment of satellites have become an indispensable
part of modern science. These satellites serve various purposes, including
navigation [1], weather forecast [2], and data collection [3]. In the past few
years, CubeSat (CS) - a novel type of miniature satellite - has attracted
significant interest from researchers in academia as well as industry [4].
Each CS unit measures $10\times 10\times 10$ cubic centimeters ($10\ cm^{3}$).
The rise of CS has significantly reduced the cost associated with satellite
deployment, consequently democratizing the field. In particular, the reduction
in satellite deployment cost has enabled small to mid-sized companies,
universities, research institutes, and even developing nations [5] to
participate in space expeditions.

While CS provides a cost-effective means for entering the satellite
playground, it also introduces a new array of challenges that do not apply to
traditional satellites. The fundamental reason for such unprecedented
challenges is the limited availability of resources (including computing
power, memory, and communication bandwidth) in CS. One such challenge within
resource-constrained environments is the software update process [6], and CSs
are no different. In fact, it is even more crucial to secure the software
update process for CSs as they are mission-critical, where even a minute error
can lead to mission failure or the complete loss of a satellite. Furthermore,
it is essential for CS’s software to be modular and reusable [7].

Malicious software updates can lead to unauthorized control, data
manipulation, and communication interference, which can lead to severe
consequences (e.g., increased risk for mission failure, lack of data
integrity, even complete loss of control over CS). Moreover, unauthorized
access to a satellite poses a significant risk not just to its owners, but to
the broader space environment as well. As a representative example, an
attacker taking control of a satellite and activating its thrusters could lead
to the Kessler Syndrome [8]. Kessler Syndrome is a scenario where debris from
one satellite collision spreads and hits other satellites, creating more
debris in a domino effect. Such a chain reaction could potentially block
access to space for decades, as observed in different simulations [9, 10]. CS
commonly utilizes amateur radio frequencies for communication (i.e., UHF/VHF
[11]), resulting in relatively low data rates (typically ranging from 9.6 Kbps
to 100 Kbps). For instance, the daily throughput of ThingSat [12] is
approximately 1500 KB [11]. Furthermore, utilizing standard cryptographic
schemes to handle malicious updates is impractical since cryptographic
operations tend to be expensive in terms of computational resources; making
them unsuitable for CS’s resource-constrained environment.

The on-board software is one of the most critical components of any space
mission. It encompasses the core capabilities of the space system, ranging
from daily activities within the system (like navigation, communication, and
energy management) to more specialized tasks (like data collection and
processing). The effectiveness of a space system relies heavily on the correct
functioning of on-board hardware and software. Post-launch, satellites may
face unexpected events and operating conditions. While some issues can be
mitigated via exception handling (if anticipated during initial software
development), others may be fixed through software updates.

Over-the-Air (OTA) updates have overwhelmingly affected various user-centric
domains, e.g., smartphones, smart TVs, automobiles, and IoT devices. OTA
enables manufacturers to deliver software updates remotely, eliminating the
need for physical access to a device. For the end users, OTA updates offer a
convenient way to receive the latest functionality without visiting the
service center. For manufacturers, it provides a way to improve their
products’ value by delivering new features, bug fixes, and security patches on
time. The importance of OTA updates extends beyond convenience. OTA updates
are critical for the lifecycle management of modern devices to ensure they
remain efficient, secure, and up-to-date with minor user intervention.

Nilchiani [13] argues that the capability of remote modification and
enhancement of on-board software is crucial for space systems due to the
uncertain nature of space. This capability can help preserve system
functionality, adapt to emerging requirements, or improve performance without
needing physical upgrades (which are often impossible after launch). In-orbit
software updates are now standard practice for small satellites [14]. Even
nano-satellites (e.g., PlanetLabs Dove nanosatellite constellation [15])
acknowledge support for in-orbit firmware updates without disclosing the
details.

In this paper, we introduce CSUM, a lightweight scheme designed to enhance the
security of software updates in CS. CSUM is designed to take into account the
constrained hardware capabilities of CS and the limited communication
bandwidth between Ground Station (GS) and CS. It aims to preserve software
updates’ integrity, authenticity, and freshness, thereby safeguarding CS from
adversaries attempting to tamper with in-transmission software updates. Our
approach advocates for using lightweight hash functions because a single
public-key computation is roughly equivalent to hundreds of hash computations
in processing time [16].

The major contributions of our paper are as follows:

  1. 1.

We propose CSUM, a novel and lightweight scheme that utilizes hash chains to
ensure authentication, integrity, and freshness for CS software update
broadcasts.

  2. 2.

We validate the effectiveness of CSUM via empirical evaluations of its proof
of concept implementation. Our results show that CSUM can validate 50,000
consecutive updates in just 0.81 seconds.

  3. 3.

Furthermore, we perform a comparative analysis of different cryptographic
primitives. Our analyses show that the hash-based approach outperforms the
traditional mechanisms even in resource-constrained environments. In
particular, encryption, decryption, signing, and signature verification
operations are over 155, 126, 64, and 61 times slower than the hash-based
approach, respectively.

Organization: Section II provides an overview of the related research works
and background knowledge. We discuss our system and adversary model along with
security requirements in Section III, elaborate CSUM in Section IV, and
discuss our results in Section V. We present CSUM’s security analysis in
Section VI. Section VII highlights the potential limitations of our proposed
solution. Finally, Section VIII concludes the paper and highlights the
possible future directions for CS software update procedure.

##  II Background

Section II-A delves into the advancements in securing space systems,
particularly through OTA software updates, and highlights the challenges in
securing software updates in resource-constrained environments. Section II-B
introduces cryptographic fundamentals essential for our proposed scheme.

###  II-A Related works

The security of space-based assets (like CS) has not been extensively
researched as their terrestrial counterparts (like connected vehicles),
especially concerning OTA software updates. Recently, researchers have been
looking into CS security, focusing on the unique challenges posed by the
limited resources available on such platforms. Halder et al. [17] underlines
the significance of OTA updates and categorizes existing OTA update techniques
for connected vehicles. Various secure update techniques for connected
vehicles have been developed to address integrity, authenticity, and
confidentiality. These techniques include Uptane [18], a secure software
repository framework that enhances compromise resilience by distributing
responsibilities across distinct roles. Blockchain-based schemes [19]
eliminate cloud involvement and utilize smart contracts to ensure update
integrity and authenticity, while hash function-based protocols [20] safeguard
the transmission integrity of software updates. Frameworks, such as SecUp
[21], utilize a combination of symmetric and asymmetric key cryptography to
ensure secure and efficient OTA updates. Moreover, hardware-based solutions
leveraging Hardware Security Modules (HSM) [22] and Trusted Platform Modules
(TPM) [23] provide robust security at hardware-level.

Souza et al. [24] emphasize the difficulties in implementing secure software
updates due to these resource constraints, proposing a multi-layered mission
software approach for CS. Similarly, Bellissimo et al. [6] highlights the
challenges in securing software updates in deployed systems, complexities in
safeguarding against known attacks, and the challenges of applying secure
content distribution methods in resource-limited devices. Willbold et al. [25]
offers a comprehensive threat taxonomy against satellite firmware, including
an analysis of real-world satellite firmware security issues and a survey
among professional satellite developers to shed light on the satellite
security landscape.

The authors in [26, 27, 11] discuss different firmware update mechanisms for
an in-orbit CS. Sünter et al. [27] explore firmware updating systems for nano-
satellites using the ESTCube-1 mission [28] to compare four distinct update
procedures, highlighting their implementation complexities and error recovery
mechanisms for in-orbit satellite software management. Fitzsimmons [26]
improves CS robustness through a software update mechanism, focusing on update
usability, validation, and system recovery to extend mission capabilities and
safeguard against operational anomalies. The author utilizes MD5 for
integrity, but the scheme does not address authentication. Bezem and Fjellby
[29] tackle the absence of inherent security features in satellite
communications by enhancing the CS Space Protocol with HMAC and sequence
numbers to prevent replay attacks. However, apart from focusing exclusively on
replay attacks, the scheme also requires secure infrastructure, which is
comparatively costly. Molina et al. [11] addresses secure software updates for
multi-tenant CS through Cubedate, a framework designed for continuous software
deployment to orbiting CS. Despite its innovative approach, the framework
relies on digital signatures and encryption, raising concerns about
computational feasibility in the constrained environment, alongside its
dependence on a single trust anchor. Challa et al. [30] proposed CubeSec and
GndSec, lightweight security solutions for CS communications, acknowledging
the need for efficient security measures in resource-constrained environments.
However, the security of their approach relies heavily on pre-shared keys as
they utilize symmetric encryption.

In traditional pre-shared key systems, all security properties are lost once
the key (or trust anchor) is compromised. In our approach, even if a CS is
compromised, adversaries can only validate tokens and read the next one when
it comes; they cannot create the next key due to the pre-image resistance of
cryptographic hash functions. This significantly limits the damage an
adversary can do as long as they can only read the trust anchor and not
replace it.

To summarize, using standard cryptographic primitives (i.e., encryption in
CubeSec [30], CubeDate [11], and GndSec [30] as well as digital signatures in
CubeDate [11] and NUTS [29]) make state-of-the-art CS security solutions
computationally expensive. CSUM overcomes computational overheads by limiting
the use of public-key operations to just one instance (i.e., to create a one-
time trust anchor) and utilizing lightweight hash function in subsequent
operations.

###  II-B Prerequisites

####  II-B1 Cryptographic hash function

A hash function transforms a message of any length into a random-looking
fixed-size string. For a hash function to be considered a cryptographic hash
function, it must contain three properties:

  * •

Pre-image resistance: Given a hash function output $H$, it should be
computationally infeasible to find input value $m$ such that $h(m)=H$.

  * •

Second pre-image resistance: Given an input value $m_{1}$, it should be
computationally infeasible to find a different input value $m_{2}$ such that
$h(m_{1})=h(m_{2}),\text{where }m_{1}\neq m_{2}$.

  * •

Collision resistance: It should be computationally infeasible to find two
distinct inputs $m_{1}$ and $m_{2}$ such that $h(m_{1})=h(m_{2})$.

####  II-B2 Hash chain

Hash chain utilizes a cryptographic hash function to create a linked chain of
hashes. A hash chain is constructed by recursively applying a cryptographic
hash function to a randomly generated seed as shown in Figure 1. Hash chains
inherently inherit the properties of cryptographic hash functions while also
exhibiting their own unique characteristics due to their iterative structure.

Figure 1: Representation of a hash chain starting from seed to $T_{n}$.

##  III System architecture and threat model

In this section, we outline the system model (cf. Section III-A), describe the
adversary model for CSUM (cf. Section III-B), and specified the security
requirements for CS (cf. Section. III-C).

###  III-A System model

CSUM focuses on ensuring the secure delivery of Software Update Package
($SUP$) from GS to CS while considering the inherent vulnerabilities of the
communication systems linking them. Our system model comprises three primary
entities: administrator, GS, and CS. The administrator plays a pivotal role in
the initial setup by generating a seed to create a hash chain, which acts as a
trust anchor and lays the foundation for secure communication. The
administrator is also responsible for creating $SUP$s and corresponding
Transmission Token ($TT$), which are essential for authorizing updates. GS is
responsible for transmitting $SUP$s and its corresponding $TT$s received from
the administrator to CS. CS is tasked with the reception and verification of
$SUP$ and their accompanying $TT$s, ensuring the security of the deployment
process. CS is equipped to perform critical cryptographic operations despite
its limited resources.

The communication link between GS and CS is inherently insecure but reliable
and susceptible to threats such as replay attacks, message alteration, and
injection. Despite these challenges, both the administrator and CS are
considered secure entities with secure internal storage capabilities to resist
direct attacks. Operating within a constrained environment, CS must
efficiently manage its limited bandwidth, processing capabilities, and
storage, highlighting the need for streamlined and lightweight security
solutions. A reliable transfer protocol, like Saratoga protocol [31], can
mitigate issues related to packet losses and propagation delay. Our proposed
scheme is agnostic to transport mechanisms as long as we transmit both $SUP$
and the corresponding $TT$.

Figure 2 illustrates a communication system where the administrator interacts
with the Ground Station over the Internet, with the potential for both secure
and insecure data transmission. However, the communication between the Ground
Station and the CS is insecure.

Figure 2: A simplified communication architecture of CS.

###  III-B Adversary Model

Our adversary model considers a highly capable adversary with computational
resources surpassing those typically available in a CS environment. The
adversary operates within Probabilistic Polynomial Time (PPT) and targets
vulnerabilities primarily within the communication framework connecting GS and
CS. We assume that the trusted components in the overall CS infrastructure,
including the administrator, CS, and GS, remain secure throughout the system’s
operational life.

The adversary possesses a diverse array of attack capabilities to compromise
software updates between GS and CS. These capabilities include passive
eavesdropping on the communication channel, active interception and data
manipulation to facilitate Man-in-the-Middle attacks, executing replay attacks
by re-transmitting legitimate $SUP$, injecting malicious $SUP$, and
overwhelming CS (and its verification capacity) by flooding CS with fake $SUP$
and $TT$.

The adversary’s objectives include disrupting genuine communication, deceiving
CS into accepting malicious $SUP$s, extracting sensitive information from
transmitted messages, and wasting CS resources. Despite these capabilities,
the adversary is bound by PPT, which restricts its ability to break strong
cryptographic systems within a reasonable time frame. Additionally, the
adversary is incapable of altering the initially trusted data placed in a CS
(e.g., trust anchor).

###  III-C Security Goals

The primary objective of CSUM is to secure the transmission of $SUP$s from GS
to CS against threats on insecure channels. We aim to achieve the following
critical security goals [32]:

  1. 1.

Authentication: To ensure that $SUP$s originate from a verified source, CSUM
incorporates the use of authentication tokens. This mechanism ensures that
only authorized entities can initiate software updates.

  2. 2.

Integrity: CSUM is designed to detect any unauthorized modifications in $SUP$s
received by CS. Thereby safeguarding the integrity of the transmitted data.

  3. 3.

Data freshness: It is crucial that CS receives the most recent $SUP$. CSUM
mitigates the risk of replayed attacks by adversaries, ensuring that only the
latest valid $SUP$ are installed.

##  IV Proposed Scheme

CS is designed to operate under limited resources, e.g., extremely low
bandwidth, constrained memory, and minimal processing power. Formulating
effective security strategies within these constraints is non-trivial and
presents a significant challenge. These constraints force us to move away from
traditional cryptographic mechanisms that are robust but resource-intensive.
Thus, such mechanisms are impractical for low-resource environments, like CS.
In contrast, cryptographic hash functions emerge as a better solution due to
their significantly lower computational overheads [16]. CSUM utilizes a
lightweight hash function to ensure the authentication and integrity of $SUP$s
sent from GS to CS.

CSUM aims to minimize reliance on resource-intensive public-key operations and
replace them with efficient hash operations instead. This approach holds
significant advantages for CS due to the lightweight nature of hash functions
compared to encryption and signature schemes. The proposed scheme aims to
achieve authentication, integrity, and freshness with constant network
overhead (i.e., output length of a single hash function).

Now we elucidate different phases (cf. Section IV-A) and operations (cf.
Section IV-B) in CSUM. We also present a sample execution of CSUM in Section
IV-C.

###  IV-A Phases

CSUM involves setup, key encapsulation, and authentication and integrity
phases. We utilize several symbols as defined in TABLE I while explaining
CSUM.

TABLE I: Symbol definitions. Symbol | Description
---|---
$TA$ | Trust Anchor
$TT$ | Transmission Token
$DT$ | Derived Token (from transmission)
$PT$ | Partial Token
$AT$ | Authentication Token
$AT_{curr}$ | Current Authentication Token
$AT_{prev}$ | Previous Authentication Token
$h(x)$ | Hash function applied on $x$
$h^{n}(x)$ | Hash function applied on $x$ $n$ times

####  IV-A1 Setup phase

The setup phase initializes the system, where the administrator employs a
hardware random number generator [33] to produce a random seed. The generated
seed undergoes iterative hashing to form a hash chain [34]. The resulting tip,
$h^{n}(seed)$, is stored in CS memory as a Trust Anchor ($TA$) for subsequent
operations.
Prior to launch, storing $TA$ in CS is straightforward. Post-launch introduces
considerations for secure transmission. Confidentiality is ensured through
pre-existing mechanisms supporting confidentiality, allowing direct transfer
of $TA$ without additional security layers. Encryption becomes necessary only
when the default mechanism lacks confidentiality support despite the
additional overhead.

####  IV-A2 Key encapsulation phase

The key encapsulation phase conceals a one-time Authentication Token (AT)
without utilizing encryption techniques. Our key encapsulation involves a
bitwise XOR operation ($\oplus$) between the current $AT$ (i.e., $AT_{curr}$)
and the result of applying a cryptographic hash function ($h$) to the
concatenation of $SUP$ and the previous $AT$ (i.e., $AT_{prev}$) as shown in
Eq. (1).

$TT\coloneqq AT_{curr}\oplus h(SUP\mathbin{\|}AT_{prev})$ (1)

In simpler terms, we combine $AT_{curr}$ with a hashed value derived from the
concatenation of $SUP$ and $AT_{prev}$ to generate $TT$. Figure 3 shows
interconnection between subsequent $TT$s.

Figure 3: Protocol describing secure software update procedure.

####  IV-A3 Authentication and integrity phase

The authentication and integrity phase is crucial in ensuring the secure
transmission of $SUP$s from GS to CS. This phase links $TT$ to $AT_{curr}$,
$SUP$, and $AT_{prev}$ (previous state of hash chain) while confirming the
validity of $AT_{curr}$. CSUM ensures integrity by associating the hash of
$SUP$ to $TT$ as shown in Eq. (1). Any attempt by an adversary to alter $SUP$
results in CS failing to extract the correct $AT_{curr}$ from $TT$, leading to
the rejection of $SUP$. $AT_{curr}$ verification requires a single hash
operation, as shown in Eq. (2).

$h(AT_{curr})=AT_{prev}$ (2)

Overall, the proposed scheme leverages hash functions to ensure authentication
and integrity in a resource-constrained environment, making it suitable for CS
with limited bandwidth, processing power, and memory. The hash chain and $TT$
mechanisms provide a lightweight yet effective approach to secure software
updates in the presence of potential adversaries and insecure communication
channels.

###  IV-B Operations

This section explains the tasks executed by the administrator, GS, and CS
within the proposed scheme. Figure 4 presents a sequence diagram that
illustrates CSUM for securely installing software updates on CSs.

Figure 4: Sequence diagram illustrating CSUM for secure software update.

####  IV-B1 Administrator operation

Several crucial tasks are undertaken to ensure the proper functioning of CSUM
at the administrator’s end. These tasks include generating a hash chain and
creating a $SUP$ with the corresponding $TT$. The administrator initializes
the scheme by generating a random seed; the generated seed is hashed
iteratively to create a hash chain. Each $SUP$ sent to CS is accompanied by
its corresponding $TT$, formulated as shown in Eq. (1). Algorithm 1 presents
the pseudocode for $TT$ generation by the administrator for each $SUP$.

The administrator and GS can communicate in an encrypted or plain text manner.
However, we require an integrity mechanism while sending $SUP$s without
encryption. We especially require an encrypted connection between the
administrator and GS only while sending $TA$ during the initial setup phase.
For regular $SUP$s, the administrator creates and sends $SUP$ and the
corresponding $TT$ to the GS. Algorithm 1 details the psuedocode for this
case.

Algorithm 1 Pseudocode for $TT$ generation.

Input: $SUP$, $AT_{curr}$, $AT_{prev}$

Output: $TT$

1:if $h(AT_{curr})=AT_{prev}$ then $\triangleright$ Validate AT

2: $PT=h(SUP\mathbin{\|}AT_{prev})$

3: $TT:=AT_{curr}\oplus PT$

4: return $TT$

5:else

6: Invalid $AT_{curr}$ and $AT_{prev}$ combination

7:end if

####  IV-B2 Ground station operations

GS receives $SUP$ and $TT$ from the administrator. It forwards both $SUP$ and
$TT$ to CS in unencrypted form. GS has more resources than CS in terms of
computational power. It enables GS to manage communication links with multiple
satellites simultaneously and process large amounts of data transmitted from
such satellites.

####  IV-B3 CubeSat operations

CS extracts both $SUP$ and its corresponding $TT$ from a transmission received
from the GS. Subsequently, CS deciphers $AT_{curr}$ using received $SUP$, $TT$
and $AT_{prev}$, using Eq. (3).

$\displaystyle AT_{curr}\coloneqq TT\oplus h(SUP\mathbin{\|}AT_{prev})$ (3)

Following token extraction, CS verifies the authenticity of deciphered
$AT_{curr}$ by comparing its hash with $AT_{prev}$ as shown in Eq. (2).
Successful verification confirms the integrity and authenticity of $SUP$, and
thus, CS installs $SUP$ and updates $AT_{prev}$. Algorithm 2 provides
psuedocode for AT extraction, AT verification, and $SUP$ installation at CS.

Algorithm 2 Pseudocode for $AT$ extraction and verification.

Input: $SUP^{rec}$, $TT$

Output: True/False

1:while hasNextUpdate() do

2: $PT:=h(SUP^{rec}\mathbin{\|}token)$

3: $DT:=TT\oplus PT$

4: if $h(DT)=token$ then $\triangleright$ Validate $DT$

5: Install $SUP^{rec}$ on CS

6: $token:=DT$

7: Send “Update successful” message to GS

8: return True

9: else

10: Abort update

11: Send “Error: Update Failed” message to GS

12: return False

13: end if

14:end while

The flowchart depicted in Figure 5 outlines the verification procedure for
$TT$ at CS. If CS receive $SUP^{sent}$ and $TT$ without any modification to
$SUP$ or $TT$ during transmission then $SUP^{sent}=SUP^{rec}$, $DT=AT_{curr}$.
Here, $token$ is a local variable stored in CS such that other parties are
unable to access it.

Figure 5: Flowchart describing software verification procedure at CS.

###  IV-C Sample execution

We now present a sample execution of CSUM to illustrate its working better.
Consider a hash chain of size three as depicted in Figure 6. After hashing the
seed thrice, the administrator obtains $T_{3}$, which is securely stored on CS
in the $token$ variable as its $TA$ (prior to CS’s launch in space). Given the
hash chain has a length of three, it can support two111In practice, CSUM can
support one more update. However, it would require using the variable length
seed. For the sake of engaging only fixed-size $token$s (to maintain constant
network overheads), we suggest using seed-based validation only in extreme
scenarios, e.g., wiping CS with a final update or re-initializing the hash
chain. successful software updates in CSUM. During such updates, two distinct
$SUP$ are broadcast to CS. TABLE II lists the computations at both the
administrator and CS for each update iteration.

Figure 6: A sample hash chain of length three. TABLE II: CSUM dry run for a hash chain of length three. Site | Variable | Update iteration
---|---|---
One | Two
Administrator | $SUP$ | $sw1$ | $sw2$
$AT_{prev}$ | $T_{3}$ | $T_{2}$
$\mathbf{AT_{curr}}$ | $\mathbf{T_{2}}$ | $\mathbf{T_{1}}$
$TT$ | $\begin{array}[]{@{}l@{}}TT_{1}=T_{2}\oplus\\\ \quad\quad\quad h(sw1\|T_{3})\end{array}$ | $\begin{array}[]{@{}l@{}}TT_{2}=T_{1}\oplus\\\ \quad\quad\quad h(sw2\|T_{2})\end{array}$
CS | $SUP^{rec}$ | $sw1$ | $sw2$
$token$ | $T_{3}$ | $T_{2}$
$PT$ | $h(sw1\|T_{3})$ | $h(sw2\|T_{2})$
$\mathbf{DT}$ | ${\mathbf{T_{2}}}$ | $\mathbf{T_{1}}$

$1^{st}$ software update: The administrator prepares $SUP=sw1$ and generates
$TT=T_{2}\oplus h(sw1\mathbin{\|}T_{3})$ as described in Eq. (1). Here,
$AT_{curr}=T_{2}$ and $AT_{prev}=T_{3}$. Upon receiving a software update, CS
creates $PT=h(SUP^{rec}\mathbin{\|}token)$ and uses it to derive $DT=TT\oplus
PT$ as specified in Eq. (3). If $SUP^{rec}$ is equal to $sw1$, then $DT$
resolves to $T_{2}$ (matching $AT_{curr}$). With $DT=T_{2}$ and $token=T_{3}$,
CS checks whether $h(DT)=token$ to authenticate $SUP^{rec}$ (cf. Eq. (2)).
Given the relationship between $T_{2}$ and $T_{3}$ (cf. Figure 6), the
verification is successful. CS now installs $sw_{1}$ and updates its
$token=T_{2}$.

$2^{nd}$ software update: The administrator prepares $SUP=sw2$ and calculates
$TT=T_{1}\oplus h(sw2\mathbin{\|}T_{2})$. Now, $AT_{curr}=T_{1}$ and
$AT_{prev}=T_{2}$. Upon receiving a software update, CS calculate
$PT=h(SUP^{rec}\mathbin{\|}token)$ and use it to derive $DT=TT\oplus PT$. If
$SUP^{rec}$ is equal to $sw2$, then $DT$ resolves to $T_{1}$ (matching
$AT_{curr}$). With $DT=T_{1}$ and $token=T_{2}$, CS checks whether
$h(DT)=token$ to authenticate $SUP^{rec}$. Given the relationship between
$T_{1}$ and $T_{2}$, the verification is successful. CS now installs $sw_{2}$
and updates its $token=T_{1}$.

To summarize, CSUM sends $AT_{curr}$ to CS in such a way that only CS that has
the knowledge of corresponding $AT_{prev}$ can extract it.

##  V Experimental Evaluation

We performed experiments on a Lenovo ThinkPad P14s Gen 2 machine. We
implemented our proposed scheme using python 3.7 and utilized four common
open-source packages including Putty, Notepad++, FileZilla, and Audacity with
sizes $<$ 16 MB to simulate $SUP$ being sent to CS.

Encryption/decryption-based schemes are traditionally employed to provide
authentication, confidentiality, and integrity. However, they may not
inherently guarantee data freshness, which is crucial to prevent replay
attacks. Moreover, decryption operations at CS can impose a significant
computational burden. Signature-based schemes primarily focus on ensuring
authentication and integrity with the potential to provide freshness depending
on the specific implementation. However, signature verification operations at
CS can also introduce computational overhead.

To this end, we designed an experiment with different commonly used software
applications, including Putty v0.80 [35], NotePad++ v8.6 [36], FileZilla
v3.66.4 [37], and Audacity v3.4.2 [38]. We performed the following
cryptographic operations: encryption, decryption, signature generation,
signature verification, and hashing on these open-source software packages to
collect timing data. We utilize RSA with a 2048-bit key with PSS padding [39]
for signing, AES with a 256-bit key in CBC mode for encryption, and SHA-256
for hashing. We used hazmat layer from the Python cryptography library [40] to
implement cryptographic primitives. The results are shown in Figure 7.
Encryption, signature generation, and hashing operations are performed at
administrator (without any resource limitation) while decryption, signature
verification, and hashing operation are done at CS (with limited resources).

Figure 7: Timing information for various software of cryptographic primitives.

As shown in Figure 7, we observe that hashing operations are consistently the
fastest across various file sizes, taking only 0.000161s for a 1.58 MB file,
0.000564s for a 4.59 MB file, 0.000313s for a 12.22 MB file, and 0.000110s for
a 15.09 MB file. Signature verification, a process that ensures data integrity
and authenticity, is more time-consuming than hashing, with times ranging from
0.001681s for the smallest file to 0.019880s for the largest file. Decryption
times, which ensures confidentiality, data integrity and authenticity, is even
more expensive then signature verification, requiring 0.003326s for the
smallest file and scaling up to 0.040679s for the largest tested file.

We have taken previous literature and our results into account and decided to
utilize hash-based mechanism to design CSUM. CSUM takes a different approach
by employing a hash-based mechanism, which inherently assures authentication,
integrity, and freshness while using a hash chain. Freshness is assured by the
sequential nature of the hash chain, which prevents the reuse of old hashes.
CSUM simplifies the verification process by requiring only a single hash
operation at CS, significantly reducing computational overhead.

Performance: TABLE LABEL:tab:hashchain_performance shows the performance
analysis of the hash chain, particularly, the time taken to generate the hash
chain and the verification time. CSUM takes less than 0.01s to generate a hash
chain for 10,000 updates, and it gradually increases to 0.056s for 50,000
updates. This rise indicates a proportional increment in the computational
load associated with a larger number of targeted updates. Naturally, the
number of targeted updates directly affects to number of times our system has
to hash the seed to create the hash chain. On another side, verifying 10,000
updates requires about 0.18s, which increases to 0.805s for 50,000 updates.
This increase is steeper since more operations are involved in verifying
$SUP$s than in generating a hash chain. Overall, both the hash chain
generation time and verification of $SUP$s grow linearly with the number of
$SUP$s.

TABLE III: Performance analysis of hash chains. | Number of
---
$SUP$s
| Time taken to
---
generate hash
chain (s)
| Verification by our
---
approach for every
single $SUP$ in chain (s)
10,000 | <0.01 | 0.179558
20,000 | 0.019748 | 0.316285
30,000 | 0.031258 | 0.509595
40,000 | 0.040098 | 0.635965
50,000 | 0.055507 | 0.805479

Network overhead: The network overhead in our approach is independent of the
size of a $SUP$, and it is determined by the fixed output length of the
utilized hash function, i.e., 256 bits in our implementation. Therefore, our
proposed scheme has a constant network overhead.

##  VI Security Analysis

Figure 8 outlines security features provided by different components of CSUM’s
$TT$. In particular, $TT$ integrates authentication with $AT_{curr}$, ensures
the integrity of $SUP$ through hashing, and maintains freshness with hash
chain continuity. This approach effectively safeguards against unauthorized
access and data manipulation. To summarize, CSUM leverages a hash chain for
generating $AT$ and embeds $AT$ within $TT$ to preserve authenticity,
integrity, and freshness for each $SUP$ transmission.

Figure 8: $TT$ structure: authentication with $AT_{curr}$, integrity via $SUP$
hash, and freshness with hash chain continuity.

###  VI-A Authentication

Authentication is facilitated by utilizing $AT_{curr}$, which is known only to
the legitimate entities involved in the software update process. In CSUM, each
$AT_{curr}$ is cryptographically linked to $AT_{prev}$ as shown in Eq. (2),
preventing adversaries from determining the pre-image of $AT_{prev}$ in
polynomial time without breaking pre-image resistance property of a
cryptographic hash function. Including $AT_{curr}$ within $TT$ enables CS to
verify the origin of $SUP$, preventing impersonation and unauthorized access.

Successfully guessing $AT_{curr}$ allows the recovery of $AT_{prev}$, enabling
an adversary to create a valid $TT$ for their altered update. However, the
likelihood of accurately guessing $AT_{curr}$ is extremely low, i.e.,
$1/2^{256}$. Alternatively, correctly guessing $AT_{prev}$ permits the
extraction of $AT_{curr}$, not by deriving pre-image but by employing Eq. (3).
However, the probability of guessing $AT_{prev}$ remains similarly low.

###  VI-B Integrity

The integrity of $SUP$ is maintained by incorporating the hash of $SUP$
concatenated with $AT_{prev}$ in a $TT$, rendering $TT$ update specific. Any
changes in $SUP$ data would result in a distinct hash output, generating
different $TT$ and an invalid $AT_{curr}$ as depicted in Eq. (2). If Eq. (2)
is not satisfied during verification at CS, it indicates tampering with $SUP$,
leading to rejection. Now we delve into a brief proof-by-contradiction for
asserting “Any unauthorized modification to $SUP$ is detectable.”

  * •

Assume an adversary can make an undetectable modification to $SUP$.

  * •

An undetectable modification implies that after altering $SUP$, the resulting
$TT$ is still valid, i.e., $TT\coloneqq AT_{curr}\oplus
h(SUP^{\prime}\mathbin{\|}AT_{prev})$.

  * •

This requires
$h(SUP\mathbin{\|}AT_{prev})=h(SUP^{\prime}\mathbin{\|}AT_{prev})$. However,
finding such $SUP$′, where $h(SUP\mathbin{\|}AT_{prev})$ is equal to
$h(SUP^{\prime}\mathbin{\|}AT_{prev})$ breaks second pre-image resistance of a
cryptographic hash function.

Our assumption leads to a contradiction, establishing that integrity in CSUM
is maintained via detection of modifications.

###  VI-C Freshness

Freshness is ensured by leveraging the sequential nature of the hash chain
used to generate $AT$. Since each $AT_{curr}$ is used only once and is
replaced by the next in the hash chain for the subsequent update, ensuring
that each $TT$ is unique. We are utilizing each token in the hash chain as a
one-time password. CS verifies Eq. (2) to ascertain the freshness of an
update, mitigating replay attacks where adversaries attempt to resend old
$SUP$s with previously valid $TT$s.

Attack prevention: CSUM inherently protects against common attacks including:

  1. 1.

Replay attacks: CSUM utilizes one-time tokens derived from a hash chain,
making it resistant to replay attacks. CS rejects previously captured $SUP$
along with their respective $TT$s as they fail to correct $AT_{curr}$, leading
to the automatic rejection of the update.

  2. 2.

Malicious update attacks: CSUM generates a portion of the $TT$ using a hash of
$SUP$ combined with $AT_{prev}$ to tackle malicious update attacks. Any
modification in $SUP$ renders the resulting $TT$ invalid, preventing CS from
deriving the correct $AT_{curr}$ and resulting in the rejection of a malicious
update.

  3. 3.

Token swapping attacks: CSUM is resistant to token swapping attacks as CS
could not derive correct $AT_{curr}$ from old authentic TT, leading to the
automatic rejection of the outdated update.

##  VII Limitations

The potential limitations of CSUM are as follows:

  1. 1.

Unique hash chain for each satellite: CSUM requires a unique hash chain for
every satellite. However, it may not be an issue as the administrator and GS
are resource-rich. The size of the hash chain, which the administrator
generates, is minimal. For instance, storing a hash chain of length 100
requires only 3.2 KB. Moreover, the size of each token is the same as the size
of the hash function output (making it suitable for the administrator, GS, and
even CS). Finally, there are a finite number of satellites under the control
of GS.

  2. 2.

Re-initialize hash chain: CSUM requires re-initializing the hash chain once
all the tokens are used in the existing hash chain. Authors in [41, 42, 43]
demonstrate efficient ways to re-initialize the hash chain, which can be
extended to our work as well.

  3. 3.

Lack of confidentiality: An increasing number of CS projects are moving
towards open-source software [44]. The emphasis has shifted from the principle
of security through obscurity towards a model that prefers transparency and
collaborative security practices. Open-source projects benefit from this
paradigm by allowing broader inspection and collective improvement. Therefore,
the security of CSUM does not rely on concealing the software’s components but
rather on the robustness of the cryptographic methods implemented.

##  VIII Conclusion and future work

The fundamental requirements of authentication, integrity, and data freshness
are essential for ensuring the security of $SUP$s broadcast to CS. In this
paper, we propose a lightweight scheme that ensures authentication, integrity,
and data freshness for CS software updates, providing a practical solution
specifically tailored to the resource-constrained environment of CS. We
validate the practical feasibility and efficacy of our proposed approach by
developing a proof of concept. CSUM does have limitations, such as the
requirement for unique hash chains for each CS and the need for hash chain re-
initialization. Despite these challenges, our work significantly improves the
overall security and the performance of the software update procedure for CS.

In the future, we will explore a scalable and secure group update scheme for a
cluster of CSs, eliminating the need for unique $AT$ per satellite/update.

## References

  * [1] W. Lechner and S. Baumann, “Global Navigation Satellite Systems,” _Computers and Electronics in Agriculture_ , vol. 25, no. 1-2, pp. 67–85, 2000.
  * [2] S. Kalsi, “Satellite based Weather Forecasting,” _Satellite remote sensing and GIS applications in agricultural meteorology_ , vol. 331, 2002.
  * [3] M. Antonini, A. De Luise, M. Ruggieri, and D. Teotino, “Satellite Data Collection & Forwarding Systems,” _IEEE Aerospace and Electronic Systems Magazine_ , vol. 20, no. 9, pp. 25–29, 2005.
  * [4] M. Swartwout, “The First One Hundred Cubesats: A Statistical Look,” _Journal of Small Satellites_ , vol. 2, no. 2, pp. 213–233, 2013.
  * [5] K. Woellert, P. Ehrenfreund, A. J. Ricco, and H. Hertzfeld, “Cubesats: Cost-effective Science and Technology Platforms for Emerging and Developing Nations,” _Elsevier Advances in Space Research_ , vol. 47, no. 4, pp. 663–684, 2011.
  * [6] A. Bellissimo, J. Burgess, and K. Fu, “Secure Software Updates: Disappointments and New Challenges,” in _USENIX Workshop on Hot Topics in Security_ , 2006.
  * [7] M. Eshaq, I. Al-Midfa, Z. Al-Shamsi, S. Atalla, S. Al-Mansoori, and H. Al-Ahmad, “Flight Software Design and Implementation for a CubeSat,” in _IEEE Advances in Science and Engineering Technology International Conferences_ , 2023, pp. 1–6.
  * [8] D. J. Kessler, N. L. Johnson, J. Liou, and M. Matney, “The Kessler Syndrome: Implications to Future Space Operations,” _Advances in the Astronautical Sciences_ , vol. 137, no. 8, 2010.
  * [9] J. Pavur and I. Martinovic, “The Cyber-ASAT: On the Impact of Cyber Weapons in Outer Space,” in _IEEE Int. Conf. on Cyber Conflict_ , 2019, pp. 1–18.
  * [10] J. Drmola and T. Hubik, “Kessler Syndrome: System Dynamics Model,” _Space Policy_ , pp. 29–39, 2018.
  * [11] F.-X. Molina, E. Baccelli, K. Zandberg, D. Donsez, and O. Alphand, “Cubedate: Securing Software Updates in Orbit for Low-Power Payloads Hosted on CubeSats,” in _IFIP/IEEE Int. Conf. on Performance Evaluation and Modeling in Wired and Wireless Networks_ , 2023, pp. 1–6.
  * [12] (2022) Thingsat project. CSUG - Grenoble University Space Center. [Online]. Available: https://www.csug.fr/projects/thingsat-project/
  * [13] R. Nilchiani, “Valuing Software-based Options for Space Systems Flexibility,” _Acta Astronautica_ , vol. 65, no. 3-4, pp. 429–441, 2009\.
  * [14] B. Garrido, A. Garcia, N. Alfaro, and J. Asensio, “MINISAT01 on-board Software Maintenance,” in _Data Systems in Aerospace_ , vol. 422, 1998, p. 65.
  * [15] W. Marshall and C. Boshuizen, “Planet Labs’ Remote Sensing Satellite System,” 2013.
  * [16] C.-S. Park, “One-time Password based on Hash Chain without Shared Secret and Re-registration,” _Computers & Security_, vol. 75, pp. 138–146, 2018\.
  * [17] S. Halder, A. Ghosal, and M. Conti, “Secure Over-The-Air Software Updates in Connected Vehicles: A Survey,” _Computer Networks_ , vol. 178, p. 107343, 2020.
  * [18] T. Karthik, A. Brown, S. Awwad, D. McCoy, R. Bielawski, C. Mott, S. Lauzon, A. Weimerskirch, and J. Cappos, “Uptane: Securing Software Updates for Automobiles,” in _International Conference on Embedded Security in Car_ , 2016, pp. 1–11.
  * [19] M. Baza, M. Nabil, N. Lasla, K. Fidan, M. Mahmoud, and M. Abdallah, “Blockchain-based Firmware Update Scheme Tailored for Autonomous Vehicles,” in _IEEE Wireless Communications & Networking_, 2019, p. 7.
  * [20] D. K. Nilsson and U. E. Larson, “Secure Firmware Updates over the Air in Intelligent Vehicles,” in _IEEE International Conference on Communications Workshops_ , 2008, pp. 380–384.
  * [21] M. Steger, C. A. Boano, T. Niedermayr, M. Karner, J. Hillebrand, K. Roemer, and W. Rom, “An Efficient and Secure Automotive Wireless Software Update Framework,” _IEEE Transactions on Industrial Informatics_ , vol. 14, no. 5, pp. 2181–2193, 2017.
  * [22] M. S. Idrees, H. Schweppe, Y. Roudier, M. Wolf, D. Scheuermann, and O. Henniger, “Secure Automotive On-Board Protocols: A Case of Over-the-Air Firmware Updates,” in _Springer Communication Technologies for Vehicles. Nets4Cars/Nets4Trains_ , 2011, pp. 224–238.
  * [23] R. Petri, M. Springer, D. Zelle, I. McDonald, A. Fuchs, and C. Krauß, “Evaluation of Lightweight TPMs for Automotive Software Updates over the Air,” in _International Conf. on Embedded Security in Car_ , 2016, pp. 1–15.
  * [24] K. V. de Souza, Y. Bouslimani, and M. Ghribi, “Flight Software Development for a CubeSat Application,” _IEEE Journal on Miniaturization for Air and Space Systems_ , vol. 3, no. 4, pp. 184–196, 2022.
  * [25] J. Willbold, M. Schloegel, M. Vögele, M. Gerhardt, T. Holz, and A. Abbasi, “Space Odyssey: An Experimental Software Security Analysis of Satellites,” in _IEEE Symposium on Security and Privacy_ , 2023.
  * [26] S. Fitzsimmons, _Reliable Software Updates for On-orbit Cubesat Satellites_. California Polytechnic State University, 2012.
  * [27] I. Sünter, A. Slavinskis, U. Kvell, A. Vahter, H. Kuuste, M. Noorma, J. Kutt, R. Vendt, K. Tarbe, M. Pajusalu _et al._ , “Firmware Updating Systems for Nanosatellites,” _IEEE Aerospace and Electronic Systems Magazine_ , vol. 31, no. 5, pp. 36–44, 2016.
  * [28] A. Slavinskis, M. Pajusalu, H. Kuuste, E. Ilbis, T. Eenmäe, I. Sünter, K. Laizans, H. Ehrpais, P. Liias, E. Kulu _et al._ , “ESTCube-1 In-Orbit Experience and Lessons Learned,” _IEEE Aerospace and Electronic Systems Magazine_ , vol. 30, no. 8, pp. 12–22, 2015.
  * [29] B. Bezem and P. K. J. Fjellby, “Authenticated Uplink for the Small, Low Orbit Student Satellite NUTS,” _Department of Telematics, NTNU_ , 2012.
  * [30] O. Challa, G. Bhat, and J. Mcnair, “CubeSec and GndSec: A Lightweight Security Solution for CubeSat Communications,” 2012.
  * [31] L. Wood, W. M. Eddy, W. Ivancic, J. McKim, and C. Jackson, “Saratoga: A Delay-Tolerant Networking Convergence Layer with Efficient Link Utilization,” in _IEEE International Workshop on Satellite and Space Communications_ , 2007, pp. 168–172.
  * [32] C. Boyd, A. Mathuria, and D. Stebila, _Protocols for Authentication and Key Establishment_. Springer, 2020.
  * [33] R. Davies, “Hardware Random Number Generators,” in _15th Australian Statistics Conference_ , 2000.
  * [34] L. Lamport, “Password Authentication with Insecure Communication,” _Communications of the ACM_ , vol. 24, no. 11, pp. 770–772, 1981.
  * [35] (2023) Putty v0.80. [Online]. Available: https://the.earth.li/ sgtatham/putty/0.80/w64/putty.exe
  * [36] (2023) Notepad++ v8.6. [Online]. Available: https://github.com/notepad-plus-plus/notepad-plus-plus/releases/download/v8.6/npp.8.6.Installer.x64.exe
  * [37] (2023) FileZilla v3.66.4. [Online]. Available: https://download.filezilla-project.org/ client/FileZilla_3.66.4_win64_sponsored2-setup.exe
  * [38] (2023) Audacity v3.4.2. [Online]. Available: https://github.com/audacity/audacity/releases/download/ Audacity-3.4.2/audacity-win-3.4.2-64bit.exe
  * [39] M. Bellare and P. Rogaway, “PSS: Provably Secure Encoding Method for Digital Signatures,” 1998.
  * [40] (2023) Cryptography. [Online]. Available: https://pypi.org/project/cryptography/
  * [41] V. Goyal, “How to Re-initialize a Hash Chain,” _Crypto. ePrint Archive_ , 2004.
  * [42] Y. Zhao and D. Li, “An Improved Elegant Method to Re-initialize Hash Chains,” _Crypto. ePrint Archive_ , 2005.
  * [43] H. Zhang, X. Li, and R. Ren, “A Novel Self-renewal Hash Chain and its Implementation,” in _IEEE/IFIP International Conference on Embedded and Ubiquitous Computing_ , 2008, pp. 144–149.
  * [44] M. Shalashov and A. Kiseleva, “Review of Open-source Cubesat Projects,” in _Journal of Physics: Conference Series_ , vol. 1925, no. 1, 2021, p. 012039\.


# Symmetric Bidirectional Quantum Teleportation using a Six-Qubit Cluster
State as a Quantum Channel

Javid A Malik  Muzaffar Qadir Lone  Rayees A Mala  Department of Physics,
University of Kashmir, Srinagar-190006, India

###### Abstract

Bidirectional quantum teleportation is a fundamental protocol for exchanging
quantum information between two quantum nodes. All bidirectional quantum
teleportation protocols till now have achieved a maximum efficiency of $40\%$.
Here, we propose a new scheme for symmetric bidirectional quantum
teleportation using a six-qubit cluster state as the quantum channel, for
symmetric ($3\leftrightarrow 3$) qubit bidirectional quantum teleportation of
a special three-qubit entangled state. The novelty of our scheme lies in its
generalization for ($N\leftrightarrow N$) qubit bidirectional quantum
teleportation employing a $2N$-qubit cluster state. The efficiency of the
proposed protocol is remarkably increased to $50\%$ which is highest till now.
Interestingly, only GHZ-state measurements and four Toffoli-gate operations
are necessary which is independent of the number $(N)$ of qubits to be
teleported.

##  I Introduction

Quantum Teleportation (QT) first proposed by Bennett et al. [1], is one of the
most extraordinary applications of the quantum correlations i.e. entanglement
[2] present in a composite quantum system. It is a communication protocol that
enables transmission of quantum information from one location to another, with
the aid of preshared entanglement, local operations, and classical
communications. Since its inception, many key developments in the QT have been
reported [3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18].

Bidirectional quantum teleportation (BQT) [19] is an advanced version of QT
and is defined as the bilateral QT protocol between two quantum nodes in a
quantum communication channel. This protocol finds its applications in
cryptography such as quantum secure direct communication (QSDC)[20], quantum
secret sharing (QSS), and cryptographic switch [21], etc. BQT can be carried
out with or without the aid of a controller. The first bidirectional quantum
controlled teleportation (BQCT) protocol was introduced in [19], that employed
a five-qubit cluster state for mutual transfer of an unknown single-qubit
state between Alice and Bob with the help of controller Charlie. Several BQCT
protocols have been proposed by utilizing multi-qubit cluster states as a
quantum channel[22, 23, 24, 25, 26]. In[24] seven-qubit cluster state is used
for asymmetric bidirectional quantum controlled teleportation where Alice
sends an arbitrary single-qubit state to Bob and Bob sends a two-qubit state
to Alice with the control of Charlie.

Several two-party BQT protocols have been proposed[27, 28, 29, 30, 31, 32,
33]. Shang et al. [27], proposed an asymmetric bidirectional quantum
teleportation protocol in absence of the controller. By utilizing a five-qubit
cluster state as a channel, Alice teleports a two-qubit entangled state to Bob
and Bob sends an arbitrary single-qubit state to Alice. Using the eight-qubit
cluster state as the quantum channel Zadeh et al.[28] faithfully achieved the
BQT of an arbitary two-qubit state. To achieve the BQT of multi-qubit states
different cluster states were used. Chen et al.[29] utilised a four-qubit GHZ-
state and two Bell states as a quantum channel to mutually teleport two
arbitrary single-qubit states and an unknown three-qubit state between Alice
and Bob. In[31], a new BQT protocol was proposed using a six-qubit cluster
state, however, it used non-local CNOT operation for its action, resulting in
a decrease of intrinsic efficiency and an increase in operational complexity.
This use of non-local CNOT operation was eliminated by Verma [32] by proposing
a modified BQT protocol. In, order to employ N-qubit BQT Verma [33] proposed a
protocol with one of the G-state[14] as a quantum channel. In this protocol,
to achieve faithful transmission of N-qubits 2(2N-1)-CNOT gate operations
along with two Hadamard gate operations are required. This increases the
operational complexity without any improvement in intrinsic efficiency. It is
therefore desirable to have a new scheme that reduces the operational
complexity by reducing the number of CNOT gate operations and increasing the
intrinsic efficiency.

Along this direction, to have greater efficiency and minimum complexity, we
propose a new symmetric BQT protocol 1 for mutual transmission of a special
three-qubit entangled state using six-qubit cluster state as a quantum
channnel. We also generalize our proposed protocol for implementation to
N-qubit BQT. The novelity of our scheme as compared to the previous
protocols[27, 28, 29, 30, 31, 32, 33] is (i) only four Toffoli gate operations
are required which is independent of the number (N) of qubits to be
teleported, (ii) operation complexity is greatly reduced, (iii) by introducing
the auxiliary qubits the intrinsic efficiency is highest till now ($50\%$)
achieved in any bidirectional quantum teleportation protocol.

This paper is organised as follows: In Section II, the proposed BQT protocol
based on six-qubit cluster state is presented in detail. In Section III, we
generalize our proposed protocol for N-qubit BQT. Finally, the we compare our
work with previous protocols and conclude in section IV.

##  II Protocol for Symmetric BQT ($3\leftrightarrow 3$) Using Six Qubit
Cluster State

We propose a scheme for BQT that utilizes a six qubit cluster state as a
quantum channel shared between Alice and Bob:

$\displaystyle\ket{\phi}_{123456}=\frac{1}{2}\Big{(}\ket{000000}+\ket{000111}+\ket{111000}+\ket{111111}\Big{)}$

where the indices $1-6$ refer to the ordering of qubits. Assume that Alice is
in the possession of a special three-qubit entangled state, which is given by

$\displaystyle\ket{\chi}_{a_{1}a_{2}a_{3}}=\large(\alpha\ket{000}+\beta\ket{111})_{a_{1}a_{2}a_{3}}$
(1)

with $|\alpha|^{2}+|\beta|^{2}=1$. At the same time, Bob also possesses a
similar three qubit entangled state which can be expressed as

$\displaystyle\ket{\chi}_{b_{1}b_{2}b_{3}}=\large(\gamma\ket{000}+\delta\ket{111})_{b_{1}b_{2}b_{3}}$
(2)

such that $|\gamma|^{2}+|\delta|^{2}=1$. Now, Alice and Bob wants to transmit
the respective states to each other simultaneously, let the quantum channel
given by Eq.(1) be distributed between Alice and Bob so that the qubits 1, 4,
5 belongs to Alice and Bob holds the qubits 2, 3, 6. The proposed scheme for
implementation of BQT ($3\leftrightarrow 3$) is executed in the following
manner:

Figure 1: Schematic representation of the Symmetric BQT proposed in this
paper. Alice and Bob share a six qubit cluster state, and both parties send
three qubit states (equations 1-2), bi-directionally. The upper dashed boxes
represent three-qubit GHZ-state measurement performed by Alice and the lower
dashed box represents Bob’s three-qubit GHZ-state measurement. $U_{2}\otimes
U_{3}$ refers to recovery operations performed by Bob and $U_{4}\otimes U_{5}$
by Alice as shown in Table-2. $\ket{\chi}_{a_{1}a_{2}}$ and
$\ket{\chi}_{b_{1}b_{2}}$ are the two qubit entangled states recovered by Bob
and Alice respectively. Using, only two auxillary qubits
$(\ket{0_{A}},\ket{0_{B}})$along with four Toffoli gate operations, the
bidirectional teleportation is succesful with the utilization of minimum
resources and maximum efficiency as compared to the previous proposed
protocols. $(\alpha|000\rangle+\beta|111\rangle)_{23B}$ and
$(\gamma|000\rangle+\delta|111\rangle)_{45A}$ are the recovered three qubit
states.

Step-I: Conversion of three-qubit entangled state to two-qubit entangled state
and single-qubit state (Toffoli-gate operations): Toffoli-gate (also known as
CCNOT-gate) is a three-qubit gate with two controls and one target. It
performs an X on the target only if both controls are in the state
$|1\rangle$.

  * •

Alice applies Toffoli-gate with $a_{1}a_{2}$ as control and $a_{3}$ as target
such that
$\ket{\chi}_{a_{1}a_{2}a_{3}}\longrightarrow\ket{\chi}_{a_{1}a_{2}}\otimes\ket{0}_{a_{3}}$

with

$\ket{\chi}_{a_{1}a_{2}}=\large(\alpha\ket{00}+\beta\ket{11})_{a_{1}a_{2}}$
(3)

  * •

Next, Bob applies Toffoli-gate with $b_{1}b_{2}$ as control and $b_{3}$ as
target such that
$\ket{\chi}_{b_{1}b_{2}b_{3}}\longrightarrow\ket{\chi}_{b_{1}b_{2}}\otimes\ket{0}_{b_{3}}$

with

$\displaystyle\ket{\chi}_{b_{1}b_{2}}=\large(\gamma\ket{00}+\delta\ket{11})_{b_{1}b_{2}}.$
(4)

After this step the joint state of the qubits $a_{1}a_{2}b_{1}b_{2}123456$
becomes

$\displaystyle\ket{\psi}_{a_{1}a_{2}b_{1}b_{2}}^{123456}$ $\displaystyle=$
$\displaystyle\ket{\chi}_{a_{1}a_{2}}\otimes\ket{\chi}_{b_{1}b_{2}}\otimes\ket{\phi}_{123456}$
(5) $\displaystyle=$
$\displaystyle\frac{1}{2}\big{(}\alpha\ket{00}+\beta\ket{11})_{a_{1}a_{2}}\otimes\large(\gamma\ket{00}+\delta\ket{11})_{b_{1}b_{2}}\otimes\large(\ket{000000}+\ket{000111}+\ket{111000}+\ket{111111})_{123456}$

The joint state $\ket{\psi}_{a_{1}a_{2}b_{1}b_{2}}^{123456}$ takes the form

$\displaystyle\ket{\psi}_{a_{1}a_{2}b_{1}b_{2}}^{123456}$ $\displaystyle=$
$\displaystyle\frac{1}{4}\Big{[}\ket{\eta_{1}^{\pm}}\ket{\zeta_{1}^{\pm}}\ket{\psi_{1}^{\pm}}+\ket{\eta_{1}^{\pm}}\ket{\zeta_{1}^{\mp}}\ket{\psi_{2}^{\pm}}+\ket{\eta_{1}^{\pm}}\ket{\zeta_{2}^{\pm}}\ket{\psi_{3}^{\pm}}+\ket{\eta_{1}^{\pm}}\ket{\zeta_{2}^{\mp}}\ket{\psi_{4}^{\pm}}$
(6)
$\displaystyle+\ket{\eta_{2}^{\pm}}\ket{\zeta_{1}^{\pm}}\ket{\psi_{5}^{\pm}}+\ket{\eta_{2}^{\pm}}\ket{\zeta_{1}^{\mp}}\ket{\psi_{6}^{\pm}}+\ket{\eta_{2}^{\pm}}\ket{\zeta_{2}^{\pm}}\ket{\psi_{7}^{\pm}}+\ket{\eta_{2}^{\pm}}\ket{\zeta_{2}^{\mp}}\ket{\psi_{8}^{\pm}}\Big{]}$

where $\ket{\eta_{i}^{\pm}}$ and $\ket{\zeta_{i}^{\pm}}$ are GHZ states 2
given by

$\displaystyle\ket{\eta_{1}^{\pm}}_{a_{1}a_{2}1}$
$\displaystyle=\frac{1}{\sqrt{2}}\Big{(}\ket{000}\pm\ket{111}\Big{)}$ (7)
$\displaystyle\ket{\eta_{2}^{\pm}}_{a_{1}a_{2}1}$
$\displaystyle=\frac{1}{\sqrt{2}}\Big{(}\ket{001}\pm\ket{110}\Big{)}$ (8)
$\displaystyle\ket{\zeta_{1}^{\pm}}_{b_{1}b_{2}6}$
$\displaystyle=\frac{1}{\sqrt{2}}\Big{(}\ket{000}\pm\ket{111}\Big{)}$ (9)
$\displaystyle\ket{\zeta_{2}^{\pm}}_{b_{1}b_{2}6}$
$\displaystyle=\frac{1}{\sqrt{2}}\Big{(}\ket{001}\pm\ket{110}\Big{)}$ (10)

and $\ket{\psi_{i}}^{\pm}$ are the states of the qubits 2, 3, 4 and 5 shown in
Table-1.

Figure 2: Quantum circuit to obtain the GHZ-states used for measurement by
Alice and Bob given in equations 7 to 10.

Step-II: Measurements and classical communications

  * •

Alice performs a GHZ-state measurement(GSM) on her qubits ($a_{1}a_{2}1$) in
the measurement basis made up of the states $\ket{\eta_{i}}^{\pm},i=1,2.$

  * •

Bob also performs a GHZ-state measurement(GSM) on his qubits ($b_{1}b_{2}6$)
in measurement basis consisting of the states $\ket{\zeta_{i}}^{\pm},i=1,2.$

Afterwards Alice and Bob convey their measurement outcomes to each other by
classical communication, and corresponding to each measurement outcome is a
collapsed state of the qubits 2, 3, 4 and 5. In, order to recover the target
states Alice and Bob apply the local operations on their qubits. The collapsed
states of particles 2, 3, 4 and 5 after GHZ-state measurements(GSM) are given
in Table-I.

$\ket{\psi_{1}^{\pm}}$ | $=\big{(}\alpha\ket{00}\pm\beta\ket{11}\big{)}_{23}\otimes\big{(}\gamma\ket{00}\pm\delta\ket{11}\big{)}_{45}$
---|---
$\ket{\psi_{2}^{\pm}}$ | $=\big{(}\alpha\ket{00}\pm\beta\ket{11}\big{)}_{23}\otimes\big{(}\gamma\ket{00}\mp\delta\ket{11}\big{)}_{45}$
$\ket{\psi_{3}^{\pm}}$ | $=\big{(}\alpha\ket{00}\pm\beta\ket{11}\big{)}_{23}\otimes\big{(}\gamma\ket{11}\pm\delta\ket{00}\big{)}_{45}$
$\ket{\psi_{4}^{\pm}}$ | $=\big{(}\alpha\ket{00}\pm\beta\ket{11}\big{)}_{23}\otimes\big{(}\gamma\ket{11}\mp\delta\ket{00}\big{)}_{45}$
$\ket{\psi_{5}^{\pm}}$ | $=\big{(}\alpha\ket{11}\pm\beta\ket{00}\big{)}_{23}\otimes\big{(}\gamma\ket{00}\pm\delta\ket{11}\big{)}_{45}$
$\ket{\psi_{6}^{\pm}}$ | $=\big{(}\alpha\ket{11}\pm\beta\ket{00}\big{)}_{23}\otimes\big{(}\gamma\ket{00}\pm\delta\ket{11}\big{)}_{45}$
$\ket{\psi_{7}^{\pm}}$ | $=\big{(}\alpha\ket{11}\pm\beta\ket{00}\big{)}_{23}\otimes\big{(}\gamma\ket{11}\pm\delta\ket{00}\big{)}_{45}$
$\ket{\psi_{8}^{\pm}}$ | $=\big{(}\alpha\ket{11}\pm\beta\ket{00}\big{)}_{23}\otimes\big{(}\gamma\ket{11}\mp\delta\ket{00}\big{)}_{45}$
Table 1:  The collapsed states of the qubits 2, 3, 4 and 5 after GHZ-state
measurements.

Step-III: Local Operations

  * •

Alice applies appropriate unitary operation($U_{4}\otimes U_{5}$) to recover
the two qubit state depending upon classical information received from Bob’s
measurement.

  * •

Bob also applies appropriate unitary operation($U_{2}\otimes U_{3}$) to
recover the two qubit state depending upon Alice’s measurement outcome.

The GHZ-state measurement outcomes of Alice and Bob and corresponding unitary
operations are given in Table-2. In order to recover the three qubit target
entangled states, once two qubit entangled states are recovered by Alice and
Bob, we introduce two auxiliary qubits $\ket{0}_{A}$ and $\ket{0}_{B}$.

Alice’s MR |  Bob’s MR |  Collapsed state |  Alice,s UO ($U_{4}\otimes U_{5}$) |  Bob’s UO ($U_{2}\otimes U_{3}$)
---|---|---|---|---
$\ket{\eta_{1}^{+}}$ |  $\ket{\zeta_{1}^{+}}$ |  $\ket{\psi_{1}^{+}}$ |  $\sigma_{0}\otimes\sigma_{0}$ |  $\sigma_{0}\otimes\sigma_{0}$
$\ket{\eta_{1}^{-}}$ |  $\ket{\zeta_{1}^{-}}$ |  $\ket{\psi_{1}^{-}}$ |  $\sigma_{0}\otimes\sigma_{3}$ |  $\sigma_{0}\otimes\sigma_{3}$
$\ket{\eta_{1}^{+}}$ |  $\ket{\zeta_{1}^{-}}$ |  $\ket{\psi_{2}^{+}}$ |  $\sigma_{0}\otimes\sigma_{3}$ |  $\sigma_{0}\otimes\sigma_{0}$
$\ket{\eta_{1}^{-}}$ |  $\ket{\zeta_{1}^{+}}$ |  $\ket{\psi_{2}^{-}}$ |  $\sigma_{0}\otimes\sigma_{0}$ |  $\sigma_{3}\otimes\sigma_{0}$
$\ket{\eta_{1}^{+}}$ |  $\ket{\zeta_{2}^{+}}$ |  $\ket{\psi_{3}^{+}}$ |  $\sigma_{1}\otimes\sigma_{1}$ |  $\sigma_{0}\otimes\sigma_{0}$
$\ket{\eta_{1}^{-}}$ |  $\ket{\zeta_{2}^{-}}$ |  $\ket{\psi_{3}^{-}}$ |  $\sigma_{1}\otimes i\sigma_{2}$ |  $\sigma_{3}\otimes\sigma_{0}$
$\ket{\eta_{1}^{+}}$ |  $\ket{\zeta_{2}^{-}}$ |  $\ket{\psi_{4}^{+}}$ |  $i\sigma_{2}\otimes\sigma_{1}$ |  $\sigma_{0}\otimes\sigma_{0}$
$\ket{\eta_{1}^{-}}$ |  $\ket{\zeta_{2}^{+}}$ |  $\ket{\psi_{4}^{-}}$ |  $i\sigma_{2}\otimes i\sigma_{2}$ |  $\sigma_{0}\otimes\sigma_{3}$
$\ket{\eta_{2}^{+}}$ |  $\ket{\zeta_{1}^{+}}$ |  $\ket{\psi_{5}^{+}}$ |  $\sigma_{0}\otimes\sigma_{0}$ |  $\sigma_{1}\otimes\sigma_{1}$
$\ket{\eta_{2}^{-}}$ |  $\ket{\zeta_{1}^{-}}$ |  $\ket{\psi_{5}^{-}}$ |  $\sigma_{0}\otimes\sigma_{3}$ |  $i\sigma_{2}\otimes\sigma_{1}$
$\ket{\eta_{2}^{+}}$ |  $\ket{\zeta_{1}^{-}}$ |  $\ket{\psi_{6}^{+}}$ |  $\sigma_{3}\otimes\sigma_{0}$ |  $i\sigma_{2}\otimes i\sigma_{2}$
$\ket{\eta_{2}^{-}}$ |  $\ket{\zeta_{1}^{+}}$ |  $\ket{\psi_{6}^{-}}$ |  $\sigma_{0}\otimes\sigma_{0}$ |  $\sigma_{1}\otimes i\sigma_{2}$
$\ket{\eta_{2}^{+}}$ |  $\ket{\zeta_{1}^{+}}$ |  $\ket{\psi_{5}^{+}}$ |  $\sigma_{0}\otimes\sigma_{0}$ |  $\sigma_{1}\otimes\sigma_{1}$
$\ket{\eta_{2}^{+}}$ |  $\ket{\zeta_{2}^{+}}$ |  $\ket{\psi_{7}^{+}}$ |  $\sigma_{1}\otimes\sigma_{1}$ |  $\sigma_{1}\otimes\sigma_{1}$
$\ket{\eta_{2}^{-}}$ |  $\ket{\zeta_{2}^{-}}$ |  $\ket{\psi_{7}^{-}}$ |  $\sigma_{1}\otimes i\sigma_{2}$ |  $i\sigma_{2}\otimes\sigma_{1}$
$\ket{\eta_{2}^{+}}$ |  $\ket{\zeta_{2}^{-}}$ |  $\ket{\psi_{8}^{+}}$ |  $i\sigma_{2}\otimes\sigma_{1}$ |  $i\sigma_{2}\otimes i\sigma_{2}$
$\ket{\eta_{2}^{-}}$ |  $\ket{\zeta_{2}^{+}}$ |  $\ket{\psi_{8}^{-}}$ |  $i\sigma_{2}\otimes i\sigma_{2}$ |  $\sigma_{1}\otimes i\sigma_{2}$
Table 2: Measurement outcomes, corresponding unitary operations and collapsed
states.

Step-IV: Toffoli-gate operations

  * •

Alice applies Toffoli gate with qubits 4, 5 as control and $\ket{0}_{A}$ as
target qubit to recover the target three qubit entangled state
($\gamma\ket{000}+\delta\ket{111}\big{)}_{45A}$ shown in Figure- 1

  * •

Bob also applies Toffoli gate with qubits 2, 3 as control and $\ket{0}_{B}$ as
target qubits to recover the desired state
($\alpha\ket{000}+\beta\ket{111}\big{)}_{23B}$ shown in Figure-1

Thus, symmetric ($3\leftrightarrow 3$) BQT protocol is faithfully and
deterministically observed.

##  III Generalization to $N$-Qubits

In this section our proposed scheme for symmetric BQT can be generalised for
($N\leftrightarrow N$) qubit BQT using the 2N-qubit cluster state as a quantum
channel. In, our scheme no additional quantum resources are required which
makes it a novel scheme for BQT. Let Alice and Bob are respectively in a
possession of the following $N$-qubit entangled states

$\displaystyle\ket{\chi}_{a_{1}a_{2}\dots a_{N}}$ $\displaystyle=$
$\displaystyle(\alpha\ket{00\dots 0}+\beta\ket{11\dots 1})_{a_{1}a_{2}\dots
a_{N}}$ (11) $\displaystyle\ket{\chi}_{b_{1}b_{2}\dots b_{N}}$
$\displaystyle=$ $\displaystyle(\gamma\ket{00\dots 0}+\delta\ket{11\dots
1})_{b_{1}b_{2}\dots b_{N}}$ (12)

By utilising the $2N$-qubit cluster state and employing our scheme Alice and
Bob can faithfully achieve mutual transmission of the above $N$-qubit states.
The $2N$-qubit quantum channel has the form

$\displaystyle\ket{\phi}_{12\dots
2N}=\frac{1}{{2}}\bigg{(}\ket{x_{1}}+\ket{x_{2}}+\ket{x_{3}}+\ket{x_{4}}\bigg{)}_{12\dots
2N}$ (13)

where

$\displaystyle\ket{x_{1}}=\otimes_{i=1}^{N}\ket{0}\otimes_{i=N}^{2N}\ket{0},~{}~{}~{}~{}~{}~{}\ket{x_{2}}=\otimes_{i=1}^{N}\ket{1}\otimes_{i=N}^{2N}\ket{1}$
(14)
$\displaystyle\ket{x_{3}}=\otimes_{i=1}^{N}\ket{0}\otimes_{i=N}^{2N}\ket{1},~{}~{}~{}~{}~{}~{}\ket{x_{4}}=\otimes_{i=1}^{N}\ket{1}\otimes_{i=N}^{2N}\ket{0}$
(15)

Let Alice has qubits $1,N+1,\dots,2N-1$ and Bob has the qubits
$2,3,\dots,N,2N.$ The steps involved in ($N\leftrightarrow N$)qubit symmetric
BQT protocol are same as that of the ($3\leftrightarrow 3$) qubit BQT
protocol. The implementation of our scheme for general case is described in
following steps.

First step: Alice applies a Toffoli gate operation with ($a_{N-2},a_{N-1}$) as
control qubits and $a_{N}$ as target qubit to convert the N-qubit state to be
teleported into an $N-1$ qubit entangled state and a single qubit. Bob also
applies Toffoli gate with ($b_{N-2},b_{N-1}$) as control qubits and $b_{N}$ as
target qubit. After this step the joint state of the (4N-2) qubits
($a_{1}a_{2}\dots a_{N-1}b_{1}b_{2}\dots b_{N-1}12\dots 2N$) becomes

$\displaystyle\ket{\psi}=\ket{\chi}_{a_{1}a_{2}\dots
a_{N-1}}\otimes\ket{\chi}_{b_{1}b_{2}\dots b_{N-1}}\otimes\ket{\phi}_{12\dots
2N}$ (16)

Second step: Alice performs $N$-qubit GHZ-state measurement (NGSM) on qubits
($a_{1}a_{2}\dots a_{N-1},1)$ and convey the measurement outcomes to Bob. Bob
also performs NGSM on qubits ($b_{1}b_{2}\dots b_{N-1},2N)$ and convey the
outcomes to Alice.

Third step: Alice and Bob apply the unitary operations on their qubits
($N+1,\dots,2N-1$) and( $2,3,\dots,N$) respectively depending upon their
measurement outcomes enabling them to recover the corresponding $(N-1)$ qubit
entangled states.

Fourth step:In order to recover the target $N$-qubit entangled states, two
auxiliary qubits $\ket{0}_{A}$ and $\ket{0}_{B}$ are introduced as in section-
II. Alice applies the Toffoli gate with qubits $(2N-2,2N-1)$as control and
$\ket{0}_{A}$ as target qubit. Bob also applies Toffoli gate with $(N-1,N)$ as
control qubits and $\ket{0}_{B}$ as target qubit.

In, this manner our scheme for symmetric BQT can be generalised for (
$N\leftrightarrow N$) qubit BQT successfully. Only four Toffoli-gate
operations are required for its implementation, which is interestingly same
for general case i.e, independent of number of qubits to be teleported.

Protocol |  $q_{s}$ |  NO |  $b_{t}$ |  $q_{a}$ | BQT | $\eta$
---|---|---|---|---|---|---
[27] |  $5$ |  $2BSM$ |  $4$ |  $0$ | $2\leftrightarrow 1$ | $33.3$
[29] |  $8$ |  $4SM,4QM$ |  $8$ |  $0$ | $2\leftrightarrow 3$ | $31.25$
[30] |  $6$ |  $2GSM$ |  $4$ |  $0$ | $2\leftrightarrow 2$ | $40$
[31] |  $7$ |  1GSM,1BSM, 1SM |  $7$ |  $0$ | $3\leftrightarrow 1$ | $28.5$
[32] |  $6$ |  1GSM, 1BSM |  $4$ |  $0$ | $3\leftrightarrow 1$ | $40$
[33] |  $4$ |  $2MCB$ |  $4$ |  $2$ | $2\leftrightarrow 2$ | $40$
${\rm Our}$ |  $6$ |  $2GSM$ |  $4$ |  $2$ | $3\leftrightarrow 3$ | $50$
${\rm Our}$ |  $2N$ |  $2GSM$ |  $2N-2$ |  $2$ | $N\leftrightarrow N$ | $50$
Table 3: Comparison Among BQT protocols. Here NO means number of operations
required.

##  IV Comparison and Conclusions

To show the novelty of our BQT scheme, let us compare our protocol with the
previous protocols as shown in Table-3. The comparison is based on following
aspects: the quantum bits transmitted $q_{t}$, the quantum resources consumed
( number of qubits of the quantum channel $q_{s}$), the classical resources
transmitted $b_{t}$, the number of auxiliary qubits $q_{a}$, the required
operations (NO) and the intrinsic efficiency ($\eta$). The intrinsic
efficiency ($\eta$) is defined as

$\displaystyle\eta=\frac{q_{t}}{q_{s}+q_{a}+b_{t}}.$ (17)

It is clear that as the number of qubits to be teleported increases both the
number of quantum bits of the channel and the classical resource consumption
increases which results in the decrease of intrinsic efficiency. However, in
our scheme by introducing the auxiliary qubits no additional quantum resources
are required for implementation to the general case and the efficiency is also
remarkably increased.

In conclusion, we have proposed a novel scheme for symmetric BQT via six-qubit
cluster state as a quantum channel. Furthermore, we generalized our scheme to
implement ($N\leftrightarrow N$) qubit BQT using the $2N$-qubit cluster state
as the quantum channel. The proposed protocol is based on GHZ-state
measurements (GSM), local unitary operations and Toffoli-gate operations. In,
our scheme Alice and Bob are interested in mutual transmission of three-qubit
entangled states without a controller. We employ Toffoli-gate operations to
transform a three qubit entangled state into a two qubit entangled state and a
single qubit state. At the end of the protocol we again perform Toffoli gate
to restore the target three-qubit states. The previous protocol for $N$-qubit
BQT [33], employs $2(2N-1)$ CNOT-gate operations, Hadamard gate operations for
its implementation. In our, scheme only Four Toffoli gate operations are
necessary for $N$-qubit BQT thereby reducing the operational complexity and
quantum resources involved in the BQT scheme. From Table-3, its clear that our
scheme has the prominent advantage of more qubits transmitted and highest
intrinsic efficiency. The extension of our proposed protocol for BQT in noisy
channels and influence of auxillary qubits on efficiency will be presented
elsewhere [34].

## References

  * [1] C. H. Bennett, G. Brassard, C. Cr´epeau, R. Jozsa, A. Peres, and W. K. Wootters, Physical review letters 70, 1895 (1993).
  * [2] P. H. M. Horodecki, R. Horodecki and H. K., Rev. Mod. Phys. 81 (2009).
  * [3] R. F. Werner, Journal of Physics A: Mathematical and General 34, 7081 (2001).
  * [4] T. Sasaki, Y. Yamamoto, and M. Koashi, Nature 509, 475 (2014).
  * [5] F. Yan and X. Zhang, The European Physical Journal B-Condensed Matter and Complex Systems 41, 75 (2004).
  * [6] Z.-X. Man, Y.-J. Xia, and N. B. An, The European Physical Journal D 42, 333 (2007).
  * [7] D. Bouwmeester, J.-W. Pan, K. Mattle, M. Eibl, H. Weinfurter, and A. Zeilinger, Nature 390, 575 (1997).
  * [8] X.-S. Ma, T. Herbst, T. Scheidl, D. Wang, S. Kropatschek, W. Naylor, B. Wittmann, A. Mech, J. Kofler, E. Anisimova, et al., Nature 489, 269 (2012).
  * [9] X.-M. Jin, J.-G. Ren, B. Yang, Z.-H. Yi, F. Zhou, X.-F. Xu, S.-K. Wang, D. Yang, Y.-F. Hu, S. Jiang, et al., Nature photonics 4, 376 (2010).
  * [10] Q. Zhang, A. Goebel, C. Wagenknecht, Y.-A. Chen, B. Zhao, T. Yang, A. Mair, J. Schmiedmayer, and J.-W. Pan, Nature Physics 2, 678 (2006).
  * [11] S. Pirandola, J. Eisert, C. Weedbrook, A. Furusawa, and S. L. Braunstein, Nature photonics 9, 641 (2015).
  * [12] J.-G. Ren, P. Xu, H.-L. Yong, L. Zhang, S.-K. Liao, J. Yin, W.-Y. Liu, W.-Q. Cai, M. Yang, L. Li, et al., Nature 549, 70 (2017).
  * [13] K. Yang, L. Huang, W. Yang, and F. Song, International Journal of Theoretical Physics 48, 516 (2009).
  * [14] G. Rigolin, Physical Review A 71, 032303 (2005).
  * [15] D.-f. Li, R.-j. Wang, and E. Baagyere, Quantum Information Processing 18, 1 (2019).
  * [16] P. Agrawal and A. K. Pati, Physics Letters A 305, 12 (2002).
  * [17] D. Saha and P. K. Panigrahi, Quantum Information Processing 11, 615 (2012).
  * [18] P. Agrawal and A. Pati, Physical Review A 74, 062320 (2006).
  * [19] X.-W. Zha, Z.-C. Zou, J.-X. Qi, and H.-Y. Song, International Journal of Theoretical Physics 52, 1740 (2013).
  * [20] C. Wang, F. G. Deng, and G. L. Long, Optics communications 253, 15 (2005).
  * [21] N. Srinatha, S. Omkar, R. Srikanth, S. Banerjee, and A. Pathak, Quantum information processing 13, 59 (2014).
  * [22] C. Shukla, A. Banerjee, and A. Pathak, International Journal of Theoretical Physics 52, 3790 (2013).
  * [23] Y. Chen, International Journal of Theoretical Physics 53, 1454 (2014).
  * [24] Y.-J. Duan, X.-W. Zha, X.-M. Sun, and J.-F. Xia, International Journal of Theoretical Physics 53, 2697 (2014).
  * [25] M.-h. Sang, International Journal of Theoretical Physics 55, 380 (2016).
  * [26] R.-G. Zhou, C. Qian, and H. Ian, IEEE Access 7, 42445 (2019).
  * [27] M.-h. Sang, International Journal of Theoretical Physics 55, 1333 (2016)
  * [28] M. S. S. Zadeh, M. Houshmand, and H. Aghababa, International Journal of Theoretical Physics 56, 2101 (2017).
  * [29] J. Chen, D. Li, M. Liu, and Y. Yang, IEEE Access 8, 28925 (2020).
  * [30] R.-G. Zhou, X. Li, C. Qian, and H. Ian, International Journal of Theoretical Physics 59, 166 (2020).
  * [31] R.-G. Zhou, R. Xu, and H. Lan, IEEE Access 7, 44269 (2019).
  * [32] V. Verma, IEEE Communications Letters 25, 936 (2020).
  * [33] V. Verma, Physica Scripta 95, 115101 (2020).
  * [34] J. Malik, M. Lone, and R. Malla, To be published.