Sunteți pe pagina 1din 74

School of Mathematics and Systems Engineering Reports from MSI - Rapporter frn MSI

PKI Solution for Mobile Systems

Christian Hammarstedt Jonas Stewn

Juni 2001

MSI Vxj University SE-351 95 VXJ

Report 01070 ISSN 1650-2647 ISRN VXU/MSI/DA/E/--01070/--SE

Abstract
This thesis was made in collaboration with AerotechTelub Communications. AerotechTelub is a service company which offers qualified technical services and customer-adapted system solutions within information technology, electronics and aviation technology for military and civil defence, government departments and public authorities as well as selected sectors of trade and industry. The role of the Communications department is to specify, design, project, install and maintain communication systems. They do that from a supplier-independent position and with the intention of creating a function-adapted and reliable system through long-term co-operation with their customers. The purpose of this thesis is to explore the possibilities of a mobile wireless PKI. AerotechTelub Communications wanted us to explore if there was a possibility to create a secure mobile ad-hoc network with today's existing technology. We had to see if we could get mobile telephones, pocket PC's and radio to be able to communicate with each other in a secure way. This report is also intended as a tool and a help, if our ideas are implemented. To be able to solve this problem we had to understand the underlying technology. We have in this thesis studied the technology behind PKI, mostly the areas of CA, X.500 and X.509. We have also studied the WTLS layer of WAP and the digital radio technology called TETRA. Another important part was to see if any other companies have tried to solve the same problem or had solutions similar to what we was trying to accomplish. For this reason we studied two of the largest companies in the business, RSA Security and Baltimore Technologies. After studying the underlying technology and other wireless PKI solutions we had the knowledge to make a suggestion of what we could offer towards a solution.

Preface
This Masters thesis has been carried out at AerotechTelub, Communications in Vxj from March 2001 to June 2001. This thesis is the final part of our Masters Degree in Computer Science at Vxj University. AerotechTelub Communications wanted to see if it was possible to realise a mobile ad-hoc network with existing technology. Our goal with this thesis is to see what possibilities there are to realise this problem This report is also intended as a tool and a help if a our ideas are implemented. We would like to thank the following people for their help and support. Ulf Cederling, Supervisor at Vxj University Anders Strand, Supervisor AerotechTelub Communications In addition we want to thank the people at AerotechTelub who made this thesis possible.

Contents
FIGURE INDEX.................................................................................................................................................... 6 ABBREVIATIONS................................................................................................................................................ 7 1 INTRODUCTION ............................................................................................................................................ 10 1.1 BACKGROUND .............................................................................................................................................. 10 1.2 PROBLEM DISCUSSION .................................................................................................................................. 10 1.3 DEFINITION OF THE PROBLEM ....................................................................................................................... 11 1.4 LIMITATIONS ................................................................................................................................................ 11 1.5 PURPOSE AND OBJECTIVE ............................................................................................................................. 11 1.6 THE CONTENT OF THE REPORT ...................................................................................................................... 11 2. METHOD......................................................................................................................................................... 12 2.1 POSSIBLE METHODS ...................................................................................................................................... 12 2.1.1 Conceptual-analytical approach .......................................................................................................... 12 2.1.2 Theory-testing approach....................................................................................................................... 12 2.1.3 Theory-creating approach .................................................................................................................... 13 2.1.4 Artifacts-building approach.................................................................................................................. 13 2.1.5 Artifacts-evaluating approach .............................................................................................................. 13 2.1.6 Mathematical approach........................................................................................................................ 13 2.2 MOST SUITABLE METHODS ........................................................................................................................... 13 2.2.1 Artifacts-building approach.................................................................................................................. 14 2.2.2 Theory-testing approach....................................................................................................................... 15 2.3 OUR CHOICE OF METHOD .............................................................................................................................. 16 3. PRESENTATION OF AEROTECHTELUB, COMMUNICATIONS ....................................................... 17 3.1 AEROTECHTELUB ......................................................................................................................................... 17 3.2 COMMUNICATIONS ....................................................................................................................................... 18 4. PKI OVERVIEW ......................................................................................................................................... 19 4.1 CA ............................................................................................................................................................... 19 4.2 X.500 ........................................................................................................................................................... 21 4.2.1 Information model. ............................................................................................................................... 21 4.2.2 Namespace............................................................................................................................................ 22 4.2.3 Functional model.................................................................................................................................. 22 4.2.4 Authentication framework .................................................................................................................... 23 4.2.5 Distributed operation model................................................................................................................. 24 4.3 X.509 ........................................................................................................................................................... 25 4.3.1 Overview............................................................................................................................................... 25 4.3.2 Certificate structure.............................................................................................................................. 25 4.3.3 Authentication procedures.................................................................................................................... 28 5. TECHNOLOGY .............................................................................................................................................. 29 5.1 TERRESTRIAL TRUNKED RADIO ................................................................................................................... 29 5.1.1 Overview............................................................................................................................................... 29 5.1.2 TDMA ................................................................................................................................................... 31 5.1.3 SDS ....................................................................................................................................................... 32 5.1.4 TETRA SIM........................................................................................................................................... 33 5.1.5 TETRA IP.............................................................................................................................................. 34 5.1.6 Security in a TETRA network ............................................................................................................... 35 5.2 WTLS .......................................................................................................................................................... 37 5.2.1 Overview............................................................................................................................................... 37 5.2.2 Record protocol .................................................................................................................................... 38 5.2.3 Alert Protocol ....................................................................................................................................... 39 5.2.4 Change Cipher Spec Protocol .............................................................................................................. 39 5.2.5 Handshake Protocol ............................................................................................................................. 39

5.3 WTLS CLASSES............................................................................................................................................ 42 6. ANALYSIS OF MOBILE PKI PRODUCTS ................................................................................................ 43 6.1 BALTIMORE, TELEPATHY ............................................................................................................................. 43 6.1.1 Company information ........................................................................................................................... 43 6.1.2 Product information ............................................................................................................................. 44 6.1.3 Telepathy WST...................................................................................................................................... 45 6.1.4 Telepathy WAP PKI Digital Signature Toolkit (PDST)........................................................................ 46 6.1.5 Telepathy WAP Certificate Authority (WAC) ....................................................................................... 47 6.1.6 Telepathy WAP PKI Registration System (PRS)................................................................................... 47 6.1.7 Telepathy WAP PKI Validation System (TVS)...................................................................................... 50 6.2 RSA SECURITY, BSAFE .............................................................................................................................. 51 6.2.1 Company information ........................................................................................................................... 51 6.2.2 Product information ............................................................................................................................. 52 6.2.3 RSA BSAFE WTLS-C............................................................................................................................ 53 6.2.4 BSAFE SSL-C and SSL-J...................................................................................................................... 55 6.2.5 RSA BSAFE Crypto-C and Crypto-J .................................................................................................... 57 6.3 SUMMARY OF THE PRODUCT EVALUATION ................................................................................................... 59 7. SOLUTION ...................................................................................................................................................... 60 7.1 OVERVIEW ................................................................................................................................................... 60 7.2 COMMUNICATION CENTRAL ......................................................................................................................... 61 7.3 HEADQUARTERS ........................................................................................................................................... 62 7.4 MOBILE DEVICES .......................................................................................................................................... 62 7.4.1 PDA to PDA ......................................................................................................................................... 62 7.4.2 TETRA to TETRA ................................................................................................................................. 63 7.4.3 TETRA to PDA ..................................................................................................................................... 65 7.4.4 Outbound communication..................................................................................................................... 66 7.5 DEVELOPING THE SYSTEM ............................................................................................................................ 68 7.6 SECURITY AND THREATS .............................................................................................................................. 68 8. CONCLUSION ................................................................................................................................................ 70 8.1 SUMMARY .................................................................................................................................................... 70 8.2 FUTURE EXPECTATIONS ................................................................................................................................ 70 8.2.1 Network ................................................................................................................................................ 70 8.2.2 Mobile phones ...................................................................................................................................... 70 8.2.3 Authentication....................................................................................................................................... 71 8.3 REFLECTIONS ............................................................................................................................................... 71 REFERENCES .................................................................................................................................................... 72

Figure index
Figure 2.1 Figure 4.1.1 Figure 4.1.2 Figure 4.2.1 Figure 4.2.2 Figure 4.2.3 Figure 4.2.4 Figure 4.2.5 Figure 4.3.1 Figure 5.1.1 Figure 5.1.2 Figure 5.1.3 Figure 5.1.4 Figure 5.1.5 Figure 5.2.1 Figure 5.2.2 Figure 5.2.3 Figure 5.2.4 Figure 5.2.5 Figure 5.2.6 Figure 5.2.7 Figure 5.2.8 Figure 6.1.1 Figure 6.1.2 Figure 6.1.3 Figure 6.1.4 Figure 6.2.1 Figure 6.2.2 Figure 6.2.3 Figure 7.1 Figure 7.2 Jrvinens classes of research methods Hierarchical structure Cross-certification structure Directory Information Base and Directory Information Tree Namespace Password authentication Signature authentication X.500: DSA and DUA X.509 Certificate TETRA network schematic TETRAs positioning of technology TETRAs data services TETRA PEI TETRA IP network schematic WAP Layers WTLS cryptographic algorithms WTLS architecture States in WTLS Full handshake Abbreviated handshake Optimized handshake WTLS classes WST architecture WAC architecture PRS architecture SAT in PRS RSA BSAFE WTLS-C functional layers RSA BSAFE SSL-C and SSL-J functional layers RSA BSAFE Crypto-C and Crypto-J functional layers Our solution Outbound communication 12 20 20 21 22 23 23 24 25 29 30 31 32 35 37 37 38 38 40 42 42 42 46 47 48 49 54 55 58 60 67

Abbreviations
3DEA ACELP AKM ANSI AuC AVL BHAPI BPS CA CAO CAI CONP CP CPS CRL DAP DECT DES DF DFEC DIB DIIS DIT DN DNS DSA DUA ECC ETSI GPRS GSM IDEA IETF IP IP context ISDN ISI ISO ITSI ITU LDAP MAC MCCH MD2-5 MoU NMI OCSP OMT Triple DES Algebraic-Code-Excited Linear Prediction Authentication Key Management American National Standards Institute Authentication Centre Automatic Vehicle Location BSAFE Hardware API Bits Per Second Certification Authority CA Operator Common Air Interface Connection Oriented Network Protocol Certificate Policy Certification Practice Statement Certificate Revocation List Directory Access Protocol Digital European Cordless Telephone Data Encryption Standard Diffie-Hellman Diffie-Hellman Elliptic Curve Directory Information Base Director, Information and Identification Services Directory Information Tree Distinguished Name Domain Name System Directory System Agent Directory User Agent Elliptic Curve Cryptography European Telecommunication Standardisation Institute General Packet Radio Services Global System for Mobile communication International Data Encryption Algorithm Internet Engineering Task Force Internet Protocol Association between IP address and TETRA identity (ITSI). Integrated Services Digital Network Inter-system interface International Organisation for Standardisation Individual TETRA Subscriber Identity International Telecommunications Union Lightweight Directory Access Protocol Message Authentication Code Main control channel. Message Digest Algorithms Memorandum of Understanding Network Management Interface On-line Certificate Status Protocol Orthogonal-mode Transducer 7

OSI PABX PEI PMR PAMR PDA PDCH PDN PDO PIN PKI PKIX PKCS PKCS #1 PKCS #7 PKCS #8 PKCS #10 PKCS #11 PKCS #12 POI POP PPP PSTN PVC RA RAO RC1-6 RDN RF RPE-LPC RSA S-CLNP SAT SDK SDS SDU SHA-1 SIM SMS SSL TCP TDMA TETRA TNP1 TLS TTP UDP UMTS/3G URL

Open System Interconnection Private Automatic Branch Exchange Peripheral Equipment Interface Private/Professional Mobile Radio Public Access Mobile Radio Personal Digital Assistant Physical data channel. Private Data Network Packet Data Optimised Personal Identification Number Public Key Infrastructure Public Key Infrastructure for X.509 Public Key Cryptography Standards RSA Cryptography Standard Cryptographic Message Syntax Standard Private-Key Information Syntax Standard Certification Request Syntax Standard Cryptographic Token Interface Standard Personal Information Exchange Syntax Standard Proof of Identity Proof of Possession Point-to Point protocol Public Switched Telephone Network Permanent Virtual Circuit Registration Authority RA Operator Symmetric encryption algorithms Relative Distinguished Name Radio Frequency Regular Pulse Excited - Linear Predictive Coder with a Long Term Predictor Loop Rivest, Shamir och Adelman, Asymmetric cryptography method Specific Connection Less Network Protocol SIM Application Kit Software Developer Kit Short Data Service Service Data Unit Secure Hash Function Subscriber Identity Module Short Message Service Secure Sockets Layer Transmission Control Protocol Time Division Multiple Access Terrestrial Trunked Radio Tetra Network Protocol 1 Transport Layer Security Trusted Third Party User Datagram Protocol Universal Mobile Telecommunications System / 3rd Generation Uniform Resource Locator

V+D VC VPN WAP WIM WML WTLS X.25 X.500 X.509 X9.68

Voice plus Data Virtual Circuit Virtual Private Network Wireless Application Protocol Wireless Identity Module Wireless Markup Language Wireless Transport Layer Security Network protocol defined in OSI International standard for electronic online directory services Standard for defining digital certificates Certificate capable of handling DFEC

1 Introduction
This masters thesis in computer science was done for AerotechTelub, Communications in Vxj The thesis is made by Jonas Stewn and Christian Hammarstedt and has lasted twenty man weeks during the spring of 2001. The thesis was made in collaboration between AerotechTelub Communications and Vxj University.

1.1 Background
This all started when we saw the ad for this project. We set up a meeting with AerotechTelub Communications where we discussed what the thesis should concentrate on and what was most important. After this meeting both parties agreed on which terms the thesis would be carried out. AerotechTelub Communications had a need to find out if mobile PKI communication was possible with existing technology and we were curious if this would really work.

1.2 Problem discussion


Our thesis is called PKI solution for mobile systems. The problems we are faced with are: How can we construct an ad-hoc mobile network with a public key infrastructure without changing the current equipment, such as mobile phones, PDA and TETRA radio handsets. How can we get all of these different technologies interacting with authentication and encryption of messages, with todays current technology? A PKI enables users of basically unsecured public networks, such as the Internet, to securely and privately exchange data through the use of a public and a private cryptographic key pair that are obtained and shared through a trusted authority. The public key infrastructure provides for a digital certificate that can identify an individual or organisation. Also a directory service that can store and, when necessary, revoke the certificates. An ad-hoc or spontaneous network is a local area network or other small networks, especially one with wireless or temporary plug-in connections. Some of the network devices are part of the network only for the duration of a communication session or, in the case of mobile or portable devices, while in some close proximity to the rest of the network. Today there is a big demand for both PKI and especially small spontaneous networks. This kind of technique suits our time, since there are a lot of mobile phones and PDAs that could be used to get online in an ad-hoc network. To be able to do this in a secure way the information has to be encrypted and the users need to be authenticated. If a network like this lacks the encryption and authentication, the network will be wide open for anyone and this is not a desired feature when discretion is needed. To make these kinds of networks more secure, a method similar to those used on ordinary computers connected to the Internet could be used. When talking about a certificate on a mobile phone or PDA, it is important that the size of the information sent between the mobile units and the certificate authority is kept to a minimum. This is because a mobile phone or a PDA do not have the same quantity of memory space as available in an ordinary computer. Another reason for keeping the size of the information down, is that the overall transfer rate on mobile units are not as fast as in a regular network. For this to be effective, a way to minimise those parts has to be discussed. A different aspect on this project is that communication has to be possible between different types of mobile units with the same certificate. These units could be mobile phones, PDA, TETRA radio or many others. It is therefore not possible to look at only one of these units and create a requirement specification from those premises. This is why a general requirement specification has to be developed.

