Mobile OTP

THE MOBILE PHONE AS AN OTP DEVICE BASED 2 FACTOR AUTHENTICATION

The rapid growth in the number of online services leads to an increasing number of different digital identities each user needs to manage. As a result, many people feel overloaded with credentials, which in turn negatively impacts their ability to manage them securely. Passwords are perhaps the most common type of credential used today. To avoid the tedious task of remembering difficult passwords, users often behave less securely by using low entropy and weak passwords. Weak passwords and bad password habits represent security threats to online services. Some solutions have been developed to eliminate the need for users to create and manage passwords. A typical solution is based on giving the user a hardware token that generates one-timepasswords, i.e. passwords for single session or transaction usage. Unfortunately, most of these solutions do not satisfy scalability and/or usability requirements, or they are simply insecure. Besides the fact that, the widespread use of the Internet has contributed enormously towards the growth of e-commerce. Technological advances in mobile phones (e.g. Smartphones) have also made it possible to carry out e-commerce via mobile phones (m-commerce). M-commerce involves the use of mobile devices such as mobile phones and PDAs in carrying out electronic transactions. Applications in this domain range from normal information consumption to high security financial electronic transactions. Just like e-commerce, the security of mcommerce applications is critical, especially when it involves applications that deal with user sensitive data such as credit cards details, medical details etc. One of the solutions for this issue is the two factor authentication technique as a fundamental security function. Our proposal, The mobile phone as an OTP device Based 2 Factor Authentication, explores the two factor authentication technique and implementation issues which can be used for the two factor authentication technique. In this thesis, we propose a scalable OTP solution using mobile phones and based on trusted computing technology that combines enhanced usability with strong security. Two factor authentication also have disadvantages which include the cost of purchasing, issuing, and managing the tokens or cards. From the customers point of

Mobile OTP

view, using more than one two-factor authentication system requires carrying multiple tokens/cards which are likely to get lost or stolen. Mobile phones have traditionally been regarded as a tool for making phone calls. But today, given the advances in hardware and software, mobile phones use have been expanded to send messages, check emails, store contacts, etc. Mobile connectivity options have also increased. After standard GSM connections, mobile phones now have infra-red, Bluetooth, 3G, and WLAN connectivity. Most of us, if not all of us, carry mobile phones for communication purpose. Several mobile banking services available take advantage of the improving capabilities of mobile devices. From being able to receive information on account balances in the form of SMS messages to using WAP and Java together with GPRS to allow fund transfers between accounts, stock trading, and confirmation of direct payments via the phones micro browser . Installing both vendor-specific and third party applications allow mobile phones to provide expanded new services other than communication. Consequently, using the mobile phone as a token will make it easier for the customer to deal with multiple two factor authentication systems; in addition it will reduce the cost of manufacturing, distributing, and maintaining millions of tokens. By definition, authentication is the use of one or more mechanisms to prove that you are who you claim to be. Once the identity of the human or machine is validated, access is granted. Three universally recognized authentication factors exist today: what you know (e.g. passwords), what you have (e.g. ATM card or tokens), and what you are (e.g. biometrics). Recent work has been done in trying alternative factors such as a fourth factor, e.g. somebody you know, which is based on the notion of vouching. Two factor authentication is a mechanism which implements two of the above mentioned factors and is therefore considered stronger and more secure than the traditionally implemented one factor authentication system. Withdrawing money from an ATM machine utilizes two factor authentication; the user must possess the ATM card, i.e. what you have, and must know a unique personal identification number (PIN), i.e. what you know. Passwords are known to be one of the easiest targets of hackers. Therefore, most organizations are looking for more secure methods to protect their customers and employees. Biometrics are known to be very secure and are used in special

Mobile OTP

