FEATHER: A Proposed Lightweight Protocol for Mobile Cloud Computing Security

-Ensuring security for lightweight cryptosystems in mobile cloud computing is challenging. Encryption speed and battery consumption must be maintained while securing mobile devices, the server, and the communication channel. This study proposes a lightweight security protocol called FEATHER which implements MICKEY 2.0 to generate keystream in the cloud server and to perform mobile device decryption and encryption. FEATHER can be used to implement secure parameters and lightweight mechanisms for communication among mobile devices and between them and a cloud server. FEATHER is faster than the existing CLOAK protocol and consumes less battery power. FEATHER also allows more mobile devices to communicate at the same time during very short time periods, maintain security for more applications with minimum computation ability. FEATHER meets mobile cloud computing requirements of speed, identity, and confidentiality assurances, compatibility with mobile devices, and effective communication between cloud servers and mobile devices using an unsafe communication channel.

transfer of confidential information. However, some require a large computation capability. The Advanced Encryption System (AES) is widely used because it is a very strong and secure cryptosystem [5]. However, it is a "heavy" system that requires large computational resources, has high power consumption, and is therefore not suitable for mobile devices with limited computation capacity. Some researchers have introduced lightweight versions of AES for small devices, such as ALE [6], to reduce the demand on resources, such as Central Processing Units (CPUs) and memory, used to generate the keystream. Some components in cloud computing such as embedded systems on cloud computing with 32-bit, 16-bit, and 8-bit microcontrollers cannot meet real time demands for conventional methods of cryptography [7]. Therefore, AES is a poor solution for many embedded devices in cloud computing that have low computation ability.

B. Cloud Computing
For a lighter encryption method in cloud computing, lightweight stream ciphers can be implemented to provide the required security. Lightweight stream ciphers include a decryption function and an encryption function to handle messages of arbitrary length. Thus, they are better than block ciphers, such as AES, that only handle inputs of a fixed length. Due to their functionalities, they are well adapted to low bandwidth or noisy communications and thus are appropriate for cloud computing. Speed, memory, number of CPUs, and cost efficiency are also important factors [8]. In [9], a MICKEY 2.0 variant, MICKEY 2.0.85, was proposed as the preferred choice over other lightweight stream ciphers. It is lighter and has lower energy consumption, which means it is more cost efficient [10]. However, the protocol can be adapted to implement other lightweight ciphers, such as Trivium or Grain. Al-Omari [11] proposed a lightweight block cipherbased encryption mechanism and tested a faster algorithm by comparing it to an AES cipher in terms of speed. Ali et al. [12] focused on a cloud-based file distribution and management model, and showed that the ability of cloud computing to adapt is important for users, and not only in terms of data storage. The study also addressed the problem of offloading tasks to the server by using multiple servers and demonstrated how this method provides more security when sharing data. Hassan et al. [13] discussed cloud computing applications using machine learning approaches as a useful direction for predicting loading using statistical analysis, as well as for ensuring service level agreements.
III. LITERATURE REVIEW Bahrami and Singhal [14] studied the adequacy of using AES in mobile cloud computing and explained that, due to cost, cryptosystems such as AES are not suitable for mobile devices, because mobile devices have limited resources, such as limited power energy, low speed processors, and tiny RAM capacity. AES is not the appropriate encryption technique, since offload and download is done for every single transferred file. They introduced lightweight methods, such as pseudorandom permutation, based on chaos systems. Another solution is using lightweight security methods that provide a balance between energy efficiency and security. A lightweight security technique can be considered an easy operation (i.e. a permutation) instead of using complicated and expensive operations when using secret key or public key encryptions [15][16][17].

A. The Advantage of using Stream Ciphers in Small Devices
A stream cipher is a symmetric cryptosystem that uses the same key for encryption and decryption. Stream ciphers can transform data faster than other ciphers, such as block ciphers, and also faster than ciphers in an asymmetric cryptosystem [18,19]. Stream ciphers are less secure than other, symmetric and block cipher, types of cryptosystems, such as AES which is one of the most secure ciphers. The encryption process in AES involves permutations and a substitution process and requires a number of rounds, which increases the power and storage requirements. On the other hand, lightweight stream ciphers such as MICKEY 2.0, Trivium, and Grain [20] need much less power and memory. Widely used lightweight stream ciphers for small applications include E0 (Bluetooth), RC4 (Web), and the A5 family (GMS) [21]. Stream ciphers have advantages due to their high throughput property and low computational complexity. Lightweight stream ciphers [22] are a better choice than block ciphers because they need less memory and less hardware complexity

