1 00:00:00,000 --> 00:00:08,469 foreign 2 00:00:00,500 --> 00:00:08,469 [Music] 3 00:00:11,160 --> 00:00:16,320 good afternoon I am here to talk to you 4 00:00:14,160 --> 00:00:19,080 today about webbleathan passkeys and you 5 00:00:16,320 --> 00:00:21,180 the future of Authentication 6 00:00:19,080 --> 00:00:24,119 who am I my name is William Brown I'm a 7 00:00:21,180 --> 00:00:25,800 senior software engineer at Souza Labs I 8 00:00:24,119 --> 00:00:29,099 primarily work on identity management 9 00:00:25,800 --> 00:00:30,840 systems and ldap I am based in Brisbane 10 00:00:29,099 --> 00:00:32,340 Australia which means that for our 11 00:00:30,840 --> 00:00:34,200 International viewers I'm often not 12 00:00:32,340 --> 00:00:37,620 online so the best way to get in contact 13 00:00:34,200 --> 00:00:41,100 with me is via email which is 14 00:00:37,620 --> 00:00:44,340 william.brown souza.com 15 00:00:41,100 --> 00:00:47,460 so you may have heard about pass Keys 16 00:00:44,340 --> 00:00:50,760 now they were announced last year by 17 00:00:47,460 --> 00:00:52,500 Apple and they've been promised as a 18 00:00:50,760 --> 00:00:54,719 replacement for passwords they're faster 19 00:00:52,500 --> 00:00:56,460 to sign when in with and better and 20 00:00:54,719 --> 00:00:58,980 normally when we have announcements like 21 00:00:56,460 --> 00:01:00,719 this in Tech circles they tend to stay 22 00:00:58,980 --> 00:01:03,180 within technology circles they don't 23 00:01:00,719 --> 00:01:05,220 tend to escape from those areas however 24 00:01:03,180 --> 00:01:08,100 we've even seen in Australia that our 25 00:01:05,220 --> 00:01:09,479 mainstream media with the ABC News have 26 00:01:08,100 --> 00:01:11,939 actually published their own articles 27 00:01:09,479 --> 00:01:15,840 about pass keys and how Tech Giants want 28 00:01:11,939 --> 00:01:20,280 to kill off and remove passwords so 29 00:01:15,840 --> 00:01:23,400 the question becomes what are pass keys 30 00:01:20,280 --> 00:01:26,040 and this is where things start to get a 31 00:01:23,400 --> 00:01:29,400 little bit confusing and difficult for 32 00:01:26,040 --> 00:01:33,080 us is that there is no clear definition 33 00:01:29,400 --> 00:01:33,080 of what a pass key is 34 00:01:34,380 --> 00:01:37,500 there being no real definition it 35 00:01:36,180 --> 00:01:39,299 started with the fact that Apple 36 00:01:37,500 --> 00:01:41,880 announced pass keys but didn't say what 37 00:01:39,299 --> 00:01:43,860 they were it really started to appear 38 00:01:41,880 --> 00:01:46,340 like a marketing term or just a friendly 39 00:01:43,860 --> 00:01:49,619 way to describe you know web authen 40 00:01:46,340 --> 00:01:52,920 credentials and authenticators and over 41 00:01:49,619 --> 00:01:54,299 time this definition has evolved and has 42 00:01:52,920 --> 00:01:56,040 actually created multiple different 43 00:01:54,299 --> 00:01:57,479 meanings or understandings of what a 44 00:01:56,040 --> 00:01:59,700 pass key is 45 00:01:57,479 --> 00:02:02,040 so our first definition of what is a 46 00:01:59,700 --> 00:02:03,600 pass key is all possible web authen 47 00:02:02,040 --> 00:02:05,820 authenticators so this could be things 48 00:02:03,600 --> 00:02:07,979 like your Uber key or Touch ID on your 49 00:02:05,820 --> 00:02:10,140 Mac or your fingerprint sensor on your 50 00:02:07,979 --> 00:02:12,120 phone or your Android phone 51 00:02:10,140 --> 00:02:14,400 but to give you a demonstration of what 52 00:02:12,120 --> 00:02:16,140 it looks like to use a pass key to 53 00:02:14,400 --> 00:02:19,620 authenticate to a web service or a 54 00:02:16,140 --> 00:02:23,520 website let's have a look at a demo 55 00:02:19,620 --> 00:02:26,520 so here I have a website which accepts 56 00:02:23,520 --> 00:02:28,440 pass keys and I'm a new user so I'm 57 00:02:26,520 --> 00:02:32,580 going to register myself and I'm going 58 00:02:28,440 --> 00:02:34,560 to register as everything open 2023 and 59 00:02:32,580 --> 00:02:36,840 today I can spell correctly which is 60 00:02:34,560 --> 00:02:38,520 lovely I'm going to begin my 61 00:02:36,840 --> 00:02:41,940 registration and I am prompted to create 62 00:02:38,520 --> 00:02:43,860 a pass key for the website my ubikey is 63 00:02:41,940 --> 00:02:46,620 blinking and I'm now going to touch it 64 00:02:43,860 --> 00:02:48,660 and I'm prompted to enter my PIN 65 00:02:46,620 --> 00:02:51,000 I enter that PIN 66 00:02:48,660 --> 00:02:54,060 I touch the key again and I've now 67 00:02:51,000 --> 00:02:56,640 registered this UB key with this website 68 00:02:54,060 --> 00:02:59,700 if I want to authenticate once again 69 00:02:56,640 --> 00:03:01,140 click authenticate my key is blinking so 70 00:02:59,700 --> 00:03:03,360 I touch it 71 00:03:01,140 --> 00:03:04,800 I type in my PIN 72 00:03:03,360 --> 00:03:07,140 touch it again and I've now 73 00:03:04,800 --> 00:03:09,599 authenticated now if I was to take this 74 00:03:07,140 --> 00:03:11,760 UB key and throw it to one of the many 75 00:03:09,599 --> 00:03:13,319 people in our audience right now they 76 00:03:11,760 --> 00:03:15,480 would not be able to use that key 77 00:03:13,319 --> 00:03:17,040 because they don't have my pin only I 78 00:03:15,480 --> 00:03:20,340 know it so it's not just possession it's 79 00:03:17,040 --> 00:03:21,840 also that pin is unique to me 80 00:03:20,340 --> 00:03:24,060 now let's 81 00:03:21,840 --> 00:03:25,620 try out how this looks in a different 82 00:03:24,060 --> 00:03:27,300 way with a different device so I've gone 83 00:03:25,620 --> 00:03:30,019 over to Safari 84 00:03:27,300 --> 00:03:34,459 and I'm going to 85 00:03:30,019 --> 00:03:34,459 register a new user which is 86 00:03:34,860 --> 00:03:41,700 the AV team is the best thank you 87 00:03:38,099 --> 00:03:43,799 now uh I will now begin my registration 88 00:03:41,700 --> 00:03:45,900 in Safari and I get a slightly different 89 00:03:43,799 --> 00:03:48,120 prompt this time this time I'm prompted 90 00:03:45,900 --> 00:03:50,159 to save a pass key and I'm prompted for 91 00:03:48,120 --> 00:03:51,780 my fingerprint now I'm using a MacBook 92 00:03:50,159 --> 00:03:53,519 Pro so I'm going to touch the 93 00:03:51,780 --> 00:03:56,099 fingerprint reader it's going to 94 00:03:53,519 --> 00:03:58,500 register that fingerprint 95 00:03:56,099 --> 00:04:00,720 and I've now registered this credential 96 00:03:58,500 --> 00:04:02,519 now let's say that I've gone out and 97 00:04:00,720 --> 00:04:06,360 I've decided to go see my friend at 98 00:04:02,519 --> 00:04:08,340 honest Rob and his car explodium and I 99 00:04:06,360 --> 00:04:11,340 left my laptop at home and so I'm using 100 00:04:08,340 --> 00:04:13,019 one of his totally legitimate laptops so 101 00:04:11,340 --> 00:04:15,180 I want to authenticate so what I have 102 00:04:13,019 --> 00:04:17,940 here with me is I've got my phone which 103 00:04:15,180 --> 00:04:19,979 is also signed in with my Apple ID 104 00:04:17,940 --> 00:04:22,979 I'm going to select to authenticate 105 00:04:19,979 --> 00:04:25,800 and I'm going to pick other options 106 00:04:22,979 --> 00:04:28,080 and I'm going to select use my iPhone 107 00:04:25,800 --> 00:04:29,580 iPad or Android device which says user 108 00:04:28,080 --> 00:04:32,100 from a device with a camera 109 00:04:29,580 --> 00:04:34,199 select continue I'm going to open up the 110 00:04:32,100 --> 00:04:36,419 camera app on my phone 111 00:04:34,199 --> 00:04:38,220 scan that QR code 112 00:04:36,419 --> 00:04:40,020 and right now I'm getting a sign in 113 00:04:38,220 --> 00:04:42,360 prompt on my phone 114 00:04:40,020 --> 00:04:43,800 and in a moment I'll be asked for 115 00:04:42,360 --> 00:04:45,780 touching that and I wish which I'll 116 00:04:43,800 --> 00:04:48,120 touch now 117 00:04:45,780 --> 00:04:50,520 and once that touch is complete the 118 00:04:48,120 --> 00:04:52,440 authentication is now completed on the 119 00:04:50,520 --> 00:04:54,300 laptop which is really quite cool that I 120 00:04:52,440 --> 00:04:55,560 can use my phone to authenticate in that 121 00:04:54,300 --> 00:04:57,780 way 122 00:04:55,560 --> 00:05:01,919 so 123 00:04:57,780 --> 00:05:04,259 what did we just say how did that work 124 00:05:01,919 --> 00:05:06,120 what just came together to allow me to 125 00:05:04,259 --> 00:05:07,259 use these devices and authenticate in 126 00:05:06,120 --> 00:05:11,040 that way 127 00:05:07,259 --> 00:05:13,020 there are three parts in a web authen uh 128 00:05:11,040 --> 00:05:15,120 operation you have the relying party 129 00:05:13,020 --> 00:05:16,860 which is the web server or website which 130 00:05:15,120 --> 00:05:19,680 is hosting that service 131 00:05:16,860 --> 00:05:21,300 you have the client which is in this 132 00:05:19,680 --> 00:05:22,620 case it doesn't mean Google the client 133 00:05:21,300 --> 00:05:25,320 actually means your web browser that 134 00:05:22,620 --> 00:05:27,120 could be Chrome Safari or something else 135 00:05:25,320 --> 00:05:29,699 that has the capability of interacting 136 00:05:27,120 --> 00:05:31,440 with these devices and then you have the 137 00:05:29,699 --> 00:05:34,259 authenticator and this is the hardware 138 00:05:31,440 --> 00:05:35,699 secure element or cryptographic 139 00:05:34,259 --> 00:05:37,500 Authenticator 140 00:05:35,699 --> 00:05:39,120 which you have in your possession and 141 00:05:37,500 --> 00:05:41,639 you can interact with 142 00:05:39,120 --> 00:05:44,220 and these come together and there is a 143 00:05:41,639 --> 00:05:45,479 whole series of interactions which we 144 00:05:44,220 --> 00:05:47,460 aren't going to get into the complete 145 00:05:45,479 --> 00:05:50,820 nitty-gritty of today and all the exact 146 00:05:47,460 --> 00:05:53,520 details of how this works but the 147 00:05:50,820 --> 00:05:55,380 general overview is that within your web 148 00:05:53,520 --> 00:05:57,720 browser you initiate an authentication 149 00:05:55,380 --> 00:05:58,740 to the website which sends you back a 150 00:05:57,720 --> 00:06:00,720 challenge 151 00:05:58,740 --> 00:06:02,100 the challenge is then processed by the 152 00:06:00,720 --> 00:06:04,919 client and then sent into the 153 00:06:02,100 --> 00:06:07,380 authenticator the authenticator then you 154 00:06:04,919 --> 00:06:10,199 creates a signature and that signature 155 00:06:07,380 --> 00:06:11,820 is then sent back to your client your 156 00:06:10,199 --> 00:06:13,680 web browser where it is then passed back 157 00:06:11,820 --> 00:06:17,100 to relying party who validates that the 158 00:06:13,680 --> 00:06:20,100 authenticator was legitimate 159 00:06:17,100 --> 00:06:22,680 so at its core what we're talking about 160 00:06:20,100 --> 00:06:24,960 here is web authen being a form of 161 00:06:22,680 --> 00:06:26,759 public private key cryptography or 162 00:06:24,960 --> 00:06:27,900 asymmetric key cryptography and this is 163 00:06:26,759 --> 00:06:29,819 similar to 164 00:06:27,900 --> 00:06:33,500 past attempts at cryptographic 165 00:06:29,819 --> 00:06:36,840 authentication with things like PIV or 166 00:06:33,500 --> 00:06:38,880 smart cards now 167 00:06:36,840 --> 00:06:41,699 what happens is that we have a private 168 00:06:38,880 --> 00:06:44,100 key stored in our authenticator and we 169 00:06:41,699 --> 00:06:47,520 have some data that we wish to sign 170 00:06:44,100 --> 00:06:48,960 that private key can sign that data and 171 00:06:47,520 --> 00:06:50,759 create a signature 172 00:06:48,960 --> 00:06:52,680 and that signature can be sent to our 173 00:06:50,759 --> 00:06:56,280 relying party which has the public key 174 00:06:52,680 --> 00:06:59,340 it can then validate that public key and 175 00:06:56,280 --> 00:07:01,680 validate that signature sorry and assure 176 00:06:59,340 --> 00:07:05,460 and is assured that only that private 177 00:07:01,680 --> 00:07:08,639 key could have created that signature 178 00:07:05,460 --> 00:07:11,660 however knowing just the public key and 179 00:07:08,639 --> 00:07:14,580 given that data you cannot falsify or 180 00:07:11,660 --> 00:07:16,319 fake that signature 181 00:07:14,580 --> 00:07:18,660 this is really good because it means 182 00:07:16,319 --> 00:07:23,039 that if the relying party is compromised 183 00:07:18,660 --> 00:07:24,960 or exploited then the uh unlike a 184 00:07:23,039 --> 00:07:27,479 password which has to be stored either 185 00:07:24,960 --> 00:07:30,300 in plain text which is unfortunately all 186 00:07:27,479 --> 00:07:32,639 too common or a hash which can then be 187 00:07:30,300 --> 00:07:34,680 exploited in various ways 188 00:07:32,639 --> 00:07:36,360 knowledge of the public key and its 189 00:07:34,680 --> 00:07:38,699 exploit or publication 190 00:07:36,360 --> 00:07:39,780 does not weaken the security of you the 191 00:07:38,699 --> 00:07:41,699 user it doesn't have personal 192 00:07:39,780 --> 00:07:43,380 identifying information and someone 193 00:07:41,699 --> 00:07:45,000 can't go and then start impersonating 194 00:07:43,380 --> 00:07:47,460 you so this is really good because it 195 00:07:45,000 --> 00:07:49,319 means that private key really is yours 196 00:07:47,460 --> 00:07:52,380 it really means you are who you say you 197 00:07:49,319 --> 00:07:54,599 are and you are have a much stronger 198 00:07:52,380 --> 00:07:56,460 level of authentication and security as 199 00:07:54,599 --> 00:07:57,960 the user 200 00:07:56,460 --> 00:08:00,360 so 201 00:07:57,960 --> 00:08:02,039 the next question that I'm kind of 202 00:08:00,360 --> 00:08:05,160 preempting about pass keys and web 203 00:08:02,039 --> 00:08:08,580 authen here is are they multi-factor 204 00:08:05,160 --> 00:08:10,440 because as Security Professionals and 205 00:08:08,580 --> 00:08:12,060 Technology professionals we've been 206 00:08:10,440 --> 00:08:14,340 recommending people to move to 207 00:08:12,060 --> 00:08:15,599 multi-factor authentication for a long 208 00:08:14,340 --> 00:08:17,460 time 209 00:08:15,599 --> 00:08:19,080 and multi-factor authentication until 210 00:08:17,460 --> 00:08:22,319 this point 211 00:08:19,080 --> 00:08:25,740 has looked like a password combined with 212 00:08:22,319 --> 00:08:27,960 something like a trtp or it has been a 213 00:08:25,740 --> 00:08:29,520 password combined with our security Keys 214 00:08:27,960 --> 00:08:32,099 once again 215 00:08:29,520 --> 00:08:34,800 and these boil down to something we know 216 00:08:32,099 --> 00:08:36,959 and something that we have 217 00:08:34,800 --> 00:08:39,719 so how are we now taking this device 218 00:08:36,959 --> 00:08:41,219 which was previously a single factor and 219 00:08:39,719 --> 00:08:43,919 turning it into both something that we 220 00:08:41,219 --> 00:08:46,980 know and have we are now making it the 221 00:08:43,919 --> 00:08:48,899 sole multi-factor Authenticator 222 00:08:46,980 --> 00:08:50,519 and how this works comes from that 223 00:08:48,899 --> 00:08:52,620 element of the demo which I showed you 224 00:08:50,519 --> 00:08:55,740 where that pin was requested 225 00:08:52,620 --> 00:08:58,740 the browser actually contacts the device 226 00:08:55,740 --> 00:09:01,560 over USB and in that request actually 227 00:08:58,740 --> 00:09:03,060 sends the pin that you typed in into the 228 00:09:01,560 --> 00:09:05,880 Authenticator 229 00:09:03,060 --> 00:09:07,740 the authenticator validates that pin is 230 00:09:05,880 --> 00:09:10,019 correct and if that pin is not correct 231 00:09:07,740 --> 00:09:12,000 it will not proceed only if that pin is 232 00:09:10,019 --> 00:09:13,920 correct will it proceed and then it 233 00:09:12,000 --> 00:09:15,480 waits for interaction so I have to 234 00:09:13,920 --> 00:09:16,860 physically touch the device if this was 235 00:09:15,480 --> 00:09:18,899 malware or someone's remotely 236 00:09:16,860 --> 00:09:20,760 controlling my computer they can't fake 237 00:09:18,899 --> 00:09:23,339 that interaction on my machine I have to 238 00:09:20,760 --> 00:09:25,560 be physically at the device and have 239 00:09:23,339 --> 00:09:28,080 been the one who put in that PIN 240 00:09:25,560 --> 00:09:30,860 this interaction and pin verification 241 00:09:28,080 --> 00:09:33,420 are all embedded into the signed result 242 00:09:30,860 --> 00:09:36,120 and that signature is then released so 243 00:09:33,420 --> 00:09:37,920 we now have a cryptographic proof that I 244 00:09:36,120 --> 00:09:40,740 have not only touched the device but 245 00:09:37,920 --> 00:09:42,899 I've also am the one who interacted with 246 00:09:40,740 --> 00:09:45,000 it so this is how we get a very strong 247 00:09:42,899 --> 00:09:47,220 Assurance with web authen and pass keys 248 00:09:45,000 --> 00:09:49,500 that it is not just someone in 249 00:09:47,220 --> 00:09:51,959 possession of this device but it is me 250 00:09:49,500 --> 00:09:53,880 or the owner of that device who is in 251 00:09:51,959 --> 00:09:56,100 possession 252 00:09:53,880 --> 00:09:58,860 this this is very similar with Touch ID 253 00:09:56,100 --> 00:10:01,320 on machines that have it or your phone 254 00:09:58,860 --> 00:10:04,140 is that when the request is sent into 255 00:10:01,320 --> 00:10:06,120 the device the fingerprint is requested 256 00:10:04,140 --> 00:10:07,740 on the device and you when you put your 257 00:10:06,120 --> 00:10:09,420 fingerprint on the reader 258 00:10:07,740 --> 00:10:11,399 the act of putting your finger on the 259 00:10:09,420 --> 00:10:14,760 reader is not only the interaction that 260 00:10:11,399 --> 00:10:17,040 is required to prevent malware but it is 261 00:10:14,760 --> 00:10:19,380 also validating the Biometrics of your 262 00:10:17,040 --> 00:10:20,880 fingerprint at that point depending on 263 00:10:19,380 --> 00:10:23,399 the type of Hardware I know that with 264 00:10:20,880 --> 00:10:24,600 Apple devices the fingerprint reader 265 00:10:23,399 --> 00:10:26,399 isn't actually connect to your operating 266 00:10:24,600 --> 00:10:28,380 system it's actually connected into the 267 00:10:26,399 --> 00:10:30,899 secure Enclave so the fingerprint can't 268 00:10:28,380 --> 00:10:32,880 be falsified by the operating system or 269 00:10:30,899 --> 00:10:35,519 even captured and that fingerprint data 270 00:10:32,880 --> 00:10:39,540 never leaves the device 271 00:10:35,519 --> 00:10:42,839 these again these um data are embedded 272 00:10:39,540 --> 00:10:45,000 in the user verification uh elements and 273 00:10:42,839 --> 00:10:46,320 that signature is released 274 00:10:45,000 --> 00:10:48,899 so 275 00:10:46,320 --> 00:10:50,820 in that demo I did what looked a little 276 00:10:48,899 --> 00:10:53,160 bit like a magic trick where the phone 277 00:10:50,820 --> 00:10:56,880 authenticated me 278 00:10:53,160 --> 00:10:58,620 and I think that this is one of the more 279 00:10:56,880 --> 00:11:00,480 interesting parts of web authenia is 280 00:10:58,620 --> 00:11:02,579 that until this point we've we've 281 00:11:00,480 --> 00:11:04,860 generally thought about things like uber 282 00:11:02,579 --> 00:11:07,019 keys or security Keys as being a single 283 00:11:04,860 --> 00:11:08,640 device and the keys are stored within 284 00:11:07,019 --> 00:11:12,660 that device 285 00:11:08,640 --> 00:11:14,579 and you know not all devices can work 286 00:11:12,660 --> 00:11:17,399 with with web orthan and there's a lot 287 00:11:14,579 --> 00:11:18,959 of things that have improved with Fido 288 00:11:17,399 --> 00:11:21,779 to make these single device credentials 289 00:11:18,959 --> 00:11:25,500 be able to support pins and other things 290 00:11:21,779 --> 00:11:26,040 but with my phone I 291 00:11:25,500 --> 00:11:28,500 um 292 00:11:26,040 --> 00:11:30,420 uh what Apple has done and what other 293 00:11:28,500 --> 00:11:32,220 providers will do such as Google or 294 00:11:30,420 --> 00:11:34,380 Microsoft is they are creating what is 295 00:11:32,220 --> 00:11:36,540 called a Multi-Device credential and 296 00:11:34,380 --> 00:11:38,399 that is where the private keys are 297 00:11:36,540 --> 00:11:41,339 synchronized between your devices so in 298 00:11:38,399 --> 00:11:43,800 my demo when I enrolled that device the 299 00:11:41,339 --> 00:11:45,660 private key that was generated for this 300 00:11:43,800 --> 00:11:48,660 website that was on my Mac was then 301 00:11:45,660 --> 00:11:50,940 encrypted put into the iCloud keychain 302 00:11:48,660 --> 00:11:53,100 and then only other devices in my 303 00:11:50,940 --> 00:11:55,200 account can download decrypt that 304 00:11:53,100 --> 00:11:57,420 private key and then use it and that is 305 00:11:55,200 --> 00:11:58,680 how then my phone also had access to 306 00:11:57,420 --> 00:12:01,140 that private key 307 00:11:58,680 --> 00:12:03,300 to then perform that authentication so 308 00:12:01,140 --> 00:12:05,760 when I scan that QR code what has 309 00:12:03,300 --> 00:12:08,160 occurred is that the QR code has 310 00:12:05,760 --> 00:12:09,959 prompted a Bluetooth low energy 311 00:12:08,160 --> 00:12:12,180 connection to my phone which has then 312 00:12:09,959 --> 00:12:13,620 allowed my phone to complete the rest of 313 00:12:12,180 --> 00:12:15,420 the authentication and send the 314 00:12:13,620 --> 00:12:17,040 necessary data and signatures back to 315 00:12:15,420 --> 00:12:18,899 the browser 316 00:12:17,040 --> 00:12:21,180 so because of this Multi-Device 317 00:12:18,899 --> 00:12:23,279 credential nature that we've now started 318 00:12:21,180 --> 00:12:24,660 to see from vendors which is very useful 319 00:12:23,279 --> 00:12:27,000 for many people 320 00:12:24,660 --> 00:12:28,140 is the second definition of what is a 321 00:12:27,000 --> 00:12:30,899 pass key 322 00:12:28,140 --> 00:12:33,540 and this is that pass keys are a 323 00:12:30,899 --> 00:12:37,320 synchronized credential so this 324 00:12:33,540 --> 00:12:38,880 definition became popular soon after the 325 00:12:37,320 --> 00:12:41,399 Apple announcement of what past keys 326 00:12:38,880 --> 00:12:43,380 were and this is still used by many 327 00:12:41,399 --> 00:12:45,180 services today there are many websites 328 00:12:43,380 --> 00:12:47,519 and services which still refer to pass 329 00:12:45,180 --> 00:12:49,920 Keys as these synchronized credentials 330 00:12:47,519 --> 00:12:53,600 as opposed to these single device 331 00:12:49,920 --> 00:12:53,600 credentials like your UB key 332 00:12:54,120 --> 00:12:58,920 so we've got these great credentials 333 00:12:56,399 --> 00:13:01,860 they are cryptographic they're very 334 00:12:58,920 --> 00:13:03,480 secure they can be synchronized they 335 00:13:01,860 --> 00:13:05,639 might be stored they're generally stored 336 00:13:03,480 --> 00:13:07,620 on a secure Enclave the next question is 337 00:13:05,639 --> 00:13:10,380 can they be fished and this is really 338 00:13:07,620 --> 00:13:13,079 important because phishing is one of 339 00:13:10,380 --> 00:13:15,120 those attacks that's very endemic and it 340 00:13:13,079 --> 00:13:16,920 has been the cause of many high-profile 341 00:13:15,120 --> 00:13:18,540 breaches that you are likely aware of 342 00:13:16,920 --> 00:13:21,300 and 343 00:13:18,540 --> 00:13:24,060 we need to you know if we are going to 344 00:13:21,300 --> 00:13:27,899 improve authentication we need to get 345 00:13:24,060 --> 00:13:30,540 past phishing this is a a huge problem 346 00:13:27,899 --> 00:13:32,940 today things like passwords and totp can 347 00:13:30,540 --> 00:13:34,380 still be fished in real time and then 348 00:13:32,940 --> 00:13:35,760 replayed immediately to the Target 349 00:13:34,380 --> 00:13:39,240 website 350 00:13:35,760 --> 00:13:42,240 so to understand phishing resistance in 351 00:13:39,240 --> 00:13:44,579 web authen we need to come back to 352 00:13:42,240 --> 00:13:47,040 our workflow and understand the 353 00:13:44,579 --> 00:13:49,440 interactions that are occurring here 354 00:13:47,040 --> 00:13:52,380 in fact the step That Matters to prevent 355 00:13:49,440 --> 00:13:54,420 fishing within web authen and pass Keys 356 00:13:52,380 --> 00:13:56,360 is at this stage here between the 357 00:13:54,420 --> 00:13:58,440 collected client data from the browser 358 00:13:56,360 --> 00:14:01,040 and how it is sent into the 359 00:13:58,440 --> 00:14:01,040 Authenticator 360 00:14:02,000 --> 00:14:07,440 the data that is sent into the 361 00:14:04,980 --> 00:14:08,519 authenticator is actually taken from two 362 00:14:07,440 --> 00:14:10,500 sources 363 00:14:08,519 --> 00:14:13,079 the first source of data is this 364 00:14:10,500 --> 00:14:15,600 credential request options this includes 365 00:14:13,079 --> 00:14:17,700 the relying party identifier which is a 366 00:14:15,600 --> 00:14:19,380 part of the DNS or the domain name of 367 00:14:17,700 --> 00:14:20,820 the website that you are visiting so 368 00:14:19,380 --> 00:14:23,160 this is what the relying party is 369 00:14:20,820 --> 00:14:26,100 telling you that its domain name is 370 00:14:23,160 --> 00:14:28,620 but the second part is the origin and 371 00:14:26,100 --> 00:14:30,420 this origin is actually not collected 372 00:14:28,620 --> 00:14:33,420 from the relying party it's collected 373 00:14:30,420 --> 00:14:35,760 from our web browser so this means that 374 00:14:33,420 --> 00:14:37,980 we have now in our collector client data 375 00:14:35,760 --> 00:14:39,600 a true and realistic view of what the 376 00:14:37,980 --> 00:14:43,920 user is seeing so it doesn't matter if 377 00:14:39,600 --> 00:14:45,480 it's a a homonym attack or similar just 378 00:14:43,920 --> 00:14:47,820 because it can trick a person we are 379 00:14:45,480 --> 00:14:50,220 embedding the exact set of bytes of that 380 00:14:47,820 --> 00:14:53,279 domain name into this collected client 381 00:14:50,220 --> 00:14:56,940 data that will be signed 382 00:14:53,279 --> 00:14:59,279 so these data are then uh hashed and 383 00:14:56,940 --> 00:15:01,079 then sent into the authenticator which 384 00:14:59,279 --> 00:15:03,240 will sign these as part of its 385 00:15:01,079 --> 00:15:05,339 verification data and then these are 386 00:15:03,240 --> 00:15:09,320 sent back to the relying party for 387 00:15:05,339 --> 00:15:12,180 validation so to put this in 388 00:15:09,320 --> 00:15:15,839 uh a theoretical attack scenario let's 389 00:15:12,180 --> 00:15:18,779 say that I go to totally legitimate uh 390 00:15:15,839 --> 00:15:21,360 Rob's honest cars website.com 391 00:15:18,779 --> 00:15:24,000 which is trying to fish me for my 392 00:15:21,360 --> 00:15:26,100 corporate account and I've fallen for 393 00:15:24,000 --> 00:15:28,560 the email which happens to any of us we 394 00:15:26,100 --> 00:15:30,000 are all human and I've gone to this 395 00:15:28,560 --> 00:15:32,339 domain and I haven't noticed that it's 396 00:15:30,000 --> 00:15:35,399 totally dodgy.com 397 00:15:32,339 --> 00:15:37,139 as I've performed this signature the 398 00:15:35,399 --> 00:15:38,579 signature and the origin that's in this 399 00:15:37,139 --> 00:15:41,279 collected client data says totally 400 00:15:38,579 --> 00:15:43,440 dodgy.com and I've signed that and 401 00:15:41,279 --> 00:15:44,940 that's fine because if the website 402 00:15:43,440 --> 00:15:46,500 that's trying to fish me forwards this 403 00:15:44,940 --> 00:15:48,360 signature to the legitimate corporate 404 00:15:46,500 --> 00:15:49,380 site it will check that signature and 405 00:15:48,360 --> 00:15:51,779 say yes this really is Williams 406 00:15:49,380 --> 00:15:53,940 authenticator but that domain name is 407 00:15:51,779 --> 00:15:56,040 wrong so I'm going to refuse to allow 408 00:15:53,940 --> 00:15:58,079 this authentication to proceed because 409 00:15:56,040 --> 00:16:00,839 this is clearly a phishing attack and 410 00:15:58,079 --> 00:16:02,940 that can actually be signaled and uh 411 00:16:00,839 --> 00:16:04,320 used to determine if if there are 412 00:16:02,940 --> 00:16:06,000 further indicators or compromise that 413 00:16:04,320 --> 00:16:08,100 you need to follow up 414 00:16:06,000 --> 00:16:09,779 and this is so important to to really 415 00:16:08,100 --> 00:16:11,639 stress this that 416 00:16:09,779 --> 00:16:13,260 web authenia is not able to be phished 417 00:16:11,639 --> 00:16:15,120 because of these properties the relying 418 00:16:13,260 --> 00:16:16,920 party ID must be part of the effective 419 00:16:15,120 --> 00:16:19,260 domain or the origin of the website that 420 00:16:16,920 --> 00:16:21,120 you're accessing the origin comes from 421 00:16:19,260 --> 00:16:23,040 the browser not the relying party which 422 00:16:21,120 --> 00:16:24,540 means that it's much harder to actually 423 00:16:23,040 --> 00:16:26,880 tamper with 424 00:16:24,540 --> 00:16:28,620 the signature contains both the origin 425 00:16:26,880 --> 00:16:33,060 and relying party ID so we have a 426 00:16:28,620 --> 00:16:34,740 cryptographic Assurance on the uh of 427 00:16:33,060 --> 00:16:35,880 what the user is actually seeing and 428 00:16:34,740 --> 00:16:39,060 accessing 429 00:16:35,880 --> 00:16:40,500 and you know where this comes back to 430 00:16:39,060 --> 00:16:43,019 that phishing thing is that those synced 431 00:16:40,500 --> 00:16:45,839 credentials still do rely on the 432 00:16:43,019 --> 00:16:48,660 security of the identity provider that 433 00:16:45,839 --> 00:16:51,060 backs them so the security of a Yuba key 434 00:16:48,660 --> 00:16:52,680 is about physical possession the 435 00:16:51,060 --> 00:16:54,600 security of your Apple credentials is 436 00:16:52,680 --> 00:16:57,360 about the security of your Apple ID 437 00:16:54,600 --> 00:16:59,699 account password and second Factor Apple 438 00:16:57,360 --> 00:17:01,800 do require 2fa for those credentials 439 00:16:59,699 --> 00:17:03,240 other providers may or may not we don't 440 00:17:01,800 --> 00:17:05,459 know 441 00:17:03,240 --> 00:17:07,199 so this is great we've got these 442 00:17:05,459 --> 00:17:09,059 unfishable credentials they're very 443 00:17:07,199 --> 00:17:10,980 secure there's cryptographic auth it's 444 00:17:09,059 --> 00:17:13,260 it's very easy to use 445 00:17:10,980 --> 00:17:15,179 I want to start enrolling it well what 446 00:17:13,260 --> 00:17:17,660 if I run out of keys how many sites can 447 00:17:15,179 --> 00:17:17,660 this work with 448 00:17:18,540 --> 00:17:22,380 so 449 00:17:19,860 --> 00:17:25,079 we want to empower our users to be able 450 00:17:22,380 --> 00:17:26,640 to use these keys without to with 451 00:17:25,079 --> 00:17:29,700 Reckless abandon 452 00:17:26,640 --> 00:17:32,520 and the answer is you can use this on an 453 00:17:29,700 --> 00:17:34,679 infinite number of sites 454 00:17:32,520 --> 00:17:38,179 but there is an asterisk here 455 00:17:34,679 --> 00:17:38,179 the asterisks is a pretty big one 456 00:17:38,340 --> 00:17:42,000 the way that we allow these credentials 457 00:17:40,200 --> 00:17:45,360 to work with an infinite number of sites 458 00:17:42,000 --> 00:17:47,280 happens at this stage when we first have 459 00:17:45,360 --> 00:17:49,260 our browser initiate the authentication 460 00:17:47,280 --> 00:17:52,140 from our relying party 461 00:17:49,260 --> 00:17:54,179 and so what happens at this stage to 462 00:17:52,140 --> 00:17:56,880 allow this infinite set of credentials 463 00:17:54,179 --> 00:17:58,559 is that when we go to the brow when we 464 00:17:56,880 --> 00:18:00,539 when our client says Hey I want to log 465 00:17:58,559 --> 00:18:03,179 in as William 466 00:18:00,539 --> 00:18:05,280 the relying party says okay cool here's 467 00:18:03,179 --> 00:18:07,260 the list of credential IDs that William 468 00:18:05,280 --> 00:18:11,160 has ever logged in with and these 469 00:18:07,260 --> 00:18:14,039 credential IDs are this base64 blob and 470 00:18:11,160 --> 00:18:16,080 these base64 blobs are actually an 471 00:18:14,039 --> 00:18:17,940 encrypted blob and these encrypted blobs 472 00:18:16,080 --> 00:18:19,440 are encrypted with the internal primary 473 00:18:17,940 --> 00:18:22,440 key of your device and they are 474 00:18:19,440 --> 00:18:23,580 encrypted with AES and if your 475 00:18:22,440 --> 00:18:25,860 Authenticator 476 00:18:23,580 --> 00:18:28,500 can decrypt that it now has the real 477 00:18:25,860 --> 00:18:30,960 true private key in memory and can then 478 00:18:28,500 --> 00:18:33,480 use that private key for cryptographic 479 00:18:30,960 --> 00:18:35,940 operations such as web authen 480 00:18:33,480 --> 00:18:37,980 now if you happen to have a different 481 00:18:35,940 --> 00:18:40,320 Yuba key and it's not the one that 482 00:18:37,980 --> 00:18:43,140 actually created those blobs 483 00:18:40,320 --> 00:18:44,460 and you try to decrypt them the blob 484 00:18:43,140 --> 00:18:47,880 will fail to decrypt and it will fail 485 00:18:44,460 --> 00:18:50,520 it's hmac and the private key will not 486 00:18:47,880 --> 00:18:53,880 be accessible meaning that you cannot 487 00:18:50,520 --> 00:18:55,620 continue or Forge that now the 488 00:18:53,880 --> 00:18:57,720 frequently Asked question at this point 489 00:18:55,620 --> 00:18:59,640 is is this somehow less secure because 490 00:18:57,720 --> 00:19:02,280 you are exposing these credential IDs 491 00:18:59,640 --> 00:19:04,980 when someone prompts for a username and 492 00:19:02,280 --> 00:19:07,799 the answer is no these are encrypted 493 00:19:04,980 --> 00:19:09,960 with the as128 they are hmac so if 494 00:19:07,799 --> 00:19:11,700 someone is able to decrypt these then we 495 00:19:09,960 --> 00:19:13,380 have very significant problems in the 496 00:19:11,700 --> 00:19:15,539 security of cryptography on the internet 497 00:19:13,380 --> 00:19:18,059 as a whole 498 00:19:15,539 --> 00:19:19,860 this style of key where the key is 499 00:19:18,059 --> 00:19:22,140 ephemeral and 500 00:19:19,860 --> 00:19:25,020 decrypted out of the internal primary 501 00:19:22,140 --> 00:19:28,500 key is called a non-discoverable or a 502 00:19:25,020 --> 00:19:30,360 non-resident key or internally a key 503 00:19:28,500 --> 00:19:32,160 wrapped key 504 00:19:30,360 --> 00:19:34,380 of course 505 00:19:32,160 --> 00:19:36,720 the word non-discoverable here or 506 00:19:34,380 --> 00:19:40,679 non-resident key implies the existence 507 00:19:36,720 --> 00:19:44,700 of discoverable keys or resident keys 508 00:19:40,679 --> 00:19:46,980 a resident key or a discoverable key is 509 00:19:44,700 --> 00:19:48,780 a key that's stored inside the limited 510 00:19:46,980 --> 00:19:51,900 storage of the device 511 00:19:48,780 --> 00:19:53,340 and when you request a user from when 512 00:19:51,900 --> 00:19:56,400 you request an authentication from a 513 00:19:53,340 --> 00:19:58,080 website where you have this setup a 514 00:19:56,400 --> 00:20:00,360 blank credential ID list will be 515 00:19:58,080 --> 00:20:01,919 provided to you so in the presence of no 516 00:20:00,360 --> 00:20:03,900 credential IDs 517 00:20:01,919 --> 00:20:05,700 your authenticator goes okay well I now 518 00:20:03,900 --> 00:20:07,260 need to discover which Keys could be 519 00:20:05,700 --> 00:20:09,600 used here I haven't been given that list 520 00:20:07,260 --> 00:20:11,820 I need to work it out it then 521 00:20:09,600 --> 00:20:14,039 investigates which set of private Keys 522 00:20:11,820 --> 00:20:16,559 it has and it matches up the relying 523 00:20:14,039 --> 00:20:18,900 party ID with the private Keys it has 524 00:20:16,559 --> 00:20:20,700 and then offers them as Choice choices 525 00:20:18,900 --> 00:20:22,620 for the user to use 526 00:20:20,700 --> 00:20:24,419 now of course because we are now storing 527 00:20:22,620 --> 00:20:26,340 these within the device and we have that 528 00:20:24,419 --> 00:20:28,260 storage available we can embed little 529 00:20:26,340 --> 00:20:30,960 bits of metadata such as the user's 530 00:20:28,260 --> 00:20:32,820 unique ID or the user's display name so 531 00:20:30,960 --> 00:20:36,679 that we can present this to the user in 532 00:20:32,820 --> 00:20:36,679 an authentication selection dialog 533 00:20:36,840 --> 00:20:42,000 the problem here is that with many moles 534 00:20:39,720 --> 00:20:44,760 of keys Unfortunately they support this 535 00:20:42,000 --> 00:20:47,340 many credentials and this is a blank 536 00:20:44,760 --> 00:20:49,380 slide because they don't support any so 537 00:20:47,340 --> 00:20:50,640 there are some devices which can't store 538 00:20:49,380 --> 00:20:52,679 data 539 00:20:50,640 --> 00:20:56,280 some devices have very limited storage 540 00:20:52,679 --> 00:21:01,860 they can only store eight resident keys 541 00:20:56,280 --> 00:21:04,380 yubikes are support generally about 32. 542 00:21:01,860 --> 00:21:07,440 some devices have near infinite storage 543 00:21:04,380 --> 00:21:09,600 such as a laptop or a phone where the 544 00:21:07,440 --> 00:21:11,940 storage of private of these private keys 545 00:21:09,600 --> 00:21:14,880 and being discoverable or resident is 546 00:21:11,940 --> 00:21:17,460 bound by the size of the nvme drive 547 00:21:14,880 --> 00:21:20,340 within that machine 548 00:21:17,460 --> 00:21:22,160 so this is really cools the the key 549 00:21:20,340 --> 00:21:24,419 storage you know 550 00:21:22,160 --> 00:21:26,640 can be infinite for some things which 551 00:21:24,419 --> 00:21:28,380 means that we can store those usernames 552 00:21:26,640 --> 00:21:30,000 and have that little bit of metadata for 553 00:21:28,380 --> 00:21:31,200 making some of our workflows a little 554 00:21:30,000 --> 00:21:33,179 bit nicer 555 00:21:31,200 --> 00:21:35,580 but we also have a lot of key stories 556 00:21:33,179 --> 00:21:37,860 that is finite 0 to 32 is the common 557 00:21:35,580 --> 00:21:39,780 numbers and unfortunately as a relying 558 00:21:37,860 --> 00:21:42,600 party you can't probe for that storage 559 00:21:39,780 --> 00:21:46,500 capability before or during that request 560 00:21:42,600 --> 00:21:48,659 you either can request it or you can't 561 00:21:46,500 --> 00:21:50,640 and unfortunately some devices such as 562 00:21:48,659 --> 00:21:54,000 ctap2 can never delete or change a key 563 00:21:50,640 --> 00:21:55,520 and this has some very uh negative 564 00:21:54,000 --> 00:21:58,740 impacts on 565 00:21:55,520 --> 00:22:01,020 transgender or community members or 566 00:21:58,740 --> 00:22:03,120 women because they may not be able to 567 00:22:01,020 --> 00:22:04,919 update or change their personal 568 00:22:03,120 --> 00:22:09,840 identifying information in these devices 569 00:22:04,919 --> 00:22:12,419 without a very uh very weird and ex not 570 00:22:09,840 --> 00:22:14,340 obvious user workflow that I only 571 00:22:12,419 --> 00:22:16,919 learned about yesterday 572 00:22:14,340 --> 00:22:17,880 but of course the problem is the bigger 573 00:22:16,919 --> 00:22:19,440 problem there is of course you can't 574 00:22:17,880 --> 00:22:21,419 delete a key so once you fill up your 575 00:22:19,440 --> 00:22:23,039 storage that's it you you can't delete a 576 00:22:21,419 --> 00:22:25,320 key that you no longer use 577 00:22:23,039 --> 00:22:28,020 so unfortunately we have to assume right 578 00:22:25,320 --> 00:22:30,299 now that we have finite and you know 579 00:22:28,020 --> 00:22:32,100 Keys can't be deleted out of storage 580 00:22:30,299 --> 00:22:34,320 which means that we can't really request 581 00:22:32,100 --> 00:22:37,940 resident keys at the risk of damaging 582 00:22:34,320 --> 00:22:37,940 people's security keys 583 00:22:38,460 --> 00:22:42,000 this leads us however to our third 584 00:22:40,140 --> 00:22:45,000 definition which has become more 585 00:22:42,000 --> 00:22:48,840 recently popular and that is that people 586 00:22:45,000 --> 00:22:50,460 Define pass Keys as resident keys now 587 00:22:48,840 --> 00:22:52,679 for the reasons I've just described I 588 00:22:50,460 --> 00:22:54,360 don't like this definition because while 589 00:22:52,679 --> 00:22:56,520 resident Keys have some really fun 590 00:22:54,360 --> 00:22:58,020 properties with username autocomplete 591 00:22:56,520 --> 00:22:59,700 and discoverability and being able to 592 00:22:58,020 --> 00:23:01,799 sit in your keychain and some other 593 00:22:59,700 --> 00:23:03,840 things like that the problem is is that 594 00:23:01,799 --> 00:23:06,500 by requesting them or forcing them 595 00:23:03,840 --> 00:23:09,000 outside of just opportunistic existence 596 00:23:06,500 --> 00:23:12,179 we do have potential harms against 597 00:23:09,000 --> 00:23:14,700 people and I don't think that's okay 598 00:23:12,179 --> 00:23:16,919 so great okay we've now talked about 599 00:23:14,700 --> 00:23:18,900 these Keys how they're stored they're 600 00:23:16,919 --> 00:23:20,940 secure they've got multi-factor that's 601 00:23:18,900 --> 00:23:23,039 great how can I use these in my website 602 00:23:20,940 --> 00:23:24,480 you know you're I I bet everyone at home 603 00:23:23,039 --> 00:23:26,760 right now is just jumping up and down 604 00:23:24,480 --> 00:23:30,360 with excitement and itching to go 605 00:23:26,760 --> 00:23:33,059 wanting to use and deploy these 606 00:23:30,360 --> 00:23:35,220 this is my obligatory warning 607 00:23:33,059 --> 00:23:37,740 writing your own cryptographic code is 608 00:23:35,220 --> 00:23:39,780 great fun and it's a really wonderful 609 00:23:37,740 --> 00:23:42,120 educational experience if you want to 610 00:23:39,780 --> 00:23:44,880 learn the internals of how cryptography 611 00:23:42,120 --> 00:23:46,200 or security systems work please write 612 00:23:44,880 --> 00:23:48,659 that code 613 00:23:46,200 --> 00:23:51,000 but there is a big gap between writing 614 00:23:48,659 --> 00:23:53,940 that code for Education and Fun to 615 00:23:51,000 --> 00:23:56,159 production once you jump into production 616 00:23:53,940 --> 00:23:59,280 there are many more risks and threats 617 00:23:56,159 --> 00:24:01,500 and issues that you need to consider and 618 00:23:59,280 --> 00:24:03,780 while it is possible to learn these 619 00:24:01,500 --> 00:24:06,480 risks and what these considerations are 620 00:24:03,780 --> 00:24:08,220 it is still a big gap and it is one that 621 00:24:06,480 --> 00:24:09,900 you need to be aware of before you want 622 00:24:08,220 --> 00:24:12,059 to make that leap 623 00:24:09,900 --> 00:24:14,580 now I don't say this lightly I say this 624 00:24:12,059 --> 00:24:18,000 is someone who has probably a problem 625 00:24:14,580 --> 00:24:19,860 this is just a subset of my collection 626 00:24:18,000 --> 00:24:22,500 of security Keys I've spent a lot of 627 00:24:19,860 --> 00:24:25,140 time with um 628 00:24:22,500 --> 00:24:27,720 this standard and this library and with 629 00:24:25,140 --> 00:24:29,659 the co-authors of of the web authen rust 630 00:24:27,720 --> 00:24:33,179 Library working on 631 00:24:29,659 --> 00:24:35,220 this on web authen and there are many 632 00:24:33,179 --> 00:24:38,220 gaps in this standard and I mean this 633 00:24:35,220 --> 00:24:41,520 standard is 164 pages long and I've 634 00:24:38,220 --> 00:24:44,880 probably read all of it the spec for web 635 00:24:41,520 --> 00:24:47,280 authen is trying to solve many use cases 636 00:24:44,880 --> 00:24:49,620 it's trying to solve all of these 637 00:24:47,280 --> 00:24:51,720 different problems in one spec so if you 638 00:24:49,620 --> 00:24:53,940 have if you have a narrow use case like 639 00:24:51,720 --> 00:24:56,400 pass keys or I just want cryptographic 640 00:24:53,940 --> 00:24:59,220 auth it can be hard to navigate through 641 00:24:56,400 --> 00:25:01,919 this complex spec to find how to make 642 00:24:59,220 --> 00:25:05,059 that secure use case exist Within These 643 00:25:01,919 --> 00:25:05,059 164 pages 644 00:25:06,179 --> 00:25:10,260 very prescriptive if you go sit down and 645 00:25:08,640 --> 00:25:11,520 write your own implementation you'll 646 00:25:10,260 --> 00:25:14,640 probably end up with a pretty good web 647 00:25:11,520 --> 00:25:17,580 authen library but there are those gaps 648 00:25:14,640 --> 00:25:20,280 and we do want to give the best secure 649 00:25:17,580 --> 00:25:22,200 experience to our users so you do need 650 00:25:20,280 --> 00:25:24,779 to be careful 651 00:25:22,200 --> 00:25:27,120 some libraries as implemented represent 652 00:25:24,779 --> 00:25:29,100 the spec as it is 653 00:25:27,120 --> 00:25:30,960 which means that we need to as 654 00:25:29,100 --> 00:25:32,520 developers and implementers guide those 655 00:25:30,960 --> 00:25:34,679 libraries to make sure that we're aware 656 00:25:32,520 --> 00:25:35,880 of those gaps and we fill them over or 657 00:25:34,679 --> 00:25:37,679 plug them in 658 00:25:35,880 --> 00:25:41,460 some libraries are built around use 659 00:25:37,679 --> 00:25:43,679 cases and can actually wrap these up and 660 00:25:41,460 --> 00:25:45,419 have solved some of these gaps but of 661 00:25:43,679 --> 00:25:47,279 course it can be confusing with multiple 662 00:25:45,419 --> 00:25:49,740 Parts definitions of what a pass key is 663 00:25:47,279 --> 00:25:51,779 to know what they actually mean 664 00:25:49,740 --> 00:25:53,460 so this isn't an exhaustive list of web 665 00:25:51,779 --> 00:25:56,039 authen libraries this is just the few 666 00:25:53,460 --> 00:25:57,600 that I was able to find in the last uh a 667 00:25:56,039 --> 00:25:59,159 couple of days unfortunately I've been 668 00:25:57,600 --> 00:26:01,080 very busy and had a lot of uh personal 669 00:25:59,159 --> 00:26:03,480 things so I couldn't make a longer list 670 00:26:01,080 --> 00:26:06,419 but for rust there is the web authen 671 00:26:03,480 --> 00:26:09,000 rust Library which is a use case driven 672 00:26:06,419 --> 00:26:10,620 library and has the parsky definition as 673 00:26:09,000 --> 00:26:14,159 all possible authenticators 674 00:26:10,620 --> 00:26:16,559 the python library is very much a a very 675 00:26:14,159 --> 00:26:19,020 good well-written implementation and 676 00:26:16,559 --> 00:26:21,480 follows the specification very exactly 677 00:26:19,020 --> 00:26:23,760 and of course that means that we need to 678 00:26:21,480 --> 00:26:25,799 you know be aware of some of the traps 679 00:26:23,760 --> 00:26:28,380 like you know the examples list are 680 00:26:25,799 --> 00:26:30,720 resident key or RK is required so we 681 00:26:28,380 --> 00:26:32,100 need to change that to discouraged and 682 00:26:30,720 --> 00:26:33,659 there's some issues around its user 683 00:26:32,100 --> 00:26:35,159 verification handling in certain 684 00:26:33,659 --> 00:26:37,020 scenarios so we need to set user 685 00:26:35,159 --> 00:26:38,940 verification required as well to force 686 00:26:37,020 --> 00:26:42,539 that secure multi-factor authentication 687 00:26:38,940 --> 00:26:44,279 and the same is true of the Ruby Library 688 00:26:42,539 --> 00:26:47,059 if your language wasn't mentioned here 689 00:26:44,279 --> 00:26:50,700 and there is a very good chance it's not 690 00:26:47,059 --> 00:26:52,919 the general rules are can you set 691 00:26:50,700 --> 00:26:55,440 residency to discouraged or false we 692 00:26:52,919 --> 00:26:59,520 can't force resident keys because of the 693 00:26:55,440 --> 00:27:01,919 issues around key key permanency and key 694 00:26:59,520 --> 00:27:03,480 deletion that I mentioned before so we 695 00:27:01,919 --> 00:27:05,460 need to be able to set that 696 00:27:03,480 --> 00:27:07,140 is user verification preferred handle 697 00:27:05,460 --> 00:27:09,000 correctly now I didn't go over what the 698 00:27:07,140 --> 00:27:10,620 bugs are here but use verification 699 00:27:09,000 --> 00:27:12,240 preferred and discouraged are 700 00:27:10,620 --> 00:27:14,100 effectively equivalent unless the 701 00:27:12,240 --> 00:27:16,980 library has special security hardening 702 00:27:14,100 --> 00:27:18,360 in it most libraries if if they don't 703 00:27:16,980 --> 00:27:20,159 indicate that they have this and they 704 00:27:18,360 --> 00:27:21,720 probably don't you must set user 705 00:27:20,159 --> 00:27:23,700 verification required else your 706 00:27:21,720 --> 00:27:25,020 multi-factor devices are actually single 707 00:27:23,700 --> 00:27:27,000 Factor 708 00:27:25,020 --> 00:27:29,460 if you have strict security requirements 709 00:27:27,000 --> 00:27:32,059 such such as a Regulatory Compliance or 710 00:27:29,460 --> 00:27:35,340 other things you will need attestation 711 00:27:32,059 --> 00:27:37,440 attestation is not I'm not going to 712 00:27:35,340 --> 00:27:38,100 cover it too much in this 713 00:27:37,440 --> 00:27:39,659 um 714 00:27:38,100 --> 00:27:41,940 but it's basically a certificate of 715 00:27:39,659 --> 00:27:44,520 authenticity as to the manufacturer or 716 00:27:41,940 --> 00:27:46,980 origin of your device and it allows you 717 00:27:44,520 --> 00:27:48,659 to selectively enforce Which models or 718 00:27:46,980 --> 00:27:50,279 brands or devices are used in your 719 00:27:48,659 --> 00:27:51,960 relying party 720 00:27:50,279 --> 00:27:53,340 and finally when you're selecting your 721 00:27:51,960 --> 00:27:57,299 libraries don't let fighter 722 00:27:53,340 --> 00:27:58,980 certification be a barrier to whether 723 00:27:57,299 --> 00:28:00,900 you do or do not select a library 724 00:27:58,980 --> 00:28:03,299 fighter certification represents 725 00:28:00,900 --> 00:28:07,159 conformance to an API not a 726 00:28:03,299 --> 00:28:07,159 representation of security or quality 727 00:28:07,260 --> 00:28:11,159 so to summarize pass keys are a 728 00:28:09,900 --> 00:28:14,159 self-contained multi-factor 729 00:28:11,159 --> 00:28:16,380 Authenticator they can't be fished 730 00:28:14,159 --> 00:28:18,120 the Biometrics and pins can't be 731 00:28:16,380 --> 00:28:20,159 exfiltrated from the device they are 732 00:28:18,120 --> 00:28:22,679 contained within they require physical 733 00:28:20,159 --> 00:28:24,960 presence which helps to defeat malware 734 00:28:22,679 --> 00:28:26,940 key residency can unfortunately cause 735 00:28:24,960 --> 00:28:28,919 problems for our users who wish to 736 00:28:26,940 --> 00:28:30,659 choose which authenticators they want to 737 00:28:28,919 --> 00:28:32,460 use and bring 738 00:28:30,659 --> 00:28:35,159 sharp edges in the web authen 739 00:28:32,460 --> 00:28:37,020 specification means probably don't go 740 00:28:35,159 --> 00:28:38,220 down to Bunnings and believe it's a DIY 741 00:28:37,020 --> 00:28:39,960 job 742 00:28:38,220 --> 00:28:41,760 the libraries are still evolving and 743 00:28:39,960 --> 00:28:43,320 options that you as an implementer 744 00:28:41,760 --> 00:28:45,419 choose to use in those libraries 745 00:28:43,320 --> 00:28:46,860 probably need careful review and you 746 00:28:45,419 --> 00:28:48,299 will need to be empowered to assess 747 00:28:46,860 --> 00:28:50,400 things yourself and I hope that this 748 00:28:48,299 --> 00:28:52,559 talk has done so for you 749 00:28:50,400 --> 00:28:55,440 but finally pass keys are a secure and 750 00:28:52,559 --> 00:28:57,419 easy way for users to authenticate as 751 00:28:55,440 --> 00:28:59,520 well as yourself 752 00:28:57,419 --> 00:29:02,100 so your homework 753 00:28:59,520 --> 00:29:03,360 after this session is to go and 754 00:29:02,100 --> 00:29:04,559 Implement pass keys for your own 755 00:29:03,360 --> 00:29:06,840 websites 756 00:29:04,559 --> 00:29:08,760 from what you have learned today now I 757 00:29:06,840 --> 00:29:11,039 this assignment will be due by next 758 00:29:08,760 --> 00:29:13,919 everything open and I will be reviewing 759 00:29:11,039 --> 00:29:15,779 each website individually and of course 760 00:29:13,919 --> 00:29:17,340 if you would like to submit early please 761 00:29:15,779 --> 00:29:20,039 email me these 762 00:29:17,340 --> 00:29:22,440 my name is William Brown and you can 763 00:29:20,039 --> 00:29:26,460 contact me here thank you very much for 764 00:29:22,440 --> 00:29:28,320 listening to this and if I have time I 765 00:29:26,460 --> 00:29:31,679 am going to go through some questions 766 00:29:28,320 --> 00:29:32,700 from the talk session yesterday do I 767 00:29:31,679 --> 00:29:35,700 have time 768 00:29:32,700 --> 00:29:37,980 I need a nod hello from the back yep got 769 00:29:35,700 --> 00:29:39,659 time cool so uh what's happening right 770 00:29:37,980 --> 00:29:41,520 now is just that I am actually having to 771 00:29:39,659 --> 00:29:44,520 re-record the talk 772 00:29:41,520 --> 00:29:46,860 um because I created some technical 773 00:29:44,520 --> 00:29:48,419 chaos yesterday so yesterday when we had 774 00:29:46,860 --> 00:29:50,640 more audience members in front of me 775 00:29:48,419 --> 00:29:52,559 there were a number of questions that 776 00:29:50,640 --> 00:29:54,600 were presented by them and I think they 777 00:29:52,559 --> 00:29:57,539 were really good questions and I want to 778 00:29:54,600 --> 00:29:59,940 repeat them so they are not lost for the 779 00:29:57,539 --> 00:30:02,700 recording 780 00:29:59,940 --> 00:30:04,440 one of the questions was how can I 781 00:30:02,700 --> 00:30:06,419 prevent user enumeration I have a 782 00:30:04,440 --> 00:30:08,700 website where if I try to log in with a 783 00:30:06,419 --> 00:30:10,620 username and I get the credential ID 784 00:30:08,700 --> 00:30:12,720 list back I know that that user now 785 00:30:10,620 --> 00:30:13,919 exists if I log in with the user if I 786 00:30:12,720 --> 00:30:16,140 attempt to log in with a username that 787 00:30:13,919 --> 00:30:17,760 does not exist I get an empty credential 788 00:30:16,140 --> 00:30:20,279 ID list so I know that that user does 789 00:30:17,760 --> 00:30:23,279 not exist so the individual in question 790 00:30:20,279 --> 00:30:24,960 believed that that was a reason to you 791 00:30:23,279 --> 00:30:27,059 know use resonant keys and that is 792 00:30:24,960 --> 00:30:28,440 arguably a reason 793 00:30:27,059 --> 00:30:30,960 and 794 00:30:28,440 --> 00:30:33,299 user enumeration 795 00:30:30,960 --> 00:30:34,980 it was uh yesterday while I was 796 00:30:33,299 --> 00:30:36,720 answering the question in my head I said 797 00:30:34,980 --> 00:30:38,700 our user enumeration isn't a problem and 798 00:30:36,720 --> 00:30:40,260 then in within the 60 seconds of 799 00:30:38,700 --> 00:30:41,700 answering the question I realized that 800 00:30:40,260 --> 00:30:44,399 it actually was a problem in certain 801 00:30:41,700 --> 00:30:46,919 cases depending on metadata and privacy 802 00:30:44,399 --> 00:30:50,580 so to prevent user enumeration 803 00:30:46,919 --> 00:30:52,440 uh we we talked about this later and uh 804 00:30:50,580 --> 00:30:53,880 what we came up with was that you could 805 00:30:52,440 --> 00:30:55,500 actually take the username that was 806 00:30:53,880 --> 00:30:57,960 being presented and use that to false 807 00:30:55,500 --> 00:31:00,419 falsely generate credential IDs that 808 00:30:57,960 --> 00:31:02,760 look legitimate uh in a stable and 809 00:31:00,419 --> 00:31:04,620 repeatable way just to confuse attackers 810 00:31:02,760 --> 00:31:06,960 so they do not know if the credential ID 811 00:31:04,620 --> 00:31:08,820 is legitimate or not 812 00:31:06,960 --> 00:31:10,799 um so we I will probably write up a blog 813 00:31:08,820 --> 00:31:12,419 post on this and maybe extend webworth 814 00:31:10,799 --> 00:31:14,539 and rs with this as a feature in the 815 00:31:12,419 --> 00:31:14,539 future 816 00:31:14,880 --> 00:31:19,200 do browsers warn you before you create a 817 00:31:17,220 --> 00:31:20,820 resident key since I've just sat there 818 00:31:19,200 --> 00:31:22,380 and talked about how sometimes resident 819 00:31:20,820 --> 00:31:25,140 keys can cause problems for our security 820 00:31:22,380 --> 00:31:27,299 keys do we get a warning before one is 821 00:31:25,140 --> 00:31:29,700 created and the answer is no 822 00:31:27,299 --> 00:31:31,559 as I understand it browsers do not warn 823 00:31:29,700 --> 00:31:34,740 you before you create a resident key 824 00:31:31,559 --> 00:31:36,659 and unfortunately without you know we 825 00:31:34,740 --> 00:31:39,360 don't really have access to control the 826 00:31:36,659 --> 00:31:42,299 Chrome or Safari user interfaces we need 827 00:31:39,360 --> 00:31:44,279 to ask them to change their uis or 828 00:31:42,299 --> 00:31:46,260 change the behavior of how things like 829 00:31:44,279 --> 00:31:49,320 resident key preferred handles with 830 00:31:46,260 --> 00:31:52,140 security keys for this really to become 831 00:31:49,320 --> 00:31:54,960 a better user experience but it's also 832 00:31:52,140 --> 00:31:56,399 just one of those problems which it's 833 00:31:54,960 --> 00:31:58,860 very hard to communicate what the 834 00:31:56,399 --> 00:32:01,080 challenges are with resident Keys even 835 00:31:58,860 --> 00:32:04,799 within a text space let alone external 836 00:32:01,080 --> 00:32:07,440 to attack space and you know if giving 837 00:32:04,799 --> 00:32:09,360 users a secure and accessible method of 838 00:32:07,440 --> 00:32:11,340 authentication is our Focus 839 00:32:09,360 --> 00:32:13,559 we need to try and make that as easy as 840 00:32:11,340 --> 00:32:15,960 possible and trying to communicate these 841 00:32:13,559 --> 00:32:18,059 complex do you do not create a resident 842 00:32:15,960 --> 00:32:20,100 key or not is not really something 843 00:32:18,059 --> 00:32:23,340 that's going to help with this I've 844 00:32:20,100 --> 00:32:24,659 already seen some very bad uis I have a 845 00:32:23,340 --> 00:32:26,399 really good neighbor 846 00:32:24,659 --> 00:32:28,440 and she's a lovely person she's an 847 00:32:26,399 --> 00:32:30,899 accountant very intelligent 848 00:32:28,440 --> 00:32:33,960 and you know obviously outside of tech 849 00:32:30,899 --> 00:32:35,580 and I asked her to you know test the 850 00:32:33,960 --> 00:32:38,159 same websites that I demonstrated with 851 00:32:35,580 --> 00:32:40,080 her Android phone and it came up with 852 00:32:38,159 --> 00:32:41,820 you would like to create a security key 853 00:32:40,080 --> 00:32:43,380 please enroll your cryptographic 854 00:32:41,820 --> 00:32:44,940 security key would you like to log in 855 00:32:43,380 --> 00:32:46,559 and shoot a step back and just went whoa 856 00:32:44,940 --> 00:32:49,559 okay you know I 857 00:32:46,559 --> 00:32:51,299 I think I've just been hacked and 858 00:32:49,559 --> 00:32:52,740 you know if we have problems with 859 00:32:51,299 --> 00:32:54,419 communicating to people how to enroll 860 00:32:52,740 --> 00:32:56,760 their device their devices in the first 861 00:32:54,419 --> 00:32:58,200 place we're going to have much bigger 862 00:32:56,760 --> 00:33:00,240 challenges we're trying to communicate 863 00:32:58,200 --> 00:33:01,679 about the risks and positive the 864 00:33:00,240 --> 00:33:03,960 positives and negatives of Resident Keys 865 00:33:01,679 --> 00:33:05,220 basically on those devices to help them 866 00:33:03,960 --> 00:33:08,480 make informed choices so this 867 00:33:05,220 --> 00:33:08,480 communication is really difficult 868 00:33:09,179 --> 00:33:11,760 a question that we 've been something 869 00:33:10,140 --> 00:33:13,380 that was asked is so what are resident 870 00:33:11,760 --> 00:33:15,240 Keys good for if they're problematic 871 00:33:13,380 --> 00:33:17,340 then why are they used it all and when 872 00:33:15,240 --> 00:33:19,559 could I use them so resident keys do 873 00:33:17,340 --> 00:33:22,380 have good some good properties so 874 00:33:19,559 --> 00:33:26,220 uh one of the properties that is really 875 00:33:22,380 --> 00:33:28,440 good is that uh the way that the 876 00:33:26,220 --> 00:33:30,419 synchronized devices work so say your 877 00:33:28,440 --> 00:33:32,279 Apple iCloud or Android these are all 878 00:33:30,419 --> 00:33:35,039 resonant keys because of the way that 879 00:33:32,279 --> 00:33:37,260 those synchronization mechanisms work 880 00:33:35,039 --> 00:33:39,419 um they could in theory synchronize a 881 00:33:37,260 --> 00:33:41,460 internal shared primary key just the 882 00:33:39,419 --> 00:33:42,960 same way that ubiques have built in but 883 00:33:41,460 --> 00:33:46,200 they've chosen to synchronize the 884 00:33:42,960 --> 00:33:49,980 resident Keys instead so key residency 885 00:33:46,200 --> 00:33:52,140 can prompt for key synchronization on 886 00:33:49,980 --> 00:33:53,820 these platforms so Apple will always 887 00:33:52,140 --> 00:33:56,820 create a resident key no matter what you 888 00:33:53,820 --> 00:33:58,980 ask for so that it enforces that they 889 00:33:56,820 --> 00:34:01,440 are synchronized I believe that Android 890 00:33:58,980 --> 00:34:04,500 may not actually create a synchronized 891 00:34:01,440 --> 00:34:07,440 key in some cases but we've got to 892 00:34:04,500 --> 00:34:08,760 choose do we brick devices or do we make 893 00:34:07,440 --> 00:34:11,580 it so people just have to enroll their 894 00:34:08,760 --> 00:34:15,359 two phones I don't you know what's the 895 00:34:11,580 --> 00:34:18,659 more lasting harm versus the the benefit 896 00:34:15,359 --> 00:34:21,359 um there are some other use cases where 897 00:34:18,659 --> 00:34:24,480 the one of the use cases is username 898 00:34:21,359 --> 00:34:26,099 Auto completion and the thing is I do 899 00:34:24,480 --> 00:34:27,480 like yes it allows username Auto 900 00:34:26,099 --> 00:34:29,580 completion through a thing called 901 00:34:27,480 --> 00:34:31,560 conditional UI where you send the blank 902 00:34:29,580 --> 00:34:33,419 credential ID list and the user is 903 00:34:31,560 --> 00:34:34,740 prompted hey here are the credentials 904 00:34:33,419 --> 00:34:37,139 just for this website which one would 905 00:34:34,740 --> 00:34:39,060 you like to use and yeah it's a pretty 906 00:34:37,139 --> 00:34:41,520 slick UI but 907 00:34:39,060 --> 00:34:43,379 I don't think that justifies again the 908 00:34:41,520 --> 00:34:45,119 possible harms that can happen from 909 00:34:43,379 --> 00:34:47,520 preventing people being able to choose 910 00:34:45,119 --> 00:34:48,359 devices they want to use 911 00:34:47,520 --> 00:34:52,260 um 912 00:34:48,359 --> 00:34:54,540 and the final uh option is things like 913 00:34:52,260 --> 00:34:57,000 devices that are more offline or 914 00:34:54,540 --> 00:34:58,859 disconnected so one of my home projects 915 00:34:57,000 --> 00:35:01,920 is I actually want to make a web authen 916 00:34:58,859 --> 00:35:03,660 NFC door unlock where you hold your key 917 00:35:01,920 --> 00:35:05,880 up to the door and 918 00:35:03,660 --> 00:35:07,619 because of the way that these Keys work 919 00:35:05,880 --> 00:35:10,079 you would need that to be a resident key 920 00:35:07,619 --> 00:35:12,900 for that kind of thing so resident Keys 921 00:35:10,079 --> 00:35:14,400 would could be used a lot more in say 922 00:35:12,900 --> 00:35:16,260 like a corporate environment where you 923 00:35:14,400 --> 00:35:18,900 control and issue keys to someone and 924 00:35:16,260 --> 00:35:19,560 that can have the resident keys on them 925 00:35:18,900 --> 00:35:21,240 um 926 00:35:19,560 --> 00:35:23,780 but you know there are those those 927 00:35:21,240 --> 00:35:23,780 problems 928 00:35:24,480 --> 00:35:28,260 but with your door unlock why does it 929 00:35:26,700 --> 00:35:29,060 have to be resident can't you just send 930 00:35:28,260 --> 00:35:32,400 the 931 00:35:29,060 --> 00:35:33,660 3743 105 different credential IDs that 932 00:35:32,400 --> 00:35:35,579 have previously been registered into the 933 00:35:33,660 --> 00:35:37,160 device to try and authenticate the 934 00:35:35,579 --> 00:35:39,420 answer is no 935 00:35:37,160 --> 00:35:43,260 there is a limit to how many credential 936 00:35:39,420 --> 00:35:46,740 IDs you can provide to a device 937 00:35:43,260 --> 00:35:48,420 uh during an authentication request and 938 00:35:46,740 --> 00:35:50,040 if you provide too many the devices will 939 00:35:48,420 --> 00:35:52,079 have a little panic attack and not work 940 00:35:50,040 --> 00:35:54,780 so you can't 941 00:35:52,079 --> 00:35:56,400 just send it like this huge list of all 942 00:35:54,780 --> 00:35:58,500 possible credential IDs and just pick 943 00:35:56,400 --> 00:36:01,619 out which one that was used you have to 944 00:35:58,500 --> 00:36:03,660 limit that down to the username of the 945 00:36:01,619 --> 00:36:06,660 person and just send it exactly those 946 00:36:03,660 --> 00:36:09,599 ones or you need to use the resonant 947 00:36:06,660 --> 00:36:12,780 Keys as as mentioned 948 00:36:09,599 --> 00:36:14,040 are software keys not in TPM or enclaves 949 00:36:12,780 --> 00:36:15,300 a problem 950 00:36:14,040 --> 00:36:16,560 now 951 00:36:15,300 --> 00:36:19,619 uh 952 00:36:16,560 --> 00:36:21,960 the answer to this one is a little bit 953 00:36:19,619 --> 00:36:23,579 more complicated but I wish that I had 954 00:36:21,960 --> 00:36:27,300 sparkly glittery hands at the moment 955 00:36:23,579 --> 00:36:30,859 because the answer is it depends 956 00:36:27,300 --> 00:36:34,680 at one end of our Spectrum we have 957 00:36:30,859 --> 00:36:36,420 software keys and you know they are 958 00:36:34,680 --> 00:36:37,980 still better than a password they are 959 00:36:36,420 --> 00:36:39,660 still not going to be fished they don't 960 00:36:37,980 --> 00:36:42,599 have those breach attacks or replay 961 00:36:39,660 --> 00:36:44,220 attack threats that that we have from 962 00:36:42,599 --> 00:36:45,900 you know disclosure of passwords or 963 00:36:44,220 --> 00:36:47,880 password hashes so just having 964 00:36:45,900 --> 00:36:50,280 cryptographic auth in those software 965 00:36:47,880 --> 00:36:51,660 Keys is already a huge win for user 966 00:36:50,280 --> 00:36:54,540 security over 967 00:36:51,660 --> 00:36:56,280 you know passwords and trtp 968 00:36:54,540 --> 00:36:58,140 but at the complete opposite end of this 969 00:36:56,280 --> 00:37:00,599 spectrum we have strict regulations and 970 00:36:58,140 --> 00:37:03,240 compliance for individuals businesses 971 00:37:00,599 --> 00:37:05,640 High Assurance environments and here we 972 00:37:03,240 --> 00:37:07,740 really probably do want Keys stored in 973 00:37:05,640 --> 00:37:09,720 Secure enclaves or Hardware or at least 974 00:37:07,740 --> 00:37:13,020 Hardware backed in some way 975 00:37:09,720 --> 00:37:14,400 and because of this 976 00:37:13,020 --> 00:37:16,380 um 977 00:37:14,400 --> 00:37:18,480 uh entire Spectrum there's a number 978 00:37:16,380 --> 00:37:20,280 there's a spectrum of controls that you 979 00:37:18,480 --> 00:37:23,280 have the major one being attestation 980 00:37:20,280 --> 00:37:26,640 which is again that validation and 981 00:37:23,280 --> 00:37:28,320 certificate of authenticity of devices 982 00:37:26,640 --> 00:37:30,720 so we really come so I'm not really 983 00:37:28,320 --> 00:37:32,280 worried about software keys but there is 984 00:37:30,720 --> 00:37:34,440 a spectrum of threat models that you 985 00:37:32,280 --> 00:37:36,480 have to consider here 986 00:37:34,440 --> 00:37:37,740 have you heard about insert favorite or 987 00:37:36,480 --> 00:37:41,460 thing here 988 00:37:37,740 --> 00:37:43,380 uh no I probably haven't when I went and 989 00:37:41,460 --> 00:37:46,500 looked up insert person's favorite or 990 00:37:43,380 --> 00:37:48,599 thing here okay cool but it doesn't mean 991 00:37:46,500 --> 00:37:51,900 it's widespread or used 992 00:37:48,599 --> 00:37:53,640 um and that's really the problem is that 993 00:37:51,900 --> 00:37:55,380 you know it's one thing to have your 994 00:37:53,640 --> 00:37:57,119 favorite new or thing it's another thing 995 00:37:55,380 --> 00:37:59,760 for it to be widely deployed and 996 00:37:57,119 --> 00:38:01,560 embraced and in people's hands and right 997 00:37:59,760 --> 00:38:03,480 now web authen may not be perfect but 998 00:38:01,560 --> 00:38:05,640 it's in people's hands and so we should 999 00:38:03,480 --> 00:38:07,500 use it 1000 00:38:05,640 --> 00:38:08,880 you keep saying at a station what is 1001 00:38:07,500 --> 00:38:09,900 that all right this is like the third 1002 00:38:08,880 --> 00:38:12,119 time 1003 00:38:09,900 --> 00:38:14,040 so let's actually explain it 1004 00:38:12,119 --> 00:38:15,480 it is the official Nintendo seal of 1005 00:38:14,040 --> 00:38:17,700 quality what it is is that when you 1006 00:38:15,480 --> 00:38:19,380 register your key it is sent it is 1007 00:38:17,700 --> 00:38:21,900 signed along with a certificate that 1008 00:38:19,380 --> 00:38:24,540 says this is a signature from the 1009 00:38:21,900 --> 00:38:27,300 manufacturer's CA signing key that says 1010 00:38:24,540 --> 00:38:29,760 yes this actually is a Yuba key and it 1011 00:38:27,300 --> 00:38:31,920 is exactly this model and it has exactly 1012 00:38:29,760 --> 00:38:34,680 these properties or you get something 1013 00:38:31,920 --> 00:38:37,619 like a fashion key and it will have the 1014 00:38:34,680 --> 00:38:40,079 phase and signed one that says hey this 1015 00:38:37,619 --> 00:38:42,300 is a fashion key is a fashion E-Pass it 1016 00:38:40,079 --> 00:38:45,720 does this it does this 1017 00:38:42,300 --> 00:38:48,420 as a relying party you can specify which 1018 00:38:45,720 --> 00:38:50,520 Cas you trust and which individual 1019 00:38:48,420 --> 00:38:52,800 device models you trust or want to use 1020 00:38:50,520 --> 00:38:54,720 based on your requirements 1021 00:38:52,800 --> 00:38:56,280 this is what attestation is there are 1022 00:38:54,720 --> 00:38:58,619 very few web or thin libraries that 1023 00:38:56,280 --> 00:39:00,420 support this so if you need attestation 1024 00:38:58,619 --> 00:39:02,760 you will probably have to do a fair bit 1025 00:39:00,420 --> 00:39:05,099 of legwork to make it happen web orthane 1026 00:39:02,760 --> 00:39:07,800 RS is probably the closest to having a 1027 00:39:05,099 --> 00:39:11,339 production viable public version of 1028 00:39:07,800 --> 00:39:13,800 attestation available for you to use and 1029 00:39:11,339 --> 00:39:16,200 what this lets you do is 1030 00:39:13,800 --> 00:39:17,640 you can say okay we have tested and 1031 00:39:16,200 --> 00:39:19,320 asserted that ubiques are really good 1032 00:39:17,640 --> 00:39:20,460 and Nitro keys are really bad which by 1033 00:39:19,320 --> 00:39:21,780 the way they actually are don't buy 1034 00:39:20,460 --> 00:39:22,560 Nitro Keys 1035 00:39:21,780 --> 00:39:25,500 um 1036 00:39:22,560 --> 00:39:27,839 we can assert that only these keys are 1037 00:39:25,500 --> 00:39:29,339 used when they when users register and 1038 00:39:27,839 --> 00:39:30,960 now we know they have to have at least 1039 00:39:29,339 --> 00:39:32,880 these security properties 1040 00:39:30,960 --> 00:39:34,560 the caveat without a station is that 1041 00:39:32,880 --> 00:39:37,260 there are some devices which if you 1042 00:39:34,560 --> 00:39:39,900 request attestation will not provide a 1043 00:39:37,260 --> 00:39:41,220 credential at all when they go to 1044 00:39:39,900 --> 00:39:42,720 register or will not provide an 1045 00:39:41,220 --> 00:39:44,760 attestation certificate so you have to 1046 00:39:42,720 --> 00:39:47,579 reject these 1047 00:39:44,760 --> 00:39:50,280 um or it could absolutely prevent um 1048 00:39:47,579 --> 00:39:51,660 people from registering those devices so 1049 00:39:50,280 --> 00:39:53,839 you also still need to be careful with 1050 00:39:51,660 --> 00:39:53,839 this 1051 00:39:55,079 --> 00:39:59,700 I do use case 1052 00:39:57,119 --> 00:40:01,859 I have no idea I'm I am not the font of 1053 00:39:59,700 --> 00:40:03,119 all auth vendor product features so 1054 00:40:01,859 --> 00:40:05,640 unfortunately 1055 00:40:03,119 --> 00:40:07,560 uh you will probably need to go and 1056 00:40:05,640 --> 00:40:09,180 check some of this yourself and I hope 1057 00:40:07,560 --> 00:40:11,880 that some of the topics of this talk 1058 00:40:09,180 --> 00:40:14,000 have helped you understand what some of 1059 00:40:11,880 --> 00:40:17,820 these settings like attestation 1060 00:40:14,000 --> 00:40:19,260 and user verification and key residency 1061 00:40:17,820 --> 00:40:20,579 actually mean 1062 00:40:19,260 --> 00:40:22,740 so once again 1063 00:40:20,579 --> 00:40:24,480 thank you for sticking with the the set 1064 00:40:22,740 --> 00:40:27,000 of questions that have been asked from 1065 00:40:24,480 --> 00:40:29,280 yesterday's users I really appreciate 1066 00:40:27,000 --> 00:40:31,440 you watching the talk and again I really 1067 00:40:29,280 --> 00:40:33,300 appreciate a big thank you to the AV 1068 00:40:31,440 --> 00:40:35,940 crew who have given up their lunch break 1069 00:40:33,300 --> 00:40:38,099 to re-record this talk with me thank you 1070 00:40:35,940 --> 00:40:40,380 very much for their patience as well and 1071 00:40:38,099 --> 00:40:42,119 big shout outs to my co-contributor 1072 00:40:40,380 --> 00:40:44,280 Michael Farrell who has been a wonderful 1073 00:40:42,119 --> 00:40:47,160 support and contributor to the web 1074 00:40:44,280 --> 00:40:48,960 authen space and helping me out a lot 1075 00:40:47,160 --> 00:40:51,240 with this so if you have any questions 1076 00:40:48,960 --> 00:40:54,740 please email me at william.brown 1077 00:40:51,240 --> 00:40:54,740 souza.com thank you