My apartment building recently switched from coin-op laundry machines to a stored value system using smartcards. The way it works is they have a central dispensing machine that you can use to purchase a card as well as fill up existing cards using a credit card. Each washer/dryer then has a reader interface that will decrement the stored value after starting the machine.
Being the curious type I stuck the card into my smartcard reader to see what chip they were using. A quick google search of the ATR revealed it was a member of the Atmel CryptoMemory family, AT88SC0404C. After pulling the datasheet from Atmel. I began exploring the security mechanisms they had in place.
Before I go any further I should explain that the remaining portion of this article doesn't explain an attack on the Atmel CryptoMemory parts in any way. If that is what you're after I recommend reading Tarnovsky's blog or an attack on the CryptoMemory algorithm here. With that out of the way let's forge on.
After reading through the datasheet I found that this card had a configuration page and 4 user-pages each consisting of 128bytes. I dumped the config using the following APDU.
After spending some time hand parsing the response I came up with this config.
By looking at the above we can pick out a few things. First of all the 0x27 fill is probably a security measure because we haven't authenticated in any way. Secondly, bit 4 of the DCR byte tells us that we only have 4 attempts to verify any of the eight passwords before we're locked out. Also, by looking at AR registers [0,3] we can see that all user pages do not require a password but they do require authentication. Here is another interesting tidbit from the datasheet:
Seems simple enough, verify the write 7 password, program the configuration, then blow a one time programmable fuse to prevent anyone from changing the data. So, let's read the fuse byte!
This is where things start to fall apart. According to the datasheet a fuse byte of 0x27 means only the SEC bit is blown which is done by Atmel during manufacturing to lock the lot code. With the proper write 7 password we can change the configuration (HINT: maybe removing the authentication enable bits from AR bytes?)
Ok, now we just need to guess the write 7 password. The password is 24 bits... That gives us 16,777,216 attempts to brute force it. At 4 attempts per card that will take 4,194,304 cards or 2,097,152 cards on average... There must be an easier way... My next idea was to sniff the traffic between the reader and card to get an idea of what kind of data is being passed back and forth, then after wading through the paper above, implement the algorithm to crack the cipher itself. Then I found this little diddy in the datasheet:
.
Surely you would think the engineer(s) implementing this weren't negligent enough to leave the default password... you would be wrong.
Now that we can read/write the config page all we have to do is set AR bits 4-7 to disable the password and authentication check then we can dump the user pages. I found a few things by dumping the user pages. Page 0 contains some string constants and doesn't look to be related to the stored value in any way. Page 1 looks to have all the goodies. By dumping the card before and after use I can see the bytes that change. There appears to be a sequence of 36 bytes that differ between dumps starting at 0x5c. There is also a 1 byte counter that increments by 1 as the stored value is decremented. I've yet to decode how the stored value is encoded on the card so I'll leave that as an exercise for the reader.
At this point an attacker could fill up the card and dump the contents. Then after using the card until there is no value left they could restore the dump rather than paying to refill the card. I don't want to promote fraud (or get sued) so I will not provide dumps of the user pages. Below is a proof of concept video to prove how easily it can be done.
I wrote the application below in C# to assist in working with the Atmel CryptoMemory line. Although I've only tested it on a AT88SC0404C it should work with any chipset in the family. The software provides the ability to dump the config to the terminal, read the fuse byte, and backup and restore the entire card including the config and user pages. Be warned! Since the fuse byte is completely unlocked all fields in the config page are writable. Even the ATR! On a few occasions I overwrote the ATR to all zeros accidentally (due to a bug in the application.) This caused the cards to respond with all zero ATRs which broke ISO-7816-3 compliance so they no longer work in my reader. It may be possible to recover them using the synchronous 2-wire serial interface but I haven't tried yet. The software should work with any compatible PC/SC reader.
THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
AtmelCrypto.zip
This software is provided free of charge under the creative commons license. If you find this software useful please consider making a secure donation using the link to the right to support future research.
