Subverting 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
If the potential profit is high enough, the counterfeiter will try the next level attack: Subversion of the database itself. They will try to get an insider to place their own VR hashes on the system, by amending existing data or by assisting the upload of apparently legitimate data from an illicit source (which we deal with under Attack 4)
Defeating the amendment attack will be partly achieved by implementing a WORM based protocol in which the only legitimate route by which data can be added to the online database will be via WORM storage. i.e. all new submissions are written, first, to the WORM devices (almost certainly CDRs) and only written to the Oracle database from the WORM source.
In addition, all access and attempts to access the database will be logged in detail and the Logs stored on WORMs themselves. These Logs will be publicly accessible and will operate with appropriate disclosure rules. (with an option for the uploader to override disclosure protection and allow their identity to be published - this might be appropriate, for example, as part of a public launch of new products etc)
There is an inherent element of integrity in the use of WORM storage as, by definition, there is no known way to rewrite WORM data. However it is, of course, not perfect as an attacker can replace the entire CD with a new version which contains their desired data. Protection against that attack comes from our next defence.
Specifically, we also use Hashing in its more traditional form to confirm and protect the contents of each CD. As part of our audit trail, the Master Document Hash of all the data on the CD will be published in a number of reputable journals with a combined circulation of not less than one million. This has the effect of making the hash a matter of dated public record. Should any challenge arise as to the legitimacy of the content of the Codel database, it can first be compared to the value on its original CD and the hash value of that CD can then be compared to the public record. As the MDH of any illicit substitute CD will not match the published version, and no attacker can realistically hope to alter a million or more published copies, substitution attacks are untenable.
This procedure is practical for Codel, as speed of uploading is not critical. Speed of access to data that is already online is highly desirable, but it doesn't matter if it takes a few minutes or even hours to conduct all necessary checks and create the audit entries prior to uploading new data.
The online database will then run continuous integrity checks to ensure that its online values never drift (without logged detection, investigation and correction) from the offline originals. In addition to the continuous integrity checks, any VRs specifically queried from the outside will automatically be checked against their WORM source data at the earliest opportunity following the external match. This will ensure that, even in the event of subversion, any illicit amendments are identified and dealt with before any serious harm can be done.
