A System for Public-Key Services in the Spanish Research and Academic Network

Lucia Pino
Juan J. Ortega
Javier López <jlm@lcc.uma.es>
Antonio Maña
Universidad de Málaga


Electronic mail is one of the reasons for the continuing increase in the number of Internet users. Both data and resources become vulnerable once the user is connected to other computers in the network. Messages are open and available and the use of encipherment techniques is the best way to provide security; public-key cryptosystems are frequently used in broad computer networks. In this paper, we propose a hybrid system for public-key management over the Internet that avoids synchronization problems between key servers and reduces network traffic.

Keywords: e-mail security, key distribution, authenticity, certification.


1. Introduction

The Internet currently has nearly 40 million users throughout the world. It is thought there are 5 million Web pages, 45,000 interconnected networks, and 56,000 registered domains. The annual growth of the Internet is 180 percent, so, if the Forrester Research Institute's [1] forecasts for 1997 are correct, the global network will reach 126 million users this year.

The size of the Internet in Spain is still modest [2]. There are about 30,000 professional users with proprietary connections and nearly 150,000 with an Internet address. Only a few years ago the Internet was restricted to the Spanish academic and research world. However, since 1992, but mainly during 1995 and following, the international trends of Internet expansion, the network's tentacles have slowly spread beyond these fields to reach all Spanish society with an annual growth rate of 100 percent, in line with the rest of Europe.

In 1987, when only a few people in Spain had the chance to use electronic information services, the most important Internet initiative came from the Telecommunications Engineering Technical High School in Madrid. These pioneering activities gave rise to RedIRIS (Computer Resources Interconnection Network), oriented to the academic and research community [3]. In 1988, the R+D National Project started the IRIS program for Universities and Research Centers, which was originally managed by the Foundation for the Development of Social Activities in Communications (Fundesco). In 1991, the project was transformed into RedIRIS, which soon became the national academic and research network. In January 1994, RedIRIS came under the responsibility of the Scientific Research High Council (CSIC) [4], and currently it offers services to over two hundred organizations and institutions.

In this paper we introduce a system for public-key service in RedIRIS to be used in encrypted electronic mail (e-mail) applications. In Section 2 we show the significance of e-mail in the Internet (and the risks involved in its use). In Section 3 we consider security aims as well as different cryptographic techniques. In Section 4 the two main key-management systems are studied as well as their shortcomings. In Section 5 we show the details of the new hybrid system for a public-key service designed to be used in RedIRIS.

2. Significance and risks of e-mail

The size of the Internet is doubling every year, and e-mail is one of the main reasons for this growth; it is a commodity with a very high impact on human communication media. In fact, it is the most frequently used application in distributed systems, where users have mailboxes to transmit and receive documents, graphics, and computer programs and even close business and private deals. More than a hundred million e-mail messages travel every day through computer networks all around the world.

The annual growth rate of mailboxes is spectacular, in keeping with the importance companies and individuals are attaching to e-mail. Several factors underlie this growth:

The importance of the e-mail market will continue its meteoric rise within the global software market. According to an IDC study [5], worldwide sales of e-mail software reached $1.6 billion in 1996, and will reach $2.6 billion in the year 2000. This is equivalent to a 19 percent annual growth rate.

But there is a critical problem to be addressed: the vulnerability that e-mail brings to both data (information stored in computers) and resources (computers themselves) once a connection with the Internet is established.

Messages travel from computer to computer openly and freely, making them very easy to intercept at intermediate points. Users may choose not to intercept messages or may be prevented from doing so by restrictions in their network operating system access privileges, but the fact is that security is based on the honesty, ignorance, or indifference of those at the intermediate points. And even worse, the message sender has no control over which intermediate points are used.

To understand the possible threats to e-mail messages, we must consider what happens as a message makes its way from sender to receiver. First, the message passes through a large number of computers as it travels over a network. Each computer along the way can make a copy of the message. Second, the message arrives at its destination and waits until the intended receiver picks it up. During this time, the message is vulnerable to being read or copied by the computer's operator. Last, depending on how the recipient reads mail, the message may be susceptible to electronic eavesdropping; that is, when the message moves from the destination computer's hard disk to the screen, it can be invisibly intercepted.

