Light-Weight Security Protocol and Data Model for Chip-to-Chip Zero-Trust

The semiconductor supply chain is vulnerable to multiple security attacks, such as hardware Trojan injection, intellectual property theft, and overproduction. The notion of zero-trust (ZT)– never trust, always verify– offers a promising opportunity for chip security by authenticating integrated circuits (ICs) when they are connected to critical computing systems. Before exchanging any data, the system establishes trust with the chip using industry security protocols. In this paper, we propose using the secure protocol and data model (SPDM) to establish chip-to-chip (C2C)- ZT communications. Furthermore, we present formal models for this solution and verify these models using state-of-the-art formal verification tools. The results show that the SPDM meets the requirements of the ZT architecture and can be used as a foundation for secure C2C interconnection.


I. INTRODUCTION
Over the last few years, ZT has become the preeminent concept, drawing the attention of the cyber security community [1]. Many corporate giants have already deployed ZT networks, notably Google's yondCorp [2], [3] and Microsoft's self-ZT security model [4], [5]. Due to the significant interest of the research community in ZT, the National Institute of Standards and Technology (NIST) has recently drafted the terms, definitions, and network infrastructure components for ZT. It is anticipated that it will be an integral part of future systems to protect enterprises and critical infrastructures against cyber attacks. The ZT principle has been widely adopted in a wide range of applications, including but not limited to self-driving networks [6], cloud computing [7], device-to-device communications [8], medical and healthcare sector [9], [10], and internet of things (IoT) [11].
The ZT principle promotes the notion of never trusting and always verifying. Recently, the hardware community has shown keen interest in ZT to protect chips and embedded sys-The associate editor coordinating the review of this manuscript and approving it for publication was Dominik Strzalka . tems. Especially since the emergence of the IoT, the security of the enormous, tiny devices is vital, since they may serve as soft targets for cyber attackers [12]. Drones / unmanned aerial vehicles (UAVs) are another example of devices that can be flown away from control centers and then kidnapped, hacked, and operated by an unauthorized entity [13].
In this paper, we propose a C2C-ZT architecture that provides physical-level security for hardware systems by permitting communication between two chips only if they pass an authentication and attestation procedure. This solution aims to mitigate the security concerns associated with outsourcing chip production that may lead to vulnerable embedded systems [14], [15]. Physically unclonable function (PUF) is a relevant technology that provides a digital fingerprint for chips. To validate this fingerprint, the user must have access to additional information, namely the challenge-response table. So, authenticating a chip with PUF boils down to trusting this challenge-response table, which contradicts the ZT principle. SPDM, on the other hand, is based on trusting the certification authority, rather than any data generated in the chip supply chain. Therefore, tt the core of the proposed C2C-ZT architecture is the SPDM.
As SPDM becomes increasingly popular in the cyber security community, it is crucial to validate the protocol. Indeed, the prerequisite for attesting any security protocol is its formal verification (FV). If a security protocol successfully passes all security threat tests during the FV, it can be implemented in systems. There are numerous tools and techniques available for verifying security protocols. In this study, we use the widely used push-button verification tool, automatic verification of internet security protocols and applications (AVISPA)+secure protocol animator (SPAN), which is extensively utilized by the research community for FV [16], [17], [18], [19], [20]. The performance of AVISPA tool is evaluated in [21]. Multiple security protocols are utilized to test the tool, and it is determined that the tool is well-suited for validating the protocols.

A. LITERATURE REVIEW
The ZT security architecture has been extensively studied in the literature, and various proposals have been put forward to address different security threats. In this section, we systematically classify the current ZT security architecture based on different threats and survey them accordingly.

AUTHENTICATION AND CONFIDENTIALITY OF IoT DEVICES
To guarantee the authentication and confidentiality of IoT devices, blockchain-enabled information sharing under the ZT principle is proposed in [11]. A lightweight continuous device-to-device authentication (LCDA) protocol is proposed in [8] to protect inter-device communication on resourceconstrained devices. The protocol specifies mutual and continuous authentication phases that include a dynamic secret key refreshing method including channel state information (CSI) modification.

INSIDER THREATS
A ZT-based framework for the IC design process to counter insider threats is proposed in [14]. Palmo et al. in [22] proposed a method to securely embed resource-limiting IoT devices within software-defined perimeter (SDP), a ZT model proposed by the cloud security alliance (CSA). The use of endogenous security concepts to improve the internal structure of the ZT security model is proposed in [23]. The suggested heterogeneous redundancy mechanism enhances the security of the ZT system against internal threats while maintaining universal applicability, ensuring reliable network services and effective security defense.

