Tải bản đầy đủ - 0trang
1 Security Requirements -- A New Threat Model
Hybrid WBC: Secure and Eﬃcient White-Box Encryption Schemes
The works of Chow et al.  and their successors implicitly assume that there
is a part of the encryption process, called external encoding, which is performed
outside of the encryption device and cannot be accessed by the white-box adversary. Such an assumption is not realistic in scenarios where the entire encryption
process is implemented in software.
Instead, we propose the following threat model, which is relevant in a wide
variety in realistic scenarios. Assume that the same white-box encryption scheme
is used in many devices, with at most a small diﬀerence between them (e.g., a
unique identiﬁcation number that is used in the encryption process). Further,
assume that the adversary can mount an ‘expensive’ white-box attack on at
most a few devices (e.g., by purchasing them and then analyzing in depth), and
he is willing to break the encryption of all other devices. Formally, we assume
that the adversary has a white-box access to several devices from the family and
only black-box access to all devices in the family. Using the white-box access,
the adversary can obtain full information on the devices he took control of. His
goal is to break the encryption schemes of all other devices. Thus, the security
goal in this model can be thought of as minimizing the damage from one-time
Our threat model is well suited for IoT environment. IoT devices are usually manufactured in a production line simply assembling ﬂash memories with
the same binary programmed including cryptographic keys, i.e. the same cryptographic keys are shared across multiple devices. This is because it would be quite
expensive to embed separate keys into each device either in production lines or
by consumers; additional key-embedding process and related key management,
as well as adding UX layers to IoT devices, generally require considerable cost.
In such an IoT environment, an adversary may implement the white-box attack
for a single device, and try to compromise the whole system using the obtained
key or any critical information, along with capabilities from the conventional
We note that this threat model does not ﬁt for all applications of white-box
cryptography. However, it seems relevant in suﬃciently many scenarios for being
Performance and Cost Requirements
While industry accepts the need in strong security of the algorithms, it is often
the case that practical eﬃciency considerations are prioritized by commercial
users over security considerations. Hence, if we want to design a primitive that
will be employed in practice, we should take into account the main practical
requirements from the industry point of view.
The main two design criteria we concentrate on are the following:
Reasonable performance. Previously suggested white-box algorithms except
the SPACE family are 12 to 55 times slower than AES. White-box primitives
have thus been used to protect relatively small sizes of data. We aim at using
the white-box primitive to protect large amounts of data, and so, the encryption
speed must be reasonably fast – ideally, almost as fast as the AES.
J. Cho et al.
Low transition cost. The new architecture should be designed so as to minimize the modiﬁcation of the existing development or manufacturing process
related to cryptographic implementations. Interestingly, this may be the most
important factor for commercial adoption in reality.
The practical requirements listed above lead to the following design considerations.
First, if we use a white-box algorithm to encrypt each block of the message
then the performance of the resulting encryption scheme is the same as that of the
white-box algorithm. For most of the currently existing white-box algorithms,
this means that the scheme is very slow. Moreover, even for the SPACE family
whose members are not so slow, standard ‘software obfuscation techniques’ aimed
at protecting the security of the running code, make the encryption process much
slower, and thus too slow for our purposes. As a result, it is desirable to use the
white-box algorithm to encrypt only part of the message blocks, and encrypt
most blocks with a ‘classical’ algorithm.
Second, almost all existing solutions for data protection in data communication such as SSL, TLS and SSH are based on a shared secret (e.g. session
key). Designers of some solutions for data communication want to apply this
session key in white-box encryption with minimum modiﬁcation of their cryptographic implementation. However, they cannot use this key directly in a whitebox scheme since the initiation of a white-box algorithm is slow and in general
is separate from running environment. In addition, in many cases users request
a certiﬁcate algorithm to be used in their implementation. Hence, we aim at
applying a session key directly in the components of our scheme, except the
Third, the most eﬀective way to minimize the damage from one-time compromise is to encrypt each message by a one-time key which is protected by
white-box algorithms. However, managing these one-time keys is a big burden
and existing key exchange protocols do not provide a one-time session key. Thus,
we will encrypt the nonce by a white-box algorithm and use it in the encryption
process as a replacement for a one-time key.
The New Primitives
General Structure and Security Goals
Our primitives use two separate keys – one for a white-box primitive and another
for a ‘classical’ encryption algorithm (e.g., AES), where the white-box algorithm
is only used for encryption of a nonce (e.g. initial vector (IV) or a counter) while
the classical algorithm is used for encryption of plaintexts. The keys K1 and K2
are assumed to be permanent and may be shared by many devices, while the
nonce in changed in every encryption session.
Hybrid WBC: Secure and Eﬃcient White-Box Encryption Schemes
We restrict the use of our scheme to encrypting messages of length at most
264 blocks in a single session (i.e. without rekeying). Furthermore, as common
in nonce-based algorithms, we do not allow re-use of the nonce.
The security level we aim at is data complexity of 264 and memory and time
complexities of 280 . That is, any white-box attack that can recover the secret
key K1 , or distinguish our scheme from random, or recover part of the plaintext
in a non-compromised session, should require either more than 264 messages, or
more than 280 time or more than 280 memory.
The New Hybrid White-Box Schemes
In this subsection we present two new hybrid white-box schemes, which – according to our preliminary analysis – are secure in the white-box model.
Fig. 1. F-CTR-WBC: a white-box variant of AES-CTR with a 256-bit block and a
The ﬁrst scheme, called F-CTR-WBC and presented in Fig. 1, is similar to
the standard CTR mode of operation using the AES block cipher, but with three
diﬀerences. First, a counter CTR is encrypted using a white-box primitive (e.g.,
white-box-AES or a member of the SPACE family). Second, the scheme contains
a feed-forward operation (in order to thwart a trivial attack in the white-box
model presented in ). Third, the block length is increased to 256 bits (e.g., by
using Rijndael-256 instead of AES), in order to make a time-memory tradeoﬀ
attack presented in  infeasible. Our experiments show that this scheme is only
1.3 times slower than AES-CTR.
The second scheme we propose, presented in Fig. 2, is a bit more complex,
using AES with feed-forward also in the counter update function. If the full
AES is used in both layers of the scheme, it is almost two times slower than
F-CTR-WBC with Rijndael-256. However, as the upper layer is used mainly
to reduce the relation between consecutive inputs to the second-layer AES and
their relation to the initial CT R, it is actually suﬃcient to use 3-round AES-128
in the upper layer. As a result, this scheme has roughly the same performance
like F-CTR-WBC presented above.
Initial security analysis of both schemes is presented in .
J. Cho et al.
Fig. 2. UF-CTR-WBC: a two-layered variant with feed-forwards
1. Biryukov, A., Bouillaguet, C., Khovratovich, D.: Cryptographic schemes based on
the ASASA structure: black-box, white-box, and public-key (extended abstract). In:
Sarkar, P., Iwata, T. (eds.) ASIACRYPT 2014, Part I. LNCS, vol. 8873, pp. 63–84.
Springer, Heidelberg (2014)
2. Bogdanov, A., Isobe, T.: White-box cryptography revisited: space-hard ciphers. In:
Proceedings of Computer and Communications Security (CCS 2015), pp. 1058–1069.
3. Cho, J., Choi, K.Y., Dunkelman, O., Keller, N., Moon, D., Vaidberg, A.: Hybrid
WBC: Secure and Eﬃcient White-Box Encryption Schemes, IACR eprint report
4. Chow, S., Eisen, P., Johnson, H., Van Oorschot, P.C.: White-box cryptography and
an AES implementation. In: Nyberg, K., Heys, H. (eds.) SAC 2002. LNCS, vol.
2595, pp. 250–270. Springer, Heidelberg (2003). doi:10.1007/3-540-36492-7 17
5. Gilbert, H., Plˆ
ut, J., Treger, J.: Key-recovery attack on the ASASA cryptosystem with expanding S-boxes. In: Gennaro, R., Robshaw, M. (eds.) CRYPTO 2015,
Part I. LNCS, vol. 9215, pp. 475–490. Springer, Heidelberg (2015). doi:10.1007/
Moving in Next Door: Network Flooding
as a Side Channel in Cloud Environments
Yatharth Agarwal1 , Vishnu Murale2 , Jason Hennessey3(B) , Kyle Hogan3 ,
and Mayank Varia3
Phillips Academy, Andover, USA
Buckingham Browne & Nichols School, Cambridge, USA
Boston University, Boston, USA
Abstract. Co-locating multiple tenants’ virtual machines (VMs) on the
same host underpins public clouds’ aﬀordability, but sharing physical
hardware also exposes consumer VMs to side channel attacks from adversarial co-residents. We demonstrate passive bandwidth measurement to
perform traﬃc analysis attacks on co-located VMs. Our attacks do not
assume a privileged position in the network or require any communication between adversarial and victim VMs. Using a single feature in the
observed bandwidth data, our algorithm can identify which of 3 potential YouTube videos a co-resident VM streamed with 66 % accuracy. We
discuss defense from both a cloud provider’s and a consumer’s perspective, showing that eﬀective defense is diﬃcult to achieve without costly
under-utilization on the part of the cloud provider or over-utilization on
the part of the consumer.
Keywords: Cloud privacy · Encrypted communication analysis
work virtualization · Side channel · Traﬃc analysis
In response to an increasingly digital age, researchers have developed cryptographic protocols to protect cyber-privacy. However, the gap between protocols’
physical implementations and the theoretical context in which they are usually considered introduces the potential for side channel attacks. Side channels
are ﬂows of information exposed by the physical implementation of a system
and typically not included in any proofs of security . For example, despite
the encryption SSH performs on each keystroke, Song et al. extracted about 1
bit of information per pair of keystrokes from timing information on when the
keystrokes were sent .
Y. Agarwal and V. Murale are equally contributed.
c Springer International Publishing AG 2016
S. Foresti and G. Persiano (Eds.): CANS 2016, LNCS 10052, pp. 755–760, 2016.
DOI: 10.1007/978-3-319-48965-0 56
Y. Agarwal et al.
The rise of cloud computing exacerbates the threat that side channels pose.
Cloud providers issue customers virtual machines (VMs), often co-locating diﬀerent customers’ VMs to increase resource utilization and amortize costs. Thus, a
customer’s VM may be placed on the same host as a diﬀerent, potentially adversarial VM. Ristenpart et al. and others have shown that a co-resident adversary
can leverage this sharing of a physical platform, particularly the shared caches,
to compromise the isolation of a victim’s VM [5,7].
Our contributions. This paper examines the network interface side channel. We
empirically demonstrate load measurement and behavior proﬁling on two commercial cloud environments: DigitalOcean and the Massachusetts Open Cloud.
Our raw data collection component is available in an open-source repository.1
Our experimental setup involves a malicious VM, denoted Flooder, that
saturates the network interface to put its bandwidth in contention with that of
the targeted co-resident customer’s VM, Victim. Data from test trials helped
calibrate Flooder’s observations to estimate Victim’s load over time. Such
data can be used to determine when a competitor’s traﬃc spikes or learn statistics about a cloud environment that doesn’t publish its utilization.
The raw data becomes more valuable when paired with encrypted communications analyses to determine, for example, which website Victim is visiting.
After test trials had trained a classiﬁcation algorithm, we showed the algorithm
could identify which YouTube video Victim was streaming with 66 % accuracy
compared to 33 % for random guessing. This result represents a macro-approach
relying on estimating bandwidth instead of the usual micro-approach of collecting individual packets. Thus, we do not require Flooder to have a privileged
position on the network or any kind of aﬃliation with the cloud provider.
By contrast, previous work was conducted on local testbeds and furthermore
required a malicious client to remain connected to Victim on the order of seconds
to reliably measure throughput . This limited potential targets to web or media
servers that oﬀered large downloads publicly. The single long connection cannot
be substituted simply with short, repeated ones if Victim uses DDoS protection.
Our threat model imposes no such restriction.
We consider two cloud tenants: an honest Victim and a malicious Flooder. As
the name suggests, Flooder sends as many packets as the network can process;
various choices for packet sizes, sleep times, and internet protocols are described
in Sect. 3.
We assume that the cloud provider is a trusted entity whose switch usage
data isn’t directly published. Additionally, we assume that the cloud provider is
unaﬃliated with adversaries, so Flooder cannot directly request co-residency
with Victim. However, researchers have demonstrated indirect achievement of
co-residency with speciﬁc victims on commercial clouds [1,4,7]. Therefore, we
Moving in Next Door: Network Flooding as a Side Channel
presume here that co-residency is achievable and build from there. We consider
Environment A. Victim and Flooder occupied diﬀerent MacBook Pros
connected via ethernet to the same LAN network. Both Victim and
Flooder connected to clients over the internet via a 10 MB/s downlink.
Environment B. Victim and Flooder occupied diﬀerent physical Sun
v20z servers running Ubuntu 16.04 x64, and both connected to clients on the
same LAN via a dedicated switch capable of a throughput of 12 MB/s.
Environment C. Victim and Flooder ran as diﬀerent processes on a
$10/mo VM running Ubuntu 14.04 x64 on DigitalOcean, a production cloud.
Both connected to clients on diﬀerent VMs in the same data center, NYC-2.
Environment D. Victim and Flooder occupied co-located m1.medium
VMs running Ubuntu 14.04 x64 on the Massachusetts Open Cloud (MOC),
a production cloud environment. Both connected to diﬀerent clients with a
throughput on the order of 40 MB/s.
With an increase in Victim’s network activity, we observed a corresponding
decrease in Flooder’s throughput in all four environments described above,
including two production clouds. We conﬁrmed an inversely linear relationship
and, on the basis of test runs, calibrated a tool to output an estimate for Victim’s
load based on Flooder’s observations (see Fig. 1).
Data collection used TCP instead of UDP. UDP sent packets fast enough
to congest the network and thus achieved very low goodput. Having Flooder
sleep between transmissions of UDP packets improved goodput until a point,
Fig. 1. Inverse linear relationship between Victim’s and Flooder’s throughput (in
green and blue respectively). Left shows data collected in Environment C; Right
shows data collected in Environment D. Right additionally overlays (in red) Flooder
throughput in a follow-up trial without Victim activity. Note that the ﬂuctuations in
Flooder’s throughput due to Victim’s activity are distinguishably larger than those
caused by unrelated environmental factors. (Color ﬁgure online)
Y. Agarwal et al.
after which goodput decreased again. We were not able to saturate the network
interface enough with UDP for Victim’s and Flooder’s bandwidth to be in
Data was collected using 4000-byte packets as we determined this packet
size resulted in the most consistent bandwidth across trials. Consistency in the
bandwidth aids in distinguishing ﬂuctuations in Flooder’s bandwidth caused
by Victim’s activity from those caused by unrelated environmental factors. Even
then, environmental noise was signiﬁcantly higher in Environment D than in
Environments A, B, and C.
Correlating data gathered from side channels with known behaviors makes the
data much more meaningful. We demonstrate that the continuous estimate of
Victim’s load from our tool in the previous section can serve as a foundation
for encrypted communication analysis.
We considered the case of streaming 4K YouTube videos and observed ‘bandwidth ﬁngerprints’ unique to the video being streamed (see Fig. 2(a)). Variable
bitrate (VBR) technology, which lets a higher bitrate be allocated to more complex segments of media ﬁles, contributes to this phenomenon .
We trained our classiﬁcation algorithm on 60 trials of 3 diﬀerent videos using
the feature of delays between bandwidth dips. After recursively weighing the
importance of the dips, we ﬁt the learning data with 75 % accuracy. On a new
set of 60 trials, the trained algorithm achieved an accuracy of 66 % compared to
the 33 % accuracy of random guessing (see Fig. 2(b)).
(a) Victim load while streaming the same (b) ROC curves for our algorithm (“33-66”
video in multiple trials.
curve represents random classiﬁcation).
Fig. 2. Classiﬁcation of YouTube video in environment A.
This result attests to the feasibility of determining which YouTube video
Victim streamed with passive load measurement in the cloud as well as of applying other encrypted communication analysis attacks like those demonstrated by
Dyer, Miller and others [3,6,9,10].
Moving in Next Door: Network Flooding as a Side Channel
Counter-Measures and Future Vision
Each of the three agents that participate in this paper’s threat model (the cloud
provider, the victim, and the adversary) face trade-oﬀs in defending or executing
the presented attack.
A Cloud Provider’s Perspective. A provider has incentive to protect the privacy
of customers’ information as loss of trust translates into loss of business. However,
this can be at odds with overall utilization and thus the economies of scale oﬀered
by the cloud. Perfect co-resident isolation could be achieved, for example, by
dedicating a network port to each VM, but this would be prohibitively expensive,
especially for VMs that are relatively small compared to the host. Future work
exploring this tradeoﬀ would seek to identify what level of network isolation
is required (such as switch- or hypervisor-based methods) to render network
ﬂooding attacks ineﬀective in speciﬁc scenarios.
A second approach would be to automatically detect ﬂooding activity within
the cloud. Cloud providers could then thwart the attack by terminating suspicious VMs, migrating them to another host, or rate limiting their traﬃc. Each
option comes with its own tradeoﬀs: terminating a VM without notice could violate service level agreements, migrating VMs could be prohibitively costly and
would not prevent the VM from attacking any tenants on its new host, and rate
limiting would need to balance network utilization with privacy protection.
A Customer’s Perspective. A tenant on a cloud can thwart attackers’ attempts
by preventing them from becoming co-located with his or her VMs . To achieve
this, he or she can provision VMs so as to consume the resources of an entire
physical host or take advantage of host isolation options like Amazon EC2’s
Dedicated Hosts. Many clouds including the MOC allow customers to create
aﬃnity groups which preferentially co-locate their own machines. Alternatively,
customers can try to mask their signal by adding bandwidth noise, though this
can be diﬃcult to do eﬃciently and might incur additional costs .
An Adversary’s Perspective. Improving the presented attack encompasses
increasing the accuracy and precision of the data gathered via the ﬂooding
technique as well as improving the analysis of that data. Using UDP instead
of TCP to ﬂood Victim promises improvements due to UDP’s statelessness,
allowing increased control over packet timing and size. Additionally, having a
malicious client connect directly to Victim, as done in , would help to control for environmental ﬂuctuation in Flooder’s client’s throughput. To work
around provider rate limits, a promising avenue of research includes micro-bursts,
ﬂooding for brief periods of time, as well as using multiple Flooders working
together. In terms of analysis, a more intelligent classiﬁer trained on a greater
number of features would allow for more accurate YouTube video identiﬁcation, especially as the number of videos Victim could potentially have streamed
Y. Agarwal et al.
Acknowledgements. We would like to acknowledge the MIT PRIMES program and
thank in particular Dr. Slava Gerovitch and Dr. Srini Devadas for their support. We are
also grateful to Boston University, the Hariri Institute, and the Massachusetts Open
Cloud. This paper is based upon work supported by the National Science Foundation
under Grants No. 1414119 and 1413920.
1. Bates, A.M., Mood, B., Pletcher, J., Pruse, H., Valafar, M., Butler, K.R.B.: Detecting co-residency with active traﬃc analysis techniques. In: Proceedings of the 2012
ACM Workshop on Cloud Computing Security, pp. 1–12. ACM (2012)
2. Chen, S., Wang, R., Wang, X., Zhang, K.: Side-channel leaks in web applications:
a reality today, a challenge tomorrow. In: Proceedings of the 2010 IEEE Symposium on Security and Privacy, SP 2010, pp. 191–206. IEEE Computer Society,
3. Dyer, K.P., Coull, S.E., Ristenpart, T., Shrimpton, T.: Peek-a-boo, i still see you:
why eﬃcient traﬃc analysis countermeasures fail. In: Proceedings of the 2012 IEEE
Symposium on Security and Privacy, SP 2012, pp. 332–346. IEEE Computer Society, Washington (2012)
4. Herzberg, A., Shulman, H., Ullrich, J., Weippl, E.R.: Cloudoscopy: services discovery and topology mapping. In: Proceedings of the 2013 ACM Cloud Computing
Security Workshop, CCSW 2013, pp. 113–122. ACM (2013)
5. Liu, F., Yarom, Y., Ge, Q., Heiser, G., Lee, R.B.: Last-level cache side-channel
attacks are practical. In: 2015 IEEE Symposium on Security and Privacy, pp. 605–
622, May 2015
6. Miller, B., Huang, L., Joseph, A.D., Tygar, J.D.: I know why you went to the clinic:
risks and realization of HTTPS traﬃc analysis. CoRR abs/1403.0297 (2014)
7. Ristenpart, T., Tromer, E., Shacham, H., Savage, S.: Hey, you, get oﬀ of my cloud:
exploring information leakage in third-party compute clouds. In: Proceedings of the
2009 ACM Conference on Computer and Communications Security, pp. 199–212.
8. Rohatgi, P.: Side-channel attacks. In: Handbook of Information Security, Threats,
Vulnerabilities, Prevention, Detection, and Management, vol. 3. Wiley (2006)
9. Song, D.X., Wagner, D., Tian, X.: Timing analysis of keystrokes and timing attacks
on SSH. In: 10th USENIX Security Symposium. USENIX (2001)
10. Wright, C.V., Ballard, L., Monrose, F., Masson, G.M.: Language identiﬁcation of
encrypted voip traﬃc: Alejandra y roberto or alice and bob? In: Proceedings of
16th USENIX Security Symposium, SS 2007, pp. 4:1–4:12. USENIX Association,
Abidin, Aysajan 284, 335, 615
Aceto, Giuseppe 737
Agarwal, Yatharth 755
Akiyama, Mitsuaki 521
Al-Ibrahim, Naser 713
Al-Kazaz, Noor R. 36
Alomair, Basel 265
Aly, Abdelrahaman 284, 615, 743
Anima, Bashira Akter 692
Azarderakhsh, Reza 88
Beato, Filipe 681
Belyaev, Kirill 383
Brezo, Félix 192
Buccafurri, Francesco 719
Budianto, Enrico 731
Canard, Sébastien 299, 594
Chen, Hua 3
Chen, Liqun 467
Chen, Yu-Jia 637
Cheng, Chen-Mou 637
Cho, Jihoon 749
Choi, Kyu Young 749
Chow, Richard 731
Chueh, Di-Chia 637
Cleemput, Sara 615
Colajanni, Michele 626
Dai, Tianxiang 651
de los Santos, Sergio 192
Derler, David 211
Dimitriou, Tassos 713
Ding, Jonathan 731
Dunkelman, Orr 749
El Bansarkhani, Rachid
Emura, Keita 228
Fan, Limin 3
Feng, Jingyi 3
Ferretti, Luca 626
Gao, Si 3
Grossklags, Jens 670
Grothe, Martin 159
Halpin, Harry 176
Halunen, Kimmo 681
Hanaoka, Goichiro 228
Harizi, Wafa 400
Hasanuzzaman, Md 692
Hayasaka, Kenichiro 350
Hennessey, Jason 755
Hirano, Takato 350
Hiruta, Shohei 521
Hogan, Kyle 755
Horst, Matthias 159
Hsu, Yuan-Che 637
Igier, Mathilde 701
Iovino, Vincenzo 585
Irvine, Sean A. 36
Ishida, Ai 228
Iwamoto, Mitsugu 350, 500
Jager, Tibor 159
Jalali, Amir 88
Jao, David 88
Jasim, Mahmood 692
Kaffel-Ben Ayed, Hella 400
Kaneko, Kali 176
Kaufmann, Thierry 573
Kawai, Yutaka 350
Keller, Nathan 749
Kim, Eunkyung 435
Koseki, Yoshihiro 350
Koziel, Brian 88
Krenn, Stephan 211
Laguillaumie, Fabien 299
Laing, Thalia M. 467
Lax, Gianluca 719
Leontiadis, Iraklis 419
Li, Ming 419
Longa, Patrick 124