QR codes can be considered as encrypted messages; after all no human eye is able to decode it. We need an extension -in a form of a mobile device – to read them.
What about encrypted QR codes for mobile devices? What if a QR code is there in public but nobody except a group of people (municipality workers for example) can decode it with their phones? Is it possible? Who may need encrypted QR codes and how hard is it to crack the encryption method?
Truth is that encrypted QR codes exist already. Few readers provide it as a gimmick – QR Droid on Android and QuickMark on the web are few examples. The encryption system in these QR codes is relatively easy to break since the QR code itself is readable, you can see the encrypted message and the encryption key is relatively short in contrast to what is suggested in this post.
Who may need encrypted QR codes?
One of the first applications that come to mind is to use encrypted QR codes on passports, driver license and other identification or even loyalty cards. Assume that every citizen will have a hidden Id residing in a secured governmental database. This hidden Id points in the database to an overt Id printed on the passport together with a name and other details. The QR code encrypts a URL and the hidden Id. An inspector scanning the QR code will get from the secured database all data linked with the hidden Id including name, birth date address and more. All the inspector has to do is compare the received data to that on the passport. With today technology even the image that should be on the passport can be sent for comparison.
Why encrypted QR codes? The authorities might not want anyone (including the inspectors) to know how are the hidden IDs like. The reason for not revealing the content of the QR codes is to minimize the chance that hackers may find how they were generated and create new Id’s.
Other areas for encrypted QR codes may be banking, hospitals, health care services and enterprise data on merchandise that should be read only by workers – not intended for general public.
Why encryption works so good with QR codes?
QR codes are composed from 3 different chunks of data. One chunk is the structural data which consists from the finder patterns, guide patterns, timelines and format info, such mask and error correction used in current QR code. Another chunk of data is the original data encoded in the QR code while the third chunk of data is the Reed-Solomon data which is derived from the original data and serves for correcting errors that may be found in the QR code or as a result of the decoding procedure.
If you happen to encrypt the original data and/or the error correction data, the QR code will simply not decode. This will happen because the original data and error correction data will not match, resulting in too many errors. All readers will fail to decode the QR code and you won’t have any clue to what is in it. This is very different from conventional encryption methods, where the encrypted data is visible.
Here is an example of an encrypted QR code. You can try reading it and see that nothing happens.
In order to see what the encrypted data looks like, you will need special software that will ignore the inconsistencies with the error correction data chunk. In that case you are totally helpless against purposeful errors that may be planted in original data region which normally would resolve by the Reed-Solomon error correction mechanism. With a false encrypted data you have a very small chance if at all to find the real message hidden behind.
Money transactions example
Assume that a banking app permits you to make transactions from your account in the following way. You type in the app the sum of money you want to pay and a QR code containing the transaction Id, current time, current location and the sum of money is displayed on your mobile screen. The first person that scans this code through his banking mobile app will have the sum of money transferred into his account. This will happen after the bank will check that such a transaction ID is indeed pending and was issued in a range of say two minutes from decoding time. Note that the transaction ID is never displayed to any user and the data transfer itself take place under a secured protocol such as TLS. The user will get a text message asking him to confirm the transaction, together with the sum of money and the identity of the transaction target.
Obviously if the QR code is not encrypted, the transaction ID generator may be emulated and false QR codes may be generated concurrently with real ones generated by the bank, ending with some transactions going to the wrong accounts. No doubt that a bank will want these kind of QR codes to be encrypted so that no reader will be able to see the transactions IDs.
The security level of such a system is very high although simple encryption systems may be involved. The amount of errors deliberately hidden in the message and their random locations will turn that system to be extremely hard to break.
How to encrypt QR codes
All ways described here will use symmetrical keys, meaning that the same key used for encryption is the key used for decryption. The length of the encryption key may be at the length of both the original and error correction data. This key can be composed from a sentence or a series of non meaningful characters, and encryption is done by performing a bitwise XOR operation on both data chunks using this sequence. Redo the same operation on the encrypted message and you will get back the original message.
Now after encryption, choose a number of random locations in data (no more than half of the permitted errors by the error correction level) and change the bytes in these locations randomly.
After decrypting the message with a knowledgeable reader (that knows the secret key), the Reed-Solomon algorithm will correct the wrongly decrypted codewords and the correct message will be formed.
For a version 2 QR code that contains 44 codewords a key of length 44*8=352 bits is equivalent to a number with 106 digits. For comparison, SSL keys with 128 digits are considered to be unbreakable today. A version 3 QR code with 70 codewords may use a key of 70 bytes equivalent to a number with 168 digits.
A harder encryption is achieved by making some errors in random places like before, this time before encryption. After that shuffling the bits of both original and error correction data in a certain order and applying to this a symmetrical key, just like before. To decrypt this you will first need to apply the symmetrical key, after that reshuffle the bits to their original position, then apply the Reed-Solomon algorithm to correct the planted errors in the message.
Two factors make this encryption method very hard to break. One is the long encryption key (in the length of original and EC data). The other lies within the fact that the Reed-Solomon data is encrypted with a different set of bits than those used on the data. Many wrong keys may create new ‘decrypted’ error correction data that will agree with the wrongly ‘decrypted’ original data within a permitted number of errors. In this way millions of possible original data streams will be generated without any indication to tell who the original is.
I am quite sure that other variations for encrypting QR codes exist and will be suggested and used in time to come. For example the QR code above was created by choosing a rectangle in the QR code and simply inverting its content.
Encrypted QR codes surely have a place and functionality in our society, the only question is where and when they will first appear in daily usage.