Internet access through WLAN with XML encoded SPKI certificates

Internet access through WLAN with XML encoded SPKI certificates J. P. T. Koponen*, P. Nikander†, J. Paajarvi*, J. Rasanen* *First

Hop Ltd. Research1

†Ericsson

Abstract Wireless Local Area Networks (WLAN) are one of the most promising approaches for IP based mobile network access. In this paper, we present a security and accounting architecture for WLAN based public Internet access. Our scheme is based on the use of Simple Public Key Infrastructure (SPKI) certificates supporting all kinds of prepayment mechanisms. The architecture provides the possibility to grant fully anonymous Internet access for users while using strong cryptography in checking the access rights. As an example implementation of our concept, we describe an Internet cafe where the users buy Internet access time for their portable terminals together with other products. The access rights are presented as SPKI certificates and transferred to the users through an infrared link which is secure due to its locality. The user requesting the Internet access presents the required certificates through WLAN link to the access controller. Routing to the external Internet is granted if the access control check is passed. We present the performance results measured with our experimental arrangement. The results show that the system would be feasible to be used in a real application. We also discuss the risks and benefits of PKI systems in general and evaluate the suitability of decentralized public key certificate infrastructures for locally administered service provisioning. In addition, we emphasize the benefits of XML as the certificate encoding format, as recently suggested at the IETF by Paajarvi. Keywords: SPKI, XML, certificates, anonymity.

operator NTT DoCoMo. Within the next few years, both traditional telecom operators and new enterprises will be launching successive technologies allowing more sophisticated services, including services based on the current GSM technology (e.g., GPRS and UMTS), and services based on other access network approaches (e.g., Metricom Ricochet). The accounting and security solutions of these technologies are varying. However, all these systems are based on authenticating the users identity against a centralized database. In this paper, we present a concept for accessing Internet through public Wireless Local Area Networks (WLAN) [2] in a way that conserves the customer anonymity. The accounting and security system is based on Simple Public Key Infrastructure (SPKI) [3][4]. The cryptographic certificates are encoded in XML, using the format proposed recently [5]. Thus, our system is based on the use of decentralized authorization rather than centralized identity authentication and explicit access control lists. In order to evaluate the viability of our concept, we have implemented a simple example system (see Section 4). Our experiment simulates an Internet cafe providing WLAN access for customers buying also the cafes products. The customer receives certificates granting access to the Internet through an IrDA [6][7] based infrared link. The Internet access is granted if the customer can present a valid certificate chain through the WLAN link and prove that he or she is the party for whom the certificates were created.

1.1 1 Introduction The era of widespread wireless Internet access has begun after the introduction of Wireless Access Protocol (WAP) [1] and iMode launched by the Japanese cellular 1. While majority of this work was made, P. Nikander was at Helsinki University of Technology.

Centralized vs. decentralized PKI

In the common security parlance, public-key infrastructure (PKI) based security architectures usually rely on certificate authorities (CAs). In such systems, the certificate authorities hold the monopoly of issuing certificates, and only the CAs belonging to a set of predefined CAs, or to a CA directly or indirectly approved by a CA in the predefined set, are allowed to issue certificates. Indeed, in this paper we reserve the term certificate authority to denote parties in such a monopoly position.

