Current Status of Public Key Infrastructures

Transcription

1 Current Status of Public Key Infrastructures Tejan Balakrishnan M.Sc in Information Systems The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others. I understand that failure to attribute material which is obtained from another source may be considered as plagiarism. (Signature of student)

2 Summary This report aims to review the area of Information Security in general, and Public Key Infrastructure in particular. Public Key Infrastructure, as a technology, has an interesting history when it first emerged in the late nineties, it was labelled as the solution to virtually all problems of enterprise security. It did not quite live up to this early hype but since then, has refused to disappear into the realms of forgotten technologies. This report attempts to review the basic components around which the concept of PKI was born, and to describe in further detail the architectural and functional backbone of PKI. The theoretical concepts described are further illustrated by means of a case study of the security model of the UK e-science Grid. However, the main focus of the report is the study and analysis of the various problems and issues that surround PKI today - these are the reasons held responsible for the failure of PKI to live up to the initial hype. The security community has recognized these weaknesses, and the report also gives a detailed description of the steps that have been taken to address these shortcomings and the general direction in which PKI is going today. This includes a brief explanation of the growing role of XML-based solutions in the field of Internet security and Public Key Infrastructures. Additionally, the report includes a section detailing the development and evaluation of an animated, interactive web-based teaching resource for PKI. i

3 Acknowledgements I would like to take this opportunity to express my sincerest gratitude to all those who have helped to make this project a success. In particular, I would like to mention my supervisor, Professor Bill Whyte. His expert advice helped me give my project a sense of direction, while his friendly and patient attitude helped me through the otherwise stressful challenge of a Masters project. I would like to thank my assessor Professor Peter Dew for his comments at two vital stages of the project. His comments on the interim report early on, as well as those that he gave after the demonstration later in the project provided important guidelines. I am also grateful to Mr. Martin Thompson for pointing me to the resources relevant to security on the Grid. I would like to thank Mr. Ahmad Damen whose impromptu crash-course on Flash made the development of the web-based teaching resource possible. I would also like to thank all those who have helped me make the most of my year here in Leeds. I would like to thank my mother, my friends back home in Calcutta and my relatives. I would also like to thank Mr. Rahul Ahuja, Ms. Dima Damen, Ms. Diana Torres, Mr. Inderjit Singh, Mr Udoyon Bhaduri, Ms. Amrita Paul and Ms. Halima Hossain for their friendship and support throughout this year. It is much appreciated and this would not have been possible without you. Finally, I would like to dedicate this project to the memory of my father. Thank You All! ii

4 Table Of Contents Summary... i Acknowledgements... ii Table Of Contents... iii 1. Introduction Understanding the problem Approach to Solution Structure of the Report Understanding the Problem Chapters 1, 2 and Producing a Solution Chapters 4, 5, 6 and Evaluation Chapter Introduction to Information Security Information Security Cryptography and Encryption Private Key Cryptography Public Key Cryptography Digital Signatures Digital Certificates Where Public Key Infrastructures Fit In Public Key Infrastructures Generic Architecture of a Public Key Infrastructure End Entity Certification Authority (CA) Registration Authority (RA) Certificate Repository (CR) X.509 Certificates Certificate Revocation Lists (CRL) Functions of a Public Key Infrastructure Enrolment - Registration, Initialisation and Certification Key Recovery Key Update Certificate Revocation Cross Certification Case Study: Security in the UK e-science Grid How the UK e-science Grid CA Works Also in Grid Security Current Status of Public Key Infrastructures The Truth About Public Key Infrastructures The Main Issues With PKI Lack of Technical Interoperability Approaches to Cross Certification and Issues of Scale Certification Path Construction and Validation X.509 as an Identity Certificate Problems with Revocation Risk of Insecure End System Security...19 iii

5 5. Future Direction of Public Key Infrastructures Conclusions Project Findings Project Recommendations: PKI Role of XML- Based Solutions Introduction Components of XML-Based Solutions Conclusions Is XML Really the Future? Web-based Teaching Resource and PKI Demonstrator Introduction Methodology Adopted Phase 1 - Requirements Analysis Phase 2 - Design User-centred Design Methodology Interface Design Decisions Content Design Decisions Demonstrator Design Decisions Test Design Decisions Phase 3 Implementation Phase 4 Testing and Evaluation Testing - Cognitive Walkthroughs Evaluation - Questionnaires Project Management and Evaluation Initial Project Plan Need for Revisions Revised Project Plan Project Evaluation Evaluation of PKI Resource (Revisited) Evaluation of Research Conducted...36 Bibliography...38 Appendices...43 Appendix A Reflections...43 Appendix B Project Objectives and Deliverables Form...45 Appendix C Marking Scheme and Interim Report Header Sheet...47 Appendix D Questionnaire Used...49 Appendix E Interview with Lecturer...55 Appendix F PKI Related Standards...56 Appendix G Glossary of Terms...58 Appendix H List of Figures and Tables...61 iv

6 1.1 Understanding the problem Current Status of Public Key Infrastructure 1. Introduction The basic aim of this project was to review the very broad and somewhat controversial field of Public Key Infrastructures. The following problem statement initially scoped this project: Public Key Infrastructure (PKI) is a set of technologies, protocols and practices for ensuring secure e-business across the Internet. Widespread acceptance of it has been slow, for a number of reasons. The aim of this project is to assess the current attitudes in the market place for PKI, any barriers and possible enablers, to understand the principles behind PKI and to build a demonstrator (on the Web or on a stand-alone PC) that teaches these principles, for classroom use or for small businesses. To solve the problem stated above, the following project objectives were laid down: Gain a clear and in-depth understanding of the concept of PKI. A software demonstrator should be produced to prove understanding of the concepts involved. Conduct research into the current status of PKI in global e-business with particular reference to the problems preventing PKI from becoming a widespread solution. In addition, conduct a study into the role of XML in PKI. The focus of this project was relevant to the theme of the MSc course, particularly keeping the growing realisation of the importance of enterprise information security in mind. The author was able to draw extensively from his experiences in the Engineering E-Business module, and used it as the background for the research conducted. The various tools and techniques learnt as part of the Information Systems Engineering module were also valuable, especially in tackling the systems development and human computer interaction (HCI) issues related to the development of the teaching resource and associated demonstrators. 1.2 Approach to Solution The problem, as described above, suggested that there would be two separate components comprising the project. The first was a research component requiring an extensive literature review followed by a critical analysis of the areas covered. The second was the implementation of a demonstrator that would help teach the principles of PKI. With time, this evolved into a full-fledged teaching resource not only for PKI but also the topics around which PKI is built. To ensure the quality of the research conducted, the author took the conscious decision to use trusted literature sources rather than depend on the large volumes of information available on the publicly accessible Internet. As a result, apart from books covering the area, the primary source of information was articles available on trusted journals like IEEE, Information Security Technical Report and ACM. In order to provide a balanced view of the various issues covered, industry white papers and technical resources from reputed companies like Entrust, Verisign, IBM, Lucent and BT were also consulted. An effort was also made to be critical of the areas covered and to incorporate the author s views wherever possible. The technical skills required to build the demonstrator were fairly simple. However, substantial effort was required to ensure that the system built would actually meet its intended objective, and to achieve this the author decided to emphasise on usability and effectiveness of content. This took the form of a User Centred Design (UCD) methodology for the design of the resource. Care was also taken to justify the various design decisions that were made along the way. 1

7 Finally, to ensure that the system was evaluated appropriately, research was also conducted into the construction and interpretation of questionnaires. This was then used as the basis for the final evaluation of the product. 1.3 Structure of the Report Understanding the Problem Chapters 1, 2 and 3 Chapter 1 provides an introduction to the project. It outlines the problem, the approach adopted to produce the solution and the structure of the project report. Chapter 2 provides an introduction to the growing need for information security and an overview of the concepts that have led to the evolution of PKI, i.e. cryptography, digital certificates and signatures. Chapter 3 describes the generic architecture of the PKIX model and the functions provided. It also describes a real-world deployment of PKI within the context of the UK e-science Grid Producing a Solution Chapters 4, 5, 6 and 7 Chapter 4 provides an in-depth analysis of the problems that plague PKI and have hindered its widespread adoption. The analysis comprises a statement of the problems, a description of the directions the security community is moving in, and the author s comments and opinions on the effectiveness of these solutions. Chapter 5 draws on the findings of Chapter 4 to suggest a set of recommendations for the areas that the research community and the security industry should focus on in the next few years in the opinion of the author. This chapter also describes the increased use of XML-based solutions in the backdrop of the emergence of the concept of web services and the grid. The effect of these solutions on PKI and their long-term value are also discussed. Chapter 6 describes the development of the teaching resource and demonstrators. It takes the reader through the phases of analysis, design, implementation and testing and provides a justification for the decisions made. It also describes the use of questionnaires as a mean of evaluating the project. Chapter 7 describes the steps taken to ensure that the project was conducted in a timely and effective manner. In particular, it includes the initial and revised project plans and a brief explanation of the reasons that led to the changes made Evaluation Chapter 7 Chapter 7 also provides a detailed description of the manner in which the project has been evaluated. The evaluation is divided into two sections one summarising the questionnaire-based evaluation of the resource and the second providing a subjective evaluation of the research conducted. 2

