 OK, let's get started. This is the last topic of this year. And actually, thank you so much for all of you for staying there to join my talk. And being the last topic, actually, is not bad, because many studies show that people tend to operate, tend to remember what came first and what came last. So I would hope you enjoyed. OK. My name is Bing. And my first name is Bing. It is easy to memorize, because Microsoft, Structure Engine has the same name with me. I don't know why they use this name. And I have been working for Intel for 10 years. And now I'm part of Android Security. And today my topic is about Android Security's storage and how to virtualize it in one of our projects, which is based on automotive hypervisor. And we have a lot of contributors for this, because this is a complicated project. And actually, one of the guys, actually, Thomas Winkler. Can you raise your hand or stand up? OK. He actually is an expert for the RPNB. I'll talk about later on what is RPNB. He's the MMC RPNB expert. I believe he's the first one to try to upstream RPNB kernel driver to the Linux kernel. So I'm going to skip this. So this is our agenda today. And first of all, I'm going to talk a little bit about the problem statement and explain why we need to build a secure storage for Android. And then I'm going to talk some more details on RPNB. RPNB is a replay protected memory block. And this is the fundamental knowledge to understand how to build a secure storage in Android system. And then I'm going to talk a little bit about the secure storage architecture and what it looks like. And after that, I'm going to go through the secure storage virtualization in one of our hypervisor projects for automotive product. And finally, I came to conclusions. OK, so the reason we need to secure storage is actually it's all about data security and privacy. So we have a couple of examples here to explain why we need that. Because for example, first of all, it's a screen unlock. So everybody has a phone, right? If you forget the password, you may try it again and again. But probably after you five times retry, you may need to wait maybe 10 minutes, for example. Then after 10 minutes, you can retry a password again. Then if it fails, then system may need ask you to wait for one hour or even much longer. So actually, the implementation behind this is because the time delay policy depends on the time failure counter. So we need secure storage to save that counter, which means that if someone can change that counter, then they can continue to try the password until a correct password is found, right? So this is one of the requirements for screen unlock. And there are some others which look pretty straightforward. For example, we need secure storage to save the system image version so that we can disallow attacker to downgrade the system image to old and vulnerable version, right? So the other use is we need secure storage to save the factory provision in the keybox, like for usage, the content protection, you need those keyboxes to decrypt the content key so that you can play back your movies, something like that. And also for testation, private keys. And for the device, as a fingerprint, you need secure storage to save your fingerprint image data, which is called template. This is not only about security, it's also about privacy because typically your fingerprint template data may be used to uniquely identify a person, right? So this is just a couple of reasons. And then if you are working for Android development, you will know that Android CDD, CDD is compatibility definition document. So if you want to get the GMS or get your Android phone to be certified by Google, you need to pass the minimum requirement defined by this document. And since from Android Marshmallow, this feature is introduced, so from now, from Android now, OAP, this feature actually is managed. So let's take a look at more details about the RPMB, this is replay protected memory block. So basically, let's take an EMMC as an example. So if you have an EMMC, there is a small partition which is called RPMB, and it's a special partition. And you cannot increase or decrease this size as long as this EMMC device vendor manufactures this device. So typically it's maybe only two megabyte or four megabyte, it is pretty small. But according to specification, it can be, it could be a 118 kilobytes to six kilobytes, but typically actually in our many reference board, reference platform is only four megabytes. So it is pretty small. And actually, in this picture, there's only one RPMB partition, but in the latest specification, like UFS 3.0, NVMe-based flat storage, it can support multiple RPMB partitions. So I will talk about that later, a bit later on this. So let's give you more details on this partition. Unlike other ordinary partitions, reliable accesses partition must have, must require the syndication key. And basically, if the key is not programmed to this device, any access will fail, because the error code indicates that the key is not programmed, you cannot access, you cannot really cannot write. But as long as you program this key into the device in a factory, in a safe environment, and this key cannot be changed anymore, it cannot be reprogrammed, it's invisible to any software because the hardware doesn't provide any interface allow you to change this key, or reprogram the key, or extract this key. So basically this key, so basically, after the key is programmed, then you can, if you have the key, then you can use that key to write the data. I will talk about a data example for write operation. But for read actually, even if you don't have this key, you can still read the data. But the problem is that you have no way to verify whether this data is modified, it's a replayed data. Anyway, so this also means that if you have a secret data, a key, something like that, you must not directly say those data in this partition. So you must have to encrypt it, and that encryption is responsible by fast software. So software need to encrypt data before sending the data to this partition. And apparently it can provide a replay protection. And for write access, this hardware provide a built-in monitoring counter which is used to detect the data replay protection. And for read access, because in read operation, software is responsible for verifying the data to ensure to check the data freshness. So software is responsible for generating a random number which is used to provide a replay protection. And now basically, I'm gonna give you an example of how it works for authenticated write access and how the replay protection is applied on this partition. So suppose that this block, the left side, is a EMB hardware, and it has an EMB data error which is saved the data sent by a software. And it has a built-in HMAC engine which is used to calculate data, mark value, mark its message as indication code. And it has a built-in Fuse OTP register, OTPs one-time programmed register. This register is used for software to program the key in the manufacturer, as I just talked about before. And this key can only be programmed once. And out of the program, there's no way to get it from software. And it also has a built-in Montana counter. This counter can only be increased by the controller, by the hardware, followed by each successful RP&B write access. And you cannot decrease this counter, you cannot change this counter, you cannot, I mean, you cannot reset the counter even after power cycle. So now we have a software. So the right side represents a software who may want to write some arbitrary data to this partition. Then we need to get the authentication key, right? So in the implementation, actually, we can derive this authentication key from some trusted hardware or firmware or something like that. And basically here, we assume that this software can already get this key. And this key is the same key with the key in the hardware that is provisioned into hardware. And then you have the counter. This counter, actually, the counter is readable, so you can just read this counter from hardware because this counter, actually, it's not a secret. And then you have, you need a software HMAC engine. Then if you want to write the data, then you need to prepare the data and prepare the metadata like the data size and the block address which the data will be sent to. And then you can calculate this data with the counter and then use the authentication key to calculate the MAC value. We can call this MAC message as an authentication code as a signature, right? And then we send a whole bunch of data to the hardware. Then the hardware will extract this data and the counter and recalculate the signature, which is the MAC value. And then we compare this MAC. If this calculated MAC is matched with the MAC value sent from software, then it means that the software may have the key, right? And then also need to compare the right counter to make sure the counter sent from software is exactly the same counter, which is really from building internal counter. If the counter is matched, then it means that the data is fresh. So then after these two values are matched, then the data can be right to this partition. So this is the last, actually this is last, this is last stop. The last stop is after the data is successfully right to this area, the counter here will be automatically increased by one, which uses that for the next right, you cannot use the previous data to replay a tag. For example, you replay the previous data, you recorded the previous data and send the data again, then the counter obviously will mismatch. So basically this is how the RPMB works, which is defined by the specification for this, for MMC, UFS and MME device. So next I'm going to talk about the software full stack. I mean, how to build this, the software stack for the, to enable this RPMB partition to build a secure storage solution. So basically we, actually in these two days, many people talk about how to protect Linux, how to secure Linux, but here I'm assuming that the Linux Android system is compromised, so we need to build a TE secure environment which is on the right side. So actually, if this is our ARM system, you know that the ARM trust can support the two world which the secure world and now secure world. And in X86 platform we use a virtualization technology to isolate the TE environment. And if you look, actually this is not something new. If you look at Windows, since Windows 10, Windows has a built in virtualization based security which is called VBS which uses the exact same architecture. So here we just use the virtualization to isolate the world but actually all the device, especially for the storage device, the Android Linux kernel owns the, all the native data. We don't want to let them storage here. We just use the virtualization to isolate the world. And then, and you can see that in this block the trustee TE is providing enough service in the, there are a couple of TAs here, TAs trustee application and but actually I'm not talking about all of them here. I just only focused on the secure storage TE which can provide the, as previously mentioned, we have a syndication key, right? We need, we use this secure storage to manage that syndication key and also we need to provide encryption to make sure that the data confidentiality. So this is what secure storage architecture looks like and at the right side of this secure storage TA and it can derive the RPMS syndication key and also can get the secure storage and encryption master key after each reboot and these two key must be protected in the TE solution so that Android cannot have this key. So even if Android compromises the data which is saved in the RBMB cannot be decrypted or cannot be stored. And we have a very, actually Google implemented this file system, a secure file system in this secure storage TA and we, if we wanna save the data, we use encryption key to encrypt the data and use the syndication key to sign the data then send the data over the IPC communication channel to our proxy in Android. And this proxy then can talk with, talk to RPMB over the RPM position over the RPMB driver here. The reason is that the, actually the MMC device is single head device which means that this two OS cannot talk the single device simultaneously. So we need a proxy here to send the data up. And we assume that this path is untrusted path but anyway, because we have, we can keep the storage encryption key and syndication key be secured so we can make sure the data can be protected. And as you can see that we also have extra data flow which send the data to a Linux, ordinary Linux system. I will explain why this later. And basically this secure storage can provide two different service to the TE environment system. And one, the first one is a tamper we call TP and which is a tamper proof secure storage. As you can see in this picture and all the data after encryption I mean, including both data and file system metadata and they both send, eventually send to RPMB partition. So we do this because of two good reasons. First one is we can provide much higher level secure protection because if attacker doesn't have the key then they cannot tamper this data. So this is what we call tamper proof or tamper resistant. So another reason is that this, the data saved in the RPMB can survive from factory set. Now this is pretty good for the usage. Like if you have some key of materials and you need to provision into factory then this RPMB, this service is the best for you, right? And but we have the problem here is that the sites constriction are constricted because typically the only two or four megabits it's very small, but most of the cases if you only use this for key materials as a key material storage then it should be fine because think about the TPM actually TPM just only have maybe seven or six kilowatts it's pretty, pretty small than this. And so to solve this size constricted problem we provide another service which is called a tamper detection secure storage. And as you see that this, we split the data and metadata and we send the data to the ordinary data partition in Android as the main storage, right? And but we send the file system metadata in the RPMB. So in this case we can support a large amount of data, right? And this is very useful, like it can be used to save your fingerprint template data because if you do factory recede then all the data will be gone. That's fine, right? And however we also provide actually the building file system provide the capability to detect the data, for example if the data is altered, if data is replayed then we can detect the data is changed. So this is what we call the tamper detection or sometimes we call tamper evidence secure storage. So we have already talked about the, we call it the native environment and but now we, I'm going to talk about the secure storage virtualization around our, one of our project which is called ACORN. ACORN is actually, it's the name of the seed of this oak tree, anyway. And this is the open source project. It's a lightweight hypervisor which is built for IoT and automotive use, automotive industry. And you can, actually it's Linux Foundation project. You can take a look at the details of, this is our future website, we can give that up now. And but here I just only have a quick view of the architecture looks like. This is the one of usage, there are some other usage like for real mode, for IoT industry, for real mode, guest support, RTOS support. But here we are using for automotive. And in the, you know, vehicle actually we may have multiple system like the front seat, you probably have infotainment system, the back seat, rear seat, you have entertainment system. So we can use this hypervisor to build a multiple and your guest VM to save the cost because we can use a single SOC to support a multiple OS. And here the, and in this case we have a service that runs on the left and this is a privilege OS, it's a closed system, it can provide the, it has most of the native drivers, including the RPNB driver, including the MMC, or the Stardew driver, and can provide device mediation or device emulation for the other guest VM because all the guest VM take a Stardew as an example, the guest will see the virtual Stardew. And it can also provide a guest user, we call it as a user VM, a UOS, it can provide a UOS management. And since we, since we need to support Android here, so we build a similar trust execution environment in this, on top of this hypervisor. And we actually, in this architecture, we further reduce the NAF code, this native hypervisor, by introduce a new concept which we call the one word, sorry, one VM, two word. And which basically means that in the hypervisor we only create one single VM data structure, but we create two different virtual CPU, context error, in order for saving with each word, virtual CPU state. And just like a traditional process or thread context switch in the operating system, we call this the word context switch because the trustee in the secure or secure world and the Android, they are actually a time-saving on the same physical processor. So we can switch back-force between them by save and restore the virtual CPU state. So let's talk about how the secure Stardew is virtualized on top of this system. Then you can see that we have a hypervisor. We have a native driver which is inside the service host kernel and we have a EMMC device, but assuming that this device has only one single RPNB partition, right? So during the board time we send the authentication key RPNB syndication from firmware to hypervisor and have whatever is sent to the service host kernel so that the service host can access the physical RPNB because service can have this key, right? However, for the virtual machines like Android VM on the right side, they all don't have the directed physical RPNB driver, physical EMMC driver to access. So we need to build a virtual RPNB module in this device model process. The device model process, you can imagine that this is something like the cumul. We don't use the cumul because the cumul is too complicated to run and it's not nice and friendly for commercial use because someone, many other motive vendors doesn't want to disclose their source code. And so in this virtual RPNB module, when this module started, we generate a virtual RPNB key and we hand over this key security to the trustee world so that from trustee's perspective, it doesn't care whether this is a virtual key or this is a physical key. It just uses this key as the RPNB authentication key to talk with the backend RPNB emulation module. The emulation module exactly behave as the behavior of the hardware RPNB controller. So as long as the trustee world get the authentication key then it can send the data over the proxy and then because there is no physical RPNB driver so we need to write a front end RPNB driver and talk with backend RPNB service over the virtual IO framework and then send the data to the virtual RPNB module. Then the virtual RPNB module use the virtual key to verify the data and then extract data then send to cumul and the cumul will use physical RPNB to send the data and send the data to eventually the physical RPNB so we can build the whole flow like this. And by the way, if there is multiple Android start we use a different virtual key here. For example, this is the virtual key one, another one may be a virtual key two and this key can, I mean, this key can, they are different and each user VM cannot see the other VM virtual key. And we have different process isolation so that the different processes in the service also cannot see other virtual key here. So this is the basically RPNB virtualization works in this hypervisor project in which we can support a multiple Android and provide a temporary system to secure storage for those multiple Android as a guest OS. Wait, but still we have a problem here. As we previously mentioned, the secure storage not only provides the data as an integrity and also provide a confidentiality. So we also need a secure storage encryption here to encrypt data before sending the data over the proxy to service OS, right? So I'll talk about how to generate this secure storage key in this system. Okay, so this is how it works. The, actually there is a platform seed which is what we call a P seed. This is unique per each platform. This key is bound to hardware in UK. And the firmware, the root of the firmware generate this key and send this key to hypervisor and then whenever the guest VM user starts then the hypervisor will derive this key. And over the UI, the UI ID is the user's unified ID and this ID is fixed as long as it's created. And we derive this, we derive a user, sorry, VM seed for this specific VM. And then we use this VM seed to derive the secure storage encryption key for this trustee. So if there is another VM start, we will use the platform seed in hypervisor to derive another different VM seed. And then that VM seed can be used to derive a different secure storage master key here. So in this case, we can isolate the data because even the service or us can have the knowledge of the physical RPNB driver or how physical RPNB can, it cannot know the data, the play text data which is encrypted by different user VM, right? Because the service doesn't know the platform seed because hypervisor never send the seed to, the platform seed to service or us. So this is how it works to make sure the data confidentiality protection in this on top of this virtualization system. So let's quickly come to conclusions and some future considerations especially for improvement. And now we know that we can provide temporary system and temporary evidence secure storage in native Android and in this virtualized environment which can support multiple Android VM. And we also can provide the data integrity and the confidentiality protection. And but for replay protection, we can achieve that obviously for native Android but we have problem for virtual Android in on top of that ACON hypervisor because although and also it's implemented in a closed system as well as has no knowledge of secure data encryption key for each virtual Android VM but as also does has actually RPNB, it means that the SOS if it's compromised it can recall the data and then replay. So in this case, the virtual Android guests doesn't know that, right? So this is the one of enhancement in the future of what we need to do that. And by the way, the entire solution depends on the verify board and the chain trust because we start firmware and the firmware start hypervisor and hypervisor start service OS then service OS to create a device module like QML to create each multiple each Android OS. So we need a trust chain to build in this flow. And for the future consideration, first one is actually as I previously mentioned, the latest YAMC, I don't think YAMC will support multiple RPNB but UFS since from 3.0 now has already supported maximum four RPN partitions which means that four partitions can program with four different authentication keys. So if we take this into consideration for build virtualization on the hypervisor, for example, we can assign each virtual Android with a dedicated physical RPNB then in that case we can prove when RPNB replay attack as I just previously mentioned. And we also have to do the enhancement for the service OS integrity protection like that. Okay, so this is all. Thank you. Questions? This isn't actually a question here but could we have a round of applause for Elena who's been doing such a wonderful job doing the MCs. Now back to your regular questions. It's a bit out of my order. So do we have a question? Do we have questions for speaker? Sorry for the ignorance, I'm not familiar with the hypervisor but what kind of trusted execution environment we're talking about here because is this like a vendor independent or this is TXT or some other Intel new stuff? Oh, this technically this is not something new. It's just based on the virtualization technology. So it uses VTX which is supported by CPU and also use VTD which is also, we call IOMMU provided by chipset. So currently we don't use some new technologies like SGX or some other un-disclosed technology because this is built for the multi-product and we build based on autumn-based processor because on that processor there are many advanced technology actually they are not available yet in that hardware. Okay, but the hypervisor targeting Intel platforms. Hypervisor only targeting Intel platforms. Sorry, what is the last sentence? Hypervisor. I'm just. Targeting Intel. Oh, targeting Intel architecture. Okay, thanks. Okay, thanks. More questions? Hey, let's send thank you speaker. Thank you, have a good weekend.