how to avoid replay attack without using time-stamp

Question

I am developing a mobile application which sends some encrypted data to a Bluetooth device and this Bluetooth device sends the data to server. My question is that in this case how can I prevent replay attacks. Someone might use a fake Bluetooth device to get the signals and send them to the server.

• The mobile application works in offline mode and has no connection to server. So using a synchronized nonce or counter doesn't help.

• I can not also use time-stamp to narrow the attack window because mobile phone's time might not be correct (synchronized with a time server).

• Communication between my mobile application and Bluetooth device is one-way and my mobile application can only send data to the device.

Meng

You want to stop replay attacks between the bluetooth device and the server, and you already trust the bluetooth connection between the device and server? – Egwan

@Marcus I do not trust the bluetooth connection. someone may use a fake device to get data from users (just like using a fake POS terminal to steals card data) and after capturing data inform the user that transaction has been failed but send captured data later. i want to avoid replay/man-in-the-middle attacks. User's data in well encrypted and can not be tampered but one might capture them. – Meng

Answer 1

One way to do this would be to use a counter, but allow it to skip a large number of steps. For example if the last counter value you've seen from phone A is 123 and you get something with a counter value of 156 then you accept it, but anything outside the range of [124, 1000123] you discard (1000000 being completely arbitrary and dependent on your use case).

This would prevent a replay attack, but you do have to take care that the transmissions aren't malleable or it would be trivial to forge counter numbers. This could be accomplished by having a secret per device MAC key (which would only be possible if the server and phone communicate beforehand).

It's worth stating that it would be good for the transactions to be authenticated (only phone A has the capability to generate a message saying it's from phone A) or an attacker could move up the counter very quickly and do a denial of service on phone A. However, from the way you phrased the question it sounds like it's something you've already dealt with.

Pinkster

What if someone gets transaction 123 and does not send it to server. in this case my mobile application assumes that the transaction is failed and can not inform the server to invalidate the used counter (123). this way attacker may send the captured message later. – Meng

@Meng I see. I misunderstood because I was thinking of a strict replay (instead of just a delay). Unfortunately, I don't see any way to avoid this problem in this case. If you can't trust the phone's clock, I don't think it's possible put any bound on 1-way latency to the server (which is what you're asking, essentially). – Pinkster