iButtonLock
Aaron suggested I develop a lock using iButtons and PIC
chips. He was going to build it but plans changed and it was
never used.
There are various designs for such a lock floating around the 'net. One I saw had the ability to learn new iButtons as required but only the schematic was shown - you had to pay for a pre-programmed PIC chip. In the end I created a stripped down schematic using ideas from several designs. From a software point of view, the code is very cunning in that it uses the program memory to store data - that data being the ID codes of the valid iButtons.
First up, here's the schematic:
There are various designs for such a lock floating around the 'net. One I saw had the ability to learn new iButtons as required but only the schematic was shown - you had to pay for a pre-programmed PIC chip. In the end I created a stripped down schematic using ideas from several designs. From a software point of view, the code is very cunning in that it uses the program memory to store data - that data being the ID codes of the valid iButtons.
First up, here's the schematic:
As you can see, very few components are required
to make this circuit work. All the hard work is going on in
software. I never built this as a finished project but I did
build a prototype on breadboard and tested the software with real
iButtons.
The software is cobbled together from various sources. The iButton reading routines didn't quite match the timings of the official documentation so I tweaked them to bring them into compliance. The original source also assumed that the iButtons would be of the ID only variety. I changed this so that any member of the iButton family can be used.
This is an overview of the sequence of events:
The software repeatedly performs the "iButton presence" check until it actually sees an iButton.
Then it sends the "Read ID" command and stores the response including the CRC while also calculating the CRC of the received data.
If the CRC is not valid then it assumes there was a reading failure and goes back to the presence stage.
If the CRC is valid then it checks the received ID code against the valid ID codes stored in memory.
If it doesn't match then it goes back to the presence stage.
If it does match then it activates the line to the relay which could be wired to an electric door release for example.
As I mentioned earlier, the valid ID codes are stored in the program memory of the PIC chip rather than its EEPROM memory. This cunning technique lets you store more ID codes than you would be able to in EEPROM memory.
Now it is possible to program a microcontroller chip to behave like an iButton and cycle through all possible ID codes. In order to defeat such an attack, the software will lock for twenty seconds after a failure to match against the list of valid keys. You could increase that to minutes if you so desired but that could allow for a denial of service attack if taken to extremes. You could use another line on the PIC chip to activate an alarm after three consecutive invalid ID codes. Feel free to embellish the design but watch out for adding too much code so that it overwrites the stored ID codes!
Final note: The version of the software supplied has been set up with three valid ID codes. They are stored in bytes starting from the LSB which is the family code. The CRC (which is the MSB) is not stored since if the CRC is both read and calculated to be valid from the incoming data and the first seven bytes match the stored seven bytes then, by definition, the CRC of the stored ID code is the same as the one just read.
The second stored ID code is deliberately an invalid code so that it can never match and is there purely for testing purposes. Obviously you must replace these codes with your own before you program your PIC chip and don't forget to change the "SID" constant to the new number of stored ID codes.
<Back>
The software is cobbled together from various sources. The iButton reading routines didn't quite match the timings of the official documentation so I tweaked them to bring them into compliance. The original source also assumed that the iButtons would be of the ID only variety. I changed this so that any member of the iButton family can be used.
This is an overview of the sequence of events:
The software repeatedly performs the "iButton presence" check until it actually sees an iButton.
Then it sends the "Read ID" command and stores the response including the CRC while also calculating the CRC of the received data.
If the CRC is not valid then it assumes there was a reading failure and goes back to the presence stage.
If the CRC is valid then it checks the received ID code against the valid ID codes stored in memory.
If it doesn't match then it goes back to the presence stage.
If it does match then it activates the line to the relay which could be wired to an electric door release for example.
As I mentioned earlier, the valid ID codes are stored in the program memory of the PIC chip rather than its EEPROM memory. This cunning technique lets you store more ID codes than you would be able to in EEPROM memory.
Now it is possible to program a microcontroller chip to behave like an iButton and cycle through all possible ID codes. In order to defeat such an attack, the software will lock for twenty seconds after a failure to match against the list of valid keys. You could increase that to minutes if you so desired but that could allow for a denial of service attack if taken to extremes. You could use another line on the PIC chip to activate an alarm after three consecutive invalid ID codes. Feel free to embellish the design but watch out for adding too much code so that it overwrites the stored ID codes!
Final note: The version of the software supplied has been set up with three valid ID codes. They are stored in bytes starting from the LSB which is the family code. The CRC (which is the MSB) is not stored since if the CRC is both read and calculated to be valid from the incoming data and the first seven bytes match the stored seven bytes then, by definition, the CRC of the stored ID code is the same as the one just read.
The second stored ID code is deliberately an invalid code so that it can never match and is there purely for testing purposes. Obviously you must replace these codes with your own before you program your PIC chip and don't forget to change the "SID" constant to the new number of stored ID codes.
<Back>