A New Decentralized Cryptographic Access Control Solution for Smart-phones

As the wireless technologies are becoming more and more popular and the number of cloud providers increases due to the growing demand of services and new emerging concepts like “Cloud computing”, security concerns are gaining a leading role. Data storage follows deprecated systems which make the cloud more vulnerable to data leakage. Besides, commmon cellphones have evolved to small pocket computers known as smart-phones, running their own Operating System. These devices are suffering every year an increment of cyber-attacks owing to weaknesses regarding the Operating System policy and the fact of using wireless standards such as GSM, UMTS, LTE, Wiﬁ or Bluetooth. Over this document, we propose a new access control solution based on a cryptographic system managed by the end-user to add extra security to one’s personal information on the cloud. It is orientated to smart-phones and takes into account the computational limitations these devices may have.


Introduction
In a world with a growing demand of services, where concepts like the Internet of Things (IoT) or Big Data are now a reality, and considering the rise of the global Internet connectivity as well as its speed average, the current global thinking has tended to move most part of resources to the cloud (Cloud Computing), filling the net with loads of data and increasing the number of cloud storage providers. In addition, the increment of smart-devices and wireless technology in general has caused people to be nearly permanently connected, sending constantly information to the Internet. As a consequence, end-users are highly interested in keeping their personal data securely on the cloud [8] instead of a physical device such as the hard disk or a pen-drive.
This issue has provoked a rise of net security concerns: • Is our personal data safe?
• Who has access to this data?
• How can we assure its integrity?
• How to safely share this data?
Researches about this topic have discovered some weaknesses on most cloud storage providers, even the major ones, all of them concerning the way our files are shared. So as to put the reader into a context, there are usually two ways these servers provide for file-sharing: email and URL. The first option does not control which account the user gets logged in with. On the other hand, the second option does not assure that this URL is not gonna be widely distributed without the owner's permission. Furthermore, it does not even always follows the HTTP protocol.
Therefore, while the file transference to the cloud is secure and commonly uses the TLS/SSL protocol, we come across two different problems. Firstly, the way in which these files are shared is not completely efficient. Secondly, the way they are stored is deprecated. It does not usually follow any cryptographic method or, in case it does, it is not possible for the end-user to use his own cryptographic key, that means, decentralize the process. As a result, we cannot be absolutely sure the administrator of the server has not accessed or even modified my personal data.
Over this document, we will explain a valid solution to cope with these security problems. We will call "owner" to that end-user who is in charge of the key management, that is, the administrator of the "sharing group", the master. Likewise, we will name "partners"to those end-users who are part of the sharing group, but do not manage it.

ACL vs CAC
Regarding data storage, there are mainly two distinct solutions globally implemented: • Access Control Lists.
The former consists in a list of permissions which specifies which users are granted access and what kind of operations they are allowed to perform. Traditionally these operations are three at least: read, write and execute. ACLs are centralized which means there is a third party in charge of given these permissions. This is the main system found in current cloud storage providers.
ACLs can be thought of as a building. If someone wants to gain access to it, he must go to the entry phone, get identified and say which his intentions are. The system is centralized and it might keep a record containing all people accesses, timings, attendance. The problem is the information stored using this method is not encrypted and can be easily modified: a trusted central component is needed, not being suited for cloud storage providers. The content may have been even modified by the administrator of the building or someone who entered it by mistake, not being possible then to make sure of its integrity, authenticity and confidentiality.
The latter refers to that solution where the information is encrypted by its owner and decrypted for those who want to get access to this information, implying the necessity of a key management: generation, exchange, storage, use and replacement of cryptographic keys.
Depending on how this key management is performed, it is said the cryptographic access control is centralized or decentralized. On one hand, the key management can be done by the owner of the information. In this case, the key management is decentralized and has the advantage that the key is only known by the owner and not by a third party. Hence, it can be assured the information is authentic, has not been modified and no unauthorized person has accessed it. The problem appears when storing the key: there is no backup and in case the user loses its device or it gets broken, his data is lost too.
On the other hand, the key management can be performed by the cloud and in this case it is said it is centralized. Thus, the cryptographic key is always negotiated with the cloud, which is also in charge of its distribution and storage, having this way a backup. Nevertheless, the administrator or person in charge of the server could access at any time the data stored on it as the key has been agreed with the server.
In any case, if choosing a cryptographic access control, there is no impediment for a person who knows the key to have total access to the information as there is no difference between accesses: in this case, someone at the entrance of the building should get identified to get in it, being only capable of accessing the information he has the key for.
Eventually and so as to gather the advantages of both systems, the best solution is a combination of both approaches, where ACLs are used to grant access to some information which is encrypted, being safer that the key management is decentralized. Therefore, integrity, authenticity and confidentiality are guaranteed as well as restraining permissions are used.