8 2. Introduction to Information Security 2.1 Information Security The ongoing evolution of the Internet in general, and the increased importance of areas like e- Business and e-science has seen the birth of new business models and the alteration of existing ones (Rappa, 2003). While the Internet has opened up a whole new world of opportunities for organisations to restructure themselves with respect to partners, customers and suppliers, factors such as trust, privacy and security have taken on even greater dimensions than in traditional environments. Moreover, a multitude of sectors including finance, healthcare and education have seen government regulation make strict conformance to privacy of data a prerequisite (Lareau, 2002). Apart from the huge financial losses that may be incurred by the business as a result of security breaches, the loss of trust and confidence of business partners and customers can be catastrophic. According to Mansfield (1999), the cornerstone of building confidence in the emerging global information infrastructure is trust. Computers now play a major role in information-processing, most of which is directly related to the work of individuals and the organizations they belong to. This includes , databases containing customer information, process-control information and organisational strategy. As in traditional business environments, not only is it important to ensure that people from outside the organisation are unable to access this information; it is equally important to monitor and restrict internal access (Johner et al). All these reasons have led to an increased understanding of the vital importance of investing in security, and this is reflected in Figure 2.1. Figure 2.1 Trends in Security Budgets ( ) (Enough Is Never Enough, 1999) The security services required by organisations operating in electronic environments can be classified into the following (Lareau, 2002): Authentication: The process of checking that the entity (person, computer system, etc.) that is at the other end and trying to communicate is actually who they claim to be. Authorization: Once the identity of the entity has been ascertained, it is necessary to check whether that entity has the permission to access the requested information or has access to the particular service of the system that has been requested. Basically, every entity registered with the system has a list of associated access rights that are used to decide whether the entity can access the information requested. This is also called Access Control. Confidentiality: Organizations possess large volumes of information that should be confidential, i.e. should be disclosed only to authorised parties. This is called confidentiality. 3

9 Integrity: While confidentiality makes information undecipherable, it is still possible for attackers to intercept and corrupt the data. Integrity refers to the service that ensures that any corruption of data while it is on the network can be easily detected. Non-Repudiation: All business situations involve some degree of legal obligation. Hence, it is vital that there be a mechanism to ensure that neither party can subsequently falsely deny having sent or received a particular message. The technologies and processes that attempt to provide these services together form what is commonly referred to as Information Security. 2.2 Cryptography and Encryption In Section 2.1, confidentiality was described as one of the primary security requirements within electronic environments. To provide confidentiality, it is necessary to make information undecipherable while it is in transit over the network. Consequently, even if it is read off the network, it is difficult for the attacker to make sense of the message. This process of making the information undecipherable before sending it is called encryption whereas the converse process by which the recipient deciphers it is called decryption. Both encryption and decryption involve the use of an algorithm to specify how the scrambling and unscrambling of information are to be carried out, as well as a key to provide the exact settings to be applied to the algorithm. The science of encryption and decryption is called cryptography (Johner et al, 2000). Over the years, cryptography has evolved greatly, and many different algorithms have been developed to achieve confidentiality Private Key Cryptography Private key cryptography involves the use of a shared secret-key by the communicating parties. The sender uses a key K to encrypt a message that is then sent over the network to the receiver. The receiver knows what the key K is, and uses it to decrypt the message. Hence, even if attackers intercept the encrypted message, it is not possible for them to make sense of it unless they also know what the secret key is (Johner et al, 200). The simplest private key algorithms work on the principles of substitution or transposition (Benantar, 2001). Modern secret-key cryptographic algorithms are more complex but work around these principles as well. The enormous increase in the processing power of modern day computers has resulted in the fact that transformations can now be applied at the bit level (binary representation of the character) rather than the character level. Hence, it is even possible for the algorithm that is being used be made public without compromising on security as long as the key is kept secure (Benantar, 2001). Today, the most common incarnation of secret key cryptography is the Data Encryption Standard (DES) (Anderson, 2001). Although private key algorithms like DES are very effective, they suffer from the restriction that the shared key MUST be kept secret, and hence a covert channel is required to transfer the secret key between sender and receiver. If the key were compromised, it would be possible for attackers to unscramble the message while it is on the network. This led to the development of Public Key Cryptography, as described next Public Key Cryptography Public (or Asymmetric) Key Cryptography was designed as a way to eliminate the need for a covert channel to secretly transfer the key between the sender and receiver (Johner et al). Public key systems use a pair of keys, one for encryption and the other for decryption, instead of a single shared key, as is the case in private key systems. Every person or entity possesses a pair of keys - a public key that it makes publicly available to all parties that would like to send it messages, and a private key that it uses to decrypt the message. 4

10 The major advantage of this scheme is the fact that the public key can be made publicly available without compromising on security, as long as the sender keeps the corresponding private key secure. This is possible because the public and private keys are uniquely related to one another mathematically, i.e. knowledge about either does not indicate the value of the other. However, a message encrypted with a particular public key can only be decrypted with the corresponding private key (Johner et al). The two most commonly used mathematical techniques used in public key cryptography are factorisation and discrete logarithms (Anderson, 2001). Diffie and Hellman, in their seminal paper in 1976 (Diffie and Hellman, 1976), described a public key algorithm based on the use of discrete logarithms. However, in recent times, the most commonly used public key algorithm is RSA. RSA is based on number factoring and is supported by most web browsers and is a major component of the SSL protocol (Binder, 2002). Although public key algorithms solve the problem of secure key transfers, this scheme involves several disadvantages. First, public key algorithms take substantially longer time to carry out the encryption and decryption processes (Khan, 1998). This is resolved by using a combination of public and private key cryptography - public key cryptography is used to secretly transfer a shared secret key between parties, i.e. the public key system in effect provides the covert channel. Secondly, a public key in itself does not guarantee security. There is no way to be guarantee that the public key actually belongs to the person or entity claiming to own it. This problem is solved by the use of certificates, as described later. 2.3 Digital Signatures The role of cryptography is not restricted to confidentiality together with the concept of hashing, it forms the basis of the integrity and non-repudiation services in the form of digital signatures. Hashing refers to the creation of a digital fingerprint of a message this is called the hash or message digest and can subsequently be used by the receiver to check the integrity of the message. The sender applies a hashing algorithm to the message to generate the hash value for the message. He then encrypts the hash value with his private key and sends the encrypted hash and the message together. The receiver accesses the sender's public key and uses it to decrypt the received hash value. He then uses the hashing algorithm on the message to obtain the hash value for the message received. If the hash value for the received message matches with the hash value sent to the receiver, the receiver can be sure that the message has not been altered in any way over the network. Moreover, non-repudiation is achieved because only the person or entity that sent the message owns the private key required to generate the digital signature (Binder, 2002). Hashing algorithms have several unique properties (RSA). These include the fact that they should produce fixed-size hash values and should be deterministic, random and irreversible by nature. Common digital signature creation and verification algorithms include the Digital Signature Algorithm (DSA), RSA and Elliptic Curve Digital Signature Algorithm (ECDSA). Common hashing algorithms include MD5 and the Secure Hash Algorithm (SHA1) (Savage, 2003). Digital signatures have become increasingly important, especially with the support of recent legislation that provide credibility to the concept of electronic signatures. The U.S. E-Sign Law (2000) and the EU Digital Signature Law (2001) are prominent examples of this trend. 5

11 2.4 Digital Certificates We saw that the use of public keys, in itself, does not provide a complete solution since communicating parties cannot be sure that a public key actually belongs to the entity claiming to own it. The mechanism that is used to solve this problem is digital certificates (Kohnfelder, 1978). The concept of digital certificates is somewhat similar to that of a passport - it is issued by a trusted authority (referred to as Certification Authority or CA) and binds the individual or entity (referred to as end entity) to its public key. After verifying that an end entity does actually own a particular public key, the CA issues a certificate that states the same. To ensure that the contents of the certificate are not altered after it has been issued, the CA also digitally signs the certificate. Now, if the sender wants to send a message to a receiver, he attaches the certificate to the message instead of just attaching the public key. The receiver can view the certificate, and as long as he trusts the same CA that issued the certificate, can be assured of the authenticity of the public key. The exact implementation of the certificates, their format and the way they are retrieved varies. The most common certificate format is that of the ITU (ITEF) standard X.509 (version 3) certificate as shown below. Figure 2.2 Format of X.509 version 3 digital certificate (Kiran et al, 2002) Pretty Good Privacy (PGP) is an alternative scheme which uses a different trust model based on trust between entities rather than in a central trusted authority (Klemetti and Valkeinen, 1999). 2.5 Where Public Key Infrastructures Fit In While some sources describe Public Key Infrastructure as a system for supporting digital signatures and document encryption for an organization (Binder, 2002), it is important to reemphasise the importance and significance of the word infrastructure. It is true that digital certificates, signatures and public-key cryptography are the primary enablers of PKI however, as suggested by the word infrastructure, a PKI provides a complete security framework that all business applications within an organization should be able to tap into and make use of. This is in contrast to situations in the past where organizations had a multitude of applications, each of which had security built into them. PKI also differs with individual protocols like SSL and Kerberos that have been used successfully, but for restricted areas. Public key infrastructures make use of digital certificates as their primary building blocks and are designed to provide trust in electronic business environments, i.e. they provide a way for parties that would like to establish a communication to do so with the confidence that the public key they are using really belongs to the entity that claims to own it. While certificates provide the binding between the identity of an entity and it s public key, the PKI is responsible for creation and management of those certificates within the user community (Johner et al, 2000). 6

12 3. Public Key Infrastructures 3.1 Generic Architecture of a Public Key Infrastructure The Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (PKIX) working group has been the main driver for the development of the formal X.509-based PKI model that is used most widely today. The PKIX architectural model (Kiran et al, 2002) divides a PKI into a number of components. These are shown in Figure 3.1 and have been described below. Figure 3.1 PKIX Architectural model components of a PKI (Kiran et al, 2002) End Entity End entity is the generic term used to describe the end users who make use of the services supported by a PKI. These may include individuals, devices such as routers and servers, processes or other entities that can be identified by the name on a certificate. The end entity is the starting point for the issue of a certificate by the CA and requests for a certificate that binds its identity to its public key Certification Authority (CA) The Certification Authority forms the centre of the trust model supported by a PKI. The CA is essentially responsible for issuing digital certificates to end-users - these certificates are digitally signed by the issuing CA, thus effectively binding the identity of the entity to its public key. Certification authorities are also involved in various administrative tasks that may sometimes be delegated to Registration Authorities (RA). Responsibilities of the CA include checking that requests for certification conform to the policy under which they will be issued, and that a suitably authorised RA has submitted them (Bosworth, 2001). If these criteria are satisfied, the certificate is generated by the CA and subsequently registered in the central directory. Certificate revocation, the process by which certificates that have become invalid before their expiry date are retired, is handled by the CA in similar fashion. Finally, the CA is also responsible for cross-certification, the process by which a CA establishes and manages a trusted relationship with a CA in a separate PKI domain Registration Authority (RA) As mentioned above, some of the administrative tasks of the CA may optionally be delegated to one or more registration authorities. This is often the case in large, geographically dispersed environments that require personal interaction of end-entities in the enrolment and verification process. Distributed RAs can minimise personal travel and inconvenience to end-entities. 7

