1

Deleting Secret Data with Public Veriability

Feng Hao, Member, IEEE, Dylan Clarke, Avelino Francisco Zorzo
Abstract
The problem of secure data erasure has been extensively studied in the past with a rich body of literature available. All existing
software-based solutions can be summarized as following the same one-bit-return protocol: the deletion program performs data
erasure and returns either success or failure. However, such a one-bit-return protocol turns the data deletion system into a black
box the user has to trust the outcome but cannot easily verify it. This is especially problematic when the deletion program is
encapsulated within a Trusted Platform Module (TPM), and the user has no access to the code inside.
In this paper, we initiate a study on how to delete secret data with public veriability. This is a subject that has not been
investigated before, partly because it seems intuitively impossible. In this paper, we show a solution is possible by applying appropriate
cryptographic primitives. Based on combining DHIES, Chaum-Pedersen Zero Knowledge Proof and ECDSA, we present a Secure
Storage and Erasure (SSE) protocol. The key idea in our solution is based on a trust-but-verify paradigm, which is generally
applicable to many security problems but has been largely neglected in the eld of secure data deletion. Finally, we present a
concrete implementation of the SSE system to demonstrate its practical feasibility.
I. INTRODUCTION
Secure data erasure requires permanently deleting digital data from a physical medium such that the data is irrecoverable [14].
This requirement plays a critical role in all practical data management systems, and in satisfying several government regulations
on data protection [25]. For the past two decades, this subject has been extensively studied by researchers in both academia and
industry, resulting in a rich body of literature [5], [7], [8], [14], [15], [17], [23], [25], [26], [28], [31], [33]. A recent survey on
this topic is published in [27] .
A. One-bit return
To delete data securely is a non-trivial problem. It has been generally agreed that no existing software-based solutions can
guarantee the complete removal of data from the storage medium [27]. To explain the context of this eld, we will abstract away
implementation details of existing solutions, and focus at a higher and more intuitive protocol level. Existing deletion methods
can be described using essentially the same protocol, which we call the one-bit-return protocol. In this protocol, the user sends
a command usually through a host computer to delete data from a storage system, and receives a one-bit reply indicating
the status of the operation. The process can be summarized as follows.
User Storage : Delete data
Storage User : Success/Failure (1 bit )
Deletion by unlinking. Take the deletion in the Windows operating system as an example. When the user wishes to delete a
le (say by hitting the delete button), the operating system removes the link of the le from the underlying le system, and
returns one bit to the user: Success or Failure. However, the return of the Success bit can be misleading. Although the link
of the le has been removed, the content of the le remains on the disk. An attacker with a forensic tool can easily recover the
deleted le by scanning the disk [13]. The same problem also applies to the default deletion program bundled in other operating
systems (e.g., Apple and Linux).
Deletion by overwriting. Obviously, merely unlinking the le is not sufcient. In addition, the content of the le should be
overwritten with random data. This has been proposed in several papers [5], [14], [15] and specied in various standards (e.g.,
[18]). However, one inherent limitation with the overwriting methods is that they cannot guarantee the complete removal of data.
As concluded in [14]: it is effectively impossible to sanitize storage locations by simply overwriting them, no matter how many
overwrite passes are made or what data patterns are written. The conclusion was drawn based on studying magnetic drives,
but similar conclusions have been reported to hold for other storage media: e.g., tapes [7], optical disks [15] and ash-based
solid state drives [31]. In all cases, an attacker is able to recover the overwritten data (with some non-negligible probability) by
analyzing the physical remanence in the locations where the data was stored. In conclusion, overwriting using software means
only makes data recovery harder, but it does not change the basic one-bit-return protocol. Same as previously, the return of
Success does not guarantee the actual deletion of data.
Deletion by cryptography. Boneh and Lipton [7] were among the rst in proposing the use of cryptography to address the
secure data erasure problem, with a number of follow-up works [17], [20], [21], [24][26], [33]. In general, a cryptography-based
F. Hao and D. Clarke are with the School of Computing Science, Newcastle University, UK. Email: {Feng.Hao, Dylan.Clarke}@ncl.ac.uk. A.F. Zorzo is
with Pontical Catholic University of RS, Brazil. Email: avelino.zorzo@pucrs.br. The rst author would like to acknowledge the support of EPSRC First Grant
EP/J011541/1 and ERC Starting Grant No. 106591.
2
solution works by encrypting all data before saving it to the disk, and later deleting the data by discarding the decryption key. This
approach is especially desirable when duplicate copies of data are backed up in distributed locations so it becomes impossible
to overwrite every copy [7]. The use of cryptography essentially changes the problem of deleting a large amount of data to that
of deleting a short key (say a 128-bit AES key). Still, the basic question remains: how to securely delete the key?
Several researchers propose to save the key on the disk, alongside the encrypted data (typically as part of the meta data in
the le header) [17], [20], [25], [26]. Deleting the data involves overwriting the disk location where the key is stored. Once the
key is erased, the ciphertext immediately becomes useless [7]. This has the advantage of quickly erasing data since only a small
block of data (16 bytes for AES-128) needs to be overwritten.
However, if the key is saved on the disk, cryptography may not add much security in ensuring data deletion [16]. On the
contrary, it may even degrade security if not handled properly instead of recovering a large amount of overwritten data, the
attacker now just needs to recover a short 128-bit key. This signicantly increases the chance of a total recovery. Once the key
is restored, the deleted data will be fully recovered. (We assume the ciphertext is available to the attacker, which is usually the
case.)
The above example shows that when cryptography is used, key management becomes critically important. Instead of saving
the key on the disk, Wright, Martino and Zadok proposed to use a user-dened password as the encryption key [33]. (The same
solution is also used in TrueCrypt, a widely distributed free disk-encryption program). In this approach, the decryption key is
derived on the y in RAM upon the users entry of the password so it is never saved on the disk. However, passwords are
naturally bounded by low entropy (typically 20-30 bits) [3]. Hence, cryptographic keys derived from passwords are subject to
brute-force attacks. As soon as the attacker has access to ciphertext data, the ciphertext becomes an oracle, against which the
attacker can recover the key through the exhaustive search. Instead of directly using a password-derived encryption key, Lee et
al. proposed to rst generate a random AES key for encrypting data and then use the password to wrap the AES key and store
the wrapped key on the disk [21]. This is essentially equivalent to deriving the key from the password. The wrapped key now
becomes an oracle, against which the attacker can run the exhaustive search.
The standard industry solution is to use a tamper resistant hardware module (e.g., TPM) for key management [3]. Typically,
the key management works as follows. A random key is generated on-board inside the protected memory of the module. To
allow the use of the key, the module provides a set of pre-dened Application Programming Interface (API) commands, which
a legitimate (authenticated and authorized) host program can invoke to perform cryptographic operations.
The use of a tamper resistant module for assured data deletion was suggested earlier by Perlman in 2005 [24]. In her solution,
data is always encrypted before being saved onto the disk. All decryption keys are stored in a tamper resistant module and are
not disclosed outside the module. Erasing the keys will effectively delete the data. To delete a key, the user simply sends a delete
command to the module with a reference to that key and receives a one-bit conrmation if the operation is successful. Clearly,
the deletion process still follows the same one-bit-return protocol as before.
B. Deleting data with public veriability
Black-box system. The biggest problem with the one-bit-return protocol is that it turns a secure data erasure system into a
black box. The system returns one bit at the end of the operation. The user has to trust the outcome, but cannot easily verify
it. Several things may go wrong inside the system: for example, the deletion program may have just unlinked the data from
the le system without overwriting it; the program may have tried to overwrite the disk, but nevertheless have left discernable
physical traces that would allow a forensic expert to recover the deleted data later (e.g., by using microscopic techniques as
demonstrated in [14], [15]); it may have overwritten one copy of the data, but have left other duplicate copies intact (which
may happen in ash-based disk drive where in-place-update is impossible and writing a block usually involves rst copying the
content to a temporary location in memory [20], [21]); the deletion program may contain serious software bugs that render the
erasure process completely ineffective (as reported in [32]). If any of the above occurred, the assurance on the data deletion
would have been lost without the user being aware of it.
There are similar examples of black-box systems in security. For instance, as explained in [19], the Direct Recording Electronic
(DRE) e-voting machines, widely used in the US between 2000 and 2004, worked like a black-box system. The system returns
a tally at the end of the election, which the voters have to trust but cannot easily verify. The lack of veriability had raised
wide-spread suspicion about the integrity of the election, eventually forcing several states in the US to abandon DRE machines.
Today, the importance of having public veriability in any e-voting system has been commonly acknowledged and progress is
being made in deploying veriable e-voting in real-world elections [2], [6].
Unfortunately, the need for public veriability in a secure data erasure system has been almost entirely neglected. Partly, this
is because the concept appears intuitively impossible if using software means can never guarantee the complete deletion of
data, then verifying something impossible does not seem to make sense.
Publicly veriable system. You normally change the problem if you cant solve it. (David Wheeler [11]) Here, we slightly
change the problem by shifting our attention from verifying the secure deletion of data to verifying the failure of that operation.
Insights from research in security economics [3] have taught us that many real-world security systems failed not for technical
reasons, but for a misalignment of incentives. If the party that is in the best position to protect security is not liable for the
3
security failure, it will lack the incentive to invest in improving security. Consequently, the security of the overall system will
suffer and eventually fail.
If we regard the data deletion program as one system, the provider of that system is in the best position to protect security
ensuring that all best practices are followed to properly delete data so that any effort to recover the deleted data will be
prohibitively expensive. However, unless the disk is physically destroyed, absolute guarantee on data deletion is not possible.
Hence, it is necessary to consider the case of security failure. But, with the one-bit-return protocol, it is difcult to pinpoint the
exact liability for the failure. For example, let us assume a user claims that she is able to recover deleted data after the storage
system has deleted it with success. On the other hand, a dishonest user may have made the same claim (the purpose may be to
discredit the system). It is not easy for a third party (say a judge) to distinguish the two cases. The one-bit return is insufcient
to allow making a judgement.
Besides technical considerations, we also need to take into account the business aspects of secure data erasure. In the existing
business model of the data storage market, data storage is regarded as a paid service while data deletion is not. For example, a
user needs to purchase a new disk for storing more data, but she can always choose to delete existing data to free up space so
she does not need to buy more. This model puts strong incentives for the disk manufacturers to invest in improving the reliability
of the storage medium, but little on ensuring the secure deletion of data. A free service naturally comes with no guarantee.
To make the discussion more meaningful, we propose a new business model that regards secure deletion as a paid service
too. We assume there is a niche market, in which users are willing to pay for guaranteed data deletion. We believe this is a
reasonable assumption, given that deleted data often contains condential information and the leakage of such information can
cause a nancial loss. Hence, there is a value in the service that provides the protection of the deleted data. Since the user
pays a premium for secure data deletion, it is reasonable to expect assurance or guarantee in the deletion. If the system had
failed to delete data properly as promised, the user should have the right to demand compensation (e.g., get money back) via an
agreed Service Level Agreement (SLA). Under this new business model, the need for public veriability in secure data deletion
becomes compelling.
Contributions. Our contributions are as follows.
1) we introduce a new concept of securely deleting data with public veriability, and accordingly, propose a Secure Storage
and Erasure (SSE) protocol based on a trust-but-verify paradigm;
2) we introduce a new business model that regards the secure data deletion as a paid service and devise an initial pricing
strategy for this new model;
3) we provide a full open-source implementation of the SSE protocol on a resource-constrained Java card to demonstrate
its practical feasibility (to our knowledge, this is the rst public implementation of DHIES and Chaum-Pedersen Zero
Knowledge Proof on a Java card).
Summary. The main idea of this work can be easily explained in a trust-but-verify paradigm. Following the industry standard
practice, we will employ a TPM for key management. The TPM stores cryptographic keys inside its secure memory and provides
API commands to allow cryptographic use of those keys. However, instead of blindly trusting TPM, our solution allows the user
to verify: 1) if the correct encryption key has been used correctly to encrypt data; 2) if the correct key has been deleted correctly
as instructed. The rst will involve integrating a public-key encryption algorithm (DHIES [1]) with a Zero Knowledge Proof
technique (Chaum-Pedersen [10]). The second will involve using a digital signature scheme (ECDSA) to cryptographically bind
the TPMs commitment of deleting a key to the outcome of that operation. More technical details will follow in Section IV.
Organization. The rest of the paper is organized as follows. Section II reviews related past work on veriable data deletion.
Next, Section IV presents a veriable data deletion system called Secure Storage and Erasure (SSE). Section V shows a prototype
implementation of the proposed SSE system with detailed performance measurements. Section VI presents the system analysis.
Finally, Section VIII concludes the paper.
II. RELATED WORK
In 2010, Paul and Saxena [22] discuss the importance of the user being able to verify the outcome of secure data erasure.
They propose a scheme called the Proof of Erasability (PoE), in which a host program deletes data by overwriting the disk
with random patterns and the disk must return the same patterns as the proof of erasability. Clearly, this so-called proof is not
cryptographically binding, nor publicly veriable, since the data storage system may cheat by echoing the received patterns
without actually overwriting the disk.
In ESORICS10, Perito and Tsudik [23] study how to securely erase memory in an embedded device, as a preparatory step
for updating the rmware in the device. They propose a protocol called Proofs of Secure Erasure (PoSE-s). In this protocol, the
host program sends a string of random patterns to the embedded device. To prove that the memory has been securely erased,
the embedded device should return the same string of patterns. It is assumed that the embedded device has limited memory -
just enough to hold the received random patterns. This protocol works essentially the same way as the PoE in [22], but with an
additional assumption of bounded storage.
Finally, in 2012, Wanson and Wei [32] investigate the effectiveness of the built-in data erasure mechanisms in several
commercial Solid State Drives (SSDs). They discovered that the built-in sanitize methods in several SSD were completely
4
ineffective due to software bugs. Based on this discovery, they stress the importance of being able to independently verify the
data deletion outcome. They propose a verication method that works as follows. First of all, a series of recognizable patterns
are written to the entire drive. Then, the drive is erased by calling the built-in sanitize command. Next, the drive is manually
dismantled and a custom-built probing tool (made by the authors) is used to read raw bits from the memory in search for any
unerased data. This approach can be useful for factory testing. However, it may prove difcult for ordinary users to perform.
In summary, several researchers have recognized the importance of veriability in the secure data deletion process and proposed
some solutions. Our work differs from theirs in that we aim to provide public veriability for a secure data deletion system. In
the following sections, we will explain the technical details.
III. CRYPTOGRAPHIC PRIMITIVES
In this section, we explain two cryptographic primitives that will be used in our protocol.
A. DHIES
The Dife-Hellman Integrated Encryption Scheme (DHIES) is a public key encryption system adapted from the Dife-Hellman
key exchange protocol and has been included into the draft standards of ANSI X9.63 and IEEE P1363a [1]. The scheme is
designed to provide security against chosen ciphertext attacks. It makes use of a nite cyclic group, which for example can be
the same cyclic group used in DSA or ECDSA [29]. Here, we use the ECDSA-like group for illustration. Let E be an underlying
elliptic curve for ECDSA and G be a base point on the curve with the prime order n.
Assume the users private key is v, which is chosen at random from [1, n1]. The corresponding public key is Q
v
= v G. The
encryption in DHIES works as follows. The program rst generates an ephemeral public key Q
u
= u G where u
R
[1, n1].
It then derives a shared secret following the Dife-Hellman protocol: S = u Q
v
. The shared secret is then hashed through a
cryptographic hash function H, and the output is split into two keys: encKey and macKey. First, the encKey key is used to
encrypt a message to obtain encM. Then, the macKey key is used to compute a MAC tag from the encrypted message encM.
The nal ciphertext consists of the ephemeral key Q
u
, the MAC tag and the encrypted message encM. This encryption process
is summarized in Figure 1.
The decryption procedure starts with checking if the ephemeral public key Q
u
is a valid element in the designated group
a step commonly known as public key validation
1
. Next, it derives the same shared secret value following the Dife-Hellman
protocol. Based on the shared secret, a hash function is applied to derive encKey and macKey, according to Figure 1. Upon
the successful validation of the MAC tag by using the macKey, the encrypted message will be decrypted accordingly by using
the encKey. More details about DHIES can be found in [1].
It is worth noting that DHIES is essentially built on the Dife-Hellman key exchange protocol, but with adaptations to make it
suitable for a secure data storage application. For example, Alice can encrypt a message under her own public key using DHIES,
so that only she can decrypt the message at a later time. In some sense, it is like Alice securely communicating with herself in
the future.
For any key exchange protocol, there is always a key conrmation step, which is either implicit or explicit [29]. The original
DHIES scheme is designed to provide only implicit key conrmation the key is implicitly conrmed by checking the MAC
tag. However, there are two drawbacks with this approach. First, it does not distinguish two different failure modes in case the
MAC verication is unsuccessful. In the rst mode, wrong session keys may have been derived from the key exchange process.
For example, the message had been encrypted by a different key v

G, v

= v. In the second mode, the encrypted message

encM may have been corrupted (due to storage errors or malicious tampering). It is sometimes useful for an application to be
able to distinguish the two modes and handle the failure accordingly, but this is not possible in the original DHIES. The second
drawback is performance. In DHIES, the latency for performing implicit key conrmation (through checking MAC) is always
linear to the size of the ciphertext. However, this linear time complexity O(n) can prove unnecessarily inefcient if the MAC
failure was due to the derivation of wrong session keys. (We will explain more on this after we describe the Audit function in
Section IV.)
We address both limitations by adding an explicit key conrmation step to DHIES. This change provides explicit assurance
on the correct derivation of the session keys. It is consistent with the common understanding that in key exchange protocols,
explicit key conrmation is generally considered more desirable than implicit key conrmation [29]. We will explain the modied
DHIES in detail in Section IV.
1
The original DHIES paper [1] does not explicitly mandate public key validation on the ephemeral public key, but as explained by Antipa et al. in [4], the
security proofs in DHIES [1] implicitly assume the received points must be on the valid elliptic curve; otherwise, the scheme may be subject to invalid-curve
attacks. In our specication, we regard such public key validation as a mandatory step.
5
v G
u vG
uG
T
Make
secret value
u
Make
ephemeral PK
H
macKey encKey
E
M
Users
public key
Ephemeral
public key
Secret value
tag encM
Figure 1: Encrypting with DHIES [1]. The symmetric encryption algorithm is denoted as E, the MAC algorithm as T and the
hash function as H. The shaded rectangles constitute the ciphertext.
Prover Verier
s [1, n 1] (A, B) = (s G, s X)

c [1, n 1]
t = s +c r mod n

accept if and only if

t G = A+c R
t X = B +c Z
Figure 2: Chaum-Pedersen protocol [10]: a zero-knowledge proof technique to prove the statement that (G, X, R, Z) = (G, x
G, r G, x r G) is a DDH tuple.
B. Chaum-Pedersen protocol
Assume the same Elliptic Curve setting (E, G, n) as above. Given a tuple (G, X, R, Z) = (G, x G, r G, x r G) where
x, r
R
[1, n 1], the Chaum-Pedersen protocol is an honest verier Zero-Knowledge Proof (ZKP) technique for proving that
the tuple (G, X, R, Z) is a Decisional Dife-Hellman (DDH) tuple [10]. This is equivalent to proving that log
G
X = log
R
Z, or
alternatively, log
G
R = log
X
Z. For the Chaum-Pedersen protocol to work, the prover must know either the r or x value. Without
loss of generality, we assume the prover knows r. The Chaum-Pedersen protocol works interactively between a prover and a
verier in three message ows, as shown in Figure 2. In our solution, we use a non-interactive variant of the Chaum-Pedersen
protocol, which is realized by applying the standard Fiat-Shamir heuristics [12].
IV. SYSTEM DESIGN
In this section, we will propose a Secure Storage and Erasure (SSE) system. As shown in Figure 3, in an architectural view,
the system comprises three components: 1) a tamper resistant hardware module handles key management; 2) a disk drive that
stores digital data; 3) a host program that controls the disk drive and communicates with the module, through a SSE protocol.
In the paper, we will use TPM to refer to the tamper resistant hardware module.
Trust assumptions on TPM. There are often two opposing assumptions about the TPM: either completely trustworthy or
completely untrustworthy. Our assumption lies in between and we call it trust-but-verify. When a TPM is used to handle
sensitive key materials, it is inevitable that it is in a position of being trusted. However, instead of totally (or blindly) trusting
the TPM, we believe it is necessary to at least give users the opportunity to audit the TPM and verify its behavior. One trivial
solution is to check the source code of the TPM software. But this is impossible because of the encapsulated nature of a TPM;
users have no access to the software code. Our solution works by making the TPM produce cryptographic proofs, hence users
verify the software integrity by checking the output of the software instead of its source code. (The underlying idea is in line
with the software independence principle for e-voting by Ron Rivest and John Wack.)
One core functionality of a TPM is to be tamper resistant, so that secrets can be safely kept inside. However, many past
research works have demonstrated that it might be possible to extract secrets from a TPM in various ways, e.g., semi-invasive
attacks, API attacks and side-channel attacks [3]. Hence, it is prudent not to assume the tamper resistance in its absolute term.
Instead, we acknowledge the possibility that a TPM might be reverse-engineered and its secrets extracted. However, we assume
such attacks will incur a high cost. Under this assumption, a TPM is still useful as long as the cost of reverse-engineering is
signicantly higher than the value of the data that the TPM protects.
A. Threat model
In our threat model, we will consider threats from three different angles: the data thief, the TPM provider and the user.
6
Figure 3: Architectural overview of the proposed system
First, the obvious threat concerns a data thief who has captured the entire system (TPM, host and disk) and whose goal is
to recover the deleted data. We assume the attacker is able to not only read all unerased data from the disk but also recover
overwritten bits on the disk. However, since the data is all encrypted, the attacker must have access to the decryption keys, which
are stored in the secure memory of the TPM. We assume the cost of reverse-engineering a TPM is higher than the value of the
data that it protects.
The second type of threat comes from the TPM provider. In general, the TPM provider should have no business incentives to
install malicious rmware in the TPM. However, two possible scenarios need to be considered. First, the rmware may contain
software bugs. Second, the TPM provider might be coerced by a state-funded security agency to add trapdoors in its product
2
.
In our threat model, we assume that the TPM is sold in a mass commercial market, hence any bugs or trapdoors (if any) will
exist in not just one TPM, but all products in the market. In other words, we do not consider targeted attacks against a particular
user.
Third, we consider the threat from a user. A user differs from a data thief in that she is the legitimate possessor of the TPM and
holds the Service Level Agreement. It is expected that the user only saves the encrypted data onto the disk, so that later the data
can be deleted by just erasing the key. However, a mishaving user may deviate from this expectation as follows. In parallel to
saving the encrypted data onto the disk, she also backs up the plaintext data in some secret location. In that case, simply erasing
the key is useless to delete the data. In our model, we do not consider this threat as it trivially breaks all cryptography-based
data deletion methods. Second, a user might try to reverse-engineer the TPM and claim compensation based on the SLA. We
will further analyze this scenario in Section VI after we explain the full protocol in the next section.
B. SSE protocol
The TPM communicates with the host, following a Secure Storage and Erasure (SSE) protocol. This protocol is the central
element in the entire system design. It operates in the same group setting as ECDSA (or DSA). Here, we choose the ECDSA
setting, so it is consistent with the actual implementation of the protocol in a Java Card, as we will explain in Section V. As
before, let E be the underlying elliptic curve of ECDSA and G be a base point on the curve with the prime order n.
Each TPM contains a unique ECDSA signature key pair: Prv
t
and Pub
t
, which are generated on-board during the factory
initialization stage. The ECDSA public key for every TPM is published on the TPM providers website so that anyone can
access it, while the private key is securely kept inside the TPM. As an overview, the SSE protocol species the following API
functions:
KeyGen. To generate a random public/private key pair;
Encrypt. To encrypt data with a specied public key;
Decrypt. To decrypt data with a specied private key;
Audit. To audit if encryption was done correctly;
Delete. To delete a specied private key with a digital signature returned as a proof of deletion.
To call the above functions, the user must be authenticated rst. This can be realized in several ways: for example, passwords,
biometrics, etc. For simplicity, we assume the user has passed the authentication and can call the functions. Details of each API
function are explained below (the notations are summarized in Table I).
1) Key generation: KeyGen(1
k
, C) creates an instance of the client user C. It takes as input a security parameter 1
k
and the
identity of the user C, generates a private key on-board Prv
Ci
:= d
Ci

R
[1, n 1], and returns the corresponding public key
Pub
Ci
:= d
Ci
G and an index reference C
i
to the created key pair. The user C is free to create as many instances as she
wishes, subject to the constraint of the maximum persistent memory in the TPM. As an example, with 160-bit n, 32-bit index
C
i
and a TPM of 16 MB EEPROM memory (see [36]), up to 666,667 user instances can be created. The user may choose to
use different instances for encrypting different types of les. The KeyGen function can be formalized as below (for simplicity,
we will omit the return of error in all functions):
2
This seemingly remote threat becomes realistic in the light of the recent revelations by Edward Snowden [38]. We believe in the post-Snowden world people
will take an even more critical view on TPM, and our trust-but-verify paradigm is one step towards addressing that concern.
7
Notations Meaning
Prvt, Pubt A pair of unique ECDSA keys for each TPM
C The client user
Ci One instance of the client user
Prv
C
i
The private key of the client instance, Prv
C
i
:= d
C
i
Pub
C
i
The public key of the client instance, Pub
C
i
:= d
C
i
G
m An input message
Q The ephemeral public key during DHIES Q = d G
k
enc

, k
mac

The session keys derived from DHIES for authenticated encryption

kc The key-conrmation key derived from DHIES for explicit key conrmation
E
Auth
k
(m) Authenticated encryption of m using the session keys {k
enc

, k
mac

}
E(Pub
C
i
, m) Encryption of m under Pub
C
i
using DHIES, E(Pub
C
i
, m) := {Q, H(kc), E
Auth
k
(m)}
The reference to the ciphertext E(Pub
C
i
, m)
ZKP A Zero Knowledge Proof to prove the well-formedness of ciphertext
SLA
del
C
i
A Service Level Agreement for the deletion of client instance Ci
Sig(...) A signed message using the TPMs ECDSA private key Prvt
Table I: Notations and meaning
Host TPM : 1
k
, C
TPM : Generate Prv
Ci
:= d
Ci
TPM Host : Pub
Ci
:= d
Ci
G, C
i
2) Encryption: Encrypt(C
i
, m) takes as input the reference to the created user instance C
i
, a message m and returns the
encrypted message under the public key Pub
Ci
. For the encryption, we adopt the Dife-Hellman Integrated Encryption Scheme
(DHIES) [1]. First, the TPM generates an ephemeral public key Q

= d

G where d

R
[1, n1]. It then calculates two session
keys, which include an encryption key k
enc

= H(d
Ci
Q

|| 0x01) and a MAC key k

mac

= H(d
Ci
Q

|| 0x10). Both keys are

used to encrypt the message in an authenticated manner to obtain E
Auth
k
(m). In addition, the TPM generates a key-conrmation
key k
c
= H(d
Ci
Q

|| 0x11) and outputs a one-way hash of k

c
. This is to allow explicit key conrmation during the latter
decryption and audit steps. The returned ciphertext will be stored in the mass storage device. The encryption is performed inside
the TPM as it involves securely generating a random factor (i.e., d

), whose secrecy also needs to be protected. It is possible to

perform public key encryption in a host computer, but the standard industry solution is to do that in a tamper resistant device so
that all security-sensitive key materials are protected by the tamper resistance [3]. The Encrypt function can be formalized as:
Host TPM : C
i
, m
TPM Host : Q

:= d

G, H(k
c
), E
Auth
k
(m)
3) Decryption: Decrypt(C
i
, Q

, H(k
c
), E
Auth
k
(m)) takes as input the reference to an existing user instance C
i
, the ciphertext
obtained from the earlier encryption step, and returns the decrypted message if the verications on the key conrmation string and
MAC are successful. The TPM rst validates that Q

is a valid public key on the curve. It then computes k

c
= H(d
Ci
Q

|| 0x11)
and proceeds to decryption only if H(k

c
) = H(k
c
). The decryption procedure follows subsequently as described in DHIES [1].
Upon the successful verication of the MAC tag, the encrypted message will be decrypted and the original plaintext m will be
returned. The Decrypt function can be formalized as:
Host TPM : C
i
, Q

, H(k
c
), E
Auth
k
(m)
TPM Host : m
4) Audit: Audit(C
i
, Q

, H(k
c
)) takes as input the reference to an existing user instance C
i
, the ephemeral public key Q

and
the key conrmation string H(k
c
), and allows the user to verify whether the earlier encryption operation was done correctly.
The TPM rst checks that Q

is a valid public key on the curve, and veries if H(H(d

Ci
Q

|| 0x11)) = H(k
c
). It then outputs
d
Ci
Q

and a Zero Knowledge Proof (ZKP), which proves that log

G
d
Ci
G = log
Q
d
Ci
Q

without leaking anything about

the private key d
Ci
. The ZKP is based on the Chaum-Pedersen protocol [10], which is made non-interactive by applying the
Fiat-Shamir heuristics [12]. Because of the use of a key-conrmation string, it is unnecessary to feed in the entire encrypted
message (i.e., E
Auth
k
(m)) into the audit function input. This improves the efciency as the size of the encrypted message may
potentially be large. With the output from the audit function, the host is able to compute the encryption and MAC keys based
on k
enc

= H(d
Ci
Q

|| 0x01) and k
mac

= H(d
Ci
Q

|| 0x10). With these symmetric keys, the host is able to fully verify if
the message was encrypted correctly using these keys. Note that this auditing only reveals the symmetric encryption and MAC
keys within one DHIES session; the secrecy of the keys derived in other sessions is not affected. The Audit function can be
formalized as:
8
Host TPM : C
i
, Q

, H(k
c
)
TPM Host : d
Ci
Q

, . . .
ZKP

[log
G
d
Ci
G = log
Q
d
Ci
Q

]
5) Delete: Delete(C
i
) deletes a user instance C
i
by overwriting its private key d
Ci
in the TPMs protected memory and
returns artifact
del
Ci
, which is a Service Level Agreement {Delete, Pub
Ci
} signed by the TPMs ECDSA signing key. After
the erasure of the private key, all messages encrypted under Pub
Ci
can no longer be decrypted. Assume the TPM had failed
to erase the private key d
Ci
properly and that the key is later discovered by the user. The user can present d
Ci
together with
SLA
del
Ci
, as publicly veriable evidence, that the TPM had failed to provide the secure data deletion service as promised. Based
on the evidence and the terms in the Service Level Agreement, the user should be entitled to compensation. We will discuss the
amount of compensation and the pricing strategy in further detail in Section VI. The Delete function can be formalized as:
Host TPM : C
i
TPM Host : SLA
del
Ci
:= Sig(Delete, Pub
Ci
)
V. IMPLEMENTATION
In this section, we will describe a full prototype implementation of the proposed SSE system, based on using a standard Java
card [37] as a TPM for key management, a MacBook laptop (1.7 GHz with 4 GB memory) for the host and a standard disk
drive for mass data storage. As we will show, this is a non-trivial development effort. To our knowledge, what we provide is the
rst public implementation of DHIES and Chaum-Pedersen ZKP on a resource constrained Java card. (The full source code for
the prototype can be found at the end of the paper.)
The Java card we use has a dual interface, supporting both contact and contactless communication. We use the contactless
interface for all experiments. The chip on the card has an 80 KB EEPROM for persistent storage and an 8 KB RAM for holding
volatile data in memory. The card is compliant with Java Card Standard 2.2.2, but also supports some additional APIs from Java
Card Standard 3.0.1. In particular, it supports ALG_EC_SVDP_DHC_PLAIN under the javacard.security.KeyAgreement interface,
which allows obtaining the plain shared secret (instead of a SHA-1 hash of the secret) from the Elliptic Curve Dife-Hellman
(ECDH) key exchange protocol. This API is essential for the prototype implementation of our system.
One obstacle we encountered is that the existing Java card API standards does not support modular multiplication of big
numbers (see [30], [37]). To the best of our knowledge, no Java Cards currently available in the market provide the API support
to perform this basic modular operation. Therefore, we had to implement the big number modular multiplication from scratch by
ourselves using the primitive arithmetic operators and byte arrays (without involving any hardware support from the low-level
native C library on the card). It takes about 150 lines of Java code to execute one modular multiplication.
Regarding the elliptic curve setting, we chose the standard P-256 curve as dened in the Digital Signature Standards
specication [35]. When the Java card applet is rst loaded into the chip, upon initialization it generates a random ECDSA
key pair over the P-256 curve. The same curve is used for the generation of all further public/private key pairs required.
In the following, we will explain the implementation details and performance measurements of all the functions specied
in the SSE protocol. For each function, the latency is measured in terms of the delay in the card processing and in the card
communication (via the contactless interface). We repeated the experiments thirty times and summarize the average results in
Figure 4 and Table II.
KeyGen. This function involves generating a random public/private key pair over the P-256 curve for a new user instance.
The public key, along with a 16-bit unique identier, is returned to the user. The private key (32 bytes) is stored in the TPMs
EEPROM. To facilitate the encryption operation later, we also keep the public key in EEPROM. The card only supports the EC
public key in the uncompressed form, so the size of the public key is 64 bytes. Given that the Java card that we use has 80
KB EEPROM in total and that the SSE program takes up 16 KB storage in EEPROM, we can create about 650 random EC
public/private pairs. As shown in Table II, this operation takes a constant 835 ms in total.
Encrypt. The function receives a plaintext le, encrypts it using DHIES and returns the ciphertext. In one DHIES session,
two symmetric session keys are derived to encrypt the le in an authenticated manner (see Figure 1). In theory, there should be
no limit in how long is the input le that can be encrypted under one DHIES session. However, in practice, there is an upper
limit due to the constrained memory size in the Java card. (The reason shall become more evident later when we explain how
the Decrypt operation works.) In our implementation, up to 2 KB data can be encrypted in one DHIES session. For a plaintext
le bigger than 2 KB, the host program needs to divide the le into block with each less than 2 KB and encrypt each block in
one DHIES session.
Another constraint in the implementation is the size of the APDU buffer. The card receives and sends messages through
an APDU buffer, which can hold data up to 255 bytes at one time. Therefore, for a long message, the encryption cannot be
done in one operation, and needs to be done in four steps. First, the card receives an instance ID that identies the public key.
Accordingly, it creates an ephemeral public key, and computes the DHIES session keys. The session keys comprise a 128-bit
AES key for encrypting data and another 128-bit AES key for computing MAC. The encryption is performed in the CBC mode.
9
512 1024 1536 2048 2560 3072 3584 4096 4608 5120 5632 6144
0
2000
4000
6000
8000
10000
12000
Latency measurements for encryption
Size of the input plaintext file (bytes)
L
a
t
e
n
c
y

(
m
s
)


Card processing
Communication delay
(a) Performance of Encrypt
512 1024 1536 2048 2560 3072 3584 4096 4608 5120 5632 6144
0
2000
4000
6000
8000
10000
12000
Latency measurements for decryption
Size of the input ciphertext file (bytes)
L
a
t
e
n
c
y

(
m
s
)


Card processing
Communication delay
(b) Performance of Decrypt
Figure 4: Performance evaluation based on a proof-of-concept implementation using a resource-constrained Java card (5 MHz
processor). The same implementation should work several hundred times faster on a high-performance Tamper Resistant Module
such as IBM Storage Manager HSM (2 GHz processor) [41].
Algorithm 1 Encryption in one DHIES session
Input: User instance reference C
i
, message m, elliptic curve E with generator G of order n, secure hash function H;
Output: Ephemeral public key Q

, hashed key conrmation key H(k

c
), encrypted message E
Auth
k
(m); initialisation vector IV ;
1: Client sends C
i
to card;
2: Card retrieves instance private key d
Ci
corresponding to user instance C
i
;
3: Card randomly chooses d

[1, . . . n];
4: Card sets Q

= d

.G;
5: Card sets k
enc

= H(d
Ci
.Q

0x01);
6: Card sets k
mac

= H(d
Ci
.Q

0x10);
7: Card generates random IV and returns this to the client;
8: Client divides m into segments m
i
with each segment not more than 255 bytes;
9: for segments m
i
do
10: Client sends m
i
to card;
11: Card generates E
k
(m
i
) using AES-CBC with key k
enc

;
12: Card generates MAC
i
for E
k
(m
i
) using AES-CBC with key k
mac

and with initialisation vector set to ZERO when i = 0

and MAC
i1
when i>0;
13: Card obtains the nal MAC with the entire encrypted message to give E
Auth
k
(m);
14: Card sets k
c
= H(d
Ci
.Q

0x11);
15: Card returns to the client Q

, H(k
c
), E
Auth
k
(m);
A random IV for AES-CBC is generated and returned to the host in this step (this to optimize the bandwidth usage so that in the
subsequent step, the plaintext data can ll up the entire APDU buffer and the returned ciphertext will occupy the whole buffer as
well). Second, the message is divided into segments with each segment not more than 255 bytes. The card receives each segment
in turn, performs encryption and saves the intermediate results in RAM. This step is repeated until the penultimate segment of
the message. Third, it receives the last segment of the message and nalizes the encryption. Fourth, a MAC is returned, which is
computed over the entire ciphertext using CBC-MAC. Full implementation details about the DHIES encryption are summarized
in Algorithm 1
The latency measurements for the encryption operation are shown in Figure 4a. For each input le of different sizes, the
Encrypt operation is invoked to encrypt the le and return the ciphertext. The measured total latency includes both the card
processing and card communication delays. In order to obtain the communication delay, we conduct a separate experiment. We
add a dummy API to the card, which works supercially similar to Encrypt in that it accepts an input le and returns an output
le that has the same size as what the Encrypt API would return. However, the dummy API does not perform any processing
on the input data and it immediately outputs a xed data string that is stored in the card memory back to the host. We measure
10
Algorithm 2 Decryption in one DHIES session
Input: User instance reference C
i
, ephemeral public key Q

, hashed key conrmation key H(k

c
), encrypted message E
Auth
k
(m),
elliptic curve E with generator G of order n, secure hash function H, initialisation vector IV ;
Output: Message m or failure notication;
1: Client sends C
i
, Q

, H(k
c
), IV to card;
2: Card retrieves the instance private key d
Ci
corresponding to user instance C
i
;
3: Card validates Q

is a point on E of correct order;

4: Card sets k

c
= H(d
Ci
.Q

0x11);
5: if H(k

c
) = H(k
c
) then
6: Card Sets k
enc

= H(d
Ci
.Q

0x01);
7: Card sets k
mac

= H(d
Ci
.Q

0x10);
8: Client divides E
Auth
k
(m) into segments M
i
9: for segments M
i
do
10: Client sends M
i
to card;
11: Card sets m
i
to be the decryption of M
i
using AES-CBC and key k
enc

and IV ;
12: Card generates a MAC
i
for M
i
using key k
mac

with initialisation vector set to ZERO when i = 0 and MAC

i1
when
i>0;
13: Card veries that the nal MAC generated equals the MAC included with E
Auth
k
(m);
14: if MAC verication succeeds then
15: Card returns all m
i
to client;
16: else
17: Card returns failure notication to client;
18: else
19: Card returns failure notication to client;
the latency of calling the dummy API and take that measurement as the communication delay. The card processing delay is
obtained by subtracting the communication delay from the total latency.
As shown in Figure 4a, the card processing delay in the Encrypt operation increases with the size of the input in a step-wise
manner. This is because we limit the maximum allowed plaintext data that can be encrypted within one DHIES session to be
2 KB. Hence, for the input size of less than 2 KB, the card processing cost is predominantly determined by the public key
operations in DHIES to derive the session keys. The cost of the subsequent symmetric operations using the session keys is almost
negligible in comparison to asymmetric operations. For the input size of between 2 KB and 4 KB, the card processing cost is
almost doubled because the encryption involves two DHIES sessions.
Decrypt. As previously, due to the limited size of the APDU buffer, the ciphertext has to be divided into segments, with each
segment not more than 255 bytes. In the implementation, this operation has ve steps. First, the card receives the instance ID,
the ephemeral public key, the key conrmation string and the IV (for AES-CBC decryption). After it successfully veries the
key conrmation string, the card computes a 128-bit AES encryption key and another 128-bit AES MAC key. Second, it receives
each ciphertext segment in sequence, decrypts each segment using the AES encryption key derived in step one and stores the
decrypted result in RAM. Meanwhile, it computes a MAC for the received ciphertext using AES-CBC. This step is repeated until
receiving the penultimate segment of the ciphertext. (The computed MAC becomes the IV input for computing the next MAC
using AES-CBC.) Third, it receives the last segment of the ciphertext. It decrypts the segment accordingly, saves the decrypted
data to an array in RAM, and also computes the nal MAC. Fourth, it receives a MAC. It checks it against the MAC that
was derived in the previous step. Fifth, it returns the decrypted plaintext if the MAC was veried successfully in the previous
step. The last step is called repeatedly until all plaintext data is returned. All the intermediate results during the cryptographic
operations are stored in the volatile RAM. (Writing data into EEPROM is much slower, and is subject to a limited number of
writing cycles, while writing data in RAM is fast and incurs no limit in the number of overwriting operations.) The decryption
process is summarized in Algorithm 2.
Since the card only returns the plaintext upon successful verication of the MAC value, the maximum allowed size of the
ciphertext is determined by the available RAM in the card. In the Java card that we use, the chip has 8 KB RAM, more than
half of which is used to run the instance of the program. Through experiment, we found that the maximum data that the card
can accommodate in RAM is 2 KB.
As shown in Figure 4b, the latency of the decryption increases with the size of the ciphertext le in a similar step-wise
manner as in the encryption. As compared with the encryption that involves two scalar multiplications over the elliptic curve, the
decryption only requires one. Hence, the latency of card processing in decryption (Figure 4b) is about half of that in encryption
(Figure 4a). The latency of card communication remains the roughly same in both cases. For an input ciphertext le of 1 KB,
11
Operations Card processing Communication Total latency
KeyGen 782 53 835
Audit 10594 165 10759
Deletion 674 56 730
Table II: Latency measurements (ms)
the decryption takes about 2 seconds in total (0.5 seconds on the card processing).
Audit. This function requires the card to prove that the two session keys in an earlier Encrypt operation had been derived
correctly following the DHIES specication. The main part in the implementation is in computing a Zero Knowledge Proof
to prove the equality of two discrete logarithms. The implementation needs two primitive functions. The rst is to compute
the scalar multiplication over the Elliptic Curve and the second is to compute a modular multiplication of two big numbers
(32-byte modulus). Although the Java Card Standard 2.2.2 [37] does not provide any direct API to allow computing the scalar
multiplication over the EC, it is possible to (ab)use the ECDH API as follows. First, the ECDH API is initialized with a pair of
public/private keys, where the private key is the scalar. Upon receiving an ephemeral public key, the ECDH API does a scalar
multiplication over the elliptic curve and returns the ECDH shared secret in the plain form. However, instead of returning a point,
the API only returns the x coordinate (more specically, the x coordinate of B = s X in the rst ow of the Chaum-Pedersen
protocol; see Figure 2.) Hence, the host has to reconstruct the point by calculating the y coordinate from one of the two possible
values. Once the whole point is reconstructed, the Zero Knowledge Proof can be veried accordingly. The limitation in the card
API reduces the security level of the ZKP by exactly one bit, because it halves the search space of an exhaustive search attack.
As shown in Table II, the audit function causes 10, 594 ms delay in the card processing. The most signicant cost factor is
in doing the modular multiplication (i.e., computing t = s + c r mod n in the last step of the Chaum-Pedersen protocol; see
Figure 2). It takes 9, 094 ms. This seemingly trivial calculation incurs a long delay because there is no available API in the Java
card to do this operation efciently and we had to implement it from scratch in pure software without any hardware support.
We have tried our best to optimize the code and also compared with alternative methods (e.g., do a modular multiplication by
abusing the RSA encryption API as described in [30]). It seems that the 9.094 seconds delay is probably best we could achieve
without getting any hardware support from the card cryptographic co-processor
3
. It is worth noting that the latency in audit is
a constant value. This is attributed to the use of explicit key conrmation; otherwise, with the original DHIES, we will have to
feed in the entire encrypted message and the latency for auditing will have a linear time complexity O(n).
Delete. Upon receiving an index to the user instance, this function erases the private key for the specied user instance, by
calling the clearKey method of the javacard.security.key interface. This follows the recommendation from the Java Card API
Standard (2.2.2) that a key should be cryptographically destroyed through the clearKey method [37]. After the private key is
erased, the function returns an ECDSA signature as specied in the SSE protocol. This delete operation takes about 730 ms
delay in total (see Table II).
VI. ANALYSIS
In this section, we analyze the security of the proposed system, including the API security, the threat analysis and the pricing
strategy that denes the amount of compensation.
A. API security
In the SSE protocol, we have dened ve API functions. The KeyGen function simply generates keys on-board. The Encrypt
and Decrypt functions follow the widely standardized DHIES, which has been proven secure against chosen-ciphertext attacks
[1]. We propose to add a key-conrmation string to DHIES in order to provide explicit key conrmation, while the original
DHIES only provides implicit key conrmation. The key-conrmation key is derived separately from the encryption and MAC
keys. This is to ensure that the encryption and MAC keys remain indistinguishable from random after the key conrmation
step. Thus, the security proofs in DHIES [1] are not affected. The use of explicit key conrmation allows a more efcient
implementation of the audit function. In the Delete function, we use the well-established ECDSA to cryptographically bind the
TPMs commitment to delete a secret key with the outcome of the deletion operation. We refer the reader to [1] and [35] for
the security of DHIES and ECDSA respectively. Here, we will focus on the Audit function.
The Audit function serves as an enhancement to DHIES. The aim is to allow users to verify if the encryption had been
correctly implemented following the DHIES specication. To analyze the security of this function, we will consider two types
of attackers: a passive attacker and an active attacker. We dene a passive attacker as one who obtains the ciphertext only by
calling the Encrypt function and subsequently feeds the obtained ciphertext into the Audit function. This is analogous to passively
3
We contacted several Java card vendors and were glad to learn from one vendor that adding native support for modular multiplication was in their development
plan for future products.
12
monitoring all inputs and outputs while the user performs the Encrypt and Audit operations. We dene an active attacker as one
who constructs his own ciphertext and then feeds it into the Audit function.
Passive attack. First, we consider a passive attacker and make the following claim with a sketch of its proof.
Claim 1. Under the assumption that the underlying Chaum-Pedersen ZKP is secure, the output of the audit function does not
reveal any information about the private key d
Ci
to a passive attacker.
Proof: In the case of a passive attack, the input ciphertext will be successfully veried by the TPM since it was generated
by the same TPM earlier. Given the input {d

G, H(k
c
)}, the audit function returns {d
Ci
d

G, ZKP

}. The ZKP

reveals
nothing more than one bit information about the truth of the statement: the tuple {G, d
Ci
G, d

G, d
Ci
d

G} is a DDH tuple
4
(see [10]). We assume that the audit function is called of an unlimited number of times. The passive attacker records every input
and output, and eventually builds up a transcript of all possible tuples, each comprising {d

G, d
Ci
d

G} (recall that d

is
dynamic and d
Ci
is static.). However, he can simulate the same transcript by generating the random values d

by himself and
computing d

d
Ci
G accordingly. In conclusion, he learns nothing about d
Ci
from the transcript that he can simulate all by
himself .
Active attack. Second, we consider an active attacker and make the following claim with a sketch of its proof.
Claim 2. Under the assumption that the Computational Dife-Hellman (CDH) problem in the designated group is intractable,
and given that the ciphertext input, supplied by an active attacker, has passed the internal verication in the TPM, the input
must have been generated with the knowledge of the ephemeral private key d

.
Proof: Assume the attacker has calculated the input to the audit function on his own, which includes {d

G, H(k
c
)}. To
obtain a contradiction, we assume the attacker does not know d

. Given the successful public key validation on d

G, it shows
that d

G is a valid public key in the designated group over the elliptic curve, so the discrete logarithm (i.e., the private key) with
respect to the base point G must exist. In other words, the value d

actually exists. Given the successful verication on the key

conrmation, this gives the TPM explicit assurance that the supplier of the input must have obtained the same key-conrmation
key k
c
, which is derived from the ECDH shared plain secret through a one-way hash function: k
c
= H(d
Ci
d

G||0x11).
Hence, the attacker must have obtained the same ECDH shared plain secret. In summary, without knowing d
Ci
or d

, the attacker
has computed d
Ci
d

G from {d
Ci
G, d

G}. This contradicts the CDH assumption as stated in the claim. In conclusion, the
active attacker must have known d

when computing his own input to the audit function.

Obviously, if the attacker knows d

, he will learn nothing from the Audit function as he is able to compute the DDH tuple
{G, d

G, d
Ci
G, d
Ci
d

G} all by himself.
B. Threat analysis
In the threat model dened in Section IV, we have highlighted threats from three different angles. We now analyze those
threats in detail.
1) Data thief: We assume the attacker has physically captured the TPM and the disk. Clearly, the attacker cannot make use
of the TPM without passing the authentication mechanism. We further assume that the attacker has had the users authentication
credential, so he can invoke all API functions of the TPM. Obviously, if the keys have not been deleted, the attacker will be
able to trivially decrypt the ciphertext stored on the disk. This is unstoppable as the attacker is essentially no different from a
legitimate user from the systems perspective. The basic design goal of the SSE system is to prevent the attacker from recovering
deleted data. Hence, before the system falls into the enemy hands, we assume that the user erases keys by calling the Delete
function, or in the extreme case, physically destroying the TPM chip. The latter guarantees the complete erasure of the keys,
but in our analysis we will focus on non-destructive means to delete data.
If the Delete function has been implemented correctly, the key should have been erased and its location in memory be
overwritten with random data. This can prove extremely costly for the attacker to recover the deleted key; without the key, the
attacker will have to do a ciphertext-only attack against DHIES, which has been proved infeasible [1].
In order to recover the deleted key, the attacker has to penetrate two layers of defence. First, he needs to bypass the physical
tamper resistance, so he can gain access to the protected memory in the TPM. Second, he needs to recover the overwritten bits
in the memory cells where the key was stored before the deletion. Compromising both layers is not impossible, but will incur
a high cost to the attacker. This will be an arms race between defenders and attackers, but if the cost to attack is signicantly
higher than the value of the target data, the thief may be deterred.
2) TPM provider: As explained above, if the TPM has i) encrypted data correctly based on the DHIES algorithm, and ii) also
erased keys properly from the protected memory, it can prove prohibitively expensive for a data thief to recover the deleted data.
However, we shall not take it for granted that the TPM provider must have implemented both operations correctly. Software bugs
are one concern. We should also be wary of the possibility that the TPM provider might be coerced by a powerful state-funded
adversary to insert a trapdoor into the products.
4
Since the non-interactive ZKP is obtained by applying the Fiat-Shamir heuristics, a random oracle model is assumed.
13
E
k
( compress(m) ) E
k
( k )
E
k
( m ) Ciphertext 1
Ciphertext 2
Figure 5: Ciphertext 1 is produced by an honest TPM while ciphertext 2 is by a dishonest TPM. k is an encryption key and k

is a trapdoor key (known to a state-funded security agency). Given that the encryption algorithm is semantically secure, users
cannot distinguish the two ciphertexts.
Trust-but-verify. Instead of completely trusting the TPM, we adopt a trust-but-verify approach. More specically, this trust-
but-verify is reected in the design of the SSE protocol in two aspects: veriable encryption and veriable deletion.
Veriable encryption. First, the encryption should be veriable. The SSE protocol allows the user to verify if the encryption
has been implemented correctly following the DHIES specication. This verication is critical, because if the encryption had
not been done correctly in the rst place, then deleting the key will not logically lead to the deletion of data. In past work,
such verication is usually done implicitly the fact that the software program can reverse the encryption process and recover
the same original plaintext gives implicit assurance that the encryption was done correctly. This kind of implicit verication is
widely used in software testing to ensure the encryption and decryption are implemented correctly.
In a security-critical application, this kind of implicit assurance is insufcient, especially when the software program is
encapsulated within a tamper resistant device and its source code is totally inaccessible. We provide one possible attack in Figure
5. Since the plaintext data normally contain redundancies, the TPM can compress the data rst before doing encryption. The
compression will create spare space to insert a trapdoor block, which is the decryption key wrapped by a trapdoor key (known
to a state-funded security agency). Given that the ciphertext length remains the same and the encryption cipher is semantically
secure (i.e., the output of the encryption is indistinguishable from random), users cannot distinguish the two ciphertexts in
Figure 5. During the decryption, the TPM can simply ignore the trapdoor block and decrypt data as normal. This attack may
be mitigated by always requiring the data compression rst before encryption. However, a powerful state-funded adversary may
know a compression algorithm that is more efcient than the publicly known ones. A slight advantage in the compression ratio
would prove sufcient to insert a few extra bytes as the trapdoor. We assume the attackers goal to enable mass surveillance
over the Internet once the ciphertext is sent over the Internet (say to a remote storage server), the attacker is able to trivially
decrypt data without anyone being aware of it.
Our solution to the above problem is through the audit function. One trivial way to allow auditing the encryption is to reveal
the user instances private key d
Ci
. But the private key d
Ci
may have been used in many DHIES sessions (each session is an
invocation of the Audit function). The auditing should be limited to one specic session, but the revelation of d
Ci
will affect
the secrecy of all other sessions. This reveals too much information.
Another solution is to reveal the random factor d

used in one DHIES session. With d

, the two session keys can be derived

and every byte in the ciphertext can be fully veried accordingly. This does not affect the secrecy of other sessions (since the
random factors are all different). However, the random factor d

is only transient in memory during the encryption process and

is immediately erased once the encryption is nished.
The technique we propose has the same effect as revealing the random factor d

, but without having to know d

. First of
all, the TPM reveals the plain ECDH shared secret: S = d
Ci
d

G, which can be easily computed since the TPM knows the

user private key d
Ci
. With this revealed secret S, the two session keys can be derived and every byte in the ciphertext can be
veried accordingly. However, in addition to revealing S, the TPM must demonstrate that S is well-formed. In other words, if
we dene the tuple {G, C, N, S} = {G, d
Ci
G, d

G, d
Ci
d

G}, the revealed S will make the tuple form a valid DDH tuple.
This is equivalent to proving either of the following two statements: 1) log
G
C = log
N
S; or 2) log
G
N = log
C
S. The choice
of the statement depends on whether the prover knows either d
Ci
or d

. In our case, the TPM does not have d

, but it knows
d
Ci
, hence is able to compute the ZKP based on the Chaum-Pedersen protocol.
Veriable deletion. As we explained earlier, the deletion operation should return a proof (ECDSA signature) that cryptograph-
ically binds the commitment in deleting a secret key with the outcome of that operation. If the TPM has failed to erase the key
correctly, the digital signature will serve as publicly veriable evidence to indicate the security failure. Based on the evidence
and the terms in the Service Level Agreement, the user should be entitled for compensation.
Traditionally, when one (say a researcher) wants to demonstrate a security failure (or vulnerability) of a TPM, he would need
to write a technical article, post a video or do a live demo. Our protocol makes this exposure process easier and more directly:
just publishing a short string of data (an ECDSA signature and the recovered key) on the internet. Anyone will be able to verify
the digital signature and conrm the evidence of security failure.
C. User
We consider a user who is a legitimate owner of a SSE system. However, the user might want to prot from claiming for
compensation. To claim compensation, the user will need to present an ECDSA signature together with the private key d
Ci
that
14
is supposed to have been deleted.
In one attack, the user can do as a data thief would do: 1) compromising the tamper resistance to gain access to the TPMs
protected memory; 2) recovering the overwritten key value in the protected memory in the TPM.
However, instead of penetrating two layers of defence, the user actually just needs to compromise one layer. Once she is able
to gain access to the protected memory, she can extract an existing private key d
Ci
in memory and call the delete function to
erase this key in order to obtain an ECDSA signature. Equivalently, she can extract the ECDSA private key and generate her
own ECDSA signature. The evidence itself does not tell if the security failure is due to the compromise of the ECDSA signing
key or due to the recovery of the allegedly deleted private key. But both keys should have been kept in the secure memory of
the TPM. Hence, in any case, it should become publicly clear that the claimed tamper resistance has been compromised. As
compared to a data thief, a user exploits a short-cut in the attack as she does not need to go further to recover the overwritten
bits in the memory. This needs to be considered in the pricing strategy on determining the compensation amount, which we
discuss in the next section.
VII. PRICING STRATEGY
In the proposed new business model, the user pays a premium for the secure data deletion service. According to the Service
Level Agreement, the solution provider is obliged to provide the promised security or to pay a penalty for the failure. In
WEIS10, Cezar, Cavusoglu and Raghunathan have discussed contracting issues in the information security market [9], hence
the idea of imposing contractual penalty for the security failure is not wholly new. (As a practical example, the IBMs Service
Level Agreement offers Money-Back Payment: i.e., providing US$50,000 to the client rm for any security breach listed in the
contract. [9]) However, to our knowledge, in the eld of secure data storage, we are the rst to propose to treat secure data
deletion as a paid service. No one has discussed the contractual penalty for the information leakage in the data deletion before.
In the following, we will attempt to provide the initial investigation into this subject.
In the SSE protocol, the evidence of security failure is designed to be publicly veriable. Hence, if the user shows evidence
to prove that the TPM has failed to provide the promised security, she should be entitled to compensation. Depending on the
details in the Service Level Agreement, the compensation may be the same as the product price (i.e., get money back) or a
variable amount of indemnity. To make it general, we assume the amount of compensation is N.
We begin by taking C
1
to be the cost of breaking the tamper resistance of the TPM (i.e., so as to extract the ECDSA signing
key) and C
2
to be the cost of recovering an overwritten key from the secure memory. Hence, the overall cost to recover a deleted
key from the TPM is: C = C
1
+C
2
. We denote P as the selling price of that TPM, and N is the amount of compensation. As
long as N P +C
1
, then a user will not be able to make a prot by reverse engineering a TPM. (Note that we use C
1
instead
of C because of the short-cut in the attack, as explained in the previous section.)
Let us denote T as the cost of producing the TPM. To make the TPM more tamper-resistant will usually increase the cost
of the TPM. A TPM vendor may choose to cut corners and produce TPMs that are inexpensive but not very tamper resistant.
When P T > N, the TPM vendor will be able to unfairly prot by simply producing cheap but weak TPMs and attempt to
sell a large amount of them before this insecurity is discovered. Then, when the insecurity is discovered, the vendor can pay
compensation to every user, making a prot of P T N for each TPM. Hence, the amount for compensation should be within
the following (rough) range:
P T N P +C
1
(1)
The key observation from the above equation is that the range for the amount of compensation largely depends on C
1
, which
is the cost to break tamper resistance. Take the Java card as an example. A Java card typically sells at a price between $5 and
$15 [39]. The manufacturing cost T is xed. But the exact cost of C
1
is difcult to estimate as it may vary greatly from a few
hundred to a few million dollars [3]. To a large extent, it reects the core technology in the design and manufacturing of the
TPM chip. Within this broad price range (see Equation 1), we expect a reasonable amount of compensation would be N = P.
This falls within the range in eq. 1 and also ts the common expectation that if a product is found faulty (or below the promised
quality standard), the customer should have the right to at least ask the money back.
It is worth noting that the above analysis is an initial attempt to dene a pricing strategy for a new business model. The
estimated pricing range is only approximate. For example, we have not taken into account the cost of the company losing
reputation when its security product is found awed. In future research, we plan to work on a more rened model.
VIII. CONCLUSION
In this paper, we investigate how to make a black-box data deletion system more transparent and veriable. Current cryptography-
based solutions universally work by rst using a cryptographic key to encrypt data and later deleting the data through discarding
the key. However, we identify two problems in this approach. First, existing schemes commonly assume that the encryption must
have been done correctly, but that assumption can be easily challenged when the encryption is done within a TPM. Second, in
all schemes, only one bit is returned from the deletion operation without any proof of liability (in case anything goes wrong),
15
thus the user is expected to just trust the one-bit outcome. The rst problem is particularly important if data is not encrypted
correctly in the rst place (say left with a covert trapdoor in the ciphertext), then discarding the key is meaningless in deleting
the data.
We aim to address the above two problems in a systematic approach. Our work includes both theoretical and practical
contributions, which are summarised below.
We introduced a trust-but-verify paradigm, based on which we designed a Secure Storage and Erasure (SSE) protocol.
To this end, we modied the DHIES scheme by adding explicit key conrmation. Our modication improves the message
size complexity from O(n) to O(1) in the auditing process. Furthermore, we enhanced the security of DHIES by adding
an audit function based on Chaum-Pedersens ZKP. The result is a veriable public key encryption primitive, which can
prove generally useful. Finally, we applied a digital signature scheme to cryptographically bind the TPMs commitment to
delete a key to the outcome of this operation. This serves to provide publicly veriable evidence in case the TPM failed
to delete the key properly.
We proposed a new business model that recognizes the secure data deletion as a paid service. Furthermore, we provided
an initial pricing strategy for the new business model.
We provided the rst public implementation of DHIES and Chaum-Pedersen ZKP on a Java card after overcoming several
obstacles due to the extremely constrained resource on the card. The Java card and the host programs for the SSE prototype
are released as open source code. With a physical Java card ($5-15), a user can build her own SSE system without any
extra cost. The user may carry the card with her and use it to encrypt/decrypt data on the y (e.g., encrypting all data
before sending them to the cloud).
Future work includes extending the trust-but-verify paradigm to other crypto primitives, in particular, the secure random
number generator. The problem of permitting end users to audit if a random number has been generated correctly in a TPM as
part of the encryption process (or a cryptographic protocol) is still largely unsolved and deserves further research.
SOURCE CODE
The source code for the Java card and host programs is publicly available at: https://github.com/SecurityResearcher/SSE). Java
cards can be purchased from various sources, e.g., [39], [40].
REFERENCES
[1] M. Abdalla, M. Bellare and P. Rogaway, The Oracle Dife-Hellman Assumptions and an Analysis of DHIES, Topics in Cryptology - CT-RSA01, LNCS
Vol. 2020, 2001.
[2] B. Adida, Helios: Web-Based Open-Audit Voting, Proceedings of the 17th USENIX Security Symposium, pp. 335-348, 2008.
[3] R.J. Anderson, Security Engineering : A Guide to Building Dependable Distributed Systems, 2nd edition, New York, Wiley 2008.
[4] A. Antipa, D. Brown, A., Menezes, R. Struik, S. Vanstone, Validation of Elliptic Curve Public Keys, Proceedings of the 6th International Workshop on
Practice and Theory in Public Key Cryptography Public Key Cryptography (PKC03), LNCS 2567, pp. 211-223, 2003.
[5] S. Bauer, N.B. Priyantha, Secure Data Deletion for Linux File Systems, Proceedings of the 10th USENIX Security, 2001.
[6] C, Burton, C. Culnane, J.A. Heather, P.Y.A. Ryan, S. Schneider, T. Srinivasan, V. Teague, R. Wen, Z. Xia, Using Pret a Voter in Victorian State Elections,
Proceedings of the 2012 Electronic Voting Technology/Workshop on Electronic Voting (EVT/WOTE12), 2012.
[7] D. Boneh, R. Lipton, A Revocable Backup System, Proceedings 6th USENIX Security Conference, pp. 91-96, 1996.
[8] C. Cachin, K. Haralambiev, H.C. Hsiao, A. Sorniotti, Policy-Based Secure Deletion, Proceedings of the 2013 ACM Conference on Computer and
Communications Security (CCS13), pp. 259-270, 2013.
[9] A. Cezar, H. Cavusoglu, S. Raghunathan, Outsourcing Information Security: Contracting Issues and Security Implications, Proceedings of the ninth
Workshop on the Economics of Information Security (WEIS10), 2010.
[10] D. Chaum and T.P. Pedersen, Transferred Cash Grows in Size, Proceedings of EUROCRYPT, pp. 390-407, 1993.
[11] D. Wheeler, Protocols Using Keys from Faulty Data (Transcript of Discussion), Proceedings of the 9th Security Protocols Workshop (SPW01), LNCS
No. 2467, pp. 180-187, 2002.
[12] A. Fiat, A. Shamir, How to Prove Yourself: Practical Solution to Identication and Signature Problems, Proceedings of CRYPTO, pp. 186-189, 1987.
[13] S. Garnkel, A. Shelat, Remembrance of Data Passed: A Study of Disk Sanitization Practices, IEEE Security & Privacy, Vol. 1, No. 1, pp. 17-27, 2003.
[14] P. Gutmann, Secure Deletion of Data from Magnetic and Solid-State Memory, Proceedings of the Sixth USENIX Security Symposium, pp. 22-25, 1996.
[15] P. Gutmann, Data Remanence in Semiconductor Devices, Proceedings of the 10th conference on USENIX Security Symposium, 2001.
[16] N. Joukov, H. Papaxenopoulos, E. Zadok, Secure Deletion Myths, Issues, and Solutions, Proceedings of the second ACM workshop on Storage Security
and Survivability (StorageSS), pp. 61-66, 2006.
[17] M. Kallahalla, E. Riedel, R. Swaminathan, Q. Wang, K. Fu, Plutus: Scalable Secure File Sharing on Untrusted Storage, Proceedings of the 2nd USENIX
Conference on File and Storage Technologies (FAST03), pp. 29-41, 2003.
[18] R. Kissel, M. Scholl, S. Skolochenko, X. Li, Guidelines for Media Sanitization, NIST Special Publication 800-88, 2006.
[19] T. Kohno, A. Stubbleeld, A.D. Rubin, and D.S. Wallach, Analysis of an Electronic Voting System, Proceedings of the 25th IEEE Symposium on
Security and Privacy, May, 2004.
[20] J. Lee, S. Yi, J.Y. Heo, H. Park, S.Y. Shin and Y.K. Cho, An Efcient Secure Deletion Scheme for Flash File Systems, Journal of Information Science
and Engineering, Vol. 26, pp. 27-38, 2010.
16
[21] B. Lee, K. Son. D. Won, S. Kim, Secure Data Deletion for USB Flash Memory," Journal of Information Science and Engineering, Vol. 27, pp. 933-952,
2011
[22] M. Paul, A. Saxena, Proof Of Erasability for Ensuring Comprehensive Data Deletion in Cloud Computing, Communications in Computer and Information
Science, Vol. 89, Part 2, pp. 340-348, 2010.
[23] D. Perito, G. Tsudik, Secure Code Update for Embedded Devices via Proofs of Secure Erasure, Proceedings of the 15th European Conference on
Research in Computer Security (ESORICS), pp. 643-662, 2010.
[24] R. Perlman, File System Design with Assured Delete, Proceedings of the Third IEEE International Security in Storage Workshop (SISW), pp. 83-88,
2005.
[25] Z.N.J. Peterson, R. Burns, J. Herring, A. Stubbleeld, A.D. Rubin, Secure Deletion for a Versioning File System, Proceedings of the 4th Conference
on USENIX Conference on File and Storage Technologies (FAST), Vol. 4, pp. 143-154, 2005.
[26] J. Reardon, S. Capkun, D. Basin, Data Node Encrypted File System: Efcient Secure Deletion for Flash Memory, Proceedings of the 21st Usenix
Symposium on Security, 2012.
[27] J. Reardon, D. Basin, S. Capkun, SoK: Secure Data Deletion, Proceedings of the 2013 IEEE Symposium on Security and Privacy, pp. 301-315, 2013.
[28] J. Reardon, H. Ritzdorf, D. Basin and S. Capkun, Secure Data Deletion from Persistent Media, Proceedings of the ACM Conference on Computer and
Communications Security, 2013.
[29] D. Stinson, Cryptography: Theory and Practice, Third Edition, Chapman & Hall/CRC, 2006.
[30] H. Tews, B. Jacobs, Performance Issues of Selective Disclosure and Blinded Issuing Protocols on Java Card, Proceedings of the 3rd IFIP WG 11.2
International Workshop on Information Security Theory and Practice (WISTP09), 2009.
[31] M. Wei, L.M. Grupp, F.E. Spada, S. Swanson, Reliably Erasing Data From Flash-Based Solid State Drives, Proceedings of the 9th USENIX Conference
on File and Storage Technologies (FAST), 2011.
[32] M. Wei, S. Swanson, SAFE: Fast, Veriable Sanitization for SSDs, Technical Report CS2011-0963, University of California, San Diego, 2011.
[33] C.P. Wright, M.C. Martino, E. Zadok, NCryptfs: A Secure and Convenient Cryptographic File System, Proceedings of the 2003 USENIX Annual
Technical Conference, pp. 197-210, 2003.
[34] C. Wright, D. Kleiman, S. Sundhar, Overwriting Hard Drive Data: The Great Wiping Controversy, Proceedings of the 4th International Conference on
Information Systems Security, pp. 243-257, 2008.
[35] Digital Signature Standard (DSS), Federal Information Processing Standards Publication, NIST FIPS Pub 186-4, July 2013.
[36] Specication of High Capacity Smart Cards, http://www.ecebs.com/high-capacity-smart-cards-a212 (accessed in Feburary, 2014)
[37] Java Card Platform Specication 2.2.2, http://www.oracle.com/technetwork/java/javacard/specs-138637.html (accessed in Feburary, 2014)
[38] The Guardian news on the Snowden documuments, September, 2013, http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security
(accessed in Feburary, 2014)
[39] Smart Card Solution Provider, http://www.javacardsdk.com/ (accessed in Feburary, 2014)
[40] Mobile Technologies, http://www.motechno.com/ (accessed in February, 2014)
[41] IBM Tivoli Storage Manager HSM, http://www-01.ibm.com/support/docview.wss?uid=swg21319299 (accessed in May, 2014)