B. Using Lightweight Stream Ciphers in Cloud Computing
and Mobile Cloud Computing Lightweight stream ciphers have several advantages for cloud computing. They provide fast encryption by generating a secure keystream faster than other popular ciphers, such as AES. They need fewer computation facilities, such as CPUs and memory from the cloud, which reduces cost and power consumption significantly. Additionally, they include faster encryption, the consumption of less battery power, and lower bandwidth requirements.

C. AES and CLOAK Protocols
CLOAK is a lightweight protocol based on the AES cipher that enables two mobile devices to communicate, while leaving the keystream generation on an external server [23]. As CLOAK can get the keystream from either trusted or untrusted external servers, the main security concern is to protect the keystream. Security can be compromised by fetching the keystream from an external server and from communication media. Lightweight stream ciphers that can be used in mobiles include Trivium [24], Grain [25], and MICKEY 2.0 [26]. MICKEY 2.0 cipher is more resistant to statistical attacks [27][28][29] and it can produce large throughput. The lightweight protocol developed in this study does not rely on the server to be secure and will not be compromised as in the CLOAK protocol, which assumes the security of the server relies on the server provider [23]. Using MICKEY 2.0 in this lightweight protocol to provide a secure keystream is significantly faster than using AES. For example, the time needed by the server to generate the keystream is reduced, which in turn reduces the time to transfer the data between the server and the mobile.
Adithya et al. [30] introduced another enhancement for the CLOAK security, which is compared to the proposed FEATHER protocol in this study in Figure 3, and discussed in Section VIII.

A. Overview
The study designed a MICKEY 2.0 cipher based protocol called FEATHER to strengthen confidentiality and protection during messaging between mobile devices, as well as communication between devices and the cloud server (see Figure 1). The MICKEY 2.0 cipher produced a secure keystream in the external server to reduce reliance on mobile devices that have limited computing power and memory. The role of mobile devices is only encryption and decryption, which allows mobile devices to compute and reduce the amount of energy consumed by the device battery. A lightweight secure protocol is introduced for communication between devices and the external server over the cloud, as well as design applications on mobile devices for the process of verification and encryption and decryption. The proposed protocol is faster and can move larger files than the CLOAK cipher [23]. The protocol also maintains a high level of security. The protocol was designed to achieve security through the application of the MICKEY 2.0 cipher with additional protection systems for identity verification, such as hash functions, time stamps, and out-of-band passwords. A lightweight stream cipher is needed to generate the keystream faster and use fewer resources, so more secure applications can take advantage of advances in mobile cloud computing. If the keystream generated in the server is faster, it will allow more mobiles to get it from the cloud compared to a heavy encryption system like AES. Thus, it will be more efficient and will reduce cost. Using MICKEY 2.0 meets most of these needs.

B. Design Principles
There are ten design principles for a lightweight protocol:

1) Avoid Implementing a Heavy Encryption Method
As some popular encryption algorithms, such as AES, require considerable resources in terms of CPU time and/or memory usage, the protocol should offload the more computing-intensive steps to a server in the cloud while simplifying the steps carried out on the mobile device. Therefore, a lightweight protocol can offload generation and storage of the keystream to a server using the MICKEY 2.0 algorithm.

2) Avoid Relying Entirely on the Server
It is important to avoid relying entirely on the server to ensure communication security. Then, even if an adversary compromises the server, it cannot easily use the captured keystream data to decrypt messages directly. Although the client receives a keystream from the server, the client does not use it directly. Instead, the client selects a few random values using primitive polynomials to apply the keystream to the plaintext to compute the encrypted data.

3) Send Messages between Client and Server over the Internet
The protocol must assume an adversary may intercept messages or an impostor may try to insert invalid messages in the client-server communication. One popular approach is to use a key-exchange algorithm, such as Diffie-Hellman (which is vulnerable to a man-in-the-middle attack), or a more sophisticated Station-to-Station protocol [31], which avoids this vulnerability. The significant computation of these approaches may not be appropriate for simple mobile or microcontroller devices. The protocol needs to assume the ability to send brief out-of-band messages using a different communication medium. For example, if the protocol is implemented on top of the HTTP protocol, a secret out-of-band message may be sent by email or SMS. In this protocol, an outof-band message is sent from the server to the client to convey a one-time-pad, and from one client to another to convey a file token and the secret values (using primitive polynomials) used to step through the keystream.

