Analysis of the Linux Random Number Generator in Virtualized Environment

Masaryk University Faculty of Informatics

Analysis of the Linux random number generator in virtualized environment

Master’s Thesis

Radka Cieslarová

Brno, Fall 2018

Declaration

Hereby I declare that this thesis is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Radka Cieslarová

Advisor: RNDr. Petr Švenda, Ph.D.

Acknowledgements

I would like to thank to my great advisor Petr Švenda for his consulting, enthusiasm and tolerance. I am also grateful to other people for their support and willingness to help, especially to Radim, Káťa and Robert.

iii Abstract

This thesis analyzes the Linux random number generator behavior in virtualized environment in two different ways. Firstly, entropy inputs to the generator are examined and their entropy is compared to the entropy of inputs in non-virtualized environment. Secondly, the Linux random number generator behavior after restoring from snapshots is analyzed to observe so-called reset vulnerabilities.

iv Keywords randomness testing, statistical test batteries, Linux random number generator, entropy, virtualized environment, VirtualBox

Contents

1 Introduction 1

2 Related work 3 2.1 Widespread weak keys in network devices ...... 3 2.1.1 Vulnerabilities ...... 3 2.1.2 Weak entropy and the LRNG ...... 5 2.2 Virtual machine reset vulnerabilities ...... 5 2.2.1 TLS client vulnerabilities ...... 6 2.2.2 TLS server vulnerabilities ...... 7

3 Randomness testing 9 3.1 Statistical randomness testing ...... 9 3.2 NIST Statistical Test Suite ...... 10 3.3 Dieharder ...... 11 3.4 TestU01 ...... 12 3.5 Randomness Testing Toolkit ...... 12

4 Generating random data in Linux 15 4.1 Function $RANDOM ...... 15 4.2 Linux random number generator ...... 15 4.2.1 Initialization ...... 16 4.2.2 Entropy collection ...... 17 4.2.3 Entropy pools update ...... 20 4.2.4 /dev/random ...... 20 4.2.5 /dev/urandom ...... 22 4.2.6 Changes to the LRNG in previous years . . . . . 23

5 Generating random data in virtualized environment 25 5.1 Access mediation to hardware resources ...... 25 5.1.1 Hardware resources not accessible to a guest . . 25 5.1.2 Hardware resources exclusively assigned to a guest ...... 25 5.1.3 Hardware resources shared between guests . . . 26 5.2 Access mediation to CPU instructions ...... 26 5.3 Entropy Sources in Linux random number generator .... 26 5.3.1 Disk I/O ...... 27

vii 5.3.2 Human input ...... 28 5.3.3 Interrupt requests ...... 29 5.3.4 Timer in Oracle VirtualBox ...... 29

6 Analysis of the LRNG entropy inputs in virtualized environment 31 6.1 Methodology ...... 32 6.2 Baseline ...... 34 6.2.1 Testing output data ...... 34 6.2.2 Testing input data ...... 35 6.3 Detailed input analysis ...... 39 6.3.1 Disk I/O ...... 39 6.3.2 Interrupt requests ...... 39 6.3.3 Human input ...... 40

7 Analysis of the LRNG within virtual machine snapshots 41 7.1 Methodology ...... 41 7.2 Results ...... 43

8 Conclusion 45

Bibliography 47

Index 51

A VirtualBox settings 51

viii 1 Introduction

Random numbers are important for many different uses – in statistics, computer simulations, and in cryptography. In cryptography, random numbers are necessary for creating initial vectors, keys, seeds, and random noise. Hence, it is important to be able to generate random data of a high quality. A widely used generator is the Linux random number generator (LRNG) from the Linux kernel. The LRNG uses several different entropy inputs, however, when used in a virtualized environment, an access to these entropy sources might be limited or modified by the virtual machine monitor. The aim of this thesis is to analyze the LRNG behavior in a virtualized environment, especially in the Oracle VirtualBox, in two different ways. Firstly, entropy inputs to the generator are examined and their entropy is compared to the entropy of inputs in a non-virtualized environment. Secondly, the Linux random number generator behavior after restoring from snapshots is analyzed to observe so-called reset vulnerabilities. The second chapter presents two papers connected to the vulnerabilities in the LRNG. The chapter shows how even a good random number generator, which the LRNG is, may generate vulnerable keys. In the first paper, vulnerable keys generated by the LRNG are caused by limited access to entropy. The second paper presents so-called reset vulnerabilities, where the LRNG virtual machines reverted from snapshots produce the same output. The third chapter focus on methods for measuring randomness, on randomness testing. Statistical randomness testing and different randomness testing suites are presented. Chapter four provides one of the most detailed descriptions of the LRNG on the Internet. A part of the LRNG was changed in 2016, thus many sources do not provide actual information about the LRNG generating mechanism. A detailed study of the LRNG was necessary for the analysis in the practical part of the thesis. The following chapter describes how is the LRNG influenced when used in the virtualized environment. The influence on all entropy

1 1. Introduction inputs is examined with a focus on virtual machine monitor Oracle VirtualBox. In chapter six, analysis of the LRNG entropy inputs in a virtualized environment are executed. Firstly, the output of the LRNG is analyzed using statistical randomness testing. The kernel is modified in such a way that it allows collecting entropy inputs. Entropy in the entropy inputs to the LRNG is measured, and finally, different sources of the entropy inputs are observed. The source code of the modified kernel is available as an electronic attachment. The last chapter examines the virtual machine reset vulnerabilities in the Oracle VirtualBox.

2 2 Related work

Significant body of research related to random data generation was published. The publications focus on different topics in this area: new generators design [1, 2, 3, 4], weak or predictable generators [5, 6], random data analysis [7], vulnerabilities caused by using problematic generators [8, 9], etc. Two most related publications that investigated issues connected to random data generation in the Linux operating system [10] and within a virtual machine [11] are presented in this chapter.

2.1 Widespread weak keys in network devices

Research Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices [10] was published in 2012. The paper focused on RSA and DSA keys, which can be vulnerable when generated by malfunctioning random number generators. Inspected keys come from TLS and SSH servers, and the researchers found out that surprisingly high amount of those keys is vulnerable. Found vulnerabilities are presented in the following section. In this research, a large network scan was performed and 5.8 million unique TLS certificates and 6.2 million unique SSH host keys were obtained. Afterwards, it was necessary to identify what hardware or software generated the obtained keys to find potentially vulnerable device models producing weak keys, and then compare keys from a specific device model.

2.1.1 Vulnerabilities Repeated keys: It was found that 61% of the TLS hosts and 65% of the SSH hosts used the same key as another host in the scan. Usually, the keys were the same due to using default keys or due to low entropy available during the key generation. Many repeated keys were due to shared hosting providers. Another cause of repeated keys were distinct certificates with the same public key, belonging to the same organization. Neither of those causes can

3 2. Related work be considered as a vulnerability, nevertheless still many vulnerable keys remain. More than 5% of the TLS hosts served default keys or certificates from the manufacturer. These keys are preconfigured in the firmware and usually, all devices of one device model share the same key pair. Private keys may be obtained by reverse engineering, or simpler from public databases of these default keys if such a database exists for the device model. In TLS, more than 0.3% hosts (43,852 hosts) served repeated keys due to low entropy during the key generation and 98% of these certificates with repeated keys were self-signed. In the case of SSH hosts, it was impossible to distinguish between default keys and repeated keys due to low entropy during key generation. However, 9.6% of the obtained SSH keys were repeated for one of these reasons. Factorable RSA keys: When two RSA keys share one of their prime factors with another key, counting GCD of these keys is simple and fast, thus it is simple to count the private keys. Based on shared prime factors, it was possible to obtain private keys of 0.4% of the TLS certificates and 0.02% of RSA SSH host keys. Most of those vulnerable keys were generated by devices from only a few different manufacturers. In one case, 576 devices from one manufacturer used keys generated only from 9 distinct prime factors. Most of the vulnerable keys were system-generated certificates and keys used by headless or embedded network devices like routers or firewalls. DSA signature weaknesses: In a case of DSA keys, the problem is with repeated ephemeral keys. When a DSA key is used to sign two different messages using the same ephemeral key, it is possible to compute the long-term private key from the public key and signatures efficiently. In the scan, 0.05% of obtained SSH DSA signatures (usually two signatures were obtained from one SSH host) contained the same r as at least one other signature and 94% of these repeated r values used the same r and public key. Based on this and using the same ephemeral key, it was possible to count private keys for 1.6% of SSH DSA hosts.

4 2. Related work

Nearly 90% of long-term key collisions were from a different host. Even if two different hosts using the same public key use the same ephemeral key, their private keys are vulnerable in the same way as if the ephemeral key was used twice by one host. In the research, tens of thousands of hosts were found to use the same public key as some other host.

2.1.2 Weak entropy and the LRNG Based on the obtained results, the researchers decided to find the root causes of the vulnerabilities due to low entropy during a key generation. They examined three open-source cryptographic software com- ponents appearing frequently in the vulnerable hosts: Linux Random Number Generator (LRNG), OpenSSL and Dropbear. Examination of the LRNG follows. The examination was done on Linux kernel version 2.6.35. The sources of entropy for this kernel version were the startup clock time in nanoseconds, human input, and disk I/O. In previous kernel versions, interrupt requests were used as another source of entropy, and they were later added again, but they were not used in kernel version 2.6.35. Headless and embedded devices, which often contained vulnerable keys, does not have any human input device, disks or multiple cores, thus the only source of entropy was startup time. The problem with headless and embedded devices might be even more serious when the device does not use a clock. In that case, there is no source of entropy and the LRNG produces deterministic output. Another problem was a boot-time entropy hole. A boot-time entropy hole is present short time after system boots when there is not sufficient amount of entropy, thus the generated keys are likely to be vulnerable. As a result of the LRNG examination, authors recommend using device /dev/random LRNG instead of /dev/urandom, which was used by all inspected open-source implementations.