These conditions have created a growing demand for authentication and confidentiality services to supplement the basic service of e-mail [6].

3. Security goals and cryptographic techniques

In the Internet communication environment, these needs are being met through the use of cryptographic techniques [7]. We should be aware of the importance of developing an overall strategy for computer security so that time spent in encryption efforts is not rendered useless further down the road. In general, computer security has several aims:

Cryptographic techniques can be grouped into two types (Figure 1): private-key cryptosystems and public-key cryptosystems. A unique secret key, shared by the sender and the receiver, is used in private-key systems and is used for both encryption and decryption. On the other hand, public-key systems use a pair of mathematically related keys for each member in the system: a public key for the encryption process and a private key for the decryption process.

Figure 1. Cryptographic techniques

The main advantage of public-key cryptography is increased security because the private key does not need to be transmitted. But in private-key cryptography there is always a risk of key interception during transmission. Other advantages of public-key cryptosystems are that they provide a method for digital signature implementations and that they do not need the huge number of keys required by private-key cryptosystems for wide network systems [8].

In practice, most attacks on private- and public-key systems are aimed at the key-management level rather than at the cryptographic algorithm itself. In fact, key management is the hardest part of cryptography [9]. Designing secure cryptographic algorithms and protocols is not easy, but keeping the keys secret is much more difficult. Even if the algorithm used for encryption is computationally unfeasible to break, the entire system is vulnerable if the keys are not adequately protected. Users must be able to securely obtain a key pair well suited to efficiency and security needs. There must be a way to look up another user's public keys and to make one's own key public. Users must have confidence in the legitimacy of the other user's public keys; otherwise, an intruder can either change public keys listed in a directory or impersonate another user.

4. Key management systems

Several techniques are used for public-key management. They are either centralized or distributed in their design. Unfortunately, both designs have certain problems; therefore, it is the goal of our design is to use a hybrid system to avoid them.

The development of our system was a result of the creation of the RedIRIS Security for Electronic Mail working group in December 1995. Its main goal was to create a secure mail service for RedIRIS users (Figure 2). Some simple security and cryptography documents were created for RedIRIS users and individuals in charge of the mail service. Other private e-mail programs were studied and PGP [10] was selected because of its widespread use and low requirements (although, as we will see later, our design is very useful for any ciphered mail program). One objective that still has not been achieved by RedIRIS is utilization of public keys certifying infrastructure for extended use. This is precisely the step that is developed in our scheme. But before introducing it, we will examine the previously mentioned techniques used for public-key management and the problems found in them.

Figure 2. RedIRIS infrastructure

Centralized management systems [11] use a key distribution center (KDC) as a receiver of a user's public-key requests (Figure 3). Generally, the KDC can be something of a bottleneck in the central system because a user must ask the KDC for a public key for each user to be contacted. Also, a single person is in charge of the whole security scheme, and if this person is dishonest, the guarantee of privacy in the whole system disappears.

Figure 3. Centralized key-management systems

In distributed management systems, two approaches (Figures 4a-4b) can be considered [12]:

The first one uses synchronized key servers with replicated versions of public-key databases throughout the Internet. But such synchronization becomes intractable because its complexity increases exponentially as the number of users of the e-mail system grows. It is important to realize that, when a key server is used, there is really no way to verify whether or not a user's key is legitimate since the servers, at least for PGP, do not check the authenticity of the keys they store (key servers are not given as officially supported services by the universities or companies where they reside).

The second approach does not use key servers because the key is directly requested from the key owner. The drawback of this system is that a user cannot verify the validity of any other user's key. When a key is received, there is no guarantee that the user will know who is signing the mentioned key (introducers).

Figure 4a. Synchronized key servers
Figure 4b. No key servers

5. A hybrid key-management system