The usual argument supporting this monopolistic arrangement is based on the claim that issuing certificates is very risky, and therefore, it should be made in a centralized and well controlled way. In our view, both the claim and the conclusion are wrong. To summarize our view briefly, we want to note that much of the common PKI “wisdom” is based on the assumption that certificates are used for identification. But unfortunately computers are particularly bad in identifying humans, and certificates do not change this fundamental difficulty. Therefore, as noted in [8] and discussed by in more detail in e.g. [9], certificates are much better suited for decentralized authorization [9][10] than identity authentication. In our example situation, i.e., anonymous Internet access, this is indeed the situation. Thus, when considering certificates and access control, the key question can be expressed as follows: for what is the certificate authority needed in the first place? Actually, we do not want that some instance or instances have the ultimate authority to issue authorization certificates on our behalf unless we have freely chosen so. The main argument for decentralized authorization is that it is much better to decide case by case, whether to trust the issuer of an certificate or not. Furthermore, the decision whether to trust the contents of a certificate should not be based only on the issuer of the certificate, but also on the authorizations carried by the certificate. Some issuers are trusted for some actions but not for others, and thus, the authorization system must be fine grained. The descriptive power of a decentralized fine grained authorization mechanism exceeds the descriptive power of a certificate authority based authorization mechanisms. To be more specific, the certificate authority based mechanism can be simulated with the decentralized mechanism: a principal2 writes a certificate granting all authorizations to the top most certificate authority. After that, the certificate authority can write a certificate for a lower level certificate authority granting full access to resources of the initial principal. This shows that the centralized mechanism is only a subset of the decentralized mechanism. This leads us to the fundamental principles behind decentralized PKIs [3][10][11]. In such a PKI, all the principals can issue certificates. All principals decide 2. In this paper, we use the term “principal” to denote computers, programs, or other active parties that are assumed to have one or more private keys in their sole possession. In our architecture, a “principal” is the basic identifiable unit that is able to perform actions.

individually whether to trust a given chain of certificates or not. In addition to the conventional certificate validity checks, the decision is based on local policy rules, explicitly created and altered by the validating principal. Thus, the contents of a certificate are not necessarily respected even though the certificate was validly signed by a known party. Instead, the result of the decision whether to respect the certificate or not depends on the local policy related to the certificates purpose. Considering wireless Internet access, building on the top of a decentralized PKI leads to simple design. Basically, each wireless access control point is able to determine the access rights of a user simply in the following way. First, it checks whether there is a chain of certificates originating from the access control point itself to the user. Secondly, it checks whether the certificate chain explicitly expresses the user’s right to gain access to the network through the access control point. We introduce the concept of decentralized authorization in more detail in Section 2. The XML encoding of SPKI certificates is briefly presented in Section 3. We also underline the benefits of encoding certificates in a format which is both human and machine readable. Section 4 describes the architecture of our conceptual structure and presents our experimental arrangement. In addition, we present initial performance figures showing that the access control decision can be made in a subsecond time frame. Finally, Section 5 describes some future directions while Section 6 gives our conclusions.

2 Decentralized authorization The Simple Public Key Infrastructure (SPKI) is a way to decentralize authorizations so that no certificate authority is needed [3][4]. In SPKI, the instance controlling the access to a resource grants the access rights to a second instance it trusts. If the initial instance trusts the second instance enough, it can also give it the right to delegate rights further to third instances. In the end, the access controller checks if the access rights originate from itself. Thus, the concept of CAs can be abandoned, and all valid certificate chains must be originated by the validating instance. In addition to SPKI, there are also other decentralized experimental level security infrastructures, including PolicyMaker [10] and KeyNote [11][12]. These infrastructures differ from SPKI, but the central idea that trust should be decentralized is mutual to all of them. For a thorough discussion in decentralized trust and authorization in general, see [9].

2.1

Simple Public Key Infrastructure

Simple Public Key Infrastructure is an experimental level public key infrastructure proposed by the IETF. It is attractive since it solves many of the problems related to PKIs in a straight forward way. The authors feel that the major reason for the under valuation of SPKI is the dominant position of X.509. This dominance is not due to better infrastructure, but better marketing and existing market positions. SPKI is highly simple compared to X.509, however, not on the cost of functionality. In SPKI, there can be name certificates and authorization certificates. The name certificates bind names to the rights transmitted by the certificates. The authorization certificates bind the cryptographic keys to the transmitted authorizations. The cryptographic keys are used to identify the principals delivering the certificates unambiguously. When using name certificates, the names must be bound to the cryptographic keys identifying the principals. This is not always trivial.

2.2

SPKI Certificate Theory

