Technische documentatie over TETRA door kpmg

KPN-TELECOM document about: TETRA technical information
1. Introduction
During the standardisation phase of TETRA, which now has reached its finale stage, a large number of security features was specified. The standardised TETRA security features mostly aim to provide a high level of air interface security and access control. TETRA is designed to fulfil the requirements for a broad range of user groups including public users with limited security requirements and emergency service users often with very high security demands.

A detailed overview of the TETRA security features is given in [1]. The standard security integrated in TETRA comprises:

Over the last year some additional work was done. First of all a mechanism for the security for TETRA SIM card (SIM stands for Subscriber Identification Module and it is a smart card containing the authentication key) was specified. This mechanism can be used to ensure that information can be transferred from the SIM to the mobile equipment in a secure way. Furthermore the standardisation of a mechanism for lawful interception was finalised. Such a mechanism will be required for public TETRA services in many countries and the standardisation of this mechanism will reduce the costs for its implementation.
The standardisation of security in TETRA is now finalised, perhaps with the exception of security for some new TETRA features. This does not mean that the work on security for TETRA networks is completed. It is a fact that TETRA is a system with a higher security potential than any other comparable system. But it is also a fact that the final level of security of TETRA networks also will depend on implementation issues, such as key management, security policy and related issues. The security level of a final implementation of each system is limited by the weakest link in the security chain.
The objective of this paper is to illustrate the above statement by describing in more detail a number of security issues which are relevant for implementation of TETRA networks.
Section 2 of this paper will address the general issues related to Key Management and Security Policy. Sections 3 and 4, respectively, describe some specific issues for the TETRA Key Management and Security Policy.

2.     A General Key Management Framework and Security Policy
The problem of key management might best be illustrated by the following example. Suppose you have a large amount of money or jewellery or other valuable things stored in different places and you need to put them in some secure place. So you decide to buy a safe and put them in there. Does this solve the problem?  Only to some extend because now the problem is replaced by another problem: what to do with the key and/or code to the safe. In a way the problem is more easy, because the key seems more easy to manage. But in another way it is a bigger problem because all security is now concentrated in this single key and/or code. And that is in fact what security does for you: it concentrates the security risks to some clearly identifiable items (mostly keys)  which can be managed. On the one hand this is a good thing because it offers the possibility to control the security. On the other hand though it brings the responsibility to control and manage the security in an appropriate way, because a loss of control could have severe consequences.
The TETRA standard support use of several sorts of cryptographic keys as described in [1]. Generally speaking you could say that a key has some sort of life cycle: it is created at some place, then has to be transferred to another place where it is installed and used for a certain period; some time the key retires and is replaced by a new key; in certain cases it might be needed for security reasons to destroy the old key.
During this process of key management there are a lot of potential risks and problems. Are keys generated in a correct way, e.g. using an appropriate random generator? Are the keys transferred and installed in a save way, i.e. without being eavesdropped? Where and how can keys be stored in a secure way. If keys are replaced, at which moment should the new key be used? (Especially in the case of TETRA where group call keys are used this is a very relevant question.)  And is there a special need to destroy the old keys, e.g. because the information encrypted with such keys is relevant for a longer period? Finally, who has the responsibilities for the key management and who controls and audits the key management processes?
All these questions have to be answered within a the general framework of the key management and an underlying security policy. Such a key management framework and security policy are two main pillars for the security. They need to be defined for every system incorporating cryptographic security and hence also for TETRA networks which will be implemented.
Key management as such was not a subject of the TETRA standardisation, since the best solutions for key management always depend on the specific network. However the TETRA standard contains many features which support a secure key management.
The TETRA standards does not contain a generic security policy for TETRA implementations. Also a security policy is highly implementation dependent and it has to be defined for every individual system. It will be based though on the available TETRA security features.
In the following paragraphs we will look into more specific issues of TETRA key management and the security policy for TETRA networks.

3.     TETRA Key Management Issues
TETRA has unique features with unique security aspects. This has to be taken into consideration when designing the key management for TETRA networks. This design is a complex and specialised job and it is not the objective of this paper to provide a complete or detailed overview of all the problems involved. This section will only outline some specific key management issues.

