WEBVTT 00:00:14.900 --> 00:00:19.200 Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. 00:00:19.500 --> 00:00:26.000 I'm an analyst and advisor with KuppingerCole Analysts. We are in the series of episodes 00:00:26.000 --> 00:00:32.700 that we internally and externally call the Road to EIC. So we are looking at topics that 00:00:32.700 --> 00:00:40.300 are relevant as key topics for the upcoming EIC conference in Berlin in May. And one topic 00:00:40.300 --> 00:00:43.850 that we covered already last year, I did this 00:00:43.850 --> 00:00:47.400 with Alexei, our colleague. And today we want 00:00:47.400 --> 00:00:49.708 to look at what has changed, has something 00:00:49.708 --> 00:00:52.400 changed and what have we learned in the meantime. 00:00:52.400 --> 00:00:56.088 We want to look at post-quantum identity or more 00:00:56.088 --> 00:00:59.700 specifically at future-proofing authentication. 00:01:00.100 --> 00:01:02.671 So first of all, let me introduce my 00:01:02.671 --> 00:01:06.600 colleague, a recent guest, Jonathan Care. Hi, Jonathan. 00:01:07.300 --> 00:01:10.900 Hi, Matthias. Thank you so much for having me again. It's a pleasure. 00:01:11.200 --> 00:01:14.200 Great to have you, Jonathan. And we want to look 00:01:14.200 --> 00:01:17.200 at the topic in a different way. We want to look 00:01:17.200 --> 00:01:20.166 at it like we do in a good TV series when 00:01:20.166 --> 00:01:24.000 there's a new season. We look at what happened in the 00:01:24.000 --> 00:01:26.297 meantime and what happened in the last 00:01:26.297 --> 00:01:29.500 episode. We want to look at the quantum clock that is 00:01:29.500 --> 00:01:33.808 ticking. We have new computers that are looming 00:01:33.808 --> 00:01:38.300 around the corner and they will break encryption. 00:01:39.200 --> 00:01:42.464 But is this the real important part that they 00:01:42.464 --> 00:01:45.800 are breaking encryption? Or why are we talking 00:01:45.800 --> 00:01:50.900 about that when Copenhagen Coal is so much an identity company? Why, of course, also a 00:01:50.900 --> 00:01:53.224 cybersecurity company, but we're looking at it 00:01:53.224 --> 00:01:55.700 from the identity perspective. So why is identity 00:01:55.700 --> 00:01:59.450 the quantum bullseye? Well, I think there's a 00:01:59.450 --> 00:02:03.200 couple of things here. First of all, identity 00:02:04.600 --> 00:02:09.291 assertions. So I am JC at copenhagencoal.com. 00:02:09.291 --> 00:02:14.400 So my email address is an assertion of my digital 00:02:14.400 --> 00:02:18.076 identity. All of these are secured and 00:02:18.076 --> 00:02:23.300 protected by cryptographic controls. So in the case of 00:02:23.300 --> 00:02:26.496 Copenhagen Coal, we had passwords. We've now 00:02:26.496 --> 00:02:30.200 moved to passkeys because as Matthias says, we're a 00:02:30.200 --> 00:02:33.008 forward-looking identity company. But passkeys 00:02:33.008 --> 00:02:36.000 and passwords are both protected by cryptography. 00:02:36.300 --> 00:02:42.900 And the reason that we can establish trust is based on public cryptography 00:02:42.900 --> 00:02:47.400 and Kerberos and all these other very important 00:02:47.400 --> 00:02:51.900 crypto protocols. And I think, so if quantum or 00:02:52.700 --> 00:02:55.965 when quantum breaks encryption, then lots of 00:02:55.965 --> 00:02:59.600 things will happen. And lots of people say, well, 00:02:59.700 --> 00:03:02.550 oh goodness, there's going to be governments who 00:03:02.550 --> 00:03:05.400 have been storing encrypted messages for decades 00:03:05.400 --> 00:03:10.400 are now going to be able to decrypt everything. And yes, that is a potential concern for 00:03:11.200 --> 00:03:15.500 many people. It's certainly going to erode the privacy boundary, 00:03:16.800 --> 00:03:19.200 which is something obviously Copenhagen Coal is very interested in. 00:03:19.700 --> 00:03:23.312 And I think the identity piece is very simple to 00:03:23.312 --> 00:03:27.300 say. Authentication protocols depend on cryptography. 00:03:29.100 --> 00:03:33.591 Identity is the new perimeter. We say this, 00:03:33.591 --> 00:03:38.500 and when you come to EIC and we meet in person, 00:03:38.500 --> 00:03:42.052 we'll probably say that to each other. What does 00:03:42.052 --> 00:03:45.900 it mean? It means that in a zero trust architecture, 00:03:47.400 --> 00:03:55.100 90% or even every access decision hinges on cryptographic identity verification. 00:03:56.100 --> 00:04:05.300 And if that is breakable, then bye-bye zero trust. And I talked about Copenhagen Coal as a 00:04:05.300 --> 00:04:09.750 looking identity company, which we are. And like 00:04:09.750 --> 00:04:14.200 many organizations, like many banks, like Apple, 00:04:14.900 --> 00:04:21.500 like many organizations, we have moved away from passwords towards these cryptographic 00:04:21.500 --> 00:04:23.966 authentication methods. Parsky's, Fido2, and 00:04:23.966 --> 00:04:26.600 Specificate-based Auth. And I think while I was 00:04:26.600 --> 00:04:32.100 in, many decades ago, when I worked at Sun Microsystems, a friend and colleague of mine 00:04:32.100 --> 00:04:34.916 developed an automated password cracker, which 00:04:34.916 --> 00:04:38.100 was basically exploiting some of the vulnerabilities 00:04:38.100 --> 00:04:45.800 in the Unix crypto algorithm. No doubt that the crypto underneath needs replacing. 00:04:47.400 --> 00:04:54.000 So we have a problem in that we've moved away from passwords, we still obviously rely on 00:04:54.000 --> 00:04:58.900 cryptographic storage, towards cryptographic authentication conversations. And I'll say 00:04:58.900 --> 00:05:06.800 Parsky's, Fido2, Certificate-based Authentication, being just three that come to mind. 00:05:09.500 --> 00:05:12.510 We've replaced the weakest link, that being 00:05:12.510 --> 00:05:15.800 passwords. And I've said this for years, I know 00:05:15.800 --> 00:05:18.996 Matthias and our friend and colleague Martin 00:05:18.996 --> 00:05:22.700 have said, passwords are the weakest link for many, 00:05:22.700 --> 00:05:30.100 many years. And we replaced it with a mathematically beautiful, robust cryptographic 00:05:29.700 --> 00:05:34.252 architecture. Unfortunately, quantum means that 00:05:34.252 --> 00:05:38.900 that mathematics itself is under threat. So this 00:05:38.900 --> 00:05:48.400 is a problem that as security architects, as software designers, as AI operations, 00:05:48.400 --> 00:05:51.446 or security operations, we've not faced this 00:05:51.446 --> 00:05:54.700 where actually the mathematics is under threat. 00:05:55.600 --> 00:05:58.750 But if we assume that, and now I'm really playing 00:05:58.750 --> 00:06:01.900 a bit, you have a layman or the devil's advocate, 00:06:02.900 --> 00:06:07.800 let's say in five years, there's quantum computing around and in five and a half years, 00:06:09.000 --> 00:06:15.800 every cryptographic mechanism that actually underpins authentication is broken. So we need 00:06:15.800 --> 00:06:18.640 to take care, say in four and a half years. Why 00:06:18.640 --> 00:06:21.600 is that a wrong assumption? So what am I missing? 00:06:22.000 --> 00:06:29.700 Is it just the authentication or is there more? Well, as we've seen with many scenarios, 00:06:30.800 --> 00:06:33.701 we're not very good as humans about thinking 00:06:33.701 --> 00:06:36.800 about something we need to take care of in four 00:06:36.800 --> 00:06:40.661 and a half years. As evidence for myself, I've had 00:06:40.661 --> 00:06:44.600 a diet issue that I need to address, which is going 00:06:44.600 --> 00:06:50.400 to be a problem in four and a half years. So we're not good at that as humans. We focus on 00:06:50.400 --> 00:06:55.642 the immediate and we focus on the big things. 00:06:55.642 --> 00:07:01.000 So it's very difficult to focus a mind unless, 00:07:01.400 --> 00:07:03.481 of course, you are a specialist in this area. 00:07:03.481 --> 00:07:05.700 But let's turn it around and let's look at those 00:07:05.700 --> 00:07:11.500 facts I mentioned. I mentioned nation state adversaries, and you think, well, why does a 00:07:12.700 --> 00:07:18.100 nation state care about me? I don't know why nation state care about you. But 00:07:20.300 --> 00:07:25.294 it is entirely possible that your messaging, it 00:07:25.294 --> 00:07:30.500 is entirely possible that your banking traffic is 00:07:30.500 --> 00:07:33.352 entirely possible, that whatever you may be 00:07:33.352 --> 00:07:36.800 doing, which is currently protected by cryptography, 00:07:37.300 --> 00:07:43.100 is of interest, even if it's just building up that picture of communications that 00:07:44.800 --> 00:07:50.900 ELINT companies or ELINT organizations like to do. So if they're capturing authentication 00:07:50.700 --> 00:07:54.200 handshakes, certificate exchanges, and federated 00:07:54.200 --> 00:07:57.700 identity assertions, which right now are robust, 00:07:58.700 --> 00:08:05.900 they won't be. And it's interesting that I mentioned banking, and of course, that's the 00:08:05.900 --> 00:08:10.107 falling siren call that many people use. But 00:08:10.107 --> 00:08:14.600 the Federal Reserve in the US published a paper 00:08:14.600 --> 00:08:22.700 in September specifically on this risk, which is HMDL, harvest now, decrypt later. 00:08:23.200 --> 00:08:29.100 So we're no longer in theoretical territory. This is a real issue. And I say, as security 00:08:29.100 --> 00:08:31.222 architects, we do need to be cognizant of what's 00:08:31.222 --> 00:08:33.300 going to happen in four and a half years' time. 00:08:34.300 --> 00:08:43.600 And let me, again, hone in a little on the specific risk to identity because people say, 00:08:43.800 --> 00:08:51.400 well, I don't care if some government reads my emails. Let me give you a identity-specific 00:08:51.400 --> 00:08:54.553 scenario. A captured authentication session 00:08:54.553 --> 00:08:58.000 could be replayed, could be analyzed to extract 00:08:58.000 --> 00:09:00.660 long-lived credentials, be analyzed to 00:09:00.660 --> 00:09:04.300 extract session keys or identity federation secrets. 00:09:05.300 --> 00:09:09.000 Now, a friend of mine who's security managing one of the big 00:09:11.200 --> 00:09:18.800 companies that provide cloud services says that the thing that really gets them 00:09:19.600 --> 00:09:23.040 going is when they hear about an endpoint being 00:09:23.040 --> 00:09:26.700 lost. Because long-lived credentials, session keys 00:09:27.300 --> 00:09:32.336 are all up for grabs on that endpoint. So scale 00:09:32.336 --> 00:09:37.800 that not just from the, oh no, I've lost my laptop, 00:09:37.900 --> 00:09:40.913 which is occasional, to everybody has lost 00:09:40.913 --> 00:09:44.500 long-lived credentials, session keys, and identity 00:09:44.500 --> 00:09:52.300 federation secrets. You then have a problem with all of the cloud services you access, 00:09:52.800 --> 00:09:57.400 all of the cloud services that underpin the cloud services that you access, and so on, 00:09:57.400 --> 00:10:01.341 and so on, and so on, are then up for grabs. And 00:10:01.341 --> 00:10:05.200 we know we've talked about transitive trust for 00:10:05.200 --> 00:10:09.200 a long time. Well, this is going to be the biggest transitive trust problem we've seen 00:10:10.000 --> 00:10:17.500 with the target group being everybody. You mentioned four and a half years. And yes, 00:10:17.500 --> 00:10:20.867 I think estimates have said it's between three 00:10:20.867 --> 00:10:24.600 and 10 years, but the identity data being harvested 00:10:24.600 --> 00:10:29.776 today has value for decades. So CISOs, the 00:10:29.776 --> 00:10:36.800 question for you is not when will quantum computers break 00:10:36.800 --> 00:10:40.929 my authentication? It's what identity data is 00:10:40.929 --> 00:10:45.700 being captured right now, which is up for decryption 00:10:45.700 --> 00:10:56.200 later. Right. So there is no chance to wait until then. We should have started last year, 00:10:56.300 --> 00:10:59.088 and we should have maybe started even earlier 00:10:59.088 --> 00:11:02.000 to apply this, what people call crypto agility, 00:11:02.600 --> 00:11:06.714 to say, okay, let's exchange the algorithms with 00:11:06.714 --> 00:11:11.000 ones that are stable against this expected quantum 00:11:12.800 --> 00:11:15.839 computing data encryption part. So how to do 00:11:15.839 --> 00:11:19.500 this? What has maybe changed in the meantime since we 00:11:19.500 --> 00:11:23.290 talked about that last time? I'm a great friend 00:11:23.290 --> 00:11:27.000 of standards, of interoperability, of testing, 00:11:27.200 --> 00:11:30.200 of testing scenarios, interoperability testing. 00:11:30.200 --> 00:11:33.200 Is there something that is going on that we can 00:11:33.200 --> 00:11:36.500 build upon to start right now? Well, there are 00:11:36.500 --> 00:11:39.800 some standards, and I was going to make a joke 00:11:39.800 --> 00:11:43.100 about I'm not friends with standards. I just say that so they'll buy me a beer. 00:11:43.900 --> 00:11:46.858 But there are standards that are there that help 00:11:46.858 --> 00:11:50.000 us, and the three FIPS standards that come to mind, 00:11:50.600 --> 00:11:53.888 FIPS 203, which is known as MLChem, which is 00:11:53.888 --> 00:11:57.700 module lattice key encapsulation, and that replaces 00:11:57.700 --> 00:12:01.523 the key exchange with protected cryptographic 00:12:01.523 --> 00:12:05.600 objects, something I worked on a while back when 00:12:05.600 --> 00:12:09.161 I was doing stuff for UK government. The other 00:12:09.161 --> 00:12:12.800 one that's of interest is FIPS 204, and that's, 00:12:13.000 --> 00:12:17.600 again, module lattice digital signatures, and this 00:12:17.600 --> 00:12:22.200 replaces and hardens RSA, ECVSA signatures. So the 00:12:22.500 --> 00:12:28.200 good old RSA, which never has gone away, and also the encrypted, sorry, the elliptic curve 00:12:28.200 --> 00:12:36.300 cryptography digital signatures are able to be replaced by that. The final one of the trio 00:12:36.500 --> 00:12:44.100 is FIPS 205, which is SLH DSA, and this is exciting because this is stateless hash-based 00:12:44.100 --> 00:12:47.150 digital signatures, and that gives us, again, a 00:12:47.150 --> 00:12:50.200 backup to FIPS 204, but also some diversity. We 00:12:50.200 --> 00:12:53.250 have choices. I'm particularly interested in that 00:12:53.250 --> 00:12:56.300 because the idea of a stateless digital signature 00:12:56.300 --> 00:13:00.953 means we're no longer relying on potentially weak 00:13:00.953 --> 00:13:05.700 exchanges prior to the digital signature exchange. 00:13:07.400 --> 00:13:11.500 So there are some good news. We have these primitives. 00:13:13.600 --> 00:13:18.600 We have these, and I'm trying to think, for those of you who are keen chefs, we have some 00:13:18.600 --> 00:13:24.700 really great ingredients coming into our kitchen, but the recipe, the identity protocols, 00:13:24.700 --> 00:13:30.700 have not been fully updated, and particular questions that come to mind. 00:13:32.800 --> 00:13:37.700 How do you issue post-quantum certificates at scale? 00:13:39.600 --> 00:13:49.300 When it's everybody in your 20,000 person organization, when it's everybody in your 00:13:49.300 --> 00:13:56.300 200,000 telecoms organization, how do you issue certificates at scale? 00:13:58.100 --> 00:14:05.200 What happens, furthermore, to PKI hierarchies? I share a joke with a friend of mine 00:14:06.000 --> 00:14:11.300 who now ended up in one of the vendors, and I talk to Dave, and I say, yes, Dave, 00:14:12.100 --> 00:14:17.800 2026 is going to be the year of PKI, and we've made that joke now since 2015, 00:14:17.800 --> 00:14:21.025 so we're still waiting. But what happens to 00:14:21.025 --> 00:14:24.700 PKI hierarchies when root CAs need to transition? 00:14:25.400 --> 00:14:28.377 The basis of trust, so they say, hey, we're 00:14:28.377 --> 00:14:31.700 going to change, and you need to change with us. 00:14:32.400 --> 00:14:35.500 There's going to be an awful lot of people who are scrambling at that point. 00:14:38.200 --> 00:14:48.200 The idea of hybrid certificates, so a homogenization, a mix of classical and 00:14:48.200 --> 00:14:54.700 post-quantum certificates, is still being standardized at IETF. Now, the good news is, 00:14:54.900 --> 00:15:00.700 we are expecting something in early 2026. The bad news is, it's now early 2026. 00:15:01.600 --> 00:15:07.100 And so, I guess the thing I would say is that we have the building blocks, 00:15:07.200 --> 00:15:12.100 we have the ingredients. What we don't have is the architectural blueprint 00:15:12.700 --> 00:15:17.700 for rebuilding identity infrastructure on top of those building blocks. 00:15:19.200 --> 00:15:21.250 Right. This still sounds a bit scary, and 00:15:21.250 --> 00:15:23.800 you've talked about the large-scale infrastructure, 00:15:24.000 --> 00:15:29.900 so really these large PKI trees that rely on root certificates, and changing this 00:15:29.900 --> 00:15:32.579 might be an issue. But if we get closer to our 00:15:32.579 --> 00:15:35.200 daily life, we are doing authentication with, 00:15:35.200 --> 00:15:39.579 I don't know, OIDC, OAuth, SAML, FIDO pass 00:15:39.579 --> 00:15:45.000 keys. What is the impact of what we are just talking 00:15:45.200 --> 00:15:48.133 about on these technologies? And can this be 00:15:48.133 --> 00:15:51.200 solved easier, or are we still waiting for the 00:15:51.200 --> 00:15:54.684 same building blocks that you just mentioned? 00:15:54.684 --> 00:15:58.400 So, yeah, let's start to drill down. And I think 00:15:58.400 --> 00:16:01.481 the question there, if I understood it correctly, 00:16:01.481 --> 00:16:04.500 is what's going to happen to the stuff we use in 00:16:04.500 --> 00:16:10.200 our daily lives, specific authentication technologies? I mentioned pass keys, FIDO2. 00:16:10.600 --> 00:16:14.261 I also mentioned PKI, but then also SAML, OIDC. 00:16:14.261 --> 00:16:18.000 All of that is, of course, again, very important 00:16:18.000 --> 00:16:25.700 for client services. So, just looking at that, again, there's good news. FIDO Alliance has 00:16:25.700 --> 00:16:29.600 updated specs to support PQ signature algorithms. So, once again, 00:16:30.000 --> 00:16:39.100 I think the FIDO folks are doing the right thing. The analysis I've seen says that 00:16:39.100 --> 00:16:45.700 pass keys and FIDO2 have quietly become quantum safe. I love that, because if it's quiet, 00:16:45.700 --> 00:16:55.600 there's no fuss, no must, it's just done. On the other hand, the entire ecosystem, 00:16:56.700 --> 00:17:00.591 authenticators, blind parties, and platforms 00:17:00.591 --> 00:17:05.100 need firmware and software updates. The firmware in 00:17:05.100 --> 00:17:14.100 your phone that protects that trusted enclave needs an update. UBQ are already demoing 00:17:14.100 --> 00:17:23.100 PQ-ready security keys. And for those of us who have moved to pass keys, 00:17:23.600 --> 00:17:26.350 there's considerable evidence to say that we've 00:17:26.350 --> 00:17:29.100 made good choices. They are the best positioned 00:17:29.100 --> 00:17:32.910 authentication technology for the PQ transition, 00:17:32.910 --> 00:17:36.800 because they're already based on publicly crypto, 00:17:36.800 --> 00:17:42.400 and that upgrade path is clean. It is quiet, no must, no fuss. 00:17:44.200 --> 00:17:51.800 PKI and these certificates, they become important for much in our daily lives, 00:17:52.200 --> 00:17:55.070 including our directory, active directory 00:17:55.070 --> 00:17:58.500 structures, including much of our authentication, 00:17:58.500 --> 00:18:10.000 including obviously TLS is based on PKI. And PKI is deeply embedded almost everywhere in 00:18:10.000 --> 00:18:15.356 enterprise identity, including the growing field 00:18:15.356 --> 00:18:20.600 of non-human identities. So if you think you're 00:18:20.600 --> 00:18:23.539 going to have a problem, just wait until you see 00:18:23.539 --> 00:18:26.600 what your fridge does. Certificate sizes are going 00:18:26.600 --> 00:18:29.816 to increase significantly with PQ algorithms. If 00:18:29.816 --> 00:18:33.100 we want crypto agility, we don't get it for free. 00:18:33.300 --> 00:18:37.733 We're going to have a larger data load. So 00:18:37.733 --> 00:18:42.800 for example, an MLDSA signature is 2.4 kilobytes 00:18:43.400 --> 00:18:48.160 versus 72 bytes for ECDSA. And when you're 00:18:48.160 --> 00:18:53.600 thinking about what you can get on a smart chip, 00:18:54.100 --> 00:18:58.600 something that you can embed in a SIM card or whatever, that becomes significant. 00:18:59.300 --> 00:19:03.000 The other side, of course, is that we are dealing with these larger certificates, 00:19:03.900 --> 00:19:09.900 and therefore the handshakes will be slower because the mathematics is more cumbersome. 00:19:11.700 --> 00:19:16.547 It can take more bandwidth. So again, TLS-based 00:19:16.547 --> 00:19:21.600 transactions between the payment terminal in your 00:19:21.600 --> 00:19:25.006 store and the bank will take more bandwidth. 00:19:25.006 --> 00:19:28.800 And of course, when I think about constrained IoT 00:19:28.800 --> 00:19:31.604 devices like payment terminals, and I 00:19:31.604 --> 00:19:36.000 frivolously just said the fridge, my car is an IoT device, 00:19:36.000 --> 00:19:51.000 and my CPAP machine is an IoT device. Arguably, my mother's pacemaker is an IoT device. 00:19:51.900 --> 00:19:57.700 All of these constrained IoT devices, which not only include medical, not only include 00:19:58.100 --> 00:20:02.700 personal and consumer, but also some industrial devices as well. So again, 00:20:02.700 --> 00:20:08.400 pump controllers that are in some isolated place in the Swiss Alps, for example, 00:20:08.900 --> 00:20:16.300 are all going to be affected by this. And route CAs, it's a multi-year planning 00:20:16.600 --> 00:20:20.322 exercise. We've never had to think about this or 00:20:20.322 --> 00:20:24.200 do this before. And so this is going to be fraught 00:20:24.200 --> 00:20:31.900 with a lot of work and a delicate thing to achieve. I think our approach, Matthias, 00:20:32.100 --> 00:20:35.340 when we talked about this, is that this idea 00:20:35.340 --> 00:20:38.800 of hybrid certificates, issuing certs with both 00:20:38.800 --> 00:20:41.846 classical and PQ signatures is the way to go 00:20:41.846 --> 00:20:45.100 in transaction. So we've got a fallback method. 00:20:46.800 --> 00:20:52.300 When I look further down, when I mentioned federation protocols, so SAML and OIDC, 00:20:52.300 --> 00:21:00.100 and this is everything in cloud. Everything, but everything is based on SAML, OIDC, 00:21:00.500 --> 00:21:08.300 and of course, OAuth token signing. So SAML assertions are XML signed, so we need to 00:21:09.200 --> 00:21:13.262 upgrade the signature of them to include PQ. 00:21:13.262 --> 00:21:17.600 OAuth token signing, JWTs, and I was talking to 00:21:17.600 --> 00:21:19.443 Matthias just before we started talking and 00:21:19.443 --> 00:21:21.500 saying, well, I need to make sure that I'm using 00:21:21.500 --> 00:21:24.826 a proper API key, not just grabbing a JWT for 00:21:24.826 --> 00:21:28.300 a little AI project I'm running because I don't 00:21:28.300 --> 00:21:31.615 really want the LLM to get mad at me. But 00:21:31.615 --> 00:21:35.900 again, we're going to need PQ-safe algorithms in Jose 00:21:36.300 --> 00:21:44.700 specifications and the federation chain problem. We are as vulnerable as the weakest link. 00:21:45.300 --> 00:21:49.606 So if any link in a federated identity chain uses 00:21:49.606 --> 00:21:54.000 vulnerable crypto, the whole chain is compromised. 00:21:56.000 --> 00:22:02.400 And finally, something which is very visible to CISO security architects and 00:22:03.200 --> 00:22:07.650 desktop support people, Enterprise IAM. Active 00:22:07.650 --> 00:22:12.100 Directory that uses certificates and Microsoft 00:22:12.100 --> 00:22:16.700 fortunately have published a PQ roadmap, which looks good. 00:22:17.600 --> 00:22:21.300 However, there's going to be a lot of migration activity required. 00:22:22.400 --> 00:22:26.600 Smart card authentication. I mentioned the ICC chips that you find in 00:22:29.400 --> 00:22:33.555 ICAO smart travel documents like our passports 00:22:33.555 --> 00:22:37.800 now. Any smart card is going to need a physical 00:22:37.800 --> 00:22:41.390 token refresh. And the refresh cycle for that 00:22:41.390 --> 00:22:45.300 is three to five years. So you as an organization 00:22:45.300 --> 00:22:48.466 need to plan now for anything that you're using 00:22:48.466 --> 00:22:51.700 smart card authentication. And oftentimes it can 00:22:51.800 --> 00:22:59.100 be treasury services. It can be high trust healthcare services, the things that you 00:22:59.100 --> 00:23:02.500 really don't and can't afford to have break. I 00:23:02.500 --> 00:23:05.900 mentioned frivolously as we went past, I said, 00:23:05.900 --> 00:23:09.435 what about machine identity or NHI? What about 00:23:09.435 --> 00:23:13.200 API keys? What about service accounts? What about 00:23:14.000 --> 00:23:17.051 MTLS? I mean, right now, I mean, actually, one 00:23:17.051 --> 00:23:20.300 of the things about NHI that we're all saying is, 00:23:20.400 --> 00:23:22.348 hey, we're just overlooking the problem of 00:23:22.348 --> 00:23:24.900 service accounts. Well, watch out because here it comes 00:23:24.900 --> 00:23:28.973 with teeth. These things are often overlooked, 00:23:28.973 --> 00:23:33.400 have a massive scale challenge waiting to bite us. 00:23:33.400 --> 00:23:37.111 The scariness is not getting better while we're 00:23:37.111 --> 00:23:40.900 talking. So we will talk about that at EIC. This 00:23:40.900 --> 00:23:44.944 is a road to EIC podcast episode. So I skipped 00:23:44.944 --> 00:23:48.900 the vendor part, but I like the way that you, 00:23:49.100 --> 00:23:56.600 Jonathan, in person are writing advice for CISOs. And maybe we can close down that episode 00:23:56.600 --> 00:24:00.613 with a clear roadmap for CISOs. What should 00:24:00.613 --> 00:24:05.000 they do? And I think this is some, as you said, 00:24:05.100 --> 00:24:07.449 three to five years, 10 years, five and a half 00:24:07.449 --> 00:24:09.900 years. This is something where they should start 00:24:09.900 --> 00:24:13.400 now, but such a roadmap should be much bigger. 00:24:13.400 --> 00:24:16.900 If you can lay out that, and then all of those 00:24:16.900 --> 00:24:20.521 who are listening can just jot down some more. 00:24:20.521 --> 00:24:24.300 I strongly encourage you, if you're listening to 00:24:24.300 --> 00:24:28.747 this, EIC is where you need to be. We're all in 00:24:28.747 --> 00:24:33.100 Berlin in May, and you will find discussion of 00:24:33.100 --> 00:24:35.691 this that you literally won't get anywhere 00:24:35.691 --> 00:24:38.900 else. And I worked in other analyst companies. I can 00:24:38.900 --> 00:24:44.100 tell you the people I'm working with are significantly smart and are thinking about 00:24:44.100 --> 00:24:51.400 this in ways that even astonishes me. But let's talk about the CISO. And this again, 00:24:51.400 --> 00:24:54.858 we'll be talking about this at EIC. There's a 00:24:54.858 --> 00:24:58.700 four-step plan really. Phase one now is discovery. 00:24:59.400 --> 00:25:05.500 Where is this being used in your stack? You need to map the certificate authorities, 00:25:05.800 --> 00:25:08.459 the key lengths, algorithm dependencies. You 00:25:08.459 --> 00:25:11.300 need to identify which systems are crypto agile 00:25:11.300 --> 00:25:14.889 and which ones are crypto rigid. So what we're 00:25:14.889 --> 00:25:18.400 going to find when we do this discovery phase 00:25:18.400 --> 00:25:21.058 is that we don't know where all certificates 00:25:21.058 --> 00:25:24.200 are. And we went through this with several different 00:25:25.300 --> 00:25:27.503 vulnerability disclosures that we didn't know 00:25:27.503 --> 00:25:30.000 where things were. We're going to find certificates 00:25:30.000 --> 00:25:35.200 buried inside a printer. We're going to find it inside a vendor managed system that we've 00:25:35.200 --> 00:25:38.515 never touched, or we don't even know how to 00:25:38.515 --> 00:25:42.600 issue a change for. We're going to have to prioritize 00:25:42.600 --> 00:25:48.300 then. What are the high value, long lived identity assets that we need to focus on first? 00:25:49.300 --> 00:25:51.714 What are we going to do about our root CA 00:25:51.714 --> 00:25:54.600 certificates, which have 15 to 25 year lifespans? 00:25:55.200 --> 00:26:02.100 Again, this is organizational identity. What do we do about VPN and NTLS certificates, 00:26:02.400 --> 00:26:07.100 where we have people accessing sensitive environments? So again, you may have developers 00:26:07.100 --> 00:26:16.400 who are trying to get into a sensitive environment. They need a trusted, protected 00:26:16.400 --> 00:26:20.222 right to access it. Speaking of developers, 00:26:20.222 --> 00:26:24.400 we're going to have to prioritize code signing. 00:26:25.000 --> 00:26:30.800 If you are a software company, and I quote JP Morgan, who said, 00:26:31.800 --> 00:26:38.600 we're a software company that happens to do banking. So we're all software companies, 00:26:39.100 --> 00:26:47.300 and code signing is going to be important. Think about all of the music creative. Again, 00:26:47.700 --> 00:26:52.400 code signing becomes important there. All the financial transactions, code sign becomes 00:26:52.400 --> 00:26:59.100 important there. Everything we touch will need code signing certificate looked at, because 00:26:59.100 --> 00:27:02.146 the integrity of our supply chain is 00:27:02.146 --> 00:27:06.800 important. Data with long confidentiality requirements, 00:27:07.300 --> 00:27:11.900 and I briefly mentioned healthcare, briefly mentioned financial, but also government as 00:27:11.300 --> 00:27:15.900 well. Things with decades long confidentiality 00:27:15.900 --> 00:27:20.600 requirements will also need to be top priority. 00:27:21.100 --> 00:27:27.700 The third phase is to test this idea of hybrid. So deploying hybrid key exchange 00:27:27.700 --> 00:27:33.800 in test environments, measuring the performance in compact authentication flows, 00:27:33.900 --> 00:27:38.354 and testing operability with identity federation 00:27:38.354 --> 00:27:42.900 partners. ISACA has released a 12 month playbook, 00:27:43.400 --> 00:27:47.900 and it has practical quarterly milestones for post quantum readiness. 00:27:48.600 --> 00:27:57.700 Phase four is into 2027 and beyond, we start the migration. We transition production 00:27:57.800 --> 00:28:03.700 identity infrastructure. We update CA hierarchies and reissue certificates, 00:28:04.100 --> 00:28:09.000 and we ensure backward compatibility during this code distance period. 00:28:11.300 --> 00:28:16.200 Right. So there is a plan, and this is as you laid out, it's really something that 00:28:16.800 --> 00:28:24.400 you can really start right now by cleaning up the basement and looking what you have, and 00:28:24.400 --> 00:28:31.600 we need to get into the migration phase in two years from now, one year from now. 00:28:32.100 --> 00:28:35.638 So there is a plan, but it sounds like a lot of 00:28:35.638 --> 00:28:39.100 work, and a lot of the damage is already done. 00:28:39.100 --> 00:28:42.729 When you say the lost laptop could be subject 00:28:42.729 --> 00:28:46.600 to decryption anyways, because it's too late for 00:28:46.900 --> 00:28:50.528 those. The sooner we start, the smaller the 00:28:50.528 --> 00:28:55.000 blast radius, because we make sure that the next lost 00:28:55.000 --> 00:29:00.000 laptop may be encrypted in a secure manner. As I said, this is an interesting topic, 00:29:00.000 --> 00:29:06.900 and we are already running a bit longer, but I don't want to end before us having some key 00:29:06.900 --> 00:29:13.300 takeaways from you. What would be your key takeaways, apart from the phase plan that you 00:29:13.300 --> 00:29:17.022 just mentioned? What should be something that we 00:29:17.022 --> 00:29:20.900 have under our bedroom pillow to keep in mind when 00:29:20.900 --> 00:29:29.000 it comes to crypto agility, when it comes to post-quantum? Personally, I keep a sandwich 00:29:29.000 --> 00:29:33.597 under the pillow just in case I get hungry in the 00:29:33.597 --> 00:29:38.100 night. But in all seriousness, the key takeaways 00:29:38.100 --> 00:29:42.306 and the things that all of us from Cup and Kikol 00:29:42.306 --> 00:29:46.600 will be talking and asking people about there is, 00:29:47.700 --> 00:29:50.731 what are you going to do about this uniquely 00:29:50.731 --> 00:29:53.900 vulnerable identity layer? It's not just about 00:29:54.200 --> 00:29:59.100 data. It's about the integrity of every authentication decision. 00:30:00.300 --> 00:30:07.300 Again, what are you doing with discovery? Because you can't protect what you can't see. 00:30:07.800 --> 00:30:11.413 As I said, crypto inventory is step one. The real 00:30:11.413 --> 00:30:15.100 goal here, and again, we'll be talking about this, 00:30:15.100 --> 00:30:22.500 as I keep saying in EIC extensively, the real goal is crypto agility. The ability to swap 00:30:22.500 --> 00:30:27.696 algorithms without rebuilding infrastructure. If 00:30:27.696 --> 00:30:33.000 you are using passkeys in FIDO2, congratulations, 00:30:33.500 --> 00:30:39.400 you're ahead of the curve. You've got that tailwind to move you towards passwordless, 00:30:39.600 --> 00:30:44.900 which will help. The final thing, and as I say, the window for planning is now, 00:30:45.600 --> 00:30:51.100 which is why we're going to be talking about this a lot in Berlin. Migration is going to 00:30:51.100 --> 00:30:54.736 take three to five years for large enterprises, and 00:30:54.736 --> 00:30:58.800 the threat is already active by HMDL, I mentioned before. 00:31:01.000 --> 00:31:09.000 Well, these are great takeaways. As you said, we will talk about that at EIC, 00:31:10.000 --> 00:31:15.800 but I don't want to make it too much the commercial break part of this section, but we 00:31:16.100 --> 00:31:19.132 also do advisories. We are up here to support 00:31:19.132 --> 00:31:22.500 with helping you in making the first steps towards 00:31:22.500 --> 00:31:28.500 crypto agility. If you have questions, reach out to Jonathan, to me, to Kuping and Kohl. 00:31:28.800 --> 00:31:36.300 That's where we can help you. Otherwise, follow this podcast, follow our blog posts, 00:31:36.600 --> 00:31:39.734 follow our research. There is a lot to digest, 00:31:39.734 --> 00:31:42.800 and we will meet you at EIC in Berlin. If you 00:31:42.800 --> 00:31:46.014 have any questions for this episode, please 00:31:46.014 --> 00:31:49.900 leave your comments below this episode on YouTube in 00:31:49.900 --> 00:31:55.400 the comment section. It is monitored. We are looking at that, and we will reply. If you're 00:31:55.500 --> 00:31:58.889 listening on, I don't know, on Apple iTunes or 00:31:58.889 --> 00:32:02.500 Google Podcasts or whatever, just drop us a mail. 00:32:02.600 --> 00:32:05.500 You have already mentioned your mail address. It's 00:32:05.500 --> 00:32:08.400 JC at Kuping and Kohl. It's MR at Kuping and Kohl, 00:32:08.400 --> 00:32:14.300 and just reach out to us. We are really happy to get your feedback. Oh, and on LinkedIn, 00:32:14.700 --> 00:32:18.400 and social media will also be involved because we need to authenticate there as well. 00:32:21.000 --> 00:32:23.253 Thank you, Jonathan, for being my guest 00:32:23.253 --> 00:32:26.200 today. That was a great episode, and it showed what 00:32:26.200 --> 00:32:31.706 happened and what did not happen in the meantime. 00:32:31.706 --> 00:32:37.100 The quanto calypso is not there yet, but we have 00:32:37.100 --> 00:32:41.162 a bit more time to look at it. We still do not 00:32:41.162 --> 00:32:45.400 know when it will happen, but we do know that we 00:32:45.400 --> 00:32:48.368 need to prepare right now, as you've mentioned. 00:32:48.368 --> 00:32:51.400 The planning window is now. Thank you, Jonathan. 00:32:51.700 --> 00:32:54.381 I'm looking forward to having you soon again. 00:32:54.381 --> 00:32:57.300 Thank you, Matthias. If I can leave a final word, 00:32:57.700 --> 00:33:00.302 the biggest risk isn't the quantum computer. 00:33:00.302 --> 00:33:03.200 It's the 10-year certificate you issued last week 00:33:03.200 --> 00:33:09.363 using RSA 2048. Yes, that's true. That will 00:33:09.363 --> 00:33:16.100 be a long-term mine in your garden that will be 00:33:16.100 --> 00:33:21.200 around for some time. Thank you, Jonathan. I'm looking forward to having you soon and 00:33:21.200 --> 00:33:24.700 latest seeing you in Berlin. Thank you, Matthias.