Limited Use Cryptographic Tokens in Securing Ephemeral Cloud
Servers
Gautam Kumar and Brent Lagesse
University of Washington Bothell, Computing and Software Systems, Bothell WA, U.S.A.
Keywords:
Security, Moving Target Defence, Cryptography, Cloud Architecture.
Abstract:
Many enterprises and consumers today are dependent on services deployed on Infrastructure as a Service
(IaaS) cloud providers. Such cloud deployments can have hundreds of virtual servers running. Each virtual
server needs to have access to sensitive information such as database passwords and API keys. In such as
scenario, verifying that a large number of servers have not been compromised is an arduous task. In this
paper we propose an architecture which limits the extent to which an attacker can exploit a compromised
server in a large scale cloud deployment. To achieve such a limitation we propose the use of hash chains as
an authentication mechanism for virtual server with a Central Trusted Authority (CTA) acting as a proxy to
sensitive resources. This architecture shifts the requirement of security validation from hundreds of public
facing servers to a few servers without public interfaces which comprise the CTA. Since hash chains offer
an inherent limitation in their use, our architecture leans towards using ephemeral virtual servers, thus also
providing a moving target defence.
1 INTRODUCTION
According to Microsoft (Harms and Yamartino,
2010), more than 85% of work done by enterprise
IT departments is towards infrastructure maintenance.
Cloud providers offer a solution to this by minimizing
the effort needed to purchase and maintain physical
hardware which is a unique advantage to enterprises.
But cloud infrastructure comes with its own set of
unique challenges and one of the primary concerns is
security. Many cloud providers offer computational
and storage resources on virtualized shared hardware
to maximize utilization. Thus the essence of securing
cloud systems is using multiple layers (Panwar et al.,
2011) of security to increase an attacker’s cost for tak-
ing over the system. One of the emerging layers of
security is moving target defence (Evans et al., 2011).
So in this paper on of our one of our focuses is to
increase the cost to an attacker for launching a zero-
day attack using moving target defence. According
to Bilge & Dumitras (Bilge and Dumitras, 2012), on
average, zero day attacks remain undetected for 10
months. Once zero-day attacks are disclosed, mal-
ware authors begin to utilize them multiple orders of
magnitude more frequently; however, there is often a
significant delay between notification and the deploy-
ment of patches fixing the zero-day exploit. One of
the goals of this project is to reduce the risk of sys-
tems when we are not aware of the existence of the
vulnerability.
Consider the situation where a large service
provider has a number of public facing servers with
access to a private, remote database. In the case that
one of those public facing servers is compromised by
an adversary, the data in the private database will be
vulnerable for the entire duration that the attacker has
access to the server. The goal of our work is to dras-
tically reduce the length of time that the attacker has
access. to sensitive information even when we do not
know that the attack has occurred.
In this paper we propose an implementation of
moving target defence using ephemeral servers and
a central trusted authority which acts on behalf of an
ephemeral server and proxies requests to sensitive re-
sources such as database servers, caching servers and
REST end points. Hash chains are used as an authen-
tication mechanism by the central trusted authority.
We take advantage of the limited use property of hash
chains to authenticate ephemeral servers for a limited
period of time. Hash chains are used as opposed to
a timer as it reduces link-ability and provides crypto-
graphic guarantees for its limited use.
Kumar, G. and Lagesse, B.
Limited Use Cryptographic Tokens in Securing Ephemeral Cloud Servers.
DOI: 10.5220/0006208704470454
In Proceedings of the 3rd International Conference on Information Systems Security and Privacy (ICISSP 2017), pages 447-454
ISBN: 978-989-758-209-7
Copyright
c
 2017 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
447

