# Privacy-Aware Access Protocols for MEC Applications in 5G +
## 4 Results and Discussion
### Analysis
#### 4.2.1 Independent Case  
Let us first analyze the case where all three parties, MNO, MEC, and APPIFY, are independent of each other.  
Data and Identity Confidentiality  
As explained in Section 4.1, we use secure channels between UE and MNO, MNO and MEC, and MEC and APPIFY. Hop-by-hop protection of the path between UE and APPIFY protects the traffic against outsiders. In addition, the messages of other MEC applications might be in the same UE-MNO or MNO-MEC secure channels as APPIFY. However, this does not mean that the other MEC application can extract the communication between [PERSON] and APPIFY. Thus, the requirements R16-OUT-D, R17-OUT-I, R18-OUT-I, and R20-OUT-U are fulfilled. This hop-by-hop protection is not enough to protect against the honest-but-curious parties who are nodes in the traffic path.  
The request for APPIFY in Step 5 of the procedure, see Figure 4, and subsequent messages between [PERSON] and APPIFY are delivered inside the DTLS channel. This prevents MNO from learning the identities, APPIFY and Alice13, as well as the content of messages exchanged between [PERSON] and APPIFY. The MNO can only observe that [PERSON] is using some MEC application. We can conclude that the requirements R2-MNO-D and R3-MNO-I are fulfilled for the independent case.  
[PERSON] does not send any messages to APPIFY, including her personal information, until the TLS handshake between UE and APPIFY is completed. After the handshake, all the communication between [PERSON] and APPIFY is concealed by the TLS channel. [PERSON] introduces herself as [PERSON] by sending \(cert(Alice13)\) to APPIFY inside a secure channel to perform the post-handshake client authentication. This way, APPIFY authenticates [PERSON], and MEC does not learn the identity of [PERSON]. The real identity of [PERSON] is not used in any messages of the procedure, and it is only known by MNO. The IMSI is only used between [PERSON] and MNO. Therefore, MEC cannot learn any of these identifiers. We can conclude that the requirements R6-MEC-D, R7-MEC-I, R8-MEC-I are fulfilled.  
APPIFY is at the end of the communication path. Since all the information between Alice and APPIFY, similarly as between MEC and APPIFY, is transferred inside an integrity-protected channel, APPIFY receives only the information that other parties have intended for it. Therefore, APPIFY cannot learn more information than what [PERSON] provides. Similarly, as we explained earlier for MEC, we can conclude that APPIFY does not learn either of the identifiers \"Alice\" and IMSI. Therefore, APPIFY cannot relate these identifiers with [PERSON]. Thus, the requirements R11-APP-D and R12-APP-I are fulfilled.  
It should be noted that after Step 11, [PERSON] might choose to share her IMSI, her real name \"[PERSON]\", or some other information with APPIFY, e.g., to receive better service. The protocol cannot protect against such disclosure of information. However, the same is probably true for any protocol that allows the free-format exchange of information.  
Outsiders and MNO cannot see the identifier of APPIFY because it is carried inside secure channels. Still, traffic analysis may help in identifying the MEC application in use; see [58; 59]. For that reason, our solution does not fully meet the requirements R1-MNO-D and R15-OUT-D. Another example of gathering information indirectly is when the other MEC application observes a load on the MEC host. The other MEC application could then correlate the observed load to observed traffic patterns related to a particular user, e.g., on the radio interface. This may help in concluding that the user is connected to APPIFY. If the application cannot be recognized by studying encrypted traffic patterns or other indirect means, then R1-MNO-D and R15-OUT-D are met.