# Reputation-Based Trust Approaches in Named Data Networking
## 2 Background
### NDN Trust and Security  
By making named data the central piece of its architecture, NDN secures the data itself, independent of the underlying communication channels. All NDN Data packets are immutable and each one carries a signature generated using its producer's cryptographic key at the time of data creation, binding its name to its content. The NDN security framework is built on public-key cryptography. Applications and all other communication participants in an NDN network (entities), own one or more names. An entity proves its ownership of a name through an NDN certificate, which binds the name and a cryptographic public-private key pair possessed by the entity. Each entity can also issue certificates for the sub-namespaces it delegates to other entities. NDN security offers flexibility to application developers in deciding how to obtain certificates. Depending on the system design, a cloud-based application may obtain its certificate from a centralized certificate service, while a distributed application (e.g., P2P applications) may obtain the certificate from its users. Utilizing public key cryptography also requires NDN to establish trust anchors. NDN necessitates that all cryptographic verifications must terminate at a pre-established trust anchor, while assuming that the authority of each networked system establishes its own trust anchor(s) and that all the entities under that authority can discover these trust anchors through local system settings. This trust model resembles that of the Simple Distributed Security Infrastructure (SDSI/SPKI) in trust anchor establishment. By using the aforementioned mechanisms, NDN applications can validate received data packets independent from where they are fetched, while utilizing name semantics to reason about which cryptographic keys to use for which content, instead of relying on the \"yes-or-no\" model provided by third-party certificates [14]. In this context, it is clear that trust has been mainly addressed in NDN by using credential-based trust mechanisms. The main research focus has been on utilizing public key cryptography to validate communications and addressing related challenges, such as establishing trust anchors, providing effective solutions for trust management and developing usable key management solutions [15; 16]. To achieve this, the NDN security framework utilises 3 main components: Digital Keys, Certificates and Trust Policies. By combining the above, NDN ensures Data authenticity, integrity and, optionally, confidentiality at a fine granularity. Signature verification is performed by consumers for each Data packet, by retrieving the certificate of its producer. This certificate represents its issuer's endorsement of the binding between the name and the public key. It is a Data packet carrying a public key and can be fetched like any other Data packet. The issuer will put its signing key name with other auxiliary information into Data's signature info field. The authenticity and integrity of received Data packets (some of them may be certificates) are determined by a combination of the following two factors: Validation of trust policies and Signature verification. When fetched, a certificate recursively points to its signer's certificate and finally arrives at a specified trust anchor. The Data packet is considered valid only if all the certificates in the above chain have valid signatures and satisfy the trust policies [14]. In NDN, applications define trust policies that specify which entities are trusted for producing which piece of data, as well as which key should be used for which data namespace (and for what purpose). Therefore, different trust models are used by different applications and trust context is defined by the application. Users and applications can express their trust policies in a form that can be directly executed by applications, by using so called \"trust schemas\" [16]. In contrast to the built-in security features, access control is not inherent in NDN architecture.