Introduction:
In summary, to address cross-
The Internet of Things (IoT), a network of numerous
interconnected physical devices via the Internet, has
garnered significant attention in recent years. Global end-
user spending on IoT solutions is expected to reach
approximately 1.6 trillion dollars by 2025. However, the
unsupervised state of IoT devices poses a challenge to
widespread adoption due to potential security threats.
Authentication plays a crucial role here. It is a communication
process where one entity verifies a property claimed by
another entity. In IoT systems, devices from different
companies or institutions often have shared resources,
forming relatively independent trust domains to prevent
unauthorized access. However, real-world scenarios may
involve cooperative relationships across multiple domains
when implementing certain functions. Hence, cross-domain
considerations become essential in IoT device authentication.
Traditional methods for cross-domain authentication can be
problematic. They can require a lot of work to manage
encryption keys or depend on trusted third parties, which
may not always be available. Some existing solutions that use
blockchain to help with this kind of authentication still have a
problem: they don't completely protect against potential
wrongdoing by people who manage these different security
domains.
A new and efficient method for secure device authentication
in cross-domain IoT systems is introduced as "blockchain and
TEE-assisted authentication." Their solution addresses the
issue of not fully trusting the managers of these security
domains. It combines different technologies like blockchain
which is used to establish trust between different security
domains.
There is also the introduction of Trusted Execution
Environment (TEE) technology that establishes a secure
execution environment, called an enclave, isolating data and
programs from the host operating system and ensuring
correct outputs. TEE technology enables an alternative
approach to cross-domain authentication in blockchain-based
IoT systems, offering a secure and reliable solution.
In existing blockchain-based cross-domain authentication
schemes, we believe that the blockchain are thoroughly
reliable which means they cannot be directly broken by
adversaries. However, existing IoT device authentication
systems are potentially vulnerable to quantum computing
advancements. Traditional cryptographic methods in
blockchain-based authentication systems may become
susceptible to quantum attacks. Malicious attackers can
exploit these vulnerabilities to steal private information
thereby endangering people's lives, property, and privacy.
In this proposed scheme, we advocate for combining TEE and
quantum blockchain systems as an emerging research
direction. Running smart contracts within a TEE enhances the
confidentiality of data on the quantum blockchain and
streamlines the consensus process for improved efficiency. In
our Quantum Blockchain and TEE-assisted Authentication
scheme, TEE acts as a trusted entity, managing IoT device
identity information and generating authentication results.
This approach eliminates concerns about manager-related
security risks, as the TEE executes specific processes
independently of the manager.
domain authentication challenges in IoT systems, we present
a Quantum Blockchain and TEE-assisted Cross Domain
Authentication scheme.
Related Work:
Proposed Approach:
Background:
In this section, we give a brief overview of the basic concepts
that form the basic building blocks of our proposed solution.
Lattice-Based Cryptography:
Lattice-based cryptography is a type of cryptographic
construction that relies on the mathematical structure of
lattices for its security. A lattice is a mathematical structure
that can be visualized as an infinite arrangement of regularly
spaced points in multiple dimensions.
Lattice-based cryptography leverages the hardness of lattice
problems to build cryptographic systems that are believed to
be secure against both classical and quantum attacks. As the
field of post-quantum cryptography evolves, lattice-based
schemes are considered promising candidates for securing
communication in a future where traditional cryptographic
systems may be vulnerable to quantum attacks.
NewHope Algorithm:
The NewHope algorithm is a key exchange protocol that falls
under the category of lattice-based cryptography. It is
specifically designed to be post-quantum secure, meaning it
is resistant to attacks from both classical and quantum
computers.
Parameter Selection - NewHope involves carefully selecting
parameters to define the lattice and its security. This includes
choosing the ring dimensionn , modulusq , and other
parameters to balance security and efficiency.
Key Generation -
1. Alice - Generates a random polynomiala (x)and computes
her public key b A (x ) by combining a (x) with a small noise
terme A (x ):
b (x)=a( x ). s A (x )+e A (x )mod q
Here, s A (x) is Alice’s secret polynomial.
2. Bob - Generates his own random polynomiala (x)and
computes his public key b B (x ) by combining a (x) with a
small noise terme B (x ):
b (x)=a(x ). s B (x)+e B (x )mod q
Here, s B (x) is Bob’s secret polynomial.
Key Exchange - The key exchange involves two rounds of
communication between Alice and Bob:
Round 1 (Alice to Bob) : Alice sends her public key b A (x ) to
Bob.
Round 2 (Bob to Alice): Bob generates a new random
polynomial a ' (x) and computes his own public key b ' B (x )
by combining a ' ( x) with a small noise term e ' B ( x):
 b ' B (x )=a ' (x). s ' B (x )+ e ' B (x )mod q