2.2 Virtual machine reset vulnerabilities

Research When Good Randomness Goes Bad: Virtual Machine Reset Vul- nerabilities and Hedging Deployed Cryptography [11] was published in

5 2. Related work

2010. In the research, virtual machine reset vulnerabilities were presented and used against TLS in secure web browsing. Virtual machine snapshot is a whole copy of the machine and its internal state. Virtual machines can be restored to exactly the same state as they were at the moment of taking the snapshot, thus snapshots are used to replicate, transfer or backup virtual machines. Virtual machine reset vulnerabilities use virtual machines snapshots to replay a connection and compromise session or even obtain DSA private key from the server. Reset vulnerabilities are caused by reusing randomness stored in snapshots. Two different experiments on virtual machine reset vulnerabilities were executed, TLS client vulnerabilities and TLS server vulnerabilities. As a solution to presented vulnerabilities, authors recommend generating fresh and unused randomness for every use of a generator, for example from /dev/random or from /dev/urandom. However, it is not possible after resetting from a snapshot, because devices /dev/random and /dev/urandom have their state saved in snapshots. Another solution might be to use physical RNG connected to the client or server.

2.2.1 TLS client vulnerabilities In TLS client vulnerabilities, client machine was virtualized. Using the virtual machine for browsing the Internet might be recommended in some causes, because, in the case of downloaded malware or virus, only the virtual machine is infected. If there is a snapshot, it is possible to revert the machine state to a state before getting infected. Web browsers include TLS client which establish a session key, usually using RSA algorithm. A premaster secret is chosen by the user, and then the secret is sent to the server, encrypted with the server’s public key. Afterwards, the premaster secret is used to establish a session key. When a snapshot of the virtualized client machine is created just before sending the premaster secret and sent after snapshot creation, the session key may be compromised. This may happen only in cases when the machine is reverted to the snapshot and connected to another server, thus the same premaster key is sent to more than one servers. In executed experiments, two Apache servers using OpenSSL were run on two different physical machines. The client created a snapshot,

6 2. Related work

connected to one server using a web browser, reset the virtual machine to the snapshot, and connected to another server. For each snapshot, three iterations of resetting and connecting to both servers were done. Different web browsers were tested on Windows and Ubuntu operating systems. Premaster secrets generated for both servers were obtained and compared. All experiments were executed on virtual machine monitor Virtu- alBox and VMware, but the results were the same for both monitors. The differences were only between browsers. Firefox running on Win- dows or Ubuntu always sent the same premaster secret to both servers, Chrome only on the Ubuntu operating system. Chrome, Internet Ex- plorer and Safari on Windows never sent the same secret to different servers, but all of them in some cases sent the same premaster secret to same server.

2.2.2 TLS server vulnerabilities In TLS server vulnerabilities, Apache servers using Diffie-Hellman key exchange with DSA signature scheme for TLS were virtualized. Apache servers use OpenSSL cryptographic library for their RNG used for TLS. Entropy sources for the RNG are chosen by a configuration file and can be time stamp in seconds, process IDor /dev/random and /dev/urandom when running on a Unix-based system. When servers use the same randomness repeatedly to sign different messages, an attacker who knows the signed message and the resulting signatures can observe DSA key of the server [12]. The experiments were executed using virtual machine monitors VirtualBox and VMware for servers. Virtualized servers were run in two different settings, with and without clock synchronization between a guest and a host machine. Servers without clock synchronization were tested only on VMware. Snapshot of a server was created and then non-virtualized client connected to the server. Afterwards, ten iterations of reverting the server and connecting the client were done. Iterations were executed in two different ways, with and without restarting host machine before each trial. The randomness used by the server was observed. The virtualized server used the same randomness in several cases. In the case of VirtualBox, all observed session IDs were the same.

7 2. Related work

Servers run on VMware monitor used the same session IDs only in some trials, a higher number of same keys was noticed in monitors used without time synchronization. Servers run with time synchronization sometimes produced the same key probably due to generating the key just after reverting to the snapshot, before the clock has synchronized. Restarting host machine between trials without clock synchronization caused a lower number of same session IDs. Reverting from a snapshot was significantly slower than reverting without restarting a host, thus the lower number may be caused by bigger timing vari- ability. On the other hand, when the server running on VMware was used with time synchronization and without host restart, all observed keys were different, while with the host restart part of the keys were the same. The authors did not provide any explanation for this case.

8 3 Randomness testing

An output from a true random number generator (TRNG) is truly random data. On the other hand, an output from a pseudorandom number generator (PRNG) would never be truly random data, even from the best generator, because the generator is deterministic. How- ever, TRNGs are expensive and might be slow to be used in practice, thus PRNGs are needed. The data generated from PRNG should fulfill three requirements. Pseudorandomness: The output from the generator looks random to an attacker. In cases where an attacker does not have the knowledge of the generator’s internal state, this requirement is sufficient alone. In the case of pseudorandomness, the output from the generator should look random. Given two sequences, one from TRNG and the second one from PRNG (which fulfill the pseudorandomness requirement), it should not be possible to distinguish which sequence was generated from which generator. We say that the output from pseudorandom number generator is indistinguishable from the truly random data. Forward secrecy: In cases where an attacker knows the internal state of the generator, forward security requirement is necessary. The requirement ensures that even when an attacker learns the internal state at a certain time, from this information, she is not able to obtain any information about previous outputs of the generator. Break-in recovery/backward secrecy: Break-in recovery/backward security requirement is similar to the forward security requirement. Even an attacker knows the generator’s internal state at a certain time, this does not provide any information about the future outputs. To fulfill this condition, sufficient amount of entropy must beusedto refresh the generator’s state.

3.1 Statistical randomness testing

As was mentioned above, PRNG cannot produce truly random data. On the other hand, the data from the PRNG should look as much random as possible. The problem is, how to decide what is randomness and what should tested sequence fulfill to be considered indistinguish-

9 3. Randomness testing able from random sequence. In this section, methods for measuring randomness is presented. Randomness is a mathematical property and thus it can be charac- terized in terms of probability. A sequence is said to be random if it contains patterns or anomalies with similar probability as expected from a truly random sequence. Statistical randomness tests look for a presence of these patterns or anomalies. The tests do not claim that the sequence fulfills forward secrecy or break-in recovery/backward secrecy requirement, they are focused only on the pseudorandomness requirement. Statistical randomness tests are based on testing the null hypothesis (H0), which says that the tested sequence is random. The null hypothesis is tested against alternative hypothesis (Ha), which says that the sequence is not random. The statistical test rejects or does not reject the null hypothesis, and claim whether the sequence can be considered as random. The example of a simple statistical randomness test compares the number of ones and zeroes in a binary sequence. The ratio of ones and zeroes should be roughly the same in a random sequence. More complex test divides tested binary sequence into subsequences of a specific length (eg. 5 bits long), count number of occurrences ofeach possible subsequence value and compare this obtained distribution with expected distribution. In theory, an infinity number of statistical randomness tests canbe created. Thus, several statistical testing suites containing different statistical tests for binary sequences were designed. The widely used are NIST Statistical Test Suite [13], Dieharder [14] and TestU01 [15]. These tests can be downloaded and run on tested sequences locally. Another option is to use Randomness Testing Toolkit [16], which provides an online tool for testing randomness with these three batteries.

3.2 NIST Statistical Test Suite

NIST Statistical Test Suite (NIST STS) was created by National Institute of Standards and Technology in 2000. The suite was published as an official NIST document, hence it is used as a standard.

10 3. Randomness testing

NIST STS consisted of 16 statistical randomness tests, but during revisions, one of the tests was removed because of problems in implementation find by NIST, thus the current version contains only 15 tests. However, the run of all tests can take hours to complete, but several optimizations of this suite were published [17, 18]. The suite can obtain and test input data only as a simple file input in a binary form.

3.3 Dieharder

Current Dieharder suite comes from the original Diehard testing suite [19], which was designed by George Marsaglia in 1995 and consisted of 12 statistical tests. Current Dieharder statistical suite (version 3.31.1) is included in repositories of some Linux distributions [20] and contains 27 different tests: all original Diehard tests, three tests from NIST Statistical Test Suite and several new tests implemented by the author, Robert G. Brown. The statistical suite is open source and can be easily extended by adding new statistical tests. Morover, Dieharder suite is distributed with 63 implemented generators, but any other generators can be implemented and added. All included statistical tests can be listed within the Dieharder application. The list contains several expected fields like names of the tests or amount of data needed for each test, but also for each test an information about test reliability. The reliability contains three categories: good, suspect and do not use. Another difference between Diehard and Dieharder is a requirement in the size of tested data. Diehard used smaller files with random data, with a size of about 10 MB. Nowadays bigger files need to be tested, thus one of Dieharder suite goals was to allow testing of large files with a size in gigabytes of data. Testing bigger files allows finding small bias, which probably would not be found in smaller files. Dieharder suite supports three different ways of input data. The suite can test simple file input in a binary form, or in a file containing ASCII formatted random numbers (usually as uint). The third way is to pipe a binary stream from any PRNG or TRNG to Dieharder suite, using a standard input interface.

11 3. Randomness testing 3.4 TestU01

TestU01 is a software library implemented in the ANSI C language. The library was developed at Université de Montréal by Pierre L’Ecuyer et al. TestU01 contains statistical randomness tests from NIST STS, Dieharder, and several other tests proposed in the literature, and some original ones. Except for the tests, TestU01 contains a wide range of pseudorandom number generators in generic form, from the literature or in widely used software. The TestU01 library can be used for testing either sequence of uniform random numbers over the interval (0, 1) or binary sequences. TestU01 provides an unusual function: it performs studies of the interaction between a specific test and the structure of sequences produced by a given family of PRNGs. For a given test and a given family of PRNGs, TestU01 determine how large should be the sample size of the test, as a function of the generator’s period length, before the generator starts to fail the test systematically. Statistical tests in TestU01 are divided into ten separate batteries: Small Crush, Crush, Big Crush, Rabbit, Alphabit, Block Alphabit, PseudoDIEHARD, and FIPS_140_2. The first battery is very fast and needs only around 250 MB of data to run, while Crush and Big Crush need gigabytes of data and several hours to run. Rabbit, Alphabit and Block Alphabit does not have any requirements on the tested data size. They are designed for testing hardware bit generators, but they can test data from a binary file, either. PseudoDIEHARD battery contains tests from the original Diehard testing suite and FIPS_140_2 contains tests described in NIST FIPS 140-2 standard.

3.5 Randomness Testing Toolkit

All the statistical batteries mentioned above use a different interface, show results in a different form, and their use for randomness testing might not be easy. Hence, Randomness Testing Toolkit (RTT) was created. RTT is an online tool providing fast and user-friendly randomness testing with unified result representation. The tool provides an interface where registered users can upload their binary data. The data

12 3. Randomness testing can be tested using Dieharder, NIST STS or batteries from TestU01. It is possible to choose batteries with respective configurations for the tested data. The results are displayed in a consistent way for all three batteries, saying which batteries and also which tests failed or passed.

4 Generating random data in Linux

In Linux operating systems, there are several ways how to generate random data. The simplest way for generating random numbers is using bash function (and also a parameter) called $RANDOM [21]. Numbers generated by this method are not considered as secure, hence random data generated by system generator and stored in files /dev/random and /dev/urandom [22] are recommended to use for security purposes. Another option is downloading specialized software for generating random data.

4.1 Function $RANDOM

$RANDOM is a bash parameter, which returns a random integer from 0 to 32767. Because $RANDOM is generated only from current process ID and the current time in microseconds, it is recommended not to use this function to generate cryptographic keys and other values which should be secure. Another reason for not using this function is producing the same value when generating random numbers while booting the system. The system clock is not initialized at the time of the system boot. It is possible to seed $RANDOM to obtain more unpredictable values. However, every time the function is seeded with the same value, the output number or sequence is the same. Hence, $RANDOM is recommended to be seeded with a variable such as some function of time or main process ID.

4.2 Linux random number generator

More secure way to generate random data compared to bash function $RANDOM is to use Linux random number generator (LRNG) [23] and one of its three exported interfaces: devices /dev/random, /dev/urandom, or interface get_random_bytes(). Linux random number generator was written in 1994 by Theodore Ts’o who created the /dev/urandom Linux device node and the corre-

15 4. Generating random data in Linux sponding kernel driver [24]. Other authors contributing on the LRNG later were Matt Mackall and Jason A. Donenfeld. The device was the first Linux kernel interface providing high- quality random numbers and was firstly presented in Linux 1.3.30 version. Since its creation, /dev/random and /dev/urandom device nodes have become standard interfaces on Unix, Linux, BSD and macOS systems. The initial version of the LRNG was written in C is a part of the Linux kernel and can be found in /drivers/char/random.c file. Nowa- days, the LRNG source code is more than 2000 lines long. However, the code is not well documented, consists of hundreds of undocumented patches, and there is no official description of the whole implemented algorithm. Even the manual page for the devices /dev/random and /dev/urandom was wrong for several years. The LRNG has an internal state consisted of two pools: input pool and blocking pool. Interrupt requests, disk I/O and human input are three sources of entropy used in the LRNG to feed the input pool. Data from the input pool are then hashed and feed blocking pool or a ChaCha20 algorithm. When needed, /dev/random takes data from blocking pool and stops generating new data when the pool is ex- hausted. On the other hand, /dev/urandom and get_random_bytes() take data from the ChaCha20 algorithm, which produces new data even if the level of entropy is low.

4.2.1 Initialization When the Linux operating system is turned on, the LRNG needs to be initialized. The LRNG is fed with constant OS parameters and with information about actual time in milliseconds. These two variables can be easily predicted by an attacker; therefore more entropy sources are needed at the process of initialization. To solve this problem, the LRNG saves random seed when the system is shut down. The random seed consists of 512 bytes taken from /dev/urandom by a script which is run when the system is shut down, and the seed is saved to a file. While starting the system, a script which is run during the boot sequence makes these bytes being written back to the /dev/urandom. The process of writing to a file adds entropy to the input pool, as described above.

16 4. Generating random data in Linux

The random seed is stored in /var/lib/systemd/random-seed on systemd operating systems, in /var/lib/urandom/random-seed on non-systemd Linux operating systems, and in /var/db/entropy-file on FreeBSD. The value of the random seed is not as predictable as the other initial input to the LRNG, but anyone with the physical access to the hard disk can read the file with the seed. To prevent reusing of the same random seed when the system is not properly shut down, e. g. in power losses, a new random seed is also generated immediately after system boot, in the script run during the boot sequence. This random seed is secure against an attacker without local root access. The attacker with local root access might expose the random seed during the runtime of the operating system. Hence new random seed is generated when the system is shutting down. The script providing the whole mechanism with random seed is not part of the kernel, but it is present in Linux distributions. The authors of the LRNG recommend to add this script to Linux distribution, but as it is not a part of the kernel, the script might not be contained in all Linux distribution. An absence of such script might decrease the security of the LRNG, but fortunately the script is present in all widely used distributions like Ubuntu or Fedora. The process of initialization of the LRNG cannot be done with the random seed in live Linux distributions, as they cannot save the seed. Hence, these distributions provide random data in a less secure way than the other distributions and an attacker with complete knowledge of the start-up activities can predict the internal state of the LRNG.

4.2.2 Entropy collection The entropy is collected asynchronously from three different types of events: timing of interrupt requests, disk I/O and human input. When a hardware random number generator is present, it is used as another source. Interrupt requests as an entropy source are used only from kernel version 3.6. All the values from entropy sources are three 32 bit words. The first word is a time stamp of the event in jiffies, the second is the CPU cycles value, and the last one is a value of the event. Jiffies store the number of ticks occurred since system boot.In case the kernel has access to some architectural hardware random

17 4. Generating random data in Linux data generator, entropy from this device is also collected and used to generate random data. At a time of a system boot, one more source of randomness is used: device randomness. The function add_device_randomness() is used to add boot-specific data to the input pool, like MAC addresses or serial numbers. The device randomness does not add any entropy to the pool, it only helps to initialize the pool with different values for similar devices which may have only little entropy available to them. The disk I/O entropy is collected using interface add_disk_ran- domness(). A comment in the source code alerts that high-speed solid drives (SSD) are not good sources of disk entropy, as they have very short seek times, which are usually roughly consistent. This interface collects entropy from these sources: ∙ block device identifier, ∙ event time of disk I/O operations in jiffies, ∙ event time of interruptions, using a CPU cycles value. The block device identifier provides only a little amount of entropy, as the identifier is static for the lifetime of the system. Event time in jiffies provides only a limited amount of entropy. The last source provides almost all measured entropy from this interface. The human input collects entropy using interface add_input_ran- domness(). This interface collects entropy from these sources: ∙ pressing a key on the keyboard, ∙ mouse or touch pad movement; ∙ event time of these operations in jiffies, ∙ event time of interruptions, using a CPU cycles value. In the first two cases, it is hard to quantify the amount of provided entropy. Event time in jiffies provides again only a limited amount of entropy. The last source again provides almost all measured entropy from this interface. The human input entropy is compounded from three different values: an event type information from hardware, a code of the event, and a value of the event.

18 4. Generating random data in Linux

The last type of event, interrupt requests entropy, is collected using interface add_interrupt_randomness(). This interface feeds the randomness roughly once a second and collects entropy from these sources: ∙ the value of the instruction pointer,

∙ the register content,

∙ event time of interruptions in jiffies,

∙ event time of interruptions, using a CPU cycles value. The first three sources provide only a little amount of entropy, while almost all measured entropy if provided by the last source, CPU cycles value. The entropy is added into so-called fast_pool which is 128 bits large. The content of the fast_pool is added to the input pool approximately once per second or after processing 64 interrupts, whatever comes first. The function add_interrupt_randomness() does not collect data from all interrupt requests in the kernel. The data from predictable interrupts are omitted. The amount of provided entropy from this source is very low compared to disk I/O entropy and entropy from human input [25]. void add_disk_randomness(struct gendisk * disk) { i f(!disk || !disk −>random) return; / * f i r s t major is 1, so we get >=0x200 here * / add_timer_randomness(disk −>random, 0x100 + disk_devt(disk)); trace_add_disk_randomness(disk_devt(disk), ENTROPY_BITS(&input_pool)); } Listing 4.1: The source code of adding disk I/O randomness to the input pool. An example of source code of the interface add_disk_randomness() from kernel version 4.19 [26] can be seen in figure 4.1. In this code, the function add_timer_randomness() adds the first 32 bits large word to

