 Hello everyone, I'm going to talk about CC updateable encryption against malicious re-information attacks. I'm Yananli, this is joint work with Longchen and Qiangtang. We all know that cloud storage are vulnerable. Encryption is widely used method to protect the outsourced storage, especially for the private data. The approach is quite simple. The data owner encrypts the data and then also the encrypted data to the cloud server and starts the secret key locally. In this approach, the security of the data depends on the secrecy of the secret key. Then why do we need key rotation? We know that computers are vulnerable to various malware. For attackers, eventually it is possible to corrupt both the key in the client and the suffer test in the server. Then there is no security guaranteed. Key rotation aims to mitigate this damage as long as attackers cannot corrupt the client and the cloud server in a quite short time period. Most pragmatically, a variety of security regulations require key rotation. For example, payment card industrial data security standard requires the credit card information stored in the cloud should be encrypted and key rotated periodically. Also, key rotation can provide some fancy services like data sharing and access revocation. So much so that major companies have deployed such encryption APIs for with key rotation. How do they do? Actually, they use hybrid encryption. Let's have a quick look at this approach. The suffer test contains two parts, one is common, the other is down, where the asset is the data encryption key. For the key rotation, the client retrieved the first part of the suffer test decrypted and recrypted with the new separate key. And then save the first part to the cloud server. We can see that in the cloud server, the second part of the suffer test keep unchanged all the time. A simple method. We want to know that this key rotation method works. But actually, the answer is no. Imagine that attackers corrupt the client at some time and get the secret key CK2 and the first part of the suffer test C2 star. We can decrypt it to get the secret data encryption key S and then he tried to corrupt the cloud server, no matter how long it spins. Once it succeeds, it can get the second part of the suffer test, and then it can decrypt them to get the plan data. And we know that the widely deployed the key rotation method is not secure at all. So we want to know how to model the security or encryption with the key rotation. In order to systematically study this encryption, people formalize a new parameter called update more encryption also shorted for you. So briefly introduce the general paradigm. Similar to standard encryption, it includes the key encryption, key generation encryption and decryption methods. The suffer test contains two parts. The first part is header, which is short and the constant and the second part is the body is the real. It contains the real encryption of the data. The update procedure contains two methods. The client retrieved the header and runs a key generation method to produce a token and send to the server. The server use the token to update the suffer test body. Similarly, you have two basic requirements for the update procedure. During the update, both the communication cost and the computation cost in the client side should be not related to the data size. From the general paradigm, we can see that the token generation is related to the suffer test header. So the general UI also called suffer test dependent update more encryption, especially if the header is so short to empty. In some sense, it assails the communication cost with some other trade off. For example, no background update, suffer test update. In our paper, we mainly focus on suffer test dependent update for encryption, this general case. Now, we want to know how to formulate the UI's security. Compared with the standard encryption, the big difference is that UI's adversary has more capability. It's because that there is more than one secret key. Let's see the detail in the diagram. Here the epoch denotes a time period for the different epochs, the key is different. And the blue boxes values are corrupted by the adversary. So adversary can corrupt the key, the token, the suffer test and the update or suffer test for different epochs. And then we consider the UI's desired security goal. Since UI was proposed to achieve the secure cloud storage. Eventually, both the confidentiality and the integrity are needed. The subtle point is how to exclude the impossibility for each security goal. For example, confidentiality is hopeless if the adversary can compromise the Chinese suffer test and its corresponding secret key. Let's see the detail in the diagram. The epoch E is a challenge epoch. Then adversary cannot corrupt the secret key key. And in the epoch E plus 3, adversary has the secret key, then he cannot query the update of the challenge suffer test in this epoch. Since adversary can derive the update or suffer test from the previous compromised suffer test and its token. So in the epoch E plus 2, adversary derives such a challenge suffer test update so he cannot query the secret key. For the integrity, intuitively, we showed that integrity is hopeless in the key crafted epoch. Here we will miss the detail. Based on the big difference between the UI and the standard encryption, and it's well known that AE has a relationship, the CPA in distinguishability plus the suffer test integrity can imply the CCA in distinguishability. We are curious about how the relationship in UI. Surprisingly, we found this relationship does not hold in UI. Why is because of the adversary's capability gap? Concretely, between the confidentiality and the integrity game, there exists a gap for the adversary's capability that is adversary in the suffer test integrity game cannot corrupt the token from the key crafted epoch to the key uncropped epoch. But in the confidentiality game, this token corruption is allowed except for the challenge suffer test header. So there may exist an adversary who fails the CPA and the CTIC game, but it can leverage this capability gap to forge a new suffer test, which is related to the challenge suffer test and then query the declaration oracle to win the CCA game. More convincingly, we designed a counter example, which is the CPA and CTIC secure, but the CCA insecure. Now we introduce our design intuition. We start from a CPA and CTIC secure game and do some modification on it. The first is that the update token contains some secret information, which is protected by the previous epoch key. Please note that for the CTIC adversary, it cannot corrupt the update token and the previous epoch key at the same time. So he cannot get this secret information. Then the secret information can be used to forge a new suffer test, which may contain the challenge bit. So far, we see the scheme is still CTIC secure. Why is because CTIC adversary cannot get the secret information, then he cannot forge a new suffer test. The third step is the new suffer test can be decrypted but cannot be updated. This ensures that the scheme is CPA secure because the CPA adversary have no access to the decryption oracle, then the forge the new suffer test is useless for him. The third step is the CC adversary can query the decryption oracle with this forge the new suffer test to get the challenge bit. So the scheme is now CCA secure. We also noticed that there is a separate worker to show that this relationship holds for suffer test independent UE. We have to say for general UE CPA indistinguishability plus the suffer test integrity are not enough. The CC security is needed. Then we set forth to check the existing treatment on CCA secure UE. We found an issue that is the existing security models have an artificial restriction. It is adversary cannot query the engine oracle with malicious suffer test. Why we say this restriction is artificial. The reason had two aspects. The first is in the model level in standard CC and integrity models adversary naturally allowed to manipulate the suffer test, but this capability is restricted in the UE security models. The second is more important. Since such models with restriction cannot capture the real attack we call this malicious inclusion attack. Let's introduce this attack in detail. Here is a UE system attackers like the compromise the system manager may corrupt the cloud server and obtain the read and write privilege. Then he can inject a new suffer test to the cloud server after a time period the suffer test got updated to new words then adversary may corrupt the server again and read the update of the suffer test injected before. Actually, this attack can threaten both the confidentiality and the integrity. The confidentiality since the suffer test the C form had a prime may leak some information about other suffer test CC one prime. As for the integrity, we say attackers may leverage this suffer test to forge a new valid suffer test. Once more we found the existing schemes are vulnerable to this malicious reaction attack. Let's take the KSS scheme as an example. Here is KSS encryption. It is similar as the calm down encryption. The difference is that the data in question why the data in question key why is secret shared into two shares s and y minus s. The header is the encryption of the one share and the secret key and the other share is attached in the body. The data procedure is the client update the share in the header with the new secret key and attach it in the token. And then the server use the token to update the body part actually he only update the share in the body. The claim that malicious reaction attack can threaten both the confidentiality and the integrity of the KSS scheme. Here we show the threat confidentiality in detail. We said that the epoch E is a challenge start epoch then adversary can craft the suffer test challenge suffer test the CEB and then he can modify the suffer test to a new one just add one to the share in the body. Then move to the next epoch and adversary can craft the secret key then he cannot get to the update of the challenge suffer test but he can call it the update of the malformed suffer test too. Based on the update he can recover the real update of the challenge suffer test then we can decrypt it together challenge bait. So the case as scheme is vulnerable from this threat we hope to conclude some intuitive idea about why KSS is vulnerable to malicious reinclusion attack. The second is during the update, the malformed suffer test cannot be recognized. This point is quite important to construct a secure use scheme in our, in our work. We will introduce this later. The first contribution is the formalizing the strengths and security models. First we remove the restriction to capture the malicious reinclusion attack for three security goals, including confidentiality, integrity and the reinclusion in distinguishability. So first the contribution shows CCA security is still needed for your use so we also define the CCA style confidentiality and the reinclusion in distinguishability models. In our previous work, how pointed out that the existing your models are not clear to capture the most compromised security. So we introduced the epoch notion to make it clear. The third contribution is building a secure construction in our strengths and security models. We know that the weakness of the existing schemes is they are vulnerable to the malicious reinclusion attack. In 2000, this problem, the main goal is to resist the malicious reinclusion attack. So our idea is to enable the UI suffer test the checkability that is make sure only valid suffer test can be updated. Then the first challenge turns to how to make the suffer test the checkable. For the UI paradigm, the suffer test contains two portions, the header and the body and the header is available to the client who has a secret key. Let's take down the check into two steps. First, we find the two portions of the suffer test and then we make the header itself checkable with a secret key. That means the banded body will be checkable. Concretely, let's take a look at our construction, Recreate Plus. How does it achieve the two steps? As the name implies, Recreate Plus is built from the existing UI scheme, Recreate, and as the checkability. And the Recreate scheme is CPA secure, CPA CDNT and reincreasing the distinguishability secure in the restricted models. Here is a Recreate the suffer test. It's also kind of come down with secret sharing. The difference is data encryption key F1 to FK. Recreate achieve this data encryption with a special tool called key homophic PINF, which enables the update of the data encryption key. Now we need to add the checkability. The first step is to band the header and the body. Our idea is to attach some information to the header to band it with the body. We know that the body contains two parts, the share and the data encryption. So first we band the share arm with a commitment. And in order to check the commitment, we also need to attach the opening to the body. And then we band the data encryption with hash function. It's okay to remember the original data encryption in the body. Then the second step is to make the header checkable with the secret key. Our simple idea is to use the authenticated encryption with associated data to achieve this encryption and treat the attached two parts as associated data and also attach them at the end of the header. To check the header is only to decrypt the AEAD. Now the self-test is checkable. Then the challenge turns to how to update the self-test. We know that before the update, the challenge, the self-test itself is checkable. Then we need to make sure that after the update, the updated self-test is still checkable. This is the recrypted plus self-test. The header and the body. And we know that the box three parts are modified during the last step to achieve the self-test checkability for the other unmodified parts. We use the original update method to update the zone. Now we need to update the other modified parts. As for the opening, just plus the data opening is okay to make it consistent with the updated share. And then we need to update the commitment. In order to keep it checkable, we need to ban the update of the commitment to the new share. So it requires the update of the commitment equals to the commitment of the update. So we need a homophic commitment. Also, we need to update the hash. Also, to make it checkable, we need to ban the update of the hash to the new data encryption. It also requires the update of the hash equals to the hash or the new update. So we also need a homophic hash. The other point is that we know the original data encryption F1 to F key are key homophic pf values. Here the hash is also key homophic. So in some sense we require the two homophism compatible. That is the domain of the homophic hash is the range of the key homophic pf. We need to involve a primitive called homophic hash from DDH group to achieve this. As for the security, we reduce the CCA security to the CCA security or AEAD, the banning and hiding property or homophic commitment, the clearing resistance of the homophic hash function and the randomness of the key homophic pf. We also reduce the sabotage integrity to the sabotage integrity or AEAD and the banning property of the homophic commitment and the clearing resistance of the homophic hash function. To summarize, firstly, for general EOE, we show the surprising relationship and then we formalize the new strengthened EOE security models. Finally, we propose a new construction which is secure in our strengthened security models. That's all. Thank you.