4) Focus on Authentication on Unique Security Parameters
For authentication, this protocol uses a "bring something, know something" technique. The protocol assumes that each mobile device (or microcontroller device) has a Universally Unique Identifier (UUID). It also allows each user to select a username that is not necessarily unique. These are combined using a hash function to generate a Unique Identifier (UID) for each user. At the initiation of the protocol, each user registers its UID and then communicates an encrypted copy of its secret password to the server. For subsequent communication, all messages between the client and the server are validated using a digital signature based on hashing the message and the secret password. In this case, the "bring something" refers to the device and its UUID and the "know something" refers to the user's secret password. Since an adversary does not know the secret password, it cannot generate a valid signature, so the client and server can reject messages with invalid signatures.

5) Secure the Communication between the Client and the Cloud Server
Client-server communication security relies on a shared keystream. This shared keystream is first generated by the server when the client sends a message to register the user. In its response to the client, the server sends the shared keystream, encrypted with the one-time-pad, to prevent an adversary from capturing the keystream.

6) Offload the Keystream Generation to the Cloud Server
The server implementation may use any reasonable technique for keystream generation. In practice, a method is needed that is computationally efficient and still provides a reasonable level of security. To generate a new keystream for each user, the server must first create an initial key (or key+IV pair).

7) Ensure Client Request for the Keystream from the Cloud Authentications
When the client submits a request to generate a new keystream, it includes a token and expiry time. There are two possible implementations. The server may simply generate and store a key, and then generate the actual keystream "on the fly" whenever requested. Alternatively, the server may generate the keystream right away and store it as a file to be retrieved later when the client submits the corresponding token. The expiry time allows the client to limit the time the keystream is stored on the server. This reduces the availability of the keystream if an adversary tries to compromise the server.

8) Ensure There Are Possible and Flexible Variations for Secure Data Transfer
To enhance the security of the protocol, the server never has access to the unencrypted data. The data are encrypted by the client, using a modified version of the keystream, and this modification is unknown to the server. When transferring encrypted data from one client to another, there are three main options available.
• In one variation, since the data are securely encrypted, the file can be uploaded to any simple file server. This may provide an increased level of security since it introduces a separation from the keystream server and the file server. In fact, clients would be free to use a variety of different file servers to transfer encrypted data files, as long as these are communicated between the sender and receiver.
• In a simpler implementation, the clients can upload or download the encrypted data to the server and are being identified by a unique token which can be pseudo-randomly generated. Any other client can download the encrypted file, asynchronously, once it receives the appropriate token from the first client. Some efficiency can be gained if the file upload and download is implemented on the keystream server, since the same protocol mechanism can be used to download a keystream (given a token) or to download encrypted data (given a token). In fact, once a keystream is generated and stored as a file, the keys used to generate the keystream could be deleted, reducing the vulnerability of the protocol.
• In the third option, the encrypted data could also be transferred directly and synchronously from one client to another. This approach could make sense when a pair of clients wants to send and receive a number of smaller messages, as in a secure chat session. This can be accomplished first by generating and downloading a keystream and then sending encrypted messages back and forth without requiring an intermediate file server.

9) Modify the Keystream to Further Enhance Security
For efficiency, the client uses a keystream generated by the remote server, but for security, the keystream is modified in a way unknown to the server. In particular, the client randomly selects a few parameters that describe a particular pseudorandom permutation of keystream values. By sharing these secret permutation parameters with the other client through an out-of-band communication, the other client will be able to decrypt the encrypted file.

10) Ensure Data in the Cloud Server are Tied to Expiry Time
The security of the protocol is enhanced by reducing how long information is retained before being deleted. The keystream and the encrypted files have an associated expiry time, after which the server deletes them. This reduces the information that is exposed if the server is compromised.
C. Algorithmic Demonstration of the FEATHER Protocol 1) Channels 1. Insecure channel e.g Internet HTTP 2. Out-of-band channel e.g SMS