19 4. Generating random data in Linux the primary pool, the time stamp of the event. The second word is added by the function trace_add_disk_randomness(). As the words are 32 bits large, expected amount of provided entropy from each word is 32 bits. However, an estimated amount of entropy is lower [27]. Keyboard events provide 256 different values, which are only 8 bits of entropy. In case of mouse events, there are 2 bits of entropy for the buttons, and another 10 bits of entropy from the mouse movement, therefore mouse events provide 12 bits of entropy together. The amount of entropy provided by disk events is based on the number of disks and their type-value. Based on the presumption that an average machine has at most 8 disks, provided amount of entropy is only 3 bits. The amount of entropy provided by interrupt events is 4 bits. The result of an interrupt occurrence is a number from 0 to 15, called interrupt request channel number (IRQ number), which can be written in 4 bits.

4.2.3 Entropy pools update As was mentioned before, the internal state of the LRNG consists of two entropy pools: input pool and blocking pool. Sizes of these pools are 4096 and 1024 bits, respectively. Based on the source code [23], the input pool is sometimes called as a primary pool, and the blocking pool as an output pool or a secondary pool. This is caused by the changes made in the source code in previous years, which are mentioned in the section 4.2.6. The entropy of all sources mentioned in the previous section is added to the input pool using mixing function, and a conservative estimated amount of entropy is added to estimate of the available entropy in the input pool. Current estimate of the available entropy in the input pool can be found in file /proc/sys/kernel/random/entropy_avail. The principle of generating data can be seen in the figure 4.1, the description follows in next sections.

4.2.4 /dev/random When program requests random data via /dev/random, these data are extracted from the blocking pool. As the amount of entropy available

20 4. Generating random data in Linux

Blocking /dev/random pool

Output request Disk I/O Interrupt requests Input Human input pool

ChaCha20 /dev/urandom

Figure 4.1: Entropy transfer in the LRNG.

in blocking pool is usually low, firstly extracting data from the input pool to blocking pool is needed. At this time, there are two possibilities to occur.

1. The input pool contains enough amount of available entropy. An output with approximately equal size to the requested amount of entropy is generated and mixed to the blocking pool. After the mixing, an amount of available entropy in both pools is updated. After the transfer, the requested random data can be produced from the blocking pool. The 160 bits large SHA-1 hash of the whole blocking pool is calculated and folded in halves. The output of the blocking pool is an exclusive or of the first and the second half of the hash. The output is provided to the user or a program and is also mixed back to the blocking pool.

2. The input pool does not contain enough amount of available entropy. Then the blocking pool blocks and does not produce any data until enough entropy is gathered.

21 4. Generating random data in Linux

The blocking pool is not fed only when the device /dev/random requests data. When the input pool is getting full, it sends some data to the blocking pool until the blocking pool is 75% full. The device /dev/random is recommended to use shortly after boot as there might not be enough entropy to properly seed /dev/urandom. /dev/random is also recommended when very high-quality randomness is required, for example for generating long-term keys or one-time pad. Theodore Ts’o said that practically no one uses /dev/random as it is deprecated [28]. He recommends to use /dev/random and getrandom() [29] system call, which uses the same sources like /dev/urandom, but getrandom(2) blocks when the initial seed entropy is not available. On the other hand, not using /dev/random when generating long- term keys, e. g. RSA keys, can have catastrophic consequences [10], as mentioned in chapter 2.

4.2.5 /dev/urandom

Till the commit pushed in the June 13, 2016 [30], device /dev/urandom does not use any special pool but only stream cipher ChaCha20. The main difference between device /dev/random and /dev/urandom is that the /dev/random device stops generating random data when the entropy is low, whereas /dev/urandom device generate random data regardless to the amount of available entropy. The first seeding of this device is the only moment when thedevice cares about the amount of entropy. The first initialization of the device needs at least 128 bits of available entropy in the input pool. The device can also be initialized with only 64 bits of entropy collected from interrupt requests, but it still needs to be seeded with 128 bits of gathered entropy from input pool to be considered as fully seeded. A level of initialization is based on variable init, which can be set to 0, 1 or 2 to be uninitialized, initialized or initialized from the input pool, respectively. When the value of init is below 2 and available entropy in the input pool is higher than 128 bits, the ChaCha20 algorithm is reseeded. After the first seeding, the generator is reseeded approximately every 5 minutes, even if the previous conditions are not fulfilled. If the init variable is 0, it is set to 1 and entropy from interrupt

22 4. Generating random data in Linux

requests is sent to the ChaCha20 algorithm. In all other cases, the generator is waiting. The output of the ChaCha20 algorithm is saved into the device /dev/urandom. The generator also provides backtrack protection. The keystream is mutated with any remaining output from the ChaCha20 algorithm which has not been given to the user. The device /dev/urandom is recommended to be used everywhere where /dev/random is not necessary. The main reason is the speed, as /dev/urandom does not block when it does not have enough entropy, it produces data much faster than device /dev/random. The Linux kernel itself uses random data for various purposes, such as generating random identifiers, computing TCP sequence numbers or producing passwords. The function get_random_bytes() is kernel interface which can be used within the kernel. Based on the comments in the source code, this function provides cryptographically secure random data suitable for key generation or seeding TCP sequence numbers. The function works on the same principle like the device /dev/urandom, but the function does not rely on any hardware random number generator.

4.2.6 Changes to the LRNG in previous years The Linux random number generator is changed and updated often. The whole kernel has tens of thousands pushed commits per year and tens of them contain changes in the LRNG, in the file random.c. Un- fortunately, the comments in the source code and manual page of the generator are not changing so often, therefore it might be sometimes outdated and untruthful, even for years. The biggest change in previous years was the removal of the non- blocking pool in commit in June 2016 [30], afterwards, from kernel version 4.8, non-blocking pool was replaced with ChaCha20-based cryptographic-strength random number generator (CRNG). In previous versions, the LRNG consisted of three pools: input pool, blocking pool and non-blocking pool. Data from the blocking pool were extracted to the /dev/random device and data from non-blocking pool were extracted to the /dev/urandom device. Both blocking and non-blocking pool used SHA-1 function, which is nowadays used

23 4. Generating random data in Linux only in blocking pool. The only difference between blocking and non- blocking pool was that the blocking pool blocked when the input pool did not have enough entropy, whereas non-blocking pool did not block. In kernel version 4.8, the non-blocking pool was replaced with ChaCha20 algorithm, but the non-blocking pool is still mentioned in the source code of kernel version 4.19.

24 5 Generating random data in virtualized environment

The goal of virtual machines is to emulate a real computer. A virtual machine may need access to many hardware resources, e.g. to PCI device, CPU, RAM, hard disk drive and a network device. The goal of a virtual machine monitor (VMM) is to mediate access to all these resources. In this chapter, firstly, access mediation to hardware resources and CPU instructions is described. The possibilities of how VMM can mediate or modify access to these resources are discussed. Secondly, mediation to entropy sources in the LRNG is explained with a focus on the Oracle VirtualBox VMM. This chapter is based on [31] and official VirtualBox documentation [32].

5.1 Access mediation to hardware resources

VMM treats to the hardware resources in three different ways, based on their accessibility to the guest.

5.1.1 Hardware resources not accessible to a guest Hardware resources are not accessible to a guest OS, but only to the VMM. The guest machine can use the hardware resource like device using a device driver, although the device exists only in software. Two methods are used for virtualization using device drivers: 1. Paravirtualization: The virtualized system use modified device drivers. 2. Full virtualization: The virtualized hardware is accessible with the same device drivers like the real physical driver.

5.1.2 Hardware resources exclusively assigned to a guest Hardware resources presented in more then one piece (like PCI cards) can be exclusively assigned to a guest. In this case, guest OS commu- nicate directly with assigned hardware.

25 5. Generating random data in virtualized environment

5.1.3 Hardware resources shared between guests The last possibility of treating the hardware resources is sharing them between guests. Usually, the VMM configures the real physical hardware in a way it can be exclusively assigned to the guest OS for a fixed amount of a time. The amount of time can be from microseconds up to months-long based on the device type and use. After the time window, the process is paused or stopped, and all requests to this hardware are reassigned.

5.2 Access mediation to CPU instructions

A guest OS sends instructions to CPU, however, not all of them can be processed. Because of this, CPU catches some of these instructions (based on predefined white list) and sends them to VMM. Thereafter, VMM decides what to do with the caught instruction. Four different ways exist for processing instructions: 1. CPU instructions, which are well defined and match white list, can be proceeded by the CPU without catching. 2. CPU instructions, which meet up predefined conditions, are caught and verified whether they comply VMM rules. If they do not pass, they cannot be proceeded and are sent back to a guest as an exception. 3. CPU instructions are caught, modified, and then send to CPU. 4. CPU instructions are caught and the instruction is done with a completely different set of operations.

5.3 Entropy Sources in Linux random number generator

As mentioned in the section 4.2.2, the LRNG uses disk I/O, human input and interrupt requests as entropy sources. All of these sources may be affected differently in different VMM. Description of suchan influence in general is followed by a description of an influence for the Oracle VirtualBox.

26 5. Generating random data in virtualized environment

In the case of time stamp, which is part of all entropy sources, it is influenced in the Oracle VirtualBox. The influence is caused byusing modified timer described in the last section.

5.3.1 Disk I/O