The SPKI theory is described here as presented in the original reference [3], except in the case of generic tag intersection. The data of an SPKI certificate is described by five fields, usually presented as a 5-tuple (I, S, D, A, V). Here, I denotes the issuer of the certificate, i.e., the principal who gives the authority, and S denotes the subject, i.e., the principal who receives the authorization carried by the certificate. The D field describes whether the subject is allowed to delegate the authorization further. A describes the authority carried by the certificate (in the SPKI theory, A is also called tag). The last field V denotes the validity of the certificate. The validity can be unconstrained, or it can be constrained with, for example, beginning and ending dates and times, and certificate revocation lists (CRLs) and on-line tests. To summarize, the SPKI 5-tuple defines that the authorization described by the fields D, A and V is transmitted from the issuer I to the subject S. In the default case, all principals are denoted by their public keys (or secure hashes of their public keys) rather than their names. In SPKI, the concept of certificate chain is important. If there are two certificates (I1, S1, D1, A1, V1) and (I2, S2, D2, A2, V2) so that S1 = I2, i.e., the subject of the first certificate is the issuer of the second certificate, the two certificates form a certificate chain. The certificate chain transmits authorization from the issuer of the first certificate I1 to the subject of the second certificate S2. According to the SPKI theory, the authorization trans-

mitted by the certificate chain is the intersection of the authorizations defined by the D, A, and V fields of the both certificates. The certificate chain could be replaced by a certificate (I1, S2, D3, A3, V3), where D3 is the intersection of D1 and D2, A3 is the intersection of A1 and A2, and finally V3 is the intersection of V1 and V2. Since the delegation field D has either the value true or false, the intersection D3 can be trivially computed. Similarly, if the validity field V has only dates and times data as its values, the intersection V3 can be easily determined. If validity elements contain certificate revocation lists or on-line tests, the intersection determination is more complicated, see [14]. The original SPKI theory [4] defines the authorization reduction in the same way, so that the intersection is computed in an application independent way. However, in realistic applications authority field is more problematic [5]. A good example are the Java 2 permissions [15]. Let us consider an example where we have two permissions: P1: java.security.AllPermission() P2: java.io.FilePermission( "/etc/passwd","read") Here, P1 grants all the authority to perform all the possible tasks in the operating system, and P2 grants only the authority to read the /etc/passwd file. Clearly, the intersection of permissions P1 and P2 is P2. In a general case, where two arbitrary authorities are given from arbitrary systems, there is no way to compute the intersection in a generic way. Thus, in such cases, the intersection must be computed in an application dependent way.

2.3

Certificate loops and distributed authorization

A certificate loop is a certificate chain in which the issuer of the first certificate in the chain is also the access controller validating the request. This leads us to the SPKI’s central idea: the authorization is granted only if the source of the authorization is the access controller herself! Therefore, no certificate authorities are needed. There is no other instance deciding the access control than the access controller herself. This principle decentralizes the authorization process automatically. The authorization management is done locally, so no central authorities are needed. This is an advantage in highly distributed systems, as in the case of community of mobile phones and PDAs carrying facilities for certificate processing. In these environments, the decentralized nature of SPKI could facilitate ad-hoc service

provisioning. Anyone could establish her own service, and then create and give certificates authorizing to use that service. This could be done ad-hoc since no support from centralized authorities is required, but still preserving full security. More about the certificate loops can be read in [16].

3 XML based authorization 3.1

XML -- Extensible Markup Language

The Extensible Markup Language (XML) is the new standard by World Wide Web Consortium (W3C) for delivering of electronic content [17]. XML is based on the Standard Generalized Markup Language (SGML). The original guidelines in the XML design included, among other things, the possibility to use the documents in the Internet, widely spread software support, easiness of application programming, easiness of XML document preparation, and human readability [17]. XML has met these goals and there exists many free software packages supporting the use of XML.

3.2

