## 4 Security in 5G-Enabled D2D Communications Network
### Authentication and Authorization  
The \(UE_{i}\) authenticates to the HN with SUPI as part of the primary authentication. After a successful authentication, it generates its self-certifying key pairs and pseudonym ID and sends a service request with pseudonym ID to gNB for D2D services, where gNB maintains a registration table to associate the \(UEIDs\) with \(PK_{UE_{i}}\) and service information. For example, \(UE_{A}\) with data can advertise or publish its ID \(UA\) and \(DataName\) or \(UE_{B}\) interested in the data can send an interest its ID \(UE_{B}\) and \(DataName\) using \(UE_{A}\)'s logical address \(nAdd\). Then, mutual authentication is initiated and achieved using \(PK_{UE_{i}}\), \(hash(PK_{UE_{i}})\) and nonce. After authentication, \(UE_{A}\) sends data to \(UE_{B}\) via conventional routing mechanisms of D2D communications and CCN processes. For routing, the UE can reach another UE in proximity using the UE's \(nAdd\) and each UE in the routing path without exposing any other interface. If the UEs did not communicate before, then they have no cached security context. If they have communicated before, then the valid cached data, such as IDs and public keys, can still be used for authentication and authorization. The UEs can get authorized to access, cache and share the data without involving BBU pool or gNB as central authority, even though the security context such as data encryption keys might be set by third party. Therefore, authorization procedure might depend on the MNO set policies and service agreements between the UE and HN or SPs such as access controls, FID and security tokens. It leverages on security tokens, user access rights delegation, capabilities and attributes of the user and the data [39; 56]. The UE can also use GPSI or FID as its global profile to the UEs previously authorized via a federated-based authorization instead of the pseudonym ID [39]. The data owner creates capabilities in the form of labels for the UE and data object during service authorization by SP, and each object is given a specific set of access rights that can be granted to a UE [39]. The capabilities are represented as a dot-separated sequence of numbers, a string \(.i_{1}.i_{2}....i_{n}\) for some value \(n\) where \(i_{1},i_{2},...,i_{n}\) are integers [56]. The user's capabilities \(ucap\) are transferable through delegation process [39]. The data object consists of the data object name, metadata, payload and other non-encrypted configuration. The metadata consists of publication date, expiry date, creation time and access control profile. The access attribute and capability are specified in access control profile which includes data's capabilities \(dcap\), a symmetric nonce key \(K_{d1}\) and its key ID \((hkd1)\) for decrypting the data. The \(K_{d1}\) is the \(hash(nonce,DataName)\) while the key ID is the hash of the key \(hash(K_{d1})\) signed by the data owner's private key \(SK_{DO}\). For D2D communications, the UE with data and delegated attributes creates an \(ACap\) token consisting of authorization attributes and capabilities, \(ACap=\{D1,DA,hKd1,exp\}\):  
* \(D1\): DataName. * DA: Dataset delegation (true), label \((ucap2.3)\), data owner ID \((hDOID)\), data owner's public key \(PK_{DO}\), token \(ACap\) owner ID \((UB)\), scope (offline access, cache, share, any). * hKd1: Nonce key ID signed by data owner's private key \(SK_{DO}\)
* Exp: Token expiry date. The delegated access rights include dataset delegation; if set to true, then it permits the delegation of attributes and capabilities to other users in line with the data owner's set permissions. It also includes the scope of user/client's access rights in relations with the data object, data owner's ID \((hDOID)\), data owner's public key and user's ID of the UE in possession of data. The nonce key is a symmetric key for decrypting the data object. The \(ucap\)'s 2.3 should match the \(dcap\) 2.3, i.e., \(2=caching\) and \(3=sharing\).