A part of the disk I/O entropy is a block device identifier. This data can be obtained only from a hard disk, in a case of solid state disk, the LRNG does not obtain any entropy from this source. VMM cannot affect the identifier on a hardware level, asVMM cannot modify the hardware. On the other hand, the obtained identifier provided by VMM to the guest OS can be modified in someway, or VMM may not need to even obtain the value from disk but from a different source. The different source may be performed network request or RAM disk. When the disk access is requested from the guest OS, guest kernel block layer examine whether the request can be fulfilled by its buffer cache. If it is possible, the kernel returns required data from the cache and the LRNG disk I/O is not launched. Otherwise, I/O operation is started to fulfill the request. The request to start I/O operation comes to VMM. Similar to guest OS, VMM examine whether the request can be fulfilled by its buffer cache, and based on the result, the requested data are obtained from the buffer cache or from I/O operation. In the first case, theblock device is not used, while the second case makes the hard disk to spin. VMM can also store the requested data on a device without spin- ning platters, like solid state disk or a RAM disk, and make it look like a hard disk to the guest OS.

Oracle VirtualBox VirtualBox stores its data in the VMM file system. The file system can be stored on a hard disk drive, SATA, IDE,SAS, SCSI or USB storage, and can be accessed with an emulated hard disk controller which is presented as a block device. VirtualBox is influenced by the host kernel buffer cache, which can cause avoiding LRNG disk I/O. Nevertheless, VirtualBox offers an option to disable the use of the host kernel buffer cache for a virtual storage controller.

27 5. Generating random data in virtualized environment

The Oracle does not provide more information about how Virtual- Box affects the disk I/O operations. Based on the provided information, to reduce the effect and to collect more entropy, a backing store forthe block device should be stored on a hard disk drive and the host buffer cache should be disabled.

5.3.2 Human input The human input entropy is collected from keyboard and mouse. However, some virtualized servers are run without these devices, thus no entropy is provided from human input. Some other servers, like cloud servers, are connected to keyboard and mouse, but these devices are used very rarely, so the provided entropy is very low. In a case VMM is used through RDP or VNC protocols, keyboard and mouse are used remotely and are not connected directly to the host machine. Then these protocols send keyboard or mouse events together with event time to the host machine, and these events can be proceeded in the same way like if they are not connected remotely. The problem of transmitting these events through network protocol is the possibility of eavesdropping them. The events are sent in network packets, one event per packet. As the highest amount of entropy from human input is provided by the time stamp from this entropy source, when an attacker is close to the source, he might know the time of the event. Thus, in a case of transmitting through network protocols, the human input entropy source should be considered to provide a lower amount of entropy compared to host OS without transmitting mouse and keyboard events through the network. It is technically possible to send data directly from human input to the host machine, without any modification. It is up to VMM whether it modifies these data or not.

Oracle VirtualBox VirtualBox can be used through RDP, moreover, it supports also a headless guest OS. In these cases, the human input entropy should not be considered trustworthy due to the possibility of eavesdropping. When the guest system is used on the same machine as the host system (either with or without RDP protocol), the connection is pro- tected and cannot be easily eavesdropped or altered. In these cases,

28 5. Generating random data in virtualized environment

the human input entropy source is unaffected by using VMM, with the exception for the time stamp, as discussed in section 5.3.4.

5.3.3 Interrupt requests In a non-virtualized environment, interrupts are generated by hardware, and all interrupts obtained by the kernel proceed to the LRNG. In a virtualized environment, in addition, interrupts are generated by VMM. Guest OS does not have real access to all devices it needs, so VMM emulates behavior of these devices, and these devices (even emulated) produce interrupt requests. Thus the number of interrupt requests obtained by the guest LRNG is similar to the number of interrupts from real corresponding hardware. When some hardware device is directly assigned to the guest and the device produce interrupt request, the request is sent to VMM. VMM checks whether the request is for the guest, and if so, sends the request to the guest. Within this process, the request may be modified by VMM.

Oracle VirtualBox In VirtualBox, standard Linux interrupt handling logic is used. Thus VMM is expected not to modify interrupt requests, with the exception for the time stamp. VirtualBox uses virtio [33] for paravirtualized device driver support.

5.3.4 Timer in Oracle VirtualBox All the entropy sources in VirtualBox use a modified timer, thus any modification or interference of it will interfere all the sources. VirtualBox uses two special handlers for Time Stamp Counter (TSC), one for AMD CPUs and one for Intel CPUs. VirtualBox calls real time stamp counter (RDTSC) on the host and subtracts the offset. The offset is the value of RDTSC when the guest OS was started, which cause to show the value of RDTSC in an expected manner, however, the process causes a latency, so the result time stamp is inaccurate.

6 Analysis of the LRNG entropy inputs in virtualized environment

In the previous chapter, the influence of using a virtual machine to the LRNG was described. The goal of this chapter is to analyze the behavior of the LRNG in a virtualized and non-virtualized environment and compare the differences. When analyzing output data from the LRNG in a virtualized environment, the data are expected to be indistinguishable from truly random data, as the LRNG uses stream cipher ChaCha20 and hash function SHA-1. When a good stream cipher or hash function is fed even with very non-random data with low entropy, the output of the cipher or function should look random. ChaCha20 and SHA-1 are examples of a strong cryptographic function with good confusion and diffusion properties. Therefore, sources of entropy provided as an input to the LRNG are examined in this chapter, and their randomness properties are examined. Input data collected from disk I/O, human input and interrupt requests are analyzed, respectively for each source. The last entropy source, device entropy, was not observed as it is used only when the system boots. Based on [27], expected amount of entropy of entropy sources from the LRNG even in a non-virtualized environment is low, except information about time events. This chapter shows results from two different types of experiments. In the first class of experiments, the baseline is set. In the baseline, outputs from /dev/urandom from the LRNG in a virtualized and non- virtualized environment are observed. Also, data from each entropy input is analyzed and its randomness properties and entropy are measured and compared. Each entropy input to the LRNG gathers data from several different sources, and these sources are examined in the second class of experiments, in detailed input analysis. Description of performed methodology follows.

31 6. Analysis of the LRNG entropy inputs in virtualized environment 6.1 Methodology

The process of examination entropy sources of the LRNG contains up to four steps: 1. Saving data from entropy sources to the kernel log. 2. Sorting obtained data based on its source. 3. Counting Shannon information entropy for each source. 4. Converting obtained data to a binary file to test it with statistical randomness tests. Step 3. is omitted in experiments where results from statistical testing provide sufficient information. Step 4. is omitted in experiments where was not collected enough amount of data for statistical randomness testing. The source code of the LRNG, the file random.c, was modified to save its input data to the kernel log in /var/log/kern.log file. The generator uses these data with a combination of time information to feed the input pool, but only input data, without time stamps, are observed in this thesis. For detailed input analysis, different sources for entropy inputs were marked with different flags. An example of source code of such a modified interface, especially of add_disk_randomness(), can be seen in the listing 6.1. The function printk() writes data to the kernel log. Two different values are saved, based on their source. Later, they are observed together as one entropy input to the LRNG, and then they are observed separately as different sources for disk I/O entropy input. Afterwards, the new kernel is built with the modified generator, and run within a virtual machine, and also within a non-virtualized environment for the comparison. The used VMM is VirtualBox, version 5.2.10_Ubuntur121806. The VirtualBox is used with default settings, which include SATA backing store, enabled host buffer cache and time synchronization with the host. Specific settings can be seen in the attachment A. The kernel version used is 4.19.1. After a sufficient amount of data is collected, they are sorted and divided into separate files based on the source. For each source, a

32 6. Analysis of the LRNG entropy inputs in virtualized environment value of information entropy is counted. For the experiments where statistical randomness testing is done, the data are converted to a binary format. Then the binary data are tested using the RTT and the results are interpreted in the same way as the RTT interprets them.

void add_disk_randomness(struct gendisk * disk, int flag) { i f(!disk || !disk −>random) return;

i f(flag == 1){ printk(KERN_INFO"Value11:␣%x", disk_devt(disk)); } else{ printk(KERN_INFO"Value12:␣%x", disk_devt(disk)); }

/ * f i r s t major is 1, so we get >=0x200 here * / add_timer_randomness(disk −>random, 0x100 + disk_devt(disk)); trace_add_disk_randomness(disk_devt(disk), ENTROPY_BITS(&input_pool)); } Listing 6.1: The modified source code of adding disk I/O randomness to the input pool.

Baseline experiments also analyze the output data from the LRNG. The output from the device /dev/urandom is used instead of /dev/random because of the speed. Second reason is the change in /dev/urandom algorithm, mentioned in the section 4.2.6. After the change, only few analysis of the new generator were done. The operating system used for both, a virtual machine and a host machine, is Ubuntu 18.04 LTS. The experiments are executed on a computer with Intel Core i5-8350U (1.7 GHz, TB 3.6 GHz, with support for hyperthreading), 16 GB RAM and 512 GB SSD. During the data generation, both virtual and host machine are used for many standard user operations to provide different entropy sources. These are browsing the Internet (containing writing emails,

33 6. Analysis of the LRNG entropy inputs in virtualized environment chatting on social networks, watching videos or downloading different files), viewing and editing documents or photos, watching movies, listening to music, etc.

6.2 Baseline

In the baseline, output and input data from the LRNG in virtualized and non-virtualized environment are observed and compared, using statistical randomness testing, Shannon information entropy, or both.

6.2.1 Testing output data

The output data are collected using device /dev/urandom because of its speed. Similar experiments testing output data from device /dev/random can be seen in [34], where the result was that virtualized /dev/random produce a high quality data independent on the host machine. The output data are tested with the RTT. The data are generated in two different sets, one 10 GB large, the second one only1MB. The first set is 10 GB large, to be able to run most statistical test suites provided in the RTT. With a smaller amount of data, some tests would be skipped. The data were tested on 108 tests: 27 tests from Dieharder suite, 15 from NIST STS and 66 from 5 batteries of TestU01 (Small Crush, Crush, Rabbit, Alphabit and Block Alphabit). As both sets are produced using ChaCha20, they are expected to pass most of the tests. The results are displayed in the table 6.1. The name of the test suite is written in the first column, the results for different environments are written in the following columns. The values show the number of passed tests among the number of tests in each suite. However, failing one test, the data still can be considered random [16]. Both tested data passed approximately the same number of tests and all batteries, thus the output from LRNG can be considered as not influenced by using VirtualBox, in a pseudorandomness point of view.