13 The main responsibility of a RA is to authenticate end entities by examining and verifying their credentials this usually includes some form of proof that the end entity actually possesses the private key corresponding to the public key that it is trying to obtain a certificate for. The details of the process by which end entities are authenticated are dictated by the security policies that are in place Certificate Repository (CR) The Certificate repository provides the PKI with a directory service for storage and retrieval of PKI-related information such as certificates and Certification Revocation Lists (CRLs). The repository can be an X.500-based directory that clients access using the Lightweight Directory Access Protocol (LDAP), or it may be a simpler storage facility such as a flat file accessed via the File Transfer Protocol (FTP) or Hyper Text Transfer Protocol (HTTP). The repository thus provides end entities with a convenient mechanism to retrieve the necessary certificates and CRLs X.509 Certificates As mentioned earlier, certificates are the backbone of Public key infrastructures, and the X.509 certificate is the format most commonly used. In fact, the X.509 certificate is a core component of the majority of security-related protocols and applications in use today, including SSL (Secure Socket Layer), IPSec (Internet Protocol with Security), S/MIME (Secure/Multipurpose Internet Mail Extensions) and SET (Secure Electronic Transaction). While there are some PKI deployments that are based on X.509 version 1 or 2 certificates, the majority of them are based on the version 3 certificates Certificate Revocation Lists (CRL) The certificates issued by the CA normally have an associated validity period, as indicated by one of the fields within the certificate. However, it is possible for a variety of reasons (e.g., if the private key is compromised) that a certificate might have to be invalidated before it reaches its expiry date. To inform users about certificates that have been revoked, the CA issues a Certificate Revocation List and stores it in the repository along with the valid certificates. A key requirement of a PKI is that it issues CRLs at regular intervals to ensure that parties do not use certificates that are no longer valid. 3.2 Functions of a Public Key Infrastructure In this section, we shall describe the various functions (Kiran et al, 2002) of the PKI components and how they interact with one another Enrolment - Registration, Initialisation and Certification End entities must enrol with a PKI before they can make use of its services. Enrolment involves the following sub-phases: Registration: This step initiates the process of enrolment and occurs when the end entity introduces itself to the CA or RA. After an initial verification of identity, the end entity is issued with a shared secret key and other identifying information that is used subsequently. The strictness of this initial verification is dictated by the intended application and the policies in place. For example, authentication for an certificate may require no more than verifying if a user can receive at the given address, whereas a certificate for a merchant Web server may require official documentation (Johner et al, 2002). Initialisation: This follows the initial registration process and involves at a minimum, the initialisation of the associated trust anchor (CA) with the end entity. This step also usually includes the allocation of the public/private key pair to the end entity. Depending on the policy, 8

14 these keys may be generated by the end entity client system, the CA, a RA or a separate component. Certification: This step marks the termination of the enrolment process and involves the issuance of the digital certificate by the CA to the end entity. The certificate is simultaneously published in the repository so that relying parties can access them independently Key Recovery It is assumed that an end entity always has access to its private key. However, sometimes exceptional conditions may arise, e.g. damaged hardware, forgotten passwords, etc. due to which the private key is no longer accessible by the end entity. Key recovery allows end entities to retrieve the necessary private key from the CA or an alternative authorised backup and recovery service provider. There is some debate about the provision of this function since it implies that there is now a possibility for someone other than the concerned entity to misuse the private key; i.e. nonrepudiation can no longer be guaranteed Key Update Certificates issued by the CA are always valid only for a fixed period of time, i.e. they have an associated expiry date after which they are no longer valid. Key update becomes necessary in such cases and involves the generation of a new key pair and the issuance of a new public key certificate (Understanding Public Key Infrastructure, 1999). This is also sometimes required as a result of certificate revocation. Update of the key pair can be carried out even before a certificate has expired to ensure that a valid key is always available to the end entity. Key update is not much of an issue and may be fully automated, as the user is already trusted (by a certificate), so he can send a signed message asking for a new certificate (Binder, 2002) Certificate Revocation As mentioned earlier, although certificates are issued with fixed lifetimes determined by their expiry dates, it is sometimes necessary to declare a certificate to be invalid before it reaches this date this is called certificate revocation. Both the end entity as well as the CA can initiate the revocation process because both may have reasons to do so these might include compromise of keys or reallocation of the concerned personnel. The CA must make the most recent revocation information available at all times. To inform users about revocation, the CA issues Certificate Revocation Lists (CRL) and stores them in the CR along with the valid certificates. A revoked certificate is identified in a CRL by its certificate serial number; the certificate itself usually contains a pointer to where the corresponding CRL can be found as well (Benantar, 2001) Cross Certification Often, the end entity and the relying party belong to separate PKI domains, i.e. they trust their own CA but not the CA trusted by the other. In such cases, it is necessary for the CAs to provide a mechanism wherein they can create a certificate between themselves, if they trust one another. This is called cross-certification. The basic issue is to join independently deployed public key infrastructures with minimal disruption and the greatest transparency possible, allowing each certification authority to remain the sole authority for its own domain of operations (Benantar, 2001). A cross certificate is a public key certificate issued by one CA to another, i.e. it is a certificate that contains the public key of the CA that has been digitally signed by another CA. Cross-certification may take place bi-directionally between peer CAs or unidirectionally if a hierarchical trust model is being employed. There are a number of different approaches to cross-certifications that are in use today, as described in the next chapter. 9

15 3.3 Case Study: Security in the UK e-science Grid How the UK e-science Grid CA Works Previous sections described the primary enablers of PKI as well as the basic architecture and functions performed by a PKI. This section attempts to view the theoretical concepts discussed from the perspective of a real-life implementation - the case study selected is the UK e-science Grid. E- Science refers to the growing importance of large-scale science based on internet-enabled collaboration of large data collections and high-performance computing and visualisation resources. These requirements have been met by an evolved version of the traditional web architecture known as the Grid. Security for the UK e-science grid is provided by an underlying X.509-based PKI with certificates issued by the UK e-science Grid CA (UKESCA). The Grid Support Centre runs this CA and uses a hierarchical structure consisting of multiple RAs responsible for authenticating users this distributed model allows verification of identity on the basis of physical photographic identification, as shown below. The Information Systems Services (ISS) at the University of Leeds is the local RA for members of staff at the University. Figure 3.2 Basic Architecture of the UK E-Science PKI (Boyd and Jensen, 2002) We shall now take a closer look at how the functions mentioned earlier are actually executed within this particular implementation: Certificate Request: The individual requiring a certificate has to make an initial request through a browser-based interface. At the time of making this request, he enters his name (Distinguished Name) and a PIN number that is used later by the RA to verify that the same person made the request. He also needs to submit his address so that the certificate code can be returned once the CA has cleared the request. Under the DP Act, the CA is required to keep the address confidential. The Distinguished name entered by the user must be unique - if not, the user needs to re-submit the request with a unique variation of this name. Certificates are issued to unique individuals or resources and should not under any circumstance be shared. Server certificates must be linked to a single network entity. The certificates issued are for the X.509 namespace defined by C=UK/O=eScience/OU=<Institution>/L=<Locality>/CN=<name>. Key Pair Generation: The UK e-science scheme is built around the use of a private/public key pair generated by the user s browser. Interestingly, the private key is password protected (a minimum of 15 characters) and there is no facility for key recovery if the password is lost. The corresponding public key is transferred to the CA from the web interface via HTTP. 10

16 Verification of Identity: Once the RA receives the request for the certificate, it gets back to the individual and verifies that the same person made the request by cross-checking the value of the PIN entered by the user at the time of making the request. The RA then verifies the identity of the person using standard identity sources like passports or university identity cards. Once it has verified the authenticity of the request, it passes on the signed request to the CA for issue of the certificate. Certificate Issue: Once the RA has approved a certificate request, the certificate is normally issued by the CA within one working day and is usually sent to the user via . However, there is also a facility for users to download the certificate from the CA s website. When the certificate is issued, the CA adds the new certificate to the list of certificates that have already been issued. Key Update and Recovery: Since the user is responsible for key generation, the UK e-science CA does not have any facility for key backup in case the user loses the private key. Also, there is no provision for key update after revocation or expiry the user simply has to get a new certificate. The maximal lifetime of a certificate and the default validity period are each one year. Certificate Revocation: The CA revokes a certificate only if it receives a signed request from the user that owns the certificate, the RA that authenticated that user or someone who offers concrete proof that the corresponding private key has been compromised. The CA publishes the CRL every time that it is updated or at least once a week. However, there may be a delay of up to one day between the time the CA receives the revocation request and the time that revocation is actually carried out Also in Grid Security The description of the security model used by the UK e-science grid (NESC), as shown above, is meant to illustrate the implementation of PKI in a real-world situation. However, with the increased importance of grid computing in recent years, it is also useful to briefly mention how grid security, in general, builds on the facilities provided by a conventional PKI. The Globus project (Globus Project) is responsible for developing the backbone of technologies needed to build computational grids. The Globus Toolkit offers facilities for the development of secure services by means of its Grid Security Infrastructure (GSI). The GSI is built around the concept of an X.509-based PKI as outlined above. However, it builds on this by creating a timestamped proxy based on the user s private key - this proxy is used for access to resources that they have permission for. Since these proxies are used across all the resources on the grid, it allows for Single Sign On (SSO). This delegation ability of GSI reduces the number of times users need to enter their pass phrase for computations that require resources distributed over multiple sites. The proxy consists of a new certificate corresponding to a freshly generated key pair, and this is signed by the user s certificate rather than by the CA. The basic idea behind the use of these proxy certificates is shown in the diagram below. Figure 3.3 The Delegation model provided by GSI (Globus Project) 11

