## 5 Modeling of the Proposed Protocols
### DDSec Protocol  
The proposed DDSec protocol is modeled using \(UE_{A}\), \(UE_{B}\) and \(gNB\) entities based on the system model presented in Section 3 and a network-assisted D2D scenario. For simplification, it is assumed that \(UE_{A}\) has already been granted access to the service (data) and has been authorized to cache and share data. Therefore, \(UE_{A}\) can share data and delegate its access right and capabilities to \(UE_{B}\). \(UE_{A}\) and \(UE_{B}\) can use the proposed DDSec protocol to mutually authenticate and share data assisted by gNB. DDSec Protocol Message Exchange and Execution  
Before running the protocol, \(UE_{A}\) and \(UE_{B}\) would have achieved a successful network access authentication through primary authentication procedure using 5G-AKA/5G EAP-AKA' protocols [50] with the HN. The communication between the UEs and gNB is secured with respective keys \(K_{gNBa}\) and \(K_{gNBb}\), derived after a successful primary authentication. \(UE_{A}\) is also in possession of a symmetric key \(K_{d1}\) for decrypting the data, received as part of the service authorization procedure that grants the UE access to the service as presented in [39]. \(UE_{A}\) can advertise to other devices in proximity including gNB about the data in its possession; in addition, gNB would have information on IDs, previous data transmissions, data names and data owners. Additionally, when another UE sends an interest message about that data, gNB assists in the D2D device discovery and link setup between the two UEs. The protocol messages exchange is among \(UE_{A}\), \(UE_{B}\) and \(gNB\) entities for ScenariosA-C in Figure 3 Section 4.2. In the case of Scenarios B and C, two gNBs would be used. Figure 4 illustrates messages execution for Scenario A, with reference to notation in Table 1 and described as follows. Msg1 UEA \(\rightarrow\) gNB: ({AdvMsg},{KgNBb})  
\(UE_{A}\) sends an advertisement to \(gNB\) that it is in possession of data. The advertisement message \(AdvMsg\) includes the data name \(DataName\), its pseudonym ID (\(UA\)), logical address \(nAdd\) and public key \(PK_{UE_{A}}\) encrypted with preshared key \(K_{gNBa}\) with \(gNB\). Then, \(gNB\) updates its registration table and BBU Pool updates the intra cell content database with the received message. Msg2 UEB \(\rightarrow\) gNB: ({IntMsg},{KgNBb})  
\(UE_{B}\) sends an interest message \(IntMsg\) to the affiliated BBU pool via \(gNB\), which includes  
Figure 4: DDSec protocol message exchange flow. \begin{table}
\begin{tabular}{c c} \hline \hline
**Notation** & **Description** \\ \hline \(UE_{A}/UE_{B}/UE_{C}\) & UE \\ gNB & new generation NodeB \\ Rand\_a/Rand\_b/Rand\_rb/Rand\_rc & Nonce \\ PK(X) & public key \\ SK(X) & private Key \\ Exp & expiry date \\ URI & DataName \\ Ts & time stamp \\ Acap & security token \\ \(nAdd\) & logical/node address \\ D1 & hash (DataName) \\ \(K_{gNB}\) & session key (UE and gNB) \\ hKd1 & nonce key ID \\ UA/UB/UC & pseudonym ID hash(X)UEID)) \\ DOID & data owner’s ID \\ hDOID & hash(DOID) \\ h(x) & hash value of message x \\ \{x\}[k]\} & message encrypted with key K \\ \hline \hline \end{tabular}
\end{table} 
Table 1: DDSec protocol message exchange flow. its pseudonym ID (\(\mathit{UB}\)), data name \(DataName\) of the data it is interested in and its public key \(PK_{\mathit{U}E_{B}}\) encrypted with preshared \(K_{gNBb}\) with \(gNB\). Msg3.gNB\(\rightarrow\)UEA:((DiscMsg),(KgNBa))  
\(gNB\) with BBU pool check intra cell content database for an interest match within the local cell coverage or the D2D users in proximity via AMF which may have information about other UEs from other cells in intra or inter operator scenarios. If there is a match, \(gNB\) initiates the D2D communications process of discovery and link setup between \(\mathit{UE}_{A}\) and \(\mathit{UE}_{B}\) via D2D communications supported by SMF.