A Guideline on Pseudorandom Number Generation (PRNG) in the IoT

07/23/2020 ∙ by Peter Kietzmann, et al. ∙ Freie Universität Berlin Hamburg University of Applied Sciences 0

Security and trust are essential building blocks for the emerging Internet of Things (IoT)-both heavily rely on ubiquitously available crypto primitives with integrity and robustness. In the constrained IoT, this is a challenging desire due to limited availability of memory, CPU cycles, energy, and external data sources. Random input forms such a central crypto primitive that is used virtually everywhere, but hard to obtain on deterministically operated real-time devices without user interface. In this paper, we revisit the generation of randomness from the perspective of an IoT operating system that needs to support general purpose or crypto-secure random numbers. We analyse the potential attack surface, derive common requirements, and discuss the potentials and shortcomings of subsystems in current IoT OSs. A systematic evaluation of current IoT hardware components and popular software generators based on well-established test suits and on experimental performance measurements give rise to a set of clear recommendations on how to build such a random subsystem and which generators to use.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 12

page 15

page 22

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

Random numbers are essential in computer systems to enfold versatility and enable security. Almost every operating system (OS) provides ways to generate random numbers. Unfortunately, misconceptions about randomness are common in the design and implementation of operating systems [1]. With this work, we want to shed light on the ever confusing concept of randomness and guide the design of systems that operate constrained embedded devices.

The emerging Internet of Things (IoT) is under way introducing large quantities of resource-constrained, embedded devices (i.e., Class 0 to Class 2 [2]) to the wild. They connect via standard protocols to clouds or cloudlets on the global Internet. Often they communicate autonomously via interfaces that are wireless and require protection. Common methods of self-organization and secure communication heavily rely on random input.

Starting from Class 1, IoT nodes more and more utilize an operating system instead of bare metal firmware. Over a dozen open and closed source systems exist that can operate various classes and types of devices. Our work is motivated from the heart of the RIOT system design. RIOT [3] contributes randomness to standard networking [4], security [5], resource management [6], and other user functions. Random numbers are required in almost all security components to generate or perpetuate secrets such as encryption keys or cypher streams.

In the literature, a “random sequence” is often referred to with the definition by D. H. Lehmer:

A random sequence is a vague notion […] in which each term is unpredictable to the uninitiated and whose digits pass a certain number of tests traditional with statisticians.   [7]

True random sequences are generated from random physical processes such as thermal noise, manufacturing inaccuracies, or crystal drift. Current personal computers extend such sources to sound or video input, disk drives, user keystrokes, or other as proposed by the IETF [8]. These interfaces do not necessarily exist on embedded devices. There may be complementary sources for gathering random input such as antenna noise or sensor measurements. Still, collecting random values is often difficult and resource-intensive because underlying processes are slow or do not output continuously. Furthermore, the use of additional hardware components during runtime increases energy consumption.

Pseudo-random number generators (PRNG) are deterministic algorithms that output sequences with random properties. They require a truly random seed as input in order to be unpredictable. If properly seeded, these generators expand a comparably short seed value into a long sequence of random numbers [9] while discontinuing to depend on (physical) random processes. Using a PRNG also reduces the attack surface for adversaries with physical device access. On low-cost embedded platforms, however, it is hard to generate a qualified seed if suitable hardware resources are missing. This raises a major challenge for the operating system, as it needs to abstract the hardware without sacrificing functionality.

In this paper, we explore the building blocks for proper randomness in the constrained Internet of Things. We start from the attack surface (§ II) and discuss the requirements that emerge for random number generation (§ III) and its embedding into a random IoT-OS subsystem (§ IV). The major contribution of this paper follows with the systematic testing and performance evaluation of common hardware and software generators on IoT platforms. First, we recap the statistical test suites (§ V) and then analyze popular off-the-shelf random number hardware along with a seed generator based on PUFs (Physically unclonable functions) (§ VI). Second, we perform analogous tests and evaluations for pseudo-random number generating software (§ VII) and deduce recommendations for general purpose and crypto-secure generators in the IoT. Comparing hardware and software performance properties and resource consumptions leads us to further conclusions on how to combine and jointly deploy these different components (§ VIII). We summarize four clear recommendations that immediately apply in practice in the conclusions (§ IX).

Overview of this paper
§ II II Attack Surface of the IoT Random Subsystem
§ III III Generating Randomness in the IoT
§ IV IV Randomness in IoT Operating Systems: Requirements and Related Work
§ V V Statistical Test Suites for Random Numbers
§ VI VI Hardware Generated Random Numbers
§ VII VII Software Generated Pseudo-Random Numbers
§ VIII VIII Hardware or Software Generated Randomness in the IoT?
§ IX IX Conclusions and Outlook

Ii Attack Surface of the IoT Random Subsystem

A variety of prominent attacks are based on vulnerabilities of random number generators in real-world systems and the literature provides a plethora of cryptographic analyses and attack scenarios [10, 11, 12, 13, 14, 15, 16, 17, 9, 18, 19, 20, 21, 22]. In reality, there are even more attacks anticipated that target at zero day exploits. Kelsey, Schneier et al.  [13] criticize a lack of a widespread understanding of possible attacks against random number generators among system developers. Given the shortcomings of many random subsystems, it is worth considering the corresponding attack surface of a specific environment. An attack on a random number generator is an intrusive attempt of distinguishing between the produced sequence and truly random numbers. This distinction would open doors to predict future outputs or reproduce recent outputs that might have been used for generation of secrets in the past. The situation becomes even worse if an adversary manages to direct future numbers of a random sequence. Kelsey et al.  enumerate three classes of analytical attacks:

Direct Cryptanalytic Attacks  monitor PRNG outputs to gain knowledge about the system in order to distinguish between pseudo-random output and truly random bits.

Input-Based Attacks

  require access to PRNG inputs (seeds and initializations vectors) to inject known test sequences and perform further cryptoanalysis on random outputs.

State Compromise Extension Attacks  base on previously compromised internal state of the generator and enables prediction or backtracking within the pseudo-random sequence.

Previous work focuses on the analytical aspects of randomness on regular PCs with human-machine interaction. This approach is as well applicable in the case of interconnected embedded devices with missing user interfaces. Francillon et al.  [10] present a more generic distinction for the case of wireless sensor nodes that categorizes two types of attackers.

Remote Attackers  mainly target at cryptanalytic and input-based attacks. Without accessing the node directly, an adversary tries to compromise or manipulate the generator state, e.g., by monitoring and disturbing communication channels. In this particular example, wireless noise has been used to generate randomness. An adversary with access to the local wireless network must thus be considered a potential threat to perform an external attack.

Invasive Attackers  have gained read access to the internals of a generator and can compromise its state at one point in time. This definition does not include write access, or code injection by the attacker. Perfect state knowledge of a deterministic pseudo-random algorithm allows the adversary to predict future outputs and it can reproduce sequences that have been generated in the past, i.e., for cryptographic key generation. Unless true random vales are added to the generator state periodically, the system remains fully predictable. The update interval determines the maximum time that a generator remains vulnerable. Compromising the state by read access is also considered as an internal attack.

In the IoT, a large number of constrained embedded devices inter-connect to each others and to the global Internet. On the one hand, broadening the networking capabilities increases the attack interface, especially with availability from the outside of a local network. On the other hand, simple IoT devices entail special considerations in comparison to traditional networked devices such as servers, personal computers, or smartphones. Many IoT devices are very constrained in hardware capabilities due to minimizing price and form factors, as well as energy resources. These limitations do not only affect computational power, but often imply sparse hardware protection features. As a consequence, IoT devices often lack permission management for code execution, memory protection mechanisms, as well as secret storages.

IoT deployments can grant physical access to the hardware, which opens a potential interface to analyse and monitor delicate key material, firmware, or even program execution on a device if tamper detection is not in place. We argue that secure random number generation cannot be sustained in the case that an adversary has full read or write access to the device. Shielding attack vectors without read or write access demands for additional hardware capabilities and manufacturers of low-power chips already reacted. STMicroelectronics [12] defines three groups of attacks against microcontrollers.

System Software Attacks  focus on security and resilience affected by weak implementations, bugs, or insecure protocols after analyzing or even manipulating program execution. Disturbances can be introduced even without device access via network interfaces, e.g., by sending malicious packets, or by triggering the execution of non-verified or untrusted library functions that may be already part of the device firmware. The latter is often related to “monkey testing” or to insider knowledge.

Hardware Non-invasive Attacks  require hardware access. This category includes any kind of interface that allows interacting with the device directly, such as debug ports, or bus interfaces (UART, SPI, I2C, …). The most dangerous attacks for random sources that rely on physical processes are based on fault injection. Typically, an adversary exploits the device under environmental conditions that it is not designed for. Prevalent fault injection parameters are temperature variations, microwave induction or voltage manipulation. Furthermore, side channel analysis such as power profiling and timing analyses fall in this category.

Hardware Invasive Attacks  cover very advanced techniques that enable access to the device silicon and can be used to access hidden secrets, even if device protection mechanisms are in place. This group of attacks is usually very complex and only possible with the availability of specific measurement instruments.

Recently, hardware manufacturers of low-power microcontrollers have started to provide different countermeasures to the attack surface, ranging from debug port locks, tamper detection indicators, memory protection units, and isolated code execution environments. Also, hardware crypto acceleration on one chip become popular. These features should be used wherever possible. Nevertheless, many low-cost devices that are supported by IoT operating systems do not provide all (or any) of these capabilities, implementations and algorithms used for random number generation should be designed around the concepts of (i) a high modularity to ease partial use of hardware protection features and (ii) robustness even if hardware protection is missing.

Random number generation cannot be protected, if the adversary has full control over the device. Analytic attacks as well as fault injections can be shielded, though, by incorporating cryptographic primitives and carefully gathering entropy for seeding the PRNG, as we will discuss in the following section.

Iii Generating Randomness in the IoT

Every day in the life of an IoT device, random numbers are requested by a variety of use cases. These use cases separate into two classes: either general purpose or cryptographically secure random input. While general purpose use only requires sufficiently well represented statistical properties, cryptographically secure random numbers must also remain unpredictable even under malicious attacks. While the first category can be achieved fairly easily, the provisioning of secure randomness is very challenging in the constrained regime and—depending on the attacker model and strength—may not be achievable at all.

Iii-a General Purpose PRNGs

General purpose PRNGs are employed for tasks independent of security aspects. Typical use cases include the jittering of network protocol timers or media access protocols (e.g., random back-off in CSMA) to avoid collisions on a medium. Other applications of general purpose PRNGs include randomized sampling of sensor measurements and fuzzy testing.

A uniformly distributed stream of statistically independent random numbers is the desired output of a PRNG, which still should be approximated in higher dimensions, since concurrent applications or algorithmic elements may call on sub-sequences of the generator (

e.g., access every k-th output). Seeds between otherwise identical devices must differ to avoid identical random behavior across devices, but an individual seeding after each device restart is desired. Even though seed requirements for general purposes are moderate, a “plug and play” source for gathering seed material is missing on IoT devices that do not provide a hardware random number generator (HWRNG).

General purpose PRNGs are essential on most IoT devices and frequently called in many use cases. Implementations should therefore be very lightweight and efficient to preserve resources of the constrained devices. Available resources are better spent on generators with high security demands.

Iii-B Cryptographically Secure PRNGs

Crypto-purpose or Cryptographically Secure PRNGs (CSPRNG, as coined in the literature) are generators that are safe to use in security applications, involving the generation of cryptographic keys, nonces, or salts. Cryptographic system security relies on theses random numbers as basic input. Consequently, these generators are expected to output highly unpredictable number sequences and to be resilient against known attacks.

Building a crypto-purpose generator is more complex and consumes higher system resources than a general purpose PRNG. It involves additional building blocks of ciphers, cryptographic hash functions, runtime tests, as well a specifically robust seeding logic. Computational overhead and especially memory requirements of these building blocks are in potential conflict with resource constraints of IoT nodes, but the availability of secure random numbers is essential for enabling secure communication over the Internet. In order to reduce software complexity, some microcontrollers provide hardware acceleration of cryptographic primitives, which should be exploited when implementing the respective components.

A significant body of work reports about failures of PRNGs and successful attacks against the random input of crypto systems [13, 10, 15, 16, 9, 18, 12]. Hence, provisioning a cryptographically secure, consistent random infrastructure is a crucial component of an IoT operating system, which should be designed and tested with care. Requirements on CSPRNGs, in-depth analyses of different mechanisms and classification of those have been presented in [23, 24, 25, 26, 16, 15]. We summarize the key aspects of CSPRNGs in the following paragraphs.

Statistical Randomness

Any statistical bias gives rise to elementary attack vectors. Even though CSPRNGs mainly consist of deterministic algorithms, a crypto-secure random generator needs to produce sequences that are statistically indistinguishable from truly random [13]

. These properties base on the assumption that in a string of (pseudo-random) bits, probabilities for

one and zero are equal at any time and they are statistically independent. That means, guessing the next bit of a sequence cannot be done with better chance than 50 %. Even a very small bias must be considered as potential breach of the randomness assumption and contradicts crypto-requirements of a secure generator. A variety of statistical properties can be verified with tests that are available in well established test suites (see Section V).

Unpredictability