2 BACKGROUND
Cloud infrastructure today is characterised by three
primary classes of products. Infrastructure as a Ser-
vice or IaaS, Platform as a Service or PaaS and Soft-
ware as a Service or SaaS. IaaS providers take on
the responsibility of maintaining and securing phys-
ical hardware while organisations using IaaS are ex-
pected to maintain and secure their virtual hardware
and also their application code. Our research in this
paper is primarily focused on providing a mechanism
to improve the security for organisations who use IaaS
providers.
Hash Chains: Leslie Lamport (Lamport, 1981)
first proposed the use of hash chains in his paper on a
method for secure password authentication over an in-
secure medium. One of the properties of hash chain-
based authentication is that it has a limited use lifes-
pan. We leverage this property in our system to limit
the damage that any single compromised machine can
cause.
Threats: According to OWASP, “Sensitive data
exposure” is the one of the most critical types of se-
curity threat in web applications as of 2013 (Wich-
ers, 2014). Sensitive data exposure refers to the unin-
tended exposure of sensitive information such as pass-
words, social security numbers and date of birth. In
the context of a cloud system, sensitive information
may also include database credentials, email server
and REST API keys. These credentials are used to
authenticate cloud servers with third party services
within or outside the private cloud network. Creden-
tials are usually stored as part of configuration files or
in a server’s memory. Such credentials have a very
long life time and are sometimes valid of years. This
increases the risk of data exposure when an attacker
has a lengthy period of time within which they can
discover and exploit such credentials.
A report by Risk Based Security (Risk Based and
Security, 2014) notes that the number of data leaks
has dramatically increased from 2012 to 2013, to the
tune of $812 million. Leaking of credentials as men-
tioned earlier, could potentially grant access to mali-
cious entities within protected environments such as
a corporate network. Sensitive data exposure can also
be a consequence of other threats such as cross site
scripting (XSS) and Code Injection both of which are
considered highly critical threats based on OWASP’s
classification (Wichers, 2014).
3 PROPOSED ARCHITECTURE
Our proposed architecture consists of three primary
components. The Client Facing Server (CFS), the
Central Trusted Authority (CTA) and Sensitive Re-
sources that we’re trying protect. This is described
in figure 1.
Client Facing Servers are any servers which inter-
act with entities on a public network such as Load bal-
ancers, reverse proxies and application servers. CFSs
are assumed to be the most vulnerable to exploits by
malicious entities. To offer moving target defence and
increase the cost to an attacker, CFSs have a limited
lifetime based on the length of the hash chain. When
a hash chain expires the CFS is expected to shutdown
because it can no longer authenticate itself with the
CTA.
The Central Trusted Authority is an entity within
the corporate or private network which acts on behalf
of a CFS when a sensitive resource is requested. To
act on behalf of a CFS the CTA proxies requests to
resources such databases and external APIs and in-
cludes authenticating information required by the re-
sources. The authenticating information such as DB
Passwords and API Keys are not available to CFS.
The CTA is not publicly available and the number of
CTAs in operation is relatively small compared to the
number of CFS, it is assumed that the CTA is trust-
worthy as it will be easier to harden and monitor the
limited types of activity on CTAs. CTAs authenticate
CFS using hash chains as explained in section 3.2, and
figure 6 elaborates on the architecture of the CTA.
3.1 Assumptions
Client facing servers are assumed to be ephemeral
in our architecture. This is common in many cloud
deployments (Vaquero et al., 2011) and contributes
to the moving target nature of the security architec-
ture. Companies such as Netflix expect this behaviour
with their chaos engineering architecture (Basiri et al.,
2016). Netflix claim that this allows for higher reli-
ability of their server infrastructure. In our proposed
architecture, Client facing servers are expected to shut
down after their hash chain expires. This contributes
to their ephemeral nature and also to moving target
defence of the overall system.
3.2 CTA Architecture and
Implementation
The Central Trusted Authority consists of three pri-
mary components, A hash chain verifier, A storage
ICISSP 2017 - 3rd International Conference on Information Systems Security and Privacy
448

