Use of crypto on QR codes for access control 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.
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.