# Privacy-Aware Access Protocols for MEC Applications in 5G +
## 4 Results and Discussion
### Unlinkability  
The requirements about unlinkability are partially met with our solution. In Step 6, MEC creates a one-to-one mapping from the DTLS session between [PERSON] and MEC to the TLS session between [PERSON] and APPIFY. This means that anybody who can recognize that two messages belong to the same DTLS session (or the same TLS session) also learns that these messages are between the same user and the same MEC application. There are many ways for even an outsider to find out that two protected messages belong to the same (D)TLS session (see, for example, [60]). Therefore, we limit the discussion of unlinkability requirements to the case where the two messages under consideration belong to two different DTLS or TLS sessions.  
Our solution generates new DTLS and TLS channels from scratch for every new connection between the user and APPIFY. This makes it more difficult for parties other than Alice and APPIFY to link different TLS channels to each other.  
As explained earlier, the MNO cannot identify either APPIFY or Alice13. When a new DTLS connection is established, MNO cannot know whether this connection is for the same MEC application as an earlier connection, except by analyzing traffic patterns. Thus, requirement R4-MNO-U is partially met.  
MNO could assume that if the same UE connects to the same MEC application, then the identifier of the user toward that application is also the same. However, MNO cannot know this for sure. For example, the UE could act as a hotspot and be shared by several users. We conclude that the requirement R5-MNO-U is partially met.  
Similar reasoning as for MNO and R4-MNO-U above can be carried out for the case of outsiders. Therefore, only by traffic analysis can other users and parties not visible in the system model learn that two UEs use the same MEC application. Similarly, only by traffic analysis can these types of outsiders learn that two messages from two different DTLS sessions relate to the same MEC application. The third type of outsiders, i.e., the other MEC applications, can additionally gather information about the internal state of the MEC host. However, it is still limited as to how well this kind of indirect information could help identify the used MEC application. Therefore, the requirement R19-OUT-U is partially met.  
When establishing the outer DTLS channel, [PERSON] authenticates MEC, but MEC does not authenticate [PERSON]. This prevents MEC from linking [PERSON] to APPIFY. In the established session, MEC knows which MEC application is used, but the identities of [PERSON] are not revealed to MEC. However, the IP addresses in the messages might reveal that the same device is used in two different DTLS connections. In that case, these two connections are likely from the same user. Still, MEC cannot be sure about that, as explained above for the case of MNO. We can conclude that the requirements R9-MEC-U and R10-MEC-U are partially fulfilled.  
We now discuss the unlinkability requirements R13-APP-U and R14-APP-U for APPIFY in the case where two messages are from two different TLS sessions. In that case, APPIFY can conclude that the user is probably using the same device if the user sends the same certificate to APPIFY in both TLS sessions. On the other hand, having different certificates does not imply that different devices are used. We can conclude that requirement R13-APP-U is partially met.  
Typically there is a one-to-one mapping between the user device and IMSI. However, there may be several SIM cards in a single device, or the same SIM card could be moved from one device to another. The APPIFY cannot distinguish between any of these cases. We can conclude that R14-APP-U is partially met.  
In summary, our solution meets the privacy requirements well, except for the unlinkability part. An adversary may recognize that messages belong to the same DTLS or TLS session and conduct traffic analysis. However, similar arguments against unlinkability can be made in the setting where applications are used without the help of MEC technology.