Privacy Enhanced Mail for WWW

by
Stephan Kolletzki
Institute for Telecooperation Technology
GMD - TKT
Dolivostr. 15
D-64293 Darmstadt

kolletzki@darmstadt.gmd.de

Keywords:

Charging and Security

Overview

Internet services are increasingly used for the transmission of sensitive and economical data. Commercial WWW service providers or teleshops allow cashless payment, where clients have to enter besides other personal data their credit card number. This is obviously a security hole. Moreover, the network used by WWW is open and contains considerably security risks.
In spite of the insecurity of the network used, how can WWW data and HTML communication be protected against unauthorised manipulation or access?

These are necessary security enhancements to the existing WWW application:

• origin authentication
• non-repudiation of origin
• data integrity
• data confidentiality

One way how to provide security in WWW is to equip the HTML protocol with additional tokens and built-in-facilities. Another approach is to use existent tools that cooperate with the running WWW browser, independant of the current HTML version and transmission protocol, and started as a separate client-side process. In the actual situation we prefer the latter possibility of security enhanced WWW.

In our demonstration we want to present our implementation of Privacy Enhanced Mail. Originally, it was designed for electronic mail. However, it is applicable to any type of text-oriented data and therefore, it is also suitable for WWW communication.

PEM for E-Mail

Internet Privacy Enhanced Mail [PEM: RFC 1421-24] is a "standard" set of rules how to construct a communication infrastructure with a third-party trust model.

The public-key technique is used both for digital signatures (1 to n: one signs, many can verify), and for recipient-tied encryption/decryption (n to 1: many can encrypt, one can decrypt). The related public keys have to be certified by trusted third-parties, so called Certification Authorities.

Public information that is needed during verification or encryption can be stored and accessed in local databases or in X.500 directories, e.g. valid user certificates or black lists of expired or compromised certificates.

We built a PEM filter/library using our toolkit SecuDE (Security Development Environment), which complies the demands of RFC 1421-24. Secret objects can be stored as encrypted files or, if a high degree of security is needed, on a personal smartcard. It is available as UNIX/DOS-filter utility, furthermore we added PEM functionality to some Mail User Agents like ELM or XMH.

PEM for WWW

The goal of PEM in WWW is a similar handling as PEM in electronic mail with the additional usage of HTML features.

These scenarios provide a simple but effective solution:

• Signed WWW pages: Each reader can verify the origination of a document
  The WWW document in normal HTML format is signed by its author. The signature process would result in the addition of a hyper-link in the to-be-signed text and the creation of a related file with a name suffix ".pem" which contains the corresponding PEM-formatted signature information. On read-access, the to-be-signed file (that is the original WWW page with the added hyper-link) is sent together with the related signature information to the reader. On reception, these two files are recompiled to one PEM message containing both the text to-be-signed and the signature information. This resulting PEM message can be verified client-side by the reader according to the PEM rules; the verification process would create a third page which displays the verification results.
• Encrypted WWW pages: A list of persons can decrypt the document
  A WWW page contains hyper-links to documents that have been encrypted by the author for a list of authorised persons. Clicking a link sends the document and invokes PEM. If the person is in the list of recipients, the decrypted document will be displayed.

Our demonstration

We present the usage of digital signatures and encryption in combination with electronic mail and with HTML documents in the way described above. The demonstrated Mail User Agent will be XPEM, which performs PEM (de-)enhancement in a separate process.