# QuietPlace: An Ultrasound-Based Proof of Location Protocol with Strong Identities
## 7 Security and Privacy Analysis  
### Specifications of PoL protocols  
Proof of location protocols must satisfy certain specifications that guarantee their secure operation and make sure that they respect the involved users' privacy. Based on [4] and after an extensive study of the protocols in the literature, we present the specifications that an ideal protocol should satisfy regarding security and privacy. Security specifications that have been considered include:  
* Data integrity/unforgeability: It must be impossible for a user to tamper with the messages they receive from other users without that being evident to checking entities. * Inability to hide or add LPSs: The prover must be unable to add or remove assertions received by witnesses during a protocol session to the proof the prover sends to the verifier. This ensures that every witness's opinion is respected and that the prover does not secretly cooperate with witnesses that do not openly participate in the session. * Non-transferability: The proof created for/by the prover is bound to their identity and cannot be claimed by (or transferred to) another user of the system. * Resistance to distance fraud: The protocol must make sure that a proximity test is executed between prover and witness. This ensures that the prover cannot lie about being closer to the witness than they truly are. * Resistance to mafia fraud (man-in-the-middle): Every protocol session between a prover and a witness must be unique. The messages must be related to the sender's identity. The protocol must also use a method for identifying the existence of a man-in-the-middle. * Resistance to distance hijacking: The LPSs produced by the witnesses refer to a specific proof request made by the prover, for whom a proximity test is executed. These LPSs are useless for any other malicious prover. * Resistance to P-P collusion: It must be impossible for a prover P' to collect LPSs that certify the position of another prover P. This specification is met by combining non-transferability, resistance to distance fraud, mafia fraud, and distance hijacking. * Resistance to P-W collusion: A prover should never learn the identity of a witness that sent an LPS and whether the witness approved or rejected their claim. If the prover's claim is rejected, it is desirable that the witness sends a rejecting LPS, instead of not sending an LPS at all. In this way, the prover is unaware of the witness's decision. * Resistance to W-W collusion: Witnesses must be unaware of other witnesses' identities or whether other witnesses approved or rejected the prover's claim. * LPS uniqueness: Only one LPS per witness must be included in every created PoL. * No single point of failure: Dependency on entities that may make the entire system unusable in case of failure (i.e., if they get attacked) must be avoided. Privacy specifications that have been considered include:  
* Anonymity during proof creation: The identities of the prover and the witnesses that are involved in a PoL creation session must be hidden from everyone. This translates to protection from malicious eavesdroppers and P-W or W-W cooperation. * Anonymity during proof verification: The verifier must be able to learn the identity of the prover. They must be unable to identify the witnesses that participated in the PoL creation, unless they belong to the witness and thus are considered trusted. The CA may also learn the users' identity in order to perform checks and evaluate their behavior. No one else should be able to identify the involved users. * Prover location privacy: The location of the prover must be known only to the witnesses that are close to the prover and the verifier. * Witness location privacy: The location of the witnesses must not be revealed in the assertions they send to the prover. It is preferable that they include their distance from the prover, as it is enough to know that they are close to each other.