MALWARE AND TROJAN DETECTION
In [15], a novel ZT aligned method for detecting run-time Trojans in untrusted commercial off-the-shelf (COTS) processors is provided. A software-defined ZT architecture for sixth generation (6G) networks is proposed in [24], which has the potential to establish a flexible and scalable security framework. This architecture relies on adaptive collaboration among control domains to enable secure access control, and it provides effective protection against malicious access behaviors, including distributed denial of service (DDoS) attacks, malware propagation, and zero-day exploits.

HARDWARE SECURITY
In [25], a ProGun hardware/software co-design is proposed to mitigate the majority of security vulnerabilities caused by the lack of physical protection. It is built with multiple security layers to withstand cyber attacks. ProGun is a univeral serial bus (USB) dongle with a hardened and restricted operating system that can be used to protect any COTS computer from remote access. The dongle also includes logical interfaces and features for authentication and additional security. In [26], a satellite ground station front end processor (FEP) is examined to determine the degree of trust minimization in realworld scenarios. Using modern technologies and hardwareoriented methodologies, it is proven that trust minimization is attainable to a significant degree. It is anticipated that the code size will be reduced by a factor of 100, and that the level of protection against hardware backdoors will increase substantially. COUNTERFEITING Dutta et al. in [27] proposes and implements a ferroelectric field-effect transistor (FeFET)-based run-time reconfigurable camouflage logic technique. The solution concurrently conceals the design intellectual property (IP) from ZT foundry and an untrusted testing facility, thus eliminating the counterfeiting threats posed by reverse engineering.
Overall, these works address different security threats in the ZT security architecture and provide various solutions.

B. MOTIVATION AND CONTRIBUTIONS
The review of related work shows that substantial efforts have been made to protect devices, systems, and processes. To the best of our knowledge, however, there is no published literature on physical-layer authentication and secure communication for a C2C-ZT architecture. This physical-layer authentication of chips is highly needed to protect the system from exchanging information with counterfeit chips.
Under such a C2C-ZT architecture, no device is granted implicit access to the system, but the least possible privileges are granted after a rigorous authentication and attestation procedure. Fig. 1 shows a C2C use case in which an external chip is plugged into the host system through an interintegrated circuit (I2C) bus. The host system initiates an authentication process with the chip. The external chip is only permitted to exchange data after the successful completion of this process.
To enable the C2C-ZT architecture, we propose using the SPDM between the host system and every chip in the system. The design of robust security protocols is knowingly complex since it should take into consideration all possible hostile behaviors and activities of attackers who could interfere with the protocol to gain unauthorized access [28]. Formal verification is a recognized approach that helps in checking the correctness of security protocols. To our knowledge, the SPDM protocol has not yet been formally verified. Therefore, a comprehensive FV of this protocol is demonstrated in this paper. This is to provide assurance about the security of this protocol in the hardware community. The protocol is specified in high-level protocol specification language (HLPSL) and a complete FV is performed using the AVISPA tool. The protocol is evaluated in several attack scenarios to show its robustness against these attacks and readiness for the C2C-ZT. The main contribution of this paper is the formal verifica-tion of the SPDM protocol, as well as providing open-source models for the community to reuse based on their specific requirements, with an emphasis on lightweightness. While the SPDM protocol is recommended by Intel, 1 its integration into chips is difficult due to the large size of the compiled library and limited resources of the chips. Therefore, it is critical to develop a lightweight version of the protocol to enable practical use in resource-constrained devices. Formal models play an essential role in ensuring that the lightweight versions of the protocol are secure.

C. PAPER ORGANIZATION
The threat model, followed by an overview of the SPDM protocol, is provided in Section II. The FV of SPDM is provided in Section III. This section includes an overview of the AVISPA tool and the HLPSL description of the protocol. The SPDM security validation is discussed in Section IV. The challenges involved in the formal verification of the SPDM protocol and the C2C-ZT are described in Section V. Finally, the work is concluded in Section VI.

