Secure Card based Voice over Internet Protocol Authentication

Transcription

1 Secure Card based Voice over Internet Protocol Authentication By GOWSALYA.S HARINI.R CSE-B II YEAR (IFET COLLEGE OF ENGG.)

2 Approach to Identity Card-based Voiceover-IP Authentication Abstract Voice-over-IP (VoIP)-based services are becoming a popular alternative to traditional public switched telephony. The increasing number of users make VoIP also an interesting target for attackers. VoIP phishing and identity theft are gaining relevance. The lack of options for the reliable authen-tication between communication partners and the possibilities for anonymisation in IP-based telephony will allow attackers to steal confidential and personal information unperceived. This paper presents an approach for a reliable VoIP authentication, using federal electronic identity cards. The proposed authentication mechanism allows determining the identity of caller and callee in VoIP calls. Keywords-electronic identity card; authentication; VoIP; identity verification; I. INTRODUCTION The IP Multimedia Subsystem (IMS), specified by 3GPP [1] and TISPAN [2], forms the core of future IP-based telecommunication networks. It allows a provider comprehensive access for a ubiquitous use of telecommunication services, independent of the underlying wireless and wireline access networks. New services emerge from the evolution-ary change of circuit-switched to packet-switched telecom-munication networks. Besides new possibilities of service creation, there is also a new challenge for protecting the existing and upcoming VoIP-based services [3]. The analysis of security threats in IMS and common VoIP communication is still part of present research [4][5][6]. This paper brings an important but disregarded topic into focus, the reliable identification of communication partners in VoIPbased phone calls. Reliability is understood in terms of the unique determination of communication partner s au-thentic identity. The verification of a callers or callee s iden-tity becomes important if confidential information should be transmitted by telephone to a specific person. This person is defined by its identity or its affiliation to a company. Taking the example of a customer who calls his bank, the clerk would have to verify the customer s identity before he talks about confidential account information. Also, the customer is interested to verify whether his communication partner is indeed an employee of the bank. Besides the communication partner identification, also the transmission of information should take place in a safe and secure manner. This includes an end-to-end encryption for a confidential transmission of the conversation. This means the encryption should comprise the whole media path between the communication partner s VoIP softphones. Both the authentication of communication partner and end-to-end encryption will be provided by this approach. This paper is structured as follows. Section II and III introduce the problem of reliable communication partner identification and confidential VoIP communication. Section IV gives a short overview about the electronic identification functions of the federal identity card of Germany. In Section V, the electronic identity-based VoIP authentication mechanism is introduced. A security analysis follows in Section VI. Finally, a conclusion is given in Section VI. II. AUTHENTICATION CHALLENGES The problem of a reliable communication partner identification is as old as telephony itself. Typically, persons recognize each other in phone calls by their voices. This kind of identification requires that the persons must already know each other to recognize their voices in a phone call. An alternative technique is the usage of a common secret. This secret has to be agreed between each pair of communication partner in advance. Hence, it is inappropriate for phone calls with persons or organizations in case of a first contact. Another possible approach seems to be the usage of the transmitted phone number or the SIP-URI [7]. There are two problems, first the telephone partner shall be able to relate the number to an identity and second, these identifiers are ambiguous and not temper proof. There are many situations, where the common techniques for communication partner recognition are not applicable. If a new customer, for example, calls a bank to open a new account or a citizen calls a government agency to do some kind of registration, the callee is not able to recognize the caller by voice or number. In these cases it is not customary, that a common secret is agreed in advance. As well, the caller is interested in the identity or the affiliation of the person he is calling. A bank depositor, e.g., who calls his bank may want to know if the person he is talking

