# Distributed Reputation for Accurate Vehicle Misbehavior Reporting (DRAMBR)
## 5 DRAMBR Technical Implementation
### DRAMBR: Online Reporting  
The reporting process consists of secure transmission of MRs from \(Rep_{\text{Veh}}\) to RS. RS verifies the MRs, checks correctness, and updates RVs for both \(Rep_{\text{Veh}}\) and \(T_{\text{Veh}}\) while keeping privacy by _PCs_. Figure 11 illustrates the multi-stage process adopted in our system by incorporating different classification techniques to have an efficient and effective MR evaluation. Figure 11: MR Evaluation. **MR Decryption and Verification:** The RS performs the following operations after receiving the MR:  
1. First, the RS decrypts \(K_{s}^{*}\) using its private key \(K_{\text{priv}}^{S}\), retrieving the session key \(K_{s}\): \[K_{s}=\text{Dec}_{K_{\text{priv}}^{S}}(K_{s}^{*})\] (5) 2. To retrieve the MR, the RS decrypts the ciphertext \(C\) \[MR=\text{Dec}_{K_{s}}(C)\] (6) 3. Using the public key \(K_{\text{pub}}^{i}\) from PC, the RS verifies the signature \(\sigma_{A}\), ensuring the integrity of the report: \[\text{Verify}_{K_{\text{pub}}^{i}}(C,\sigma_{i})\] (7)
2. **MR Preprocessing and Acceptance Criteria:** In this step, the MRs are assessed by filtering out the invalid certificates and low-RV \(Rep_{\text{Venb}}\)s to ensure that only valid, reliable, and unique MRs are considered in further analysis. 1. The RS checks \(V_{i}\) pseudonym certificate \(pc\): \[\text{The MR from $V_{i}$ is accepted}\iff pc=1\] (8) \[pc= \begin{cases}1&\text{if $V_{i}$ has a valid certificate}\\ 0&\text{if $V_{i}$ has an invalid certificate}\end{cases} \] (9) 2. The RS checks \(V_{i}\) RV: \[\text{The MR from $V_{i}$ is accepted}\iff RV\geq\tau_{Rep}\] (10)
3. **MRs Grouping Using DBSCAN** This step identifies clusters of consistent MRs that likely reflect genuine events. We use the clustering algorithm DBSCAN, which identifies clusters in a dataset based on the density of data points. DBSCAN does not require a predefined number of clusters, which makes it particularly useful in scenarios with unknown cluster sizes or irregularly shaped clusters [34]. In our scenario, the RS follows this step to set the ground truth of what occurred in offline communications without relying on real-time infrastructure support. To illustrate, based on two parameters, DBSCAN groups data points into clusters: * Epsilon (\(\epsilon\)): The maximum distance between two points for them to be considered neighbors. * Minimum Points (minPts): The minimum number of points required to form a dense region (a cluster). Figure 12 illustrates the DBSCAN idea as follows: * Core Points (red points): These have at least _minPts_ neighbors within \(\epsilon\)-distance. * Border Points (yellow points): These are within \(\epsilon\)-distance of a core point but have fewer than _minPts_ neighbors. * Noise Points (blue points): These do not meet the density criteria and are treated as outliers. We adopted the DBSCAN process in our system to validate all the MRs generated in the offline communication. Hence, the RS can establish the ground truth regarding all the events, and the following steps are applied:  
1. Incident ID: First, the MRs will be grouped based on their _Incident ID_ (\(I_{\text{inc}}\)), which ensures that only MRs that are relevant to the same event are processed together: \[R_{I_{\text{inc}}}=\{MR_{i}\mid I_{i}=I_{\text{inc}}\}\] (11) Each group \(R_{I_{\text{inc}}}\) corresponds to a unique incident, isolating the observations related to that incident. 2. DBSCAN Inputs: Within each group \(R_{I_{\text{inc}}}\), DBSCAN is applied to identify consistent clusters of reports. * Feature set: \(x_{i}=[L_{i},T_{i}]\), where: * \(L_{i}\): Location of the \(Rep_{\text{Veh}}\). * \(T_{i}\): Timestamp of the MR.  
* \(\epsilon_{L}\): Spatial threshold for proximity. * \(\epsilon_{T}\): Temporal threshold for proximity. * \(min\)_PRs_: Minimum number of reports required to form a cluster.