3.1     Management of Authentication Keys
The management of the keys used for Authentication might be the most sensitive part of TETRA Key Management. These keys are the basis for a large part of the security and most of the encryption keys are either derived or protected by an authentication key. Therefore it is essential that the authentication keys are managed in a secure way. Authentication Keys have to be available in the hand set where they have to be installed directly or using a SIM (see also sections on Management of hand sets without a SIM and SIM management). On the central side of the system the Authentication Keys will be stored in databases. Obviously these databases will need a very high level of physical protection. Strict access control procedures and physical protection measures will have to be implemented to guarantee the overall security of a TETRA system.
The TETRA standard offers options as to which extend the Management of Authentication Keys can be decentralised. The options range from a completely centralised management to a decentralised management using so-called Session Authentication Keys. The for the network most appropriate level of decentralisation will have to be chosen, balancing the operational complexity and the management overhead.

3.2     Replacement of Encryption Keys for Group Calls
A specific characteristic of TETRA is that there are Encryption Keys used for Group Call Encryption which have to be replaced after certain intervals. These keys are the Common Cipher Key (CCK) used for encryption of Group Calls in one or more location areas and the Group Cipher Key (GCK) used for the encryption of calls for a specific group. Replacement of such keys might be a complicated procedure. But the TETRA standard incorporates features to support it. The first of these is that there is a secured Over The Air Re-keying protocol (OTAR) to distribute new keys over the radio path in a secure way. The other is that that the TETRA protocols allow for storing more than one version of a certain key in a hand set. However the procedures for timing the distribution of  the new keys and for the actual key change,  (such as determining the moment when the new key can be used) are a responsibility for the network. These procedures will have to be defined in an early stage during the implementation phase of TETRA networks.

3.3     Use of SCKs
The TETRA standard supports the use of up to 32 so-called Static Cipher Keys (SCKs) for the encryption of calls. The value of these keys can be determined by the system manager, but it might even possible to let the users select the value of an SCK. The SCKs are in the first place intended for use in direct mode but they can also be used in situations where there is no common CCK or GCK available, e.g. in cross border communication. An optimal use of  SCKs is achieved by assigning different SCKs for different use and/or user groups. Careful specification of an appropriate SCK assignment will especially be needed in networks for emergency services where there are different user groups needing different levels of security. What the optimal assignment is, depends to a large extend on the specific network and its security policy. Therefore the assignment has to be specified during the implementation of TETRA networks.

3.4     Management of hand sets without a SIM
It the first implementations of TETRA there will mostly be TETRA hand sets without a SIM.  In such hand sets an authentication key needs to be loaded. This poses some problems. Who should load the key in the hand set: the manufacturer or the TETRA system manager?  How is the key transferred to the central databases? And should the key loading procedure be harmonised between different hand set manufacturers? The latter would certainly make the operation of the TETRA systems more easy. Probably the TETRA MoU should play a role in harmonising key loading procedures between manufacturers.

3.5     SIM management
The use of SIMs will significantly simplify the regular management and use of authentication keys. Users can have their own SIM and use that in any TETRA hand set supporting the use of  SIMs. However in the initial phase of the key management is complex. This initial phase will include actions such as generation of authentication keys and putting them on SIM (pre-personalisation of SIMs), distribution of SIMs within the networks administrating SIMs and storing authentication keys at the central side of the system. These procedures have to be well defined and audits (for instance on the smart card producer during the pre-personalisation phase) will have to be put in place.
The TETRA standard contains a mechanism for the protection of information exchanged on the interface between the SIM and the hand set. This security mechanism will need to be used for certain TETRA user groups, normally those needing the highest level of security. Though the mechanism itself is specified in detail, the way how to use the mechanism is outside the scope of standardisation and therefore needs to be specified during the implementation phase.  Also in this case the TETRA MoU could play a role in harmonising management of the mechanism.

4.     Security Policy and related issues
For every system incorporating security features a security policy has to be designed. In case of TETRA networks the security policy should describe how the security features in the TETRA standard should be used and which additional security should be implemented. A timely specification is essential for the final security level of the implementation of a TETRA network.

The key management issues described in the previous section will be an essential part of the security policy, but there are numerous other issues some of which are addressed in this section.