10

1.3 Definition of the problem


Is it possible to use PKI in a mobile ad-hoc network using existing technology? Will it be possible to use different mobile units and still be able to communicate within the PKI and if so, how would this solution shape itself? How will the mobile units handle the certificates? What kind of products could be used to aid the development of a solution and a demonstrator? How does the existing techniques work and how can these be used to develop a solution?

1.4 Limitations
We will limit this thesis to exploring the underlying technology of PKI that is needed for the understanding and the creation of a solution. We will also study the basic technology of the mobile units that will be represented in the PKI. We will choose two large companies and study their products in depth. The thesis is intended as a suggestion, not as a complete and definite solution. It is intended to be used as a support if AerotechTelub ever want to realise a mobile wireless PKI.

1.5 Purpose and objective


The purpose of this master thesis is to evaluate the possibilities and give a suggestion on how to realise a mobile PKI network with existing mobile devices. Another objective is to investigate if there are companies with products that can be capable of either presenting a complete solution or being used as a supplement when implementing a solution. The purpose of the complete thesis is intended to function as a helping tool when developing a demonstrator for mobile PKI.

1.6 The content of the report


Chapter 2 This report starts with a method discussion where we describe how our report could look with different method approaches. In the end of this chapter we present the methods we choose and the arguments as to why it was chosen. Chapter 3 In this chapter we give a brief overview of the company we have done this thesis in collaboration with. Chapter 4 With this chapter we explain the basic components of a PKI briefly. We concentrate on the technical aspect of the components CA, X.500 and X.509. Chapter 5 In chapter 5 we describe the technologies that we will use in our solution. Our focus is on the technical possibilities of the technologies. The technologies described are TETRA and WTLS. Chapter 6 Here we investigate what kind of products and solutions are on the market today. Both SDK and complete solutions are described to give us a picture of what the possibilities of using complete products are. The companies we have focused on are Baltimore and RSA Security. Chapter 7 This chapter contains our solution to the problem described in the problem discussion. Included are both theory and real life examples. Chapter 8 Finally we conclude our thesis with summary, future expectations and our own reflections. 11

2. Method
2.1 Possible methods
In this chapter we will discuss what kind of methods are possible to use in our thesis. All methods are taken from [1]. We chose this book as reference because it is written to help computer science students in choosing a method. Below the figure shows the six different research approaches Jrvinen describes.
Research approaches

Approaches studying reality

Mathematical approaches

Researches stressing what reality is

Researches stressing utility of artifacts

Conceptualanalytical approaches

Approaches for empirical studies

Artifactsbuilding approaches

Artifactsevaluating approaches

Theorytesting approaches

Theorycreating approaches

Figure 2.1 Jrvinens classes of research methods [1]

2.1.1 Conceptual-analytical approach


This method tries to answer the question: What is a part of reality according to a certain theory, model or framework? An example can be, which kind of theory, model or framework explains how a user uses a computer? A theory, model or framework can be built by deriving from the theoretical assumptions concerning on the one hand a user and on the other hand a computer, or by generalising from the observations made by researcher and from the results of the previous empirical studies [1]. This method tries to explain how reality is described in a certain theory. The conceptualanalytical theory might not be a suitable method for our thesis. We are not looking to improve an old model of PKI or to improve a theory about it. We want to create a model that will solve the problem that we are set out to do. We have to read and understand the underlying technology of PKI, and try to put that technology to use in another way to fit the wireless world. It is not improving the actual theory of PKI.

2.1.2 Theory-testing approach


This method tries to answer the question: Does a part of reality correspond to a certain theory, model or framework? In more detail, do our experiments, field or case studies confirm or falsify our theory, model or framework [1]? This research method can be used when studying technology behind existing mobile PKI products. It can also be useful when studying standard technology other products are using. By doing this we could se if these theories can be enhanced and used in our solution model.

12

2.1.3 Theory-creating approach


This method tries to answer the question: which kind of theory, model or framework best describes or explains a part of reality? In more detail, as which kind of theories, models or frameworks can we describe and explain our observations from case studies, content analyses, ethnographic, phenomenological, hermeneutic, phenomenographic studies [1]? The theory-creating research method is not a particularly suitable method to use for our thesis. This is because this method is used when there is no prior knowledge of a part of reality or phenomenon. The problem we are trying to solve is mostly based on already existing technology. Therefore we can exclude this research method from our selection.

2.1.4 Artifacts-building approach


This method tries to answer the question: Is it possible to build a certain artifact? It also asks how a certain artifact ought to be built [1]. Artifacts-building research is a possible method for our product since we are trying to build a system capable of mobile PKI. This system is not being implemented since this thesis is theoretical. Despite the lack of implementation we think that the process of creating a solution, even a theoretical one, can be looked upon as a building of an artifact.

2.1.5 Artifacts-evaluating approach


This method tries to answer the question: How useful is a particular artifact? Basically this method tries to determine if an artifact is what is was supposed to be. This method can be used in conjunction with artifacts-building to evaluate the result of that method [1]. Since no implementation is being done in this thesis it will be hard to evaluate the final result with this method. Instead artifact-evaluation can be used when studying finished product and try to find improvements of them. These improvements can then be used when we produce our solution.

2.1.6 Mathematical approach


This method is not suitable in our thesis so there will be no further description of it. The reason is that mathematical research is built on math and the rules that applies in the world of mathematics and these are not possible to follow in our thesis.

2.2 Most suitable methods


In this section the methods that we thought were useful in our thesis will be discussed in more detail. All theories in Jrvinens book have a suggested structure of the report and these will also be discussed. The methods we choose to examine closer are Theory-testing research Artifacts-building research

13

2.2.1 Artifacts-building approach


As mentioned above this method is selected to be examined more closely, despite that it concerns a theoretical product. Artifacts-building and artifact-evaluating are two components of constructive research but since there is no way of evaluate our final solution other than in mind the artifact-evaluation is excluded. Artifacts-building is divided into three states, initial, building and target. When starting an artifacts-building process the initial state is the first one and this is where the target is specified. A target in our thesis could be, to construct a system with mobile PKI in theory. Between the initial and target state is the building state where all the processing takes place. An important feature of the building process in this research method is that there should always be an alternative to reach the target or any sub-target. These two, or more, approaches are then compared to each other and the approach that suits the problem best is chosen. During the building process there will be lots of these comparisons. This approach will work well in our thesis because we will have many alternatives to choose from since there is no standard solution on how to realise it. An example from our problem could be to compare if to use existing antennas or to build and use our own. We think that the more comparisons we will do, the better foundation we will have for our theories When writing a report based upon the artifacts-building there is a specific structure that could be followed. 1. 2. 3. 4. Introduction A potential description of the sub-process for determining the target state Restrictions (physical, human, financial and data resources) The greatest design problem, its solution alternatives and the selected alternative with reasons 5. The next greatest design problem, 6. The description of implementation and a preliminary evaluation 7. Discussion [1] Naturally we want to adopt this structure to our thesis. 1. Introduction 2. Our target was decided through a discussion between us and the company before this report was written. 3. The big restriction we have on our thesis is that existing technology must be used. We are not allowed to propose new phone-specification for instance. 4. In this part we can describe the greatest problems and see what kind of solution we can get from the alternatives. An example of a great problem is how to handle the PKI structure between different devices that can not communicate directly. 5. This will then follow point 4 in structure. 6. Since we will not implement our solution practically we could describe in detail how a system like our problem description need could work. 7. The discussion could contain future possibilities and our reflections on the work. To conclude this chapter it seems to us that the research method could be suitable in our thesis. The result of our decision will be presented in chapter 4.

14

2.2.2 Theory-testing approach


We included this method in our most suitable methods section, because we need to study and evaluate the underlying structures and technology behind PKI, to be able to see if we can develop a theory or a model that can be the base of a solution to the problem our client has given us. As mentioned in the previous chapter the theory-testing research method tries to answer the question: Does a part of reality correspond to a certain theory, model or framework? We will from the start have a certain theory about what would be possible in building a mobile PKI solution with precise restrictions. From this theory we could study technology behind existing mobile PKI solutions and from here try to find a suggestion to a solution. We could also study the standards, which we could use for our new theory. This method is a good way to perform a case study, to learn and understand the problem area better. If we would use this method we could either confirm or falsify our initial theory about mobile PKI. A theory can be tested in a few different ways. We can examine the basic assumptions underlying the theories and then compare with facts from the real world, or the conclusions derived from theories can be tested for their usefulness. In our thesis we will try and test our theory by comparing it to whatever is out on the market, similar to what we are trying to accomplish. There are certain structures that are preferred when one is basing a report on the theorytesting research method. 1. Introduction 2. The theoretical framework, derivation of research hypotheses and consideration of intervening variables. 3. Object under study (observations a sample or population). 4. Gathering the raw data (selection of technique, response rate etc.). 5. Results (elimination of the effects of intervening variables from dependent variables before statistical analyses and tests between independent and dependent variables). 6. Discussion [1] If we where to choose this model we would adopt the previous structure and add our own interpretation of it like this. 1. Introduction 2. The theory with which we started our research. The underlying technological standards and our view of the most important features of the theory behind our problem. 3. Our object under study is the underlying technology of mobile PKI and the different solutions that could exist on the market already. These solutions would be studied thoroughly. 4. This section would in our thesis be connected to the previous. It would involve data and techniques used to be able to in some way solve the problem. 5. The result would be the proposed solution to the initial problem. A small model of how the mobile PKI could be realised with no change in current equipment. 6. In this section we would have a discussion of future possibilities and a short reflection on the work we have done.

15

2.3 Our choice of method


We have decided to use both of the methods described in the previous chapter since they are good at different things. We want to use theory-testing to investigate and learn about existing technologies. Artifacts-building, will be used as the main method in our thesis. The report structure and the process as an entity will come from the artifacts-building theories. Before thinking about any solution we have to study and learn already existing technologies and techniques. In this exploratory process we will use theory-testing since this is the only method we think is useful when it comes to this kind of process. We think this because the main thing about this method is that it asks if something is corresponding to reality and that is what we want to find out when we study different theories and techniques. We can compare different theories and from that draw conclusions about which one that will be best suited in our solution. It is also a good method when studying other companies solutions to understand what kind of techniques they are basing their product on. Also the theory they are using can be investigated and not just issues that relate to techniques. The thesis as an entity will be treated like an artifacts-building process. In [1] there are a number of verbs listed that could be associated if artifacts-building could be used. They are introduce, improve, maintain, cease, extend, correct, adjust and enhance. Of course there are more but we will look at these and se which ones that match our thesis. We think that our thesis match all of these verbs except cease and correct. If we look at what our problem discussion we se that our solution can be an improvement or enhancement of already existing technology. The target in our thesis is a solution of the problems mobile PKI introduces. To take advantage of the theories that we will explore during our theory-testing state we can compare these and make a list of good and bad things about them. In artifacts-building these comparisons are a vital feature in the building process and this could be a suitable approach for us. In conclusion we want to say that these methods we have chosen are the ones that we feel can help us in our process of developing our thesis. There are of course alternatives to these but we feel that the other were to specific to certain processes. We are confident that our choice is going to help us to give our thesis a good foundation in science and structure.

16

3. Presentation of AerotechTelub, Communications


The following is taken from documents about AerotecTelub and the division Communications

3.1 AerotechTelub
When AerotechTelub was founded in the autumn of 1999 through the merger of Celsius Aerotech and parts of TietoEnator, a powerful technical service company was formed whose key areas of activity are aviation, command, information processing, communications and sensors. Our expertise includes technical and integration services, operations and maintenance along with systems deliveries within areas such as test, simulation, traffic control and telecommunications. The highly skilled technical services we offer have developed as a result of a long history. As far back as the beginning of the 1900s when the Swedish Air Force was established, the need was recognised for the provision of effective and functional maintenance. By then the foundations were laid for our professional relationship with the Air Force. At the same time we have learnt what it means to be third-party suppliers a knowledge that is today valued by our clients, who are both users and suppliers of different systems. The businesses in Celsius and TietoEnator that have been brought together in AerotechTelub provide services and solutions that are relevant to the Swedish defence, and public sectors as well as selective niches within trade and industry. We are one of the participants in the creation of the new, modern and forward thinking defence, which is building on advances in information technology. Historically the militarys needs have enforced the technical development, with everything from telephones to aircraft and computers. But today the development is rather driven by the market forces in society. Here our customers are public authorities with responsibility for establishing social infrastructures for information technology, communication and transport, that is road, rail and air. The suppliers are also our customers within the same areas. Our broad range of services within telecommunications and test means that we are of great interest to manufacturers of systems and products within information technology and telecommunications. The expertise we offer in information security, measuring technique and computer service addresses many markets. From the military assignments we have acquired the specialist skill to guarantee function and cost-effectiveness during a systems entire lifetime. To us guaranteeing technical systems incorporates further development, integration and maintenance. The highly qualified technical services we offer make us a powerful and long-term partner for both systems owners and systems suppliers. Our size, experience and breadth of knowledge give us the capability to grow together with our customers, both nationally and internationally. AerotechTelub has 2,800 employees and a turnover of approximately SEK 2,4 billion [2].

17

3.2 Communications
Communications form a part of AerotechTelub - a leading knowledge-based company. We are about 270 qualified employees who possess the broad and extensive expertise that is essential to make effective communication solutions. You meet us as project managers, technicians, engineers and administrators. Our customers are found within industry, local and government authorities, as well as the Swedish national defence. We are a natural partner for the telecommunications industry and among players within the area of infrastructure such as telecom operators, network builders, and telecom authorities. This also applies to organisations within the civil aviation sector. We are currently involved in the creation of the new Swedish defence system that to a high degree is based on the exchange of information and efficient communications [2].

18

4. PKI Overview
In this section we will briefly explain the components of a PKI. The components we have chosen to explain are CA, X.500 and X.509.

4.1 CA
The CA (Certificate Authority) is the one that can create and issue certificates. The CA can work in different ways. It is possible for the CA to just issue certificates inside an organisation or it can be internet-based and issue certificates for money. The last one is called a Trusted Third Party (TTF) and is not supposed have any interest in the information that is going to be send The TTF must also be able to guarantee that the certificate is genuine. In both cases the receiver of the certificate must send a request with information about the user. If a CA decides to trust a certificate it signs the certificate with the help of its own root certificate. This way anyone can see that the CA trusts this certificate. This is similar to a credit card, where the credit card company is the CA. It is important to protect the CAs certificate since anyone with this certificate can issue and created new certificate and pretend to be the CA. One could say that the CAs trust is in fact its certificate and without it loses all of its trust [3]. When a CA is established a CP (Certificate Policy) is written. The CP is a list that the CA must follow. This list is a requirement specification where legal, economic and technical aspects are stated. In order to know how to uphold the CPs requirements a CPS (Certification Practice Statement) is created. The CP and CPS are both vital components to a CA as they state what the CA can be liable for. There can be many different requirements depending on what kind of certificate that is issued. If a CA breaks its policy it is of course graver if this certificate is identifying a person instead of an email address. These cases must have different policies since different consequences follow any misuse of the certificate [3]. The owner of a certificate is tied to the certificate with a public key. Since this approach is used the CA can keep track of all the certificates. Once the certificate is created the CA stores the public key in a public directory. The directory the certificates are stored in at the CA is of the type X.500/LDAP. The private key for the certificate is stored on the owner of the certificate machine. If a user wants to verify a message or something similar they use the directory with all the public keys to make sure the message came from the person it said it came from. This is of course only true if the CA is trusted. There are other groups that can be interested to verify a message such as applications and other entities using certificates. A big part of the CAs job is to maintain the archive of certificates. This includes too publish Certificate Revocation List (CRL). The CRLs contain information about which certificates have been revoked and therefore not be trusted. As stated in the beginning of this text the function of a CA can be interpreted differently. The most simple approach is that the CA is just issuing and creating certificates. This approach is not very plausible since there are a lot of other function a CA must be able to cope with in order to deliver a good solution to customers. To provide a good service human resources must be used. These resources can give support to customers and maintain the certificates. This is the reason the CA is usually a big organisation [3]. There are in general two different types of structure for a CA. These are called CAhierarchy and cross certification. When the CAs are built up in a hierarchy there must be one root-CA. This is a big problem if its going to be used globally since no country is interested in being subordinate to another countrys CA. This is why this type of CA structure is not widely used [3].