The annual growth of Internet users and their increasing need for security in e-mail systems urges us to make user simplicity one of our main goals. Most users are not very knowledgeable about computer tools, including e-mail; therefore, using the system must be easy and must appeal to users with limited skills. It is equally important because of the huge number of users to keep network traffic from increasing.

In addition, key signers must not be mere users. They must be true certifying authorities (CAs). In contrast to other designs with a single authority, our proposal considers the use of a group of CAs, each operating independently. Lastly, to instill greater trust in the system, there is just one copy of each public key in the network.

5.1 System architecture

The previous considerations lead us to propose a hierarchical system based on the structure of network domains. The domains identify a network host, considering the standard format [13],[14]. So, as an example, Figure 5 shows the relation between the servers of each domain for our address lcc.uma.es.

In the proposed scheme, each group of users registers its public keys in a database located in a key service unit (KSU), where its e-mail office resides (Figure 5). The database fields are local user name, public key, public-key certification, and creation timestamp. The set of KSUs forms a hierarchy of nodes where each node stands for a subdomain of the domain above it.

Figure 5. Hierarchy of nodes and KSU components

5.2 How the system functions

Every KSU has a CA, responsible for key maintenance and system integrity. All CAs registers their key in the database of the KSU immediately above them in the hierarchy, if that exists, and the key is then authenticated by the CA in that KSU. All the keys in these databases are certified by the corresponding CA. As was mentioned before, each public key is stored only in the e-mail office closest to the user. Synchronizing the distributed systems becomes unnecessary, so key updating is very simple.

Key requests

We will outline two possible situations: First, we consider the case of a user who wants to obtain the key of another user in a remote system having the same type of key-management system; second, we consider the tools we will use when a user requests a key from a user with another key-management system.

Remote user with the same type of key-management system