34 6. Analysis of the LRNG entropy inputs in virtualized environment

non-virtualized virtualized Dieharder 26/27 27/27 NIST STS 15/15 15/15 Small Crush 10/10 9/10 Crush 32/32 32/32 Rabbit 15/16 15/16 Alphabit 4/4 3/4 Block Alphabit 4/4 4/4 Table 6.1: Results from 10 GB of the LRNG outputs.

The second set is only 1 MB large, to be comparable with results from entropy input data, which were also tested with 1 MB large files. The files are not bigger, as the input data are generated slowly, and for some inputs, it may take weeks to generate 1 MB of data. The data were tested on 35 tests: 11 tests from Dieharder suite and 24 from 3 batteries of TestU01 (Rabbit, Alphabit and Block Alphabit). More tests cannot be executed due to a small size of tested files. The results are displayed in the table 6.2.

non-virtualized virtualized Dieharder 10/11 11/11 Rabbit 16/16 16/16 Alphabit 4/4 4/4 Block Alphabit 4/4 4/4 Table 6.2: Results from 1 MB of the LRNG outputs.

The results are very similar to testing 10 GB of data, still, all batteries passed and no significant differences between data generated ina virtualized and non-virtualized system were observed.

6.2.2 Testing input data For each entropy input, 1 MB of data was collected from non-virtualized and virtualized environment and tested on the RTT. Afterwards, Shan- non information entropy was counted for each entropy input.

35 6. Analysis of the LRNG entropy inputs in virtualized environment

The data were generated on the machine using SSD, thus no data from disk I/O entropy input were obtained from the non-virtualized machine. As a backing store for the block device, VirtualBox uses files stored in the VMM file system. Thus the backing store can be stored ona hard disk drive, SATA, IDE, SAS, SCSI or USB storage, and can be accessed with an emulated hard disk controller which is presented as a block device. Based on the section 5.3.1, in the case a host machine uses a SSD, the guest machine still would collect entropy from this source as the emulated hard disk controller is presented as a block device in VirtualBox. Thus the virtualized machine collects significant amount of data from disk I/O. The results from the RTT from the non-virtualized machine can be seen in the table 6.3 and from the virtualized machine in the table 6.4.

human input interrupt requests Dieharder 0/11 0/11 Rabbit 1/16 0/16 Alphabit 0/4 0/4 Block Alphabit 0/4 0/4 Table 6.3: Results from entropy inputs from the non-virtualized machine.

disk I/O human input interrupt requests Dieharder 0/11 0/11 0/11 Rabbit 0/16 1/16 1/16 Alphabit 0/4 0/4 0/4 Block Alphabit 0/4 0/4 0/4 Table 6.4: Results from entropy inputs from the virtualized machine.

All tested sequences from both, virtualized and non-virtualized, machines failed all statistical batteries and most tests from them. Con- currently, there was not observed any significant reason between sequences from different machines, even from different entropy inputs.

36 6. Analysis of the LRNG entropy inputs in virtualized environment

The LRNG uses a specific entropy amount counter. However, the counter only conservatively estimates the amount of entropy present in the input pool. The estimation is done in a complicated way, counting with expected entropy of obtained data and data sent to /dev/urandom and /dev/random. Thus, to perform more detail analysis, the LRNG entropy estimation cannot be used. Instead, Shannon information entropy is counted for each tested data from separate values, which were saved to the kernel log. Information entropy of random variable X is measured as the negative logarithm of the probability mass function for the value.

n H(X) = − ∑ pi * log2 pi i=n

In the formula, n is number of different values and pi is the probability of occurrence of the i-th possible value. The results are displayed in bits in the table 6.5.

non-virtualized virtualized disk I/O - 0* human input 12.7 9.6 interrupt requests 2.7 1.2 Table 6.5: Information entropy of entropy inputs. The asterisk means that the information entropy was not exactly zero, but approximately 0.00005.

Despite statistical randomness tests, results from information entropy are different for the non-virtualized and virtualized environment. Information entropy is higher for the non-virtualized environment, thus the virtualization probably influences the amount of provided entropy. In the case of disk I/O entropy input, the asterisk means that the information entropy was not exactly zero, but approximately 0.00005. The reason for such low value was that only two different values (from 232 possible as the data are 32 bits long) were collected from this input. Based on [27], the highest information entropy is expected from human input, especially 20 bits, follows entropy from interrupt request with 4 bits and disk I/O with 3 bits. Information entropy from collected

37 6. Analysis of the LRNG entropy inputs in virtualized environment values is different than expected, but human input entropy in either non-virtualized or virtualized environment is significantly higher then entropy from another entropy sources, as expected. It is important to mention that collecting 1 MB of data from each input takes a different amount of time for each input and environment. The amount of time was influenced by slightly different usage of both machines, as it was not possible to do exactly the same stuff (e. g. pressing the same key on the keyboards the same number of times) on both machines. Amount of time needed to collect 1 MB of data from each input is displayed in the table 6.6.

non-virtualized virtualized disk I/O - 8 hours human input 5 days 19 days interrupt requests 7 days 18 days Table 6.6: An amount of time needed to collect 1 MB of data.

As mentioned in chapter 4.2.2, the highest amount of entropy from each entropy input is not provided by the values but by the time stamps. Thus even the disk I/O input generates only two different values from block device identifiers, this source together with its time stamps provides considerable amount of entropy for the LRNG in the virtualized environment. The amount of collected data from human input and interrupt requests was significantly smaller in a non-virtualized environment. The smaller amount was expected due to lower performance observed in KVM VMM [35], and in Xen Cloud Platform and older version of VirtualBox [34]. A short experiment was executed to validate the results for human input and interrupt requests. Both environments were running for two hours and similar standard user operations were done on them. Afterwards, information entropy was counted from collected entropy inputs. Obtained results were similar to results from longer experiments: non-virtualized environment produced little bit higher value of information entropy than virtualized, and the amount of collected data was 2× bigger for the non-virtualized environment from human input, and 2.5× bigger for interrupt requests.

38 6. Analysis of the LRNG entropy inputs in virtualized environment 6.3 Detailed input analysis

Detailed input analysis was executed to look deeper into the entropy inputs. Each entropy input collects data from several different sources and in this section, information entropy of these sources is measured and compared. Human input collects data from approximately 100 different sources, thus different methodology was used to measure its sources entropy.

6.3.1 Disk I/O Disk I/O entropy is collected from different two sources: Small Com- puter Systems Interface (SCSI) queuing library, which is located at /drivers/scsi/scsi_lib.c, and /block/blk-core.c handling all read or write requests to block devices. The results comparing the provided information entropy from those two sources can be seen in the table 6.7. The comparison was done only for the virtualized environment, as the non-virtualized machine uses only SSD and no disk I/O entropy was collected.

virtualized scsi_lib.c 0.00005 blk-core.c 0.00000 Table 6.7: Disk I/O entropy inputs.

The SCSI queuing library produce a similar amount of information entropy as the whole disk I/O entropy input, while the handler of all read or write requests produce no entropy, as the produced value is still the same. The SCSI library was the source of 60% of collected data, while the handler produced 40% of the data.

6.3.2 Interrupt requests Entropy from interrupt requests is collected from three different sources: Virtual Machine Bus (VMBus) used for VMM Hyper-V located at /drivers/hv/vmbus_drv.c, an interrupt handling core located at /kernel/irq/handle.c, and an interrupt handler for Direct Mode in Hyper- V located at /drivers/hv/hv.c.

39 6. Analysis of the LRNG entropy inputs in virtualized environment

Both VMBus and interrupt handler for Direct Mode are used only for Hyper-V VMM, thus the only one source which can be observed using VirtualBox or non-virtualized machine is the interrupt handling core. As the interrupt handling core is the only source used for interrupt request, the result values of information entropy provided are the same as in table 6.5.

6.3.3 Human input Entropy collected from human input originates from a high quantity of sources, thus the collected data were observed in a different way. Three different event parameters come as an input to the human input entropy source and a result value from these parameters is counted and added to the input pool. The parameters are a type, code, and value of the event. Event types group codes under a logical input construct. Event codes define the precise type of event, e.g. whether the value comes from keyboard or mouse. A detailed description can be seen in official kernel documentation in [36]. In baseline experiments, only the result value was observed. The result value is counted from event type, code and value as follows: (type « 4) ^ code ^ (code » 4) ^ value. Results can be seen in the table 6.8, the result value which is added to the input pool is in the last row. non-virtualized virtualized type 1.4 1.6 code 2.5 3.1 value 12.6 8.8 result 12.7 9.6 Table 6.8: Information entropy in human input parameters.

Most information entropy is obtained from the event value in both non-virtualized and virtualized environment. Information entropy from non-virtualized and virtualized environment slightly differs, in cases of types and codes, more information entropy is present in the virtualized environment, on the other hand, probably more information entropy from values causes the higher result information entropy in a non-virtualized environment.

40 7 Analysis of the LRNG within virtual machine snapshots

