Proceedings of the 38th Hawaii International Conference on System Sciences - 2005

Usability of Decentralized Authorization Systems – A Comparative Study Sanna Liimatainen Telecommunications Software and Multimedia Laboratory Helsinki University of Technology [email protected] Abstract One new type of a security system is a decentralized authorization system that allows an owner of a resource to decide who can use this resource – even without trust towards external third parties. The idea itself is fascinating, but how about its usability? Security systems are generally considered to be difficult to understand and use. This paper compares the usability features and problems of three decentralized authorization systems: PolicyMaker, KeyNote and SPKI/SDSI. The analysis is based on the Heuristic Evaluation and Cognitive Walkthrough usability test methods. The analysis suggests that approaches of public key infrastructure type, such as the SPKI/SDSI authorization system, have the best usability features but even then the current state of the art is far from the end-user requirements. Designing and measuring usability of these systems is hard, complicated by the fact that security is only a means to achieve the user goal, not the goal as such.

1. Introduction Most people lock their home doors but many leave the door to the cyber world open. Keys and locks of the real world have been in use for centuries but the corresponding computer mechanisms are under construction and their usability is still in its infancy. In this paper, we analyze the usability of distributed access control mechanisms. One of the biggest problems of security systems is that they are not easy to use. Security solutions are often complicated and some parts of the systems have complex mathematical background. However, the literature is full of examples of how different security systems enable applications that make every day life easier by using the Internet. Still, ordinary users do not trust the security solutions because, for example, they do not understand what the solutions do. Sometimes it is suggested that the security solutions should be hidden from the users. This is not a good choice since then the user is completely

uninformed about the underlying security system and she cannot base her trust on knowledge. The first security system that users usually meet is the access control mechanism of a service or a resource. This mechanism identifies and/or authenticates the user or checks that the user is authorized to use the service or the resource [1]. Authentication is usually based on the identity of the user, for example her name or identification number. The service has an access control list that contains the names of the users who are allowed to use the service. In authorization, identity is irrelevant. The access control decision is based on statements given to the user. These statements, called credentials or certificates, are usually issued by the resource or the service. The user can prove that she is allowed to use the resource or the service by giving the credentials to the access control mechanism to be evaluated. Usually, the authorization credentials are bound to a public cryptographic key of the user. The user can use the authorization if she knows the corresponding secret cryptographic key. Several methods have been developed for providing authentication and authorization. For example in Finland, the government has developed a citizen certificate and identity smart card called FINEID [9] that is based on the X.509 public key infrastructure [10]. The root Certification Authority of FINEID is Finnish Population Register Centre that issues identity certificates that binds an electronic identification number to a secret RSA key stored on a smart card. As handy as the FINEID certification system seems, it is not widely used since service providers wait for identity cards to become popular and citizens wait for more identity card services. Instead of a weak passphrase-based authentication or a traditional centralized certification authority such as FINEID, a decentralized authorization system can be used to make a service more flexible, though preserving reliability and security [8]. The identity of a user is necessary information only when some kind of profiling is done. Finally when making access control decisions, the only necessary piece of information is that the user that wants to perform an action has authorization to do so based on the given proof.

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

1

Proceedings of the 38th Hawaii International Conference on System Sciences - 2005

In a decentralized trust management system, each user can decide whom it trusts and in what way. The system does not have a central certification root. An owner of a resource itself can act as a trust root. However, the owner can use third parties when she distributes the authorization credentials. In decentralized authorization systems, the owner can choose whom it trusts to do this. It is not necessary to trust, for example, the Finnish Population Register Centre in the distribution of the credentials. When the owner trusts that someone else can handle the decision of distributing credentials, she can issue a credential that allows this other entity to delegate the authorization to use the resource. This paper studies what kind of an authorization system is usable for users of the system, and still suits well for varying applications. We have concentrated on three different approaches of decentralized authorization that are presented briefly in the next section. The third section of this paper presents the method used in this study and the assumptions about the user of the decentralized authorization systems. Then, the following section introduces user scenarios and usability problems that a user may encounter in the scenarios. Finally, the last section presents the conclusions.