cessing time increases with increasing certificate size and complexity. There are two application programming interfaces (APIs) for XML processing, Document Object Model (DOM) [20], and Simple API for XML (SAX) [21]. Developers can change the processor of the XML system with low cost as long as the new and the old XML processors provide the same API. XML supports inherently the document structure verification. The XML documents are verified against their Document Type Definition (DTD) automatically. The XML documents can be easily converted to different forms of representations with XSL. In the end, the XML certificates are both human and machine readable, which makes them more explicit to the users and system developers. Although the end users might never see the certificates, the question of certificate clarity is not without importance. If legitimate authorizations should be carried in the certificates, all the participants should be capable to understand their content. Documents with too complicated structure might not be legally sound in US court [22].

XML for certificate encoding

XML is an attractive format for encoding certificates for many reasons. It has been quickly adopted by the Internet community, and there are many free high quality software packages available [18]. These packages are aimed for encoding, parsing and verifying XML documents. Many of the already existing wireless devices (Personal Digital Assistants, PDAs, and mobile phones) can have built-in XML parsers. WAP (Wireless Application Protocol) enabled cellular phones [1] utilize Wireless Markup Language (WML) which is defined by using XML. Also, WAP browsers can be downloaded to PDAs such as Palms [19]. For example, the basic Palm III or Palm V handsets have two Megabytes memory, and the amount of memory can be expanded. Thus these devices have plenty of memory for the XML certificates, which require two kilobytes capacity with RSA keys. The next generation wireless devices have been designed to support real-life voice and video data requiring large memory capacity and high speed data links. Therefore it is clear that the size of the XML certificates is irrelevant. The extra time required for the processing of the XML certificates, whose size is comparable to the size of the example certificate shown in [5], is negligible compared to the time required by the computations related to the public key cryptography. Naturally, the certificate pro-

3.3

XML encoded SPKI certificates

The full DTD of the XML encoded SPKI certificates is given in [5]. The original SPKI proposals [3][4] present the certificates in s-expression format. This section gives an example fragment of XML encoded SPKI certificates by showing in a form of DTD definition. The following example presents the format of the definition of a public key element, and the definition of the RSA public key element: The public-key element is used to specify the issuer and also the subject if the subject is a principal. The public key can be either RSA public key, rsa-pubkey, or DSA public key, dsa-pubkey. In the example, the definition of RSA public key element is shown. It contains the data for the public exponent E, rsa-e, and the modulus N, rsa-n. The four parameters related to the DSA keys are presented in a similar way. The public key data is presented in base64 encoded ASCIIformat in the certificates.

tions, and alternative initial security measures, are briefly discussed in Section 5.

Internet

Access Controller Certificate 1 WLAN Cashier



IrDA

Cafe

Customers laptop Certificate 2

Figure 1: The schematic illustration of the implementation

The certificates must be signed. Currently, the standard for signing XML documents is under development [23]. In our application, only a small subset of the general XML signature mechanism is required. The reason for this is that the certificates do not link to any other documents that should also be taken into account in the signing process. The certificates must be canonized before signing so that all the empty spaces and line endings are removed. After that, the hash is computed over the certificate with MD5 message digest algorithm [24].

4 Example application We utilized the SPKI implementation in Java described in [25][26] in our example implementation. The implementation simulates an Internet cafe providing Internet access for customers having laptops equipped with WLAN cards along them. The authorization system is written in Java, and utilizes Java 2 security mechanisms. The system is illustrated in Figure 1. First, as the customer enters the cafe and pays for her coffee (or just for the Internet access), she simultaneously sends her public key through an infrared link to the computer of the cafe’s cashier. In our system, this is accomplished by sending a self signed XML certificate containing no permissions. The cashier receives the certificate and picks the certificate issuer’s public key. This public key is the public key of the customer. The range of the infrared link used is about one meter and the range can be reduced with optical blocks. The optical signal can be confined easily to secure the transmission against eavesdropping [7]. This ensures that the public key can be delivered in a secure way without the fear of a man-inthe-middle attack. Alternatives to IrDA communica-

