burden of proof / keys or plaintext

Ross Anderson Ross.Anderson at cl.cam.ac.uk
Thu, 05 Aug 1999 09:47:22 +0100


David Swarbrick wants clarification of:

> 20.--(1) Every power which is conferred by an enactment to which 
> this section applies on a constable who has entered premises in
> the exercise of a power conferred by an enactment shall be
> construed as including a power to require any information
> contained in a computer and accessible from the premises to be
> produced in a form in which it can be taken away and in which it
> is visible and legible.

With many products, compliance is already impossible. PGP, for
example, allows you to specify that the recipient will only be able to
display a message on screen, not print or save it. Although in theory
one can write a noncompliant implementation, it would be unreasonable
for PC Plod to insist that a user do this. 

It's not just PGP; I've helped people build PC database apps in which
you can fetch only so many records at a time, and which have all sorts
of tricks to prevent people stealing the whole database. With such
products the source code isn't available (in the case of my client,
it's not even in the UK) so the non-compliant implementation route is
very much harder.

(Yes, in case you hadn't noticed, I just uttered an argument in favour
of a non-open-source security product; this just illustrates the
extent to which government attempts to control crypto are profoundly
contrary to nature :-)

People like Intel and Microsoft are under much pressure from Hollywood
to design products that provide ever better support for applications
which won't provide information `in a form in which it can be taken
away'. The P3 serial number is the start; if you assume that software
can be made tamper resistant enough to defeat PC Plod, then P3 already 
lets you write applications which will only display file X on machine Y, 
and only if machine Z is currently online. Future processors that have a
private key on-chip will raise the bar very much higher,

Ross