Implementing Identity Provider on Mobile Phone

Transcription

1 Implementing Identity Provider on Mobile Phone Tsuyoshi Abe, Hiroki Itoh, and Kenji Takahashi NTT Information Sharing Platform Laboratories, NTT Corporation Midoricho, Musashino-shi, Tokyo , Japan {abe.tsuyoshi, itoh.hiroki, takahashi.kenji ABSTRACT We have implemented an identity provider (IdP), which is defined by the Liberty Alliance on a mobile phone. We propose an authentication method, which uses this personal IdP as a security token to prevent password leakage. In our method, the personal IdP on a mobile phone issues a security assertion signed by a private key on a Universal Subscriber Identifier Module (USIM). There are some authentication solutions that require special hardware tokens to prevent password leakage incidents, but their disadvantage is a higher distribution cost. In our method, there is no need for distribution of special hardware tokens because mobile phones are widespread personal devices. There are other authentication methods that use mobile phone terminals, but our method has the advantage that there is no need for installation of special software on s. In addition, users are able to carry out single sign-on (SSO) with our method by using the Liberty Alliance architecture. Compared with ordinary SSO where the IdP is a server computer, our method has a unique feature that the initial authentication is performed on a user s mobile phone with the key pad as an input device and LCD as an output device. Therefore, the credential for initial authentication is not transmitted from the mobile phone, and we can avoid the risk of password theft. If the mobile phone has its own security feature like fingerprint authentication, the feature can be used for SSO too. In this paper, we also discuss implementation issues on a mobile phone network and security issues regarding the man-in-themiddle attack. Results of the performance test of a prototype system are also described. Categories and Subject Descriptors K.6.5 [Management of Computing and Information Systems]: Security and Protection Authentication, Unauthorized access. General Terms Design, Experimentation, Security Keywords Authentication, Federated Identity, Identity Provider, Mobile Phone Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. DIM 07, November 2, 2007, Fairfax, Virginia, USA. Copyright 2007 ACM /07/ $ INTRODUCTION Usernames and passwords have been parts of major authentication methods for a long time. However, phishing has become a problem, so increasingly more usernames and passwords are being stolen today. Therefore, many business sites are using stronger authentication methods such as one-time passwords (OTP). However, to use the OTP method, a site owner has to distribute special hardware tokens to every user, and that cost is not negligible. Carrying tokens all the time is also inconvenient for users. On the other hand, mobile phone terminals have received attention as portable security devices. There are some commercial systems that use mobile phone terminals as an OTP software token [1] or connect a mobile phone terminal to a with a USB cable and use it as a hardware token [2]. Our approach is using a mobile phone terminal as an identity provider (IdP) which is defined by the Liberty Alliance [3]. Once a user is authenticated by his/her own mobile phone, the IdP on the mobile phone issues a Security Assertion Markup Language (SAML) [4] assertion signed by a private key on its Universal Subscriber Identifier Module (USIM) [5] and sends that assertion to service providers (s). As in the ordinary Liberty Alliance s single sign-on (SSO) procedure, no additional software or hardware are needed for users s to perform our method. In the next section, we will describe the details of our proposed method. In section 3, we will discuss the trust model. In section 4, we will discuss implementation issues. The possibility of a man-in-the-middle (MITM) attack on our method and conceivable countermeasures will be discussed in section 5. In section 6, we will show our prototype system, which achieves our proposed authentication method. 2. METHOD In this section, we will describe the details of our proposed method. Components of our proposed authentication method are shown in Figure 1. IdP the Internet Figure 1: Components of proposed method 46

2 A mobile phone is used to authenticate the user to receive a service provided from the. A user s IdP software is running on the mobile phone. Fundamentally, the sequence is the same as that of the ordinary Liberty Alliance SSO procedure, but the IdP software is running on the mobile phone terminal, not on a server computer over a network. Therefore, initial authentication can be performed directly between the user and IdP, instead of through the network. A typical sequence flow of our proposed method is shown in Figure 2. IdP (Mobile Phone) sent via User s by HTTP redirection IdP discovery 3. TRUST MODEL In the OASIS trust model guidelines [6], a variety of models that can be applied to establish trust among Liberty entities (e.g., IdPs and s) is described. The trust model taxonomy in the guidelines is shown in Figure 3. Two dimensions of trust are distinguished. The columns represent the types of authentication. Direct authentication means that entities exchange shared secret keys or public-key certificates with each other. Indirect authentication means that entities authenticate each other via intermediary entities (e.g., PKI CAs). The rows represent the types of business agreements. Direct agreements are exchanged between the participants. Indirect agreements are facilitated by business intermediaries. There could be an absence of business agreements linking participants. This figure indicates the authentication manner, and the formations of business agreements are independent of each other. Prompt for password Password (Optional) Authentication (e.g. PIN code check) Initial Authentication (if a user has not been authenticated) Authentication response with IdP signature sent via user s by HTTP POST Verify response Figure 2: Typical sequence flow When a user accesses the to receive a service, the redirects the user to the IdP on the mobile phone to authenticate the user. We will describe how the discovers the location of the IdP in section 4. If the user has not been authenticated yet, the IdP on the user s mobile phone authenticates the user. Like in an ordinary IdP on a server computer, initial authentication may be performed via a network. In addition, a user can directly input authentication information into the IdP by using the mobile phone user interface. Typically, a PIN code can be input using a keypad. If the mobile phone has its own security feature like fingerprint authentication, that can also be used for initial authentication. Then, the IdP on the mobile phone creates a SAML assertion and signs the assertion with the private key of the mobile phone. One of the mobile phone carriers in Japan ships USIMs with digital certificates and key pairs, and some mobile phone terminals can use USIMs for digital signing [2]. An authentication response that has the issued SAML assertion is sent to the through the user s by the HTTP POST method. Then, the verifies the authentication response. If the verification is successful, the provides the service to the user. Using key pairs in the USIM has security and usability merits. The security merit is that because Universal Integrated Circuit Card (UICC) is a tamper-resistant device, the private key is stored securely. In terms of usability, the same key pair can be used even if the user changes the mobile phone model. In this method, security information created on a mobile phone terminal is transferred to the user s and then sent to an using an ordinary WWW browser feature. Therefore, no additional hardware or software is needed. Business anchor list Trust anchor list Business entity in question Figure 3: Trust Model Taxonomy [6] In our proposed method, the situation represented by each cell of Figure 3 will be possible. At first we will examine authentication columns. If an end user (mobile phone IdP owner) submits a digital certificate in the USIM to the prior to SSO, the can verify the SAML assertion signed by the IdP with that digital certificate at the SSO time. This case applies to direct authentication. If the stores the mobile phone carrier s digital certificate as a root CA s certificate, the can verify the SAML assertion without prestoring each mobile phone certificate. That is because the mobile phone certificates that are signed by the mobile phone carrier will be sent with the assertion, and the verifies the mobile phone certificates with mobile phone carrier s certificate. Then, the verifies the assertion with the mobile phone certificate. This case applies to indirect authentication. Each type of business agreement may be possible. If each mobile phone user (as an IdP owner) contracts with the s, that is a direct business agreement case. In the case when each mobile phone user contracts with the mobile phone carrier, and the mobile phone carrier contracts with the s, that is an indirect business agreement. If there are no business agreements between mobile phone users and s, our method will work effectively like the OpenID [7] system. 47

3 4. IMPLEMENTATION ISSUES 4.1 IdP Discovery Generally speaking, if an is federated with multiple IdPs, the may show an IdP s list to users and let them select an IdP, which they use before the issues an authentication request. In our method, each user has his/her own IdP, so the IdP list that the has may be too long. Therefore, we should choose another method. One possible method is to let users input their IdP s URL on an form like using OpenID. The SSO sequence flow with IdP discovery is shown in Figure 4. Authentication response IdP (Mobile Phone) (IdP discovery) Prompt for URL of user s IdP URL of user s IdP Initial authentication (if a user has not been authenticated) Figure 4: IdP discovery Verify response 4.2 Enabling Mobile Phones to act as Servers To use a mobile phone terminal as an IdP, we should enable the mobile phone to act as a server that user s can access by HTTP(S). However, accessing a mobile phone terminal from the Internet by HTTP may not be possible because of a mobile phone carrier policy. In addition, there are few mobile phone terminals on which we can implement server sockets. Therefore, we prepared a relay server on the Internet. This approach is often used to connect clients on the Internet to a server on an Intranet. For example, the relay server will be managed by mobile phone carriers. The sequence flow of our method that uses a relay server is shown in Figure 5. IdP (Mobile Phone) Relay Server Connect Initial authentication (if a user has not been authenticated) Authentication response Allocate one time URL (Optional) maintain connection Prompt for URL of user s IdP URL of user s IdP Relay authentication request to appropriate IdP by requested URL At first, an IdP on a mobile phone terminal accesses a relay server. The relay server authenticates an IdP (e.g., using TLS mutual authentication). Then, the relay server maintains the connection and associates it with the IdP URL. There are two possible ways to allocate an IdP URL: one is static allocation, and the other is dynamic allocation. If the IdP URL is allocated dynamically when the connection begins, the URL should be sent to the IdP through the connection and displayed on the mobile phone terminal LCD. Dynamic URL allocation reduces the risk that an attacker accesses a user s IdP. However, there is the demerit that a user cannot remember the URL of his/her IdP. When a user s redirects from the to the IdP, at first the is routed to the relay server using DNS resolution, and then, the relay server connects the to an appropriate IdP through an associated connection. Therefore, a WWW browser on a user s can access an IdP on a mobile phone. Using the relay server, most of the mobile phone IdP URL may be the same as the URL of the other mobile phone IdPs (Figure 6). Therefore, the user may be able to input only the distinct part of the URL. The username part of a mobile phone e- mail address or phone number may be used for the distinct part of the URL in the case of static allocation. In the dynamic allocation case, the distinct part of the URL is issued every time the mobile phone accesses the relay server. Then, the complements the URL with the common part of the URL and sends the authentication request to the URL. static allocated IdP URL common part distinct part (e.g. username) dynamic allocated IdP URL common part Figure 6: IdP URL distinct part (random string) 5. DISCUSSION ABOUT MITM ATTACK In this section, we discuss MITM attacks on our proposed method and possible countermeasures. Generally speaking, even if an authentication method is not a simple username-and-password method but a multifactor authentication is also used, there is still a risk of an MITM attack. The steps of a MITM attack on the OTP method are shown in Figure 7. OTP is an effective method against password leakage incidents; however, if users are lead to an MITM, and the MITM relays the traffic between the and, the MITM may login to the. In the following subsections, we discuss two types of MITM attack. One is the MITM attack with phishing and the other is with pharming. Figure 5: Mobile phone IdP with relay server 48

4 Phishing mail (click on fake URL) Prompt for one-time password MITM Prompt for one-time password the user judge whether the peer is him/herself. For example, domain name or country name can be used for that information. Intercepting an MITM attack using the method described above is shown in Figure 9. MITM IdP (Mobile Phone) One-time password One-time password Display information of accessing machine (e.g. domain name) Figure 7: MITM attack 5.1 MITM attack with Phishing At first, we discuss the MITM attack with phishing in which an attacker leads users to the MITM by causing users to click on a fake URL link in a phishing mail. As illustrated in Figure 8, there is a possibility of an MITM attack on our proposed method as well as other multifactor authentication methods. MITM IdP (Mobile Phone) Prompt for password Password Initial Authentication Prompt for password (Optional) Password authentication on a mobile phone (e.g. PIN code check) Authentication response Figure 8: MITM attack on proposed method The attacker relays a user request for service to the. Then, the user sends his/her IdP s URL (through the MITM) to the. After that, the will redirect the user to the IdP, but indeed, the MITM accesses the IdP by means of an authentication request. At this time, the IdP on a user s mobile phone asks the user to input authentication information such as a PIN code. The user mistakes the MITM access for his access, and inputs the PIN code into the mobile phone. Then, the IdP issues an assertion for the MITM to the. The correctly verifies the assertion and allows the MITM to login. Then, we show possible countermeasures. One difference between an ordinary IdP and our IdP on a mobile phone terminal is that our IdP can communicate with users without using the network in which an MITM may exist. Using this feature, the IdP can show user information about peers that access the IdP to let Access denied User notices the difference, and refuse authentication. Figure 9: Measure against MITM attack However, this method depends on the user s judgment, so more effective ways are still required. We think the combination with risk-based authentication seems effective. The idea is shown in Figure 10. MITM IdP (Mobile Phone) Initial authentication request Risk-based analysis (if the peer is not as usual, IdP requests user to perform initial authentication directly) Access denied Initial authentication and record characteristics of... Figure 10: Combination with risk-based authentication If the peer who brings an authentication request from a is not the usual peer, the IdP alerts the user through the mobile phone display and requests him/her to access the IdP URL directly (not via the ) and perform initial authentication. When the user directly accesses the IdP and initial authentication has succeeded, the IdP saves the characteristics of the user s such as domain name, type and version of OS and browser to use for judgment later. Of course, the IdP can store characteristics of several s because a user may not have only one. There are still some possibilities that the MITM provides fake information that can be analyzed. However, this approach reduces the risk of the MITM attack. 49

5 5.2 MITM attack with Pharming In this subsection, we discuss the MITM attack with pharming. In the pharming situation, even if the correct URL is input in a user s, he/she is led to rogue sites because the DNS or hosts files are spoofed. In this situation, an attacker may send an authentication request from the via a user s (Figure 11). Then, the IdP correctly authenticates the user and tries to send an authentication response to the correct URL via a user s. However, the user has been pharmed, so the authentication response will reach the MITM. Then, the MITM shows the assertion in an authentication response sent to the and logs in using the assertion. MITM IdP (Mobile Phone) (with true s URL) MITM redirects authentication request via User s Display Information about accessing machine (e.g. domain name) authentication (e.g. PIN code check) WWW browser OS Legend: NTT DoCoMo mobile phone IdP i-appli i-appli API J2ME CLDC OS Our developed components relay server Relay Servlet Tomcat J2EE Linux pre-existent components Figure 12: System architecture J Liberty Alliance middle ware OS 6.2 Demonstration In this subsection, we illustrate the user experience in our proposed authentication method with screen shots of the prototype system. The login page of the is shown in Figure 13. The user is required to input the URL of the IdP on the mobile phone instead of the username and password. Even if IdP sends Authentication response to true URL, authentication response arrives at MITM Authentication response Figure 11: MITM attack with pharming Including an IP address of an accessing terminal in an assertion may be effective in preventing this type of attack. When an receives the assertion, the compares the IP address of the accessing terminal to the IP address contained in the assertion to confirm whether the assertion was intercepted. According to the SAML v2.0 specification, we can include the IP address of an authentication subject in the SubjectConfirmation element in a SAML assertion. This may help s confirm whether the subject is correct or incorrect. However, if the and the MITM are in the same subnet, and they access the Internet through the same Network Address Port Translation (NAPT) or HTTP proxy, IP addresses that the sees are the same. This is one of the limitations of this approach. Figure 13: Login page The user launches the IdP application on the mobile phone (Figure 14), and inputs its URL into the prompt. 6. PROTOTYPE SYSTEM In this section, we introduce our prototype system in which we implemented our proposed method explained in the previous sections. 6.1 System Architecture The system architecture of our prototype system is shown in Figure 12. We have implemented an IdP as an i-appli [8] which is a Java application for NTT DoCoMo mobile phones. Using the i-appli API, we let the IdP sign assertions by private key on a USIM. We also implemented a relay server as a Java servlet. For the, we used software of Liberty Alliance s, which our team had implemented before. We only changed site-specific Java Server Pages (J) for the. Figure 14: Launch IdP application 50

6 After the user inputs the IdP URL, the browser of the user s is redirected to the IdP on the mobile phone. Then, the IdP confirms whether it can send an assertion to the (Figure 15). If the IdP authenticates the user successfully, the IdP creates a SAML assertion, signs it, and sends it to the via the user s browser (Figure 17). Figure 15: Notification of authentication request Figure 17: Send SAML assertion If the user allows the IdP to send an assertion, the user pushes the yes button. Then, the IdP on the mobile phone authenticates the user by checking the PIN code (Figure 16). Finally, the receives the SAML assertion from the IdP on the mobile phone and verifies it using the IdP s public key. If the verification is successfully performed, the provides services to the user (Figure 18). Figure 18: Welcome page Figure 16: PIN code authentication 51

7 6.3 Performance In this subsection, we describe the performance of our prototype system. Specifications of the mobile phone on which we had implemented an IdP are shown in Table 1. The mobile phone is one of the product models in the Japanese market which has the ability to perform digital signing. Table 1: Specifications of mobile phone Model NTT DoCoMo F903i [9] CPU SH-Mobile G1 [10] Communication speed 384 kbps We measured the processing time of our IdP, which was implemented on our mobile phone. First, we connected the mobile phone IdP to our relay server on the Internet. When the IdP receives an authentication request from an via a user s and relay server, we start measuring the processing time. When the IdP finishes sending an authentication response, we stop measuring. The processing times except for the waiting times for user interactions are shown in Table 2. Table 2: Processing time of IdP Process Time [second] Communication 3 Digital signing 3 Other 0.4 The results indicate that dominant factors are communication time and digital signing time. During the communication time, the total data size of an authentication request and response is less than 5k bytes, so transfer time may be negligible. Therefore, we think that almost 3 seconds is consumed for connection establishment overhead. The connection to the relay server is established before the start of the measuring time, but after the IdP receives an authentication request, the connection is closed. That is because our mobile phone can only communicate with the server on the Internet as an HTTP client. Hence, we transfer the authentication request on an HTTP response, and the authentication response on an HTTP request. This is similar to the Liberty reverse HTTP binding for SOAP (PAOS) [11]. However, we use our own protocol instead of SOAP. As a result, when the IdP sends an authentication response, a connection to the relay server is established again. Our IdP constructs a SAML assertion and generates a SignedInfo element of the XML-Signature [12], and signs the SignedInfo element with the RSAwithSHA1 algorithm. The data size of the SignedInfo element is approximately 700 bytes. According to Table 2, our mobile phone can sign 700 bytes of data in 3 seconds. The output data of a digital signature from our mobile phone is in the PKCS#7 [13] format, so we have to convert that to the Signature-element format of the XML-Signature specification at the relay server. The format conversion time in the relay server is less than 20 milliseconds using a Pentium III 1.2- GHz computer. 7. CONCLUSION In this paper, we have proposed an authentication method that uses a mobile phone as an IdP. To inform an about the user s IdP location, the user sends the URL to the like in the OpenID method. We prepared a relay server with which the browser of a user s can access the IdP on the user s mobile phone. Considering the MITM attack, a combination of risk-based authentication and including the information in the assertion is useful. We implemented our method on a mobile phone terminal and the method worked well with an. The prototype system works within a practical amount of time. REFERENCES [1] RSA SecureID Token for Mobile Phones, RSA Security Inc., [2] FirstPass, NTT DoCoMo Inc., (Japanese Only) [3] Liberty Alliance Project. [4] Security Assertion Markup Language (SAML) V2.0. Version 2.0. OASIS Standards. [5] Universal Subscriber Identity Module (USIM) conformance test specification. 3GPP TS [6] Trust Models Guidelines, OASIS, [7] OpenID, [8] i-appli, NTT DoCoMo Inc., tent/iappli/index.html [9] FOMA F903i, NTT DoCoMo Inc., /index.html [10] Renesas Technology s SH-Mobile G1 Chip to be Selected for FOMA 903i Series Handsets, 96.htm&fp=/company_info/news_and_events/press_releases [11] Liberty Reverse HTTP Binding for SOAP Specification, 303/file/liberty-paos-v2.0.pdf [12] XML-Signature Syntax and Processing, W3C Recommendation, [13] RFC PKCS #7: Cryptographic Message Syntax Version 1.5, 52