3 to is a clerk of his bank. A. State of the Art Previous approaches [8][9][10] were not universally ap-plicable or impracticable for identity verification in VoIP calls. Up to now, there is no ID card-based twofactor authentication approach, which allows the usage personal information like name, address or birthday for the reliable identification of communication partner. For professional usage where a reliable communication part-ner identification and confidentiality is mandatory, hardware-based security systems already exist [11][12][13]. However, this kind of equipment is very expensive and not widely used in the population. Besides the communication partner authentication, the encrypted transmission of conversation is also necessary. This problem will be introduced in the following Section. III. CONFIDENTIALITY CHALLENGES In VoIP calls, the media are typically transported unencrypted via Real-Time Transport Protocol (RTP). If a confidential exchange of information is required, the data have to be encrypted and transported via Secured Real- Time Transport Protocol (SRTP). On the signalling plane the Session Initiation Protocol (SIP) [7] is typically used for the creation, modification and termination of a call session. Since SIP and SRTP base on IP, these protocols are also affected of IP-based attacks. Different key agreement protocols are proposed by the IETF and TISPAN and also analysed in [5] for their applicability of the generation of a common secret, which can used to secure SRTP streams. These protocols include MIKEY [18] and SDES, which operate in the signalling plane, and DTLS-SRTP and ZRTP, which operate in the media plane. The concept, introduced in this paper, is limited to these protocols that could guarantee confidentiality, integrity and authenticity in the media plane. The majority of these protocols allow the key agreement for SRTP in an end-toend manner. A big challenge is the verification of source authenticity and identity in media streams. A reliable verification of which person is sending a media stream, can be realised with a Public Key Infras-tructure (PKI) or by exchanging security tokens in previous conversations. However, an interoperable PKI, where every potential communication partner can be verified, does not exist yet, and a key agreement in advance of a conversation is often not possible. There is a need for an approach to realise a reliable end-to-end encryption of media streams in VoIP calls and also the possibility to determine the identity of communication partner. IV. FEDERAL IDENTITY CARD OF GERMANY In November 2010, the new German electronic identity card (eid), depicted in Fig. 1, will be launched and suc- cessively replace the existing one [22]. The identity card is equipped with a Radio Frequency Identification (RFID) chip according to ISO [23] and implements an elec-tronic identity (eid) function [24]. This function allows the accomplishment of a mutual authentication process between ebusiness and egovernment services provider and eid card holders. The so-called online authentication enables the citizens to determine the authenticity of an offered online service. The advantage for the service providers consists of a reliable determination of eid card holder s identity. Figure 1. A. Authorized Access New German identity card The authorization for accessing the eid card data by the service provider is guaranteed through an authorization certificate, the so-called Card Verifiable (CV) certificate and a PIN, which is exclusively known by the eid card holder. Trustworthy service providers can apply for this certificate at a federal office. A CV certificate contains information about the service provider and the offered service, like name, address, address and a service-specific identifier. The eid card contains personal information about the citizen, like name, address or birthday, which can be transmitted to the service provider if he exhibits an authentic CV certificate. The data transmission necessitates the interaction with the eid card owner, so an unnoticed access is not possible. The eid function allows the involved communication partner to verify the identity of the counterparts. The eid card holder is able to select individual data fields in advance of the transmission. So he has the ability to control, which information will be transmitted to the service provider. The eid function, among others, provides the following data fields: first name, last name doctor s degree date and place of birth current address document type (ID card) issuing country, (abbreviation D for Germany) expiration date 62

