 We are here for the talk Wheel of Fortune, analyzing embedded OS number generators with Joss Wetzels and Alia Basi. Short introduction, they're both researchers. They work with distributed and embedded systems groups at the University of Twente. Joss Wetzels is hardening systems and hands-on teacher for offensive security. Alia Basi comes as a... So, welcome to the session for the lecture. Hardware. Wheel of Fortune is the head of vulnerability analysis and penetration testing group and we are happy to give feedback on Twitter with the hashtag C3T. I'll just give over to both of them and we'll have a great talk and question back. We just got introduced and it's going on right away. Welcome everybody to our talk. Wheel of Fortune, analyzing embedded OS random number generators. We're looking at embedded OS random number generators. I'm Joss Wetzels as I already was introduced. I'm a researcher for embedded system security. I'm Alia Basi, a PhD student at distributed and embedded system security group. I'm from the University of Twente and I'm visiting researcher at chair of system security of Wilcombe University Bochum in Germany. So, we start with the introduction of the OS random number generators today and then we go over some embedded challenges and we're looking at a couple of embedded generally hard-earnings for random numbers for OS random number generators. We will have some case studies showing these challenges, how it's affecting all of the existing embedded OSs or real-time operating systems. And we're looking at the impact of these things on the OS system, which I'm supervising. And, yeah, so... Yeah, and now let's start. So, first of all, embedded systems are actually now distributed from consumer electronics to medical devices, critical infrastructures, military equipment or any other material. And besides that, there is a drive to connect these embedded systems. And the original devices were not designed to be connected to danger. And now there is a gap where vendors have to speak, right? And, well, this can cause problems. And as you can see, for example, for the random number generators which we specifically work, you can see there are really problems. For example, millions of embedded devices use the same hard-earnings. The problem is, among other things, that many devices use SSH and TLS keys that are programmed firmly. And, yeah. Well, what is randomness? I don't want to talk about it. I don't want to talk about randomness here, but it's generally a stream of bit if you cannot read the next bit. Generally, it's just because that we can't say what's next. And another side of it is like entropy. And the other side of it is entropy. And it is, in the end, in effect, a quantity or a measure for a coincidence or for information. And high entropy is high. And of course, why this is very important because actually random numbers are actually a fundamental part of other security ecosystems. So, for example, a lot of random numbers are a critical part of cryptographic systems. And they are actually being used for keys, non-sense, and other things. Stack-smashing protections. So, randomness is actually critical for other underlying systems which are based upon them. So, that might be a good idea. So how we can generate random numbers from physically? Like true random number, different systems and radioactive decays or random noises. You can generate hardware randomness that can be created by radioactivity and four registers, or as in tech-based devices, we can, for example, integrate CPUs or serve smart cards. But there are some downsides to randomness. For example, they are expensive, or very soft, or they've been recommended to try to move to the next target. That's why you can use those expensive hardware as you are using some very rich hardware. And there are like deterministic numbers which trade seeds into sequence of random-looking bits. And, for example, not all of these random numbers can be used for security purposes, for example, and show it's really safe by something better. It's not designed for security purposes, but some people use it anyway. So, because of that, we have secure random number generators. And those are usually they have a particular class or properties, first of all, is that random number generators, a single random number generator, and they must have forward security, which means that in case the internal state of the system is compromised, and the past outputs must still appear random. And again, for example, if the system is compromised, it must be a random state that is compromised again, which still might not appear random, provided that the receiving will be the sufficient quality entropy. So, because of that, a designing random number generator will not be used, but because of that you have for a random number generator like NIST SB 898, possibly by a source of seed entropy. But the problem is that this standard needs some more problems. For example, initial seed entropy or receding control or how town will be of the source of the entropy. It's so because of that, some other people think about it and design something else, which already invented in some advance OSes, such as OS6, or iOS. So, the problem here is actually a chicken and egg problem, because well, chicken and egg problem, you need some kind of entropy or randomness, but these randomnesses again, so ideally you want to use this is a compound, means such as like if we consider quantum randomness is like radioactive decay, shock noises or non-quantum randomness, these are physical phenomena, radioactive decay, shock noises and other physical influences of the environment. But they are not always usable and practically you take unpredictable system events and these are user inputs and influences of the environment or like secure randomness should be provided as a system service because it's hard and of course if you don't, so as a system service for example, do you have a random in a Unix-like system or a crypto-random API on Windows and we have a new random device in Unix-like system and as a random number generator and again based on open SSL you have like open SSL it's very very important on this a lot of relevant services we've taken a look at the general background of random number generators and now we'll take a look at what kind of background these random number generators have and now we'll look at the challenges normally you just use random and use it but in the embedded world it's unfortunately not so difficult not so easy because these embedded random generators are often not too random or not safe first of all is the problem that there are many different operating systems in the normal computer there are only OSX, BSD, Linux and Windows but in this embedded world there are many different systems that all have different capabilities it's difficult to design a standardised additional generator for all these different systems a similar problem is in the hardware where in the embedded world microcontrollers are used so if you assume that there is a physical or hardware additional generator then you can't use it in chips that don't have and of course devices are designed to be as small as possible and use as little resources for example the processor is relatively slow i.e. the cryptology can't be very complex you can't use a lot of batteries and often there are limitations with the storage of a relatively small entropy pool also the environment of the embedded world is relatively boring because the embedded world often only with other technical things is very deterministic i.e. it's difficult to find new peripherals because there are no peripherals there are no hardware random number generators and these conditions are usually worst during boot time because at the beginning it's very very deterministic there is a solid boot sequence and that works i.e. yet non-blocking interfaces to random number generators allow for drawing from the random number generator even when insufficient entropy is at the end of the day it results in something more than the minimum entropy so this is a very good method because a lot of bad devices will be generated if there is a persistent boot and an initial state the problem is that you have a system with little entropy and at the beginning it already generates random numbers which are not really random a relatively new solution is to work with a seed file i.e. a random number generator which writes a file in a seed file and a really random or pseudo random sequence but this still doesn't solve this problem some possibilities is to have a seed file in the firmware but the problem is it's difficult to do it unpersonally or you could use personalized data i.e. the MAC address or the serial number but this is also difficult or you can use less good sources for entropy like urns it's also difficult now that we have an idea why it's so hard that embedded operating systems really have random generators we will now imagine a few false studies mainly we will talk about how embedded systems implement it and how they can't i.e. QNX that's a Unix-like operating system that was originally on the BlackBerry it's the system that's under BlackBerry OS that's also in cars, in routes even in nuclear systems it has a defu random implementation that's a bit adapted it's non-blocking and it's implemented in the user space that's started after the boot we have reverse engineered and found out that it's based on Yaro but it turned out to be based on an older product implementation not on the reference version of Yaro a paper release so it only has a single entropy pool and no faster output no block service no energy output at all it's directly drawn from the input so when QNX Yaro I turned the version of this over it's a QNX Yaro that means it's directly drawn from the internal status and additionally it diverges this system that they used also from this already bad old Yaro here you see a design diagram we first tested the quality of the outputs tested with the dieharder and the NIST statistical test suit it has both of these tests suits but it only tells us about the output and not about the source not about the entropy after we engineered the reverse with the boot time entropy that's the system time the clock cycle the entropy sources system time clock cycles proc PIDs and def names and that a hash function is calculated that is used to initialize Yaro because it sounds a bit strange to us we looked how the boot time entropy looks like so our quality measure is the min entropy which basically when this entropy goes in one direction that would be very easy for an attacker to go in there and use the NIST entropy source to validate this data we collected 50 boot runs by instruments to run the number generator and I'm loving the raw data I'm loving the raw data which isn't good at all because the min entropy is 0.0276 that's much less than the 1 bit of min entropy per 8 bit raw data that you want to have and here you can see a visualization of it we also evaluated the cross boot entropy how it looks between the single boot runs this is also behavior you don't want and it turned out that apart from having less than stellar single boot entropy gathering we found that it was also very similar between the single boot you can see it's very consistent and very predictable what you don't want between the 50 boot runs that we tried so it was certain things that always come back there's the same number of processes each time the same names and the only real coincidence comes from times but of course it's not coincidence here you can see the reverse engineered run time entropy you have system information which is basically process IDs thread IDs, flags, all these kind of process variables fed into the shallow one into the yarrow input function and in the bottom left you have your interrupt timing source in the bottom right there is an undocumented function which is a callback at the bottom end we have interrupt timing sources and it's not clear from the code either so some thoughts on this run time entropy and this run time entropy because there's lots of static information we have a few problems because we have a lot of static information we have the flags the priorities of the stack will probably not vary between boot cycles and that's why we have very predictable systems and the only real randomness is time or program state one of the big problems is that it really puts the burden on the developer because the developer has to select which interrupts to draw the entropy from so that means that they have to decide how these interrupt timing sources are not triggered too periodically etc but there's a real matter which is almost all Q and X-rays there is no reset control they actually interrupt the binary and they actually call them which means that run time entropy is accumulated but never actually makes back interest time entropy pool and you can find Q and X people of a Q and X and then this is very dangerous especially if you consider the quality of the boot time entropy in the latest version Q and X 6.6 this is an attempt to create some kind of Q and X 6.6 initialization output. So whenever the PRNG output is received from part of the pool. But an issue is that no entropy estimation is actually done. And this is what Seattle, what is the design to do to do entropy estimation on entropy pools. So you only receive a proper entropy quality in these pools. This isn't what we're up to. Luckily we disclosed some of these issues to BlackBerry. Luckily we were able to give a few of these problems to BlackBerry and they have a new Fortuna-based Pseudorandom Number Generator. And it will now follow Yaro. And there are patches for QNX 6.6 that will be published in January. So this brings us to the next operating system, which we can't mention because it was the next operating system that we were able to continue. And this is a POSIX-compliant RTOS operating system, which will be used in the ISS. It will be used as a random number generator available via DevUrandom interface. And as you can see it comes from Urandom read, which fills a buffer with n from its random function. Urandom read and it fills a buffer with a write. And it feeds these outputs back into the entropy pool. So it's also very predictable. And the underlying function shows that it's a BSD random number generator, but it's not custom constant. And that's not the way it's written out because we also discovered a local re-seated deck because the DevUrandom device is writeable, which means that anyone on the system can force a PRNG re-seat regardless of their privileges. So every random world writeable, so every single write-to-see, to the random number generator and all across the board control the PRNG output. So, yeah, that's it. But even if that wasn't enough, and we also discovered a known seed attack because if you reverse it, you see that there's no seeding at all. It's just a static 32-bit seed, which is the same across all these operating systems that are deploying. So it's just the same point over and over again, and that's why I'm talking to you in the system at all. So an attacker who knows the PRNG seed also knows the BSD or deterministic functions. They also know all of our corresponding PRNG output consumed by critical application. So you can see in the slide here that all of the other numbers can be simply dropped from the same output we saw earlier produced by this known seed. So it's here over and over again, the local attacker who has a public key generated on this target operating system, and they know the animation here in G-seed. They simply go under an open generator, see the appropriate state offset, read the number here, generate the corresponding key, and the state offset is also right in the batches. And even though it iterates to the next state offset, because the state offset is determined by how many bytes have been read from the DAPI random device, this is bounded by your family being a root force upper bound because I don't think more than four gigabytes will have been read from the random number generator before generating your keys. So we can now assume that we don't have four gigabytes before our generation and our key will be generated, and that's why it's still a root force. We have a screenshot here, and that's basically our attack, and we showed that it's feasible. Yeah, and the funny thing is that I don't think even they are going to patch it. The last case study is VxWorks 6.9, and the initial release is in 1987, and quite a lot of high-tech equipment is used as a root force. And VxWorks deepens no cyber secure random number generator. And well, it will help predict the consequences too, and search in the internet for the developers for asking questions about this stuff, what makes VxWorks 6.9 that somebody comes and says, hey, I implemented, I used the RAN function as the seeding source for, I don't know, the commentator on the internet said that it's not secure, it shouldn't be for the secure network. Well, and if you are thinking that these three operating systems are the first two which have problems and have a lot about it, is that the voice actually is not. Actually, in the embedded OSes and real-time running systems, the actual majority of them do not sell any secure random number generator. And VxWorks is far from the owner one with these problems, but VxWorks is one of the biggest ones, and you expect that they provide something which they don't. Yeah, so what are the takeaways from this talk? The embedded world is very harsh, and it's hard to deal with the operating systems that seek deployment, and there are many constraints that you have to deal with in this design, and that limits the source of entropy quite a bit. The developers, because they will screw up, they simply don't care about the developers, because they won't be able to do that, and more scrutiny is required, because the advice just used definitely that it should not land the developer into trouble, as it needs operating systems. And too much of the embedded secure in the world is much more trained, so we need more offensive research and training systems that have been almost up to speed with the general purpose world. So if you're looking for more technical details on embedded security, recommend or talk about general purpose world in 2017, and if you've got any questions, you can ask them now. Okay, thanks a lot first. For questions and answers, please use the microphones. Just line up behind the microphones, and I'll pick you for your questions. So this is not a question, this is a nice story that might be replicated. Please, only questions at the moment would be really relevant. No, this is about randomness. Okay, it's now about a funny question, a funny story that I heard. I talked to an engineer from Bristol, and he told me the following story, because they had so much bandwidth on the internet, and they were saying, well, let's see what happened if you send a random bit stream to Dev Zero in foreign country. It lasts for two weeks for the G-Series to knock on their door and ask them what the heck they are doing there, and the random number generator they used was a noise diode. Okay, thank you. A question from the internet is a radio noise from a software-defined radio, a good source of entropy for a random number generator. I'm sorry, can you be the question now? Is radio noise that you get from software-defined radio chip? Would that be a good source of entropy? I mean, I guess it depends on your threat model, because is it possible that the attacker controls radio signals around the device that draws so many from the R&D chip? Yeah, I mean, if you can control a specific frequency, then, well, it's not. It's really good, but it really depends on your threat model. Is it a remote attacker you're dealing with on the attacker of physical access, et cetera, et cetera? One of the slides you mentioned, both are to the microphone, please. One of the slides you mentioned on boot low-entropy attacks, and do you have any best practice accommodations for different, because on Linux, there are random blocks. On Linux, there are random block, unless it hasn't been seeded yet, and OpenBSD seats it in the boot loader stage, even before even the kind of last one. And now, application developers are opposed to know every operating system? Well, the problem with the blocking thing is, and this came up in communication with BlackBerry as well, is that if you say, I only provide randomness when I have sufficient information, and I'm sure this is high quality, this is not as easy to do in the embedded world, because that means that, for example, if you need some source of secure randomness very good, you don't have enough entity, but boot don't get really slow, and especially if you have devices on a real-time constraint, this is an engineering hurdle right there. So, I see your, the paper was published, I think, at Security and Privacy 2013. I think it was called something like, welcome to the public, or something like that. And there were some good best practices, recommendations for the embedded world, mainly in the form of seed files, but as we mentioned already, if you have this close notes, there are, it's kind of an open problem to design a real open source, so random number generator, yeah, all across the board. Second microphone back in the air, please. Thank you. You mentioned the NDA you have with the vendor, you have the non-disclosure agreement with a vendor, what kind of, what kind of relationship do you have with this software manufacturer, and how did it come to that you have a non-disclosure agreement? As an answer, I can tell you, it took one year until we got access to it. It is, to be honest, in lots of real-time operating systems, they are living in 1998. So, it's an academic approach, not a consulting assignment. Yes. Okay, thank you. Then you, please. Thanks for your talk. First question. Arm V8 relies on UFI random, for initializing kernel address randomization, layout randomization. Do you think that relying on bootloader is better for operating system than trying to solve random problem with ugly means? I mean, don't take into their, don't take random number generating into their responsibility of their operating system, but operating system means to employ them. Yeah, I mean, I guess that depends on, well, on your design model, for example, that would require you to have a bootloader that's standardized all across the board, where you want to deploy it, for example, if there's no bootloader that's suitable for the kind of embedded system, but you do more than the way it works, and doesn't have a random number generator, then you're left without a random number generator. So, it's one of the biggest problems, and that's where the only bunch of hard-to-much systems is that in the general purpose world, you can make some assumptions about hardware roughly looks like this, roughly as it's capable of this software, the computers that can be used in the embedded world are so much diversity that it's probably better to, also really include functionality all across the software standard in case, than to simply single or simply shoot the bootloader and the bootloader is out of the bootloader. Okay, thanks. Another idea. Can we rely on the manufacturer which makes a small device without random number sources to feed the device by random input during the manufacturing? I mean, attach the device before selling it to some random expensive random number generator, get the random input and then go. Yeah, it's one of the things I mentioned, that's essentially a seed file, and it seems like I mentioned in slides, if you include a seed file, which firmware image you use, random per firmware image, then that might be a workaround, but that depends on how well the vendor understands what they're doing, because in case, in point, would be the Western digital self-encryption drives, where they actually generated these based on their, let's see, RAND function. So, it could be a solution, but yeah, that depends on the vendor, whether they do it well. Thanks, you. Thank you. Okay, we have time for one short last question. Okay, you have three pretty bad examples here. You have a broader field, a broader view of the field. Are there, is it a general problem that they are probably there, or did you just pick the reworked one and stumbled upon? Are there some operating systems that do it right, and whatever the right might be for this? No, actually, these are the best. Okay, thank you very much. A warm round of applause for them again, please.