19

Root CA

CA

CA

CA

CA

Figure 4.1.1 Hierarchical structure The cross-certification is a flat structure. It can be looked upon as different hierarchical CA structures where the top node in each hierarchy is connected through each other. This way all the root CAs stands at the same level in the structure. To get this approach to work the different root CAs must carry information about other root CAs [3].

CA1

CA2

CA3

Subordinate CAs

Subordinate CAs

Subordinate CAs

Figure 4.1.2 Cross-certification structure

20

4.2 X.500
The X.500 is an international standard for electronic online directory services created by OSI and ITU. X.500 can be looked upon as a phonebook that contains world-wide information. There is a lot of application that uses this service. Email, phone-number and postal address is examples of what the X.500 could contain. X.500 is defined by 5 its components [4]. Information model The form and the character of the information are defined by this component. Namespace This component allows the information to be referenced and organised. Functional model The operations that can be performed on the information in X.500 are defined in the functional model. Authentication framework To make the information secure this component is used. Distributed operation model How the data is supposed to be distributed and how the operations behave is determined by this component.

4.2.1 Information model.


The complete set of all information held in the Directory is known as the Directory Information Base (DIB). The DIB is centred on entries. The entries hold a number of attributes, which in turn determines the type of the attribute and the attribute values. The value field itself is divided so that it can contain multiple values. Each entry has an object class that defines what kind of type the entry is. For example, if the directory consists of employees then all employees must have a name but not all have a mobile phone. The structure of DIB can be viewed in Figure 4.2.1 below.
DIB DIT
Root

Entry

Entry

Entry

Entry

Entry
Entry

Attribute

Attribute

Attribute

Attribute type

Attribute value(s)

Alias

Distinguished attribute value

Attribute value

Attribute value

Figure 4.2.1 Directory Information Base and Directory Information Tree [5] 21

The entries in the DIB are structured as a hierarchy. The structure is that of a tree and that is why the entries can be represented as the Directory Information Tree (DIT). In the DIT every node is a different entry. The DIT follows the normal rules for a hierarchical tree with subordinate nodes and a top node (root). Every entry in the DIT has it own Distinguished Name (DN). In addition to the DN the entries carry the parent node(s) name as well. This is called Relative Distinguished Name (RDN) and is added to the entry on creation. The entries in the tree are all unique since they all have a DN and a RDN. Alias nodes are allowed in DIT. The alias nodes points to another node in the tree that contains an entry. The reason for this is that it can be useful for an object to have more than one name. The use of alias nodes does not make the tree ambiguous since the RDN are used [6].

4.2.2 Namespace
X.500 consists of a hierarchical namespace. The namespace is used to make it possible to reference and organise the data. The namespace in X.500 is built similar to the DNS but is more flexible and expandable. Nodes creating a tree structure are the backbone in a namespace. An example string can look like this, person.company.country. It is not necessary that the syntax look like this, it is allowed to for example skip the organisation.

Root Country Organization Person/ Object

Figure 4.2.2 Namespace

4.2.3 Functional model


The functional model describes the operations that are available in X.500. There are a couple of different operations in X.500 but they can basically be divided into three groups. Search and Read Modify Authenticate

These groups consist of multiple operations that can perform the task the group must be able to handle. The operations functionality and structure depends on what protocol is being used. The standard protocol in X.500 is called Directory Access Protocol (DAP) and can operate asynchronous as well as synchronous. DAP involves a lot of overhead and it is not required that this protocol is used. If it is vital to bring the overhead down to a minimum then the Lightweight Directory Access Protocol (LDAP) can be used instead.

22

4.2.4 Authentication framework


This component is vital for the X.500 since it makes sure that the information in the directory is only displayed to people who have the right to access it. To make it possible two methods is used. Authentication When a person or an application tries to get access the directory must know that they are who they claim to be. Access control Everyone is not allowed to access everything. This is why the directory needs the access control to make sure only the designated information is revealed to a user.

The authentication framework use both simple authentication and strong authentication. The simple authentication consists of name-password pairs. The password can be stored as clear text or be a protected password. Protected passwords are encrypted before they are sent. Neither of these approaches can be considered secure since passwords often are compromised but if there is no need for high security this method can be used.
Compare(Name,Password)

DUA

DSA

Figure 4.2.3 Password authentication The strong authentication is built on the principle of asymmetric cryptography. The messages from users and applications are hashed and then signed, and when the directory decrypts the message it can be sure it really came from the right person or application.
Message
Hash Compare

#Message
Encrypt with Senders Private Key

#Message
Decrypt wirh Senders Public Key

#Message
Hash

Digital Signature
Combine

Digital Signature
Split

Message

Signed message

Signed message

DUA

Transfer

DSA

Figure 4.2.4 Signature authentication

23

4.2.5 Distributed operation model


To make this work the X.500 is divided in client and server. The client side is called Directory User Agent (DUA) and is responsible for converting the user's request into an access protocol. There are two big access protocols to choose between, DAP and LDAP. The DUA is also responsible for displaying the result through some kind of interface. The server side of X.500 is called Directory System Agent (DSA). The server directory consists of many DSAs that contain part of the database. The servers communicate with each other through a protocol called Directory System Protocol (DSP) [5].

Directory System Protocol

Directory User

Client (DUA)

Server (DSA) The Directory

Server (DSA)

(Lightweight) Directory Access Protocol

Figure 4.2.5 X.500: DSA and DUA [5] If the user request information that the receiving DSA does not have, chaining is applied. The first DSA forwards the request to another DSA until the information is found and sent back to the user. This method is possible because the DSAs have information about each other and can therefore forward the information to the one best suited. If chaining is not possible for some reason the DSAs send referrals back to the client instead. This way the DSAs can make referrals to the DSA they think is best for the client. The downside of this method is that it is slower than chaining. The positive aspect is its capability of keeping the load on busy servers down compared to chaining. This happens because the burden is placed more on the DUA than on the DSA with referral [5].

24

4.3 X.509 4.3.1 Overview


X.509 is the most widely used standard for defining digital certificates. The first version of X.509, version 1, came out in 1988. That makes it the oldest proposed standard for PKI. The standard is developed by the International Telecommunications Union (ITU). It is actually a recommendation from ITU and has not yet been officially defined or approved. Different companies have therefor implemented the standard in different ways. Many big companies around the world have embraced the X.509 standard. Companies such as Visa and Mastercard use X.509 for their electronic transactions [3].
Version Certificate Serial Number
Parameters

Subject Name Subjects public key information


Algorithms Parameters Key

Issuer unique identifier Subject unique identifier Extensions

Signature

Algorithms Parameters Encrypted

Figure 4.3.1 X.509 Certificate [3]

4.3.2 Certificate structure


The X.509 standard defines the information that the certificate can consist of, and it describes the data format. All X.509 certificates are structured the same way. Version The version field identifies which version, 1, 2 or 3, of X.509 that applies to the certificate. This is important because it defines what kind of information that can be put into the certificate. The latest version of X.509 is version 3. New X.509 applications can use previous versions of certificates, but an application that is developed for version 1 can not use a version 3 certificate.

All versions

Version 3

Period of Validity

Not before Not after

Version 2

Issuer Name

Version 1

Signature algorithm identifier

Algorithm

25

Certificate Serial Number The certificate serial number is a unique number that the certificate authority, CA, has to assign the individual certificate. This is done because of the need to distinguish the certificates created by a certain CA from each other. The CA has full control over this field and has the right to put any value there. Signature algorithm identifier This field identifies the algorithm used to sign the certificate as well as the parameters used with the algorithm. This is the information about the CAs public key. Issuer Name This field identifies the CA that has signed the certificate. It contains the X.500 name of the CA. Using this certificate implies that the CA, that signed the certificate, is trusted. This is a unique name and it often contains the common name, organisational unit, organisation, state or province and country. Period of Validity Each certificate is valid only for a limited amount of time. This period identifies both the start date and time and the end date and time. If date and time isnt within these limits the certificate is thought of as invalid. The amount of time a certificate is valid can be as short as a few seconds or as long as almost a century. Subject Name The subject name field identifies who owns the public key that is being certified. Like the issuer name field the subject name field uses the X.500 standard. The field therefor contains the subjects distinguished name, DN. Subjects Public Key Information This field contains the public key of the entity. It also identifies the algorithm being used and its parameters. This field differs from the signature algorithm identifier field in that this field contains information about the subjects public key. Issuer unique identifier This field is optional and it is used when two different CAs has the same unique X.500 name. Putting different values in this field can then separate the CAs. This field was introduced in X.509 version 2. Subject unique identifier This field is also optional and it is used when two subjects have the same X.500 name. Putting different values in this field can separate these subjects. As this scenario seldom happens this field is not used very often. This field was also introduced in X.509 version 2. Extensions In this field the issuer can put private information about the certificate as a set of one or more extension fields. The extension field was introduced in X.509 version 3. This field was added because of the need to fit more information in to the certificate. Instead of adding more fields to the fixed structure of the X.509 certificate, it was decided to use a more flexible approach. The optional extensions were therefor added.

26

The extension must consist of an extension identifier, a criticality indicator and an extension value. The criticality indicator is set to be either critical or non-critical. That is done by setting the value either TRUE or FALSE. If the extension is not recognised by an application it can ignore the extension only if it is set to non-critical, if it is set to critical the certificate must be treated as invalid. There are 14 recommended extensions that are presented in the X.509 standard. Authority Key Identifier This extension helps identifying the public key that corresponds with the private key used to sign the certificate or CRL. It must not be marked as critical. Subject Key Identifier This extension helps identifying certificates that contains a certain public key. This extension must not be marked as critical either. Key Usage This extension defines the usage of the certificate key. For example encipherment, signature and certificate signing. When this extension is used it should be marked as critical. Private Key Usage Period This extension allows the CA to set a different period of validity for the private key than the certificate. It is not recommended to use this extension because it can easily get ambiguous. Certificate Policies This extension contains information about the policy under which the certificate has been issued. It also indicates under what circumstances the certificate may be used. Policy Mappings This extension contains pairs of object identifiers. It is used only in certificates for CAs that has been issued by other CAs. Each pair contains of one issuerDomainPolicy and one subjectDomainPolicy. This is important when the issuer and the subject wants to compare policies. This extension must not be marked as critical. Subject Alternative Name This extension is used when different applications have their own alternative names or if there is a need for other alternative names. For example, e-mail address, DNS name and IP address. Issuer Alternative Names This extension is used to connect Internet style identities with the CA. The issuer alternative extension should not be marked as critical. Subject Directory Attributes This extension can be used to contain any X.500 directory attribute value for the subject of the certificate. It is not recommended to use this extension unless it is used in a local environment. This extension must not be set as critical. Basic Constraints This extension identifies if the subject is allowed to act as a CA and if that is the case, it is specified how long the certification path may be. Name Constraints This extension is allowed to be used only in a CA certificate. It shows a name space where all subject names in the certification path must be located. Policy Constraints This extension is used to constrain path validation. It can be used in two ways. It can be used to ban policy mapping and to require that each certificate in a path contains an acceptable policy identifier.

27

Extended key usage field This extension is used as an additional field for the key usage extension. It can indicate more information about the usage of the certificate key. CRL Distribution Points This extension points out how CRL information is gathered. It should be set as non-critical.

Signature This is the last field in the certificate. It contains the signature algorithm identifier and a hash code of the other fields encrypted with the CAs private key [3,7].

4.3.3 Authentication procedures


X.509 includes three different authentication procedures. These procedures use public key signatures. In the authentication it is assumed that the two users know each others public keys. They could have got the public keys either through a CA directory or through it being exchanged via messages. One-way authentication This is a single transfer between users A and B. It establishes the following elements. The identity of A and that the message was generated by A. That the message was intended for B. The integrity and originality of the message. Only A identity is verified in this process. Two-way authentication It establishes these elements in addition to the previous three. The identity of B and that the reply message was generated by B. That the message was intended for A. The integrity and originality of the reply. Two-way authentication permits both A and B to verify the identity of each other. Three-way authentication This approach includes that a part of the message from B to A is sent back to B again. This makes it possible to detect replay attacks. Three-way authentication is used when synchronised clocks are not available [3].

28

5. Technology
In the following chapter we will describe the existing technology needed to suggest a solution. Both TETRA and WTLS is needed in our initial problem discussion.

5.1 Terrestrial Trunked Radio 5.1.1 Overview


TETRA means Terrestrial Trunked Radio. It is a new open digital radio standard defined by the European Telecommunication Standardisation Institute (ETSI). It was developed to meet the demands of the most demanding professional mobile radio users. TETRA is the latest ETSI standard and follows the path set by the Global Standard for Mobile telecommunication (GSM), which started in Europe, but has now been accepted world-wide. This infrastructure is targeted primarily at the mobile radio needs of public safety groups such as police and fire departments, utility companies, and other enterprises that provide voice and data communications services. These groups have been using either private/professional mobile radio (PMR) or public access mobile radio (PAMR) technology. TETRA is a standard solution for groups that has been using PMR and PAMR. In recent years a lot of disasters have happened in Europe where the European countries have had to work together in disaster areas. This has been difficult due to the lack of standardisation in their mobile radio equipment. TETRA is an effort to try to solve this problem and to create a new European standard. TETRA is based on digital trunked radio technology as opposed to PMR and PAMR that is based on analogue radio technology. It relies on digital trunking, which means that every radio on the system listens on a logical control channel, that is a data transmission giving the radios all their instructions. A trunking system works like a big repeater system. All communication is two-way, but the communication is performed through the basestations trunking system [8].
Terminals in TETRA Repeater Mode TETRA Base Stations Terminals in Direct Mode

Gateways to PSTN,PDN, PABX, Private data networks

Network Switching Centre

Network Switching Centre

Line Connected Dispatch

X.25 Internet
OMT

OMT

Network Switching Centre

ISDN

Stand-alone Base Station

Figure 5.1.1 TETRA network schematic [9] 29

TETRA has adopted features from several different technological areas, such as mobile radio, digital cellular phones, paging and wireless data transmission. TETRA-based products come with built-in encryption features to ensure the privacy and confidentiality of sensitive data/voice communications. These products are also designed with the ability to transfer data at faster rates than ever seen before in mobile communications. The TETRA standard specifies several essential interfaces to ensure compatibility between different manufacturers equipment. Common air interface (CAI) for peripheral equipment. For either trunked mode or direct mode. Inter-system interface (ISI) for network interconnection. Used between different TETRAnetworks. Network management interface (NMI). Interfaces for line stations and mobile data equipment. Interfaces for PSTN, ISDN, PDN and PABX interconnection.

