Campus-Wide Use of Public Key

8/6/2019 Campus-Wide Use of Public Key

http://slidepdf.com/reader/full/campus-wide-use-of-public-key 1/59

Campus-wide use of public key

cryptography

Master’s Thesis

Lauri Karppinen

Helsinki University of Technology Teknillinen korkeakouluDepartment of Computer Science and Tietotekniikan osastoEngineeringTelecommunications Software and Tietoliikenneohjelmistojen jaMultimedia Laboratory multimedian laboratorioEspoo 2002



HELSINKI UNIVERSITY OF ABSTRACT OF

TECHNOLOGY MASTER’S THESIS

Author: Lauri KarppinenName of thesis:

Campus-wide use of public key cryptography

Date: May 30th 2002 Pages: 8 · 51

Department: Department of Computer Science Chair: T-110and Engineering

Supervisor: Professor Teemupekka VirtanenInstructor: Sanna Liimatainen, M. Sc. (Tech.)

The increased intake of students and demands for faster results have forced theuniversity to search for and develop new tools and learning systems to automatethe management of courses.

The Telecommunications Software and Multimedia laboratory at Helsinki Uni-versity of Technology has since 1996 experimented with a new kind of e-mailbased learning system. The TML Learning System successfully combines PGP

secured e-mail, student management and course management into one elegantpackage.

In order to the TML Learning System useful for other laboratories and univer-sities, a common infrastructure for cryptographically secured e-mail must becreated.

In this thesis we set up a public key infrastructure on HUT campus. The systemwill be based on HUT Computing Centres e-mail system and is ready to bedeployed with a five-year timeframe.

Keywords: TML Learning System, PGP, e-mail, public keycryptography

Language: English

ii



TEKNILLINEN KORKEAKOULU DIPLOMITYÖN TIIVISTELMÄ

Tekijä: Lauri KarppinenTyön nimi: Julkisen avaimen salausjärjestelmän käyttö kampuksella

Päivämäärä: 30. toukokuuta 2002 Sivuja: 8 · 51

Osasto: Tietotekniikan osasto Professuuri: Tik-110

Työn valvoja: Professori Teemupekka VirtanenTyön ohjaaja: DI Sanna Liimatainen

Kasvanut opiskelijoiden sisäänotto ja paineet nykyistä nopeampaan valmistu-miseen ovat saaneet korkeakoulun etsimään ja kehittämään uusia työkaluja jaopetusjärjestelmiä kurssienhallinnan automatisointiin.

Tietoliikenneohjelmistojen ja multimedian laboratorio Teknillisessä kor-kea-koulussa on vuodesta 1996 lähtien kehittänyt uudenlaista sähköpostin väli-tyksellä toimivaa opetusjärjestelmää. Tämä järjestelmä yhdistää PGP-salatunsähköpostin sekä oppilaiden ja kurssien hallitsemisen.

Jotta muutkin laboratoriot ja yliopistot voisivat käyttää TML:n opetusjär- jestelmää, täytyy ensin luoda yhteinen pohja salatun sähköpostin käytölle.

Tässä opinnäytteessä rakennetaan julkisen avaimen salausjärjestelmä TKK:lle.Järjestelmä laajentaa TKK:n atk-keskuksen olemassaolevaa sähköpostijär- jestelmää ja se voidaan luoda viidessä vuodessa.

Avainsanat: TML:n opetusjärjestelmä, PGP, sähköposti, julkisenavaimen salaus

Kieli: englanti

iii



Acknowledgements

This work has been carried out in the Telecommunication Software and Multime-

dia Laboratory at the Helsinki University of Technology.I’m grateful to a number of people who have helped me with the thesis. First of all,I would like to thank my instructor, M.Sc. Sanna Liimatainen, for her guidanceduring this work.

I also wish to thank my supervisor, Professor Teemupekka Virtanen, for his pa-tience and the opportunity to work in the TML.

Also special thanks to everybody who contributed to the FROST project. It wasan experience.

Otaniemi May 30th 2002

Lauri Karppinen

iv



Contents

Abstract ii

Tiivistelmä iii

Acknowledgements iv

1 Introduction 1

2 Background 3

2.1 TML Learning System . . . . . . . . . . . . . . . . . . . . . . . 32.1.1 Other learning systems . . . . . . . . . . . . . . . . . . . 4

2.2 Brief introduction to public key cryptography . . . . . . . . . . . 4

2.3 Pretty Good Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 Trust and public keys . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.1 The “web of trust” . . . . . . . . . . . . . . . . . . . . . 8

2.4.2 Public Key Infrastructure (PKI) . . . . . . . . . . . . . . 9

2.4.3 Comparison of “Web of trust” and PKI models . . . . . . 9

2.5 The HUT computing centre . . . . . . . . . . . . . . . . . . . . . 10

3 The problem 11

3.1 Research goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 The importance of key distribution and management . . . . . . . 12

3.3 Key management problem . . . . . . . . . . . . . . . . . . . . . 13

3.3.1 PGP Keyring . . . . . . . . . . . . . . . . . . . . . . . . 14

v



3.3.2 Key escrow . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3.3 Additional revokation keys . . . . . . . . . . . . . . . . . 15

3.3.4 Authentication and trust . . . . . . . . . . . . . . . . . . 16

3.4 Other problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4.1 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4.2 The choice between commercial and “free” solutions . . . 17

4 The plan 19

4.1 Extending the mail system . . . . . . . . . . . . . . . . . . . . . 19

4.1.1 The mandatory public key . . . . . . . . . . . . . . . . . 19

4.1.2 The automated internal secure e-mail . . . . . . . . . . . 21

4.2 Required modifications to the current system . . . . . . . . . . . 23

4.2.1 User support issue . . . . . . . . . . . . . . . . . . . . . 23

4.2.2 Key server . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.3 Mail user-agents . . . . . . . . . . . . . . . . . . . . . . 26

4.2.4 Integration with student-management tools . . . . . . . . 27

4.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.1 Time-frame . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3.2 Immediate costs . . . . . . . . . . . . . . . . . . . . . . 28

4.3.3 Annual costs . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3.4 The new and remaining unsolved problems . . . . . . . . 29

4.4 Alternative or abandoned schemes . . . . . . . . . . . . . . . . . 31

4.4.1 HST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4.2 PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4.3 Biometrics . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Conclusion 33

A Attack trees 35

B Comparison of keyserver products 38

vi



B.1 Feature matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

B.2 Evaluation notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

B.2.1 MIT Public Key Server (PKS) 0.9.4 patchlevel 2 . . . . . 38

B.2.2 NAI PGP Keyserver 7.0 . . . . . . . . . . . . . . . . . . 39

B.2.3 Novell Certificate Server 2.0 . . . . . . . . . . . . . . . . 40

B.2.4 RSA Keon Certificate Authority . . . . . . . . . . . . . . 40

B.3 FROST project . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

C Flexible user agents 43

vii



List of Figures

2.1 Public key encryption and decryption . . . . . . . . . . . . . . . 5

2.2 Digital signing of a document . . . . . . . . . . . . . . . . . . . . 5

2.3 A PGP-signed message . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 A small web of trust . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 A PGP fingerprint . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1 Operation of SMTP . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1 A 1024 bit RSA PGP public key . . . . . . . . . . . . . . . . . . 20

4.2 A public key signed by HUT CA . . . . . . . . . . . . . . . . . . 214.3 Sending secure e-mail inside HUT campus . . . . . . . . . . . . . 22

4.4 A Finnish national HST ID-smartcard . . . . . . . . . . . . . . . 31

viii



Chapter 1

Introduction

Computer aided learning is a topic of which there are many different visions andinplementations. The basic idea of using computers to aid human learning hasbeen a limited success. The use of computers to visualize different consepts andtechniques has become very popular. The technical sciences have used Computer-aided Design (CAD) tools, specialized mathematic tools and communication toolsfor years. Applying computers into more traditional learning has been a muchmore mixed success.

Teaching methods in the Helsinki University of Technology are for a large parttraditional. There are courses with lectures, exercises and exams. A predefinedset of courses constitutes a degree. The exercises and especially exams are al-most always of traditional variety with answers written on paper which is thensubmitted to the course staff.

Telecommunications Software and Multimedia laboratory (TML) has for severalyears experimented with computer-based alternatives to the traditional paper re-turnings. On the biggest TML courses all homeworks and their results are trans-mitted and managed electronically.

The TML Learning System[14, 15, 28], features a completely computerized way

for students to register, manage and complete their courses on the HUT. Two-waycommunication between the students and the university staff is done via electronicmail which is authenticated and secured with public key cryptography. The stu-dents may get their signed and encrypted assignments via e-mail and return themin a similar fashion. Students even have an option to have a “computer exam”which is a controlled situation where the students get an electronic version of thecourse exam and write their answers down into a WWW-form using all the stan-dard text-processing aids like cut, copy and paste. Thus all authentication, groups,timestamps and examinations are completely automated.

1



CHAPTER 1. INTRODUCTION 2

The TML Learning System enables course staff to manage a far larger number of

participants on the courses than before without lowering the quality of education.

The TML Learning System is complex system and depends on multiple sub-systems and services. This thesis focuses on the use of Pretty Good Privacy[6,35, 5] or PGP application which is used to cryptographically sign and encryptmessages sent via our system. This work will present the problematic issues of implementing a PGP infrastructure on a campus-wide scale with ca. 13000 userswith multiple roles and levels of trust. This work will also present a sound modelfor the said infrastructure which will allow a University or a medium-size corpo-ration to take advantage of modern cryptography on securing their internal and tothe limited degree their external e-mail communications.