credentials to an external compliance checker. The local policy credentials describe the common access control policy of the application, e.g. the trusted third parties that the application uses. The newly fetched other credentials are written in the same programming language as the local policy credentials of the application. The compliance checker evaluates the request. It checks that the credentials form a chain from the local policy to the enduser. Then, it returns the result of the evaluation to the application. This result can be “accept” or “reject” or “accept with restrictions”. The result is actually written in the credentials. Thus, several applications can use the same compliance checker that does not need to understand the semantics of the applications and its credentials. The application knows how to interpret the result that the compliance checker returns to it. Finally, the application tells the result of the query to the user and acts according to the evaluation result. Both the KeyNote and the PolicyMaker credentials have three parts: issuer, subject, and conditions. The issuer is a certification authority that is the owner of the resource presented by a public key. Similarly, the subject of the credential, a user, is also a public key. The subject can also be a set of public keys or some other structure identifying the recipient of the right.

2. Decentralized Authorization Systems The three decentralized authorization systems we have studied are PolicyMaker, KeyNote, and Simple Public Key Infrastructure (SPKI). All of the systems use authorization credentials, but otherwise the systems have differences. The main difference is that PolicyMaker and KeyNote use a common credential validity checker for all applications while in SPKI the resource checks itself that the given credentials prove that the user has the right to use the resource. This section presents more details on how these decentralized authorization systems work.

2.1. PolicyMaker and Management Systems

KeyNote

local policy answer

Trust

query

TTP: credentials

compliance checker Figure 1. Checking validity of PolicyMaker credentials

The first trust management system developed is PolicyMaker [3, 4]. PolicyMaker was later developed into a somewhat different system, the KeyNote trust management system [2]. These two systems are based on the same kind of architecture. They work as is presented in Figure 1. When a user wants to perform an action in an application, she sends a request to the application e.g. clicks a button in her application. The application then fetches the necessary credentials for the action from the trusted third parties of the application. These credentials describe the rights of the user. The application sends the query along with the policy credentials and other

2.2. Simple Public Key Infrastructure The IETF Simple Public Key Infrastructure (SPKI) working group has developed a certificate structure and operating procedures for trust management on the Internet [6, 7]. At the same time in Massachusetts Institute of Technology, the Simple Distributed Security Infrastructure (SDSI) was developed to be a simple public key infrastructure [14]. The development of SPKI and SDSI was combined together in 1997, the system is now called SPKI/SDSI. It is an authorization certificate system similar to the commonly used public key infrastructures

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

2

Proceedings of the 38th Hawaii International Conference on System Sciences - 2005

a)

R

b)

+

Figure 2. a) Authorization of Entities with SPKI/SDSI. b) Using the SPKI/SDSI credentials to proof authorization.

(e.g. X.509), but it uses authorization certificates instead of identification certificates. In addition, this system does not have any centralized certification authority to whom all must trust. In SPKI/SDSI, trust statements are encapsulated in certificates that have five main fields: issuer, subject, validity, delegation, and permission. An owner of a resource issues a certificate that typically allows the subject of the certificate to further delegate the permission given in the certificate. If delegation is allowed, the certificates can form a chain from the first issuer, the owner of a resource, to the subject of the last certificate that is an end-user. Figure 2 presents how SPKI/SDSI chains work: When the user wants to use the resource, the access control application that she is using sends all the certificates to the owner of the resource for evaluation. If the certificates form a complete chain from the owner of the resource to the user and all the certificates are valid and give the required permissions, the user is allowed to perform the requested action. The certificate chain and the request form a complete loop back to the resource owner.

3. Method and Assumptions This section first presents the used usability test methods, and then Common Criteria and its use in the analysis are presented. Finally, we present assumptions about the users of the decentralized authorization systems.

3.1. Usability Test Methods In the Heuristic Evaluation usability test method [11], a small set of evaluators examine a system and compare it to predefined usability principles. Similarly, in the Cognitive Walkthrough method [13], the system is analysed and basic tasks of the users are described as scenarios. Each scenario describes who will try to perform the task, and

what this user knows, what goals and subgoals this user has, and what her motivation is. Based on this kind of an evaluation method Whitten and Tygar [15] have tested the usability of a public key infrastructure called Pretty Good Privacy (PGP). They define [16] that a security system is usable if its · Users are aware of the security tasks, · Users know how to perform the tasks, · Users do not make fatal errors, and · Users are comfortable with using the system. This definition has also been the basis for the analysis of this study that searches the usability problems of the decentralized authorization systems, and we use it in the Heuristic Evaluation as the usability principle for security systems. Next, we describe how the scenarios are selected with the help of the Common Criteria security evaluation.