organizations, but they are not used much in secure online transactions or ATM machines given the expensive hardware that is needed to identify the subject and the maintenance costs, etc. Instead, banks and companies are using tokens as a mean of two factor authentication. A security token is a physical device that an authorized user of computer services is given to aid in authentication. It is also referred to as an authentication token or a cryptographic token. Tokens come in two formats: hardware and software. Hardware tokens are small devices which are small and can be conveniently carried. Some of these tokens store cryptographic keys or biometric data, while others display a PIN that changes with time. At any particular time when a user wishes to log-in, i.e. authenticate, he uses the PIN displayed on the token in addition to his normal account password. Software tokens are programs that run on computers and provide a PIN that changes with time. Such programs implement a One Time Password (OTP) algorithm. OTP algorithms are critical to the security of systems employing them since unauthorized users should not be able to guess the next password in the sequence. The sequence should be random to the maximum possible extent, unpredictable, and irreversible. Factors that can be used in OTP generation include names, time, seed, etc. Using tokens involves several steps including registration of users, token production and distribution, user and token authentication, and user and token revocation among others. While tokens provide a much safer environment for users, it can be very costly for organizations. For example, a bank with a million customers will have to purchase, install, and maintain a million tokens. Furthermore, the bank has to provide continuous support for training customers on how to use the tokens. The banks have to also be ready to provide replacements if a token breaks or gets stolen. Replacing a token is a lot more expensive than replacing an ATM card or resetting a password. From the customers prospective, having an account with more than one bank means the need to carry and maintain several tokens which constitute a big inconvenience and can lead to tokens being lost, stolen, or broken. In many cases, the customers are charged for each token. We propose a mobile-based software token that will save the organizations the cost of purchasing and maintaining the hardware tokens. Furthermore, will allow

Mobile OTP

customers to install multiple software tokens on their mobile phones. Hence, they will only worry about their mobile phones instead of worrying about several hardware tokens. The mobile OTP software describes a method of implementing two factor authentication using mobile phones. The proposed method guarantees to authenticating to services, such as online banking or ATM machines, is done in a secure manner. The proposed system involves using a mobile phone as a software token for One Time Password generation. The generated One Time Password (OTP) is valid for only a short user-defined period of time and is generated by factors that are unique to both, the user and the mobile device itself. In order to secure a system, the generated OTP must be hard to guess, retrieve, or trace by hackers. Therefore, it's very important to develop a secure OTP generating algorithm. Several can be used by the OTP algorithm to generate a difficult-to-guess password (user can use mobile number or PIN for services such as authorizing mobile micropayments). These factors must exist on both the mobile phone and server in order for both sides to generate the same OTP password.