Here, s ' B (x) is a new secret polynomial generated by Bob.
Bob sends b ' B (x ) to Alice along with additional information.
Shared Secret Computation: After the key exchange rounds,
both Alice and Bob use their private keys and the received
public keys to compute the shared secret.
Shared secret=s A (x ). b ' B (x )mod q
Shared secret=s ' B (x ). b A (x )mod q
Both Alice and Bob now have the same shared secret. The
noise terms in the public keys and the random polynomials
contribute to the security of the shared secret. Even if an
eavesdropper intercepts the public keys, the noise makes it
computationally hard to determine the shared secret without
knowledge of the private keys and the specific random
polynomials used.
Quantum Resistance - NewHope is considered post-quantum
secure because its security is based on lattice problems,
which are believed to be resistant to attacks from quantum
computers.
Falcon Algorithm:
Falcon is a post-quantum digital signature algorithm based on
the hardness of the Short Integer Solution (SIS) problem. The
SIS problem involves finding short vectors in certain lattices.
Falcon's security relies on the difficulty of solving this
problem in a certain parameter space.
Mathematical Concepts:
Short Integer Solution (SIS) Problem - Given a matrix A and a
vectorb , find a short vector x such that A . x=b .
Ring Learning With Errors (Ring - LWE) - It's a variant of the
Learning With Errors (LWE) problem, where the noise is
sampled from a ring structure. Ring-LWE is used to ensure
the security of Falcon against certain attacks.
Hash Function H (∙) - A cryptographic hash function used to
compress and transform data, providing a fixed-size output.
Falcon Key Generation
1. Parameter Setup:
Security Parameters
n : Dimension of tℎe lattice
q : Modulus
w :Widtℎ parameter for tℎe SIS problem .
The security of Falcon is based on the hardness of the
SIS problem with parameters n , q , w .
2. Key Generation:
Select Prime Modulus - Choose a prime modulus q that
is large enough to provide the desired security level.
Generate matrix A of size n × n with coefficients
sampled from a certain distribution. This matrix is used to
define the SIS problem.
Secret key S - Sample a short vector S from the SIS
distribution. This vector is the secret key.
Public Key A . S + E - Compute the public key as
A . S + E , where E is a noise vector.
3. Falcon Signature Generation:
a) Complete Hash - Hash the message M to a fixed-
size hash valueℎ.
b) Ring - LWE Sampling - Sample a random noise
vectorr from a distribution related to the Ring
Learning With Errors (Ring-LWE) problem.
c) Compute Commitment - Compute a commitment
R=A . R S + R E, where R S and R E are a ring-LWE
samples.
d) Hash Commitment - Hash the commitment R to
get c=H (R).
e) Signing - Compute the response z=c . S +r and
set z '=R S . S+ R E + z
f) Output Signature - The signature on message M is
(R , z ').
4. Falcon Signature Verification:
a) Compute Hash - Hash the message M to obtainℎ.
b) Parse Signature - Parse the signature (R , z ') into
the components R S and R E + z .
c) Compute Commitment - Compute
R '=A . R S + R E
d) Hash Commitment - Hash R ' to obtain
c '=H (R' ).
e) Verify - If c '=c , then the signature is valid;
otherwise it is invalid.
This is a simplified overview, and the actual Falcon algorithm
involves more complex mathematical operations. The
security of Falcon relies on the difficulty of solving lattice-
based problems, making it a promising candidate for post-
quantum cryptography.
Architecture:
Fig.1 - System Model of the Proposed System
The proposed system consists of three entities: Quantum
Blockchain, administrator node (AN), and ordinary node (ON).
AN and ON collectively constitute a trust domain.
1. AN (Administrator Node): ANs serve as the trusted centers
within a trust domain, possessing robust computing and
storage capabilities. They collaboratively maintain a Quantum
Blockchain and oversee the management of ONs within the
domain. ANs deploy Trusted Execution Environments (TEE)
and execute corresponding programs in enclaves.
2. ON (Ordinary Node): ONs function as edge nodes within
the domain, representing entities such as IoT devices in an
IoT system. Their computing and storage capabilities are
relatively modest compared to ANs. ONs within the domain
must request a private key for signature verification, and
interactions between ONs necessitate authentication by the
AN.
3. Quantum Blockchain: The Quantum Blockchain in this
system stores information from different domains, crucial for
cross-domain authentication. Prior to interactions, ONs must
register and acquire a valid identity for authentication
purposes. The registered identity information is stored on the
Quantum Blockchain for subsequent authentication.
Additionally, information regarding the revocation of an ON
will be recorded on the Quantum Blockchain upon its exit
from the system.
Workflow:
1. Initialization
A and B are administrative nodes in Domain A and Domain
B, respectively.
TEE A and TEE B are the Trusted Execution Environments
for A and B.
QBlockcℎain is the quantum-resistant blockchain.
2. Key Exchange with newHope
The newHope key exchange algorithm is a post-quantum
cryptographic algorithm that enables two parties to establish
a shared secret key over an insecure communication channel.
The process involves public key exchange, reconciliation, and
key derivation.
Let pk A , sk Abe the public and secret keys for the
administrative node in Domain A, and pk B , sk B for the
administrative node in Domain B.
Key Exchange by Sender (Node in Domain A)
Public Key Exchange - Domain A's administrative node
initiates the key exchange by generating a pair of public and
private keys:
k pub A , k priv A =newHope ¿ ().
The public key k pub A is sent to Domain B.
Key Exchange by Receiver (Node in Domain B)
Domain B's administrative node receives k pub A and
generates its own key pair:
k pubB , k priv B=newHope ¿ () .
Domain B uses k pub A and its private key k priv B to perform
the key exchange :
c B =newHope ¿ (k pub A , k priv B ).
c B , the result of the key exchange, is sent back to Domain A.
Reconciliation by Sender (Node in Domain A):
Domain A's administrative node receivesc B and uses its
private key k priv A to reconcile the key:
k pubB =newHope reconcile (c B , k priv A ).
Shared Secret Key Derivation
Both Domain A and Domain B derive a shared secret key
k sℎared from the reconciled public key:
k sℎared =newHope ¿ (k pub B ).
The derived shared secret key k sℎared is used to establish a
secure communication channel between the administrative
nodes in Domain A and Domain B.
Overview of the newHope Key Exchange:
Let k pub A , k pub B be the public keys generated by Domain A
and Domain B, respectively.
c B is the result of the key exchange algorithm.
k priv A , k priv Bbe the private keys of Domain A and Domain B,
respectively.
Key Exchange by Sender (Node in Domain A):
k pub A , k priv A =newHope ¿ ().
c B =newHope ¿ (k pub A , k priv B ).
Key Exchange by Receiver (Node in Domain B):
k pubB , k priv B=newHope ¿ ().
c B =newHope ¿ (k pub A , k priv B ).
Reconciliation by Sender (Node in Domain A):
k pubB =newHope reconcile (c B , k priv A ).
Shared Secret Key Derivation:
k sℎared =newHope ¿ (k pub B ).
The newHope key exchange algorithm facilitates the secure
exchange of keys between Domain A and Domain B's
administrative nodes. The public and private keys are
generated, and a shared secret key is derived, providing a
secure foundation for subsequent communication. The
mathematical operations involved in key exchange ensure
that even in the presence of quantum adversaries, the shared
secret key remains secure.
3. Cross Domain Authentication with FALCON
FALCON is a post-quantum cryptographic algorithm used for
digital signatures. In this step, FALCON is employed to
generate a secure authentication token by signing a message
with the private key in the sending Trusted Execution
Environment (TEE) and to verify the received token's
authenticity in the receiving TEE.
Parameters:
 m A represents the message containing user credentials,