3.2. Common Criteria Common Criteria (CC) defines requirements for security properties of information technology products and systems, and provides criteria that can be used to compare that a product fulfils its requirements [5]. In the Common Criteria security evaluation, the testers first set the goals to which the system is targeted to, and then compares the goals to how the evaluated systems actually work. The comparison criteria as such are not suitable for this study, since the goal is not to evaluate security but usability. Thus, CC is used only for identifying all functional parts that an ordinary decentralized authorization system has. The functional parts of decentralized authorization systems identified with help of CC are handling of credentials, security attribute management, authorization, delegation, management of credentials, revocation, validity, privacy, and trusted communication.

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

3

Proceedings of the 38th Hawaii International Conference on System Sciences - 2005

3.3. Test Method First, we used the Common Criteria security evaluation criteria to find out the functional parts of a generic decentralized authorization systems. Following the Cognitive Walkthrough, the detailed scenarios are defined to describe how these functional parts of the systems are used. Finally, the Heuristic Evaluation is used to compare the predefined usability principles, defined by Whitten’s and Tygar’s, to functioning of the different decentralized authorization systems. The next section presents the use scenarios in more details. In brief, the scenarios that present the most important functions of decentralized authorization systems are · Authorization of entities, · Definition of a security policy, · Revocation of rights, · Checking validity of a set of credentials, · Protecting privacy of users, and · Distinguishing trusted channels from untrusted channels.

3.4. Limitations of the Test Method The main drawback of this kind of evaluation method is that real users are not involved in the test, but only expert user issues can be addressed [12]. This kind of testing can be used in early phase of the design. The test should be repeated with several evaluators, and finally, using of observation and interviews methods, the real users should be involved when integrating the decentralized authorization to a real application.

3.5. Assumptions about the User Nowadays, many homes have an always on connection to the global Internet. Because service providers take care of security issues differently, at home someone should be able to configure the security for the computer: who can use the resources offered by the computer. This is the main goal of a decentralized authorization system. The owner of a resource can define the security policy for it, and as well, that she can define who can use the resource and under what kinds of conditions. In addition, the owner can choose to distribute the credentials to the end-users through trusted third parties. The owner can choose whom it trusts to act as trusted third party and in what way. For example, the owner can delegate all access control decisions to someone trustworthy. The current decentralized authorization systems are suitable for expert rather than ordinary users. A resource owner must know much of the underlying technology used and use much time to define necessary credentials i.e. act as an administrator of the resource. The administrator can

be responsible for the whole system or only for one application in it. Actually, we can think that the owner of the resource of the service has authorized in real world the administrator to act on her behalf when credentials are created and access control decisions are made. The user who wants to gain access to the resource or the service needs less experience, e.g. she has to provide needed credentials for access control decision.

4. Results This section describes the results of the Heuristic Evaluation. Summary of the results is presented in the end of this section.

4.1. Scenario 1: Authorization of Entities The administrator delegates rights to use a resource to other entities. She makes sure that the entity is trustworthy, that is, can be authorized, and that some security policy allows her to give these rights to the entity. All the studied systems support this principally, since the main purpose of decentralized authorization systems is to authorize entities to perform actions. Often, the authorizations can also be further delegated. The biggest problem is that none of the decentralized trust management systems considered in this study defines how the administrator can gain assurance of trustworthiness of an entity that can be either the third party or the end-user. PolicyMaker and SPKI/SDSI do not help the administrator to choose the correct public cryptographic keys that usually represent the entity to whom the authorization is given. The cryptographic keys are long garbled text that is not meant for humans to read. In KeyNote, the administrator can give human readable aliases to public keys but this can lead to a problem described in Scenario 5. PolicyMaker and KeyNote require programming skills since credentials are defined in a programming language. In addition, in these systems every participant of the system must agree on what the statements in the credentials mean since the compliance checker does not understand the meaning of the credentials.

4.2. Scenario 2: Definition of a Security Policy for a Resource First, the management of an organization defines the top level security policy. The administrator derives the technical security policy of a resource in the organization from this upper level policy. Then, the administrator creates the necessary credentials for every resource that needs

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