As said earlier TETRA is developed mostly for groups using PMR and PAMR. But in the future TETRA can become significant for people using wireless phones. There are a lot of benefits for all kinds of users. The key benefits of TETRA. Channel efficiency - more channels, less congestion. New voice call services - improved personal and group communication. Advanced data communication services - better efficiency and safety. Encryption - complete security of communication. Multi-vendor equipment market - several manufacturers to choose from.

The picture below is showing TETRAs positioning of technology [9].


Private system

Public access

PMR/Group Mobility

DIIS TETRA

Wireless Telephony

DECT

GSM GPRS UMTS/3G

Local area

Wide area

Figure 5.1.2 TETRAs positioning of technology [10]

30

5.1.2 TDMA
TETRA is based on TDMA, which means Time Division Multiple Access. It is a technology that was first used in digital cellular telephone communication. TDMA works by dividing a radio frequency into time slots and then allocating slots to multiple calls. In this way, a single frequency can support multiple simultaneous data channels. TDMA relies upon the fact that the audio signal has been digitised. Which means, divided into a number of milliseconds-long packets. It allocates a single frequency channel for a short time and then moves to another channel. The digital samples from a single transmitter occupy different time slots in several bands at the same time. In digital cellular telephone communication, technology the frequency is divided into three different slots. In TETRA the frequency is divided into four different time slots [9]. Voice plus Data (V+D) and PDO (Packet Data Optimised) The V+D standard uses four TDMA air interface slots. Usually the first slot is the logical control channel and the three other slots are logical traffic channels. If for some reason an application needs more control channels, more slots can be allocated as control channels. In this way the TETRA network can be transformed for the applications needs. The TETRA PDO standard uses no time slots at all. It uses the entire frequency channel for packet data transmission. When using PDO, no voice or circuit mode data transmissions are allowed. PDO and V+D uses the same modulation and bit rate. The major manufacturers focus on the V+D standard in their development of TETRA [11,12,13].

TETRA Standard - data services -

TETRA Voice + Data Standard

TETRA PDO Standard (Packet Data Optimised)

Short Data Service (SDS)

Circuit Mode

Packet Mode

Packet Mode

Connection oriented IP

Connection less

Figure 5.1.3 TETRAs data services [11]

31

5.1.3 SDS
The TETRA SDS (Short Data Service) is divided into a few different categories. SDS is very efficient at transferring small amounts of information. The first category is status messaging. A status message is a 16-bit number sent over the logical control channel. This is done by simply pressing a button on the radio. The 16-bit number can be associated to a certain status message. It is possible to define up to 32,767 status messages. This kind of status messages can only be transmitted from the radio to the dispatcher, not the other way around. An example of a usage is when a police car is free for assignments it presses the status button on the radio and the dispatcher sees the message on the screen that the car is available. Another category is the free format text or binary data. Different types of these kinds of messages is available, different fixed length and one variable length SDS type. SDS can in some ways be compared to GSMs SMS (Short Message Service). SDS messages can only contain up to 256 bytes. SDS can be used where binary data transmission is needed, like in database access or AVL (Automatic Vehicle Location). To be certain that a message has been received SDS uses different types of acknowledgement mechanisms. The message is sent to a server and from there it is sent to the right address when the receiver is available. The first type of acknowledgement is sent from the server to the sender, it says that the message is received and that the message will be sent on when the addressee is available. The second type is from the receiver, it says that the message was received correctly. TETRA SDS supports point-to-point and point-to-multipoint messages. That means that messages can be sent and received from radio to radio or through a gateway inside the infrastructure [11,12]. Circuit Mode The TETRA circuit mode has three different bit rates and three levels of error correction. Highly protected data at 2400 bps. Medium protected data at 4800 bps. Unprotected data at 7200 bps. These bit rates are for a single slot. If a higher data throughput is wanted, all of the four slots can be used. This means that a maximum of 28.8 kbps can be reached when using all four channels in unprotected mode. To use all four time slots, another RF base station is needed to act as a control channel. One of the strengths of TETRA TDMA is that for example two channels can be used for circuit mode data transmission while one is used for voice and the last one is used as a control channel. This can be varied in any combination. [11] Packet Mode The TETRA packet mode has three different packet modes. Connection Oriented Network Protocol (CONP), Specific Connection Less Network Protocol (S-CLNP) and the third one is Internet Protocol (IP). The Connection Oriented Network Protocol is similar to the X.25 packet service. It provides both Virtual Call (VC) and Permanent Virtual Circuit (PVC). The Specific Connection Less Network Protocol is similar to the IP packet service. The connectionless mode also allows multicast transmission. The Internet Protocol will bring TETRA closer to the TCP/IP world. With the last mode it is easy to access IP networks through standard IP routers [11]. 32

5.1.3.3 Peripheral Equipment Interface (PEI) The TETRA Peripheral Equipment Interface is divided into three different versions.
TETRA PEI

PPP (Point-to-Point Protocol)

AT Command Set

TNP1

Figure 5.1.4 TETRA PEI [11] The most refined level of PEI is the Point-to Point protocol (PPP). PPP is normally used to connect to the Internet via a serial data cable. It is the link used by TCP/IP applications. In the case of TETRA, the PPP handler would exist inside the radio, in that case a PC with standard WINSOCK software running, for example, Internet Explorer could be used over the TETRA radio, without any special drivers needed. The data service that would fit to be used in the PPP case is IP. In most cases the peripheral equipment would be a Windows compatible platform connected to the radio, to be able to take advantage of the TCP/IP features like multisession capabilities. It would be possible to get database access from a PDA running for example Windows CE over TETRA. The second level of PEI is the well-known Hayes AT command set. AT commands are designed for circuit mode data, but with a few modifications it can be used in SDS as well. In that way, the AT command interface could be used with both circuit mode and SDS, that would make data connectivity much easier. Low power computing devices such as organisers and other micro controller based platforms can be directly connected to TETRA radio with SDS. Applications using very short packages of data or requiring easy connectivity is suited to use SDS together with the AT command interface. The third level is the Tetra Network Protocol 1 (TNP1). TNP1 provides access to SDS, circuit mode data, speech call control, radio status information and supplementary services [11].

5.1.4 TETRA SIM


In TETRA, the SIM is designed as an inseparable part of the functioning radio. This means that the radio is only complete when both the handset and the smartcard are paired. This can be achieved in a number of ways physical, electrical and by signalling. The role of the card is to hold data pertaining to the user. Therefor the card is likely to hold both the user's TETRA identity (ITSI) and his associated authentication key (K). Both of these are unalterable by the user, and in the case of K it will not be accessible in any way from the interface. In a very simple way, a smartcard gives a security function to TETRA in the same way that a key gives a security function to a car. Using keys is the most basic method against theft. A SIM enabled radio handset without a resident SIM should be more difficult to use when stolen than a radio handset with the user data permanently installed. There are mechanisms in TETRA to remotely disable a handset. A temporary disablement can be achieved at the root directory level by marking the TETRA directory as not active. A permanent disablement demands the deletion of the TETRA directory structure [14].

33

5.1.5 TETRA IP
With TETRA IP, users can access databases and use IP based applications from anywhere in the TETRA network. With the IP-enabled radios, users will be able to connect to secure central databases or public Internet servers. With TETRA IP, instead of calling someone and ask to do a database enquiry, waiting for them to do it and then find out the information, with TETRA IP the user can do the database enquiry themselves and get the information right in their handset. TETRA provides an ideal end to end IP service using the packet data service. TETRA IP significantly enhances access to WAP services compared to the performance of mobile phones. WAP technology has so far been a bit of a disappointment for GSM users because of the length of time it takes to connect to a service. This is because WAP over GSM operates in circuit-switched mode, and as with starting an Internet connection over a terrestrial phone line, the handset must dial up a modem, set up a network session and log on to a gateway server before treating each request. With TETRA IP, the connection is set up just once when the radio is turned on, enabling an almost instantaneous response to later requests. TETRA IP is used like this: 1. 2. 3. 4. 5. 6. Activate IP context = obtain IP address for the terminal, routing possible Stay on MCCH (Main Control Channel) Move on to PDCH (Physical Data Channel) for data transmission Leave PDCH to MCCH after an idle period timer has expired Repeat 3 and 4 Deactivate IP context = release IP address

TETRA IP can provide several different applications. Here is an example of different solutions available: WAP applications Corporate intranet applications File transfer E-mail Database Query Dispatching Web applications Surveillance AVL (Automatic Vehicle Location) Navigation Fleet management Telemetry [15]

34

Figure 5.1.5 TETRA IP network schematic [13]

5.1.6 Security in a TETRA network


There is a lot of security built in to TETRA because it is used by public safety and security organisations. If TETRA would have any security problems it could lead to lives being at risk or criminals getting away. There are different threats that a TETRA network could face. Authentication is the main way of frustrating unauthorised radio users. An accepted user has an authentication key that is known only by the network infrastructure and the radio unit. The radio unit must prove to the infrastructure that it knows the key in order to gain access to the network. This does not mean that the key has to be transferred over the network. When using authentication keys, one must also have some form of key management. Authentication Key Management (AKM) is the method used to transfer the authentication key to the infrastructure and the mobile station (MS). Generation of a TETRA authentication key involves generating a random unpredictable value of 128 bits. This can be done by the manufacturer of a handset, by the manufacturer of a detachable module for the handset in which the key is securely stored or by a special security agency, in the case of military and security police networks. Distribution and linking identities to keys is an essential step needed to put the keys into operation. Only when this is done the keys can be used. Storage of keys needs to be done in two different places: in the network and in the handset. In the network, a secure Authentication Centre (AuC) will normally be used and on the SIM card in the handset the key must be stored in such a way that it cannot be extracted. Once keys are no longer operational they need to be destroyed or deactivated [15].

35

Air-Interface Encryption is a highly secure cipher method and provides a security level high enough for almost all users. Signalling and coded speech that is sent on the radio path is ciphered using an encryption key and an encryption algorithm. Only authorised recipients know the cipher keys and only they can decode the encrypted speech and signalling. Standard encryption algorithms may be used and a range of air interface encryption algorithms is available both for public safety and commercial systems. End-to-end encryption is intended for special groups such as internal inspectors and undercover agents. In addition to being ciphered in the air interface, the voice signal is also ciphered throughout the TETRA infrastructure i.e. in the base stations, transmission and exchanges. Circuit mode speech can be encrypted this way and the end user organisation may provide its own encryption algorithm. The sender and receiver must share a common end-to-end encryption key. End-to-end encryption key management is outside the scope of the TETRA standard but the TETRA MoU has made a recommendation on how to implement it. These systems and safeguards assure users that using a TETRA network is a safe and secure method of communicating their confidential information [15].

36

5.2 WTLS 5.2.1 Overview


The Security layer protocol in the WAP architecture is called the Wireless Transport Layer Security, WTLS. It operates between the transport and the transaction layer. This layer is responsible for the security of the connection between client and server. The technology behind WTLS is based on TLS, which is the corresponding layer in a wired network. TLS is an independent protocol based on SSL, which was developed by Netscape. WTLS took the principles of TLS and made adjustments to the wireless world. A wireless network does not have the same bandwidth, memory or processing power as a regular network. The purpose of WTLS is to be a lightweight version of TLS.

Application Layer (WAE) Session Layer (WSP) Transaction Layer (WTP) Security Layer (WTLS) Transport Layer (WAE) Bearer (GSM, CDMA, etc) Other services and applications

Figure 5.2.1 WAP Layers [16] The following features describes WTLS: Privacy, data integrity and authentication Datagram support Optimised handshake Dynamic key refreshing [17]

The datagram support is needed when using packet-switched services. The optimised handshake is another feature that saves time and bandwidth in the WTLS and is described later. In WTLS there is also a possibility to change the keys that encrypt and authenticates the secure connection in certain time intervals. By doing this the possibility for an eavesdropper to decrypt a message becomes much tougher since the keys are not the same throughout the entire session. How often the keys are changed is decided in the handshake procedure. WTLS supports a number of cryptographic algorithms in order to establish and maintain a secure connection. Authentication Key Exchange SHA-1, MD5 RSA, DF (Diffie-Hellman), DFEC (Diffie-Hellman Elliptic Curve) Encryption RC5, DES, 3DEA, IDEA Figure 5.2.2 WTLS cryptographic algorithms 37

WTLS architecture is divided into five parts. It has a Record Protocol and four client protocols that are used in conjunction with the Record Protocol [16].
Record Protocol

Alert Protocol

Application Protocol

Change Cipher Spec

Handshake Protocol

WTLS

Figure 5.2.3 WTLS architecture [16]

5.2.2 Record protocol


WTLS has a layered Record Protocol. The Record protocol is divided into four different protocol clients; Alert, Application, Change Cipher and Handshake protocol. This protocol takes data that is about to be transferred from a higher layer and compresses, applies a MAC, encrypts and then transmits it. When the Record Protocol receives data it is decrypted, verified, decompressed and then send to the next layer. Compression, authentication and encryption are all optional methods. Which ones are being used is decided in the handshake. This way the Record Protocol cares for the integrity and the authentication. Unlike TLS there is no fragmentation in the Record Protocol, since the transport layer is caring for fragmentation and it being reassembled. When connecting to a client or server with WTLS the Record Protocol enters a connection state. During this state the algorithms for compression, MAC and encryption is decided. There are two different connection states. During the current state all the processing is done. The pending state marks that the record protocol is waiting for something. Before the handshake is completed the state is pending and when it is finished the state changes to current.
Handshake Processing Pending Current

Figure 5.2.4 States in WTLS In order to protect the payload, explicit sequence numbering can be used. If the datagram transport protocol is used then this is mandatory. When using this, issues with duplicate and lost records appear. To solve this a sliding window is used to keep track of the received messages. The sequence numbers always starts with zero. The maximum value of a sequence value is 216 -1 and when it reaches this limit the secure connection must be closed. When a ChangeCipherSpec message is send the sequence number starts at zero again [16].

38

5.2.3 Alert Protocol


This protocol is used to send different alerts between client and server. An alert can be a message to close the connection between client and server or an error message. When one side wants to close the secure connection it sends an alert to the other, telling it to terminate the connection. The other side responds and the connection closes down. The error alert contains information about how severe the alert is and a description of the problem. There are three kinds of error alerts; warning, critical and fatal. If a fatal alert is sent to client or a server they will both immediately terminate their secure connection since it could be compromised. Other connections using the same session may continue but the session identifier must be invalidated so that a connection can not be set up with the failed connection. The critical alert causes the connection between server and client to terminate. Other connection can continue to use the secure session without invalidating the session identifier. This implies that new connections can be established using the secure session despite the alert. The warning alert is not an error. When a warning alert is sent it only means that the MAC is not correctly validated. No connections are terminated, instead the packet with corrupt MAC is discarded [16,17].

5.2.4 Change Cipher Spec Protocol


If a client or server wants to change the cipher suite used it sends a Change Cipher Spec. After sending it the sender goes into the pending state. When the receiver gets the message it also goes into the pending state. At this point the receiver has to respond to the message to start the connection with a new cipher suite and when the senders gets the confirmation the two goes into the current state and processing is started again [16,18].

5.2.5 Handshake Protocol