2) Algorithm 1: Mobile Device
Step 1: Register mobile with server i. Pick a unique username ii. Create UID: Hash (username, device ID) iv. Get the timestamp t v. Send register action (via channel 1) with payload [mobile phone number, UID, t] vi. Wait for response vii. If OK status received, go to step 2. Otherwise, ERROR status received, go to step 1 (ii).
Step 2: Update password with server i. Wait for one-time-pad, OTP ii. Provide a password iii. Create hashed password, pass: Hash (password, UID) iii. Create an encryption d: XOR (pass, OTP) iv. Get the timestamp t v. Create the payload, x: Hash (UID, d, t) vi. Send update action with payload vii. Wait for response viii. If OK status received, go to step 3. Otherwise, ERROR status received, go to step 2 (ii).
Step 3: Validate password with server, if the first time i. Send validate action with payload x ii. Go to step 4.
Step 4: Generate keystream from server i. Provide a unique 32-byte token ii. Send generate action with no payload iii. Wait for keystream response, with bytes size n iv. Go to step 5.
Step Step 7: Request from server i. If token + keystream, create an encryption f: XOR (token, keystream). Otherwise: an encryption f: XOR (file-id, keystream) ii. Get the timestamp t iii. Create the payload x: Hash (pass, UID, f, t) iv. Send request action with payload x.

3) Algorithm 2: Server
Step The FEATHER communication protocol enables mobile devices with limited computational resources to share encrypted files with the help of an external server that has greater computing, storage, and bandwidth resources. The protocol uses two communication channels. The first channel is assumed to be insecure, such as the Internet using HTTP to transport messages between the mobile devices and the external server. The second channel carrying "out-of-band" messages is assumed to be secure and could be implemented using SMS messages to mobile devices, or possibly email. The first channel allows mobile devices to initiate six actions by sending a message to the external server and receiving a response. The second out-of-band channel is used to send and receive three kinds of secret information: • A one-time-pad, which could use a more secure parameter instead of justification.
• A file id.
• A token id (and some additional parameters).
The protocol also uses a cryptographic hash function, such as SHA-256, which outputs a 32-byte hash value. For distinct pairs of strings, s and t, H(s)≠H(t) (with very high probability). Messages in the protocol are simply concatenated key = value pairs of parameters. Each of the 11 possible parameters is identified by a unique character: a = action s = status c = code (error code) u = uid p = phone f = token or file d = data n = number e = expire t = timestamp x = signature The timestamp is Unix time in seconds, and can help prevent "replay attacks". The cryptographic signature is a hash of the entire message string (before the signature is added) and is used to authenticate messages. UPLOAD, and REQUEST. Figure 2 illustrates the secure communication between the basic components, server, mobile devices and communication channel.

A. REGISTER
The person using the mobile device app provides a username (e.g. "Jason"). The device hardware is also assumed to have a unique hardware identifier (e.g. Device ID). The mobile app combines these strings using a hash function to get a unique id that can be sent to the external server without revealing any private information. uid = H(device ID, username); 32-byte value.
The mobile device also has a telephone number at which it can receive an out-of-band message via SMS. The person registers an account on the external server by sending a message: a = register u = uid p = phone t = timestamp When the external server receives this message, if no account exists for that uid, a new account is created, and this message is sent back: If an account already exists for that uid the server responds: s = ERROR c = code (indicating type or error) t = timestamp If an account already exists for the given uid, the person needs to pick a new username to create a different uid:

ONE-TIME-PAD via SMS
Following a successful REGISTER message, the external server sends a one-time-pad to the mobile device via an out-of-band channel using SMS to the phone number provided. The person would need to cut-and-paste this string into the mobile device app to be stored.

B. UPDATE
In the mobile device app, the person also provides a password (e.g. "MySecret"), which provides a type of "bring something, know something" security (bring something = mobile device, know something = username, password). The user's simple password is combined with the uid to create a "hashed password", which will be sent to the external server.

pass = H(uid, password)
The hashed password is encrypted using XOR with the secret one-time-pad. The entire message (before the signature) is hashed to create a cryptographic signature for authentication. a = update u = uid d = XOR(pass, OTP(One-Time-Pad)) t = time x = H(message) The external server confirms the validity of the message by recomputing the signature, and then decrypts and stores the hashed password in the account. The response is either OK or ERROR.

C. VALIDATE
This message is optional but useful for debugging purposes when implementing this protocol for the first time. The mobile device sends the following message asking the external server to confirm that the hashed password and signature are valid. a = validate u = uid d = XOR(pass, OTP) t = time x = H(message, pass) The external server decodes the hashed password, recomputes the signature, and responds with either OK or ERROR.