time stamp, and other relevant data.
 k priv A and k pub A are the private and public keys for the
Trusted Execution Environment (TEE) in Domain A,
respectively.
 σ A is the digital signature generated using FALCON.
 TEE B is the Trusted Execution Environment in Domain
B.
 σ Verify represents the result of the FALCON verification
process.
Authentication Token Generation (Sender - Domain A):
Message Generation
The sender (Domain A) creates a message m A containing
user credentials, timestamp, and other relevant
authentication data.
Digital Signature Generation
Using FALCON, the sender signs the message with its private
key: σ A=FALCON sign (m A , k priv A )
Secure Transmission
The digital signature σ A and the original message m A are
securely transmitted to Domain B.
Authentication Token Verification (Receiver - Domain B): Blockchain Transaction
Secure Reception The hash of the transaction data ( ℎasℎtx )and the digital
Domain B securely receives the digital signature σ A and signature (signaturetransaction ) are added to the blockchain
original message m A . as a new block.

Verification Process Verification on Blockchain

Using FALCON, Domain B verifies the received signature with
the public key of Domain A:
σ Verify =FALCON verify (m A , σ A , k pub A ) .
If σ Verify is true, the verification is successful, and Domain B
knows that the message was signed by the private key
corresponding to k pub A .
If σ Verify is false, the verification fails, indicating potential
tampering or a non-authentic source.
Overview of the FALCON Algorithm:
Digital Signature Generation (Sender - Domain A)
σ A=FALCON sign (mA , k priv A )
Authentication Token Verification (Receiver - Domain B):
σ Verify =FALCON verify (m A , σ A , k pub A ) .
FALCON is utilized to generate a digital signature during
authentication token creation and to verify the received
signature during authentication token verification. This
process ensures the authenticity of the message and guards
against unauthorized modifications or forgeries. The
mathematical operations involved in FALCON's signing and
verification mechanisms provide a robust foundation for
secure cross-domain authentication in the IoT environment.
4. Quantum Blockchain Transaction
After successful authentication the acknowledgment and
relevant authentication details are recorded as a quantum-
resistant transaction on the blockchain (QBlockcℎain ).
Parameters:
 QBlockcℎain represents the quantum-resistant