There are three kinds of handshakes, full handshake, abbreviated handshake and optimised handshake. When communicating in a datagram environment the handshake messages can be lost, out of order and duplicated. This is why WTLS requires the use of Service Data Unit (SDU). The SDU consists of the handshake messages going in one direction concatenated together. Of course it is only possible to concatenate messages that are sent before the other side must respond. For example the ServerHello, ChangeCipherSpec and Finished in the abbreviated handshake can be send together as a single SDU. If a client leave any fields blank in any of the handshake messages it is the server responsibility to fill them. This goes for all kinds of handshakes. During the handshake all the security related parameters are decided. These parameters consist of information about protocol version, cryptographic algorithms, information on the use of authentication and public key techniques to generate a shared secret. The handshake involves the following steps [16]. Exchange hello messages to agree on algorithms, exchange random values. Exchange the necessary cryptographic parameters to allow the client and server to agree on a pre-master secret. Exchange certificates and cryptographic information to allow the client and server to authenticate themselves.

39

Generate a master secret from the pre-master secret and exchanged random values. Provide security parameters to the record layer. Allow the client and server to verify that their peer has calculated the same security parameters and that the handshake occurred without tampering by an attacker [16].

Full handshake

ClientHello ServerHello Certificate* ServerKeyExchange* CertificateRequest* ServerHelloDone Certificate* ClientKeyExchange* CertificateVerify* [ChangeCipherSpec] Finished [ChangeCipherSpec] Finished

Figure 5.2.5 Full handshake [16] The server can request the handshake by sending the HelloRequest. This message consists of nothing but a notification that the server wants to make a handshake. The client then sends a ClientHello in response if it wants to create a secure connection. If not, it can send an alert that specifies that the client does not wish to do a handshake. The server can use this command if it wants the client to renegotiate the secure connection but it is not mandatory for setting up a handshake. If the client wants to start a handshake, it can do so without the HelloRequest. In the ClientHello the client specifies what kind of key exchange methods, cipher suites and compression methods it supports. It also specifies which certificates the client trusts. These properties have the form of a list and the different options reside in the list reflecting the clients preferences. The first preference takes the first place in the list. The client generates a random number to be used later in the protocol and if a session ID is available it is included otherwise the client leaves it blank. In order to make sure the server gets all information needed the ClientHello also consists of the clients version of WTLS, what sequence number mode to use and how to handle key refreshing. It is important that the client version value is the highest version supported by the client. After gathering this data and sending it to the server the client starts to receive data until the ServerHelloDone is received. The ServerHello consists of the same attributes as the ClientHello, except trusted certificates that are omitted. The server examines the data it receives and decides which values that are going to be used for the secure connection. Before sending the message, the server generates a random number that are going to be sent with the message just as the client did. Of course these two random values are created independent of each other. After sending the ServerHello, the server has a choice whether to send the Certificate, ServerKeyExchange and/or CertificateRequest. If authentication is going to be used the server has to send its certificate to the client. The Certificate message consists of one or more certificates. A certificate can be a X.509, WTLS or 40

X9.68. The last one is yet to be defined. Instead of sending the certificate, a URL to a location can be used but this is mainly for the clients to use. The ServerKeyExchange is only sent if the Certificate sent previously did not contain enough data to allow the client to exchange a pre-master secret. This could be a public RSA key to encrypt the secret with. The secret is calculated from the two random numbers the client and server generated and the pre-master secret decided by the server. If the server want the client to authenticate itself a CertificateRequest is sent. This message contains a list of certificate authorities trusted by the server. To let the client know the server is done sending, the ServerHelloDone is sent to the client. After it is sent the server waits until it receives a Finished message. Instead it is now the clients turn to send messages. After receiving the ServerHelloDone the client has to send the data needed. This depends on what the server has sent. If the client received a CertificateRequest it has to send a Certificate message to the server. The format of the Certificate is the same as the one the server sent. As described before the client can send a URL instead of a certificate. If it is done the server checks the certificate at the URL instead. The client then sets the pre-master secret by sending a ClientKeyExchange message. The structure of this message depends on what key exchange method the server chose to use. In the message a secret is encrypted with the exchange method that was chosen. This secret is used to send application data over the secure connection later in the protocol. If the server wants the client to authenticate itself, the client has to send a CertificateVerify message. This message is a signature of a hash of all the handshake messages sent so far, made by the client and is only possible if the client has a certificate with capability to sign, i.e. RSA certificates. When the client has finished sending data, it sends the ChangeCipherSuite message to the server and sends a Finished message through the new cipher suite. This new cipher suite is the result of the negotiating though the handshake and includes whatever algorithms were decided. The server receives the Finished message and verifies that it is correct. If this is so the server sends the ChangeCipherSuite to the client. Then the Finished message is sent to the client through the new cipher suit and the client verifies it. This marks the end of the handshake and if everything worked out, client and server can start to communicate through the new secure connection. The Finished message consists of a value derived from the data that has been sent between the two so far, concatenated together. If either part receives a Finished message that does not correspond with the other side the connection terminates through an alert [16,18]. Abbreviated handshake If the client and server have a previous secure connection and the client wants to resume it, the client can initiate an abbreviated handshake. This starts with that the client sends a ClientHello where the Session ID of the session that are being resumed. The server receives this and checks if the Session ID is present in the cache. If it does not exist the server generates a new Session ID and a full handshake must take place. If the Session ID exists then the server sends a ServerHello followed by ChangeCipherSuite and Finished messages. The client sends the ChangeCipherSpec and the Finished messages and the secure connection can continue. This is possible since both know the shared secret since the last session. It is possible for the client or server to change the key refresh rate during the abbreviated handshake. The abbreviated handshake makes it possible to have many secure connections under the same Session ID [16].

41

ClientHello ServerHello [ChangeCipherSpec] Finished [ChangeCipherSpec] Finished

Figure 5.2.6 Abbreviated handshake [16] Optimised handshake This handshake is used when the client certificate can be found at a TTP or at the server itself. In order for this to take place the client has to send the appropriate information in the ClientHello. The server can then retrieve the clients certificate from the TTP instead of receiving it from the client. After the server has validated the certificate it sends its own certificate to the client and continues with the ChangeCipherSpec and Finished message. As with the other handshakes the client responds with the same and the secure connection is established. The application data can be sent through the secure connection [16].
ClientHello ServerHello Certificate [ChangeCipherSpec] Finished [ChangeCipherSpec] Finished

Figure 5.2.7 Optimised handshake [16]

5.3 WTLS classes


WTLS connections have three different kinds of classes. These classes support different functionalitys. Below a figure shows what the different classes include. M stands for Mandatory and O for Optional [16]. Feature Public key exchange Server certificates Client certificates Shared secret handshake Compression Encryption MAC Smart card interface Class 1 M O O O M M Class 2 M M O O O M M O Class 3 M M M O O M M O

Figure 5.2.8 WTLS classes [16] 42

6. Analysis of mobile PKI products


In this chapter we analyse the mobile PKI products from two of the largest companies in information security

6.1 Baltimore, Telepathy 6.1.1 Company information


Baltimore Technologies at a glance Baltimore Technologies is a global leader in e-security products, services and solutions. Through the provision of an award winning e-security infrastructure technology, Baltimore enables companies world-wide to securely develop their Internet strategies: e-Business & e-Commerce e-Services Mobile Commerce Enterprise IT systems Baltimore Technologies is a public company listed on NASDAQ (BALT) and London Stock Exchange (BLM) with offices in major cities world-wide [19]. Employees Over 1,200 people worldwide [19]. Offices World-wide Baltimore Technologies operates from 46 offices world-wide with headquarters in Dublin, Ireland; London, UK; Boston, USA; Tokyo, Japan and Sydney, Australia [19]. Customers Baltimore Technologies has customers in over 50 countries worldwide covering a range of industries including the Financial Services, Government, Healthcare, Telecommunications / Network Operators and Technology sectors. Blue-chip customers include: ABN-AMRO Bank, Australian Tax Office, Banco Santander (BSCH), Bank of Ireland, Belgacom, Citibank, Commerce One, EUROPAY, Identrus, Intel IAS, Irish Revenue Commissioners, MasterCard, Ministry of Defence (UK) and VISA International [19]. Partners Baltimore Technologies markets and sells its e-security solutions worldwide via its worldwide office network and through its extensive Baltimore TrustedWorld partner program. With over 500 partners in 52 countries, Baltimore TrustedWorld is the leading partner program in e-security today, combining experts in resale, systems integration, e-services, wireless esecurity and PKI interoperability. Key partners include Accenture, Check Point, Cisco, Compaq, EDS, Hewlett Packard, Logica, PricewaterhouseCoopers, Sony and Unisys [19]. Products & Services Baltimore Technologies develops and markets e-security technology to assist organisations in building secure, trusted systems for e-business, the Internet and mobile commerce. Baltimores product range includes award winning Public Key Infrastructure (PKI) systems and services (UniCERT Options), access and authorisation management products (Baltimore

43

SelectAccess), wireless e-security solutions (Baltimore Telepathy), developer toolkits (Baltimore KeyTools), hardware cryptographic devices (Baltimore SureWare) and content security products (MIMEsweeper) to provide a complete security infrastructure. The comprehensive product suite is policy-driven, modular, scalable and highly flexible. Baltimores commitment to service guarantees the provision of consultancy, training and deployment to customers and partners world-wide coupled with 24/7 support [19]. World Firsts Baltimore Telepathy - the first complete product line for e-security over wireless networks Baltimore KeyTools - the first product for securing XML documents and systems - the first commercial Java Crypto Toolkit for building secure Java based systems; subsequently licensed to RSA Security MailSecure - worlds first non-US S/MIME product for secure e-mail UniCERT - next generation Certificate Management System for complete security of high-value Internet transactions Enabled the worlds first Digital Signing ceremony of an international communiqu between President of the USA, Bill Clinton and Prime Minister of Ireland, Bertie Ahern [19]

6.1.2 Product information


Baltimore's Telepathy solutions are targeted at e-Commerce companies, Mobile Operators and software Developers to deploy complete end-to-end security solutions for mobile commerce. It enables businesses to provide new services to mobile customers by securing communications and transactions from the end-user to a company's e-commerce and IT systems. Telepathy includes security solutions for mobile devices, network operators and e-businesses [19]. Telepathy consists of multiple components. Telepathy WAP Security Toolkit (WST) WST is a software development kit that enables creation of secure encrypted connections between online units. Contains an implementation of WTLS to ensure a high security in WAP. Telepathy WAP PKI Digital Signature Toolkit (PDST) This is another software development kit. PDST makes it possible to use digital signatures on a wireless network. It implements WML (Wireless Markup Language) and allows providers to receive signatures from the mobile units and to verify their signature. Telepathy WAP Certificate Authority (WAC) This is an extension of a CA made by Baltimore capable of producing wireless certificates. The certificates that WAC can produce is WAP (WTLS). Telepathy WAP PKI Registration System (PRS) PRS supplies the mobile units in the wireless network with digital certificates. This component is not WAP specific but is also working on ordinary GSM units.

44

Telepathy WAP PKI Validation System (TVS) PVS is used to retrieve and validate certificates. This is done with consideration on the limited storage space and bandwidth in a wireless network. Instead of storing the certificate on a mobile unit, the unit holds a certificate identifier. This way the mobile units can access multiple certificates without having to download them [19].

6.1.3 Telepathy WST


Overview Telepathy WST (WAP Security Toolkit) is a software development kit that provides developers with the capability of creating secure wireless sessions between multiple wireless devices. This toolkit includes an implementation of WTLS 1.1 (Wireless Transport Layer Security) so that the developers can take advantage of the security layer in WAP. Telepathy WST keeps the API at a high level so that the developers do not need to bother with the complexity of cryptography. This means that when the developers build an application, the underlying security mechanism is automatically incorporated in the application. A basic certificate handling is also included to provide an easy incorporation of PKI functions into the Telepathy WST. The API in Telepathy include support for Session caching Security renegotiating Temporary key reuse Dynamic reconfiguration during session Integration into datagram layers defined in WAP, i.e. UDP/IP.

Standards of how to store keys and certificates in a secure manner are supported by this product. These are PKCS#1, #7, #8 and #12. Signing with private keys is also supported so there are no obstacles for including even safer methods of establishing connection, i.e. smartcards and hardware tokens. Telepathy WST has support for following cryptography algorithms RSA Diffie-Hellman RC5 DES, Triple DES SHA-1 MD5

The strength of the key is not predefined so the developers can choose a key strength that is appropriate for their security needs. This gives an opportunity to balance the system between speed and security. The symmetric key length has a maximum of 128 bits and the asymmetric a maximum of 2048 bits. Telepathy WST is available as a collection of ANSI-C libraries for the following platforms. Win32 (Windows 95, 98 and NT) Sparc Solaris 2.5+ HP-UX 10.2+ Linux

45

Architecture In means of architecture, Baltimore has chosen to divide up Telepathy WST into two main architecture elements. The WST session and the WST support service.
WST support service * Session Cache Cipher Suites 1 WST session

Record Layer

Compression Methods Client Authentication CA Certificates

Cerificate Verifier

Personal Certificates

Figure 6.1.1 WST architecture [20] The WST session object is basically a connection to a remote host. This connection is executed in a secure manner and the idea is that the data should be written and read in a secure environment. The other object, the WST support service, is used to support the WST session object. The WST support service includes support for security parameters, CA certificates, session caching, etc. Before the session is set up there are a couple of things that have to be decided first, such as what cipher method are going to be used, what CA to trust etc. To be able to do this the WST support service is configured before the session is initiated. The relation between the main parts in the architecture is WST session- WST support service, many-to-one. This establishes that there can be many sessions using the same support service. Whether it is a WTLS client or a WTLS server has to be established before the session can be created [20].

6.1.4 Telepathy WAP PKI Digital Signature Toolkit (PDST)


PDST is a high level cryptographic library. This application makes it possible for developers to implement standard wireless signatures. PDST verifies the signature at the server in order to provide authentication. WMLScript specified in WAP 1.2 is used in PDST and generally one can say that PDST is built on this. PDST is a product in the KeyTools family made by Baltimore and it can be considered a snapin for this product suite. This way all the functionality in KeyTools is available to PDST. PDTS is intended to any organisation that wants to develop a secure transaction system. It could be mobile operators, corporate user or financial institutions. Using PDST allows creation of secure e-business system and end-to-end security between client and server. Other features are full PKI support and protection against tampering of WML documents during transfer. It also supports certificate URLs and is written in 100% Java or C++. PDST supports a lot of different cryptographic algorithms such as RSA, DSA, Diffe-Hellman, Triple DES, DES, RC2, RC4, SHA-1 and MD5 [21].

46

6.1.5 Telepathy WAP Certificate Authority (WAC)


This component is built on existing technology previous built by Baltimore. The product behind WAC is the UniCERT application that has been around for some time. WAC is a both scalable and flexible product that is possible to expand after it is first deployed. The standards this component is built on are PKCS#10 and WTLS. Since WAC is an extension of UniCERT it can use both X.509 certificates and WTLS certificates [22].

Web Interface
CA CAO

WAP Gateway Server

Gateway
RA RAO

Signing Engine UniCERT WTLS CA

CAO CA operator RAO RA operator

Figure 6.1.2 WAC architecture [22] The web-interface acts as a front-end to the gateway. Incoming certificates and status requests are processed and then sent to the gateway using a Java-servlet. The gateway receives the requests from the web-interface and checks the validity of the certificate. To do this the gateway has to communicate with the UniCERT entity. Finally the signing engine acts as a second CA and is responsible for converting the certificates from X.509 to WTLS certificate and signs them. When this is done the certificate is saved in a PKI database. When a user requests a certificate the request go through the web-interface. The UniCERT CA is notified and creates a X.509 certificate. The signing engine then signs the X.509 notifies the user. The user is also able to check the status of the certificate request. Doing a poll from the WTLS CA does this. WAC is available for Windows 98/NT [22].

6.1.6 Telepathy WAP PKI Registration System (PRS)


