Authentication System for Stateless RESTful Web Service Sungchul Lee1, Ju-Yeon Jo2, Yoohwan Kim3 Department of Computer Science University of Nevada Las Vegas, Las Vegas, NV 89154 1 E-mail:
[email protected] 2, 3 E-mail: {Juyeon.Jo, Yoohwan.Kim}@unlv.edu Abstract – REST protocol is a commonly used Web-based communication interface in various areas (e.g., Web service, IoT devices). Current REST protocol faces several challenges to solve the authentication system. This paper describes an ID-based authentication algorithm using Boneh-Franklin ID-based encryption to achieve a secure and stateless RESTful Web service. This ID-based authentication process allows a server to handle client requests by acknowledging the client’s URI rather than storing client’s state, thereby simplifying the process. This paper discusses the shortcomings of current authentication mechanisms, the concept of ID-based encryption (IBE), and the process of stateless secure REST protocol. Keywords – ID-based encryption, RESTful Web service, ID-based authentication, REST I. INTRODUCTION Representational state transfer (REST)-based Web services are used commonly now. Extensive use of the Internet of things (IoT) has resulted in wider adoption of REST protocol [1]. IoT is useful in research as well as commercial applications. For example, the Nevada Solar Energy-WaterEnvironment Nexus project collects environmental data from various remote sensors [1] using IoT devices, and the data is archived at the Nevada Climate Change Portal (NCCP) [2]. In previous research, we developed a REST application program interface (API) for communication as well as Web service between sensors and server [3]. RESTful Web service became popular because of its efficiency in handling the client (e.g., user’s response), IoT data [4], and the ease of scaling up to manage a large number of clients. The firstgeneration Web service, Simple Object Access Protocol (SOAP), experienced multiple limitations when it handled various devices [5] and when scaling up was necessary. The second generation Web service, RESTful, has several benefits to address IoT because it is based on resource-oriented architecture (ROA) [6]. Accordingly, many Web service companies have shifted their API to REST from SOAP. For example, Google stopped using search API based on SOAP on December, 5, 2006 [7]. Also, REST occupied approximately 85% of Amazon interface in 2003 [8]. As a result, the majority of IoT and Web service companies are developing their Web interfaces based on RESTful Web service. The majority of IoT and Web service companies, however, are confronting challenges for configuring a stateless concept of REST because of authentication [13]. The stateless concept of REST means that a server doesn’t save the status of a client and, consequently, the server does not use the concept of session to comply with the principle of statelessness in the RESTful Web service. Without the notion of session, an authentication problem arises in the RESTful Web service. Here we revisit the benefits of utilizing RESTful Web service in the IoT environment and explore several methods that are in use for solving the authentication challenges. We then propose a novel authentication method that preserves the statelessness concept of RESTful Web service using IDbased cryptography. Also, we show implementation of an ID-based authentication system backed by performance testing. Last, we explain why ID-based authentication has a significant advantage in RESTful Web service.
Fig. 1. IoT with RESTful Web Service. II. FEATURES AND LIMITATIONS OF REST PROTOCOL REST protocol based on resource oriented architecture (ROA) [9] can manage various clients and models of IoT. REST includes four attributes of the ROA. The first attribute is addressability. Uniform resource identifiers (URI) represent all resources. This implies that all objects in the IoT can be identified through unique URI. Each URI must be used to handle each object. Therefore, REST uses URI as if the URI were a variable of object. Fig. 1 shows the process of identifying and controlling an IoT device by URI. The second attribute of REST is connectedness. In the IoT, connectedness is important for self-configuring. Connectedness is created based on addressability [10]. Resources have to be linked with other related resources to be presented to servers or users. Due to these two attributes of REST, resources and connections are well organized by URI. As a result, well-organized URI help an IoT system expedite self-configuration. The third attribute is homogenous interface. Resources are used by the basic four HTTP methods (i.e., GET, PUT, POST, and DELETE). Two more methods (HEAD and OPTION) relate to metadata and available methods: metadata can be shown using the HEAD method; OPTION is for checking available methods. Various objects use the same control interface by the function of homogenous interface. The fourth attribute of REST, the most important for this research, is statelessness. Connections made between servers and clients do not create sessions. Servers do not store the client state. So, clients must express their current state via HTTP header and body. Requested resources are only used once. Therefore, the request does not affect the next request. As there is no session, statelessness is good for balancing server loads. When one server is more highly loaded than other servers, the request is passed onto other servers without creating any additional work. Another beneficial attribute of statelessness is scalability [10]. There are authentication problems, however, because of statelessness of REST. As REST does not utilize sessions between server and client, the client authentication process is necessary whenever servers receive client requests. It is necessary to review the current authentication system before we present ID-based authentication. In the next section, we explain authentication methods for the RESTful Web service currently used (e.g., HTTP Basic/Digest Authentication, Access Token [OAuth]). III. CURRENT AUTHENTICATION FOR RESTFUL WEB SERVICE RESTful Web services are constantly burdened with the authenticating process of users. A frequent user-authentication process can cause CPU overload or waste the large amount of network resources [5,8]. Servers have to authenticate the client information for every request because of security. Instead of sending ID and password via the POST method, most companies have been trying to address the challenge by using HTTP basic authentication, HTTP digest authentication, and access token (OAuth). In this section, we discuss the basic authentication methods that are used on the Web. 1) HTTP basic authentication: This uses the ID and password of a client to authenticate the
Fig. 2. HTTP Authentication. client’s request in the HTTP header. Fig. 2 shows the HTTP authentication phases. When a server requests an authentication for a client, the server sends a message “HTTP 401 Not Authorized” with WWW-authenticated HTTP header. The client’s ID and password are encoded with Base64 and stored in the HTTP authentication header. As they are neither encrypted nor hashed, they are usually sent via HTTPS or SSL. HTTP basic authentication has a critical issue, however, in that it doesn’t support a logout function. Also, HTTP basic authentication has security vulnerabilities of replay attack, injection attack, and middleware hijacking [11]. Because of the need for saving ID and password in the HTTP Header, HTTP basic authentication can be exposed to such attacks. 2) HTTP digest authentication: This is an advanced version of HTTP basic authentication. HTTP digest authentication encrypts the client’s ID and password via hash such as MD5 [12]. By creating a nonce on the client side, HTTP basic authentication can protect the hash from a Rainbow Table attack. Also, the timestamp created on a server can secure the message of a client from a replay attack. HTTP digest authentication, however, has several security vulnerabilities. For instance, since it does not provide a method to verify the server to a client, HTTP digest authentication can be attacked via the Man-in-the-Middle method. Such an attack changes HTTP digest authentication to HTTP basic authentication, thereby nullifying the purpose of HTTP digest authentication. 3) Token based authentication (OAuth): This uses a token instead of a user’s ID and password [13]. Fig. 3 shows the way token based authentication works when the information of a user is authenticated. Resource server (RS) redirects the user’s browser to private key generator (PKG) when a user requests RS service. First, users log into an authorization server (AS) to get a token.
Fig. 3. Token based authentication.
Second, RS gets the token from the AS. Last, RS verifies the messages from the user using the token. Consequently, due to the use of a token in communication between a user and RS, users’ ID and passwords are protected from a third party. The OAuth method is frequently implemented by various Web service companies (e.g., Twitter, Yahoo, Google, Facebook, and Microsoft) because of this advantage. Even though REST is based on the principle of statelessness, the above authentication methods necessitate implementation of statelessness across multiple requests. HTTP basic authentication and HTTP digest authentication need sessions to authenticate client messages. Servers have to store a session ID to run a communication between RS and clients. This means that such methods are not stateless due to multiple sessions. Otherwise, without using a session, HTTP basic authentication and HTTP digest authentication would have to authenticate every single request of a client each time, thereby wasting time and resources of CPU and network. Also, these methods have security vulnerability due to contained (contaminated) ID and password. Because of authentication issues with these two methods, most companies use OAuth instead of HTTP basic authentication or HTTP digest authentication. OAuth is also vulnerable for security breach, however, namely covert redirect vulnerability (CRV). This method uses redirection (Fig. 3) by exploring a parameter. Attacker forges a login page (Fig. 3, ID and password) or by redirecting the URI to get client’s ID and password. Also, token based authentication is not exhibit full statelessness because a server has to store the token during the communication with the client. Next, we show the main mechanism to be authentication for communication, before explaining the concept of ID-based encryption (IBE) and then show the Boneh-Franklin scheme – an IBE system proposed by Dan Boneh and Matthew K. Franklin in 2001 [14]. IV.
PROPOSED STATELESS LIGHTWEIGHT AUTHENTICATION
In the HTTP basic authentication, the server via a two-step process authenticates a client, but this has security vulnerability as mentioned above [11]. OAuth uses a third party for authentication (i.e., a client has to access the OAuth server to get a token in order to access a resource server [e.g., Web server]). Specifically, OAuth requires extra steps (from step 2 to step 6) in Fig. 3. Generally, all current authentication methods for REST require additional steps (e.g., a redirection in OAuth, storage of a session key, or storage of ID and password in HTTP authentication). Those requirements make it difficult to maintain statelessness of the RESTful Web service. As a solution, we propose a lightweight, stateless, authentication mechanism for REST using IDbased cryptography, which we call ID-based authentication (IBA). In IBA, the receiving machine’s URI is virtually a public key, so there is no need to exchange the public keys separately. If a client knows the URI of the resource server (RS), the client can derive the public key of the RS from the URI and the master public key – and vice versa. They also can sign the message for mutual authentication using their own private keys. Therefore, both RS and the client can authenticate each other using only their URIs.
Fig. 4. Data exchange with ID-based authentication.
Table 1. Symbols used in IBE. Symbol MKpub MKpri KAlice-pub KAlice-pri KBob-pub KBob-pri C M E D P
Notation PKG public key PKG private key Alice public key Alice private key Bob public key Bob private key Cipher text Message Encrypt Decrypt Master public point
Symbol S
Bobemail RSpub RSpri r P sQ, sQ` URIRS URIClient Cs G
Notation Master private point Bob email address Resource Server public key Resource Server private key Random number Random point Client Private point Resource Server URI address Client URI address Signed cipher text Generate key
Furthermore, OAuth itself does not provide an encryption capability, and OAuth typically relies on SSL/TLS for encryption (step 7, Fig. 3) incurring high process and network overhead. OAuth implementations also have some known security vulnerabilities [15]. Alternatively, our IBA does not require any extra step for encryption and signature. Fig. 4 shows the steps in the proposed IBA. Details of the IBA are described in later sections. Next we explain the IBE algorithm. V. BASIC CONCEPT OF ID-BASED ENCRYPTION IBE is an asymmetric key algorithm. It was first proposed by Adi Shamir in 1984 [16] to simplify the certificate management process in e-mail systems. With IBE, the sender and receiver do not need to obtain public key certificates of each other. Unlike in RSA in which public and private keys are generated at the same time by the user, a private key is created first by private key generator (PKG) in IBE. PKG is a trusted third party entity that computes the clients’ private keys from their unique ID such as e-mail addresses [16]. The public keys are generated by the sender as needed from the destination’s unique ID and PKG’s public parameters. This process is summarized in the following sequence (symbols in Table 1): PKG: Alice: Bob:
KAlice-pri = G (MKpri, Aliceemail) KBob-pri = G (MKpri, Bobemail) KBob-pub = G (MKpub, Bobemail) C = E (KBob-pub, M) M = D (KBob-pri, C)
According to Dan Boneh and Matthew K. Franklin [14], four steps (i.e., setup, extract, encrypt, and decrypt) define IBE protocol framework. Setup works for PKG to create a master private key and a master public key. The master private key is kept securely in the PKG and used to generate client private keys. The master public key (public parameters) is open to the public. Extract generates a client private key. When a client requests a private key with ID, PKG generates a private key using the master private key. Encrypt occurs when the sender encrypts a message using a receiver’s public key generated by PKG. In the decrypt step, the receiver decrypts the encrypted message using a private key generated by PKG. In the next section, we provide details for the above four steps. VI. BONEH-FRANKLIN ID-BASED ENCRYPTION The Boneh-Franklin (BF) scheme uses elliptic curves and finite fields for IBE protocol. Elliptic curve cryptography (ECC) was first suggested by V. S. Miller [17] and N.Koblitz [18]. ECC is a public key cryptography with pairing based on cryptography. ECC can be divided into two groups, public groups G1 and G2 [17, 18]. The points P1 and P2 are on the elliptic curve that satisfies the
following equation: y2 = x3 + ax+ b (mod p) where P1 = (x1, y1), P2 = (x1, y1) When P1 is added to P2, the equation has only one point, P3. BF-IBE uses this concept to create a pair for the client public key and private key. 1) Setup: PKG makes a master private key and public key a) Selecting elliptic curve E and a large prime p in cycle group Zp ∈ E. b) Making additive group G1 using point P that is prime order p in the E. c) PKG chooses an arbitrary P ∈ E of order q. d) Making a group G2 using prime order q depending on security parameter k. e) Corresponding pairing e: G1 X G1 → G2 f) PKG master private key: 0< s