After the payment has been carried out, the cashier writes a certificate for the customer in which the Internet access is granted for a specified time interval. The certificate is transmitted back to the customers laptop through the infrared link, and the customer stores the certificate in her laptop’s certificate store. The certificates are stored in local key stores. The customer goes to her table and wants to begin the Internet surfing. Then she has to connect to the Internet access controller and ask for the access. In our system, she sends the certificate and an authenticator in which she proves that she has the private key connected to the public key of the certificates subject. In our test system, this is done in the wireless local access network through Java’s remote method invocation (RMI). The access controller waits for access requests, and as the customer sends the query and the certificate, the access controller tries to find a certificate chain beginning from its public key and ending to the certificates subjects public key. Earlier, the access controller has authorized the cashier to grant accesses to the system, and it has stored the certificate carrying that authorization to its own local certificate store. Therefore, the access controller finds a certificate chain consisting of two certificates. The first certificate grants authority to the cashier and, in the second, the cashier grants Internet access to the customer. This certificate chain is reduced, and the reduction certificate carries the intersection of the authorizations of the certificates in the chain. If the reduction certificate carries the permission for the Internet access at the current time (in our system the permission is WLANAccessPermission("Cafe")), the access request is processed further. Next, the access controller checks that the authenticator is signed with the private key related to the public key in which the certificate chain ends. If the signature check is successful, the customer has a valid certificate and he has proved to be the principal for whom the access permission has been granted. Currently, we have implemented the access request over WLAN. The customer connects to the access controller through RMI and submits the signed query and the certificate. The access control returns true if the access is granted and false otherwise. In the experiments the principals were identified with 1024 bits long DSA keys.

In our implementation, the customer does not authenticate the access controller. The access point providing the WLAN service might be covered by a hostile access point trying to sniff the users traffic. This problem can be solved if the wireless user challenges the access controller to sign an authenticator. For this purpose, the wireless user must get the access controllers public key in a secure way. Most naturally, the cashiers terminal sends a certificate containing the access controllers public key through the IrDA link at the same time with the other certificates.

4.1

Experimental arrangement

The system performance measurements were carried out with the following equipment. The customer is simulated with a laptop running with Windows NT 4.0 operating system. The laptop had 96 MB memory and Pentium II processor of 266 MHz CPU. The measurement software ran on Sun JDK 1.2.2. The access controller was a PC with Intel Celeron processor of 433 MHz CPU and 128 MB memory. The operating system was RedHat Linux 6.0 and the Java version used Sun JDK 1.2.2. The customer was connected to the local network through WLAN radio link compliant with the IEEE 802.11 standard. The WLAN link is capable for data transmission rate of 11 Mb/s. The WLAN access point was connected to the local Ethernet network of 10 Mb/s. At the time of the measurements there was no other significant traffic in the Ethernet network. We used 1024 bit long DSA cryptography and the certificates were signed with SHA1 with DSA [27]. The authenticator was signed with MD5 message digest algorithm.

4.2

System performance

We measured the time which is needed to check the authorization through the WLAN link. The authorization check consists of the following steps. First, an RMI connection is opened. After that, the customer calls a remote method and gives the certificate received from the cashier and the authenticator as parameters. In the access controller end we measured the time required for the certificate chain reduction and the signature checks. The system performance was measured with the tools provided by the Java system. All the measurements were repeated 20 times in order to get good estimates for the mean values of the measured quantities and rough estimates for the error bars, i.e., the standard deviations of the quantities. There was no evidence on strongly non