In proposed design, the following factors were chosen to generate an OTP: -IMEI number of mobile device (get IMEI number to play as the factor to generate seed code. The term stands for International Mobile Equipment Identity which is unique to each mobile phone allowing each user to be identified by his device. This is accessible on the mobile phone and will be stored in the servers database for each client. - IMSI: the mobile phone number (we can use the mobile phone number when the mobile devices supporting the SIM card instead of IMEI number of device). The term stands for International Mobile Subscriber Identity which is a unique number associated with all GSM and Universal Mobile Telecommunications System (UMTS) network mobile phone users. It is stored in the Subscriber Identity Module (SIM) card in the mobile phone. This number will also be stored in the servers database for each client -PIN code (to be secure user when login app). This is required to verify that no one other than the user is using the phone to generate the users OTP. The PIN together
4

Mobile OTP

with the username is data that only the user knows so even if the mobile phone is stolen the OTP cannot be generated correctly without knowing the users PIN. Note that the username and the PIN are never stored in the mobiles memory. They are just used to generate the OTP and discarded immediately after that. In order for the PIN to be hard to guess or brute-forced by the hacker, a minimum of 8-characters long PIN is requested with a mixture of upper- and lower-case characters, digits, and symbols. - Username (user registered account with the authentication server. Although no longer required because the IMEI will uniquely identify the user anyway. This is used together with the PIN to protect the user in case the mobile phone is stolen. -Hour, minute, day, year (time makes the OTP set unique to other times, application get the time from the service). The time is retrieved by the client and server from the telecommunication company or authentication server. This will ensure the correct time synchronization between both sides. The following chart is how the software generating OTP using HMAC-SHA1 algorithm:

-Seed: a key is shared with each side (client and server), it is made from factors which mentioned.

Mobile OTP

-Counter: a counter event (click on generating OTP) or time counter (period time to change to the new OTP), it is synchronized both sides (client and server). OTP change for each defined period of time (30seconds, 60 seconds or 1 minutes, 2 minutes, ...) Model For Implementing OTP In this paper, we propose a mobile-based software token system that is supposed to replace existing hardware and computer-based software tokens. The system will have two modes of operation: Independent Authentication System (OTP is generated in both sides: client and server): A one-time password (OTP) is generated without connecting the client to the server. The mobile phone will act as a token and use certain factors unique to it among other factors to generate a one-time password locally. The server will have all the required factors including the ones unique to each mobile phone in order to generate the same password at the server side and compare it to the password submitted by the client. The client may submit the password online or through a device such as an ATM machine. A program will be installed on the clients mobile phone to generate the OTP. - Register device:

Mobile OTP

- Generate OTP: input pin in order to make OTP

Mobile OTP

Database Design A database is needed on the server side to store the clients identification information such as the first name, last name, username, pin, password, mobile IMEI number, IMSI number, unique symmetric key, and the mobile telephone number for each user. It will not store the password itself. Should the database be compromised the hashes cannot be reversed in order to get the passwords used to generate those hashes. Hence, the OTP algorithm will not be traced. Client Design An Android program is developed and installed on the mobile phone to generate the OTP. The OTP program has the option of generating the OTP locally using the mobile credentials, e.g. (IMEI and IMSI numbers). In order for the user to run the OTP program, the user must enter his PIN and select the OTP generation method. The PIN and generated OTP are never stored on the mobile phone.
8

Mobile OTP

If the user inputs PIN is used to locally generate the OTP and is discarded thereafter. The PIN is stored on the servers side to generate the same OTP. Server Design A server is implemented to generate the OTP on the organizations side. The server consists of a database as described in Database Design. In order to setup the database, the client must register in person at the organization. The clients mobile phone/SIM card identification factors, e.g. IMEI/IMSI, are retrieved and stored in the database, in addition to the username and PIN. The Android OTP generating software is installed on the mobile phone. The software is configured to connect to the servers GSM modem in case the SMS option is used. A unique symmetric key is also generated and installed on both the mobile phone and server. Both parties are ready to generate the OTP at that point. Finally, there is a method for authentication using OTP mobile device

Note that the token symbol, now, play as mobile phone (mobile devices)

Mobile OTP

In order to use this software, a customer must be login with registered username with authentication server. When a user lost a username using for any services (the username is disclosed), he can absolutely believe that the hacker can not use it for cheating his account, as only a device which registered with server can make the OTP password in the same which is correct to authenticate. In case of losing the mobile phone, none can use it for generating OTP because it requires password and username to login that OTP software.

How do we integrate OTP to authentication process of VMEET or MoMEET application for seriously important video meeting?
This approach, mobile phone OTP as two factor authentication can be used for checking the user when the user connect to meeting room on MoMeet application to assure to be secure that user. It is necessary to protect the user from illegal access of others. OTP code resolves the problem how do we verify that a user is he claims to be; it brings the security for all of the important video meeting in any organization. Multiple factor authentication aims to solve the various problems associated with single factor methods by adding another layer of security to the authentication process. The method involves the use of some-thing the user knows (e.g. OTP) and something the user has which improves the strength of the authentication process. The following figure is the OTP authentication process flow:

10

Mobile OTP

OTP

Summary: OTP-Based Two-Factor Authentication Using Mobile Phones

Authentication is the cornerstone of security information. It is accepted that authentication uses one or more of these: The users knowledge, such as password or PIN with username The users possession, such as smart card and token The users biometrics, such as fingerprint, DNA, ... The users behavior, such as voice and a signature

Password based authentication is the most widely used.

11

Mobile OTP

A one time password solves the problems of reusable passwords. Areas of use: Online banking: Log on and payment authorization Card payment: payment authorization Automated application process: Loans and insurance Mutual funds and share trading Ticket purchasing and change on the mobile Healthcare Industry Secure and Remote Data Accessing Login to Operating Systems and Web Servers Setting up a Strong, Shared Key between parties that only share an OTP value. Benefit of mobile Authentication using OTP software: Replace HW (hardware) tokens with your mobile phone User friendly Pay for the value, not the hardware Only one token: Your mobile phone One mechanism for many service providers Meets banking security requirements

About OTP algorithm in Detail:

The algorithm that will generate one time passwords is TOTP (Time-based One Time Password), an extension of HOTP (HMAC-Based One Time Password) to support a time based moving factor. TOTP is an Internet Engineering Task Force standard and a cornerstone of Initiative for Open Authentication (OATH). As defined in RFC 4226, the HOTP algorithm is based on HMAC-SHA1. The security and strength of this algorithm depends on the properties of the underlying building block HOTP, which is a construction based on HMAC [RFC2104] using

12

Mobile OTP

SHA-1 as the hash function. The security analysis conclusions described in RFC 4226 are that for all practical purposes. The conclusion of the security analysis detailed in RFC4226 is that, for all practical purposes, the outputs of the dynamic truncation on distinct inputs are uniformly and independently distributed strings. HOTP was published as an informational IETF RFC 4226 in December 2005, documenting the algorithm along with a Java implementation. Since then, the algorithms were adopted by many companies worldwide and became the world's leading standard for event-based OTP authentication. The HOTP algorithm is a freely available open standard. A. HOTP Algorithm: The HOTP algorithm is based on an increasing counter value and a static symmetric key known only to the token and the validation service. In order to create the HOTP value, we will use the HMAC-SHA-1 algorithm, as defined in RFC 2104. As the output of the HMAC-SHA-1 calculation is 160 bits, we must truncate this value to something that can be easily entered by a user.

Where: Truncate represents the function that converts an HMAC-SHA-1 value into an HOTP value. C is 8-byte counter value, the moving factor. This counter MUST be synchronized between the HOTP generator (client) and the HOTP validator (server). K is the shared secret between client and server; each HOTP generator has a different and unique secret K. We can describe operations in 3 distinct steps: Step 1: Generate an HMAC-SHA-1 value: HS = HMAC-SHA-1(K, C) Step 2: Generate a 4-byte string (Dynamic Truncation): Sbits = DT (HS) DT returns a 31-bit string. Step 3: Compute an HOTP value:

13

Mobile OTP

Snum = StToNum(Sbits), Convert S to a number in 0 231 1 Return D = Snum mod 10 ^ Digit D is a number in the range 0 10Digit-1 Digit: number of digits in an HOTP value, system parameter. The Truncate function performs Step 2 and Step 3, i.e., the dynamic truncation and then the reduction modulo 10Digit. The purpose of the dynamic offset truncation technique is to extract a 4-byte dynamic binary code from a 160-bit (20-byte) HMACSHA-1 result. We define DT function as: DT (String) Let OffsetBits be the low-order 4 bits of String [19] Offset = StToNum (OffsetBits) Let P = String[OffSet]... String[OffSet+3] Return the Last 31 bits of P End (DT) where: String=String[0]...String[19] 0 <= OffSet <= 15 The reason for masking the most significant bit of P is to avoid confusion about signed vs. unsigned modulo computations. Different processors perform these operations differently, and masking out the signed bit removes all ambiguity. Implementations MUST extract a 6-digit code at a minimum and possibly 7 and 8-digit code. B. TOTP Algorithm: Notations:

14

Mobile OTP

X represents the time step in seconds (default value X = 30 seconds) and is a system parameter; T0 is the Unix time to start counting time steps (default value is 0, Unix epoch) and is also a system parameter. Basically, we define TOTP as: TOTP = HOTP (K, T) Where T is an integer and represents the number of time steps between the initial counter time T0 and the current Unix time (i.e. the number of seconds elapsed since midnight UTC of January 1, 1970). More specifically, T = (Timestamp curent - T0)/X The analysis demonstrates that the best possible attack against the HOTP function is the brute force attack.

15

Mobile OTP

References 1. Wikipedia, Time-based One-time Password Algorithm, http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm. 2. RFC 4226, HOTP: An HMAC-Based One-Time Password Algorithm, http://tools.ietf.org/html/rfc4226 3. Wikipedia, HOTP, http://en.wikipedia.org/wiki/HOTP 4. TOTP: Time-based One-time Password Algorithm, http://tools.ietf.org/html/rfc6238

16