17 The delegation model offers considerable flexibility however, this comes at the cost of the fact that the user is not in complete control of the proxy. It is not possible for the user to revoke the proxy certificate, nor does he have access to the private key for the proxy. To minimise abuse of these flaws in the model, the proxy certificates are usually short-lived. Another interesting extension of PKI that has developed within the Grid community is the use of a Community Authorization Service (CAS) to handle the authorization aspects of security. The virtual organization is a core concept within the context of the grid and e-science, and CAS allows these communities to specify course-grained access control policies for the resources that belong to this community. The CAS approach reduces the load of managing users that is otherwise exerted on the individual resource managers - resource mangers now only need to maintain access control for the community as a whole. The CAS server is responsible for maintaining access control for individual resources. 12

18 4. Current Status of Public Key Infrastructures 4.1 The Truth About Public Key Infrastructures PKI has certainly had its share of successes, especially in closed environments, and the case study is intended to show that. However, there are several problems with PKI, especially related to interoperability and scalability, and the description and analysis of these issues comprise the majority of this research. In the sections that follow, we shall examine these problems, as well as the directions that the security community is moving in to work around these problems. As mentioned earlier, the rise of the unsecured Internet as a platform for enterprise networking and electronic commerce underscores the need for the privacy, integrity, and non-repudiation attributes PKI brings (Ortiz, 2000). While PKI does provide a theoretically sound solution to a large fraction of the security problems faced by organisations, it is far from being a panacea or a silver bullet to the various problems of enterprise security. In fact, according to security experts Carl Ellison and Bruce Schneier (2000), E-commerce is already flourishing, and there is no such PKI. The majority of publicly available PKI-related literature is confusing, contradictory and sometimes clearly untrue, and security vendors are largely to blame for this. Despite all the claims regarding the ability of a PKI to solve the security problems faced by an enterprise, there is a strong opinion that PKI has been over-sold as a solution PKI technology is not a solution, or even a product. It is a toolkit that can be used as the basis for a solution (Sundt, 2002). Figure 4.1 PKI The Hype (Ortiz, 2000) Figure 4.2. PKI The Reality (Wheatman, 2002) The hype surrounding PKI and PKI-related technologies peaked in 1999 in fact, many cited 1999 as the year of PKI, and Figure 4.1 is a reflection of this hype. However, the problem with PKI goes beyond the fact that like many other technologies, it has been over-hyped and often sold on the basis of things that it clearly does not deliver. According to Wheatman (Ortiz, 2000), PKI must overcome significant hurdles before it becomes widely used, including complexity and high cost. There have been several problems that have clearly seen PKI failing to meet the successful numbers predicted for it in 1999, and these are reflected in Figure 4.2. PKI-related numbers have certainly increased but not in the dramatic ways predicted in In fact, a closer look at the graph in Figure 4.2 suggests that PKI has followed the path predicted by the technology life cycle. We now take a look at the main reasons that have led to the fact that PKI has only been able to meet with limited success in the recent past. 13

19 4.2 The Main Issues With PKI Current Status of Public Key Infrastructure Lack of Technical Interoperability The distributed nature of the Internet makes it essential that any technology that uses the Internet as a backbone is interoperable, and PKI is no exception. However, the lack of interoperability across systems is one of the most significant hurdles to PKI s widespread adoption (Ortiz, 2000). The X.500 origins of PKI have often been linked to the reasons for its poor interoperability - both in terms of interoperability of components within the same PKI as well as interoperability between separate PKIs. However, lack of interoperability is attributable to other reasons as well. These include the trends toward proprietary PKI solutions and the ambiguity of the various protocols, standards and formats that have been used over the years. An example is the X.509 version 3 certificate that allows user-defined extensions (Gutmann, 2002). Although this is beneficial in that it allows users to extend and adapt the original format towards their needs, it has led to the problem that different PKIs using different certificate formats find it difficult to communicate. The most common technical problems, as found by the Communications-Electronics Security Group (CESG) of the UK Government, can be broadly classified as follows (Lloyd et al, 2001): Encoding/Decoding issues: There are major incompatibilities between date formats, extensionencoding schemes, non-standard object identifiers (OID) used to denote algorithms and encoding of requests and empty fields. Boundary and Range issues: Different implementations of PKI make different assumptions regarding the maximum values of certain fields (e.g. certificate numbers) and place variable limits on the maximum allowable path length. Naming conventions: Different implementations often use non-standard values to identify the Distinguished Names within certificates, as well as making different assumptions regarding the ordering of attributes. Certificates and Certificate Revocation Lists: There is a lack of uniformity in the way most of the fields (both standard and extension fields) within the certificate are used. These interoperability problems are being addressed aggressively by the IETF and other bodies in the form of profiles that enable the notification, identification and understanding of certificate extensions (Sundt, 2002). Another major area of work aimed towards addressing interoperability issues is the improved use of Certificate Policies (CP) and Certificate Practices Statements (CPS) (Younglove, 2000). Policy mappings are used to ensure that organizations with different CA policies can interoperate. The same policies may be identified differently in different organisations and policy-mapping information may be included within cross- certificates to address this Approaches to Cross Certification and Issues of Scale We described the need for, and process of, Cross Certification in Section 3.2. Although cross certification in itself, is not a complicated concept, ensuring compatibility and interoperability between CAs is not a trivial matter. In fact, according to Lloyd et al (2001), it is recognized that CA-CA Interoperability is an area that is subject to some debate, and there are a number of different views that have yet to coalesce into a universally agreed position. Some critics have gone to the extent of saying that Certification paths and cross-certification will never work as envisaged (Landrock, 1999). Although PKI was initially envisioned as a global scheme, recent times have seen a definite shift to a more realistic closed model wherein the CA serves a subset of the global community, possibly under the supervision or control of one or more CAs (Sundt, 2002). Although this distributed model solves the initial problems of a centralised approach, it introduces severe problems with trust management, i.e. how different CAs relate and extend trust to each other. Traditionally, there are 14

20 two different approaches to cross certification that essentially reflect separate underlying business trust models (Turnbull, 2000). Hierarchical Approach: This approach is structured around a central CA that is the primary source of trust within the organisation. This central CA can delegate trust to secondary CAs. The fact that this model is dependent on the central CA implies that the security procedures of the CA need to be scrutinised in detail to ensure that it deserves the trust being placed in it. Major criticisms of the hierarchical approach include the fact that compromise of the private key of the root CA can be catastrophic and that the model does not scale effectively. Mesh Approach: This approach, also referred to as a peer-to-peer CA model, assumes that each pair of CAs establishes a cross-certification between themselves. However, this approach is also not scalable, i.e. if each CA has to maintain a cross certificate relationship with multiple CAs, the number of cross certificates required expands geometrically. The computation required by end-entities to construct and validate certificate paths also increases correspondingly. Both these approaches have a distinct set of disadvantages inherent in them. In recent times, there has been a shift towards a hybrid approach that aims to make use of the best features of the hierarchical and mesh approaches. This is called the Bridge Approach. Bridge Approach: This is based on the idea of a trusted third party that acts as a hub linking the CAs together, thus avoiding the need for CAs to enter into bilateral contracts with each CA that it wants to interoperate with. This approach greatly reduces the overheads associated with management of cross-certificate pairs as advocated by the peer-to-peer approach (Palmer, 2002). There are several differences between this model and the hierarchical approach. First, unlike the hierarchical model where the root CA s public key acts as the trust anchor, the bridge CA s key is not a trust anchor. Hence, changing the public key in the bridge model does not involve the degree of change required by the hierarchical model (where the entire hierarchy depends on the public key of the root). Another advantage of the bridge model is the fact that it allows multiple autonomous PKIs to interoperate without sacrificing their autonomy (Lloyd et al, 2001). A good example of the bridged approach in implementation is the Federal Bridge Certification Authority (FBCA) in the United States. The FBCA acts as a conduit of trust and supports interoperability among Federal Agency PKI domains in a peer to peer fashion (NIST). This solves some of the problems inherent in the previous approach and provides a more scalable solution to inter organisational PKIs. It also makes the problem of certificate revocation easier than in the earlier case since now only the certificate issued by the bridge CA needs to be revoked. However, the author believes that although the bridge CA concept solves the problem of cross certification within complex organisational structures, the fact that it requires placement of trust in a central, trusted bridge CA might not be acceptable in many business environments. The real issue with cross certification is not only how it should be implemented or which of the approaches to take, but also to map the trust model followed by the business to the chosen approach in an effective and correct manner. PKI needs to support many and complex trust models. Indeed, the trust models need to be understood before any PKI implementation is started. The technology should support such models, not dictate what they should be (Sundt, 2002). For example, an organisation that requires maximum control over all CAs would benefit from a centralised, hierarchical model. This is due to the fact that the root CA can be used to control the policies and number of subordinate CAs, thus maintaining overall control. On the other hand, if interoperability between separate organisations is of primary importance, the peer-to-peer method is advisable. However, if the number of CAs that the organization needs to interoperate with were large, the bridged approach would be the most appropriate. 15

