Steal bulk IDs from the database
Attack 2 - copy legitimate IDs from existing products
Attack 3 - Steal bulk IDs from the database
Attack 4 - Subverting the Channel
Attack 5- Subverting the Database
Attack 6 - Subverting the Server
This attack is primarily against the anti-counterfeit protocol but also illustrates how hashes play an important part in our overall defence.
This attack requires a bit more intelligence. The attacker will try to obtain legitimate ids in bulk, before the real goods are publicly available, and attach the IDs to their fakes.
Assuming they're trying to sell to the FD market, even if they succeed, the problem they immediately face is where and when they can sell the fakes, given that they must pass ALL the tests.
They can only sell them in a location and at a time which must both be consistent with the chain of custody. And they must get rid of all their stock before the real thing hits the street and begins to be registered in its own right. In most cases this gives them, at best, a window of opportunity of a few hours, perhaps a day or two, to sell the fakes in the vicinity of the legitimate traders, who aren't going to be too happy to see the fakes materialising in their neighbourhood the day before they get hold of the authentic goods. At the very least we can see that this will be a pretty hostile environment to have to work in.
Nevertheless, we need to protect ourselves against such an attack and reduce, still further, the chances of its success.
There are only two places they can obtain the data. The second is the manufacturing site where the VRs are generated. We deal with this here.
The First and most tempting target, however, is the central database. This, obviously, will be accessible via the web and the web is notoriously insecure, so they will try to hack into the database. We will employ best practice and state of art defences against that as a matter of course. In addition, however, we realised that we have a means of removing, from the database, that which is of greatest value to the counterfeiter, viz the actual Validation References (VRs).
We provide software (or the algorithms and protocols for those who want to amend their existing software) which creates the VRs. The software also creates a 20 character (160 bit) "digest" or hash value of the VR using the public domain SHA1 or 32 character (256 bit) with the SHA256 one-way hashing algorithms. It is this hash value, only, which we store on the Codel database.
Once the counterfeiter understands how we have stored the data, they know that there is simply no point attacking the central database; at least, not with a view to obtaining a bunch of valid usable VRs. It is worth emphasising that the VR hashes won't even appear in the Database until the goods leave the Factory gates. At which point, the counterfeiter has a matter of a few days to crack into the database, steal the hashes, brute-force decrypt them back into plaintext VRs, mark all his fakes with those VRs and distribute them to locations matching the distribution of the real products, arriving at those locations in time to be sold in the window between first legitimately acceptable arrival time and first registrations of the real thing.