If a mobile unit in a wireless network requires a unique identity, then they need digital certificates. PRS is an application that allows this. PRS does not generate any key pairs but assumes that these are already present on the mobile device. There are two types of registration into a PKI in a wireless network, pre-registration and post-registration. Pre-registration means that the mobile units already have digital certificates before they are connected to the network. Post-registration involves the delivery of digital certificates to the mobile units OTA (Over the air). It is also possible to combine the two, using pre-register to make the post-registration easier. An example of that is mobile units that have a device certificate installed on the SIM-card prior to the connection to the network. This device certificate can be used as an identity later, when the post-registration takes place. PRS supports all of the above listed cases. PRS also support root CA information for WAP clients. This means that a WAP device can obtain information from the CA so that the information on the client can be added and updated. With this information the WAP client can verify different WAP servers [23].

47

Telepathy Registration System


SAT SMS Mobile Unit signText() HTTP POP/ POI UniCERT Policy PKIX-RA Other PKIX CA/RA UniCert

WTLS

WAP

Registration Scripting Tools

Remote Data/services

Figure 6.1.3 PRS architecture [23] The core functionality in the PRS is verification of proof of possession (POP) of the signing keys, and proof of identity (POI) of mobile users. When using the POI and POP, external data can be used to make the verification. As stated before and shown in the picture, different type of client support is available. There are three kinds of client support in PRS [23]. WAP Client authentication keys First the WAP client has to establish a WTLS class 3 session with the PRS. A big difference between PRS and an ordinary WTLS server is that PRS does not have to fully verify the client certificate included in the handshake. The same goes for a certificate URL. Instead PRS retrieve the clients public keys and lets the client prove that it can use the correct private key. When the session has been created the PRS executes a script based on WMLScript. This script is used to gather information to the client. To be able to get this information the client has to prove its user identity. The script makes the client enter some value to get access to the information. This value can be a username/password or a secret known by the user. It can also be a part of another system, for example a PIN-code to something. If this is the case a so-called snap-in code has to be written in order to verify this external value. After the validation is completed the PRS sends a certificate URL to the client. The certificate is not yet at the URL but are placed there later in the process. This URL is stored on the client and can be used in other protocols as well. After this the PRS sends a certification request for the client to the relevant PKI. If the certification is successful, the PRS retrieves and publishes the certificate at the URL sent to the client earlier. If the certification fails, instead of a certificate, a failure notification is placed at the URL [23]. WAP Application signing keys The request mechanism is based on the previous method and therefore similar. Operators of the PRS are able to create and install custom WMLScript that are presented to the end-user. The user can then choose to sign a challenge produced by these scripts to prove that the private key is present on the users device. The script can also gather information similar to the client authentication keys method described above. The rest of the process is the same as above with the sending of a certificate URL and interaction with the relevant PKI [23]. 48

SAT Since WAP is not present on all mobile units there must be an option to use an alternative to WAP instead. In PRS an alternative to WAP is SAT (SIM Application Kit). SAT is more limited in functionality than WAP and there are currently no open standards on how security should be handled. One example is the lack of standard syntax for signatures generated by SAT. Because of these shortcoming the system may have to include extra implementation to handle any standard problems. If the SAT model is going to work a key pair have to be stored on the mobile unit or on the SIM card. Also, a signature function must be defined in the SAT to be able to send a registration message to PRS. PRS have two different support levels when registering a client through SAT. These are the abstract registration scheme and the SAT specific support. PRS is divided like this because the different SAT differ in details of how to handle registration. The abstract scheme is the same even if a different SAT is used. The change is only noticeable at the SAT specific support level [23].
SMS Mobile Unit S M S M C SAT Put/Lookup
Tools

Initiation SATspecific Gateway Registration

Telepathy Registration System


SAT UniCERT Policy PKIX-RA Other PKIX CA/RA UniCert

HTTP

POP/ POI

WAP

Registration Scripting

Remote Data/services

SATSpecific Data

Telepathy Put/Lookup

Figure 6.1.4 SAT in PRS [23] In the figure above the possible interactions are shown with lines. These interactions are specific to the SAT system. The mobile unit sends a SMS to the SMS messaging centre (SMS MC) which routes the message to an SAT-specific gateway. The SMS message normally does not contain the public key of the user so this has to be retrieved elsewhere. This external source can apart from public keys also hold CRL, customer names etc. It is also possible in some environment of PRS to write to this external source [23].

49

6.1.7 Telepathy WAP PKI Validation System (TVS)


TVS is a retrieval and validation system for digital certificates. It is constructed so that the bandwidth and storage requirements are kept to a minimum to ensure good services on wireless networks. In a TVS environment the mobile units hold a certificate ID that is a reference to a X.509 certificate. By using this approach no certificates have to be stored on the mobile units. Instead the mobile units have one or more certificate IDs depending on how many certificate the user has. TVS supports CRLs and OCSP (On-line Certificate Status Protocol) and since the certificate ID is used the processing take place in the TVS instead on the mobile unit and this makes the load on the mobile units much smaller. There are different kinds of proof of identity methods supported by TVS. Other features are support for X.509 version 3, complete policy control and support for 1024-2048 bit keys. Possible users for TVS are trusted PKI authorities like TTP, banks and telecom companies [24].

50

6.2 RSA Security, BSAFE 6.2.1 Company information


RSA Security at a glance RSA Security Inc. is one of the most trusted names in e-security, helping organisations build secure, trusted foundations for e-business through its two-factor authentication, encryption and public key management systems. RSA Security is renowned for providing technologies that help organisations conduct e-business with confidence. RSA Security is focused on three core disciplines of e-security, including: Public Key Infrastructure, RSA Keon. Authentication, RSA SecurID Encryption, RSA BSAFE RSA Security is a public company listed on NASDAQ (RSAS) with yearly revenues in excess of $200 million [25]. Employees Over 1,100 people world-wide [25]. Offices world-wide Headquartered in Bedford, Massachusetts, USA and with offices around the world. RSA Security is a global e-security provider with major offices in the US, United Kingdom, Singapore and Tokyo, and representation in more than 45 countries with additional international expansion underway, including locations in Europe, the Middle East, Africa, the Americas and Asia-Pacific [25]. Customers RSA Security customers span a wide range of industries, including an extensive presence in the e-commerce, banking, government, telecommunications, aerospace, university and healthcare arenas. Today, more that 7 million users across 4,500 organisations use RSA SecurID authentication products to protect corporate data, and over 500 companies embed RSA BSAFE software in over 1,000 applications, with a combined distribution of over 450 million units world-wide [25]. Partners RSA Security has through its various partnering programs strategic relationships with more than 500 industry-leading companies - including 3COM, AOL/Netscape, Apple Computer, Ascend, AT&T, Nortel Networks, Cisco Systems, Compaq, IBM, Oracle, Microsoft, Novell and Intel who are delivering integrated, RSA Security technology in more than 1,000 products [25]. Products & Services The company's RSA BSAFE line of encryption-based security technologies are embedded in over 450 million copies of today's most successful Internet applications, including Web browsers, commerce servers, email systems and virtual private network products. The majority of all secure electronic commerce and communication on the Internet today are conducted using RSA Security technologies. Both RSA SecurID and RSA BSAFE are considered de facto standards world-wide.

51

RSA Security now offers its customers the RSA Keon family of PKI products, a solution for enabling, managing and simplifying the public key authentication and encryption security in today's leading email, Web browser, Web server and VPN applications [25].

6.2.2 Product information


The increased functionality and convenience of wireless and embedded devices demand that they are secure. RSA BSAFE products are embedded in a half-billion copies of todays most successful hardware and software products, including mobile phones, cable modems, smart cards, operating systems and Web browsers. Since RSA BSAFE products are the de facto security infrastructure throughout the Internet, they provide seamless interoperability between wireless devices and all "wired" applications and services. Here are the three largest RSA BSAFE product groups that can be used in wireless security solutions. RSA BSAFE WTLS RSA is one of the leaders in the WAP Forum and have relationships with numerous wireless companies. RSA Security offers a Wireless Transport Layer Security (WTLS) product. WTLS is a security protocol optimised for use over wireless communication networks. Like the BSAFE SSL products, the WTLS tool allows developers to build secure applications, devices and servers supporting WAP [25]. RSA BSAFE SSL-C, SSL-J Secure Sockets Layer (SSL) is the Internet security protocol for consumers to conduct ebusiness. RSA BSAFE SSL-C and SSL-J products empower smart mobile devices to securely communicate with all companies offering goods or services on the Internet. Corporations utilise RSA BSAFE SSL-C and SSL-J to securely link mobile and embedded devices to critical information stored behind their corporate firewalls. RSA BSAFE SSL products contain complete implementations of the SSL and TLS protocols. They allow integration into a range of PKI products, and offer a complete range of encryption and authentication options. All in a modular set of software libraries that can be custom fitted into embedded platforms [25]. RSA BSAFE Crypto-C, Crypto-J RSA BSAFE Crypto products provide a wide range of data encryption and signing algorithms beneficial to wireless and hand-held devices. Pagers, mobile phones, micro browsers, set-top boxes and cable modems all require high speed, top quality, small footprint algorithms that enable these devices to securely access information and services on public networks like the Internet. In addition to quality and performance, RSA BSAFE Crypto products provide near-universal interoperability between non-PC devices and e-business applications. The RSA BSAFE Crypto products have been ported to the widest range of platforms in the industry and can be used in multiple wireless security protocols [25].

52

6.2.3 RSA BSAFE WTLS-C


Overview RSA BSAFE Wireless Transport Layer Security for C is a development kit for software developers that want to build a secure solution between multiple wireless devices. The popularity of Internet-ready mobile phones, personal digital assistants (PDAs) and handheld PCs in combination with the widespread adoption of the Internet has made it very attractive to develop applications with WAP. Developers can satisfy security issues by using RSA BSAFE WTLS-C to quickly add cryptographic and certificate management technologies to their wireless applications, devices and systems. The software developer kit (SDK) enables secure application programs to be developed through easy-to-use APIs linking the application to a set of routines and modules that perform security-related tasks. RSA BSAFE SSL-C and RSA BSAFE WTLS-C are closely integrated and the API is very easy to use, this makes developers able to plug-and-play their software into any application. Entire WAP applications from the Web server, through the WAP gateway to the WAP client can be rapidly secured. It is possible to develop a multitude of applications for WAP. Here is an example of a few applications built with RSA BSAFE WTLS-C SDK [25]. Browsers Financial applications Gateways e-Commerce Access to corporate data Information services Healthcare Mobile devices

RSA BSAFE WTLS-C uses the WTLS v1.1, class 1-3 standard and for certificates it uses the ANSI X.509 v 3. The SDK it supported by most operating systems. Win32 Linux Solaris Windows CE HPUX Palm OS Additional platforms available upon request [25].

53

MultiPrime MultiPrime is the new technology designed to provide wireless and embedded device manufacturers, the breakthrough they need to offer high-speed performance and enhanced security, on small footprint devices such as mobile phones, pocket PCs and personal digital assistants. The RSA algorithm has traditionally used two prime numbers to form a large, unbreakable key. The MultiPrime technology, which was developed and patented by Compaq, uses three or more prime numbers and parallelism to provide higher performance through smaller mathematical operations. Initial implementations of the new technology have already achieved more than double the performance of prior techniques, and further optimisation and combination with other techniques may enhance the achieved acceleration. MultiPrime increases the performance of RSA encryption operations by as much as 500 percent. As a result, wireless device users dont have to choose between performance and security. For the first time, they have access to both critical functions in a single device. MultiPrime allows RSA signatures to be performed on the wireless device without delaying service, signatures that provide critical functionality like client authentication and nonrepudiation. This technology combined with assembly code optimisations, supports complete client and server processing of both X.509 and WTLS formatted certificates with RSA signatures [25].

Figure 6.2.1 RSA BSAFE WTLS-C functional layers [25]

54

6.2.4 BSAFE SSL-C and SSL-J


Overview BSAFE SSL-C and SSL-J are security protocol components for C and Java. It is a software development suite for building Secure Socket Layer (SSL) security into enterprise-to-enterprise and commercial Internet applications. SSL-C and SSL-J offers a comprehensive set of security software components for building SSL-enabled applications, combined with the full suite of RSA algorithms. SSL is the most widely used protocol for transmitting data securely over the Internet and addresses the fundamental Internet communication requirements of authentication, confidentiality, and message integrity. The SSL protocol has become the de facto standard for securing e-commerce. It provides protection against eavesdropping, tampering, and forgery. Clients and servers are able to establish a secure link, or "pipe" across the Internet to protect the information being sent and received. SSL-C an SSL-J enables developers to easily embed SSL-based encryption capabilities into applications. As a result, developers can embed high levels of privacy and security in a wide range of client/server interactions without being encryption experts. SSL-C and SSL-J contains compliance with: SSLv3 SSLv2 Transport Layer Security (TLS) 1.0 [25]

Figure 6.2.2 RSA BSAFE SSL-C and SSL-J functional layers [25]

55

The SSL-C toolkit provides an Application Programming Interface (API). The API is an easy-touse interface to the underlying SSL toolkit library. The library includes routines for encryption, message digests and certificate management. The API provides a consistent high level interface to a set of read/write data primitives via a set of functions. The functions use familiar read/write system call semantics for easy incorporation of the library into existing applications. Functions have default values, which may be overridden, and standard error handling. The protocol infrastructure, upper layer services and underlying cryptographic algorithms and certifications can pose a time-intensive project for any development organisation. The RSA BSAFE SSL-C and SSL-J software developer kits (SDK) provides developers a product that includes everything needed for delivering SSL-enabled applications. SSL-C's support for X.509 certificates provides interoperability with Netscape and Microsoft web browsers and servers, and certificate authorities like VeriSign and the RSA Keon Certificate Server. Developers can save an estimated 3-6 months by using SSL-C or SSL-J when developing their SSL solution. The SDK provides extensive sample code, in-depth documentation, and technical support, which ensure fast development without having to become a cryptographic expert [25]. Here are a number of secured Internet applications that can be developed using either SSL-C or SSL-J: Wireless security Cell phones Personal digital assistants Network infrastructure Financial Secure account status Mortgage status Credit information Healthcare Secure patient records Secure health claim status

SSL-C and SSL-J supports the following platforms: Windows 95, 98, & NT Linux FreeBSD QNX HP-UX SCO UNIX Solaris VxWorks Additional platforms available upon request [25].

56

6.2.5 RSA BSAFE Crypto-C and Crypto-J


Overview RSA BSAFE Crypto-C and Crypto-J includes cryptographic components for C and Java. It allows privacy and authentication features to be built into virtually any application with optimised performance. Crypto-C and Crypto-J have optimised support for the Intel Itanium and Pentium 4 processors. Combining the strengths of MultiPrime and Intel processor optimisations, developers can expect performance improvements by as much as 500% over earlier versions of Crypto-C or Crypto-J. New algorithm optimisations for Sun's SPARC and HP's RISC are included in the SDK to improve the performance of applications. It includes modules for popular security encryption techniques, such as RSA DES RC2 RC4 RC5 RC6 ECC (Elliptic curve cryptography) SHA1 MD5 Supports digital signatures and certificates