D. GENERATE
The mobile device provides a unique 32-byte token and asks the external server to generate a new encryption key that will be used to generate a keystream of "number" bytes that will be stored until a given "expire" time. The unique token is created by hashing the uid, expire, and timestamp: The token is XOR-encrypted with the shared-keystream. The message sent to the server has these parameters: The external server generates a random MICKEY 2.0 key (20 bytes of key+IV). There are two implementation-dependent choices: • The server can simply store the 20-byte in association with the token and generate the keystream on-the-fly when requested, or • The server can generate and store the keystream and then discard the 20-byte key. With this option, the token becomes equivalent to a file-id, and the keystream becomes equivalent to the file contents.

E. UPLOAD
The mobile device asks the external server to store a file by providing a 32-byte file-id, the encrypted contents of the file, and an expiration time, after which the file will be deleted. The unique file-id is created by hashing the uid, filename, expire, and timestamp: file = H(uid, filename, expire, timestamp) The file-id is XOR-encrypted with the shared-keystream. The mobile device sends a message with these parameters: a = upload u = uid f = XOR(file, shared-keystream) d = XOR(file-contents, token-keystream) The external server stores the file and responds with OK or else ERROR if something goes wrong.

F. REQUEST
A mobile device can request a token-keystream or encrypted file contents by providing the appropriate 32-byte token or file-id. The message has these parameters: a = request u = uid f = XOR(token, shared-keystream) or f = XOR(file, shared-keystream) t = timestamp x = H(message, pass) The external server uses the token (or file-id) to look up the requested data and sends it back to the mobile device. s = OK d = XOR(token-keystream, shared-keystream) or d = XOR(file-contents, shared-keystream) t = timestamp x = H(message, pass) The protocol assumes the first mobile device (the sender) is able to communicate the "token" and "file" to the second mobile device (the receiver) through a secure out-of-band channel, here assumed to be via an SMS message. It is important that the communication remains secure even if the external server is compromised by an adversary. Therefore, the token-keystream is not used directly to encrypt the file contents, since someone with access to the server could easily decrypt the file. Instead, the first mobile device must pick several random numbers R 1 , R 2 , R 3 , ... that are used to walk through the bytes of the token-keystream in a deterministic but difficult to predict order. These sets of random numbers must also be communicated to the second mobile device through a secure out-of-band channel. For example, for a tokenkeystream with length N=2 k -1, which is a prime number, the index of the next byte to be used could be calculated as: The mobile app was designed in Android Studio and then the app was transferred as a file to be converted into a mobile local app. The code was written in Java on the Android studio platform, which works on all major operating systems (i.e. Windows, MacOS and Linux).

VI. RESULTS AND ANALYSIS
The performance of FEATHER protocol is measured on two items: the overall speed and battery consumption.

A. Speed Performance
Five different mobile devices with Android-based operating systems, shown in Table I, were used to test the protocol performance. The total time from downloading the keystream, encryption, and writing to storage was measured. Tables II-V show the computations in five different Android-based devices.

B. Power Consumption
An Android-based application, GSam Battery Monitor [32] was used to measure the overall battery power consumption of FEATHER using a Samsung Galaxy S9+ with a 3500mAh Liion battery. After running GSam and the mobile app for FEATHER, the results showed that performing the operations on 10 files varying in size from 2 to 16MB consumed less than 1% of all apps running in the background, which consumed 1% of battery power, so FEATHER consumes only 0.0001% of battery power.

C. . FEATHER vs. CLOAK
The proposed FEATHER protocol is lighter than CLOAK and is much faster. Comparing the performance for file sizes of 1, 2, 4, and 8MB shows that FEATHER is faster. For example, in Table VI, the total time for 8MB file size is 110s for CLOAK and about 9.8s for FEATHER. Therefore, FEATHER is even more practical if multiple devices need to communicate at the same time. In addition, FEATHER consumes 80% less battery power than CLOAK. Adithya et al. [30] presented another secure application of CLOAK protocol in Apache server, using a Graphical User Interface to provide more security, however it takes 1 to 2s for users to enter the digits. FEATHER, CLOAK and [30] are compared in Figure 3. This section provides an analysis of common attacks and shows how FEATHER is resistant to these types of attacks.

A. Man in the Middle Attacks
The attacker can interrupt data, inject information, and redirect the traffic. This can be between the two devices or between the devices and the external server, thus it works on the communication channel. This can be prevented by providing strong mutual authentication and end point authentication, as the FEATHER protocol does, and by using hashing for messages, so as all messages are wrapped in hash functions. Thus, FEATHER is immune from man in the middle attacks. Fig. 3.

