[FYI] (Fwd) UK: RIP ------- put all your letters inside a "Big Brown Envelope"

["Axel H Horns" <horns@ipjur.com>]

------- Forwarded message follows -------
Date sent:      	Wed, 9 Aug 2000 09:51:58 +0100
To:             	ukcrypto@maillist.ox.ac.uk
From:           	Dave Bird <dave@xemu.demon.co.uk>
Subject:        	RIP ------- put all your letters inside a "Big Brown Envelope"
Send reply to:  	ukcrypto@maillist.ox.ac.uk

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


RIP-busting suggestions........

=============================================================/''one''|

    ''Big-Brown Envelope'' Project

Abstract: Those ISPs with tradeunionist or 3rdWorld campaigning users
are concerned at use of the Regulation of Investigatory Powers bill
for delving into the content of email [or simply who sent what when]
to disrupt activities or harm contacts.

The solution may be to pass all mail in a "big brown envelope", or
user- to-server encrypted session, with a mail server in a free
country.  The components to do this are easily found; the choice is a
political and commercial one.

THREAT MODEL.  Why Threatened?  The General Skivers Union is a fairly
sedate body except for its attempts to unionise US-owned
ConglommoMunch fast food outlets, and giving space to the Bogzanian
Oil-Workers Democracy Campaign: to the annoyance of the Alabama Oil Co
and Imperial Oil.   Some information on its computers can also be used
to wiretransfer large amounts of its money.  The machines are in the
GSU open plan offices which sometimes uses volunteers,  or are to some
extent laptops or computers-at-home of its executive. The practical
consequence of information theft is that the union organisers at CM
branches would be fired, BOWDC informants in the Bogzanian government
would be shot, or GSU funds would be stolen.

BY WHOM? Conglommo-Munch do not take likely any threat to their
profits or control and  are  not above hiring free-lances to use
force,  at least  against property.   They may have intelligence
support, because - after cocaine and M16s - giving them commercial
information when Conglommo Foundation pay an agent in "consultancy
fees" is a common intelligence currency; anyway, promoting [corporate]
prosperity at home has always been an integral aim of intelligence.
AlabCo even more so, because oil is a military/commercial strategic
material.  

The nominally British, i.e. British-staffed, intelligence and security
services may be interested, because doing what they are told in
exchange for a supply of world-wide intelligence is a usual currency
with them; and it is long past the time they believed commercial
spying beneath their dignity.  They consider these activities against
British [economic] interests, and Imperial Oil to be a key strategic
asset: also they support large arms deals with the Bogzanian dictator.
 Less romantically, the GSU's funds may be quite simply a target for
thieves.

HOW? Whether the motive is political or just stealing funds, the
interloper aims to get hold of information and keep it quiet that he
has done so  -  without the owner being able to intervene or
preferably even know - for as little effort as possible. Methods will
include intercepting messages as they flow outside the building, even
if only ciphertext for which they hope to have a key later. Or include
intercepting traffic, which now needs only the signature of a junior
police canteen worker :-) , and yields almost as much information in
who talked to whom, how much, and when, as will serve to identify and
harass out of action main players in a strike committee. 

Or they will try steal-once-use-later, where they get hidden access to
a machine on one occasion either covertly or by threatening the holder
into one-off co-operation and later secrecy.  Here they are after [a]
plaintext of material sent encrypted or [b] keys they can apply to
material they intercepted as ciphertext:  it is best to have an option
that these can be "shredded" when no longer needed,  so nothing can be
yielded up under threat... and to limit the future usefulness of keys
taken now.

More extreme is entire theft, where they try to steal and operate an
entire node in the network with the one-off compliance of its owner.
The additional factor is that occasional changes of key need future
personal co-operation to stay on the network. Also their is a null
case where they buy/obtain someone's co-operation permanently: you can
limit what past material they had at time of defection, and you can to
some extent see that people know only such confidential material as
concerns them.




two''\=============================================================

DEFENCE MODEL.  If the black-hats are stopping the postman to read
postcards to and from you,  time to put letters in opaque envelopes
[individual message encryption].

If they are at the sorting office, beyond your control, photographing
all the address labels on your mail, it's time to put everything in a
"big brown envelope" and send it for sorting elsewhere i.e. user-to-
server encryption with a mail server owned and operated in a free
country.  All the ISP knows is the length of your overall session with
the foreign server:  the session contents are opaque to him.