Crypto-C includes all popular secret and public-key encryption algorithms, including the RC4 stream cipher, the high performance RC5 block cipher, the next-generation RC6 block cipher, the trusted and time-tested RSA Public Key Cryptosystem, MD5 and SHA1 message digest routines and improved routines for RSA public key generation, primality testing, and pseudorandom number generation. Crypto-C and Crypto-J also includes a complete set of elliptic curve cryptographic (ECC) algorithms for key agreement, encryption and digital signatures. RSA Security's fast-performing and low overhead public-key ECC algorithms are ideal for memory and performance constrained devices such as pagers and embedded systems. RSA BSAFE Crypto-C and Crypto-J includes PKCS#11 and BHAPI (BSAFE Hardware API) support to allow communication with hardware such as smartcards for secure key storage and cryptographic accelerator cards for performance improvements. The SDK provides extensive sample code and documentation to ease implementation. Programmers can save time developing secure applications without a background in cryptography, mathematics or number theory. Crypto-C and Crypto-J includes a wide range of data encryption and signing algorithms and ensures that you can talk securely to just about anyone, anywhere [25].

57

Crypto-C and Crypto-J is available on several different platforms: Windows 95, 98, NT, and 2000 Sun/Solaris HP-UX Linux AIX

Figure 6.2.3 RSA BSAFE Crypto-C and Crypto-J functional layers [25]

58

6.3 Summary of the product evaluation


In our survey we found that none of the products matched our requirements. The products could be used as developers kits and aid development but a complete solution to our problem could not be found among the evaluated products. We were looking for a product that could cope with our problem requirements but our problem was too complex and specific for the products we evaluated. The two companies products were quite similar since they both used WTLS as their foundations. Baltimore offered both complete products and developers kits where RSA Security only offered the different developers kits. We found out that the complete products Baltimore offers were not useful in our scenario. However we got some of the ideas from these products.

59

7. Solution
7.1 Overview
The solution to the problem defined in the problem discussion can lead to a lot of different alternatives, depending on what the requirements are that apply to the model. First of all we decided that the existing technology should be used to avoid that new mobile units must be developed. Since this ad-hoc network should be secure we thought that it would be best not to involve a third party such as a mobile operator. Otherwise the solution could have involved the existing network of the mobile network operators and to send certificates over the air. This could include a VPN over the Internet but with current transfer speed this would not be efficient enough. Since we will not use a third party network our approach makes it necessary to use an antenna not present in the environment previous to the ad-hoc network being connected. This means that the antenna has to be brought to the location in order to be able to communicate. Also we only include authentication and leave encryption to the already existing GSM technology. However, encryption can be used if the communication central demands it but it is not mandatory. This means that only the private key will be stored at the mobile unit. This system will allow two kinds of communication, voice and text. Once the mobile unit is registered in the PKI it can phone any participant. If a text-message is send it will be signed by the communication central. All this leads us to the three components in the PKI we propose. 1. Communication central 2. Headquarter 3. Mobile devices

WAP

TETRA

Headquarter

Computer

Computer

Directory

Directory

Figure 7.1 Our solution

60

Our solution will be presented in theory and also be described as a real life scenario. As example scenario we will use an emergency where the personnel from different government instances has to be able to communicate with each other.

7.2 Communication central


The communication central, as we see it must be a big vehicle like a truck or a bus. This vehicle must have antennas for each kind of communication medium used, WAP and Tetra. In addition this vehicle will function as CA and must therefore incorporate computer equipment as well as human personal. Inside the vehicle a directory of the users certificates must be present, for example a X.500 directory. This is where the human personal comes into the picture. Before the connection of the network this person must decide who can be a part of the network. First the administrator downloads a list of people that are going to participate in the network from the headquarters. The administrator can add or remove users later on in the process if needed. Since the communication central will work as a CA the administrator will be able to add a user without a certificate and generate a new certificate. When a mobile unit has registered itself in the PKI the communication central will be responsible to distribute the users involved in the network to each one of the participants. To make this update reality the communication central can broadcast the numbers and identity of the users to all in the network. Naturally, each time a new user is registered, the list must be updated. There are a number of different operations that the communication central must be able to cope with. 1. Maintain a directory with certificate and additional information about the user. Also it must incorporate a CRL to make sure revoked certificates are not used. This directory could be a X.500 or LDAP directory. 2. Add and remove a user from the directory both prior to the connection and during it. Users should be able to register themselves into the PKI both through mobile devices and direct interaction with the administrator. 3. Generate certificate if needed. This is necessary if a user lacks a certificate. 4. Establish a connection with the headquarters in order to be able to exchange information. 5. Manage Phone to Tetra connection. When a phone wants to communicate with a Tetra unit the information sent from the communication central must be send through the Tetra-antenna and vice versa. 6. Distribute the participants contact information to each an every one registered in the PKI The directory that exist at both the communication central and the headquarter will look something like this: Certificate ID 134Hj395120 671gD32456 126hJ32455 Mobile unit specific 0709-1234567 sim12345678 tetra12249834 PIN code Gh43743 Yd46kjs7 GD765hg

Of course there will be checkboxes and other utilities to make it possible to activate and inactivate users as well as add and remove user.

61

7.3 Headquarters
At the headquarters a computer with a directory similar to the one in the communication central will function as the main directory. The big difference between the directories is that the directory at the headquarters will contain a lot more information than the one in the communication central. The directory at the headquarters is the most important one and is therefore placed at a safe spot and are monitored and backed up often. This directory consists of all certificates of people that could be involved in the communication through the communication central. Before the ad-hoc network is set up, people at the headquarters decide which people in the directory that will be allowed to enter the PKI. If personnel at the headquarters wants to alter their initial choice this will be possible since the communication between the headquarters and the communication central is maintained. Updates from the headquarters can be sent at a certain time interval.

7.4 Mobile devices


In this section we will explain how the different communication mediums will communicate among each other and with other mediums. We have chosen to divide up the communication into these sections. PDA to PDA Tetra to Tetra PDA to Tetra Outbound communication

In each section there will be a description of the solution and a real life example. In our solution the word PDA can be either a mobile phone or a pocket PC but since they will both use WAP as their medium will we describe them both in the same section.

7.4.1 PDA to PDA


There are different ways to establish a mobile PKI between mobile phones, depending on what kind of technology the phones incorporates. At the moment there are mobile phones with WAP and those with only GSM. It is possible to create an environment with both kinds of mobile phones. Naturally its is easier and more efficient to take advantage of the WAP technology in a phone since WAP have components that are suitable for this kind of communication. One of those components is WTLS that is the wireless worlds answer to TLS. WTLS offers the same services as TLS but have been developed with the restriction of a wireless network in mind. If a mobile phone lacks WAP it can still be part of a wireless PKI. This is done by utilise the SMS service as a channel to establish a secure connection. One example of this is Baltimores Telepathy suite. When it comes to handling certificate we think the most sensible method is to use certificate IDs so this is the solution we will concentrate on. Instead of storing a certificate on a mobile phone with limited memory the certificate is stored elsewhere and an identifier is stored on a mobile phone. This way a user can have several certificates and still have a phone with memory left for phone-numbers. The certificate ID is used to identify the users certificate. Since bandwidth in a mobile network is limited sending certificate can take quite some time. To avoid this all processing can be done at a communication central where all the certificates stored. By doing this the mobile phones work as usual without any setbacks in memory and processing power. Whenever a phone needs the certificate it uses the certificate ID instead and then all the 62

processing is done at the communication central and the result is then send to the intended recipient. Of course this kind of approach demands some kind of proof that the right phone gets the right certificate. To do this the user enters a PIN-code and the phone sends a unit specific identifier, the certificate ID and the PIN-code entered. The feature with entering the PIN-code can be achieved using WMLScript. At the communication central every certificate have a unit specific identifier and a PIN-code tied to it in a directory. The computer then checks the validity of the PIN-code and if the phone is the owner of the specified certificate. This so-called processing computer is in reality a CA that administers the wireless network. On the CA the revocation lists of the revoked certificates should be present. Since everything is stored at the CA and all processing takes place there online checking in the CRL will be possible. This CA is of course the communication central. Real life example. This scenario involves police officer John Doe arriving at the location of the emergency. It is assumed that he exists in the communication central directory and that the private key is present on the mobile phone he is using. The first thing he has to do is to change which operator the phone is using. If he is within the range of the communication central the ad-hoc network will appear next to any other operator. After choosing the new network he will be prompted to enter a PIN-code. Next the phone sends the PIN-code, certificate ID and information specific to his mobile phone. Before the information is send the phone signs it with the private key. The computer in the communication central then processes the information and checks the validity of the data by comparing it to the directory. If the validation is successful John Doe is let into the network and can communicate with any other of the participants. When John Doe wants to send a message to another of the participant he writes the message and specifies who it is intended for. If the communication central demands it the mobile phone will encrypt the data send with the private key. The only instances that have the public keys are the communication central and the headquarters. The communication central decrypts the message and check who the recipient of the message is. Before sending the message to the recipient the message is encrypted with the recipients public key. This way only the recipient can decrypt the message. When the message arrives at the recipients mobile phone it is decrypted and the user can read the information and be sure that it came from the right person. This process is reliable since the communication central is acting as CA. Every message sent goes through the communication central and are validated there. There is no option of direct communication between the peers. Since this is the case the only real sender to a mobile phone is the communication central. When a unit wants to communicate with its peer the messages are relayed through the communication central to ensure the safety of the ad-hoc network.

7.4.2 TETRA to TETRA


There are several different ways to communicate between two TETRA handsets. TETRA combines the best features from mobile radio, cellular telephony and text messaging. TETRA handsets have SIM cards that are designed as an inseparable part of the functioning radio. This SIM-card will store the certificate ID for that specific handset and its unique private key. By having only the certificate ID in the handset instead of the whole certificate, the handset will not have any setbacks in either memory or processing power. The handset uses the certificate ID instead of the certificate. The right certificate corresponding to the certificate ID is always stored in the communication central. When a user wants to register a new TETRA handset in the PKI, the communication central has to be informed. If the handset does not already have a certificate ID and a private key

63

in it, then it has to be presented to the communication central. The personnel in the central would then give the handset a unique certificate ID, a private key and then register it as active in the PKI. If the handset already have a certificate ID the registration can be done over the network. To do this the user has to enter a PIN-code in the TETRA handset. If the PIN-code is correct, the handset will send the mobile units specific identifier, the certificate ID and the PIN-code to the communication central. The information sent is there checked, and if it is all correct the handset will be activated in the PKI. There are two ways for the communication to flow from one user to another. The communications is made through the common air interface (CAI). Through this interface there are two modes, trunked mode or direct mode. In direct mode the handsets talk directly to each other. This means that the communicating handsets can not be to far apart, or else communication will be lost. Authentication will not be possible in this mode. A unauthorised individual could in this case enter the emergency area with a TETRA handset set to direct mode and would then during a broadcasting call be able to listen to classified information or even worse send false information to the emergency personnel. In the trunked mode all communication goes through a TETRA basestation and is from there replicated and sent to the handset that was the intended recipient. This mode is better suited for our PKI solution because authentication is possible. In this way all TETRA handsets are registered in the communication central and the TETRA base station can be situated in the communication central. If a call from handset A is placed to handset B, the base station takes the call, checks the identity of A in the register, checks who the recipient is and if it exists in the register. If it does the call is transferred to handset B. Every talk session goes through the basestation at the communication central. When a broadcast call is made, the call is sent to the basestation and from there the call is sent to every handset in the registry. This means that no one can enter the emergency area and listen in on what is going on. The only way to be able to do this is to steal one of the registered handsets. But when a handset is noticed stolen, it is reported to the communication central and the handset is deleted from the registry. That means that no calls or messages will be sent to that particular handset anymore. A TETRA handset can store hundreds of predefined text messages. The user can just choose a message from a list, with the up or down arrow button. A user can also define their own text messages or write text messages similar to the way text messages are created in GSM. The text messages can be sent either to one specific recipient or as a broadcast message that will be received by all the handsets in the TETRA network. This could be very useful in an emergency situation where as an example the emergency leader want all the staff to find something out at the same time, like the wind is changing from south to west, which would be important in a fire situation. Every TETRA handset would have a private key stored in the handsets and the public key would be stored in the communication central. When a message is sent, it is encrypted with the handsets private key. The communication central then receives the message decrypts it and checks who the intended recipient is, it then encrypts the message with the recipients public key and sends it along. When the recipient receives the message it is decrypted with the private key and read by the correct person. Encryption like this is optional, it is also possible to send messages without any encryption at all. Real life example Five firetrucks arrive at the scene of a large forest fire. There is one team in each truck. Each team has a team leader with 6 fire fighters under his command. One of the team leaders is also the leader of all the firemen. A communication central is also on the scene. There are 35 TETRA handsets among the fire fighters and all of them are registered in the communication central

64

directory. When the leader of the fire fighters wants to send an encrypted broadcast message to all the firemen, he writes the message, finds broadcast message in the menu of the handset and presses send. The message is then encrypted with the private key of the handset and sent to the communication central. The communication central then decrypts the message with the public key and therefor can be sure that the message is really sent by the leader of the fire fighters. It then encrypts the message with all the other public keys and sends it on to everyone in the directory. When a fireman receives the message it is decrypted with the handsets private key and then ready to be read. The fire is hard to slow down and another firetruck from a different area is arriving. The new fire fighters need to be able to be in contact with the other firemen so they must be registered in the PKI. The new team does not exist in the communication central directory. The communication central connects to the headquarters and downloads the certificates of the new team. The TETRA handsets are assumed to have both certificate ID and private key stored in each of them. Everyone in the new team selects the ad-hoc network on their handsets and has to enter a PINcode, when the PIN-code is entered and ok is pressed the PIN-code, unit specific identifier and certificate ID is sent to the communication central. Before it is sent it is signed with the handsets private key. When the communication central gets the information it decrypts the information with the public key, making sure it is sent from the correct handset and checks that the certificate ID, PIN-code and unit specific identifier matches the directory. If everything is correct the handset is activated in the PKI and ready to start communicating with the rest of the TETRA handsets.

7.4.3 TETRA to PDA


TETRA and what can be called PDA is two totally different technologies. There is no way for a TETRA handset to directly talk to for example a GSM phone. There are two possibilities for communication between these two technologies. Both TETRA and PDA uses WAP, which is one way to solve it. Or another solution would be to have a converter stationed in the communication central that converts TETRA into GSM or the other way around. In our definition a PDA can be a phone or a pocket PC. It would be possible to use both voice and text messaging from TETRA to a phone, and from TETRA to a pocket PC only text messaging would be possible. If we decide to talk about PDA as a phone from now on it will be easier to follow. If a TETRA handset and a GSM phone are both connected to our PKI network, they will both have a unique mobile unit specific identifier, a certificate ID and a private key stored in the each handset. We begin describing how a voice message work. The TETRA handset would be sent a special list of all the GSM phones available in the PKI. They will not have the same number as they usually have because they are using a different technology on a different antenna. When a user wants to talk to a GSM phone from his TETRA handset he will dial the number of the intended recipient that was sent from the communication central. The communication central converts TETRAs ACELP (Algebraic-Code-Excited Linear Prediction) speech coding to GSMs RPE-LPC (Regular Pulse Excited - Linear Predictive Coder with a Long Term Predictor Loop) and sends it to the GSM phone. This conversion takes place continuously during the call. TETRA can use something called air-interface encryption to encrypt speech and signaling, only the registered users of a network knows the cipher key and can listen to what is being said. There is therefor a way to securely encrypt the speech from the handset to the communication central and from there send it on to the GSM phone relying on the existing GSM encryption. The text messaging from a TETRA handset to a PDA is a bit easier than speaking between them. If a TETRA user wants to text message a GSM user for example, then the message is sent with

65