Figure 1: Architectural overview of the system. This figure describes the three primary modules involved. The client facing
server, The central trusted authority and a sensitive resource.
Figure 2: Architecture of the Central Trusted Authority. The CTA consists of a storage backend, a hash chain verifier and a
request proxy.
back-end and a request proxy. The CTA performs
three roles within the system, which are
• Create new hash chains
• Verify hash chains
• Proxy requests to resources
Creating a new hash chain: Hash chains are cre-
ated by iteratively hashing a secret token T , n num-
ber of times. After the hash chain is created the CTA
stores H
n
(T ) in the storage backend and returns T and
n to the client facing server. The secret token T is not
stored by the CTA. The client facing server can now
use the the secret token n number of times. This pro-
cess is detailed in Algorithm 1.
Hash chain verification: Hash chains are used
to authenticate client facing server requests which re-
quire access to a sensitive resource. The hash chain
verification is detailed in algorithm 2.
4 PERFORMANCE
Hash chain creation: In our testing of hash chain
initialization we observed a linear increase cost based
on the hash chain’s length (n). O(n) time complexity.
Algorithm 1: Generating a Hash Chain.
Data: Hash Chain secret T and Hash chain
length N
Result: Hash Chain H
N
(T )
1 i ← 1;
2 H
1
(T ) ← H(T ) ;
3 while i <= N do
4 i ← i + 1;
5 H
i
(T ) ← H(H
i−1
(T ));
6 end
7 return H
i
(T ) where i equals N ;
This is in line with our expectations for hash chain
implementations.
In our proposed architecture the uptime of a client
facing server is influenced by the hash chain length.
This is best described by the equation
U ptime =
Hash chain length
Requests per second
where U ptime is the maximum time in seconds
that a CFS can effectively operate, Hash chain length
is the size of the hash chain provided to the CFS
Limited Use Cryptographic Tokens in Securing Ephemeral Cloud Servers
449

Algorithm 2: Verification of Hash Chain authentica-
tion.
Data: Authentication key H
i−1
(T ) from the
client
Result: Response from sensitive resource
1 Let H
i
client
= H(H
i−1
(T )) ;
2 Let AuthenticationData = f etch(H
i
client
) ;
3 if AuthenticationData exists in storage backend
then
4 replace H
i
client
with H
i−1
(T ) in storage
backend ;
5 fetch and return response from sensitive
resource ;
6 else
7 return authentication failure ;
8 end
at startup while Requests per second is the aver-
age number of requests that a CFS needs to make to a
CTA.
Hash chain verification and request proxy:
Hash chain verification is a significantly faster pro-
cess, O(1), when compared to hash chain creation.
Thus performance of the CFS is impacted merely by
the delay introduced due to the request proxy.
Our testing reveals that an additional delay in the
range of 0.05 to 0.15 seconds is introduced by using
Hash chain verification and a simple implementation
of a request proxy as illustrated by figures 3 and 4.
Figure 3: Response time for requests made to a resource
through the CTA with a SHA-256 hash chain. The X-axis
is the number of concurrent requests made and the Y-axis
describes the response time in seconds.
Testing environment: Our testing environment
was based in AWS. The CTA was a pool of EC2 ma-
chines behind a elastic load balancer. Load tests were
Figure 4: Response time for requests made to a resource
directly without authenticating with the CTA. The X-axis
is the number of concurrent requests made and the Y-axis
describes the response time in seconds
Table 1: Table of terms for equation 1.
n Length of hash chain
r
req
Request rate
r
boot
Boot rate
r
pool
Pool size change rate
conducted using multiple CFSs located in the same
AWS region as the CTA. The payload requested by
the CFS was a file located on S3.
4.1 Server Pool
Creating new virtual servers to act as CFSs can be
a slow and expensive process; however, by creating
a pool of unused CFSs to act as quick replacements,
we can minimize delay for customers. The size of
the CFS pool needs to be balanced based on the time
to initialize a new virtual server, the size of the hash
chain, and the rate at which requests are made.
The relationship between pool size, hash chain
length and requests per second is illustrated by equa-
tion 1.
r
pool
= r
boot
−
r
req
n
(1)
Equation 1 describes how the change in pool size
relates to the length of the hash, the boot rate, and the
request rate. When the number of requests that have
been authenticated using a hash chain reaches the
length of the hash chain, the VM using it is no longer
functional and must be shut down and replaced. Our
system keeps a pool of VMs in reserve so that this
process is transparent to the user and no delay is no-
ticed.System designers can use this equation to min-
ICISSP 2017 - 3rd International Conference on Information Systems Security and Privacy
450