21 4.2.3 Certification Path Construction and Validation In the previous section, we discussed different situations in which organizational trust is distributed in a complex manner processing this trust is equally complex. Before a certificate can be used, it must be validated. In order to validate such a certificate, a chain of certificates or a certification path between the certificate and an established point of trust must be established, and every certificate within that path must be checked. This process is referred to as certification path processing (Lloyd, 2002). Certificate path processing essentially involves two phases certificate path construction and validation. The CA whose primary key is used by the relying party as the starting point for certificate validation is termed the trust anchor. In the hierarchical model, the trust anchor is the root of the hierarchy, not the local CA. Moreover, cross certification is generally seen to be a one-way process wherein the root CA certifies the key of the subordinate or child CA - this is called unilateral cross certification. In the peer-to-peer model on the other hand, the trust anchor is the entity s local CA. Local CAs are autonomous and do not depend on a central root as in the case of the hierarchical model. These autonomous CAs are capable of cross certification with other autonomous CAs. This is usually a two-way process with each of the CAs certifying the other and is called mutual or bilateral cross certification (Lloyd, 2002). The main issue related to certificate path processing is how to integrate intelligence into what should otherwise be a completely automated process. Here, by intelligence we refer to the ability to decide how far the technology should go before deciding that the certificate from a particular CA cannot be trusted, i.e. that there is no path between one CA and another. Undesirable trust cascades should be prevented, e.g. if CA 1 trusts CA 2 and CA 2 trusts CA 3, then it is not necessary that CA 1 should implicitly trust CA 3. The decision whether or not to trust CA 3 should be based on the policies that have been put in place by CA 1 (Lloyd et al, 2001). In practise, this is solved by the use of path, name and policy constraints. These constraints provide organizations with a mechanism to design the trust relationships between the CAs so as to reflect the real life business relationships that the organisation supports, i.e. these provide the rules by which the degree of trust can automatically be determined (Turnbull, 2000), as described below. Path Length: In the hierarchical model, the path length constraint can be used to limit the depth of the tree, i.e. the number of child or subordinate CAs that can be added to the hierarchy. In the peer-to-peer model, the path length constraint can be used to define the maximum number of times trust can be transitively placed in CAs not directly trusted by the relying party. Name: Name constraint similarly allows trust to be limited on the basis of all or part of the distinguished name of the entity the certificate has been issued to, i.e. a CA is permitted to establish cross certification relationships only with CAs that conform to certain conditions with respect to their distinguished name. Policy: Policy constraints can be used to limit trust only to CAs that match predefined criteria with respect to the policy fields within their certificates, e.g. the assurance level specified in certificates (Turnbull, 2000). 16

22 4.2.4 X.509 as an Identity Certificate As mentioned before, the X.509 certificate and the underlying X.500 evolution form the very basis of PKIX and the majority of PKIs in place today. However, it is this very same dependence on X.500 that is the cause of a large number of weaknesses inherent in PKIX. As expressed in Gutmann (2002), The X.509 model s ties to X.500/LDAP directories, hierarchical structures, offline revocation, and other design decisions that stem from its X.500 origins further complicate the situation. Ideally, the model would instead use today s standard business tools and methods, such as relational databases, a nonhierarchical organization, and online validity and authorization checking. The primary weaknesses of PKIX that are a direct result of this include the following: 1. Naming Problems: A widely cited problem with the X.509 basis of traditional public key infrastructures arises from the fact that these are essentially identity certificates that bind the names of entities to their public keys. Although names offer the simplest way to identify entities, they are not unique identifiers and hence, are of little use in isolation (Garfinkel, 2002). They need to be used in conjunction with additional information pertaining to the entity. However, in a distributed environment, it is unlikely that the majority of users will be aware of this additional information pertaining to that entity. Identifying entities uniquely while addressing both these constraints in mind is a serious challenge. A number of solutions have been proposed to solve these problems (Ellison, 1999). The first of these is based on the idea that a private key can itself be used as a unique identifier. This is due to the fact that a private key is tightly bound to the entity that is in possession of the corresponding private key. If the private key is too long to act as a useful identifier, a shorter, hashed value of the key may be used. However, this solution suffers from the practical weakness that the resulting unique keys are not particularly meaningful and hence, unlikely to be used. The Simple Public Key Infrastructure (SPKI) initiative of the IETF solves the problem by using a certificate model that recognises the fact that globally unique names are required only in a few special cases (Gutmann, 2002). The Simple Distributed Security Infrastructure (SDSI) goes one step further and suggests allowing users to define their own namespaces and then issuing certificates within those namespaces. 2. Need for Access Control and Authorization Certificates: Yet another problem linked to the fact that X.509 acts as a certificate of identity is that very often what is required is not really an assurance of an entity s identity but a binding of a key to some form of authorization or access control (Mathews, 2000). This problem is solved by the use of authorization certificates that bind the public key to some form of authorization, as shown below. The binding between the key and the entity that it belongs to is optional and can be stored separately, if required for audit purposes. Since the public key is already assumed to uniquely identify the end user, this facilitates access control albeit indirectly (Ellison, 1999). Figure 4.3 Authorization Certificate (Ellison, 1999) Although there has been an increase in the use of authorization certificates, the author is of the opinion that there are serious issues of interoperability with older PKIX deployments that are yet to be addressed. There is also considerable doubt that X.509 will ever be replaced completely. 17

23 3. Lack of Anonymity: While the shift to the open, electronic business model provided by the Internet has enabled enterprises and individuals to overcome existing geographical barriers, it has also exposed them to a large number of security threats. Invasion of privacy is one of these threats and has led to the demand for at least a minimal, acceptable level of anonymity by users. It is well known that user activity on the Internet is continually being monitored, tracked and logged for a variety of reasons, the most common being the need to prevent and detect misuse. Striking the correct balance between the need for anonymity and the need for security, i.e. ensuring that the person one is dealing with really is who they claim to be, has thus become a major issue. The fact that the X.509 digital certificate is essentially an identity certificate implies that the concept of anonymity is widely missing from common public key infrastructures (Klemetti and Valkeinen, 1999). The CA (or RA) must go through a detailed verification process to ensure that the certificate they are issuing is for the correct entity and this process necessarily involves the entity having to part with it s identity. The solution to this problem of anonymity also takes the form of authorisation certificates, as described earlier. Thus, since the identity of the key-holder cannot be inferred from the authorization certificate, the entity is assured of a degree of anonymity not available through the use of identity certificates. However, in order to be able to respond to possible abuse of the key, the CA should ideally store information mapping the key to a particular entity. Although absolute anonymity is not possible, information related to the entity s identity is restricted to the CA Problems with Revocation In Chapter 3, we discussed the need for, and importance of, certificate revocation within a PKI. However, the exact way in which revocation is to be implemented is an area of great debate. While Certification Revocation Lists (CRL) are the most common solution today, many consider them to be too big and too outdated to be relevant (Ellison and Schneier, 2000). A CA might provide services to hundreds of thousands of users and so, the scalability and availability of CRLs becomes a major issue. A major limitation of the CRL method arises from the fact that they are not immediate, i.e. there is a delay between the actual revocation of a certificate and the issuance of the CRL reflecting that revocation. Hence, a time window exists during which users might accept invalid certificates and this is not tolerable in most business environments. It is also important to address the issue of how exactly the end-entity finds out where to find the appropriate CRL. Even if the end-entity does manage to find the correct CRL, it currently takes too long for the revocation checking process to be carried out. Some of the workarounds proposed to solve these, and other related problems, include staggering CRL expiry times for different certificate classes or issuing replicated and fragmented CRLs, thereby facilitating distributed access and increasing availability (Gutmann, 2002). PKIX attempts to solve the problem of helping the user locate the correct CRL by including the CRL distribution points extension within the X.509 certificate itself. This also addresses the issue of scalability of CRLs in environments where the CRL can grow to be quite large by allowing the CRL to be distributed over multiple locations (Benantar, 2001). There are other issues as well these include questions relating to the period of time that keys on the CRL should be retained and whether certificates that were signed with keys that have now been revoked should also now be considered invalid. One final problem is that of semantics, i.e. the fact that a particular certificate is not listed on a CRL does not necessarily imply that the certificate is 18

24 valid. A better solution would incorporate a way to offer a response regarding the validity of the certificate rather than a response that indicates whether a certificate had been revoked already. Recently, there has been a shift towards online methods for revocation checking, more specifically embodied by the Online Certificate Status Protocol (OCSP) (Gutmann, 2002). The OCSP approach (see Figure 4.4) removes the necessity for a CRL mechanism by providing the current certificate status for a particular certificate specified in the client query. The difference here is that the end entities no longer need to download voluminous CRLs at regular intervals; neither do they need to know where to find a particular CRL. Although this approach solves the problems associated with traditional CRLs, it does so by transferring the load from the client to the server, i.e. the servers now have to be able to handle a large number of client requests and dynamically create the status information related to each request. Like most other PKI-related security decisions, the choice between CRL-based revocation and online revocation should be specified in the organizational security policy. Figure 4.4 OCSP revocation mechanism (Gutmann, 2002) Risk of Insecure End System Security We have seen that a PKI basically attempts to address the issues associated with public key management. However, the levels of security available also depend on the security of the private key, and that, strictly speaking, is outside the confines of the PKI itself (Benantar, 2001). In fact, Users typically store private keys on their hard drive, usually in a browser or the system registry (Ortiz, 2000), and thus, they are usually extremely vulnerable to misuse. Protection of the private key is important because of the significance of digital non-repudiation. The Public-Key Cryptography Standards (PKCS) are a set of specifications produced by RSA Laboratories that have either been referenced or implemented in the majority of currently used security technologies including PKIX, SET, S/MIME, and SSL. The PKCS#11 and PKCS#15 standards address the issue of private key security. The basic idea is to use a separate security layer component to manipulate the private key, and this usually takes the form of either a hardware or software token. Current Internet browsers are good examples of applications that use software tokens while smart cards, physical access cards, USB tokens and Proximity based smart cards represent the use of hardware tokens (Bhimani, 2000). The guidelines for software tokens are laid down in PKCS #11 - however, the use of software tokens stored in browsers cause their own set of problems. For example, this hides the details regarding the quality of the process of creation of keys. Also, the flexibility of the browser model implies that the user is at liberty to totally ignore the security features. Even if the user chooses to use the security options, he is free to choose which root keys he wants to trust (Landrock, 1999), (Ellison and Schneier, 2000). It may be possible for attackers to add their public key to the trusted 19

25 list of root keys stored on the end entity s browser. The user may be unaware of this attack and may proceed with a transaction assuming it is with a trusted source. Of late, there has been considerable hype regarding the use of smart cards in computer security in general and PKI in particular. The PKI Forum claim that PKI enabled smart cards currently offer the best combination of flexibility, security, and cost among token technologies, and smart cards will continue to offer more functionality at decreasing costs (Longo and Stapleton, 2002). Regardless of this considerable hype and the increased use of smart card technology, there are significant hurdles in this area. According to Bhimani (2000), While it's feasible to issue smart cards and deploy card readers for a few hundred users, it's impractical to do so in large extranet or business-to-consumer environments. Like PKI, issues concerning interoperability and scalability also stand unresolved. However, it would be fair to say that smart cards do offer a theoretically sound solution to the problem of private key security, and if the issues mentioned above can be resolved effectively, we can expect to see smart cards used as a widespread solution. 20