II. THREAT MODEL AND AN OVERVIEW of SPDM PROTOCOL
The Microsoft threat modeling tool is utilized to identify potential attacks. The potential attacks are addressed by the SPDM protocol. The list of potential attacks in the C2C-ZT, and their potential countermeasures are provided in Table 2.
Recently published by the distributed management task force (DMTF) organization [29], the SPDM protocol is envisioned as a potential solution that adheres to the ZT's guiding principles. It provides means to authenticate and measure hardware devices and enable secure communications between system components. The SPDM relies on asymmetric cryptography and public-key certificates for authentication. A post-quantum design is proposed in [30].
The broader device community has widely embraced this protocol. It has been adopted by several other standard groups, including peripheral component interconnect (PCI) [31] and trusted platform module (TPM) [32]. In addition, the PCI express (PCIe) integrity and data encryption key management (IDE_KM) protocol [33] for link encryption and other application protocols are built on top of the SPDM protocol. It standardizes the authentication of hardware components and enables the establishment of secure communication channels among them [34]. The protocol allows endpoints to discover and negotiate each other's security capabilities and to retrieve each other's measurements, which include the configurations of the hardware and the firmware.

A. SPDM MESSAGES
We chose a lightweight approach to implementing the complex SPDM protocol in this work because the chip cannot execute the entire protocol due to limited on-chip resources. As a result, we carefully selected a subset of SPDM functions that guarantee ZT.
An overview of the exchanged messages in SPDM protocol is depicted in Fig. 2, and is explained in detail in Table 1. A secure connection is established between two end-nodes, referred to as a requester and a responder, after the exchange of multiple messages. The requester initiates the protocol by sending a GET_VERSION message to the responder. Typically, this message is used to either initiate a new SPDM session or reset the current session. In response to this message, the responder sends the VERSION message, which contains the version of SPDM it supports. Both the requester and responder may support multiple SPDM versions, but the requester always selects the most recent common version. Once the requester sends the GET_VERSION message, all active sessions are terminated and the associated data is discarded. After receiving a successful VERSION message response, the requester sends GET_CAPABILITIES. This message is used to retrieve a number of the capabilities of the responder, i.e., whether the requester supports digests and certificates, challenge authentication, and mutual authentication, as well as several capabilities pertaining to key exchange during the secure session. In SPDM, end-nodes can switch roles at any time. Consequently, during the exchange of GET_CAPABILITIES messages, the requester shares its capabilities with the responder.
The requester sends the NEGOTIATE_ALGORITHMS message after obtaining the capabilities of the responder. The objective of this message is to negotiate cryptographic algorithms. The requester informs the responder of all encryption algorithms supported. The responder selects the largest common encryption algorithm from the received list and responds via ALGORITHMS in a message. All SPDM session parameters are determined following a successful ALGO-RITHMS message response. The requester then transmits the GET_DIGESTS message if the responder supports digests and certificates. The responder sends the cryptographic hash values of its certificate chains in response to this message. The requester caches the received hash values and compares them to the previously cached digests. Certificates are only requested if they cannot be located in the local storage buffer.
If the received digests do not match the digests stored in the requester's cache, the requester sends the GET_CERTIFICATE message. Therefore, the GET_DIGESTS message can improve performance by avoiding the transfer of certificates that are already present at the requester. The complete certificate chain includes the first certificate, which is either signed by the root certificate or is itself a root certificate. The preceding certificates sign the subsequent certificates. The public key of the responder is contained in the leaf certificate. When receiving certificate chains, the requester must at least save the public key of the leaf certificate. In addition, the requester must send multiple GET_CERTIFICATE requests to retrieve the chain. The requester then sends the CHALLENGE message to authenticate the responder. The requester sends a randomly generated nonce and the slot number of the certificate chain to be used for authentication. In response, the responder sends the message CHALLENGE_AUTH. The certificate chain hash is returned in this message. These hash values are used to validate that the certificate chain matches the requested one. Moreover, the responder generates signatures by encrypting the nonce received from the requester with its private key. The summary of the measurements' hash values is also included within the CHALLENGE_AUTH message. In contrast, the requester verifies the received signatures with the responder's public key; a successful verification proves the responder's authentication.
After authenticating the responder, the requester sends the GET_MEASUREMENTS message to determine the number of individual measurement blocks supported by the responder and to request either specific blocks or all available blocks. This message contains a nonce and the certificate chain index used for the authentication of measurements. In addition, the requester specifies whether all measurements, all available measurements, or specific measurements are required. Multiple request messages are used by the requester to obtain the measurements. In this situation, the requester does not request signatures for each individual message. Therefore, the responder simply sends back the measurements without the signature but creates a log for all received measurement request messages. On the other hand, the requester creates a log for all measurements received. The requestor will then request the signatures in the final measurements request message. Using its private key, the responder generates a signature on the measurement log if it includes an active flag for the measurement capability. The responder generates a MEASUREMENTS message that indicates any detected changes to the signed measurement log. It assists the requester in requesting the current measurements through another GET_MEASUREMENTS message. Furthermore, the number and length of measurement blocks are included in the response. Additionally, the message contains a nonce and the signatures of the measurements log.
This request message shall initiate a handshake between the requester and responder in order to authenticate the responder (or optionally both parties), negotiate cryptographic parameters (in addition to those negotiated in the previous NEGOTIATE_ALGORITHMS / ALGORITHMS exchange), and establish shared keying material. During this phase, the public keys generated by DHE [35] are exchanged between the two end-nodes. The responder generates a DHE secret using the private key of the responder's DHE key pair and the public key of the requester's DHE key pair as specified in the KEY_EXCHANGE request message. In a similar way, the requester generates a DHE secret using the private key of the DHE key pair of the requester and the public key of the DHE key pair of the responder, which are provided in the KEY_EXCHANGE_RSP response message. Both end-nodes generate identical DHE secrets, which are used to generate session secrets. The responder sends back a KEY_EXCHANGE_RSP message containing the DHE public key it has generated. The handshake is concluded when the requester and the responder send the FINISH and FIN-ISH_RSP messages, respectively. The FINISH request and FINISH_RSP response messages serve to provide key confirmation, bind the identity of each party to the exchanged keys, and protect the entire handshake from active manipulation. The respondent returns the signature and hash-based message authentication code (HMAC) of the transcript. The application data is then exchanged between the end-nodes utilizing the authenticated encryption with associated data (AEAD) algorithm, which simultaneously provides data encryption and authentication.

