2

Let's say I have the following scenario. I have QR Code, Eddystone and/or NFC which contains IP address, with which, my client side application communicates. Let's say this IP address can vary from user to user (or let's say from entity to entity, it can be multiple users). Is there a way to protect these "data holders" (QR Code, Eddystone and/or NFC) against spoofing, i.e. an attacker won't be able to replace my QR code with his own, without my application noticing it?

Size limits

  • Eddystone - 17 bytes (all used :-/ )
  • QR Code - 4,296 characters (+- 60 used)
  • NFC - 125 bytes (+- 60 used)

Each IP address can have its own certificate which I do not know in advance. The server is mine but certificate can be replaced by admin which I do not control.

Improve this question
2
  • 2
    Do you control the application reading the QR/Edystone/NFC? That is, can you place a public key in them while assuring it is not tempered with?
    – A. Hersean
    Commented Mar 28, 2017 at 7:46
  • Yes, I control the application reading QR/Eddystone/NFC. It is a iOS/Android/Windows app.
    – Dávid Kaya
    Commented Mar 28, 2017 at 7:53

2 Answers 2

Reset to default
1

You can place a public key in your application to check the signature related to the IP address.

  • This signature could be placed in the QR/Edystone/NFC if there is enough room to place it (ECC certs can be small);
  • or you could host a service on this IP answering a challenge (the app provides a nonce, the service signs it, then the app checks the signature);
  • or you could provide a service over HTTPS on the IP address and check the HTTPS certificate with your public key.

You will also need a way to protect the private key. I can think of two solutions:

  • You can have a way to revoke the private keys deployed with the services on the IP address (for example by application update) in case a private key is abused or leaked.
  • The alternative is to provide the signature service by a web service you own so that you can ensure that the private key will not leak. This second scheme works like this: The application sends a challenge to the service, the service authenticates to your server and forward the challenge, your server sign the challenge then the service returns the signature to the application.
Improve this answer
3
  • So for QR code the ECC cert seems valid but for the rest I think a service answering a challenge seems more valid, right?
    – Dávid Kaya
    Commented Mar 28, 2017 at 8:30
  • Yes, exactly. It didn't have time to expend my answer because I would have been late for a meeting.
    – A. Hersean
    Commented Mar 28, 2017 at 8:44
  • I completed my answer to explain that you have to protect the private key(s).
    – A. Hersean
    Commented Mar 28, 2017 at 8:54
0

QR codes are just a way of getting text from your camera, so the user can send anything. Nothing would stop a user creating and scanning a QR code to input any text they wanted to.

Also QR codes quickly shrink from the 4,296 max characters you quoted when they use a different character encoding (if you need symbols) and want them easy to scan (maybe like 300 characters is more realistic depending on how you are scanning them).

This is a 2000 ish character QR code and I think its too small for most scanners to scan.

enter image description here

So there is some room for you to include some secret with the address, but then this QR would have to be kept hidden because anyone that reads it would be able to also see that secret. You could have the QR code contain a private random URL that allows a user to create a password, then have them use that password from then on.

https://softwareengineering.stackexchange.com/questions/325806/are-private-unguessable-urls-equivalent-to-password-based-authentication

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .