基于JavaCard的云数据确定性删除方法

Achieving Assured Deletion of Cloud Data Using JavaCard

摘要

确定性删除将外包数据的删除问题转换为密钥的安全管控和删除问题，使得留存于云服务提供商和数据使用者处的外包数据是失效、不可恢复的。但是，现有的确定性删除方案大多是在资源充裕的计算机和智能手机上设计和实现的，无法应用于资源受限的嵌入式设备。本文提出了适用于JavaCard平台的云数据确定性删除方法。在该方法中，密钥的使用条件可以是时间，也可以是次数，数据属主可以根据其需要选取一种条件以实现密钥在数据使用者端的受限使用。对于这两种使用条件，数据使用者都可以将密钥及使用条件安全保存在本地，节省通信开销。当密钥使用条件满足时，JavaCard用密钥解密数据； 当密钥使用条件不满足时，JavaCard安全删除密钥，并生成可公开验证的密钥删除证据。实验和对比分析表明，本文方案性能开销合理，能够实现预期目的，可以应用于嵌入式设备。

Abstract

The process of deleting outsourced data in cloud storage can be transformed into controlling and deleting the data encryption key securely, a concept known as assured deletion. The objective is to make the outsourced data retained by cloud service providers both invalid and unrecoverable for data users. However, most of the existing assured deletion schemes cannot be applied directly to embedded devices with limited resources as they are designed and implemented on computers and smartphones with abundant resources. This paper considers the assured deletion of cloud data under JavaCard platforms. Our proposal supports two conditions for using the data encryption key, i.e., the time and the number of times. The data owner can choose one state to determine how a data user can use the key according to the requirements. Moreover, for these two types of use conditions, the data user can store both the key and the use condition securely locally, saving communication overhead. The decryption of data using the key by JavaCard is only possible when the specified use condition is satisfied. In case when the use condition is not met, JavaCard surely deletes the key and generates evidence of key deletion, which is verifiable publicly. Comprehensive experimental evaluations and comparison analysis demonstrate reasonable performance overhead, ssuccessfully achieving the designed objectives. This implies that our proposal can be effectively applied to embedded devices.

Graphical abstract

关键词

云数据 / 确定性删除 / 密钥管理 / JavaCard

Key words

cloud data / assured deletion / key management / JavaCard

0　 引 言

在云存储模式下，数据被外包存储在云服务提供商（cloud service provider,CSP）处，并在数据使用者（data user,DU）端被使用，脱离了数据属主（data owner,DO）的物理控制。此时，DO无法直接删除数据。为了使得留存在CSP和DU处的数据在生命周期到达或不满足使用条件时是失效的、不可恢复的，学者们提出了外包数据的确定性删除（assured deletion）方法，其基本思想是利用密码学相关理论和技术将外包数据的删除问题转换为密钥的安全管控和删除问题，即在将数据外包存储于CSP之前，DO先对数据加密，若加密算法是安全的，则DO可以通过安全管控密钥来实现对数据的管控。密钥被安全删除后，留存于CSP和DU处的密文数据将不能被解密和访问，这时数据是不可用的，其效果等同于数据被删除了^[1，2]。

根据密钥使用条件的不同，现有的确定性删除方案一般可以分为三类，即基于时间的方案^[3~5]、基于策略的方案^[6~8]和基于次数的方案^[9~11]。但是，这些方案大多是基于资源充裕的计算机或智能手机设计和实现的，无法直接应用在资源受限的嵌入式设备上。例如，基于时间的确定性删除方案一般是将密钥分割处理后存储在动态变化的分布式哈希表（distributed hash table,DHT）网络中，以确保在密钥使用期到达时，密钥片段将因网络的动态变化而丢失，使得原始密钥不能被恢复出来。这类方案在设定密钥使用时间时会受限于所使用的动态网络；其次，密钥片段存储在第三方网络中，也会增加方案的通信开销，即DU每次访问数据时，都需要从网络中获取密钥片段，使得其无法很好地应用在带宽受限的嵌入式设备上。

在基于策略的确定性删除方案中，密钥与用户自定义的数据访问策略相关联，对策略进行操作即可控制密钥的使用与删除，DU只有在满足给定的策略或属性时才能获得密钥。这类方案大多采用了属性基加密（attribution-based encryption,ABE）^[12]算法来保护密钥，计算开销较大。而且，加密后的密钥一般被保存在第三方设备^[7]或云服务器^[8]中，导致方案的通信开销与DU访问数据的次数呈线性增长关系。资源受限的嵌入式设备在频繁访问数据时，可能无法承担这样的计算和通信开销。

基于次数的确定性删除方案会为密钥设定一个最大使用次数，并利用单调计数器记录密钥的已使用次数，当密钥的已使用次数未超过最大使用次数时，密钥可以被正常使用；否则，密钥会被安全删除。在这类方案中，DU可以将密钥及其使用次数都保存在本地，从而节省了从网络中获取密钥及其使用次数的通信开销。但是，现有的基于次数的方案需要可信平台模块（trusted platform module,TPM）^[9]、Intel SGX^[10]或ARM TrustZone^[11]等安全硬件及其配套软件库的支持。嵌入式设备由于体积和资源有限，不一定具备这样的软硬件环境。

JavaCard^[13]是SUN公司推出的一种卡上应用平台技术规范，也是一种可用Java语言编程的特殊智能卡，在嵌入式环境中有着广泛的应用，包括用于用户身份验证^[14]、硬件钱包^[15]等。因此，本文以具有较好的开放性、通用性和较高安全性的JavaCard为对象和载体，提出了基于JavaCard的云数据确定性删除方法，以解决嵌入式设备上的外包数据确定性删除问题。不同于现有方案只支持一种密钥使用条件，在本文方案中，密钥使用条件可以是时间，也可以是次数，DO可根据其需要选取一种密钥使用条件。当密钥使用条件为时间时，DO为密钥指定最大使用时长，采用FSE-TSE（time-specific encryption from forward-secure encryption）算法^[16，17]加密密钥，确保只有当前时间小于密钥失效时间点时，保存在JavaCard中的FSE-TSE私钥才是有效的，可被用于恢复出密钥。当密钥使用条件为次数时，DO为密钥指定最大使用次数，JavaCard则生成并维护一个用于记录密钥使用次数的虚拟单调计数器，以确保只有密钥已使用次数不超过其最大使用次数时，JavaCard才会恢复出密钥。当密钥使用条件不满足时，JavaCard将安全地删除密钥，生成可公开验证的密钥删除证据，并将该证据发送给DO。对于这两种密钥使用条件，DU都可以将密钥及其使用条件保存在本地，从而有效地减小方案的通信开销。本文方案充分利用了JavaCard自身的特性为密钥及其使用条件提供安全保护，无需额外的安全硬件及软件库的支持。

1　 系统模型

1.1　系统框架

本文方案有4个参与方，即云服务提供商CSP、数据属主DO、数据使用者DU、网络时间服务器（network time server,NTS），其框架如图1所示。

1） CSP。CSP是诚实但好奇的，即CSP向DO和DU提供存储服务，但可能会偷窥或泄漏其存储的数据。

2） DO。DO利用CSP提供的存储服务向外发布数据。为保护数据的机密性，DO在将数据外包给CSP之前用对称加密算法加密数据。为防止授权的DU在获得数据和密钥后无限制地使用数据，DO会为密钥设定使用条件，将使用条件与密钥一起发送给DU，以确保DU只能按照设定的条件使用数据。

3） DU。DU从CSP处获得密文数据，从DO处获得对应的密钥，利用密钥访问数据。DU端的设备为带有JavaCard的嵌入式设备，包括不可信的Host和可信的JavaCard两个部分。密钥信息（包括密钥的密文、使用条件及其哈希与签名等）存储在Host中。密钥信息和数据的处理(包括验证密钥的使用条件、恢复出密钥、更新密钥的哈希、恢复出明文数据等)则是在JavaCard中进行的。若密钥使用条件满足，JavaCard将明文数据返回给Host；否则，JavaCard安全地删除密钥，并生成可验证的密钥删除证据。

4） NTS。只有当密钥使用条件为时间时，NTS才会作为本文方案的一个参与方，为DO和DU提供实时同步的当前网络时间。当密钥使用条件为次数时，NTS不出现在本文方案中。

1.2　安全假设

对于图1所示的框架，本文有以下安全假设：

1） DU不会主动泄漏明文数据和密钥，即本文不考虑人为的截屏和拍照等泄漏行为，这类主动泄漏行为从技术上是很难防范的。但是，DU可能因遭受攻击或者误操作而导致数据的使用不受限制。

2） DO、DU端的JavaCard分别拥有可标识身份的公私钥对，且彼此存有对方的身份公钥（在DU端，DO的身份公钥被保存在JavaCard中）。此外，本文假定DO/JavaCard的身份公钥与其身份是对应的，身份公钥被篡改或替换的情况可通过证书等方式防范，本文不考虑这种情况。

3） JavaCard是可信的，其内部加解密的实现是正确且可验证的，本文直接采用了文献[18]中的验证方法，不再介绍其具体细节。

4） 当NTS作为方案的一个参与方时，DO和DU都拥有NTS的真实公钥。在DU端，NTS的公钥被存储在JavaCard中。同样的，本文也不考虑NTS的公钥被篡改或替换的情况。

1.3　设计目标

在图1所示的场景中，授权的DU虽然能够使用数据，但是其对数据的使用必须是按预设条件进行的，即只有当密钥使用条件被满足时，DU才能通过密钥正常使用数据；否则，密钥将被安全地删除，数据将不能被使用。

为此，本文的设计目标包括：1) 通过设定密钥的使用条件来实现JavaCard设备上的云数据的受限使用和确定性删除，且密钥使用条件的判定和执行不受外界的干扰；2) 根据需要选取密钥使用条件，包括时间(即限定密钥可使用的时长，超过该时长就不能使用密钥)和次数(即限定密钥的使用次数，超过该次数就不能使用密钥)；3) 密钥的安全删除能够被验证。为了实现这些设计目标，需要考虑以下的安全挑战：

i） 密钥使用条件不能被篡改。若使用条件被篡改了(如将密钥可使用时长或次数改得足够大)，则密钥的使用将不受限制，数据的使用也将不受限制。为此，本文通过数字签名来保证使用条件的完整性，每次使用密钥之前都需要验证签名的有效性以检查使用条件是否被篡改。

ii） 密钥的当前状态必须是最新的。当使用条件为时间时，JavaCard中存储的FSE-TSE私钥必须是最新的。如果当前FSE-TSE私钥不是最新时间段的，FSE-TSE算法的前向安全性将失效，为密钥设定的时限将不起作用。当使用条件为次数时，密钥的已使用次数必须是最新的。如果密钥已使用次数不变或者被回滚，为密钥设定的次数将失去作用。

为此，本文分别通过NTS和单调计数器来确保密钥使用时间和次数的实时性，并通过哈希比对的方式防止重放攻击。当使用条件为时间时，每次使用密钥前都需要将先前保存的FSE-TSE私钥的哈希与当前FSE-TSE私钥的哈希进行比对，若比对不通过，则表明发生了重放攻击，密钥将不能被正确解密和使用。每次使用完密钥且密钥还不应被删除时，就根据当前网络时间对FSE-TSE私钥进行更新，并计算和存储更新后的FSE-TSE私钥的哈希。

当使用条件为次数时，JavaCard用单调计数器记录密钥当前已使用的次数。每次使用密钥前都需要将先前保存的使用次数的哈希与计数器当前值的哈希进行比对，若比对不通过，则表明发生了重放攻击，密钥将不能被正确解密和使用。每次使用完密钥且密钥还不应被删除时，计数器的值会自动增加，更新后的使用次数的哈希也会被重新计算和存储。

iii） 与密钥相关的操作，包括验证使用条件的签名、计算和比对使用条件的哈希、使用条件的比较、恢复出密钥的明文、用密钥解密数据、更新密钥或计数器等，都被如实地执行，不能被绕过。本文将这些敏感操作都放在可信的JavaCard中进行，并可以通过远程证明^[19，20]的方式验证执行程序的可信性，以确信它们是按预期方式执行的。

2　 方案描述

为简化描述，将下文常用到的符号及其对应的含义列举在表1中。此外，假定DO已经完成了对数据的加密，并已经将加密后的数据存储在CSP处；DU已经从CSP处获得了密文数据。

2.1　限制密钥使用时间的确定性删除方案

本小节的限制密钥使用时间的确定性方案包括两个阶段：初始化阶段和数据使用阶段。在初始化阶段，DO根据DU的请求，为DEK指定使用时长，运行FSE-TSE算法生成初始的FSE-TSE私钥并加密DEK，将密钥信息（包括DEK的密文、失效时间点及其签名、FSE-TSE的主密钥及加密后的私钥等）发送给DU。DU将FSE-TSE私钥存储在JavaCard中，将FSE-TSE私钥的哈希添加到密钥信息中，将密钥信息存储在Host中。

在数据使用阶段，DU用DEK解密和访问数据。每次访问数据时，存储在Host中的密钥信息先被发送至JavaCard。JavaCard检查密钥信息的有效性，若检查通过，JavaCard更新FSE-TSE私钥及其哈希、用DEK解密数据，将数据明文返回给Host。若检查未通过，JavaCard返回错误信息或者删除FSE-TSE私钥，并生成可验证的密钥删除证据。FSE-TSE算法的详细描述见文献[21]。

2.1.1　初始化阶段

1) Host向JavaCard发出生成迁移密钥的请求。

2) JavaCard生成非对称的迁移密钥对(sk_Mgr，pk_Mgr)，将公钥部分pk_Mgr返回给Host，将私钥部分sk_Mgr保存在JavaCard中。

3) Host向DO发出密钥获取请求以获取DEK，该密钥获取请求中还包含了pk_JD，pk_Mgr，ID_M，ID_DU。

4) DO将pk_JD和ID_DU绑定后保存在本地，为DEK设定使用时长MaxT_DEK。之后，DO从NTS处获取当前时间t₀和NTS对t₀的签名。在验证t₀的有效性后，DO运行算法FSE-TSE.Setup(1 ^κ,T)生成FSE-TSE的公钥MPK和初始私钥信息\mathrm{s}{\mathrm{k}}_{[t_{{}_{\mathrm{0}}},t_{{}_{\mathrm{1}}}]}，其中κ为安全参数，T为DEK生效的时间段总数。接着，DO计算DEK的失效时间点DTP_DEK=t₀+MaxT_DEK，运行算法FSE-TSE.Enc(MPK，DTP_DEK，DEK)得到DEK的密文EncT_DEK。

5) DO用pk_Mgr加密ID _M 和\mathrm{s}{\mathrm{k}}_{[t_{{}_{\mathrm{0}}},t_{{}_{\mathrm{1}}}]}得到\mathrm{E}\mathrm{n}{\mathrm{c}}_{\mathrm{s}\mathrm{k}}=E_{\mathrm{p}{\mathrm{k}}_{\mathrm{M}\mathrm{g}\mathrm{r}}}(\mathrm{I}{\mathrm{D}}_M||\mathrm{s}{\mathrm{k}}_{[t_{\mathrm{0}},t_{\mathrm{1}}]})，用sk_DO对ID _M 和DTP_DEK签名得到\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{D}\mathrm{T}{\mathrm{P}}_{\mathrm{D}\mathrm{E}\mathrm{K}}}=\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{s}{\mathrm{k}}_{\mathrm{D}\mathrm{O}}}(\mathrm{I}{\mathrm{D}}_M||\mathrm{D}\mathrm{T}{\mathrm{P}}_{\mathrm{D}\mathrm{E}\mathrm{K}})，将ID _M，MPK，DTP_DEK，\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{D}\mathrm{T}{\mathrm{P}}_{\mathrm{D}\mathrm{E}\mathrm{K}}}，EncT_DEK，\mathrm{E}\mathrm{n}{\mathrm{c}}_{\mathrm{s}\mathrm{k}}发送给Host。

6) Host将ID _M，MPK，\mathrm{E}\mathrm{n}{\mathrm{c}}_{\mathrm{s}\mathrm{k}}发送给JavaCard。

7) JavaCard用sk_Mgr解密\mathrm{E}\mathrm{n}{\mathrm{c}}_{\mathrm{s}\mathrm{k}}恢复出\mathrm{s}{\mathrm{k}}_{[t_{{}_{\mathrm{0}}},t_{{}_{\mathrm{1}}}]}，计算\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{s}\mathrm{k}}=H(\mathrm{I}{\mathrm{D}}_M||\mathrm{s}{\mathrm{k}}_{[t_{\mathrm{0}},t_{\mathrm{1}}]})，将\mathrm{s}{\mathrm{k}}_{[t_{{}_{\mathrm{0}}},t_{{}_{\mathrm{1}}}]}和ID_M绑定后存储在JavaCard中，将\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{s}\mathrm{k}}返回给Host。

8) Host将ID _M,MPK,DTP_DEK,\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{D}\mathrm{T}{\mathrm{P}}_{\mathrm{D}\mathrm{E}\mathrm{K}}},EncT_DEK,\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{s}\mathrm{k}}存储在本地。

2.1.2　数据使用阶段

1) Host将ID _M,MPK,DTP_DEK,\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{D}\mathrm{T}{\mathrm{P}}_{\mathrm{D}\mathrm{E}\mathrm{K}}},EncT_DEK,\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{s}\mathrm{k}},C发送给JavaCard。

2) JavaCard收到上述信息后，用pk_DO验证\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{D}\mathrm{T}{\mathrm{P}}_{\mathrm{D}\mathrm{E}\mathrm{K}}}的有效性。若验证成功，则执行第3)步；否则，返回密钥加载失败信息。

3) JavaCard根据ID _M 获取当前的私钥\mathrm{s}{\mathrm{k}}_{[t_{i-\mathrm{1}},t_{{}_i}]}，计算\mathrm{D}\mathrm{i}{\mathrm{g}}_{{}_{\mathrm{s}\mathrm{k}}}^{\mathrm{\text{'}}}=H(\mathrm{I}{\mathrm{D}}_M||\mathrm{s}{\mathrm{k}}_{[t_{i-\mathrm{1}},t_i]})，比较\mathrm{D}\mathrm{i}{\mathrm{g}}_{{}_{\mathrm{s}\mathrm{k}}}^{\mathrm{\text{'}}}和\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{s}\mathrm{k}}。若它们相等，则执行第4)步；否则，返回密钥加载失败信息。

4) JavaCard从NTS处获取当前时间t_cur和NTS对t_cur的签名，若t_cur有效，则比较t_cur和DTP_DEK的大小。若t_cur≤DTP_DEK，则执行第5)~7)步，然后结束本次数据访问过程；否则，返回密钥加载失败信息，然后执行第8)~10)步，结束整个数据访问过程。

5) 假定t_cur在时间段[t_j-1,t_j ](i≤j≤T)内，JavaCard运行\mathrm{F}\mathrm{S}\mathrm{E}-\mathrm{T}\mathrm{S}\mathrm{E}.\mathrm{U}\mathrm{p}\mathrm{d}(\mathrm{M}\mathrm{P}\mathrm{K},\mathrm{s}{\mathrm{k}}_{[t_{i-\mathrm{1}},t_{{}_i}]},[t_{j-\mathrm{1}},t_j])算法得到\mathrm{s}{\mathrm{k}}_{[t_{j-\mathrm{1}},t_j]}，将i的值更新为j，将\mathrm{s}{\mathrm{k}}_{[t_{i-\mathrm{1}},t_{{}_i}]}和ID _M 绑定后存储在JavaCard中。

6) JavaCard计算\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{s}\mathrm{k}}=H(\mathrm{I}{\mathrm{D}}_M||\mathrm{s}{\mathrm{k}}_{[t_{i-\mathrm{1}},t_i]})，运行\mathrm{F}\mathrm{S}\mathrm{E}-\mathrm{T}\mathrm{S}\mathrm{E}.\mathrm{D}\mathrm{e}\mathrm{c}(\mathrm{s}{\mathrm{k}}_{[t_{i-\mathrm{1}},t_{{}_i}]},\mathrm{E}\mathrm{n}\mathrm{c}{\mathrm{T}}_{\mathrm{D}\mathrm{E}\mathrm{K}})算法恢复出DEK，用DEK解密C恢复出M，将\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{s}\mathrm{k}}和M返回给Host。

7) Host将\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{s}\mathrm{k}}保存在本地。

8) JavaCard删除其存储的\mathrm{s}{\mathrm{k}}_{[t_{i-\mathrm{1}},t_{{}_i}]}，生成密钥删除消息“ID_DU deleted DEK of ID _M ”(用符号DelMes表示该消息)，用sk_JD对DelMes签名得到\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{D}\mathrm{e}\mathrm{l}\mathrm{M}\mathrm{e}\mathrm{s}}=\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{s}{\mathrm{k}}_{\mathrm{J}\mathrm{D}}}(\mathrm{D}\mathrm{e}\mathrm{l}\mathrm{M}\mathrm{e}\mathrm{s})，将Proof=(DelMes，\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{D}\mathrm{e}\mathrm{l}\mathrm{M}\mathrm{e}\mathrm{s}})作为密钥删除证据返回给Host。

9) Host将Proof发送给DO。

10) DO用pk_JD验证Proof。若验证通过，则确信DU端的JavaCard确实删除了密钥。在此之后，如果DO发现DU端仍然能够使用密钥访问数据，则可通过Proof对DU追责。若验证不通过，则向DU发送密钥删除证据验证未通过的消息。

2.2　限制密钥使用次数的确定性方案

本小节的限制密钥使用次数的确定性方案包括初始化阶段和数据使用阶段。在初始化阶段，DO根据DU的请求，为DEK指定最大使用次数，将密钥信息（包括DEK的密文、最大使用次数及其签名）发送给DU。DU在JavaCard中创建一个用于记录DEK已使用次数的虚拟单调计数器，并对计数器进行初始化，将DEK当前已使用次数的哈希添加到密钥信息中，将密钥信息存储在Host中。

在数据使用阶段，DU使用DEK解密和访问数据。每次访问数据时，存储在Host中的密钥信息先被发送至JavaCard。JavaCard检查密钥信息的有效性，若检查通过，JavaCard用DEK解密数据，将数据明文返回给Host，并更新单调计数器的值及其哈希。若检查未通过，JavaCard返回错误信息或者删除sk_Mgr，并生成可验证的密钥删除证据。

2.2.1　初始化阶段

1) Host向JavaCard发送生成迁移密钥的请求。

2) JavaCard生成非对称的迁移密钥对(sk_Mgr， pk_Mgr)，将公钥部分pk_Mgr返回给Host，将私钥部分sk_Mgr保存在JavaCard中。

3) Host向DO发出密钥获取请求以获取DEK，该密钥获取请求中还包含了pk_JD，pk_Mgr，ID _M，ID_DU。

4) DO将pk_JD和ID_DU绑定后保存在本地，为DEK设定最大使用次数MaxN_DEK，用pk_Mgr加密ID _M 和DEK，得到\mathrm{E}\mathrm{n}\mathrm{c}{\mathrm{N}}_{\mathrm{D}\mathrm{E}\mathrm{K}}=E_{\mathrm{p}{\mathrm{k}}_{\mathrm{M}\mathrm{g}\mathrm{r}}}(\mathrm{I}{\mathrm{D}}_M||\mathrm{D}\mathrm{E}\mathrm{K})，再用sk_DO对ID _M 和MaxN_DEK签名，得到\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{M}\mathrm{a}\mathrm{x}{\mathrm{N}}_{\mathrm{D}\mathrm{E}\mathrm{K}}}=\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{s}{\mathrm{k}}_{\mathrm{D}\mathrm{O}}}(\mathrm{I}{\mathrm{D}}_M||\mathrm{M}\mathrm{a}\mathrm{x}{\mathrm{N}}_{\mathrm{D}\mathrm{E}\mathrm{K}})，将ID _M,MaxN_DEK,\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{M}\mathrm{a}\mathrm{x}{\mathrm{N}}_{\mathrm{D}\mathrm{E}\mathrm{K}}},EncN_DEK发送给Host。

