MobChain: Three-Way Collusion Resistance in Witness-Oriented Location Proof Systems Using Distributed Consensus
- Prover: A prover is a user who visits a particular location at a specific instance of the time. The user can identify his current location using a smart device that wants to generate digital proof of his physical presence. Digital proof of the physical presence of the prover can be verified in the future.
- Location: A geographical region having defined area boundaries with designated location authorities.
- Location Authority (LA): A location authority is a designated stationery entity on a specific location. The LA assists in proof generation for a prover’s physical presence at a location in a secure manner.
- Location Proof Assertion/Endorsement: An assertion/endorsement of location proof is a digital statement issued by an entity involved in the process of proof generation. An assertion statement guarantees the validity of the process and information contained in a location proof.
- Witness: Witnesses are mobile entities with smart devices, which are temporarily present at a specific location. The witness is engaged by the system to endorse the location proof by attesting the physical presence of the prover co-located with LA.
- Location Provenance: A location provenance is a chain of location proofs tracking the travel history of a prover, preserving the chronological order of locations visited.
- Auditor: An auditor is a semi-trusted entity that validates the location proof of the prover. Furthermore, the auditor is capable of validating the travel path of the prover using location provenance.
- Accountability: All participant nodes in blockchain (except thin nodes) are capable of validating the transactions in the block and can accept or reject blocks on verification. Therefore, the state of the chain gets verified by participating nodes along with every single transaction, providing strong accountability.
- Tamper-resistant: Blockchain’s decentralized mechanism of a block’s chain storage with the participation of a large number of nodes makes it irreversible and immutable. Therefore, blockchain data become tamper resistant over a period of time.
- Distributed data control: Blockchain removes the single point of failure by decentralization of data and its control and therefore provides high availability.
- No trusted third-party dependency: The blockchain consensus mechanism ensures the state of a chain without reliance on a trusted third-party.
- Non-repudiation: Transactions in blocks of blockchain are signed by public-key cryptography ensuring the authenticity of the data. The immutable and irreversible nature of the chain with cryptographic mechanism provides non-repudiation.
1.1. Requirements for Location Proof
- Integrity: Any prover should not be able to generate a fake location proof. Any fake location proof must be detectable. The LA and witnesses should not be able to victimize the prover to provide a fake location proof.
- Non-transferability: Any prover should not be able to falsely claim ownership of any legitimate location proof generated for any other prover.
- Trustworthiness: Any self-reported location proof should not be trusted. Therefore, attestation of the location proofs is required from other entities (such as the location authority or a witness) in the system to make them trustable.
- Non-repudiation: To mitigate the scenario of a user denying a location visit, a location proof, once generated by a user, should not be able to be denied.
1.2. Requirements for Location Provenance Chain
- Chronological Order: The order of the location proofs recorded in the provenance chain must depict the same sequence as the locations visited by the user.
- Timestamping: In a distributed configuration, the clocks of the entities in a location-proof system can be different; the clock of the user’s smart device should not be trusted. Therefore, accurate timestamping is a requirement. It is a challenge to accurately record the chronological order of location proofs of user visits.
- Tamper Evident: The location provenance chain should be tamper-evident. If any tampering occurs to the chain or an individual proof, it should be detectable.
- Validation: A provenance chain can be used to validate the location visit claims along with their chronological order.
- Non-repudiation: The provenance chain must be able to reveal the true travel path of the prover in case of denial or re-ordering of location visits.
1.3. Challenges of Location Proofs System
- Integrity: The prover should not be able to create a fake location proof alone or by collaboration with other entities. The prover may adopt relaying.
- Collusion Resistance: In the distributed model, location authorities aid in the proof generation, and witnesses endorse them. However, both location authorities and witnesses are not guaranteed to be trustable. The user can collude with location authorities and witnesses to generate false location proofs. A location proof system must be capable of collusion resistance.
- Storage: It must be determined as to where proofs should be stored. Storing all proofs in a central server will result in bottlenecks. In the distributed modal, each location may have common storage for location proofs; nevertheless, the verification process becomes difficult to access the proofs from distributed locations. Storing the location proofs over the user’s smart device is best if the user is trustable. However, the user has full control over his device and can manipulate the proofs; thus, proofs must be tamper-evident.
- Clock synchronization and timestamping: LPS is supposed to maintain the sequence of locations visited by the prover to allow the auditor to verify the travel path. To track the chronological order of visits, clocks of entities in the distributed environment must be synchronized. That is, the clocks of the LA, any witness and the prover need to be synchronized. Timestamps reported by the prover cannot necessarily be trusted; therefore, a reliable source providing the true timestamps for location proofs is needed.
- Location Privacy: The location privacy concern of the prover can be seen from two perspectives. First, the prover wants the auditor to validate the location proofs of the prover but wants to limit the amount of information exposed to the auditor. Secondly, the prover, while generating a location proof, needs attestation from a witness co-located. Hence, the prover wants the witness to endorse the location proofs without revealing their real identity. So, location privacy determines the level of granularity of location information; the user wants to share with auditors on one hand and wants the witnesses to endorse the location proof anonymously.
- Deployment: From a deployment perspective, a location proof system should be incremental. In the beginning, a limited number of location authorities could be deployed, but later on, adding new location authorities to divide a large area into small zones must be easy.
- Unforgeable Identities: Entities involved in the location proof system must have unique and unforgeable identities. Otherwise, a prover may generate false identities to masquerade as dummy witnesses to obtain a false location proof. The identity of an entity in the system must be linkable to a single party while keeping its anonymity for other entities in the system to preserve its privacy.
- Proof Generation Time : The proof generation time is the interval between the request generated by the user and the final proof generated by the system. It should be short enough (a few seconds) for the system to be practically usable. There is a trade-off between security and proof generation time. However, higher security guarantees requiring a longer proof generation time may make the system inapplicable in real-world scenarios.
- Proof Size : Location proof size becomes a constraint for location proof systems, bearing in mind the storage capacity of smart devices and location authority especially when location provenance is supported. Additionally, space requirements change when location privacy is enabled and support granularity levels for location information with respect to entities in the system.
- Number of Entities/Witnesses Involved [9,13]: Distributed location proof systems in general, and any witness-oriented location protocol in particlazzur, involve two or more entities in the proof protocol. The number of entities involved in location proof protocol provides the reliability of the physical presence of a user at a location. However, having more entities in the protocol provides reliability at the cost of proof generation time.
- Participant selection decision control lies with participants of the protocol: A participant’s selection control for proof generation lies with the user who will always choose the colluding participant to cheat. Xinlei et al.  proposed the STAMP scheme, which relies on witness selection on the peer discovery mechanism provided by the underlying communication technology of the user’s device. Similarly, Brambilla et al.  developed a scheme that allows the user to select the peer for assistance in a proof generation. In WORAL , a user looks up the location authority, which is the stationary entity on a site, which randomly chooses a witness from a “witness list” for aiding the user in a proof generation.
- Participant selection decision control lies with the single party: The user has direct communication with LA, and both can collude to generate a false proof. Even in the witness-oriented scheme, witness selection control either lies with the prover or LA. So, if both the prover and LA are colluding, it will be easy for them to choose a colluding witness. In the scheme of Rasib et al. , LA is the stationary entity on a site, which randomly chooses a witness from the “witness list” for aiding the user in a proof generation. Furthermore, the puppet witness attack and wormhole attacks are easy in this scenario.
- To the best of our knowledge, MobChain is the first three-way collusion-resistant witness-oriented LPS. We highlighted the two weaknesses in the design of existing schemes enabling three-way collusion attacks. Furthermore, we proposed the distributed consensus strategy in MobChain to mitigate the design weakness of existing schemes and resist three-way collusion.
- A schematic description of distributed consensus and location proof generation protocol providing coarse-grained messages and communication to achieve distributed consensus and location proofs.
- We provide a detailed security analysis of MobChain highlighting the possibilities of fake proof generation and permutations of collusion attacks and how the proposed scheme provides resistance.
- Experimental evaluation determines the low bounds on space and computation requirements of MobChain. Furthermore, it highlights the impact of the distribution of entities in the system. That is,
- Impact of the number of active workers (witnesses and location authorities) on
- Decentralized Decision Time;
- Proof Generation Time (PGT); and
- Decision Block Size and Location Proof Size.
- Impact of the number of entities participating in distributed consensus on decision block size and proof generation time.
- Concurrent request impact on decentralized decisions time.
2. Related Work
3. Threat Model
- Decision Block: Block generated by a consensus of supervisor nodes for the selection of location authority and witnesses to aid the prover for proof generation.
- Decision Blockchain: Blockchain records the decision blocks generated by the consensus of supervisor nodes in chronological order.
- Location Proof: A proof of the presence of the user at a location with an exact timestamp.
- Location Provenance Blockchain: The blockchain records all the past location proofs in a chain to keep their chronological order intact.
- False Presence: A malicious prover may want to get fake proof of location without being physically present at the claimed location.
- False Time (back-dating, future-dating): The prover tries to get the proof for his true location with a timestamp different from the time of visit. Participants of the protocol collude to generate the location proof for the prover with a past timestamp in the back-dating attack and with a future timestamp in the future-dating attack.
- Sequence Alteration: In a sequence alteration attack, the prover tries to present a false travel path by changing the chronological order of location proofs.
- Implication: Participants of the protocol dishonestly prove the physical presence of the prover at the location to victimize the prover.
- False Endorsement: In the witness-oriented model, the witness colludes with the prover to falsely endorse that prover is physically present at the claimed location.
- Presence Repudiation: The user tries to deny his presence at a location at a time instance for which the location proof has been generated.
- Proof Tampering: A legitimate old proof’s timestamp or location information may be modified to present it as a new proof.
- Puppet Witness Attack: The location authority and prover may collude and create a puppet witness to falsely endorse the proof of location or relay the request to a remote witness not co-located to the prover at the time of visit.
- Wormhole Attack: Any entity of the system physically present on the desired location may impersonate the prover and generate the location proof for him. It is not necessary that the prover has shared his secret keys with the impersonating party but might have established a covert communication channel, and the impersonator might be relaying the messages of proof generation protocol to the prover. A wormhole attack is also known as a terrorist fraud attack.
3.1. Assumptions: We Make the Following Assumptions about the Actors in the System
- Participants of the system are well known to the system, and they do not share their private keys.
- Users do not have multiple identities to launch a Sybil attack.
- Smart devices are not shared with other participants.
- At least one witness is available at the location of the visit.
- No entity in the system will be able to compromise 51% of the supervisor nodes .
MobChain has the Following Goals
- To provide resistance to three-way collusion while ensuring protection against known attacks over existing schemes.
- To measure the impact of introducing distributed consensus in location proof generation protocol.
- To analyze the storage requirements for peers (supervisor nodes) for maintaining the blockchain.
- Separation of participant selection control from location proof generation protocol
- Decentralization of control decisions (selection of participants, the addition of location proofs in provenance chain, validation of location proofs on the request of the third party).
- Approval of witness and location authority for the prover to start location proof generation.
- Making an approval decision block part of the decision blockchain (maintained by the admin layer of MobChain).
- Making a generated location proof part of a location provenance chain (maintained by the admin layer of MobChain).
- Validation of old location proofs on the request of the third party involving a decision blockchain and location provenance chain.
4.1. Architecture Overview
- Admin Layer: All control decisions are the responsibility of the admin layer underlying the P2P network. Commodity devices in the admin layer form a P2P network of supervisor nodes. Supervisor nodes take proof requests from the prover, and all control decisions are taken through a distributed consensus mechanism within the admin layer. The primary operations of the admin layer are as follows:
- Distributed consensus (decentralized decision for the selection of worker nodes co-located to the prover for assistance in location proof generation).
- Final validation of location proof generated and adding it to blockchain to build location provenance.
- Auditor role to verify the location proof requested by the third party.
- Service Layer: In MobChain, the service layer is not part of the P2P network admin layer. The service layer consists of all devices (witness, prover, and location authority devices) that may participate in the location proof protocol. The location authority is the static entity permanently designated at the location while witnesses and provers are mobile entities who may visit the location temporarily. Any mobile entity visiting the location can be in the role of a prover and witness. Once a mobile entity requests the proof of location, it becomes the prover for that request, while all other entities co-located on the location are eligible to become a witness for that prover. At some other instance of time, this witness can become the prover on requesting the proof of its location, and the prover can become the witness for him in the location proof protocol. Since the location authority is the static entity designated by the system, therefore, its location is known in advance. Furthermore, it is responsible for ensuring that the prover and witnesses are physically present at the location. All mobile entities visiting the location connect to supervisor nodes in the admin layer to let the system know their presence at the location. No permanent connection is required with the admin layer by these entities. However, a periodic ping mechanism ensures the admin layer is informed about their presence and location. Once any of these mobile entities request the system to provide location proof, it becomes the prover, and other co-located entities are considered available witnesses. RRSN pings the witness selected after distributed consensus to ensure that it is available and then sends the approval message to the prover to initiate the location proof protocol with the chosen witness and location authority.
- Decisions Blockchain: Tracks all decisions taken by the admin layer, keeping their chronological order intact with timestamps. Blocks of the decision chain will serve for validation of location proofs and cross-checking of the witness elected by the admin layer and the actual witness who aided in proof generation. It will also provide protection against future and backdating attacks and three-way collusion for a fake proof generation or representation of valid old proof after tampering.
- Location Provenance Blockchain: All location proofs of the prover will be recorded in chronological order in the location provenance chain.
4.2. Distributed Consensus
4.3. Schematic Description of Distributed Consensus and Location Proof Generation in MobChain
- Decentralized Decision on Witness and LA Selection (Distributed Consensus) Phase: On a prover’s request, the RRSN initiates the protocol over the admin layer such that the witness and LA are elected through a distributed consensus of supervisor nodes.
- Witness-Oriented Location Proof Generation Phase: Once the LA and witness are intimated to assist the prover, the actual location proof generation phase starts.
4.3.1. Decentralized Decision on Witness and LA Selection (Distributed Consensus)
4.3.2. Witness-Oriented Location Proof Generation Phase
- The prover requests the location authority LAC (chosen by the admin layer) to assist him in proof generation by sending an LPReq message.LPReq = [AMsg′, T′P]
- LAC first validates the LPReq against the AMsg′ received from RRSN. Once validated, it then performs secure localization to ensure that the prover is physically present at the mentioned location. Finally, LAC generates the location proof LP against LPReq,LP = [IDLA, LPReq, TLS]
- LAC then creates the location proof assertion request “AReqLP” and sends it to witness WC.AReqLP = [LP, SignLA(LP)]
- The witness validates the AReqLP against AMsg′ to ensure that LA is asking for the assertion of validity and then performs the secure localization to ensure that the location authority and prover are not colluding and the prover is physically present on the reported location. Once verification is successful, the witness creates the assertion statement “AStat”AStat = [IDDB′i, IDP, IDLAC, IDWC, H(AReqLP), TAStat]AR = [AStat, SignWc (AStat)]The witness now generates the final asserted location proof “ALP” and sends it back to the LA. The location authority validates by verifying the signatures of the asserted location proof using the public key of the witness to ensure it is from the selected witness. Then, the location authority provides the asserted location proof to the prover.ALP = [AReqLP, AR, TALP]
- The prover does not trust the location authority; therefore, it sends the asserted location proof (provided by location authority) back to the witness for verification to ensure the provided location proof is endorsed by the witness. Therefore, on receiving ALP, the prover issues a verification request VReq to the witness:VReq = [ALP, TVPReq].
- The witness responds the prover by Yes/No after validation of VReq by sending message “VR”V = [R, H(ALP), TV]VR = [V, SignWc(V)].
- After successful verification of the asserted location proof, the prover sends the acknowledgement ACKALP to the location authority to end the protocolACK = [ALP, VR, IDDB′i, TACK]ACKALP = [ACK, SignP(ACK)].
- After validation of ACKALP, the location authority will end the protocol and send ACKALP′ to RRSN after signing it.ACKALP′ = [ACKALP, SignLA(ACKALP)]
- RRSN after validation of ACKALP′ will make it part of the location provenance chain by broadcasting it in the admin layer.
5. Security Analysis
- Suppose all witnesses co-located to the prover are willing to participate in the collusion attack at a particular time instance. Therefore, the probability of getting malicious witnesses selected is 100%. In this scenario, the fake proof generation is only possible if the chosen location authority is also colluding. If the location authority is honest and not willing to collude, then the prover will not be able to get the fake proof of location. However, in the presence of some honest and malicious location authorities, the probability of a successful collusion attack is still reduced in MobChain, as location authority selection control is not in the hands of the prover, which is the weakness of past location proof systems.
- Suppose all available location authorities are willing to collude with the prover. Therefore, whatever location authority is chosen by the admin layer will allow the prover to obtain a fake proof. However, a fake proof cannot be generated without having a colluding witness. If a chosen witness is honest, then the fake proof will not be asserted by the witness, and the generated proof will be rejected. Since in existing schemes, witness selection control either lies with the location authority or prover itself, therefore, three-way collusion cannot be prevented. However MobChain, due to the separation of participant selection from the location proof protocol, resists such three-way collusion.
- At least 51% of the supervisor nodes in the admin layer are compromised and are colluding with the prover to assign a malicious witness and location authority of their own choice to enable fake location proof generation. We have assumed that the prover is unable to compromise 51% of the supervisor nodes in the admin layer to get the decision of his own choice . Even if the prover is successful to compromise 51% of the supervisor nodes, without having a colluding location authority and witness, a collusion attack is not possible.
- All witnesses and location authorities in the system available at a time instance are willing to collude with the prover. It means that the whole location proof system is being compromised by the prover. In this situation, even if every supervisor node in the admin layer is honest, whatever witness and location authority are chosen by the admin layer will allow the prover to generate fake proof successfully following the protocol honestly. However, we assume that at any single instance of time, all the witnesses and location authorities are not willing to collude with the single prover.
- All available location authorities and witnesses in the system are malicious and willing to collude with the prover at any time. There is not a single honest location authority and witness available in the system.
- At least 51% of the supervisor nodes in the admin layer are compromised, and the prover makes their own decisions. That is, the colluding location authority and witness are chosen in a decentralized decision.
6. Experimental Evaluation
- Decentralized Decision Time (DDT): It is the time interval between the location proof request to RRSN and the final approval message (created after distributed consensus containing the selected location authority and witness) received by the prover. Measuring the decentralized decision time will help to estimate the additional overhead in proof generation time contributed by distributed consensus.
- Proof Generation Time (PGT): Proof generation time is the interval between the location proof request generated and the final generated proof received by the prover. It should be short enough (within a few seconds) for the system to be practically usable. The proof generation time includes the decentralized decision time.
- Decision Block Size: Decision block size depends on the signature scheme used to provide non-repudiation by all entities involved in the decentralized decision. The size of the decision block will have a direct impact on the overall storage capacity required by the admin layer nodes, as the decision blockchain will be maintained by supervisor nodes.
- Location Proof Size: Since location proofs will be stored on the user’s mobile device, therefore, its size must be appropriate concerning the storage capacity of smart devices. On the other hand, the location proof size also drives the storage capacity of supervisor nodes as the location provenance chain is maintained by the admin layer.
- Number of active workers (active witnesses and LA(s));
- Number of supervisor nodes (in a P2P network of admin layer);
- Consensus Threshold
- A key size of a signature scheme.
6.1. Impact Analysis of Number of Active Workers
6.1.1. Impact on Decentralized Decision Time and Proof Generation Time
6.1.2. Impact on Proof Size and Decision Block Size
6.2. Number of Supervisor Nodes Impact Analysis
6.2.1. Impact on Decentralized Decision Time and Proof Generation Time
6.2.2. Impact on Location Proof Size and Decision Block Size
6.3. Concurrent Request Impact on Decentralized Decision Time
- ECC key size 224;
- Consensus threshold (N/2) + 1;
- 15 supervisor nodes.
7. Conclusions and Future Work
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Conflicts of Interest
- Mohapatra, D.; Suma, S.B. Survey of location based wireless services. In Proceedings of the IEEE International Conference on Personal Wireless Communications, New Delhi, India, 23–25 January 2005. [Google Scholar]
- Gambs, S.; Killijian, M.-O.; Roy, M.; Traoré, M. PROPS: A privacy-preserving location proof system. In Proceedings of the 2014 IEEE 33rd International Symposium on Reliable Distributed Systems (SRDS), Nara, Japan, 6–9 October 2014. [Google Scholar]
- Khan, R.; Zawoad, S.; Haque, M.M.; Hasan, R. Who, when, and where? Location proof assertion for mobile devices. In Proceedings of the IFIP Annual Conference on Data and Applications Security and Privacy, Vienna, Austria, 14–16 July 2014. [Google Scholar]
- Sastry, N.; Shankar, U.; Wagner, D. Secure verification of location claims. In Proceedings of the 2Nd ACM Workshop on Wireless Security, San Diego, CA, USA, 14–19 September 2003. [Google Scholar]
- Hasan, R.; Burns, R. Where have you been? Secure location provenance for mobile devices. arXiv 2011, arXiv:1107.1821. [Google Scholar]
- Muthukrishnan, K.; Lijding, M.; Havinga, P. Towards smart surroundings: Enabling techniques and technologies for localization. In Proceedings of the International Symposium on Location-and Context-Awareness, Oberpfaffenhofen, Germany, 12 May 2005. [Google Scholar]
- Zhu, Z.; Cao, G. APPLAUS: A privacy-preserving location proof updating system for location-based services. In Proceedings of the 2011 IEEE INFOCOM, Shanghai, China, 10–15 April 2011. [Google Scholar]
- Lenders, V.; Koukoumidis, E.; Zhang, P.; Martonosi, M. Location-based trust for mobile user-generated content: Applications, challenges and implementations. In Proceedings of the 9th Workshop on Mobile Computing Systems and Applications, Napa Valley, CA, USA, 25–26 February 2008. [Google Scholar]
- Wang, X.; Pande, A.; Zhu, J.; Mohapatra, P. STAMP: Enabling privacy-preserving location proofs for mobile users. IEEE/ACM Trans. Netw. 2016, 24, 3276–3289. [Google Scholar] [CrossRef]
- Duckham, M.; Kulik, L. Location privacy and location-aware computing. Dyn. Mob. GIS Investig. Chang. Space Time 2006, 3, 35–51. [Google Scholar]
- Singelee, D.; Preneel, B. Location verification using secure distance bounding protocols. In Proceedings of the IEEE International Conference on Mobile Adhoc and Sensor Systems Conference, Washington, DC, USA, 7 November 2005. [Google Scholar]
- Waters, B.; Felten, E. Secure, Private Proofs of Location. Ph.D. Thesis, Princeton University, Princeton, NJ, USA, 2003. [Google Scholar]
- Hasan, R.; Khan, R.; Zawoad, S.; Haque, M.M. WORAL: A witness oriented secure location provenance framework for mobile devices. IEEE Trans. Emerg. Top. Comput. 2016, 4, 128–141. [Google Scholar] [CrossRef]
- Talasila, M.; Curtmola, R.; Borcea, C. Link: Location verification through immediate neighbors knowledge. In Proceedings of the International Conference on Mobile and Ubiquitous Systems: Computing, Networking, and Services, Sydeny, Australia, 6–9 December 2010. [Google Scholar]
- Neisse, R.; Steri, G.; Fovino, I.N. A blockchain-based approach for data accountability and provenance tracking. In Proceedings of the 12th International Conference on Availability, Reliability and Security, Reggio Calabria, Italy, 29 August–1 September 2017; pp. 1–10. [Google Scholar]
- Greenspan, G. Multi Chain Private Blockchain-White Paper. 2015. Available online: https://www.multichain.com/download/MultiChain-White-Paper.pdf (accessed on 15 June 2021).
- Ahram, T.; Sargolzaei, A.; Sargolzaei, S.; Daniels, J.; Amaba, B. Blockchain technology innovations. In Proceedings of the 2017 IEEE Technology Engineering Management Conference (TEMSCON), Santa Clara, CA, USA, 8–10 June 2017. [Google Scholar]
- Ferdous, M.S.; Chowdhury, M.J.M.; Hoque, M.A.; Colman, A. Blockchain consensus algorithms: A survey. arXiv 2020, arXiv:2001.07091. [Google Scholar]
- Abeyratne, S.A.; Monfared, R.P. Blockchain ready manufacturing supply chain using distributed ledger. Int. J. Res. Eng. Technol. 2016, 5, 1–10. [Google Scholar]
- Khan, R.; Haque, M.; Hasan, R. A secure location proof generation scheme for supply chain integrity preservation. In Proceedings of the 2013 IEEE International Conference on Technologies for Homeland Security (HST), Waltham, MA, USA, 12–14 November 2013. [Google Scholar]
- Liang, X.; Shetty, S.; Tosh, D.; Kamhoua, C.; Kwiat, K.; Njilla, L. ProvChain: A blockchain-based data provenance architecture in cloud environment with enhanced privacy and availability. In Proceedings of the 17th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing, Madrid, Spain, 14–17 May 2017. [Google Scholar]
- Kosba, A.; Miller, A.; Shi, E.; Wen, Z.; Papamanthou, C. Hawk: The blockchain model of cryptography and privacy-preserving smart contracts. In Proceedings of the 2016 IEEE Symposium on Security and Privacy (SP), San Jose, CA, USA, 23–25 May 2016. [Google Scholar]
- Ramachandran, A.; Kantarcioglu, M. Using blockchain and smart contracts for secure data provenance management. arXiv 2017, arXiv:1709.10000. [Google Scholar]
- Miller, A.; Juels, A.; Shi, E.; Parno, B.; Katz, J. Permacoin: Repurposing bitcoin work for data preservation. In Proceedings of the 2014 IEEE Symposium on Security and Privacy, San Jose, CA, USA, 18–21 May 2014. [Google Scholar]
- Sengupta, B.; Bag, S.; Ruj, S.; Sakurai, K. Retricoin: Bitcoin based on compact proofs of retrievability. In Proceedings of the 17th International Conference on Distributed Computing and Networking, Singapore, 4–7 January 2016. [Google Scholar]
- Brambilla, G.; Amoretti, M.; Zanichelli, F. Using block chain for peer-to-peer proof-of-location. arXiv 2016, arXiv:1607.00174. [Google Scholar]
- Amoretti, M.; Brambilla, G.; Medioli, F.; Zanichelli, F. Blockchain-based proof of location. In Proceedings of the 2018 IEEE International Conference on Software Quality, Reliability and Security Companion (QRS-C), Lisbon, Portugal, 16–20 July 2018. [Google Scholar]
- Nasrulin, B.; Muzammal, M.; Qu, Q. A robust spatio-temporal verification protocol for blockchain. In Proceedings of the International Conference on Web Information Systems Engineering, Dubai, UAE, 12–15 November 2018. [Google Scholar]
- Khan, R.; Zawoad, S.; Haque, M.M.; Hasan, R. OTIT: Towards secure provenance modeling for location proofs. In Proceedings of the 9th ACM Symposium on Information, Computer and Communications Security, Kyoto, Japan, 4–6 June 2014. [Google Scholar]
- Zafar, F.; Khan, A.; Suhail, S.; Ahmed, I.; Hameed, K.; Khan, H.M.; Jabeen, F.; Anjum, A. Trustworthy data: A survey, taxonomy and future trends of Secure Provenance Schemes. J. Netw. Comput. Appl. 2017, 94, 50–68. [Google Scholar] [CrossRef]
- Gabber, E.; Wool, A. How to prove where you are: Tracking the location of customer equipment. In Proceedings of the 5th ACM Conference on Computer and Communications Security, San Francisco, CA, USA, 2–5 November 1998. [Google Scholar]
- Luo, W.; Hengartner, U. Proving your location without giving up your privacy. In Proceedings of the Eleventh Workshop on Mobile Computing Systems & Applications, Annapolis, MD, USA, 22–23 February 2010. [Google Scholar]
- Denning, D.E.; MacDoran, P.F. Location-based authentication: Grounding cyberspace for better security. Comput. Fraud. Secur. 1996, 1996, 12–16. [Google Scholar] [CrossRef]
- Capkun, S.; Hubaux, J.P. Secure positioning of wireless devices with application to sensor networks. In Proceedings of the IEEE 24th Annual Joint Conference of the IEEE Computer and Communications Societies, Miami, FL, USA, 13–17 March 2005. [Google Scholar]
- Bauer, K.; McCoy, D.; Anderson, E.; Breitenbach, M.; Grudic, G.; Grunwald, D.; Sicker, D. The directional attack on wireless localization. In Proceedings of the IEEE Global Telecommunications Conference, Honolulu, HI USA, 30 November 2009. [Google Scholar]
- Gruteser, M.; Grunwald, D. Anonymous usage of location-based services through spatial and temporal cloaking. In Proceedings of the 1st International Conference on Mobile Systems, Applications and Services, San Francisco, CA, USA, 5–8 May 2003. [Google Scholar]
- Zugenmaier, A.; Kreutzer, M.; Kabatnik, M. Enhancing applications with approved location stamps. In Proceedings of the IEEE Intelligent Network 2001 Workshop, Boston, MA, USA, 6–9 May 2001. [Google Scholar]
- Bucher, D.; Rudi, D.; Buffat, R. Captcha your location proof—A novel method for passive location proofs in adversarial environments. In Proceedings of the LBS 2018: 14th International Conference on Location Based Services, Zurich, Switzerland, 15–17 January 2018. [Google Scholar]
- Brassil, J.; Netravali, R.; Haber, S.; Manadhata, P.; Rao, P. Authenticating a mobile device’s location using voice signatures. In Proceedings of the 2012 IEEE 8th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), Barcelona, Spain, 8–10 October 2012. [Google Scholar]
- Saroiu, S.; Wolman, A. I am a sensor, and I approve this message. In Proceedings of the Eleventh Workshop on Mobile Computing Systems & Applications, Annapolis, MD, USA, 22–23 February 2010. [Google Scholar]
- Gilbert, P.; Cox, L.P.; Jung, J.; Wetherall, D. Toward trustworthy mobile sensing. In Proceedings of the Eleventh Workshop on Mobile Computing Systems & Applications, Annapolis, MD, USA, 22–23 February 2010. [Google Scholar]
- Saroiu, S.; Wolman, A. Enabling new mobile applications with location proofs. In Proceedings of the 10th Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA, USA, 23–24 February 2009. [Google Scholar]
- Luo, W.; Hengartner, U. Veriplace: A privacy-aware location proof architecture. In Proceedings of the 18th SIGSPATIAL International Conference on Advances in Geographic Information Systems, San Jose, CA, USA, 2–5 November 2010. [Google Scholar]
- Davis, B.; Chen, H.; Franklin, M. Privacy-preserving Alibi Systems. In Proceedings of the 7th ACM Symposium on Information, Computer and Communications Security, Seoul, Korea, 2–4 May 2012. [Google Scholar]
- Ananthanarayanan, G.; Haridasan, M.; Mohomed, I.; Terry, D.; Thekkath, C.A. StarTrack: A framework for enabling track-based applications. In Proceedings of the 7th International Conference on Mobile Systems, Applications, and Services, Kraków, Poland, 22–25 June 2009. [Google Scholar]
- González-Tablas, A.I.; Ramos, B.; Ribagorda, A. Path-stamps: A proposal for enhancing security of location tracking applications. In Proceedings of the CAiSE Workshops, Klagenfurt/Velden, Austria, 16–20 June 2003. [Google Scholar]
- Bussard, L.; Bagga, W. Distance-bounding proof of knowledge to avoid real-time attacks. In Proceedings of the IFIP International Information Security Conference, Chiba, Japan, 30 May–1 June 2005. [Google Scholar]
- He, W.; Liu, X.; Ren, M. Location cheating: A security challenge to location-based social network services. In Proceedings of the 31st International Conference on Distributed Computing Systems, Minneapolis, MN, USA, 20–24 June 2011. [Google Scholar]
- Malaney, R. Quantum geo-encryption. In Proceedings of the 2016 IEEE Global Communications Conference (GLOBECOM), Washington, DC, USA, 4–8 December 2016. [Google Scholar]
- Brassil, J.; Manadhata, P.K. Proving the location of a mobile device user. In Proceedings of the 2012 Virginia Tech. Wireless Symposium, Blacksburg, VA, USA, 24–29 June 2012. [Google Scholar]
- Kounas, D.; Voutyras, O.; Palaiokrassas, G.; Litke, A.; Varvarigou, T. QuietPlace: An ultrasound-based proof of location protocol with strong identities. Appl. Syst. Innov. 2020, 3, 19. [Google Scholar] [CrossRef][Green Version]
- Nosouhi, M.R.; Yu, S.; Zhou, W.; Grobler, M.; Keshtiar, H. Blockchain for secure location verification. J. Parallel Distrib. Comput. 2020, 136, 40–51. [Google Scholar] [CrossRef]
- Nosouhi, M.R.; Sood, K.; Yu, S.; Grobler, M.; Zhang, J. PASPORT: A secure and private location proof generation and verification framework. IEEE Trans. Comput. Soc. Syst. 2002, 7, 293–307. [Google Scholar] [CrossRef]
- Mengjun, L.; Shubo, L.; Rui, Z.; Yongkai, L.; Jun, W.; Hui, C. Privacy-preserving distributed location proof generating system. China Commun. 2016, 13, 203–218. [Google Scholar] [CrossRef]
- AKKA Framework. Available online: https://doc.akka.io/docs/akka/current/typed/guide/introduction.html?language=java (accessed on 25 June 2021).
|LA||Location Authority||The designated stationary entity on each site aids the prover in location proof generation while ensuring that the witness and prover are physically present at the location.|
|WN||Worker Node||Worker node refers to LA(s) and witnesses who provide services to prover for the generation of the asserted location proof.|
|SN||Supervisor Node||Admin layer peers are called supervisor nodes. These nodes are responsible for decentralized decisions.|
|RRSN||Request-Receiving Supervisor Node||The supervisor node (SN) initiates the distributed consensus protocol on receiving the proof request from the prover. Any of the supervisor nodes can receive the location proof request. RRSN is a label to differentiate the role of the request-receiving supervisor node from other supervisor nodes in the system. For example, Prover1 requests SN1 for location proof; then, SN1 is considered RRSN, while at that same time, Prover2 requests SN2 for location proof; then, SN2 is considered RRSN in for the Prover2 request.|
|CWN||Chosen Worker Node||CWN refers to the LA and witness chosen by the admin layer through distributed consensus against the proof request of the prover.|
|PReq||Proof Request||Proof request message symbol.|
|DAM||Decision Acknowledgement Message||During consensus protocol execution, every SN decides the witnesses and LA for the prover and informs the RRSN about his choice by sending a decision acknowledgement message.|
|DB||Decision Block||The decision block is the final message generated by RRSN on the completion of distributed consensus. This decision block is made part of the decision blockchain.|
|AMsg||Approval Message||On completion of distribution consensus, the prover is provided with the approval message containing the decision block ID, chosen witness, and location authority.|
|LPReq||Location Proof Request||The prover requests the location authority to aid him in proof generation using an approval message as an authentication token.|
|LP||Location Proof||LP is a digital certificate generated by LA approving the physical presence of the prover at the location on a specific time instance.|
|AReqLP||Assertion Request (of Location Proof)||The location authority requests the witness for LP assertion by sending AReqLP.|
|AR||Assertion Response||Witness after successful verification of the prover’s location and validation of AReqLP sends back an assertion response (AR) to the location authority.|
|ALP||Asserted Location Proof||Witness-asserted LP is termed as ALP.|
|VReq||Verification Request||To ensure the validity of ALP, the prover issues a verification request VReq to witness.|
|VR||Verification Response||Witness responds to the prover by Yes/No after the validation of VReq by sending the message “VR”|
|ACKALP||Acknowledgement Message||On successful verification of the asserted location proof, the prover sends the acknowledgement ACKALP to the location authority to end the protocol.|
|Case||Prover||LA||Witness||Scenario/Collusion Class||Threat/Attack||STAMP ||WORAL ||MobChain|
|1||H||H||H||Everyone Honest||No attack||✓||✓||✓|
|2||H||H||M||Malicious Witness||False endorsement||✓||✓||✓|
|3||H||M||H||Malicious LA||Denial of service, False assertion||NA||✓||✓|
|4||H||M||M||LA–Witness Collusion||Implication attack||NA||✓||✓|
|5||M||H||H||Malicious Prover, Prover–Prover Collusion||False presence, Proof tampering, Sequence alteration, False time, Wormhole/Terrorist fraud||✓||✓||✓|
|6||M||H||M||Prover–Witness Collusion||False endorsement||✓||✓||✓|
|7||M||M||H||Prover–LA Collusion||Puppet witness attack||NA||✓||✓|
|8||M||M||M||Three-Way Collusion||Fake proof generation is achievable when all participants are malicious at the same time.||✗||✗||✓|
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.
© 2021 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).
Zafar, F.; Khan, A.; Malik, S.U.R.; Ahmed, M.; Maple, C.; Anjum, A. MobChain: Three-Way Collusion Resistance in Witness-Oriented Location Proof Systems Using Distributed Consensus. Sensors 2021, 21, 5096. https://doi.org/10.3390/s21155096
Zafar F, Khan A, Malik SUR, Ahmed M, Maple C, Anjum A. MobChain: Three-Way Collusion Resistance in Witness-Oriented Location Proof Systems Using Distributed Consensus. Sensors. 2021; 21(15):5096. https://doi.org/10.3390/s21155096Chicago/Turabian Style
Zafar, Faheem, Abid Khan, Saif Ur Rehman Malik, Mansoor Ahmed, Carsten Maple, and Adeel Anjum. 2021. "MobChain: Three-Way Collusion Resistance in Witness-Oriented Location Proof Systems Using Distributed Consensus" Sensors 21, no. 15: 5096. https://doi.org/10.3390/s21155096