Not Caring About Code Signing is a Billion Dollar Mistake ft. Stefan Wenig

Speaker A: Code signing is a process. Much more than any isolated key management or certificate management issue

Speaker B: with software trust isn't a certainty. Behind the dozens of applications and programs that we use every day are, uh, layers of trust that most of us never see. As supply chain attacks increase and code signing requirements evolve, organizations are rethinking how they build sign and ship software. You're listening to Trusted Talk and I'm your host, Michelle Davidson. And today I'm joined by Stefan Wenig, CEO and CTO at SignPath, to break how new baseline requirements are, uh, changing the game and how to keep your supply chain rolling as the landscape evolves. Hi Stefan.

Speaker A: Hi Vishal. Thanks for having me.

Speaker B: Awareness for the need for CO signing has been growing in recent years. There's been recognition around strengthening CO signing practices with the CAB forum and, and introducing new baseline requirements this year with reducing the maximum validities. So with the growing awareness around CO signing, what are some of the other areas that you feel organizations might still be missing?

Speaker A: I think what we're really missing here is that code signing is a process much more than any isolated key management or certificate management issue. And also code signing is uh, part of a larger process of secure software development, of DevOps and of operations. We also need to be aware that there's a lot of players involved here that don't necessarily understand the whole picture here. So it's important to lay it out for everybody who's involved and make sure that all the little practices really work together, uh, to achieve the ultimate goal of security. So I think it's not a big surprise that we see a lot of incidents, high, uh, level incidents, severe incidents happening in the industry that basically have nothing to do with key management or certificate management practices. We just need to get a better awareness of the big picture here.

Speaker B: I love the analogy of the picture and the puzzle and how code signing is part of uh, that puzzle. I know sometimes it's often referred to the infinity loop, but the puzzle piece is just one part of a much bigger picture. I really like that analogy. So I mentioned the baseline requirements. Could you give an overview of what they are, previous changes, where is it now and um, what could organizations in the next few years to help put those pieces of the puzzle together?

Speaker A: The last two years two things were happening. So first we saw a change in the FIPS requirements. So initially we had a separation where we had uh, normal code signing certificates or OV or organization validated certificates that basically had no requirements at all. And we had extended validation certificates that required a, uh, FIPS Certified device, uh, for the keys, meaning that there is no way that the key band can be copied from the device and from that follows that the cannot be stolen. Right. So I think a lot of code signing happens in the Windows ecosystem where most organizations were already using standard validation certificates. But that basically made it the law of the land to have uh, code signing keys on um, dedicated devices. But of course that only applies to anything that's ruled by the CEP form and that's mainly public certificate authorities. So uh, there is uh, basically still no regulation about what happens with code signing keys outside the typical ecosystems of Microsoft, Microsoft, Apple, Google, Java. So if you're looking at Linux, if you're looking at firmware, if you're looking at motherboards, uh, even there has been a major incident, there is still no regulation. But yeah, that's a big step, right? So at least there is an industry recognition. Code signing keys have to be secure, you cannot just have them in files. It's just reckless. And a year later we had a change. That said, uh, code signing certificates by CAs cannot be issued for up to three years any longer. But just a single year. What will we see in the future? I'm hearing that Microsoft is going to unify extended validation and organization validation certificates and of course the other things. Big thing, the elephant in the room here is post quantum cryptography. Wildly varying expectations of when those things will be around or will be required. When quantum computers will be able to actually break codes. Right. We don't know it but we have to prepare now with signing we don't have the problem of copy first and decrypt later. Right. If you have a properly signed file, maybe the signature won't be safe in a year. But nobody can decrypt any sensitive information. But you should be prepared to re sign things on a moment's notice if something unexpected happens. Right. The other thing of course is crypto agility. Every organization should prepare in every aspect of their crypto procedures to be able to uh, switch to quantum safe algorithms. And currently we see that this is happening. GSM vendors are implementing the NIST certified uh, algorithms. The first vendors are already there. Everybody will follow shortly. What will probably be a bit later is all the platform vendors supporting MLDSA in their signature formats like Microsoft. And everybody's still working on that. And it's nice if we can create MLDSA uh, signatures, but it doesn't help us anything if Windows uh, and other systems won't recognize them. So this is probably another year out guess but it's Just a wild guess. So, yeah, crypto agility is the key here.

