The Worlds Most Trusted Online Database?

Back

Products

Concepts

Contacts

Home

 

 

To become the World's Most Trusted Online Database is a huge, and, some might say, foolish, or possibly even arrogant ambition. Can we ever justify such language?

First, please note: at this stage, it is an aim, not a claim. And the simplest justification for stating that aim is that if we don't know where we're going, we'd have little chance of getting there. More substantially, though, we need to demonstrate at this stage that we do at least have a grasp of what we would need to achieve in order to announce success in our mission.

Second, our aim is actually relatively modest:- to achieve the highest level of Global Trust. It is not to create "The Perfect Global Database". The former is clearly achievable. Someone must hold that position (of "most trusted database") even now. Achieving perfection, on the other hand, whilst being a laudable aim in itself, may be technically impossible. Should it happen, we have no objection, of course, to becoming a Perfect Database (whatever that may mean), but for the time being we prefer to make our aims more realistic and measurable.

So what, then, is the exact scope of our mission?

We have identified what we regard as the key features one ought to find in a completely trusted database.

Infallible access control.
Complete data security.
Impregnable barriers against hackers.
Guaranteed Integrity.
Perfect Audit Trails.
Full accountability.
Unlimited availability.
Unlimited scalability

We don't imagine that we (or anyone else) will achieve a truly perfect score in any one of these areas in the medium term (next 10-20 years or so). But we do believe that, even today, we can get close to mathematical perfection in some of those areas; and that, overall, we are capable of doing better than anyone else currently hosting globally accessible data. If and when we consistently deliver that level of service, then our aim will become a claim to the title of World's Most Trusted Online Database. That is the scope of our mission.

Briefly this is how we will tackle the key areas

Access Control

Access control means ensuring that only those allowed to create, amend or read data can do so, and that they can only carry out those activities for which they hold permission.

Exactly what level of control is appropriate, depends on the application. For example, we don't care who uses the system to record non-sensitive time-stamped document hashes (see Document Protection). For any non sensitive and non commercial users, this service is completely anonymous and free of charge. Nevertheless we can't just allow anyone to do anything. We need, at least, to ensure that whoever is uploading hashes can only perform that task and read the results. They can't be permitted to delete or amend existing hashes (except their own, of course, and they would rarely want to do that, preferring instead to record the amendment as a new record)

At the other end of the scale, we need to be absolutely certain of the identity of anyone purporting to be a manufacturer uploading VRs as part of their anti-counterfeiting strategy. As a result, we will require strong authentication, of their identity.

Incidentally, all uploaded data goes to our upload centre where it is given a unique filename, catalogued, hashed, and immediately burned onto either CDRs or (if demand is sufficient) to DVDRs. Only files which have an entry in the upload catalogue and a retrievable file on CD/DVD can be uploaded to the online database.

Security

Security is far too big a subject to cover here. Anyone really interested in internet security should start by reading Bruce Schneiers excellent summary "Secrets and Lies". It is our aim to be an "early adopter" of Counterpane's Managed Security Monitoring and Giga's Managed Security Service or something very similar. They are world class security specialists and we will be protected by their efforts and guided by their advice respectively.

Data security is a many headed beast and we cover a number of aspects of the problem in dealing with the anticipated attacks on the system. The most important aspect, however, which we aim to preserve is one of the most common requirements for security: viz to maintain secrecy.

Data whose content is supposed to be private or restricted will simply not be accessible from our database. Ever. Not even to us, and not even to those who uploaded the data! That may sound like a peculiar aim or claim for a database. After all what is the point of a database from which no-one can extract data?!

The answer is that our database is not intended to be an information store. Rather it is a validation source. The idea is that everyone else holds their own data. We merely confirm to "Bob" that the data "Alice" is holding is a) exactly the same as the data Bob is looking at and b) that it has been this way at least since the time its existence was registered on our database. Thus, we never need to store the real data in the first place, we only store its hash value; or, if the protected data is either non-random or too short, we further protect the hashes themselves with one-time keys