Solution Adopted
The solution considered by our side is a decentralized cryptographic access control system, implemented for smartphones [7]. The choice of this platform meets the demands of a great deal of users worried by the rise of cyber-attacks over these devices [5]. Owing to their lower performance, issues such as memory capacity or computing speed are highly relevant and must be taken into account.
For being a decentralized solution, the owner must be the one who takes over the key management, including the key storage. Our approach consists in a system where cryptographic keys are related to each other, so that only one of them (the most recent one) must be stored since it would be enough for a user to calculate and obtain the previous versions from it. This is performed by a modular operation with a "public number" known by all the people a user wants to share his information with. At the same time, only the user who "starts" encrypting first is capable of computing the new key versions as he is the only one who has the means to do it: another modular operation regarding two "private numbers", whose multiplication outcome is the "public number". With the appropriate bit length, these private numbers are impossible to be achieved out of the public one.
So as to put the reader into a context, let's picture A wants to share some information with B and C. He generates a key and starts encrypting and sharing the ciphertext with B and C. Thus, another user called D cannot access this shared information as he does not know the key in use. Now, let's figure A wants to share his information with C no longer. The limitations regarding memory capacity and computing speed prevent us from implementing a system where A had to download all his shared data, decrypt it, generate a new key, re-encrypt the data, re-upload it and share again the key with B. Instead, A could just generate a new key and start encrypting the new files with it, avoiding thus spending time in the process of re-encrypting the old data since C had already looked into the files, after all.
However, the old files would be encrypted with a different key so A and B should save both keys into the memory (again, a problem regarding capacity and, as we will see, a storage obstacle for a backup). Besides, if A wanted to share with a new user called E, he would have to distribute both keys instead of one, making the process more complicated. Hence, it would be desirable that the first key generated as well as the prospective ones had some sort of relationship between each other so that only one of them had to be stored, with the only addition of its version, that is, the position the current key occupy within the timeline. Therefore, E would receive the most recent key with which he could calculate the old versions and have access to every shared content, no matter they key that was used to encrypt them.
All in all, in terms of sharing information, our solution means some people who may have access to some data could lose their grant to new files (and/or subsequently modified ones, but not to old non-modified ones) if the key manager calculates a new key and does not distribute it or it does, but excludes some of them. It also means a new partner would only need the last key in use since he would be capable of calculating all its previous versions.
Hence, our concerns about speed and capacity in smartphones are fulfilled: • Choosing the right algorithms will guarantee the process is performed fast enough, not blocking other processes that might be running on the device.
• The key management performance will permit to store data on the cloud and avoid downloading all the files to re-encrypt them in case a new file with different access grants (meaning someone is not given the key for this new share) has to be done.
• Only one key will be needed to be stored, which is the last version, since all the previous ones will be able to be computed by means of current key.
For being a decentralized solution, we have the additional problem of the key storage: presuming the administrator and owner of the key and the private numbers lost his phone or this last one was destroyed, there would be no way to continue with the secret sharing or at least to generate new keys. What is more: what if the owner is the only person in the group? His information will be lost forever. Summarizing, the point is the owner has no backup for these vital information (key and both private numbers).
One solution might be not to create any backup: in case the phone is lost, CACS key (key + private numbers) is lost too. Another one may be to store CACS key on one server and thereby have a backup on the cloud. Nevertheless, that is precisely what it was intended to avoid from the beginning: the server administrator having the key. CACS key could be even split into several parts and stored in different servers. It could be even mixed byte by byte following some algorithm. However, it will never stop being plaintext so, all in all, part of CACS key could be known, making easier to guess it since if one of these shares is sniffed, the sniffer will have part of the information. On the other hand, encrypting CACS key with a different key is not a solution either since we are in the same situation: what to store the key?.
Fortunately, it exists a good solution based on one of the last ideas exposed. CACS key could be split in several shares but following an threshold algorithm called "Shamir Secret Sharing" [14] by which the shares are securely protected and, likewise, one sniffer could even get no information out of several shares, let alone one of them. These shares could be, afterwards, uploaded to different servers and different parts of the cloud to make it securer (we do not want all of them stored on the same server). Besides, the reader must be aware that the transmissions client-server usually follow the TLS/SSL protocols, so even to sniff just one of these shares would be highly complicated for anyone.

Key Management
The purpose of this section is to describe the algorithms implemented and used for the key management: generation, exchange, storage, use and replacement of cryptographic keys.
The variables x and y will symbolize different versions of the key used by the system, p and q are the secret numbers generated by the "owner" and n is the public number, where n = p · q

