I have been reading a lot about QR codes and how the code itself can lead to serious security risks. But one thing that I did not come across is the following.
In the following scenario:
I have a QR code which displays some of my data lets say:
- Name
- Address
- A list of things I'm allowed to do
And I scans my code to see its contents, add some stuf to the list of things that I'm allowed to do and reprint the QR code.
The next day I come to work scan my code and am allowed to do the extra thing I added to the code.
My question is: how can I stop this scenario from happening.
Note that it is not possible to check if my data is consistent with DataBase data.
More info:
I'm using phonegap in combination with Sencha Touch 2 to create my QR code reader.
It is an Android application designed only for Android 4.0 devices.
The QR codes are provided once a year.
If someone would scan his QR code of last year it would not work.
Note that: in theory if he'd change the date on the code that he would be able to get in, this is exactly what I'm trying to block.
Some employees have access to the application which reads the code.
The application does not have any way to verify the data on the QR code, so it has to be something using only the data on the QR code.
Sign the QR code data with a private key. The readers will need the public key to verify the QR code, but the public key need not be kept secret.
If you use an ECDSA Secp256K1 key, the signature will only add about 68 bytes to the QR code data.
Include the date of issue in the QR code as well. The reader will need a local clock to check that the QR code isn't too old. If the reader doesn't have a clock, you can at least keep track of the newest valid code you have ever seen. Any code issued more than a year before that date is definitely invalid.
Both BouncyCastle and OpenSSL contain implementations of the code you'll need.
If it's okay for the code readers/verifiers to contain all the information needed to generate a fake QR code, then you can use HMAC instead of ECDSA. That's simpler and an HMAC can be as little as 16-bytes and still do the job.
This is all easier to reason about if you realize that QR codes simply encode plain text. If your scheme is insecure if you were just dealing in text files or text printed on a wall -- QR codes don't change that. There is no security mechanism in a QR code.
Turning it around -- whatever means are available to secure your scheme, outside of QR codes, can probably be applied here. What you are looking for is a digital signature, the same sort of public/private key scheme used to prove that SSL certs are valid and that emails are from the claimed sender. The data your users need to supply must be signed by you to know they haven't tampered with it.
You can put anything you want in a QR code, including Base-64 encoded bytes representing a signed document. No reader will know what to do with it; you'd have to write a custom app that scans and then knows to decode it and act accordingly.
I do think it's by far easier to conceive a scheme that involves directing a user to a web site you control securely.
If you can't do any comparison, I don't know how you can secure. Maybe all information may be hashed with a secret key? then you can't reprint your code without the key
QR code is not more than encode a text into 2D image. So it is not QR code's responsibility to encrypt. But you can always generate a simple verification code, e.g. MD5 or Base64 that created from an unique id plus the date. Depends on what kind protection you want, you can either reject or disable the code comes with wrong verification code.
Related
If we want to provide more security to the consumer for authenticating their product and by using QR code scans, what techniques we can used for making that QR code copy proof and non-duplicate?
You need to consider the digital image of the QR Code before printing. You can add a secure graphic or copy detection pattern (see https://en.wikipedia.org/wiki/Secure_graphic) into the QR Code (pay attention to the error-correction level of the QR Code versus the space you use). Once printed, the secure graphic will irreversibly loose information, and if someone tries to make a copy of it, there will be an additional information loss. As the secure graphic will a lower amount of information in the copy than in an original print, you can use that that to discriminate originals from counterfeits. An app is needed to analyse the image of the secure graphic in real-time when you scan the QR Code. See example of this is done with Scantrust, and there is a developer portal to support you in integrating in your app.
Note that there are other techniques based on digital watermarking, but they are easier to hack given that digital watermarks need to respect an imperceptibility constraint and the usable signal is much weaker.
Short answer: Think of a QR code as a compressed block of plain text. You can sign it for non purposes of authenticity and non-repudiation, or encrypt it for secrecy, but you can't magically stop it from being copied and reproduced as a whole.
Longer answer:
I think what you are asking is whether it is possible to add some kind of identification or signature to a QR-code? If so, then the answer is yes - you can put pretty much whatever you like in there, so long as you keep it within the storage limits for the input mode you are using (wikipedia).
This means you could for instance add a digital signature to it, if you wanted to.
Example:
Say you wanted to encode the text "Public Message" into a QR-code, and leave it for someone to read. To prove that the message is really from you, you could use PKI and sign it with your secret key - that is, append an encrypted version of "Public Message" to the text. Decryption of that last part will then only be possible using your public key, and doing so will prove that it was encrypted using your private key, which indicates that the message must have come from you (or someone with access to your private key).
Now if someone tried to copy your QR code, and change it's message to the slightly more kinky "Public Massage" instead, a recipient could check the attached signature and see that there is a mismatch, and so conclude that the code is invalid (i.e. has been manipulated).
If a message has a valid signature, this will prove that you are the author, and that the message has not been manipulated. You still won't be able to stop anyone from copying the code and reproducing it as a whole though.
Alternative: Encryption using a public key?
If you wanted to post a secret message intended for a specific recipient, you could encrypt it using that person's public key. In that case you could share the QR-code freely, and only the recipient would be able to read it's contents; anyone else would just see garbled text.
Alternative 2: One-Time Pass (OTP)?
If you want to make sure a QR-code is used only once, you could have it include a unique ID, and implement server side logic that accepts that code, checks it's validity, and invalidates it after a single use. You can also limit the time for which such a QR-Code is valid. This is how website logins using QR-codes work.
I am using qr code for anti-counterfeiting solutions.
But the problem with Qr code is that anyone can easily create a copy of my qr code or anyone can easily read the qr code with "qr code reader" mobile application and can create the same qr code like mine.
if my application reads this fake qr codes then it shows the "valid product" message instead of "fake product" message.
So i just want to know that if there is any way to protect qr code from being copied or can i make qr code which can be readable by my mobile app only and not by any other "qr code reader" application.
There is no way to accomplish this.
QR is merely a format to store information. It does not provide confidentiality in any way.
You are looking at a systemic issue. For fraud detection, you want to use a technology where replication is hard. QR on the other hand is designed to make replication easy. QR codes are redundant and can still be read if a rather large portion of them is lost. QR codes are therefore - even on a basic level - the exact thing you don't want to use to establish the authenticity of an object.
There are different ways to do that: you can insert a copy-sensitive digital image at the center of the QR Code (called copy detection pattern or secure graphic). The secure graphic will naturally degrade and lose information if a counterfeiter tries to copy it, due to uncontrollable effects of dot gain and ink smearing. You can also embed a digital watermark by inserting small modifications that are hard to notice into the QR Code cells. These are generally easier to counterfeit though. A third approach consists in installing a high resolution camera on the printing or production line, and capture the small print variations of each printed QR Code.
The common point of these 3 approaches is that you need a specific app on your smartphone to make the authentication. If a consumer makes a normal scan of the QR Code (e.g. with the iPhone camera app), he can on land a page that will instruct her to download this app. Of course the brand owner needs to communicate to his customer or user base on how to authenticate its products. Good example on how this is done can be seen with Scantrust secure QR Code here:
https://www.dupont.com/water/resources/anti-counterfeiting-solutions.html
https://www.nexans.com/business/Telecom---Data/Local-area-network/lan_systems_blog/lan_systems_blog_posts/20.2019-Scantrust.html
There are apps that do what you are looking for. Hologram, marks etc are a waste of money except maybe for preventing some new unscrupulous elements.
Even if the app is copied, Google won't allow apps of the same name which automatically grants it a first level protection. Hence this will work.
The other option is to create a two step process wherein one is a unique number via qr or bar code and the other is linked through ones own proprietary identification system. Other can be qr, bar too or even a scratch code. Any app can be used as effect is the same.
Only difference is that the first one is easy to use.
The condition that only your app can scan your QR can be achieved by encrypting the text you want to convert into QR before converting it using any encryption algorithm and key and again after the QR code is scanned using the same algorithm to decrypt the encrypted text obtained .In this way if any other scanner scans it it will not perform the final algorithm you did to convert it into original text and hence your QR will be secure.
However, copying of QR can be done .
Some companies pair a serialised QR code with a PIN code. It can be copied but the platform will detect multiple scans from different devices and locations and can send an alert.
There are also screen solutions as mentioned such as this.
https://ypbsystems.com/en/protect-code-anti-copy-code/
Here's a (simplified) example of my situation.
The user plays a game and gets a high-score of 200 points. I award high-scores with money, i.e. 1€/10 points. The user will print a "receipt" which says he won €20, then he gives it to me, I make sure the receipt is authentic and has never been used before and I hand him his prize.
My "issue" is in the bold part, obviously. I should be able to validate the "receipt" by hand, but solutions with other offline methods are welcome too (i.e. small .jar applications for my phone). Also, it must be hard to make fake receipts.
Here's what I thought so far, their pros and their cons.
Hashing using common algorithms i.e. SHA512
Pros: can easily be validated by mobile devices, has a strong resistance to faking it with higher values (if a context-depending salt is used, i.e. the username).
Cons: can be used multiple times, cannot be validated by hand.
Self-made hash algorithms
Pros: can be validated by hand.
Cons: might be broken easily, can be used multiple times.
Certificate codes: I have a list of codes in two databases, one on the server and one on my phone. Every time a receipt is printed, one of these is printed in it and set as "used" into the database. On my phone, I do the same: I check if the code is in the database and hasn't been used yet, then set as "used" in the database.
Pros: doesn't allow for multiple uses of the same code.
Cons: it's extremely easy to fake a receipt, cannot be validated by hand.
This sounds like a classic use case for an Hash-based message authentication code (HMAC) algorithm. Since your idea of "by hand" is "using a smartphone", not "with pecil, paper, and mind", you can compute the hash and print it on the receipt, and then validate it on the phone or the back-end server.
The "missing point" is to use more systems at once so that, together, they work in the needed way. In this case, we can use HMAC for authenticating the message and a list of "certificate codes" to make sure one doesn't use the same receipt over and over.
Another idea might also be to hash the time when the receipt is outputted to the client and print it on the receipt. When someone shows you the code on the receipt, you make sure that hash hasn't been used yet and that it's valid (i.e. the message produces that hash), then you add it to the list of "used hashes".
Thanks to #RossPatterson for suggesting HMAC.
As most of you know, email is very insecure. Even with a SSL-secured connection between the client and the server that sends an email, the message itself will be in plaintext while it hops around nodes across the Internet, leaving it vulnerable to eavesdropping.
Another consideration is the sender might not want the message to be readable - even by the intended recipient - after some time or after it's been read once. There are a number of reasons for this; for example, the message might contain sensitive information that can be requested through a subpoena.
A solution (the most common one, I believe) is to send the message to a trusted third party, and a link to the that message to the recipient, who then reads this message from the 3rd party. Or the sender can send an encrypted message (using symmetric encryption) to the recipient and send the key to the 3rd party.
Either way, there is a fundamental problem with this approach: if this 3rd party is compromised, all your efforts will be rendered useless. For a real example of an incident like this, refer to debacles involving Crypto AG colluding with the NSA
Another solution I've seen was Vanish, which encrypts the message, splits the key into pieces and "stores" the pieces in a DHT (namely the Vuze DHT). These values can be easily and somewhat reliably accessed by simply looking the hashes up (the hashes are sent with the message). After 8 hours, these values are lost, and even the intended recipient won't be able to read the message. With millions of nodes, there is no single point of failure. But this was also broken by mounting a Sybil attack on the DHT (refer to the Vanish webpage for more information).
So does anyone have ideas on how to accomplish this?
EDIT: I guess I didn't make myself clear. The main concern is not the recipient intentionally keeping the message (I know this one is impossible to control), but the message being available somewhere.
For example, in the Enron debacle, the courts subpoenaed them for all the email on their servers. Had the messages been encrypted and the keys lost forever, it would do them no good to have encrypted messages and no keys.
(Disclaimer: I didn't read details on Vanish or the Sybil attack, which may be similar the what comes below)
First of all: Email messages are generally quite small, esp. compared to a 50 mb youtube vid you can download 10 times a day or more. On this I base the assumption that storage and bandwidth are not a real concern here.
Encryption, in the common sense of the word, introduces parts into your system that are hard to understand, and therefore hard to verify. (think of the typical openssl magic everybody just performs, but 99% of people really understand; if some step X on a HOWTO would say "now go to site X and upload *.cer *.pem and *.csr" to verify steps 1 to X-1, I guess 1 in 10 people will just do it)
Combining the two observations, my suggestion for a safe(*) and understandable system:
Say you have a message M of 10 kb. Take N times 10 kb from /dev/(u)random, possibly from hardware based random sources, call it K(0) to K(N-1). Use a simple xor operation to calculate
K(N) = M^K(0)^K(1)^...^K(N-1)
now, by definition
M = K(0)^K(1)^...^K(N)
i.e. to understand the message you need all K's. Store the K's with N different (more or less trusted) parties, using whatever protocol you fancy, under random 256 bit names.
To send a message, send the N links to the K's.
To destroy a message, make sure at least one K is deleted.
(*) as regards to safety, the system will be as safe as the safest party hosting a K.
Don't take a fixed N, don't have a fixed number of K's on a single node per message (i.e. put 0-10 K's of one message on the same node) to make a brute force attack hard, even for those who have access to all nodes storing keys.
NB: this of course would require some additional software, as would any solution, but the complexity of the plugins/tools required is minimal.
The self-destructing part is really hard, because the user can take a screenshot and store the screenshot unencrypted on his disk, etc. So I think you have no chance to enforce that (there will always be a way, even if you link to an external page). But you can however simply ask the recipient to delete it afterwards.
The encryption is on the other hand is not a problem at all. I wouldn't rely on TLS because even when the sender and the client are using it, there might other mail relies who don't and they might store the message as plain text. So, the best way would be to simple encrypt it explicitly.
For example I am using GnuPG for (nearly) all mails I write, which is based on some asymmetric encryption methods. Here I know that only those I have given explicitly permission can read the mail, and since there are plug-ins available for nearly all popular MUAs, I'ts also quite easy for the recipient to read the mail. (So, nobody has to encrypt the mail manually and might forgot to delete the unencrypted message from the disk...). And it's also possible to revoke the keys, if someone has stolen your private key for example (which is normally encrypted anyway).
In my opinion, GnuPG (or alternatively S/MIME) should be used all the time, because that would also help to make spamming more difficult. But thats probably just one of my silly dreams ;)
There are so many different ways of going about it which all have good and bad points, you just need to choose the right one for your scenario. I think the best way of going about it is the same as your 'most common' solution. The trusted third party should really be you - you create a website of your own, with your own authentication being used. Then you don't have to give your hypothetical keys to anyone.
You could use a two way certification method by creating your own client software which can read the emails, with the user having their own certificate. Better be safe than sorry!
If the recipient knows that the message might become unreadable later and they find the message valuable their intention will be to preserve it, so they will try to subvert the protection.
Once someone has seen the message unencrypted - which means in any perceivable form - either as text or as screen image - they can store it somehow and do whatever they want. All the measures with keys and so one only make dealing with the message inconvenient, but don't prevent extracting the text.
One of the ways could be to use self-destructing hardware as in Mission Impossible - the hardware would display the message and then destroy it, but as you can see it is inconvenient as well - the recipient would need to understand the message from viewing it only once which is not always possible.
So given the fact that the recipient might be interested in subverting the protection and the protection can be subverted the whole idea will likely not work as intended but surely will make dealing with messages less convenient.
If HTML format is used, you can have the message reference assets that you can remove at a later date. If the message is open at a later date, the user should see broken links..
If your environment allows for it, you could use the trusted boot environment to ensure that a trusted boot loader has been used to boot a trusted kernel, which could verify that a trusted email client is being used to receive the email before sending it. See remote attestation.
It would be the responsibility of the email client to responsibly delete the email in a timely fashion -- perhaps relying on in-memory store only and requesting memory that cannot be swapped to disk.
Of course, bugs can happen in programs, but this mechanism could ensure there is no intentional pathway towards storing the email.
The problem, as you describe it, does sound very close to the problem addressed by Vanish, and discussed at length in their paper. As you note, their first implementation was found to have a weakness, but it appears to be an implementation weakness rather than a fundamental one, and is therefore probably fixable.
Vanish is also sufficiently well-known that it's an obvious target for attack, which means that weaknesses in it have a good chance of being found, publicised, and fixed.
Your best option, therefore, is probably to wait for Vanish version 2. With security software, rolling your own is almost never a good idea, and getting something from an established academic security group is a lot safer.
IMO, the most practical solution for the situation is using Pidgin IM client with Off-the-Record (no-logging) and pidgin-encrypt (end-to-end assymetric-encryption) together. The message will be destroyed as soon as the chat window is closed, and in emergency, you can just unplug the computer to close the chat window.
I have a system which is a CRM of sorts, it essentially manages customers claims that they have been mis-sold insurance.
This system is expected to handle a fairly high volume of claims and several call center desks have been enlisted to that effect.
The general workflow of the system is; call center recieves a claim and enters it onto the system submitting it for approval, head office check the details of the claim approving it if it meets the neccasary criteria. On approval a one time only secure URL is emailed to the customer which they can then visit to view the 5 generated documents which contain the details of their claim. Each document requires at least one signature (from the claimant and their partner if appropriate), our client has specified that only one of these documents requires a proper signature (legally) which must be received by snail mail from the customer. The other documents they would like digitally signed (to speed up the claim process, simplify it for the claimant, cut down on paper, postage costs, etcetera).
In doing this i have to take into account that the majority of claimants likely have very little technical knowledge and so must keep this process as simple (user friendly) as possible.
As mentioned each claimant is sent a 'one time only' URL which they can use to login to sign the document, when they have viewed the documents they are given the option to sign; at which point they are asked for a password, this is then hashed (along with some personal data) and added to the footer of each document page. A visual signature is generated with nice signature like font and added to the relevant signature boxes along with the disclaimer "Please accept the electronic signature above as acceptance of your terms of business and instructions to proceed".
They can then download the generated PDF for their own records.
The system commissioner seems to think this is acceptable, howver I am not sure and would like to know if this is the right way to go about it, and if not, is there a better way bearing in mind i must keep this as simple as possible.
Thanks.
This is an incorrect use of a message digest function. The resulting hash of a secret be given to a user (or attacker...), even if it is salted. Hashes are useful for password storage because it adds an extra complexity that the attacker must overcome. Adding personal data can make the hash more difficult to break, but if an attacker had a lot of computing resources they could make a lot of guesses and then obtain someones personal information as well. A good way to think of it as that a resulting hash will leak information about the original message if the attacker can make enough guesses.
There are 2 ways you can go about doing this. The first method is something i just made up that I like. So the user logs in with this 1 time URL and then is presented with a draw box, where by using their mouse courser they sign their name. This image is then appended with a secret that only you know (Cryptographic Nonce) to create the Key "k" in an MAC, the Message "m" would be the entire document that is to be signed. This is a good way to tie together these important pieces of information using cryptography. This could also be used to prove that the signed document wasn't tampered with. However, the resulting hash which is being used as authentication code could only be verified and created if you have the secret that you provide. This would come into play if you need to prove the authenticity in a court room.
A more common approach is to use PDF's Built-In digital signatures. I have used this first hand in contract agreements. If you do go this route and a case where to make it to court it would likely be easier to defend your self in saying that a user signed the document. There are however some serious problems with this approach. Most important this is very difficult for non-tech savvy users, although it maybe okay to automatilly singing them with Adobe's PDF SDK. A draw box could still be used, and the image of the clients name could be written to the document prior to the application of the digital signature. Key distribution is going to be a pain in the ass. Its costs money because you have to pay for to use a PKI provided by someone like VeriSign (* insert vomit here *). Further more a PKI is defending against attacks that are not reliant to your needs. Although going this route means that anyone should be able to verify the authenticity of this document.
You just want to prove that a document is signed and wast tampered with. Given the nature of this problem I would make sure a lawyer looks over your proposed solution.
Hey there, I know this answer is a "bit" late, but hopefully it'll help others who read it as well. I also work in the insurance field and understand the importance of security when signing documents. I am aware of a few services available for digital signatures, here I linked to the one we're working with at our NYC office. It's great cause it really solves many issues and we don't need to print documents out any more or be worried about security. In any case, I hope this helps. :)
I would generate an image(barcode or barcode-matrix), like a checksum that is generated with some nasty algorithm on the server (RSA sounds good to me) that could be checked later if needed. Don't use a signature font, that's just tacky.