4

Proceedings of the 38th Hawaii International Conference on System Sciences - 2005

protection according to this technical security policy. In the second scenario, the problem is that the security policy of an organization is usually written in a generic level and can be a declaration, a couple of sheets long text stating that security will be taken into account in the organization. The administrator must decide how she expresses the security policy of the organization for all resources. She has to identify information, resources and services that need to be protected according to the top level security policy of the organization, and define the actual rules for the protection. This problem is common for all the evaluated systems. In addition, in these authorization systems there is no way to verify that a set of credentials (i.e. policy rules) corresponds to the whole security policy of an organization. This means that there is no way to realize if the administrator has forgotten to define the policy credentials for some resource that needs to be protected according to the top level security policy. The evaluated systems have two different approaches to giving rights: in PolicyMaker and KeyNote everything is prohibited by default and the administrator gives access rights while in the SPKI/SDSI credentials everything is allowed by default, and the administrator defines the access restrictions. In the latter approach, the administrator may accidentally give or delegate too much rights by forgetting to define a necessary access restriction. For example in the SPKI credential, if the administrator forgets to define a directory in the file hierarchy of the WWW server, the user can connect to all directories in the server. In PolicyMaker and KeyNote, the same kind of programming language is used to create common credentials and policy rules, and this causes the same problems as explained in Scenario 1. In addition, the integrity of policy credentials is not protected in PolicyMaker and KeyNote. This means that the credentials must be protected separately against unauthorized changes, which is studied in the last scenario.

4.3. Scenario 3: Revocation of Rights The administrator of the system must revoke the credential if the access rights given by the credential become invalid before the credential expires. Revocation of rights becomes topical, for example, when an employee quits working in a company or moves from one department to another in the company. KeyNote does not define revocation at all. The other systems allow for this. However, the revocation of credentials must be taken care of beforehand, i.e. when the

credentials are created. A means to check if the rights given in the credential have become invalid is written into the credential. For example in SPKI/SDSI, a credential has a field that directs to a location, defined by Uniform Resource Locator (URL), where a certificate revocation list is. These credentials can use online revocation. It means that the revocation list is accessible through a network on the Internet and always when the certificate is used, the checker should consult the list. Similarly, the revocation of PolicyMaker credentials must be taken care of when the credential is created. Revocation of credentials requires programming skills in PolicyMaker. Finally, it is difficult to gain assurance that the revocation is really necessary when such a system is used where the revocation is possible. For example, the revocation of the credentials must be a part of a process concerning an employee that moves from one department to another in a company. This process informs also the administrator that revokes the unnecessary credentials.

4.4. Scenario 4: Checking Validity of a Set of Credentials The owner of a resource checks that a set of credentials prove that the user requesting an access to the resource really has the requested authorization. In validation, the owner must check both the validity of each credential and that the set of credentials forms a complete proof of authorization. In all of the studied systems, the protected resource or the owner of the resource can check the validity of credentials. In PolicyMaker and KeyNote, the validity checker entity, which is called the compliance checker, does not understand the content of the credentials as is explained in the introduction. The checker gets in the validation query both the local policy credentials of an application and the credentials issued for the user. Based on these credentials, the compliance checker defines the answer for the query, i.e. it combines all the credentials and derives the outcome. In PolicyMaker, the result is derived from the credentials. In addition to this in the similarly working KeyNote, all the possible results must be defined and ordered from the weakest to the strongest possible beforehand when the credentials are created. In these systems, the application finally get the response and it can understand what the result means. In SPKI/SDSI, all credentials must be checked when their validity is evaluated. If the chain of certificates is unbroken from the resource to the end-user and all credentials as such are valid, then the end-user is allowed to use the resource.

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

5

Proceedings of the 38th Hawaii International Conference on System Sciences - 2005

Number of Usability Problems

PolicyMaker

KeyNote

SPKI/SDSI

1: Authorization of Entities

4

3

2

2: Definition of a Security Policy for a Resource

4

4

2

3:Revocation of Rights

3

2

2

4: Checking Validity of a Set of Credentials

2

3

2

5: Privacy of Users

2

3

2

6: Distinguishing Trusted Channels

1

1

0

Total

16

16

10

Table 1. Number of found usability problems.

If the authorization is poorly defined in the credential, every decentralized authorization system compared in this study can authorize illegitimate entities to use the protected resource.

