- Email: [email protected]
COSINE community
Computer Networks and ISDN Systems 26 (1993) 263-267 North-Holland
263
Implementing and proving security services for the RARE/COSINE community Susan Barry
a,
Patricia McQuillan
a,
Michael Purser
a
Jonathan Moffett b
Baltimore Technologies Ltd,, 36 Fitzwilliam Square, Dublin 2, Ireland h University of York, UK
Abstract Secure electronic mail (PEM) and remote access services, using asymmetric key cryptology have been developed and proved between several European countries. The paper reviews the project, high-lighting its shortcomings, since they are most likely to be of interest to others.
Keywords: Privacy enhanced mail; Public key cryptology; Certification authority; Secure remote access; Smart cards
1. Introduction The COSINE Sub-Project P8 (now named "FORTRESS") provides secure electronic mail (Privacy Enhanced MaiI--PEM) and remote access services over wide area networks using asymmetric key cryptology. Its main features have been described in a previous paper [6]. The design phase lasted from November 1991 until April 1992, and the implementation terminated in October 1992 with the installation of systems in six different countries. From then until March 1993 evaluation and proving of FORTRESS took place. This paper is largely concerned with this latter aspect of the project. However, it is necessary to review the security services provided if the evaluation and proving are to be meaningful. This is done in Section 2. Sections 3 and 4 are critiques of the user-related and technical aspects of the services. Section 5 describes the proving process, and Section 6 contains brief conclusions.
the sender's digital signature to them; and may be made confidential by means of encryption. Public key cryptology (RSA) [8] is used for the signatures, and for encrypting the symmetric keys which in turn are used to encrypt (DES) [1] the message text. The use of public key cryptology usually implies the existence of a Certification Authority (CA) which issues certificates guaranteeing the genuineness of users' public keys. (This is done by having the CA sign the user's identity and public key as a unit.) In FORTRESS the CA, operated in Dublin by Baltimore Technologies, generates as well as certifies users' secret and public keys. New users are "recommended" by
~ -~-CA ,~
~ ' ~t"
Chipcard PIN ~OPerator
2. Security service overview (Fig. 1) The principal service provided is secure messaging based on PEM [3]. Messages may be guaranteed as uncorrupted and authentic by attaching Correspondence to: S. Barry, Baltimore Technologies Ltd., 36 Fitzwilliam Square, Dublin 2, Ireland
~
" Signed,encrypted
User RN
" ~ User RN
P1, 1:>2= ParticipantSites SPA = SecureRemoteAccess
0169-7552/93/$06.00 © 1993 - Elsevier Science Publishers B.V. All rights reserved
Fig. 1. Security overview.
264
S. Barry et al. / Security services
existing privileged users, called Security Administrators (SAs); this is an on-line operation between the SA's system and the CA over the network. This remote access to the CA is made secure by means of a two-way X.509 strong authentication procedure [2], in which both parties are reciprocally and securely identified, and during which a symmetric key is established for streamencrypting the subsequent dialogue using BSA
PSE CeaJfmates
Recommenda~ons Revoca~ons DownloadRequest
[7]. In response to a successful Recommendation an SA receives, on behalf of the new user, a Personal Secure Environment (PSE) encrypted under a DES-key, derived from a PIN via a one-way function. This PIN is itself submitted, encrypted, in the prior recommendation. The PSE contains the user's secret key and other cryptographic data. It is a local matter as to how this PSE is made available to the new user; but once this has been achieved he can p e r f o r m signing/authentication and encryption/decryption operations for PEM and access to the CA, by entering his PIN as required to decrypt (momentarily) his PSE. Naturally, the user's first operation on receiving a PSE will be to change the PIN. In addition to Recommendations, other applications at the CA are made available to users over the secure remote access service. For example an SA can revoke a certificate, and place it on a blacklist. Revocation would apply if the certificate owner's secret key were compromised, or if the owner were no longer considered to be a suitable system user. Ordinary users can also access the blacklist on the CA, to read it or download it. They can download the database of valid certificates. They can access news flies, etc.
4 Site Fig. 2. Principal on-line CA services.
Fig. 2 shows the principal on-line CA services. To enable the CA to distinguish between ordinary and privileged users (SAs), a user's authorisation attributes are built into his certificate. (Other information, such as an expiry date for its validity, is also built into the certificate.) The CA uses these attributes to control Recommendations, Revocations and other operations according to an authorisation hierarchy. For example, only certain SAs can recommend new SAs at a new user site; SAs in one country cannot revoke users in another, etc. However, the presence of authorisation attributes in the certificate (a necessary concept borrowed from architectures such as Kerberos [4], S E S A M E [5]) causes a F O R T R E S S certificate to be non-standard; i.e. not compatible with X.509. (There are plans to overcome this problem, maintaining F O R T R E S S certificates for use with remote access, but introducing further X.509-compatible certificates to
Susan Barry is a Consultant Engineer with Baltimore Technologies. Since receiving her B.A. in computer science from Trinity College in 1985, her work with the company has been in the areas of X.400, conformance testing and most recently in security. Patricia McQuillan is a Software Engineer with Baltimore Technologies. Since joining the company as a graduate B.Sc. from University College Dublin, she has specialised in the security area, chiefly through her involvement in the COSINE FORTRESS project. Michael Purser is Technical Director of Baltimore Technologies. He has worked in the computer field for over thirty years and is the author of many papers and books including a recent book on Secure Data Networking. Jonathan Moffett is a Senior Research Fellow in the High Integrity Systems Engineering group at the University of York, England. He has previously been consultant on large commercial systems, including acting as computer security adviser at Esso Europe Inc. He received his bachelor's degree in mathematics in 1961 at Trinity College, Cambridge, and his Ph.D. in computing in 1990 at Imperial College, London. He is a Chartered Engineer and a Fellow of the Association of Certified Accountants.
S. Barry et al. / Security services
allow interworking with other systems, e.g. the "Password" project.) At the CA, there are additional functions which enable operators to generate RSA keys, maintain the database and blacklist, etc. The access of operators to the CA is controlled by smart cards. GMD's SecuDe software was used as a basis for the development of the F O R T R E S S software; in particular, it provided the PEM implementation, and the basic functions of the CA. The associated user interfaces, and the software for the secure remote access service, have been developed by Baltimore. The systems run under Unix, on SUN workstations. The remote access to the CA is over X.25 networks.
3. User aspects--a critique Most of the problems in F O R T R E S S were related to the user's view and management of the system: • The CA and its applications, accessed over the secure remote access service, are merely security infrastructure for P E M - - o r possibly some other future applications such as secure file transfer or EDI. PEM itself consists of two services: PEM-SCAN (process a received PEM message) and P E M - C R E A T E (or generate a PEM message). These services are essentially file-to-file processors, which perform the cryptographic functions on the way. They are simple to use, but they are not integrated with any mail or messaging system; principally because too many differing mail systems, not to mention user interfaces, exist amongst project participants. Thus a sender of a PEM message first creates the message; then processes it with P E M - C R E A T E ; and finally uses his normal mail service to transmit the file created by P E M - C R E A T E . This is inconvenient for users.
• The security of the users' end-systems, although it is explicitly outside the scope of the project, is however another practical limitation on the service. Apart from the user's encrypted PSE there is no other project-provided protection of his system. In particular, the genuineness of the code is not checked; and there is no secure control of local access (e.g. over a LAN) to the system. Thus a user, accessing his PEM facility, very probably not only sends his User-ID and
265
Password in clear over the LAN, but also his PSE PIN. In reality, if a user is to have confidence in the security of the PEM service, it is necessary to install the end-system in a secure environment with controlled access. • The decision to provide on-line access to the CA is, we believe, a good one. But it does imply that the CA should provide fast response. This is not always the case. Firstly, Recommendations give rise to the generation of RSA keys, which may take many seconds--indeed more than a minute. A solution to this can be provided by pre-generating keys, and holding them in a cache, although there are obvious security risks with this approach. Secondly, on-line user operations involving the data base of extant and the blacklist of withdrawn certificates can become quite lengthy if those lists are large. Some conventional data processing techniques (sorting?) could have been profitably used in the F O R T R E S S project. • The project was conceived with a single CA serving many participants in many countries, with secure remote access to the CA over X.25. This gives rise to many anomalies. For example, whereas participants may have local security policies, procedures, etc., the CA (whose security is fundamental to all services) is not subject to those policies. There are questions about who is responsible for handling security incidents. There must be questions in participants' minds as to how secure the CA really is. In reality, serious users wish to operate their own CAs for secure internal traffic. Insofar as they require secure external communication services, these could be supported by the cross-certification of CAs' public keys, enabling a user in one domain to authenticate a certificate belonging to a user in another domain. In turn, if CAs are to be local, it might be wiser to have them operate over a LAN-compatible infrastructure, rather than over X.25. • In an operational environment, as opposed to F O R T R E S S ' pilot service, another problem affecting users is that of out-of-date certificates. In principle, a signature to a document is valid long after the signatory's secret key has expired, provided that the signature was generated before the expiry. Similarly, a message may be held in encrypted form for years; the public key required to decrypt it should be still available, even if withdrawn. There is a need for a service making available out-of-date certificates to users, which
266
S. Barry et al. / Security services
has not yet been addressed in FORTRESS. The above problem areas: • PEM integration with the user's preferred mail environment • Security of users' end-systems • On-line response delays at the CA • In-house versus external CA • The availability of expired certificates to users have been identified by F O R T R E S S participants and the development team as important. Designers and implementors of future systems are advised to take note?
4. Technical aspectsmthe critique continues The F O R T R E S S security services work well and effectively; but there is room for improvement. In addition to aspects visible to users (see above) there are technical problem areas visible only to system operators, or to software specialists. Some of these are now pre.sented. • The initialisation of security systems usually requires manual or semi-manual procedures for the distribution of first-time keys, PINs, etc. Similarly, reinitialisation (e.g. when a key is compromised) will need such procedures, which may indeed be more demanding. As an example, if a new public key for the CA is to replace the old one, because the old one can no longer be trusted, a major logistical problem arises since all systems are affected. The solutions to these initialisation problems need to be carefully specified in advance; not left to improvisation--possibly in panic conditions. • The identification of persons and systems is always more complex than it appears. FORTRESS' SecuDe uses serial numbers as unique identifiers of certificates (per issuer). But users refer to a certificate by its owner's name. The maintenance of an unambiguous mapping between the two--given that users may have more than one certificate, may be Revoked and re-Recommended several times, etc.--is a potential source of problems. Additionally, how is the integrity of this serial number within the certificategenerating software assured? What form should the user's name take? The PEM naming hierarchy does not recognize the existence of a supranational entity such as COSINE (or Europe)
within which countries in the X.500 name structure can fit. • The F O R T R E S S CA is operated by the system developers, Baltimore Technologies. It is a PIN-controlled application accessed from Unix. This situation should be reversed. The CA should be the main program (PIN-controlled), with escape to Unix barred unless the operator has special privileges. The PIN itself is read from a chipcard; but it is inserted into the chipcard '° manually". A rigorous separation between development and operation is required, in which developers hand over to operators a system (such as the CA) in which the operator's capabilities are defined and restricted. If this hand-over is accepted the operator can thereafter be made accountable for the system. • Users of the systems must trust the correctness of the software. But in security systems there is ample scope for "spoof" software, which (for example) states that a signature has been authenticated correctly, a remote system has been identified securely, or a text has been encrypted, when it has not. Spoof software can trick users into entering their PINs to it, or into performing one operation (Revocation) when another was intended (Recommendation). Really secure software should be encrypted on file, integrity checked on loading; backups should be integrity checked and encrypted, etc. F O R T R E S S does not do this. • However cryptographic keys are secured (e.g. in encrypted PSEs for F O R T R E S S ) there comes a time when they are used. Unless this is done within tamper-proof hardware, they are then at risk. Spoof software (see above) can capture them. More prosaically, a user may simply be diverted half-way through such a critical o p e r a t i o n - - a n d the key left unprotected in memory. Timeouts and memory clean-up facilities are needed to minimise such risks. F O R T R E S S employs timeouts, but systematic clearing of memory after use is not practised. • In addition to the above problem areas there are several other vulnerabilities in the FORTRESS implementation; ranging from basic design problems (such as one PSE for the CA and all its operators) to omissions (such as proper purging facilities, e.g. for the certificate blacklist) due to time constraints and the limited scale of the project. Most of these however are minor,
S. Barry et al. / Security services
and too particular to FORTRESS to be worth detailing here. 5. The proving process The points made in Sections 3 and 4 were identified in the course of the proving phase. The COSINE Project Management L/nit, right from the start, regarded the testing out of the effectiveness of the security services as an integral part of the sub-project, and planned and budgeted for this activity. Budgetary constraints meant that it was not possible to bring in independent consultants to perform the entire proving activity, because of the amount of time which would have been required for familiarisation with the details of the system. Therefore the paper analysis and computer-based attacks were undertaken by the developers, supervised by an independent consultant. A systematic proving process was planned, involving both developers and users. It included: • The regular exchange of valid and deliberately corrupted PEM messages between participants over a 3-month period, according to a weekly rota. These exchanges revealed much about "user-friendliness", and the reliability of the underlying E-Mail carriers, but no occurrences of security failures were recorded. • A "paper" analysis of the systems implemented which culminated in a list of some 60 potential vulnerabilities, the most important of which have been discussed above. • Computer-based attacks on the security mechanisms, using defective certificates, weak keys, etc. These attacks were designed to probe further the vulnerabilities identified in the paper analysis. In reality, while interesting, they yielded no unforeseen results.About sixty users (i.e. issued key-pairs) were involved in the proving process, and some 20 percent of keypairs were withdrawn and replaced by new ones during the three-month period. Some 500 PEM messages were transmitted daily and approximately 20 secure remote accesses to the CA were made daily. 6. Conclusions The proving activity in the project has served two useful purposes: (1) It has ensured that a number of weaknesses,
267
already known to the developers, were collected and evaluated in a methodical fashion. (2) The systematic computer-based attacks, which revealed no further significant weaknesses, gave additional confidence in the robustness of the system. The FORTRESS systems and software have proved to be remarkably secure and robust, given their pilot nature. The weaknesses which have been identified are almost all in the "environment"--the physical, network and organisational surroundings within which FORTRESS operates. Genuine FORTRESS problems are few, and essentially easily remedied. More generally, in retrospect it is clear that although the international "community" approach was necessary under COSINE, the requirement for operational security services is nearly always internal--within an organisation. The FORTRESS products need to be adapted to this requirement (e.g. a foolproof CA); real user groups (generally administrative not technical persons) need to be prepared to receive them. This is the intended next phase of the project.
Acknowledgements It is a pleasure to acknowledge the cooperation received by all participants in the project, and the support and guidance given by the COSINE Project Management Unit, in particular Maria Pallares.
References [1] ANSI X3.92, Data Encryption Algorithm. [2] CCITT (Blue Book) Fascicle VIII.8 X.509 (1988), The Directory--Authentication Framework. [3] Internet RFC 1113, 1114, 1115, Privacy Enhanced Mail. [4] MIT Project Athena RFC, Draft 1, April 1989, The Kerberos Network Authentication Service Overview. [5] T. Parker, ICL Secure Systems, SESAME (Secure European System for Applications in a Multivendor Environment)--An Introduction (BulI/ICL/SNI). [6] M. Purser, COSINE Sub-Project P8: security services, Computer Networks and ISDN Systems 25 (1992) 476-482. [7] M. Purser, A fast stream encryptor, Unpublished. [8] Rivest, Shamir and Adleman, A method for obtaining digital signatures and public key cryptosystems, Comm. A C M 21 (1978).
263
Implementing and proving security services for the RARE/COSINE community Susan Barry
a,
Patricia McQuillan
a,
Michael Purser
a
Jonathan Moffett b
Baltimore Technologies Ltd,, 36 Fitzwilliam Square, Dublin 2, Ireland h University of York, UK
Abstract Secure electronic mail (PEM) and remote access services, using asymmetric key cryptology have been developed and proved between several European countries. The paper reviews the project, high-lighting its shortcomings, since they are most likely to be of interest to others.
Keywords: Privacy enhanced mail; Public key cryptology; Certification authority; Secure remote access; Smart cards
1. Introduction The COSINE Sub-Project P8 (now named "FORTRESS") provides secure electronic mail (Privacy Enhanced MaiI--PEM) and remote access services over wide area networks using asymmetric key cryptology. Its main features have been described in a previous paper [6]. The design phase lasted from November 1991 until April 1992, and the implementation terminated in October 1992 with the installation of systems in six different countries. From then until March 1993 evaluation and proving of FORTRESS took place. This paper is largely concerned with this latter aspect of the project. However, it is necessary to review the security services provided if the evaluation and proving are to be meaningful. This is done in Section 2. Sections 3 and 4 are critiques of the user-related and technical aspects of the services. Section 5 describes the proving process, and Section 6 contains brief conclusions.
the sender's digital signature to them; and may be made confidential by means of encryption. Public key cryptology (RSA) [8] is used for the signatures, and for encrypting the symmetric keys which in turn are used to encrypt (DES) [1] the message text. The use of public key cryptology usually implies the existence of a Certification Authority (CA) which issues certificates guaranteeing the genuineness of users' public keys. (This is done by having the CA sign the user's identity and public key as a unit.) In FORTRESS the CA, operated in Dublin by Baltimore Technologies, generates as well as certifies users' secret and public keys. New users are "recommended" by
~ -~-CA ,~
~ ' ~t"
Chipcard PIN ~OPerator
2. Security service overview (Fig. 1) The principal service provided is secure messaging based on PEM [3]. Messages may be guaranteed as uncorrupted and authentic by attaching Correspondence to: S. Barry, Baltimore Technologies Ltd., 36 Fitzwilliam Square, Dublin 2, Ireland
~
" Signed,encrypted
User RN
" ~ User RN
P1, 1:>2= ParticipantSites SPA = SecureRemoteAccess
0169-7552/93/$06.00 © 1993 - Elsevier Science Publishers B.V. All rights reserved
Fig. 1. Security overview.
264
S. Barry et al. / Security services
existing privileged users, called Security Administrators (SAs); this is an on-line operation between the SA's system and the CA over the network. This remote access to the CA is made secure by means of a two-way X.509 strong authentication procedure [2], in which both parties are reciprocally and securely identified, and during which a symmetric key is established for streamencrypting the subsequent dialogue using BSA
PSE CeaJfmates
Recommenda~ons Revoca~ons DownloadRequest
[7]. In response to a successful Recommendation an SA receives, on behalf of the new user, a Personal Secure Environment (PSE) encrypted under a DES-key, derived from a PIN via a one-way function. This PIN is itself submitted, encrypted, in the prior recommendation. The PSE contains the user's secret key and other cryptographic data. It is a local matter as to how this PSE is made available to the new user; but once this has been achieved he can p e r f o r m signing/authentication and encryption/decryption operations for PEM and access to the CA, by entering his PIN as required to decrypt (momentarily) his PSE. Naturally, the user's first operation on receiving a PSE will be to change the PIN. In addition to Recommendations, other applications at the CA are made available to users over the secure remote access service. For example an SA can revoke a certificate, and place it on a blacklist. Revocation would apply if the certificate owner's secret key were compromised, or if the owner were no longer considered to be a suitable system user. Ordinary users can also access the blacklist on the CA, to read it or download it. They can download the database of valid certificates. They can access news flies, etc.
4 Site Fig. 2. Principal on-line CA services.
Fig. 2 shows the principal on-line CA services. To enable the CA to distinguish between ordinary and privileged users (SAs), a user's authorisation attributes are built into his certificate. (Other information, such as an expiry date for its validity, is also built into the certificate.) The CA uses these attributes to control Recommendations, Revocations and other operations according to an authorisation hierarchy. For example, only certain SAs can recommend new SAs at a new user site; SAs in one country cannot revoke users in another, etc. However, the presence of authorisation attributes in the certificate (a necessary concept borrowed from architectures such as Kerberos [4], S E S A M E [5]) causes a F O R T R E S S certificate to be non-standard; i.e. not compatible with X.509. (There are plans to overcome this problem, maintaining F O R T R E S S certificates for use with remote access, but introducing further X.509-compatible certificates to
Susan Barry is a Consultant Engineer with Baltimore Technologies. Since receiving her B.A. in computer science from Trinity College in 1985, her work with the company has been in the areas of X.400, conformance testing and most recently in security. Patricia McQuillan is a Software Engineer with Baltimore Technologies. Since joining the company as a graduate B.Sc. from University College Dublin, she has specialised in the security area, chiefly through her involvement in the COSINE FORTRESS project. Michael Purser is Technical Director of Baltimore Technologies. He has worked in the computer field for over thirty years and is the author of many papers and books including a recent book on Secure Data Networking. Jonathan Moffett is a Senior Research Fellow in the High Integrity Systems Engineering group at the University of York, England. He has previously been consultant on large commercial systems, including acting as computer security adviser at Esso Europe Inc. He received his bachelor's degree in mathematics in 1961 at Trinity College, Cambridge, and his Ph.D. in computing in 1990 at Imperial College, London. He is a Chartered Engineer and a Fellow of the Association of Certified Accountants.
S. Barry et al. / Security services
allow interworking with other systems, e.g. the "Password" project.) At the CA, there are additional functions which enable operators to generate RSA keys, maintain the database and blacklist, etc. The access of operators to the CA is controlled by smart cards. GMD's SecuDe software was used as a basis for the development of the F O R T R E S S software; in particular, it provided the PEM implementation, and the basic functions of the CA. The associated user interfaces, and the software for the secure remote access service, have been developed by Baltimore. The systems run under Unix, on SUN workstations. The remote access to the CA is over X.25 networks.
3. User aspects--a critique Most of the problems in F O R T R E S S were related to the user's view and management of the system: • The CA and its applications, accessed over the secure remote access service, are merely security infrastructure for P E M - - o r possibly some other future applications such as secure file transfer or EDI. PEM itself consists of two services: PEM-SCAN (process a received PEM message) and P E M - C R E A T E (or generate a PEM message). These services are essentially file-to-file processors, which perform the cryptographic functions on the way. They are simple to use, but they are not integrated with any mail or messaging system; principally because too many differing mail systems, not to mention user interfaces, exist amongst project participants. Thus a sender of a PEM message first creates the message; then processes it with P E M - C R E A T E ; and finally uses his normal mail service to transmit the file created by P E M - C R E A T E . This is inconvenient for users.
• The security of the users' end-systems, although it is explicitly outside the scope of the project, is however another practical limitation on the service. Apart from the user's encrypted PSE there is no other project-provided protection of his system. In particular, the genuineness of the code is not checked; and there is no secure control of local access (e.g. over a LAN) to the system. Thus a user, accessing his PEM facility, very probably not only sends his User-ID and
265
Password in clear over the LAN, but also his PSE PIN. In reality, if a user is to have confidence in the security of the PEM service, it is necessary to install the end-system in a secure environment with controlled access. • The decision to provide on-line access to the CA is, we believe, a good one. But it does imply that the CA should provide fast response. This is not always the case. Firstly, Recommendations give rise to the generation of RSA keys, which may take many seconds--indeed more than a minute. A solution to this can be provided by pre-generating keys, and holding them in a cache, although there are obvious security risks with this approach. Secondly, on-line user operations involving the data base of extant and the blacklist of withdrawn certificates can become quite lengthy if those lists are large. Some conventional data processing techniques (sorting?) could have been profitably used in the F O R T R E S S project. • The project was conceived with a single CA serving many participants in many countries, with secure remote access to the CA over X.25. This gives rise to many anomalies. For example, whereas participants may have local security policies, procedures, etc., the CA (whose security is fundamental to all services) is not subject to those policies. There are questions about who is responsible for handling security incidents. There must be questions in participants' minds as to how secure the CA really is. In reality, serious users wish to operate their own CAs for secure internal traffic. Insofar as they require secure external communication services, these could be supported by the cross-certification of CAs' public keys, enabling a user in one domain to authenticate a certificate belonging to a user in another domain. In turn, if CAs are to be local, it might be wiser to have them operate over a LAN-compatible infrastructure, rather than over X.25. • In an operational environment, as opposed to F O R T R E S S ' pilot service, another problem affecting users is that of out-of-date certificates. In principle, a signature to a document is valid long after the signatory's secret key has expired, provided that the signature was generated before the expiry. Similarly, a message may be held in encrypted form for years; the public key required to decrypt it should be still available, even if withdrawn. There is a need for a service making available out-of-date certificates to users, which
266
S. Barry et al. / Security services
has not yet been addressed in FORTRESS. The above problem areas: • PEM integration with the user's preferred mail environment • Security of users' end-systems • On-line response delays at the CA • In-house versus external CA • The availability of expired certificates to users have been identified by F O R T R E S S participants and the development team as important. Designers and implementors of future systems are advised to take note?
4. Technical aspectsmthe critique continues The F O R T R E S S security services work well and effectively; but there is room for improvement. In addition to aspects visible to users (see above) there are technical problem areas visible only to system operators, or to software specialists. Some of these are now pre.sented. • The initialisation of security systems usually requires manual or semi-manual procedures for the distribution of first-time keys, PINs, etc. Similarly, reinitialisation (e.g. when a key is compromised) will need such procedures, which may indeed be more demanding. As an example, if a new public key for the CA is to replace the old one, because the old one can no longer be trusted, a major logistical problem arises since all systems are affected. The solutions to these initialisation problems need to be carefully specified in advance; not left to improvisation--possibly in panic conditions. • The identification of persons and systems is always more complex than it appears. FORTRESS' SecuDe uses serial numbers as unique identifiers of certificates (per issuer). But users refer to a certificate by its owner's name. The maintenance of an unambiguous mapping between the two--given that users may have more than one certificate, may be Revoked and re-Recommended several times, etc.--is a potential source of problems. Additionally, how is the integrity of this serial number within the certificategenerating software assured? What form should the user's name take? The PEM naming hierarchy does not recognize the existence of a supranational entity such as COSINE (or Europe)
within which countries in the X.500 name structure can fit. • The F O R T R E S S CA is operated by the system developers, Baltimore Technologies. It is a PIN-controlled application accessed from Unix. This situation should be reversed. The CA should be the main program (PIN-controlled), with escape to Unix barred unless the operator has special privileges. The PIN itself is read from a chipcard; but it is inserted into the chipcard '° manually". A rigorous separation between development and operation is required, in which developers hand over to operators a system (such as the CA) in which the operator's capabilities are defined and restricted. If this hand-over is accepted the operator can thereafter be made accountable for the system. • Users of the systems must trust the correctness of the software. But in security systems there is ample scope for "spoof" software, which (for example) states that a signature has been authenticated correctly, a remote system has been identified securely, or a text has been encrypted, when it has not. Spoof software can trick users into entering their PINs to it, or into performing one operation (Revocation) when another was intended (Recommendation). Really secure software should be encrypted on file, integrity checked on loading; backups should be integrity checked and encrypted, etc. F O R T R E S S does not do this. • However cryptographic keys are secured (e.g. in encrypted PSEs for F O R T R E S S ) there comes a time when they are used. Unless this is done within tamper-proof hardware, they are then at risk. Spoof software (see above) can capture them. More prosaically, a user may simply be diverted half-way through such a critical o p e r a t i o n - - a n d the key left unprotected in memory. Timeouts and memory clean-up facilities are needed to minimise such risks. F O R T R E S S employs timeouts, but systematic clearing of memory after use is not practised. • In addition to the above problem areas there are several other vulnerabilities in the FORTRESS implementation; ranging from basic design problems (such as one PSE for the CA and all its operators) to omissions (such as proper purging facilities, e.g. for the certificate blacklist) due to time constraints and the limited scale of the project. Most of these however are minor,
S. Barry et al. / Security services
and too particular to FORTRESS to be worth detailing here. 5. The proving process The points made in Sections 3 and 4 were identified in the course of the proving phase. The COSINE Project Management L/nit, right from the start, regarded the testing out of the effectiveness of the security services as an integral part of the sub-project, and planned and budgeted for this activity. Budgetary constraints meant that it was not possible to bring in independent consultants to perform the entire proving activity, because of the amount of time which would have been required for familiarisation with the details of the system. Therefore the paper analysis and computer-based attacks were undertaken by the developers, supervised by an independent consultant. A systematic proving process was planned, involving both developers and users. It included: • The regular exchange of valid and deliberately corrupted PEM messages between participants over a 3-month period, according to a weekly rota. These exchanges revealed much about "user-friendliness", and the reliability of the underlying E-Mail carriers, but no occurrences of security failures were recorded. • A "paper" analysis of the systems implemented which culminated in a list of some 60 potential vulnerabilities, the most important of which have been discussed above. • Computer-based attacks on the security mechanisms, using defective certificates, weak keys, etc. These attacks were designed to probe further the vulnerabilities identified in the paper analysis. In reality, while interesting, they yielded no unforeseen results.About sixty users (i.e. issued key-pairs) were involved in the proving process, and some 20 percent of keypairs were withdrawn and replaced by new ones during the three-month period. Some 500 PEM messages were transmitted daily and approximately 20 secure remote accesses to the CA were made daily. 6. Conclusions The proving activity in the project has served two useful purposes: (1) It has ensured that a number of weaknesses,
267
already known to the developers, were collected and evaluated in a methodical fashion. (2) The systematic computer-based attacks, which revealed no further significant weaknesses, gave additional confidence in the robustness of the system. The FORTRESS systems and software have proved to be remarkably secure and robust, given their pilot nature. The weaknesses which have been identified are almost all in the "environment"--the physical, network and organisational surroundings within which FORTRESS operates. Genuine FORTRESS problems are few, and essentially easily remedied. More generally, in retrospect it is clear that although the international "community" approach was necessary under COSINE, the requirement for operational security services is nearly always internal--within an organisation. The FORTRESS products need to be adapted to this requirement (e.g. a foolproof CA); real user groups (generally administrative not technical persons) need to be prepared to receive them. This is the intended next phase of the project.
Acknowledgements It is a pleasure to acknowledge the cooperation received by all participants in the project, and the support and guidance given by the COSINE Project Management Unit, in particular Maria Pallares.
References [1] ANSI X3.92, Data Encryption Algorithm. [2] CCITT (Blue Book) Fascicle VIII.8 X.509 (1988), The Directory--Authentication Framework. [3] Internet RFC 1113, 1114, 1115, Privacy Enhanced Mail. [4] MIT Project Athena RFC, Draft 1, April 1989, The Kerberos Network Authentication Service Overview. [5] T. Parker, ICL Secure Systems, SESAME (Secure European System for Applications in a Multivendor Environment)--An Introduction (BulI/ICL/SNI). [6] M. Purser, COSINE Sub-Project P8: security services, Computer Networks and ISDN Systems 25 (1992) 476-482. [7] M. Purser, A fast stream encryptor, Unpublished. [8] Rivest, Shamir and Adleman, A method for obtaining digital signatures and public key cryptosystems, Comm. A C M 21 (1978).