blockchain.
 acknowledgement is the acknowledgment generated
during the authentication process.
 autℎentication details include user IDs, timestamps,
and other relevant authentication data.
 signaturetransaction is the digital signature for the
transaction.
Transaction Data
The transaction data includes details such as user IDs,
timestamps, acknowledgment, and cryptographic proofs.
Let tx data represent the formatted transaction data.
Quantum-Resistant Transaction Hash
The transaction data is hashed using a quantum-resistant
hashing algorithm:
ℎasℎtx =quantum¿ (tx data )
Digital Signature for Transaction
The administrative node in Domain A signs the hash of the
transaction data using FALCON:
signaturetransaction =FALCON sign ( ℎasℎtx , k ¿ ¿ priv A)¿
Nodes in the blockchain network can independently verify
the transaction:
FALCON verify ( ℎasℎtx , signaturetransaction , k pub A )
ensures the integrity and authenticity of the recorded
transaction.
Overview:
Transaction Data:
tx data={user IDs ,timestamps , acknowledgement ,
cryptograpℎic proofs }.
Quantum Resistant Transaction Hash:
ℎasℎtx =quantum¿ (tx data )
Digital Signature for Transaction:
signaturetransaction =FALCON sign ( ℎasℎtx , k ¿ ¿ priv A)¿
Blockchain Transaction:
The blockchain records ( ℎasℎtx )and (signaturetransaction )
as a new block.
Verification on Blockchain:
FALCON verify ( ℎasℎtx , signaturetransaction , k pub A )
ensures the integrity and authenticity of the recorded
transaction.
The acknowledgment and authentication details are securely
recorded on the quantum-resistant blockchain
QBlockcℎain . The use of a quantum-resistant hashing
algorithm and FALCON for digital signatures ensures the
integrity and authenticity of the transaction data. This
process creates a tamper-evident and secure transaction
history on the blockchain, providing a reliable audit trail for
monitoring and forensic analysis in the IoT environment.
5. Secure Communication
The shared secret key k sℎared derived from the newHope key
exchange algorithm is utilized for secure communication
between ordinary nodes in Domain A and Domain B.
Quantum-resistant encryption algorithms are employed to
protect the confidentiality and integrity of the data during
transit.
Let k sℎared be the shared secret key derived from the
newHope key exchange algorithm.
Data Encryption (Sender - Ordinary Node in Domain A):
The sender uses the shared secret key k sℎared to encrypt the
data:
encrypted data =quantum¿ (data , k sℎared )
Secure Transmission:
The encrypted data is securely transmitted to the receiver
(Ordinary Node in Domain B).
Data Decryption (Receiver - Ordinary Node in Domain B):
The receiver uses the shared secret key k sℎared to decrypt the
received encrypted data:
decrypted data =quantum¿ (encrypted data , k sℎared )
The quantum-resistant encryption algorithms used in this
step are designed to withstand attacks from both classical
and quantum adversaries.
The use of the shared secret key derived from newHope
ensures that only the communicating nodes possess the
necessary information to encrypt and decrypt the data.
Ordinary nodes in Domain A and Domain B communicate
securely using the shared secret key derived from the
newHope key exchange algorithm. Quantum-resistant
encryption algorithms are employed to protect the
confidentiality and integrity of the transmitted data. This
ensures that even if an adversary intercepts the
communication, the information remains confidential and
secure, contributing to the overall security of the cross-
domain authentication scenario in the IoT environment.
6. Logging and Auditing
Cryptographic mechanisms are applied to secure the logging
process on the quantum-resistant blockchain. The goal is to
ensure that the recorded logs are tamper-evident and
authentic, providing a secure audit trail for monitoring and
forensic analysis.
Cryptographic Operations for Logging
Signature Generation (Sender - Domain A) - Domain A
generates a digital signature for the log data using the
FALCON algorithm:
signaturelog =FALCON sign (log data , k priv A )
Secure Logging on Quantum Blockchain
The signed log data (log data ) and the corresponding digital
signature(signaturelog ) are appended to the quantum-
resistant blockchain as part of a new transaction block.
Verification of Log Signature (Receiver - Domain B)
When Domain B retrieves the log data from the blockchain, it
can verify the authenticity of the log by using FALCON for
signature verification:
FALCON verify (log data , signature log , k pub A )
Overview:
 Signature Generation (Sender - Domain A):