Whenever the key of any user, A, is needed by another user, B, this user requests it (indicating A's e-mail address) from the user's own KSU(B). This unit establishes a link with KSU(A), which sends A's public key and its creation timestamp to KSU(B). A typical scenario of a simple key request is shown in Figure 6.

Figure 6. A simple key request (no certification)

It can be seen that certification has not been used; but user B may need an authentication guarantee of A's key, and so B will request not only that key (Figure 7, case 1), but also certification from higher authorities in the domain hierarchy. This certificate could consist of a digital signature [15], [16], [17] from the corresponding authority. In this case, KSU(A) sends the following to KSU(B):

Obviously, the KSU(A) authority's public key is needed to verify the certificate.

Moreover, user B may also demand the verification of the KSU(A) public key. If this is the case (Figure 7, case 2), KSU(A) requests the key certification of its own CA from the unit it depends on, that is, KSU (KSU(A), and the public key of the latter. As a general rule, user B can choose the certification depth level within the unit hierarchy that A is attached to.

Figure 7. Data flows for one and two levels of certification

A dishonest CA cannot cheat any user except one directly dependent on it. In such cases, the CA might send false keys of the users below the CA's KSU and intercept their communications without being discovered. However, this risk can be avoided and the solution is currently being developed. In any case, this situation is not very likely to happen. Instead, it is much more probable that a fake CA takes the place of a real one. If a CA is not the authentic one, then any key request with a certification level greater than one can be used as a safeguard against such a CA. The system enforces the use of the private key in those certifications, and this is only known by the genuine CA.

Having a reliable CA in every KSU results in less need for authenticity verification. There are two reasons for this: (1) direct access to the KSU closer to users, and (2) the inherent security of the place where keys are stored because the CA is the only entity that interacts with the public-key database.

We have previously referred to system simplicity as a way of preventing rejection by users. As has been already shown, all the work is automatically carried out by the KSU. The user's only task is to request the key and the certification level.

Dissimilar key-management systems

The system proposed has the additional possibility of interacting with other key services. This is totally transparent to the user because the system itself is responsible for the acquisition of the requested key. The most frequently used key services are

5.3 Performance improvement

The following discussion uses the term "proxy" to mean "key cache" and should not be confused with the proxy servers used by other systems, which are external entities (and introduce an element of insecurity into the scheme).

It was previously mentioned that one priority is to avoid a high rate of network traffic. Decreasing the traffic rate can be achieved by avoiding different transfers of one key to the same KSU in the network. To facilitate this, every KSU is provided with a proxy that stores the last keys requested. The following list is data that a registered remote user can find in the proxy:

If user B requests the key of any Internet user to KSU(B), the proxy will be asked for first. If it does not exist or if it exists with a lower certification level than the one requested by B, KSU(B) carries out the request as explained above. In any other case, the request includes a creation timestamp, to be verified by KSU(A). If timestamps are equal, KSU(A) simply sends a confirmation; otherwise it sends the new key (Figure 8).

Figure 8. Using proxies when a key is present but expired

Any CA can decide whether or not proxies are useful for their users and enable or disable them. Also, the CA can adjust proxy behavior to fit the user's needs.

The use of proxies can reduce multiple requests for the same key, which cause useless transactions over the network. A practical consequence is that performance is enhanced. The tests show that in a typical situation where users request a set of common keys this improvement is significant.

6. Conclusions and future work

This paper introduces a system for a public-key service to provide secure e-mail for Internet users. It has been demonstrated how existing designs are not completely satisfactory or secure and how a hybrid system can solve these problems and enhance network performance, avoiding a high rate of network traffic. In contrast to other certification systems, this one does not introduce interoperation islands, does not create bottlenecks, and avoids problems of inconsistency and key redundancies. The hierarchical structure of the system is adapted to the network structure and it allows the existence of authorities at different levels. In addition to this, the system is easily used, transparent to the user, and compatible with most other existing key services, allowing for the addition of future ones.

This system, recently introduced in the academic environment, is being tested for performance and user acceptance before being put into more widespread use. Further improvements to the system are also being developed.

7. References

  1. Forrester Research Institute
  2. Sánchez F., "Internet en España. El Laberinto," Comunicaciones World. March 1996 (Supplement).
  3. RedIRIS (Red de Interconexión de Recursos Informáticos)
  4. CSIC (Consejo Superior de Investigaciones Científicas)
  5. IDC (International Data Corporation)
  6. Bahreman, Alireza, "Certified Electronic Mail," Proceedings of the Internet Society 1994 Workshop on Network and Distributed System Security, 1994.
  7. Davies, Donald W., "Applying the RSA Digital Signature to Electronic Mail,"
    IEEE Computer, February 1983.
  8. Diffie, Whitfield, "The First Ten Years of Public-Key Cryptography," Proceedings of the IEE 76 (1988) 560-76.
  9. Fumy, S.; Landrock, P., "Principles of Key Management," IEEE Journal on Selected Areas in Communications, June 1993.
  10. Zimmerman, P. R., The Official PGP User's Guide, MIT Press, 1995.
  11. Popek, G.; Kline, C., "Encryption and Secure Computer Networks, "ACM Computing Surveys, December 1979.
  12. Garfinkel, S., "PGP: Pretty Good Privacy," O'Really & Associates, Inc., 1995.
  13. Mockapetris, P. V., "DNS encoding of network names and other types," RFC 1101, 1 April 1989.
  14. System and Network Administration, Administering DNS SUN Microsystems.
  15. Rivest, R. L.; Shamir, A.; Adleman, L. A., "A Method for obtaining digital signatures and public key cryptosystems," Comm. of the ACM 21, 2 (February 1978) 120-126.
  16. Even, S.; Goldreich, O.; Micali, S., "On-Line/Off-Line Digital Signatures," Lecture Notes in Computer Science 435. Proceedings of Crypto'89. Springer-Verlag, 1989.
  17. Gennaro, R.; Jarecki, S.; Krawczyk, H.; Rabin, T., "Robust Threshold DSS Signatures," Lecture Notes in Computer Science 1070. Proceedings of Eurocrypt'96, Springer-Verlag 1996.