Figure 5: The upper plot shows a random request rate generated by a poisson distribution is with a lambda of 50,000 and the
lower plot describes the pool size based on equation 1.
imize the number of VMs that have to be held in re-
serve to sufficiently handle a variable load over the
course of time. Boot rate is defined as the average
number of VMs that can be instantiated in a particu-
lar period of time. Request rate is the average number
of requests that come in during a time period. This
value can change overtime as services will have dif-
ferent peak usage times during a day.
As an example consider that a company receives
50,000 requests per minute on an average day. They
want to replace their VMs every 10 minutes, so each
VM should have a hash chain with a length of 5000.
They would have to boot 1 VM every 5 minutes. Fig-
ure 5 shows how our system would keep a small pool
of VMs that would not consume significant resources,
but would also never run out when the request rates
are sampled from a poisson distribution with a lambda
of 50,000.
Part of our future work is to design an adaptive
algorithm that solves the multi-criteria optimization
problem that manages the creating of new VMs based
on learned traffic patterns.
5 SECURITY THREATS
The proposed architecture of using a Central Trusted
Authority (CTA) to proxy requests on behalf of all the
clients places the CTA as a single point of failure. We
deem this an acceptable trade-off as the CTA is not
a public facing system and only serves the purpose
of verifying hash chains and proxying requests. As a
result, hardening its defences against possible threats
becomes an easier problem. In our current implemen-
tation, the CTA is a single hardened server; however,
we are also working on a distributed implementation.
Our architecture proposal does not prescribe any
particular hardware / VM co-location for any compo-
nents in the CTA. Thus each component can be im-
plemented on separate machines or the CTA can be
instantiated as a whole within a single VM. In this
section we detail the potential security threats against
each component and possible mitigation strategies.
5.1 Malicious Request Proxy
The request proxy component acts on behalf of the
client facing server to make a call to a sensitive re-
source such as an API endpoint. The request proxy
is also responsible for attaching authentication infor-
mation such as an API Key when contacting the API
endpoint. Upon receiving a response from the sen-
sitive resource the request proxy strips out sensitive
information such as API Keys and Refresh Tokens
before forwarding the response to the client facing
server. Under this threat scenario the request proxy
is assumed to be untrustworthy and potentially mali-
cious despite the our earlier argument that this case is
unlikely.
Chen et al (Chen et al., 2012) propose a solution to
this problem of a Malicious proxy using trusted hard-
ware such as Trusted Platform Module (TPM) or the
IBM 4758 cryptographic coprocessor (Parno et al.,
2010). The CTA executable would also verified by
a trusted third party to operate correctly as a proxy as
described in (Parno et al., 2010).
There are three primary attacks that a malicious
actor may perform on the CTA. First, the attacker may
try to expose the sensitive information stored, such
as API keys and DB passwords, from the CTA us-
ing vulnerabilities in the CTA executable. Second,
the attacker could potentially modify the requests /
responses which are being proxied by the CTA. Third
the attacker could potentially launch a reboot attack to
inject a malicious executable after attestation to carry
out one of the above attacks.
Limited Use Cryptographic Tokens in Securing Ephemeral Cloud Servers
451