III. FORMAL VERIFICATION OF SPDM PROTOCOL
This section discusses the AVISPA tool and how it is used to validate the SPDM protocol. FV, as opposed to simulations, demonstrates design correctness by using static analysis methods or model checkers for an equivalence check with a well-known referent or to demonstrate that the design properties and assertions are fulfilled. It eliminates the need for extensive simulations to get excellent coverage, and the verification results are independent of the quality of the test cases. Moreover, mathematical proofs are highly relevant in the field of computer security, as they allow for the formal verification of security protocols to ensure their correctness and security. The AVISPA+SPAN toolkit embeds mathematical proofs as a core feature, allowing for the identification and mitigation of potential security vulnerabilities.
Given that SPDM is gaining popularity in the cyber security community, validation of the protocol is highly essential. Indeed, the FV of any security protocol is a prerequisite for the protocol's attestation. If the security protocol passes all tests for security threats during the FV, it can be implemented in the systems. Numerous tools and techniques exist for the FV of the security protocols. In this work, we are utilizing the AVISPA+SPAN tool, which is a push-button verification tool that is widely utilized by the research community for FV.
Given that SPDM offers a way to authenticate, compute the device's hardware identification, and allow secure communications between the devices. The FV of the SPDM protocol will increase hardware community trust in using the protocol for device authentication. The procedure typically involves the following steps: 1) Model the SPDM protocol using a HLPSL. 2) Implement the protocol in the tool and generate an initial model. 3) Specify the desired security properties to be verified, such as authentication or confidentiality. 4) Use the SPAN tool to simulate the protocol execution and generate an attack trace. 5) Analyze the attack trace to determine if the protocol is vulnerable to the specified security properties. 6) Modify the protocol or add security mechanisms if vulnerabilities are found. 7) Repeat the verification process until all desired security properties are satisfied.
A. AN OVERVIEW OF AVISPA TOOL Figure 3 illustrates the structure of the AVISPA tool. As the initial step, the user specifies the security protocol in the HLPSL. Along with the protocol itself, the protocol's desired objectives are included in the protocol specification. The formal language HLPSL is expressive, modular, and based on roles. It describes complicated security aspects such as control-flow patterns, data structures, multiple cryptographic operators, and their corresponding algebraic properties. The HLPSL protocol specification, on the other hand, does not necessitate an initial protocol simplification because it has more robust features than weaker alternatives. The AVISPA tool converts a user-defined or standard security protocol described in HLPSL to a corresponding intermediate format (IF). The IF specifications are inputted into the tool's backends. The tool next explores the infinite-state transition system provided by the IF specifications to determine the state that signals attacks on the protocol's intended features. The current version of the AVISPA tool has four back-ends: onthe-fly model-checker (OFMC) [36], constraint-logic-based attack searcher (CL-AtSe) [37], SAT-based model-checker (SATMC) [38], and tree-automata-based protocol analyzer (TA4SP) [39]. The back-ends examine the protocols under the assumption of perfect cryptography and a network controlled by a Dolev-Yao intruder [40] for message exchanges. Even though the active intruder has control of the network, it is unable to breach the encryption. Furthermore, if the intruder has access to the corresponding keys, it can intercept and decrypt the messages. Following that, it forwards messages in the name of any other party that is generated based on its own knowledge. The analytical results are subsequently output by the backends using a standard and clearly defined output format. Based on the input goals, the outcome will indicate if the protocol is safe or unsafe. If a potential attack is detected, a trace is generated.