This work is laid up in the following manner: First we briefly introduce the readerto the elementary consepts of cryptographic signatures and public key cryptog-raphy. We will also briefly explain the main trust models used to tie the crypto-graphic keys to real persons, namely PGP’s “web of trust”[35] and the Interna-tional Telecommunication Union’s Public Key Infrastructure (PKI)[9].

The cryptographic methods and trust models are explained purely on a conseptuallevel. No attempt is made to explain the underlying theories and algorithms, andthe reader unfamiliar with these is encouraged to seek further explanation fromthe literary and online sources given in the chapter.

Next we explore the problems associated with using PGP on a large scale userbasewhere one person cannot personally validate the keys he might need to use in orderto send mail to unfamiliar recipients.

In chapter four we present a model infrastructure ready to be applied on a HUT-style environment with loose ties between various parties and constant migrationof personnel.

After a brief conclusion various technical details are discussed. In addition, areview of products that can be used to build the PGP infrastructure is described inthe chapter four.



Chapter 2

Background

2.1 TML Learning System

The TML Learning System could be described as an electronic mailing systemwhich provides a standard way for students to roll on and complete courses bye-mail and World Wide Web. Signing on a course, returning and acquiring assign-ments and communicating with course staff are all done in a standardized way.Even the exams are done online although under supervision.

The TMLs system started in 1996 as an odd collection of Perl-scripts used andwritten by the laboratory’s teaching staff to automate their repetitive tasks. Whilere-written several times after it’s introduction, the system still consists of multiplescript modules for fast and easy modifications during the terms.

The most significant feature of the TML Learning System concerning this work isit’s use of Pretty Good Privacy for securing the communications between studentsand staff members. Every participant in the TMLs system has a PGP key-pairand all authentication is done with cryptographic signatures. All e-mail home-work submissions and enrollments are also encrypted with PGP. Courses’ official

announcements are also signed with the specific courses secret key.As of writing all the major high-volume telecommunications courses at TML havestarted using the TML learning system and there is a joint effort with other com-puter science-laboratories to expand the system for a wider audience. The expan-sions requires several upgrades to the current system. One of the things that needwork is PGP key management explored in this writing.

3



CHAPTER 2. BACKGROUND 4

2.1.1 Other learning systems

There are also other large learning system projects currently under construction atHUT.

OTUS is a WWW-based course-management system developed by Innofacor Oyunder contract by the Laboratory of Information Processing Science of HUT.OTUS has been delayed several times and has gone through two pilot-programmesduring the writing of this thesis.

OODI is an ambitious attempt to create a common student-management systemshared by multiple universities. There are also plans to extend OODI to handle

course management as well. Like OTUS, OODI too has had its share of delaysand there is a lot of sceptism about the outcome.

2.2 Brief introduction to public key cryptography

One of the big issues in the application of encrypted e-mail traffic, and cryptogra-phy in general, is key management. How do we distribute the cryptographic keyswhich allows us to decrypt the encrypted message between all parties involved?Telecommunications cannot be considered secure, and personally meeting all the

present and future communication partners is often impossible. Due to this prob-lem alternative methods of cryptography have been developed. One of the popularsolution to the problem of shared secret is public key cryptography.

Public key cryptography approaches the problem with special key pairs. One key,called a “public key”, can be used to encrypt data in a way that only the secondkey, a “secret key”, can decrypt it. Figure 2.1 shows the usage of the keys whenwe send a message encrypted with the recipients public key. Since the first keycannot decrypt the data it encrypts, this key can be distributed publicly throughthe WWW, e-mail, fax, or even printed on paper cards.

Even more useful than encryption is the ability to digitally sign documents using

the secret key. It is used to encrypt a unique checksum value calculated fromthe data[21, 26, 18] which is appended to the original data. All the copies of thepublic key can then be used to validate integrity of the signed data by checking if the checksum matches the data. This property of the public key cryptography isone of the most important to the operation of electronic learning system at TML.Figure 2.2 shows how a message is first signed and then sent to a recipient.

Technically, the two public key algorithms used at time this thesis is written arebased on the asymmetric mathematical problems of factorization and calculating




Encryption Decryption

messagemessage encrypted message

publickey

secretkey

Figure 2.1: Public key encryption and decryption

signature

messagesignedmessage

Communication pathsuch as the Internet

"ok"

messagesigned msg

SENDER RECIPIENT

Hashfunc Hash

func

=

Figure 2.2: Digital signing of a document

discrete logarithms in a field [26]. Factorization and calculation of discrete loga-rithms are believed to be operations which are several magnitudes more time con-suming than their reverse counterparts, multiplying and exponentiation. It shouldbe noted that this has not been mathematically proven to be true. It might wellbe that a new method of factoring and calculating discrete logarithms is foundtomorrow, rendering these public key algorithms useless[2]. The mathematicalbackground of public key cryptosystems is well described in several basic texts of cryptography[21, 26, 18].

The largest weakness of the public key cryptography is the heavy calculationneeded for every operation. In fact, public key cryptography is several magni-tudes slower than the conventional symmetric cryptography with the same secretkey shared between all participants. The required key sizes are also ten-fold withpublic-key encryption ie. the minimum key-sizes generally considered “safe” forpublic key algorithms is 1024 bits but only 128 bits for conventional symmetricalgorithms. Because of this many protocols and applications use hybrid encryp-tion techniques: they use public key cryptography to negotiate and distribute con-




ventional secret keys which are then used for encryption and decryption of the

transmitted data.

2.3 Pretty Good Privacy

The most popular and publicly spread e-mail encryption software utilizing publickey cryptography was written in 1990 by Philip R. Zimmermann. The software,called Pretty Good Privacy or PGP, provides both encryption and signing opera-tions along with some utility services such as data compression and character setencodings. It can be considered the de-facto standard of e-mail encryption.

PGP features hybrid encryption where the messages transmitted are first conven-tionally encrypted with a symmetric key. This key is then encrypted or signed orboth with a public key algorithm. We might not want to encrypt, for example,public announcements but we might want to sign them to show that they are notpranks! The whole encrypted package including the message and symmetric keyis then transmitted via e-mail to recipient. The recipient can decrypt the messagesembedded one-time encryption key with his own secret key and then decrypts thedata with the one-time key. As an example, figure 2.3 shows a PGP-signed e-mailmessage.

It is possible, and often very desirable, to encrypt a single message with multiplepublic keys. The encrypted message can then be distributed on public channelsand every member of the group whose public keys were used can use his secretkey to decrypt the message.

Today, PGP can use both keypairs based on factorization (RSA-algorithm) or dis-crete logarithm problem (Diffie-Helman-algorithm and DSA-signatures)[18]. In-ternally, PGP uses traditional single key ciphers such as IDEA, CAST and 3DES,for encrypting and decrypting, and hash algorithms such as MD5 and SHA-1, forcalculating checksum values[22]. Various easy-to-use graphical user interfacesand interface modules to popular e-mail clients have been created in order to help

people overcome the steep learning curve of the command-line client. Some of thee-mail clients and their PGP plug-ins are introduced in section “Mail user-agents”in Chapter 3[24].

In year 1998 the Internet Engineering Task Force (IETF) created an open stan-dard called OpenPGP[3] which formally qualifies the wide-spread use of PGPand helps to create alternate, compatible software. One of the first independentPGP-compatible (and OpenPGP-compatible) software package was launched in1999 by GNU, and it was called GnuPG, the GNU Privacy Guard[7].




-----BEGIN PGP SIGNED MESSAGE-----

Hello everybody!

Due to the difficult financial situation we are in, all

this years summer bonuses have been downsized.

I would like everybody to understand that this is just

a temporary measure to boost the company profitablity

during the Q2/2002. The bonuses will be restored in good

time for x-mas. :-)

- - The Boss

-----BEGIN PGP SIGNATURE-----

Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQCVAwUBPPDhAH1JaD4102XRAQGRNQP/SpjNoETacOdYm3D83S/h7IP2ye417jIs

gwyyaUQa3QSpQtHQ5SMYTPdsvvqi/yvpa+4hZgTe+YIdm/aSTnUm/vNdoJghF02u

nZjxCec/RkmMLvca388wwhwe0vPXBBAOoGX3tfnjMCg7HxPaILwwKq11rXER2qrw

D+kKiSG0yyk=

=OtSI

-----END PGP SIGNATURE-----

Figure 2.3: A PGP-signed message

Because there are several independent but inter-operable applications present onvirtually all operating systems[5], and because many of them are already set upon HUTCCs general purpose network, the OpenPGP standard can safely be usedto provide e-mail encryption and authentication services in the TML LearningSystem. The users can freely choose the environment they prefer and still be ableto use PGP, or GnuPG.

2.4 Trust and public keys

Typically a user of PGP has his own local keyring which is a small single-filedatabase usually located at the users home directory. In the keyring he has his ownsecret key and a number of public keys of his communication partners receivedfrom various sources. How can the user be sure that these public keys belong tothe right people? How can he be sure that nobody has tampered with the keysduring their transmission? Several kinds of trust models have been created to helpsolve the problem.






2.4.2 Public Key Infrastructure (PKI)

The PGPs “Web of trust” solves the public key management problem by formingsmall networked communities with strong often personal ties. This is not suitablefor business use as you will constantly be meeting and contacting new people.The Public Key Infrastructure (PKI) introduced by the International Telecommu-nications Union approaches the problem from the business-oriented perspectivewith a hierarchical trust model[9].

In PKIs X.509 protocols, the public keys of the users are wrapped in certificatesby appointed trusted third-parties, Certificate Authorities (CA). There are differ-ent kinds of certificates, some for identifying persons and some for identification