CSPRNGs require resistance against external and internal attacks (compare Section II). A common distinction exists between prediction resistance and backtracking resistance. In more detail, prediction resistance means that an attacker cannot guess future results in computational time by monitoring the generator history, even if the algorithm is perfectly known. To achieve this at a given statistical quality, the seed needs to be fully unpredictable. Furthermore, a crypto-secure PRNGs needs to be built on cryptographic functions, usually one-way hash functions and block ciphers that are practically not invertible and do not produce colliding output from different inputs.

Every cryptographic system needs to be designed according to a specified security level. An established threshold is 128 bit of secrecy [8, 27, 28]. Assuming an adversary had to guess a secret value, it would require trying about half the number of bit combinations, if all states are equally likely. For 128-bit secrecy this would be tries on average to brute force a collision, or in the worst case. This is currently considered secure for computational resources. Both the seed at the generator input, as well as the internals of its algorithm need to meet the expected security level. It is important to note that due to the birthday paradox, an attack on a cryptographic hash function can complete with a reduced number of tries [29, 30]. Furthermore, if an attacker gained knowledge of the internal state of a generator, it should be ensured that future output is only predictable for a very short time. According to NIST, this should be achieved by adding fresh and truly random values periodically to the internal generator state (see Section III-C on re-seeding).

Backtracking resistance protects against a reconstruction of previous values or even the seed after a state comprise. It implies that no correlation between seeds and generated output should be in place. This behavior is required to assure perfect forward secrecy within cryptographic protocols [31]. Backtracking resistance is realized by applying cryptographic functions to the internal state of the generator and hardened by storing state in protected memory, if available.

High Entropy Seeding

A truly random seed value is required to make the output of a CSPRNG unpredictable [25, 32]. Random bits are usually extracted from physical resources and the Shannon entropy [33] or the Minimum entropy serve as a measure of its randomness. In this context, physically random resources are often referred to as entropy sources. Physical sources of “randomness” typically exploit variations in electronic circuits (e.g., clock drifts, uninitialized memory, ADC fluctuations), randomly noisy signals (e.g., wireless noise, bit errors, thermal noise), or user input signals (e.g., key strokes, mouse clicks) which normally are unavailable in the IoT. These real-world entropy sources, however, do not always admit “full randomness” and additional compression methods are often needed for maximizing entropy. NIST [34] also advises that seed generation should not rely on a single entropy source, for resilience.

Full entropy seeds are required for secrecy in a CSPRNG, which is equivalent to requiring tries on average, for guessing a seed of length bits. If not seeded with full entropy, an adversary may exploit internal state collisions and determine generator output faster. This can drastically degrade the security strength of the generator. Hence, great care must be taken to harvest the number of entropy bits that is required by the cryptographic strength of the system as defined by and compliant to the algorithm of the PRNG [35]. Caution is advised with implementations that limit the input length of the seeding function.

Fresh entropy may be required repeatedly to re-seed the internal sate of a CSPRNG in order to recover from a potential state compromise, or to serve multiple generator instances, as we will discuss in the next section.

Health Testing

The quality of cryptographic system components need particular attention, as it may degrade not only due to software bugs, but also due to hardware aging or side channel attacks. A variety of tests have been proposed by NIST, which should be executed on all functions of a PRNG. Additionally, there are procedures to test the behavior of entropy sources. These tests range from known answer testing during validation time up to health tests during runtime to monitor vitality of the mechanisms. As the focus of this contribution is not on testing, we refer the reader to the specific NIST documents [25, 34, 36].

Iii-C A Note on Re-seeding CSPRNGs

A CSPRNG can recover from potential state compromise by regular re-seeding [13, 23, 25, 35]. Re-seeding of PRNGs is often advised [37, 10, 38] but also under much debate in the literature [16, 9, 39]. Certain CSPRNGs proposed by NIST even build upon the concept of re-seeding [25].

Considering that a generator is perfectly secure and was seeded in agreement with its specified security level, while both its seed and its state are kept in full secrecy,then an adversary cannot predict the next output by guessing within computational time without any re-seeding. So re-seeding becomes unnecessary. In this ideal scenario, the only reason for re-seeding is to extend the finite period of the specific pseudo-random algorithm. The period of a generator describes the number of cycles it takes to run through all valid internal states. In practice, however, computationally secure PRNGs have long enough periods and are not affected by repeating pseudorandom output during their lifetime in a common IoT scenario.

Re-seeding can even be disadvantageous as it introduces an interface to inject low entropy values to the internal state during runtime. This may foster state collisions and thus break the resilience against unpredictability.

Entropy is a fragile property that is (i) not always in place (ii) in many cases manipulable at physical device access and (iii) hard to estimate during runtime. Even worse, it may be hard to depict failures in case of a compromise. To avoid adding compromised entropy values during runtime, some common security procedures base on a “trust on first use” model 

[40], which contradicts the re-seeding approach.

Another vulnerability created by re-seeding was revealed by Ristenpart et al.  [16]. Existing implementations of entropy collectors cache their outputs in memory pools because—due to its eventually long and indeterministic runtime—entropy gathering is often implemented as a parallel and asynchronous task. If these numbers are not consumed immediately, a memory without perfect secrecy exposes an attack vector. Thus, entropy pools and internal states should run in trusted execution environments, only. Especially on constrained IoT hardware, this is not always possible, which makes the case for entropy generation on demand. Conversely, the utilization of insecure memory technologies generally motivates re-seeding with fresh entropy values.

Entropy sources can get compromised during operation, but the opposite can happen, as well, if sources did not provide full entropy during PRNG instantiation. In that case, mixing additional entropy values to the internal state during operation can be rescuing. Finally, few crypto-forums argue that re-seeding protects in case of faulty implementations. Faulty implementations at hand, however, contradict many assumptions of a cryptographically secure system.

In summary, there are reasons in favor and against re-seeding of PRNGs and we argue that a decision should be made by the designer and account for the underlying hardware capabilities, deployment considerations, application scenarios, and security requirements in place. We conclude that a re-seeding mechanism should be considered as an option, but remain decoupled from the CSPRNG API. This recommendation applies to IoT environments that require modular software in order to adapt to the heterogeneity of hardware platforms of varying resources and diverse deployments in probably (physically) harsh environments. These considerations, however, are not limited to resource constrained embedded devices, but apply to regular PCs as well.

Iv Randomness in IoT Operating Systems: Requirements and Related Work

Iv-a General Requirements

Many system services require access to random input, and it is common to expect a random function at the operating system level. Use cases and applications of random numbers differ largely, though, as we discussed in Section III. General purpose PRNGs are needed to generate random events that follow a uniform statistical distribution and are often consumed at high frequencies. Security related contexts raise the additional requirement of keeping random output unpredictable, why crypto-secure generators need to maximize entropy with the help of truly random input. Such input is on the one hand difficult to obtain at often high cost, on the other hand truly random sources frequently harvest from system hardware, which is best accessed via the hardware abstraction of an operating system.

Following this perspective, both general purpose and crypto-secure random number generation should be part of an operating system, but are at the same time only versatile if they meet the diverging requirements well. We argue that the different use cases and requirements of PRNGs and CSPRNGs demand for independent methods and APIs. Isolated random functions cannot only be specifically optimized, but also prevent side channel attacks against the CSPRNG via the general purpose PRNG. Furthermore, separate APIs force developers to decide for their individual use cases.

Iv-B General Purpose PRNGs

Use cases for general purpose PRNGs require statistically well distributed random sequences. First, single applications should receive a different value out of the whole number range on each request to avoid repeating patterns. Second, multiple applications that request from a single PRNG instance should experience the same properties, even if they access only every k-th PRNG output. This requires a decent empirical distribution in higher dimensions, which is often a challenge. Security related applications should not use this generator class as it may be too easy to predict. Furthermore, most go-to PRNGs are invertible which allows to reconstructing previos sequences. Different seeds must be generated across devices to prevent a uniform collective behavior. Seeding with a decent entropy is desired to provide varying sequences between system restarts. Seeds may be accessed through the hardware abstraction of the operation system, but should be configurable to ease debugging.

General purpose PRNGs should require minimal system resources to be applicable even on very constrained devices and to act frugally while requested frequently. Efficiency metrics involve processing time, as well as energy and memory consumption. The latter can benefit from restricting state to a single PRNG instance. A central instantiation logic can be managed by the operating system.

Iv-C Crypto-secure PRNGs

Core Requirements

Security related use cases require crypto-secure PRNGs for sovereign tasks such as cryptographic key generation. Delicate key material must be largely unpredictable. A CSPRNG is expected to produce sequences that are indistinguishable from truly random numbers, as discussed in Section III-B. It is advisable to rely on approved CSPRNG mechanisms that have been verified by trusted authorities and an operating system or a public library can provide access to implementations that are tested within this environment. A CSPRNG internally consists of cryptographic functions [25] to achieve backtracking resistance and the maximum achievable prediction resistance (security strength) is typically given by that function, though, the strength of the whole generator should be specified by the designer of the approved algorithm. In order to assure a predefined security strength, a high quality seed must provide truly random data with a corresponding amount of entropy during instantiation of the CSPRNG.

In contrast to general purpose PRNGs, CSPRNGs undertake tasks like key generation, which is typically involved less frequently, but also continuous encryption within stream ciphers, thus, performance characteristics of CSPRNGs are important but they are secondary in comparison to its security qualifications. Still, computation of cryptographic primitives and entropy conditioning can be costly [9], especially on constrained embedded devices. The CSPRNG and the seed generator as provided by an OS must comply to the constraints of the target hardware and leave sufficient resources to deploy a real-world firmware with the desired application logic. The operating system should provide an optimized, configurable environment to support this.

Minimal Standards

Crypto-secure PRNGs rely on true random seeds that meet a security strength which determines the required amount of entropy in the seed. At least one entropy source must be in place that meets the requirements. The operating system should provide an entropy interface, which grants access to true random values generated from varying sources, dependent on underlying hardware capabilities. Externally connected devices may provide true random numbers as well, but typically require a device driver. An operating system can simplify access to relevant components by its hardware abstraction layer, and should additionally allow for code re-use between different hardware platforms. The need for configurability requires a highly modular architecture. In the context of IoT software, configuration is commonly done during compile time to keep firmware sizes small.

Tests are mandatory for generating robust and secure random numbers [25, 34]. Both the pseudo-random algorithm and the seed generation must be tested whereas testing procedures can be separated into a priori and live tests during deployment. Due to device constraints, a priori tests at development time should be favored to save resources on running IoT nodes. Thereby, bug free execution of the deterministic CSPRNG must be verified by comparing output sequences against ground truth. Further, seed sources rely on physical processes and should be evaluated within deployment conditions, because their behavior can be affected by environmental properties.

Optional Features

Entropy sources are essential for seed creation, but the properties of underlying physical processes are diverse. Environmental changes as well as attackers with device access can affect their reliability (see Section II). Involving multiple entropy sources during seed creation increases seed resilience. Naturally, a physical process does not provide full entropy, but conditioning is sometimes implemented already in the hardware. For sources with sparse entropy concentration, a compression mechanism is required. An entropy module provided by the operating system can increase seed quality and it should involve three fundamental building blocks: (i) An estimate about the entropy amount per input which can be provided by each source, (ii) an accumulation instance to involve multiple sources and keeps track of the amount of accumulated entropy and (iii) a compression mechanism to create high entropy seeds with limited length to meet security requirement of the CSPRNG. The entropy API should thus provide an interface to pass security requirements and it should also be able to report errors back to the CSPRNG.

Re-seeding a CSPNG is sometimes desired to recover from potential state compromise (see Section III-C). We argue that re-seeding should be kept optional because seed generation may drain a significant amount of energy on every re-seed cycle. Enabling and disabling that feature should be transparent to the application that uses the CSPRNG.

Cryptographic protocols for different purposes require to run on individual instantiations of a CSPRNG to prevent side channel attacks. This affects the operating system in two ways. First, seeding needs to be done separately for each instance—in contrast to the unified approach suitable for general purpose PRNGs. Second, every instantiation needs its own context to be handled either internally within the boundaries of the CSPRNG or externally, by dedicating context allocation to the application. In both ways, the number of contexts should be kept low in an IoT OS, because the CSPRNG state can consume much memory. It is worth noting that IoT firmware typically avoids dynamic memory allocation, why the number of CSPRNG instantiations should be explicitly defined during development.