B. SPDM SPECIFICATION IN HLPSL
The protocol is comprised of two agents: the host system and the external chip. In our proposed method, the host system is the requester, and the external chip is the responder. We assume in our protocol that only the host system authenticates the external chip. This section contains HLPSL descriptions of the involved roles and sessions under consideration. In these HLPSL specifications, all receiving and transmitting channels adhere to the Dolev-Yao (DY) intruder model. In Fig. 4, an overview of the FV of SPDM in a C2C-ZT is displayed. The environment is created with two sessions. In addition, the goals for secrecy and authentication, as well as the knowledge of the intruder, are defined. In our model, the illegal chip is impersonated as an intruder.

1) HLPSL CODE FOR HOST
The HLPSL code for the role of the host is given below: 1role host_chip (A, B: agent, 2 Hash: hash_func, 3 K: symmetric_key, 4 SND, RCV: channel(dy)) 5 6played_by A 7def= 60340 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply.    The role of the host chip initiates the protocol since it contains the statement RCV(start), where RCV is the receiving channel of the role. It then sends the Get_Ver message on the SND channel to retrieve the SPDM version from the external chip. It receives the version message in the Ver local variable via the RCV channel. After this, the host system sends the Get_Cap message and updates the state. Likewise, after receiving the capabilities message in its local variable Cap, it modifies the state and transmits the Negotiate_Algo message over the SND channel. The host system updates its current state and requests the digests of the certificates using the Get_Digests message after obtaining the common algorithm in its local variable Algo. The message received contains the hash values of the available certificates of the external chip. The host system compares the hash certificate values received within its local buffer, KeyRing. If the hash values are present in the buffer, it means that the host does not need to request the certificates because they are already available. The next message in this case is to challenge the external chip. The host chip sends a nonce to the external chip. Alternatively, if the host chip is unable to locate the received certificate hash values in its local buffer, the host modifies its current state and simultaneously sends a Get_Cert message. Concurrently, the host chip stores the received certificate hash values in the local buffer. The host receives the public key of the chip in response to the Get_Cert message in its local variable Kc1. In practice, the chip sends the entire certificate chain, with the leaf certificate containing the public key. This public key is subsequently employed to create a secure channel. In this case, the exchange of public keys should be accomplished through the exchange of certificates.
At this stage, the host chip challenges the external chip through a nonce. In response to the challenge message, the host chip receives the nonce shared by the external chip as well as its transmitted nonce that has been encrypted using the external chip's private key. If the host decrypts the encrypted nonce with the external chip's public key, it signals that it is connecting with the legal external chip. At this point, the host updates its state and sends a message to obtain the external chip's measurements. This message includes a nonce for freshness. The host then requests the chip's firmware and hardware measurements. The nonce guarantees that the most recent and accurate measurements are received. In response to the message, the host receives the measurement as well as the nonce of the chip and its own nonce encrypted using the external chip's private key. For authentication purposes, the host decrypts its encrypted nonce using the public key of the external chip.
Finally, a secure communication link between the two devices is established. The SPDM protocol accomplishes the key exchange using a handshaking method that incorporates the ephemeral DHE key exchange. Both chips generate a pair of public and private keys during this phase. After that, they exchange their respective public keys. Finally, both endpoints construct secret keys using their private keys and the public keys they have received. In [41], the FV of the DHE algorithm is provided. Therefore, we limit our FV to identification and authentication in this work.