symmetric distributions and, thus, the standard deviations describe the data well. The measured data with the corresponding error-bars are presented in Table 1, on the next page. We measured the total time experienced by the laptop user (i.e., the customer) for the access request processing. This time is denoted by ‘access request’. This does not include the starting of the Java Virtual Machine (JVM) and loading all the Java class libraries, but only the time required for the security transaction processing. In the laptops end the processing is divided into two sub tasks, opening of the RMI connection and the access control request by invoking a remote method. The results in Table 1 show that the opening of the RMI connection is slower than the actual access control. The total time required, 0.52 s, is well acceptable to be used in real life applications. The time required for the opening of the RMI connection is slightly larger than the time required for the actual access request. This is due to the RMI slowness and not due to the usage of WLAN. We ran the same tests also through the hard wired Ethernet lines, and the RMI connection time was slightly (~20%) longer than through the WLAN lines. The actual access request (‘access request’) consists of the following sub tasks: certificate chain reduction (’certificate reduction’), signature check, and extra tasks for processing the certificates and creating classes. The certificate is submitted in string format to the access controller. The certificate chain reduction includes the parsing of the cashier to customer certificate to an XML DOM tree, getting the access controller to cashier certificate from the certificate store, certificate chain search (which is very simple in this case), certification signature check, computation of the reduction certificate, and finally the check if the reduction certificate carries the required permission. All this takes only about 0.15 s. The checking of the access request includes also the check that the authenticator is signed with the private key corresponding to the reduction certificates issuers public key. We measured also the time required for creation of a new key pair in the laptop. If the customer wants to stay anonymous, he can create a new key pair for each session. The key pair creation is slow, in our experiments laptop it takes 10.8 s. On the other hand, we could create a system which computes one time key pairs in advance so that they are ready when the customer goes to the cashiers desk to get the certificate.

Measurement host

Measurement

Mean (ms)

Std. Dev. (ms)

Customer laptop

access request

520

17

Customer laptop

open RMI connection

285

7

Customer laptop

call access controller

235

16

Access Control PC

certificate reduction

146

2

Access Control PC

signature check

42

1

Customer laptop

create a new key pair

10750

25

Customer laptop

sign query

163

8

Table 1: The results of the performance measurements of the example application. Each measurement was repeated 20 times. The measurement host is the host in which the measurement was carried out. The total time required in the laptop for preparing and carrying out the access request is denoted by ‘access request’. This task is composed of two sub tasks, i.e., the opening of the remote method invocation link ‘open RMI connection’ and the actual access request by a remote method invocation call to the access controller, ‘call access controller’. In the access controllers side, the access request ‘call access controller’ consists of the sub tasks ‘certificate reduction’, i.e., parsing the certificates, and finding and reducing the certificate chain. The access control check includes also the signature checking, ‘signature check’. We measured also the time required to create a new key pair from scratch in the customers laptop (’create a new key pair’), and the time to sign a new query, ‘sign query’.

5 Future work We have demonstrated the feasibility of our approach with our current experimental arrangement. Our next step is to support alternative methods for acquiring authorization certificates at the cashier point, and to further enhance the security of the solution. We are investigating the feasibility of Bluetooth and WLAN for this purpose. In the security area, our intention is to integrate the authorization mechanism with packet level security mechanisms in such a way that all the traffic between the customer and the wireless access point would be cryptographically protected.

5.1

Alternative access methods

Bluetooth [28] is a short range radio access technology originally aimed to replace cables between portable devices such as cell phones and PDAs. When compared with IrDA, Bluetooth or WLAN would increase usability since they do not require a direct line of sight, and thereby make it easier to handle the device that communicates with the cashier point. On the other hand, since they do not require a line of sight, optical blocks or similar feasible physical solutions (a Faraday cage would not be feasible) cannot be used to secure the initial transaction. Even though the monetary value of the transactions is relatively small, the risk of communicating with a wrong device, and thereby creating a cer-

