## 4 Proposed System Model  
In response to the identified challenges in disconnected vehicular areas, this section introduces our proposed system mode. This innovative approach, Pre-Signature scheme, is designed to effectively manage trust and reputation in areas with limited or intermittent connectivity, thereby enhancing both security and operational efficiency. We introduce a new entity, the Reputation Server (RS), which provides the Reputation Values (RVs). The RS will be linked to the SCMS. During the reputation retrieval process, the RV will be pre-signed by the RS; then, the RV will be sent to the requested vehicle to complete the signature and attach it to PCs, as explained in Section 5. IEEE 1609 and ETSI Intelligent Transport Systems (ITS) are two key standards that specify the vehicular communication. The former is for the US market and the latter is for the European market. Specifically from the security architecture perspective, IEEE 1609.2 [36] and ETSI TS 102 940 [37] define the V-PKI system architecture, procedures, and messages. These V-PKI architectures are the building blocks for the security solution of V2X communication. Figure 4 illustrates the extension of the ETSI ITS V-PKI architecture [37] by introducing the RS in this system. It should be noted that the incorporation of the RS into the process would necessitate updates to the related standards, namely IEEE 1609.2 [36] and the related ETSI specifications for system architecture (TS 102 940) [37] and protocol message formats and contents (TS 102 941) [38]. As shown in Figure 4, a new section should be created to capture the functional description of the RS. Figure 5 illustrates the procedure in which a vehicle retrieves its RV from the RS. **Steps 1 and 2:**: When vehicle \(V\) contacts an RSU, it requests a reputation synchronization by sending a \(RV\_Sync\_Request\) message with the RS. The vehicle first encrypts its \(V_{ID}\) using its private key \(V_{SK}\) to the RSU (\(V^{\prime}_{ID}\gets enc(V_{ID},V_{SK})\)). The RSU then forwards the vehicle's request to the RS. **Step 3:**: Upon receiving this request from the vehicle, the RS extracts the \(V_{ID}\) by decrypting the received value using the corresponding public key (\(V_{ID}\gets dec(V^{\prime}_{ID},V_{PK})\)). Figure 4: V-PKI Architecture with RS. **Steps 4 to 6:**: Using the \(V_{ID}\) as a key, the RS retrieves the RV value for this vehicle and computes the timestamp (\(TS\gets CT-round(7 log_{2}(RV_{ID}))\)). The RS derives the Pre-Signature of this \(TS\) value (\(\sigma\)) and returns it to the vehicle in the \(RV\_Sync\_Response\) message. **Step 7:**: When the vehicle receives \(RV\_Sync\_Response\) message, it uses the Pre-Signature value (\(\sigma\)) to complete the signature (\(\sigma\)). **Step 8:**: The vehicle transmits DENM message to vehicles within its communication range (\(DENM(M,sig(M),PC,\sigma,v)\)). The signature in this DENM message is generated using the Elliptic Curve Digital Signature Algorithm (ECDSA) according to clause 5.2 and 7.1.2 in ETSI TS 103 097 [39]. Figure 6 illustrates the handling of Decentralized Environmental Notification Message (DENM) messages at the receiving vehicle when it receives the same message from multiple vehicles. This figure shows only two transmitting vehicles. However, in reality, it can be generalized to have \(n\) vehicles originating or relaying the same DENM message. **Step 1:**: Multiple vehicles (\(V_{s1},V_{s2},...\)) transmit (either originate or relay) the same Decentralized Environmental Notification Message (DENM) message (\(M_{VS1},M_{VS1},...\)). The generation of DENM message payload and its message signature are according to ETSI EN 302 637-2 [40] and ETSI TS 103 097 [39], respectively. **Step 2:**: The receiving vehicle (\(V_{rcr}\)) receives all messages from these vehicles. It verifies the message signature according to clause 5.2 and 7.1.2 in ETSI TS 103 097 [39] and verifies the TS signature (\(\sigma\)) from each vehicle.