Generation
CACS solution is based on three "magic" numbers: a key and two prime numbers p and q. The first one must be shared with the persons somebody wants to securely share data with. Nonetheless, the two last ones are known just by the owner and only the outcome of their multiplication, n, is shared so as to compute the key replacement, that is, compute previous versions of the key in case they exist.
Hence, these three numbers must be generated, attending to some conditions, though. Firstly, p and q are computed, being verified they both are prime and fulfill: These conditions are to be satisfied for the Rabin Cryptosystem to perform valid results (see Replacement section). Then, another condition is required of the key: a positive Legendre and Jacobi Symbol regarding both p and q.
Likewise, if p and q are prime, y will be their quadratic residue respectively as long as: As well as the other conditions, this one has to do with the Rabin Cryptosystem .

Replacement
As it was commented on Section 3, CACS works with keys which are related to each other. More specifically, these keys depend on each other so that somewhat only one of them is needed to calculate the rest of them. For that purpose, the public number n and the private ones p and q are needed to be part of the operations regarding this behavior.
The algorithms invoked are Montgomery Reduction Theorem and both Chinese Remainder Theorem and Rabin Cryptosystem [9]. The former allows modular arithmetic to be performed efficiently when the modulus is large, while the combination of the last ones performs the quadratic residue.
In terms of efficiency, Montgomery Reduction Theorem can be optimized by means of the following iterative calculus called "Bunimov method" [2][13]: where, X = {x n , . . . , x 1 , x 0 } and the operation computed is P = X · Y (mod M ). x i stands for the bit in the position i.
To calculate the quadratic residue is more complicated and it needs several steps. The four possible solutions of the equation are obtained by invoking the Chinese Remainder Theorem: Here, we have several terms to calculate. This is one of the reasons this operation is harder. Both a and b are the result of calling Rabin Cryptosystem. This algorithm has been commonly used as an asymmetrical encryption algorithm [1], with the disadvantage of having four possible solutions. If the plaintext is intended to represent a text message, guessing is not difficult. However, if the plaintext is intended to represent a numerical value, this issue becomes a problem that must be resolved by some kind of disambiguation scheme such as special structures or padding.
Nonetheless, its use here is with the purpose of computing an operation so having four different outcomes does not affect the behavior of CACS as long as they are valid solutions (which is true if the restrictions are fulfilled, for the key, p and q; see 4.1) since only one of them is needed. Therefore, a and b can be computed as follows: The last terms left are known as the coefficients of Bézout's identity, which can be obtained by means of the Extended Euclidean Algorithm (whose entries in this case are the secret numbers p and q). This computes the greatest common divisor (gcd) of two integers a and b as well as the previously mentioned coefficients. The Bézout's coefficients are two number s and t that fulfills: being p and q two integer numbers, with p > q. In order to calculate Bézout's coefficients, an iterative calculus must be applied which consists of computing a sequence of quotients u k and remainders r k , with The initial values for s and t are: and the next values are calculated as follows: The computation is finished when r k + 1 = 0. Likewise, all terms needed for the Chinese Remainder formula are obtained and CACS is set to perform the key replacement (and calculus of previous keys).

Use and exchange
Regarding the key use and exchange, the procedure basically follows the common standards used worldwide, except some issues that we will discuss. For the key distribution, an asymmetric scheme is used wheras a symmetric one is used for the data encryption. Thus, our solution makes use of a hybrid key exchange (like PGP solution) with RSA [10] and AES [3] respectively. The encryption is performed using AES with "ECB-mode" for the file name and "CBC-mode" for the file content. Concerning this last one, a random initializacion vector (IV) is randomly generated and appended at the end of the ciphertext so that the decryption cipher knows the sequence to use.
Another issue is the AES key length. AES standard consider three different lengths: 128, 192 or 256 bits. For security reasons, Rabin Cryptosystem demands 1024-bits numbers so as to be robust enough and not easy to be hacked. As a consequence, a hash function (SHA-256 [12]) is applied to get an appropriate length (256 bits in this case).