4 B. eid Authentication Process The authentication process, of the eid function, between an eid card owner and a service provider is depicted in Fig. 2 and will be described in the following. 1) First,the eid card holder starts an online service re-quest with his web browser, contacts a service provider via HTTPS and starts the eid Authentication process. 2) The service provider responds with a CV certificate, containing listed permissions for the access to individ-ual data fields. 3) The eid card holder allows or denies the access to the data fields and enters his PIN to grant the access. 4) A secure communication channel is established between the eid card and the card reader using the Pass-word Authenticated Connection Establishment Proto-col (PACE) [23]. In this operation a Diffie- Hellman Key Agreement Protocol is used for securing the subsequent identity exchange. The PIN shall prevent man-in-the-middle attacks. 5) Service providers CV certificate is sent to the eid card. 6) In this step the Terminal Authentication Process is performed. First, the eid card verifies the authenticity of the service provider s CV certificate by checking its signature. Afterwards, the service provider has to prove the knowledge of the secret key, which is associated to his CV certificate in a challenge response procedure. 7) In the end the Chip-Authentication process is performed. The eid card uses a static Diffie-Hellman key pair, which is signed by a federal issuer. The service provider generates an ephemeral key pair based on the eid cards static domain parameters. Subsequently, the service provider verifies the signature of the static Diffie-Hellman public key. A symmetric key is agreed for the secure messaging of eid card holder s personal information. After these operations, the following results are given: The eid card has verified the service provider and the requested service. The permission of the service to access the data fields is verified via the CV certificate. The service has verified the eid card s authenticity and has assured that the eid card has been issued by federal authorities. A secured channel is established between the web browser of the eid card owner and the service provider. This channel can now be used for secure and authenticated data transmissions in the following. The operations between the eid card and a service as well as the access operations to the eid card are specified in the ecard-api-framework [26]. This framework is part of the ecard-api strategy of the German government, which shall enable an easy and uniform access to the functions of ID-Card Card Reader Service 4 PACE 5 CV certificate 6 7 Terminal Authentication CV certificate 2 PIN 3 Chip Authentication Figure 2. eid authentication process different smart cards. The application of the eid card and the ecard-api in this approach of securing VoIP communication is explained in the following Section. V. VOIP CALL AUTHENTICATION As mentioned before, an encrypted transmission of media streams in IMS or simple VoIP telephony is realised by SRTP. The usage of this protocol necessitates further mech-anisms to exchanging the communication keys in advance, like the media plane protocols DTLS-SRTP or ZRTP. Under certain conditions these protocols only allow a reliable authentication of the communication partner and recognition of man-in-the-middle attacks on the media stream. However, a PKI or a pre-shared secret key relating to the designated identity have to be exchanged in advance for a reliable identification of communication partner. A. Call Scenario with eid Authentication The problem of a missing PKI can be solved by the application of the eid-function of the new eid card. The eid authentication results in a secured channel between the Authentication Webserver (AWS) of the service provider and the web browser of the eid card holder. Replacing the web browser, a VoIP softphone can also be used for triggering the authentication process and transmitting additional data on the secure channel. The software first establishes a secure VoIP call, e.g., with ZRTP and triggers the authentication process of the communication partner in the second step. This is followed by the mapping of the eid card holder s identity to a secured VoIP session. The secure channel, which is established in eid process, is used to transmit information that allows a mapping of the used VoIP commu-nication keys (SRTP master keys MK SRTP ) to the identities of the communication partner. These communication keys are generated with one of the key agreement protocols on the media plane, e.g. ZRTP. They are used to generate the SRTP master keys and master salts to encrypt the media