tificate for a wrong key, seems to be too high. Thus, some other means of securing the initial transaction is needed. Our current ideas include using a small keyboard with which the customers enter their Bluetooth or WLAN PIN code and thus transfer the seed information for initiating the Bluetooth or WLAN security. Second possibility is to use a display at the cashier point for showing some customer specific information that the customer can easily verify. Third possibility is to analyze if the user interface level timing synchronization between the cashier point and the user terminal could be used to create enough assurance for the situation. The difference between Bluetooth and WLAN is that with WLAN it is more difficult to gain assurance about the communication integrity. In practice, the basic reason for this is that WLAN is a shared medium in practice, while Bluetooth is based on the piconet concept, and without specialized radio equipment it is practically impossible to eavesdrop BlueTooth traffic.

5.2

Packet level authentication

We focused to verify the feasibility of XML encoded SPKI certificates for practical access control. Thus, in the current arrangement we use strong cryptography only to verify the user’s access right at the start of a session. After that, access control is simply based on the user’s source IP address. Even if this arrangement may well be secure enough for practical purposes, it has

security problems. Proper access control requires that all the packets must be individually authenticated. Our intention is to study possibilities for packet level authentication. First, we plan to use the SPKI based authorization protocol to create a session key. This session key may then be used to authenticate the individual packets, either by using it with WLAN encryption, or by including an IPsec Authentication Header in each IP packet.

tographic infrastructure. It is more natural to use just one infrastructure in the whole system.

6 Conclusions

On the other hand, if the cafe would like to provide optional services in addition to the Internet access (for example, multiplayer games in the local Intranet), the certificates should contain more content or even allow delegation. Alternatively, of course, complex tokens could be created but it is better to use standard techniques, such as XML, due to existing high quality software.

The results measured with our prototype implementation have demonstrated the applicability of SPKI for providing anonymous Internet access through WLAN. The access rights are authenticated with strong cryptography. In order to provide the full anonymity, new key pairs can be produced separately for each session.

In summary, our system enables authorized ad-hoc service provisioning. This is particularly interesting when related to ad-hoc networks in which mobile devices connect with local communication links, such as infrared links, WLAN or Bluetooth links.

The advantage to the traditional identity certificate based architectures is obvious: the decision whether to grant access to a service is made solely by the service provider. There is no need to deal with an additional party, i.e., a certificate authority (CA). The decentralized authorization eliminates the need for additional transactions with certificate authorities, and thus removes the need to pay for certificates. More generally, we claim that most access control systems should be designed to directly check whether the requesting party is authorized to use a service or not, instead of using some external identifier and additional trusted third parties.

Acknowledgements We would like the use the opportunity to thank the anonymous referees for their valuable comments concerning our paper.

References [1]

[2]

We have demonstrated the use of XML encoded SPKI certificates. The certificate parsing and signature checking is carried out in a time scale fast enough for real life purposes. The access right check over WLAN link was found to be fast enough (~ 0.5 s) to be used in a real application. This is a clear evidence that the XML is feasible for use as a certificate encoding format, and there is no need for cryptic binary encoding formats. We have listed the advantages of easily understandable and widely spread XML encoding.

[3]

In our example case, access control could also be based on simple tokens instead of certificates. In such a scenario the cashier would create a token and submit it to the laptop through IrDA. Then the access controller would check the validity of the token. This approach, albeit simple and very fast to implement, would not provide any security against hostile laptops or hostile access points. In order to prevent any misuse, the laptop and access controller should carry out mutual authentication. This would engage the use of an additional cryp-

[6]

[4]

[5]

[7]

[8]

Wireless Application Protocol standards can be obtained at the home page of Wireless Application Protocol Forum on the World Wide Web, http://www.wapforum.org Davis, P. T., and McGuffin, C. R., Wireless Local Area Networks, New York, McGraw-Hill, 1995. Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., Ylonen, T., SPKI Certificate Theory, Request For Comments 2693, Internet Engineering Task Force, September 1999. Ellison, C, SPKI Requirements, Request For Comments 2692, Internet Engineering Task Force, September 1999. Paajarvi, J., XML Encoding of SPKI Certificates, Internet Draft draft-paajarvi-xml-spki-cert00.txt, work in progress, Internet Engineering Task Force, March 2000. Infrared Data Association standards can be obtained at the organizations home page on the World Wide Web, http://irda.org Kahn, J. M. and Barry, J. R., “Wireless Infrared Communications”, in Proceedings of the IEEE, pp. 265–298, February 1997. Ellison, C. and Schneier B., “Ten Risks of PKI: What You’re not Being Told about Public Key Infrastructure,” Computer Security Journal, vol. XVI, pp. 1-7, 2000.

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

