 Hi, good afternoon, welcome to my session. In this session, I will first work you through the basic concept and technology of U2S and then I will reveal potential security stress introduced by U2S to the right of the canton. Then I will give some mitigation and comparison. About me, my name is Wang Hai from China and I work for Alibaba Group, which is one of the largest e-commerce companies in China. And my research focus is IoT, Internet of Things, vehicle to everything, and trusted computing and cyber-physics systems. I was a speaker of Red Hat USA 2017, resonating ultrasound to smart devices to mess with the VR device or iPhone or drones. And I was a speaker of Breckin Europe 2015 about GPS poofing and Wi-Fi's poofing creation. It's very tricky, thanks. I am also a founder of an open source mirror site which I have called Tuna, yeah, Tuna. And this is my email address. This mirror is easy to remember, it's hard to remember. It only has to remember the eight, oh, zero to eight. It's very easy to remember. And now the mirror, like in its turn-off interview here, you can find this output is one, only one bar of this kind of cof, very interesting. Our TDDRT is in driver mode, very likely. Oh, okay, the introduction to U2F. So what is U2F? It's called the universal factor. As we know, two-factor authentication is considered to be the most secure way to put user's account in a safe mode. So what is FIDO? Because we also call it FIDO-USF. FIDO means Fast Identity Alliance, Open Standard Alliance, founded by Google and I think Ubico. Now the U2F device is manufactured, including Ubico, based in Sweden. And naturally, it's a proud German company, I think. I'm a freaking Chinese company. Now what the U2F has many benefits over the traditional key, because for example, they have native support for Chrome browser and other browsers are supported on the way, like Firefox. You can at least use a platform to do U2F authentication. And it is driver-free because it uses USB-HID protocol, basically like the keyboard or mouse. And it's also the physics layer or the rule message layer that can be run around the BTLE, means Bluetooth, go energy and NFC. And this is a brief history of U2F. In 2010, Ubico Google created U2F. And 20 for me, the U2F technical specifications is put into the FIDO labs. And for 2014, the support for Gmail and Chrome starts. And the 2016 U2F government. And I think 2017, I remember the early of 2017, Facebook supports U2F as well. And now the portfolio, I think Facebook, Dropbox, GitHub, all of them now supports U2F. And for open source projects, like GitLab. And where's the problem, GitLab, GitLab is there. Yeah. And GitLab and WordPress now supports U2F by a simple plugin you install it. So what is the principle of U2F? It's nothing new, I think. It's basically the public, private key system. As for the reliable party, you can think it as Gmail, Facebook, or other cloud service or whatever. And for the client, you can consider it to be the browser. And the U2F device, you can think, is only this big. So the reliable party, it has the record of your public key. So when the second factor authentication starts, the reliable party sends the key handle and the application ID and the challenge down to the client. So the key handle, basically, you can think it as an index to your privacy, storing your USB device. And FID, basically, FID are the domain name of your HTTPS site. And the client, after the client received those parameters, they check the application ID first. Then the client simply for all the parameters to your U2F device. The U2F device has a microcontroller to handle the USB protocol. So first, the U2F device look out for the private key associated with the key handle H. Then the counter design, which I will be talking later about the counter issue. The counter increase by one. Then the counter, the other parameters assigned by the security element, which is a cryptographic chip, I think. They return a signature from the security element. Then all the parameters are sent back to the client. The client then voids the cloud. Then the cloud checks the signature and finishes the whole verification. This is a central of the Dropbox. I fired up the Chrome web debug console. This is the challenge. They voted for, they voted for the browser to this device. Now this is a snapshot. I think I can show you in the realm. First, I cut this key. It's an open source one. I first register it with like CCC, DPD. Next. Then it's performed. My device is not to grab. I have to put the, oh, oh, there's a new feature. It didn't sound beautiful. And the technical data includes the origin, the name and the challenge. And response data is from my key. And then I log in with the big puzzle. And also it has to press the button. Then the second factor authentication is successful. The response data, the signature data and the counter and my user presence can touch between parameters. On the background, there is a V2F2.5 which is an open source project and V2F2 later for debugging. I think the demo.utilical.com is actually left aside. It's very useful for basic technical explanation. And one of my friends built a V2F0 open source key, this one for me. So the design is very simple. It only has eight components. This is the button for user presence. And this is the LED. And this is for electric protection. And this is microcontroller. And this is the security element. The security element is for HTML, ATCC 508A. It has 16 slots for public key and private key storage. Now the question comes. If the storage capacity is 16, it's that means we have only 16 websites to buy this single key. So the final V2F has a support for infinite key numbers, key numbers. So what do they do? So let me do some basic explanation. The security element, the chain, stores public key and private key pairs. And the on-chip operations for key generation and the data signing. And also stores key portion from outside from your computer to the security element. And it has a program of limited storage. So the solution is use a single device secret which comes to the master key. And we use a key derivation, a kind of public key vacuum, to regenerate all the essential private key from one single master key. This is from the Fido U2F standard file. A U2F device, the key handle, remember the key handle H, doesn't have to be the index to the private key. Instead the key can store for the orange and the hash and to the irons to retrieve the private key. So as for the open source project, U2F0, it's labeled version of formula, source this formula. Remember the key handle is sent from the cloud to your device. And it has the nums, is a random number. And the private key, after you receive the nums, the U2F0, the microcontroller, get these nums. And the MID which is the website domain. And the device key is stored on these two. They do an HMAP. This HMAP operation is inside this security element. So they regenerate the private key. Then the HMAP part, the private key can do another HMAP to the verification of the whole process. So it's very neat and easy to handle. And for the biblical company, they don't have the essential open source code for auditions. So they provided a diagram, basically the same test code. For the web part, it's a regular U2F operation. You get an MID, you get a private key, you do an HMAP, you send it to the signature. But the blue part is the key to the validation process. So what should we be worried about handling this process? Someone asked in the UBICO forum in 2016, a member, he says, I was given an UBQ. I want to reset the U2F secret, which is a master secret. Is this possible? Or a similar question was asked in 2014. And the answer that is my coming of future. But in 2016, biblical guys said, there's no way to accept this. You have to trust us. So I was very paranoid. So I do some experiment. So my proposed attack scenario is, first, the attacker extracts the master key during the manufacturing process of this UBQ. This U2F is an open source project. Then attack the clone, this U2F key. In this case, we are integrating with a software U2F implementation called V2F.py. Then the attacker gives a U2F key to a victim. Then I assume the victim used this key to grant this pool of other services. Then the attacker gets another password from a phishing or other or torturing or something. Then, okay, this is a scenario. And after some cartographic experiment and some simple calling, I come up with these results. This is the regular authentication process. I use this key to authenticate with the demo site. It's a regular process. Then I unplug it, use the U2F.py. I integrate it with the QRM mechanism with U2F.py. Then the login was successful. I tried another website called Gmail. No big deal. It's the same principle. Then try to use this loop. Because it's long, so it's not that scary. I long this key during the manufacture process. And you can have it. And the last one is an Australian email wire or fast mail. It's very fast, so I use it as a fast mail. The first part is no big deal. It's not just like other things. But I try to roll the anti-chloric counter back by one. Now the anti-chloric counter is two. I can control it and roll it back to one. And the login process still works. So the fast mail didn't check the anti-chloric counter. And I send the email to them. Okay, what is anti-chloric counter? So first, inside the sturdy element, this is a sentence from the division of 1886508A. It says the counter is a high-endurace moroponic counter, which means you can't control it using your phone. And let's say the victim or the user now has a state of counter of 100. But the next time he authenticates with a cloud, the counter goes by one to 101. So the cloud only has to check whether the new counter is larger than any of the recorded powers. So if an attacker clogged this key, he has two ways. First, he just gets a very large counter, let's say 900. But this scenario is not so good because the victim will surely be aware of it because he has to press 801 times to let his key be bigger than the victim of the attacker's 900. So if the attacker is smart enough, he can do the best try of 102. Just patiently to do every check. So as for Google and Facebook, they didn't give a warning when this scenario happens. So our key findings have two basic key findings. First is the security model. And in traditional key model, I think, this is basically about the ultimate trust. Let's say if you have a bank account, we trust the bank ultimately. So we also trust the key issued by everything issued by the bank. So we also trust the traditional debt caregivers with security. But in these keys, like this one is open source, this one is commercial of the COTS key. So these are general problems just with key. You can buy from other website or give them from a friend. So these keys bring us a new problem to this security model. We should dongle the trust level from the ultimate, which means our most important can be called the pathographic chip network. Dongle it to manufacturer trust level, which means we, after we receive this key, we should at least do a key regeneration process or to generate our key from an ACAT computer and write the key to the USB device. Actually, the OpenPGP card has this thought. And actually, Chrome Congress should develop a new key. For example, Google and Facebook, when the rolling back event occurs, I think they don't give users a bell warning. And as for fast mail, they didn't check at all. So I report this issue to them and they confirm. So with the mitigation from the service provider side, first, we should dongle as I mentioned. And the third one is we should now implant the Chrome detection. First, of course, we could wear the user's body. And second, I think, it's a very easy way to do it because when the rolling back event was detected, the website can revoke this key pair. And maybe we think this is not a very convenient way, user-friendly way to use it, but it's too factor. You just do the factor. You still can use your phone to do an SMS notification or email. So I think the revoke is not that non-useful for me. So the conclusion is I think this can be classified as a supply chain basically because during this manufacturer process, either when the manufacturer itself or the related supply chain providers they can do something bad to your cryptographic device. Actually, do you remember I just said the cryptographic, the security element, the graphic chips can do a key to import process. Actually, in this open source project I found there is some sort of time I can export the master key from the generation port. So whether you use the security element or not, this issue should be well considered as a supply chain risk. Secondly, I think as far as I know we give a first reward example of this kind of attack. Before, we only have some foreign complaints, but this time we have an experiment. I think it's not that bad, but I think it's a reward example. And we found that unaccompaniment is not well implemented in some websites. I think the best practice is to work and revoke. These are my friends in this research providing ideas to our association. And in the future, I think in a few weeks before, FIDO has a new standard called FIDO2. They are providing new authentication to passwordless authentication, but I don't have the time to take a look at this future. The second, a phishing website, which is built to try to extract the master key reversing the HMAG function. A friend or a teacher, a professor of mine, he's a preprographic master. He says that HMAG reversion is not that difficult. I don't know many of these could be... So I think if you can use this open source version, you can draw it back to the original from there. The original from there only uses 16 keys slots inside the security element. So you can only bind these keys to 16 websites since it's security now. So thank you. Any questions? Can't it try as well? Received? As far as I know, I only tried with three-fourths, so not that much. Maybe Google now has some new ways to control. Okay, a second question. You mentioned that there is an admin chip on the board that you use, or maybe on the UP key too, and I'm not sure, but do you think it's possible to desolder the chip and reset it for reasons and flesh your own property? You can say there's a fault to resets the key. Yes, I think the problem is that the manufacturer can cover the key by flashing or generating it on a chip. If I reset the chip after I've bothered it or desoldered it, do my own generation I should be safe if I understand the problem? Yeah, but the key generation process is not an easy process. You have to send a lot of, I think, the inner commands to the function of the chip. So I think it is only by fault. It's not that easy to do a regeneration. Okay. Actually, some years ago, there is side-channel tech on UP key, and later they fixed it by another... The side-channel tech basically is the power. You use an acidic scope to narrow the voltage during the AES or other pathographic operation. Someone, I remember at least three years ago, doing this side-channel tech, but they fixed it. Okay? Yeah, main engine cut-ups. Any questions? Thank you guys.