Virtual machine snapshots are used to replicate, backup, transfer or reset the machine. The problem with restoring the machine from a snapshot is reusing the same randomness to generating keys, nonce and more security related material, which can lead to a so-called reset vulnerabilities [11]. Previous research focuses mainly on RNG generators in OpenSSL used in TLS [11] or on the LRNG on servers without human input devices, thus the entropy sources were limited [37]. Using snapshots in a virtualized environment with access to all entropy sources is not as common and would not have as catastrophic consequences as in servers with limited entropy sources, however, reset vulnerabilities still can be a threat to these environments. Any research examining reset vulnerabilities in a virtualized environment with access to all entropy sources was not executed. In this chapter, reset vulnerabilities in a virtualized environment with access to all entropy sources are examined. The output of the device /dev/urandom is observed. Four different experiment types are executed. Two experiments are done on virtual machines with time synchronization with the host machine and two without, as time stamps provide the highest amount of entropy for each entropy input. Both experiments were executed either with or without host reset between restoring from snapshots, because the host reset may affect the amount of entropy [11]. Description of performed methodologies follows.

7.1 Methodology

Output data from the device /dev/urandom are observed in conducted experiments. The experiments are launched on the VirtualBox with the same settings as mentioned in previous chapter and described in the attachment A, on the same device. The same modified kernel in version is used is 4.19.1, and the operating system is again Ubuntu 18.04 LTS.

41 7. Analysis of the LRNG within virtual machine snapshots

The problem is, how to collect data just after reverting from a snapshot, and how to distinguish between data collected before and after the reverting. In the [37], authors used a script running in virtual machine, which can detect reverting from a snapshot. The script is based on comparing the value of RDTSC time stamp with a value obtained a few milliseconds before. If the difference between these two values is higher then a specific threshold, it means that the previous RDTSC value was obtained more then a few milliseconds before the current one. Thus the virtual machine was probably reverted from a snapshot between obtaining two time stamps. However, the RDTSC is modified in the VirtualBox, as described in the section 5.3.4, thus the time stamp is obtained with latency, and the exact moment of reverting from a snapshot cannot be detected. Another option is to modify the script in such a way that it uses only guest system time instead of the RDTSC. However, this method also does not work as time synchronization with the host operating system takes several seconds or minutes after reverting from snapshot in the VirtualBox VMM. Thus different methodology is used. In the virtual machine, reading first 16 bytes from /dev/urandom is performed in infinite while- loop, and the collected data are both written to a file and to the standard output. The speed of reading data in this way was approximately 5.3 KB per second. At the same time, the kernel log is displayed in live view in terminal such that the last collected values can be seen. While running the reading while-loop, a snapshot is taken. While the snapshot is taking, the virtual machine is paused, and the last collected random data before the snapshot can be read from the standard output. Then, the machine is reverted from the snapshot in ten trials for each of the four experiment setting iteration. Data are collected for a few seconds in each trial. During the collection, nothing else is done on the guest and even on the host machine, there is no human input and the only running program is the VirtualBox on the host machine, and generating script and command viewing the kernel log on the guest. Collected data are saved, and afterwards, the data are compared. In the comparison, a count of the same collected random data is observed for each experiment settings, for both generated output from

42 7. Analysis of the LRNG within virtual machine snapshots

/dev/urandom and entropy sources from the log. Experiment settings description follows. Default VirtualBox configuration without host restart: Tested virtual machine is used with default settings, which includes enabled time synchronization. The machine is reverted from the snapshot, data are collected, and then the machine is turned off. Default VirtualBox configuration without host restart: The experiments are conducted similarly to the previous settings. Moreover, the host machine is restarted between new reverting from the snapshot. VirtualBox without time synchronization and host restart: The virtual machine has disabled time synchronization with the host machine. Thus the virtual machine’s time is the same after reverting from the snapshot. However, as the time synchronization takes some time, the results are expected to be similar to results from machine with time synchronization. VirtualBox without time synchronization and with host restart: The virtual machine has disabled time synchronization with the host machine and the host machine is restarted between new reverting from the snapshot. The first two experiment settings revert from the same snapshot. Another snapshot is used for both experiments without time synchronization, because the machine use different configuration with disabled time synchronization.

7.2 Results

The obtained results are similar for all experiment settings. For both experiments with time synchronization, the first 39 of 16 bytes values from /dev/urandom were exactly the same for all 20 trials. Then all values were distinct. Similar results were observed in experiments without time synchronization, where the first 19 values were exactly the same andall further values were distinct. There are two possible explanation for all these the same values:

1. The values were generated after reverting from the snapshot.

43 7. Analysis of the LRNG within virtual machine snapshots

2. The values were generated before taking the snapshot.

As generating 39 or 19 values takes only microseconds, and due to similar published experiments where have never been all values the same, we assume the second possibility real. The data were probably generated before the snapshot was taken, however, they were not already written to the standard output. In observed entropy inputs after reverting from snapshots, the results from all 40 trials were very similar and almost no differences were observed between different experiment settings. After reverting from the snapshot, within both experiment settings with time synchronization, the first 15 collected values were from disk I/O entropy input. All those values were the same for all trials, even their time stamps from the kernel log were the same. In the settings with disabled time synchronization, the first 14 values were the same. All the 15 or 14 values were collected very fast, within less than two milliseconds, thus they are expected to be collected just before the snapshots were taken. In the kernel log, these values are followed by a short pause. The pause is from 5 ms up to 20 ms long, and after that, interrupt request is generated. Only two different interrupt request values occurs, however, all 40 time stamps are distinct, thus they feed the input pool with different event time values. As a result, in such a modified kernel used in the VirtualBox, the virtual machine reset vulnerabilities were not observed.

44 8 Conclusion

In this work, a behavior of the LRNG in a virtualized environment was analyzed. In the beginning, related work to the thesis topic was presented. Af- terwards, the statistical randomness testing was described and several randomness testing suites were introduced. The most important and contributive chapter from the theoreti- cal part was a detailed description of the LRNG. The description is one of the most comprehensive descriptions of actual LRNG. Several comprehensive LRNG descriptions were published, however, most of them characterize outdated versions of the LRNG. In the following chapter, the influence of a virtualized environment on the LRNG was explained. In the practical part, the entropy inputs to the LRNG and its output in a virtualized environment were observed and compared to a non- virtualized environment. The pseudorandomness properties of the output are not influenced in a virtualized environment, however, the amount of entropy provided by entropy inputs is lower in a virtualized machine for the human input and interrupt requests. These sources are also collected slower in a virtualized environment. On the other hand, whereas a non-virtualized system using SSD does not collect any entropy from disk I/O, the virtualized system collects a big amount of data from this source. Even the disk device identifier from these data have very low Shannon information entropy, the highest amount of entropy is from time stamps, thus the disk I/O source is a good entropy source. The last part of the thesis focuses on reset vulnerabilities after the machine reverts from a snapshot. The reset vulnerabilities were not observed in executed experiments. In the future work, analysis of the LRNG entropy inputs in different VMM might be done to see the differences not only between virtualized and non-virtualized environment but even between different VMM. Also, a research focusing on the modified timer in the VMM might show how the time stamps are influenced in the virtualized environment.

Bibliography

1. MATSUMOTO, Makoto; NISHIMURA, Takuji. Mersenne twister: a 623-dimensionally equidistributed uniform pseudo-random number generator. ACM Transactions on Modeling and Computer Simula- tion (TOMACS). 1998, vol. 8, no. 1, pp. 3–30. 2. MARSAGLIA, George; ZAMAN, Arif. A new class of random number generators. The Annals of Applied Probability. 1991, pp. 462–480. 3. SUNAR, Berk; MARTIN, William J; STINSON, Douglas R. A provably secure true random number generator with built-in tolerance to active attacks. IEEE Transactions on computers. 2007, vol. 56, no. 1. 4. PIRONIO, Stefano et al. Random numbers certified by Bell’s theorem. Nature. 2010, vol. 464, no. 7291, pp. 1021. 5. GOLDBERG, Ian; WAGNER, David. Randomness and the Netscape browser. Dr Dobb’s Journal-Software Tools for the Professional Program- mer. 1996, vol. 21, no. 1, pp. 66–71. 6. STAMOS, Alex; BECHERER, Andrew; WILCOX, Nathan. Cloud computing models and vulnerabilities: Raining on the trendy new pa- rade. BlackHat USA. 2009. 7. BENDAT, Julius S; PIERSOL, Allan G. Random data analysis and mea- surement procedures. IOP Publishing, 2000. 8. GUTTERMAN, Zvi; MALKHI, Dahlia. Hold your sessions: An attack on Java session-id generation. In: Cryptographers’ Track at the RSA Conference. 2005, pp. 44–57. 9. Vulnerability note vu925211: Debian and ubuntu openssl packages contain a predictable random number generator [online]. 2008 [visited on 2018-12-04]. Available from: https://www.kb.cert.org/vuls/id/ 925211/. 10. HENINGER, Nadia; DURUMERIC, Zakir; WUSTROW, Eric; HALDER- MAN, J. Alex. Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices. In: USENIX Security Symposium. 2012, p. 1.

47 BIBLIOGRAPHY