Hence we are unable to reveal the real data, even to ourselves. All we can ever do is Authenticate it.

Nevertheless, there are a number of services where unequivocal cast-iron validation is a valuable tool in itself. Those services are precisely what the Codel system is designed to enable.

Hackers

It is probably impossible to defend yourself totally against all hackers. The sensible policy is to employ the best experts to design, implement, operate and audit your defences. As intimated above, that is exactly what we will do.

However, given what we've just described in the previous section on security, (about not holding real data), it is reasonable to point out that that we are unlikely to form a prime target for the hacker community, (other, perhaps, than as a "challenge"). If they do break through our defences, however, not even the hackers will be able to extract the protected data. It just isn't there to be extracted.

Integrity

Anyone relying on the database needs to be absolutely certain that the content we store is precisely what we claim it to be and that it is not possible for data to be changed, deleted or lost without a permanent and verifiable audit trail.

We will be able to prove, beyond reasonable doubt, at any time, that the content of our data is as we say it is, and has been since it was first uploaded.

It will, of course, remain possible for people to attempt to subvert the data and they may occasionally succeed. Their success, we believe, will be short lived because we think we can make it impossible for such attempts to avoid detection and subsequent correction. It is already possible to buy an "off the shelf" CDR server system which can store a little under half a terabyte of data on CDRs and provide access to any data on any one of those CDs within 12 seconds. It is thus relatively straightforward to ensure that all amendments to the online data are first checked against their unamendable offline sources. This arrangement is completely and easily scalable.

It is, of course, possible, that those legitimately choosing to store their data on our database will themselves store incorrect or illicit data. We can not verify the integrity or veracity of the content of the data submitted to us (especially as we don't know what it is!). Our claim is only that, once submitted, we can always verify exactly what was submitted and its source.

Neither are we claiming that data will never be amended legitimately. There are many circumstances in which it is both necessary and desirable to amend data. Our claim is that we will always be able to prove both what the original data was, (together with who uploaded it and when) and what the amendments were, (and who uploaded those and when).

Audit Trails

All activity affecting the Codel online and offline databases will be captured to our own Protected Audit Trail.

Again, depending on the application, permitted access will allow users to follow the audit trail for any stored data they are entitled to challenge. Codel's Protected Audit Trail is not only a product in its own right, it is the core product that makes all the others possible. We believe we can now offer the highest level of "Integrity Assurance" in the World.

Checking the audit trail will, in practice, be mostly undertaken by intelligent software agents, but it can be undertaken manually as this Flowchart explains as does this Powerpoint show.

Accountability

We accept full responsibility for any abuse of our system which causes damage or loss. That is unconditional. The risks that entails are factored into our business plan. We mitigate most of the risk with suitable insurance.

On a day to day basis, all access and management of the database will be logged and, unless publication would compromise our security, or the secrecy of the data, the logs will be maintained on a public domain.

Availability and Reliability

Whereas the Security(secrecy) and Integrity of the database can be proved mathematically, reliability relies on human and technological factors which are, inevitably, less than perfect. Our claim here is no more than we will do everything humanly and technically possible to achieve world class availability and reliability. The database will be "cloned" across many different sites in several different countries on at least two different continents. For those key checkpoints where system failure would allow abuse, alternative communication channels will be established to bypass our main channel (the web). Our staff and contractors will be rigorously vetted and, in any case, we will operate on the basis that we have corrupt insiders within the organisation, and submit ourselves to regular random auditing.

We have tried to anticipate the potential attacks that could be launched against the system and here we explain how we plan to deal with those attacks. Inevitably, as we take advantage of expert consultants, these early scribblings will be amended.

Scalability

We anticipate a trickle to begin with, and a flood when the idea catches on. That flood could take a year or 10 years to develop. We have to able to cope with both steady, comfortable growth and flash flooding.

We are preparing the ground for partnerships with major systems integrators so that as and when rapid expansion is necessary, the transition can be made as smooth as possible.

Conclusion

If you feel we've missed anything or you have any questions, please let us know