9 August 2000
Date: 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"
-----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-----