 I'm Wenjie Xiong from Yale University. I'm glad to be here to present our work on runtime accessible DRAM path in commodity devices. This is a joint work with my colleagues in TU Dumbstead. As you see from the previous two talks, physically uncomfortable functions, physical function, which embedding a physical object when queried with a challenge x, will generate a response y, which depends on the challenge x and the physical properties of the object. There are many different kinds of paths. One of them is silicon paths, which use the vibration in the fabrication process. We then pull the up type paths as run paths because it's very hard to control the manufacturing process. It's almost impossible to physically clone the path even for the manufacturer. Due to this property, path has been widely used for authentication and identification. Recently, there is the idea of intrinsic path. It does not require actual chips for path. It used the hardware, which is already onboarded anyway. For example, people use startup value of SRAM. Then we were wondering whether it is possible to exploit DRAM as path. As you see, everyday devices holds DRAM. And it would be nice if we can exploit the intrinsic DRAM to use it as a path to derive a unique fingerprint or a key for that device. A good thing of DRAM compared to the startup value of SRAM is DRAM usually have a much larger capacity than SRAM. And we can access DRAM at runtime while the SRAM path can be only accessed as startup time. As you can see on the right, there are two experiment platforms we use, the panel board and Intel Galileo. They all hold DRAM much larger than SRAM. So we want to have an intrinsic DRAM path. In our work, we are able to extract decay-based DRAM path from our modified commodity devices at the Linux system runtime, which means we get a device and we can use it as DRAM path. We are not using FPGA, and we don't need to modify the hardware. And based on our experiment from the DRAM path, we introduced new metrics based on the J card index. And through that, we show that DRAM path has robustness, uniqueness, and reliability. Based on this, we introduced new protocols for device authentication and secure channel establishment using the time-dependent decay of DRAM. As you can see, this is a DRAM array, and the DRAM cells are organized in rows and columns. Each DRAM cell consists of a capacitor and a transistor, as you know. And bits is stored as charge on the capacitor. When we want to access DRAM cells, the corresponding water line given by the address is first enabled and the transistor conduct. Then the charge on the capacitor can go to the vertical bit line here. Then the sensitive amplifier can amplify the signal on the bit line and recharge the capacitor or read out the data or write the data back to the capacitor. However, as you can see in the blue arrows here, the charge on the capacitor will leak over time. So that's why we need DRAM refresh. DRAM usually refresh every 64 million seconds. And DRAM refresh is actually successively enable each water line. And then the sensitive amplifier will recharge the capacitor, which also means when we access a water in the row, the whole row will be refreshed. But how is DRAM related to path? Due to manufacturing vibrations, some DRAM cells decay faster than others, and we exploit this as a path. This is how we access DRAM path. The challenge consists of the logical path defined by the starting address and the size, initial value and the decay time. In the beginning, we have a normal DRAM working ordinarily and then the path region defined by the address and the size is reserved, which means other part of the system cannot access the path later. And it is initialized by the initial value. At the zero or one, in our experiment, it's actually all zero. And then the DRAM refresh is disabled for this error. After that, the cells start to decay, as you can see in step three. After the decay time, T, we read out the path region, and that is the DRAM path measurement. After that, we can enable the refresh again, and the DRAM is returned to normal usage. It's a very simple idea, but it's challenge to implement this, as we need to disable the DRAM refresh when we access the DRAM path. As you see, the system is also running on the same DRAM. Over time, the data will lost and system will crash. In our experiment, after around one minute, the Linux system will crash. So then we have two approach to implement the DRAM path. First, we implement this in a firmware. Firmware is the first piece of software while earning our device. And it is not using the DRAM, it actually use the cache on chip. So we can sit late, disable the DRAM refresh, and access the path. In another approach, we implement this in a kernel module. To prevent the data used by the system lost in DRAM over time, in one scenario, we can locate the operating system in one part of DRAM, and disable the refresh for the path region, which we achieve in one of the platform, the panel board. But for Intel Galileo, we can only disable the refresh for the whole DRAM. So we use the successive selective DRAM refresh, which means we read the word of each row successfully and protect the data used by the system and other applications. Yes, this will introduce some overhead, but not so much. If we use half of the memory in Galileo for the system, it will take around 20 milliseconds to refresh that part of memory, which is around one-third of the CPU time if you use 64 milliseconds refresh period. And we find that on the room temperature, it's quite safe to use longer refresh rate. And then we can use less CPU time to do the refresh. When we are able to implement both of the approach in two platforms, the panel board, which holds a one gigabyte CDR2 memory and Intel Galileo, which holds two 128 megabytes CDR3 memory. The panel board is a computer development platform and Intel Galileo is a platform for Internet of Things devices. So using these implementations, we conduct a lot of experiment and based on that, we introduce new metrics. And I'm going to talk about how we evaluate the path measurement. In total, we measure four panel board and five Intel Galileo's. On each device, we measure two logical paths. Each logical path is 32 kilobytes. And for each logical path, we measure at five different decay times with 15 measurements each. This is a DRAM decay process. In the beginning, it is initialized. And over time, some bits flip, some they have lost. And over time, more bits start to flip. In our data, this figure shows the decay rate. The x-axis is the decay time of the DRAM measurement. The y-axis is an average decay rate for the panel board and for Galileo. We can see different devices have different decay properties. And the panel board is always decay faster than the Intel Galileo. In our data, we also find that those bits in shorter decay time will always flip for longer decay time, as you can see in this figure. This is a sample of the path measurement. Some bits flip in a range of DRAM. Well, traditionally, people think path measurements is a string of zeros and ones, a binary string. But here, it's more like a set of bits flips in the DRAM region, as you can see. So, rather than using the traditional hamming distance, we use j card index here. The j card index is usually used to evaluate the similarity of two sets. It's the cardinality of the intersection of two sets over the cardinality of the union of two sets. If the two sets are exactly the same, the j card index is one. And otherwise, it's zero. If the two sets are completely different, it's zero. We use intra-j card index and inter-j card index to evaluate robustness and uniqueness of the path. The intro is used to compile the similarity of the measurements for the same path challenge for the same logical path. Ideally, it should be close to one. And the inter-j card index is used to compare the similarity of the path measurement of different path challenge or for different logical paths. Ideally, it should be close to zero. So, we use this to compare the robustness and the uniqueness. This is our result. We have five different decay times, two kind of different device. We show the minimum intra-j card index here, which are conservative evaluation. It is quite big compared to the j-inter. Also, we show the maximum j-inter here. We also show the hamming distance here. It also shows the D-run path, half uniqueness. However, you can see the hamming distance, the number is quite small, while the j-card index can give a clear distinguish between the inter and intra. And we also say one case, the hamming distance cannot distinguish the intra and the inter case, but the j-card index can distinguish the inter and intra, which means the j-card index here is better at evaluating the D-run path. We also plot the distribution of j-inter and intra in blue and orange here for two different devices. We can see there is a clear gap between the inter and the intra, which means it has good uniqueness in D-run path. The D-run decay also depends on the ambient temperature. We conduct experiments with a heater on the top of our D-run modules for both dependent board and Intel Galileo. You might wonder why they have so different temperature dependency because they are both D-run. If you compare that with the time-dependent decay, they are related. If you take logarithm on the axis here, you will expect they have the same shape of the curve, which means the effect of the temperature is effectively speed up the D-run self-decay exponentially, which means under different temperature, if we choose a different decay time, we should observe the similar decay because we expect the temperature only accelerate the decay but not affect the order of self-decay. We also do this measurement on a different temperature and use the equivalent time and compare the j-inter. We find that the j-inter is quite close to one here on the different temperature, which means it is quite stable on the different temperature as long as we use an equivalent time. We also evaluate stability. We took measurement from the same logical path four months apart and we look at the j-card index. We find that the worst case is around 0.8, which means the measurement four months apart is quite similar to each other. So we can conclude that the path is stable over four months and we are expect it can be stable for longer time. So based on this, we propose some protocols. For authentication, we assume a passive attacker who is able to observe the network traffic. The adjusted party conduct the enrollment at a set of decay times and start the measurement at a database. In the authentication phase, the client hold the device and the server hold the database. When the client want to authenticate itself, the server send a challenge to the client. As you see the decay time and the ID here means the logical path and initial value. And the client take the measurement, send the measurement to the server, server compare the measurement with that one database. If they are similar enough, we say it's a successful authentication. The next time, if the same logical path want to do the authentication, the server choose a larger decay time. As you know, for a longer decay time, you will observe different bit flips. In this way, we are able to authenticate the client. And this protocol is very lightweight for the client side as the client only need to take the measurement and send the measurement to the server. If there exists a secure for the attractor for the DRAM path as the progress speaker told. And then a trusted party can take an enrollment and generate a set of random keys. Based on the measurement and the keys, he can generate a set of helper data. Then if they want to establish a secure channel, the server send a challenge and the helper data to a client. The client can take the measurement and they use the helper data to generate a key locally. And then both of them share the same key. And they can communicate safely. There still remains the question of how to choose the set of decay times. As you know, for two measurement on the same logical path, there are different decay time. Those bits flip in a shorter decay time will also flip in longer decay time. So if the attacker knows the measurement of progress decay time, it will also know some bits flip for longer decay time. So the security only lies in the newly flip bits for longer decay time. So we introduce a security parameter, it's known bits, which means the number of newly flip bits are showing right here. We think there should be enough newly flip bits to ensure the security. And which means knowing this measurement, the probability of an attacker successfully guess this measurement must be very, very small. You can refer to the paper for detailed calculations and go back to the device. We find that if we use the same logical path size, and if the decay time is less than six minutes, the Intel Galileo can provide seven challenges and the panel board can provide two challenges. But this is only for one logical path. There are a lot of logical paths on these devices. So in conclusion, we are able to extract a decay-based DRAM path from all modified commodity devices with two platforms and two approaches using a customer firmware and a kernel module, which we can access the DRAM path at runtime. And based on our experiment, we introduce new metrics based on Jcard index. Based on this, we show that DRAM path has robustness, uniqueness, and stability, and the decay time can act as a part of path challenge. We also show protocols for device authentication and the secure channel establishment that draw the security from DRAM path. For future work, it will be interesting to construct for the actual for the DRAM path as it's a very biased path, and we use Jcard index here, rather than having distance. It will be also interesting to better understand DRAM path characteristics, for example, on the bigger temperature range, the voltage dependency, because we now use commodity devices, it's very hard for us to only control the voltage of the DRAM module. And the readout time is kind of a jaw-back of the DRAM path. It's in the order of minutes. Actually, it depends on the use case, and we are trying to improve the readout time as well. So, thanks for our funding source, and thanks everyone supporting this work. Thank you for your attention. I will take questions. Thank you.