8

After accepting an answer to my previous question, I am beginning to have doubts.

I want to updating pricing information in vending machines by inserting an SD card with new pricing.

I have to encrypt the file, because anyone who can change it can get one cent drinks. The people who stock the machines would exchange the cards when there is new pricing. They are on minimum wage and generally not renowned hackers, but could, I suppose, pass a card on.

The SD card would be behind a locked casing and anyone who opened that could just clean out the cash box & would probably be unlikely to swipe the card.

The code in the machines is rarely changed, but there will be an option for firmware upgrade (via the same SD card), so I suppose I could update keys that way if they become compromised & store them in NonVolatile memory.

Each machine has a unique CPU Id and also is aware of its model type “drinks, candy, etc” where all machines of the same type have the same pricing structure – if that is of any use for seeding, etc

Question: what’s a good algorithm to use when I am writing in Delphi on Windows and reading in C on a low memory (128kB) embedded system (the file is likely ot be of the order of 512 to 1,024 bytes)? How to deal with keys in this scenario? Hard code into the s/w?

Any other comments or suggestions?

Community
  • 1
Mawg says reinstate Monica
  • 1,368
  • 2
  • 13
  • 26
  • 1
    How many price updates do you assume there'll be in a year (or between each firmware upgrade), and how much storage is available in the vending machine? I'm thinking One-Time Pad! – Henning Klevjer Nov 07 '12 at 07:41
  • +1 @HenningKlevjer I don't expect more than 2 or 3 updates per year. teh f/w is new & likely to be buggy at first so an inital slew of f/w upates trailing off to none within the frist year ... ? – Mawg says reinstate Monica Nov 07 '12 at 07:59
  • 1
    Would you care to elaborate on that "one time pad"? – Mawg says reinstate Monica Jun 07 '19 at 06:25
  • 1
    Hi @Mawg, it seems like little to respond after 6.5 years when you did in 18 seconds. My idea at the time, I guess, was preloading the system in the vending machine with a "one-time pad" consisting of a random string of bytes that is long enough for covering all the information you need to protect (for all updates, say each plain text string is 1 kB and you want to support 100 transmissions in a lifetime, that's 100 kB). You need a copy of the OTP on both sides, and you encrypt data by "consuming" the byte string, and using each byte for an XOR operation with each byte of the data to protect. – Henning Klevjer Jun 08 '19 at 07:32
  • 1
    Finally, the XOR-protected data is XOR-ed again after being transferred to the machine, where the only other copy of the OTP resides. – Henning Klevjer Jun 08 '19 at 07:34
  • Thanks (and upvotes) for that, Henning :-) – Mawg says reinstate Monica Jun 08 '19 at 08:35

1 Answers1

7

I have to encrypt the file, because anyone who can change it can get one cent drinks.

Encryption is used for confidentiality - to prevent unauthorized parties from reading the file. Since your goal is to prevent people from changing the file what you need is a digital signature.

There are two kinds of digital signatures: asymmetric signatures and symmetric signatures.

When using a symmetric signature the side checking the signature needs to have the same secret key used by the signer. In your case this means that the secret key needs to reside in the machine's firmware which sits on the same SD card as the file your trying to protect. Not very secure.

When using an asymmetric signature the side checking the signature (i.e. the vending machine) has a public key and doesn't have the private key needed to sign a file, which solves the above problem.

But this is still trivial for an attacker to break. Since the firmware if on the SD card, and we're assuming the attacker can modify the SD card, the attacker can simply modify the firmware so that it doesn't check the signature.

The ideal solution for this would be if the vending machine's hardware (e.g. BIOS) would validate a signature on the firmware before loading it. There are embedded devices in the world that do this (e.g. game consoles, mobile device) but vending machines are not one of them.

Given the lack of a firmware signature check there is no way to achieve real security for this. The best you could do is obfuscate the code so that it would be more difficult for a hacker to reverse engineer and modify.

If you have good reason to believe that attackers cannot modify the firmware then all you need to do is sign the file using RSA with PKCS#1 padding (which is good enough for your needs). Delphi code for this can be found in TurboPower LockBox; OpenSSL has C code.

Having said all that, there doesn't seem to be much of a threat here. If an operator lowers the price for a specific machine then you should be able to identify the discrepancy for that machine between the amount of drinks that were put into the machine and the amount of money that you got out of it. This is something you need to check anyway to ensure that the machine operators aren't simply taking money (which is clearly a more severe threat than stealing a few drinks).

David Wachtfogel
  • 5,512
  • 21
  • 35
  • +1 @DavidWachtfogel I take your point about wanting to prevent tampering, not reading - but can't I do both? I think I didn't explain well - the firmware is on a microprocessor in the machine and runs from there. If I need to load new f/w then, yes, it comes from the SD card, but is an encrypted exe & hard to hack (I hope). I take your point about auditing & there will be a *lot* ofback end s/w associated with the sales databse. Thansk for your feedback. What do you suggest, in concrete terms? – Mawg says reinstate Monica Nov 07 '12 at 08:02
  • 1
    Seeing as the last question from @Mawg asks for "just good enough" and "security through obscurity", I'd assume that an attacker was *not* able to modify firmware. – Henning Klevjer Nov 07 '12 at 08:36
  • 2
    If you assume that the attacker cannot modify the firmware then all you need to do is sign the file using RSA with PKCS#1 padding (which is good enough for your needs). http://sourceforge.net/projects/tplockbox/ has Delphi code for this; OpenSSL has C code. Since the information in the file (prices) is not secret there's no reason to encrypt the file. – David Wachtfogel Nov 07 '12 at 09:13
  • 1
    Don't be so sure about attackers not modding your firmware. Vending machines (and similar devices) can often be pwned via buffer overflows on all sorts of easily accessible interfaces. – Polynomial Nov 07 '12 at 10:34
  • +1 @Polynomial You intrigued me so much that I asked a new quesstion. Please see http://security.stackexchange.com/questions/23755/how-can-vending-machines-be-hacked-and-how-can-i-prevent-it – Mawg says reinstate Monica Nov 08 '12 at 02:07