What Data do we Store?
Codel stores the minimum client data required to validate Documents, VRs, Audit Trails etc, in accordance with our Data Storage Objectives.
The only data we MUST store are relevant hashes together with a time stamp from a trusted source.
It may be that, for a number of reasons, the owner of the relevant hashes may also wish to store other carefully selected non sensitive identifying details, such product name, consignment numbers, destinations, bid numbers etc. These, however, are usually optional and rarely required by Codel.
Exceptions include our email validation protocol, which requires us also to store keys and source identifiers so that we can verify the identity of parties to an email communication. But even these are not in a form of any use to an attacker. For example, the source id might well be the sender's public key. As this is, by definition, already in the public domain, it is of little benefit to an attacker. See how Codel defends itself from attack.
The choice, therefore, of what additional data to make available online is the clients, with the exception that we will, in line with our second objective, decline to store data of obvious significant value to attackers.
Brand owners using our anti-counterfeit protocol or manufacturers using the system for tracking goods through the supply chain may, for example, wish to include routine shipping data - the sort you would normally expect to find on a consignment note or bill of lading: Shipping source, Destination, Date of shipping, Courier id, Package or Container IDs, Product type and quantities. None of which will assist counterfeiters in creating valid VRs but could be of use to industrial competitors trying to estimate the scale of the manufacturers market and production capacity. Hence the need to protect ourselves against attacks even against the "non sensitive" data.
Data Storage Objectives.
Codel stores the minimum client data required to validate Documents, VRs, Audit Trails etc.
In all cases, we have four principal objectives.
First: we must store enough data to be able to prove our (your) case - in court if necessary.
Second: we must try to avoid storing data of significant value to an attacker.
Third: the integrity of what we store must be protected using our own Audit Trail Protection protocol
Fourth: we must do what we can to defend ourselves against attacks of all kinds.
Enough Data - what constitutes "enough" is context dependent.
To protect the copyright on a document, all we really need is its hash value. We create our own time-stamp.
On the other hand, if - when copyrighting a document - you also wish to log a claim in regard to the document (eg "this is the first documented description of how we can terraform Venus" or whatever), then you'll fill in the claim details (within the Codel Document Protection Software) and the hash of that claim will also be stored alongside the original hash.
Protecting Branded Goods again only "requires" the relevant hashes (of the VRs) but the database would be of little use to the supply chain if that's all it held. Hence, for reasons other than our primary authentication purpose, sundry non sensitive administrative details are also stored (eg type of product, consignment numbers, quantities, immediate destination etc)
Protecting a document for legal purposes is the most exacting role for the database. For this we can, optionally, store the hash of the document itself using our standard document validation procedure. But the legally required evidence is proof of the dates of sending and receipt and proof of the identity of sender and recipient. This is described in detail under our email validation protocol.
Data of significant value - iis a subjective judgement.
What may seem of no significance to us might be enormously valuable to a particular attacker. All we can do is use common sense to weed out the obviously valuable data and then respond to events. If we find, for instance that attackers are showing interest in a particular class of data we've hitherto assumed to be be non-sensitive, we will take appropriate steps to remove the temptation.
The only awkward situations will arise when the client wants to include plaintext for administrative reasons. The most obvious example is the Brand Owner who will want shipping data on the system for the benefit of the supply chain. If a rival is sufficiently determined, they may well attack the system in order to extract details of shipments.
We will have to review such cases on an ad hoc basis. In some cases the Brand Owner or the supply chain will be able to live with reduced data. In other cases, we may need to set up a secure authenticated network just for a particular supply chain in order to continue providing the benefits of the data with minimum risk of data harvesting.