4.5. Scenario 5: Privacy of Users A user can accidentally reveal her identity by giving too many credentials to an untrustworthy resource. The resource can combine the information given in the credentials and find out the identity or position of the user. A credential as such may also reveal the identity of the user when it contains the name or other identifiable information. When a collection of certificates is gathered up for proving an authorization, the true identity of the owner of the public cryptographic key may be revealed. In all the systems, the privacy protection depends on the used application and the issued certificates. In KeyNote and SPKI/SDSI, the name of an entity can be revealed accidentally. The KeyNote credential may use local constants to make credentials human readable: If the issuer of the credential uses the name of the key owner as an alias for a public key, the key owner’s identity is revealed to everyone who reads the credential. Additional certificates given to be evaluated may reveal the user’s identity in PolicyMaker and KeyNote as the credentials in these systems are monotonous. This means that every credential adds a piece of information to the rights given by the set of credentials. When the credentials are fetched from the trusted third parties of the application, additional credentials for other purposes may also be given for evaluation. If a malicious person listens the connection between the application and the compliance checker, she can guess who the user is based on the information stored in the credentials.

4.6. Scenario 6: Distinguishing Trusted Channels from Untrusted Channels Administrator must define when the unsigned credentials can be used as policy credentials and in what way they are transmitted between entities. An end-user must then follow the instructions given by the administrator. Trusted channels between two entities in a decentralized authorization system are transmission paths that are protected, at least, against unwanted modifications, but possibly also against eavesdropping. In SPKI/SDSI, the issuer of the credential always signs the credentials. The digital signature proves the origin of an electronic document but it also protects the electronic document from unauthorized changes. Thus, the SPKI/SDSI trust management system does not need trusted channels for transporting credentials from an entity to another. If the compliance checker of PolicyMaker or KeyNote is an external entity, the integrity of unsigned policy credentials during transportation must be secured with an external mechanism. Other credentials are signed and they do not need the trusted channels. Thus, the administrator must know if the compliance checker is an external entity and then there must be a trusted channel between the protected resource application and the external compliance checker. Trusted channel is unnecessary between the protected resources and the trusted third parties that store the user credentials or if the compliance checker is located in the same computer with the used application.

4.7. Summary Table 1 presents the number of usability problems that were found in the analysis presented above. PolicyMaker and KeyNote have clearly more usability problems, total 16 usability problems, than the SPKI/SDSI systems that

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

6

Proceedings of the 38th Hawaii International Conference on System Sciences - 2005

have total ten usability problems. The most important security tasks in a decentralized trust management are issuing credentials that denote trust and checking that these credentials are valid and give the requested rights. Moreover, SPKI/SDSI has fewer problems in these key tasks than PolicyMaker and KeyNote. Based on our analysis, the Public Key Infrastructure type approach used in SPKI/SDSI is more usable than the PolicyMaker approach for the administrators of the system. In SPKI/SDSI, all the trust expressions are described in a similar way by signed certificates. The structure of the SPKI/SDSI certificate clearly distinguishes the rights that can be delegated to others from the non-delegable rights and validity of the certificate is given separately from the actual authorization. In PolicyMaker and KeyNote, both the validity and delegation right are embedded in the authorization field of a credential. It is also easier to understand the approach taken by the SPKI/SDSI authorization system than that of PolicyMaker: the administrator can restrict the right given to her by someone when she issues a new credential to someone else. Because the SDSI/SPKI certificates always are digitally signed, they can be delivered from one entity to another entity of the decentralized system through an untrusted network such as the Internet. For example, a software agent does not need secure storage for its policy credentials since it can use external storage for the protected credentials, and it does not need separate system for protecting credentials on transmission. However, the digital signatures that protect the credential against unwanted modifications can reveal information about the entity that has given or received the credential because everybody is able to verify the digital signature of the credential. There exists cryptographic systems where this verification is only possible with the creator of the signature, but they are not widely used. If the policy credentials are unsigned, they must be stored and transported in a secure system which itself needs careful maintenance including access control. Although the external common compliance checker used in PolicyMaker and KeyNote can be used for multiple purposes, it may cause more work for the administrator of the system. Creating credentials that are evaluated without understanding the semantics of the credentials is difficult. In the end, the owner of the resource makes all the access control decisions. She can reject the requested action even when the credentials given to an end-user should authorize the end-user.