The state of a generator needs protection and an operating systems should involve hardware security features, if available. In more detail, secure memory technologies can provide tamper detection along with authorized access and recent low-power platforms even provide trusted executions environments (e.g., ARM TrustZone 111https://developer.arm.com/ip-products/security-ip/trustzone/trustzone-for-cortex-m) for protected code execution. CSPRNG state, seeds, and entropy values should be uninstantiated after use to avoid leakage via side channels. This is of particular importance when secure memory is absent. Memory erasure is commonly done by setting buffers to zero, though, instructions to “zeroize” a buffer are often removed by compiler optimizations, which leaves sensitive information in memory. Known solutions involve explicit_bzero implemented by the GNU C Library, as well as service functions in cryptographic libraries such as libsodium 222https://libsodium.gitbook.io or Monocypher 333https://monocypher.org.

Optimizing Parameters

Modern off-the-shelf IoT devices provide an on-chip hardware random number generator which is commonly used as seed source for CSPRNGs. In addition, accelerating hardware units are often in place and capable of processing cryptographic primitives such as ciphers and hashes. While most CSPRNG implementations base on a pure software solution of their internal cryptographic functions, a transparent substitution by hardware implementations promises performance enhancements in terms of speed and energy. The operation system can provide peripheral drivers to control hardware accelerators and a transparent reconfiguration, dependent on respective hardware capabilities, should automatically select the most performant solution.

Furthermore, certain IoT boards provide an external hardware acceleration chip mounted on the same PCB as the microcontroller which is typically connected by a peripheral bus. Transparently including this device class as (i) a cryptographic accelerator or (ii) a full CSPRNG alternative can off-load the main processor and potentially enable cryptographic applications on very constrained devices that cannot run a heavy-weight CSPRNG software.

Iv-D IoT Implementations

Among the most prominent IoT operating systems nowadays are Contiki-NG, a successor of the original Contiki operating system [41], mbed OS [42], zephyr [43], Mynewt [44], and RIOT [45], all of which implement methods to gather random numbers. In the following, we give a brief overview about current solutions in different OSes, and we focus on RIOT afterwards.

Contiki-NG provides support for few ARM Cortex-M based microcontrollers, and MSP430 platforms, although its predecessor Contiki provided support for a wider range of architectures. Contiki-NG implements a sparse random subsystem that does not distinguish between general purpose and cryptographically secure PRNGs. The random API is implemented as a wrapper around peripheral HWRNG drivers of a platform and an approved CSPRNG is not available. The interface provides a seed function that limits the input size to an unsigned short integer but it is left unimplemented in most cases, because the on-board HWRNG does not require a seed. In case of missing hardware random number support, the random module falls back to the C library function rand which maps to a lightweight linear congruential PRNG in most C libraries. An entropy module for seed generation, implementations of hardware accelerators, tests, and error indication interfaces are missing in Contiki-NG.

mbed OS  is the ARM operating system for processors of the ARM Cortex-M family. mbed implements one PRNG for general purpose random number generation based on the Xorshift generator with 128-bit internal state (Xoroshiro128+). The general purpose API provides an interface to re-seed the internal state. ARM maintains an SSL library (mbed TLS [46]) next to the operating system. This library is included in the mbed operating system for secure random number generation, and it can be ported to other software projects as well. On the upper layer, this library implements the CSPRNGs HMAC DRBG and CTR DRBG as proposed by NIST [25]. Implementations include external state handling, re-seeding procedures, and a collection of self tests. Cryptographic hardware acceleration is supported too. On the lower layer, the mbed TLS library implements a dedicated module for entropy gathering, which (i) is capable of accumulating multiple entropy sources, (ii) provides an interface to add personal entropy sources, (iii) can be used in a blocking and non-blocking fashion until certain entropy requirements are met, (iv) distinguishes between weak or strong entropy requirements, and (v) can be compiled with different complexity levels. When used on Cortex-M devices, the only built-in entropy input is the HWRNG of a platform which is expected to return full entropy values without further estimation, thus, an adequate HWRNG has to be in place for cryptographic operations and it cannot be replaced by alternative entropy sources that only provide partial entropy bits per sample. Both generator classes are seeded by the entropy module of mbed TLS.

Zephyr  supports a large variety of ARM Cortex-M based 32-bit IoT platforms as well as x86, ESP32, ARC, NIOS II and RISC-V based boards. The operating system implements a PRNG for general purposes (Xoroshiro128+) and the external mbed TLS and tinycrypt [47] libraries are ported to zephyr, which include crypto-purpose generators specified by NIST [25] (HMAC DRBG and CTR DRBG). The adaptation for running both libraries within zephyr does not include hardware abstraction for crypto accelerators. A collection of tests implemented within mbed TLS and tinycrypt can be executed from the operating system and it additionally provides benchmarks for generators of both libraries. Zephyr has an entropy interface that is used to seed both PRNG types. It can be accessed either in a blocking or non-blocking fashion. The interface is implemented as a peripheral HWRNG driver, which is expected to return full entropy, still, it does not support accumulation of different entropy sources. The fallback entropy source in case of missing hardware capabilities is a predictable timer or counter based solution. The entropy API implements a basic error interface to indicate this kind of deficits.

Mynewt  is an operating system that supports about 40 boards, most of which with an ARM Cortex-M based 32-bit microprocessor and the minority involves MIPS or RISC-V architectures. Similar to Contiki-NG, it uses the C library function rand() for requesting general purpose random numbers. Both mbed TLS and tinycrypt libraries are available for cryptographically secure random number generation. In both cases, cryptographic functions are processed in software. Selftests from mbed TLS can be executed within the operating system, whereas tinycrypt tests are not included. To seed the CSPRNGs, an interface to the HWRNG driver of the microcontroller is supplied.

RIOT  currently supports around 170 boards and 30 different microcontroller families ranging from 8-bit AVR devices with sparse peripherals, 16-bit MSP430 devices, up to 32-bit processors of the ARM Cortex-M family and ESP32 with various MCU peripherals including dedicated HWRNG circuits, as well as ARM7, MIPS, and RISC-V based microcontrollers. RIOT implements a collection of PRNGs that range from lightweight general purpose algorithms to crypto-purpose generators. Among other embedded crypto libraries, RIOT also includes tinycrypt, and it additionally offers support for relic [48], but the external CSPRNGs are not yet integrated into the random subsystem. A central random API unifies access to pseudo-random numbers, regardless of different requirements. At the API level, there is currently no differentiation between general purpose and crypto-secure PRNGs. All PRNGs that are natively supported in RIOT work on a single internal state. This forbids running multiple instances of one generator and prevents external state maintenance. A test application with user interaction via the shell allows to test vitality and basic performance metrics of a generator.

The random interface provides two initialization functions for PRNG seeding, one of which seeds with a 32-bit integer value and the other initializes an array of variable length. Neither the initialization function nor the random request function provide an interface for error reporting in case of low entropy seeding, or internal errors of the generator. As a seed, either the output of a HWRNG or an SRAM PUF seeder feed the instantiation function of a PRNG. In case of a missing entropy source, the CPUID or a static value compiled to the firmware are currently involved for seeding. The CPUID has zero entropy but as a minimum, it provides varying start values between multiple boards. The compiled value provides entropy between build processes because it is generated by a running PRNG on the development system. This solution prevents re-usage of one binary for multiple controllers which complicates deployment. Both mechanisms provide zero variation between reboots, and they should not be used in a real-world deployment. An advanced entropy module that involves multiple sources, estimates the amount of accumulated entropy and exposes an interface to request a specific number of entropy bits is yet missing in RIOT.

V Statistical Test Suites for Random Numbers

The statistical quality of random sequences can be empirically analyzed. There are many methods and tools to test for random properties. The NIST Statistical Test Suite (STS) [24] and the DIEHARDER Random Number Test Suite [49]

combine series of such tests. They have established as standard tools and are openly available. Both suites base on hypothesis tests that analyse the input against the null hypothesis of perfect randomness. This hypothesis implies that fully deterministic pseudo-random sequences with ideal random properties cannot be distinguished from truly random values. Conversely, even ideal random sources may produce sequences that appear to have non-random properties, which can lead to failures of statistical tests occasionally—usually referred to as type-1 error.

V-a NIST Statistical Test Suite

The NIST STS consists of 15 different test cases, some of which are executed repeatedly, leading to a number of 188 statistics that are processed on each run. With respect to the input size recommendation for each test [24], we apply the test suite version sts-2.1.2 to 100 Mbit generator output. Every test is repeated 100 times with 1 Mbit test sequences. A single test returns a probability value (-value) and it is expected to accept the hypothesis of perfect randomness with a confidence of , if the value lies above a significance level of . Otherwise, the hypothesis of randomness is rejected and the result is interpreted as failure. Each test is applied repeatedly which results in a vector of -values. The proportion of passed sequences for one test is determined using the confidence interval. As a next step, the distribution of values for each test is analyzed using a chi-squared test ()-test, which outputs a second order probability value (-value). The test suite defines a significance level of for testing this distribution.

V-B DIEHARDER Random Number Test Suite

The DIEHARDER test suite subsumes 31 tests to analyse statistics of random input streams. These tests are executed with varying parameters, thus, a full run calculates a total of 122 test statistics. We apply the DIEHARDER test suite version 3.31.1 with default options to streams of raw binary outputs. In default mode, the number of repetitions of a specific test varies between

in [1,1000] and the sequence length is variable between in [100,65000000] which demands for much more random input data in comparison to the NIST STS. Repeated executions deliver multiple probability values (-values) for each test, similar to the NIST tests. A Kuiper Kolmogorov Smirnov test (KS-test) is applied to test deviations from the expected distribution, which results in a second order probability value (-value).

In DIEHARDER, a test passes if its -value lies above a significance level of , below , and it fails otherwise. The result is considered as weak if -value lies above and below . It is again worth noting that even truly random numbers might generate weak results occasionally.

V-C Other Test Suites

Donald E. Knuth was one of the pioneers who described randomness tests in early editions of The Art of Computer Programming [50] and his tests are part of most established test suites today.

NIST released the first random number tests in 1994 within the FIPS 140-1 [51] standard, which specified four statistical test. In 2001, these tests were updated in FIPS 140-2 [52] with a narrowing of the test criteria. Both documents served as predecessors for the NIST Statistical Test Suite (STS) released in 2010, which includes all 140 FIPS test cases as a subset. The Diehard test suite was published in 1995 by Marsaglia [53], who had been active in this field since years. The test suite implements a collection of 18 test cases, which are a central part of the DIEHARDER test environment, which has been developed since 2003. Both NIST STS and DIEHARDER are well known and accepted as standard tools for statistical testing of random number generators [54, 55].

The TestU01 library [54, 56] was introduced in 2007. It includes the majority of tests from NIST STS, Diehard, as well as additional tests proposed in literature. Its purpose is to provide an “extensive set of software tools for statistical testing of RNGs.” [54], which led to a larger variety of tests, larger sample sizes and an extended test parametrization in comparison to the other suites. At the core, the environment implements hypothesis tests similar to NIST STS and DIEHARDER, but instead of rejecting a hypothesis, it simply reports -values outside the interval [0.001, 0.9990]. TestU01 can be executed on four complexity levels, of which the most comprehensive one (BigCrush) involves up to 160 test statistics. Generation of the required amount of random data can take a long time, in particular when generated on microcontrollers and transmitted via the UART to feed the library. This drastically increases time requirements of the evaluation process.

A range of other test environments are less prominent in the literature. The SPRNG (Scalable Parallel Random Number Generators) [57] library is a tool to optimize distributed processing for parallel random number generation and it additionally contributes a few standard tests already covered by NISTS STS and DIEHARDER. The ENT test program [58] defines a small-scale environment that executes only five statistical tests. It relies on a file based data input, which is not practical when huge datasets have to be analyzed. The CryptRndTest package [59] analyses cryptographic random numbers, focusing on high precision floating-point numbers with lengths larger than 64 bits. The latter is uncommon in the IoT.

Board Chip Entropy Source Post-processing Error Handling
ST NUCLEO-F410RB STM32F4 3 Free-running ROs Bias Correction + LFSR Health Tests
Phytec IoT Kit 2 MKW22D 2 Free-running ROs LFSR Status Indication
Nordic nRF52840 DK nRF52840 Thermal Noise Bias Correction Status Indication
Zolertia RE-Mote CC2538 RF Noise (seed only) 16-Bit PRNG
Atmel SAM R21 XPRO SAMD21
Arduino Mega 2560 MEGA2560
Openlabs Radio Breakout AT86RF233 RF Noise

Microchip

CryptoAuth XPRO-B

ATECC(5—6)08A

Quantum Mechanical

Circuit Variations

FIPS CSPRNG

Health Tests

(ATECC608A)

TABLE I: Overview of the typical on- and off-chip IoT hardware with their random features that we analyze. (Abbreviations: RO=Ring Oscillator, LFSR=Linear Feedback Shift Register, RF=Radio Frequency).

Vi Hardware Generated Random Numbers

Common off-the-shelf IoT platforms sometimes provide hardware generated random numbers. While some platforms implement “true random” circuits for entropy gathering on the same chip as the CPU, others implement pseudo-random generators in hardware. Still, many microcontrollers do not offer random hardware at all. In these cases, external components such as transceivers or cryptographic co-processors may be connected to a bus and contribute true random numbers. As an alternative, advanced mechanisms can extract random physical properties from manufacturing variations of the microcontroller itself. In this section, we analyse typical IoT hardware platforms from different manufacturers, CPU architectures, and feature sets. Results are summarized in Table I. We run RIOT-2020.01 as operating system with a collection of custom measurement programs.

Both the STM32F4 [60] and MKW22D [61] chips supply a HWRNG that gathers entropy from sampling multiple free running and jittering oscillators, followed by a post processor based on a linear shift register that ensures statistically well distributed numbers. They also cover basic runtime health tests implemented in hardware, as proposed by NIST [34]. Although the data sheets claim to pass the NIST statistical test suite, the manufacturer NXP recommends against its direct use for cryptographic applications in place of an approved CSPRNG:

It is important to note there is no known cryptographic proof showing this is a secure method of generating random data. In fact, there may be an attack against this random number generator if its output is used directly in a cryptographic application. The attack is based on the linearity of the internal shift registers. Therefore, it is highly recommended that this random data produced by this module be used as an entropy source to provide an input seed to a NIST-approved pseudo-random-number generator based on DES or SHA-1.   [61]

The nRF52840 by Nordic[62] implements a HWRNG based on sampled thermal noise followed by an optional post processor that reduces bias. Even though the reference manual describes the mechanism as suitable for cryptographic purposes, our results indicate a slightly different picture without the post processor, as we will show later in this section.

The Texas Instruments CC2538 microcontroller [63] implements a PRNG in hardware, which internally consists of a 16-bit shift register. Hence, its period is limited to . In contrast to HWRNG peripherals of the previous microcontrollers, this device implements a pseudo-random algorithm controlled by the same API that is commonly used to request true random data from on-chip generators. The PRNG is seeded by noise samples on the receive path of the on-chip radio. A similar approach is established on the standalone AT86RF233 transceiver module [64], which produces all random values by observing noise from the radio.

The ATECC508A [65] is a feature-rich cryptographic co-processor that runs a NIST-approved CSPRNG combined with an internal seed which is inaccessible from the outside. The seed is automatically updated on every power or sleep cycle or on demand. In addition, the seed is generated internally based on entropy extraction from quantum mechanical variations of the circuitry:

In the crypto devices, the random seed comes from variations at a quantum scale within the device. The inherent quantum mechanical entropy of the circuitry within the device provides a truly random seed.   [66]

Table I also lists the SAMD21 and the MEGA2560 microcontrollers by Atmel as examples of the numerous off-the-shelf devices, which completely lack hardware based random sources. This class of devices heavily benefits from external co-processors as well as internally generated entropy from physical resources that can seed an approved software PRNG.

Vi-a SRAM PUF Seeder

Physically unclonable functions (PUFs) are one solution to generate unpredictable numbers even without dedicated electronic circuits. They extract unique output from individual hardware properties. Here, we focus on SRAM PUFs because this memory technology is present on almost all available microcontrollers. Transistor variations of memory cells lead to varying states after device power-on. The startup state of multiple memory blocks form a device-unique pattern plus additional noise, which can be extracted, compressed and used as PRNG seed values [67, 68, 69, 70].

Fig. 1: PUF SRAM random seeder integration in RIOT.

Vi-A1 OS Integration


Seed Generation

The mechanism of a PUF-based seeder is visualized in Figure 1 for the example of RIOT. It operates during system startup prior to OS kernel initialization and reads out uninitialized SRAM cells. A PUF measurement is compressed by the lightweight DEK hash to build a high entropy 32 bit number that seeds a PRNG during its instantiation, afterwards in the OS startup sequence. It is noteworthy that the lightweight DEK hash is not a cryptographic function.Furthermore, 32 bit entropy is not sufficient for cryptographic use, but the mechanism is extensible to cryptographic requirements.

Re-seed Power Cycle

Only startup state of uninitialized memory after re-powering provides high entropy values. Either a power-off cycle or a low-power cycle without memory retention is required to generate a new seed. Among others, the required minimum power-off time depends on ambient conditions, age and properties of the power source. In our experiments, an off-time of 1 sec. has proven suitable for all platforms. A more detailed analysis about the impact of environmental and experimental conditions to the SRAM PUF properties has been presented by Schrijen et al.  [71].

Nevertheless, soft resets or low-power cycles with memory retention can occur and trigger the startup routine that should not perform a new memory measurement in the absence of a power-off cycle. For a solution, a simple soft-reset detection mechanism writes a randomly chosen marker at a known and reserved address in the SRAM. During the subsequent startup, this memory address is inspected and a new memory measurement is only performed if the marker has disappeared. Otherwise, a soft-reset counter is incremented, added to the previously generated seed and the result is hashed again for creating a new seed value, which is then stored for the next cycle. The last seed, as well as the soft reset counter could be stored in protected memory for crypto-safe operations.

Vi-A2 Evaluation of SRAM PUF Seeds


Next, we analyse SRAM properties on common off-the-shelf microcontrollers and present results for the SAMD21 in Tables II and III.

Device A B C D E
(i) Entropy 4.2 % 5.5 % 5.3 % 4.7 % 5.5 %
(ii) Weight 50.7 % 49.5 % 51.3 % 49.8 % 53.1 %
TABLE II: Min. Entropy and Hamming Weight between 50 reads of 1 kB SRAM on five SAMD21 MCUs (A–E) at ambient temperature.
Device Pair A–B A–C A–D A–E
(iii) Distance 49.2 % 49.8 % 50.1 % 50.4 %
TABLE III: Fractional Hamming Distance from 50 reads of 1 kB SRAM between five SAMD21 MCUs at ambient temperature.
Memory Properties

As a first step, we inspect the random properties of the memory in detail. We analyse intra- and inter-device variations between multiple PUF responses at ambient conditions. Therefor, we calculate (i) the minimum entropy as a measure of randomness and (ii) the hamming weight to determine bias between multiple startups of one device as well as (iii) the fractional hamming distance between different device responses to quantify inter-device uniqueness. Results for (i) and (ii) indicate existence of a relative min. entropy around 5 % and unbiased patterns. A relative fractional distance of approximately 50 % in (iii) indicates uniqueness of device responses.

(a)
(b)
Fig. 4: PUF SRAM seed evaluations. Min. Entropy for varying input lengths (left) and distributions of fractional Hamming Distances (right).
Seed Properties

For determining the proper size of memory used for seed generation we evaluate the minimum seed entropy for varying input lengths and different platforms as visualized in Figure 4 (left). All measurements converge to approximately 31-Bit entropy with 1 kB SRAM, which is a decent result.

Next, we test the distribution of hamming distances between multiple generated seeds on every device against normal distribution, using a simple KS-test. The probability function in Figure 

4 indicates that seed distances on all devices follow a normal distribution with an average expectation value of 0,52 which is slightly biased by the influence of the MEGA2560 platform. Still, all four controllers pass the test with probability values greater than 0,95, which allows to accept that they are unique and uncorrelated.

Vi-B Statistical Analysis with NIST STS

We now evaluate the statistical properties of all hardware based random sources from Table I by applying the NIST test suite. Following the input size recommendation for each test [24], we test 100 Mbit of random data. Every test is repeated 100 times, which results in 1 Mbit test sequences. Random integers are generated on the constrained device and fed into the evaluation tool overt UART. It is worth noting that already the serial transmission of the data takes at least 45 min. with a baud rate of 115200. This added to the randomness generation time which led to experiment times ranging from one to over two hours per run. The experiment was executed under office conditions at ambient temperature.

Results of the -test on the distribution of -values are shown in Figure 5. Certain tests produce multiple -values and we show the average in that case. We display passing tests with gray bars, and we highlight failed tests with hatched red bars or red arrows in case that the -value is too small to be displayed. The test suite additionally calculates a proportion of passed test runs and evaluates its significance. Passing tests in Figure 5 have a significant proportion within the confidence interval calculated from .

All generators but the nRF52840 (w/o bias correction) and the CC2538 show good statistical properties and pass the test suite. The STM32F4 indicates one failure for the Block Frequency test which analyses the proportion of ones in blocks of 128 bit length. A repeated experiment led to similar results, so we consider this behavior a weakness of that HWRNG.

The nRF52840 provides an optional bias correction that is applied to the sampled noise. With enabled correction the nRF52840 (w/ bias correction) passes all statistical tests without deficits. If the post-processor is disabled to increase performance, it fails several of the test statistics as visible in Figure 5. As we will see later, the bias correction requires notably more system resources. We repeated the statistical experiment with and without bias correction multiple times with similar results.

The CC2538 consists of a simple 16-bit linear shift register PRNG that (i) shortens the generator period (see Section III-C) and (ii) can be attacked with sparse processing resources due to the linearity of the internal shift registers. Correspondingly, it fails in most of the tests.

Fig. 5: Hardware Generated Random Numbers: -test results on the distribution of probability values from 15 NIST STS tests. -values 0.0001 pass the hypothesis of uniformity.

Vi-C Performance Analysis

Throughput

We measure the throughput and generation time of different random sources on the STM32F4 platform as well as the internal generators of the other devices listed in Table I

. Our test measures the throughput as a single-threaded application that generates streams of pseudo-random numbers continuously, and we count the number of values produced within an interval of 10 seconds. In addition, we measure the time of a single (blocking) function call that returns a random integer with an oscilloscope by toggling an I/O pin via direct register access on the test device. In this way the measurement overhead remains negligible. The ATECC508A crypto-chip always processes 32 Bytes per request even if only integer values are requested. We display rates, average processing times per random integer, and their standard deviation in Table 

IV.

Clearly, the PUF based seeder as well as the externally connected devices perform two up to four orders of magnitudes slower in comparison to the on-chip generator of the STM32F4 that returns random values via direct register access. It is important to note that our measurements for the SRAM based seeder only include processing times of the generator itself. In practice, the required power-off cycle as well as the OS startup are added, which can take tens to hundreds of milliseconds and is heavily dependent on the OS configuration. However, in the all-day use of an IoT-device, low power cycles occur repeatedly. The cryptographic co-processor ATECC508A is notably the slowest but it is the only candidate that runs a hardware based cryptographically secure random number generator. Its performance strongly relates to the mode of its device driver 444https://github.com/MicrochipTech/cryptoauthlib. In our measurements, we use the polling mode, which queries the device for the completed execution 4–7 times before random data is ready. Alternatively, in the non-polling mode, the driver waits a maximum execution time for each command, after which the data is ready to be fetched from the co-processor. This potentially increases execution times but leaves room for parallel processes to be scheduled or low-power sleeping. Furthermore, the ATECC508A as well as the AT86RF233 transceiver require additional I2C/SPI transmissions in comparison to the on-chip solutions.

Among different MCUs on-chip generators, the STM32F4 performs fastest. Although its CPU runs with the highest frequency (96 MHz), the processing time is not directly proportional to the CPU speed. In comparison, the MKW22D implements a similar HWRNG and runs at half the CPU speed (48 MHz), but calculates more than ten times longer to a produce random integer value. The CC2538 unsurprisingly operates comparably fast as it only operates a simple shift register without sampling noise. Both configurations of the nRF52840 generator indicate low throughput of 6–15 kB/s in comparison to the other generators, which presumably relates to the internal sampling procedure. The bias correction leads to statistically good properties of the output sequences but it reduces computational speed by a factor of 2.5.

Generator
Rate
[kB/s]
Avg. time
per Int. [us]
time
per Int. [us]
STM32F4
+ PUF SRAM 296.46 555Does not include time for power-off cycle 0.16
+ ATECC508A 3 11609.69 666ATECC508A always produces 32 Byte blocks 889.96
+ AT86RF233 25 150.48 0.08
+ HWRNG 1994 1.95 0.04
MKW22D 316 33.08 0.08
nRF52840
   w/o bias correction 15 246.04 2.25
   w/ bias correction 6 600.28 57.03
CC2538 503 6.25 0.37
TABLE IV: Hardware Generated Random Numbers: Throughput and processing time.
Energy Consumption

To evaluate the energy consumption of each generator, we measure the current consumption of all hardware based approaches with a digital sampling multimeter (Keithley DMM7510 7 1/2) at 1 MS/s and we drive the board from an external regulated voltage supply. All development boards provide a measurement header to probe the current that flows to the microcontroller. For the externally connected devices, we additionally measure the current to the power supply pin. Some HWRNGs execute at the same scale as the sampling resolution, thus, we measure generation of 1000 integers per run in that case and normalize the cumulated values afterwards. We repeat every experiment 1000 times. In setups that involve external hardware, we measure the MCU and the external device separately. If applicable, we separate microcontroller and external device consumption in our graphs.

Figure 6 displays our test results on the energy consumption. The radio based approach as well as the SRAM based seeder consume one order of magnitude more energy than the on-chip generated numbers, and the crypto-chip even requires two orders higher resources. The ATECC508A clearly has the highest energy footprint, which is strongly related to the device driver implementation. As depicted in Table IV the co-processor requires more than 11 ms to process the next output, during which the MCU is polling the co-processors status. While co-processing, though, the MCU is free to process other data or to go to a deeper sleep mode for energy saving. As depicted in Figure 6, the microcontroller consumed the larger portion of energy up to 190 J. Furthermore, the ATECC508A produces a minimum of 32 random bytes per request, thus, up to eight integers can be fetched for the same cost.

Second most energy hungry after the cryptographic co-processor is the radio based random generation. Although this approach is ten times faster, it only saves a factor of four in energy, which is due to the higher current draw of approximately 12.5 mA in receive mode of the AT86RF233 during random bit generation. The ATECC508A on the other hand only drives around 3 mA during operation. Results for the SRAM based seed generator scale similar to the radio based approach. It is worth noting that we only display the PUF SRAM overhead here that comes on top of a power-off cycle. Results for on-chip generators reflect similar properties as the processing times. The consumed energy to produce one random integer is below 3.5 uJ on all four HWRNGs. STM32F4 is notably the most economic competitor and it reduces the consumption per integer to less than 0.35 uJ.

The difference in energy consumption of the two nRF52840 modes lies about a factor of 2.5, which increases only a little lower than the processing times listed in Table IV. Still, bias correction introduces a notable increase in processing time and thereby in energy consumption.

Fig. 6: Hardware Generated Random Numbers: Energy consumption of external (left) and internal on-chip generators (right).

Vii Software Generated Pseudo-Random Numbers

Since von Neumann’s early work [72], the generic method of obtaining pseudo-random numbers builds up on some (deterministic) function that is iteratively applied to a (random) seed and attempts to approximate the output of uniformly distributed, independent random trials. As of today, very many of such pseudo-random software generators exist, which comply to various random quality and complexity requirements. From the perspective of an IoT operating system, we are interested in two types of highly efficient, memory-strained algorithms: (1) an ultra-lightweight general purpose PRNG, and (2) a crypto-secure PRNG that meets the resource constraints of class 1 IoT devices. In the following, we will introduce and analyse eight popular generators—four complex generators of high quality and four lightweight candidates for general purpose random generators in the IoT.

We apply the NIST, DIEHARDER, and the TestU01 test suites to these PRNGs using RIOT as our platform. Our test programs run as RIOT native processes on Linux servers to speed up experiment time. Thereby, we instantiated all generators with the same seed, except for the CTR PRNG and the NIST Hash DRBG that are not integrated into the random subsystem and both impose specific requirements on the seed.

Vii-a Complex Generators

Fortuna

The Fortuna PRNG is considered a cryptographic random number generator (DRG.4 [23]) and was designed to overcome the demand for entropy estimators that tend to be complex and inaccurate [38]. Internally, the Fortuna algorithm maintains pools of entropy from which a periodic re-seeding is performed. Pools are filled from different available entropy sources, whose values are distributed among these pools. The entropy accumulation is conducted by hashing the internal generator state and one entropy pool at a time using a SHA-256 function. That mechanism allows generating random sequences of unlimited period, though, it cannot overcome the requirements for proper entropy sources for seeding the generator and for updating entropy pools. Potential side effects of re-seeding have been discussed in Section III-C. The final blocks of pseudo-random output are generated by an AES-128 block cipher in counter mode.

Ctr Prng

The CTR PRNG is a cryptographic generator (DRG.4 [23]) specified and approved by NIST [25]. It is based on a 128 bit AES block cipher in counter mode, why it provides 128 bit security strength. To achieve this, the generator requires seeds of at least 128 bits entropy. The tinycrypt library implementation, though, which we use in our subsequent evaluation, requires seeds with a minimum length of 256 bits. This is in contrast to all other implementations presented in this section.

Sha256prng

The SHA256PRNG is a generator that provides cryptographically strong random numbers (DRG.2 [23]). The original mechanism of this generator was introduced in FIPS 186–1 [73] and analyzed by Kelsey et al. [13] and Desaj et al. [74]

. Outputs are generated by hashing the internal generator state, after which the internal state is updated by a linear transformation of the hash.

SHA256PRNG is the successor of the SHA1PRNG, which became popular as the choice of the Java SecureRandom class. Until recently, it was considered secure [75] but got deprecated in Android N777https://android-developers.googleblog.com/2016/06/security-crypto-provider-deprecated-in.html. The reasons for deprecation mainly relate to a seeding bug in Java and to NIST deprecating the underlying SHA-1 hash function because Wang et al. [76, 77] discovered an attack that decreased the number of brute-force tries needed to foster state collisions from to operations. For that reason, SHA256PRNG replaces the SHA-1 output function by SHA-256.

The generator is forward secure up to the previous-to-last state, which can be recovered from the current generator output by inverting the state update function. SHA256PRNG is confined to a single hash computation per block, which makes it computationally efficient. To add full forward secrecy NIST developed a collection of improved and standardized random bit generators [25], the deployment of which has been recommended in succeeding revisions of the FIP 186 [78, 79] standard.

We briefly discuss results about the NIST Hash DRBG (using the SHA-256 hash) at the side. It extends the SHA256PRNG by a cryptographic function that hashes the internal generator state to harden backtracking resistance after state compromise. This requires two hash computations on each block. The NIST Hash DRBG additionally implements an approved re-seeding mechanism to achieve unpredictability even after state compromise (DRG.4 [23]).

Mersenne Twister

The Mersenne Twister is a widely used generator, which in its default version is known to be non-secure [80], even though crypto-secure variants have been explored successively. Known advantages of that algorithm are a long period and comparably fast operations, because the generation of pseudo-random numbers avoids multiplication and division. Instead, it requires a large internal buffer of 624 integers.

Vii-B Lightweight Generators

Tiny Mersenne Twister

The Tiny Mersenne Twister is a derivate of the original Mersenne Twister that adapts to resource constraints on the price of a narrowed scope. It heavily reduces buffer requirements, on the price of a shortened period length. The generator is rather a reduced, memory efficient fallback solution of the full Mersenne Twister [81].

Xorshift

The Xorshift generator belongs to the family of linear-feedback shift register generators that are not cryptographically secure. It is known for its resource efficiency as it is confined to simple XOR and shift operations. In its simplest 32 bit state generator, we refer to it in the following. Marsaglia [82] proposed a collection of extended Xorshift PRNGs with an increased period length and improved statistical properties. Vigna et al.  analyzed and improved these generators further [83, 84, 85]. We briefly discuss results about the Xorshift64* and the Xoroshiro128+ derivatives at the side, which we integrated into RIOT for comparison. The Xorshift64* consists of a 64 bit state and applies a constant multiplication to the output for bit scrambling. The Xoroshiro128+ requires 128 bit state, although it only outputs 64 bit values per cycle. In contrast to Xorshift64* it adds two consecutive state values as a nonlinear transformation to the output.

Park-Miller ”Minimal Standard”

The Minimal Standard algorithm is a linear congruential generators (LCG) and has been known for decades [86]. Motivated by its objective to design a lightweight generator that is confined to 32 bit arithmetic without divisions, it was criticized for its statistical properties repeatedly [87]. The generator has a period or , and it is limited to produce 31 pseudo-random bits during each cycle. In RIOT, however, the API presumes 32 bit random integers, thus, one integer is generated by combining two generator outputs on each random request, which limits the usable period to . LCGs are generally not designed for cryptographic purposes.

Knuth LCG

The Knuth LCG is a widely used linear congruence generator, which is computationally lightweight and has been examined for decades. It is implemented in a range of software projects and the source code is available in different standard libraries such as Newlib 888https://sourceware.org/newlib/ or Musl C 999https://wiki.musl-libc.org/. The generator adopts a multiplier that was obtained by Knuth [50, Chapter 3.3.2, p. 108] but current implementations differ from the “MMIX” Knuth LCG in its increment. Furthermore, it truncates the most significant bits of the 64 bit state to 32 bit output values due to known poor statistical properties of the lower bits in modulo-2 generators [88].

Fig. 7: Pseudo Random Numbers: -test results on the distribution of probability values from 15 NIST STS tests. -values pass the hypothesis of uniformity.

Vii-C Statistical Analysis with NIST STS

Our first statistical analysis applies the NIST STS test suite to these generators. The results of the -test are shown in Figure 7. We display average -values, where applicable. Analog to Section VI-B, tests are only passed after a significant proportion of repeated successful runs. That is, 96 successful results for a sample size of 100 sequences. Test 11 and Test 12 (Random Excursions and Random Excursions Variant), however, are not always applicable and as such, they reduce the sample size internally. In our configuration, that lead to proportions of sequences passing one of both tests ranging from 53/56 to 67/71, in different PRNG measurements.

All generators except for the Xorshift pass all 15 statistical NIST tests. Xorshift results indicate a failure of the Rank (Binary Matrix Rank) test. This test analyses linear dependences among substrings of a sequence. In our case, all 100 test sequences fail already the first order hypothesis test and thus, the -distributions test fails as a consequence. We consider this as weakness of the Xorshift. The deficit is fixed with the extensions applied to Xorshift64* and Xoroshiro128+, which pass all tests.

The Frequency Test on the Mersenne Twister had a very small -value on the first run (not displayed here) and we ran the same test again with altered seed value during initialization. This succeeded the test as displayed in Figure 7. We want to stress that the magnitude of a -value in hypothesis testing is not a causal measure of quality. This means that a low -value confirms to reject a null hypothesis (sequence is not random) but it does not claim how likely it is that the alternative hypothesis is true (sequence is random). For further interpretation of statistical tests, we refer the reader to the NIST test suite description [24] and work by Greenland et al.  [89].

Vii-D Statistical Analysis with DIEHARDER

Fig. 8: KS-test results on the distribution of probability values from 31 DIEHARDER tests. -values in the significance interval with pass the test. -values within the interval with are considered as weak.

Next, we apply the DIEHARDER test suite to our random generator candidates. DIEHARDER test values behave similar to the NIST STS results presented in the previous section, but procedures are more demanding and failures are more distinctive.

Results of the Kolmogorov-Smirnov test for each PRNG in RIOT are displayed in Figure 8. Similar to the NIST tests, we plot average -values, where applicable. In the style of previous graphs, we display passing tests with gray bars, and we highlight failed tests with hatched red bars or red arrows in case that the -value is too small to be displayed. Additionally, we mark weak results with black bars.

All complex generators displayed in the first row of Figure 8 pass all tests. Few test statistics return weak results, which is expected in 1 % of the test cases due to the uniform distribution of p-values. The DIEHARDER help page 101010https://linux.die.net/man/1/dieharder recommends repeated test executions and analysis of p-value histograms on weak results. All weak results in Figure 8 passed a repeated experiment run with a different seed.

Several failures must be observed for the lightweight generators displayed in the second row of Figure 8. The Tiny Mersenne Twister fails Tests OQSO (Overlapping Quadruples Sparse Occupancy Test), and the DNA test, which both examine the distribution of overlapping substrings in a stream of random integer values. These results indicate a systematic problem of the generator.

The Xorshift generator fails the Monobit 2 test, the 32x32 Binary Rank test, and the Count the 1s Stream test. The Monobit 2 is a derivate of the NIST Frequency test and measures the proportion of zeros and ones within blocks (12-bit blocks applied here). Surprisingly, the general Monobit test, which counts “1” bits in a long sequence of random samples (100000 samples considered here) does not fail. Hence, the Xorshift introduces bias within smaller sub-blocks, which is compensated over the whole sequence. Results persist after repeated experiment executions with different seeds. Failing on the matrix rank test was expected, as the equivalent from the NIST STS already failed in a similar configuration. The Count the 1s Stream Test examines whether the distribution of ones in a stream of bytes matches that of uniform random bytes (Binomial(8, 0.5)). Failures indicate that Xorshift output streams produce repeated “words” that appear with pronounced probability. It is likely that the same effect led to bad results of the linear dependency test among sub-matrices. The advanced Xorshift64* and Xoroshiro128+ generators pass all DIEHARDER tests.

The Minimal Standard generator fails the Bitstream and the Generalized Minimum Distance test. The first successively analyses overlapping 20-bit tuples (

possible words) and tests the statistic of missing words for a normal distribution. Failing this test indicates recurrence of patterns with enhanced probability. The second test places random pairs of points in a square and tests its squared distances for an exponential distribution. The Minimal Standard generator fails to produce outputs that appear independent in this dimension. Finally, this generator issues a suspiciously high number of weak test results. For further interpretation of test results, we refer to the DIEHARDER Test Suite description 

[49].

Vii-E Statistical Analysis with TestU01

We additionally apply the “BigCrush” from the TestU01 test suite to all software generators. Table V summarizes test results with failures reflecting the number of reported test statistics with -values outside the confidence interval [0.001, 0.9990].

Generator
Fortuna
CTR
PRNG
SHA256PRNG
Mersenne
Twister
Tiny Mers.
Twist.
Xorshift
Minimal
Standard
Knuth LCG
Failures 1/160 0/160 0/160 2/160 13/160 58/160 71/160 9/160
TABLE V: Summary of test results from the “BigCrush” of the TestU01 environment.

Results reflect a similar picture as depicted by NIST and DIEHARDER. TestU01, though, stresses more failures due to a higher number of tests and tighter hypothesis criteria. According to L’Ecuyer et al.  [54], -values outside the significance interval are obtained approximately 2 % of the time, even if the PRNG behaves well. This, however, should not reoccur systematically.

The Minimal Standard misses almost half of all tests (45 %), and the Xorshift fails a surprisingly high number of 58 tests (35 %), which reduces to 1–2 failures for its enhanced derivatives Xorshift64* and Xoroshiro128+. The Tiny Mersenne Twisters attains a failure rate of 8 %, which still exceeds the acceptable rate by a factor of four, whereas the Knuth LCG performs notably better, failing about 5 % of the test statistics.

For the Mersenne Twister, both failures have a -value of more than , which significantly misses the acceptance interval, and unacceptable results reappear with repeated experiment runs of different start values. This indicates systematic weaknesses. In contrast, all CSPRNGs report zero or single failures based on -values at the order of . Repeated test executions then passed these tests.

Vii-F Performance Analysis

In the constrained IoT, an important dimension for any base system primitive lies in its performance. To assess the value of the different random number generators, we measure the computational speed, the memory overhead, and the energy consumption of all random number generators. Thereby, we consider base mechanisms, and we disable reseeding, if available.

Throughput

We measure the throughput and speed of each generator on the IoT STM32F4 hardware platform that has been introduced in Section VI. Our test applications are implemented analogously to those presented in Section VI-C. In addition, we display maximum values for cases, in which a generator occasionally takes significant time to rebuild its internal state. Results are summarized in Table VI.

Generator
Byte rate
[kB/s]
Avg. time
per Int. [us]
Max. time
per Int. [us]
Fortuna 44 87.50
CTR PRNG 102 442.01111111CTR PRNG always calculates at least one AES-128 cipher on each call
SHA256PRNG 393 10.04 69.60
Mersenne Twister 3605 0.85 189.20
Tiny Mers. Twist. 4807 0.62
Xorshift 8152 0.28
Minimal Standard 3348 0.98
Knuth LCG 6147 0.44
TABLE VI: PRNG throughput and processing time measured on STM32F4.

Naturally, the four lightweight generators are fastest. They can reliably compute a random number in less than a microsecond. The two ultra-lightweight algorithms Knuth LCG and Xorshift can even produce several numbers per microsecond on the constrained microcontroller, which must be considered a very low runtime overhead. With a production rate of more than five MB/s, these generators could seamlessly support a stream cypher, if they were cryptographically secure. Unfortunately they are not, but showed some weaknesses in statistical tests as discussed in the previous section. Xorshift clearly has the highest throughput. Its derivatives Xorshift64+ and Xoroshiro128+ perform around 2–3 times slower.

From the complex generators, SHA256PRNG and the Mersenne Twister are presented with additional maximal values in processing time. For SHA256PRNG this is due to the algorithmic property of producing 32 Bytes in one hash call, which thereafter are split into 8 Byte long integer values. Hence, a hash value is computed only every fifth call, which then takes significantly longer. The Mersenne Twister follows a similar approach, although it does not involve cryptographic functions. At the initialization and every 624 calls, it generates 624 fresh pseudo-random integers, which takes up to 190 s. This is orders of magnitudes longer than simply returning a value from its buffer. This notably degrades its performance in comparison with the other lightweight generators.

The three cryptographically secure generators Fortuna, CTR PRNG and SHA256PRNG operate more than one order of magnitude slower than the general purpose counterparts. All algorithms involve cryptographic functions (AES-128, SHA-256), which are computationally expensive on constrained microcontrollers. Clearly, the SHA256PRNG is the most vital among all crpyto-generators presented, requiring around 70 s on every hash computation, which leads to an average time of 10 s per integer with number caching, and a rate of almost 400 kB/s. The more advanced NIST Hash DRBG (SHA-256) doubles the time per integer due to additional hash computation in the feedback path. The implementation, however, does not allow number caching. This overhead is compensated while requesting larger random blocks or streams because state updates only occur once after each API call, while generating large outputs requires multiple hashing.

In comparison to SHA256PRNG, the CTR PRNG generates random four times slower in a stream of numbers, whereas returning one random integer takes between six and thirty times longer. The CTR PRNG on the other hand has an almost constant runtime per integer. It is noteworthy that up to 16 Bytes can be obtained by the CTR PRNG without runtime overhead because this generator computes one AES-128 block on every call that delivers 128 Bit from which four 32 Bit integers can be created. The Fortuna operates slowest when requesting continuous random data and it halves the throughput of the CTR PRNG. It has a constant runtime per integer of less than 90 s, which on the other hand is faster by a factor of five than the CTR PRNG. It requires approximately 120 % of time as the SHA256PRNG when processing a new hash internally (every eighth call), why the rate is less by a factor of almost ten.

It is worth noting that the different design choices between SHA256PRNG and CTR PRNG relate to security implications. Holding a precomputed hash value in RAM as SHA256PRNG does while only one integer is requested may violate security requirements. In the presence of protected memory, a generator could secure its state and its cached numbers to reduce the attack surface. Low-cost devices often lack memory protection mechanisms and as such, a design might be favored that avoids keeping sensitive data in memory for longer intervals in order to prevent (i) manipulation of future output (see Section II) as well as (ii) predicting future random numbers (see Section III). In the presence of frequent re-seeding from fresh entropy, the generator state becomes less sensitive to memory attacks. In contrast, the purpose of caching is performance enhancement and random numbers would be simply returned without update after re-seeding. Still, the performance per integer request of the CTR PRNG would notably benefit from a caching mechanism.

Memory Overhead

Memory is a particular scarce resource on IoT devices, why memory of random number generators should have the lowest possible footprint. We evaluate the memory overhead, which comes on top of a minimal RIOT build while enabling different PRNGs at compile time for the target STM32F4 MCU in Figure 11. Numbers are differentiated w.r.t. RAM and ROM memory. Furthermore, crypto-purpose generators include dependencies such as hash functions and ciphers, which are highlighted as “RAM/ROM Dep.”.

(a)
(b)
Fig. 11: PRNG memory overhead in ROM (left) and RAM (right) measured on the STM32F4 microcontroller. “Dep.” denotes memory requirements of dependent software modules (i.e., hashes, ciphers) that a generator may include.

Results reassure the unsurprising previous observation that complexity of the PRNGs correlates with resource consumption. Similar to the throughput measurements, Xorshift, Minimal Standard and Knuth LCG generators remain most frugal in memory and only require around 100 Bytes additional ROM and few additional Bytes in RAM. The internal state size (32 bit), i.e., 4 Bytes in RAM suffice for the Xorshift, whereas the Knuth LCG adds an internal multiplier to a total of 8 Bytes RAM. Similarly, Xorshift64* has an 8 Byte state, but it requires additional memory to split and buffer 8 Bytes generated on each cycle into two 32 bit integers. In total, Xorshift64* allocates 20 Bytes RAM and Xoroshiro128+ allocates 28 Bytes. The Xorshift-derivatives hence operate on a different scale than the ultra-lightweight alternatives. Both Mersenne Twisters allocate between 250–300 Bytes in ROM, whereby the “tiny” version surprisingly requires the higher amount. The Mersenne Twister is comparably RAM intensive by allocating up to 2.5 kB, which is mainly used for its buffer of 624 integers.

Crypto-secure PRNG such as SHA256PRNG and CTR PRNG are rather efficient in RAM when compared to the Mersenne Twister, but are more demanding in ROM memory. This is mainly due to its dependencies cryptographic functions. The NIST Hash DRBG (SHA-256) uses similarly much RAM as the SHA256PRNG but it requires additional 800 Bytes ROM. Reasons for that relate to the extra logic in the state update function as well was reseeding capabilities of this CSPRNG. The most demanding generator in terms of ROM memory is the Fortuna due to its dependencies to multiple cryptographic functions. It includes the SHA-256 and the AES-128 RIOT modules, which is the main source of high ROM requirement. Furthermore, the Fortuna internally implements an entropy pool that by default initializes 32 SHA-256 contexts, one of which requires 104 Bytes. This is the main reason for its high RAM consumption of around 3,5 kB. Here it must be stressed that this already consumes 10 % of the available memory on the test device, or 44 % on an Arduino Mega 2560.

Energy Consumption

We evaluate the energy consumption with the same setup as described in Section VI. Figure 12 displays the energy consumed by each pseudo-random generators in RIOT, measured on the STM32F4 platform. The Fortuna, CTR PRNG and the SHA256PRNG crypto-purpose generators are most expensive in energy—up to several micro Joule per integer. Thereby, SHA256PRNG operates at the lower end and the SHA256-based NIST Hash DRBG consumes about twice as much. The CTR PRNG notably demands maximal resources. Using approximately 24 J it drains a factor of 3.7 more energy than the Fortuna. The CTR PRNG generates four integers in one call, why it outperforms the Fortuna slightly in a stream of random numbers.

All other PRNGs operate on the same scale as the on-chip HWRNG on that device (compare Figure 6), which takes approximately 0.03 J. Non-cryptographic generators remain by a factor of 20–100 below the most efficient cryptographic generator SHA256PRNG. The most resource-friendly general-purpose PRNGs are the Xorshift with an average of 0.01 J and the Knuth LCG with 0.02 J per integer, which is in agreement with our findings from throughput measurements in Table VI. The enhanced Xorshift64* and Xoroshiro128+ consume 3–4 times more energy than their lightweight 32 bit Xorshift companion, which is a notable increase over the Knuth LCG.

Fig. 12: PRNG energy consumption per integer measured on a STM32F4 microcontroller.

Vii-G Recommendations on Software-PRNGs

Having examined eleven widely available software-PRNGs (eight algorithms plus three variants) that cover the basic levels and functions, we are now ready to make the choice of recommendation for random number generators to be included in a constrained IoT operating system. Following the previous discussion in Section IV, we differentiate our selections in one general purpose and one crypto-secure PRNG as two different system functions.

General Purpose Generator

The general purpose generator should be very lightweight, while complying with common statistical requirements. It should run seamlessly on very constrained 8 bit microcontrollers at low energy costs.

From the two ultra-lightweight generators, only the Knuth LCG passes all NIST and Dieharder statistical tests. It performs second best. The Xorshift generator consumes about half of its resources, but has notable statistical flaws. The Knuth LCG produces better output sequences while being similarly fast. The enhanced Xorshift64* or Xoroshiro128+ generators exceed resource consumption of the Knuth LCG significantly. All other lightweight generators admit lower statistical quality at higher cost. We therefore recommend the Knuth LCG to be used as general-purpose, non-cryptographic PRNG in the constrained IoT.

Crypto-secure Generator

The Fortuna, SHA256PRNG, (NIST Hash DRBG,) and CTR PRNG are the only candidates for a CSPRNG, as they are constructed from secure and non-invertible cryptographic functions. They pass all statistical tests (including BigCrush) and fulfill the requirements of unpredictability and brute-force resistance.

Perfect forward and backward secrecy after a state compromise is assured by the Fortuna, CTR PRNG and the NIST Hash DRBG based on their one-way nature during state update in combination with re-seeding. The SHA256PRNG holds a (linear combination of) the previous-to-last state and thus only guarantees forward secrecy for earlier values due to its secure one-way SHA-256 output function (cf., [13]). Backward secrecy can be added by reseeding on demand to the generator as discussed in III-C.

This generator stands out as it is the only cryptographically secure algorithm that attains moderate performance values. All competitors exceed the SHA-256 performance measures by one order of magnitude in at least one dimension. We conclude that the resource frugality in combination with modular cryptographic robustness justify to commend SHA256PRNG as the CSPRNG in the constrained IoT.

Viii Hardware or Software Generated Randomness in the IoT?

An increasing number of embedded controllers is expected to provide hardware primitives for basic cryptographic operations in the near future, which bring promise of fast and efficient random generators that contribute real entropy. The performance of on-chip HWRNGs, however, is heterogeneous. Some devices operate fast and save battery resources (i.e., STM32F4), while others are slow and require notably larger amounts of energy (i.e., nRF52840) than corresponding software. As shown in Section VI, few devices even produce poor statistical output (i.e., CC2538). Some manufacturers advice against an immediate use for cryptographic random number. Other manufacturers describe their on-chip random number generators as suitable for cryptographic purposes without providing a cryptographic proof (Nordic). Truly random generators rely on real entropy from a physical process. This may be influenced by environmental factors, which opens an attack surface.

Common IoT operating system such as RIOT need to make decisions on which hardware functions to include and how to integrate hardware and software components into the random subsystem. These multi-platform multi-purpose systems want to provide an overall lean solution of reliable quality at a predictable performance. To aid this design process, we now analyze key performance properties of the different hardware- and software-based random number generators.

In Figure 13, we compare energy consumption and average generation time per integer (left) as well as the average current flow (right) for the hardware systems summarized in Table I. Software generators are measured on the STM32F4 board.

Fig. 13: Average energy consumption over average time (left) and average current draw (right) for hardware and software generated random integers.

We observe that the lightweight software generators are fastest and together with the HWRNG on the chip of STM32F4 consume least energy. While software PRNGs operate up to five times faster, they charge a higher current than the HWRNG which results in a similar energy footprint. On-chip hardware generators on the CC2328 and MKW22D devices consume about one order of magnitude more time and energy. Hence we argue for the choice of a lightweight software generator (i.e., the Knuth LCG) for the regular production of random numbers. Hardware generators are best used for (re-)seeding, when true entropy is required.

Running a cryptographically secure generator demands unsurprisingly more energy resources in comparison to its lightweight PRNG alternatives or the STM32F4 on-chip HWRNG solution. Among the three software CSPRNGs, SHA256PRNG is clearly most frugal with an energy consumption of 0.5 J for one integer and an average current consumption of 17 mA. Note that caching is involved here, thus, only every eighth requested integer involves computation of a new hash which then causes currents up to 20 mA. Fortuna and CTR PRNG drain notably more energy in comparison to the SHA256PRNG as already visible in the previous analysis. CTR PRNG consumes up to 24 J for one integer, which is four times more than Fortuna, even though its average current consumption is similar to the SHA256PRNG that uses 5 mA less than Fortuna. The increased energy consumption for one integer may be compensated in a stream or by caching intermediate numbers. Hardware based random numbers on the nRF52840 controller consume energy similar to the CSPRNGs, although the low-power MCU drains less than 5 mA in both operation modes (w/ and w/o bias correction). This is due to its slow operation.

The external ATECC508A chip, which implements an approved CSPRNG in hardware, exhibits a worse performance than all software CSPRNGs. The throughput of the software solutions is 20–100 times higher while the energy consumption remains 3–10 times less. The average current of the ATECC508A solution remains small in comparison to the software solutions that do not even have to power a second device. This is because the main controller idles while the external chip processes random values. The external chip requires only a small current as shown in Section VI-C. Eventually, the total energy consumption can be improved by further driver optimizations. A minimum of 280 J is required to request from one up to eight integers. It is noteworthy that this chip implements secure seeding on its own, which enhances very constrained devices without proper entropy sources.

Memory limitations of very constrained devices (e.g., ATmega2560 with only 8 kB RAM and 256 kB Flash) are unable to run complex software CSPRNGs as they require more memory. The Fortuna CSPRNG would take almost 50% of the ATmega2560 RAM leaving only 4 kB for the remaining firmware. This is not sufficient for real-world IoT-networking applications [45]. Instead, the device driver for the ATECC508A chip can be included which (i) reduces the memory requirements of cryptographic functions, (ii) offloads processing of complex algorithms on the device, and (iii) includes additional crypto-related features at the same time.

Next to the dedicated crypto-chip, other external randomness generators, namely the AT86RF233 transceiver as well as the SRAM PUF are energy expensive using up to one order of magnitude more than the SHA256PRNG. Both mechanisms, though, are not designed to be used periodically. Instead, they act as seed sources that are utilized once during instantiation of a PRNG and on re-seeding. The current consumptions differ notably between the transceiver and the PUF SRAM. The transceiver powers two devices in active mode because the MCU polls random bytes via the SPI while the radio needs to stay in receive mode. This draws a current of up to 26 mA in total. The PUF SRAM on the other hand takes twice as long to retrieve a high entropy integer but it drains less than 10 mA on average. As depicted in Section VI-A, this procedure needs to take place very early on startup—even before clock and bus initialization in the operating system.

In summary, we argue that software generators—a lightweight general purpose PRNG or an approved CSPRNG—are the preferable solution for producing (secure) random numbers. Co-processors and hardware assistance are vital for adding entropy at (re-)seeding instances and can help to improve memory footprints for very constrained devices. They lead to a decreased throughput, though, when compared to software that runs on the main controller. In particular, transceivers as well as uninitialized SRAM are very important on devices with missing HWRNGs. Even though PUF SRAM and the radio-based entropy sources are costly, they uniquely contribute entropy and are only sparsely called for seeding purposes.

Ix Conclusions and Outlook

In this paper, we explored the building blocks for randomness in the constrained Internet of Things: hardware and software components that generate statistical randomness, entropy, and robustness according to cryptographic challenges. We systematically derived the requirements for IoT random subsystems from the perspectives of statistics, security, and operating system integration. An extensive, comparative evaluation using several prominent test suites as well as detailed performance measurements on popular boards delivered insights into the overall quality and suitability of the different components under test.

This work derives four major recommendations:

  1. Separate general purpose random generators from cryptographically secure generators already on the OS level. Avoid any mixture or interference between the two.

  2. Prefer software generators over random hardware, as they are more efficient and reliable. Exploit hardware components as additional entropy sources for (re-)seeding, or when CSPRNG operation is infeasible on a constrained node.

  3. The Knuth LCG is the most efficient general purpose generator of decent statistical quality. It is simple and lean enough to run on very constrained devices.

  4. We recommend SHA256 PRNG as a cryptographically secure generator, since it outperforms its competitors by an order of magnitude in several dimensions.

With this work, we hope to contribute to a thoughtful development toward a secure Internet of Things. This will be of particular importance, as more and more (sensitive) data originates from IoT nodes and needs protection. Content object security with OSCORE [90, 91] and LAKE [92], for example, will facilitate the encryption of individual information units, but will extend the use of cryptographic primitives such as random numbers during operation.

References

  • [1] H. Corrigan-Gibbs and S. Jana, “Recommendations for Randomness in the Operating System, or How to Keep Evil Children out of Your Pool and Other Random Facts,” in 15th Workshop on Hot Topics in Operating Systems (HotOS XV).   USENIX Association, 2015.
  • [2] C. Bormann, M. Ersue, and A. Keranen, “Terminology for Constrained-Node Networks,” IETF, RFC 7228, May 2014.
  • [3] E. Baccelli, O. Hahm, M. Günes, M. Wählisch, and T. C. Schmidt, “RIOT OS: Towards an OS for the Internet of Things,” in Proc. of the 32nd IEEE INFOCOM. Poster.   Piscataway, NJ, USA: IEEE Press, 2013, pp. 79–80.
  • [4] M. Lenders, P. Kietzmann, O. Hahm, H. Petersen, C. Gündogan, E. Baccelli, K. Schleiser, T. C. Schmidt, and M. Wählisch, “Connecting the World of Embedded Mobiles: The RIOT Approach to Ubiquitous Networking for the Internet of Things,” Open Archive: arXiv.org, Technical Report arXiv:1801.02833, January 2018. [Online]. Available: https://arxiv.org/abs/1801.02833
  • [5] M. Frey, C. Gündogan, P. Kietzmann, M. Lenders, H. Petersen, T. C. Schmidt, F. Shzu-Juraschek, and M. Wählisch, “Security for the Industrial IoT: The Case for Information-Centric Networking,” in 2019 IEEE 5th World Forum on Internet of Things (WF-IoT) (WF-IoT 2019).   Piscataway, NJ, USA: IEEE Press, April 2019, pp. 424–429. [Online]. Available: http://dx.doi.org/10.1109/WF-IoT.2019.8767183
  • [6] M. Rottleuthner, T. C. Schmidt, and M. Wählisch, “Eco: A Hardware-Software Co-Design for In Situ Power Measurement on Low-end IoT Systems,” in ACM SenSys, 7th International Workshop on Energy Harvesting & Energy-Neutral Sensing Systems (ENSsys 2019).   New York: ACM, November 2019, pp. 22–28. [Online]. Available: https://doi.org/10.1145/3362053.3363495
  • [7] D. H. Lehmer, “Mathematical Methods in Large-scale Computing Units,” in Proceedings of the Second Symposium on Large Scale Digital Computing Machinery.   Cambridge, United Kingdom: Harvard University Press, 1951, pp. 141–146.
  • [8] D. E. 3rd, J. Schiller, and S. Crocker, “Randomness Requirements for Security,” IETF, RFC 4086, June 2005.
  • [9] Y. Dodis, D. Pointcheval, S. Ruhault, D. Vergniaud, and D. Wichs, “Security Analysis of Pseudo-random Number Generators with Input: /dev/random is not Robust,” in CCS ’13: Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security.   New York, NY, USA: ACM, 2013, pp. 647–658.
  • [10] A. Francillon and C. Castelluccia, “TinyRNG: A Cryptographic Random Number Generator for Wireless Sensors Network Nodes,” in WIOPT ’07: 5th International Symposium on Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks and Workshops.   Limassol, Cyprus: IEEE, 2007, pp. 1–7.
  • [11] K. Nohl, D. Evans, S. Starbug, and H. Plötz, “Reverse-Engineering a Cryptographic RFID Tag,” in 17th Conference on Security Symposium (SS ’08).   San Jose, CA, USA: USENIX Association, 2008, pp. 185–193.
  • [12] Introduction to STM32 microcontrollers security, STMicroelectronics, October 2019, rev. 3.
  • [13] J. Kelsey, B. Schneier, D. Wagner, and C. Hall, “Cryptanalytic Attacks on Pseudorandom Number Generators,” in FSE ’98: Proceedings of the 5th International Workshop on Fast Software Encryption.   London, UK, UK: Springer-Verlag, 1998, pp. 168–188.
  • [14] J. Kelsey, B. Schneier, and N. Ferguson, “Yarrow-160: Notes on the Design and Analysis of the Yarrow Cryptographic Pseudorandom Number Generator,” in 6th Annual Workshop on Selected Areas in Cryptography.   Berlin, Heidelberg: Springer, 1999, pp. 13–33.
  • [15] L. Dorrendorf, Z. Gutterman, and B. Pinkas, “Cryptanalysis of the Windows Random Number Generator,” in CCS ’07: Proceedings of the 14th ACM Conference on Computer and Communications Security.   New York, NY, USA: ACM, 2007, pp. 476–485.
  • [16] T. Ristenpart and S. Yilek, “When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities and Hedging Deployed Cryptography,” in NDSS, 2010.
  • [17] Z. Guttermann, B. Pinkas, and T. Reinman, “Analysis of the Linux Random Number Generator,” in Symposium on Security and Privacy (S&P ’06).   Berkeley, CA, USA: IEEE, 2006, pp. 371–385.
  • [18] D. Kaplan, S. Kedmi, R. Hay, and A. Dayan, “Attacking the Linux PRNG on Android: Weaknesses in Seeding of Entropic Pools and Low Boot-Time Entropy,” in 8th USENIX Conference on Offensive Technologies (WOOT ’14).   USENIX Association, 2014.
  • [19] I. Goldberg and D. Wagner, “Randomness and the Netscape Browser,” https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.html, last accessed 07-17-2020, 1996.
  • [20] D. Shumow and N. Ferguson, “On the Possibility of a Back Door in the NIST SP800-90 Dual EC PRNG,” http://rump2007.cr.yp.to/15-shumow.pdf, last accessed 07-17-2020, 2007.
  • [21] Bushing and Marcan and Segher and Sven, “Console Hacking 2010 - PS3 Epic Fail,” https://fahrplan.events.ccc.de/congress/2010/Fahrplan/attachments/1780_27c3_console_hacking_2010.pdf, last accessed 07-17-2020, 2010.
  • [22] A. K. Lenstra, J. P. Hughes, M. Augier, J. W. Bos, T. Kleinjung, and C. Wachter, “Ron was wrong, Whit is right,” https://eprint.iacr.org/2012/064, last accessed 07-17-2020, 2012.
  • [23] W. Killmann and W. Schindler, “A proposal for: Functionality classes for random number generators,” BSI, Bonn, Germany, Tech. Rep. AIS 20 / AIS 31, 2011.
  • [24] L. Bassham, A. Rukhin, J. Soto, J. Nechvatal, M. Smid, E. Barker, S. Leigh, M. Levenson, M. Vangel, D. Banks, N. A. Heckert, J. Dray, and S. Vo, “A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications,” National Institute of Standards & Technology, Gaithersburg, MD, US, Special Publication NIST SP 800-22, 2010.
  • [25] E. B. Barker and J. M. Kelsey, “Recommendation for Random Number Generation Using Deterministic Random Bit Generators,” National Institute of Standards & Technology, Gaithersburg, MD, United States, Special Publication NIST SP 800-90A, 2012.
  • [26] W. Stallings, Cryptography and Network Security, 6th ed.   Pearson Education, 2014.
  • [27] E. Rescorla and N. Modadugu, “Datagram Transport Layer Security Version 1.2,” IETF, RFC 6347, January 2012.
  • [28] H. Tschofenig and T. Fossati, “Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things,” IETF, RFC 7925, July 2016.
  • [29] M. Girault, R. Cohen, and M. Campana, “A Generalized Birthday Attack,” in EUROCRYPT ’88: Advances in Cryptology, ser. LNCS, vol. 330.   Berlin, Heidelberg: Springer, 1988, pp. 129–156.
  • [30] M. Bellare and T. Kohno, “Hash Function Balance and Its Impact on Birthday Attacks,” in EUROCRYPT ’04: Advances in Cryptology, ser. LNCS, vol. 3027.   Berlin, Heidelberg: Springer, 2004, pp. 401–418.
  • [31] D. Harkins and D. Carrel, “The Internet Key Exchange (IKE),” IETF, RFC 2409, November 1998.
  • [32] M. Mitzenmacher and E. Upfal, Probability and Computing: Randomization and Probabilistic Techniques in Algorithms and Data Analysis (Second Edition).   Cambridge University Press, 2017.
  • [33] C. E. Shannon, “A Mathematical Theory of Communication,” Bell System Technical Journal, vol. 27, pp. 379–423, 623–656, July/Oct. 1948.
  • [34] M. S. Turan, E. B. Barker, J. M. Kelsey, K. A. McKay, M. L. Baish, and M. Boyle, “Recommendation for the Entropy Sources Used for Random Bit Generation,” National Institute of Standards & Technology, Gaithersburg, MD, United States, Special Publication NIST SP 800-90B, 2018.
  • [35] J. Woodage and D. Shumow, “An Analysis of NIST SP 800-90A,” in EUROCRYPT ’19: Advances in Cryptology, ser. LNCS, vol. 11477.   Berlin, Heidelberg: Springer, 2019, pp. 151–180.
  • [36] E. B. Barker and J. M. Kelsey, “Recommendation for Random Bit Generator (RBG) Constructions,” National Institute of Standards & Technology, Gaithersburg, MD, United States, Special Publication NIST SP 800-90C, 2016.
  • [37] P. Gutmann, “Software Generation of Practically Strong Random Numbers,” in SSYM ’98: Proc. of 7th USENIX Security Symposium.   Berkeley, CA, USA: USENIX Association, 1998, pp. 19–19.
  • [38] N. Ferguson, B. Schneier, and T. Kohno, Cryptography Engineering: Design Principles and Practical Applications.   Wiley Publishing, 2010.
  • [39] D. J. Bernstein, “Entropy Attacks! The conventional wisdom says that hash outputs can’t be controlled; the conventional wisdom is simply wrong.” https://blog.cr.yp.to/20140205-entropy.html, last accessed 07-17-2020, 2014.
  • [40] V. Dukhovni, “Opportunistic Security: Some Protection Most of the Time,” IETF, RFC 7435, December 2014.
  • [41] A. Dunkels, B. Grönvall, and T. Voigt, “Contiki - A Lightweight and Flexible Operating System for Tiny Networked Sensors.” in Proc. of IEEE Local Computer Networks (LCN).   Los Alamitos, CA, USA: IEEE Computer Society, 2004, pp. 455–462.
  • [42] ARM Ltd., “Mbed OS,” https://www.mbed.com, last accessed 07-17-2020.
  • [43] Zephyr Project, “Zephyr,” https://www.zephyrproject.org, last accessed 07-17-2020.
  • [44] Apache Software Foundation, “Apache Mynewt,” https://mynewt.apache.org, last accessed 07-17-2020.
  • [45]

    E. Baccelli, C. Gündogan, O. Hahm, P. Kietzmann, M. Lenders, H. Petersen, K. Schleiser, T. C. Schmidt, and M. Wählisch, “RIOT: an Open Source Operating System for Low-end Embedded Devices in the IoT,”

    IEEE Internet of Things Journal, vol. 5, no. 6, pp. 4428–4440, December 2018. [Online]. Available: http://dx.doi.org/10.1109/JIOT.2018.2815038
  • [46] ARM Ltd., “Mbed TLS,” https://tls.mbed.org, last accessed 07-17-2020.
  • [47] Intel Corporation, “TinyCrypt Cryptographic Library,” https://github.com/intel/tinycrypt, last accessed 07-17-2020.
  • [48] D. F. Aranha and C. P. L. Gouvêa, “RELIC is an Efficient LIbrary for Cryptography,” https://github.com/relic-toolkit/relic.
  • [49] R. G. Brown, D. Eddelbuettel, and D. Bauer, “Dieharder: A Random Number Test Suite,” 2019. [Online]. Available: https://webhome.phy.duke.edu/~rgb/General/dieharder.php
  • [50] D. E. Knuth, The Art of Computer Programming (Second Edition).   Addison Wesley, 2009.
  • [51] NIST, “Security Requirements for Cryptographic Modules,” National Institute of Standards & Technology, Gaithersburg, MD, US, Federal Information Processing Standards 140–1, January 2001.
  • [52] ——, “Security Requirements for Cryptographic Modules,” National Institute of Standards & Technology, Gaithersburg, MD, US, Federal Information Processing Standards 140–2, May 2002, supersedes FIPS 140–1.
  • [53] G. Marsaglia, “The Marsaglia Random Number CDROM including the Diehard Battery of Tests of Randomness,” https://web.archive.org/web/20160125103112/http://stat.fsu.edu/pub/diehard, last accessed 07-17-2020, 1995, originally published in https://stat.fsu.edu/pub/diehard.
  • [54] P. L’Ecuyer and R. Simard, “TestU01: A C Library for Empirical Testing of Random Number Generators,” ACM Trans. Math. Softw., vol. 33, no. 4, 2007.
  • [55] M. Sýs and Z. Říha, “Faster Randomness Testing with the NIST Statistical Test Suite,” in SPACE ’14: Security, Privacy, and Applied Cryptography Engineering.   Cham, Switzerland: Springer, 2014, pp. 272–284.
  • [56] P. L’Ecuyer and R. Simard, “TestU01 A Software Library in ANSI C for Empirical Testing of Random Number Generators. User’s guide, compact version,” Department of Computer Science and Operations Research, University of Montreal, Montreal, Canada, Tech. Rep., 2013.
  • [57] M. Mascagni and A. Srinivasan, “Algorithm 806: SPRNG: A Scalable Library for Pseudorandom Number Generation,” ACM Trans. Math. Softw., vol. 26, no. 3, 2000.
  • [58] J. Walker, “A Pseudorandom Number Sequence Test Program,” http://www.fourmilab.ch/random/, last accessed 07-17-2020, 2008.
  • [59] H. Demirhan and N. Bitirim, “CryptRndTest: An R Package for Testing the Cryptographic Randomness,” The R Journal, vol. 8, pp. 233–247, 2016.
  • [60] STM32F410 advanced Arm-based 32-bit MCUs, STMicroelectronics, November 2018, rev. 3.
  • [61] MKW2xD Reference Manual, NXP, May 2016, rev. 3.
  • [62] nRF52840 Product Specification, Nordic Semiconductor, March 2018, version 1.0.
  • [63] CC2538 System-on-Chip Solution for 2.4-GHz IEEE 802.15.4 and ZigBee/ZigBee IP Applications, Texas Instruments, May 2013, version C.
  • [64] AT86RF233 Low Power, 2.4GHz Transceiver for ZigBee, RF4CE, IEEE 802.15.4, 6LoWPAN, and ISM Applications, Atmel, July 2017, rev. 8315E–MCU Wireless–07/14.
  • [65] ATECC508A CryptoAuthentication Device Complete Data Sheet, Microchip, December 2017, rev. A.
  • [66] Generating Random Secrets: ATSHA204A, ATECC108A, and ATECC508A, Atmel, September 2015, rev. 8843B.
  • [67] A. van Herrewege, V. van der Leest, A. Schaller, S. Katzenbeisser, and I. Verbauwhede, “Secure PRNG Seeding on Commercial Off-the-shelf Microcontrollers,” in 3rd International Workshop on Trustworthy Embedded Devices (TrustED ’13).   New York, NY, USA: ACM, 2013, pp. 55–64.
  • [68] A. Schaller, “Lightweight Protocols and Applications for Memory-Based Intrinsic Physically Unclonable Functions Found on Commercial Off-The-Shelf Devices,” Doctoral Dissertation, Department of Computer Science, Technische Universität Darmstadt, December 2017. [Online]. Available: http://tuprints.ulb.tu-darmstadt.de/7014/
  • [69] K. Krentz, C. Meinel, and H. Graupner, “Secure self-seeding with power-up SRAM states,” in ISCC ’17: Symposium on Computers and Communications.   Heraklion, Greece: IEEE, 2017, pp. 1251–1256.
  • [70] P. Kietzmann, C. Gündogan, T. C. Schmidt, and M. Wählisch, “A PUF Seed Generator for RIOT: Introducing Crypto-Fundamentals to the Wild,” in Proc. of 16th ACM International Conference on Mobile Systems, Applications (MobiSys), Poster Session.   New York, NY, USA: ACM, June 2018.
  • [71] G.-J. Schrijen and V. van der Leest, “Comparative analysis of SRAM memories used as PUF primitives,” in DATE ’12: Design, Automation Test in Europe Conference Exhibition.   Dresden, Germany: IEEE, 2012, pp. 1319–1324.
  • [72] J. von Neumann, “Various Techniques Used in Connection with Random Digits,” J. Res. Nat. Bur. Stand. Appl. Math. Series, vol. 5, pp. 768–770, 1951.
  • [73] NIST, “Digital Signature Standard,” National Institute of Standards & Technology, Gaithersburg, MD, US, Federal Information Processing Standards 186–1, December 1998.
  • [74] A. Desai, A. Hevia, and Y. L. Yin, “A Practice-Oriented Treatment of Pseudorandom Number Generators,” in EUROCRYPT ’02: Advances in Cryptology, ser. LNCS, vol. 2332.   Berlin, Heidelberg: Springer, 2002, pp. 368–383.
  • [75] N. Galbreath, Cryptography for Internet and Database Applications: Developing Secret and Public Key Techniques with Java.   Wiley Publishing, 2002.
  • [76] X. Wang, Y. L. Yin, and H. Yu, “Finding Collisions in the Full SHA-1,” in CRYPTO ’05; Proceedings of the 25th Annual International Conference on Advances in Cryptology.   Berlin, Heidelberg: Springer-Verlag, 2005, pp. 17–36.
  • [77] M. Stevens, E. Bursztein, P. Karpman, A. Albertini, and Y. Markov, “The First Collision for Full SHA-1,” in Advances in Cryptology (CRYPTO ’17).   Springer, 2017, pp. 570–596.
  • [78] NIST, “Digital Signature Standard,” National Institute of Standards & Technology, Gaithersburg, MD, US, Federal Information Processing Standards 186–3, June 2009, supersedes FIPS 186–2.
  • [79] ——, “Digital Signature Standard,” National Institute of Standards & Technology, Gaithersburg, MD, US, Federal Information Processing Standard 186–4, July 2013.
  • [80] M. Matsumoto and T. Nishimura, “Mersenne Twister: A 623-dimensionally Equidistributed Uniform Pseudo-random Number Generator,” ACM Trans. Model. Comput. Simul., vol. 8, no. 1, pp. 3–30, 1998.
  • [81] M. Saito and M. Matsumot, “Tiny Mersenne Twister (TinyMT): A small-sized variant of Mersenne Twister,” 2011, retrieved 2019-11-24. [Online]. Available: http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/TINYMT
  • [82] G. Marsaglia, “Xorshift RNGs,” Journal of Statistical Software, Articles, vol. 8, no. 14, pp. 1–6, 2003. [Online]. Available: https://www.jstatsoft.org/v008/i14
  • [83] S. Vigna, “An Experimental Exploration of Marsaglia’s Xorshift Generators, Scrambled,” ACM Trans. Math. Softw., vol. 26, no. 4, 2016.
  • [84] ——, “Further Scramblings of Marsaglia’s Xorshift Generators,” J. Comput. Appl. Math., vol. 315, no. C, pp. 175–181, 2017.
  • [85] D. Blackman and S. Vigna, “xoshiro / xoroshiro generators and the PRNG shootout,” http://prng.di.unimi.it/, last accessed on 04-01-2020.
  • [86] S. K. Park and K. W. Miller, “Random Number Generators: Good Ones Are Hard to Find,” Commun. ACM, vol. 31, no. 10, pp. 1192–1201, 1988.
  • [87] R. Whittle, “Park-Miller-Carta Pseudo-Random Number Generator,” 2005, retrieved 2019-11-25. [Online]. Available: http://www.firstpr.com.au/dsp/rand31/
  • [88] G. Marsaglia, “Random Numbers Fall Mainly in the Planes,” Proc. of the National Academy of Sciences, vol. 61, no. 1, pp. 25–28, 1968.
  • [89] S. Greenland, S. J. Senn, K. J. Rothman, J. B. Carlin, C. Poole, S. N. Goodman, and D. G. Altman, “Statistical tests, P values, confidence intervals, and power: a guide to misinterpretations,” European Journal of Epidemiology, vol. 31, no. 4, pp. 337–350, 2016.
  • [90] G. Selander, J. Mattsson, F. Palombini, and L. Seitz, “Object Security for Constrained RESTful Environments (OSCORE),” IETF, RFC 8613, July 2019.
  • [91] C. Gündogan, C. Amsüss, T. C. Schmidt, and M. Wählisch, “IoT Content Object Security with OSCORE and NDN: A First Experimental Comparison,” in Proc. of 19th IFIP Networking Conference.   Piscataway, NJ, USA: IEEE Press, June 2020, pp. 19–27, best Paper Award. [Online]. Available: https://ieeexplore.ieee.org/document/9142731
  • [92] M. Vucinic, G. Selander, J. Mattsson, and D. Garcia-Carillo, “Requirements for a Lightweight AKE for OSCORE,” IETF, Internet-Draft – work in progress 04, June 2020.

Author Biography

Peter Kietzmann received the M.Eng. degree in information technology from the Hamburg University of Applied Sciences, Hamburg, Germany, where he is currently pursuing the Ph.D. degree with the Internet Technologies Research Group. His particular research interest includes low-power radios, and IoT protocols, many of which he analyzed and transformed into code of RIOT. In the German research project I3 (ICN for the Industrial Internet) he explores IoT-based technologies for information centric networks and security components.

Thomas C. Schmidt studied mathematics, physics, and German literature at Freie Universität Berlin (FU Berlin), Berlin, Germany, and the University of Maryland at College Park, MD. He received the Ph.D. degree in mathematical physics from FU Berlin, in 1993. He is a Professor of computer networks and Internet technologies with the Hamburg University of Applied Sciences, Hamburg, Germany, where he heads the Internet Technologies Research Group. He was the Director of the HTW Computer Centre, Berlin. Since then, he has continuously conducted numerous national and international research projects. He was the Principal Investigator in a number of EU, nationally funded, and industrial projects, as well as a Visiting Professor with the University of Reading, Reading, U.K. He is also a co-founder and a coordinator of the open source community developing the RIOT operating system. His current research interests include development, measurement, and analysis of large-scale distributed systems like the Internet or its offsprings. Dr. Schmidt has served as a Co-Editor and a Technical Expert on several occasions and is actively involved in the work of IETF and IRTF, where he co-chaired the SAM RG.

Matthias Wählisch received the Ph.D. degree (with highest honors) in computer science from Freie Universität Berlin (FU Berlin), Berlin, Germany. He is a Professor of computer science with FU Berlin, heading the Internet Technologies Research Group. He is a co-founder and a coordinator of some successful open source projects such as RIOT. His efforts are driven by trying to improve Internet communication based on sound research. He is the PI of several national and international projects. He has authored or co-authored over 130 peer-reviewed papers (e.g., in ACM HotNets, ACM IMC, and ACM ICN). His current research interests include the design and evaluation of networking protocols and architectures, as well as Internet measurements and analysis. Dr. Wählisch was a recipient of the Young Talents Award of Leibniz-Kolleg Potsdam for outstanding achievements in advancing the Internet, and recipient of the Excellent Young Scientists Award for his contributions to the Internet of Things and their prospective entrepreneurial practice. He has been active in the IETF/ IRTF since 2005. He co-organized or co-chaired over 30 scientific events, including the IEEE ICNP Ph.D. Forum 2013, ACM ICN 2017, ACM IMC 2017, and ACM SIGCOMM 2017.