5) Host将ID _M 发送至JavaCard。

6) JavaCard创建一个与ID _M 相绑定的单调计数器VC(假定该VC的标识符为ID_VC，后文均用ID_VC来表述该VC)，将ID_VC的值VCVal初始化为0。

7) JavaCard创建变量Cnt_DEK以记录DEK当前已使用的次数，获取ID_VC的当前值VCVal，将VCVal赋给Cnt_DEK，计算\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{C}\mathrm{n}{\mathrm{t}}_{\mathrm{D}\mathrm{E}\mathrm{K}}}=H(\mathrm{I}{\mathrm{D}}_M||\mathrm{C}\mathrm{n}{\mathrm{t}}_{\mathrm{D}\mathrm{E}\mathrm{K}})，将\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{C}\mathrm{n}{\mathrm{t}}_{\mathrm{D}\mathrm{E}\mathrm{K}}}返回给Host。

8) Host将ID _M，MaxN_DEK，\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{M}\mathrm{a}\mathrm{x}{\mathrm{N}}_{\mathrm{D}\mathrm{E}\mathrm{K}}}，EncN_DEK，\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{C}\mathrm{n}{\mathrm{t}}_{\mathrm{D}\mathrm{E}\mathrm{K}}}存储在本地。

2.2.2　数据使用阶段

1) Host将ID _M，MaxN_DEK，\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{M}\mathrm{a}\mathrm{x}{\mathrm{N}}_{\mathrm{D}\mathrm{E}\mathrm{K}}},EncN_DEK，\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{C}\mathrm{n}{\mathrm{t}}_{\mathrm{D}\mathrm{E}\mathrm{K}}},C发送给JavaCard。

2) JavaCard收到上述信息后，用pk_DO验证\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{M}\mathrm{a}\mathrm{x}{\mathrm{N}}_{\mathrm{D}\mathrm{E}\mathrm{K}}}。若验证通过，则执行第3)步；否则，返回密钥加载失败信息。

3) JavaCard根据ID _M 获取ID_VC当前值VCVal，计算\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{C}\mathrm{n}{\mathrm{t}}_{\mathrm{D}\mathrm{E}\mathrm{K}}}^{\mathrm{\text{'}}}=H(\mathrm{I}{\mathrm{D}}_M||\mathrm{V}\mathrm{C}\mathrm{V}\mathrm{a}\mathrm{l})，比较\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{C}\mathrm{n}{\mathrm{t}}_{\mathrm{D}\mathrm{E}\mathrm{K}}}^{\mathrm{\text{'}}}和\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{C}\mathrm{n}{\mathrm{t}}_{\mathrm{D}\mathrm{E}\mathrm{K}}}。若它们相等，则执行第4)步；否则，返回密钥加载失败信息。

4) JavaCard比较VCVal和MaxN_DEK。若VCVal<MaxN_DEK，则执行第5)~7)步，然后结束本次数据访问过程；否则，返回密钥加载失败信息，然后执行第8)~10)步，结束整个数据访问过程。

5) JavaCard用sk_Mgr解密EncN_DEK恢复出DEK，用DEK解密C恢复出M，将M返回给Host。

6) JavaCard将ID_VC的值增加1，然后获取ID_VC的当前值VCVal，将VCVal的值赋给Cnt_DEK，计算\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{C}\mathrm{n}{\mathrm{t}}_{\mathrm{D}\mathrm{E}\mathrm{K}}}=H(\mathrm{I}{\mathrm{D}}_M||\mathrm{C}\mathrm{n}{\mathrm{t}}_{\mathrm{D}\mathrm{E}\mathrm{K}})，将\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{C}\mathrm{n}{\mathrm{t}}_{\mathrm{D}\mathrm{E}\mathrm{K}}}返回给Host。

7) Host将\mathrm{D}\mathrm{i}{\mathrm{g}}_{\mathrm{C}\mathrm{n}{\mathrm{t}}_{\mathrm{D}\mathrm{E}\mathrm{K}}}保存在本地。

8) JavaCard删除其存储的sk_Mgr，生成密钥删除消息“ID_DU deleted DEK of ID _M ”(用符号DelMes表示该消息)，用sk_JD对DelMes签名得到\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{D}\mathrm{e}\mathrm{l}\mathrm{M}\mathrm{e}\mathrm{s}}=\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{s}{\mathrm{k}}_{\mathrm{J}\mathrm{D}}}(\mathrm{D}\mathrm{e}\mathrm{l}\mathrm{M}\mathrm{e}\mathrm{s})，将Proof=(DelMes,\mathrm{S}\mathrm{i}{\mathrm{g}}_{\mathrm{D}\mathrm{e}\mathrm{l}\mathrm{M}\mathrm{e}\mathrm{s}})作为密钥删除证据返回给Host。

9) Host将Proof发送给DO。

10) DO用pk_JD验证Proof。若验证通过，则确信DU端的JavaCard确实删除了密钥。在此之后，如果DO发现DU端仍然能够使用密钥访问数据，则可通过Proof对DU追责。若验证不通过，则向DU发送密钥删除证据验证未通过的消息。

3　 安全性分析

本文方案通过在DU端限制密钥的使用来实现数据的确定性删除，因此，方案的核心是要保证密钥及其使用条件的安全。具体而言，一是保护密钥的机密性，即密钥不能被不可信的Host所获得；二是要保护密钥使用条件的完整性，即密钥的使用条件不能被篡改或绕过。

