Trust Model. 6.1 The Role of Privacy According to [Seigneur 2004], there is an inherent conflict between trust and privacy since the more we trust the system, the more information we risk revealing. For the system, it is required to have measurable trade- off between privacy and trust depending on the nature of services. Seigneur and Xxxxxx propose the use of pseudonymity mechanisms for formation of trust without exposing privacy sensitive information. In the context of mobile networks, related pseudonymity mechanisms are used to protect subscriber privacy. We describe the interplay between trust and privacy in different domains of the current mobile network architecture. In particular, we refer to the formal domain model as described in Section 5.1.1 and outline risks of each domain with respect to their trust. In access network domain, the user privacy information is protected using pseudonymity mechanism in the form of TMSI. However, recent attacks [Shaik 2016], [Xxxxx 2014], [Xxxxxxx 2014] and incidents [NSA] question whether mechanisms used in the access network domain are sufficient to balance the trade-off between trust and privacy. For example, due to the fact that base stations are treated as trusted elements in 4G networks, compromised base stations pose privacy challenges to mobile subscribers [Shaik 2016]. In addition, the mobile device (in particular the baseband operating system) is trusted during the communication with base stations. Xxxxx’x research work raises privacy issues originating from modified baseband software [Golde 2013] in current networks. Research results from [Xxxxxxxxxx 2013] and [Golde 2013] demonstrate the need to re-structure the trust properties of elements such as User Equipment and base stations. In the infrastructure domain, the home and serving networks are trusted domains. A trusted interconnection between these two network domains is necessary for international roaming purposes. However, trust in this interconnection interface raises severe privacy concerns regarding mobile subscribers [Xxxxx 2014]. In addition, trusted access via an API is provided to third parties for certain types of services in the core network domain, for example Home Location Register (HLR) lookup. This implied trust in HLR lookup services also raises privacy questions. For 5G networks, a new formal domain model based on [3GPP 2015] will be presented in the 5G-ENSURE D2.4 report. In this model, the infrastructure domain will be divided into several sub-do...
Trust Model. 7.5.1 Background to trust models Strictly speaking, trust models should not be part of an architecture document. They describe a basic requirement that would normally be explored in requirement gathering deliverables. In fact, this was the case, but the concept of trust models was unfamiliar to our reference communities. Equally, the trust that underpinned our reference communities was not ‗clean and logical‘, and was therefore hard to capture. Therefore, we decided to use our expert knowledge to interpret the likely requirements and thus define a suitable trust model. We began D4.1 by considering how the different community member‘s attitude to risk varied. Some were risk accepting, while others were risk averse.
Trust Model. Girault [27] shows that public key cryptosystems essentially can be classified into three different trust levels depending on the trust assumption of the trusted third party (TTP). • At trust level 1, the TTP knows the users’ private keys and can therefore impersonate any user at any time in an undetectable way. • At trust level 2, the TTP does not know the users’ private keys, but can still imperson- ate users by generating false public keys. • At trust level 3, the TTP does not know the users’ private keys, and generating false public keys will expose the TTP’s actions. Due to the escrow property, it’s easy to see that the trust level of CL-PKC is greater than that of ID-PKC. In PKI, whenever a CA tries forge a certificate, it can be identified by the fact that there are two working certificates for the same user. In CL-PKC, however, the TTP will still be able to replace public keys without the entities realizing that these are invalid. To address this and achieve trust level 3, CL-PKC also proposes an alternative key generation technique that binds a user identifier to a public key. Thus, the corresponding private key will be bound to the public key, and if the KGC replaces a public key it will easily be noticed. A minor drawback of this technique is that the public key must be generated before the private key is issued by the KGC.
