A Guideline on Pseudorandom Number Generation (PRNG) in the IoT
11 A Guideline on Pseudorandom NumberGeneration (PRNG) in the IoT
Peter Kietzmann, Thomas C. Schmidt, and Matthias W¨ahlisch
Abstract —Security and trust are essential building blocksfor the emerging Internet of Things (IoT)—both heavily relyon ubiquitously available crypto primitives with integrity androbustness. In the constrained IoT, this is a challenging desiredue to limited availability of memory, CPU cycles, energy, andexternal data sources. Random input forms such a central cryptoprimitive that is used virtually everywhere, but hard to obtainon deterministically operated real-time devices without userinterface.In this paper, we revisit the generation of randomness fromthe perspective of an IoT operating system that needs to supportgeneral purpose or crypto-secure random numbers. We analysethe potential attack surface, derive common requirements, anddiscuss the potentials and shortcomings of current IoT OSs. Asystematic evaluation of current IoT hardware components andpopular software generators based on well-established test suitsand on experimental performance measurements give rise to aset of clear recommendations on how to build such a randomsubsystem and which generators to use.
Index Terms —Internet of Things, operating system, pseu-dorandom number generator, cryptographically secure PRNG,physically unclonable function, statistical testing, performanceevaluation
I. I
NTRODUCTION
Random numbers are essential in computer systems toenfold versatility and enable security. Almost every operatingsystem (OS) provides ways to generate random numbers.Unfortunately, misconceptions about randomness are commonin the design and implementation of operating systems [1].With this work, we want to shed light on the ever confusingconcept of randomness and guide the design of systems thatoperate constrained embedded devices.The emerging Internet of Things (IoT) is under way in-troducing large quantities of resource-constrained, embeddeddevices ( i.e.,
Class 0 to Class 2 [2]) to the wild. They connectvia standard protocols to clouds or cloudlets on the globalInternet. Often they communicate autonomously via interfacesthat are wireless and require protection. Common methods ofself-organization and secure communication heavily rely onrandom input.Starting from Class 1, IoT nodes more and more utilize anoperating system instead of bare metal firmware. Over a dozenopen and closed source systems exist that can operate variousclasses and types of devices. Our work is motivated fromthe heart of the RIOT system design. RIOT [3] contributesrandomness to standard networking [4], security [5], resourcemanagement [6], and other user functions. Random numbers
P. Kietzmann and T.C. Schmidt are with Hamburg University of AppliedSciences, Germany (e-mail: { peter.kietzmann, t.schmidt } @haw-hamburg.de).M. W¨ahlisch is with Freie Universit¨at Berlin, Germany (e-mail:[email protected]). are required in almost all security components to generate orperpetuate secrets such as encryption keys or cypher streams.In the literature, a “random sequence” is often referred towith the definition by D. H. Lehmer : A random sequence is a vague notion [. . . ] inwhich each term is unpredictable to the uninitiatedand whose digits pass a certain number of teststraditional with statisticians. [7]
True random sequences are generated from random physicalprocesses such as thermal noise, manufacturing inaccuracies,or crystal drift. Current personal computers extend suchsources to sound or video input, disk drives, user keystrokes,or other as proposed by the IETF [8]. These interfaces do notnecessarily exist on embedded devices. There may be comple-mentary sources for gathering random input such as antennanoise or sensor measurements. Still, collecting random valuesis often difficult and resource-intensive because underlyingprocesses are slow or do not output continuously. Furthermore,the use of additional hardware components during runtimeincreases energy consumption.Pseudo-random number generators (PRNG) are determinis-tic algorithms that output sequences with random properties.They require a truly random seed as input in order to beunpredictable. If properly seeded, these generators expand acomparably short seed value into a long sequence of randomnumbers [9] while discontinuing to depend on (physical)random processes. Using a PRNG also reduces the attacksurface for adversaries with physical device access. On low-cost embedded platforms, however, it is hard to generate aqualified seed if suitable hardware resources are missing. Thisraises a major challenge for the operating system, as it needsto abstract the hardware without sacrificing functionality.In this paper, we explore the building blocks for properrandomness in the constrained Internet of Things. We startfrom the attack surface (§ II) and discuss the requirementsthat emerge for random number generation (§ III) and itsembedding into a random IoT-OS subsystem (§ IV). The majorcontribution of this paper follows with the systematic testingand performance evaluation of common hardware and softwaregenerators on IoT platforms. First, we recap the statistical testsuites (§ V) and then analyze popular off-the-shelf randomnumber hardware along with a seed generator based on PUFs(Physically unclonable functions) (§ VI). Second, we performanalogous tests and evaluations for pseudo-random numbergenerating software (§ VII) and deduce recommendationsfor general purpose and crypto-secure generators in the IoT.Comparing hardware and software performance properties andresource consumptions leads us to further conclusions on howto combine and jointly deploy these different components a r X i v : . [ c s . CR ] J u l (§ VIII). We summarize four clear recommendations thatimmediately apply in practice in the conclusions (§ IX). Overview of this paper§ II Attack Surface of the IoT Random Subsystem§ III Generating Randomness in the IoT§ IV Randomness in IoT OSs: Requirements and Related Work§ V Statistical Test Suites for Random Numbers§ VI Hardware Generated Random Numbers§ VII Software Generated Pseudo-Random Numbers§ VIII Hardware or Software Generated Randomness in the IoT?§ IX Conclusions and Outlook
II. A
TTACK S URFACE OF THE I O T R
ANDOM S UBSYSTEM
A variety of prominent attacks are based on vulnerabilitiesof random number generators in real-world systems and theliterature provides a plethora of cryptographic analyses and at-tack scenarios [9]–[22]. In reality, there are even more attacksanticipated that target at zero day exploits. Kelsey, Schneieret al. [13] criticize a lack of a widespread understandingof possible attacks against random number generators amongsystem developers. Given the shortcomings of many randomsubsystems, it is worth considering the corresponding attacksurface of a specific environment. An attack on a randomnumber generator is an intrusive attempt of distinguishingbetween the produced sequence and truly random numbers.This distinction would open doors to predict future outputsor reproduce recent outputs that might have been used forgeneration of secrets in the past. The situation becomes evenworse if an adversary manages to direct future numbers ofa random sequence. Kelsey et al. enumerate three classes ofanalytical attacks:
Direct Cryptanalytic Attacks monitor PRNG outputs to gainknowledge about the system in order to distinguish betweenpseudo-random output and truly random bits.
Input-Based Attacks require access to PRNG inputs (seedsand initializations vectors) to inject known test sequences andperform further cryptoanalysis on random outputs.
State Compromise Extension Attacks base on previouslycompromised internal state of the generator and enables pre-diction or backtracking within the pseudo-random sequence.Previous work focuses on the analytical aspects of random-ness on regular PCs with human-machine interaction. Thisapproach is as well applicable in the case of interconnectedembedded devices with missing user interfaces. Francillon etal. [10] present a more generic distinction for the case ofwireless sensor nodes that categorizes two types of attackers.
Remote Attackers mainly target at cryptanalytic and input-based attacks. Without accessing the node directly, an adver-sary 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 togenerate randomness. An adversary with access to the localwireless network must thus be considered a potential threat toperform an external attack . Invasive Attackers have gained read access to the internals ofa generator and can compromise its state at one point in time. This definition does not include write access, or code injectionby the attacker. Perfect state knowledge of a deterministicpseudo-random algorithm allows the adversary to predictfuture outputs and it can reproduce sequences that have beengenerated in the past, i.e., for cryptographic key generation.Unless true random vales are added to the generator stateperiodically, the system remains fully predictable. The updateinterval determines the maximum time that a generator remainsvulnerable. Compromising the state by read access is alsoconsidered as an internal attack .In the IoT, a large number of constrained embedded devicesinter-connect to each others and to the global Internet. On theone hand, broadening the networking capabilities increases theattack interface, especially with availability from the outside ofa local network. On the other hand, simple IoT devices entailspecial considerations in comparison to traditional networkeddevices such as servers, personal computers, or smartphones.Many IoT devices are very constrained in hardware capabili-ties due to minimizing price and form factors, as well as energyresources. These limitations do not only affect computationalpower, but often imply sparse hardware protection features. Asa consequence, IoT devices often lack permission managementfor code execution, memory protection mechanisms, as wellas secret storages.IoT deployments can grant physical access to the hardware,which opens a potential interface to analyse and monitor del-icate key material, firmware, or even program execution on adevice if tamper detection is not in place. We argue that securerandom number generation cannot be sustained in the casethat an adversary has full read or write access to the device.Shielding attack vectors without read or write access demandsfor additional hardware capabilities and manufacturers of low-power chips already reacted. STMicroelectronics [12] definesthree groups of attacks against microcontrollers.
System Software Attacks focus on security and resilienceaffected by weak implementations, bugs, or insecure proto-cols after analyzing or even manipulating program execution.Disturbances can be introduced even without device access vianetwork interfaces, e.g., by sending malicious packets, or bytriggering the execution of non-verified or untrusted libraryfunctions that may be already part of the device firmware.The latter is often related to “monkey testing” or to insiderknowledge.
Hardware Non-invasive Attacks require hardware access.This category includes any kind of interface that allowsinteracting with the device directly, such as debug ports, or businterfaces (UART, SPI, I2C, ...). The most dangerous attacksfor random sources that rely on physical processes are basedon fault injection. Typically, an adversary exploits the deviceunder 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 timinganalyses fall in this category.
Hardware Invasive Attacks cover very advanced techniquesthat enable access to the device silicon and can be used toaccess hidden secrets, even if device protection mechanisms are in place. This group of attacks is usually very complexand only possible with the availability of specific measurementinstruments.Recently, hardware manufacturers of low-power microcon-trollers have started to provide different countermeasures tothe attack surface, ranging from debug port locks, tamper de-tection indicators, memory protection units, and isolated codeexecution environments. Also, hardware crypto accelerationon one chip become popular. These features should be usedwherever possible. Nevertheless, many low-cost devices thatare supported by IoT operating systems do not provide all(or any) of these capabilities, implementations and algorithmsused for random number generation should be designed aroundthe concepts of (i) a high modularity to ease partial useof hardware protection features and (ii) robustness even ifhardware protection is missing.Random number generation cannot be protected, if theadversary has full control over the device. Analytic attacks aswell as fault injections can be shielded, though, by incorporat-ing cryptographic primitives and carefully gathering entropyfor seeding the PRNG, as we will discuss in the followingsection.III. G
ENERATING R ANDOMNESS IN THE I O TEvery day in the life of an IoT device, random numbers arerequested by a variety of use cases. These use cases separateinto two classes: either general purpose or cryptographicallysecure random input. While general purpose use only requiressufficiently well represented statistical properties, cryptograph-ically secure random numbers must also remain unpredictableeven under malicious attacks. While the first category can beachieved fairly easily, the provisioning of secure randomnessis very challenging in the constrained regime and—dependingon the attacker model and strength—may not be achievable atall. A. General Purpose PRNGs
General purpose PRNGs are employed for tasks inde-pendent of security aspects. Typical use cases include thejittering of network protocol timers or media access protocols( e.g., random back-off in CSMA) to avoid collisions on amedium. Other applications of general purpose PRNGs in-clude randomized sampling of sensor measurements and fuzzytesting.A uniformly distributed stream of statistically independentrandom numbers is the desired output of a PRNG, whichstill should be approximated in higher dimensions, sinceconcurrent applications or algorithmic elements may call onsub-sequences of the generator ( e.g., access every k-th output).Seeds between otherwise identical devices must differ to avoididentical random behavior across devices, but an individualseeding after each device restart is desired. Even thoughseed requirements for general purposes are moderate, a “plugand play” source for gathering seed material is missing onIoT devices that do not provide a hardware random numbergenerator (HWRNG). General purpose PRNGs are essential on most IoT devicesand frequently called in many use cases. Implementationsshould therefore be very lightweight and efficient to preserveresources of the constrained devices. Available resources arebetter spent on generators with high security demands.
B. Cryptographically Secure PRNGs
Crypto-purpose or Cryptographically Secure PRNGs(CSPRNG, as coined in the literature) are generators that aresafe to use in security applications, involving the generationof cryptographic keys, nonces, or salts. Cryptographic systemsecurity relies on theses random numbers as basic input.Consequently, these generators are expected to output highlyunpredictable number sequences and to be resilient againstknown attacks.Building a crypto-purpose generator is more complex andconsumes higher system resources than a general purposePRNG. It involves additional building blocks of ciphers, cryp-tographic hash functions, runtime tests, as well a specificallyrobust seeding logic. Computational overhead and especiallymemory requirements of these building blocks are in poten-tial conflict with resource constraints of IoT nodes, but theavailability of secure random numbers is essential for enablingsecure communication over the Internet. In order to reducesoftware complexity, some microcontrollers provide hardwareacceleration of cryptographic primitives, which should beexploited when implementing the respective components.A significant body of work reports about failures of PRNGsand successful attacks against the random input of crypto sys-tems [9], [10], [12], [13], [15], [16], [18]. Hence, provisioninga cryptographically secure, consistent random infrastructure isa crucial component of an IoT operating system, which shouldbe designed and tested with care. Requirements on CSPRNGs,in-depth analyses of different mechanisms and classificationof those have been presented in [15], [16], [23]–[26]. Wesummarize the key aspects of CSPRNGs in the followingparagraphs.
Statistical Randomness.
Any statistical bias gives rise toelementary attack vectors. Even though CSPRNGs mainlyconsist of deterministic algorithms, a crypto-secure randomgenerator needs to produce sequences that are statisticallyindistinguishable from truly random [13]. These propertiesbase on the assumption that in a string of (pseudo-random)bits, probabilities for one and zero are equal at any time andthey are statistically independent. That means, guessing thenext bit of a sequence cannot be done with better chance than50 %. Even a very small bias must be considered as potentialbreach of the randomness assumption and contradicts crypto-requirements of a secure generator. A variety of statisticalproperties can be verified with tests that are available in wellestablished test suites (see Section V).
Unpredictability.
CSPRNGs require resistance against ex-ternal and internal attacks (compare Section II). A commondistinction exists between prediction resistance and backtrack-ing resistance. In more detail, prediction resistance means thatan attacker cannot guess future results in computational timeby monitoring the generator history, even if the algorithm is perfectly known. To achieve this at a given statisticalquality, the seed needs to be fully unpredictable. Furthermore,a crypto-secure PRNGs needs to be built on cryptographicfunctions, usually one-way hash functions and block ciphersthat are practically not invertible and do not produce collidingoutput from different inputs.Every cryptographic system needs to be designed accordingto a specified security level. An established threshold is 128bit of secrecy [8], [27], [28]. Assuming an adversary had toguess a secret value, it would require trying about half thenumber of bit combinations, if all states are equally likely.For 128-bit secrecy this would be − tries on averageto brute force a collision, or in the worst case. This iscurrently considered secure for computational resources. Boththe seed at the generator input, as well as the internals ofits algorithm need to meet the expected security level. It isimportant to note that due to the birthday paradox , an attackon a cryptographic hash function can complete with a reducednumber of tries [29], [30]. Furthermore, if an attacker gainedknowledge of the internal state of a generator, it should beensured that future output is only predictable for a very shorttime. According to NIST, this should be achieved by addingfresh and truly random values periodically to the internalgenerator state (see Section III-C on re-seeding).Backtracking resistance protects against a reconstructionof previous values or even the seed after a state comprise.It implies that no correlation between seeds and generatedoutput should be in place. This behavior is required to assureperfect forward secrecy within cryptographic protocols [31].Backtracking resistance is realized by applying cryptographicfunctions to the internal state of the generator and hardenedby storing state in protected memory, if available. High Entropy Seeding.
A truly random seed value is requiredto make the output of a CSPRNG unpredictable [25], [32].Random bits are usually extracted from physical resources andthe Shannon entropy [33] or the Minimum entropy serve as ameasure of its randomness. In this context, physically randomresources are often referred to as entropy sources. Physicalsources of “randomness” typically exploit variations in elec-tronic circuits ( e.g., clock drifts, uninitialized memory, ADCfluctuations), randomly noisy signals ( e.g., wireless noise, biterrors, thermal noise), or user input signals ( e.g., key strokes,mouse clicks) which normally are unavailable in the IoT. Thesereal-world entropy sources, however, do not always admit “fullrandomness” and additional compression methods are oftenneeded for maximizing entropy. NIST [34] also advises thatseed generation should not rely on a single entropy source, forresilience.Full entropy seeds are required for secrecy in a CSPRNG,which is equivalent to requiring n − tries on average, forguessing a seed of length n bits. If not seeded with fullentropy, an adversary may exploit internal state collisions anddetermine generator output faster. This can drastically degradethe security strength of the generator. Hence, great care mustbe taken to harvest the number of entropy bits that is requiredby the cryptographic strength of the system as defined byand compliant to the algorithm of the PRNG [35]. Caution is advised with implementations that limit the input length ofthe seeding function.Fresh entropy may be required repeatedly to re-seed theinternal sate of a CSPRNG in order to recover from a potentialstate compromise, or to serve multiple generator instances, aswe will discuss in the next section. Health Testing.
The quality of cryptographic system compo-nents need particular attention, as it may degrade not onlydue to software bugs, but also due to hardware aging orside channel attacks. A variety of tests have been proposedby NIST, which should be executed on all functions of aPRNG. Additionally, there are procedures to test the behaviorof entropy sources. These tests range from known answertesting during validation time up to health tests during runtimeto monitor vitality of the mechanisms. As the focus of thiscontribution is not on testing, we refer the reader to the specificNIST documents [25], [34], [36].
C. A Note on Re-seeding CSPRNGs
A CSPRNG can recover from potential state compromise byregular re-seeding [13], [23], [25], [35]. Re-seeding of PRNGsis often advised [10], [37], [38] but also under much debate inthe literature [9], [16], [39]. Certain CSPRNGs proposed byNIST even build upon the concept of re-seeding [25].Considering that a generator is perfectly secure and wasseeded in agreement with its specified security level, whileboth its seed and its state are kept in full secrecy,then anadversary cannot predict the next output by guessing withincomputational time without any re-seeding. So re-seedingbecomes unnecessary. In this ideal scenario, the only reasonfor re-seeding is to extend the finite period of the specificpseudo-random algorithm. The period of a generator describesthe number of cycles it takes to run through all valid internalstates. In practice, however, computationally secure PRNGshave long enough periods and are not affected by repeatingpseudorandom output during their lifetime in a common IoTscenario.Re-seeding can even be disadvantageous as it introducesan interface to inject low entropy values to the internal stateduring runtime. This may foster state collisions and thus breakthe 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 behard to depict failures in case of a compromise. To avoidadding compromised entropy values during runtime, somecommon security procedures base on a “trust on first use”model [40], which contradicts the re-seeding approach.Another vulnerability created by re-seeding was revealedby Ristenpart et al. [16]. Existing implementations of entropycollectors cache their outputs in memory pools because—dueto its eventually long and indeterministic runtime—entropygathering is often implemented as a parallel and asynchronoustask. If these numbers are not consumed immediately, amemory without perfect secrecy exposes an attack vector.Thus, entropy pools and internal states should run in trustedexecution environments, only. Especially on constrained IoT hardware, this is not always possible, which makes the case forentropy generation on demand. Conversely, the utilization ofinsecure memory technologies generally motivates re-seedingwith fresh entropy values.Entropy sources can get compromised during operation,but the opposite can happen, as well, if sources did notprovide full entropy during PRNG instantiation. In that case,mixing additional entropy values to the internal state duringoperation can be rescuing. Finally, few crypto-forums arguethat re-seeding protects in case of faulty implementations.Faulty implementations at hand, however, contradict manyassumptions 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 bemade by the designer and account for the underlying hardwarecapabilities, deployment considerations, application scenarios,and security requirements in place. We conclude that a re-seeding mechanism should be considered as an option, butremain decoupled from the CSPRNG API. This recommenda-tion applies to IoT environments that require modular softwarein order to adapt to the heterogeneity of hardware platforms ofvarying resources and diverse deployments in probably (phys-ically) harsh environments. These considerations, however, arenot limited to resource constrained embedded devices, butapply to regular PCs as well.IV. R
ANDOMNESS IN I O T O
PERATING S YSTEMS :R EQUIREMENTS AND R ELATED W ORK
A. General Requirements
Many system services require access to random input, andit is common to expect a random function at the operatingsystem level. Use cases and applications of random numbersdiffer largely, though, as we discussed in Section III. Generalpurpose PRNGs are needed to generate random events that fol-low a uniform statistical distribution and are often consumed athigh frequencies. Security related contexts raise the additionalrequirement of keeping random output unpredictable, whycrypto-secure generators need to maximize entropy with thehelp of truly random input. Such input is on the one handdifficult to obtain at often high cost, on the other hand trulyrandom sources frequently harvest from system hardware,which is best accessed via the hardware abstraction of anoperating system.Following this perspective, both general purpose and crypto-secure random number generation should be part of an operat-ing system, but are at the same time only versatile if they meetthe diverging requirements well. We argue that the differentuse cases and requirements of PRNGs and CSPRNGs demandfor independent methods and APIs. Isolated random functionscannot only be specifically optimized, but also prevent sidechannel attacks against the CSPRNG via the general purposePRNG. Furthermore, separate APIs force developers to decidefor their individual use cases.
B. General Purpose PRNGs
Use cases for general purpose PRNGs require statisticallywell distributed random sequences. First, single applications should receive a different value out of the whole numberrange on each request to avoid repeating patterns. Second,multiple applications that request from a single PRNG instanceshould experience the same properties, even if they accessonly every k-th PRNG output. This requires a decent empiricaldistribution in higher dimensions, which is often a challenge.Security related applications should not use this generatorclass as it may be too easy to predict. Furthermore, mostgo-to PRNGs are invertible which allows to reconstructingprevios sequences. Different seeds must be generated acrossdevices to prevent a uniform collective behavior. Seeding witha decent entropy is desired to provide varying sequencesbetween system restarts. Seeds may be accessed through thehardware abstraction of the operation system, but should beconfigurable to ease debugging.General purpose PRNGs should require minimal systemresources to be applicable even on very constrained devicesand to act frugally while requested frequently. Efficiencymetrics involve processing time, as well as energy and memoryconsumption. The latter can benefit from restricting state to asingle PRNG instance. A central instantiation logic can bemanaged by the operating system.
C. Crypto-secure PRNGs
Core Requirements.
Security related use cases require crypto-secure PRNGs for sovereign tasks such as cryptographickey generation. Delicate key material must be largely unpre-dictable. A CSPRNG is expected to produce sequences that areindistinguishable from truly random numbers, as discussed inSection III-B. It is advisable to rely on approved CSPRNGmechanisms that have been verified by trusted authorities andan operating system or a public library can provide accessto implementations that are tested within this environment. ACSPRNG internally consists of cryptographic functions [25] toachieve backtracking resistance and the maximum achievableprediction resistance (security strength) is typically given bythat function, though, the strength of the whole generatorshould be specified by the designer of the approved algorithm.In order to assure a predefined security strength, a high qualityseed must provide truly random data with a correspondingamount of entropy during instantiation of the CSPRNG.In contrast to general purpose PRNGs, CSPRNGs under-take tasks like key generation, which is typically involvedless frequently, but also continuous encryption within streamciphers, thus, performance characteristics of CSPRNGs areimportant but they are secondary in comparison to its securityqualifications. Still, computation of cryptographic primitivesand entropy conditioning can be costly [9], especially onconstrained embedded devices. The CSPRNG and the seedgenerator as provided by an OS must comply to the constraintsof the target hardware and leave sufficient resources to deploya real-world firmware with the desired application logic. Theoperating system should provide an optimized, configurableenvironment to support this.
Minimal Standards.
Crypto-secure PRNGs rely on truerandom seeds that meet a security strength which determinesthe 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 fromvarying sources, dependent on underlying hardware capabili-ties. Externally connected devices may provide true randomnumbers as well, but typically require a device driver. Anoperating system can simplify access to relevant componentsby its hardware abstraction layer, and should additionally allowfor code re-use between different hardware platforms. Theneed for configurability requires a highly modular architecture.In the context of IoT software, configuration is commonlydone during compile time to keep firmware sizes small.Tests are mandatory for generating robust and secure ran-dom numbers [25], [34]. Both the pseudo-random algorithmand the seed generation must be tested whereas testing pro-cedures can be separated into a priori and live tests duringdeployment. Due to device constraints, a priori tests at devel-opment time should be favored to save resources on runningIoT nodes. Thereby, bug free execution of the deterministicCSPRNG must be verified by comparing output sequencesagainst ground truth. Further, seed sources rely on physicalprocesses and should be evaluated within deployment condi-tions, because their behavior can be affected by environmentalproperties.
Optional Features.
Entropy sources are essential for seedcreation, but the properties of underlying physical processesare diverse. Environmental changes as well as attackers withdevice access can affect their reliability (see Section II).Involving multiple entropy sources during seed creation in-creases seed resilience. Naturally, a physical process doesnot provide full entropy, but conditioning is sometimes im-plemented already in the hardware. For sources with sparseentropy concentration, a compression mechanism is required.An entropy module provided by the operating system canincrease seed quality and it should involve three fundamentalbuilding blocks: (i) An estimate about the entropy amount perinput which can be provided by each source, (ii) an accu-mulation instance to involve multiple sources and keeps trackof the amount of accumulated entropy and (iii) a compressionmechanism to create high entropy seeds with limited length tomeet security requirement of the CSPRNG. The entropy APIshould thus provide an interface to pass security requirementsand it should also be able to report errors back to the CSPRNG.Re-seeding a CSPNG is sometimes desired to recover frompotential state compromise (see Section III-C). We argue thatre-seeding should be kept optional because seed generationmay drain a significant amount of energy on every re-seed cy-cle. Enabling and disabling that feature should be transparentto the application that uses the CSPRNG.Cryptographic protocols for different purposes require torun on individual instantiations of a CSPRNG to prevent sidechannel 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 purposePRNGs. Second, every instantiation needs its own contextto be handled either internally within the boundaries of theCSPRNG or externally, by dedicating context allocation to the application. In both ways, the number of contexts shouldbe kept low in an IoT OS, because the CSPRNG state canconsume much memory. It is worth noting that IoT firmwaretypically avoids dynamic memory allocation, why the numberof CSPRNG instantiations should be explicitly defined duringdevelopment.The state of a generator needs protection and an oper-ating systems should involve hardware security features, ifavailable. In more detail, secure memory technologies canprovide tamper detection along with authorized access andrecent low-power platforms even provide trusted executionsenvironments ( e.g.,
ARM TrustZone ) for protected codeexecution. CSPRNG state, seeds, and entropy values shouldbe uninstantiated after use to avoid leakage via side chan-nels. This is of particular importance when secure memoryis absent. Memory erasure is commonly done by settingbuffers to zero, though, instructions to “zeroize” a bufferare often removed by compiler optimizations, which leavessensitive information in memory. Known solutions involve explicit bzero implemented by the GNU C Library, as well asservice functions in cryptographic libraries such as libsodium or Monocypher . Optimizing Parameters.
Modern off-the-shelf IoT devicesprovide an on-chip hardware random number generator whichis commonly used as seed source for CSPRNGs. In addition,accelerating hardware units are often in place and capableof processing cryptographic primitives such as ciphers andhashes. While most CSPRNG implementations base on apure software solution of their internal cryptographic func-tions, a transparent substitution by hardware implementationspromises performance enhancements in terms of speed andenergy. The operation system can provide peripheral driversto control hardware accelerators and a transparent reconfigu-ration, dependent on respective hardware capabilities, shouldautomatically select the most performant solution.Furthermore, certain IoT boards provide an external hard-ware acceleration chip mounted on the same PCB as themicrocontroller which is typically connected by a peripheralbus. Transparently including this device class as (i) a crypto-graphic accelerator or (ii) a full CSPRNG alternative can off-load the main processor and potentially enable cryptographicapplications on very constrained devices that cannot run aheavy-weight CSPRNG software.
D. IoT Implementations
Among the most prominent IoT operating systems nowa-days are Contiki-NG, a successor of the original Contiki oper-ating system [41], mbed OS [42], zephyr [43], Mynewt [44],and RIOT [45], all of which implement methods to gatherrandom numbers. In the following, we give a brief overviewabout current solutions in different OSes, and we focus onRIOT afterwards. https://developer.arm.com/ip-products/security-ip/trustzone/trustzone-for-cortex-m https://libsodium.gitbook.io https://monocypher.org Contiki-NG provides support for few ARM Cortex-M basedmicrocontrollers, and MSP430 platforms, although its prede-cessor Contiki provided support for a wider range of architec-tures. Contiki-NG implements a sparse random subsystem thatdoes not distinguish between general purpose and cryptograph-ically secure PRNGs. The random API is implemented as awrapper around peripheral HWRNG drivers of a platform andan approved CSPRNG is not available. The interface providesa seed function that limits the input size to an unsigned shortinteger but it is left unimplemented in most cases, becausethe on-board HWRNG does not require a seed. In case ofmissing hardware random number support, the random modulefalls back to the C library function rand which maps to alightweight linear congruential PRNG in most C libraries.An entropy module for seed generation, implementations ofhardware accelerators, tests, and error indication interfaces aremissing in Contiki-NG. mbed OS is the ARM operating system for processors of theARM Cortex-M family. mbed implements one PRNG for gen-eral purpose random number generation based on the Xorshiftgenerator with 128-bit internal state (Xoroshiro128+). Thegeneral purpose API provides an interface to re-seed the inter-nal state. ARM maintains an SSL library (mbed TLS [46]) nextto the operating system. This library is included in the mbedoperating system for secure random number generation, and itcan be ported to other software projects as well. On the upperlayer, this library implements the CSPRNGs HMAC DRBGand CTR DRBG as proposed by NIST [25]. Implementationsinclude external state handling, re-seeding procedures, and acollection of self tests. Cryptographic hardware accelerationis supported too. On the lower layer, the mbed TLS libraryimplements 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) canbe used in a blocking and non-blocking fashion until certainentropy requirements are met, (iv) distinguishes between weakor strong entropy requirements, and (v) can be compiled withdifferent complexity levels. When used on Cortex-M devices,the only built-in entropy input is the HWRNG of a platformwhich is expected to return full entropy values without furtherestimation, thus, an adequate HWRNG has to be in placefor cryptographic operations and it cannot be replaced byalternative entropy sources that only provide partial entropybits per sample. Both generator classes are seeded by theentropy module of mbed TLS.
Zephyr supports a large variety of ARM Cortex-M based32-bit IoT platforms as well as x86, ESP32, ARC, NIOS IIand RISC-V based boards. The operating system implementsa PRNG for general purposes (Xoroshiro128+) and the ex-ternal mbed TLS and tinycrypt [47] libraries are ported tozephyr, which include crypto-purpose generators specified byNIST [25] (HMAC DRBG and CTR DRBG). The adaptationfor running both libraries within zephyr does not includehardware abstraction for crypto accelerators. A collectionof tests implemented within mbed TLS and tinycrypt canbe executed from the operating system and it additionallyprovides 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 sup-port accumulation of different entropy sources. The fallbackentropy source in case of missing hardware capabilities is apredictable timer or counter based solution. The entropy APIimplements a basic error interface to indicate this kind ofdeficits.
Mynewt is an operating system that supports about 40boards, 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 libraryfunction rand() for requesting general purpose random num-bers. Both mbed TLS and tinycrypt libraries are availablefor cryptographically secure random number generation. Inboth cases, cryptographic functions are processed in software.Selftests from mbed TLS can be executed within the operatingsystem, whereas tinycrypt tests are not included. To seedthe CSPRNGs, an interface to the HWRNG driver of themicrocontroller is supplied.
RIOT currently supports around 170 boards and 30 differ-ent microcontroller families ranging from 8-bit AVR deviceswith sparse peripherals, 16-bit MSP430 devices, up to 32-bit processors of the ARM Cortex-M family and ESP32with various MCU peripherals including dedicated HWRNGcircuits, as well as ARM7, MIPS, and RISC-V based mi-crocontrollers. RIOT implements a collection of PRNGs thatrange from lightweight general purpose algorithms to crypto-purpose generators. Among other embedded crypto libraries,RIOT also includes tinycrypt, and it additionally offers supportfor relic [48], but the external CSPRNGs are not yet integratedinto the random subsystem. A central random
API unifiesaccess to pseudo-random numbers, regardless of differentrequirements. At the API level, there is currently no differ-entiation between general purpose and crypto-secure PRNGs.All PRNGs that are natively supported in RIOT work on asingle internal state. This forbids running multiple instancesof one generator and prevents external state maintenance. Atest application with user interaction via the shell allows totest vitality and basic performance metrics of a generator.The random interface provides two initialization functionsfor PRNG seeding, one of which seeds with a 32-bit integervalue and the other initializes an array of variable length.Neither the initialization function nor the random requestfunction provide an interface for error reporting in case oflow entropy seeding, or internal errors of the generator. Asa seed, either the output of a HWRNG or an SRAM PUFseeder feed the instantiation function of a PRNG. In caseof a missing entropy source, the CPUID or a static valuecompiled to the firmware are currently involved for seeding.The CPUID has zero entropy but as a minimum, it providesvarying start values between multiple boards. The compiledvalue provides entropy between build processes because it isgenerated by a running PRNG on the development system.This solution prevents re-usage of one binary for multiplecontrollers which complicates deployment. Both mechanisms provide zero variation between reboots, and they should notbe used in a real-world deployment. An advanced entropymodule that involves multiple sources, estimates the amountof accumulated entropy and exposes an interface to request aspecific number of entropy bits is yet missing in RIOT.V. S
TATISTICAL T EST S UITES FOR R ANDOM N UMBERS
The statistical quality of random sequences can be em-pirically analyzed. There are many methods and tools totest for random properties. The NIST Statistical Test Suite(STS) [24] and the DIEHARDER Random Number TestSuite [49] combine series of such tests. They have establishedas standard tools and are openly available. Both suites baseon hypothesis tests that analyse the input against the nullhypothesis of perfect randomness. This hypothesis impliesthat fully deterministic pseudo-random sequences with idealrandom properties cannot be distinguished from truly randomvalues. Conversely, even ideal random sources may producesequences that appear to have non-random properties, whichcan lead to failures of statistical tests occasionally—usuallyreferred to as type-1 error.
A. NIST Statistical Test Suite
The NIST STS consists of 15 different test cases, someof which are executed repeatedly, leading to a number of188 statistics that are processed on each run. With respectto the input size recommendation for each test [24], we applythe 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 ( p -value) and it isexpected to accept the hypothesis of perfect randomness witha confidence of − α , if the value lies above a significancelevel of α = 0 . . Otherwise, the hypothesis of randomnessis rejected and the result is interpreted as failure. Each testis applied repeatedly which results in a vector of p -values.The proportion of passed sequences for one test is determinedusing the confidence interval . As a next step, the distributionof p − values for each test is analyzed using a chi-squared test( χ )-test, which outputs a second order probability value ( p -value). The test suite defines a significance level of α =0 . for testing this distribution. B. DIEHARDER Random Number Test Suite
The DIEHARDER test suite subsumes 31 tests to analysestatistics of random input streams. These tests are executedwith varying parameters, thus, a full run calculates a total of122 test statistics. We apply the DIEHARDER test suite ver-sion 3.31.1 with default options to streams of raw binary out-puts. In default mode, the number of repetitions of a specifictest varies between psamples in [1,1000] and the sequencelength is variable between tsamples in [100,65000000] whichdemands for much more random input data in comparison tothe NIST STS. Repeated executions deliver multiple probabil-ity values ( p -values) for each test, similar to the NIST tests. AKuiper Kolmogorov Smirnov test (KS-test) is applied to testdeviations from the expected distribution, which results in asecond order probability value ( p -value). In DIEHARDER, a test passes if its p -value lies above asignificance level of α = 0 . , below (1 − α ) , and itfails otherwise. The result is considered as weak if p -valuelies above α w = 0 . and below (1 − α w ) . It is again worthnoting that even truly random numbers might generate weakresults occasionally. C. Other Test Suites
Donald E. Knuth was one of the pioneers who describedrandomness tests in early editions of
The Art of ComputerProgramming [50] and his tests are part of most establishedtest suites today.NIST released the first random number tests in 1994 withinthe FIPS 140-1 [51] standard, which specified four statisticaltest. In 2001, these tests were updated in FIPS 140-2 [52]with a narrowing of the test criteria. Both documents served aspredecessors for the NIST Statistical Test Suite (STS) releasedin 2010, which includes all 140 FIPS test cases as a subset. TheDiehard test suite was published in 1995 by Marsaglia [53],who had been active in this field since years. The test suiteimplements a collection of 18 test cases, which are a centralpart of the DIEHARDER test environment, which has beendeveloped since 2003. Both NIST STS and DIEHARDERare well known and accepted as standard tools for statisticaltesting of random number generators [54], [55].The TestU01 library [54], [56] was introduced in 2007. Itincludes the majority of tests from NIST STS, Diehard, aswell as additional tests proposed in literature. Its purpose isto provide an “extensive set of software tools for statisticaltesting of RNGs.” [54], which led to a larger variety oftests, larger sample sizes and an extended test parametrizationin comparison to the other suites. At the core, the envi-ronment implements hypothesis tests similar to NIST STSand DIEHARDER, but instead of rejecting a hypothesis, itsimply reports p -values outside the interval [0.001, 0.9990].TestU01 can be executed on four complexity levels, of whichthe most comprehensive one ( BigCrush ) involves up to 160test statistics. Generation of the required amount of randomdata can take a long time, in particular when generated onmicrocontrollers and transmitted via the UART to feed thelibrary. This drastically increases time requirements of theevaluation process.A range of other test environments are less prominent inthe literature. The SPRNG (Scalable Parallel Random NumberGenerators) [57] library is a tool to optimize distributedprocessing for parallel random number generation and itadditionally contributes a few standard tests already coveredby NISTS STS and DIEHARDER. The ENT test program [58]defines a small-scale environment that executes only fivestatistical tests. It relies on a file based data input, which isnot practical when huge datasets have to be analyzed. TheCryptRndTest package [59] analyses cryptographic randomnumbers, focusing on high precision floating-point numberswith lengths larger than 64 bits. The latter is uncommon inthe IoT.
Board Chip Entropy Source Post-processing Error HandlingST NUCLEO-F410RB STM32F4 3 Free-running ROs Bias Correction + LFSR Health TestsPhytec IoT Kit 2 MKW22D 2 Free-running ROs LFSR Status IndicationNordic nRF52840 DK nRF52840 Thermal Noise Bias Correction Status IndicationZolertia 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 – –MicrochipCryptoAuth XPRO-B ATECC(5—6)08A Quantum MechanicalCircuit 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. H
ARDWARE G ENERATED R ANDOM N UMBERS
Common off-the-shelf IoT platforms sometimes providehardware generated random numbers. While some platformsimplement “true random” circuits for entropy gathering on thesame chip as the CPU, others implement pseudo-random gen-erators in hardware. Still, many microcontrollers do not offerrandom hardware at all. In these cases, external componentssuch as transceivers or cryptographic co-processors may beconnected to a bus and contribute true random numbers. As analternative, advanced mechanisms can extract random physicalproperties from manufacturing variations of the microcon-troller itself. In this section, we analyse typical IoT hardwareplatforms from different manufacturers, CPU architectures,and feature sets. Results are summarized in Table I. We runRIOT-2020.01 as operating system with a collection of custommeasurement programs.Both the STM32F4 [60] and MKW22D [61] chips supplya HWRNG that gathers entropy from sampling multiple freerunning and jittering oscillators, followed by a post processorbased on a linear shift register that ensures statistically welldistributed numbers. They also cover basic runtime healthtests implemented in hardware, as proposed by NIST [34].Although the data sheets claim to pass the NIST statistical testsuite, the manufacturer NXP recommends against its directuse for cryptographic applications in place of an approvedCSPRNG:
It is important to note there is no known cryp-tographic proof showing this is a secure methodof generating random data. In fact, there may bean attack against this random number generatorif its output is used directly in a cryptographicapplication. The attack is based on the linearity ofthe internal shift registers. Therefore, it is highlyrecommended that this random data produced bythis module be used as an entropy source to providean input seed to a NIST-approved pseudo-random-number generator based on DES or SHA-1. [61]
The nRF52840 by Nordic [62] implements a HWRNGbased on sampled thermal noise followed by an optional postprocessor that reduces bias. Even though the reference manualdescribes the mechanism as suitable for cryptographic pur-poses, our results indicate a slightly different picture withoutthe post processor, as we will show later in this section. The Texas Instruments CC2538 microcontroller [63] imple-ments a PRNG in hardware, which internally consists of a 16-bit shift register. Hence, its period is limited to . In contrastto HWRNG peripherals of the previous microcontrollers, thisdevice implements a pseudo-random algorithm controlled bythe same API that is commonly used to request true ran-dom data from on-chip generators. The PRNG is seeded bynoise samples on the receive path of the on-chip radio. Asimilar approach is established on the standalone AT86RF233transceiver module [64], which produces all random values byobserving noise from the radio.The ATECC508A [65] is a feature-rich cryptographic co-processor that runs a NIST-approved CSPRNG combined withan internal seed which is inaccessible from the outside. Theseed is automatically updated on every power or sleep cycle oron demand. In addition, the seed is generated internally basedon entropy extraction from quantum mechanical variations ofthe circuitry: In the crypto devices, the random seed comes fromvariations at a quantum scale within the device.The inherent quantum mechanical entropy of thecircuitry within the device provides a truly randomseed. [66]
Table I also lists the SAMD21 and the MEGA2560 micro-controllers by Atmel as examples of the numerous off-the-shelf devices, which completely lack hardware based randomsources. This class of devices heavily benefits from externalco-processors as well as internally generated entropy fromphysical resources that can seed an approved software PRNG.
A. SRAM PUF Seeder
Physically unclonable functions (PUFs) are one solutionto generate unpredictable numbers even without dedicatedelectronic circuits. They extract unique output from individualhardware properties. Here, we focus on SRAM PUFs becausethis memory technology is present on almost all availablemicrocontrollers. Transistor variations of memory cells leadto varying states after device power-on. The startup state ofmultiple memory blocks form a device-unique pattern plusadditional noise, which can be extracted, compressed and usedas PRNG seed values [67]–[70].
1) OS Integration:
Seed Generation.
The mechanism of a PUF-based seeder isvisualized in Figure 1 for the example of RIOT. It operates Entropy ExtractionHash FunctionKernel InitModules Init (PRNG)ApplicationBootloaderROM RAM s ee d Fig. 1: PUF SRAM random seeder integration in RIOT.during system startup prior to OS kernel initialization andreads out uninitialized SRAM cells. A PUF measurementis compressed by the lightweight DEK hash to build ahigh entropy 32 bit number that seeds a PRNG during itsinstantiation, afterwards in the OS startup sequence. It isnoteworthy that the lightweight DEK hash is not a crypto-graphic function.Furthermore, 32 bit entropy is not sufficientfor cryptographic use, but the mechanism is extensible tocryptographic requirements.
Re-seed Power Cycle.
Only startup state of uninitializedmemory after re-powering provides high entropy values. Eithera power-off cycle or a low-power cycle without memoryretention is required to generate a new seed. Among others,the required minimum power-off time depends on ambientconditions, age and properties of the power source. In ourexperiments, an off-time of 1 sec. has proven suitable forall platforms. A more detailed analysis about the impact ofenvironmental and experimental conditions to the SRAM PUFproperties has been presented by Schrijen et al. [71].Nevertheless, soft resets or low-power cycles with memoryretention can occur and trigger the startup routine that shouldnot perform a new memory measurement in the absence of apower-off cycle. For a solution, a simple soft-reset detectionmechanism writes a randomly chosen marker at a knownand reserved address in the SRAM. During the subsequentstartup, this memory address is inspected and a new memorymeasurement is only performed if the marker has disappeared.Otherwise, a soft-reset counter is incremented, added to thepreviously generated seed and the result is hashed again forcreating a new seed value, which is then stored for the nextcycle. The last seed, as well as the soft reset counter could bestored in protected memory for crypto-safe operations.
2) Evaluation of SRAM PUF Seeds:
Next, we analyse SRAM properties on common off-the-shelfmicrocontrollers and present results for the SAMD21 in Ta-bles II and III.
Memory Properties.
As a first step, we inspect the randomproperties of the memory in detail. We analyse intra- andinter-device variations between multiple PUF responses at
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 50reads of 1 kB SRAM on five SAMD21 MCUs (A–E) atambient 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 readsof 1 kB SRAM between five SAMD21 MCUs at ambienttemperature.ambient conditions. Therefor, we calculate (i) the minimumentropy as a measure of randomness and (ii) the hammingweight to determine bias between multiple startups of onedevice as well as (iii) the fractional hamming distance betweendifferent 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 fractionaldistance of approximately 50 % in (iii) indicates uniquenessof device responses.
Seed Properties.
For determining the proper size of memoryused for seed generation we evaluate the minimum seedentropy for varying input lengths and different platforms asvisualized in Figure 2 (left). All measurements converge toapproximately 31-Bit entropy with 1 kB SRAM, which is adecent result.Next, we test the distribution of hamming distances betweenmultiple generated seeds on every device against normaldistribution, using a simple KS-test. The probability functionin Figure 2 indicates that seed distances on all devices follow anormal distribution with an average expectation value of 0,52which is slightly biased by the influence of the MEGA2560platform. Still, all four controllers pass the test with probabilityvalues greater than 0,95, which allows to accept that they areunique and uncorrelated.
B. Statistical Analysis with NIST STS
We now evaluate the statistical properties of all hardwarebased random sources from Table I by applying the NIST SRAM length [Bytes]51015202530 E n t r o p y [ B i t ] MEGA2560SAMD21CC2538STM32F4 0 25 50 75 100Frac. Hamming Distance [%]0.00.20.40.60.81.0 C D F MEGA2560 p =0.951SAMD21 p =0.998CC2538 p =0.998STM32F4 p =0.998 ( , )=0.52 =0.014 Fig. 2: PUF SRAM seed evaluations. Min. Entropy for varyinginput lengths (left) and distributions of fractional HammingDistances (right). test suite. Following the input size recommendation for eachtest [24], we test 100 Mbit of random data. Every test isrepeated 100 times, which results in 1 Mbit test sequences.Random integers are generated on the constrained device andfed into the evaluation tool overt UART. It is worth noting thatalready the serial transmission of the data takes at least 45 min.with a baud rate of 115200. This added to the randomnessgeneration time which led to experiment times ranging fromone to over two hours per run. The experiment was executedunder office conditions at ambient temperature.Results of the χ -test on the distribution of p -values areshown in Figure 3. Certain tests produce multiple p -valuesand we show the average in that case. We display passing testswith gray bars, and we highlight failed tests with hatched redbars or red arrows in case that the p -value is too small to bedisplayed. The test suite additionally calculates a proportionof passed test runs and evaluates its significance. Passing testsin Figure 3 have a significant proportion within the confidenceinterval calculated from α = 0 . .All generators but the nRF52840 (w/o bias correction) andthe CC2538 show good statistical properties and pass thetest suite. The STM32F4 indicates one failure for the BlockFrequency test which analyses the proportion of ones in blocksof 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 thatis applied to the sampled noise. With enabled correctionthe nRF52840 (w/ bias correction) passes all statistical testswithout deficits. If the post-processor is disabled to increaseperformance, it fails several of the test statistics as visible inFigure 3. As we will see later, the bias correction requiresnotably more system resources. We repeated the statisticalexperiment with and without bias correction multiple timeswith similar results.The CC2538 consists of a simple 16-bit linear shift registerPRNG that (i) shortens the generator period (see Section III-C)and (ii) can be attacked with sparse processing resources dueto the linearity of the internal shift registers. Correspondingly,it fails in most of the tests. C. Performance Analysis
Throughput.
We measure the throughput and generationtime of different random sources on the STM32F4 platformas well as the internal generators of the other devices listed inTable I. Our test measures the throughput as a single-threadedapplication that generates streams of pseudo-random numberscontinuously, and we count the number of values producedwithin an interval of 10 seconds. In addition, we measure thetime of a single (blocking) function call that returns a randominteger with an oscilloscope by toggling an I/O pin via directregister access on the test device. In this way the measurementoverhead remains negligible. The ATECC508A crypto-chipalways processes 32 Bytes per request even if only integervalues are requested. We display rates, average processingtimes per random integer, and their standard deviation inTable IV.Clearly, the PUF based seeder as well as the externallyconnected devices perform two up to four orders of magnitudes
Generator Rate[kB/s] Avg. timeper Int. [us] σ timeper Int. [us]STM32F4+ PUF SRAM – 296.46 TABLE IV: Hardware Generated Random Numbers: Through-put and processing time.slower in comparison to the on-chip generator of the STM32F4that returns random values via direct register access. It isimportant to note that our measurements for the SRAM basedseeder only include processing times of the generator itself. Inpractice, the required power-off cycle as well as the OS startupare added, which can take tens to hundreds of millisecondsand is heavily dependent on the OS configuration. However,in the all-day use of an IoT-device, low power cycles occurrepeatedly. The cryptographic co-processor ATECC508A isnotably the slowest but it is the only candidate that runsa hardware based cryptographically secure random numbergenerator. Its performance strongly relates to the mode ofits device driver . In our measurements, we use the pollingmode, which queries the device for the completed execution4–7 times before random data is ready. Alternatively, in thenon-polling mode, the driver waits a maximum execution timefor each command, after which the data is ready to be fetchedfrom the co-processor. This potentially increases executiontimes but leaves room for parallel processes to be scheduledor low-power sleeping. Furthermore, the ATECC508A as wellas the AT86RF233 transceiver require additional I2C/SPItransmissions in comparison to the on-chip solutions.Among different MCUs on-chip generators, the STM32F4performs fastest. Although its CPU runs with the highestfrequency (96 MHz), the processing time is not directly pro-portional to the CPU speed. In comparison, the MKW22Dimplements a similar HWRNG and runs at half the CPUspeed (48 MHz), but calculates more than ten times longer toa produce random integer value. The CC2538 unsurprisinglyoperates comparably fast as it only operates a simple shiftregister without sampling noise. Both configurations of thenRF52840 generator indicate low throughput of 6–15 kB/s incomparison to the other generators, which presumably relatesto the internal sampling procedure. The bias correction leadsto statistically good properties of the output sequences but itreduces computational speed by a factor of 2.5. Energy Consumption.
To evaluate the energy consumptionof each generator, we measure the current consumption of allhardware based approaches with a digital sampling multimeter(Keithley DMM7510 7 1/2) at 1 MS/s and we drive the board https://github.com/MicrochipTech/cryptoauthlib Does not include time for power-off cycle ATECC508A always produces 32 Byte blocks −5 −4 −3 −2 −1 FrequencyBlock FrequencyCumulative SumsRunsLongest RunRankFFTNon Overlapping TemplateOverlapping TemplateUniversalApproximate EntropyRandom ExcursionsRandom Excursions VariantSerialLinear Complexity
STM32F4 + PUF SRAM 10 −5 −4 −3 −2 −1 STM32F4 + ATECC508A 10 −5 −4 −3 −2 −1 STM32F4 + AR86233RF 10 −5 −4 −3 −2 −1 STM32F4 + HWRNG10 −5 −4 −3 −2 −1 FrequencyBlock FrequencyCumulative SumsRunsLongest RunRankFFTNon Overlapping TemplateOverlapping TemplateUniversalApproximate EntropyRandom ExcursionsRandom Excursions VariantSerialLinear Complexity
MKW22D 10 −5 −4 −3 −2 −1 nRF52840 w/ bias correction 10 −5 −4 −3 −2 −1 nRF52840 w/o bias correction 10 −5 −4 −3 −2 −1 CC2538Test Passed Test failed, p < 10 −4 Test failed, p < 10 −6 p -value Fig. 3: Hardware Generated Random Numbers: χ -test results on the distribution of probability values from 15 NIST STStests. p -values ≥ µ J. Furthermore, the ATECC508Aproduces a minimum of 32 random bytes per request, thus, upto eight integers can be fetched for the same cost.Second most energy hungry after the cryptographic co-processor is the radio based random generation. Althoughthis approach is ten times faster, it only saves a factor offour in energy, which is due to the higher current draw of approximately 12.5 mA in receive mode of the AT86RF233during random bit generation. The ATECC508A on the otherhand only drives around 3 mA during operation. Results forthe SRAM based seed generator scale similar to the radiobased approach. It is worth noting that we only display thePUF SRAM overhead here that comes on top of a power-offcycle. Results for on-chip generators reflect similar propertiesas the processing times. The consumed energy to produceone random integer is below 3.5 uJ on all four HWRNGs.STM32F4 is notably the most economic competitor and itreduces the consumption per integer to less than 0.35 uJ.The difference in energy consumption of the two nRF52840modes lies about a factor of 2.5, which increases only a littlelower than the processing times listed in Table IV. Still, biascorrection introduces a notable increase in processing time andthereby in energy consumption.VII. S
OFTWARE G ENERATED P SEUDO -R ANDOM N UMBERS
Since von Neumann’s early work [72], the generic methodof 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 dis-tributed, independent random trials. As of today, very many ofsuch pseudo-random software generators exist, which complyto various random quality and complexity requirements. Fromthe perspective of an IoT operating system, we are interested intwo 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 IoTdevices. In the following, we will introduce and analyse eight A T E C C
A A T R F P U F S R A M S T M F C C M K W D n R F ( w / o p r o c . ) n R F ( w / p r o c . ) E n e r g y C o n s u m p t i o n [ u J ] Fig. 4: Hardware Generated Random Numbers: Energy con-sumption of external (left) and internal on-chip generators(right).popular generators—four complex generators of high qualityand four lightweight candidates for general purpose randomgenerators in the IoT.We apply the NIST, DIEHARDER, and the TestU01 testsuites to these PRNGs using RIOT as our platform. Our testprograms run as RIOT native processes on Linux serversto speed up experiment time. Thereby, we instantiated allgenerators with the same seed, except for the CTR PRNGand the NIST Hash DRBG that are not integrated into therandom subsystem and both impose specific requirements onthe seed.
A. Complex Generators
Fortuna.
The Fortuna PRNG is considered a cryptographicrandom number generator (DRG.4 [23]) and was designedto overcome the demand for entropy estimators that tendto be complex and inaccurate [38]. Internally, the Fortunaalgorithm maintains pools of entropy from which a periodic re-seeding is performed. Pools are filled from different availableentropy sources, whose values are distributed among thesepools. The entropy accumulation is conducted by hashing theinternal generator state and one entropy pool at a time using aSHA-256 function. That mechanism allows generating randomsequences of unlimited period, though, it cannot overcomethe requirements for proper entropy sources for seeding thegenerator and for updating entropy pools. Potential side effectsof re-seeding have been discussed in Section III-C. The finalblocks of pseudo-random output are generated by an AES-128block cipher in counter mode.
CTR PRNG.
The CTR PRNG is a cryptographic generator(DRG.4 [23]) specified and approved by NIST [25]. It isbased on a 128 bit AES block cipher in counter mode, whyit provides 128 bit security strength. To achieve this, thegenerator requires seeds of at least 128 bits entropy. Thetinycrypt library implementation, though, which we use in our subsequent evaluation, requires seeds with a minimum lengthof 256 bits. This is in contrast to all other implementationspresented in this section.
SHA256PRNG.
The SHA256PRNG is a generator that pro-vides cryptographically strong random numbers (DRG.2 [23]).The original mechanism of this generator was introduced inFIPS 186–1 [73] and analyzed by Kelsey et al. [13] and Desajet al. [74]. Outputs are generated by hashing the internalgenerator state, after which the internal state is updated bya linear transformation of the hash.SHA256PRNG is the successor of the SHA1PRNG, whichbecame popular as the choice of the Java
SecureRandom class.Until recently, it was considered secure [75] but got deprecatedin Android N . The reasons for deprecation mainly relate to aseeding bug in Java and to NIST deprecating the underlyingSHA-1 hash function because Wang et al. [76], [77] discoveredan attack that decreased the number of brute-force tries neededto foster state collisions from to operations. For thatreason, SHA256PRNG replaces the SHA-1 output function bySHA-256.The generator is forward secure up to the previous-to-last state, which can be recovered from the current generatoroutput by inverting the state update function. SHA256PRNGis confined to a single hash computation per block, whichmakes it computationally efficient. To add full forward secrecyNIST developed a collection of improved and standardizedrandom bit generators [25], the deployment of which has beenrecommended 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 theSHA256PRNG by a cryptographic function that hashes theinternal generator state to harden backtracking resistance afterstate compromise. This requires two hash computations oneach block. The NIST Hash DRBG additionally implementsan approved re-seeding mechanism to achieve unpredictabilityeven after state compromise (DRG.4 [23]). Mersenne Twister.
The Mersenne Twister is a widely usedgenerator, which in its default version is known to be non-secure [80], even though crypto-secure variants have beenexplored successively. Known advantages of that algorithmare a long period and comparably fast operations, because thegeneration of pseudo-random numbers avoids multiplicationand division. Instead, it requires a large internal buffer of 624integers.
B. Lightweight Generators
Tiny Mersenne Twister.
The Tiny Mersenne Twister is aderivate of the original Mersenne Twister that adapts to re-source constraints on the price of a narrowed scope. It heavilyreduces buffer requirements, on the price of a shortened periodlength. The generator is rather a reduced, memory efficientfallback solution of the full Mersenne Twister [81].
Xorshift.
The Xorshift generator belongs to the family oflinear-feedback shift register generators that are not crypto- https://android-developers.googleblog.com/2016/06/security-crypto-provider-deprecated-in.html graphically secure. It is known for its resource efficiencyas it is confined to simple XOR and shift operations. Inits simplest 32 bit state generator, we refer to it in thefollowing. Marsaglia [82] proposed a collection of extendedXorshift PRNGs with an increased period length and improvedstatistical properties. Vigna et al. analyzed and improvedthese generators further [83]–[85]. We briefly discuss resultsabout the Xorshift64* and the Xoroshiro128+ derivatives atthe side, which we integrated into RIOT for comparison.The Xorshift64* consists of a 64 bit state and applies aconstant multiplication to the output for bit scrambling. TheXoroshiro128+ requires 128 bit state, although it only outputs64 bit values per cycle. In contrast to Xorshift64* it adds twoconsecutive state values as a nonlinear transformation to theoutput. Park-Miller ”Minimal Standard”.
The Minimal Standardalgorithm is a linear congruential generators (LCG) and hasbeen known for decades [86]. Motivated by its objectiveto design a lightweight generator that is confined to 32 bitarithmetic without divisions, it was criticized for its statisticalproperties repeatedly [87]. The generator has a period or − , and it is limited to produce 31 pseudo-random bitsduring each cycle. In RIOT, however, the API presumes 32 bitrandom integers, thus, one integer is generated by combiningtwo generator outputs on each random request, which limitsthe usable period to − . LCGs are generally not designedfor cryptographic purposes. Knuth LCG.
The Knuth LCG is a widely used linearcongruence generator, which is computationally lightweightand has been examined for decades. It is implemented in arange of software projects and the source code is available indifferent standard libraries such as Newlib or Musl C . Thegenerator adopts a multiplier that was obtained by Knuth [50,Chapter 3.3.2, p. 108] but current implementations differ fromthe “MMIX” Knuth LCG in its increment. Furthermore, ittruncates the most significant bits of the 64 bit state to 32 bitoutput values due to known poor statistical properties of thelower bits in modulo-2 generators [88]. C. Statistical Analysis with NIST STS
Our first statistical analysis applies the NIST STS test suiteto these generators. The results of the χ -test are shown in Fig-ure 5. We display average p -values, where applicable. Analogto Section VI-B, tests are only passed after a significantproportion of repeated successful runs. That is, 96 successfulresults for a sample size of 100 sequences. Test 11 and Test12 (Random Excursions and Random Excursions Variant),however, are not always applicable and as such, they reducethe sample size internally. In our configuration, that lead toproportions of sequences passing one of both tests rangingfrom 53/56 to 67/71, in different PRNG measurements.All generators except for the Xorshift pass all 15 statisticalNIST tests. Xorshift results indicate a failure of the Rank (Bi-nary Matrix Rank) test. This test analyses linear dependences https://sourceware.org/newlib/ https://wiki.musl-libc.org/ among substrings of a sequence. In our case, all 100 testsequences fail already the first order hypothesis test and thus,the χ -distributions test fails as a consequence. We considerthis as weakness of the Xorshift. The deficit is fixed with theextensions applied to Xorshift64* and Xoroshiro128+, whichpass all tests.The Frequency Test on the Mersenne Twister had a verysmall p -value on the first run (not displayed here) and we ranthe same test again with altered seed value during initializa-tion. This succeeded the test as displayed in Figure 5. Wewant to stress that the magnitude of a p -value in hypothesistesting is not a causal measure of quality. This means that alow p -value confirms to reject a null hypothesis (sequenceis not random) but it does not claim how likely it is thatthe alternative hypothesis is true (sequence is random). Forfurther interpretation of statistical tests, we refer the reader tothe NIST test suite description [24] and work by Greenland etal. [89]. D. Statistical Analysis with DIEHARDER
Next, we apply the DIEHARDER test suite to our randomgenerator candidates. DIEHARDER test values behave similarto the NIST STS results presented in the previous section,but procedures are more demanding and failures are moredistinctive.Results of the Kolmogorov-Smirnov test for each PRNG inRIOT are displayed in Figure 6. Similar to the NIST tests,we plot average p -values, where applicable. In the style ofprevious graphs, we display passing tests with gray bars,and we highlight failed tests with hatched red bars or redarrows in case that the p -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 6pass all tests. Few test statistics return weak results, which isexpected in 1 % of the test cases due to the uniform distribu-tion of p-values. The DIEHARDER help page recommendsrepeated test executions and analysis of p-value histograms onweak results. All weak results in Figure 6 passed a repeatedexperiment run with a different seed.Several failures must be observed for the lightweight gen-erators displayed in the second row of Figure 6. The TinyMersenne Twister fails Tests OQSO (Overlapping QuadruplesSparse Occupancy Test), and the DNA test, which both ex-amine the distribution of overlapping substrings in a streamof random integer values. These results indicate a systematicproblem of the generator.The Xorshift generator fails the Monobit 2 test, the 32x32Binary Rank test, and the Count the 1s Stream test. TheMonobit 2 is a derivate of the NIST Frequency test andmeasures 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, theXorshift introduces bias within smaller sub-blocks, which iscompensated over the whole sequence. Results persist afterrepeated experiment executions with different seeds. Failing https://linux.die.net/man/1/dieharder −5 −4 −3 −2 −1 FrequencyBlock FrequencyCumulative SumsRunsLongest RunRankFFTNon Overlapping TemplateOverlapping TemplateUniversalApproximate EntropyRandom ExcursionsRandom Excursions VariantSerialLinear Complexity
Fortuna 10 −5 −4 −3 −2 −1 CTR PRNG 10 −5 −4 −3 −2 −1 SHA256PRNG 10 −5 −4 −3 −2 −1 Mersenne Twister10 −5 −4 −3 −2 −1 FrequencyBlock FrequencyCumulative SumsRunsLongest RunRankFFTNon Overlapping TemplateOverlapping TemplateUniversalApproximate EntropyRandom ExcursionsRandom Excursions VariantSerialLinear Complexity
Tiny Mersenne Twister 10 −5 −4 −3 −2 −1 Xorshift 10 −5 −4 −3 −2 −1 Minimal Standard 10 −5 −4 −3 −2 −1 Knuth LCGTest Passed Test failed, p < 10 −6 p -value Fig. 5: Pseudo Random Numbers: χ -test results on the distribution of probability values from 15 NIST STS tests. p -values ≥ − pass the hypothesis of uniformity. −5 −4 −3 −2 −1 BirthdaysOPERM 532x32 Binary Rank6x8 Binary RankBitstreamOPSOOQSODNACount the 1s (stream)Count the 1s (byte)Parking LotMinimum Distance (2d Circle)Minimum Distance (3d Sphere)Squeeze TestSumsRunsCrapsMarsaglia and Tsang GCDMonobitRunsSerialBit DistributionGeneralized Minimum DistancePermutationsLagged SumKolmogorov-Smirnov Testdab_bytedistribDCTFill TreeFill Tree 2Monobit 2
Fortuna 10 −5 −4 −3 −2 −1 CTR PRNG 10 −5 −4 −3 −2 −1 SHA256PRNG 10 −5 −4 −3 −2 −1 Mersenne Twister10 −5 −4 −3 −2 −1 BirthdaysOPERM 532x32 Binary Rank6x8 Binary RankBitstreamOPSOOQSODNACount the 1s (stream)Count the 1s (byte)Parking LotMinimum Distance (2d Circle)Minimum Distance (3d Sphere)Squeeze TestSumsRunsCrapsMarsaglia and Tsang GCDMonobitRunsSerialBit DistributionGeneralized Minimum DistancePermutationsLagged SumKolmogorov-Smirnov Testdab_bytedistribDCTFill TreeFill Tree 2Monobit 2
Tiny Mersenne Twister 10 −5 −4 −3 −2 −1 Xorshift 10 −5 −4 −3 −2 −1 Minimal Standard 10 −5 −4 −3 −2 −1 Knuth LCGTest passed Weak result Test failed, p > (1 − 10 −6 ) Test failed, p < 10 −6 p -value Fig. 6: KS-test results on the distribution of probability values from 31 DIEHARDER tests. p -values in the significanceinterval ( α, − α ) with α = 10 − pass the test. p -values within the interval ( α , − α ) with α = 5 · − are consideredas weak. on the matrix rank test was expected, as the equivalent fromthe NIST STS already failed in a similar configuration. TheCount the 1s Stream Test examines whether the distributionof ones in a stream of bytes matches that of uniform ran-dom bytes (Binomial(8, 0.5)). Failures indicate that Xorshiftoutput streams produce repeated “words” that appear withpronounced probability. It is likely that the same effect led tobad results of the linear dependency test among sub-matrices.The advanced Xorshift64* and Xoroshiro128+ generators passall DIEHARDER tests.The Minimal Standard generator fails the Bitstream and theGeneralized Minimum Distance test. The first successivelyanalyses overlapping 20-bit tuples ( possible words) andtests the statistic of missing words for a normal distribution.Failing this test indicates recurrence of patterns with enhancedprobability. The second test places random pairs of points ina square and tests its squared distances for an exponentialdistribution. The Minimal Standard generator fails to produceoutputs that appear independent in this dimension. Finally,this generator issues a suspiciously high number of weak testresults. For further interpretation of test results, we refer tothe DIEHARDER Test Suite description [49]. E. Statistical Analysis with TestU01
We additionally apply the “BigCrush” from the TestU01test suite to all software generators. Table V summarizes testresults with failures reflecting the number of reported teststatistics with p -values outside the confidence interval [0.001,0.9990].Results reflect a similar picture as depicted by NIST andDIEHARDER. TestU01, though, stresses more failures dueto a higher number of tests and tighter hypothesis criteria.According to L’Ecuyer et al. [54], p -values outside the sig-nificance interval are obtained approximately 2 % of the time,even if the PRNG behaves well. This, however, should notreoccur 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 deriva-tives Xorshift64* and Xoroshiro128+. The Tiny MersenneTwisters attains a failure rate of 8 %, which still exceeds theacceptable rate by a factor of four, whereas the Knuth LCGperforms notably better, failing about 5 % of the test statistics.For the Mersenne Twister, both failures have a p -valueof more than (1 − − ) , which significantly misses theacceptance interval, and unacceptable results reappear withrepeated experiment runs of different start values. This indi-cates systematic weaknesses. In contrast, all CSPRNGs reportzero or single failures based on p -values at the order of − .Repeated test executions then passed these tests. F. Performance Analysis
In the constrained IoT, an important dimension for any basesystem primitive lies in its performance. To assess the valueof the different random number generators, we measure thecomputational speed, the memory overhead, and the energyconsumption of all random number generators. Thereby, we consider base mechanisms, and we disable reseeding, if avail-able.
Throughput.
We measure the throughput and speed ofeach generator on the IoT STM32F4 hardware platform thathas been introduced in Section VI. Our test applications areimplemented analogously to those presented in Section VI-C.In addition, we display maximum values for cases, in whicha generator occasionally takes significant time to rebuild itsinternal state. Results are summarized in Table VI.Naturally, the four lightweight generators are fastest. Theycan reliably compute a random number in less than a microsec-ond. The two ultra-lightweight algorithms Knuth LCG andXorshift can even produce several numbers per microsecondon the constrained microcontroller, which must be considereda very low runtime overhead. With a production rate of morethan five MB/s, these generators could seamlessly support astream cypher, if they were cryptographically secure. Unfortu-nately they are not, but showed some weaknesses in statisticaltests as discussed in the previous section. Xorshift clearlyhas the highest throughput. Its derivatives Xorshift64+ andXoroshiro128+ perform around 2–3 times slower.From the complex generators, SHA256PRNG and theMersenne Twister are presented with additional maximal val-ues in processing time. For SHA256PRNG this is due tothe algorithmic property of producing 32 Bytes in one hashcall, which thereafter are split into 8 Byte long integer values.Hence, a hash value is computed only every fifth call, whichthen takes significantly longer. The Mersenne Twister followsa similar approach, although it does not involve cryptographicfunctions. At the initialization and every 624 calls, it generates624 fresh pseudo-random integers, which takes up to 190 µ s.This is orders of magnitudes longer than simply returning avalue from its buffer. This notably degrades its performancein comparison with the other lightweight generators.The three cryptographically secure generators Fortuna, CTRPRNG and SHA256PRNG operate more than one order ofmagnitude slower than the general purpose counterparts. Allalgorithms involve cryptographic functions (AES-128, SHA-256), which are computationally expensive on constrainedmicrocontrollers. Clearly, the SHA256PRNG is the most vitalamong all crpyto-generators presented, requiring around 70 µ son every hash computation, which leads to an average timeof 10 µ s per integer with number caching, and a rate ofalmost 400 kB/s. The more advanced NIST Hash DRBG(SHA-256) doubles the time per integer due to additionalhash computation in the feedback path. The implementation,however, does not allow number caching. This overhead iscompensated while requesting larger random blocks or streamsbecause state updates only occur once after each API call,while generating large outputs requires multiple hashing.In comparison to SHA256PRNG, the CTR PRNG generatesrandom four times slower in a stream of numbers, whereasreturning one random integer takes between six and thirtytimes longer. The CTR PRNG on the other hand has analmost constant runtime per integer. It is noteworthy thatup to 16 Bytes can be obtained by the CTR PRNG without CTR PRNG always calculates at least one AES-128 cipher on each call Generator Fortuna CTRPRNG SHA256PRNG MersenneTwister Tiny Mers.Twist. Xorshift MinimalStandard Knuth LCGFailures 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.
Generator Byte rate[kB/s] Avg. timeper Int. [us] Max. timeper Int. [us]Fortuna 44 87.50 –CTR PRNG 102 442.01 –SHA256PRNG 393 10.04 69.60Mersenne Twister 3605 0.85 189.20Tiny 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 measuredon STM32F4.runtime overhead because this generator computes one AES-128 block on every call that delivers 128 Bit from which four32 Bit integers can be created. The Fortuna operates slowestwhen requesting continuous random data and it halves thethroughput of the CTR PRNG. It has a constant runtime perinteger of less than 90 µ s, which on the other hand is faster bya factor of five than the CTR PRNG. It requires approximately120 % of time as the SHA256PRNG when processing a newhash internally (every eighth call), why the rate is less by afactor of almost ten.It is worth noting that the different design choices betweenSHA256PRNG and CTR PRNG relate to security implications.Holding a precomputed hash value in RAM as SHA256PRNGdoes while only one integer is requested may violate securityrequirements. In the presence of protected memory, a generatorcould secure its state and its cached numbers to reduce theattack surface. Low-cost devices often lack memory protectionmechanisms and as such, a design might be favored that avoidskeeping sensitive data in memory for longer intervals in orderto prevent (i) manipulation of future output (see Section II) aswell as (ii) predicting future random numbers (see Section III).In the presence of frequent re-seeding from fresh entropy, thegenerator state becomes less sensitive to memory attacks. Incontrast, the purpose of caching is performance enhancementand random numbers would be simply returned without updateafter re-seeding. Still, the performance per integer requestof the CTR PRNG would notably benefit from a cachingmechanism. Memory Overhead.
Memory is a particular scarce resourceon IoT devices, why memory of random number generatorsshould have the lowest possible footprint. We evaluate thememory overhead, which comes on top of a minimal RIOTbuild while enabling different PRNGs at compile time for thetarget STM32F4 MCU in Figure 7. Numbers are differentiatedw.r.t. RAM and ROM memory. Furthermore, crypto-purposegenerators include dependencies such as hash functions andciphers, which are highlighted as “RAM/ROM Dep.”.Results reassure the unsurprising previous observation thatcomplexity of the PRNGs correlates with resource consump- tion. Similar to the throughput measurements, Xorshift, Min-imal Standard and Knuth LCG generators remain most frugalin memory and only require around 100 Bytes additionalROM and few additional Bytes in RAM. The internal statesize (32 bit), i.e.,
Energy Consumption.
We evaluate the energy consumptionwith the same setup as described in Section VI. Figure 8 dis-plays the energy consumed by each pseudo-random generatorsin RIOT, measured on the STM32F4 platform. The Fortuna,CTR PRNG and the SHA256PRNG crypto-purpose generatorsare most expensive in energy—up to several micro Joule perinteger. Thereby, SHA256PRNG operates at the lower endand the SHA256-based NIST Hash DRBG consumes abouttwice as much. The CTR PRNG notably demands maximalresources. Using approximately 24 µ J it drains a factor of 3.7more energy than the Fortuna. The CTR PRNG generates fourintegers in one call, why it outperforms the Fortuna slightlyin a stream of random numbers.All other PRNGs operate on the same scale as the on-chip HWRNG on that device (compare Figure 4), which takes F o r t u n a C T R P R N G S H A P R N G M e r s e n n e T w i s t e r T i n y M e r s . T w i s t . X o r s h i f t M i n i m a l S t a n d a r d K n u t h L C G M e m o r y O v e r h e a d [ k B y t e s ] F o r t u n a C T R P R N G S H A P R N G M e r s e n n e T w i s t e r T i n y M e r s . T w i s t . X o r s h i f t M i n i m a l S t a n d a r d K n u t h L C G M e m o r y O v e r h e a d [ k B y t e s ] Fig. 7: PRNG memory overhead in ROM (left) and RAM (right) measured on the STM32F4 microcontroller. “Dep.” denotesmemory requirements of dependent software modules ( i.e., hashes, ciphers) that a generator may include. F o r t u n a C T R P R N G S H A P R N G M e r s e n n e T w i s t e r T i n y M e r s . T w i s t . X o r s h i f t M i n i m a l S t a n d a r d K n u t h L C G −2 −1 E n e r g y C o n s u m p t i o n [ u J ] Fig. 8: PRNG energy consumption per integer measured on aSTM32F4 microcontroller.approximately 0.03 µ J. Non-cryptographic generators remainby a factor of 20–100 below the most efficient cryptographicgenerator SHA256PRNG. The most resource-friendly general-purpose PRNGs are the Xorshift with an average of 0.01 µ Jand the Knuth LCG with 0.02 µ J per integer, which is inagreement with our findings from throughput measurementsin Table VI. The enhanced Xorshift64* and Xoroshiro128+consume 3–4 times more energy than their lightweight 32bit Xorshift companion, which is a notable increase over theKnuth LCG.
G. Recommendations on Software-PRNGs
Having examined eleven widely available software-PRNGs(eight algorithms plus three variants) that cover the basiclevels and functions, we are now ready to make the choice ofrecommendation for random number generators to be includedin a constrained IoT operating system. Following the previousdiscussion in Section IV, we differentiate our selections in one general purpose and one crypto-secure PRNG as two differentsystem functions.
General Purpose Generator.
The general purpose generatorshould be very lightweight, while complying with commonstatistical requirements. It should run seamlessly on veryconstrained 8 bit microcontrollers at low energy costs.From the two ultra-lightweight generators, only the KnuthLCG passes all NIST and Dieharder statistical tests. It per-forms second best. The Xorshift generator consumes about halfof its resources, but has notable statistical flaws. The KnuthLCG produces better output sequences while being similarlyfast. The enhanced Xorshift64* or Xoroshiro128+ generatorsexceed resource consumption of the Knuth LCG significantly.All other lightweight generators admit lower statistical qualityat higher cost. We therefore recommend the Knuth LCG tobe used as general-purpose, non-cryptographic PRNG in theconstrained IoT.
Crypto-secure Generator.
The Fortuna, SHA256PRNG,(NIST Hash DRBG,) and CTR PRNG are the only candidatesfor a CSPRNG, as they are constructed from secure and non-invertible cryptographic functions. They pass all statisticaltests (including BigCrush) and fulfill the requirements ofunpredictability and brute-force resistance.Perfect forward and backward secrecy after a state com-promise is assured by the Fortuna, CTR PRNG and theNIST Hash DRBG based on their one-way nature during stateupdate in combination with re-seeding. The SHA256PRNGholds a (linear combination of) the previous-to-last state andthus only guarantees forward secrecy for earlier values dueto its secure one-way SHA-256 output function (cf., [13]).Backward secrecy can be added by reseeding on demand tothe generator as discussed in III-C.This generator stands out as it is the only cryptographicallysecure algorithm that attains moderate performance values. Allcompetitors exceed the SHA-256 performance measures byone order of magnitude in at least one dimension. We con-clude that the resource frugality in combination with modularcryptographic robustness justify to commend SHA256PRNGas the CSPRNG in the constrained IoT. VIII. H
ARDWARE OR S OFTWARE G ENERATED R ANDOMNESS IN THE I O T?An increasing number of embedded controllers is expectedto provide hardware primitives for basic cryptographic op-erations in the near future, which bring promise of fastand efficient random generators that contribute real entropy.The performance of on-chip HWRNGs, however, is heteroge-neous. Some devices operate fast and save battery resources( i.e.,
STM32F4), while others are slow and require notablylarger amounts of energy ( i.e., nRF52840) than correspondingsoftware. As shown in Section VI, few devices even producepoor statistical output ( i.e.,
CC2538). Some manufacturersadvice against an immediate use for cryptographic randomnumber. Other manufacturers describe their on-chip randomnumber generators as suitable for cryptographic purposes with-out providing a cryptographic proof (Nordic). Truly randomgenerators rely on real entropy from a physical process. Thismay be influenced by environmental factors, which opens anattack surface.Common IoT operating system such as RIOT need to makedecisions on which hardware functions to include and how tointegrate hardware and software components into the randomsubsystem. These multi-platform multi-purpose systems wantto provide an overall lean solution of reliable quality at apredictable performance. To aid this design process, we nowanalyze key performance properties of the different hardware-and software-based random number generators.In Figure 9, we compare energy consumption and averagegeneration time per integer (left) as well as the average currentflow (right) for the hardware systems summarized in Table I.Software generators are measured on the STM32F4 board.We observe that the lightweight software generators arefastest and together with the HWRNG on the chip ofSTM32F4 consume least energy. While software PRNGs oper-ate up to five times faster, they charge a higher current than theHWRNG which results in a similar energy footprint. On-chiphardware generators on the CC2328 and MKW22D devicesconsume about one order of magnitude more time and energy.Hence we argue for the choice of a lightweight softwaregenerator ( i.e., the Knuth LCG) for the regular productionof random numbers. Hardware generators are best used for(re-)seeding, when true entropy is required.Running a cryptographically secure generator demandsunsurprisingly more energy resources in comparison to itslightweight PRNG alternatives or the STM32F4 on-chipHWRNG solution. Among the three software CSPRNGs,SHA256PRNG is clearly most frugal with an energy con-sumption of 0.5 µ J for one integer and an average currentconsumption of 17 mA. Note that caching is involved here,thus, only every eighth requested integer involves computationof a new hash which then causes currents up to 20 mA. Fortunaand CTR PRNG drain notably more energy in comparison tothe SHA256PRNG as already visible in the previous analysis.CTR PRNG consumes up to 24 µ J for one integer, whichis four times more than Fortuna, even though its averagecurrent consumption is similar to the SHA256PRNG that uses5 mA less than Fortuna. The increased energy consumption for one integer may be compensated in a stream or bycaching intermediate numbers. Hardware based random num-bers on the nRF52840 controller consume energy similar tothe CSPRNGs, although the low-power MCU drains less than5 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 ap-proved CSPRNG in hardware, exhibits a worse performancethan all software CSPRNGs. The throughput of the softwaresolutions is 20–100 times higher while the energy consump-tion remains 3–10 times less. The average current of theATECC508A solution remains small in comparison to thesoftware solutions that do not even have to power a seconddevice. This is because the main controller idles while theexternal chip processes random values. The external chiprequires only a small current as shown in Section VI-C.Eventually, the total energy consumption can be improved byfurther driver optimizations. A minimum of 280 µ J is requiredto request from one up to eight integers. It is noteworthythat this chip implements secure seeding on its own, whichenhances very constrained devices without proper entropysources.Memory limitations of very constrained devices ( e.g.,
AT-mega2560 with only 8 kB RAM and 256 kB Flash) are un-able to run complex software CSPRNGs as they requiremore memory. The Fortuna CSPRNG would take almost50% of the ATmega2560 RAM leaving only 4 kB for theremaining firmware. This is not sufficient for real-world IoT-networking applications [45]. Instead, the device driver forthe ATECC508A chip can be included which (i) reduces thememory requirements of cryptographic functions, (ii) offloadsprocessing 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 random-ness generators, namely the AT86RF233 transceiver as well asthe SRAM PUF are energy expensive using up to one order ofmagnitude more than the SHA256PRNG. Both mechanisms,though, are not designed to be used periodically. Instead, theyact as seed sources that are utilized once during instantiationof a PRNG and on re-seeding. The current consumptions differnotably between the transceiver and the PUF SRAM. Thetransceiver powers two devices in active mode because theMCU polls random bytes via the SPI while the radio needs tostay in receive mode. This draws a current of up to 26 mA intotal. The PUF SRAM on the other hand takes twice as longto retrieve a high entropy integer but it drains less than 10 mAon average. As depicted in Section VI-A, this procedure needsto take place very early on startup—even before clock and businitialization in the operating system.In summary, we argue that software generators—a lightweight general purpose PRNG or an approvedCSPRNG—are the preferable solution for producing (secure)random numbers. Co-processors and hardware assistance arevital for adding entropy at (re-)seeding instances and can helpto improve memory footprints for very constrained devices.They lead to a decreased throughput, though, when comparedto software that runs on the main controller. In particular,transceivers as well as uninitialized SRAM are very important Avg. Time [us]10 −2 −1 A v g . E n e r g y [ u J ] X o r s h i f t K nu t h L C G T i n y M e r s e nn e T w i s t e r M e r s e nn e T w i s t e r M i n i m a l S t a n d a r d S T M F CC S H A P R N G M K W D F o r t un a A T R F n R F w / o P U F S R A M C T R P R N G n R F w / A T E CC A −2 −1 A v g . E n e r g y [ u J ] Hardware-generated:STM32F4 + ATECC508ASTM32F4 + AT86RF233STM32F4 + PUF SRAMSTM32F4 (HWRNG) CSPRNGs on STM32F4:FortunaCTR PRNGSHA256PRNG PRNGs on STM32F4:Mersenne TwisterTiny Mersenne TwisterXorshiftMinimal StandardKnuth LCG Other Platforms:CC2538 (HWRNG)MKW22D (HWRNG)nRF52840 (HWRNG) w/o bias correctionnRF52840 (HWRNG) w/ bias correction
Fig. 9: Average energy consumption over average time (left) and average current draw (right) for hardware and softwaregenerated random integers.on devices with missing HWRNGs. Even though PUF SRAMand the radio-based entropy sources are costly, they uniquelycontribute entropy and are only sparsely called for seedingpurposes. IX. C
ONCLUSIONS AND O UTLOOK
In this paper, we explored the building blocks for ran-domness in the constrained Internet of Things: hardwareand software components that generate statistical randomness,entropy, and robustness according to cryptographic challenges.We systematically derived the requirements for IoT randomsubsystems from the perspectives of statistics, security, andoperating system integration. An extensive, comparative eval-uation using several prominent test suites as well as detailedperformance measurements on popular boards delivered in-sights into the overall quality and suitability of the differentcomponents under test.This work derives four major recommendations:1) Separate general purpose random generators from cryp-tographically secure generators already on the OS level.Avoid any mixture or interference between the two.2) Prefer software generators over random hardware, asthey are more efficient and reliable. Exploit hardwarecomponents as additional entropy sources for (re-)see-ding, or when CSPRNG operation is infeasible on aconstrained node.3) The Knuth LCG is the most efficient general purposegenerator of decent statistical quality. It is simple andlean enough to run on very constrained devices.4) We recommend SHA256 PRNG as a cryptographicallysecure generator, since it outperforms its competitors byan order of magnitude in several dimensions.With this work, we hope to contribute to a thoughtfuldevelopment toward a secure Internet of Things. This will beof particular importance, as more and more (sensitive) dataoriginates from IoT nodes and needs protection. Content object security with OSCORE [90], [91] and LAKE [92], for ex-ample, will facilitate the encryption of individual informationunits, but will extend the use of cryptographic primitives suchas random numbers during operation.R
EFERENCES[1] H. Corrigan-Gibbs and S. Jana, “Recommendations for Randomness inthe Operating System, or How to Keep Evil Children out of Your Pooland Other Random Facts,” in . 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¨unes, M. W¨ahlisch, and T. C. Schmidt,“RIOT OS: Towards an OS for the Internet of Things,” in
Proc. of the32nd IEEE INFOCOM. Poster . Piscataway, NJ, USA: IEEE Press,2013, pp. 79–80.[4] M. Lenders, P. Kietzmann, O. Hahm, H. Petersen, C. G¨undogan,E. Baccelli, K. Schleiser, T. C. Schmidt, and M. W¨ahlisch, “Connectingthe World of Embedded Mobiles: The RIOT Approach to UbiquitousNetworking 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¨undogan, P. Kietzmann, M. Lenders, H. Petersen,T. C. Schmidt, F. Shzu-Juraschek, and M. W¨ahlisch, “Security for theIndustrial IoT: The Case for Information-Centric Networking,” in .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¨ahlisch, “Eco: A Hardware-Software Co-Design for In Situ Power Measurement on Low-endIoT Systems,” in
ACM SenSys, 7th International Workshop onEnergy 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 ComputingUnits,” in
Proceedings of the Second Symposium on Large ScaleDigital Computing Machinery . Cambridge, United Kingdom: HarvardUniversity Press, 1951, pp. 141–146.[8] D. E. 3rd, J. Schiller, and S. Crocker, “Randomness Requirements forSecurity,” 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 ACMSIGSAC Conference on Computer & Communications Security . NewYork, NY, USA: ACM, 2013, pp. 647–658. [10] A. Francillon and C. Castelluccia, “TinyRNG: A Cryptographic RandomNumber Generator for Wireless Sensors Network Nodes,” in WIOPT’07: 5th International Symposium on Modeling and Optimization inMobile, Ad Hoc and Wireless Networks and Workshops . Limassol,Cyprus: IEEE, 2007, pp. 1–7.[11] K. Nohl, D. Evans, S. Starbug, and H. Pl¨otz, “Reverse-Engineering aCryptographic RFID Tag,” in . 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 Attackson Pseudorandom Number Generators,” in
FSE ’98: Proceedings of the5th 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 De-sign and Analysis of the Yarrow Cryptographic Pseudorandom NumberGenerator,” in .Berlin, Heidelberg: Springer, 1999, pp. 13–33.[15] L. Dorrendorf, Z. Gutterman, and B. Pinkas, “Cryptanalysis of theWindows Random Number Generator,” in
CCS ’07: Proceedings ofthe 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: VirtualMachine Reset Vulnerabilities and Hedging Deployed Cryptography,” in
NDSS , 2010.[17] Z. Guttermann, B. Pinkas, and T. Reinman, “Analysis of the LinuxRandom 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 LinuxPRNG on Android: Weaknesses in Seeding of Entropic Pools andLow Boot-Time Entropy,” in . 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 ac-cessed 07-17-2020, 1996.[20] D. Shumow and N. Ferguson, “On the Possibility of a Back Door in theNIST 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, andC. 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 classesfor random number generators,” BSI, Bonn, Germany, Tech. Rep. AIS20 / 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 PseudorandomNumber Generators for Cryptographic Applications,” National Instituteof Standards & Technology, Gaithersburg, MD, US, Special PublicationNIST SP 800-22, 2010.[25] E. B. Barker and J. M. Kelsey, “Recommendation for Random Num-ber Generation Using Deterministic Random Bit Generators,” NationalInstitute of Standards & Technology, Gaithersburg, MD, United States,Special Publication NIST SP 800-90A, 2012.[26] W. Stallings, Cryptography and Network Security , 6th ed. PearsonEducation, 2014.[27] E. Rescorla and N. Modadugu, “Datagram Transport Layer SecurityVersion 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 ofThings,” IETF, RFC 7925, July 2016.[29] M. Girault, R. Cohen, and M. Campana, “A Generalized BirthdayAttack,” 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 onBirthday 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: Random-ization and Probabilistic Techniques in Algorithms and Data Analysis(Second Edition) . Cambridge University Press, 2017. [33] C. E. Shannon, “A Mathematical Theory of Communication,”
BellSystem 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 forRandom 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 BitGenerator (RBG) Constructions,” National Institute of Standards &Technology, Gaithersburg, MD, United States, Special Publication NISTSP 800-90C, 2016.[37] P. Gutmann, “Software Generation of Practically Strong Random Num-bers,” in
SSYM ’98: Proc. of 7th USENIX Security Symposium . Berke-ley, 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 thathash outputs can’t be controlled; the conventional wisdom is simplywrong.” https://blog.cr.yp.to/20140205-entropy.html, last accessed 07-17-2020, 2014.[40] V. Dukhovni, “Opportunistic Security: Some Protection Most of theTime,” IETF, RFC 7435, December 2014.[41] A. Dunkels, B. Gr¨onvall, and T. Voigt, “Contiki - A Lightweight andFlexible Operating System for Tiny Networked Sensors.” in
Proc. ofIEEE Local Computer Networks (LCN)
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ˆea, “RELIC is an Efficient LIbrary forCryptography,” https://github.com/relic-toolkit/relic.[49] R. G. Brown, D. Eddelbuettel, and D. Bauer, “Dieharder: ARandom 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,” NationalInstitute of Standards & Technology, Gaithersburg, MD, US, FederalInformation Processing Standards 140–1, January 2001.[52] ——, “Security Requirements for Cryptographic Modules,” NationalInstitute of Standards & Technology, Gaithersburg, MD, US, FederalInformation Processing Standards 140–2, May 2002, supersedes FIPS140–1.[53] G. Marsaglia, “The Marsaglia Random Number CDROM includingthe 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 Testingof Random Number Generators,”
ACM Trans. Math. Softw. , vol. 33,no. 4, 2007.[55] M. S´ys and Z. ˇR´ıha, “Faster Randomness Testing with the NISTStatistical Test Suite,” in
SPACE ’14: Security, Privacy, and AppliedCryptography Engineering . Cham, Switzerland: Springer, 2014, pp.272–284.[56] P. L’Ecuyer and R. Simard, “TestU01 A Software Library in ANSI Cfor Empirical Testing of Random Number Generators. User’s guide,compact version,” Department of Computer Science and OperationsResearch, University of Montreal, Montreal, Canada, Tech. Rep., 2013.[57] M. Mascagni and A. Srinivasan, “Algorithm 806: SPRNG: A ScalableLibrary for Pseudorandom Number Generation,”
ACM Trans. Math.Softw. , vol. 26, no. 3, 2000. 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 andZigBee/ZigBee IP Applications , Texas Instruments, May 2013, versionC.[64]
AT86RF233 Low Power, 2.4GHz Transceiver for ZigBee, RF4CE, IEEE802.15.4, 6LoWPAN, and ISM Applications , Atmel, July 2017, rev.8315E–MCU Wireless–07/14.[65]
ATECC508A CryptoAuthentication Device Complete Data Sheet , Mi-crochip, December 2017, rev. A.[66]
Generating Random Secrets: ATSHA204A, ATECC108A, andATECC508A , 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 . 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 CommercialOff-The-Shelf Devices,” Doctoral Dissertation, Department of ComputerScience, Technische Universit¨at Darmstadt, December 2017. [Online].Available: http://tuprints.ulb.tu-darmstadt.de/7014/[69] K. Krentz, C. Meinel, and H. Graupner, “Secure self-seeding withpower-up SRAM states,” in
ISCC ’17: Symposium on Computers andCommunications . Heraklion, Greece: IEEE, 2017, pp. 1251–1256.[70] P. Kietzmann, C. G¨undogan, T. C. Schmidt, and M. W¨ahlisch, “APUF Seed Generator for RIOT: Introducing Crypto-Fundamentals tothe Wild,” in
Proc. of 16th ACM International Conference on MobileSystems, Applications (MobiSys), Poster Session . New York, NY, USA:ACM, June 2018.[71] G.-J. Schrijen and V. van der Leest, “Comparative analysis of SRAMmemories used as PUF primitives,” in
DATE ’12: Design, AutomationTest in Europe Conference Exhibition . Dresden, Germany: IEEE, 2012,pp. 1319–1324.[72] J. von Neumann, “Various Techniques Used in Connection with RandomDigits,”
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 ProcessingStandards 186–1, December 1998.[74] A. Desai, A. Hevia, and Y. L. Yin, “A Practice-Oriented Treatment ofPseudorandom Number Generators,” in
EUROCRYPT ’02: Advances inCryptology , 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 . WileyPublishing, 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 InternationalConference on Advances in Cryptology . Berlin, Heidelberg: Springer-Verlag, 2005, pp. 17–36.[77] M. Stevens, E. Bursztein, P. Karpman, A. Albertini, and Y. Markov, “TheFirst 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 ProcessingStandards 186–3, June 2009, supersedes FIPS 186–2.[79] ——, “Digital Signature Standard,” National Institute of Standards &Technology, Gaithersburg, MD, US, Federal Information ProcessingStandard 186–4, July 2013.[80] M. Matsumoto and T. Nishimura, “Mersenne Twister: A 623-dimensionally Equidistributed Uniform Pseudo-random Number Gen-erator,”
ACM Trans. Model. Comput. Simul. ∼ m-mat/MT/TINYMT [82] G. Marsaglia, “Xorshift RNGs,” Journal of Statistical Software,Articles
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 thePRNG shootout,” http://prng.di.unimi.it/, last accessed on 04-01-2020.[86] S. K. Park and K. W. Miller, “Random Number Generators: Good OnesAre Hard to Find,”
Commun. ACM
Proc. ofthe 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, confidenceintervals, and power: a guide to misinterpretations,”
European Journalof Epidemiology , vol. 31, no. 4, pp. 337–350, 2016.[90] G. Selander, J. Mattsson, F. Palombini, and L. Seitz, “Object Securityfor Constrained RESTful Environments (OSCORE),” IETF, RFC 8613,July 2019.[91] C. G¨undogan, C. Ams¨uss, T. C. Schmidt, and M. W¨ahlisch,“IoT Content Object Security with OSCORE and NDN: A FirstExperimental Comparison,” in
Proc. of 19th IFIP NetworkingConference . 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, “Require-ments for a Lightweight AKE for OSCORE,” IETF, Internet-Draft –work in progress 04, June 2020. A UTHOR B IOGRAPHY
Peter Kietzmann received the M.Eng. degree ininformation technology from the Hamburg Univer-sity of Applied Sciences, Hamburg, Germany, wherehe is currently pursuing the Ph.D. degree with theInternet Technologies Research Group. His partic-ular research interest includes low-power radios,and IoT protocols, many of which he analyzedand transformed into code of RIOT. In the Germanresearch project I3 (ICN for the Industrial Internet)he explores IoT-based technologies for informationcentric networks and security components.