Storage
Regarding the key storage, Shamir Secret Sharing scheme is applied. In cryptography, a secret sharing scheme is a method for distributing a secret amongst a group of participants, each of which is allocated a share of the secret. The secret can only be reconstructed when the shares are combined together as individual shares are of no use on their own.
More formally, in a secret sharing scheme there is one dealer and n players. The dealer gives a secret to the players, but only when specific conditions are fulfilled. The dealer accomplishes this by giving each player a share in such a way that any group of k (for threshold) or more players can together reconstruct the secret but no group of less than k players can. Such a system is called a (k, n)threshold scheme [11]. Particularly, Shamir Secret Sharing scheme make use of polynomial interpolation ("Lagrange interpolation") and this is the reason this scheme is so popular.
The essential idea of Adi Shamir's threshold scheme [14] is that 2 points are sufficient to define a line, 3 points are sufficient to define a parabola, 4 points to define a cubic curve and so forth. That is, it takes k points to define a polynomial of degree k − 1.
Suppose we want to use a (k, n) threshold scheme to share our secret S, without loss of generality assumed to be an element in a finite field F of size P , where 0 < k ≤ n < P , S < P and P is a prime number.
Choose at random k − 1 positive integers a 1 , a 2 , . . . , a k−1 with a i < P , and let a 0 = S. Build the polynomial y = f (x) = a 0 +a 1 x+a 2 x 2 +a 3 x 3 +. . .+a k−1 x k−1 . Let us construct any n points out of it, for instance set i = 1, 2, . . . , n to retrieve (i, f (i) mod p). Every participant is given a point (an integer input to the polynomial, and the corresponding integer output). Given any subset of k of these pairs, we can find the coefficients of the polynomial using interpolation. The secret is the constant term a 0 .
In order to reconstruct the secret we will compute Lagrange basis polynomials: . . . Therefore, 6 Comparison: Solutions on the market Currently on the market, there are several tools based on decentralized access control systems. They split and, therefore, distinguish between storage and confidentiality responsibilities, hence emphasizing, once more, that a cloud storage provider should only be responsible for storing data and regulating user-level access. There are two main kinds of tools: container and file based encryption tools. The latter is the one in the matter at hand.
These file encryption tools usually work as a third-party for a great number clouds, such as Dropbox, Google Drive, Box or Microsoft One Drive. We will highlight two of them: Boxcryptor and TAVUU.
The first one defines themselves as an "easy-to-use encryption software optimized for the cloud", supporting a great deal of different cloud storage providers and OS platforms. The file encryption is performed symmetrically and the file key is added to the resulting bunch of bits after an asymmetrical encryption. It fulfills the "Confidentiality as a Service" paradigm [4] in which a multiple commutative layers of encryption scheme is used. This means these layers can be added and removed in an arbitrary order.
The second one is a peer-to-peer solution which avoids the use of a server, all in all a client-based software solution. As in the case above, the file encryption is symmetrical and it makes use of an asymmetric scheme for the key exchange. The foremost idea is this solution is a hierarchical system, where one user generates a key as "an entry point" key, which has a public and a private part and grants access to the parent directory. Keys for subfolders are discovered by traversing the file system, depending whether you are authorized. This authorization comes from a user, called owner or producer, who can also deauthorize other users, making them incapable of seeing new files or changes.
The flaw of this approach is its incapability for backup: as it is a non-server solution, one users password will never leave his end-point device (computer, mobile phone. . . ). Thus, as a side-effect it is impossible to recover it in case of forgetting or damage. Our key management approach follows a modern and secure solution for the key storage, which offers a user-friendly experience based on a (k, n)-threshold scheme. The upset is the more shares one wants to split the key in, the more accounts and password one has to remember.
Besides, these two presented solutions are focused more on computers than smart-devices. The algorithms they use do not considered their computational and memory limitations and, thereby, are not optimized for the use of smart-phones or tablets. Our solution is more time-efficient in this sense and, by means of the Rabin-method and the idea of relating keys to each other, no re-encryption is needed after the owner decides to exclude one of his partners from the sharing group.

Implementation and Testing
This approach has been implemented and tested in an Android environment. We will now attend to some considerations about its implementation. The resulting application makes use of different folders for the synchronization in which we can find: • Plain files.
• Meta data needed for the synchronization (revision number on the server and timestamp in the smartdevice).
• The CACS key, RSA pair of keys and both secret numbers, in case of the owner; the CACS key, RSA pair of keys and the public number, in case of the partner.
The App enables file and folder uploading, downloading, renaming and deletion. Client-server operations are carried out immediately while server-client ones are performed with a 10 seconds latency. All these operations need a multithreading system.
It has been tested exhaustively by a random group of students within a period of one month, installing the App in their smart-phones. During this time, several development bugs were corrected to improve its operation and its simple userfriendly interface. The following considerations arose within this test: Table 1. CACS operation results. Except the last measure, the rest depends on the speed of the prime number generation. The wide range on the first measure is due to the restrictions the three numbers must fulfilled between each other.
The rest of operations (key exchange, use and key substitution) were performed time-efficiently, barely consuming time. By these, it was deduced the algorithms CACS solution implements are suitable for smart-devices, considering the background idea, as well.

Conclusion
Conceivable bugs and weaknesses that might be on cloud storage providers are coped by our approach, adding a new grade of security to data storage. By making use of the Rabin Cryptosystem from an uncommon point of view, we are capable of setting up a entire cryptographic system which fulfills with the smart-phones computational limitations. We propose a decentralized solution where it is the end-user, and not any third party, who manages the key and we give a solution for the key storage, based on a (k, n)-threshold scheme.
Over the paper, we have commented one by one all the pieces which form part of the key management. This system has been implemented and tested on Android, but it is itself a solution not only valid por Android smart-phones, but general purpose. Finally, we have given several reasons for which we think cryptographic access control should be added to current cloud data storage.