 All right, so the next speaker, the next paper is about evaluating and monitoring free running oscillators and this is joint work with Ellie Alini, Matt Chiet, Skorci, Skorski, Otto Pettura, Florian Bernhardt, Mark Laban and Victor Fischer, and Otto will give the talk. Thank you. So Let me jump right in and start with some core concepts and motivation. Well, the jitter clock, the jittery clock is a commonly used source of randomness in digital devices can be caused by several noise sources among which white noise is by far the best because it is not manipulable. Then there are autocorrelated noises which introduce dependencies to output numbers and so they make entropy rate difficult to estimate and lastly there are data dependent noises which are dangerous because obviously they depend on the data process, so they shall never be used to generate random numbers from and it seems easy and clear on the paper, but all these noises are actually affecting the jittery clock at the same time. In order to produce quality random numbers, we need to monitor jitter continuously to verify its properties and usually we use variants for that. There is a common assumption that the quality of the jitter depends and the properties of the jitter depend on the type of the oscillator used and we actually decided to test this assumption by comparing two commonly used oscillators and those are the ring oscillators and self-timed rings. Also, the quality of the generated random numbers depends on the randomness extraction method used and there are quite a few among which the most the most commonly used is the jittery clock sampling which uses one oscillator to generate the reference clock which is used to sample the jittery clock generated by the second oscillator. Another method which is less common but much more efficient is to count the jittery clock periods and here the reference oscillator is used to generate the counting period during which we count the rising edges of the jittery clock. Our objectives here just to summarize them to analyze the use of variants for entropy estimation. Use high-order Markov model to estimate entropy coming from auto-correlated noises and compare performance of ring oscillators and STRs as source of randomness. So the entropy at the output of the generator depends on the variance of jitter and this variance can be computed from power spectral density of the random fluctuations affecting the clock frequency. So how does it actually work, the variance can be computed from the power spectral density by integrating actually the power spectral density multiplied by the Fourier image of the variance operator. Which for statistical variance, which is more the most commonly used looks like this. And the statistical variance has one big disadvantage and that is that for low frequency noises such as flicker noise this integral does not converge and so consequently the statistical variance causes entropy overestimation. Luckily for us there are other types of variance such as Allen variance which is actually computed from the first order differences of values and this variance is ensured to converge even for low frequency noises and so it is accurate even when these low frequency noises are affecting the signal. Now since the variance and all other statistical measures are accurate only when computed from infinite data set, which we cannot do in reality we need to compute them from the from limited set of data where we use only m-samples and the statistical variance tends to diverge when changing this value which is not the case for Allen variance. So as seen here in experimental results actually Allen variance stays stable regardless of the number of samples used to compute it and also here on the right side we can see that based on the jitter accumulation period k, which corresponds to number of reference clock periods used to generate one sample Allen variance stays always below the statistical one So the statistical variance we can see here really overestimates the on the jitter. Here it is important to note that our intention is to use the lowest accumulation time period possible to reduce the impact of low frequency noises such as flicker noise but below certain value quantization noise prevails and so we need to choose a suitable compromise. Also for both oscillator types that we tested these results were very similar. So in order to monitor the jitter in real time we need to implement the variance measurement in hardware where again we can see that Allen variance is much more suitable because it is simpler to implement. For example, it does not require us to compute the mean value of samples on the fly so it reduces the requirement of this computational branch and also since it operates on first-order differences it reduces the requirements on general register size. So when compared to other implementations, implementation of Allen variance is all smaller, faster and require more power effective. So now at the beginning I said that autocorrelated noises are not not that good to generate randomness from random numbers from because they introduce dependencies to output numbers, but these dependencies can be conveniently modeled using Markov chains and recent approach actually offers an efficient way to estimate mean entropy using Markov models. So obvious application would be to try to estimate entropy coming from low frequency noises, autocorrelated noises actually. So we did that and we see here that Markov chains are actually very efficient and very accurate in detecting, in estimating the entropy, especially in high entropy cases here where neither the AIS nor the NIST standardized tests could tell the difference in the entropy rate which we can see when estimating using Markov chains. Also here on this slide we can see that counting the G3 clock periods is much more effective method of randomness extraction than sampling the G3 clock because already after 20,000 periods of reference clock we were able to accumulate enough jitter to pass all the tests where even after waiting for 100,000 periods of reference clock, we were not able to accumulate enough jitter when just sampling the clock. Now also another aspect to consider when designing a T-RNG is that the surrounding logic actually has an impact on the randomness source itself. So to be able to quantify this we decided to implement three projects on in the same device where the first project was the reference project where only the oscillators were implemented inside the device and their jitter and corresponding counter values were measured using oscilloscope. The second project contained AES cipher oscillator-based T-RNG and embedded variance measurement to mimic the behavior of the whole crypto system implemented and one of the clocks was generated using external quartz oscillator where the other one was generated inside the device and in the third project we implemented the whole crypto system again, but both clocks were generated inside the device. Here we can see that implementing the whole crypto system more than doubles the jitter of internal oscillator or internal oscillators and but basically the variance of counter values does not change when only internal oscillators are used. Which is not the case when external oscillator is used where the variance of counter values drastically changes and so also the entropy estimation based on this variance measurement will be overestimated and incorrect. On top of all that we can introduce global noise sources and we will introduce global noise sources into the generator when using external clocks and finally the comparison of the ring oscillators and the STRs. Here we conducted the autocorrelation study where we can see that autocorrelation of counter values when using external quartz oscillators combined with either of the the two internal oscillators is extremely high. This autocorrelation is reduced when using only two internal oscillators and when working on the first order differences, which is the case when we use random variance, the autocorrelation is negligible. And finally to conclude counting jittery clock periods gives higher quality random numbers which provides for higher bit rate and higher entropy rate. Counter values can be also directly used to monitor the jitter. All of our variance should be used to estimate entropy rather than the statistical variance because it is not sensitive to window size and it provides accurate estimation even when a low frequency noises are present and also it requires smaller circuitry to implement. The differential principle of the TRNG design is a stringent requirement and not a recommendation because global manipulable noises are strong and they are inevitable. They may even come from the ambient temperature in the room, which was also the case in which it was also our case. And finally, higher-order Markov chain models provide good mean entropy estimates and are efficient to detect dependencies in generated numbers so that they may be the good way to go in the future to study the randomness that's coming from autocorrelated noises. This is all from my side and let me just thank our sponsors and thanks to all of you for listening to me. So are there any questions? No questions? There is one. So maybe... There is one over there. Oh, there is one question. Okay, sorry. Yes, I didn't see. So the main source of jitter is and... Sorry, I couldn't hear you because the microphone is perhaps not working. So the mic... Put the microphone closer to you. Is this good? Yes. That's right. Okay, I'll cover my face with it. So the main source of jitter in the clock distribution network is noise in the power supply network. So did you try to characterize the noise in the power supply network like in the voltage regulator module and so on? Well, actually we tried that because when we detected this problem with... Sorry. With... Yeah, noise is affecting the generator when using external clock. We tried to find out where this noise is coming from and we tried also to characterize the noise coming from the power supply. But since the board that we were using was using linear power supplies, low-noise power supplies that wasn't coming from that. But yes, that's one of the things that actually might affect this. For example, the power supply on the board is actually affecting the board itself and not only the device. I don't know if that answered the question. That was not coming from that. In our case, the noise that was affecting the external clock and the whole generator was coming actually from the ambient temperature. We managed to correlate the behavior of ambient temperature in the room to the behavior of the noise. Okay. To see why it's not working. Okay. I was just going to ask, the 90B tests do include a predictor based on a higher-order Markov model. So I was curious if you thought about that at all. I noticed that the 90B tests were getting a lower estimate than your thing in your data. Yeah, that's... I don't know if that was right, if that's more accurate or less accurate. But I just want to point out that there is a higher-order Markov model up to 16th order, I think, in one of the predictors in 90B. I must admit that this is not my area of expertise, but I remember something like that from the discussions with other authors. And I think that the answer may lie in the order of the Markov chain, which here in our case was chosen based on the autocorrelation study that is presented in one of the last slides here. Actually, so perhaps I don't know. Maybe it's because of the Markov model that we used was more tailored to what we had. Right, so the predictor, I just noticed because it's my design, but the Markov model predictor considers Markov models with depth 1 through 16, and whichever one is giving the best predictions is the one that it uses for its estimate. So it has some flexibility. It wouldn't go higher than 16, but... I don't know if that's useful. I don't know. I would consider that, but we used 8th order and really I'm not really the right person to... I'm not qualified enough to answer that, but that's what I was told to say. Sorry. There's one more question here in the front. So my question goes in the same... John, a question. So I think if you have dependencies in such models, then you have long-term dependencies. So this... And therefore you would be good to have a very high order of the Markov model. Otherwise you cannot estimate all the state transitions. So you have a problem, you already said that's not your field of expertise. Yes, but I think that the answer would be still the same, that actually a colleague that designed this, designed it based on the study of the autocorrelation that we made. So he had some basis of what we are working with. Could you say... Sorry. Order of the autocorrelation function after smoothing. So it's 10 to the minus 3 or 4 or 5. Cannot be seen on these. The right hand... Here. Here? The upper one. This one, the upper one here? No, no, the lower one. Right? This one I don't know, but if I'm not mistaken that's actually written in the article, so I very warmly invite you to read it. Okay. Any more questions? Okay, let's thank the speaker again.