signaturelog =FALCON sign (log data , k priv A )
 Verification of Log Signature (Receiver - Domain B):
FALCON verify (log data , signature log , k pub A )
This ensures the integrity and authenticity of the logs
recorded on the quantum-resistant blockchain. The use of
the FALCON algorithm for signature generation and
verification adds a layer of security, making it
computationally in-feasible for adversaries to tamper with
the logged data without detection. This tamper-evident
logging mechanism enhances transparency, accountability,
and the ability to conduct secure audits in the IoT
environment.
7. Continuous Monitoring
Continuous monitoring is a crucial component of the overall
security framework, providing proactive detection and
response capabilities to mitigate potential security threats. In
the context of the scenario, the monitoring tools are
integrated with the TEEs and the quantum-resistant
blockchain to ensure the security of the system.
Components of Continuous Monitoring:
a. TEE Monitoring:
a) Objective - Detect anomalies or unauthorized
access within the TEEs.
b) Implementation: Continuous monitoring tools
track the behavior of TEE A and TEE B , looking
for unusual patterns, unexpected activities, or
potential security breaches.
c) Alerts: If anomalies are detected, alerts are
triggered for immediate investigation and
response.
b. Blockchain Monitoring:
a) Objective: Monitor the quantum-resistant
blockchain for any suspicious transactions or
unexpected changes.
b) Implementation: Continuous monitoring tools
analyze the transactions recorded on the
blockchain, ensuring that they adhere to expected
patterns and security protocols.
c) Alerts: Any deviations from normal behavior or
potential security incidents trigger alerts for
further investigation.
c. Communication Anamoly Detection:
a) Objective: Identify irregularities in the
communication between nodes.
b) Implementation: Monitoring tools analyze the
communication patterns between ordinary nodes
in Domain A and Domain B, looking for unusual
volumes, unexpected destinations, or signs of
potential attacks.
c) Alerts: Anomalies in communication patterns
trigger alerts for immediate investigation.
d. Resource Usage Monitoring:
a) Objective: Monitor resource usage within TEEs and
the overall system.
b) Implementation: Track resource consumption
metrics, such as CPU usage, memory usage, and
network activity, to identify any abnormal patterns
that might indicate a security threat.
c) Alerts: Unusual resource consumption triggers
alerts for further examination.
Real Time Responses:
Automated Responses - In some cases, continuous
monitoring tools may be configured to execute automated
responses to known threats or anomalies. For example,
blocking suspicious network traffic or isolating a
compromised TEE might be automated responses.
Human Intervention - Critical security incidents or those
requiring in-depth analysis may trigger alerts for human
intervention. Security personnel can investigate alerts,
analyze logs, and take appropriate actions to address the
detected threats.