Figure 6: Sequence diagram describing the authentication and proxying capabilities of the CTA. CFS refers to Client Facing
Server while CTA refers to Central Trusted Authority.
Prior work (Libert and Vergnaud, 2008) (McCune
et al., 2008) on preventing reboot-attacks can be lever-
aged to impede the attacker’s ability to inject a mali-
cious executable. The proposed architecture also al-
lows for the CTA to be placed behind secure corporate
firewalls to further limit the risk of a malicious take
over by an attacker. Further work is needed to fully
secure the CTA against a malicious proxy.
6 DISCUSSIONS
6.1 Providing moving target defence
Green et al (Green et al., 2015) identify Unpre-
dictability, Vastness and Revocability as some of the
criteria for evaluating moving target defences. In this
section we try define how our implementation con-
forms to these criteria.
Unpredictability: Cryptographic hash functions
(Rogaway and Shrimpton, 2004) are designed to be
collision resistant and comply with the avalanche ef-
fect and thus the generated sequence is highly unpre-
dictable in nature. Hash chains can compound this
effect by sequential application of the cryptographic
hash function.
Vastness: A secure cryptographic hash function
such as SHA-256 has a vast state space as the output
could be any of 2
256
different values. As a result, the
likelihood of an attacker guessing the correct value is
negligible.
Revocability: The proposed architecture allows
individual chains or a group of chains to be revoked
merely by purging them from the database. Further
group / hierarchical revocability can be achieved us-
ing Merkle hash tree implementations as a means of
Hash chain generation.
6.2 CTA Alternative
In this paper we have presented our solution with a
centralized CTA and argued that in some cases this
approach is sufficient. In the case that this solution
does not work for an application, we are also explor-
ing a DHT-based proxy though we have not yet im-
plemented it. In the DHT-based solution, there would
be a large number of proxies in a DHT. Each proxy
in the DHT would be responsible for servicing a sub-
set of requests from CFS. In this solution, the DHT
would be keyed on the hash chain hash value, so the
requests would be routed to a different proxy every
time. By using a DHT-based solution, an adversary
would only be able to compromise a subset of the re-
quests, further limiting its ability to intercept targeted
information or read widespread sensitive requests.
6.3 Future Work
Formulating learning algorithms to create an adaptive
balance between server lifespan and hash chain length
to optimize computational resources in a cloud sys-
tem, this can be derived from the equations we have
derived in this paper and current work into load bal-
ancing in cloud systems (Randles et al., 2010). Such
an adaptive system could be used to choose an ideal
hash chain size and CFS pool in real time based on
the performance requirements of a cloud system.
Timed Release Cryptography (Chalkias and
Stephanides, 2006) can be integrated as a hash chain
renewal mechanism to potentially increase the lifes-
pan of a server after a certain cool off period. Im-
plementing Time Release Cryptography would en-
able our architecture to accommodate systems where
a constant pool of ephemeral servers are not available
and existing servers can be populated with a batch of
hash chains which can only be accessed after a certain
period of time.
A Merkle hash tree implementation middle-ware
ICISSP 2017 - 3rd International Conference on Information Systems Security and Privacy
452