11. RISTENPART, Thomas; YILEK, Scott. When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities and Hedging Deployed Cryptography. In: NDSS. 2010. 12. BELLARE, Mihir; GOLDWASSER, Shafi; MICCIANCIO, Daniele. “Pse- udo-random” number generation within cryptographic algorithms: The DDS case. In: Annual International Cryptology Conference. 1997, pp. 277–291. 13. RUKHIN, A.; SOTO, J.; NECHVATAL, J.; SMID, M.; BARKER, E. A statistical test suite for random and pseudorandom number generators for cryptographic applications [online]. 2001 [visited on 2018-12-04]. Avail- able from: http : / / www . nist . gov / manuscript - publication - search.cfm?pub_id=906762. Technical report. DTIC Document. 14. BROWN, R. G. Dieharder: A Random Number Test Suite [online]. 2004. Version 3.31.1 [visited on 2018-12-04]. Available from: http://phy. duke.edu/~rgb/General/dieharder.php. 15. L’ECUYER, P.; SIMARD, R. TestU01: AC library for empirical testing of random number generators. ACM Transactions on Mathematical Software (TOMS) [online]. 2007, vol. 33, no. 4, pp. 22 [visited on 2018-12-04]. Available from: http : / / www . iro . umontreal . ca / ~lecuyer/myftp/papers/testu01.pdf. 16. OBRÁTIL, Ľubomír. The automated testing of randomness with multiple statistical batteries [online]. 2017 [cit. 2018-12-04]. Master’s thesis. Masaryk University, Faculty of Informatics, Brno. 17. SUCIU, Alin; NAGY, Iszabela; MARTON, Kinga; PINCA, Ioana. Par- allel implementation of the NIST statistical test suite. In: Intelligent Computer Communication and Processing (ICCP), 2010 IEEE Interna- tional Conference on. 2010, pp. 363–368. 18. SÝS, Marek; ŘÍHA, Zdeněk. Faster randomness testing with the NIST statistical test suite. In: International Conference on Security, Privacy, and Applied Cryptography Engineering. 2014, pp. 272–284. 19. MARSAGLIA, George. The Marsaglia random number CDROM includ- ing the diehard battery of tests of randomness [online]. 1995 [visited on 2018-12-04]. Available from: https://web.archive.org/web/ 20160125103112/http://stat.fsu.edu/pub/diehard/.

48 BIBLIOGRAPHY

20. BROWN, R. G. dieharder(1) – Linux man page [online]. Version 3.31.1 [visited on 2018-12-04]. Available from: https://linux.die.net/ man/1/dieharder. 21. $RANDOM source code [online]. Version 4.0 [visited on 2018-08-06]. Available from: http://www.bashcookbook.com/bashinfo/source/ bash-4.0/variables.c. 22. random(4) – Linux manual page [online]. 2017 [visited on 2018-12-04]. Available from: http://man7.org/linux/man-pages/man4/random. 4.html. 23. random.c – A strong random number generator [https://github.com/ torvalds/linux/blob/master/drivers/char/random.c]. GitHub. 24. DODIS, Yevgeniy; POINTCHEVAL,David; RUHAULT, Sylvain; VERG- NIAUD, Damien; WICHS, Daniel. Security analysis of pseudo-random number generators with input:/dev/random is not robust. In: Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security. 2013, pp. 647–658. 25. MÜLLER, Stephan. Linux random number generator—a new approach. 2017. Available also from: http://www.chronox.de/lrng/doc/ lrng.html. 26. LINUS TORVALDS. Linux kernel [https://github.com/torvalds/ linux]. GitHub, 2018. Version 4.19. 27. GUTTERMAN, Zvi; PINKAS, Benny; REINMAN, Tzachy. Analysis of the linux random number generator. In: Security and Privacy, 2006 IEEE Symposium on. 2006, 15–pp. 28. LKML: Theodore Ts’o: Re: [RFC PATCH v12 3/4] Linux Random Number Generator [online] [visited on 2018-12-04]. Available from: https: //lkml.org/lkml/2017/7/20/993. 29. getrandom(2) – Linux manual page [online]. 2017 [visited on 2018-12-04]. Available from: http : / / man7 . org / linux / man - pages / man2 / getrandom.2.html. 30. random.c – A strong random number generator [https://github.com/ torvalds/linux/commit/e192be9d9a30555aae2ca1dc3aad37cba4- 84cd4a]. GitHub, 2016.

49 BIBLIOGRAPHY

31. MÜLLER, Stephan; KRUMMECK, Gerald; KURTH, Helmut. Analysis of random number generation in virtual environments. In: 2016. 32. Oracle VM VirtualBox [online]. Version 4.0 [visited on 2018-08-06]. Available from: https://www.virtualbox.org/manual/. 33. Virtual I/O Device (VIRTIO) Version 1.0 [online]. Version 1.0 [visited on 2018-12-04]. Available from: http://docs.oasis-open.org/ virtio/virtio/v1.0/virtio-v1.0.html. 34. FERNANDES, Diogo AB; SOARES, Liliana FB; FREIRE, Mário M; INÁCIO, Pedro RM. Randomness in virtual machines. In: Utility and Cloud Computing (UCC), 2013 IEEE/ACM 6th International Conference on. 2013, pp. 282–286. 35. KUMARI, Rashmi. Analysis of Linux Random Number Generator in Vir- tualized Environment. 2015. PhD thesis. University of Calgary. 36. Event codes [online] [visited on 2018-12-04]. Available from: https: //www.kernel.org/doc/Documentation/input/event-codes.txt. 37. EVERSPAUGH, Adam; ZHAI, Yan; JELLINEK, Robert; RISTENPART, Thomas; SWIFT, Michael. Not-so-random numbers in virtualized Linux and the Whirlwind RNG. In: Security and Privacy (SP), 2014 IEEE Symposium on. 2014, pp. 559–574. 38. BERNSTEIN, Daniel J. How to find smooth parts of integers. 2004. Available also from: http://cr.yp.to/papers.html. 39. SÝS, Marek; MATYÁŠ, Vashek. Randomness Testing: Result Interpre- tation and Speed. In: The New Codebreakers. Springer, 2016, pp. 389– 395. 40. MARTON, Kinga; SUCIU, Alin. On the interpretation of results from the NIST statistical test suite. SCIENCE AND TECHNOLOGY. 2015, vol. 18, no. 1, pp. 18–32. 41. LACHARME, Patrick; ROCK, Andrea; STRUBEL, Vincent; VIDEAU, Marion. The linux pseudorandom number generator revisited. 2012. 42. MURDOCH, Duncan J; TSAI, Yu-Ling; ADCOCK, James. P-values are random variables. The American Statistician. 2008, vol. 62, no. 3, pp. 242–245.

50 A VirtualBox settings

Name: Ubuntu Groups: / Guest OS: Ubuntu (64-bit) UUID: 8ac9735d-495b-4525-a8f2-4720a05096c8 Config file: /home/user/VirtualBox VMs/Ubuntu/ Ubuntu.vbox Log folder: /home/user/VirtualBox VMs/Ubuntu/Logs Hardware UUID: 8ac9735d-495b-4525-a8f2-4720a05096c8 Memory size: 8192MB Page Fusion: off VRAM size: 16MB CPU exec cap: 100% HPET: off Chipset: piix3 Firmware: BIOS Number of CPUs: 1 PAE: off Long Mode: on Triple Fault Reset: off APIC: on X2APIC: on CPUID Portability Level: 0 CPUID overrides: None Boot menu mode: message and menu Boot Device (1): Floppy Boot Device (2): DVD Boot Device (3): HardDisk Boot Device (4): Not Assigned ACPI: on IOAPIC: on BIOS APIC mode: APIC Time offset: 0ms RTC: UTC Hardw. virt.ext: on Nested Paging: on

51 A. VirtualBox settings Large Pages: off VT-x VPID: on VT-x unr. exec.: on Paravirt. Provider: Default Effective Paravirt. Provider: KVM State: powered off (since 2018-12-11T00:18:02.00) Monitor count: 1 3D Acceleration: off 2D Video Acceleration: off Teleporter Enabled: off Teleporter Port: 0 Teleporter Address: Teleporter Password: Tracing Enabled: off Allow Tracing to Access VM: off Tracing Configuration: Autostart Enabled: off Autostart Delay: 0 Default Frontend: Storage Controller Name (0): IDE Storage Controller Type (0): PIIX4 Storage Controller Instance Number (0): 0 Storage Controller Max Port Count (0): 2 Storage Controller Port Count (0): 2 Storage Controller Bootable (0): on Storage Controller Name (1): SATA Storage Controller Type (1): IntelAhci Storage Controller Instance Number (1): 0 Storage Controller Max Port Count (1): 30 Storage Controller Port Count (1): 1 Storage Controller Bootable (1): on IDE (1, 0): /home/user/.config/VirtualBox/VBoxGuest- Additions_5.2.18.iso (UUID: 98f63e5f-9217-4bf9-9982-338c5de4365c) SATA (0, 0): /home/user/VirtualBox VMs/Ubuntu/Snapshots/ {460fde4b-0260-46b7-9795-b9f25d164d93}.vmdk (UUID: 460fde4b-0260-46b7-9795-b9f25d164d93) NIC 1: MAC: 08002732ADD7, Attachment: NAT, Cable

52 A. VirtualBox settings connected: on, Trace: off (file: none), Type: 82540EM, Reported speed: 0 Mbps, Boot priority: 0, Promisc Policy: deny, Bandwidth group: none NIC 1 Settings: MTU: 0, Socket (send: 64, receive: 64), TCP Window (send:64, receive: 64) NIC 2: disabled NIC 3: disabled NIC 4: disabled NIC 5: disabled NIC 6: disabled NIC 7: disabled NIC 8: disabled Pointing Device: USB Tablet Keyboard Device: PS/2 Keyboard UART 1: disabled UART 2: disabled UART 3: disabled UART 4: disabled LPT 1: disabled LPT 2: disabled Audio: enabled (Driver: PulseAudio, Controller: AC97, Codec: AD1980) Audio playback: enabled Audio capture: enabled Clipboard Mode: disabled Drag and drop Mode: disabled VRDE: disabled USB: enabled EHCI: disabled XHCI: disabled

USB Device Filters: Bandwidth groups: Shared folders: Guest: Configured memory balloon size: 0 MB