Nikander, P., An architecture for Authorization and Delegation in Distributed Object-Oriented Agent Systems, Doctoral Dissertation, Helsinki University of Technology, Helsinki, Finland, 1999. Blaze, M., Feigenbaum, J. and Lacy, J., “Decentralized Trust Management,” in the Proceedings of IEEE Conference on Security and Privacy, Oakland, CA, May 1996. Blaze, M., Feigenbaum, J., Ioannidis, J., and Keromytis, A., The KeyNote Trust-Management System Version 2, Request For Comments 2704, Internet Engineering Task Force, September 1999. Blaze, M., Feigenbaum, J. and Keromytis, A. D., “KeyNote: Trust Management for Public-Key Infrastructures,” in Security Protocols, International Workshop, Cambridge, England, 1998. Housley, R., Ford, W., Polk, W. and Solo, D., Internet X.509 Public Key Infrastructure, Request For Comments 2459, Internet Engineering Task Force, January 1999. Kortesniemi, Y., Hasu, T. and Sars, J., “A revocation, validation and authentication protocol for SPKI based delegation systems,” in Proceedings of Network and Distributed System Security Symposium (NDSS 2000), 2-4 February 2000, San Diego, California. Gong, L., Inside Java 2 Platform Security: Architecture, API Design, and Implementation, Addison-Wesley, 1999. Lehti, I., Nikander, P., “Certifying Trust,” in Public Key Cryptography — First International Workshop on the Practise and Theory in Public Key Cryptography PKC’98, Pasifico Yokohama, Japan, February 1998, LNCS 1431, pp. 83-98, Springer-Verlag, March 1998. T. Bray, J. Paoli, C. M. Sperberg-McQueen, Extensible Markup Language (XML) 1.0, W3C Recommendation, 10 February 1998, http://www.w3.org/TR/1998/RECxml-19980210.html. Maryama, H., Tamura, K. and Uramoto, N., XML and Java, Developing Web Applications, Addison-Wesley, USA, 1999. Information on Palm Computers can be found for example on the World Wide Web, http://www.palm.com/ Vidur Apparao et al., Document Object Model (DOM) Level 1 Specification version 1.0, W3C Recommendation, 1 October 1998, http: //www.w3.org/TR/REC-DOM-Level-1

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

Megginson, D., SAX 1.0: The simple API for XML, USA, 1998, available on the World Wide Web, http://www.megginson.com/ SAX/index.html. This opinion is based on our discussions with Winchel Vincent III, Georgia State University, J. Mack Robinson College of Business and College of Law, 2000. Eastlake, D. et al., XML-Signature core syntax and processing, Internet Draft draft-ietf-xmldsigcore-04.txt, work in progress, Internet Engineering Task Force, February 2000. Rivest, R., The MD5 Message-Digest Algorithm, Request For Comments 1321, Internet Engineering Task Force, April 1992. Nikander, P. and Partanen, J., “Distributed Policy management for JDK 1.2,” Proceedings of the 1999 Network and Systems Security Symposium, San Diego, CA 4-6 February, pp. 91–102, Internet Society, February 1999. Partanen, J., Using SPKI Certificates for Access Control in Java 1.2, Master’s Thesis, Helsinki University of Technology, August 1998. U.S. Department of Commerce, National Institute of Standards and Technology, Secure Hash Standard, FIPS PUB 180–1, available on the World Wide Web, http://csrc.nist.gov /fips/fip180-1.pdf Bluetooth SIG, available on the World Wide Web, http://www.bluetooth.com/