I read this paper on protecting user privacy in smart parking management system. It talks about using zero knowledge proofs to protect privacy but I am not certain how they do it. My assumption is that the Verifier has the public key of the User and sends the User challenges that the User needs to complete with its private key. Would be great if someone could clarify this to me.


2 Answers 2


Caveat: the whole idea of protecting user privacy in electronic parking meters when cars have license plates looks like a solution in search of a problem to me.

We are told a user's device (e.g. NFC-enabled mobile phone) is loaded with some (assumed genuine) credential:

The credential encodes the User’s attributes (name, vehicle registration plate and some fresh random value).

Then when a check is needed, the user's device

generates from her credentials a presentation token that contains the required information and the supporting cryptographic evidence.

What this cryptographic evidence is, how parking rights are determined from that, what actually protects name and vehicle registration plate from prying eyes, and how it is prevented that credentials are cloned to the device of another user with no right to park (like some user with right to park wants to lawlessly allow another without such right to park) is left at the imagination of the audience. The article is extremely lacking on that.

A nearly totally disconnected second part of the article explains that the user's device makes a cryptographic proof of a private key $x$ that it holds to another verifying device like a parking gate, per Schnorr’s zero-knowledge protocol or well-known derivatives, run on an Elliptic Curve group. There's no discussion about the potential that the public key (necessary on the verifier side, thus customarily sent by the device on request) becomes identifying information.

But that article is far from the worse published in non-crypto journals among those blending IoT and ECC in a would-be catchy title. I did not spot a glaring error in 10 minutes of reading. And at least, the performance reported (11 to 58s on small microprocessors for scalar multiplication on a 160-bit elliptic curve) is plausibly true.


I believe the answer lies in section 4 of the paper, titled "Privacy preserving outdoor parking management".

The authors explain the details of ZKP schemes later on, as well as the libraries they used and curve parameters chosen... which explains the "how" pretty clearly.

My understanding of this paper is that the the possession of secret information (e.g. personally identifying information) of a parking client is to be proven to the parking system operator in zero knowledge.

I would also add that they mention both interactive and non-interactive versions of ZK protocols. So in that case, only the prover sends a (single) message to the verifier, e.g. for the modified Schnorr protocol (5.3). Again, the client is the prover and the parking system is the verifier in this application, for this non-interactive scheme.

  • $\begingroup$ I do understand that the user is the Prover and the parking sensor is the Verifier. I am not certain if they are using public and private key for zero knowledge proof. Does the prover have a private key and the verifier the public key for the zero knowledge proof to work? $\endgroup$ Nov 10, 2018 at 14:07
  • $\begingroup$ The authors aren't doing signing or encryption. There is secret information $x$ (encoded as an integer mod n) that the prover wants to prove they know (in zero knowledge), and nothing more in this scheme. I'd just keep the notions separate for clarity. Re-read the steps of the protocol in 5.2 and 5.3 and you'll plainly see that the prover does indeed transmit $x\cdot P$. In other contexts, that's a public key. But we just don't care about those semantics here. $\endgroup$
    – Michael
    Nov 10, 2018 at 16:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.