3.1　密钥的机密性保护

当使用条件为时间时，数据加密密钥DEK由FSE-TSE算法加密后存储在Host中，FSE-TSE的初始私钥信息\mathrm{s}{\mathrm{k}}_{[t_{{}_{\mathrm{0}}},t_{{}_{\mathrm{1}}}]}先由迁移密钥的公钥pk_Mgr加密后传给Host，再在JavaCard中被解密并被存储在JavaCard中。在数据使用过程中，FSE-TSE的私钥信息\mathrm{s}{\mathrm{k}}_{[t_{i-\mathrm{1}},t_{{}_i}]}也都是在JavaCard中被更新和使用的。因此，在JavaCard为可信的情况下，Host无法获得FSE-TSE的私钥信息\mathrm{s}{\mathrm{k}}_{[t_{i-\mathrm{1}},t_{{}_i}]}，也就无法获得DEK，即DEK的机密性能够被保护。

当使用条件为次数时，数据加密密钥DEK由迁移密钥的公钥pk_Mgr加密后保存在Host中，迁移密钥的私钥sk_Mgr保存在JavaCard中，且sk_Mgr只能在JavaCard中被使用。因此，在JavaCard为可信的情况下，Host无法获得sk_Mgr，也就无法获得DEK，即DEK的机密性能够被保护。

3.2　密钥使用条件的完整性保护

当密钥使用条件为时间时，DEK的失效时间点DTP_DEK由DO的私钥sk_DO签名后保存在Host中，每次使用DEK前，JavaCard会首先验证该签名的有效性，以确保DTP_DEK未被篡改。其次，JavaCard会将FSE-TSE当前私钥信息的哈希与上一次存储的FSE-TSE私钥信息的哈希进行比较，以确保FSE-TSE私钥信息是最新的，没有被重放^[9~11]。最后，JavaCard只会用当前时间与DTP_DEK进行比较，以确保密钥使用条件没有被绕过。这些操作都是在JavaCard内部进行的，不受Host的干扰，在JavaCard为可信的情况下，能够确保密钥使用条件的完整性，保证密钥是按预期限定条件被使用的。

当密钥使用条件为次数时，DEK的最大使用次数MaxN_DEK由DO的私钥sk_DO签名后保存在Host中，每次使用DEK前，JavaCard会首先验证该签名的有效性，以确保MaxN_DEK未被篡改。其次，JavaCard用单调递增的计数器记录DEK已被使用的次数，每次使用DEK前，会将当前计数器值的哈希与上一次存储的计数器值的哈希进行比较，以确保计数器值是最新的，没有被重放^[9~11]。最后，JavaCard还会将计数器的当前值与MaxN_DEK进行比较，以确保密钥使用条件没有被绕过。这些操作都是在JavaCard内部进行的，不受Host的干扰，在JavaCard为可信的情况下，能够确保密钥使用条件的完整性，保证密钥是按预期限定条件被使用的。

4　 实验与分析

4.1　实验环境

本文实验环境如下：操作系统为64位的Windows10，CPU是Intel(R) Core(TM) i7-8750HCPU@2.21 GHz，内存为16 GB。编程语言为Java，JDK版本为1.7，集成开发环境为Eclipse 4.11.0。JavaCard设备由在Eclipse中运行的JavaCard Development Kit Simulator(JCDK simulator) 3.1.0模拟。其中，存储临时数据的RAM(random access memory)为24 KB，存储JavaCard运行环境和数据的ROM(Read-Only Memory)为124 KB，存储卡上应用的EEPROM (electrically erasable programmable read-only memory)为128 KB。对称加密算法为AES，非对称加密算法为ECC，哈希函数为SHA-256，数字签名算法为ECDSA，这些算法均由JavaCard API提供。FSE-TSE算法中用于生成双线性映射的群阶数的比特长度为512位（即安全参数κ为512），{\mathbf{\mathbb{Z}}}_p阶数的比特长度为160位。

4.2　时间开销及分析

本文方案是通过在DU端限制密钥的使用来实现数据的确定性删除，因此，本文主要测试了DU端在数据使用阶段中处理密钥所用的时间开销，包括密钥的正常使用和密钥删除两种情况。没有测试初始化阶段和数据加解密的时间开销，其原因在于初始化阶段主要是在DO和DU之间进行密钥迁移，以及在DU端安全存储密钥信息，还没有实际使用密钥，且该过程只执行一次；而用对称加密算法加解密数据是常规操作，所用的AES算法是非常成熟的算法，不是本文方案的重点。

在密钥的正常使用过程中，通过改变DEK的大小来测试方案的时间开销。具体地，在ECDSA密钥长度为128位的情况下，以64、128、256、512、1 024 B的数据模拟不同大小的DEK，分别测试其时间开销。本文还在此情况下测试了CP-ABE算法^[12]和Shamir秘密共享算法^[4，22]的时间开销，以作为对比。其中，CP-ABE算法中用于生成双线性映射群的阶数长度为512位，属性集大小为3，且每个属性包含2个值；Shamir秘密共享算法中（t,n）为（3,5）。对于每组数据，分别执行了50次正常数据访问操作（当密钥使用条件不满足时，重新生成密钥进行测试），以其平均值作为最终结果，如图2所示。其中，当密钥使用条件为时间时，密钥使用时长为3分钟，参数T的值为6；当密钥使用条件为次数时，ECC密钥长度为128位。

由图2可知，密钥的处理时间随着密钥文件大小增加而增加，其原因在于JavaCard是通过应用协议数据单元(application protocol data unit,APDU)缓冲区接收和发送数据的，APDU缓冲区一次可读取的最大数据为224 B，超过224 B的数据则需分块读取，分块时需在每个分块的头部添加指令参数，当所有分块读取完后再在RAM中进行组合以还原出原始数据。因此，密钥越大，JavaCard读取密钥文件的时间越长。此外，在密钥处理过程中，需要计算密钥的哈希，数据量越大，计算哈希的时间也越长。