can potentially provide hierarchical authentication au-
thorization capabilities to the CTA as illustrated by Yi
& Wang (Yi and Wang, 2012). In the scenario of an
information leak, Merkle trees would allow adminis-
trators to black list either a single or a hierarchy of
hash chains to safeguard the system.
7 RELATED WORK
There have been other systems proposed which offer
moving target defence using a temporary address or
a temporary authentication mechanism. Many tech-
nology companies have real world implementations
of the Central Trusted Authority architecture similar
to our proposal. In this section we present the most
relevant proposals and discuss how our proposed ar-
chitecture differs.
Dunlop et al (Dunlop et al., 2011) leverage the
vast address space (2
128
) of IPv6 to move the source
and destination IP addresses mid-session based on a
pre-agreed pattern to limit an attacker’s ability to in-
tercept or interfere with a TCP session. The technique
proposed by Kampanakis (Kampanakis et al., 2014),
however, operates at the network level by using an
SDN’s ability to vary the address space and the route
taken by packets to increase the cost for an attacker
and thus providing moving target defence.
Active authentication proposed by (Yiu et al.,
2011; Aksari and Artuner, 2009; Li et al., 2014) of-
fer a way to verify a user’s identity based on their
behaviour thus eliminating the need for hard to re-
member passwords. Active authentication is a form of
moving target defence where the authenticating fac-
tor is constantly changing in a hard to predict manner,
thus significantly increasing the cost for an attacker to
reproduce the authenticating factor.
Confidant (lyft, 2015) is a library maintained by
Lyft, a transportation network company based out of
San Francisco. Confidant provides an implementa-
tion of the Central trusted authority server. This sys-
tem lacks the hash chain based approach that we use
and as a result does not provide the additional mov-
ing target defence that raises the adversary’s cost of
launching an attack.
8 CONCLUSION
In this paper we propose an architecture which in-
creases the cost of exploiting vulnerabilities for an
attacker with minimal impact on performance by pro-
viding moving target defence using a pool of Client
Facing Servers (CFS) which only operate for a rela-
tively short period of time. Our architecture also sig-
nificantly hampers an attacker’s ability to steal sen-
sitive configuration information from by centralizing
configuration within a Central Trusted Authority.
We believe this approach can be used in cloud sys-
tems to limit the risk of a compromised client facing
server. Security-related software bugs are constantly
being discovered and exploited, so while we may not
be able to deploy a system that will never be compro-
mised, we can deploy defences that limit the effec-
tiveness of an attacker, even when they are utilizing a
zero-day attack.
ACKNOWLEDGEMENTS
The work presented in this paper was partially sup-
ported under US National Science Foundation Grant
DGE-1419313. The author would like to thank Vic-
toria Wettmarshausen from UW Bothell’s Writing &
Communication Center for her feedback on the struc-
ture and presentation of this paper.
REFERENCES
Aksari, Y. and Artuner, H. (2009). Active authentication
by mouse movements. In Computer and Information
Sciences, 2009. ISCIS 2009. 24th International Sym-
posium on, pages 571–574. IEEE.
Basiri, A., Behnam, N., Rooij, R. d., Hochstein, L.,
Kosewski, L., Reynolds, J., and Rosenthal, C. (2016).
Chaos Engineering. IEEE Software, 33(3):35–41.
Bilge, L. and Dumitras, T. (2012). Before we knew it: an
empirical study of zero-day attacks in the real world.
In Proceedings of the 2012 ACM conference on Com-
puter and communications security, pages 833–844.
ACM.
Chalkias, K. and Stephanides, G. (2006). Timed re-
lease cryptography from bilinear pairings using hash
chains. In Communications and Multimedia Security,
pages 130–140. Springer.
Chen, R., Reznichenko, A., Francis, P., and Gehrke, J.
(2012). Towards statistical queries over distributed
private user data. In Presented as part of the 9th
USENIX Symposium on Networked Systems Design
and Implementation (NSDI 12), pages 169–182.
Dunlop, M., Groat, S., Urbanski, W., Marchany, R., and
Tront, J. (2011). MT6d: A Moving Target IPv6 De-
fense. In 2011 - MILCOM 2011 Military Communi-
cations Conference, pages 1321–1326.
Evans, D., Nguyen-Tuong, A., and Knight, J. (2011). Ef-
fectiveness of Moving Target Defenses. In Jajodia, S.,
Ghosh, A. K., Swarup, V., Wang, C., and Wang, X. S.,
editors, Moving Target Defense, number 54 in Ad-
vances in Information Security, pages 29–48. Springer
New York. DOI: 10.1007/978-1-4614-0977-9 2.
Limited Use Cryptographic Tokens in Securing Ephemeral Cloud Servers
453

