Tải bản đầy đủ - 0 (trang)
1 Security Requirements -- A New Threat Model

1 Security Requirements -- A New Threat Model

Tải bản đầy đủ - 0trang

Hybrid WBC: Secure and Efficient White-Box Encryption Schemes


The works of Chow et al. [4] 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 difference between them (e.g., a

unique identification 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 flash 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

black-box model.

We note that this threat model does not fit for all applications of white-box

cryptography. However, it seems relevant in sufficiently many scenarios for being

considered specifically.


Performance and Cost Requirements

While industry accepts the need in strong security of the algorithms, it is often

the case that practical efficiency 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 modification of the existing development or manufacturing process

related to cryptographic implementations. Interestingly, this may be the most

important factor for commercial adoption in reality.


Design Strategies

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 modification 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 certificate algorithm to be used in their implementation. Hence, we aim at

applying a session key directly in the components of our scheme, except the

white-box algorithm.

Third, the most effective 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 Efficient 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

feed-forward operation

The first 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

differences. 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 [3]). 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 tradeoff

attack presented in [3] 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 sufficient 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 [3].


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.

ACM (2015)

3. Cho, J., Choi, K.Y., Dunkelman, O., Keller, N., Moon, D., Vaidberg, A.: Hybrid

WBC: Secure and Efficient White-Box Encryption Schemes, IACR eprint report

2016:679 (2016)

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/

978-3-662-47989-6 23

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’ affordability, but sharing physical

hardware also exposes consumer VMs to side channel attacks from adversarial co-residents. We demonstrate passive bandwidth measurement to

perform traffic 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 effective defense is difficult 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 · Traffic analysis


· Net-


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 flows of information exposed by the physical implementation of a system

and typically not included in any proofs of security [8]. 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 [9].

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 different customers’ VMs to increase resource utilization and amortize costs. Thus, a

customer’s VM may be placed on the same host as a different, 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 profiling 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 traffic 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 classification 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 affiliation 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 [1]. This limited potential targets to web or media

servers that offered 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

unaffiliated with adversaries, so Flooder cannot directly request co-residency

with Victim. However, researchers have demonstrated indirect achievement of

co-residency with specific 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

4 scenarios.

Environment A. Victim and Flooder occupied different 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 different 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 different processes on a

$10/mo VM running Ubuntu 14.04 x64 on DigitalOcean, a production cloud.

Both connected to clients on different 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 different clients with a

throughput on the order of 40 MB/s.


Load Measurement

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 confirmed 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 fluctuations in

Flooder’s throughput due to Victim’s activity are distinguishably larger than those

caused by unrelated environmental factors. (Color figure 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 fluctuations in Flooder’s bandwidth caused

by Victim’s activity from those caused by unrelated environmental factors. Even

then, environmental noise was significantly 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 fingerprints’ 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 files, contributes to this phenomenon [2].

We trained our classification algorithm on 60 trials of 3 different videos using

the feature of delays between bandwidth dips. After recursively weighing the

importance of the dips, we fit 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 classification).

Fig. 2. Classification 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-offs 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 offered

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 tradeoff would seek to identify what level of network isolation

is required (such as switch- or hypervisor-based methods) to render network

flooding attacks ineffective in specific scenarios.

A second approach would be to automatically detect flooding activity within

the cloud. Cloud providers could then thwart the attack by terminating suspicious VMs, migrating them to another host, or rate limiting their traffic. Each

option comes with its own tradeoffs: 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 [7]. 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

affinity groups which preferentially co-locate their own machines. Alternatively,

customers can try to mask their signal by adding bandwidth noise, though this

can be difficult to do efficiently and might incur additional costs [3].

An Adversary’s Perspective. Improving the presented attack encompasses

increasing the accuracy and precision of the data gathered via the flooding

technique as well as improving the analysis of that data. Using UDP instead

of TCP to flood 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 [1], would help to control for environmental fluctuation in Flooder’s client’s throughput. To work

around provider rate limits, a promising avenue of research includes micro-bursts,

flooding for brief periods of time, as well as using multiple Flooders working

together. In terms of analysis, a more intelligent classifier trained on a greater

number of features would allow for more accurate YouTube video identification, 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 traffic 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,

Washington (2010)

3. Dyer, K.P., Coull, S.E., Ristenpart, T., Shrimpton, T.: Peek-a-boo, i still see you:

why efficient traffic 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 traffic analysis. CoRR abs/1403.0297 (2014)

7. Ristenpart, T., Tromer, E., Shacham, H., Savage, S.: Hey, you, get off 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.

ACM (2009)

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 identification of

encrypted voip traffic: Alejandra y roberto or alice and bob? In: Proceedings of

16th USENIX Security Symposium, SS 2007, pp. 4:1–4:12. USENIX Association,

Berkeley (2007)

Author Index

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

Gavin, Gérald



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

Tài liệu bạn tìm kiếm đã sẵn sàng tải về

1 Security Requirements -- A New Threat Model

Tải bản đầy đủ ngay(0 tr)