FITUG e.V.

Förderverein Informationstechnik und Gesellschaft

UK: RIP ------- put all your letters inside a "Big Brown Envelope"

------- 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

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

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

Zurück