A Simple Data Re-encryption Framework using Commutative RSA

advertisement
A Simple Data Re-encryption Framework using Commutative RSA with
Application to Cloud-based Encrypted File Delegation
Yi-Jun He1, Lucas Hui2, Echo P. Zhang3 *, Jin Shiqiao2, Li Linhui2
1
Hong Kong R&D Centre for Logistics and Supply Chain Management Enabling Technologies,
Hong Kong, ahe@lscm.hk
2
Department of Computer Science, The University of Hong Kong, Hong Kong,
hui@cs.hku.hk, h1395020@connect.hku.hk, h1395072@connect.hku.hk
3
Department of Computer Science, Guang Dong Police College, Guangzhou, China,
pzhang.echo@gmail.com
摘要:利用加密的手段保护用户的个人数据,是云服务商提供保护云端存储器数据安全
的手段之一,然而加密手段也随之带来了解密密钥的管理问题。更进一步,在数据访问权
可由某一用户授权给另一名用户的情况下,密钥管理问题愈加的复杂。现有的众多加密数
据访问授权解决方案或者依赖于可信任第三方(例如云服务提供商),或者利用耗时耗资
源的加密算法(例如代理重加密机制)来管理授权过程。前一类解决方案的效率较高但有
可能遭受内部攻击,这是此类涉及可信任第三方方案的通病。后一类方案并不依赖于云服
务商的可信赖度,但这类方案一般在实施上较为复杂或者无法与大部分的云系统兼容。
在这篇文章中,我们提出了 SCARF(简易可换式 RSA 重加密体系)解决机制并将其应用
于基于云服务的加密文件授权。SCARF 不需要可信任第三方,它只需简单地运行 RSA 算
法就可达到文件重加密的目的。更重要的一点是 SCARF 可与任何一种基于云服务存储器
的模型兼容,它提供了一个安全且便捷的加密文件授权的途径。
关键词:云计算,加密数据授权,可换式 RSA,代理重加密
Abstract
With customer data being stored in cloud service providers, encryption is a method for ensuring
data security on cloud. However, encryption also introduces the management issues about the
decryption keys. This key management issue is even more complicated when the data access
right is delegated from one data user to another one. Existing approaches for encrypted data
delegation either rely on a trusted party (e.g. cloud service provider) or use expensive
*
Corresponding author: Echo P. Zhang, No. 500 Binjiang Rd East, Department of Computer Science,
Guangdong Police College, Guangzhou, China 510230. Tel: (86) 20 34068180, (86) 13928865901.
1
cryptographic algorithms (e.g. proxy re-encryption) to manage delegation process. The preselection approaches provide good efficiency, but suffer from insider attack, which is the
intrinsic problem of such trusted party involved system. The latter approaches put less trust on
cloud service provider, but a re-encryption key is required to be pre-computed before delegation.
Further, its process is too complex to be implemented, or the model may not be compatible with
most cloud-base systems.
In this paper, we present a Simple Commutative RSA Re-encryption Framework (SCARF) with
application to cloud-based encrypted file delegation. SCARF does not require a trusted third
party. It can be implemented simply using RSA algorithm. More importantly, SCARF is
compatible with any cloud-based storage model, which provides a secure and convenient way for
encrypted data delegation.
Keywords: cloud computing, encrypted data delegation, commutative RSA, proxy re-encryption
1. Introduction
People are increasingly using cloud storage nowadays, however, cloud security is still a major
concern people taking into account while adopting cloud storage. When there is no cloud service
provider can be fully trusted, data owners are not willing to share plaintext data with other
parties or to outsource plaintext to the service provider neither. A traditional solution to ensure
security and privacy of the data is encryption. Owners encrypt their sensitive data with their own
keys and outsource their partitions to a cloud service provider. When the data owner wants to
share the data from the cloud to other users, decryption is needed. The distribution of decryption
keys to the target users could become a big problem. This key management issue is even more
complicated when the data access right is delegated from one data user to another one.
Existing approaches for encrypted data delegation either rely on a trusted party (e.g. cloud
service provider) or use expensive cryptographic techniques (e.g. proxy re-encryption, secret
sharing, broadcast encryption, homomorphic encryption, etc.) to manage delegation process.

