2

I need to create a system that allows a user to enter codes to charge an allowance. Embedded in this code should be the amount to charge the allowance.

The user would pay for a code which would then be generated on a server and then presented to the user. Then the user would enter the code into an embedded computer with no internet connection. The computer needs to decrypt the code to make sure the code is valid and also get the allowance out of the code.

To make this secure, I thought about doing this:

  • Have a counter on the server and client. Counter increases on the server when the user pays for a new code and also increases when the user types in a valid code. The counter would be contained in the payload of the code. This is to make sure the user can't enter the same code multiple times.
  • Store allowance, counter, customer ID in the payload, then encrypt it with RSA.
  • Each customer has their own key that is used to encrypt the payload. The key would be generated by a random number provided by the server and entered by the technician that installs the device. That way, the technician doesn't have to enter the full key (which can be long and thus prone to errors)
  • When the user enters a key it is checked for validity by decrypting it first, then comparing the customer ID of the payload with the configured ID and comparing the counter variable of the payload with the internal counter. If those checks pass, the allowance is increased by the amount specified in the payload.

Please try to think of ways that would allow you to crack this system with the goal of adding allowance without having paid for a code (thus, generating a valid code on your own).

Physical access to the device (such as flashing it) is not an issue.

10
  • how do you deal with the case where someone purchases a code (counter increases), does not use it, and then purchases again (counter increases again)? - the counters on the server and the embedded device will not match.
    – WoJ
    Apr 11 '15 at 12:06
  • also: you would like to store the allowance, counter and ID (all encrypted) and still have a practical (short) key to be keyed in by the customer?
    – WoJ
    Apr 11 '15 at 12:08
  • In the first case the customer would be out of luck, the previous codes could be provided to the customer in case he forgot to enter them.
    – narrowtux
    Apr 12 '15 at 10:52
  • I would only store the allowance and a hash in the key. The hash would consist of counter, ID and allowance all hashed together. Because those are known by the embedded device, it is enough to just hash everything together.
    – narrowtux
    Apr 12 '15 at 10:53
  • So the key must be reversible and since it has to be of a reasonable length (6 digits being some norm), which is about 14 bits. The hash will therefore be short and thus prone to collisions.
    – WoJ
    Apr 12 '15 at 12:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.