1
$\begingroup$

I want to create a process whereby registered users receive a QR code on their phone and then they present this code to a camera. The camera should scan the QR code and then decide if the QR code is legitimate, in which case access is granted.

According to my very basic understanding, the camera would be equipped with a "public key" and the QR codes (sent to the users) should all be generated using a matching "private key". The camera then performs a basic decode and allows/denies access.

What cryptographic techniques are suitable? How are they used?

EDIT

The core behind the question is around the event where the web-cam needs to validate a random QR code. This should be achieved using local keys/hashes without the web-cam having to connect to some database in order to validate the QR code. So my question, I suspect, is a very basic one around cryptography: Can the camera have some key stored in memory (typically on a Rasberry Pi) and be able to validate the QR code (again without connecting to the internet). If my question is nonsense then please discard altogether.

$\endgroup$
4
  • 1
    $\begingroup$ This Q/A site is about questions on cryptography itself. Creating a full secure system is unfortunately out of bounds. Furthermore, I think your question is more like a project, and seems to lack research making it overly broad, so I cannot migrate this question. $\endgroup$ – Maarten Bodewes Feb 1 '20 at 9:41
  • $\begingroup$ If you want the question reopened, please focus it on how cryptography should be used for your application. Notice that while there's a private key involved, it most likely won't be in the camera or device connected to It. I made an answer describing basic use of public-key crypto in such system, and what signature scheme to use. But there are many other important considerations. $\endgroup$ – fgrieu Feb 1 '20 at 12:12
  • $\begingroup$ @gmarais the easiest way would be to generate a random string, save it to a database, and send the QR encoded string to the user. Then the camera decodes the QR, connects to the database, checks for the record, and if it's there let the user in and delete the record. Simple. You do of course need to secure the database and all that. $\endgroup$ – Legorooj Feb 2 '20 at 8:53
  • $\begingroup$ Sure: you can use a signature (48 to 64 bytes minimal when using Elliptic Curve) or a MAC (12-16 bytes minimal for e.g. HMAC with partial hash as output). However, for the latter, if the symmetric key can be gained from the webcam, then everything falls down. Sizes are excluding the data itself. So you'd want a large 2D barcode, in other words. $\endgroup$ – Maarten Bodewes Feb 23 '20 at 23:53
2
$\begingroup$

The question is about using digital signature for signing access-control 2D-barcodes.

In the simplest form, some authority will generate and hold a private key, with the corresponding public key stored in the access control systems. A message with access rights (e.g. time interval and location for authorized access) will get signed by the authority using the private key, and encoded with (or in) the signature as a 2D-barcode. The access control system reads the 2D-barcode, thus obtaining the message and signature. It then verifies the signature against the message and the public key (that's the signature verification step of digital signature), and (only if the verification succeeds) allows access or not according to the access rights in the message.

It is cryptographically impossible to make an acceptable 2D-barcode without knowing the private key, other than by duplicating verbatim the content (message and matching signature) of a known one. In particular, any attempt at the alteration of a message will cause the signature verification to fail, and access won't be granted. This is obtained with a purely local verification process, as could be carried by almost any CPU.

The use of digital signature starts to make sense when the access control system is distributed: even reverse-engineering a device can't let one make a forged 2D-barcode that gets accepted. That's because the reverse-engineering can not get at the private key, for it's not there.


Among the most common signature standards usable (and routinely used) for this application are DSA, ECDSA, and EdDSA. The signature will add like 64 bytes for 128-bit security. A Raspberry Pi is powerful enough to perform an ECDSA or EdDSA signature verification step in a small fraction of a second.

If we want to make the size overhead incurred by signing as small as possible¹ (because the less information in a 2D-barcode, the easiest it is to read), there is also the short/original Schnorr signature scheme (48-byte for 128-bit security), but AFAIK it is not standardized². There also are BLS signature schemes, but good luck figuring out safe parameters, and I'm not even sure there's any gain.

Digital signature with message recovery could help a little: it embeds some of the messages in the signature. For short messages (below about 192 bytes) the best standard such schemes are the DLP based ones³, which achieve about the same size overhead as the aforementioned Schnorr scheme, with a better security justification and a standard to boast. For larger messages, an RSA/Rabin based scheme⁴ lowers the overhead to 34 bytes, and also greatly reduce the computational overhead of verifying a signature.


An obvious issue with the system is that signed 2D-barcode can still be duplicated, including captured as screenshots and sent electronically.


Notes:

¹ Of course the message size should be as low as possible. The best is using a compact encoding, or when that's not possible after-the-fact data compression to compensate for a lousy encoding. That's independent of crypto.

² Perhaps because simple security arguments for short Schnorr signature are not rigorous, and the latest developments are complex to the point of being hard to interpret.

³ Some standards are ISO/IEC 9796-3 and X9.92-1, see this for bibliography; beware of the patent minefield.

ISO/IEC 9796-2 scheme 3. It is not patent-encumbered AFAIK, but the standard itself is not legally available online for free.

$\endgroup$
2
  • $\begingroup$ @frgrieu this is exactly the thinking and information that I was hoping to get from someone with experience. Thank you so much for the response. However based on my edit, I wonder if you can hone in on the web-cam validation part. I will accept the answer regardless. Thanks $\endgroup$ – gmarais Feb 2 '20 at 5:52
  • $\begingroup$ @gmarais: I added material about the cryptographic aspect of the validation part, and indication that the standard ECDSA and EdDSA signature systems are usable on a Raspberry Pi without hitting performance (or other) issue. This is not the place for questions regarding the QR-Code reading itself, nor hardware/programming/systems design aspects. $\endgroup$ – fgrieu Feb 2 '20 at 8:28

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