The former approach could be similar to what is employed in Cephesus [1]; it uses a trusted
access control server to distribute the keys. So, the group members must contact the access
control server to obtain their decryption keys for accessing files. However, the above keys
distribution method may not be satisfactory, since the underlying access control server
model relies on a complete trust in the server operator. Furthermore, in practice, the server
operator could abuse the keys kept by the server to decrypt any data. Even if the access
control server operator can be trusted fully, letting all critical key data kept by a single server
could make it become a potential attack target.
2

Proxy re-encryption scheme, a cryptographic scheme, introduced in [2] can be employed to
address the problems in the former approach. It allows a third-party (the proxy) to re-encrypt
a ciphertext which has been encrypted for one party without seeing the underlying plaintext
so that it can be decrypted by another. This is illustrated in Figure 1, where Alice keeps
some photos, videos or sensitive files in encrypted form in the file server; Bob fetches
encrypted files from file server, and then transmits the encrypted files to proxy; Alice sends
a re-encryption key to the proxy which re-encrypts the encrypted files and sends Bob the reencrypted ciphertext which can be decrypted by Bob with his own private keys. Thus, with
the help of the proxy, data owner can delegate the decryption right to any delegatee. The
above scheme aroused much interest in the encryption community [3-8] since it could be
exploited in a number of applications for achieving better information security and privacy.
Proxy re-encryption scheme puts less trust on cloud service provider, but its process is more
complex and implementation is not mature. It requires data owner to pre-compute a reencryption key for data delegation, and also requires proxy cooperation to compute reencryption. This is done without the need for data owner to release its secret key, and more
importantly the proxy server does not learn the content of data processed. However, it
should be noted that misuse of the re-encryption key or colluding between delegatee and
proxy can corrupt the whole system, and may lead to exposure of delegator’s private key.
Further, it is not compatible with most cloud-based storage models, because cloud service
provider may not be willing to take up the role of proxy to do re-encryption.