Speaker B: It's really interesting you mentioned that crypto agility has come, um, up on the podcast a number of times from different guests. And you mentioned earlier around automation, crypto agility, post quantum, they all sort of play together in that bigger picture. So focusing on the smaller picture of the systems and how they work, the DevOps that you mentioned earlier. But if you take that step back in the bigger picture, that is looking at how the workflows of the organizations fit within what they're trying to do, right?

Speaker A: You need to know what's going on. That's the first step. If you don't know where your keys are, if you don't know what certificates have been issued in your organization's name, well, then you're basically figured out for you. If you have all these things centralized, it probably still doesn't mean that you know what everybody's doing with it. If you're just assigning access permissions to keys and certificates, it doesn't really give you a good idea of what's being done with it. Um, due to the nature of typical signing architectures, you don't usually get the information on the side of the key management systems. You get hash codes, right? You cannot really gather, uh, any data from here. And so you might have some configuration data that goes with that that allows you to get some, I don't know, statistics or usage data. But I think a lot of organizations are still flying blind here and basically don't know what certificates are there even if they know what they're exactly being used for. And that's the first step. And we can go from there, right? Once we know it, the next question becomes how flexible is the, uh, configuration system that you have here? Do you have to go into every single development team and have them review their build scripts and exchange key format, uh, command line options in every kind of place? Or is it more like a central switch where you can just say, uh, this project should use that certificate now? There's a big difference too.

Speaker B: So how can organizations kind of prepare for those future industry shifts that you talked about? Those expectations have changed, given some your estimations on the timelines, but particularly to ensure that dev development and security teams are aligned on what they're trying to do. What can organizations do now besides getting an overview of, uh, their current certificate landscape?

Speaker A: So what you often do in that situation is you have some kind of certificate discovery mechanisms, but it usually works for things like web service. It doesn't work as well for code signing. Because where would you start discovering that if you don't have it managed already? My first step would always be make sure that you have centralized infrastructure. Make sure that you have centralized certificate procurement and key assurance. Make sure that everybody in your organization knows what the certificates are. Make sure that you know that nobody has like a credit card contract with some certificate authority that you're not even aware of. So that's the first thing. Make sure that the procurement, uh, channels are clear. And for internal certificates, for internally managed keys, make sure that everybody who uses these keys knows where to get them from. So you don't have like bilateral relationships between development and operations where they agree on some key exchange mechanism. This also has to be part of the central management. And then m. Yeah, as a security person I would just say go ahead and monopolize, uh, this thing. You have to control that, right? Whenever somebody needs a Q certificate, it has to go through some kind of central infrastructure and some kind of centralized process. And once you have that, at least you know who has access to what certificate. Right. And everything down from there. Like if you want to have more information, if you want to have more control. My suggestion would be to choose the platform wisely that you use. Make sure that you understand the possibilities and the limitations of the platform because otherwise you will probably just try to make up for weaknesses with processes. That's typically not a good place to be.

Speaker B: You mentioned around making sure you have a vendor, uh, suitable for your business needs with the maximum validities that obviously that is going to impact workflow. So that relationship you hold with your vendor is going to be super critical because right now it's been put in place as of March this year. But that could change at any point. As we've seen across the PKI landscape industry, it's happened to many different certificate types. So having that vendor uh, in place that you trust and can work with on those changes is really crucial.

Speaker A: And um, also have like a central place where you can change these things without reaching out to every single development team in your organization and giving them a how to and a deadline.

Speaker B: Yeah, that's really interesting. That concludes kind of a really interesting conversation for us around the importance of code signing and how it is putting it into practice. And um, so we do like to ask our guest Stefan, one final question. What is the one piece of tech you could not live without?

Speaker A: Well, of course I'm addicted to my phone. Like everybody is so guilty. I'm not a tech gadget person. Really try to keep that thing out of my personal life. So it's probably the phone. Who can live without a smartphone these days, right?

Speaker B: One piece of technology can sometimes rule our lives. That is all we have time for today. So if you have been listening and you have a question about this topic or there's another topic you would like us to discuss on the podcast, please leave us a comment or get in touch@, uh, trust.idtalkobalsirring.com thank you for joining us today, Stefan.

Speaker A: Thank you, Michelle. Thanks for having me.

Speaker B: You're welcome. It's been an absolute pleasure. And to everyone listening, this has been Trusted Talk. Until next time.