of computers and services. When a user starts using, for example, encrypted e-mail, he first requests a personal certificate from his local CA. The local CA hasbeen appointed by a root CA and it has been given the rights to generate new cer-tificates. The CA generates a public key keypair similar to PGP and wraps themalong with the users name and other contact information into a certificate. TheCA signs the certificate with its own secret key which in turn is signed by a higherlevel (root) CA. The public key is placed into the CAs repository. The user getshis certificate and installs it into his e-mail client. When the user starts to sendencrypted e-mail to a recipient, the e-mail client fetches the recipients public keyfrom the CA. If the CA doesn’t have the key, it queries another CA higher in the

hierarchy all the way up to the root CAs, until the key is found.

2.4.3 Comparison of “Web of trust” and PKI models

The main difference between the PKI and “Web of trust” is the relationship be-tween a person and the trusted third party who vouches for the person. In PKIthe voucher is a global self-appointed organization who sells trust for a periodtime. The trust is delegated down to national levels but ultimately is providedby a company far away with profit expectations. What happens to the valuableclient information database the CA has (possibly including the secret keys of allclients!), if the company drift into financial troubles?[4]

The “Web of trust” on the other hand is cumbersome to create and upkeep. Thereare no guarantees that, for example, the public keyservers are kept operational inthe future. There is also no entity responsible for possible frauds and problemspossibly resulting in financial damage to the users. In this light it is easy see whyPKI has received more favorable attention from companies.

None of the schemes is immune to human error: if somebody generates keyswith somebody elses name on them, and starts distributing them hoping to catch




some data meant for the victim, there’s always a chance of success. PGP relies

on each user to carefully sign only keys they personally can vouch to be real. Itdoes not enforce or force this behavior. PKI does the same but with CAs insteadof individual users. Practice has shown both schemes to be equally vulnerable.For example, in March 2001 Verisign, a root CA, was fooled into issuing twocertificates with the identifier “Microsoft” to an individual posing as a Microsoftemployee[19, 31].

2.5 The HUT computing centre

The Helsinki University of Technologys Computing Centre (HUTCC) is a sepa-rate unit apart from the departments that provides and supports the general purposecomputers and accessories in the HUT campus area[11]. The HUTCC administersthe main network and provides services such as e-mail to the students and staff of HUT. It also publishes a large number of guides and documentation for the HUTcomputing environment.

The HUTCC provides disk space for all its users and uses a Network Filesystem(NFS) to help them access the space from different machines.

The HUT Computing Centre has for a long time helped its users use PGP by

installing PGP and GnuPG into their general purpose Unix computers. While un-supported, the users can relatively easily create a new keypair into their accountshome directory. Unfortunately the only documentation provided are the manualpages supplied with PGP. What makes the matter worse is that the versions of PGP vary between machines and operating systems, and so does their usage.



Chapter 3

The problem

3.1 Research goal

The aim of this thesis is to study and design an infrastructure needed to able thestudents and staff of Helsinki University of Technology, or a similar medium-sizedorganization, to efficiently and easily send and receive secure e-mail.

Our infrastructure will enable every operative in the organization to send and re-

ceive internal e-mail so that the message encryption and authentication will beboth efficient and transparent to the user. The infrastructure will also allow secureexternal e-mail communications with little extra effort to the user.

The infrastructure should also support the current electronic learning system usedat the Telecommunications Software and Multimedia Laboratory at Helsinki Uni-versity of Technology and thus allow other laboratories of HUT to use the system.

The predetermined requirements for the system are the following:

̄

The e-mail system must be secure against eavesdropping from the other

users in the organization.

̄ It must be possible to authenticate the communicating parties online sothat automated tools can be developed to help manage user data. The sys-tem must be able to support the current projects for student management,namely TML’s own learning system and the upcoming systems like OTUSand OODI and other similar systems.

̄

The infrastructure must be able to scale to a larger user base.

11



CHAPTER 3. THE PROBLEM 12

̄

The infrastructure must be open and not dependent on any single third party

or vendor.

̄

The system must be equally suited and available to all e-mail users at HUT,human or automaton.

These requirements have been set by the Telecommunication and MultimediaLaboratory (TML) at the Computer Science Department of the Helsinki Univer-sity of Technology.

3.2 The importance of key distribution and man-agement

In TML, we want to use e-mail to electronically manage a large number of stu-dents and their assignments. In detail, we would like to be able to reliably andeasily send and receive private messages and homework submissions from a pre-determined set of users in a way that is secure against eavesdropping and imper-sonation.

The problems we face are e-mail protocol itself, the correct application of proper

cryptographic methods, decreased ease of use of the e-mail system, and non-technical issues of politics and laws.

Security and privacy Online privacy is a rather complex issue. The electronicconversation between the staff and the user should be secured so that no third-partycan determine what is being transmitted. The parties of the conversation shouldalso be able to verify that they are communicating with the correct recipient. Thisrequires among other things robust cryptographic protocols which need a reliablemethod of distributing the encryption keys of the recipients inside (and outside)the organization. Also to be ever actually used, the organizations security and

privacy policies should take into account and encourage the use of more securee-mail practices.

E-mail Electronic mail as a protocol[25] has a number of well known problems.First, the message delivery system is not 100% reliable. The message delivery de-pends on multiple untrusted machines on the network and anyone of these can failto pass the message onward to the recipient. Secondly the messages are routedthrough to the recipient via a route undetermined at the time the message is sent




(Figure 3.1). Third, the message including its addresses and other header infor-

mation can easily be read and altered at any point along the delivery path. Thereis no way to determine if, for example, the sender’s address is valid or a forgery.To the application presented in this thesis it should be also noted that no attemptsof message privacy or confidentiality were designed into the protocol. (They werenot relevant issues back in 1982 when the standard was drafted[25].)

E-mailclient

E-mailclient

Sender Recipient

Internet mail servers

Figure 3.1: Operation of SMTP

Cryptography Cryptographic methods for message encryption and signing arenot easy to understand nor easy to implement flawlessly. In this work we focus

on PGP which has been found, during years of studies by experts in the field of cryptography, to be a rather reliable application[30]. PGPs user interface thoughhas not evolved a bit since it’s first versions. Many people find PGPs command-line user-interface confusing and hard to use. Most of the troubleshooting andhelpdesk activity during the TML courses with the TML Learning System areabout problems with the PGP.

3.3 Key management problem

In public key cryptography every user that wants to send or receive secure elec-tronic mail needs a valid keypair. The user also needs access to this keypair andto the public keys of all the other users of secure mail. In a networked environ-ment, the user might need to use electronic mail from multiple computers, allwith different operating systems. This creates a need for some kind of key sharingscheme. We will take a closer look at the various ways PGP stores its keys.

The cryptographic keypair needs maintenance. In order to keep up with the in-creasing processing power available for breaking the keys, the keys should be




replaced periodically with longer ones. This will also limit the possibility of dam-

age in a situation where somebody has managed to steal a copy of the secret key.To protect the secret key, the usage of the secret key is locked with a long pass-word called passphrase. Without the passphrase the key cannot be used to signmessages or decrypt message encrypted with the public key.

The experiences from different computing environments has shown that users tendto either use bad passwords and passphrases or forget them altogether[29, 10]. Asall public key operations need the passphrases, this is a major problem. Other user-related problems are the special cases when the keys fall into wrong hands andshould be erased. Due to the nature of public key cryptosystems, this is usuallynot possible. The keys must be revoked instead - an operation which needs the

keys passphrase.

Various methods have been developed to solve the last two problems. These arethe key escrow system and the creation of additional revokation keys.

3.3.1 PGP Keyring

The PGP and its GNU counterpart GnuPG store the users keypair into a keyring-file which is stored into the users computer. The user should then import thepublic keys of his e-mail companions into the keyring. Thus, he can send and

receive electronic mail from them.Now, let’s assume that the user uses multiple computers to send and read e-mail.The user is now forced to copy his keyring to all the machines he uses. If heimports new keys or changes the settings of his own keys at any machine, hemust then re-synchronize the keyrings on all machines. Alternatively, the usercould always connect to a single designated e-mail computer from home, workand abroad, and store a single copy of the keyring at the remote computer. Butthen he cannot be sure that his own keypair, and especially his secret key, is safeat the networked remote machine.

Even without the synchronization problem, it is a waste of resources to store all theorganizations e-mail-users public keys into every e-mail-users local keyring. (Onemight think of using some kind of network filesystem to share a single keyringbetween all the users but experiences with the TML Learning System indicate thatthe PGP keyring format cannot handle the situation. According to our experience,such a large keyring will quickly become corrupt.)

From version 5 onward, PGP can search and send public keys from designatedkeyservers. PGP connects to a keyserver with a simplified version of HTTP calledthe Horowitz Key Protocol (HKP) named after its creator Marc Horowitz[8].




Newer versions of PGP can also use Light-weight Directory Access Protocol

(LDAP) to connect to keyservers. The LDAP access provides additional searchpossibilities which the HKP access lacks. There are many free, public keyserverson the Internet and the larger ones synchronize their stores with each other form-ing rings of keyservers spanning multiple continents.

The user, however, cannot obviously store his own secret key on a keyserver. Hewill also need to be careful with keys downloaded from public keyservers as thekeyserver might have several public keys that match the search criteria. How canthe user tell which key belongs to the John Smith HE wants to communicate with?

3.3.2 Key escrow

Key escrow is a scheme in which a secure transaction is committed between twoparties but the keys used to secure the conversation are handed over to a trustedthird party. With PGP, this means that when a message is encrypted to one recip-ient it is also automatically encrypted for the trusted third party. This third partycan then also open the message.

The key escrow-scheme was first publicly proposed by the United States govern-ment in an attempt to create a message encryption standard where all messagescould be opened by the government in order to fight crime (and probably spy on

it’s own citizens). The proposal was withdrawn quickly because of great resis-tance from the security-aware citizens and representatives but there remains civicuses for key escrow.

