Response
As you may have understood, I was quite content with the results: while it didn't prove as easy as the other 5 devices I had cracked, eventually I did end up with fingerprint-less access to the flash contents. I informed Tweakers.net, and we decided to inform the suppliers of the stick, just as we had done with the other five sticks. The Dutch firm which imports the sticks referred us to the manufacturer in Signapore, which quickly contacted us.
Ofcourse, the company was interested in the attack I did, although the people we spoke to had their doubts if I could pull it off with a second stick. They offered to bring me such a stick personally: a trip to Europe was planned anyway so they could drop by my house easily. When they arrived, I tried to do my hack on the new stick: open the casing, snip the trace, connect the cable, run the program... but while at that point the original stick happily would give up its data, this stick wasn't so lenient. After three times, it even did something the first stick never did: instead of happily checking fingerprints, it refused to do anything but blink its leds. Even a correct fingerprint couldn't bring it to its senses anymore. As you might understand, I was quite flabbergasted.
While the delegation of Ritech-people couldn't immediately tell me what happened, a quick call to Signapore cleared things up: as soon as the BioSlimDisks firmware detects certain errors in the communications, it will completely lock up: all it does after that is blink its leds. The stick would then have to be sent back to Ritech for re-flashing of the firmware. The reason why the first stick I had didn't do it, is because it was an early engineering sample, with firmware that didn't have the self-destruct-feature yet.
Ofcourse, I didn't plan on giving up that easily. Armed with a new stick, I decided to see if I could make more sense out of the protocol used. I eventually found out that the sensor was made by a company called 'UPEK' and after some more Googling I found a document that explained most of the bitfields used in the communication. I used that to expand my program and to see if I could make sense of what the BioSlimDisk exactly does to prevent replay attacks, which is how the attack I did on the prototype generally is called.
As it seems, the final version of the BioSlimDisk uses a feature of the UPEK-chipset called 'private data storage'. Every time a fingerprint is enrolled, the PIC sends a piece of (presumably random) data to the fingerprint-chip that gets stored along with the fingerprint template. This data only leaves the chip again when that particular fingerprint is detected again. The PIC then compares it to the data it knows it sent at the enrollment of the finger, and if the two are the same, it knows that the fingerprint is valid. An attacker can't know the data unless he has the original fingerprint, so a replay attack as was done on the prototype, won't work in the final version of the stick. In other words: that aspect of the chip was safe, and I couldn't really find any other gaping security risks to crack the stick with.
Ok, so the BioSlimDisk is reasonably secure. What is 'secure'? According to Ritech, the BioSlimDisk Signature was made with the following requirements:
RiTech developed Signature base on these security protection of the device by
the user. These expectations are:
1. If I loose the device it takes significant effort before someone can
access the data
2. If I leave my device in my office a colleague cannot access the data
within e.g. half a day or a day.
As you can see, the protocols that are in place make sure these requirements are met. I'd like to go a bit further, though: can the BioSlimDisk Signature be used in situations that have needs that exceed these expectations? Let's see if, for example, it would be wise to store nuclear secrets on it, and perhaps we'll run into something that's interesting for normal use, too.
The protocol specsheet did implicate a few ways to make cracking the stick using latent fingerprints easier. For example, while some versions of the sensor seem to have advanced features like the ability to make a distinction between a live finger and a lifeless object, this can be disabled by sending the right commands over the serial line. The same thing goes for the sensitivity of the sensor: while this is only adjustable by a small amount, it might be just enough to use it in combination with a couple of latent fingerprints to let the sensor part with its private data. This is guesswork, though: the specsheet PDF is quite old and may not exactly match 100% with the features of the BioSlimDisk-sensor.
A quirk of the current firmware can make things a bit easier for a would-be hacker: because the private data stored alongside all the fingerprints is the same, one would need just one fingerprint to get the private data. As soon as that data is known, it is possible to just enroll your own fingers, providing the fingerprint-chip with the previously received piece of private data. Connect the chip to the rest of the hardware, enter your own fingerprints and you're in. A cracker could get the fingerprint, for example, from the fingerprint-sensor if you were too lazy to swipe your finger over it after use: while that probably isn't that easy because there are multiple overlapping fingerprints, I'm sure that it eventually can be done, especially when the carrot is an important nuclear secret. It would take expertise and time, though: making a mold from a latent fingerprint is no sine-cure.
If you're worrying about crackers using latent fingerprints to get to your precious hypothetical nuclear secrets, Ritech can, on demand, deliver you a stick that self-destructs after a certain amount of tries. While it is a nice feature, it's possible to overcome it: as soon as you connect the fingerprint-sensor directly to a PC and use that to check and verify the latent fingerprints, the PIC will never know and won't self-destruct.
Without latent fingerprints and if enough money and time is invested, a hacker still might be to get to the information: not because the designers made a mistake, but rather because everything can be cracked. For example, the PIC, the microcontroller where the AES-key is stored, does have some security features that stop it from allowing access to its memory freely. The processor is hardly a security processor, though: it's quite possible that people with the means to get access to the processors die can get out the AES-key. While the costs and knowledge that such an operation would require is prohibitive for the majority of people, an enemy nation wanting access to your nuclear secrets would be able to pull it off.