View previous topic :: View next topic |
Author |
Message |
jojos
Joined: 30 Apr 2007 Posts: 64
|
Protect smartcards(or phonecards) eeprom |
Posted: Tue Nov 25, 2008 5:34 am |
|
|
Hello i am working on a project that will measure water flow and substract user units as the flow goes on.Each user will have the opportunity to load units to their devices through an eeprom that is on a smartcard (like phonecards e.t.c.).The card aslo will be able to be reloaded with units by the company that owns the water supply.I face now the problem of how can i protect the eeprom from someone to load units without paying.First of all is it possible someone to load units(change values of the cards eeprom) and if yes is there any eay that i can protect this.Thank you
P.S. Also i could use some eeprom chip like Microchip's 24lc16 and make a small boaed that could inserted to the main device and load the units.Is there way to protect that chip? |
|
|
crystal_lattice
Joined: 13 Jun 2006 Posts: 164
|
|
Posted: Wed Nov 26, 2008 12:14 am |
|
|
Yes, there is a solution, one word: encryption.
Embed a serial number on each device, use the same serial number on the card. Encrypt the value of credits with a combination of this serial and some secret value (also known as salt)
When the unit reads the credit value it decrypts it with a combination of it's serial and the salt value. Now perform a checksum and confirm that the decryption was successful. Implementing a serial number prevents the user from using the card on another system or from cloning the eeprom card.
If the user changes the serial number on the card before it is recharged, the credits placed on it will only work for the system matching the serial number, thus nothing was gained. You don't have to store the serial number in the eeprom on the card you could even print it on the card as a human readable number. This does make it prone to user error when recharging though.
Nearly forgot to add: look at the TEA and XTEA encryption algoritms found on the net and elsewhere on the forum. |
|
|
crystal_lattice
Joined: 13 Jun 2006 Posts: 164
|
|
Posted: Wed Nov 26, 2008 12:27 am |
|
|
On second thoughts, you will also have to include some means of keeping track of used recharge values. You could implement a sequential number and appended it to each recharge value, thus when the unit recharges, it stores this number and prevents the user from cloning his _own_ cards. Unfortunately, this will require some amount of non volatile memory on each unit. |
|
|
crystal_lattice
Joined: 13 Jun 2006 Posts: 164
|
|
Posted: Wed Nov 26, 2008 12:31 am |
|
|
I didn't see you post script, you could use any means of transporting your credits if they are encrypted, you could even have a hexadecimal keypad on your unit and have the user punch in the number from a paper slip printed by the vendor....saves you even more money... |
|
|
jojos
Joined: 30 Apr 2007 Posts: 64
|
|
Posted: Wed Nov 26, 2008 1:30 am |
|
|
Thank you crystal_lattice for your suggestions .I have implemented everything in this project and all is left is that part of the card.I thought even i could make my own kind of of card with a small controller.I have to think of all kind of parameters until i decide the final implement.Thanks again |
|
|
crystal_lattice
Joined: 13 Jun 2006 Posts: 164
|
|
Posted: Wed Nov 26, 2008 1:44 am |
|
|
Alternatively you could look at the the Maxim/Dallas iButtons, they have some nice SHA and OTP type buttons well suited for this type of thing - that is if you want to go the physical memory device route as opposed to the paper token. |
|
|
|