Imagine a modern corporate environment which uses encrypted e-mail. Whathappens when an employee resigns? In this kind of situation key escrow guar-antees that vital messages do not become lost due to missing encryption keys. Itmight not be suitable for personal communication but for work-related e-mail keyescrow has legitimate uses.

3.3.3 Additional revokation keys

Users frequently forget their passwords or lose their keys altogether. In public keycryptography when a secret key is lost, the owner must somehow inform all theparties that have his public key, that the public key is no longer valid ie. he cannotdecrypt messages sent to him. The common way to accomplish this is by revokingthe key.

When a key is revoked, it is marked as invalid. The revoked key is distributedas the public key was and eventually every holder of the invalid public key will




receive the revokation notice. This is especially true if all relevant users use same

sources to obtain public keys. Only one problem remains: User must have accessto his secret key in order to create the revokation notice. How can he do this if he has either lost the key of he has forgot the key’s passphrase? In later PGPversions he can create subkeys (or Additional Revokation Keys, ADKs) to hissecret key which allow all the public keys to be revoked at a later time. He createsthe additional subkeys when he creates the keypair and stores them somewheresafe. Later on if he needs to revoke his keypair he can always use the subkeys. Hecan also authorize another users key to revoke his keypair if the need arise.

3.3.4 Authentication and trust

In all trust models there is a trusted third party that assures the validity of differentparties. In “Web of trust” the trusted third-party is a personally known friend andin the PKI it is a (self-)appoined organization.

In this thesis we form a model which is a combination of both. The trusted third-party in our model is the HUT Computing Centre, but instead of accepting keysgenerated by the HUTCC, the users generate their keys by themselves and thenauthenticate them with the HUTCC personally. The user does format his keys’user id-field in a specific format but the choice of ciphers and algorithms is the

users.

The HUT Certificate Authority

The HUT Computing Centre will take the role of a certificate authority. It will beresponsible for verifying that the keys belonging to the users of HUTCCs generalpurpose network. It also verifies that the name of the user found in the keys userid-field is correct.

To certify these keys the HUT CA must sign the users’ public keys with its ownsecret key and distribute the signed keys to the HUT users.

The HUT CA signature on a persons public key is a strong indication that theuser is who he claims to be even to persons outside the HUT. If another universitywas to create a similar CA, the HUT CA and the other CA could sign each otherspublic keys and thus create a trust relationship between the universities (assumingthat both universities were equally careful in signing their users’ keys!). Thiswould enable the use of secure e-mail between the users of both universities.

For example, the University of Helsinkis IT-department provides services verysimilar to that HUTCC provides. There is a general purpose network in which




all users have an account that they can use to send and receive e-mail similar to

HUTs. There is a Novell NetWare-based system for providing users with storagespace accessible from different computers.

3.4 Other problems

3.4.1 Usability

It has been possible to send and receive encrypted electronic mail for over a decadebut it is still almost as uncommon as it was back in the beginning of the 90s.Encryption software has become more reliable, powerful, and free, both in theeconomical and political sense. The usability of the software, however, is still asbad as it was when the first software revisions were compiled.

PGP is generally used though command-line user-interface although graphicalshells are available to the more popular operating systems. Using PGP from thecommand-line relies (in traditional unix-style) on a large number of one-letterswitches which are hard to remember[33, 34]. These switches also vary on differ-ent versions of PGP. This command-line interface, while being very powerful andeasy to integrate in shell programs and other automated scripts, is rather confusing

to a non-technical user who just wants to send e-mail.While there are people who place the flexibility of rich command-line interfaceabove the graphical user interfaces, we believe that product such as PGP, whichis an addition to a simple e-mail system, must be made easier and simpler to use.Security products are often received as an extra nuisance to the user because theyrequire more work and seldom provide visible benefit to the investment.

The solution to the dilemma is obvious. The functionality of PGP must be hiddeninside the mechanism of the e-mail client system in a way that completely hidesthe technical process of encrypting, signing, decrypting and verifying a messagefrom the user.

3.4.2 The choice between commercial and “free” solutions

Even though the security product market has grown with the spreading of theInternet, it is still rather small. There are a few large providers of security productsand a number of small ones. Many of the companies are formed around a singleproduct and very few can offer a solution to all areas of computer security.

The small number of available products leads easily to dependency on a single




software provider and as we saw during the IT recession in the beginning of the

21st century, security software providers do go bankrupt and leave their productson their own.

When looking at the available OpenPGP/PKI keyservers, we can roughly dividethe available products into two categories: open and closed ones.

The open products are often provided for free or little cost and are created asprojects by enthusiasts or students. These products are usually poorly supportedand documented but stick to common standards where ever possible. No guar-antee of any kind is given and the user is often expected to correct encounteredsoftware bugs and errors by himself. The MIT Public Key Server (PKS), FROST

and a number of half-finished open source-projects on Sourceforge1

go into thiscategory.

The closed products are bought for a set fee and all modifications to the softwareis usually not permitted by the software license. The vendor provides support inthe use of the software according to the terms of the negotiated license. (Soft-ware licenses are explained in more detail in Chapter 4). Quality documentationis provided. The products in this category include the Novell Certificate Server,Network Associates PGP Keyserver and RSA Securitys Keon Certificate Author-ity.

While there cannot be made any assumptions about the quality of the products in

either category, it is clear that the open products can be more easily customizedto different kinds of systems. The closed products, on the other hand, are oftenbetter tested and polished and all the features can be expected to work.

Proof of security

It is hard to prove that a product or security architecture is actually secure. Youcan test the products and audit the procedures to find out misbehavior but youcannot for certain prove that something is secure. Very small portions of softwareproducts can be mathematically proven to work as intended but the vulnerabilitiesin other parts of the product may still void the usefulness of the software.

Many experts put great weight on the track-record of a product. If the product hasbeen used for years and no exploitable weaknesses have been found during thattime the product might be considered more reliable than other similar products.This is especially true for popular, widely used, products as there would be moreto gain by breaking the system.

1http://sourceforge.net/



Chapter 4

The plan

4.1 Extending the mail system

When we start modifying the current e-mail system of the HUT Computing Cen-tre, we must focus on two things: transparency and simplicity. It is not by chancethat electronic mail is by far the most widely used service of all the available onesat HUT computing environment. E-mail is simple and it works well no matterwhich brand or vintage your computer is. If it has a TCP/IP-protocol implemen-

tation and a network connection, it will be able to send and receive e-mail. Thedefault e-mail clients on most computers usually have a helpful enough user in-terfaces that even a first-time computer user manages to successfully send e-mail.

To provide secure e-mail, we must somehow equip every person on campus with apair of cryptographic keys and provide the means to put them into use. This mustbe done breaking the easiness of use of e-mail.

4.1.1 The mandatory public key

In public key cryptography every user must have his own public and secret key(An example of a PGP public key is shown in figure: 4.1) and a reasonable wayto acquire other recipients public keys.

We will begin by analyzing a current use of HUT computer services. Every useron campus has a password protected account on the HUT Computing Centresgeneral-purpose network. The account password is renewed every six months andthe account can be used to generate special purpose accounts into specific serviceslike the campus Windows 2000 network and dial-up-lines.

19



CHAPTER 4. THE PLAN 20

-----BEGIN PGP PUBLIC KEY BLOCK-----

Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

mQCNAzzw4LAABAEEAMhrsbogQ2hTZMwwLkiKuhMcUX84Fw07Pn/JIsG6OknARUx3

h9nf17hVdXRDvUha+zetbJXsG0x94LI+SlO4BR8HjLy0f3szG/JQoD7kz+I3e/El

dqUlRNWrTuvlxDqTfdHkd7z0nIrZgjtnkMa8CSzwpKMBS0YnFn1JaD4102XRAAUR

tBZUaGUgQm9zcyA8PGRlbW9AZGVtbz4+iQCVAwUQPPDgsH1JaD4102XRAQGoAwP/

TZGdbnCDM43iyMpPcxVGudlF87sfoSFafQYOByVEpxOQr1d7q6cdv/qTzmyXRSfE

MNfjO0lpYbYku9Z6LgwYp1iv5IwmdJremklUIxdj21YtHRdodDl4e1EPbyOGRtF4

jZY5re9TFJjE2ViUEwj77sri+0asJ4STQW83WU5OaFE=

=tWtJ

-----END PGP PUBLIC KEY BLOCK-----

Figure 4.1: A 1024 bit RSA PGP public key

The user applies for the account from the HUT study office when they first enterto the university. The users identity and permissions to apply for the account arechecked, and then a new account is created. The account includes the right to sendand receive electronic mail with an address of form <[email protected]>.

Now, as this account is the only publicly available electronic id common to alle-mail users at HUT, we will use this account and the procedures associated withit to equip every user with a PGP keypair.

We will extend the account-generation process so that on the first logon to a newlycreated account, a PGP keypair will be created. An automated script will help thenew account owner in creating his own keyring and keypair. The users usernamefor the account will be entered into the secret and public keys’ user id-field. Thekeypair will be made to expire in 5 years, which is the expected graduating timeat HUT, and an additional revokation key will be created and sent to the HUT CA.The passphrase for the PGP keypair could be the same password that is used tologin into the account.

The script then helps the user to print out the fingerprint of the new key and sendsa copy of the public key to the HUTCC. The user authenticates himself to the

HUTCC using the fingerprint. The public key will then be signed by the HUTCCsecret key to indicate that the HUTCC certifies the users identity. The key is thenput on the HUT keyserver for everybody to use.

The whole process of creating the account, the keys and authenticating the keyscould be done at the same visit to the HUT Computing Centre, but it would helpthe users to better learn the important concepts of public key encryption, if theauthentication was done at the end of the mandatory T-106.001 Computer as aTool-course.