在本文的限制密钥使用时间的方案中，在运行FSE-TSE.Dec()算法恢复出密钥时需要执行FSE-TSE.Upd()算法，这个过程会产生较多的时间开销。而在本文的限制密钥使用次数的方案中，是直接执行ECC算法的解密操作恢复出密钥的。因此，本文限制时间方案的时间开销比限制次数方案的时间开销要大。

在本文方案与CP-ABE算法和Shamir秘密共享算法的性能比较中，本文限制次数的方案因为只涉及签名验证和哈希等基本运算，其时间开销最小。本文限制时间的方案因为FSE-TSE算法本身的特性，其时间开销略高于Shamir秘密共享算法，但低于CP-ABE算法。例如，当密钥文件大小为1 024 B时，本文限制时间和次数方案的时间开销分别为23.62 ms和19.54 ms，而CP-ABE算法和Shamir秘密共享算法的时间开销分别为30.18 ms和22.37 ms。但是对于通信开销来说，采用Shamir秘密共享算法保护密钥时，DU无法在本地存储密钥，每次访问数据都需要通过网络来获取密钥，因此Shamir秘密共享算法的通信开销较大。在本文限制时间的方案中，密钥能被DU存储在本地，虽然每次访问数据时也需要与NTS交互以获取当前时间，但是其通信开销相较于Shamir秘密共享算法要小一些。从数量级上来看，本文方案的时间开销对于嵌入式设备是可以接受的。

当使用条件不满足时，JavaCard会安全删除密钥，并生成密钥删除证据。因此，本文在不同长度的ECDSA密钥（长度分别为112、128、160、192位）下测试了证据生成的时间开销，测试结果为50次操作的平均值，其结果如表2所示。从表2可见，当ECDSA密钥长度增加时，证据生成时间也将增加。这是因为生成证据时，ECDSA密钥在签名过程中要参与模运算，密钥越大，运算时间越长，最终的签名时间也越多。从数量级上看，当ECDSA密钥长度为192位时，证据生成的时间为18.62 ms，其时间开销对于嵌入式设备也是可以接受的。

4.3　通信和存储开销

在通信和存储开销方面，本文原型系统生成的JavaCard可执行文件（JavaCard converted applet，CAP）占用的空间为35 KB，只占用了本文EEPROM空间的27.34%。若用8位存储ID _M,16位存储时间,8位存储次数，则当ECDSA密钥为128位、ECC密钥为128位时，本文方案的通信及存储开销如表3所示。从表3中可见，本文方案的通信及存储开销都较小，能够满足存储和带宽资源有限的嵌入式设备的应用要求。

4.4　方案的综合对比分析

表4给出了本文方案与现有方案的一些对比。文献[3]和文献[4]利用了DHT网络动态变化的特性使得密钥片段在指定的时间点到达后丢失，从而限制了密钥的使用时间。文献[7]和文献[8]利用ABE算法对密钥进行保护，通过策略来限制密钥的使用。上述方案将密钥存放在DHT网络或可信第三方处，DU每次访问数据时都需要通过网络来获取密钥，使得方案的通信开销较大。文献[9~11]在不同类型的安全硬件上设计了单调计数器以实现对密钥使用次数的限制，但是嵌入式设备一般不具备这样的安全硬件及其配套的软件库。总体而言，大多现有的确定性删除方案应用场景都是在PC或移动设备上设计的，难以直接应用于资源受限的嵌入式设备。此外，大多数确定性删除方案只支持单一的密钥限制条件，使得方案的应用场景较为局限。

在本文方案中，密钥使用条件可以是时间，也可以是次数，DO可根据需要指定密钥的使用条件。而且只在初始化阶段通过网络传输一次密钥及其使用条件。之后，密钥及其使用条件被安全存储在DU本地，节省了通信开销。本文充分利用了JavaCard自身的安全特性为密钥及其使用条件提供保护，无需额外的安全硬件及软件库支持。此外，与近期的多数确定性删除方案^{[7，8，10，11，18，23，24]}一样，本文方案也支持密钥删除的公开验证。从表4中可见，本文方案是适用于嵌入式设备的，能够实现预期设计目标。

5　 结 语

针对嵌入式环境下的云数据确定性删除需求，本文提出了基于JavaCard的云数据确定性删除方法。本文方案支持时间和次数这两种密钥使用条件，并且可以将密钥及其使用条件保存在用户本地，节省了通信开销。当密钥使用条件满足时，JavaCard用密钥解密数据，将明文数据返回给应用程序。当密钥使用条件不满足时，JavaCard将安全地删除密钥，并生成可公开验证的密钥删除证据。本文方案充分利用了JavaCard的安全特性来保护密钥及其使用条件，无需额外的安全硬件及软件库的支持。实验和对比分析表明，本文方案性能开销在合理范围内，能够实现预期目的，可以应用于嵌入式设备。

参考文献

[1] 任正伟， 李雪婷， 王丽娜， 等. 云存储中外包数据确定性删除研究综述［J］. 电子学报， 2022， 50（10）： 2542-2560. DOI： 10.12263/DZXB.20220204 .

[2] REN Z W， LI X T， WANG L N， et al. A survey on assured deletion of outsourced data in cloud storage［J］. Acta Electronica Sinica， 2022， 50（10）： 2542-2560. DOI： 10.12263/DZXB.20220204 （Ch ）.

[3] ZHENG D， XUE L， YU C， et al. Toward assured data deletion in cloud storage［J］. IEEE Network， 2020， 34（3）： 101-107. DOI： 10.1109/MNET.011.1900165 .

[4] GEAMBASU R， KOHNO T， LEVY A A， et al. Vanish： Increasing data privacy with self-destructing data［C］//Proceedings of the 18th Conference on USENIX Security Symposium. New York： ACM， 2009： 299-316.

[5] 王丽娜， 任正伟， 余荣威， 等. 一种适于云存储的数据确定性删除方法［J］. 电子学报， 2012， 40（2）： 266-272. DOI： 10.3969/j.issn.0372-2112.2012.02.010 .