Benefits of Continuous Monitoring:

Proactive Security - Continuous monitoring enables the
identification of potential security threats before they
escalate into serious incidents.

Rapid Incident Response - Real-time alerts facilitate swift

response to security incidents, minimizing the impact and
preventing further compromise.

Forensic Analysis - Detailed logs generated by continuous

monitoring tools support forensic analysis, helping to
understand the nature and origin of security incidents.

Adaptability to Emerging Threats - Continuous monitoring

systems can be updated and adapted to new threat vectors
and attack patterns, enhancing the overall resilience of the
security infrastructure.

Continuous monitoring is an integral part of the security

architecture, ensuring the ongoing integrity and resilience of
the cross-domain authentication scenario in the IoT
environment. By continuously monitoring TEEs, the quantum-
resistant blockchain, communication channels, and resource
usage, the system can quickly detect and respond to
potential security threats, maintaining a high level of security
and trustworthiness.

Fig - 2 - Workflow of the proposed system.

Design Goals
Design goals for the proposed system should aim to address
various aspects of security, efficiency, and functionality. Here
are key design goals for the system:
1. Quantum Resistance:
a) Goal: Ensure that cryptographic algorithms used in
key exchange, authentication, and communication
are resistant to attacks from quantum computers.
b) Implementation: Utilize post-quantum
cryptographic algorithms such as newHope for key
exchange and FALCON for digital signatures, as
they are believed to be secure against quantum
attacks.

2. Secure Key Exchange:

 a) Goal: Establish a secure and authenticated key b) Implementation: Modularize components to allow
exchange mechanism between administrative for easy replacement of cryptographic algorithms
nodes in different domains. and update protocols in response to evolving
b) Implementation: Leverage the newHope key security requirements.
exchange algorithm within Trusted Execution
Environments (TEEs) to ensure a secure By aligning the proposed system with these design goals, the
establishment of shared secret keys. system can provide a resilient and secure foundation for
cross-domain authentication in an IoT environment while
3. Authentication and Authorization: mitigating potential quantum threats.
a) Goal: Implement a robust authentication and
authorization mechanism to verify the identity of
nodes in different domains.
b) Implementation: Use FALCON for secure
authentication token generation and verification,
ensuring the integrity and authenticity of
communication.

4. Quantum-Resistant Blockchain:
a) Goal: Provide a secure and tamper-evident
transaction recording mechanism using a
quantum-resistant blockchain.
b) Implementation: Use quantum-resistant
cryptographic algorithms to secure transactions
and logs on the blockchain, ensuring integrity and
transparency.

5. Secure Communication:
a) Goal: Establish a secure communication channel
between ordinary nodes in different domains.
b) Implementation: Utilize the shared secret key
derived from the newHope key exchange algorithm
for quantum-resistant encryption of
communication data.

6. Logging and Auditing:

a) Goal: Maintain a tamper-evident and transparent
log of authentication, communication, and
transaction activities.
b) Implementation: Use FALCON for signing logs
before recording them on the quantum-resistant
blockchain, ensuring authenticity and integrity.

7. Continuous Monitoring and Anomaly Detection:

a) Goal: Implement mechanisms for continuous
monitoring of TEEs and detection of anomalous
activities.
b) Implementation: Integrate anomaly detection tools
with TEEs to identify and respond to security
incidents promptly.

8. Scalability and Efficiency:

a) Goal: Ensure that the framework is scalable to
accommodate a growing number of nodes and
efficient in terms of computation and
communication overhead.
b) Implementation: Optimize cryptographic
algorithms and protocols for efficiency, and design
the system architecture to scale seamlessly.

9. Flexibility and Adaptability:

a) Goal: Design the framework to be flexible and
adaptable to changes in cryptographic standards
and emerging threats.