 The final talk today is another slight experiment in the Euro-BSD algorithms concept. Stephen didn't submit this paper, we pulled it out of there. He's an invited speaker, Robert Watson to do it. This would be a really interesting topic, somewhat offbeat compared to all this BSD is the best thing and BSD is the second best thing and all this stuff. Here we go. Stephen's playing with computers and tech apps. I think it's really cool. Thanks for staying around everyone. Here's a coffee light on my top. We're talking about clock scoops. So I'll introduce some definitions of what I precisely mean by clock scoops. Show how this is linked to the temperature this will become clear later on and also how to measure clock scoops remotely. Then show how this technique can be used to attack the power and the maintaining work. And finally I'll discuss some current work on improving this technique and also some alternative applications. One of the general lessons of this talk is actually the background of academia and sometimes if you read academic paper it will be like I did A, then I did B, then I did C and then I made this amazing discovery. I have my Nobel Prize for things. Actually this is not how science works. It's a lot more messy about this. So as this talk created, I'll discuss how I actually got to the stage of finding the results that I wanted as if that is what I meant to do in the first place. Here's what I mean by clocks. I don't mean what clocks, although that's one example. I'm talking about a very general concept of just something that counts, something to do with time. These are constructed out of both hardware and software components. There's an oscillator. This is driven by a crystal. So I'm looking something like that. There will probably be three up over in your average computer. And then this is connected up to a counter. Sometimes this will be hardware, sometimes it will be software. Sometimes it will be implemented in the processor. That's the adventure about here. Or sometimes it will be a dedicated chip that counts every tick that comes off this oscillator. And as a good example, I'll mention the 3DSD. They have something called tick counter. It's a little variable called tick. It runs at h, then it's clock speed. There's a very similar concept in Linux called the Jiffy Timer. And this is incremented to each time there's a timer interrupt. This plugs into the system clock. This is the one that will be seen to most user space programs. You get at this by doing get time of day. And one that I'm not really going to talk about is the BIOS clock. This is the one that runs even when your computer's off. Sometimes this is a dedicated chip. If you have a older EC, you might see a Dallas chip that's got an alarm clock on it. That's the real time clock. And more modern computers like what I'm taking photos of, this is in the South Bridge. For the BIOS system of this clock, I'm interested in looking to connect with clocks to remotely. There's a very large number of ways to do this. But a few important ones are the ICMB timestamp request. This is where you can send an ICMB packet to a computer. If it hasn't been disabled, it will respond with the current time according to the get time of day system call at a millisecond position. So that's running at 1 kHz. This advantage of this is it's disabled by default on a lot of systems because it's not that useful nowadays at a potential security risk. And also in a lot of firewalls, ICMP will be completely locked or there will just be some quite listed packets that are permitted. Another one, which is actually only applicable to Linux or... It's not applicable to ASD or previous E, which I looked at. It is applicable to Linux. This is not normally considered a timestamp, but it works like one. This is because in Linux, when you're generating a TCP initial sequence number, you take source port, destination port, source IP address, destination IP address, actually all together and then add on a 1 mHz counter. So that if an initial sequence number is generated for that same post and port tube later on, there's not going to be a collision. So this is from an RSE by Steve Bellman. OpenBSD uses almost a completely random initial sequence number. FreeBSD uses something that's inspired by the Bellman scheme for generating sequence numbers, but it's not together the same and it's not good for getting a timestamp out of the host. So the most general technique that I'm going to talk about and this is where all my results are from, is the TCP timestamp. This is an option in TCP packets. It should not be confused with the IP timestamp option. In TCP timestamps, the host generates a timestamp. It's up to it how fast it is in practice you see between 2 Hz and 1 kHz. It sticks this into every packet that goes out. The response to that packet will include that timestamp so that allows a host to estimate the ground strip time. Another advantage of this is to generate sequence number wraparound on great fast networks. Because sequence number is 30 to this and that can wrap around and the TCP timestamp allows you to tell the difference between 2 packets with the same sequence number. So that's how you collect timestamps, but now you've got them. What can you actually do about them? I am going to have to choose a lot of technology. The offset is the difference between 2 clocks. So the offset between this clock and that clock on the wall is when you subtract the 2 times. If they were perfectly synchronised that would be 0. If they were off by some constant then the difference to offset between 2 clocks would stay the same. But if this one is running faster than that one then the offset will change over time. And this is what this graph shows. Each of these lines is a different computer and each of these dots which you can barely see is a sample of me asking for a timestamp from that machine. And as you can see this host drifts down here this host which is over a chance of landing length the green one is more or less static and then there's another 3 or 4 machines that are going off in a different direction. This is interesting because a single computer will have a fairly constant skew. Skew is the rate of change on the offset. So it means you can, by measuring the skew of another computer, you can get a fair amount of information about that computer's identity. There was a paper from Yoshi Kono from Kaida and Keist. Yoshi Kono is at the University of Washington and Keisty Clampy from Kaida measured this for a large collection of computers and they found that even if you have the same model of computer the clock skews will vary significantly across them up to 50 parts per million. But on one machine it will work very well over the day by one or two parts per million. A few applications of this fingerprinting technique one is that you can identify a machine if it moves ISP it changes IP address it's still going to have the same clock speed. Even if they change physical location and you've got no idea which ISP it was when you see it again you will be able to roughly guess if it's the same computer. Similarly if you have network traces it's common for measurement techniques you'll get a non-managed traces of information being sent across them to net. They'll take off IP addresses but if you can find out the clock skew based on the TCP timestamp then you'll be able to find out if you've seen this computer before. Another very neat experiment that Kono has added was Nuckeits, virtual machines like the one generated by Honey. HoneyD generates a very large number of machines so someone who's trying to attack that virtual network will think there's lots of machines and this is a big company and it's all worth by attacking. In fact if you measure the clock skew of all these machines it turns out to be the same because they're all sitting on the same physical machine and in fact HoneyD has now been updated in order to generate a random clock skew for all the different virtual machines. Another trick is if you have a net everything coming into that net will have the same IP address but by looking at how many distinct clock skew the clock skew measurements there are you can identify how many machines that are behind that and one sort of a site almost that the paper mentioned was the clock skew changes over time I mentioned one or two parts per million and one of the potential reasons of this is temperature but the paper didn't really go into much more detail about that and that's where I came in and to do a little bit a little bit more work on that. So I mentioned that science isn't about anything I didn't think about the temperature initially at all I guess. Is there a question on that? Because you said that you can count the number of machine on the net and you only get like 5-6 bits of information about that. Yeah. I mean it's not possible to count more than what I said earlier also. On average yes but in pathological cases where machines diverge far more than you'd expect just by running then you're really able to count more. Another measurement of the 5-6 bits is for machines which were absolutely identical hardware where you have machines with different operating systems and different hardware then diverging more than that. The way I came into this was not thinking about temperature it was a good idea or even coming close to that I wanted to collect better measurements than what the original was on the actual picture you mentioned a bit. I saw that they used TCP time stamps which at best run at one kilograms but I noticed because of their entirely unrelated paper that TCP initial sequence numbers on Linux have one megahertz counter so that's a factor of sense and difference so I thought using this faster counter I could do better and I tried to do that and the results were just weird I was expecting that I'd start off with noise about that weight and then jump about that weight actually I got an entirely crazy graph of two peaks and I puzzled for a while why this was actually happening and then looked into a bit more detail and at two o'clock in the morning the clocks could change anyone guess fine? Time flow it was Tron Tron woke up and updated the Acebook 8 database that spun up the hard disk and that warmed up the computer and that was enough and decided to investigate exactly what that is so this graph shows how the clock speed and the graph's y axis change the temperature and the scale goes from minus 50 to 100 degrees celsius that's the specifications for the clock trust me while I look at that and it changes and it changes between minus 20 and plus 20 that's quite a lot but on the hand I go from minus 50 to 100 if you want them to keep on working so this is the same graph it's zoomed in to where a normal PC will sit and I measure that when I'm sitting in my office going from no load down here up to high load this isn't the CPU temperature this is the case temperature because it's a clock crystal it's not sitting on the CPU it's somewhere in the corner and now the clock speed changes far less when I measure that it's less than one but on different dimensions of the crystal it doesn't sound very much but it's major so here's the same graph again these are several different computers that I measure the offset for and as you can see this is the same version but these look very close to straight lines and the clock speed is changing you wouldn't be straight lines so you have to do something a little bit more clever first of all you take lots and lots of data and then you take those lines that are up there and then you shift all the points down by subtracting the linear component of the offset and now you get a graph like this the scale is far less so in this previous graph it's minus 20 and over a few minutes on this graph it's only going to minus 2 and this is about 24 and there's a lot more data in here and you can see it's also very noisy this noise is a problem so we want to remove it somehow and the obvious thing to do which is also the right thing to do is just draw a line over the top so that's what I did and this is the denoise version of the offset but I don't want the offset I want the skew that's the slope of this set each of these line segments and overtime, in other words differentiation sorry and now you have a graph like this so you can see that the skew is gradually going up over here and then the skew drops and then it starts letting up if you remember the clock skew changes in the opposite direction to the temperature and that's why I've actually flipped this axis so this is high skew and this is the most skew and if we compare this to the temperature you can see it's actually a pretty good match as on the site I find the temperature was changing at about 8 o'clock in the morning and it certainly wasn't because I was in my office it turned out to be a fuck in the building temperature controller it's far too smart for a zone route what it does overnight this was in the summer overnight it looks at how fast the building is cooling but what it doesn't look at is whether any windows are open so in summer people leave the windows open the building controller sees that because the windows are open they're cooling very fast so then around 8 o'clock in the morning the panics and things they're always going to be really cold if the sun doesn't come off and then it turns on the heating so it turns on the heating and then the sun comes up and it starts panicking so it's probably too hot and it turns on the heating so being a security researcher is a bit of a strange occupation once you've done something in the years you're like what can I break now and I've been working on TOR for a while to break projects they actually hired me recently but I like breaking TOR I've written a few papers on this and I thought I can do it again so for those of you who don't know about TOR it's an anonymisation service if you want to browse a website and you don't want to interact you can use TOR to do this so here is me looking at Google and this all happens in Europe it turns out that I actually come out in Denmark yes I can do a few other neat things one is that it can have post hidden websites so-called hidden services I'm going to talk about those later but actually most people use it for this anonymous web browsing facility and also get TOR it works by taking your data encrypting it under multiple layers and then sending it through a set of volunteer TOR nodes there's around about a thousand nodes now each of these nodes will take one layer off, look where the data is meant to be sent to next and pass it on and that means that the data coming into each TOR node looks different from the data coming out what it doesn't do is introduce any delay for those of you who don't know about the anonymous media and premiums they delay a message if you did that for web browsing TOR is already pretty slow so it doesn't introduce any delay and it makes it vulnerable to a certain type of attack so I've mentioned about hidden services I'll give a brief overview about how these work the details are entirely important but maybe I'll address there are three stages to that the hidden service up here was the publisher website they connect to TOR nodes they chosen a random called the introduction point and makes a permanent connection to there and it sends that over two other TOR nodes so the introduction point doesn't know the real idea of this hidden server the hidden server then sends the address of the introduction point to the directory server these are three or so producers run by the operators of the TOR network now time passes and the client wants to access this hidden service it connects to the directory server and asks what is the introduction point for this hidden service and it gets this back then the client connects to a node called the roundy viewpoint this time the client chooses it over two TOR nodes and makes a permanent connection to that and then the client sends to the introduction point same one over here the address of the roundy viewpoint and that gets passed on to the hidden server in the final stage the hidden service connects to the roundy viewpoint makes a connection there and the roundy viewpoint is still connected to the client and they can now send data back and forth after all this the client doesn't know where the hidden service is and also the hidden service doesn't know where the client is that's exactly what you want from hidden servers and hidden servers are used for real data one of the more high profile cases was there was a drug called plexia and employee probably of the company who produces that drug released some documents which said that it had much worse side effects than the company was disclosing and those documents had been pretty much removed from the internet by the lawyers acting on behalf of the company who produced this but they're still available on torian services so someone's using this to protect them from at very least a very serious court case so it's important to understand exactly how well tor works and personally be able to know if there are any weaknesses how serious they are and if at all possible fix them so one attack on tor is by lasso over there from norway and Paul cybersome from usd research labs and the goal of this attack is to de-anonymise hidden service I mentioned before the connection set on this is the last stage and the interesting thing is this node over here is around the chosen part of node is the idea of this of this hidden service it doesn't know at this point that it's being connected to the hidden service and it doesn't know what is the pseudonym of this hidden service that the current one is but I mentioned before it doesn't introduce any delay in the data sense so the client wants to find out the new idea of this server can send lots of data and stop for a little while send lots of data and then stop for instance this node is controlled by a malicious client it will see the same pattern and then it will know that the pseudonym that the client is talking to it matches the idea of this of the hidden service there's 1000 tor nodes so there's only 1000 chance roughly that the hidden tor node will be on here but what a client can do is just keep on connecting until it sees the correct hidden service and this works surprisingly well within 15 minutes or so you can de-anonymize the tor hidden service so Paul and Lassa came up with a fix against this which is rather than this node which is the critical one here being chosen at random it's chosen at random once and then it's fixed for the life of that node which means that if the client starts meeting lots of connections this one will stay the same so if the hidden service is unlucky and it so happens the first one you chose so go card node is malicious then it's lost but otherwise it should be safe I have a question? Yes How does the the match one who knows that it is talking to the server and not another server? Every tor server is registered in the tor directory so that means that the last node you can see if the hidden server is also a tor node if it is then maybe it just happens to be one of these other two and if it's not it's probably the hidden service but even if the hidden service is also a tor node which is better in some cases for security although it's actually worse then you can just keep on trying and two of the tor nodes will change at random and then one node will stay the same and that's the hidden service so you might have to do multiple times but eventually it will work in that previous attack I assumed that the attacker can snoop on the network it can become part of the network in case it's work that's true because anyone can join but what happens if it can't let's assume that the attacker is entirely external to the network it can use it it can send data through it but it can't actually introduce any nodes of its own then this scenario is that we have a two web server and then the victim is looking at web page on that web server the web server wants to find out if the client is and the client doesn't want to leak its identity to the web server what the attacker can do is send in a funny pattern send lots of data for a few minutes and then stop and do this over and over and then the attacker has another user which simultaneously probes the latency of all the tor nodes in the network there's only a thousand or so if you want to botnet then that's quite easy and for this tor node it will get another funny pattern back and it's not the same so it knows that this one of the stream going to the client is not going to this tor node but if it codes this one when the data that it's looking for is going through then it will get the same pattern back and eventually over time you can track whether a given connection is going through a tor node without even being part of the network all you have to do is get it or maybe you can use tor to send data over it and watch how much the data comes back and that's the theory but we actually had to try it and here's one graph on the top whenever there's a gray bar I'm sending some data I'm being the victim of the e-webs however in this case so here I'm sending lots of data then I stop for a few minutes send data then I stop and the simple thing is that I measure the latency going through all the tor nodes and this tor node is the latency and as you can see when I send data to the tor node its latency jumps a lot and this one is quite blatant there are other nodes that we look at which then have quite as good a correlation but over enough time you can discover whether data is being sent to the tor node you're interested in so this tag is pretty bad it doesn't tell you who the client is but it does tell you the path that the client took to the e-webs server so it released and prevented and this seems like a typical quality of service problem the tor node servers so busy servicing one request that it's delaying all other ones so you can use a quality of service feature in order to prevent the attack that is that you set a rule that no stream going through a node can affect any other stream this could be implemented by a tor node generating a fixed number of streams that is able to handle and breaching nodes have a maximum data rate and accept no more traffic than that maximum this also means that when one stream that is allocated one circuit is using less of this bandwidth than the capacity allocated the server can give that to any other stream because they now give a measurable signature so it just has to sit there and do nothing when it's doing nothing it's not going to do as much encryption and then it will cool down and then it's temperature the temperature will decrease and then this clock screw will change so that's the theory but I want to actually try that and it works basically here's the graph same graph, probably the same graph as before I'll go through it one of these dots is one measurement of offset and you can see there's lots of noise here then I've got a green line over the top of it to get rid of the noise and then the blue line is differentiating that green line and when I'm sending data to the core node the blue line gets high and then when I stop it goes down and this correlates very well with the temperature for the purpose of the experiment and see this although realistically an attacker wouldn't be able to do that I've just given one example of how you can use temperature as a forward channel for an attack but it's a communication channel that can be used for random inter-process communication in some systems there's a rule that two computers two processes on that computer are not permitted to communicate say for example when the top secret program is processing satellite photos and then the other one is the payroll application where it's got lots of bugs and some key information to the internet if those are running on the same computer you want to make sure that no information can leak from the satellite photo program down to the payroll program one way of beating a measure like this if you close off all standards communication channels or the high level process to send them in some unconventional way back even in the 1970s it was realised that if you use up lots of CPU in one type on one process then other processes are going to be started so to send a one the top secret program can use up lots of CPU time and then the payroll application will recognise that it's getting very little if it wants to send a zero the top secret application will run for a third time and then the payroll application sees that it speeds up consequently there's a defence against this where you allocate every process think for a time slot and you don't allocate that to any other process even if that process isn't using it this reduces efficiency but it eliminates that over a channel but this is similar to the case I just described when that time slice has not been used by anyone and the CPU will go down another program to detect it it uses time source to act as a reference clock and this could be something like ATV or if it can't get access to network it can just compare its own measurement of time to another clock crystal in the machine it mentions that a PC might have up to half a dozen clock crystals one is on the SIM card it can just compare its own percentage from the time to the SIM card and it should know the temperature of change another case is crossing air gap security boundaries air gap security boundaries are supposed to be basically impenetrable you don't want two computers to communicate you put them in separate points in the rack but heat rises if one computer runs up then the one above it is going to do a change of temperature as well and we've had confirmation from another person that he can cause a three degree temperature difference by warming up the computer below it in the case of a blade server you are going to do even better because then you've got a very tight couple between each of the blades to confirm this I would set a blade server so instead I took this one up here and put it inside of my PC case and then turned it on and off to our favorites and you can see that I'm getting a corresponding oscillation in temperature and also I'm going to take this using clock scoop I hope just pretty sure I'm trying to make it better as well and another attack against Tor is if you take over enough of the Tor network, again it's only a thousand Tor nodes that's timing then there's a good chance that one of your servers will be both the first and the last clock on the Tor connection then you do the same trick as before you correlate the amount of traffic coming in with the amount of traffic going out and then you know who's going to where so this attack has been known since the beginnings of the onion routing project packet in the department of defence so when 30 Tor nodes came up all on the same two slash six teams started getting nervous then there's a tracer to them and found it on Washington near FDI and then people were really nervous and also how many people can get two slash 16s yes some places have two slash 16s but your average ISP doesn't so a lot of people started investigating them and I knew about this temperature coerce handle thing so I applied here and these are six measurements I got from the 30 Tor nodes and I can learn two things from this firstly there's the constant screw between all of these machines so I mentioned that in the Kono et al attack machines can divert 15 parts per minute in the cases of these six computers they were all the same and also you can see that they're changing in the same pattern of equations they're roughly the same environment so basically these graphs you can guess that they are the same machine and almost certainly they were another way to do this was I tried SSH into them and being very wise they blocked SSH from both blocks and these are Tor nodes so you make a path to the Tor network from the node to itself and then it's by the parallel and then you can log in and then try to get a password probably illegal but I didn't get the host key and it was the same for actually there are two host keys we can guess that there are probably only two computers here and there are not virtual machines because they're all the same the same host key just one machine was not to write the addresses and then Tor is bound to each of my addresses so we got more thinking and found out actually it was rather nice and in turn it wasn't the Stoogs it was just someone who thought that he really liked Tor and one Tor would be good so 30 Tor nodes would be great but he was causing a problem so this problem is now being fixed and the person doing many nodes has to be not to say who he was sorry sorry he's one of the types of people who isn't a Spook who does have large numbers of signs but I hate messes so there's a lot of fat on the other end yeah but there's lots of people in universities in places like that get to the door so this is pretty crazy but we can actually go a bit further and I just want to note that for any of you who come from warmer places temperature changes depending on where you are on the earth and also changes over the day other than the fact that it's realized by a building controller in my lab so based on the temperature and which is likely to clock-shoot the dimensions are when sunrise was on that place there and also the length of day changes depending on your latitude so based on the temperature the length of the day and when the midday or sunrise actually occurs you can roughly guess for something I haven't tried this but let's do the source codes on the webpage an obvious problem with these types of attacks is what happens if the server is running NTP in practice this isn't much of a problem firstly, NTP changes clock very slowly if it starts to change it very fast then as soon as one NTP packet is being delayed then it will jump dramatically although over time NTP will destroy any absolute screw between computers which will defeat the fingerprinting attack when the temperature changes it will change fast it can often change faster then NTP can adjust it this introduces some problems when you're trying to measure it by the fact you can bypass any of these problems by just using a different type of clock so while ICFP timestamps are under links adjusted by NTP TCP sequence numbers aren't and that's for every reason if you have a clock, then sometimes the clock will slow or sometimes it will look faster and you'll actually need that for TCP timestamps 3DSP is pretty similar but it looks like ICP timestamps are going to be safe but TCP timestamps come from the instrument controller so aren't all TCP sequence numbers as I mentioned are randomized so not particularly helpful to estimate clock speed so if NTP doesn't help what can be done better you can block time information you can block TCP timestamps and so on and that will defeat some types of attacks but it's not going to affect things like the packet interrupt timer when a TCP connection is tested it will drop and that comes after a timer interrupt and as the timer interrupts are being adjusted by NTP then you'll be able to take that and the other thing you can do is keep on running the CPU from load no matter what happens this is pretty inefficient and also I noticed that depending on exactly what you're doing with the CPU the texture difference will change for example there's a problem called CPU burn which will cause a very big difference in the temperature but actually just doing crypto doesn't increase that as much you can install the temperature compensated crystal this is called this little temperature sensor on it and then adjust it to the clock temperature this might not be good enough because it sticks but these show one part per million accuracy and the texture introduces a smaller difference than that and can be detected if you want to go one level up you can get uncompensated crystals these have little heaters in it and try to keep that constant temperature these work better but the right expensive ones are also by power hungry I'm using a different set of slides than to present so I mentioned that there's lots of noise in these samples and here's another graph and in fact this graph is a good case here you can see there's this band noise now this comes because clocks don't have inferred precision they actually run down the time stamps so when you ask for the time you'll get a slight amount of inaccuracy the other source of noise is network jitter sometimes accuracy will be delayed but in cases like this it's quantization noise that's a big problem I'll go into a bit more detail on this the quantization noise of a sample depends on how close that sample was to a clock edge so imagine I think that my watch is a little bit too fast or too slow so I ask someone what's the time if they tell me accurately I'll be able to guess when the time stamps that out and guess the difference between my clock and their clock and then correct it but now let's suppose that I think my watch is five minutes either too slow or too fast but the person who's going to hit me isn't going to be that much help and then they will just tell me if it's before or after five o'clock now if I asked quarter an hour ago then regardless of how fast my watch is they would always give me the same answer and it would be no use to so what I should do is wait till it's almost I think it's almost exactly five o'clock and then ask them the time and then depending on whether they ask whether they think it's before or after they'll give me a different answer so to overall make sure this is the closer this is to the clock this is a sample and this is a clock tick this is the clock increasing on a time closer to the sample is to one of these lines the lower the error is going to be another graph this one is the quantization error so in the best case I can get a one tell error clock and that has a period of one millisecond in some other operating systems the GCP time stamp clock is 250 errors so in that case the end of that bar will be somewhere over here but other clocks for example the one in the HTTP time stamp is one hertz so that means any noise a few hundred meters over in that direction and that's when the noise will destroy the type of noise that I'm doing so some work that Sebastian Zander's been doing with me is trying to reduce this noise by asking the question at the right time this is just what I mentioned before if you want to ask someone the time you ask either when you think when their clock takes place to happen so if they take one error in case of someone who will tell me whether before or after an error I should ask that at that point when they're going to change their answer and we can now compare with the noise we get with these blue dots these blue dots are intentionally as close as possible to the clock takes and you can see here it's a little bit after and here it's a little bit before and this is basically what the technique that Sebastian and I worked on does the algorithm works by the it first works along the typing standards it sends out packets in sequential times until it sees a clock tick and then it goes roughly when that clock tick is it knows roughly when the next one is going to be so it tries to get before and tries to get after in the guess guess is right then it can start guessing much closer to when the clock tick is but the guess is wrong for example it sends one with when it thinks it's before and one with when it thinks it's after in terms of both reports then it whitens that error and then starts guessing again and over time it will start converging on the correct value and this is the graph which is going to get out and much more examples are extremely wrong and pretty much everything all the noise here is caused by the network and this is almost this is almost in pain of the clock frequency so even if you have a really slow clock like the one maker's 80 degree clock then you still get very good noise quality so in summary the results are a vital attack in theory it should all work but actually when you try it, it does I gave an example of when you can track Tor ahead services by warming up the server and then measuring the result by the clock skew and also it is custom on the ways that it's possible to use Tentra core channels in situations like multi-level even crossing ERC security boundaries in hostly thermally coupled racks or blaze arrows I also mentioned that a more general message that is true not in the case of these examples but in other areas of our research no one thought that temperature was a security critical quantity and if you look at the system that is secure in the astring designers were thinking of introducing more to that abstraction you start to find additional attacks so even if you have a system that you think is secure start thinking a common phrase think of weird things that someone might actually try it probably won't work but maybe it will and it may turn out that the system is not as good as you might have thought how long does it actually take to say fingerprint a machine so if you're just trying to figure between the number of candidates it can be tens of minutes in the case of temperature it's closer to overnight because although we can get very clever techniques where we're moving the noise actually the smaller amount of time that you run the experiment the smaller difference in absolute difference between two clocks and they were just the start of the problem at all so we realized there would be errors in your attempt to reduce the measurement noise you realize that you could actually use DSP technologies to do that because if the radical quantization error is a grant function and you have a number of samples of that which corresponds to an over sector so if you fill in the blanks with non-measurements you actually get the base frequency at a very high position and you get the faithful image and you do that with very few samples yes, but you still need to sample out the right points then you'll know where the right points are yes so the nice thing to be when you add it is it may actually be the same it may be the same as what you're restraining because it's a POL it's a low loop so the last thing we've been doing most of the work in this I suggest the idea of a while while we're just a little bit I say one of my papers and then he's been working on some fairly advanced control algorithms for me as well hopefully you'll be able to score them online soon as well have you tried to play with the Blitz kernels to see if you were able to see your measurements no, I haven't that would be interesting but what do you really look to properly you can see it's pretty much the same but the Teclos kernels will be very interesting well you've made these Teclos kernels some much better well what I think on your comments on your content comment on why you said it was proper to use the top green one above your red dots yeah so in the case of this graph if the temperature wasn't changing you would have a smooth line at both the top and the bottom but when you start measuring over a large length then you start having a network jitter and the reason you choose the top length is because in the top length the network jitter is zero up here there's actually loads of points off here so there isn't a clean bottom line but there isn't a clean top line I don't have a clutch in mind as you have a clutch a variable clutch yes, you can't get a latency less than zero and that's why you have a clean top line but latency if you want the seconds when you're going across some money resource think outside the box