2) HLPSL CODE FOR EXTERNAL CHIP
The following is the HLPSL specification for the role of external chip: In the case under consideration, the external chip imitates a responder. Consequently, it always responds to the host system's messages. The first message the external chip receives is the Get_Ver message. It responds by updating its state and sending the Ver message. The chip then receives the Get_Cap message and sends the Cap response message to the host chip to convey its capabilities. The chip then gets a Negotiate_Algo message and, in response, selects a hash algorithm from the host's shared list of hash algorithms. Typically, the chip selects the greatest common hash algorithm and returns it to the host via an Algo message. It receives the Get_Digests message from the host in the subsequent state. The chip returns the hash values for all available certificates. In the proposed FV, the external chip's public key is hashed and returned to the host chip as part of the HLPSL description. The host then issues a challenge to the chip in the form of a nonce. The chip creates its own nonce and uses its private key to encrypt the received nonce. The created and encrypted nonce is then transmitted to the host. After the challenge authentication, the host sends the chip a measurements request that contains a nonce. The chip encrypts the received nonce and then creates a new nonce in response to the request. Then it returns its measurement blocks, as well as the encrypted host nonce and its newly created nonce.

3) HLPSL CODE FOR SESSION ROLE
The HLPSL code for the session role is given below: The session role combines the defined protocol participants. In this case, for example, the roles of the host chip and the external chip are glued together. Both roles are instantiated inside the session role. The session role defines local variables for all transmitting and receiving channels.

4) HLPSL CODE FOR ENVIRONMENT ROLE
Following is the HLPSL specification for the environment role: This role manages the sessions. The environment role can accommodate numerous sessions. As previously mentioned, in this work, we define two sessions. Furthermore, the objectives for secrecy and authentication are specified. In this role, the protocol (including the initial knowledge of the intruder) and the scenario to be implemented, i.e., the instances of parallel sessions, are examined. The information given to the roles as parameters is constant, with the exception of the communication channels.

IV. SPDM SECURITY VALIDATION
SPDM provides a set of security mechanisms, including mutual authentication, data integrity, confidentiality, and replay attack protection, among others. The protocol is designed to be flexible and extensible to support various security requirements and use cases. The majority of these SPDM security features have been investigated in this research work. Replay attack prevention is one of the features provided by SPDM. It uses sequence numbers and timestamps to detect and prevent replay attacks. Besides replay attacks, the authentication of the guest chip is verified, and confidentiality and secrecy are also checked.
The AVISPA+SPAN tools are used to examine the following security features of the SPDM protocol.

A. PROTOCOL SIMULATION
The flow of messages in the SPDM protocol is validated using the protocol simulation feature of SPAN. The simulation of the protocol is depicted in Fig. 5. The SPAN tool enables the visualization of the sequential message exchange of the SPDM protocol. Furthermore, the protocol simulation is useful for eliminating and correcting semantic errors in the HLPSL protocol description. The complete message exchange in Fig. 5 indicates that the HLPSL specification contains no semantic error.

B. AUTHENTICATION
In this step, the endpoints confirm that they are communicating with the desired entity. Two endpoints are involved in the SPDM protocol, namely the host chip and the external chip. In the HLPSL specification, the authentication property of a protocol can be examined using the request and witness clauses, which permit endpoints to declare that they want to be the peer and will agree on a value (variable) for authentication.
Here, the request-witness pair of the host chip authenticates the external chip using the nonce Nb1. This authentication is VOLUME 11, 2023 60343 Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply.  declared as the authentication goal in the goal section of the HLPSL.