If they break into your house for filed mail, with or without a
warrant, then perhaps you should be prepared by regularly shredding
old mail... and the envelopes it came in, if you don't want them to
know even the senders.  It is never a good idea to lie or expect
others to lie under pressure about what information is held: just see
that it is not held, and the shredding policy is recorded.

Some people may worry that with a sufficiently high-priced attack even
deleted files may be read off disks by microscopically examining the
edge of tracks. The solution in this case is to keep sensitive files
encrypted on removable Zip 100MB or Jaz 1000MB drives: junk old media
monthly, and be sure to re-format them with a lump hammer first.  No
technical solution gives perfect security, but such measures can make
it less and less likely anything will be found after more and more
work.

Security Policy. The passage of the immensely damaging R-I-P bill
despite the fact that it is clearly insane shows that parliamentary
process is inadequate to guard our liberties:  British Democracy would
be a good idea, but we don't have it yet. Threats to take content and
traffic, under laughable safeguards, from under our noses without our
knowledge or power to object -- and even more so to enter our homes
and co-opt us as spies on others, forced into silence by the threat of
being locked up in a cellar -- are a fist in the face to ordinary
Internet users.

Anyone whose data may have political or commercial implications, or
who likes their private life however dull to be private
thank-you-very-much, should have the means of making choices:  whether
they want their letters open, whether they want their mail-traffic
logable, whether it should be possible to take past correspondence
from their machine.   Or indeed the means to make a minimum compliance
to demands put upon them. No doubt they will mix various levels of
security for various broad levels of priority [though the experts
might urge them to "treat everything as highest security so the
sensitive items don't stand out"]. 

BIG-BROWN (OVERVIEW).  

What would the project look like?  A server would be set up somewhere
overseas  such as Ireland or Norway, on which the UK ISP hires
services, but which over  there and owned by local people so British
hold over it was minimal.  The users would be given a program to
communicate with it on CD, or told where to download it. The security
of their traffic would then be between them and the server.

All the unresolved questions are political/commercial in nature:  how
much would it cost, what would be the demand for it, who do we know
over there, are we sure their laws and government would protect us
adequately from overseas interference in it. The technical solutions
to this are then straightforward [but, if it is not strategically
correct, they are merely answers looking for a question to fit them].
This is really for ISPs to decide; my further details are on the
technical aspect.

How hard would it be to use?   Not very hard at all.  It is vital that
the user  can be led through what looks like, to him, a
straightforward process of signing up, then just send and read mail
through his usual mailer program to our interface. I have outlined
what a sign-up session might look like, and written some code.

==========================================================/'''''three

How complicated are the internals?  Slightly more complicated than
present crypto systems, but not that hard to put together from the
pieces provided in the PGP or free-PGP libraries. And you don't have
to know how the engine works to drive a car. What would be at the
server end?  There is almost certainly code around which allows you to
set up "this web-page is a mail-service:  click here to sign up, click
here to collect your mail, click here to compose mail on-line or send
prepared mail."  

With slightly more work you could write custom scripts to do things
like "Only send mail from me if it has my PGP signature" and/or "...if
I have PGP encrypted it to someone."  Or "only deliver mail to me if
it has a valid PGP signature to a key on one of the usual servers", or
"if it appears to be encrypted to my public key." A user who chose to
do those things would block the mail-spamming which is the bane of
hot-mail accounts, and be pretty sure nobody else could hack his
mailbox successfully.  This is in addition to the session crypto
provided by the client.

How practical is all this?  I asked a colleague who is doing
philosophy at LSE,   but knows PERL-scripting for servers in practical
detail, how hard it would be to actually implement this: "not hard at
all is the answer."  Nothing in it is that much different from the way
many present programs work, and what is new in overall nature is
merely a matter of bolting together existing components.  It could
easily be done in PERL or Java on the server.  A client program for
users could easily be made in Java, or in PERL - being sure to ship
one of the existing PERL interpreters for their machine - for many
different kinds of user machine.  

Some of the functionality we want is embodied in SSL (Secure Session
Link), and rather more in SSH (Secure SHell) which already exist,
although users would have to make sure that they updated old browsers
to the more recent 128-bit crypto modules. None of it would be that
difficult to write anyway, given a small amount of programming effort.
 


BIG-BROWN (EASE OF USE).  
On the next page I have drawn out in WinWord the simple series of
steps for a tabbed dialog box ("wizard") to guide the user through
setting up an account.  As an exercise, and because it looks clearer
than on paper, I also wrote some actual dummy code to produce an
interface like this. It takes surprisingly much code to produce visual
interfaces -- perhaps 6 or 7 pages for this - but much of it can be
automated with Visual Basic or Visual Java.  I did this in a single
afternoon without sweating too hard [and I'm not even fully up to
speed on using JBuilder], so it is not vastly difficult; see
http://www.xemu.demon.co.uk/BigBrown.jar  .


BIG-BROWN (INTERNALS).
The internal systems, although not visible to the user, would be a
touch more complicated than current systems.  I assume readers know
the basics of public-key crypto before going on to something slightly
more complicated.  We would probably have multi-layers of cryptography
as follows.

The server end has a permanent "identifying" public key which is
certified through to the user as valid by various means.  It uses this
to sign assorted temporary public "keys-of-the-month" it has created:
when they cease to be used, they are erased.  The purpose of this is
that, if the interlopers do not compromise all of these keys in the
current month then they are not into the message text.  If they have
private-key control of the main key then they can create new
temporaries.

The client end ditto has the key which it permanently uses with the
server. It uses this to certify a temporary public key which it keeps
in memory and deletes at end of session.  Private key-control would
create new temporary keys, but it cannot decrypt a session key which
was encrypted in one of the old keys (and hence the text which was
encrypted in that).  


''four''\======================================================



            Diagrams omitted 









===========================================================/''five'''

 The client starts with only the protection of one of the server's
public keys-of-the-month. He encrypts to this what his current
temporary public key is, though of course only he has the decode end. 
The server obliges by proposing a 128-bit IDEA session key apparently
decryptable to the client's temporary key.  Now we have a session key
known each end.

Some people have proposed a belt-and-braces approach in which there is
also a mutating idea key.  When the account is established the agreed
key modifier at  each end is zero.  At the end of a session, a key
modifier is agreed based on the hash of the session. Next time round,
you don't get the correct IDEA key... you get one which will be
correct when XOR'ed with the key-modifier.   Schemes of this kind used
alone can only be unzippered starting from the first message onwards
with  none missing from the sequence.  For extra fun either end might
want to propose additional material xor'ed into the key modifier,
though this has less application here. [Hmmm. Told you it was
complicated. But all of this is just calls to existing crypto library
functions].

SMALL ENVELOPES, AND SHREDDERS.

There are certain things that concern me about PGP as a "per-message"
envelope for nullifying interception of content at the ISP, chiefly as
concern making it easier to get started with so more people will use
it. I am also interested in a variety of "shredders" for dealing with
demands for filed plain-text of old messages received, or with keys
that will still decrypt old intercepted messages [by saying and
proving you having got them].  The latter requires belt-and-braces as
above.

(a) Making small-envelopes easy.
I like the seamless integration of the Turnpike mailer to PGP and  far
as encrypt / decrypt and sign/verify goes, but I would very much like
to see it prompt the user with two Wizards.... one about making the
key and attaching a photo, the other to lead through the phone
verification steps a few days later; I found these aspects moderately
hard as a newcomer to the program, and feel help is needed. I did a
piece on usenet concerning this, as below.  I am also all for
encouraging key exchange and verification through webpages with keys
and photos on webpages of our various organisations.

On Mon, 31 Jul 2000 21:54:28 +0100,
in demon.ip.support.turnpike, art<TooWvzGEeeh5Ew1T@xemu.demon.co.uk>,
re WISHLIST: Turnpike could do its own Make/verify key Whizzard, Dave
Bird <dave@xemu.demon.co.uk> writes: >WISHLIST:   Turnpike could do
its own  Make/verify key Whizzard

(b) Installing shredders. 
I am interested that mailers allow you to set up a clear storage
policy as system default and then per addressee between store
encrypted messages: In clear, Encrypted to me, Encrypted to recipient
(default), Or not at all..................... and be able to print out
that the policy is and when it was last changed.  I am also looking at
some sort of key modifier system based on hash of the last message. 
It may be that you have to keep a small amount of current key
information i.e. if your new message fails to get through and cause a
change of modifier then you know how to reach the old key.  Also it
would be nice to prompt every so often to "phone me with some extra
modifier info":  thus even a fully stolen system cannot be sustained
unless you can compel permanent, not one-off, compliance.  

DAVE BIRD,
2000/aug/08
My key fingerprint 2B0D 5195 337B A3E6 DDAC  BD38 7F2F FD8E 7391 F44F
My physical signature................. verifying I own the key
identified above.

''six''\============================================================


Proposed Response to RIP
Author: Damian Steer                 Date: Wed Aug 2
Introduction
http://www.shellac.freeserve.co.uk/ripbust.html
The RIP Bill, which passed into UK law recently, poses a threat to the
(supposed) privacy enjoyed by many internet users and also the
security of commercial transactions on the internet. This paper offers
some suggestions for how one might reasonably preserve privacy and
security. The particular threats from RIP that I deal with are · The
interception of communications. · The requirement that individuals
hand over keys to decrypt encrypted communications. These threats can,
I believe, be reduced using currently available technologies. My
proposals suggest a manner in which ISPs can aid clients. The
fundamental point in all which follows is that the ISP's servers must
be locate outside the UK. These methods are of no use if the server
can be monitored directly.

Secure Sockets Layer (SSL)_____________
SSL is a widely used technology which provides encrypted pipelines
between a client and server. It is most commonly used for web
communications where security is paramount, for example commercial
transactions. (It was been the case that browsers shipped outside the
US came with rather weak encryption, but this has now changed.) In
addition to this it provides authentication methods to ensure that the
server is indeed the server the client wants (and, optional, methods
to verify the clients identity). SSL works in the following way (I
shall skip the authentication details here, and much of the detail).
The client A wishes to connect to server B. B has a public and private
key for encryption and decryption respectively. B sends its public key
to A. A then creates a conventional key and sends it to B, encrypted
with the public key. A and B now share a conventional key, which they
can use to encrypt their communications. The conventional key is
forgotten at the end of the session.

This system achieves much that we require. Communications are
encrypted, and the user does not have the knowledge to decode these
communications, even if ordered.

However there are two potential problems. Firstly the server's private
key is all that is needed to decrypt the entire communication.
Secondly there is the question of what services can use SSL. In
principle the answer is 'any'. However, currently SSL is principally
used for HTTP. Some mail programs (e.g. Outlook Express and Netscape
Mail) can use SSL. However for better integration one really need to
create an SSL 'tunnel' to provide wider services, over a range of
client software. Such tools are rather scarce.

Secure Shell (SSH)_____________________________
SSH is very similar to SSL. Its main use is to provide secure
connections for telnet-style connections. It can, however, provide a
great deal more than this as we shall see.

SSH operates much as SSL does, though with a variation. Once again I
will skip much of the detail. In SSH a client A connects to a server
B. B has two key pairs. The first, X, is a key pair which never (or
rarely) changes. This (public) key is sent to A to provide
authentication, in part. A second key pair, Y, is temporary, and held
in memory always. This key is changed periodically, say every hour. B
sends A Y as well. A picks a (conventional) key and encrypts it to X
and Y and sends this to B. A and B now share a conventional key, to
use for communication. Immediately SSH scores over SSL in that, even
if someone has the server key, X, there is no way to recover the
communications since Y has been destroyed.

In addition SSH provides a way to tunnel arbitrary communications
across the encrypted pipe. SSH can 'join' a local port on the client
to a port on the host. So, for example, if port 110 on the localhost
is connected to 110 on the server then any mail client can connect to
the localhost and download mail via pop3 securely.

This capability is available for unix, windows and macintosh clients,
often with free software. SSH allows security for clients with,
usually, a minimal financial cost, since the SSH software is cheap,
and the user can continue to use their current software.

NOTE: ftp is slightly problematic, since it uses ports in a curious
way. This is not too hard to circumvent. One particular use of SSH
would be to set up a web proxy on a server, and have the user access
this via SSH. This would prevent monitoring of web browsing behavior.

Conclusion . Does this circumvent all the problems of RIP? Clearly
not. All it does is help establish secure communication to servers
outside the UK. This is, at least, a start. 

=====================END=OF=DOCUMENT================================


- --          .       ___                     .       
      '-|:::|@\-[x]/__/|              .-|:::|@\                    
        ||--|"" .  |__|/                ||--|"" .                   
          '-|:::|@\      (")"""-.         .-|:::|@\  --+--.(")"""-'   
               
            ||  |""       ||""|             ||  |""    '   ' |""|

 DEMOCRACY: two wolves & a lamb     LIBERTY: a lamb with a kalashnikov
        voting what's for lunch     contesting  the  vote



-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBOZEbrn8v/Y5zkfRPEQJ/AwCgissUIHCqyp1RhcdJ3rxpO+kCvdAAoIBp
ApSce2xzshKYuMbVAbMTq7oN
=BWEX
-----END PGP SIGNATURE-----


------- End of forwarded message -------