26 5. Future Direction of Public Key Infrastructures This chapter is divided into two separate sub-sections. The first section continues from the previous chapter to suggest a set of recommendations for PKI for future investigations. The second section provides a brief introduction to the growing use of XML-based solutions within PKI. Recent years have seen the rise of the concept of web services, and the majority of XML-based security solutions are directly related to this. The author has attempted to describe these developments and clarify exactly what role XML has in the realm of Public Key Infrastructures. 5.1 Conclusions The previous chapter covered the major shortcomings in conventional PKIs. The security community has addressed the majority of these issues and are moving in directions that attempt to solve them. However, PKI is still in a state of evolution, and it is difficult to say whether PKI will become the preferred security solution for organizational security requirements. However, it is certain that there is a well-defined need for a security infrastructure at an enterprise level, and since PKI appears to be the only realistic option, it is likely that more organizations will adopt PKI Project Findings The main issues and problems facing PKI, as explained, in earlier sections are summarised in Table 5.1. The table shows what the main issues are as well as the solutions that have been proposed to resolve these issues, i.e. the direction that the security community is moving in to address them. Finally, the table also shows the issues that still stand unresolved and the problems that could be encountered in the current scenario. These are divided into implementation and research issues, and form the basis of the recommendations made by the author in the next sub-section Project Recommendations: PKI The following recommendations are derived from the findings described in the previous section and summarised in the table below. The author has attempted to express the recommendations in order of priority, and believes that these are the areas in which PKI- related research and development should focus in the next few years. 1. Test interoperability between PKIs that use authorization certificates and existing PKIs based on X.509 certificates. 2. Find alternatives to addresses that are as meaningful a representation of an entity s identity, but are more secure. 3. Conduct detailed research into the costs involved in deploying smart card related hardware, and a feasibility study to check whether these costs are within acceptable limits for target organizations. Moreover, an attempt should be made to gauge the likelihood that smart card readers will actually become a standard component of computers in the near future. 4. Develop a model that incorporates the advantages of the bridged approach without forcing the CAs to depend on a central, trusted Bridge CA, i.e. ways should be found to distribute the trust centre. 5. Find alternatives (software or hardware) to smart cards for private key security. Viability should be thought of in terms of both cost, as well as convenience. 6. Find ways to enhance the availability and performance of the OCSP servers. 21

27 I s s u e P r o p o s e d S o lu tio n U n r e s o lv e d T e s tin g a n d I m p le m e n ta tio n I s s u e s 1. L a c k o f Use of Policy mappings and Profiles T e c h n ic a l Improved use of CP and CPS In te r o p e r a b ility 2. C r o s s - C e r tific a tio n 3. C e r tific a tio n P a th P r o c e s s in g 4. X a s a n Id e n tity C e r tific a te 5. P r o b le m s w ith R e v o c a tio n 6. In s e c u r e E n d S y s te m S e c u r ity Choose between the hierarchical, peer-to-peer and bridge approaches depending on organizational structure and security requirements Use of name, path and policy constraints to restrict trust between different domains Use of a common unique identifier, e.g. address instead of the traditional approach of using X.500 based distinguished names. Shift towards authorization certificates e.g. the SPKI model that uses the public key itself as the identifier CRL fragmentation and replication Shift towards online methods for revocation - use of OCSP mechanism Use of hardware-based solutions such as smart cards for private key security Authorization certificates are a major deviation from the X.509 format that has been the basis of PKI until now, and the shift is a major one. Interoperability with legacy PKI deployments needs to be tested. The OCSP mechanism shifts the load of revocation from the client onto the server. To ensure availability, steps need to be taken to ensure that the server is able to handle the load. Smart card readers and related hardware are not yet a standard part of most computer configurations. U n r e s o lv e d R e s e a r c h I s s u e s Although the bridge approach is increasingly seen as the optimal solution, it requires the placement of trust in a central Bridge CA. This is not desirable in many environments. Although addresses are increasingly being used as an online identity, they do not provide a foolproof solution. Alternative meaningful, online identities need to be considered. Mechanisms that deal with the security of private keys are still quite immature. Although smart cards seem to hold promise, alternate solutions are desirable. T a b le 5.1 T h e M a in Is s u e s in P K I, P r o p o s e d S o lu tio n s a n d U n r e s o lv e d A r e a s 22

28 5.2 R o le o f X M L - B a s e d S o lu tio n s Current Status of Public Key Infrastructure In tr o d u c tio n In recent times, there has been a concerted effort to reconstruct existing security standards using XML as syntax. Although XML is a technology that was o r ig in a lly in te n d e d to s o lv e c e r ta in w e b b r o w s e r is s u e s (Selkirk, 2001a), it has now become a central component of most business technologies, and constructing XML based security standards facilitates better interoperability with application data. XML grew out of the desire to standardise HTML and to provide an opportunity for developers to use their own customised tags. However, u n e x p e c te d ly, it h a s b e c o m e th e fo r e m o s t b u s in e s s d a ta fo r m a t, a n d is b r a n c h in g o u t in to c o m p u te r p r o to c o ls a n d e v e n s e c u r ity mechanisms (Selkirk, 2001a). The Internet Engineering Task Force (IETF) and the Organization for the Advancement of Structured Information Standards (OASIS) have been the main bodies responsible for the development of XML in the field of security. As mentioned earlier, the advantage of using XML in the field of security arises from the ability to interoperate with other XML data vocabularies, and the fact that different XML-based protocols can communicate with ease. Apart from the portability of XML, another major driver for XML-based security solutions has been the shift away from traditional web architectures and towards a more service-oriented web services architecture. Although the concept of web services is still at an early stage, there is much hope within the industry that it is truly the future of the Internet. However, the provision of security within this open model is still very much an issue, and since the model is based on XML technology, there has been a lot of effort to develop security solutions based on the same. Finally, a major reason for the failure of PKI in living up to expectations arise from its complexity. Although the XML-based solutions discussed below were originally designed with the web services model in mind, they provide an effective way to simplify conventional PKI C o m p o n e n ts o f X M L -B a s e d S o lu tio n s The XML-based solutions that the security community has been working on centre around the following standards. 1. X M L D ig ita l S ig n a tu r e : This standard defines the XML schema for the creation and validation of digital signatures. The XML Digital Signature (XML Dsig) standard forms the backbone of most XML security standards, and it makes use of other common XML-related standards. For example, the concept of XML namespaces is useful because it allows future XML-based security standards to refer to, and make use of the features of XML DSig and other related standards. Standards like XPath, XPointer and XSLT are also vitally important since they are used by XML DSig to refer to, or transform the XML document to be signed. The basic idea behind this standard is that the text within the SignedInfo tag is what is signed. However, before being signed, its contents are canonicalised to ensure that XML documents that have the same information always have the same binary representation, and hence the same signature. This is useful in cases where XML data is stored, or retrieved from data sources that store data in other formats that might cause slight changes in the format. An important feature of XML DSig is the fact that signatures may be detached, i.e. signatures for documents that are external to the signature, or enveloped, i.e. signatures that are a part of the document they are signing. In fact, the biggest advantage of XML signatures is the flexibility and fine-grained semantics it provides, i.e. the signature can refer to multiple documents, or several 23

29 parts of the same document. This is significant because it allows for situations where different parties might contribute to an XML document, and hence might want to sign it separately. F ig u r e 5.1 S tr u c tu r e o f th e X M L D ig ita l S ig n a tu r e (Selkirk, 2001a) XML signatures are optimised for use with XML documents but can be used with non-xml documents also. The K e y In fo tag allows key-related information to be included. The standard offers extensive support for traditional X.509 certificates as well as the PGP and SPKI certificate variants. 2. X M L E n c r y p tio n : This provides a mechanism for encryption and decryption of XML documents. Like the XML Digital Signature standard, XML Encryption allows only portions of XML documents to be encrypted, instead of the entire document. Another significant advantage of XML Encryption is that it facilitates the creation of secure sessions between more than two parties (Siddiqui, 2002). However, th e u s e s o f X M L E n c r y p tio n a r e n o t s o im m e d ia te ly o b v io u s a s fo r X M L S ig n a tu r e (Selkirk, 2001a). Unresolved issues include how to prevent the encrypted data from being guessed correctly if the amount of data being encrypted is small, and how to handle the changes in data types of elements or attributes as a result of encryption. 3. X M L K e y M a n a g e m e n t S p e c ific a tio n : As mentioned earlier, a major driver for the development of a lightweight, XML-based solution to enterprise security was the complexity of PKI in its traditional form. The main focus of this effort takes is the X M L K e y M a n a g e m e n t S p e c ific a tio n or XKMS. XKMS was developed by industry leaders including VeriSign, Microsoft and WebMethods and, as shown below makes use of the XML DSig and XML Encryption standards. F ig u r e 5.2 X K M S a r c h ite c tu r e (XML Key Management, 2000) XKMS itself was developed keeping in mind its delivery in the form of a web service and to enable a p p lic a tio n s w ith a s m a ll tr u s te d c o m m u n ity... to h a v e a s e c u r e s y s te m w ith o u t r e q u ir in g th e c o m p le x ity o f a p u b lic k e y in fr a s tr u c tu r e (Selkirk, 2001b). XKMS is divided into two separate parts, both of which make use of the K e y In fo tag specified in the XML Digital Signature standard described earlier: 24

