Schneier on Security

In the UK the Government has been pushing for "all electronic courts" with one of the "show case courts" being Kingston Crown Court in Southwest London (it's where many of the celebrity cases are held).

Suffice it to say it has had teething problems and the technology does not appear to be as robust or reliable as one would hope.

Interestingly that although the court has microphones etc and records what is said they still don't allow independent recordings to be made.

This means that a defendant would have to pay for their own court certified stenographer, which is a very significant cost that as far as I'm aware would not be covered by the usuall relief (legal aid in the UK) available to defendant's of criminal proceedings.

Thus a significant hole appears to be opening up that could alow for "records to be unverifiably" changed whether by accident or design. And in the latter case by those in power or those unknown.

However one thing to note, if the basic "digital audio" records are kept, then they will have traces of "mains hum" on them thus finding any changes from two different recordings should be relativly easy, and as in the case of the UK a forensic copy of the mains frequency is kept, then it should be fairly easy to identify which recording had been tampered with.

@ keymaster,

FBI accused of planting backdoor in OpenBSD IPSEC stack

This allegation was made privately to a member of the OpenBSD team well over a year ago and appeared even then to be somewhat odd. The member of the team despite that chose to release the allegation into the public arena. Since then many many eyes have studied the code and little has come of it.

SSH/SSL in the meanwhile has been found to have a number of design / protocol errors.

And this realy is the point, how do you know if a design / protocol error is a deliberate "back door" or an unintentional mistake?

It's safest to assume that although they may be unintentional they are / will be exploited and thus in any complex system there are in effect backdoors.

Thus you need a different design criterion to mitigate this assumption, and all the popular / commodity OS's currently use the wrong design criteria with their monolithic kernels and ring 0 device drivers and other long historic design choices.

As Nick P has pointed out on the odd occasion there are OS's that are more secure by design.

However that said, the battle has realy moved from the OS space to the Application space. I've been saying for many years that the likes of web browsers are totaly insecure by design because of the wrong viewpoint early on in their design.

This is because they use(d) a single process space all at the same privilege level and under a single process / user ID to do work on seperate and often unrelated tasks (ie one window open to say a Web Admin interface on one service whilst another is reading posts on a blog, and another accessing Email etc etc).

Which traditionaly was done by seperate (terminal) programs which would have been done running in seperate process spaces with different process IDs and sometimes even under different user IDs thus leveraging not bypassing the OS security mechanisms.

For all it's faults the design of the Chrome Browser was a step in the right direction all be it small and somewhat hesitant as it needs to go one heck of a sight further to even get back to the same level of security that the old style working methods had.

And arguably it may not be possible, the whole point of an OS is that it is intimate with the underlying hardware for task switching and importantly addressing the MMU whilst also by the use of kernel buffers etc provides a vanilla interface to programs. Thus in the general case the usual userland program cannot setup seperate work spaces from within it's own resources and have them arbitrated by the hardware.

The solution for commodity OSs is to setup seperate process spaces through the OS and use IPC mechanisms for communication between them. However this is difficult to set up has many many awkward limitations and is usually "two legged dog slow" and does not stop rouge behaviour in a process from insecure behaviour across the IPC mechanisms.

Which brings us to a fundemental issue of computer security of segregation-v-usability. To be secure you need very strong segregation at all levels to stop information leaking between processes. However to be usable for user "multi task" work you usually need minimal segregation of user directed information flow between tasks.

Thus you need very strong segregation between processes which is relatively straight forward to achive, but you then need to have communications across the segregation that in turn needs to be secure at all levels. And secure communications at even the simplest levels is very difficult if not impossible to do. Because covert channels can dribble information across and are difficult if not impossible to find and stop as their visability is often related to their bandwidth. And as a generalised rule of thumb you can only find an illicit communications path if you are aware of the general class it falls into or if you can prove illicit information is being transferred.