5 Secure Bank ecard-api Secure Messaging 4 eid Server Auth. WS. 4 5 Customer Card ecard-api Reader Electronic ID Card Secure VoIP Connection Identity Matching & Challenge Response Authentication Webserver 5 6 Secure eid Authentication Channel ID Card Holder VoIP Call Center Enterprise Network VoIP Agent VoIP Server Softphone Figure 3. VoIP caller and callee authentication streams for confidentiality and integrity protection, both for the SRTP stream and the corresponding Secure Real-Time Control Protocol (SRTCP). So, the keys of the SRTP session are mapped to the identities, which are verified by the eid Function. The key agreement protocol can be chosen freely. In this paper ZRTP is used exemplarily. B. Conceptual Approach The approach is introduced in the following in form of an exemplary call scenario, depicted in Fig. 3. On the left side the service provider is located. He offers a telephone share trading service for his customers. On the right side is the eid card holder. He would like to use the telephone trading service of the bank. Due to the confidentiality of the phone call, mutual authentication of the communication partner and media encryption are required. In this scenario, the authentication process is performed after call establishment. It is also possible that the eid-authentication is performed in advance of the call. This use case is illustrated in the following. It describes the steps of the whole VoIP authentication process in case of a customer who possess an eid card and calls his bank to order some shares: 1) The customer registers himself at his VoIP service provider and initiates a SIP session with a Call Center Agent (CCA) of his bank. 2) During the connection establishment a SRTP media session is created between the communication partner. The key agreement is performed with ZRTP. This results in the SRTP master keys and master salts for the SRTP session. 3) Since the customer wants to trade some shares, the CCA demands him to authenticate himself. Now the customer initiates the eid authentication process by his VoIP software. The URL of the authentication webservice (Auth. WS.) is transmitted by CCA to customer s VoIP software in the Universal Resource Identifier (URI) field of the Session Description Pro-tocol. Alternatively, if the softphone does not support the exchange of the URI, the CCA tells the URL to the customer via voice. 4) Subsequently, the eid authentication process is executed as described in Section IV-B. The customers VoIP softphone triggers the eid authentication process by contacting the Authentication Webserver using HTTPS, which prepares the eid Server to process the eid authentication. Subsequently, the VoIP softphone receives a session number and further information, which allow the ecard-api on customer side to con-tact the eid server to process the eid authentication [28]. The session number is used to assign the HTTPS connection to the verified identity. The result is a secure channel between the customer s VoIP softphone and the AWS of the bank. Both endpoints of this chan-nel are authenticated: that means they have verified their mutual identities. The selected data fields con-taining the personal information about the customer are transmitted to the eid Server and forwarded to the AWS. So, the bank knows the identity of the customer, and the eid card has also verified the CV certificate of the bank IV-A. 5) In this step, the mapping between the customer in its part as a caller and its eid authenticated identity follows. Similarly, the affiliation of CCA to the bank is proved. Both, the CCA and the eid card holder trans-mit a hash value of the SRTP master key MK SRTP ) to AWS s authentication webservice. The eid card holder uses the prior established secure and authenticated HTTPS connection. Since the CCA and the AWS belong to the same bank, a trust relationship exists. So, the CCA uses conventional authentication and encryption protocols, like IPSec, for the transmission of the hash to the AWS. The authentication webservice

