Secure Jini Services in Ad Hoc Networks
Secure Jini Services in Ad Hoc Networks
Fredrik Andersson and Magnus Karlsson
Stockholm, 2000
Master of Science Thesis
Royal Institute of Technology (KTH)
______
Supervisor Examinator
Christian Gehrmann Björn Pehrsson
Communication Security Lab Department of Teleinformatics
Ericsson Researce
1
1
Abstract
Providing secure services in Ad Hoc networks is an important issue. Ad Hoc networks can in the near future, be created by using the Bluetooth technology. Due to the lack of security in today's applications, there is a lot of work to be done to secure Ad Hoc applications. In this work, secure Ad Hoc applications will be discussed. As well as how and where to implement security, in an Ad Hoc application.
Jini, which is written in Java, and its service "lookup" will be used as the basic programming technology.
1
Table of Contents
Abstract I
Preface VII
1Introduction......
2Bluetooth......
2.1Introduction......
2.2Background......
2.3Radio Interface......
2.4Physical Link......
2.5Interference......
2.6Networking......
2.7Scatternet......
2.8Summary......
3Service Discovery Protocol......
3.1Introduction......
3.1.1What is a service discovery protocol?......
3.1.2Passive and active services......
3.1.3Service Discovery Protocol in pre-configured networks......
3.1.4Service Discovery Protocol in Ad Hoc networks......
3.1.5What does a service discovery protocol need to provide?......
3.2Bluetooth Service Discovery Protocol......
3.2.1Service Discovery Protocol......
3.2.2How SDP works......
3.2.3Advantages and disadvantages......
3.2.4Built-in security......
3.3Service Location Protocol......
3.3.1Service Location Protocol......
3.3.2How SLP works......
3.3.3Advantages and disadvantages with SLP......
3.3.4Requirements......
3.3.5Built in security......
3.4Universal Plug and Play......
3.4.1Universal Plug and Play......
3.4.2How UPnP works......
3.4.3Advantages and disadvantages......
3.4.4Requirements......
3.4.5Built in security......
3.5Jini......
3.5.1Jini......
3.5.2How Jini works......
3.5.3Advantages and disadvantages......
3.5.4Requirements......
3.5.5Built in security......
3.6Summary......
4Communication Security......
4.1Introduction......
4.2Fundamentals of Layered Protocol Architectures......
4.2.1OSI Reference Model......
4.2.2The Transmission Control Protocol and the Internet Protocol (TCP/IP)......
4.3Where should Security be implemented?......
4.3.1Link Level Security......
4.3.2Network Level Security......
4.3.3End System Level Security......
4.3.4Application Level Security......
4.3.5Summary......
4.4Summary......
5Cryptographic Techniques......
5.1Introduction......
5.2Fundamental Encryption......
5.3Symmetric Encryption......
5.3.1DES, Data Encryption Standard......
5.4Asymmetric Encryption......
5.4.1Public-Key Cryptography Standards (PKCS)......
5.4.2Public-Key Cryptography......
5.4.3The PKCS standards......
5.5Hybrid Techniques......
5.6Message Digest......
5.7Signature......
5.8Certificate......
5.9Certification Revocation List (CRL)......
5.10Encoding Rules in X.509, PKRC, ASN.1 and BER......
5.11Key-Agreement......
5.11.1Diffie-Hellman......
5.12Summary......
6Java 2 Security......
6.1Introduction......
6.2The old Java Sandbox Model......
6.3The Java 2 Sandbox Model......
6.3.1Overview of the Protection Mechanism......
6.3.2Permission......
6.3.3The Java Policy......
6.3.4Access Control Mechanism......
6.3.5Secure Class Loading......
6.4Summary......
7The Jini-proxymodel......
7.1Introduction......
7.2The Jini-proxymodel......
7.2.1The service......
7.2.2The client......
7.2.3The Lookup Server......
7.3Summary......
8Our Security Solution......
8.1Introduction......
8.2The Service Implementation......
8.2.1Introduction......
8.2.2Security......
8.2.3Step 0 and 1: Authentication of the service......
8.2.4Fingerprint (Used in step 5 and 6)......
8.2.5Step 6: Authenticated Diffie-Hellman key exchange algorithm......
8.2.6Step 7: The Fileserver’s authentication of the client......
8.3The Client Implementation and the Key and Fingerprint Management......
8.3.1Introduction......
8.3.2Step 5: Authentication......
8.3.3Step 6: The Master Key......
8.3.4The Key and Fingerprint Management......
8.4Alternative Ways to Implement our Security-Model......
8.4.1Dynamically update the Policy File......
8.4.2Explicitly Verify Signature......
8.4.3Security Flaw......
8.5Summary......
8.5.1Constructions demands......
8.5.2Easy to use......
8.5.3As little overhead as possible......
8.5.4Speed considerations......
9Conclusion......
10Future Work......
Appendix A: The File Interface......
Appendix B: The file packet......
Appendix C: Classdiagram......
Appendix D: The Client’s GUI......
Appendix E: Installing and Running the Service......
E.1 Preparation......
E.1.1 Client Preparation......
E.1.2 Lookup Server Preparation......
E.1.3 Server Preparation......
E.2 Starting the application......
E.3 Useful Bat-File......
E.4 Useful Links......
Appendix F: Dictionary......
Referens:......
1
Preface
This report is the result of our Master of Science thesis done at Ericsson Research, Communication Security Lab in Kista, under supervision by the department of Teleinformatics at the Royal Institute of Technology in Stockholm.
During a presentation of the Bluetooth project at the Royal Institute of Technology we became interested in the Bluetooth technology and what made us really hooked up, was that it involved Java programming. We both felt that after four years of studying, it would be nice to do a practical Master of Science work and not a theoretical one.
We would like to thank: professor Björn Pehrson at the Royal Institute of Technology for his supervision in our master of science work and Christian Gehrmann at Communication Security Lab for his belief and encouragement in our work. Others we would like to thank is Annika Johansson for arousing our interest in this field.
Magnus KarlssonFredrik Andersson
Stockholm, February 2000
1
1Introduction
To share services in open networks, such as Ad Hoc networks, some service discovery protocol can be used. An example of an Ad Hoc network technology is the Bluetooth technology, which is described in the first part of the report. Some of the available service discovery protocols are described as well. When using services in open networks, security issues arise. The service user must be able to use a service, knowing that the service can not do anything. These kinds of problems are not yet solved in the current versions of any of the available service discovery protocols.
As service discovery protocol we used Jini and implemented a simple service. Our solution is described in the second part of the report. Jini is built in Java and has no built in security. Hence, to be able to create secure Jini services, some additional programming considerations have to be taken into account. We need to design both the service provider and the service user correctly. To be able to describe the existing security problem and solutions to these problems, a simple fileserver was implemented. Examples of security problems connected to our application are:
- Authentication, how to make sure that a person is who he claims to be.
- Communication privacy, how to protect data from being visible to other users while transferred between the service user and the service provider in open networks, such as the Internet.
- Communication reliability. How to make sure that data has not been changed during transfer.
- Key management, how to transfer secret keys used to provide the security without showing them to others.
These security issues are discussed and solutions of the problems are given in part II of the report.
The Thesis is organised as follows:
In part I the background is given which is needed to be able to present our solution.
In part II our solution of how to secure a Jini service is presented.
In part III conclusions and future work is discussed.
1
2Bluetooth
2.1Introduction
The Bluetooth technology enables devices equipped with Bluetooth interfaces to in short range and wireless connect with each other and form an Ad Hoc network [1]. Each unit can simultaneously communicate with up to seven other units per piconet, i.e. a small network that only contains seven members. A unit can also belong to other piconets.
2.2Background
The idea of Bluetooth was born in the Ericsson Mobile Communications AB in Lund 1994. The goal was to find a cheap, small and power-efficient radio chip that could create a micro-scale web between mobile phones and their accessories. At that time, the only known and developed technique was infrared links (IrDA), but IrDA have many drawbacks in contrast to radio technique.
- Limited range (approximately one or two meters).
- Require direct line-of-sight.
- Can in principle, only be used between two devices.
Another criteria to make this product widespread, was to make it compatible with as many other electronic devices as possible. Therefore, a special interest group was put together. Its purpose was to urge other electronic manufacturers to support Bluetooth standard and establish a de facto standard for the air interface and the software that controls it.
2.3Radio Interface
The initial requirements that was defined for the Bluetooth interface were:
- It must operate world-wide.
- The connection must support voice and data.
- The radio transceiver must be small and run on low power.
To be able to operate world-wide the frequency band must be license-free and open to any radio system. The only frequency band that satisfies these requirements is the 2.45 GHz band or the Industrial-Scientific-Medical (ISM) band.
2.4Physical Link
There are two types of physical links defined, which support multimedia applications:
- Synchronous connection-oriented (SCO) link
- Asynchronous connectionless (ACL) link
When transmitting voice, the SCO link is typically used. SCO supports symmetrical, circuit-switched, point-to-point connections.
ACL link handles typically peak-flow transmission and supports symmetrical or asymmetrical, packet-switched, point-to-multipoint connections.
2.5Interference
When choosing an open frequency band, the radio systems must cope with several uncontrolled sources of interference. The following optimisations have been done to prevent those sources of interference:
- Frequencies hopping with high hopping rate and short packet lengths.
- Forward error code.
- Using automatic-retransmission-query (ARQ) to achieve short delays and shorten transmission ratio, i.e. if an error is detected the receiver at once indicates that in the next packet.
- Never retransmit voice. Instead, a robust voice-encoding scheme is used.
2.6Networking
When two Bluetooth devices are within range, they can set up an Ad Hoc connection. To set up a piconet, one of the Bluetooth devices has to take the role as master. The master role is to control the traffic in the piconet. To achieve that, every piconet user uses the master built-in clock and the master’s identity to keep track of hopping. The master also allocates capacity for SCO links by reserving slots. For ACL links, they use a polling scheme. The polling scheme states, that a slave only is allowed to send in the slave-to-master slot, when the slave is addressed with the MAC address in the slot header. This also eliminates collision between slave transmissions.
2.7Scatternet
As discussed above, units within range can establish Ad Hoc connections between them. If one member of this newly created piconet also belongs to another piconet an overlapping pattern will occur. If all members of the two piconets share the same hop-channel that will result in a drastically decrease of throughput in the network. Therefore, another solution was adopted – scatternet. This solution simply states that only devices that wants to communicate with other piconet members should be using the same hop channel. In spite of this approach collision do occur, because the piconets hop independently.
2.8Summary
Bluetooth is an uprising technology that has all the qualities to become a leading product. Today only one Bluetooth product exists and that product only support point-to-point connection, but a point-to-multipoint connection is under development and will soon be presented.
1
3Service Discovery Protocol
3.1Introduction
Today exist different applications that discover a service in a network. We have chosen to discuss four of the most promising solutions. The first is the Bluetooth Service Discovery Protocol (SDP) which hardware background was discussed in the previous section. Thereafter, three software approaches will be discussed.
3.1.1What is a service discovery protocol?
A service discovery protocol is used to find different services within a network. A service can be a device offering some kind of work to be performed. It could for example be a printer offering the service to print pages or it could be a file-server offering storage of files. A service can be nearly anything offered within a network.
3.1.2Passive and active services
You could say that there are three different types of services. A service can offer some kind of work or it can provide you with information. The third kind of service can even allow changing of states in a device, such as switching on and off a lamp.
3.1.3Service Discovery Protocol in pre-configured networks
Service discovery can be very useful in pre-configured networks, such as LANs. The service discovery can be used to find for example printers in the network, without the need of any pre-configuration of the computer or the printer. Other shared resources, such as CD and DVD-exchangers can easily be shared between users within the network. The idea with a discovery protocols is that there is not any need to management of new devices added to the network. Therefore, a device can easily be moved from one network to another, without the need of re-configuration. An example of this is a company’s projector, used for presentations at the home office, but also at different customer offices.
The possibility to be able to access the company’s file-server from a laptop without any pre-configuration could be of big interest for travellers. With use of a discovery protocol, such services can easily be built into the network.
3.1.4Service Discovery Protocol in Ad Hoc networks
Ad Hoc networks are networks that are not pre configured and where devices are added and removed now and then. In these temporary networks, resources (services and clients) can appear as fast as they can disappear. In these networks, service discovery methods can be of big help. A discovery protocol gives, for example, a user the possibility to print on the closest printer wherever he might be in the world. It might be at a place he has never been before, and at a printer-model he has never seen. With use of a discovery protocol he can use any printer-model. The service discovery protocol will make sure it works. In Ad Hoc networks, discovery protocols can make devices available to users without pre-configuration. Furthermore, the management of the networks will drastically decrease the use of a discovery protocol. As the world is getting wireless, the discovery protocol is one solution to solve some of the new arising network configuration problems.
3.1.5What does a service discovery protocol need to provide?
A discovery protocol must provide the ability to share services between devices. Some kind discovery message is usually used to maintain the sharing. To be able to share services without overloading the network with announcement- and discovery-messages, commonly some kind of centralised service-server is used. This will reduce the traffic in the network and allow an administrator to manage the services if preferred. In the following section a deeper description will be given of a few discovery protocols and the security will be examined in each discovery protocol. Finally, a summary will be given where the different protocols will be compared with each other. The following Service Discovery Protocol will be examined:
- Bluetooth Service Discovery Protocol, SDP
- Simple Lookup Protocol, SLP
- Universal Plug and Play, UPnP
- Jini
3.2Bluetooth Service Discovery Protocol
3.2.1Service Discovery Protocol
Bluetooth is a wireless connection device, which is using radio waves to connect different devices. To be able to connect different Bluetooth devices, it has a built in discovery protocol, the Bluetooth Service Discovery Protocol (SDP) [2]. SDP addresses service discovery specifically for the Bluetooth environment. It is designed to find services available from or through Bluetooth devices. SDP does not define any method for accessing the services. To be able to access the devices, other service discovery methods such as Jini, UPnP or SLP can be used. While SDP can coexist with these other service discovery protocols, it does not require them. Other ways to access the service might also be used depending on the service. In Bluetooth environments, found services can be accessed using other Bluetooth specific protocols.
3.2.2How SDP works
SDP can be used to find devices without the need of any other service discovery protocols. SDP can for example be used to establish a connection to a remote Bluetooth device [3]. When this is done, the connection is established at the L2CAP-layer, se figure 3.1. The SDP protocol does not have any mechanism for how to utilise the service, such as delivering the service access protocols.
Figure 3.1The Bluetooth protocol stack [3].
SDP servers maintain a database with information about existing services within the Bluetooth network. The server also responds to request on an existing connection. SDP clients can search for services in a specific class or for a specific service. Clients can also provide the ability to browse available services. A SDP service is any feature usable by another device. Services can be searched for as a specific class of services or it can be searched for from browsers.
3.2.3Advantages and disadvantages
Here follows a short summary of some advantages and disadvantages with SDP.
+Fast and hardware cheap.
-Works only between Bluetooth devices.
3.2.4Built-in security
SDP does not care about security. It does only allow devices to locate other devices within the Bluetooth environment.
3.3Service Location Protocol
3.3.1Service Location Protocol
SLP is defined by IETF in RFC 2165 [4]. The Service Location Protocol was constructed to provide a scalable framework for discovery and selection of network services. When devices use this protocol, the requirements on static configured networks decrease. Or as they describes it in the RFC “Using the protocol, computers using the Internet no longer need so much static configuration of network services for network based applications.” [4] This is, as described in the RFC, very important as computers are becoming more and more portable and in the same turn, the network management has to decrease.
3.3.2How SLP works
Usually a user finds a service by a host name (a URL) which is an alias for the network address [4]. This is not a convenient way to find services in a network when the computer doesn’t know where they are located, or maybe not even know which services are present in the current network. The Service Location Protocol eliminates the need for a user to know even these basic things. Instead, the user asks the network for a service by its name and/or some attributes to describe the service. The Service Location Protocol then allows a binding of the description to the network address of the service.
The Service Location Protocol is built to work in local area networks. It is not a global resolution system for services within the entire Internet. All hosts within the multicast radius will be reached when searching for new services. The multicast radius is the same as the TTL (Time To Live) in the multicast advertisement. The default multicast-radius is set to 32. If a site does not support multicast, the request is restricted to that local subnetwork.
The SLP consists of three parties, the User Agent, the Service Agent and the Directory Agent. The User Agent is a process that is working on behalf of the user to receive service attributes and configuration from Service Agents or Directory Agents. A Service Agent is a process that is working on behalf of one or more services to advertise service attributes and configuration of the services. Directory Agents are processes that collect information from different Service Agents to be able to provide a single answer to requests from User Agents. It is used to centralise the information for efficient user access.