5. Conclusions The security functions of decentralized systems are secondary rather than primary goals of the user of the system. The decentralized authorization systems are usually working with an application that provides some content service. There is no suitable method to easily test the secondary functions such as usability of security [16]. In this paper, we presented comparison of decentralized authorization systems based on the Heuristic Evaluation and the Cognitive Walkthrough usability methods and the security evaluation system Common Criteria. Common Criteria suits well for identifying essential parts of a security system for usability testing of the system even though it is not used otherwise. The purpose of this study was to find out which of the decentralized trust management system best supports the users of the system by providing usable concepts. Our analysis suggests that SPKI/SDSI public key infrastructure with authorization certificates is the most usable system. It has a common basis with the currently widely used identity certificate public key infrastructures such as X.509, and errors are not so likely to occur accidentally with SPKI/SDSI. Our analysis has shown, however, that the current decentralized authorization systems have many usability problems that must be solved before the systems are usable for an ordinary user who does not understand the underlying security technology well. Defining and creating usable security has not yet been successful and we still need tools and methods in order to achieve the goal of usable security. The concepts behind the system are complex, making misunderstandings and errors likely to occur even among experienced users. Generally speaking, the decentralized authorization systems are made for expert users and from an engineer’s point of view without regarding ordinary end-users and how the systems will work in practice. The administrators need to understand the security technology that the system is based on well, and even know the basics of programming language, in order to create a trustworthy system. The analysis presented in this paper is necessary since the usability aspects must be integrated in the early development phase of security systems. Thus, the engineers need a wake up call to act for the end-users.

6. Acknowledgements I thank Jouni Karvo, Timo Kiravuo, Linda Staffans, Teemupekka Virtanen, Ursula Holmström and Kristiina Karvonen who have given valuable comments for this paper.

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

7

Proceedings of the 38th Hawaii International Conference on System Sciences - 2005

7. References [1] R. Anderson, “Security Engineering. A Guide to Buiding Dependable Distributed Systems”. John Wiley & Sons. 2001 [2] M. Blaze, J. Feigenbaum, J. Ioannidis, and A. Keromytis, “The KeyNote Trust Management System Version 2”. RFC 2704, 1999 http://www.ietf.org/rfc/rfc2704.txt?number=2704 [3] M. Blaze, J. Feigenbaum, and J. Lacy “Decentralized Trust Management”. Proc. IEEE Conference on Security and Privacy, 1996. [4] M. Blaze, J. Feigenbaum, and M. Strauss, “Compliance Checking in the PolicyMaker Trust Management System”. Proc. 2nd Financial Cryptography Conference, 1998. [5] Common Criteria Evaluation Board. “Common Criteria for Information Technology Security Evaluation”, version 2.1. September 2000 [6] C. Ellison, “SPKI Requirements”. RFC 2692, 1999 http://www.ietf.org/rfc/rfc2692.txt?number=2692 [7] C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas and T. Ylönen. “SPKI Certificate Theory”. RFC 2693, 1999 http://www.ietf.org/rfc/rfc2693.txt?number=2693 [8] J. Feigenbaum “Towards an Infrastructure for Authorization, Position Paper”. Proc. 1998 USENIX Ecommerce Conference, 1998. [9] Finnish Population Register Centre. Electronic Identification. 2002 http://www.sahkoinenhenkilokortti.fi/default.asp?todo=setlang &lang=uk [10] International Telecommunication Union, Telecommunication Standardization Sector. X.509. 1997 [11] Molich, R. and Nielsen, J. Improving a Human-Computer Dialogue. Communications of the ACM, 33(3), March 1990 [12] Nielsen, J. Usability Engineering. Academic Press, 1993. [13] Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S. and Carey, T. Human-Computer Interaction. Addison-Wesley. 1994 [14] Rivest, R. and Lampson, B. SDSI – A Simple Distributed Security Infrastructure, 1996. http://theory.lcs.mit.edu/~cis/sdsi.html [15] Whitten, A. and Tygar, J. D. Usability of Security: A Case Study. Carnegie Mellon School of Computer Science. 1998 [16] Whitten, A. and Tygar, J.D. Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0. Proc. 8th USENIX Security Symposium. 1999

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

8