If the user chooses to use the HUTCC’s Windows 2000 network he normally runs

the script on the master account which creates a new account on the Windows2000 network. The script is modified so that it copies the users keyring to the usershome directory in the Windows 2000 network. An example public key signed witha fictional HUT Certificate Authoritys secret key is presented at figure 4.2.

Figure 4.2: A public key signed by HUT CA

The expiration date helps to keep the amount of public keys in circulation rea-sonable, because the keys of people who graduate or change jobs will eventuallyexpire by themselves. One might also see the key expiration and the mandatory

key renewal process as an incentive for the students to graduate.The additional revokation key will be used to revoke the keypair when the studentforgets his passphrase or when the account is misused by the account owner or bymalicious third parties.

The passphrase and password are bundled together purely for user convenience.There are already too many different passwords that a typical user at HUT campusneeds to remember. By bundling the password and the passphrase we can alsomodify the password changing program at HUTCC to change the PGP passphraseperiodically with account password.

The HUTCC signature on the keys shows that the keys are really associated withthe HUT user account specified in the user id-field of the key. It also helps tomanage the organizations keyserver as all valid keys in the organization have aspecific signature.

4.1.2 The automated internal secure e-mail

After we have every person at HUT capable of using PGP, we need to prepare theprograms used to send and receive electronic mail to recognize PGP signatures




and encryption.

Usage of PGP is complex and the usability of the software is bad[33, 34]. Luckilywe can for the most part prevent the user from having to deal with PGP directlywith e-mail client plug-ins.

The HUT Computing Centre has chosen a number of e-mail clients for which itprovides supports and which it encourages its users to use. We can extend thefunctionality of these clients so that they automatically invoke PGP command-line application during sending and receiving electronic mail. Since every personat HUT has a valid e-mail address which is also listed at the user ID-field of thatpersons public key, we can automatically recognize if the user is sending e-mail to

a person under HUT administration (from the postfix of the recipients e-mail ad-dress). We can then look up the recipients public key either from the senders localPGP keyring or from a predefined HUT keyserver. Figure 4.3 shows the protocolsused in the process: The message itself is transmitted with Simple Mail Trans-fer Protocol (SMTP) while the public key is fetched with either Horowitz KeyProtocol (HKP) or Light-weight Directory Access Protocol (LDAP). The user isconnected to the mail system via Post-Office Protocol (POP) or Internet MessageAccess Protocol (IMAP).

PGP plug-in PGP plug-in

Keyserver

E-mailclient

E-mailclientSender Recipient

SMTP

POP/IMAP

POP/IMAP

HKP/LDAP

HKP/LDAP

E-mailservers

SMTP

Figure 4.3: Sending secure e-mail inside HUT campus

In a similar fashion we can configure the e-mail client to grab the senders e-mailaddress from an incoming signed e-mail, get the senders public key from the localkeyring or remote keyserver, and check the authenticity of the message.

...and outside the HUT campus?

To send electronic mail and to check signatures from a recipient outside the HUTe-mail system, the user needs to get a copy of the recipients public key and import




it to his own local PGP keyring. The authenticity of this key must be determined

in the usual PGP way ie. by exchanging key fingerprints in person, over the phoneor by other secure means.

To receive secure mail from outside the HUT e-mail system could be made easyif we allow the HUT keyserver to be used from outside the HUT network. Thenthe sender could query the recipients public key from the keyserver prior sendingthe message. The problem with this is that it makes possible for the senders of unsolitated e-mail, ie. spammers, a means to easily harvest a number of valide-mail addresses to abuse. So the access to the keyserver will probably have tobe restricted and the outside sender must acquire the recipients public key via theusual PGP way.

4.2 Required modifications to the current system

The suggestions laid out in the previous section require a number of modifica-tions to the current electronic mail system at HUT. The most significant techni-cal changes are the keyserver, modifications to the e-mail clients and the hooksneeded to the learning systems to fully exploit the new possibilities available.

4.2.1 User support issue

The users of the new secure electronic mail system need to have support when theyencounter error conditions and special situations, such as that the users keyringsomehow becomes damaged. If the system is indeed to be used by everyone, end-user support must be provided by a dedicated support organization. As most of theissues that will arise with the PGP are the same as with the regular user accountie. lost passwords and locked-out accounts, thus it is most logical to combinethe end-user support of the PGP with the end-user support already present by theHUT Computing Centre.

The specific new issues for the HUTCCs support personnel to handle would be

̄ Help authenticated users to create new PGP keypairs.

̄

Sign the new keys with HUTCC key.

̄ Send the signed new key to the HUT keyserver.

̄

Revoke lost or damaged PGP public keys.




̄

Correcting technical problems like broken keyrings, changed e-mail client

configurations etc.

̄

Supply users with documentation on using PGP (for example, to use securemail with persons outside the campus).

Staff training

What special knowledge should the administrator responsible for the keyservercomputer have?

The administrator should have a clear understanding of the principles of publickey cryptography. He should understand the need for a working database of validpublic keys and the various abuses a keyserver might face like denial-of-serviceattacks and forged and damaged keys.

The keyserver will be a required part of the HUT e-mail system (though the clientplug-ins should be designed to fall back to regular e-mail if the keyserver can-not be contacted) and thus it should be protected from network abuse like anymainframe in the Computing Centres computer hall.

The administrator should be able to take care of the underlying operating systemof the keyserver computer. He should periodically install security patches and

monitor the logfiles for any suspicious activity.The administrator should know how to operate the keyserver daemon or service(and should preferable have installed it in the first place) and how to solve specialerror conditions.

Furthermore, the administrator must be able to keep strict notes of all the opera-tions and error conditions on the server.

4.2.2 Key server

As we have discussed in the previous chapter, the users local PGP keyring cannotwith any reasonable resources be kept syncronized with the constantly changingamount of public keys in use. A central key repository is needed. As there areover 100000 e-mails sent each day from the HUTCC mail system, the keyserverneeds to be both efficient and well connected to keep up with the traffic.

As a part of this thesis we evaluated four keyserver-products suitable to be used asa HUT keyserver. We also designed and implemented a free and well-documented




alternative on a software project course1 during the fall term 2001 and spring

term 2002. The features of the products and detailed evaluations can be found inappendix B.

The key factors evaluated in the keyservers are the performance of the server withcirca 10000 public keys, the standards compliance of the server (Especially LDAPand HKP/HTTP), and the management tools available for the administration of theserver.

All of the keyservers had a unique edge over the others. For PKS it was the open-ness of the product along with the licensing and the good public track record.Novell was the only choice for Netware-network. Network Associates’ and RSA

Securitys servers have dedicated support mechanisms provided by the companies(with the Network Associates’ server geared towards the PGP and RSA Securi-tys server towards X.509 certificates). With the others, no support is available if there are problems. TMLs FROST keyserver shares some of the strenghts of theMITs Public Key Server (PKS), but with a feature set more tuned to the HUTenvironment. As the newest product is has no track record.

Of these keyservers we would have to recommend the PKS and FROST. Becausethe Network Associates’ product is no longer sold and the HUT does not useNetWare, the Network Associates PGP Keyserver and Novell Certificate servercannot be recommended. The RSA Securitys Keon Certificate Authoritys fea-

ture set and expandability vastly exceed the need of this thesis, and is thereforeconsidered too complex and expensive to this application.

The MIT PKS and TML FROST are very similar products, with small differenceslike the database format. Both can be freely modified and distributed. PKS hasa long track-record and can be considered the more hardened and tested of thetwo. As the author of this thesis was involved in development of FROST, it wouldinappropriate to promote either of the two.

Licenses

A software license describes is a document describing the terms under which apiece of software is released or sold by the author or owner. One does not buysoftware, one licenses it under the terms of the license agreement.

Typically software licenses impose restrictions on the use of software and disclaimall responsibility for any damage caused by the program. Other common clausesare the prohibition of re-distribution, reselling, modifying and reverse engineeringof the software. A disturbing new trend are the clauses allowing the software

1T-76.115 Software Project, http://www.soberit.hut.fi/






and external e-mail. The plug-in will therefore query the keyserver every time

secure e-mail is sent to or received from outside the organization. Luckily thereare also individual third-party plug-ins for all the e-mail clients. A list of differentthird party plug-ins can be found in Appendix C.

4.2.4 Integration with student-management tools

One of the main objectives of deploying public cryptography into campus was theautomatisation of repetitive and monotonous student management routines suchas publishing results, calculating grade-limits and enforcing deadlines.

The TML Learning System was developed with PGP in mind from the day one, soit naturally puts the PGP message authentication possibilities into good use. Forexample, the students’ homework returns are submitted as PGP signed files andPGP timestamps are used to keep track of students contributions. Similarily thestaff members can automatically publish student grades and status via individualsecure mailings. The homeworks returned by students are automatically randomlyshuffled to different course assistants for checking. The homeworks under check-ing remain pseudo-anonymous to the assistants so the students are better protectedagainst abuse from the course staff.

Other learning systems can be made to take advantage of PGP in a more limited

way with very little effort. It is not a great task to organize the course staff to usePGP to sign official course announcements and to ask their students to secure thefiles they submit during the course.

4.3 Deployment

4.3.1 Time-frame

Due to the large number of users, over 10000, in the HUT campus, the deploy-ment of the new e-mail system with PGP will take time. Most of the users of HUT Computing Centre are students. The current average time a student takesto graduate into M.Sc is seven years. Taking these facts under consideration werealize that the most painless way to equip all users with PGP keypairs would bea five-year plan.




year status tasks

0 1% Start planning the keyserver1 10% Documentation for the early adopters2 20% Train support personnel3 40% Set up user support4 60% Testing5 95% Take the system into use

