Content uploaded by Mahalingam Ramkumar
Author content
All content in this area was uploaded by Mahalingam Ramkumar on Feb 26, 2015
Content may be subject to copyright.
1
Assuring a Cloud Storage Service
Somya D. Mohanty, Mahalingam Ramkumar
Department of Computer Science and Engineering
Mississippi State University, MS.
Abstract—A cloud storage assurance architecture (CSAA) for
providing integrity, privacy and availability assurances regarding
any cloud storage service is presented. CSAA is motivated by the
fact that the complexity of components (software / hardware and
personnel) that compose such a service, and lack of transparency
regarding policies followed by the service makes conventional
security mechanisms insufficient to provide convincing assurances
to users. As it is impractical to rule out hidden undesired
functionality in every component of the service, CSAA bootstraps
all desired assurances from simple transformation procedures
executed inside a low complexity trustworthy module; no com-
ponent of the cloud storage service is trusted.
I. INTRODUCTION
Users of a cloud storage service create files for access from
multiple platforms owned by the same user, and/or for access
by other users explicitly specified by the originator of the
file. From a security perspective, users of the service desire
assurances regarding the integrity,privacy, and availability of
files stored at remote/unknown locations.
A practical cloud storage service [1] will include numerous
elements in the form of complex hardware, software, and
personnel. Unexpected (malicious or accidental) functionality
in any hardware/software component, or malicious intent /
incompetence of personnel who administer the service, can
result in the violation of the desired assurances. A rogue
systems administrator could delete files or expose the contents
of a file to unauthorized parties; so can an attacker who may
have surreptitiously gained access to a server, perhaps by
exploiting a bug or a Trojan horse in some software/hardware
component.
Even if the owner/deployer of the service is convinced that
the system is very well designed, and all necessary steps have
been taken to ensure the integrity of the service, this is a far
cry from actually providing convincing proof of the integrity
of the service to it’s users. While it is far from practical to
convince the users of the lack of undesired functionality in
every hardware/software component and personnel of such a
service, it is reasonable for the service to be able to assure the
operation of a single trustworthy module. This is especially
true if the module is deliberately constrained to possess simple
and open functionality. In this paper, we propose a cloud
storage assurance architecture (CSAA) for a generic cloud
storage service, where users are assured of the integrity of the
service by a trustworthy module T. The specific contributions
include an algorithmic description of module Tfunctionality,
and protocols that leverage simple trusted functionality to
provide integrity, confidentiality and availability assurances to
users.
A. Overview of CSAA
The users of any cloud storage service expect contents of
files to be made privy only to users explicitly authorized
by the owner of the file. They expect that only explicitly
authorized users can modify their files. They expect the service
to provide only the latest version of a queried file (unless
explicitly queried for an older version). Users also expect that
they should not be improperly denied service.
Taking advantage of the pre-image resistance property of
any cryptographic hash function h(), the ability to assure
integrity of any file translates to the ability to store the
cryptographic hashes of each version of every file in a “pro-
tected boundary” (that is guaranteed to not be molested). The
ability to assure freshness of the file (that the latest version
is provided, even if the querier may not keep track of the
version number) can be translated into the ability to maintain
a monotonic counter for each file inside the secure boundary.
Ensuring that only authorized users can modify the file implies
the ability to store access control lists (ACL) for each file
within the protected boundary.
Taking advantage of encryption schemes, the ability to
ensure privacy of contents of files can be translated in the
ability to store all file encryption keys inside the protected
environment, and the ability to check the ACL before releasing
the secret to authorized users. That users should not be
improperly denied service (by incorrectly stating that the
“file does not exist” or that the user “does not have the
requisite access”) implies that a process running in the secure
environment should be able to unambiguously answer a simple
question: “what is the access privilege of a user ufor a file
f?”
As the service is not trusted, file hashes, encryption secrets,
and ACLs, will need to be submitted to processes running
inside the protected environment by users of the service.
In order to prevent users from providing deliberately incon-
sistent information (for example, to taint the reputation of
a good cloud storage service) the information provided by
users should also be verifiable, and approved by the service.
For example, the service should be able to verify that the
authenticated file hash submitted to the module by the user is
consistent with the file submitted to the service, or that the
ACL submitted to the module by the user is the same as the
ACL submitted to the service, etc. In CSAA, the “protected
boundary” is a resource limited module T.
1) Clark-Wilson Model: CSAA bears some similarities to
the Clark-Wilson (CW) model [2], [3] for system integrity. In
the CW model,
1) all data items whose integrity need to be guaranteed are
2
constrained data items (CDI).
2) integrity verification procedures (IVP) take all CDIs as
input, and outputs a binary value indicating if the system
is in a valid/invalid state.
3) CDIs may be modified only by well-formed transforma-
tion procedures (TP).
Specifically, well-formed TPs are guaranteed to take the
system into a correct state if the system was at a correct
state before the execution of the TP. That a system is in a
correct state is initially demonstrated by an IVP. From this time
onwards, if only a sequence of well-formed TPs are applied,
the system is guaranteed to remain in a correct state.
In the CW model, the correctness of IVPs and TPs are
certified during design time by a “security officer” for the
system. The only restriction on TPs imposed by CW model is
by definition of CW-triples of the form (user, TP, CDIs) that
specify which user process is allowed to execute a TP, and
which CDIs can be modified by the TP. The CW model simply
assumes run-time integrity of TPs and IVPs. The assumption
that TPs executed on general purpose computers can not be
molested, is far from realistic. The major departure of CSAA
from the CW model is that it imposes strict limitations on
TPs and IVPs to ensure that they can be executed inside the
confines of a resource limited boundary offered by a trustwor-
thy module T. Specifically, CSAA, constrains TPs/IVPs to
be simple and fixed procedures composed of only logical and
hash operations, and demand small (for example, a few KB)
and constant memory size. The need to limit the complexity of
Tarises from the fact that high complexity can severely limit
ones ability to consummately verify and certify the integrity
of module T[4], [5].
2) Key Elements of CSAA: In CSAA, file indexes, file
hashes, ACLs, and file encryption secrets are akin to CDIs in
the CW model. Not withstanding self-imposed constraints on
module Tcapabilities, CSAA does not place any constraints
on the scale of the service — the number of files, users, size
of ACLs or even number of versions of each file.
Key elements of CSAA include a versatile data-structure,
an Index Ordered Merkle Tree (IOMT) [7] - [9], and the
concept of self-certificates [10]. The IOMT permits a module
to represent a practically unlimited number of dynamic “virtual
CDIs” as a single CDI — the root of an IOMT stored inside
the module T. Virtual CDIs can be stored outside the module
in an untrusted location. Simple functionality consisting of
a small number of hash operations afford the ability check
the integrity of any virtual CDI against the single CDI stored
inside the module. Self-certificates, which are “memoranda
issued to oneself” — enable the module to store any number
of static CDIs in an untrusted location by taking advantage of
a secret privy only to module T.
B. Organization
The rest of this paper is organized as follows. In Section
II we provide an overview of the desired features and as-
surances regarding the operation of a cloud storage service.
In Section II-C we provide an overview of CSAA. A core
component of CSAA, the index ordered merkle tree (IOMT),
is the subject of Section III. Section III-C outlines module
generic Tfunctionality required to assure the integrity of an
IOMT. Section IV outlines CSAA specific IVPs and TPs, and
protocols for ensuring the integrity of processes like creating
new files, updating files, updating ACLs, and reporting values
associated with a file to users.
II. FE ATUR ES A ND DE SI RE D ASSURANCES
The participants in CSAA include an untrusted cloud stor-
age service S, a trusted module T, and any number of users.
Service S: The service may include one or more database
servers with access to large back-end storage. The specific
components of Sare irrelevant from a security perspective, as
such components are assumed to be untrusted.
Trusted module T: The module is assumed to be read-
proof and write-proof [6]. In other words, a) secrets stored
inside the module can not be exposed, and b) the simple TPs
executed inside the module (which will be described in the
rest of this paper) can not be modified.
Users: The system may possess an unlimited number of
users. Every user is issued a unique identity. It is assumed
that every user shares a secret with the module T. We shall
represent the secret shared between the module and a user ui
as Ki.
Users of the system employ their shared secret for securely
submitting file hashes, secrets, ACLs, to the module, and for
receiving authenticated file hashes, secrets and acknowledg-
ments from the module. The service Sserves as a middle-man
between the users and the module to check correctness of all
information provided by users to the module.
A. Files and ACLs
The total number of users/subscribers of the service S
is assumed to be dynamic, and potentially unlimited. Any
subscriber can create a file, choose a random secret to encrypt
the file, and upload the encrypted file to S. The original owner
of the file is also expected to specify an ACL for the file, which
is also uploaded to S.
The ACL Afor a file is assumed to be of the form
A={(u1, a1),(u2, a2),...,(ul, al)}(1)
where u1· · · ulrepresent user identities and a1· · · altheir
respective access permissions. We assume three types of
permissions
1) ai= 1 implies read-only;
2) ai= 2 implies read-write access; such users may create
new versions of the file;
3) ai= 3 implies read-write for both the file and the ACL;
such users can even modify the ACL for the file.
Collaborating users are not expected to possess any out-of-
band mechanism for communicating file encryption secrets.
Thus, file encryption secrets will also need to be securely
stored by S, and made available only to authorized user.
3
B. Integrity / Privacy / Availability Assurances
The CSAA approach aims to provide the following assur-
ances regarding the operation of S:
[A1.] Swill not alter files; only users explicitly granted
access level 2 or higher can modify the file, and in this process
create a new version of the file.
[A2.] Sis not trusted with file encryption secrets; only the
module T, and users explicitly specified in the ACL can gain
clear access to file encryption secrets;
[A3.] Scan not modify the ACL; only users with ACL level
3 for the file can do so.
[A4.] Only the latest version the file will be provided by
Sto authorized users, except when explicitly queried for an
earlier version.
[A5.] After an ACL has been modified, the old ACL will
not be used to determine the access privileges.
[A6.] When a user uwith legitimate access rights requests
a file, Swill not refuse to provide access. Specifically, S
is required to provide authenticated denial, in the form of
convincing proof that “the request can not be entertained.”
[A7.] In providing authenticated denial, no unsolicited in-
formation should be revealed to users.
Assurances A1 is towards authenticity and integrity of files;
assurances A2 and A3 are required to guarantee privacy of
file contents; assurances A4 and A5 address replay attacks;
assurance A6 is towards authenticated denial — to prevent
improper denial of service to a subscriber for a legitimate
request.
Assurance A7 is required to address data mining issues that
arise from authenticated denial. When authenticated denial
is mandated, the RFSS is expected to provide a verifiable
response to every query — either by providing the requested
data, or by convincing the querier that the query can not
be entertained. Typical strategies for authenticated denial
demonstrate non existence of the requested object by ordering
all objects that do exist, and demonstrating the presence of two
adjacent objects that “cover” (or span) the requested object.
Unfortunately, such an approach makes it possible for users
to make random queries to gain knowledge of the existence
of two other objects. For example, a user may send a query
for a random file to learn about the existence of two files
that do exist. Similarly, an user not in the ACL for a file,
may get to know the identities of two users who are included
in the ACL. The ability to gain unsolicited knowledge can
motivate malicious users to make random queries for nefarious
data mining purposes which can a) unduly burden the RFSS,
and b) compromise the expectations of privacy of users. To
prevent such attacks it should be ensured that no unsolicited
information will need to be revealed by S.
C. Overview of CSAA
The constrained data items necessary to guarantee all de-
sired assurances include ACLs for each file and file-hash/file-
encryption-secret for each version of every file. All CDIs can
be seen as a database with one record for each file. Each record
in the CDI-DB, indexed by a file index f, contains
1) a list of two-tuples that represent the ACL for the file;
and
2) a list of two-tuples for each version indicating the file
hash γand file encryption secret σ.
A record Rfor index fis thus of the form
Ra= [f{(u1, a1),...,(ul, al)},
{(γ1, σ1)),...,(γr, σr)}].(2)
The database is dynamic, as files may be added or deleted,
the ACL for any file may be changed at any time, and new
versions of a file may be added. All information necessary
to construct this dynamic database comes from authenticated
information asynchronously supplied by users to the module,
using the service Sas the middle-man. Every authenticated
request from the user to modify the database is acknowledged
by the module, indicating failure or success.
To create a new file, a user uiand the service Sagree on
a file index f. A message from ui, indicating the file index
fis the trigger needed to create a record for fand set the
ACL for fto {(ui,3)}, attributing user uiwith read-write
privileges for the ACL.
To add a new version a user conveys values f, γ , σ0where
γis a file hash and σ0is the encrypted version of the file-
encryption secret σ. If the user has access level 2 to f, a
two-tuple (γ, σ)is added to the file record.
To update the ACL a user with access level 3 provides a
new ACL (a list of two tuples), which replaces the old ACL.
To delete the file a user with access level 3 can provide an
empty ACL.
Any user may request to perform any action on any file.
Even if the file does not exist, or if the user does not have
the necessary access right. In all such scenarios too the user
expects an authenticated response from the trusted module.
Authenticated denial is necessary to prevent the untrusted
service provider from improperly denying service in scenarios
where the user does have the necessary privileges. Note that
if the user has no access, or if the file does not exist, the user
does not even need to know if file fdoes or does not exist.
This is to provide assurance A7 (no unsolicited information
should be revealed). The response from the trusted module in
such a case is simply “illegal request.” IF the use is in the ACL
of the file but does not have the necessary access privilege the
module’s acknowledgment indicates the current access level
of the user.
1) The Challenge: What makes the ability to reliably
respond to queries (based on asynchronously provided authen-
ticated information from users) challenging for the module is
the fact that
1) the module is severely resource limited, and
2) we do not place any limitation on the number of files,
or number of users, size of the ACL for a file, or the
number of versions for a file.
Fortunately, the reason that a severely resource limited module
can still meet this challenge is thanks to a versatile data struc-
ture — an Index Ordered Merkle tree (IOMT). The IOMT is
a binary hash tree constructed using a standard cryptographic
hash function h(). The IOMT enables the module Twhich
4
L0L1L2L3L4L5L6L7L8L9LaLbLcLdLeLf
v0v1v2v3v4v5v6v7v8v9vavbvcvdvevf
v01 v23 v45 v67 v89 vab vcd vef
v03 v47 v8bvcf
v07 v8f
ξ
Fig. 1. A binary hash tree with 16 leaves.Nodes v67, v47, v07 and ξare
“ancestors” of v6.v07 is the “immediate parent” of v6.v7is the sibling
of v6, and v45, v03 and v8fare siblings of it’s ancestors v67, v47 and
v07 respectively. The set of siblings {v7, v45 , v03, v8f}is the set of nodes
“complementary” to v6.
stores only a single cryptographic hash ξinside the trusted
boundary, to track the integrity of any number of databases of
any size maintained by an untrusted entity. More specifically,
by performing log2Nhash operations (where Nis the total
number of database records) the module can a) verify the
integrity of any record against the root ξstored inside the
module, or b) infer the absence of a record with a specific
index, or c) update the root ξcorresponding to addition /
updates to records. For our purposes, all CDIs (the database
with ACL two-tuples and version three-tuples for each file
index) may actually be stored by the untrusted service S. Only
a single IOMT root will be stored inside the module T. Each
event that calls for updating/adding a record or responding to
a query by conveying values from a record will only call for
execution of O(log2N)hash operations inside the module.
III. IND EX OR DE RE D MER KL E TREE
Similar to the better known Merkle hash tree [11], an
IOMT is a binary hash tree constructed using a standard
cryptographic hash function like SHA-1. A tree with Nleaves
has 2N−1internal nodes (cryptographic hashes) distributed
over L= log2Nlevels ( N
2lnodes in levels l= 0 to l=L).
The lone node at level Lis the root of the tree, which is a
cryptographic commitment to all leaves. Figure 1 depicts a
binary tree with 16 leaves.
A. Nodes and Leaves
Corresponding to a leaf Liis a leaf node viat level 0 of
the tree, computed as
vi=h(Li).(3)
Two adjacent nodes are each level (sibling nodes) are hashed
together to compute the immediate parent at a higher level.
More specifically, the parent node pof two sibling nodes u
and vis computed as
p=HN(u, v) =
uif v= 0
vif u= 0
h(u, v)if u6= 0, v 6= 0
(4)
For example, v67 =HN(v6, v7),v03 =HN(v01, v23), etc.
The root of the tree is a commitment to all leaves and nodes.
Corresponding to any leaf node viit is trivial to identify a
set of Lcomplementary nodes vi(Figure 1) depicts the set
of L= 4 nodes complementary to v6). The complementary
nodes of v6, together, can be seen as a commitment to all
nodes except v6. A simple one way function fbt() consisting
of L HN() operations, confirms the existence of a one-way
relationship between the leaf node vi(and hence the leaf Li)
and the root ξ, through the set of complementary nodes vi.
ξ=fbt(vi,vi).(5)
For example, v6and ξare related through {v7, v45, v03, v8f}
through a sequence of L= 4 operations v67 =HN(v6, v7),
v47 =HN(v45, v67 ),v07 =HN(v03, v47 )and ξ=
HN(v07, v8f).
If there is a valid reason to update leaf node vito v0
i, the
new root can be computed as ξ0=fbt(vi,vi). Using the same
complementary nodes bfvifor verifying the viagainst root ξ
and updating ξto ξ0ensures that no other leaf node is affected
by the update (as viis a commitment to all nodes except vi).
Note that HN() is a simple hash function if both inputs
are non zero; else, it outputs a parent that is the same as the
non zero child. The parent of two zero children is also zero
(or HN(0,0) = 0). Treating zero nodes in a special manner
makes it possible to easily insert nodes. A tree can be seen as
including any number of zero leaf nodes. Any zero node can
be updated to a non zero value to insert a node.
1) IOMT Leaves: The leaves of an IOMT are constrained to
form a virtual circular linked list. Specifically, an IOMT leaf is
a three-tuple of the form (INDEX,NEXT INDEX,VALUE)
where VALUE is a is a value associated with index INDEX.
The quantity zero is given a special interpretation in IOMTs.
An index can never be zero. A like leaf (a, a0,0) with zero
VALUE field is a “place-holder” for index a.(a, a0,0) does not
mean that “index ais associated with value 0.” A place-holder
(a, a0,0) indicates that “no value is associated with index a.”
For all leaves in a tree NEXT INDEX >INDEX except
for the leaf with the highest index, amax, for which the
next index is the least index amin. For a tree with a single
leaf NEXT INDEX = INDEX. The constraint (to remain a
linked list) is enforced when leaves are inserted are removed
from the tree. A leaf is always inserted as a place-holder; only
place-holders can be removed.
To insert a place-holder for an index bthe verifier need to be
convinced of the existence of a leaf or place-holder (b, b0, ωb)
such that (b, b0)encloses a. This is true if b<a<b0, or if
b0≤b(which will be the case if bis the highest index and
b0is the least index, or if b=b0is the sole index) then any
athat is lower than b0or greater than bis considered to be
circularly enclosed by (b, b0). In other words (b, b0)encloses
aif
(b<a<b0)OR(b0≤b<a)OR(a <b0≤b) (6)
To ensure integrity of the linked list when a place holder for
ais inserted, the newly inserted place-holder will be (a, b0,0),
and the encloser (b, b0, ωb)will be modified to (b, a, ωb). Recall
that an IOMT can be seen as consisting of any number of
5
(5,7, r5)(2,4, r2)(4,5, r4)(9,2, r9)(7,9, r7)IOMT Leaves
[5,R5] [2,R2] [4,R4] [9,R9] [7,R7]DB Records
(5,7, r5)(2,3, r2)(4,5, r4)(9,2, r9)(7,9, r7)(3,4,0)
place-holder inserted for index 3
[5,R5] [2,R2] [4,R4] [9,R9] [7,R7]
IOMT Leaves
DB Records
Fig. 2. Relationship between a database and IOMT leaves. Riis a record for
an index. riis a compact representation of Ri(for example, ri=h(Ri)).
Insertion of a place-holder leaf has no effect on the data base even though it
modifies an enclosing leaf (shown in a lighter shade).
nodes with value zero. To insert the place holder one such zero
node will need to be updated to h(a, b0,0); simultaneously,
a node vb=h(b, b0, ωb)will need to be updated to v0
b=
h(b, a, ωb). Correspondingly, the root of the IOMT will be
updated (by executing fbt()) to account for the modifications
to two leaf nodes.
B. Database Representation Using IOMT
Together, all leaves of an IOMT can be seen as a representa-
tion of a database, where each leaf corresponds to a record for
an index specified by the first field. The value ωaassociated
with index acan be seen as a succinct commitment to the
database record for index a(for example, hash of the record).
Figure 2 depicts the relationship between leaves of an IOMT
and a database represented by the IOMT. Applications em-
ploying IOMTs can be seen as two-party protocols involving
a (typically resource limited) verifier, and a (resource rich)
prover. The prover maintains the database of records, all
IOMT leaves, and nodes. Only the root ξof the IOMT will
need to be stored by the verifier. The prover can readily
identify a set of complementary nodes necessary to prove the
integrity of any leaf against the root ξ.
If the prover requires to modify a record, an application
specific justification will need to be provided. For example, in
the case of CSAA, a justification in the form of a authenticated
request from an authorized user is necessary.
As can be seen from Figure 2, from the perspective of the
database represented by an IOMT, addition of a place-holder
makes no difference — even while it required two leaves (and
the IOMT root) to be modified. If ξwas the root before the
insertion of a place holder, and ξ0the root after insertion,
then ξand ξ0are considered as equivalent roots. In order
to update a record for an index a(change the value field in
the IOMT leaf for index a) typically a database/application
specific justification will be necessary. However, a module can
be requested to change it’s root to an equivalent root without
providing an application specific justification.
C. IOMT Algorithms Inside A Trusted Boundary
Consider a trusted boundary capable of executing the al-
gorithm fbt(). More specifically, given a hash xand a set
of hashes (complementary nodes) x, the module can readily
compute y=fbt(x, x). If the inputs xand xwere actually
chosen from an IOMT, yis guaranteed to be a node in the
same IOMT. More specifically, if xincluded nvalues, then y
is an ancestor of xthat is nlevels higher. If the inputs were
randomly chosen it is still true that yis an ancestor of xin
some IOMT, though not necessarily an IOMT that is actually
used by anyone.
Assume a secret χinside the trusted boundary, that was
spontaneously generated, and thus not known to any entity
apart from T. Having determined a relationship between x
and y(that yis an ancestor of x) the module can issue a
memorandum to itself as
ρ= HMAC([x,y], χ)(7)
where HMAC() represents a function for computing a hashed
message authentication code (HMAC), executed inside the
module. The values ρ, x and ycan be provided back to the
module at any time to convince the module that it had already
verified that yis an ancestor of x(without actually having to
provide the complementary values x).
Similar to records, IOMT leaves and nodes, certificates can
be stored by the untrusted prover. While dynamic values will
need to be represented as leaves of a hash tree before they
can be stored outside, to prevent replay attacks. However, a
static values can be stored using less expensive symmetric
certificates.
Simple additional functionality inside the module can then
be used to combine two or more certificates to make higher
level inferences about the IOMT, or the database represented
by the IOMT, and certify such inferences. Depending on the
nature of the higher level inference, each certificate can be
identified by a type-field.
In the rest of this section we shall outline some useful cer-
tificate types (NU, EQ, RV and RU) along with a description of
functions that generate such certificates of different certificate
types computed as
ρnu = HMAC(NU,[x,y,x0,y0], χ);
ρeq = HMAC(EQ,[y,y0], χ);
ρrv = HMAC(RV,[x,v,y], χ);
ρru = HMAC(RU,[x,v,y,v0,y0], χ);
(8)
Certificates of type NU and EQ are oblivious to actual
records represented by an IOMT. Certificate types RV and
RU are not. A certificate NU-[x, y, x0, y0]is proof that yis an
ancestor of x, and if x→x0, then y→y0. In the rest of this
paper we shall use the notation type-[· · ·], for example,
NU −[x,y,x0,y0],EQ −[z,z0], . . . (9)
etc., to represent the type and contents of a certificate.
A certificate EQ-[y, y0]is proof that the root of an IOMT
can be toggled between yand y0without affecting the integrity
of any record in the database represented by the IOMT. A
certificate RV-[x, v, y]is proof that in an IOMT with root y
there exists a leaf for INDEX xwith VALUE v. If v= 0 the
implication is that no record exists with INDEX x. This may
be due to a) existence of a mere place-holder for INDEX x,
or absence of a leaf/place-holder with INDEX x— indicated
by the presence of an encloser for index x. A certificate RU-
[x, v, y, v 0, y0]is proof that an IOMT with root ythere exists
6
a leaf for INDEX xwith VALUE v, and that if v→v0, then
y→y0.
Function Fnu() takes inputs x, x0and x, computes y=
fbt(x, x)and y0=fbt (x0,x)to create a certificate of type
NU.
Fnu() :
x, x0,x
y0←y←fbt(x, x)
IF (x6=x0)
y0←fbt(x0,x)
→NU[x,y,x0,y0].(10)
Fnu() is the only function that accepts complementary nodes
as inputs. All other functions generate various certificate type
by manipulating various certificate types.
Function Fcat() can be used to combine two NU certificates
to create another NU certificate. Specifically, a certificate NU-
[x, y, x0, y0]and a certificate NU-[y , z, y0, z0]can be used to
create a new certificate NU-[x, z, x0, z0]binding xto higher
level ancestor z. In other words function Fcat() can be
represented as
Fcat() : NU[x,y,x0,y0]
NU[y,z,y0,z0]→NU[x,z,x0,z0].(11)
Recall that inserting a place-holder for index ain any IOMT
requires the existence of an encloser (b, b0, ωb), and that after
insertion, the leaf node corresponding to the encloser will need
to be modified from ve=h(b, b0, ωb)→v0
e=h(b, a, ωb)
and another leaf node (corresponding to the newly inserted
leaf) will need to be modified from 0→vi=h(a, b0,0).
Given a NU certificate which states that “ve→v0
eimplies
y→y0” and another NU certificate stating that “0→vi
implies y0→y00, function Feq () can readily conclude that
yand y00 are equivalent roots, and issue a certificate ρ=
HMAC(EQ,[y,y00], χ).
More specifically, changing an IOMT root from y→y00
corresponds to inserting a place-holder. Conversely, changing
a root from y00 →ycorresponds to deleting a place-holder! In
the same spirit of Eq (11) function Feq() can be represented
as
Feq() :
NU[ve,y,v0
e,y0]
NU[0,y0,v0
i,y00]
(b, b0)encloses a
ve=h(b, b0, ωb)
v0
e=h(b, a, ωb)
vi= 0; v0
i=h(a, b0,0)
→EQ[y,y00].(12)
Given a certificate NU-[x, y, x, y]binding a value xto an
ancestor y, and given a leaf (a, a0, ωa)such that the leaf hash
is x=h(a, a0, ωa), function Frv () can conclude that (a, a0, ω)
is a leaf in a tree with root yand issue a certificate binding
the record index aand value ωato the ancestor node y. Given
an additional index bsuch that (a, a0)encloses b,Frv () also
infers that “no record for index bexists in the tree with root
y.” Accordingly, function Frv() issues a certificate of type RV
(record verified) binding values b, 0and y(the zero indicates
that no record exists for index b).
Frv () :
NU[x,y,x,y]
x=h(a, a0, ωa)
hbencl. by (a, a0)i
→RV[a, ωa,y].
hRV[b,0,y]i(13)
Given a certificate NU-[v, y, v0, y 0], values (a, a0, ωa)satis-
fying v=h(a, a0ωa), and ω0such that and v0=h(a, a0ω0
a),
function Fru() can issue a certificate of type RU (record
update) which states that “updating a record with index afrom
ωa→ω0
awill require the root to be modified from y→y0.”
In other words,
Fru() :
NU[v,y,v0,y0]
v=h(a, a0, ωa)
v=h(a, a0, ω0
a)
→RU[a, ωa,y, ω0
a,y0].(14)
D. Application Specific Functions
For systems/applications whose integrity is assured by a
trustworthy module T, the untrusted system is the prover
that maintains one or more application specific databases and
IOMTs corresponding to the databases. The module stores
one or a small fixed number of IOMT roots. Apart from
interfaces/functions exposed by the module to generate various
types of application independent certificates, the module will
expose some additional interfaces:
1) functions that accepts equivalence certificates to in-
sert/delete place-holders;
2) transformation procedures (TPs) that accept authenti-
cated proof of the need to modify a database record (in
the case of the cloud storage service S, an authenticated
request from an authorized user is necessary to update
any record in the CDI DB).
3) integrity verification procedures (IVPs) necessary to
submit integrity assurances to users of the system, and
possibly
4) other functions for generating additional application
specific certificate types.
TPs that accept proofs for the need to change a leaf from
(say) (a, a0,0) →(a, a0, ωa)will accept a certificate like RU-
[a, 0, ξ, ωa, ξ 0]indicating that if the current root is ξ, the root
should be changed to ξ0, in order to modify the record for
index a. IVPs that supply proof of integrity, similarly, may
accept certificates of type RV to convey application specific
record contents (for example, the correct hash of a file) to
users. In order to interact with users, the module Twill need
to support additional functionality for establishing secrets with
users of the system.
IV. CS AA P ROT OCOLS
Underlying the CSAA protocols are three assumptions,
1) the integrity of simple functions executed inside the
module T,
2) privacy of secrets employed by the module to interact
with the outside world, and
3) the hash function h() is pre-image resistant.
The module Tpossesses in-built functionality K() to compute
a secret it shares with any user. We shall represent by
Ki=K(S, ui)(15)
the secret Kishared with user ui. There are several ways to
establish a secret between a module and users; one possibility
is to employ a trusted key distribution center (KDC) who
7
issues a secret Sto the module. The KDC also issues secrets
to the users. A user uiis issued a secret Ki=h(S, ui). In this
case the functionality Ki=K(S, ui)is simply Ki=h(S, ui).
If it is desired to employ a plurality (say, 2) of independent
KDCs, then each KDC supplies module with a a secret (say,
S1and S2respectively). Each KDC issues a secret to each
user (secrets of uiare then h(S1, ui)and h(S2, ui), and the
shared secret Ki=K({S1, S2}, ui) = h(S1, ui)⊕h(S2, ui).
The module is also possesses in-built functionality to com-
pute HMACs. Messages from users are authenticated by
appending a HMAC. For example, to authenticate a bit-string
ua user ul(who shares a secret Klwith the module) computes
a HMAC as
µ= HMAC(u,Kl)(16)
Acknowledgments from the module Tto the user ulare also
authenticated in the same manner, using a HMAC computed
using secret Kl. As was discussed in the previous section, self-
certificates are also computed using HMACs using the secret
χknown only to the module.
The untrusted Smaintains the CDI-DB, and the correspond-
ing CDI-IOMT. Module Tstores only an IOMT root ξof the
CDI-IOMT.
A. CDI-DB
The CDI-DB maintained by Scan be seen as consisting as
one record for every file index f. A record for file index f
includes
1) the latest version number qfof f;
2) a counter cf(which is incremented every time any
modification is made to record index fin the CDI-DB);
3) an ACL represented as an IOMT with root αf; a leaf
in the ACL tree is of the form (u, u0, a), indicating that
user uhas access privilege afor file f(and that all user
identities enclosed by (u, u0)do not have any access
privilege);
4) a certificate of type FR (file record) binding values
f, cf, αf, qf(certificate FR-[f , cf, αf, qf]); this certifi-
cate is re-issued by the module every time the counter
cfis incremented.
Leaves of the CDI-IOMT (with root ξ) maintained by S
are of the form (f, f 0, cf)where cfis a counter. In addition,
corresponding to every version of each file, the CDI-DB
includes four values. The values corresponding to version q
of file f(where 1≤q≤qf) are
1) a value κ, which is a commitment to the file encryption
secret σ; more specifically, κ=h(σ, f );
2) a value λwhich is a function of the hash of the encrypted
file γand the commitment κ. Specifically, λ=h(γ, κ).
3) a value σswhich is an encrypted version of the file
encryption secret σ; specifically, σs=h(κ, χ)⊕σcan
be decrypted only by the module T.
4) a certificate ρvr of type VR (version record) binding val-
ues f, q and λ(certificate VR-[f , q, λ]). One certificate
is issued by the module every time a new version of the
file is created.
B. Transformation Procedures
The copy of the root ξof the CDI-IOMT stored inside the
module Tcan only be modified by TPs executed inside the
module.
A TP Fph() which accepts an equivalence certificate EQ-
[y, y0]as input can be used to insert/delete place holders (for
file indexes) in the IOMT. Specifically, if the current root is
ξ=y, it is modified to y0; if the current root is ξ=y0it is
set to y.
Fph() : EQ[ξ, ξ0]OR EQ[ξ0, ξ]→ {ξ→ξ0}(17)
Apart from purposes of inserting/deleting place-holders
(which does not affect the CDI-DB) all other modifications
to ξcorrespond to a due to a modification to the CDI-
DB (and hence the CDI-IOMT). The justification for such
modifications have to be provided as authenticated inputs from
a user authorized to do so (access level a≥2for adding a
new version, and access level a= 3 for updating ACL or
removing a file). An authenticated message from a user uito
the module (authenticated using secret Ki)
µ= HMAC(type,f,c,v],Ki)(18)
includes a type (which distinguishes between updates to ACL
and updates to the file), file index f, a counter c, and a value
v; the value v=αis the rot of an ACL IOMT for messages
that update the ACL. For file update messages v=λfor the
new file version. Every successful request is acknowledged by
the TP. As we shall see later illegal requests (non existence of
file, lack of access rights etc.) are also acknowledged using an
IVP Fres() (discussed in Section IV-C) that informs the user
of the nature of the illegality of the request, while at the same
time making sure that no unsolicited information is revealed.
From the perspective of the module, updating the ACL can
also be for reserving a file index for deleting a file fby
conveying ACL root α= 0.
A message [f, 0, α0]from a user uialong with a certificate
RU-[f, 0, ξ, 1, ξ 0]is sufficient to convince the module that no
record exists in the CDI-DB for index f, and that adding a
record with counter set to 1 will necessitate modification of
root to ξ0. The module also issues a certificate FR-[f, cf=
1, α0, q = 0], which is required to make the next update to the
record for file f.
For all other update requests from a user uan FR-certificate
(indicating ACL root αf) and an RV certificate RV-[u, a, αf]
indicating access privilege of user is necessary. The two
certificates are sufficient to convince the module that if the
current counter value for index fis cf,then uihas access
level afor file f. If the user has required access level, then
a certificate RU-[f, cf, ξ, c0
f, ξ0]is sufficient to convince the
module that file fwith counter value fcis indeed consistent
with the indeed current root ξ, and that modifying the counter
to c0
fwill require the root to be updated to ξ0. The new counter
value c0
f=cf+1 for all update operations, except for deletion
of file, for which c0
f= 0.
All updates that increment the counter produce a new FR
certificate for the updated counter value (which is needed
for the next update). Updates for adding a new version also
8
{f, c =cf, v }ui
RU [f, cf, ξ , c0
f, ξ0]
F R[f, cf, qf, α]
RV [ui, a, α]
IF (c0
f=cf+ 1);
⇒
IF (cf= 0)
F R[f, c0
f,0, v =α0]
ξ←ξ0;
IF (ui= 3)
F R[f, c0
f, qf, v =α]
ξ←ξ0;
IF (ui≥2)
F R[f, c0
f, qf+ 1, v =λ]
V R[f, qf+ 1, v ]
ξ←ξ0;
IF (c0
f= 0) ∧(α= 0) ⇒IF (ui= 3) ξ←ξ0;
Fig. 3. CASS TP Ftp () that modifies CDIs. For reserving a file, updating a
file/ACL the counter value is incremented (c0
f=cf+ 1). All these updates
produce a FR certificate necessary for the next update. For deleting a file the
counter value is c0
f= 0. No certificate is produced. The “type” field in the
user request and the acknowledgment from the module are not shown.
produce an additional VR certificate VR-[f, q, λ], which can be
used to convey the value λassociated with any version qof file
fto any user with access level 1 or higher. Figure 3 depicts the
algorithm for transformation procedure Ftp() which handles
all updates. All successful updates are acknowledged (not
shown in Figure 3)
Before invoking the the TP the service Sis expected to
ensure that the ACL submitted by the user is consistent with
the value v=αin the message and that the counter value c
in the message is consistent with the current counter value cf
for f. When reserving a file Smay require that the user is
added with level 3 access in the ACL.
Along with a message [f, cf, λ]from a user ulto add the
next version of file f, the user is expected to send to San
encrypted secret σ0, a commitment κ, and the new version of
the file. The service Shashes the (encrypted) file to ensure
that the file hash is indeed γ, and verifies that λ=h(γ, κ).
If the user chooses not to encrypt the file, then κ= 0,
and σ0= 0. If κ6= 0 Scan not by itself verify the
integrity of the secret σ0submitted by the user. This is
achieved using a function Frs() exposed by the module. Given
values ul, f, cf, κ,Frs () decrypts the secret, verifies that it is
consistent with the commitment κ. Only then is the secret
encrypted using χand returned to Sfor storage as σs.
Frs :
f, q, ul, σ0, κ
σ=h(f, cf, Kl)⊕σ0
IF (κ=h(f, σ))
σs=h(κ, χ)⊕σ;
→σs(19)
C. IVPs for CASS
CASS IVPs are invoked by Sfor
1) sending a negative acknowledgement to a user request-
ing an illegal update; and
2) sending value λcorresponding to any version of any file
to an authorized user
IVP Fsnd() can only send contents determined to be consistent
with the current IOMT root ξ.
Given certificates RV-[f, cf, ξ ], RV-[ul, a, α], FR-
[f, cf, αf, qf], RV-[f, q, λ]an IVP Fsnd() is convinced
that usrer ulhas access right afor file f. For a non existent
file cf= 0, and the other certificates are not necessary. If the
user does no have access, or if the file does not exist, the
same negative acknowledgement is created, conveying the
requested file index fand no other unsolicited information.
If file exists, and if the user has access level a > 0the
user is authorized to receive information about any version of
f. An additional VR certificate provides information regarding
version qof the file where it is possible that q6=qf(if the user
had requested an older version). The response also includes the
most current version number, and the current counter value cf
for the file. IVP Fsnd() can be represented as follows:
RV[f,cf, ξ]
RV[ul,a, α]
FR[f,cf, αf,qf, ξ]
VR[f,q, λ]
⇒
IF ((cf= 0) ∨(a= 0))
{f}T→ul
ELSE
{f, cf, qf, q, λ}T→ul
When a user receives the file from Sthe user also expects
a value κto be provided by S(module Tdoes not care that
λ=h(γ, κ)or even the exact mechanism used for computing
file hash γ). The user hashes the file to obtain γand verifies
that λin the authenticated response by the module is consistent
with γand κ. If κ6= 0 the user can easily conclude that he/she
is eligible to receive a secret with commitment κ.
To relay the stored secret to an authorized user, the
service employs another IVP Frs(). Given certificates RV-
[f, cf, ξ ],RV-[uj, a ≥1, αf], and FR-[f, cf, αf, qf]it can
be concluded that user ujis eligible to receive secret σ
corresponding to any version of file f. Along with the three
certificates values σsand κare also provided as inputs to a
function Frs() to relay the file encryption secret to user uj.
The secret is decrypted as σ=h(κ, χ)⊕σs. The integrity of
the decrypted secret is confirmed if κ=h(f, σ)before it is
conveyed to the user (using secret Kjshared with the user).
IVP Frs() can be represented as follows:
RV[f,cf, ξ]
RV[ul,a, α]
FR[f,cf, αf,qf, ξ]
σs, κ
σ←h(κ, χ)⊕σs
κ=h(f, σ)
⇒σj=h(κ, Kj)⊕σ.
D. Summary of Module TFunctionality
Figure 4 provides a broad summary of various certificate
types, certificate functions, TPs and IVPs. The vertical dotted
line separates generic IOMT functions from CASS specific
functions that are aware of the (application specific) interpre-
tation of IOMT leaves.
The two arrows from (for example) NU to EQ illustrates
that two NU type certificates are required for obtaining an
EQ certificate. From the figure it can be readily seen that
two RV certificates are required to generate an LV certificate
(certifying latest version in a tree with root θ), and the LV
certificate along with an EQ certificate (for insertion of a place-
holder for the next version) and RU certificate (for updating the
place-holder to a leaf) are required to generate certificate type
VU. Certificate generation functions are “helper functions”
that are independent of CDIs.
9
NU
Fcat() : (NU,NU) →NU EQ
Feq() : (NU,NU) →EQ
RV
Frv () : NU →RV
RU
Fru() : NU →RU
FR
VR
IVP Fsnd(RV,RV,FR,VR)
IVP Frs(RV,RV,FR)
TP Fph(EQ)
TP Ftp(RV,RU,FR)
Generic CASS Specific
Fig. 4. Generic and CASS-specific functions and certificates.
In the right end of the figure all CASS specific TPS and
IVPs are listed along with the types of certificates needed
as input. Ftp() modifies virtual CDIs, and hence the real
CDI (IOMT root ξ) stored inside the module. The TP Fph()
modifies the real CDI without affecting virtual CDIs (CDI-
DB). IVPs do not modify CDIs.
V. DISCUSSIONS, RELATE D WORK AND CONCLUSIONS
The main differences between CSAA and Clark-Wilson
(CW) model are as follows:
Execution of TPs and IVPs: In CSAA TPs and IVPs are
constrained to be executed inside the trustworthy boundary
of a sufficiently tamper-responsive module T. It is assumed
that attempts to expose secrets protected by the module or
attempts to modify the module functionality will result in
zeroisation of the module (where the module simply erases it’s
secrets) thereby rendering the module unusable for providing
assurances to users. CW model makes no attempt to explicitly
define the environment in which TPs are executed.
Constrained structure for CDIs: A second difference lies
in deliberately constraining CDIs to be represented as a special
data-structure (IOMT). This is to permit any number of CDIs
to be tracked by a resource limited module T.
Unconstrained Data Items (UDIs): Both CSAA model
and the CW model recognizes the need for unconstrained
data items (UDI). CDIs are actually born as UDIs. More
specifically, UDIs serve as inputs to the system, and are
manipulated by TPs to create CDIs. In the CW model TPs
that handle UDIs are required to be verified to meet application
specific “separation of duty” requirements. In CSAA, UDIs are
authenticated inputs provided by users to the module. They are
unconstrained, as a user can request actions on any file (even
non existent ones) or files to which the user does not have
access rights. The ability of the module to answer a simple
question (what is the access right of user ufor file f) even for
non existent files and non existent users in the ACL (thanks
to IOMT) is a very important feature required to verify the
correctness of UDIs before they are converted into CDIs.
Access to TPs and IVP: The CW model was primarily
intended for applications executed on a single computer that
supports multiple users. Apart from specification of TPs and
IVPs the CW model for a system specifies three-tupes of
the form (user, TP,CDIs) that specify which user process can
execute a TP, and what CDIs can be accessed/manipulated
by the TP. In CSAA any one with access to the module
can invoke functions exposed by the module. The untrusted
service Sis responsible to ensure that no user can directly
access functions exposed by the module to provide deliberately
inconsistent information to the module. If the service Sfails
to protect access to the module, the service may not be able
to demonstrate it’s integrity to users.
A. Scalability
Issues that affect the scalability of CSAA can be seen as
belonging to two broad categories: a) the number of CDIs,
and b) the rate at which events that modify CDIs occur. For
a file storage system, the number of CDIs will be roughly
proportional to the total number of files. A thousand fold
increase (say from a billion to a trillion) will only increase
the complexity of each procedure by a factor 40/30, as the
number of hash operations is proportional to log2N, which
increases from log2109≈30 to log21012 ≈40.
While the complexity of handling each “event” (triggered by
a user request to reserve/update/delete a file or by a request
from Sto send parameters related to a version of a file to
a user) increases logarithmically, unfortunately, the frequency
of events is more likely to increase linearly. A system with
10 times as many files as is likely to handle ten times as
many events every second. The second issue can be addressed
by deploying CSAA in parallel, using a plurality of identical
modules T, where each module tracks only a specific range
of file indexes. In this case every user will need to share a key
with every module.
B. Scope of Assurances
It is important to note that the CDI databases are very
different compared to the actual databases maintained by the
service. For example, a real life cloud storage system may use
different indexes for each file (to make it possible to readily
identify the directory the file is located in, the owner of the
file, etc.). The service may also maintain a database of different
computers belonging to a user, and a list of folders that need
to be synced in each computer. The service may also maintain
a database with a record for each user indicating user quota,
an the actual space utilized by the user. As the index of a file
in the CDI database can be different from the indexing used
by the service’s databases, the service may maintain another
database that enables translation between the two indexes.
Ultimately, the CSAA CDI database is designed solely
based on explicitly desired assurances. For our purposes, for
providing the seven assurances outlined in Section II-B, it is
not necessary for the CDI database to track user quota, or
the correctness of file syncing operations. However, if it is
desired to provide additional assurances, like (for example)
that “users should not be incorrectly denied access based on
storage quotas” or that “every file in a directory is correctly
synced to the latest version,” then some additional CDIs will be
required, demanding additional TPs and IVPs to be executed
by module(s) T.
10
C. Related Work
A closely related work that also aims to assure the operation
of a cloud storage service by employing a trusted module is the
virtual counter (VC) [12] approach. In the file storage model
used in [12] users create files for access by themselves from
other locations (no ACLs are used). The goal is to ensure that
that only the latest version will be provided by the service
(older versions should not be replayed). Specifically, a user
may update a file using her computer at work. When she later
tries to retrieve the file from her home, she expects the latest
version of the file. The assumption here is that the user may
not actually remember the previous updates she had made, and
thus may not recognize the freshness of the version provided
by the service. As the user does not trust the service, she
expects the module to certify the file hash corresponding to
the freshest version of the file.
In [12] a trusted module assures the integrity of the root of a
merkle tree, where the leaves of the tree are virtual counters —
one associated with every file. The virtual counter associated
with a file (in a leaf of the tree) will be incremented by the
module only when the file is updated through an authenticated
message from the owner of the file. The hash of the new
version of the file is bound to the incremented virtual counter
value.
As a response to a query for a file, users expect an
authenticated response from the module. The module will
authenticate only responses that include the file hash bound
to the current virtual counter value for the file.
One flaw in the virtual counter approach is that there is
no mechanism to prevent the same file from being bound
to multiple counters. Thus, when an update is received, the
server can request the module to update one counter, while
leaving a second counter bound to the older version. From the
perspective of the module the other counter is still, legitimate,
and can thus be replayed. In [13] it was pointed out that using
an IOMT (which guarantees uniqueness of indexes) instead of
a plain Merkle tree, can address this flaw.
Several authors [14] -[16] have addressed strategies for
providing proof of retrievability (POR) for assuring users of
the integrity of files stored in the cloud. The main motivation
for such approaches stem from the fact that for large files,
hashing entire files to determine hash may be an expensive
operation. Most such approaches involve random checking
of multiple small segments of a large file to be assured of
(with a high probability) the integrity of the file. There is
inherently nothing in the proposed approach that mandates that
file integrity has to be verified by hashing a file. The module
Tdoes not care how the integrity of a file is demonstrated
against a commitment γ. The users and the service can choose
an appropriate (and convenient) strategy. Instead of a file hash,
the value γcan be a concise representation (hash) of values
required to verify integrity.
D. Conclusion
With ever growing complexity of hardware and software
components, the presence of hidden malicious functionality is
a very serious concern. It is thus essential to have strategies in
place to provide assurances regarding the operation of complex
systems, without the need to rely on the integrity of complex
components. In the proposed CSAA for assuring cloud storage
service Sno component of the service Sis trusted.
As all assurances are bootstrapped from the assumption of
integrity of module Tit is necessary to take every possible
effort to ensure simplicity of the module. Lower the memory
requirement inside the trusted module, the lower is the possi-
bility that hidden malicious functionality can escape detection.
The lower the power consumed by the module, the lower the
need to dissipate heat, and thus the module can be shielded
very well from intrusions that attempt to expose secrets from
the module or modify the module functionality [4], [5]. It is
for these reasons we limit the module Tto possess a small
constant memory size irrespective of the size of the database
to be protected, and limit the operations performed by the
module to simple sequences of hash operations.
It is important to note that the proposed approach does
not seek to improve the reliability of the service Sitself. It
does not prevent, for example, a rogue system administrator
or an attacker who has gained access to the system from
deleting/modifying a file. All that is assured is that, if such an
event occurs, the system can no longer prove it’s integrity to
any one who may query the illegally deleted/modified file. The
service provider is expected to take all necessary precautions to
weed out undesired functionality in their system, to rightfully
gain the trust of users.
REFERENCES
[1] M. Borgmann, T. Hahn, M. Herfert, T. Kunz, M. Richter, U. Viebeg,
S. Vowe, “On the Security of Cloud Storage Services,” SIT Technical
Report SIT-TR-2012-001, Fraunhofer Institute for Secure Information
Technology, March 2012.
[2] D.D.Clark, D.R. Wilson, “A Comparison of Commercial and Military
Computer Security Policies,” in Proceedings of the 1987 IEEE Sympo-
sium on Research in Security and Privacy (SP’87), May 1987, Oakland,
CA; IEEE Press, pp. 184193.
[3] X. C. Ge, F. Polack, R. Laleau, “Secure databases: An analysis of Clark-
Wilson model in a database environment,” Proceeding of Advanced
Information Systems Engineering, 2004, pp 234-247.
[4] S. W. Smith, “Trusted Computing Platforms: Design and Applications,”
Springer, New York, 2005.
[5] M. Ramkumar, “Trustworthy Computing Under Resource Constraints
With the DOWN Policy,” IEEE Transactions on Secure and Dependable
Computing, pp 49-61, Vol 5, No 1, Jan-Mar 2008.
[6] R. Gennaro, A. Lysyanskaya, T. Malkin, S. Micali, T. Rabin, “Tamper
Proof Security: Theoretical Foundations for Security Against Hardware
Tampering,” Theory of Cryptography Conference, Cambridge, MA,
February 2004.
[7] V. Thotakura, M. Ramkumar, “Minimal TCB For MANET Nodes,” 6th
IEEE International Conference on Wireless and Mobile Computing,
Networking and Communications (WiMob 2010), Niagara Falls, ON,
Canada, September 2010.
[8] S. Mohanty, A. Velagapalli, M. Ramkumar,“ An Efficient TCB for
a Generic Content Distribution System,” International Conference on
Cyber-enabled distributed computing and knowledge discovery, Oct
2012.
[9] A. Velagapalli, S. Mohanty, M. Ramkumar,“An Efficient TCB for
a Generic Data Dissemination System,” International Conference on
Communications in China: Communications Theory and Security (CTS),
ICCC12-CTS, 2012.
[10] D.Davis, R. Swick, “Network Security via Private-Key Certificates,”
SIGOPS Oper. Syst. Rev. 24 (4) pp 64–67, Oct. 1990.
[11] R.C. Merkle, “A Digital Signature Based on a Conventional Encryption
Function,” Advances in Cryptology CRYPTO ’87. Lecture Notes in
Computer Science 293. 1987.
11
[12] F.G. Sarmenta, M.V.Dijk, C.W. ODonnell, J. Rhodes, S. Devadas,
”Virtual monotonic counters and count-limited objects using a TPM
without a trusted OS,“ Proceedings of the 1st ACM CCS Workshop on
Scalable Trusted Computing (STC06, pages 27–42, 2006.
[13] S. D. Mohanty, M. Ramkumar, “Securing File Storage in an Untrusted
Server Using a Minimal Trusted Computing Base,” First International
Conference on Cloud Computing and Services Science, Noordwijker-
hout, The Netherlands, May 2011.
[14] A. Juels, J. Burton S. Kaliski, “PORs: Proofs of Retrievability for Large
Files,” Proc. of CCS 07, pp. 584597, 2007.
[15] H. Shacham, B. Waters, “Compact Proofs of Retrievability,” Proc. of
Asiacrypt 08, Dec. 2008.
[16] G. Ateniese, R. D. Pietro, L. V. Mancini, G. Tsudik, “Scalable and
Efficient Provable Data Possession,” Proc. of SecureComm 08, pp. 1
10, 2008.
