Re: UK to ban free use of crypto?

The document is at http://dtiinfo1.dti.gov.uk/pubs/

At 08:01 AM 3/23/97 -0500, Peter D. Junger wrote:
>After a very quick reading of this proposal I am convinced that all it
>would do if implemented by legislation that follows its recommendations
>would be to forbid those who are in the UK from using an unlicensed
>key escrow services.
>
>It quite clearly does not intend to ban the use of cryptography or the
>publication of cryptographic software.  

And Michael Froomkin offers similar sentiments.  They're both lawyers,
and I'm not (:-), so they're expected to do a better job of reading
the legal parts of it.  On the other hand, the DTI says:
	57.The legislation will provide that bodies wishing to offer 
	or provide encryption services to the public in the UK will be 
	required to obtain a licence. The legislation will give the 
	Secretary of State discretion to determine appropriate licence conditions. 
and it's got a really broad definition of "encryption services",
including even things such as time-stamping.

The big problem is that the document has a really warped view of the 
cryptographic and business services that a "Trusted Third Party" 
would provide, and some parts are expressed in quite broad language.
For instance, it implies that the TTP is being trusted with private keys,
otherwise there would be no way for it to recover anything.

On the other hand, from their Q&A:
	Q: Will a TTP be able to access an encrypted message ? 
	A: No. It is important to be clear that it is not envisaged 
	that the encrypted communication would be routed via the TTP. 
	Nor will the TTP encrypt the message, it will merely assist 
	(depending on the service offered) in the very complex area of 
	key management or Key Certification. 
If the TTP is not encrypting the data, they don't need the secret key
or your private key.  They DO need your public key, to sign it, 
so a second party can trust that a key they have is really yours.
But you and the second party can use the signed keys to exchange a
secret session key, or to sign documents, without the TTP's help.*
So their primary description of what a TTP would do does not involve escrow.

Keys are used for three things - communications, signatures, and storage.
As discussed above, for communications, the TTP doesn't need your private key,
and there's no business need for anyone to have the keys to decode a 
communication unless they already have the cyphertext.  Business applications
that do require a third party to have a copy of your _message_ can be
met by sending them a copy of your message, encrypted with their key,
and the document explicitly says it's not talking about them.
Similarly, cell-phone companies are providing encryption and routing,
so this document claims not to be about them, though it regulates them.
The only third parties who need just the session key itself are
eavesdroppers and forgers, who are Untrusted Third Parties.

For signatures, there's also _never_ a need for the third party to
have the private keys - the function you Trust the Third Party to do
is to certify that the holder of the key either is who he claims to be
or has the permissions he claims to have (e.g. to write purchase orders
or sign contracts for Company X.)  And the document even states that
"There is, of course no intention for the Government to access private keys
used for only integrity functions."

The main time you want another party to have a copy of your keys
is for stored data:  to cover the "employee dies" case 
(the document explicitly permits companies to handle their own keys 
without regulation, so no TTP is needed here), and the 
"you die, and your family digicash is in your encrypted file system" case,
for which you can give a copy of your key to your spouse or solicitor,
or keep it on a floppy in your bank safe deposit box, all of which cases
are presumably covered by current law in the UK just as they are in the US.

SO - what _is_ all this malarkey about "legal access" and "key recovery"
and "key escrow" systems?  The document claims repeatedly that it's not
purporting to regulate any of the conditions under which a Third Party
would ever be Trusted with the keys you actually encrypted something with.
There's a whole lot of material about restricting who can be in the
business and offer these services, seemingly designed to either
restrict the emergence of new services or to be later expanded to cover
other parts of the encryption business, such as supplying encryption software.
And it's very unclear about whether it covers the encryption services
used in inter-corporate projects such as Mondex - as a stockholder and
customer of some of those companies, this concerns me.

In particular, the expansion appears to be targeted specifically at the 
UK end of the Stronghold Apache-SSL web server, Adam Back's RSA Munitions
Shirts,
the PGP and Crypto Software distribution site at Oxford, and Ross Anderson.

[*There are non-public-key systems where the TTP handles the secret keys,
but they're typically older or specialized military or banking systems,
where the TTP isn't an independent party, and are generally superseded by
public-key systems now that the technology is practical.]


#			Thanks;  Bill
# Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com
# You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp
#     (If this is a mailing list, please Cc: me on replies.  Thanks.)

Bill Stewart <stewarts@ix.netcom.com> writes:
> The big problem is that the document has a really warped view of the 
> cryptographic and business services that a "Trusted Third Party" 
> would provide, and some parts are expressed in quite broad language.
> For instance, it implies that the TTP is being trusted with private keys,
> otherwise there would be no way for it to recover anything.
> 
> On the other hand, from their Q&A:
> 	Q: Will a TTP be able to access an encrypted message ? 
> 	A: No. It is important to be clear that it is not envisaged 
> 	that the encrypted communication would be routed via the TTP. 
> 	Nor will the TTP encrypt the message, it will merely assist 
> 	(depending on the service offered) in the very complex area of 
> 	key management or Key Certification. 

I think that the paper implies in several places that TTPs, if they
offer a CA service for public encryption keys, will also be required
to hold the private keys, and to hand the private keys over to the
government on demand.

This Q&A is not contradictory with this interpretation.

When they say that the TTP will not be able to decrypt the message,
what they mean is that it would be able to decrypt the message if the
message were given to it, but that that's not the way the GAK
architecture works.

What happens is they first obtain a authorisation for a wire tap, then
obtain copies of your email.  Then they go to the central access point
and ask for your private key.  Then *they* decrypt your email.  `The
TTP will not be able to access an encrypted message' in the sense that
they won't give it the message to decrypt.

> If the TTP is not encrypting the data, they don't need the secret key
> or your private key.  They DO need your public key, to sign it, 
> so a second party can trust that a key they have is really yours.
> But you and the second party can use the signed keys to exchange a
> secret session key, or to sign documents, without the TTP's help.*

This is bypassing the intent of the key-escrow/GAK functionality of a
TTP.  There is a section which discusses this, and makes it a design
criteria that users not be able to by pass the GAK function, whilst
making use of the signature certification function.  Personally, I'm
not sure that this is possible, as there a whole host of ways around
it.  (Use the signature key in the way you suggest, superencrypt,
subliminal channels, stego, etc).

> The main time you want another party to have a copy of your keys
> is for stored data:  to cover the "employee dies" case 
> (the document explicitly permits companies to handle their own keys 
> without regulation, so no TTP is needed here),

This is the point which I think should be pushed: the only commercial
need for CKE (_commerical_ key escrow) is for _stored_ data.  Do you
see any corporations crying out to open their communications for
industrial espionage by DISSI, NSA, GCHQ, etc.?

> SO - what _is_ all this malarkey about "legal access" and "key recovery"
> and "key escrow" systems?  The document claims repeatedly that it's not
> purporting to regulate any of the conditions under which a Third Party
> would ever be Trusted with the keys you actually encrypted something with.

I think there are several sections which imply that the TTP must keep
private encryption keys for any public encryption keys it holds (and
that it must allow government access to them).  There are many places
where the presumption is made that the TTP has the key to release to
government.

Adam

-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`