Green, M., MacFarland, D. C., Smestad, D. R., and Shue,
C. A. (2015). Characterizing Network-Based Moving
Target Defenses. In Proceedings of the Second ACM
Workshop on Moving Target Defense, MTD ’15, pages
31–35, New York, NY, USA. ACM.
Harms, R. and Yamartino, M. (2010). The economics of the
cloud. Microsoft whitepaper, Microsoft Corporation.
Kampanakis, P., Perros, H., and Beyene, T. (2014). SDN-
based solutions for Moving Target Defense network
protection. In World of Wireless, Mobile and Multi-
media Networks (WoWMoM), 2014 IEEE 15th Inter-
national Symposium on a, pages 1–6.
Lamport, L. (1981). Password authentication with inse-
cure communication. Communications of the ACM,
24(11):770–772.
Li, F., Clarke, N., Papadaki, M., and Dowland, P. (2014).
Active authentication for mobile devices utilising be-
haviour profiling. International journal of information
security, 13(3):229–244.
Libert, B. and Vergnaud, D. (2008). Tracing Malicious
Proxies in Proxy Re-encryption. In Galbraith, S. D.
and Paterson, K. G., editors, Pairing-Based Cryptog-
raphy Pairing 2008, number 5209 in Lecture Notes
in Computer Science, pages 332–353. Springer Berlin
Heidelberg. DOI: 10.1007/978-3-540-85538-5 22.
lyft (2015). Confidant: Your secret keeper. A library to
store and retrive senstive configuration within a cen-
tral trusted authority encrypted at rest using Amazon
KMS. https://github.com/lyft/confidant.
McCune, J. M., Parno, B. J., Perrig, A., Reiter, M. K., and
Isozaki, H. (2008). Flicker: An execution infrastruc-
ture for TCB minimization. In ACM SIGOPS Op-
erating Systems Review, volume 42, pages 315–328.
ACM.
Panwar, A., Patidar, R., and Koshta, V. (2011). Layered se-
curity approach in cloud. In 3rd International Confer-
ence on Advances in Recent Technologies in Commu-
nication and Computing (ARTCom 2011), pages 214–
218.
Parno, B., McCune, J. M., and Perrig, A. (2010). Bootstrap-
ping trust in commodity computers. In 2010 IEEE
Symposium on Security and Privacy, pages 414–429.
IEEE.
Randles, M., Lamb, D., and Taleb-Bendiab, A. (2010). A
Comparative Study into Distributed Load Balancing
Algorithms for Cloud Computing. In 2010 IEEE 24th
International Conference on Advanced Information
Networking and Applications Workshops (WAINA),
pages 551–556.
Risk Based and Security (2014). An Executives Guide to
2013 Data Breach Trends. Presentation, Risk Based
Security.
Rogaway, P. and Shrimpton, T. (2004). Cryptographic
Hash-Function Basics: Definitions, Implications,
and Separations for Preimage Resistance, Second-
Preimage Resistance, and Collision Resistance. In
Roy, B. and Meier, W., editors, Fast Software En-
cryption, number 3017 in Lecture Notes in Computer
Science, pages 371–388. Springer Berlin Heidelberg.
DOI: 10.1007/978-3-540-25937-4 24.
Vaquero, L. M., Rodero-Merino, L., and Buyya, R. (2011).
Dynamically Scaling Applications in the Cloud. SIG-
COMM Comput. Commun. Rev., 41(1):45–52.
Wichers, D. (2014). OWASP Top-10 2013. OWASP Foun-
dation, February.
Yi, X. and Wang, W. (2012). The Cloud Access Control
Based on Dynamic Feedback and Merkle Hash Tree.
In 2012 Fifth International Symposium on Compu-
tational Intelligence and Design (ISCID), volume 1,
pages 217–221.
Yiu, M. L., Lo, E., and Yung, D. (2011). Authentication
of moving kNN queries. In 2011 IEEE 27th Interna-
tional Conference on Data Engineering, pages 565–
576. IEEE.
ICISSP 2017 - 3rd International Conference on Information Systems Security and Privacy
454