[6] WANG L N， REN Z W， YU R W， et al. A data assured deletion approach adapted for cloud storage［J］. Acta Electronica Sinica， 2012， 40（2）： 266-272. DOI： 10.3969/j.issn.0372-2112.2012.02.010 （Ch ）.

[7] XIONG J B， LIU X M， YAO Z Q， et al. A secure data self-destructing scheme in cloud computing［J］. IEEE Transactions on Cloud Computing， 2014， 2（4）： 448-458. DOI： 10.1109/TCC.2014.2372758 .

[8] TANG Y， LEE P P C， LUI J C S， et al. Secure overlay cloud storage with access control and assured deletion［J］. IEEE Transactions on Dependable and Secure Computing， 2012， 9（6）： 903-916. DOI： 10.1109/TDSC.2012.49 .

[9] YU Y， XUE L， LI Y N， et al. Assured data deletion with fine-grained access control for fog-based industrial applications［J］. IEEE Transactions on Industrial Informatics， 2018， 14（10）： 4538-4547. DOI： 10.1109/TII.2018.2841047 .

[10] XUE L， YU Y， LI Y N， et al. Efficient attribute-based encryption with attribute revocation for assured data deletion［J］. Information Sciences， 2019， 479： 640-650. DOI： 10.1016/j.ins.2018.02.015 .

[11] 王丽娜， 任正伟， 董永峰， 等. 云存储中基于可信平台模块的密钥使用次数管理方法［J］. 计算机研究与发展， 2013， 50（8）： 1628-1636.

[12] WANG L N， REN Z W， DONG Y F， et al. A management approach to key-used times based on trusted platform module in cloud storage［J］. Journal of Computer Research and Development， 2013， 50（8）： 1628-1636 （Ch）.

[13] REN Z W， CHEN X S， TANG J S， et al. Limited times of data access based on SGX in cloud storage［C］//2021 IEEE International Conference on Systems， Man， and Cybernetics （SMC）. New York： IEEE Press， 2022： 3146-3151. DOI： 10.1109/SMC52423.2021.9658833 .

[14] REN Z W， LI X， XU S W， et al. Restricting the number of times that data can be accessed in cloud storage using TrustZone［C］//2022 22nd IEEE International Symposium on Cluster， Cloud and Internet Computing（CCGrid）. New York： IEEE Press， 2022： 289-296. DOI： 10.1109/CCGrid54584.2022.00038 .

[15] BETHENCOURT J， SAHAI A， WATERS B. Ciphertext-policy attribute-based encryption［C］//2007 IEEE Symposium on Security and Privacy （SP'07）. New York： IEEE Press， 2007： 321-334. DOI： 10.1109/SP.2007.11 .

[16] Oracle. JavaCard Classic Platform Specification 3.1［EB/OL］. ［2022-08-22］.

[17] KEYKHAIE S， PIERRE S. Mobile match on card active authentication using touchscreen biometric［J］. IEEE Transactions on Consumer Electronics， 2020， 66（4）： 376-385. DOI： 10.1109/TCE.2020.3029955 .

[18] REZAEIGHALEH H， ZOU C C. New secure approach to backup cryptocurrency wallets［C］//2019 IEEE Global Communications Conference （GLOBECOM）. New York： IEEE Press， 2020： 1-6. DOI： 10.1109/GLOBECOM38437.2019.9014007 .

[19] BONEH D， BOYEN X， GOH E J. Hierarchical identity based encryption with constant size ciphertext［C］//Advances in Cryptology―EUROCRYPT 2005（LNCS 3494）. Berlin： Springer， 2005： 440-456. DOI： 10.1007/11426639_26 .

[20] KASAMATSU K， MATSUDA T， EMURA K， et al. Time-specific encryption from forward-secure encryption： Generic and direct constructions［J］. International Journal of Information Security， 2016， 15（5）： 549-571. DOI： 10.1007/s10207-015-0304-y .

[21] HAO F， CLARKE D， ZORZO A F. Deleting secret data with public verifiability［J］. IEEE Transactions on Dependable and Secure Computing， 2016， 13（6）： 617-629. DOI： 10.1109/TDSC.2015.2423684 .

[22] ANKERGÅRD S F J J， DUSHKU E， DRAGONI N. State-of-the-art software-based remote attestation： Opportunities and open issues for Internet of Things［J］. Sensors， 2021， 21（5）： 1598. DOI： 10.3390/s21051598 .

[23] CHEN G X， ZHANG Y Q， LAI T H. OPERA： Open remote attestation for intel’s secure enclaves［C］//Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security. New York： ACM， 2019： 2317-2331. DOI： 10.1145/3319535.3354220 .

[24] 陈钟凯. JavaCard平台下的云数据确定性删除方法研究［D］. 武汉：武汉科技大学， 2023.

[25] CHEN Z K. Research on assured deletion of cloud data under JavaCard platforms［D］. Wuhan： Wuhan University of Science and Technology， 2023 （Ch）.

[26] SHAMIR A. How to share a secret［J］. Communications of the ACM， 1979， 22（11）： 612-613. DOI： 10.1145/359168.359176 .

[27] CHENG Y T， YANG L， YU S， et al. Achieving efficient and verifiable assured deletion for outsourced data based on access right revocation［C］//International Conference on Cryptology and Network Security. Cham： Springer， 2019： 392-411.10.1007/978-3-030-31578-8_8_22. DOI: 10.1007/978-3-030-31578-8_22 .

[28] YANG C S， TAO X L， ZHAO F， et al. Secure data transfer and deletion from counting bloom filter in cloud computing［J］. Chinese Journal of Electronics， 2020， 29（2）： 273-280. DOI： 10.1049/cje.2020.02.015 .

基金资助

国家自然科学基金(61902285)

国家自然科学基金(32061123007)

武汉引力与固体潮国家野外科学观测研究站开放研究基金资助课题(WHYWZ202109)

湖北省自然科学基金(2019CFB099)

中央高校基本科研业务费专项基金(2662022XXYJ004)

应用数学湖北省重点实验室（湖北大学）开放基金(HBAM202101)