We will begin by equipping all fresh starting students with PGP keys as describedin the section “The mandatory public key” earlier and by starting to build therequired infrastructure ie. the keyserver and the e-mail client plug-ins.

After the first year we will have about 1500 students and a small number of tech-nically curious early adopters ready to use the system. During the second yearwe will start teaching the Computing Centres support personnel the usage of PGP.Another 1500 students will now be ready to use the system. The third year will beused to organize the user support and write end-user support documents. Duringthe fourth year we can take the system into use. A significant amount of userbaseis now capable of using the system and as the people will get comfortable withsecure e-mail the adoption rate will increase. At the start of the fifth year most of the HUT users will be able to use the system and there has been enough time towork around technical problems with the infrastructure.

4.3.2 Immediate costs

The cost of the new campus-wide secure e-mail system is two-folded. There arethe initial costs of setting up the system and the annual costs of keeping the systemoperational.

The initial costs are made of two things: computer hardware and man-hours.

The most significant initial hardware investment is the keyserver. The cost isdivided between the cost of the hardware and the possible licensing fees of thesoftware. The choice of hardware is influenced by the experience of the futureadministrators and by the existing deals and purchases of hardware at HUT Com-puting Centre. Same goes for the operating system of the machine.

Many man-hours are initially spent on training and possible recruiting of newadministrators and support personnel. Installing and configuring the e-mail clientplug-ins and the keyserver will take time as does testing of the new services.

For an example we will calculate a very rough extimate of the initial cost of aone possible scenario (assuming an average hourly wage of 30

/h, including the




employers fees). In this scenario we have two administrators trained to manage

the keyservers and four persons trained to help users with the use of PGP.

Keyserver hardware 5000

Software licenses, OS + server 2000

1 administrators training (16h) 2*480

1 ser support persons training (40h) 4*1200

Setting up the server (8h) 240

Setting up the clients (100h) 3000

Testing the system (100h) 3000

total 19000

4.3.3 Annual costs

The new extended e-mail system needs constant maintenance to stay operational.The most expenses will come from the added work on the user support personnel.Some extra effort will be needed from the system administrators as they need tokeep the keyserver and clients up to date. Like we did with the initial costs wewill calculate expenses for our sample scenario.

We assume that the users need at least two hours of personal time from the support

personnel per week and that the keyserver software itself is not updated during ayear. With the same assumption of 30 /h wage we get:

Keyserver OS updates (4h) 120

User support (2*52=104h) 3120

Client upgrades (16h) 480

total 3720

/year

4.3.4 The new and remaining unsolved problems

No technique in the field of computer science is without drawbacks, not even pub-lic key cryptography. The application of PGP presented in this thesis introducesnew problems and fails to solve some old ones.

Even though every e-mail user will have his own keypairs and these keys arevouched by the HUT Computing Centre to belong to that user there is still noabsolute certainty that a given message was actually wrote by a person. The mes-sage might be signed but we cannot know if the message was really signed by theperson associated with the key. The same problem affects all the keys, keycards




and other forms of authentication in which the user needs to use complex tools

to sign something. The problem of creating and upkeeping a secure computingenvironment is beyond the scope of this thesis.

Another associated problem is caused by the lack of distributed storage spacebetween different networks of HUT. The user has separate home directories onthe Windows 2000 network and the general purpose HUTCC network. In order tosign messages and recieve encrypted messages on both systems, the user needs tohave two copies of his keyring. This can be automated, though, since the Windows2000 network account is generated by the user from the HUTCC account.

The security of the public key cryptography itself is not proven. A long-term

commitment to currently used public key methods might backfire with new math-ematic breakthroughs. Quantum computing might render all public key methodsuseless overnight[2]. Assuming that these nightmare scenarios do not materialize,we can conclude that the public key cryptography is secure enough to resist directattacks of technical kind.

In order to chart the attacks the secure e-mail system might face we used a methodcalled attack trees[27] to draw a map of what a malicious person might try in orderto meet different objectives. The attack trees for reading another persons e-mailand forging a message so that it appears to be signed by a certain person, arepresented in the appendix A.

As can be seen from the trees trying to break the public key cryptosystem is themost difficult and unlikely way to accomplish the malicious objectives. Most of the real dangers come from unsecure third-party software and from human error.The only way to reduce security threats exploiting human errors is education. Theusers should be taught the correct security procedures and why they are needed.An ideal opportunity to accomplish this at HUT would be on the course T-106.001Computer as a Tool. The course is mandatory to all students at HUT and is thecourse where the usage of e-mail is taught.

Public key cryptography has been under around since its discovery in 1970s. It israther old and mature technology though it is not very widely used. One reason

for this is that the public perception of electronic message signing, encryption,and cryptography in general is not the greatest possibly. Encryption is still easilyassociated with computer crime because of the misconception that only criminalshave a need for cryptography.

Another reason for the slow adoption of public key cryptography is the unclearlegal position of digital signatures. While work is being done to refine the legisla-tion, there are no precedents based on the new laws.




4.4 Alternative or abandoned schemes

4.4.1 HST

In 1999 the Finnish Population Register Centre began selling national identifi-cation cards with embedded certificates and a 1024 bit RSA keypair (figure 4.4,published with the permission of Population Register Centre). The PopulationRegister Centre also put up a certificate authority to support the use of the cards.The cards are valid for a fixed time-period of three years and can only be pur-chased from the Finnish police.

Figure 4.4: A Finnish national HST ID-smartcard

It would be very tempting to replace the PGP keys used by the system describedin this thesis with the HST cards. The HUT Computing Centre would not need toset up CA services or the keyserver at all, but it could rely on government for theinfrastructure and authentication of the cardholders.

There are however two big issues speaking against the HST cards in the context of this thesis. First is the fact that only Finnish citizens can get the card. This wouldleave all foreign students and visiting lecturers and teachers unable to participatein the secure e-mail system. Second the certificates embedded on the HST cards

lack the card owners e-mail address. Most of the already existing e-mail applica-tions expect to find the e-mail address from the certificate and will therefore notwork with HST cards.

The brilliant idea of a standard national smart card is also somewhat tarnished asthe Social Insurance Institution of Finland (KELA), has also announced that theyplan to start using their own smart card system which is incompatible with theHST cards.





Chapter 5

Conclusion

We started this thesis in order to find a way to enable every user at HUT networkto send and receive secure electronic mail.

We did this in order to make it possible for other laboratories and departments atHUT to use the Learning System developed at the Telecommunications Softwareand Multimedia Laboratory. As a side-effect, we also set up a standard by whichHUT users can now send and receive messages with each other, without the fearof eavesdropping and fake messages.

We introduced a model in which every student is given a PGP keypair when theyfirst start their studies at the university and reviewed the different support require-ments this imposes to the university.

We reviewed a number of products that could be used to build the infrastructureneeded to help all users use their PGP keys in an easy and transparent way. Wealso saw that there is no need to change the software students and university staff curently use to send and receive e-mail. We also made a very rough estimate of the different costs the new infrastructure would generate, most of which wouldfall upon the HUT Computing Centre.

The new infrastructure can have many other benefits besides the learning system.For example, it could be used to replace the password-based authentication usedby most of the HUT services. The password-based authentication is coming to theend of its usefullness due to the large number of passwords needed. The authorof this thesis, for example, currently has 15 different passwords 1 into differentHUT services. The use of public key authentication could replace many of these

1Primary account, e-mail, dial-up, windows-network, FTP, Topi-course management, 2 multi-media accounts, CS account, TML account and different course-specific accounts - and no, I don’tremember all of them.

33



CHAPTER 5. CONCLUSION 34

passwords and perhaps improve the quality of the passwords that remain. It is

easier for users to remember and take care of a couple of good passwords than 15.

While this thesis focuses on PGP, as this is the system used by the TML LearningSystem, most of the issues discussed are relevant to other public key systems aswell.



Appendix A

Attack trees

Objective: Forge e-mail

1. Get a copy of the victims secret key

1.1 Make the victim give up his secret key and passphrase

1.1.1 Use violence and threats or bribes

1.1.2 Use social engineering

1.2 Break into the computer the user stores his secret key1.2.1 Get physical access to the computer

1.2.2 Hack the computer from network

1.3 Make the victim change his secret key and get a copy

1.3.1 Spy the user when he creates a new key

1.3.2 Monitor the computer the user uses to compute the new key

1.3.3 Fool the user into using a trojan-horse software that looks likePGP

2. Change the victims key to one the attacker has

2.1 Make the victim believe that his key has been compromised

2.1.x Like in the leaf 1.3.x

2.2 Wait for the victim to change his key

2.2.x As in the leaf 2.1.x

3. Make victim (unknowingly) send the e-mail

3.1 Plant trojan-horse software into victims computer

35



APPENDIX A. ATTACK TREES 36

3.2 Fool the user

4. Get messages signed by the victim, deduce the secret key and then createforged messages

4.1 Break asymmetric encryption

4.1.1 Brute-force

4.1.2 Mathematic break-through

4.1.3 Cryptanalysis

Objective: Intercept an e-mail send to recipient

1. Sniff the e-mail of the network and decode it

1.1 Get access rights to a computer in the same network segment as therecipients computer

1.2 Get access rights to a router on messages path

1.3 Get the recipients PGP secret key and guess the passphrase

1.3.1

1.4 Break asymmetric encryption

1.4.1 Brute-force1.4.2 Mathematic break-through

1.4.2.1 Find a new way to factor RSA modulus or calculate DSAdiscrete logarithms

1.4.3 Cryptanalysis

2. Get the e-mail after it is delivered to the victims computer and decrypted

2.1 Spy the recipients computer

– Shoulder surfing

– Keyloggers

– Remote management tools

2.2 Threaten, blackmail and bribe the recipient

2.3 Electromagnetic surveillance (TEMPEST etc)

