Professional Documents
Culture Documents
Juni 2001
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.
10
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.
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
Mathematical approaches
Conceptualanalytical approaches
Artifactsbuilding approaches
Artifactsevaluating approaches
Theorytesting approaches
Theorycreating approaches
12
13
14
15
16
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
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.
Entry
Entry
Entry
Entry
Entry
Entry
Attribute
Attribute
Attribute
Attribute type
Attribute value(s)
Alias
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.
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
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
23
Directory User
Client (DUA)
Server (DSA)
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
Signature
All versions
Version 3
Period of Validity
Version 2
Issuer Name
Version 1
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].
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.
X.25 Internet
OMT
OMT
ISDN
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.
Public access
PMR/Group Mobility
DIIS TETRA
Wireless Telephony
DECT
Local area
Wide area
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].
Circuit Mode
Packet Mode
Packet Mode
Connection oriented IP
Connection less
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
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].
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
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
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
Handshake Protocol
WTLS
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
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
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
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]
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].
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
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].
46
Web Interface
CA CAO
Gateway
RA RAO
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].
47
WTLS
WAP
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
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
50
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].
52
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].
54
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
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
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
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.
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.
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.
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.
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.
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.
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.
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.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.
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
72
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/
73
Matematiska och systemtekniska institutionen SE-351 95 Vxj tel 0470-70 80 00, fax 0470-840 04 www.msi.vxu.se