 This talk is available at the URL shown on the screen. If you want to follow these slides at your own pace, you're welcome to do so. There aren't any major spoilers in the slides. Give it a moment to take a photo or copy it on the URL if you want. My name is Taylor Campbell. I'm a NetBSD developer. I'm on the NetBSD core team. Been developing NetBSD for some years now. I work on various things, from networking to cryptography to file systems to whatever else needs to be fixed. And for a long time, I was leery of hardware authentication tokens for reasons I'll get into a little bit later in the talk. But at some point, my past employer insisted that I use a FIDO key and so I looked into it and I realized, wow, this is actually a good design. So I will lead you through what motivates it and what makes it different from past hardware crypto tokens and some cool things you can do with them. Traditionally, when you want to get into a computer system, you have to give the password. In fact, passwords go back a very long time. If you wanted to get into the castle, you probably had to castle here and claim it, I bet. You probably had to give the password at the gate and otherwise they wouldn't let you in. They'd probably impale you and put your head on a stake or something, I don't know, whatever medieval people did. I'm not a medieval historian, don't quote me on that. Well, here's an approximation to an email I received nominally from the EuroBSDCon organizers. And you've probably all seen, if you have any friends or colleagues or acquaintances who have sent you a Google Docs link to share the Google Doc with you, you've probably seen an email just like this. I actually took a real email I received and modified the from address to obscure who is actually from, but this is very close approximation to a Google Docs email that you might receive. So as you all know, when you get an email with a link in it, the thing you do is you click on the link because, well, that's actually how you're supposed to do it with Google Docs, with Google Drive Sharing. And so I have this link. It's got a EuroBSDCon conference program and I gotta figure out when my talk is so I better click on the link. It's not an attachment. I can't just download the attachment and read that. So I click on the link and I get a Google sign-in page and I thought it was signed in, but whatever, maybe cookies were lost or something, who knows. And so I type in my email address and then hit next and I type in my password, which is obscured by asterisk so you can't see it. But I type in my password and this is legit. It says Google on it, right? It says Google and welcome and it's all legit, right? So I type in my password and I've been phished because that was not in fact a Google Docs link. If you look very closely at the Google, it says htscolon slash slash drive.googie.com. And if you look very closely at the URL bar, you'll see it says also googie.com. And this, well, this wasn't actually a phishing exercise. What I really did was I took that Google Docs link and I went to real Google Docs sign-in page and I just edited the URL bar before I took the screenshot. But there's nothing to stop a phishing attacker from creating a page that looks just like the Google sign-in page. You can't tell the difference unless you've scrutinized the URL bar very closely, which I'm sure all of you as security conscious BSD nerds did. So you knew this was coming, there was no surprise to you. Well, you probably did because of course I've built up dramatic tension here. So how do we fix this? Well, the traditional approach to getting more security with login systems is two-factor authentication. And with two-factor authentication, a password is not enough. You've got to have something, two of three things. You've got to have something you know, something you have and something you are. Something you know like a password or your security questions like your mother's maiden name and the social security number of your brother and the luggage combination to your partner's luggage locks. These are all things that you might know and you can put into security questions or passwords or whatever. So when you have a physical object like a USB device, like I have in my hand, well, this is not actually a security thing, but maybe a phone or a key on a key chain or a USB device. And another option is something that you are, which is a BSD nerd and that is how you get into the conference. Well, okay, maybe that's not a very good authentication system. I actually walked in here without this badge even, but I guess I looked enough like a BSD nerd. No, something you are, biometrics, like you're a retina scan or fingerprints or what have you. I'm not really a fan of biometrics to be honest because if your finger is compromised on a glass, then you can't get a new finger. But anyway, we want to talk about biometrics in this talk. This is all about FIDO. So typical 2FA system, two factor authentication system is you have access to a phone and there's a SIM card in your phone maybe. And the SIM card has a super secure cryptography on it. Well, maybe not that super secure cryptography. The telephony network, it doesn't have a stellar reputation in that respect. But let's say, and when you want to log in, you get a secret code sent to your phone and then you copy into the websites. Other systems are on Authenticator app, which doesn't use the telephony network. There's just an app running on your phone or on your laptop or just a two line Python program that you run, which is actually what I do. Authenticator app usually means the TOTP standard, which is RFC 6238, building on RFC 4226. It's a very simple protocol, very easy to implement, nothing exciting in there, nothing proprietary, like I said, few lines of Python. Or you might get a push notification to your phone. Anytime you try to log in to Google.com, then you get a pop-up on your phone saying someone is trying to log in to Google.com from Coimbra, Portugal, is that you? And you say yes, of course, because you just want to get your work done. And okay, so how does this work? You see another login page, this is an actual GitHub login page just from a few minutes ago, in fact. And after I've entered my password, then I have the option to enter an authentication code from my Authenticator app, TOTP. And when I do that, then if this were not a actual GitHub, oh, well, in fact, if you look closely, this is not GitHub, this is Git Bub. Well, now the operator of Git Bub has my password and my TOTP code, and they can instantly log in to GitHub as me and change my password and change my Authenticator apps and so on. It might be slightly more difficult, well, there might be another step involved for them to actually do that, because GitHub is probably gonna ask you to enter another TOTP code, but it's not that hard for a Fisher to take advantage of the easily distracted here. You're trying to get something done on a pull request, someone submitted a really annoying patch that they're about to merge, and you've gotta put that review in. You're not thinking about the authentication right now, you're thinking about the one critical line in that patch that is wrong, and you have to fix it. Push notifications, I don't have a screenshot of that because I don't use them. This is left as an exercise for the reader. Some of you probably work at companies that require a Microsoft Authenticator or a Duo Authenticator or something. It's a push notification, it's like an obnoxious news alert, it's for logging into your email. So two factor phishing, well the way that it works is you type in a code that's written over SMS and the attacker takes that code and relays it to the legitimate server and logs in as you. Same thing with TOTP codes. And with push notifications, well you try to log into a link that you think is github.com and it's actually github.com and so you get a notification on your phone someone is trying to log into github.com which the attacker actually is doing and you're also trying to do that you think and so you say yes, of course I'm trying to log in here. Another approach is that an attacker will just randomly decide to try to log in as you and you'll get a notification and you know that you're using 2FA so you don't have to choose a super secure password and the attacker takes advantage of this so they run through all the passwords you could be using and they send you notification after notification and you get really sick of these, you just, yes, go away, just, just, just, and then they get in. And this leads to notification fatigue and you know it's similar to warning fatigue and that's bad for usability which is bad for security. Now the main problem here with one time codes is that although they're only good for one use you're still copying and pasting a secret that's not bound to the actual origin, it's not bound to github.com and there's nothing, you know, you can mis-paste it into the wrong site. Even if you use a password manager, password managers that try to be clever about auto-filling forms that relies on scraping the HTML and looking at it and seeing if it looks like the right place to put a password and a TRTP code and what have you and sometimes it doesn't work and so you might decide, I need to get in here, I just, maybe the website is broken, I changed the HTML and the copy and pasting the password manager doesn't work anymore so you copy and past it yourself and bam, you've been phished. Now, when you want to have a enhanced security, the important part is not more security, the important part is managing risks. So you have to start with a threat model and realistically, the biggest threat for most people and most organizations and most people between them and their money and so on is phishing because the thing about phishing is that anyone can send an email and that email can have instructions in it and that email can look like it came from somebody else and it's, you know, even if you have all the DKIM and all the whatever email, you know, verification systems and so on, you know, it's still, if it's got instructions in it, it looks sort of plausible even if it isn't exactly github.com, but github.com, well, you might act on it. And so phishing, there's a very low bar to entry for an adversary. So if you look at, you know, threat reports from like Microsoft or the FBI or something about cybersecurity threats, phishing rates way at the top of the kinds of threats that every organization has to deal with. So the number one threat model is phishing and really the number two and three threat models because it really is a big, big problem and the barrier to entry is so low. You also have to worry about user fatigue and circumvention. You know, if your security measures are difficult then people don't want to deal with them. You know, crypto nerds like me, yeah, we're happy to deal with weird elaborate obscure things but people who want to get the work done, send an email, edit a document, they don't have time to mess with elaborate security mechanisms and they're gonna find ways around them. And sometimes that means they'll just adopt a different tool from the one that is hidden behind the super security, super secure barrier that you have. So an important lesson for security people here which is that you need to be an enabler, not a disabler. Don't get in the way of people. You need to enable people to get their work done and make the user experience easy. Don't put security barriers in the way. Make systems that people can use that don't need barriers that get in the way. Then way low at the bottom of these threats is things like hardware theft, laptop theft, and yeah, that is a problem but it's the barrier to laptop theft or man-to-middle attacks in the network or shoulder surfing, it's much higher, it's much harder to pull that off. You have to have physical access for hardware theft or shoulder surfing. You have to have control of network rooting for man-to-middle attacks and yeah, there are ways that can happen but it's fishing is a much bigger threat than all of these. So there's some hardware tokens out there like RSA secure ID, it's like a proprietary version of TOTP. You've got a little dongle, it has a display on it and it has a code and you type it in and you get phished because it's not phishing resistant. All UB keys, similar thing but it presents as a USB keyboard and it just automatically types some text for you into the getbub.com text fields which you've been phished and then a bunch of hardware crypto tokens with following standards with numbers. Nobody can remember like PQCS number 11 because number 15, the OpenBGP tokens and these legacy crypto tokens is a huge software stack. You have to deal with you gotta install a bunch of different packages and there's like demons and libraries and drivers and I put some links in here if you wanna follow them for some issues I've had with actual crypto tokens like I had this E-PASS 2003 from Phytien and OpenSC couldn't reset the device to initialize it. It got in some weird state where it was just bricked and there was this proprietary binary blob tool from Phytien you could run to unbrick it. I got a friend to reverse engineer it and figured out and sent a patch and now you can actually reset these devices but it's a big pain. There's like limited number of keys per device that you can put on there and you have to have special tools like PQCS 11 in there or 15 in it or OpenSC in it or the GPG dash has card status and once you do that you can have like a client certificate but that is a privacy league across websites because it presents the same client certificate to all the websites and that's just a tracking code uses. I'm Taylor Campbell, yeah I'm a Taylor Campbell. I'm the same person all these websites and so it's bad for usability, bad for privacy. The software is brittle, it's hard to work with, it's a nightmare. So enter Phytto. Phytto will protect us from the phishing. Now I should add the caveat that this won't protect all phishing, phishing of the form. Hey, I'm the CEO and I'm at a client engagement. I gotta get this client a gift card from an Amazon gift card. You just send me one. Can't really protect against that but it can protect against credential phishing where someone takes over your account from copying your password and TOTP key and whatnot. So I'm gonna do a live demo. I'm gonna actually mess with my own GitHub account. If I can get the, here we go. That's my GitHub profile. Let's make this much bigger. Okay, so here's my GitHub profile and I have some security keys registered. Now a security key is a little USB token like this little black thing. It's got one button on it, it's a USB-A device. It's got one button on it, just a touch sensor. There's no other input or output. And I'm gonna, I have it named in here as UB4Chain, so let's delete that. And, oh, I gotta confirm that I have access to this. So let's confirm, yes, I do actually have access to this. So when I wanna register this security key to start using it for GitHub login, I just say register new security key and I'll call it the same thing, UB4Chain. Just a nickname for the device for my own reference so I can keep them straight if I have multiple ones. Add that and GitHub wants to register an account with one of your security keys. So I'll plug it in and tap the button and that's it, now it's registered. That's how, that's all you need to do to set up a FIDO key with a website to log in. Then if I log out, why is the log out button so far away? All the way, here we go, sign out. Yes, I do want to sign out, I'm doing a live demo. Okay, now let's sign back in, where's the sign in button? Here we go, sign in and let's enter my username. I'll type my password into github.com and now, if I wanna use the security key, I just hit use security key and I have this USB device and I tap the button and that's it, that's the only addition to the entire user experience of sign up and log in. You just plug it in, register security key, tap the button, that's it. I didn't have to install any special tools, didn't have to configure the device, no device initialization, you get it out of the box and it just works. So how does it work under the hood? You might wonder what security properties it has. How does this just button, how does it solve anything? Well, the server at sayexample.com, when you navigate your browser to example.com, when I said register a new security key, the server brands me Java script code that asked to make a new credential and the browser asked me to tap the button to approve and the device, this little USB device with a little microcontroller on it, generates what's called a credential ID, just like a random 16 to 128 byte string depends on the vendor what this string is but it's a random string that will identify a key pair. So the device generates a credential ID and a key pair using the origin, the website, example.com as an input just to randomize things a little bit. And the device returns the credential ID and the public key, which the server stores for later use, for later login. Now each time you register a device, each time you use a new, a key, if I do a device to make a new registration, so if I delete it and make a new one or if I go to a different website, the key pairs are all independently generated. So in this works because elliptic curve crypto key generation is very cheap. You just have to generate say a 32 byte seed and then do one public key operation, which is a few hundred thousand cycles maybe, a few tens of thousands of cycles for modern things. So under the hood, this is the general protocol flow of what's happening. Then when I will log in, log authentication flow, the server at example.com generates a challenge, sends a challenge and a list of stored credential IDs, the ones that are all registered for use in login for my account and asks a device to please prove that you have one of these credential IDs. So the browser then asks user to tap button to confirm and the device takes a credential ID and figures out from just a credential ID and the website, example.com, what the private key was when it generated the key pair. It does it deterministically, so it always gets the same one each time that it has the same inputs, the same credential ID and the same origin and then it returns a signature on a challenge and the server verifies the signature with a stored public key. So it's a fairly simple idea, but it's a little tweak on the traditional thing where you just have a long-term public key that you reuse for many purposes. In this case, there's usually going to be a long-term seed stored on the FIDO key that is used to derive keys deterministically with like HMAC or something. And this has some nice properties. The public key pairs are independent for each site, so there's nothing to track you across sites using the same device. So you only really need one device or actually best to have two of them, a primary and a backup, but you really only need one to log into many different sites without creating any sort of super cookie to track you across the sites and you can still use it to log in. You can use it for different purposes and the sites can't tell, even if they collude behind the scenes, even if Google and Facebook and whoever else is colluding behind the scenes, they can't tell if you're using the same device or multiple different devices for the different accounts and different sites. There's no user-visible state to manage on this device. Remember, I got this device, took it out of the box, plugged it in and used Firefox with it to set up with GitHub. I didn't have to install a PKCS-15 init tool to set it up. I don't have to worry about how many keys are stored here. In fact, you can have an unbounded number of credentials because they're not actually stored on the device. They're derived deterministically each time you log in. So there's no limitation on storage here. And with the traditional hardware crypto tokens, if you use that as your main credential to log into something, well, there's always a chance that you, the vendor has been compromised or they've deliberately put a backdoor and they've stored some way to derive all the private keys so the NSA can get at them again. And that is a concern with FIDO keys, but when you use them as a second factor, the backdoor into, say, Ubiqui, Ubico is not as attractive a target because on its own, it's not enough to break in anywhere else. When it's used as a second factor, that mitigates the supply chain attack angle of the hardware tokens. So while that is still potentially a concern, there's no longer one party, no single point of failure from the vendor that could break in. They would have to both break, have the backdoor and fish you or something like that to get your password as well. So it presents less of a concern about the vendors of single points of failure. I should acknowledge that there are some very limited privacy leaks from FIDO keys, from FIDO devices. When you register the device, the server can ask the device, the website can ask the device for an attestation of the manufacturer and batch number for the device. Some enterprise deployments will do this if they have, there's like a corporate IT policy that you must use Ubico devices or you must use solo keys devices, you must use nitro key or something. An approved vendor. But the standard and which has an auditing process, there's a standard body, FIDO Alliance and it has an auditing process. It requires that the batch number included in the device attestation. I think that it has to be, it has to narrow it down to no fewer than a thousand different devices or so. And it is up to the browser whether it sends this. In Firefox, if the server asks for this, the browser will ask you, the server is requesting some information that may limit your anonymity, do you want to send this? And you can say no. And for an enterprise deployment with an IT policy behind it, then it might not work. The server might say no, I don't want to do this. But you don't have to worry about that for GitHub or Google or whatever. Most sites, this is not relevant. So you can most ignore this, just say no, don't anonymize me anyway in Firefox. The story is different in Chromium, I think it might automatically pass it through, but it's, well, Chromium doesn't run on NetBSD anyway yet, so we don't have to worry about that yet. Now, Chromium is hard, it's a lot of work. There's some progress toward it, but it's not. Now, on authentication, the device may send a count of the number of signatures it has made. Now, in principle, this provides some fingerprinting information. There's a security motivation for this, which is that this allows a server to detect if a device has been cloned and then shut off access to it. Because if a signature counter rolls back, then the server knows, oh, this hardware device, which is supposed to be a thing that's baked in epoxy, so if you try to get at it, you'll destroy it, whatever, that somehow someone has cloned it, that might be bad, and so servers can choose to cut off access. As a result, this leaks a little tiny bit of information when you use it. This is something where the server, if two servers wanna collude to try to figure out if you're using the same key, they can maybe get some statistical answer about this, but they can't get a definite answer. It's like solving the German tank problem in statistics, where in World War II, the British were trying to count how many tanks the Germans had, and they looked at the serial numbers to figure out, from captured tanks, and they tried to, you know, you had some statistical analysis to guess what the largest serial number might be based on that. So you have to use some statistical analysis to even use this information. It is a privacy leak, but it's a very limited one compared to like X709 client certificates, where you're just saying, oh, I am Taylor Campbell. I'm trying to browse to this website, and it leaves a record of exactly what certificate you're using all the time. Finally, a server can tell, Google.com can tell if you're using the same device for multiple different accounts at that server. So if you have a personal Google account and you're trying to do something very politically exciting about Google itself that would make Google interested in determining whether, or maybe the US federal government that is trying to track you, then maybe you should use more than one phyto device for that. But servers can't track you across sites, so it doesn't function as like a super cookie. Generally for users, I recommend that you get two devices, a primary that you keep on like a key chain, or you can get these little tiny ones that I have on a string here. This is just like a USB connector, and that's all that there is here. The whole device is stuck under the USB connector. It's a really tiny nano-sized one. There's also USB-C nano-sized ones, and it just fits in the USB port, and it sticks out like maybe a millimeter. And there's a little ring you can use to pull it out if you want, but it's very unobtrusive, and it's just a contact thing. So you can have one always plugged into your laptop, and maybe a backup and a desk somewhere. So if you lose one, it's no big deal. You can just get a new one, use your backup to log in again and register the new one. There is also a protocol in development maybe deployed somewhere. I'm not sure if it's in hardware for letting one key delegate to another one. But it's, I can't say much about that. Now, some enterprise deployments also involve pins, and the protocol technically supports it where a device has a pin you have to type in on your laptop to get access to it. This is not a good system in my not-so-humble opinion. Pins have a bad user experience. They have limited software support, require special tooling. Also it makes the vendor, again, a single point of failure in contrast to using a password as one factor and a device as a second factor. If you use a device with a pin, then the device is now a single point of failure from vendor. So it becomes attractive as a target. But for almost all use of FIDO, unless you're in a weird enterprise deployment, you're building your own custom application, you won't encounter pins. Don't, yes, so don't worry about that. If you want to add support in a web application, you have to just run, use the WebAuthN API. This is what it looks like. Just a JavaScript function in navigator.crentials.create, you pass some parameters. There's some magic constant here. This just says, I'm willing to accept an ECDSA key. There's some other parameters here. It's not that complicated to use once you have, once you get started using it. There's more options than you need to deal with, but this is pretty much all you need. There's a thing in here to exclude credentials, so that if you're, to make a user experience a little better, if you have already registered a key, you can, and someone asked to register a new one, you can say, okay, don't let them register an existing one, let them make sure they register a new one, so exclude all the ones they've already registered. And that's the mechanism that a server can also use as a, to detect whether you're using the same key or do two different accounts. This is more information at WebAuthNutGuide. It's a good place to find resources. Similar thing when you want to authenticate, when you want to log in, this is a JavaScript function you call, and then it passed the result onto the server, and the server can verify that the credential is good. Here's, yeah, so there's various libraries in C, in Golang, in Rust, in JavaScript, in whatever you have for your server applications to generate the parameters for creating and verifying credentials, and to actually verify the credentials once you get a signature back from the device. There's more information here on how to do that. WebAuthN is the name for the web API that is exposed to browsers. FIDO is the name for the standard for the physical devices, like this USB key. And you might also hear the older term U2F, universal second factor. It's based interchangeable with FIDO, just the name, older name for the standard, some older devices. They have some lesser capabilities, but for the most part it's, you don't need to worry about the difference. You see U2F, you see FIDO, you see WebAuthN, unless you're working with nitty gritty details of the protocol and the standards of something, you can read them as all the same thing. Here's a list of sites that support WebAuthN for login, like Google, Facebook, Twitter, some, there are a couple of banks, there are some various hosting providers, a big list of sites that do and don't support WebAuthN you can use. And it's, there's also Git repository, if you know a site supports it, you can submit a pull request to on GitHub to update that. There's a few of these, but this one is specifically, specifically highlights FIDO, WebAuthN. Some other ones just talk about like general 2FA, which is not as useful for anti-fishing. So I promise this would be a BSD talk at some point in the abstract, I think, and so let's talk about FIDO on BSD. Well, as you can see, it works on that BSD out of the box, I didn't have to do anything here. The way that it works is that the main transport that is used between the little crypto processor inside this key, inside this tiny device here is USB, and it presents itself as a USB human interface device, which is a little bit funny, but this has the nice property that you don't need any special kernel drivers for it. And so interacting with it is very easy. It just exposes some simple input-output report pipes. Kind of like the way that if you have a USB mouse or something, it will present a report as a collection of coordinates of where is the mouse right now or what direction is the mouse moving in, and you can write an output report to make it, I don't know, print something on a screen, I don't know, but anyways, very simple interface, easy to use from user land, generally doesn't require privileges because these devices aren't exciting, like it's not like a printer device where you need to make sure that the general user program can't have arbitrary USB access to a USB printer to reconfigure it and control it without privileges. It's designed for applications to get at user interface, and so it's all unprivileged and works very easily out of the box on all operating systems. There are some other transports. You can get FIDO smart cards that's in like a credit card form factor. I have a few. Support isn't as good on BSDs. Some of them have NFC, like this little blue one here, and it's probably too far away for you to see, but this little blue one here does USB and NFC, so you can use the same thing for your desktop or laptop and for your phone. If your phone has an NFC port, so you don't even need like a USB A to C converter, you just tap it on your phone and it'll work. There's also Bluetooth. I don't know if that works on any BSDs. I never tried it, never looked into it. It didn't occur to me until an hour ago to even think about that, but it technically, it might be there. In user land, if you want an application that talks to a device and does signature verification, interacts with it, you can use libfighto2. It's a C library maintained by Ubico, one of the vendors who makes FIDO keys. It supports NetBSD, OpenBSD, and FreeBSD out of the box and Linux and macOS and Windows and stuff. It's available in package source and ports and it's shipped in NetBSD base, so I've built some applications using libfighto and it just works. I had to write it back in for NetBSD so it would know what device node to talk to and exactly what IO codels to run and how to read and write and stuff, but that was fairly easy. There's just a couple hundred lines of C code and easy to maintain, low cost, we'll keep it working. In Firefox, there's this Rust crate called AuthenticatorRS. It's maintained by Mozilla. It serves a function similar to libfighto. It talks to the device nodes in slash dev so that Firefox can expose your FIDO device on a USB transport to a website via WebAuthn. In this case, in this context, it is important to distinguish the client and device side of things from the browser and server side of things WebAuthn. It's used by Firefox. It sports NetBSD and FreeBSD out of the box. It nominally has support for OpenBSD, however, when I looked at this a few months ago, I found a bug in the NetBSD code that looks like it was also there in FreeBSD and someone else verified yes, it is also there in FreeBSD. I think it's there in OpenBSD too. I haven't tested. I made a pull request for NetBSD. That's what the link goes to. I suspect that it needs to happen to OpenBSD too, but again, I haven't tested. The maintainer used to be Ray Flurther and I sent an email to him about it, but I don't know what the state is. This might need a new maintainer from OpenBSD. The maintenance burden is pretty low. You have to be able to read and write some Rust code, but it's not very complicated Rust code for the backend. And so if someone wants to volunteer to do that, it would be great to get this working in OpenBSD again. Feel free to contact me or just look at the pull request and check it out. It's very easy. It's a very simple problem. You can also use Flito in OpenSSH. You can generate a key just like you would with SSH key gen, but instead of saying dash t ecdsa or dash t add 2519, you say dash t ecdsa sk. And then you keep the ID ecdsk key private as usual. This is a little bit different from the normal WebAuthn approach where the server keeps a credential ID. The ecdsa sk file contains a credential ID. This is because it's difficult to, it would require a change to the SSH protocol to pass a credential ID back over to the client. So anyway, so it just works like traditional open SSH keys and you put the .pub in the authorized keys file. And when you want to log in, you have to tap the device to authenticate. I should note, you can also use what are called resident keys or discoverable credentials. In that case, you don't need to keep the ID ecdsa sk file, the private key, it's not actually a private key, it's just a credential ID, but it functions in SSH like a private key. So you don't need to keep that around if you use resident keys or discoverable credentials, but that goes back to the old problems with traditional crowd or crypto tokens. Well, first of all, it requires newer FIDO keys and there's limited storage per device. You have to deal with state management, maybe pins. I'm not a fan of that. It's there if you want it, but I would ignore it. Also, I should note on some lesser platforms that some people use like Linux or Mac OS, that all this stuff works out of the box. And so this is not like a BLT specific thing. And quick rundown of some cool things you can do with FIDO that are not WebAuthN. You can store disk encryption keys on it. Well, actually it's not really storing disk encryption keys, but there's a clever protocol you can use to derive disk encryption keys, perhaps, with a FIDO device. You can use FIDO to decrypt your disk at boot time. Here's a link. I wrote that, by the way, and I also wrote another tool to decrypt your disk I wrote that, by the way, and I also wrote another tool to sign messages with FIDO devices because essentially it just makes a signature, the device, and so you don't need to use it for WebAuthN. You can also sign arbitrary messages. It has a custom format for the input so it's not compatible with PGP or X, V, I or something, but you can make a tool to do this. And I put some nice properties in this but I don't have time to go through that. You can also use OpenSSH to sign arbitrary messages with SSH keygen command and with those you can use key pairs that were generated for FIDO devices. Very easy. You can also use it to send encrypted messages with Aghe, and I also wrote this, I wrote a few of these. I've been messing around with this for a little while. There's some side projects I've been doing but happy to receive input from you folks if you're curious about these. I mentioned in the abstract the old internet guard dog, Kerberos, and so Kerberos is a sort of different thing. It's not a replacement for a fight or it's not an earlier version of FIDO. It's a way to do single sign-on where you type your password once, get tickets that you can then use in other applications to log into your mail, to log into websites and whatnot. And traditional Kerberos authentication uses, single sign-on uses a password to get your SSO tickets. There is some work in progress. It's not widely deployed or implemented yet but there's some work in progress to implement FIDO as a 2FA step, a second factor for getting your Kerberos tickets. And I'll be curious to see what happens with that. I'm hoping it'll get deployed. I hope it's a good protocol. I haven't looked at it really but it's a thing that is out there and then so maybe you'll be able to use FIDO to prevent phishing of Kerberos tickets as well or for Kerberos passwords. And I think about of time for blathering at you but if you folks have any questions then I'd be happy to take them. Yes, Benny. The question is, can you use a FIDO device as a second factor to logging into your machine, locally I assume, and the answer is yes, there is a PAM module called PAMU2F. This is from the days before FIDO was called FIDO when it was called U2F and that is built in to NetBSD base out of the box. You just have to turn it on in the relevant PAM configuration file for the service that you want, like the local display manager or something and then create a file with, there's a tool called PAMU2F config that will create a registration to be able to log in. So yes, you can do it out of the box NetBSD. I'm not sure about FreeBSD, OpenBSD. OpenBSD doesn't do PAM, if I recall correctly, so it'd have to be something else, but maybe to work in FreeBSD too, I think it might be in ports, I'm not sure, but it's a very simple program. It should be easy to adapt if you want to do that. Other questions? Yes, all the way in the back, I can't see who you are. Yes, the question is, what is it needed about a UB key or a FIDO key to make it work and if you reset it, is it like a different key now? And the answer is, it varies from vendor to vendor, but most of the time what the way that it will work is that there is a long-term seed secret key on the device, like a 32-byte HMAC key, HMAC SHA-256 key or something, and a random number generator on the device. And the firmware on the device will generate a credential ID at random or maybe generate an HMAC input at random and feed that through HMAC under the secret key to produce other key, public key material, produce key pairs and credential IDs and whatnot. If you reset the device, and there's a tool you can use to do this, I'm not sure you can do it in the FIDO protocol, but with UB keys you can use a tool that will reset the device and with solo keys and so on. And if you do that, that just erases or regenerates the secret key, so all credentials you've created with it will be lost and it functions as a totally new key and it will no longer work to log into any site that you had registered before. So if you wanna ditch your key, then yeah, you can just do that and boom, gone. Other questions? Oh, oh, hey, I have a question for any organizers in this room. Do you know if we're doing the auction at the end of the event? Oh, right, okay. I don't know if there's an auction. Don't know, okay, all right. Yes, there is an auction? Okay, great. Okay, so I kinda wanna, I don't know if this is wrong, but I kinda wanna, I have a couple of devices here that I wanna auction off and contribute to that auction, but this seems like a more appropriate venue than the random, the usualing. I mean, should I hold off or should I do it now? Sorry, I'm looking at you because you look like an organizer, but I realize you're not. All right, so here's a Ubico security key. It's just USB-A, not NFC, but it works. It's a FIDO key, it works great. So does anyone wanna bid on this Ubico security key? What was that? What's next? The auction. Okay, should I hold off until then? Okay, all right, I'll wait, but there will be a couple of FIDO keys at this auction. All right, well thank you. Thank you.