2.4 Get the message from computers hard drive

2.4.1 Custom disk driver

2.4.2 Steal the hard drive



APPENDIX A. ATTACK TREES 37

2.4.3 Get the message from hard drive backups

3. Make the victim forward or print the e-mail

3.1 Fool the recipient

3.2 Plant trojan horse-program into recipients computer

3.3 Wait for the recipient to leave his computer unlocked



Appendix B

Comparison of keyserver products

B.1 Feature matrix

Product MIT PKS0.9.4

NAI PGPKeyserver7.0

NovellCertificateServer 2.0

RSA KeonCA

FROST

Manufac-turer

MarcHorowitz

NetworkAssociates

Novell Inc. RSA Secu-rity

TML/HUT

Availableversions

“Unix”source

Solaris7&8, WinNT/2000

NetWare 5and newer

Solaris 7&8, Win NT

Posix-compliantsystems

Testedversion

Linux(x86)

Win 2000 NetWare 5 Win 2000 Linux(x86)

Licensingand cost

Berkeley-stylelicense,free of cost

Not cur-rentlyavailable

Commerciallicense,free of cost

Commerciallicense, perclient

GPL, freeof cost

B.2 Evaluation notes

B.2.1 MIT Public Key Server (PKS) 0.9.4 patchlevel 2

Tested version: 0.9.4 patch 2 source code distribution compiled with GNU C-compiler (Redhat 7.1, Linux x86). Will not work under Windows.Website: http://www.mit.edu/ marc/pks/

38



APPENDIX B. COMPARISON OF KEYSERVER PRODUCTS 39

Massachusetts Institute of Technology (MIT) has developed a keyserver specifi-

cally to distribute PGP public keys[8]. The Massachusetts Institute of TechnologyPublic Key Server can communicate with the PGP client by using the HorowitzKey Protocol, a simplified HTTP, which has become the de-facto standard forPGP keyservers. The PKS uses Sleepycat Softwares DB2-database to store itskeys, and this database is included in the PKS distribution.

The PKS is distributed under a license which allows redistribution and modifica-tion of the software without cost, provided the authors copyright to the product isacknowledged. The PKS source distribution can be downloaded from the MarcHorowitzes main distribution site at MIT.

The installation was a typical Unix-style process. It was easy enough though notautomatic. The creation of the database was easy and well documented. Theinstallation path and size could be adjusted. The documentation covered only theinstallation and if one runs into any kind of trouble he is guided to contact theauthor directly via e-mail or usenet newsgroups.

The PKS uses DB2-format to store the public keys so there are a number of toolsavailable to administer the database. This is good because no tool is supplied withthe PKS. The server works well and there exists many public keyserver servicesthat use the PKS (for example pgp.mit.edu which hosts over 7000 public keys).

PKS is a straight-forward no-thrills keyserver which is proven to work well.

B.2.2 NAI PGP Keyserver 7.0

Tested version: 7.0 Trial for Windows NTWebsite: Unknown due to reorganization

The Network Associates’ PGP Keyserver 7.0 was available on Sun Solaris andWindows NT platforms. The tested version was the Windows NT Trial versiondownloaded from the Network Associates website.

During the making of this thesis Network Associates announced the closure of

PGP Security business unit and while some products were transferred over to theMcAfee business unit, the PGP Keyserver was put into “maintenance mode”. Thismeans that old support contracts are honored but no new development is done noris the product sold anymore.

The end-user license of the version tested prohibits the publishing of tests andevaluations about the product. A permission to publish evaluation notes was re-quested but never received so it is left out.

The older version 2.5.8 of the product for Windows NT and Solaris, remains free




to use without cost for personal, non-commercial use and is ditributed on MIT

Distribution Center for PGP.

B.2.3 Novell Certificate Server 2.0

Tested version: 2.0.2 under 30-day evaluation license for NetWare 5Website: http://www.novell.com/products/certserver/

Novell Certserver is a PKI x.509 certificate server for NetWare environments.Novell Certificate Server integrates with Novell eDirectory, available on NetWare5 and newer, and uses eDirectory to securely store keys.

The server supports NetWare 5 and client software is supplied for Microsoft Win-dows. Popular Windows e-mail clients like Outlook can be used to access NovellCertificate Server through Groupwise.

The server itself is rather easy to install because most of the setting up and man-agement is done from an administration client “ConsoleOne”. The eDirectorystorage have been shown to handle large amounts of data but no testing of theCertificate Server itself was executed due to lack of a big enough NetWare net-work.

The Novell Certificate Server can be downloaded for evaluation purposes from

the Novell website. The product is sold under a typical commercial license: Nov-ell reserves all rights not expressly granted to you. There are multiple differentlicenses the product can be acquired with. In order to use the software in a com-mercial public network service, a separate license must be obtained.

B.2.4 RSA Keon Certificate Authority

Tested version: SentryCA v4.7 for Windows NT/2000Website: http://www.rsasecurity.com/products/keon/index.html

The RSA Securitys Keon Certificate Authority is easily the most complex pack-age in this small evaluation. This comes as no surprise because it is intended touse as a part of RSA Keon Advanced PKI, which implements a complete PKIsolution. RSA Keon Certificate Authority is avalable for Windows NT/2000 andSun Solaris 7 and 8.

The installation of the Certificate Authority is straight-forward but the initial con-figuration is rather chaotic. It takes the installer through all the necessary stagesbut does not explain the relevance of each option. Difficult configuration processis often the counter-product of high customization or caused by bad user-interface,




in this case the first one. After the initial configuration is done, the Keon Certifi-

cate Authority is easy to use.

The RSA Keon Certificate Authority (or Xcert SentryCA as the program callsitself) is managed and configured completely with a www-browser.

On the RSA Security website, RSA Security provides documentation of a testby Sun Microsystems, where Keon Certificate Authority is benchmarked with 8million users to prove the scalability of the product.

The cost of the product depends on the number of clients connecting to the server.The evaluation license was for 20 clients.

We would like to thank Petri Wilander of RSA Security for providing the copy forevaluation.

B.3 FROST project

Website: http://frost.tml.hut.fi/

During the fall term 2001 TML launched a software project with a purpose todevelop a simple keyserver to support the TML Learning System. The outcomewas the Free, Reliable, Openpgp keyService from Tml - FROST. FROST is a small

and scalable keyserver which can connect with PGP command-line clients usingthe Horowitz Key Protocol (HKP, a simplified version of HTTP). FROST attachesto a standard SQL database like PostgreSQL or Oracle and uses the database tostore public keys.

FROST requires a POSIX-compliant platform to run on and can take advantageof common Unix-logging tools if they are available.

The project was given strict performance requirements and FROST was designedto be as simple and efficient as possible. The internal operation of FROST hasbeen formally tested to satisfy the original requirements.

FROST does not have any means to restrict access to its client interface. This taskwas left to the host computer. FROST can filter out keys which do not satisfy a setof criterias before transferring the keys into a database. This can be used to makesure, for example, that only keys signed with a certain key can be entered into thedatabase.

After the project ended at the end of spring semester 2002, FROST was releasedunder the GPL license and can be downloaded for free from the project website ei-ther as source code or as a pre-compiled Redhat Linux binary distribution (RPM).




As the author of the thesis is directly responsible for the launch of the project,

and acted as the project manager during it, no review of the installation process ordocumentation is given.



Appendix C

Flexible user agents

Calyspo 3 PGP plugin

Category: Email plugin

Platform: Windows 95/98/NT

For use with: PGP 5.x/6.x

License: Shareware

Homepage: http://www.mcsdallas.com/mcs/calypso/

Description: Email plugin for Calypso E-mail Client.

Claris Emailer plugin


Platform: MacOS


License: Freeware

Homepage: http://www.pgpi.com/cgi/download-wizard.cgi

Description: This plugin integrates PGP with Claris Emailer.

It is included in the PGP 6.0.2i distribution.

CryptoEx 1.0b4



For use with: PGP 2.x

License: Commercial (free beta-versions available)

Homepage: http://www.glueckkanja.de/

Description: A professional PGP extension for Microsoft Outlook

and Microsoft Exchange. The client-based, transparent

43



APPENDIX C. FLEXIBLE USER AGENTS 44

extension has been fully integrated into the familiar

email user environment.It automatically recognizes

encrypted emails and offers an easy-to-use keyring

administration. CryptoEx works with both the US and the

international version of PGP. A user-friendly

adminstrator tool helps distributing CryptoEx and

managing user options in large Windows networks.

elmpgp 2.4pl24


Platform: Unix


License: Freeware

Homepage: ftp://ftp.cert.dfn.de/pub/tools/crypt/pgp/utils/elm/README.ht

Description: PGP interface for the elm mail reader.

Emacs auto-pgp


Platform: Unix


License: Freeware

Homepage: ftp://ftp.ifi.uio.no/pub/pgp/2.x/unix/auto-pgp.tar.gz

Description: An Emacs/PGP Interface.

Eudora plugin


Platform: MacOS


License: Freeware

Homepage: http://www.pgpi.com/cgi/download-wizard.cgi

Description: This plugin integrates PGP with Eudora. It is included

in the PGP 6.0.2i distribution.

Lotus Notes plugin




License: Freeware

Homepage: http://www.pgpi.com/cgi/download.cgi?




filename=PGP602LotusNotesPlugin.zip

Description: This plugin integrates PGP 6.0.2i with Lotus Notes.

Mailcrypt 3.5.3


Platform: Unix

For use with: PGP 2.x/5.x/GnuPG

License: Freeware

Homepage: http://www.nb.net/~lbudney/linux/software/mailcrypt.html

Description: Mailcrypt is an Emacs Lisp package which provides a

simple interface to public key cryptography with PGP