B. Insider Attacks
On the server side, if an insider can gain access to the information they only gain access to the keystream. However, the message will be included in a hash function, as well as the one-time-pad, and another secure parameter such as the timestamp or a random number only known by the mobile device users. On the mobile side, the mobile will validate the messages received from the server and other mobiles.

C. Denial of Service Attacks
The FEATHER protocol has steps in the external server to authenticate users before accessing the service by: 1) authentication of users' credentials, 2) updating the accessing parameters, and 3) validating the users' messages and hash functions. As verification by the server and devices is mutual, a denial of service attack is not applicable.

D. Chosen IV-Attacks
The keystream is generated by using MICKEY 2.0 and (key, IV) as the initial input. In FEATHER, the IV is not used more than once with the same key, thus FEATHER eliminates this threat by preventing the reuse of the IV, as well as by including the IV in the hash function, so an attacker choosing the IV will not result in the key being revealed.

E. Two-time Pad Attacks
Assuming there are two messages m 1 and m 2 , if the same key (k) is used (called two-time pad), and there are two ciphertexts (c 1 , c 2 ) then: Therefore, it is easy for the attacker to perform the XOR operation for ciphertexts in order to reveal the plaintext as: that is, using statistical frequency analysis leads to m 1 ⊕ m 2 . In the FEATHER protocol, each file is encrypted by a different keystream as well as a different one-time-pad for every session and time timestamp. Thus, this attack is not applicable.

F. Impersonation Attacks
This kind of attack occurs when the attacker gains access to a mobile device and requests a response from the server. The server will validate and authenticate the request. As mobile users will be using a hash function, including a one-time-pad (as discussed in the protocol implementation), the server also will hash the keystream with a one-time-pad among other user credentials, meaning this attack is not feasible with FEATHER.

G. Brute Force attacks
As the complexity of a brute force attack in key=80bit in general is 2 80 , the FEATHER protocol used a hash function. For example, using D-3 (a user may choose other stronger hash functions, and that will not affect the speed performance as the slower part is the downloading time), the computation power relies on the implementation, and adding other secure parameters such as using OTP, that is similar to the one-timepad cipher, which substantially raises the computation power needed to break the protocol.

VIII. DISCUSSION
In FEATHER, downloading is the most time-consuming task compared to the CLOAK protocol. If it is required for more than two mobile devices to communicate at the same time, the external server generating the keystream in the FEATHER protocol is much faster than CLOAK. This will reduce the overall time as the decoding time is just performing XOR on messages with the keystream, which is fast. The mobile battery lifetime is also longer. The proposed lightweight security protocol FEATHER provides confidentiality, authorisation, and security for users in mobile cloud computing technology and IoT technology. It also helps reducing power consumption, which will improve the overall performance of mobile applications. The proposed protocol was analyzed against possible known attacks, which showed that it is secure for implementation. The MICKEY 2.0 cipher was used as a pseudo-random number generator. However, the FEATHER protocol can be adapted to use other IV-based lightweight synchronous stream ciphers. The proposed MICKEY 2.0.85 [9] which is 23% faster in generating pseudo-random numbers, can also be used, however, even using MICKEY 2.0 in FEATHER is fast enough. MICKEY 2.0.85 is useful for other smaller applications. The FEATHER protocol offers a secure contribution to mobile cloud computation. The comparison in Figure 3 shows that FEATHER is much faster than the recent CLOAK and [30] protocols, and it also provides more security.
The limitations of this study include the testing on five devices, although the CLOAK protocol [23] was also tested on five devices. Future work could involve further testing of the performance of FEATHER on a wider range of devices, and compare it to a wider range of existing protocols. Another important direction for future research is adapting other lightweight ciphers such as Trivium, Grain, and other lightweight block ciphers to generate the keystream in the server, and then implementing FEATHER and calculating the overall execution time.

IX. CONCLUSION
Ensuring security in mobile cloud computing is critical but challenging. The proposed lightweight security protocol, FEATHER, will reduce cost and time used in the external server. Therefore, it can increase the number of devices communicating at the same time and enhance mobile cloud computing applications. The FEATHER protocol has better performance than existing protocols and can help meet the requirements for secure mobile cloud computing with Internet connectivity.