30 a. X M L K e y R e g is tr a tio n S e r v ic e S p e c ific a tio n (X K R S S ): This provides the facility to register a specified key. It also handles functions like revocation and recovery of keys. For registration of a key, the client application sends its public key to the XRSS service on a dedicated r e g is tr a tio n s e r v e r. The registration server returns a certificate, or a location from where the public key can be accessed. b. X M L K e y I n fo r m a tio n S e r v ic e S p e c ific a tio n (X K I S S ): This provides the facility to retrieve information related to a specified key. The idea behind XKISS is that if a client application receives an XML-signed document and needs to verify the authenticity of that signature, it can pass the K e y In fo value of the signature onto the server for processing. 4. W e b S e r v ic e s S e c u r ity (W S S e c u r ity ): WS Security, as the name suggests, is a security standard developed to exclusively address issues of web services security. The standard is backed by industry leaders including IBM, Microsoft and Verisign and provides security enhancements for SOAP messaging and methods for encoding X.509 certificates and Kerberos tickets. WS Security makes use of XML Dsig and XML Encryption and provides message-layer security to the SOAP messages that form the backbone of the web services model. The standard facilitates message integrity and confidentiality but is restricted to a single SOAP message. WS-Security is also expected to play a major role in providing security to the next generation of grid services and is being considered for incorporation within the O p e n G r id S e r v ic e s A r c h ite c tu r e (OGSA) C o n c lu s io n s Is XML Really the Future? We have discussed the shift towards an XML-based security framework. The important issue however, as far as this report is concerned, is how these XML-based solutions fit into the PKI environments that we have focussed on. Evidently, the emerging XML security standards are aimed at moving the load away from the client application and towards dedicated server side components. S ig n e d X M L c a n p r o v id e a lig h tw e ig h t s ig n a tu r e a n d v e r ific a tio n m e th o d o lo g y th a t e n c o m p a s s e s s ig n e d d o c u m e n ts, fo r m s, tr a n s a c tio n s, a n d m e s s a g e s o n th e w e b (Selkirk, 2001b). XKMS extends this concept and attempts to simplify key management by removing the necessity for complex PKI certificate processing at the client. This implies that only minimal changes need to be made to the client application as PKI evolves. This simplification of the client environment has the added advantage of being particularly useful in lightweight environments like those required by mobile devices (XML Key Management XML Trust Services). However, there are several unresolved issues related to the role of XML within public key infrastructures. Although XKMS simplifies client side code, the fact that it is designed as a web service requires client side support for protocols such as S im p le O b je c t A c c e s s P r o to c o l (SOAP) and W e b S e r v ic e s D e s c r ip tio n L a n g u a g e (WSDL), and this is not trivial for legacy applications. There is also the concern that the XKMS architectural model is similar to, but not quite the same as that of the conventional PKIX model. For instance, XKMS requires the deployment of specialised r e g is tr a tio n and a s s e r tio n s e r v e r s. Thus, interoperability between XKMS-based PKI applications and legacy deployments of PKI is still an unclear issue. As things stand now, it appears that XML Signature, XML Encryption, XKMS and WS Security have a valuable contribution to make to the field of Public Key Infrastructures. However, using XML mechanisms to replace the entire security infrastructure is not advisable. XML should be used w h e r e it h a s a n a d v a n ta g e o v e r e x is tin g p r o to c o ls (Selkirk, 2001b). According to many experts, u ltim a te ly, w h a t m a y p r e v a il a r e n o t P K IX o r X M L S ig n a tu r e s e x c lu s iv e o f o n e o th e r b u t r a th e r s o m e h y b r id o f th e s e tw o te c h n o lo g ie s (Fox and LaMacchia, 2001). 25

31 6. W e b -b a s e d T e a c h in g R e s o u r c e a n d P K I D e m o n s tr a to r 6.1 In tr o d u c tio n Methodology Adopted This chapter describes the development of a web-based teaching resource for PKI. The basic requirement of the resource is to aid students who wish to learn about information security in general, and PKI in particular. Since the target group of the teaching resource and associated demonstrators consists primarily of students, the author decided to focus on the u s a b ility and e ffe c tiv e n e s s of the teaching-aid. Consequently, the author felt that a lig h tw e ig h t a p p r o a c h comprising the traditional phases of analysis, design, implementation and testing would be suitable. The emphasis on usability was incorporated into this lightweight approach in the form of the U s e r - C e n tr e d D e s ig n (UCD) methodology, as part of the design phase. Details of this methodology are described in the section outlining the Design phase. Furthermore, in order to ensure that the final product met the requirements of the users, a conscious effort was made throughout the development process to involve students in the design process. Techniques implemented include w a lk th r o u g h s, q u e s tio n n a ir e s and p r o to ty p in g and the results obtained through these techniques were used ite r a tiv e ly to make improvements to the product. The key features of the approach adopted are: L ig h tw e ig h t a p p r o a c h comprising analysis, design, implementation and testing phases Key Requirements high u s a b ility and understandable c o n te n t Emphasis on d e s ig n and te s tin g phases Emphasis on design through U s e r C e n tr e d D e s ig n Emphasis on testing and evaluation through Q u e s tio n n a ir e s and W a lk th r o u g h s 6.2 Phase 1 - Requirements Analysis In te r v ie w in g techniques were used to find the exact requirements of the teaching-aid. An interview was held with the lecturer for the module for which the teaching resource was being designed. The detailed, paraphrased transcript of this interview is available in Appendix E. This interview formed the basis for the development of the system, and the requirements are summarised below. 1. U s e o f R e s o u r c e : a. L e c tu r e r The lecturer will use the demonstrations available within the resource to help him explain the concept of security and PKI to students. It is hoped the demonstrations will be animated and highly visual, and will help the students understand the concepts better. b. Students The students may refer to the resource in two situations. First, they may use it as a follow-up to the material presented within the lecture, i.e. to understand the concepts better or to revise them. Secondly, students who are not taking the module but would like to gain a better understanding of the area may use the resource for self-study. 2. Background of Target Students: Students most likely to use the resource will include final year and postgraduate students taking a security-related module. The background knowledge and understanding required by users of the system should correspond to such students. 3. Facilities to be provided: a. Demonstrator(s) The most important component of the resource is the PKI d e m o n s tr a to r. It is to be used by both the lecturer as well as students, as outlined above. To provide the optimal learning experience, it should be visual and animated in nature. b. Textual Explanation: Additionally, to enable students to use the resource exclusively for the purpose of self-study, te x tu a l e x p la n a tio n s of the concepts are desirable. 26

32 c. A d v a n c e d M a te r ia l: The resource aims to help students gain a basic level of understanding of security and PKI. However, the facility for students interested in pursuing particular areas in further detail should be provided. d. G lo s s a r y : The additional facility of a glossary would be optional but desirable. It is hoped that the glossary will provide a quick and easy reference for the terms used in the resource. e. T e s t: Since the main aim of the resource is to instruct students and increase their level of understanding, there should be a facility whereby students can check whether it has helped them to learn what they had hoped to. 6.3 P h a s e 2 - D e s ig n As mentioned in Section 6.1, u s a b ility and e ffe c tiv e n e s s o f c o n te n t were judged to be the most important factors in the successful development of the teaching resource. The design methodology adopted, the significant design decisions taken, and their corresponding justifications are described below U s e r -c e n tr e d D e s ig n M e th o d o lo g y The emphasis on usability for this project was formalised by the adoption of the User-centred Design Methodology (UCD). The UCD is a h ig h ly s tr u c tu r e d, c o m p r e h e n s iv e p r o d u c t d e v e lo p m e n t m e th o d o lo g y d r iv e n b y : (1 ) c le a r ly s p e c ifie d, ta s k -o r ie n te d b u s in e s s o b je c tiv e s, a n d (2 ) r e c o g n itio n o f u s e r n e e d s, lim ita tio n s a n d p r e fe r e n c e s. In fo r m a tio n c o lle c te d u s in g U C D a n a ly s is is s c ie n tific a lly a p p lie d in th e d e s ig n, te s tin g, a n d im p le m e n ta tio n o f p r o d u c ts a n d s e r v ic e s. W h e n r ig o r o u s ly a p p lie d, a U C D a p p r o a c h m e e ts b o th u s e r n e e d s a n d th e b u s in e s s o b je c tiv e s o f th e sponsoring organization. Thus, the UCD approach emphasises on the objectives of the systems and the needs and limitations of the user - this ties in well with the focus of the teaching resource. The main features of this methodology (UCD) are: 1. D e v e lo p m e n t o f d r iv in g fu n c tio n s : The UCD approach helped the author start from the basic requirements outlined above and translate them to an initial set of design decisions and functional specifications. The focus was on ensuring that all the facilities required to make it an enriching experience for the student were implemented. A decision was taken to include the following components as part of the teaching resource. Textual Explanation: A short textual explanation will be provided for each of the topics included. This aims to provide students not already familiar with that specific topic an introduction of the area before viewing the demonstration. Demonstration: The demonstration forms the core functionality of the system, i.e. it aims to help students understand the concept of PKI. This differs from the textual explanation of PKI that merely provides information about the topic. External Resources and Glossary: The need for access to additional, advanced material pertaining to the areas covered by the teaching resource was laid down as a requirement within the analysis phase. The actual decision to provide this information in the form of external links was taken here - the main reason for this was the desire to keep the core of this resource small and simple. The requirement of a glossary was also specified in the analysis phase as desirable and after consideration, the author felt that it would be a good idea to include one. Testing Mechanism: Again, as specified in the analysis phase, the decision was taken to include the facility to allow students to test their understanding of the core concepts. The decision was also made that the test would be a process-oriented one rather than an objective question-andanswer type, i.e. an effort would be made to design the test to measure understanding of the topic rather than memory. 27