2.x/5.x, as well as GnuPG.

Mollusc 1.0


Platform: Windows 3.x/95/98/NT


License: Commercial, try before you buy

Homepage: http://www.compulink.co.uk/~net-services/pgp/

Description: Direct interface to your e-mail software - you don’t have

to cut and paste. Extensive key management including Key

Server functions. Mollusc currently supports Eudora Pro

(v2.2 - 32 bit), Eudora Light (1.5.2 and 1.5.4),

Pegasus Mail 2.40, WinCIM 2.0, Ameol, Free Agent and

Netscape 1.2N.

MS Outlook and Exchange plugin




License: Freeware

Homepage: http://www.pgpi.com/cgi/download-wizard.cgi?country=US

&platform=Windows+95%2F98%2FNT&license=freeware

Description: This plugin integrates PGP with Microsoft Outlook

97/98/2000 or Exchange. It is included in the PGP 6.5.1

distribution.

MS Outlook Express plugin







License: Freeware

Homepage: http://www.pgpi.com/cgi/download- wizard.cgi?

country=US&platform=Windows+95%2F98%2FNT&license=freeware

Description: This plugin integrates PGP with Microsoft Outlook

Express 4/5. It is included in the PGP 6.5.1 distribution.

PGP Encryptor Interface 1.1


Platform: Windows 3.x


License: Freeware

Homepage: http://web.aimnet.com/~jnavas/winpmail/helpers.html

Description: Integrates seamlessly into Pegasus Mail for Windows

(Version 2.23 and above), making it easy to protect email

messages with secure PGP public ke encryption and/or

digital signatures. NB! Only works with the 16-bit

version of Pegasus Mail.

pgp4pine


Platform: Unix


License: Freeware

Homepage: http://pgp4pine.flatline.de/

Description: PGP/GPG filter for pine, enabling you to manually and

automatically decrypt and encrypt email messages.

pgp4pine 3.2


Platform: Unix

For use with: PGP 2.x/5.x/GnuPG

License: Freeware

Homepage: http://azzie.robotics.net/

Description: Script that automaticly encrypts/decrypts mail under PINE

using PGP. User is not separated from things that PGP do.

Program supports PGP 2.6.3, 5.0, 6.5.1 and GNUPG 1.0. It

can remember your passphrase for a session if you need

and supports signature rotating programs.RPMs are also




avaliable (with some latency).

PGP4Pine (aka PAPP)


Platform: Unix


License: Freeware

Homepage: http://user.cs.tu-berlin.de/~gator/pgp4pine/

Description: PGP4Pine, also known as "PAPP" ("Pine And PGP") is a Perl

script to integrate pgp into the popular mail reader Pine.

pgpenvelope


Platform: Unix

For use with: PGP GnuPG

License: Freeware

Homepage: http://pgpenvelope.sourceforge.net/

Description: pgpenvelope is a Pine and procmail filter which allows

one to process messages with GnuPG.

QDPGP 2.60




License: Freeware

Homepage: http://www.wow.net/community/grt/qdpgp.html

Description: Email plugin for Pegasus Mail. Supports

encryption/decryption, generation/verification of

signatures, addition of public keys to keyring.

zmail PGP script


Platform: Unix


License: Freeware

Homepage: http://www.rhein.de/~aldo/zmail.html

Description: Script for integrating PGP with zmail.



Bibliography

[1] L. Baranyi, Network Associates AB, “Corporate use of PGP & Key Man-

agement/recovery”, Nordsec’98, 5-6 1998, Trondheim, Norway

[2] G. Brassard, “A Bibliography of Quantum Cryptography”,URL: http://www.cs.mcgill.ca/ crepeau/CRYPTO/Biblio-QC.html

[3] J. Callas, L. DonnerHacke, H. Finney and R. Thayer, “OpenPGP MessageFormat”, Internet standards track, IETF Network Working Group, RFC 2440

[4] C. Ellison, and B. Schneier, “Ten Risks of PKI: What You’re Not BeingTold About Public Key Infrastructure”, Computer Security Journal, v 16, n1, 2000,

URL: http://www.counterpane.com/pki-risks.html

[5] Freeware PGP version list,URL: http://www.pgpi.org/products/pgp/versions/freeware/ ,(Referred: 10.5.2002)

[6] Frequently Asked Questions about PGP,URL: http://www.faqs.org/faqs/pgp-faq/,(Referred: 25.5.2002)

[7] GNU, GNU Privacy Guard,URL: http://www.gpnug.org/gnupg.html,(Referred: 10.5.2002)

[8] M. Horowitz, “A PGP Public Key Server”,URL: http://www.mit.edu/people/marc/pks/,(Referred: 10.5.2002)

[9] International Telecommunication Union, Series X: Data networks and opensystem communications, Internetworking between networks - directory(X.509 03/00), ITU-T

48



BIBLIOGRAPHY 49

[10] D.Klien, “Foiling the Cracker: A Survey of, and Improvements to, Password

Security”, Feb22, 1991,URL: http://packetstorm.widexs.nl/papers/password/klein.ps ,(Referred: 10.5.2002)

[11] R. Kukkonen et al, “TKK:n atk-keskuksen asiakkaan opas”,URL: http://www.hut.fi/atk/oppaat/asiakkaan/index.html

[12] R. Kukkonen et al, “IT at HUTCC”,URL: http://www.hut.fi/atk/oppaat/itathutcc/

[13] H. Lamm, PGP4PINE,

URL: http://pgp4pine.flatline.de/

[14] S. Liimatainen and T. Virtanen, “Distributed Learning and Management Sys-tem for University Courses”, World Computer Congress (WCC 2002), Au-gust 25-30 2002, Montréal, Canada.

[15] M-L Markkula, “Verkkomedian opintojakso vuonna 2000”, Teknillisen ko-rkeakoulun Opetuksen ja opiskelun tuen julkaisuja 3/2000, Helsinki 2000

[16] T. Matsumoto, H. Matsumoto, K. Yamada, S. Hoshino, “Impact of Artifi-cial “Gummy” Fingers on Fingerprint Systems”, Proceedings of SPIE Vol.

#4677, Optical Security and Counterfeit Deterrence Techniques IV[17] T. Matsumoto, “Importance of Open Discussion on Adversarial Analyses

for Mobile Security Technologies -A Case Study for User Identification”,Yokohama National University Matsumoto Laboratory, ITU-T Workshop onSecurity, Seoul 2002

[18] A. Menezes, P. Oorschot and S. Vanstone, “Handbook of Applied Cryptog-raphy”, CRC Press, 1996, ISBN 0-8493-9523-7,URL: http://www.cacr.math.uwaterloo.ca/hac/

[19] Microsoft Corporation, “Erroneous VeriSign-Issued Digital CertificatesPose Spoofing Hazard”, Microsoft Security Bulletin MS01-017, March 28,2001,URL: http://www.microsoft.com/technet/security/bulletin/MS01-0(Referred 28.5.2002)

[20] J. Myers, Netscape Communications, “Service Extensions for Authentica-tion”, Network Working Group, March 1999



BIBLIOGRAPHY 50

[21] Network Associates, “An Introduction to Cryptography”, version 7.1,

URL: http://download.nai.com/products/media/pgp/support/pgp/pgp71_win32/introtocrypto.pdf

[22] Network Associates, “An Introduction to PGP”, version 7.1,URL: http://download.nai.com/products/media/pgp/support/pgp/pgp71_win32/introtopgp.pdf

[23] PGP E-mail client plug-in search results,URL: http://www.pgpi.org/cgi/tools.cgi?category=Email+plugin&platform=&pgpversion=&license=&text=,(Referred: 25.5.2002)

[24] PGP Shells and front-ends search results,URL: http://www.pgpi.org/cgi/tools.cgi?category=Shell&platform=&pgpversion=&license=&text=,(Referred: 25.5.2002)

[25] J. Postel, “Simple Mail Transfer Protocol”, Request For Comments, August1982

[26] B. Schneier “Applied Cryptography: Protocols, Algorithms and SourceCode in C, 2nd edition”, John Wiley & Sons Inc, 1996, ISBN 0-471-12845-7

[27] B. Schneier, “Attack Trees”, Dr. Dobb’s Journal December 1999,URL: http://www.counterpane.com/attacktrees-ddj-ft.html(Referred 22.5.2002)

[28] M. Seppä, “The Requirements for the New Learning System and How theTML Learning Systems Stand Up in Comparison”, Master’s Thesis, HelsinkiUniversity of Technology, Dept. of Computer Science, Espoo 2000, 73 s.

[29] K. Thompson and R. Morris, “Password Security: A Case History”, 1979,URLhttp://www.alw.nih.gov/Security/FIRST/papers/password/pwst(Referred:10.5.2002)

[30] W. Unruh, “PGP ATTACKS”,URL: http://axion.physics.ubc.ca/pgp-attack.html,(Referred: 15.5.2002)

[31] VeriSign, Inc, “VeriSign Security Alert Fraud Detected in AuthenticodeCode Signing Certificates March 22, 2001”, Security Notice, March 222001,URL: http://www.verisign.com/developer/notice/authenticode/ind(Referred 28.5.2002)



BIBLIOGRAPHY 51

[32] Väestörekisterikeskus, The Electronic ID Card,

URL: http://www.sahkoinenhenkilokortti.fi/, 2002

[33] A. Whitten and J. Tygar, “Usability of Security: A Case Study”, CMU-CS-98-155, December 18, 1998

[34] A.Whitten and J. Tygar. “Why Johnny Can’t Encrypt: A Usability Evalua-tion of PGP 5.0”

[35] P. Zimmermann, “The Official PGP User’s Guide”, MIT Press 1995, ISBN0-262-74017-6

Campus-Wide Use of Public Key

Documents