Besides proxy re-encryption, secret sharing [9-12], broadcast encryption [20-21] and
homomorphic encryption [13] are also common technologies to solve the delegation of
access right to encrypted data. Although most of these techniques offer strong privacy
guarantees, they suffer from similar limitations as proxy re-encryption, such as sophisticated
framework which is impractical for implementation; it is not compatible with most cloudbased storage models, etc.
File Server
2
1
Alice
Proxy
5
Bob
4
3
Figure 1. Proxy re-encryption model
2. Review of Commutative Encryption
3
Commutative encryption is a special class of encryption algorithm that has the property of being
commutative. It has been exploited in a number of applications for achieving better information
security and privacy, e.g. protecting secrecy and privacy in e-commerce [15-17], data mining
[18], and network routing [19]. Here, we borrow the definition of commutative encryption from
[14].
“A commutative encryption is a pair of encryption functions f and g such that f(g(m)) =
g(f(m)). Thus by using the combination f(g(m)) to encrypt m, we can ensure that Receiver
cannot compute the encryption of a value without the help of Sender. In addition, even
though the encryption is a combination of two functions, each party can apply their function
first and still get the same result.”
That is, when one uses the commutative cipher to apply two encryption operations on a message,
the encryption sequence does not change the ultimate result. In general, this property holds for
any finite number of encryption operations. Two commonly used commutative ciphers are the
Pohlig-Hellman algorithm based on Elliptic Curve Cryptography (ECC), and the RSA
cryptography. In this paper, we just focus on commutative RSA. RSA is commutative for keys
with a common modulus n. The same n is used by all users. There are two generally discussed
commutative RSA protocols as follows:
1. Alice and Bob jointly choose primes p and q, and both compute n = pq. Alice then chooses
an RSA key pair A = ((eA, n), (dA, n)), which she can do since she knows the factorization of
n. Similarly, Bob chooses an RSA key pair B = ((eB, n), (dB, n)) using the same n. Alice and
Bob both keep their key pairs private (until the end of the protocol, when they reveal them to
each other to verify that there was no cheating). Then the encryption is carried out by EA(M)
= MA(mod n). Then EB(EA(M)) = (MA)B = (MB)A = EA(EB(M)), so commutative property holds.
This is also how Mental Poker [23] performs.
However, researchers [24] show that this commutative RSA is not secure against chosen
plaintext attack, such that one party who cleverly chooses the plaintext to represent the card
will have an advantage in the game.
2.
Another commutative RSA protocol runs like this: A trusted central authority provides Alice
with a unique pair eA, dA from which Alice forms a RSA key pair A = ((eA, n), (dA, n)).
Similarly, Bob obtains his key pair B = ((eB, n), (dB, n)). Then (eA, n), (eB, n) are public to
anyone. Encryption is carried out by EA(M) = MA(mod n). Then EB(EA(M)) = (MA)B = (MB)A
= EA(EB(M)), so commutative property holds.
At first glance this may seem to work: Bob cannot decrypt a ciphertext C = MA mod n
intended for Alice because Bob does not have dA. However, this is incorrect and the
resulting system is insecure. It is pointed out in [22] that Bob can use his own exponents eB,
dB to factor the modulus n. Once n is factored Bob can recover Alice's private key dA from
her public key eA. This observation shows that an RSA modulus should never be used by
more than one entity.
Upon survey of commutative RSA, we find that it is always discouraged to use commutative
4
RSA because of its secruity vulnerabilities. Any misuse of it can lead to security problems.
However, we also notise that if we adopt commutative RSA encryption in an unconventional
way, it could be used for cloud-based encrypted data delegation securely. In this paper, we
propose a framework called SCARF which is based on commutative RSA for encrypted data
delegation. This framework is different from the two approaches described above. Chosen
plaintext attack succeeded in protocol 1 is not applicable to our framework, since Alice is the file
owner who is willing to share files with Bob, and it is unnecessary for her to cheat Bob in order
to know which file Bob chooses from her. Attack in protocol 2 does not do any harm to our
framework too, because if Bob recovers Alice’s private key, Bob can only see the content of that
file which he has already known after delegation. We shall describe SCARF in next section.
3.
Design of SCARF Framework
SCARF is based on commutative RSA. Although commutative RSA is vulnerable to chosen
plaintext attack and at risk of exposing user keys, we can use RSA in an unconventional way for
encrypted file delegation. In SCARF, Alice and Bob each has a long time RSA key pair ((eA, nA),
(dA, nA)) and ((eB, nB), (dB, nB)). If given a common modulus n1, Alice and Bob are also capable
of generating several one-time commutative RSA key pairs ((eA1, n1), (dA1, n1)) and ((eB1, n1),
(dB1, n1)), etc. For each file Alice wants to share with Bob, a new module will be used. Here the
important point is that rather than using only one common modulus n for all files encryption, we
choose different common modulus n for each file being shared.
Note that even if user keys generated using the same common modulus are recovered after file
delegation, other files encrypted with different modulus will not be affected. For example, if (dA1,
n1) and (dB1, n1) are recovered, file encrypted under (dA2, n2) or (dB2, n2) will not be affected.
Also note that when A delegates a file to B, even if A recovers dB1, A can only see the content of
that file, which he already know. So this vulnerability of commutative RSA does not do any
harm. Similarly, if B recovers dA1, B can only see the content of that file which he has already
known.
Thus, we can avoid vulnerabilities mentioned in section 2 and make use of commutative RSA for
file sharing. The framework is described in Figure 2.
1. Alice holds some important files that need to be shared securely. She then generates several
one-time RSA key pairs ((eA1, n1), (dA1, n1)), ((eA2, n2), (dA2, n2)), … , ((eAi, ni), (dAi, ni)) with
e
different modulus n. She encrypts each file using public key by EA1(M1) = Mi A1(mod n1), ...
e
EAi(Mi) = Mi Ai(mod ni). After encryption, she uploads these encrypted files to her cloud
storage;
2. Bob, who wants to get one shared file say M1 from Alice, sends the corresponding URL (in
cloud storage such as CloudFront [25], or Pogoplug [26], files can be identified by URL) to
Alice, indicating that he is interested in this file;
5
3. Alice sends to Bob the related (n1,p1,q1), where p1,q1 are primes and n1=p1*q1, which is
encrypted using Bob’s long term public key eB;
4. Upon Bob receives the feedback, he is able to generate his corresponding one-time RSA key
pair ((eB1, n1), (dB1, n1)) now. Then he downloads this encrypted file M1 and use his public
e
e
key (eB1, n1) to re-encrypt it as well by EB1(EA1(M1)) = (M1 A1) B1;
5. Bob uploads this re-encrypted file to his cloud server so that Alice can do the decryption;
6. Alice downloads the corresponding re-encrypted file from Bob’s cloud server and this time
she will decrypt the file once using her one-time private key (dA1, n1) by DA1(EB1(EA1(M1))) =
EB1(M1). Actually, it is still under encryption due to the property of commutative encryption;
7. Alice uploads the new file EB1(M1) to her cloud server;
8. Finally, Bob downloads the new file EB1(M1) and use his one-time private key (dB1, n1) do a
second decryption, then he will get the plaintext file.
Cloud
Server
6
5
1
7
8
Alice
4
2
3
Bob
Figure 2. The SCARF Framework
The proposed scheme has several merits:
1. There is no need to have a trusted third party (i.e. the proxy) for distributing keys, or for
performing re-encryption.
2. The file is always in encrypted among Alice, cloud server and Bob. Thus, cloud server
cannot read plaintext file.
3. The whole system is not complex for implementation, only RSA encryption is needed.
4. It is compatible with most of cloud storage designs, since there is no need to do anything in
the cloud.
4. Evaluation of SCARF
6
Note that measurements do not take into account the setup time and key generation time, since
the encryption, decryption and re-encryption time are the major concerns in re-encryption
schemes. The Operation system is Ubuntu server 12.04 64bit. Processor: Intel(R) Core (TM) i73770 CPU @ 3.40GHz, with 8.00 GB memory (RAM). The size of the test string for encryption
is 16 bytes.
Table 1. Performance evaluation of Commutative RSA
Key bit size
Encryption Re-encryption Decryption
(ms)
(ms)
(ms)
1024
0.651
3.118
2.477
2048
4.5
21.7
17.1
4096
33.6
164.13
131.5
8192
260
1279
1018
Table 1 shows that execution of the SCARF framework is efficient, so the scheme is practical.
5. Conclusion
In this paper, we propose to use commutative RSA in a unconventional way for cloud based
encrypted file delegation. The whole system is secure and efficient. It does not require any
complex cryptographic algorithm, so it is practical and straight forward for implementation.
What is more important, the system is compatible with most cloud storage without creating any
burden to it.
References
[1] K. Fu. Group sharing and random access in cryptographic storage file systems. Master’s
thesis, May 1999.
[2] M. Blaze, G. Bleumer, and M. Strauss. Divertible protocols and atomic proxy cryptography.
In EUROCRYPT, pages 127–144, June 1998.
[3] A. Ivan and Y. Dodis. Proxy cryptography revisited. In NDSS, February 2003.
[4] G. Ateniese, K. Fu, M. Green, and S. Hohenberger. Improved proxy re-encryption schemes
with applications to secure distributed storage. In NDSS, pages 29–43, February, 2005.
[5] B. Libert and D. Vergnaud. Tracing malicious proxies in proxy re-encryption. In Pairing,
pages 332–353, September 2008.
[6] Yi-Jun He, Tat Wing Chim, Lucas Chi Kwong Hui, Siu-Ming Yiu, “Non-Transferable Proxy
Re-Encryption Scheme”, in Proceeding of 5th IFIP International Conference on New
Technologies, Mobility and Security (NTMS’12), May, Istanbul, Turkey, 2012.
[7] Kaitai Liang, Zhen Liu, Xiao Tan, Duncan S. Wong, Chunming Tang. A CCA-Secure
7
Identity-Based Conditional Proxy Re-Encryption without Random Oracles. In Information
Security and Cryptology – ICISC 2012, pp 231-246.
[8] Toshiyuki Isshiki, Manh Ha Nguyen and Keisuke Tanaka. Proxy Re-Encryption in a
Stronger Security Model Extended from CT-RSA2012. In Topics in Cryptology – CT-RSA
2013, pp 277-292.
[9] A. Shamir, “How to share a secret,” in Communication of ACM, vol. 22, no. 11, 1979, pp.
612–613.
[10] Boyang Wang, Sherman S.M. Chow, Ming Li, and Hui Li. Storing Shared Data on the
Cloud via Security-Mediator. 2013 IEEE 33rd International Conference on Distributed
Computing Systems (ICDCS’13)
[11] Hadavi,M., Jalili, R. Secure Data Outsourcing Based on Threshold Secret Sharing; Towards
a More Practical Solution. In: Proc. VLDB PhD Workshop, pp. 54–59 (2010)
[12] Agrawal, D., El Abbadi, A., Emekci, F., Metwally, A., Wang, S. Secure Data Management
Service on Cloud Computing Infrastructures. New Frontiers in Information and Software as
Services. LNBIP, vol. 74, pp.57–80. Springer, Heidelberg (2011)
[13] Bharath K. Samanthula, Gerry Howser, Yousef Elmehdwi, and Sanjay Madria. 2012. An
efficient and secure data sharing framework using homomorphic encryption in the cloud. In
Proceedings of the 1st International Workshop on Cloud Intelligence (Cloud-I '12).
[14] Rakesh Agrawal, Alexandre Evfimievski, and Ramakrishnan Srikant. Information sharing
across private databases. In Proceedings of the 2003 ACM SIGMOD international
conference on Management of data (SIGMOD '03). ACM, New York, NY, USA, 86-97.
[15] F. Bao, R. Deng, and P. Feng. An efficient and practical scheme for privacy protection in the
e-commerce of digital goods. In ICISC, 2000.
[16] F. Bao, R. Deng, P. Feng, Y. Guo, and H. Wu. Secure and private distribution of online
video and some related cryptographic issues. In ACISP, 2001.
[17] S. chi Cheung, H. fung Leung, and C. Wang. A commutative encrypted protocol for the
privacy protection of watermarks in digital contents. In Hawaii International Conference on
System Sciences, 2004.
[18] C. Clifton, M. Kantarcioglu, J. Vaidya, X. Lin, and M. Zhu. Tools for privacy preserving
distributed data mining. ACM SIGKDD Explorations, 4(2), 2003.
[19] Hao Yang; Songwu Lu. Commutative cipher based en-route filtering in wireless sensor
networks, Vehicular Technology Conference, 2004. VTC2004-Fall. 2004 IEEE 60th, vol.2,
no., pp.1223,1227 Vol. 2, 26-29 Sept. 2004.
[20] Adam Barth, Dan Boneh, Brent Waters. Privacy in Encrypted Content Distribution Using
Private Broadcast Encryption. 10th International Conference on Financial Cryptography and
Data Security, pp.52-64, FC 2006.
[21] Dharmendra Chourishi, Sridevi Seshadri, Dhruvendra Chourishi, "Secure content sharing
using third party with broadcast encryption for stateless receivers," iccsit, pp.528-531, 2nd
IEEE International Conference on Computer Science and Information Technology, 2009
[22] Dan Boneh. Twenty Years of Attacks on the RSA Cryptosystem. Notice of the AMS, pp203213, 1999.
[23] A. Shamir, R. Rivest, and L. Adleman, "Mental Poker", Technical Report LCS/TR-125,
Massachusetts Institute of Technology, April 1979
[24] WILAB. Security Models: Dolev-Yao, Semantic Security, Probabilistic Encryption and
ZKIP .
[25] Amazon. CloudFront. http://aws.amazon.com/cloudfront/
8
[26] Pogoplug. https://pogoplug.com/
9
Download