witness(A,B,auth_Nb,Nb1')
This indicates that the host chip expects the external chip to authenticate it on the Nb1 protocol. Here, auth_Nb represents the protocol identifier that is later used to set the goal.
request (A,B,auth_Nb,Nb1') which indicates that the external chip has requested that the host chip authenticate itself on Nb1. The authentication goal is finally defined in the Environment using the protocol identity auth_Nb as,

authentication_on auth_Nb
Correspondingly, we validated the authentication of several messages using HLPSL specifications.

C. CONFIDENTIALITY SECRECY
During the active SPDM protocol session, this feature indicates that confidential information is not disclosed to an unauthorized endpoint. SPDM maintains secrecy by exchanging messages through an encrypted channel. The confidentiality of secret values may be confirmed in AVISPA by declaring the secrecy clause in the role that generates secret information and by adding the secrecy goal of the HLPSL specification. For instance, we checked the secrecy of the external chip's public key by including the following statement in the session for the external chip: secret (Kc1,secrecy_kc1,A,B) where the first argument Kc1 is the public key of the external chip, which is required to be kept secret. The second argument secrecy_kc1 specifies the secrecy goal identifier, whilst the last argument indicates the agents with whom the secret value is exchanged. Here, we test the secrecy of Kc1 between the host and external chips by establishing the following goal:

secrecy_of secrecy_kc1
Likewise, we have examined the secrecy of the encrypted nonce values.

D. REPLAY ATTACK
A replay attack happens when an unauthorized agent or intruder captures network communication and delays or repeats it deliberately while impersonating a legal agent. Messages can be made resistant to replay attacks by including a nonce or timestamp. SPDM resists this attack by including a nonce within the handshake nonce. In order to test against a replay attack, the following two protocol sessions were evaluated: • session(a,b,k,h): This session executes the protocol assuming that all agents participating in the session are legitimate. The simulation for this session is shown in Fig. 5.
• session(a,i,k,h): This session simulates a situation in which an intruder imitates the external chip. The simulation for this session is shown in Fig. 8. Table 3 summarizes the attack scenarios. The AVISPA tool is only compatible with the Dolev-Yao model. In the Dolev-Yao intruder model, the intruder has complete control of the network, meaning that all communications delivered by agents are routed to the intruder. The intruder may intercept, analyze, and/or modify the message and transmit any message to an agent posing as a legal agent, but without the key, he or she cannot encrypt or decrypt the communication. Figure 6 depicts the intruder simulation of the session (a,b,k,h). The outcome of the OFMC backend with intruder simulation demonstrates that the protocol is unsafe with two legitimate agents, a and b in the presence of an intruder i. The output trace of the intruder simulation of session(a,b,k,h)   This scenario will never occur in this work since the SPDM protocol is executed between two devices. However, Fig. 6 depicts the exchange of SPDM messages across three devices. In addition, the intruder can listen to the exchanged messages, but it cannot decrypt the external chip's public key, as only a symmetric key between the host chip and the external chip can be used to decrypt the key. This symmetric key is unknown to the intruder. However, the intruder chip imitates crypt(inv(pk),nonce-1)),pair(Nb2,crypt(inv( Test_Kc1),Na5))) The host chip can be connected, over the same bus, to more than two chips using, for example, the I2C interface, as shown in Fig 7. Therefore, the host chip, which is the master, may simultaneously establish the SPDM protocol between several chips. The master should orchestrate the data exchange with an external peripheral by sending the address of the appropriate slave. One of the expected scenarios is that one of the connected slaves is a malicious peripheral. So, the illegal peripheral can intercept the data on the bus, but it cannot decrypt the external chip's public key, as only a symmetric key between the host chip and the external chip can be used to decrypt the key. Figure 8 demonstrates the actual situation involving an unauthorized external chip. In this scenario, the host chip initiates SPDM exchanges with the intruder (unauthorized external chip). As the exchange of the initial three messages occurs prior to authentication, there are no issues. As soon as the host chip requests the digests, the intruder is unable to supply the digests of the certificate, prompting the host chip to terminate subsequent message exchanges and implying that the external chip is illegitimate. The OFMC output trace for this simulation can be seen below.

E. VERIFICATION RESULTS
The validation results for SPDM using the OFMC backend are presented in Table 4. The table shows the cases that have been examined for potential security goal breaches.
The obtained results are reported in Table 4. These results are summarized by AVISPA using one of the following: • Safe means that the protocol does not breach any of the security goals outlined in the HLPSL specification.
• Unsafe implies that the protocol for which an attack trace was identified contains a security vulnerability.
• Inconclusive refers to the fact that, due to fundamental difficulties, AVISPA is unable to examine the protocol.

F. COMPUTATIONAL OVERHEAD
The tool is efficient and consumes minimal memory and central processing unit (CPU) resources. We used the system monitor tool to estimate the CPU and memory usage and found that, on average, the tool uses approximately 1% of CPU resources and 30% of memory resources. It should be noted that the tool runs on an Ubuntu platform within a virtual machine, which is allocated 4096 MB of base memory and three processors by the host system. Despite these modest resources, the verification process completes within seconds, demonstrating that the verification process is both feasible and fast enough. AVISPA+SPAN is a powerful tool for verifying security protocols, but it can be computationally intensive and may not scale well for very large systems or complex protocols. In particular, the verification time can increase exponentially with the number of protocol runs, making it impractical for large systems. However, there are techniques that can be used to improve the scalability of formal verification through AVISPA+SPAN, such as reducing the size of the protocol, optimizing the verification parameters, and parallelizing the verification process across multiple machines. We proposed a lightweight SPDM protocol that is not computationally intensive. As a result, the tool can traverse the required number of states quickly.
We estimated the computational complexity of the SPDM protocol in addition to that of the verification tool. The protocol is executed on two Raspberry Pi 4B devices, with one designated as the requester and the other as the responder module. The Raspberry Pi platform integrates a powerful Broadcom BCM2711 processor with a frequency of 1.8GHz and 4GB of internal memory. The total runtime of the protocol is approximately 29 seconds, including a 2-second initial communication stage, a 0.70-second GET_DIGEST stage, a 3-second GET_CERTIFICATE stage, a 10-second CHAL-LENGE phase, a 12-second KEY_EXCHANGE stage, and a 0.7-second secure communication session.

V. CHALLENGES INVOLVED
The SPDM protocol provides a comprehensive set of tools and features to ensure the authentication, secrecy, and confidentiality of data and devices. This work focuses on C2C-ZT, where the host chip initiates the protocol and authenticates the guest chip using digital certificates. Major challenges in formally verifying the proposed lightweight SPDM protocol for C2C-ZT include: 1) We model the private key of the CA as a symmetric public key between the chips and use inv() to convert it into the private key. To ensure the confidentiality and secrecy of the CA's private key, we have implemented specific features. While this method replicates the concept of a public-key infrastructure (PKI), finding an exact solution to this problem remains a challenge. 2) While we assume that the guest chip contains a digital certificate, in reality, most hardware chips do not have digital certificates, and it is unclear whether they contain them. Implementing PKI for hardware chips requires the host chips to store the public keys of major CAs, which can be an overhead. 3) To minimize the amount of data exchanged between devices, SPDM incorporates the sharing of digital certificate hashes before the actual exchange takes place. Although this feature significantly reduces data exchange overhead, implementing it on the AVISPA+SPAN tool can be challenging due to the presence of if-else conditions. If the host chip detects the presence of digital certificate hashes, it skips the step of requesting the certificate and proceeds directly to sending the challenge. However, if the hashes are not found, it will request the digital certificates before proceeding. 4) A major challenge is to thoroughly study the SPDM protocol and develop the necessary features that guarantee the minimum requirements for ZT authentication while remaining lightweight. 5) The SPDM protocol relies on asymmetric cryptography and public-key certificates for authentication. While these operations can be resource-intensive, they are necessary for ensuring ZT. This means that chip manufacturers may need to provide more on-chip resources to support authentication. In the proposed lightweight SPDM, we suggest using lightweight digital certificates instead of the standard X.509 certificates [42]. These lightweight certificates are already being used by the research community for IoT devices and are more efficient because they use elliptic curve cryptography (ECC) instead of Rivest-Shamir-Adleman (RSA) for encryption. In summary, more resources than what are currently available on-chip may be required for achieving C2C-ZT. However, using lightweight digital certificates and ECC can help to reduce the resource requirements and make the authentication process more efficient. Still, we think that it is accepted that ZT authentication comes with additional costs.

VI. CONCLUSION
This paper describes a C2C architecture based on the ZT principles. The SPDM protocol, which allows the authentication of the external chip to the host chip, is described in detail. In addition, the protocol enables the establishment of a secure communication channel for the exchange of data between the two chips. A detailed formal validation of SPDM protocol is performed using the widely-used AVISPA+SPAN tool. Simulations are conducted for both an authorized and unauthorized external chip. We infer from the FV that the protocol meets the necessary security features (secrecy, authentication, and freshness) and is secure against active and passive attacks. This document also includes the HLPSL specification for SPDM. Furthermore, we intend to use fuzzy testing to supplement formal verification and identify any potential vulnerabilities that may have been missed during formal verification.