Group Sense PDA Limited. Hong Kong and. Nguyen TRAN. Industrial Research Institute of Swinburne. Swinburne University of Technology. Hawthorn, Victoria,.
Security Implementation of Bluetooth Technology for 3G and future mobile communications Wing K TAM Research and Development Department Group Sense PDA Limited Hong Kong and Nguyen TRAN Industrial Research Institute of Swinburne Swinburne University of Technology Hawthorn, Victoria, Australia ABSTRACT The future mobile networks are designed for high quality voice, high speed data and multi-media services. Bluetooth technology will play an important role in voice and data services. With the rapid growth of M-commerce, security is essential for 3G and future mobile networks. The powerful security features of Bluetooth Technology will be a major consideration in the whole of 3G and future mobile security architecture. A Bluetooth link connecting a mobile phone to a headset and computing devices will provide secure voice and data communication services. Keyword : Bluetooth, 3G and future mobiles, Security of Bluetooth, Secure Mobile Network. 1. INTRODUCTION The future mobile networks are aimed at providing a high speed data infrastructure for a good quality voice, video, image and a large amount of information transmission in a wide range of services. A mobile phone is however not a good device to input and display a large amount of data due to its limited keyboard and display size. If a mobile phone is equipped with a standard keyboard and a large screen, it will be too big for normal phone usage. The use of Bluetooth Technology provides the solution to this problem. It allows computing and mobile communication devices to link together freely without any physical connection. Users can use their portable computer or PDA to access the Internet without any cable connection to the telephone or LAN socket anytime and anywhere. With the broadband 3G network and Bluetooth Technology, mobile data will become the major data communication in the near future. A very important factor yet to be considered is “security”.
Security of a communication channel is an important factor for the success of 3G mobile data services. In a UMTS 3G network, the access security features are a superset of those provided in GSM. They are specified in TS33.102[1], which is included in the first major release of the 3GPP specifications, known as Release 99. Looking more into the future, mobile cellular systems will have to accommodate a variety of different radio access networks, including short-range wireless technologies, connected to a common core network. Bluetooth is the major short-range wireless access technology with powerful security features. The security of a Bluetooth link is a major consideration in the whole 3G network architecture. This paper discusses the security features of Bluetooth and security architecture for selected Bluetooth Wireless Profiles. A new idea on the implementation of voice and data security systems for mobile network based on the Bluetooth technology is also discussed. 2. SECURITY IN BLUETOOTH Bluetooth has powerful security features with the SAFER+ encryption engine using up to 128 bits keys. The Bluetooth specification includes security features at the link level. It supports authentication and encryption. To authenticate a device, it is necessary to verify the shared secret key – the link key as shown in Fig. 1. The secret key is derived from the Bluetooth passkey using the E2 algorithm as shown in Fig. 2. The Bluetooth passkey is either entered in a user interface or it can be built in by the manufacturer for devices such as headsets which do not have a user interface. After authentication, devices can use the E3 algorithm to create shared encryption keys which can be used to encrypt traffic on a link as shown in Fig. 2. The combination of authentication and creating link keys is
called pairing. At the application level, pairing, possibly accompanied by exchange of higher level security information, is called bonding. Claimant
Verifier
Link Key
Link Key RAND
BD_AddR_S
BD AddR S
LMP_au_rand
E1
E1
SRES S
SRES_M
LMP_sres
=?
Fig. 1 Authentication PIN
PIN
E2
E2
Authentication Link Key
Link Key
E3
E3
Encryption Encryption Key
Encryption Key
Fig. 3 Security Architecture 3. SECURITY ARCHITECTURES FOR SELECTED BLUETOOTH WIRELESS PROFILES The Bluetooth Technology contains a set of profiles [3]. The purpose of a profile is to provide a clear description of how a full specification of Bluetooth wireless system should be used to implement a given end-user function. It ensures the interoperability of different Bluetooth products with the same profile implemented.
Fig. 2 Key Generation and Usage Three security modes are available in Bluetooth. Mode 1 is not secure, mode 2 has security imposed at the request of applications and services, and mode 3 has security imposed when any new connection is established. Most of the Bluetooth mobile phones are equipped with the security mode 3 which requires pairing to form a pair of trust devices before connection. A Bluetooth security white paper [2] suggests the architecture for implementing security in the higher layers of a Bluetooth protocol stack. Fig. 3 shows the security architecture described in [2]. This is based on a mode 2 security. In addition to being authenticated by the link management procedures, the security architecture introduces the idea of a device being authorized by a user to use a particular service. This is suggested in the white paper [2] to implement through a pair of databases: one holds the information on which devices to be authenticated and / or encrypted. A service and protocol register with a central security manager handles the access to the databases. After registration, the central security manager grants permission to the user services.
The current Bluetooth specification defines security at the link level only. The application level security is not specified. It allows the application developers to select the most appropriate security mechanisms for their particular application. The Security Expert Group of Bluetooth Special Interest Group (SIG) has developed the general security architecture models for developers to handle the application level security. The security architecture for selected Bluetooth wireless profiles is discussed in this section. The following two profiles are selected in this section as they are related to the voice and data security of 3G and future mobile communication : • •
Headset Profiles Dial-up Networking Profiles.
Headset Profiles The Headset Profile defines the facilities required to make and receive hand-free voice calls from a headset to a cellular phone handset. Of course, it can be used to transfer voice calls between other Bluetooth devices. A typical headset configuration consists of two devices, a Headset (HS) and an Audio Gateway (AG), as shown in
Fig. 4[4]. The AG is typically a cellular phone. The secure link between HS and AG can be set according to policy rules. Irrespective of which policy rule is employed, HS and AG need to store the necessary Bluetooth passkeys and link keys. Normally an HS does not contain User Interface (UI) for inputting new Bluetooth passkey value. Hence, a fixed Bluetooth passkey in the HS is reasonable. Consequently, HS manufacturers are encouraged to use randomly generated initial Bluetooth passkey values that are unique for each HS. The initial Bluetooth passkey should be stored in non-volatile memory.
The Dial up networking (DUN) profile provides a Dial up data connection between a data terminal and a gateway. This allows a computing device (such as laptop) to access a telephone network using the services of a communication device (such as a cellular phone) as shown in Fig. 5. In this case, the data terminal (DT) is a laptop and the gateway (GW) is a cellular phone. A typical DT-GW configuration is shown in Fig. 6[4].
Optional PIN values
Security Policy Audio Gateway (AG) Link Key Database
Headset (HS)
Optional PIN values
Security Policy
Link Key Database Bluetooth Wireless Connections
Access Policy
Headset settings
Data Terminal
Gateway Link Key Database
Link Key Database Bluetooth Wireless Connections
Access Policy
Authentication and Encryption Policy
Security Policy Access Policy
PIN Value
Security Policy
PIN Value
Serial port Connection
Authentication and Encryption Policy
Access Policy
Authentication and Encryption Policy
Allowed audio Connections Serial port Connection
Authentication and Encryption Policy
Allowed Control Connections
Fig. 4 Headset Security Architecture To build up a secure link between HS and AG, pairing is the first step as stated in section 2. As the initial exchange of keys using non-encrypted channels is the weakest part of the pairing procedure in the Bluetooth Baseband Specification[5], it is recommended that the user should be in a private area before using the pairing procedure. After pairing, a link key is created and shared by HS and AG. An encryption key may also be created for data encryption between HS and AG. At this point, the HS will only accept a connection from the AG with which it is paired. These procedures implement the mode 3 Bluetooth security. It is recommended that a mode 3 security for Headset Profile is implemented since HS is a simple device that is easier to make all connections to the HS in the same way in terms of demand authentication and encryption. The AG may be used for several other applications such as wireless modem, base set of cordless system etc. Different security polices may apply for different applications and connections. Security mode 2 makes it possible to implement different security policies. Dial-up Network Profile
Cellular Phone Laptop or PC
Fig.5 Dial-up Networking Scenario
Fig. 6 Dial-up Networking Security Architecture To have a secure communication link, it is recommended that a security mode 2 or mode 3 is implemented in the dial-up networking profile. It is straightforward to implement security mode 3 for the dial-up networking DT-GW pair. It should be noted that pairing should be in a pairing mode of DT and GW and perform according to the Bluetooth Baseband specification [5]. It is the same as the case of a Headset Profile, pairing should be performed in private area. If pairing must be performed in a public area, the GW and DT should use long random Bluetooth passkey values to reduce the chance of being eavesdropped. After pairing, a link key is created and shared between DT and AG. The encryption key may also be created for data encryption between DT and AG. It may need to implement the security mode 2 for an advanced mobile phone and laptop computer pair. For mode 2 implementation, it is the service that decides the level of security to be enforced. Security is enforced only when access is requested to a protocol or service which requires security. The protocol or service requests access from the security manager. The security manager looks up the service or protocol in the service database to see what level of security to impose. Then it looks up the connecting device in the device database to see whether it meets the requirements of the service. If necessary, the security manager enforces authentication and/or encryption and sends any necessary queries for PINs or authorization to the user interface. Access is then granted or refused, and if access was granted, the service can be used through dial-up network profile.
4. SECURE VOICE AND DATA OF 3G MOBILE NETWORK USING BLUETOOTH TECHNOLOGY Bluetooth Headset
Bluetooth Headset
3G Mobile Network Bluetooth Phone
Bluetooth Phone
Bluetooth PDA
Bluetooth PDA
Protected by end to end encryption using shared encryption key
Fig. 7 End to end secure 3G network In section 2 and section 3, we have discussed the security features of Bluetooth and its implementation in selected wireless profiles. The secure Bluetooth connection can be extended to provide an end to end secure network in current and future mobile communication systems. Fig. 7 shows the concept of an end to end secure 3G mobile network using Bluetooth Technology. The key technique of this secure mobile network is the shared Bluetooth encryption key. This encryption key is created by using the passkey input from users. To build an end to end encrypted data communication network, the data terminal (It can be a computer with Bluetooth module or a Bluetooth PDA as shown in Fig. 7) and the gateway (A Bluetooth 3G mobile phone as shown in Fig. 7) should be doing the pairing procedure first. They will hence become a trust device pair so that they can have an encrypted wireless link. The Dial up Networking Profile is implemented in order to build a data channel through the mobile phone. The secure mobile data communication service should be stored in the service database of the security manager in Bluetooth security mode 2. When the DT requires the services, the device database will check whether the device is authorized for this service and the service database will inform that the service requires encryption. The passkey is required to enter in DT and GW. This passkey is used to be the source of an algorithm for generating an encryption key KD. The encryption key KD is used for data encryption for any encrypted mobile data communication. It is required on the other end of the communication channel to have the same encryption key. Hence, the same procedure should be performed at the other end. A user at the other end needs the same passkey for the generation of the encryption key KD. The passkey can be an agreed shared information within a private
group. This is for a high secure private secure data communication channels. The passkey can also be distributed by using PKI for public channels. A Bluetooth Headset and Cellular phone pair can create a secure voice connection through the Headset Profile by using the same encryption key Kv for voice data encryption. Kv is created after a trust HS and AG (Cellular phone) pair is formed. The HS may not be suitable for a passkey input but it can receive the passkey and the command of encryption key generation from the AG through the encrypted Bluetooth data link. The passkey can be shared within a private group or exchanged through PKI in the same manner as a data connection. For secure voice communication, it is not possible to encrypt ordinary mobile voice calls such as GSM or 3G voice calls because transcoding errors would prevent decryption. A secure voice system can send encrypted voice data over a circuit switching data connection as this is not transcoded. A separate phone number is necessary for secure voice communication. The original voice coder cannot be used as it is for non-encrypted voice signal. An encrypted voice signal will lose its voice pattern and hence cannot be handled by a normal voice coder. It is necessary to have another voice coder for the secure voice service. The voice coder for Bluetooth headset can be used for this purpose. The future communication system will be an integrated communication system as shown in Fig. 8. The concept described here is system independent. It can be implemented in any communication system with a Bluetooth wireless connection. The GW’s and AG’s can be devices such as a computer, a fixed line telephone set, a modem or a LAN access points.
Fig. 8 Future encrypted mobile communications 5. CONCLUSION We present a brief discussion on the Bluetooth security feature and its implementation in selected wireless profiles. We also present a concept of building a secure
end to end mobile communication using Bluetooth trust device pairs. The key technology of the concept is the shared encryption key which is created in a secured Bluetooth trust device pairs. The concept can be deployed by a private group for their secure communication and in public channels by exchanging encryption key using PKI. Security of mobile networks and convenient man machine interfaces are the key factors in making future mobile networks become a main stream communication service. Bluetooth plays an important role in both of these two key factors and will become an essential technology in future communication devices. 6. REFERENCES [1] 3GPP TS33.102, “Security architecture”, see http://www.3gpp.org [2] Bluetooth SIG, “Specification of the Bluetooth System, Core”, Version 1.1, 22 Feb. 2001, see http://www.bluetooth.com [3] Bluetooth SIG, “Specification of Bluetooth System, Profiles”, Version 1.1, 22 Feb. 2001, see http://www.bluetooth.com [4] Christian Gehrmann, “Bluetooth Security White Paper”, Revision 1.01, 14 May 2002, see http://www.bluetooth.com [5] T. Müller, “Bluetooth Security Architecture”, A Bluetooth SIG White Paper, Revision 1.0, July 1999, see http://www.bluetooth.com
