Attack 7

The Manufacturer

How It Works

Back to Previous

Back to Products

Home

Contact Codel

Attack 1 - Naïve

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

Attack 7 - The Manufacturer

Attack 8 - Distributed Denial of Service

Attack 9 - Physical Destruction of the Database

This attack is anticipated against Brand Owners using our Anti-Counterfeiting Protocol.


After defending ourselves against Attacks 1 to 6, there is still one obvious place for the counterfeiter to go to obtain valid VR data - direct to the Manufacturer where the VRs are created.

Codel Can't Permit Sloppy Security
Protection here is primarily the responsibility of the manufacturer but we will provide any support they require. It is a condition of any contract between Codel and the manufacturer that certain minimum security protocols are implemented and routinely audited. Not only is this in the manufacturers' interest, but we cannot afford to have the integrity of the Codel database compromised, so all contributors to it must achieve at least the basic minimum security levels.

The software will do much of the work, but there is a window of vulnerability between the generation of the VRs and shipment of goods, so well rehearsed manual security protocols will be essential.

Leave VR generation as late as possible
Wherever possible, the generation of VRs will be left as late in the production/packing cycle as is practical. The optimum time, from a security standpoint, is just prior to despatch. Unfortunately, this is rarely likely to be convenient for large operations where goods are packaged and palletted for at least a day or two prior to being uploaded into a shipping consignment.

Whatever that period is, between labelling with VRs and final despatch, this is the window of maximum vulnerability. During this period, the bulk data exists in two places - as physical labels on the products and as raw data in the VR application database on the manufacturer's site.

The physical data represents the lower risk (except in the case of RFIDs - see below). Routine packaging security should cope. If the packaging is tampered with while still on the factory premises, then all the products therein can, in most cases, simply be re-labelled and the original VRs voided. (Note, a similar procedure also applies to any goods reported stolen from the supply chain. By voiding their VRs (or flagging them as stolen), we make them impossible to validate and they become a high risk for the thief to dispose of. Essentially he can only sell to the CC market at a low price. The FD market consumer is too likely to attempt registration)

Protecting the Computers
Detecting illicit access to data (for the purpose of copying) is somewhat more complex. The electronic data needs to be protected with appropriate physical and software protocols and proper vetting and selection of authorised personnel.

Restrict Physical Access to VR generation areas
There is a third area of risk which is at the point of VR acquisition. For example, if the VRs are to be applied as barcoded labels, then from the time the labels are printed, to the time they are scanned into first level cartons, a rogue scanner could re-capture the legitimate VRs from the barcodes. The area where this operation takes place will therefore have to be a physically protected, continuously monitored, secure and restricted access zone.

RFID - additional risks
This risk is also a negative aspect of RFIDs. Restricted access zones won't do anything to prevent theft of their codes. By their very nature - indeed, it is their major selling point - RFIDs can be read from a distance, while still within the packaging, and they can be read in bulk. From a tracking perspective this offers substantial advantages. From a security angle, it is a potential nightmare as whole consignments of valid VRs could be harvested by anyone with appropriate readers.

RFID - possible countermeasures
There are at least two possible solutions. First is some novel form of protection (for example a jamming broadcast) which may not even exist yet. The second solution is to create not one, but two VRs for RFID protected items. The RFID VR would be used "in transit" and a completely different plaintext VR would be used for validation and registration. The readers could capture the RFID signatures but this would reveal nothing about the plaintext VRs whose security would thus remain intact. The database knows which is which, and would identify but reject attempts to register RFID signatures in place of the true VR.

Neither solution would providee complete protection. In the first case, for example, how do you ensure the jammer is always on when its required? How do you ensure that when the jammer has to be switched off, so that the RFIDs can be officially read, some rogue isn't nearby capturing the data? In the second, stolen RFIDs would not help the counterfeiter much (too much chance of collisions between valid and invalid RFIDs) But they could be attached to dummy replacements and used to mask (during transit at least) theft of the real product (presumably for sale on the CC market).

Protection from VR Generation to Shipping
Other than RFID labels which will require these - and possibly other - special measures, this high level of security will need to be maintained from the moment a VR is generated, until the product with that VR is shipped.

For Brand Owners who already have anti-counterfeit measures in place, their existing physical security is probably adequate. For those who do not already implement such security, it does represent an additional cost.

Protecting VR data
With regard to the data itself, once the goods have left the factory, the VR generator can dramatically reduce the risk by chopping out a large part of the plaintext VR and removing it securely from the Brand Owner database.

Why retain any of the plaintext at all? Isn't the hash all we need? Yes but...

We can anticipate telephone queries from consumers based on their plaintext. Whilst it is, of course, possible to insist that the consumer reads out all 25 characters, (in which case we could find the item by matching the hash) this is neither friendly nor necessary. We can search for any VR on a "popup" and by the time you have entered the first 5 characters, you are, in most cases, looking at the correct VR. If we allow for the first 10 we can guarantee uniqueness (by rejecting 10-character duplicates at the generation stage). Incidentally this allows the manufacturer to create 2,758 Trillion IDs unique at the 10 character point (3510).

The need to retain those 10 plaintext characters provides the clue to why we need 20 character VRs (plus check digits).

If the VR was only 10 characters to start with, then the retained data would, of course, be the complete data and remain permanently vulnerable. If it was originally only 15 characters and we retain 10, then the counterfeiter has 2/3 of his job done for him and the calculation of the missing 5 characters is within the bounds of feasible computation. It is only by ensuring that at least 10 characters are removed (and thus have to be "cracked") that we also ensure that any stolen data still poses a huge computational barrier. In losing 15 characters we can be confident that the remaining 10 characters do not represent any significant security risk.

System Resistant - Attackers Can't cover their tracks
The system would even be resistant to attacks on the manufacturer like that which happened to a reputable sportswear manufacturer a few years ago, one of whose far east factories were running two shifts for the Brand Owner and one for the fraudsters. (We can't call them counterfeiters in this case because their product was completely authentic, merely illicit production and stolen goods)

Had the Codel system been in place, the thieves in this case would still have to register their VRs (or they couldn't be sold in the lucrative FD market), and unless they have corrupted the entire management layer at any given factory, the illicit VR upload must be noticed. Even if it isn't, and the management is completely corrupt, the protected audit trail would eventually reveal these illicit activities to anyone who went looking. Thus, even if they can succeed in producing illicit product by subverting entire sites, they cannot cover their tracks.