33 2. I n te g r a tio n o f c u s to m e r fe e d b a c k in th e d e v e lo p m e n t p r o c e s s : The UCD s focus on customer feedback was incorporated into the design phase by consulting sample students regarding their expectations of web-based demonstrators, and their opinions of the layout chosen. As development progressed, sample students were continually consulted regarding the appropriateness of the design decisions and changes that were deemed appropriate by the author were made. This approach was continued beyond the design phase and until the final product was ready. 3. N o D e s ig n F r e e z e T im e : The UCD approach does not encourage the fr e e z in g of the functional requirements of the system until late into the development process. This was adopted for the development of this system as well the requirements were reviewed at regular intervals, as was the system s ability to meet them. Rather than using a formal fu n c tio n a l s p e c ific a tio n as the basis for development, an ongoing process of defining, meeting and reviewing requirements was adopted. 4. U s e o f I te r a tiv e D e v e lo p m e n t: UCD, with its comprehensive treatment of user requirements and satisfaction, is essentially an iterative approach and this was adopted extensively for the purpose of this project the functionality provided by the system was reviewed at the end of each iteration and improvements were made wherever possible In te r fa c e D e s ig n D e c is io n s # 1. F o n t a n d R e a d a b ility : The following guidelines were used in selecting the fonts for the teaching resource (Research-Based Web Design Guidelines). U s e a t le a s t a 1 0 -p o in t fo n t to a c h ie v e th e b e s t p o s s ib le r e a d in g p e r fo r m a n c e U s e e ith e r a fa m ilia r s e r if o r s a n s s e r if fo n t to a c h ie v e th e b e s t p o s s ib le r e a d in g s p e e d D o n o t m ix s e r if a n d s a n s s e r if fo n ts w ith in th e te x t, b e c a u s e it m a y d e c r e a s e r e a d in g s p e e d M a k e s u r e th a t th e r e is e n o u g h c o n tr a s t b e tw e e n te x t a n d b a c k g r o u n d c o lo u r s To ensure that these guidelines were met, a 12-point Arial font was used for the majority of the text included within the resource. Moreover, different fonts were not mixed together within the same body of text and a simple black text on white background contrast was chosen to maximise readability. # 2. C o lo u r s a n d C o n tr a s t: The colours selected for the resource address the following issues. O p tim a l c o n tr a s t (1 0 0 % ) C o lo u r -b lin d fr ie n d ly The colours used, as mentioned earlier, were black text on a white background. Moreover, the dominant colours for the resource layout were light blue and yellow. These colours offered optimal contrast and since colours like green, red and orange were avoided, it is expected that colour-blind users will not face any problem. # 3. L a y o u t a n d S tr u c tu r e : The following guidelines were adopted to ensure that the layout and structure of the resource provide an optimal experience to students (Lynch and Horton, 2002). U s e c le a r n a v ig a tio n a id s E n s u r e th a t th e r e a r e n o d e a d -e n d p a g e s M a x im is e s im p lic ity a n d c o n s is te n c y In c o r p o r a te a m e c h a n is m fo r fe e d b a c k a n d d ia lo g Simplicity is one of the key factors in the construction of usable online resources. Keeping this in mind, a fairly simple, yet common layout was chosen for the teaching resource. The aim of the resource is to get students to navigate through it sequentially from beginning to end. To meet this aim, the decision was made to exclude any links from the actual body of text provided within the resource. The only means of navigation is the panel of links on the left, and this ensures that the student is less likely to get distracted and lose his way. 28

34 6.3.3 C o n te n t D e s ig n D e c is io n s Previously, we discussed the reasoning behind the decision about which components to include. However, the author also needed to make the decision regarding the to p ic s to be included. The author was able to draw from his experience in Information Security and PKI gained as part of the project to decide which areas were necessary to achieve the ultimate goal of explaining PKI to students. Present students similar to those who are likely to use the final product were also consulted to gather their opinions regarding what topics might be suitable. Eventually, the decision was made to describe the basic concepts around which PKI works, i.e. cryptography, digital certificates and signatures. The core of the resource was divided into 5 sections - four corresponding to the topics mentioned above and finally, a section on PKI itself. It was also decided that five separate demonstrators would be built to explain each of these areas D e m o n s tr a to r D e s ig n D e c is io n s From the beginning, the focus was on the development of a demonstrator that would help explain the concept of PKI to students unfamiliar with the topic. The analysis phase showed that this requirement was best suited by some form of animated and highly visual presentation. Although choosing the technology with which to implement these demonstrators is usually perceived as an implementation-phase decision, the nature of this project suggested that it be made in the design phase itself. This was because the demonstrations formed the core of the system, and knowledge of the technology to be used would help understand the abilities and constraints that would be faced. The initial alternatives that were considered included: Macromedia Flash Microsoft Office Power Point Java Applets Initial investigations suggested that the decision was not a difficult one for the purpose intended M a c r o m e d ia F la s h, a vector graphics based graphics animation program clearly seemed to be the best option. This was due to the functionality provided by Flash as well as the disadvantages inherent in the alternatives. Java Applets provided a reasonable solution in terms of what could be done through them. However, pursuing an applet-based solution involved extensive programming, and the nature of this project did not seem to justify the time required, nor the complexity involved. Power Point seemed a better alternative due to the fact that reasonable animations could be constructed with it in short time. However, interactivity was limited. Flash was a clear winner - it allows for relatively quick and easy development of animated, interactive presentations like those required for this project. Flash presentations and movies can also easily be embedded within web pages. Moreover, text and movement can easily be synchronised within the movie. Although Macromedia Flash does have its fair share of detractors, keeping in mind the nature of the deployment required for this project, it is fair to say that none of these disadvantages were great enough to suggest that Flash not be used. This is supported by Lynch and Horton (2002) according to whom if y o u a r e c r e a tin g a s ite fo r a s p e c ific a u d ie n c e a n d n o t fo r g lo b a l in te r e s ts y o u w ill p r o b a b ly h a v e m o r e fle x ib ility a n d c a n a s k m o r e fr o m y o u r u s e r s. Y o u c a n r e q u ir e th e m to u s e s p e c ific b r o w s e r s o ftw a r e a n d p lu g -ins Say, for example, that your site is academic and your audience is a group of students or faculty with specialized interests. Apart from the choice of Macromedia Flash, the major design guideline that was followed was to open up the flash demonstrations in a separate window. When you have animation that relates to the content of your site, one way to minimize the potential distraction is to present the animation in a secondary window. This technique offers a measure of viewer control: readers can open the window to view the animation and then close the window when they're through (Lynch and Horton, 2002). 29

35 6.3.5 T e s t D e s ig n D e c is io n s Background study conducted into the use of different modes of online assessment provided the following guidelines (Rice, 2003) for the design of the short online test included. U s e te s ts a n d q u iz z e s le s s fo r g r a d in g a n d m o r e fo r le a r n in g e n h a n c e m e n t D e v e lo p a c o m p r e h e n s iv e te s t w ith v a lid q u e s tio n s Since a decision was also made to design the test in an objective, multiple-choice format, the following design guidelines were also adhered to (Rice, 2003). E a c h q u e s tio n h a s o n e c le a r ly r ig h t a n s w e r a n d s e v e r a l p la u s ib le d is tr a c te r s Avoid none of the above and all of the above answers Avoid as much as possible the use of negatively stated items Responses should be grammatically parallel with the question Simplify the items as possible while providing all of the necessary information to answer questions correctly Place the questions in an appropriate sequence All of the above mentioned guidelines were followed. In order to ensure that all the questions were meaningful and truly measured the user s understanding of PKI, the author decided to base the test around the process of PKI. Hence, instead of asking questions that tested the memory of the user, the questions were designed to test whether the user had actually understood the processes that PKI works around. 6.4 P h a s e 3 Implementation The task of implementation was relatively straightforward and involved implementing the required web pages in HTML and the demonstrators in Macromedia Flash. Screen shots illustrating the layout and structure of the teaching resource and demonstrator are shown below. Figure 6.1 shows a screen shot for a sample page from within the resource. This page describes the process of Private Key Cryptography. Similar pages exist for the other topics covered. This screen shot illustrates how the design goals laid down in the previous section have been adhered to. The simplicity of the structure and layout of the resource is aimed at maximising usability. Hyperlinks have been kept to a minimum to minimise the possibility of students getting confused or distracted. The link to the Flash demonstrator is in the form of a prominent button at the end of the textual explanation of the topic. To ensure that students actually view the demonstrator, they have explicitly been advised to do so once they have read the text. A provision for feedback via electronic mail has also been included on each page. Figure 6.2 shows a screen shot for a sample demonstrator. This demonstrator illustrates the process of Private Key Cryptography. Similar demonstrators exist for each of the other topics covered. There are two main issues here. The first is the fact that as explained earlier, the demonstrator is called in a new window. This is a simple approach and minimises confusion on the part of the user. The second important feature is the fact that the demonstrator has been sub-divided into two sections. The first section (the upper portion) is for the animation while the second section (the lower portion) contains a textual summary of the action that is taking place. The synchronisation of the text with the corresponding actions was an important issue in this phase, especially keeping in mind the fact that people have greatly variant reading speeds. So, to ensure that all can use the demonstrators, the speed of animation is fairly low. 30

36 Title of Teaching Resource Panel of Buttons Links to Previous and Next Page Textual Explanation of topic Link to Flash Demonstrator Provision for Feedback F ig u r e 6.1 S c r e e n S h o t o f a s a m p le p a g e o f th e r e s o u r c e Original page from which the demonstrator was called Demonstrator in separate window Area for Animation Area for Synchronised Text F ig u r e 6.2 S c r e e n S h o t o f a s a m p le d e m o n s tr a to r 6.5 P h a s e 4 Testing and Evaluation As mentioned earlier, the author decided that the main criteria for measuring the success of the teaching resource would be u s a b ility and e ffe c tiv e n e s s of the content. Two main techniques used for testing and evaluation of the teaching resource were q u e s tio n n a ir e s and c o g n itiv e w a lk th r o u g h s. However, it is important to note that questionnaires were used more for the purpose of evaluation, i.e. a fte r a stable version of the product was ready whereas the walkthroughs were used for the purpose of testing, i.e. d u r in g the process of development itself T e s tin g - C o g n itiv e W a lk th r o u g h s The Cognitive Walkthrough is defined as a te c h n iq u e fo r e v a lu a tin g th e d e s ig n o f a u s e r in te r fa c e, with special attention to how well the interface supports explanatory learning, i.e., first-time use without formal training. The walkthroughs were conducted at different stages of development and provided useful insight into problems with the resource, as perceived by its intended users, i.e. the students. The major areas to which improvements were made on the basis of these walkthroughs were as follows. Look and feel of the resource Content included within the resource, i.e. the way various topics were explained The speed of animation within the demonstration 31