4.1     Security of the underlying fixed part of TETRA networks
TETRA standardisation focuses on the air interface protocols. With few exceptions, such as the Inter System Interface (ISI), the underlying fixed part of TETRA network is not standardised but left to implementation.  Attacks on a system always take place where the systems is weakest or most easy to attack. With the air interface having a high standard security, the underlying fixed part of a TETRA network is a target for potential attacks. For this fixed part it has to be assessed which are the risks and which security features need to be implemented  to also achieve an appropriate level of security. It has e.g. to be decided how vulnerable the fixed connections in the network are and to which extend they need to be secured e.g. by cryptographic functions such as encryption or authentication.

4.2     Profiling of security
The TETRA standards offers many optional security features. This is an advantage because it offers to possibility to tune the security and apply the appropriate level of security needed for the users of the network. In many networks there will be different user groups each needing their own level of security. In general it will be very inefficient to choose what seems the most easy solution and provide the highest possible level of security. A more practical and effective method is to define for each group a security profile which is a list of security features appropriate for this group. This will provide a solution which is both secure and manageable.

4.3     Fraud detection and prevention of illegal use
In all systems where services are offered on commercial basis the existence of fraud is inevitable. This will also be true for commercial TETRA systems. Even if security features are implemented there are situations where users loose their hand set/SIM or have it stolen. Also user will take subscription without intention to pay. Therefore from a commercial point of view it is essential that fraud detection and prevention systems are operational at the moment a commercial TETRA network start its service.
Of course also in non-commercial TETRA systems the loss and theft of hand set/SIMs will occur. Procedures will have to be put in place to limit the consequences of this. The TETRA standard contains features to disable hand sets and SIMs  (and if needed later enabled them again) via the air interface in a secure way. There will be a need to define how this feature should be used in a secure way. Alternatively, or additionally, the use of so called white lists and black lists indicating which hand sets/SIMs are, respectively are not allowed in a TETRA network, could be considered.

4.4     Paging Security
Since it might be cost efficient to use a dedicated existing paging system, it is not certain if all TETRA network will use the TETRA standard to realise their paging. If instead a dedicated paging is used it will probably not support the TETRA security features and in any case not the TETRA standard cryptographic algorithms which may only be used in TETRA systems. Therefore it will be needed to specify a security policy and may be required to design and implement special security features for the non-TETRA paging.

4.5     Jamming
Jamming is at the moment not an issue for public or semi-public radio networks. Only in military networks jamming is considered to be a risk. This might be changed if TETRA is introduced as communication system for national and cross border police communications. It can be more rewarding to carry out jamming attacks against such systems than against local police communications. The security policy for a TETRA network will need to consider if jamming is a risk and if so what kind of countermeasures should be implemented. If countermeasures against jamming would be in issue in more TETRA implementations, the TETRA MoU might be able to recommend countermeasures based on features contained in the TETRA standard.

4.6     End-to-end security
The level of the standard air interface security offered by TETRA is very high, as is the complexity of introducing additional end-to-end security. Therefore based on the security policy of the specific TETRA networks only certain users, such as special groups within police organisations, will need end-to-end security and will want to pay for this. On the one hand it is essential to notice that these users will have special requirements for their end-to-end security, requirements which often relate to national security policies. On the other hand designing a special end-to-end security solution for every user group who needs it is not very cost effective. Therefore there is a rationale for finding a common agreement between manufacturers and users on a common basis for end-to-end security. This could be done within the TETRA MoU. Also interest groups from the potential users could draft common requirements to reduce the cost for implementation of end-to-end security.

5.     Conclusion
Security is a complex but very important part of TETRA. The work on security standardisation in TETRA has been completed. The result is that TETRA systems with a very high level of security can be realised. However many security issues are outside the scope of standardisation and during the implementation of specific TETRA systems work in the area of security will have to be done. This paper has indicated a number of the security issues for the implementation of TETRA system. The paper does not claim to provide a complete and in-depth treatment of the subject. The security issues for the implementation of TETRA systems are too complex to cover completely is a short paper. Many problems are pointed out, but definite solutions can not be provided since these solutions will depend on the specific TETRA implementation. This paper is merely showing the top of the security implementation issues iceberg which could even make systems with a potential titanic security like TETRA sink.

Acknowledgments

The author would like to thank Mr Michel Smit (PTT Telecom Telesolutions) for his comments and suggestions.