Is there a way to "block/erase" the code until it receives a "password" to operate again?
Im thinking in something like the code stops/expires at certain time(with an RTC) and you need to upload new code to make it work again until certain time.
Yes.
You can create an endless loop, e.g. with while(1); if a certain condition is met.
This will force that one needs to upload again before it can do its real job.
I'm not sure where the password comes in. You can prompt users for a password when the code has expired and set a new expiry date/time (store in eeprom).
Asuza:
Is there a way to "block/erase" the code until it receives a "password" to operate again?
Im thinking in something like the code stops/expires at certain time(with an RTC) and you need to upload new code to make it work again until certain time.
Does the user have physical access to the Arduino? That would make it much harder to secure.
If the Arduino is in a locked box then it would not be hard to prompt for and wait for a valid code to be entered on a keypad. If the valid code is based on the current date or current date and time then they could not use out-of-date codes.
Is each code good for the same amount of time?
If they have physical access to the Arduino (ie, can connect to any pin), it cannot be secured. You can protect your code with lockbits (requiring the chip to be erased to reprogram), but they can do that and upload whatever replacement code they want. Even if you disable SPI programming and don't use the bootloader, they can still erase the chip with HVSP and reprogram. Hell, they could even change the date in the RTC without touching the micro. Of course, if they don't have the code or hex file for your code, they couldn't upload your code.
That said, assuming the above is okay - there are a variety of schemes that you could use with an RTC module to derive a code from a date, and then test the supplied code against that; its hard to say what would be appropriate without knowing more about your requirements.
The user wont have acces to the arduino.
I was thinking the password could be entered through a keypad(hex password) or even uploaded through an usb. And after entering it "refreshes/uploads" the code with a new date. (Thanks for the responses)
Asuza:
after entering it "refreshes/uploads" the code with a new date. (Thanks for the responses)
So after they enter a code the Arduino goes back to doing something useful. When the new date arrives, it goes back to prompting for a new code.
Does the code have to include the expiration date? If not, how does the Arduino get the new expiration date?
johnwasser:
So after they enter a code the Arduino goes back to doing something useful. When the new date arrives, it goes back to prompting for a new code.
Does the code have to include the expiration date? If not, how does the Arduino get the new expiration date?
Yes. I'm sorry if Im not being too clear, this part of the project might be a little confusing for me but Im willing to do it.
This code runs a domestic appliance and it has the RTC set with an expiration date. After the expiration date is met, the machine will request a "licence" with a new expiration date.
This "license" could be entered in a file by USB (not sure if this is possible) containing maybe just the same code but now with a differente expiration date until the date is met again.
Im refering to it as a password as well because maybe the user can enter it through a keypad(still thinking in something like [machine number+user number+expiration date+key] ) and then arduino could just "take" the date part and replace it into the old code.
To generate the 'password'
1)
Take the date as a unix timestamp (seconds since 1970/2000).
2)
Calculate a crc over it to prevent tampering.
3)
Encrypt using e.g. 3DES; AES and RSA are probably better but might occupy more memory in the Arduino.
4)
Convert to base64.
When the Arduino receives it
1)
Convert back from base64.
2)
Decrypt.
3)
Verify crc.
4)
Store timestamp in eeprom.
5)
When needed, read timestamp from eeprom. You can compare the current timestamp (from RTC) against the stored timestamp to check if the license has expired.
If the 'date' only needs 1-day resolution and historical dates aren't necessary I would reduce the size of the 'date' by dividing by seconds per day and subtracting days until 2010. The remainder would fit in 16 bits and still cover the next 170 years.
Base64 encoding would be great, if the device had a full alphanumeric keyboard. For a 12-key or 16-key keypad (the two most common flavors) you would want something in decimal.
sterretje:
To generate the 'password'
1)
Take the date as a unix timestamp (seconds since 1970/2000).
2)
Calculate a crc over it to prevent tampering.
3)
Encrypt using e.g. 3DES; AES and RSA are probably better but might occupy more memory in the Arduino.
4)
Convert to base64.When the Arduino receives it
1)
Convert back from base64.
2)
Decrypt.
3)
Verify crc.
4)
Store timestamp in eeprom.
5)
When needed, read timestamp from eeprom. You can compare the current timestamp (from RTC) against the stored timestamp to check if the license has expired.
I would need another arduino for that right? Is it too dificult to do that?
Asuza:
I would need another arduino for that right? Is it too dificult to do that?
You should not need another Arduino. If your existing code takes up too much room you could switch to an Arduino with more memory.
I’d save the lock/unlock state in EEPROM, then depending on reading that state during setup(), the code would ‘abort’ until the correct key, or re-flash occurred.