the special GSM addresses delivered from the communication central. The message can be encrypted or sent unencrypted. If it should require encryption the TETRA handset encrypts the message with its private key and sends it to the communication central. When the communication central intercepts the message it is decrypted with the TETRA handsets public key and before sending the message to the recipient the message is encrypted with the recipients public key. By doing this, the only one that can read the message is the intended recipient. When the message is received it is decrypted and the user can read the information and be sure that it came from the right person. Real life example In this scenario we have a large accident that involves several different rescue organisations. There are TETRA radio handsets, GSM mobile phones and pocket PCs involved. All of them have to be able to communicate with each other without any unauthorised individuals listening in or sending false messages to make the rescue operation harder. We have a situation where a plane has crashed just outside a village. There are crowds of curious people building up around the accident area, there are also newspaper and TV reporters present. Rescue personnel present are firemen, ambulance personnel, police, civil defence and people from the commission of inquiry into the aircraft accident. The communication central is also present. Let us assume that police, firemen and ambulance personnel are already registered in the communication central directory and activated in the PKI. The civil defence is called in to handle the crowd and search the area for parts of the wrecked plane. The only one from the civil defence unit that will enter the PKI is the unit leader. He has a GSM mobile phone with WAP. To be able to activate the civil defence leader in the PKI he has to personally appear at the communication central and there his GSM phone is registered in the directory. A certificate ID and a private key are uploaded to his phone. The ad-hoc network is chosen in the menu of his GSM phone and he is prompted to enter a PIN-code. When the PIN-code is entered and certificate ID, unit unique identifier are signed with the private key and sent on to the communication central, he is marked as active in the PKI. Let us say that the police leader (P) wants to talk to the civil defence leader (C), P uses TETRA and C uses GSM. P, who since C has been added to the PKI, has been sent an updated telephone list with Cs number in. P chooses C in his telephone book and presses call on his handset. The call is received at the communication central and is checked to be coming from an active PKI member. The intended recipient is found to be a GSM phone also registered as active in the PKI. Ps call is transferred through the ACELP to RPE-LPC converter and C receives the call.

7.4.4 Outbound communication


Outbound communication is defined as communication from inside the PKI to some recipient outside the PKI or the other way around. We have limited the communication in and out of the PKI to go through the connection between the communication central and the headquarters and from there out of the PKI. Because of this we will limit the communication to text messages since ordinary voice communication would be far to complex to handle when it is going through the connection with the headquarters. There will be no way to contact the communication central directly from outside the PKI. The headquarters will be located at the same place all the time and the communication central will be able to move anywhere it is needed. In our solution we have decided to use GSM to establish a connection between the headquarters and the communication central. To make this work there has to be an agreement between the government and the existing mobile operators. Two unique numbers must be created so they can be dialled in every GSM network, much like

66

the emergency number 112. The first number goes to the communication central and the second number goes to the headquarters. To maintain a high level of security the communication central is the only one who can call the headquarters and vice versa. This channel between the headquarters and the communication central is a vital part in the system since the headquarters has to be able to send information about the users in the PKI. Naturally the information being sent must be heavily encrypted with some kind of symmetric encryption algorithm. To make this possible WTLS in WAP can be used to maintain the connection. Since this is used a new secret key can be used every time a connection is established. There is also an option to change the secret key during the transmission. In our solution we will limit the communication between the headquarters and persons outside the PKI to secure computer communication. To be able to communicate with the headquarters the computer must be connected to a VPN. This VPN consists of the headquarters and any authorised personnel outside the PKI. We exclude everything other than computer communication because we feel that it is not safe enough and that authentication is not satisfactory. If an authorised person wants to send a message to someone inside the PKI they have to specify inside the message who the intended recipient is. The message is then delivered through the VPN. When the message is received at the headquarters it is automatically sent to the communication central. The headquarters will also send information from the directory about the person who sent the message. The communication central then signs the message with the recipients public key and delivers it. Along the way the message is subject to auditing from predefined functions. These functions will make sure that the message syntax is correct. Any failure will result in the message being rejected and the sender being informed that the message did not meet the requirements. Another feature these functions carry out is to parse the message so that it can be sent like any other message inside the PKI. This means that the message the recipient receives states who the sender of the message is.

PKI
Communication Central

VPN
Headquarters

Computers

Figure 7.2 Outbound communication Real life example This scenario involves a hostage situation. An armed fugitive has taken a family hostage in their home in a rural area. Both police and ambulance personnel are present on the scene. The hostage negotiators are trying to establish communication with the armed man. The police chief sitting in his office at the police house wants to send the policeman in charge on the scene a message. The message includes the approval to shot the armed man. This message can under no circumstances be read by anyone else than the policeman in charge. The police and ambulance personnel are all active in the ad-hoc PKI around the house. The police chief is

67

connected to a special VPN that just certain persons in the top are connected to. These persons are all registered in the directory of the headquarters. The message is written on the computer and signed with the private key of the police chief. The intended recipients name is stated in the beginning of the message. It is then sent to the headquarters address where it is joined with information about the sender and then encrypted with a secret key. The encrypted message is then sent on to the communication central via the special telephone number associated with the central. When the message is received at the communication central it is decrypted with the secret key. The message is run through a parser to check that the syntax is correct both at the headquarters and at the communication central. The communication central signs the message with the recipients public key and then sends it forward. When the policeman gets the message it is decrypted with the phones private key and he can read the original message and see who it is sent by. To notify that he has got the message the policeman sends a message back. When the communication central gets the new message it is encrypted with the secret key and sent to the headquarters number. The headquarters decrypts the message with the secret key and uses the recipients public key to encrypt it again. It is then sent through the VPN and the police chief can finally read the message.

7.5 Developing the system


There are both complete solutions and developers kit on the market today. Which one to choose depends on the level of special features needed. If the requirements are basic and a complete solution is already available, there is no need for the developers kit. But on the other hand if the system has to be custom-made the developers kit is the better choice. This is the case we have in our solution since there are no system capable of all the features we want. If this approach is used then the system can be altered later in order to meet changing requirement. Generally the system developed with developers kit will meet the requirements more accurate than a generic made solution. This because the custom-made solution will exclude redundant features and only focus on the matters at hand. We have in a previous chapter audited what two companies have to offer. Baltimore has both a developers kit and generic solutions. RSA offers developers kit but can deliver a complete solution based upon the developers kits. As stated above our solution demands a custom-made system and therefore a developers kit could be used to create this system. Basically these kits are packages that can be used in major programming languages such as Java and C++. By using these packages the programmer get access to operations that are based on WTLS. In our solution the communication central will contain an implementation using some kind of developers kit. By using developers kit there will be no need to program the WTLS operation yourself. Instead the predefined operations that makes use of WTLS can be used as the programmers see fit.

7.6 Security and threats


The security in this system is of course a very important aspect. First of all we have decided not to make encryption mandatory and rely on the GSM and Tetra cryptography. As mentioned in previous sections it is possible to use encryption but it is not necessary according to us. When a network like this is established with its own antennas the risk of eavesdropping is lower than if we would have used an existing antenna. Even if someone is trying to eavesdrop they still have to crack the cryptography of GSM and Tetra. As we see it the biggest threat against this network is if the communication central is compromised, since most of the processing is done here. Inside the communication central a lot of secret information will be stored so it is vital to keep this component as safe as possible. It will not be easy to locate the communication central, since 68

it is a mobile unit which can position itself wherever it wants as long as its close enough to the users. Another thing that makes it hard to locate the communication central is that no one is supposed to know when the network is going to be established except the involved personnel. Since the persons that will be a part of the PKI will belong to government instances it is probably safe to assume that these people will maintain discretion. The very foundation of the system is based upon that the people involved will not contact the press or any similar instance. Another issue is if someone steals a mobile device and a SIM card. If this happens and the person is currently in the vicinity to the communication central, an attempt to register into the PKI can take place. The user then first has to enter the correct pin-code to be registered into the PKI. Since all the pin-codes are stored in the directory in the communication central it cannot be retrieved from the mobile device or the SIM card itself. These pin-codes will be long enough and contain a lot of different characters and numbers to make sure it is nor possible to guess a pincode. In addition to this a maximum number of attempts will exist to make sure the person can not use a brute force method to get access to the PKI. If the communication central get the information that a mobile device has been stolen, the unit specific identifier will be revoked. Also if a mobile device acts suspiciously, it is possible to revoke the privileges for this unit. Jamming is another threat that could cause problems. To be able to jam the communication in our solution you would have to jam a big range of frequencies since both there are both communication with Tetra and GSM. This makes it hard to know exactly what frequencies to jam. Another threat is traffic analysis but this does not really apply to our solution since the connection and location of the ad-hoc network is not permanent.

69

8. Conclusion
This chapter includes a summary of our solution, what we might expect from the future and our own reflections.

8.1 Summary
Our task was to give AerotechTelub a suggestion on how to build a mobile PKI system. We started to investigate different technologies and products to get a better insight in the area. By taking the initial problem and limitations in consideration, we found that the solution with a mobile communication central would fit this particular environment best. The communication central makes our solution very flexible because of its mobility. Also a vital part of the PKI is the headquarters where all personal information is stored. We chose to divide the communication into four different cases. PDA to PDA and TETRA to TETRA use their incorporated technology while TETRA to PDA has to use a specially built converter. With PDA, we mean both mobile phone and pocket PC. Finally the outbound communication is limited to messages over a secure VPN of computers. In all, we can say that our system is one solution on how the problem can be solved. Of course there alternatives, but we have chosen this approach.

8.2 Future expectations


At the time of the creation of this report the development of anything related to mobile network and mobile PKI is going very fast. There are many big companies involved, in fact every company with mobile communication as business wants to be a part of the development. The biggest actor in the market right now is the WAP Forum that tries to standardise as much as possible so that it will be easier for companies to participate. Most of the big companies are represented at WAP Forum. Also there are a lot of projects being developed at the companies. We have looked in to some of these and two of them are a part of this report. Generally we can say that much of the products being displayed on the companies websites are under constant development.

8.2.1 Network
Soon a new kind of mobile network will be built. This is called UMTS/3G and will open new possibilities with its higher performance. 3G will be capable of much higher transfer speed than GSM. This speed improvement means that the restrictions on mobile PKI will diminish. Compromises like the one with the communication central that process most of the calculations will not be needed. Instead the certificate can be sent over the air.

8.2.2 Mobile phones


In this area a lot of development is being done. One thing that will open new possibilities is the WIM (Wireless Identification Module). The WIM will store the identity of the user and will assist in calculations such as encryption and authentication. This new identity can be used in conjunction with an ordinary SIM, or it can be used separately. If this becomes a widespread standard and most of the mobile phones incorporate WIM, then we will have a much better environment for mobile PKI than the one we have today.

70

8.2.3 Authentication
In our solution we have used a PIN-code to make sure the only person that can register the device into the PKI is the person who knows the PIN. In our solution we think this method gives acceptable safety since the PIN-codes have to be of a fixed length and contain predefined characters. However, the better the authentication the safer the network, and a component that probably will be widely accepted in the future is the biometrics system. These systems include methods such as retina scan and finger print reader. The most plausible method in our solution is the fingerprint reader. This because research on the use of fingerprint readers in conjunction with mobile units has come little further than the retina scan. Another issue is that it is more convenient and easier to use a fingerprint reader. The fingerprint reader can then be brought along with the mobile device if authentication is needed. An alternative is to have a fingerprint reader built into the mobile unit. In the future we think that authentication techniques that are built upon biometrics are going to replace the PIN-codes and passwords. This would give a much greater guarantee that the authentication is without flaws.

8.3 Reflections
First of all we must say that we have had some difficulties to gather material because of the constant development in this area. We have requested a lot of information from companies but the companies have been reluctant to hand out information about their products. That is why we focused our efforts on the two biggest companies, Baltimore and RSA Security. We discovered that it was much easier to get information from these two. We have chosen the structure of this thesis based on what we thought we needed to create a solution. The PKI section is a brief overview but is still a vital part in the thesis. We also chose to describe technologies we thought could help us develop a solution. The companies products were investigated so that we could get a picture of what the current situation looks like. Also this investigation gives us information if it is possible to solve this problem with existing developing software or complete solution. During the development of the thesis we have been free to structure the work as we saw fit. AerotechTelub did not insist that we should carry out the work at a specific place, instead we been able to be flexible in where we chose to work. Our supervisor has been very interested, positive and flexible and has constantly supplied us with new information. We think that this has been a very interesting subject to investigate and we have learned a lot of new things. The thesis has given us insight in an area in which we had limited knowledge before.

71

References
Litterature [1] [3] Pertti Jrvinen, On research methods, Tampere, Finland, ISBN 951-97113-6-8 Stallings William, 2000, Network security essentials Applications and standards, Prentice Hall

Articles & Journals [5] [8] [9] [10] [11] [12] [13] [14] [20] [21] TrueTrust Ltd, 2000, Introduction to PKI: Part 1-3, TrueTrust Ltd ETSI, 1998, TErrestrial Trunked RAdio Tait Electronics, Digital trunked radio system Godfrey Phil, 2000, Key areas for development in the TETRA world Schmidt Hinrich, 1997, A detailed look at data communications in TETRA Jacobs Gavin, 1999, Using TETRA in a Scada environment Micheli Mario, 2000, Effective use of TETRA Cadzow Scott, 1999, The role of SIM cards in application development Baltimore Ltd, 2000, Telepathy WAP Security Toolkit (WST), Baltimore Ltd Baltimore Ltd, 2000, Telepathy PKI Digital Signature Toolkit (PDST), Baltimore Ltd Baltimore Ltd, 2000, Telepathy WAP CA (WAC), Baltimore Ltd Baltimore Ltd, 2000, Telepathy PKI Registration System (PRS), Baltimore Ltd Baltimore Ltd, 2000, Telepathy PKI Validation System (TVS), Baltimore Ltd

[22] [23] [24]

Internet [2] [4] [6] AerotechTelub (2001-05-30)


http://www.aerotechtelub.se

The Lightweight Directory Access Protocol: X.500 Lite (2001-05-30)


http://www.stanford.edu/group/networking/directory/doc/ldap/ldap.html

Understanding X.500 (2001-05-30)


http://www.salford.ac.uk/its024/Version.Web/Contents.htm

72

[7] [15] [16] [17] [18] [19] [25]

RFC2459 Internet X.509 PKI certificate and CRL profile. (2001-05-30)


http://www.faqs.org/rfcs/rfc2459.html

Nokia Professional Mobile Radio (2001-05-30)


http://www.nokia.com/networks/pmr/

WAP WTLS (2001-05-30)


http://www.wapforum.org/

WTLS The security layer in the WAP stack (2001-05-30)


www.keyon.ch/en/publications/infosec_wtls_keyon.pdf

Security in WTLS (2001-05-30)


http://www.hut.fi/~jtlaine2/wtls/

Baltimore Technologies (2001-05-30)


http://www.baltimore.com/

RSA Security (2001-05-30)


http://www.rsasecurity.com/

Unreferenced material Stephen Farrell, 2001, Outlining Wireless Public Key Infrastructure, Baltimore Ltd Chalmers Alan, F., 1994, Andra upplagan, Vad r vetenskap egentligen?, BokfrlagetNya Doxa E.C. Cuff & G.C.F. Payne, 1996, Samhllsvetenskapliga perspektiv, Bokfrlaget Korpen Jamie Lewis, Network strategy overview: Public Key Infrastructure Architecture, The Burton Group ETSI, 2000, Electronic Signature Formats, ETSI TS 101 733, ETSI TETRA Memorandum of Understanding (2001-05-30)
http://www.tetramou.com/

The Internet Engineering Task Force (2001-05-30)


http://www.ietf.org/

73

Matematiska och systemtekniska institutionen SE-351 95 Vxj tel 0470-70 80 00, fax 0470-840 04 www.msi.vxu.se