6 compares the received hash from the customer to the hash of the CCA. If both hashes are identical, the authentication webservice can assign the customer to the CCA and transfers customer identity information to the CCA. Both hashes are particularly identical if both communication partner use the same key (MK SRTP ). In this case, it can be assumed that the CCA and the customer are in the same VoIP communication session. 6) The customer also receives a feedback message. If the hashes are identical, so he can assure that he is really talking to an employee of the bank he is calling. After performing these six steps a secure end-to-end con-nection between the VoIP software of both communication partner. The identity of the eid card holder is verified by the CCA. The eid card holder itself was able to verify that the person he is talking to is a clerk of the bank. So the identities of the communication partner are mapped to the end-to-end secured VoIP communication session. This also allows the detection of man-in-the-middle attacks, because both endpoints have to generate the same hash value, based on MK SRTP. In the following section, a short security analysis of the proposed caller identification process is given. 3 N = SIGN(MK SRTP, N) Figure 4. Call Center Authentication ID Card Holder Agent Webservice N Choose random N number N 2 N 4 N 1 5 VERIFY(MK SRTP, N ) Additional challenge-response verification process VI. SECURITY ASSESSMENT AND ADDITIONAL PROCEDURES The described concept is based on the confidence of the eid card holder in the service provider, if this can present a valid CV certificate. If the bank is trusted by the eid card holder, the report of the positive hash match is also trusted. However, the comparison of hashes is only performed by the bank, so the eid card holder cannot reproduce the matching. Alternatively, the eid card is able to perform an additional challenge-response procedure, which likewise increases the duration of the whole authentication process, but allows reproducing the matching by the customer. The challenge-response procedure is depicted in Fig. 4 and illustrated in the following: 1) The eid card owner generates a random number N and transfers it to the AWS using the secure and authenticated HTTPS connection. 2) The AWS forwards N to the CCA 3) The CCA signs the N with the common secret key MK SRTP and transfers N to the AWS. 4) The AWS forwards the signed N to the eid card owner. 5) The eid card owner verifies the signature of N. This signature can exclusively been correct, if the CCA holds MK SRTP. Then, it can be assumed that the person the eid card holder is talking to is an employee of the bank. Since just the VoIP softphone of the CCA also holds the common SRTP master key, the CCA can correctly answer the request and creates the correct signature. Without the challenge response procedure, the eid card holder must solely rely on a correct comparison of the AWS. Another security relevant issue concerns the AWS URL transmission in step 3 of the call scenario in V-B. The URL reaches the eid card holder unencrypted in the SDP part of a SIP message. An attacker could change the URL to an address of a rogue AWS, which is under his control. However, this attack can be recognized by the eid card holder because the eid server must prove its identity during the authentication process. The eid card holder checks the content of the CV certificate and the eid card verifies during the terminal authentication if the eid server holds the corresponding secret key. In case the attacker shows a real CV certificate of the secure bank, he does not hold the correct secret key and can t prove the possession. VII. CONCLUSION The paper has introduced a new reliable and comprehen-sive caller and callee identification and confidential infor-mation exchange based on media plane security and federal identity cards. This concept can be applied, if confidential information must be exchanged by phone. The scope of application is, among others, the trusted telephony with public authorities, on the financial sector or with person with security clearance. The proposed approach is not limited to the new German identity card. At the end of 2010, many European states perform eid and egovernment projects on national level in use. The European Large-Scale Pilot STORK, e.g., shall establish an European eid Interoperability Platform that will allow citizens to use electronic identification services across borders, just by presenting their national eid. Hence, the approach can be adapted to other national identity cards in future, which support similar kinds of eid authentication. There is also a prototype running, based on an open source SIP softphone. Because the integration is not yet fully completed, performance tests are not part of this paper. This approach is also not limited to the usage with personal

7 computers. It can be expected that the number of mobile de-vices, which support near-field communication and ISO/IEC increases in future. So eid cards can be applied with mobile phones for the mutual authentication and the confidential exchange of information. REFERENCES [1] 3rd Generation Partnership Project, Technical Specification Group Services and System Aspects - IP Multimedia Subsystem (IMS) - Stage 2 Release 9, Juni [2] ETSI TISPAN, ES V2.1.1 IP Multimedia Subsystem (IMS) Functional architecture, November [3], TR Ver TISPAN NGN Security (NGN SEC) Threat, Vulnerability and Risk Analysis, December [4] S. Niccolini et al., SPEERMINT Security Threats and Suggested Countermeasures - draft-ietf-speermint-voipthreats- 01, July [5] J. Floroiu and D. Sisalem, A comparative analysis of the security aspects of the multimedia key exchange protocols, in IPTComm 09: Proceedings of the 3rd International Conference on Principles, Systems and Applications of IP Telecommunications. New York, NY, USA: ACM, 2009, pp [6] H. Abdelnur, T. Avanesov, M. Rusinowitch, and R. State, Abusing sip authentication, in IAS 08: Proceedings of the 2008 The Fourth International Conference on Information Assurance and Security. Washington, DC, USA: IEEE Computer Society, 2008, pp [7] J. Rosenberg et al., Session Initiation Protocol (SIP), RFC 3261, June [8] S. T. Chow, C. Gustave, and D. Vinokurov, Authenticating displayed names in telephony, Bell Lab. Tech. J., vol. 14, no. 1, pp , [9] S. Chow, C. Gustave, and D. Vinokurov, Authenticated names, in NSPW 07: Proceedings of the 2007 Workshop on New Security Paradigms. New York, NY, USA: ACM, 2008, pp [10] S. Mizuno, K. Yamada, and K. Takahashi, Authentication using multiple communication channels, in DIM 05: Proceedings of the 2005 workshop on Digital identity management. New York, NY, USA: ACM, 2005, pp [11] Cryptophone. [Online]. Available: