Security. Cryptography. Whatever.

Nate Lawson: Part 1

September 09, 2022 Security, Cryptography, Whatever Season 2 Episode 3
Security. Cryptography. Whatever.
Nate Lawson: Part 1
Show Notes Transcript

We bring on Nate Lawson of Root Labs to talk about a little bit of everything, starting with cryptography in the 1990s.

References

  • IBM S/390: https://ieeexplore.ieee.org/document/5389176
  • SSLv2 Spec: https://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft02.html
  • Xbox 360 HMAC: https://beta.ivc.no/wiki/index.php/Xbox_360_Timing_Attack
  • Google Keyczar HMAC bug (reported by Nate): https://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/

Errata

  • HMAC actually published in 1996, not 1997
  • "That was one of the first, I think hardware applications of DPA was, was, um, satellite TV cards." Not true, they first were able to break Mondex, a MasterCard smart card


"Security. Cryptography. Whatever." is hosted by Deirdre Connolly, Thomas Ptacek, and David Adrian.

Transcript: https://share.descript.com/view/lhzrbt6hDeL

Deirdre:

Hello, welcome to security, cryptography, whatever. I'm Deirdre

David:

I'm David

Thomas:

I, I, I guess I'm Thomas.

Deirdre:

mm-hmm and our special guest today is Nate Lawson of Root Labs. Hi Nate.

Nate Lawson:

Hey, how's everyone doing?

Deirdre:

Good. Um, we're just gonna jump into the conversation we were having before we clicked our button, which was you asking Thomas? How he got into crypto?

Nate Lawson:

Absolutely. Yeah. I had been talking to him about crypto in like, I think the late nineties, maybe early two thousands. And he never honestly seemed that interested. So I was wondering what changed in the mid two thousands when suddenly he started blogging about it and getting very interested in it.

Thomas:

I

David:

he's a coastal elite podcaster.

Thomas:

it's true. That's how these things work. I forget how young I was back then, but you know, at every point in my entire career, back to when I was like working at 19 years old, right. Like I felt like I. Absolutely everything. Not about like everything, but like about my own career, like whatever it was I was doing, I felt maximally competent at that thing. Um, so like I would've defined myself back then as like I do practical security, literally these are the words I would use. I would say I do practical security, which I would define as all the security that is not cryptography. Um, which is, which is impractical security, right? Where like, you know, the, the back and forth of how like, you know, vulnerabilities and stuff worked in. Oh, I found this like crazy crypto analytic attack against decipher and reduced the Q strength from modern 28 bits to, you know, 112 bits. And I call it a day. Right. That's kind of what I felt about cryptography. The, that the simple answer is just pig ignorance, right? Like, um, so I'm sure it was a Matasano project I was on. And I'm sure it was the result of talking to you on IM about what I had run into. And I'm sure it was that you had given me, given me some kind of tip. It was, it might have been SRP. It was probably SRP. It was probably, here's an SRP implementation. If you send it zero, instead of, you know, the actual authenticator, you can log as log in as anybody. And then it actually worked. and like, it's one of those imprinting moments, right. It's also like the first time I ever did a web application penetration test. Um, like one of the first things I did, I didn't like, know how like cross site scripting worked or SQL injection worked. I, I was like a, you know, a memory corruption, you know, vulnerability researcher prior to that, or like Unix privilege, escalation and stuff like that. But none of the web stuff. And like the very first thing I did on that project was I logged in as quote or quote quote equals quote and it, and it worked, which, which ruined me for every other project I was ever on because except the expectation that that happens normally, like somebody might actually have a SQL lookup and the login thing that'll give you SQL injection. When I try to log in with quote. The SRP thing is kind of similar, right? Like that bug almost ruined me for cryptography. Right. Cuz you like, there aren't many better bugs than that. So I think that's what it was. I think it was you telling me about SRP and then like just the realization that like, so my, my priors for, for crypto stuff was that the vulnerabilities were all impractical, um, hyper mathematical and like on a, on a project or if I was just trying to break into something, it wasn't gonna gimme anything I cared about. And then after that it's like, oh shit, what else is there? That's like this. and then you just gave, gave me all my attacks. That's that's how it happened.

Nate Lawson:

Well I think the key thing about crypto that I've I've used before is that catch phrase is that it's very strong, but also brittle. And I think that's what you got caught in, or could have been caught in what there, where, um, you were impressed by the potential strength of cryptography, but um, you hadn't thought about much about the brittleness about how it can all fall apart if you don't get it exactly right.

Thomas:

Yeah. How did you end up doing this?

Nate Lawson:

question. Yeah. Um, I was working for ISS in, in, uh, 1996. Um, and I created the first network intrusion detection system. Uh, at least the first commercial one that I know of. And I was also young at the time and, uh, you know, was interested in the idea of this kind of, um, Empowering technology where a single network administrator could monitor a bunch of streams, that things that are going on the network get alerts when things are going bad and then intrude on, on the attackers and, and block them, um, kind of thought of this, this, uh, augmentation kind of approach. And, um, at the time I was enjoying that, but I was really dismayed at this state of security in general, like bug track and, and, um, exploitation race conditions and, and memory corruption. It was just everywhere. And basically attackers were winning. And so I wanted to move to an area of security where you could make stronger guarantees about what you had done. And cryptography was very appealing. The very first cryptography book I read was a library book I got when I was a kid. And it had, you know, classical ciphers, substitution, um kind where you wrap a piece of paper around a pencil and, you know, you write your letters on that, those kinds of things. And, uh, I left it on the swing set and it got, uh, sprinklers on it. So I had to buy it from the library but, uh, that was sort of my introduction to cryptography. Um but yeah, like in, in 1996 I was, um, looking what, what to do next after ISS and I wanted to move on. So, um, cryptography was really interesting, um, to me and actually, um, uh a mutual friend, um, that was, was I'm new on IRC said Hey, come out to San Francisco, I've got this interesting startup. And um, the company's called simple access. They were using Lyft to do some kind of. Pricing prediction thing for, for eCommerce and, uh, I didn't understand it at all. Um, but you know, I came out to San Francisco, had an interview in the flat iron building and was impressed, but also confused at the company. Um and my friend's like, you know, I think that wasn't quite the right position for you, but there's this company near your, near your school at, um, Cal poly SLO and, um, it's called info guard and they're doing cryptography and you might be good for that. And I said, okay, I don't have any formal training cryptography, but, um, I'm interested in it. So I went and interviewed there and, um, I got, got a job so, um, info guard was really interesting at the time it was founded by three TRW people, ex-TRW, um one was focused on like physical security. So he went to museums and helped them configure their sensors for alarm systems, um, to test those kinds of things. Another was a cryptographer from NSA, uh, and the third one was just kind of a, a manager and, um, The three of them had actually helped author the FIPS 140 standard, which was brand new at the time. Like

Deirdre:

it's their fault

Nate Lawson:

Yeah. And their idea was like the cryptography. They, they created a fax encryption device at TRW and um, they decided along with NIST that there needed to be some kind of standard for the actual implementation of cryptography and cryptographic protocols, um, to make sure they're secure. And that way the government purchasing could, could ask for the certification. But it was what was interesting at the beginning as they started working, there was that they were very focused on actually making implementations robust. FIPS 140 became a little bit of a joke later on when people are sort of rubber stamping implementations, running a few test vectors through and saying you're done. But at the time they were, they were really pushing for the standard to be like the minimum and then certifications to be based on top of that. Um, based on the creativity of the person who's doing the evaluation. So the first thing I worked on there was Netscape SSL module.

Deirdre:

oh my

Nate Lawson:

yeah, so Netscape had NSS

Deirdre:

God You're like the Forest Gump of applied cryptography. You're just popping up in like the past 30 years that you've been alive and working and all the cryptography, sorry Netscape SSL.

Nate Lawson:

I've seen a lot.

David:

I've, I've given a few presentations that begin with kind of like Netscape SSL as a historical note. And then we go from there.

Nate Lawson:

fascinating at the time it was SSL V2. Um, and they had the NSS crypto layer for the Netscape version four browser. They were working on adding a FIPS mode. They wanted to get gov government contracts and have governments purchasing their, their browser and V3 was in process and little bookmark there. Um, Paul Kocher who was the author of the SSLv3 spec was working as a consultant at Netscape at the same time I was working on this review, but I didn't know at the time. Um, and, uh yeah, so for this FIPs module, we were kind of saying like, what would be the security boundary of this, of this software? How do we, it had some nonstandard crypto, like it used in MD5 based PRNG. So how do we certify this? If it's NIST which doesn't allow, uh, MD five use, they didn't wanna throw out the MD five. Uh, they didn't wanna use SHA1 instead, but, um, which would've been. So it's kind of a weird thing there, but also like, um, where do you draw the boundary? How do you in software, like, is, is this crypto module gonna have some kind of process isolation from the rest of the browser? You know, the keys, it has the keys gonna be like encrypted on disk. And so they had this thing where you would enter a password in and would unlock the keys. And there's just a master password, which would do a key derivation. Um but that was trying to make it map to physical crypto modules, which was what FIPS 140 was focused on mostly. Um, and that was fun. I got to drive up to, you know, um, Mountain View and go to the Netscape building there and, and talk, talk with people there while they were working like crazy on this thing and try to try to get it done.

David:

Where was the Netscape building and does it still exist? And is there

Nate Lawson:

Uh yeah it's a mountain view Um, I don't know the company,

David:

I was gonna say, is it the Firefox building now?

Nate Lawson:

it was, I think Google took over at one point. Um, I don't know for sure.

Deirdre:

That feels spiritually correct.

Thomas:

So first of all, you, you've got like, you've got no cryptographic training going into Ingar and your first project is probably the highest profile piece of cryptography on the internet, which is great. Um, I. Uh, you have a CS background, you were at Cal Poly SLO, but like, did you do like a lot of mathematics, like, was math a big part of your CS, your CS degree when you were there?

Nate Lawson:

I've, I've never been that great at math, honestly. Like, um, I've been when, you know, when people program things, I think they often fall back on one of two mental models. One of them is language models and the other one's, um, mathematical models. Um, I've always been the language model kind of person. Um, so my, my superpower, if I were to pick one is I can read a bunch of stuff. Remember all of it and then put it all back together, um, by remembering it all. And so we had a great library at school and I read every book we had on the history of computer security, all the way back to rainbow book and all that stuff. I read, you know, old, early DARPA papers about this stuff. Um, a bunch of the early development papers around, uh, Lucifer, cipher, and Des and all this stuff. Um, they had the, um, differential crypto analysis book by, um, Eli Biham. And so that kind of stuff. So I, I like just read all, all this stuff, um, and remembered it all. And then just, yeah. And then I think when I got to Info Guard, I started reading all of the source code to all this stuff that the projects they had done previously. And so I, I kind of learned it that way. And then the, the guy, um, the guy, Ken, who was the ex NSA person, was really helpful in helping me calibrate some of my mental models of these things about what's practical and what's not. And he, he has, he had probably the best skeptic, skeptical view of cryptography that I'd ever seen. And, um, so we, we went

Deirdre:

he was breaking it all the time or

Nate Lawson:

Yeah. And designing it, he, he was kind of radio HAM radio person. And so he was really focused on sort of, uh, crypto analysis of, of broadcast communications and that kind of thing So, yeah, but he had a really good hunch for how to break things and I absorbed that through osmosis and, um, started kind of projecting forward what that would look like in the software world,

Thomas:

So you, you were like, you're, you're coming from you're coming from ISS, which like, I think we're the old two people on this podcast and Deirdre and David are the younger two, but like, ISS and Secure Networks I'd say are like, um, it's kind of like the birthplace of modern vulner, modern commercial vulnerability research is probably the way I'd put it

Nate Lawson:

and Pepsi

Thomas:

We're the Coke and Pepsi of commercially looking for vulnerabilities. So like you're steep, you're like steeped in this culture of you, you're reading all these books and stuff, but I just knowing you somewhat socially before this, this, I, I remember you being at Info Guard, I remember, you know, um, you know, being warm acquaintances back then. So like I knew you when you were doing that. Right. But I knew you long before that. So you'd been doing, you know, commercial vulnerability research and, you know, amateur vulnerability, research, whatever we wanna call it. Right. Um, for kind of like years prior, like you're like, that's, that's definitely, I would assume that's like, just part of your mental model. It's. You know, the way people look at systems and break them apart and look for flaws and the reason and all that, like just every vulnerability researcher does. Did that, like carry over to the cryptography work that you were doing when you were reading stuff, were you like reading it adversarially? I I'm, I'm really curious about like, you know, I, I have an, I have an idea of like, roughly your level of, I don't know what the word is, but like your comfort level breaking crypto systems now, and I have no idea where you felt like you were in 96 or whatever, when you started at Info Guard, right? Like how, how would you say you're different now than you were then? Like, what would you have done differently on that project?

Nate Lawson:

Um, that's a lot of questions. Uh, the first first answer is that yes, you look at it the same way you look at attacking any system. Identifying different vantage points. An attacker can have how they can get to those vantage points, what leverage they have over the system from those vantage points. Uh, one of the interesting things at the time I read was about how to prove protocols correct. that was a really helpful thing because it forces you to, um describe and, and, um, write out all the different capabilities an attacker have. Can they change a value? Can they learn a value, um, from a certain vantage point or after they've seen certain messages and that model applies to an entire system. So if you look like a PRNG can attacker choose entropy going into the system. And if they know entropy, probably partial entropy exposure of the PRNG state, what can that allow them to do? And I gave a really, uh, short, uh, rump session talk at CRYPTO 98, I think was 97 on this. It was really, really early. I think it got recorded, but it was like one of the very first recorded ones. Um but I was talking about how, um I think it was the SSH PRNG I was talking about, but there's the mixing process. There's input entropy. And, and I was discussing about the ways an attacker can either partially control or influence the entropy pool. And so when most people thought about entropy, they thought of on the output side of like, how much did you entropy did you feed in and how much did you get out the other side? And how far can you extend that securely? But not as many people were focused on like, okay, now you've had a partial exposure, you know, half the pool. What about this particular construction of how it's mixed and how long can you maintain partial or full knowledge of the pool after that point? And so, again, that's just kind of the, that thorough vantage point model for looking at attacks. But what was your second question?

Thomas:

Yeah, I lost my window because I was in archive.org trying to find a working version of the video link for Nates 98, uh, crypto

Nate Lawson:

can I can look it up later.

Thomas:

I, I guess, like, you know, a general thing, I just wonder about the, kind of like the FIPS verification type work that you were doing at Info Guard cause like your career kind of rapidly goes into more high-end, you know, kind of crypto analysis or whatever we wanna call crypto vulnerability research and design too. I mean, you're actually a, you know, cryptography engineer where I'm like a, a vulnerability researcher slash crypto gadfly, right? Like, and David and Deirdre are both actual cryptography engineers. Right. But like you kind of rapidly got into actual, pretty serious, like, you know, breaking systems and stuff. Right. Cause you moved on from there too, you know, cryptography research. Right. So I guess I'm curious, like, um, you know, was it kind of like checkboxy stuff like this system, like here's reasons why this system isn't sound, but we're not gonna go into the details of like what you could actually do with it or like, do you like, did you actually have findings on those projects that you'd like consider like now actual vulnerability findings.

Nate Lawson:

Yeah, that was, that was really interesting. Um, the companies would definitely, when, when they're being, uh, evaluated for FIPS 140, they'd definitely push for a rapid certification. And they'd argue whenever you found something that they said was outside of the guidelines, you know, it'd be like, well, that's not allowed because the crypto boundary is here and that's it over here. And it's like, yeah, yeah. But that does influence the inputs or outputs of the system in a way that kids can attacker some additional leverage. So, no, we can't leave that out. Um, and my managers would go to bat for me on this. So, which is great. It was the company culture was like, we need to secure this stuff. And FIPS 140 is more of a guideline. Yes. We need to make sure you've checked all the boxes. But in addition to that, we need to explain or fix anything we find. And, um, but the companies definitely had pressure to get certified, cuz that was getting in the way of their purchasing with the US government. So it was a tough dynamic and one, which I think ultimately undid the usefulness of FIPS 140, but early on, it was seeming like we were holding the line on this. Um yeah, there were a lot of things which were necessary because of the design constraints at the time, the technology or the gate equivalents or whatever you could get out of a design power issues that um, necessarily limited. Um, I worked on a, a radio, a crypto radio for Motorola at the time. And the, one of the things was the PRNG for how it did, um, keying for, for, uh, channel communications. And it's hard to get entropy when you're wandering around a battlefield, um, something with a radio on your back, and they didn't have room for like a lot of NV RAM or anything like that. So it would like open the microphone, push the gain way up and just hash together, a bunch of noise.

Deirdre:

I was gonna say, I was like, I was trying to think of how you would do that. And I'm like, I have a, you know, a comparable, super computer full of sensors in my pocket right now. I'm like, accelerometer, like just some accelerometer, crap. And I'm like, oh, you don't have that. Like what do you have? It's like, you have like a mic or you have the antenna, so, yeah. Okay.

Nate Lawson:

Yeah. And, and so we, we, we tried to do things like keep some state from the prior communication if there was one. So, um, so at least you weren't starting completely from scratch, but a lot of times you had to bootstrap this and, you know, you can't really make strong guarantees about how much entropy you have in that before you used the first key. And, um that was a critical environment. Ultimately not very solvable with, with the equipment at the time. One interesting thing that happened as well was, um, you know, IBM had this giant mainframe the S390 and they were building this crypto processor and this was gonna be the first level four FIPS 140 evaluation. They really wanted to go to the highest level. And this thing was giant. It's probably the size of a, a dinner plate. Um, And it was a chunk of metal steel, you know, maybe about size, size of a dinner plate shoebox or something like that. Um, and it went in this mainframe and it was gonna be used for driving pins for ATMs or whatever, but, um, they wanted to make sure it had, like at level four you have active, uh, tamper resistance. So it had like a battery inside and a envelope around the whole thing and epoxy potting for all of that.

Deirdre:

wow

Nate Lawson:

Yeah And I think it generated a lot of heat as well, but anyway, They were like, we want level four evaluation. We're like, okay, we're gonna like really work on this thing. We're not gonna give the first level four of the entire program to something that we haven't really hammered on. Just because you say you have an envelope doesn't mean that's enough. And so the physical security guy, um, he x-rayed it and a bunch of stuff. And it was, it was kind of interesting because of the way they, they had mesh, uh, and the mesh was inside the epoxy, but the way the mesh was folded, you know, it's a, it's a flat sheet and think of wrapping a gift, you kind of fold things, but at the corners, you know, you have multiple layers that kind of meet at the corners. And by x-raying he found there was like the tiniest of creases sort of at the corner where they fold it. So he got like a dentist drill and like drilled through the epoxy into it and hooked like, you know, like a really tiny hair, thin wire to it and added power to the mesh and then was able to, to cut away the rest of it without zero izing, anything. And there was like, you know, uproar of this because that's not part of the blah, blah, blah. And standard well, you know, it's, it needs to resist, you know, this kind of attack. And this was a pretty straightforward attack. So, you know, they did some changes to their production line or something like that to address that. But um, but yeah, that, that really revealed the kind of, um, conflict in trying to reach some of these really high security levels.

David:

With, uh, the stuff that was going on, like in the mid nineties, then, especially with SSL two and three, like how much did the export restrictions come into play? Um, cuz like that was, uh, that was a big part of SSL and like rediscovering how that worked was like, uh, and then turning it into vulnerabilities like 20 years later is what qualified me for a PhD. like if you told me like, oh, we already knew all that in like the mid nineties and just, that was kind of the way the world was. And then, you know, we rediscovered it in 20 years later. Um, I totally believe you. And so I'm curious if there was like effects from the export regulation beyond SSLv2 or, or what dealing with that. That was like at the.

Nate Lawson:

Yeah, that that's really interesting. Yeah. We, we were, for these products we evaluated, we were definitely pushing for triple DES is kind of the standard, um, block cipher mode or block cipher. I mean, um, and uh, but a lot of single DES products were still coming. and I mean, back when the original DES was being certified, um they were standardized. They, they definitely had, um, debates over through the 56 bit keys. And, and why do we need these parody bits and crap like that? And people knew it was going to be in insecure from that. Um, but at the time, Des was also being designed more of a as a hardware algorithm and software implementations were possible, but most people didn't think it would be used in software. Cause it was so slow. Um, we're talking late seventies here. So yeah, so people were thinking that we want something that's simple to implement in hardware and small gate wise And um, so they're like, well, 56 bits would probably be okay even though it's not great. Um cryptographers of course didn't say that, but you know, the, in the engineers who are building the systems based on this were like, nobody's gonna be able to brute for a search 56 bits for a really long. But by the mid nineties, this is there, there was the clipper chip debate going on. There was a lot of like, uh, key escrow stuff was finally becoming a national issue. And the NSA had been sort of flexing their muscles around, um, interfering with, with designs of, of various, uh, systems, not, not ones I worked on directly, uh, that I know of. But, um, just in the background, you know, contacting people who had worked there before and saying, you know, you should really modify this. There were some rumors about some of the cryptographic uh, the telephone encryption devices and things like that at the time, um, from different, um, different companies, um, and just like what kinds of additional little backdoor they had added to 'em or whatever. And, um, that was, that was a definitely very prevalent. In terms of SSL, the, um, export modes were a really big deal in. Um, I don't remember exactly how it worked, but I think you had to download a different version to the Netscape to get the non-export modes And you had to like certify something or on a webpage or something. I don't remember exactly. Like you not a controlled location or something. Yeah. ITAR, et cetera.

David:

My understanding is they had the US version and the international edition. And you just had to like pick the right one to download when you like

Nate Lawson:

It wasn't hard. Yeah. It wasn't like there was a hard restriction there, but they had to do something to differentiate their builds of that. And I think they, they didn't, it also have like 40 bit keys. RC4 40, I think was one of the minimum cipher modes and besides none

David:

I believe

Nate Lawson:

Yeah Um yeah so Um, that was even worse than 56 bits, but, um, but yeah, in, in FIPS mode, you know, all that was disabled, you couldn't use anything less than single DES um, and triple DES I think was the preferred mode. If, if the server supported it, um, At that time, we were already trying to push for cuz we knew it was totally insecure, but I think that did limit a lot of the things that manufacturers were designing. They were always trying to, that was always a consideration in, in what they were creating.

Thomas:

I'm gonna bounce back to what I was asking before. And I'll ask a more direct version of the question first serious. Like I would've considered it a serious crypto vulnerability finding roughly what was it?

Nate Lawson:

a good question. Uh, would this be like the first time anyone discovered something and published it

Thomas:

time you were able to E either find or use something on a project. What was your SRP moment?

Nate Lawson:

ah, let's see. a good question.

Thomas:

I'm I'm investigative reporting. We're uncovering the fact that Nate Lawson has never discovered a crypto vulnerability.

Nate Lawson:

Uh, no, I, I have, uh, no, I just, the reason why I'm hesitant about this is I definitely have done a lot of design reviews and that was the earliest stuff I was doing. So it was the question is most of those cases I'd report it to the company and they'd fix it. It wasn't, uh, there's no exploit needed. So, um, like when I was working for info guard, there was a lot of cases where you said you need to change this design, um, this key material isn't being encrypted before it's written to disc, it's written in plain texts here. And like, well, no one has access to your plain text unless you're on your machine already. And that kind of kind of thing. Um, there was some of that, the, the stuff I talked about with the PRNG mixing sort of not, not thoroughly mixing the entropy or entropy mixing happening only periodically so that, um there were times when raw entropy would be output from the pool. There was cases like that. Yeah. I mean the first one that I found that I, I don't think anyone had published this specific thing before and they didn't actually publish it, but before the Xbox 360 HMAC timing attack, I had privately found HMAC timing attacks in other systems, um, that we were reviewing and, and put it in a report. Um, that was kind of the, the first one I think, I mean, everyone knew about timing attacks at the time. And people knew like the secret key material associated with H Mac, for example, with sensitive. But I don't think people realize that the HMAC of a specific chosen value is also sensitive. And so being able to do a timing attack against the HMAC comparison where the, um, victim has knows the correct answer, as well as your answer, your guess, and that could allow you to iteratively guess what the correct answer is? Um I think that was the first, first one of that specific instance, but again, it was like I was specializing something that someone else had already invented.

David:

On the Xbox 360. Um, is that how the, is that what the mod chips that you would buy would do? Is that, were they executing an HMAC timing attack or was that just like we have connected to the debug ports, like screw you type,

Nate Lawson:

there there were a number of, there were a number of interesting flaws in the Xbox 360. Um, one of 'em was a hypervisor attack. That was kind of interesting, um, where they found a sys call that wasn't validating its inputs properly or something like that. And they were able to, to get software code execution, the earliest attacks were swap attacks against the CD ROM and that was, that was kinda interesting. Well, so it, depending on the system, um versus, you know, the, the, um, PlayStation 3, the Xbox 360 had earlier attacks against like copying the discs and, and DVD based attacks. And without the whole system security being broken, whereas the PS3 sort of stood up longer, but then, you know, had fail overflow and, and a total like compromise due to ECS ECDSA,

Deirdre:

Yeah. remember that one.

Nate Lawson:

which

David:

I've I've always had like a kind of special spot for that kind of stuff, because like I started kind of getting into some of this stuff in high school in the context of like being, uh, to make you guys feel old, um, like in the mid two thousands being a user of like the buffer overflow exploit on the first Xbox to be able to run like Xbox Media Center and other stuff, and then also play pirated games, cause I was in high school and didn't have any money. And then that eventually turned into getting the mod ships for the 360 and then like some years later, And like undergrad. I was like, oh, that's what a buffer buffer overflow is. And like, oh, these are the bites. Like on the, like all the like networking I put together to like, be able to stream like 480P TV, uh, to the Xbox and like setting up windows file sharing. Oh, this is how all this stuff actually works on the wire.

Deirdre:

I was such a little media pirate in high school, but I didn't know shit about cryptography or even security. I just knew that I had to get around some stuff and like, I, I didn't even go very far and I wish I could go back in time and tell high school me like, like run this little script. It's fine. And it works with a little bit of math because I just had no clue at the time. I was a little bit motivated, but I had no clue. Um, do we wanna go into like crypto then versus crypto now? I'm, I'm kind of curious about this.

Nate Lawson:

Well, I, I wanted to address something that he said first that, so um, I, I, I think that Thomas has actually done more attacking cryptography stuff than I

Thomas:

Not a chance

Nate Lawson:

I've done a lot of, yeah. In terms of exploiting it. So I've done a lot of auditing of designs and I've done a lot of designs

Thomas:

I've, I've repeated the same dumb attacks over and over more than you have, but,

Deirdre:

And they still

Thomas:

but you have a broader, a broader variance of attacks that you're able to deploy.

Nate Lawson:

You I'm sure you've, you've exploited more, many more systems using cryptography than I have. And the, the, the thing is, is that I, I did a lot of design reviews. And again, like when you do a design review and you find something like, oh you know, this system doesn't verify the RSA PKCS padding. It's like, well, what can you do with that? And, you know, when I worked with Paul Kocher at cryptography research, you know, he was the one that found the exact sequence of papers. They're like, okay, if you have an E equals 17 RSA system and you know, you're not verifying the signature padding, it takes approximately this number of of queries to be able to forge a signature and that kind of

Thomas:

You could do that with E 17.

Nate Lawson:

with, with a lot, lot more queries yeah but it's, it's feasible. Yeah I can't say what the system was, but there was a piece of hardware that had an E equals 17 RSA implementation. They didn't verify the PKCS padding on the signature of something that was very important. Um, and so you could do the same attack you did with equals three. Um, that became public in 2006. Um but it took a lot more queries. I think. I can't remember exactly how many, but let's say, you know, million queries, but this is hardware you have physical access to. So you can do as many as you want.

Thomas:

I feel like, um, you know, I can like mentally run through the basic attack. You know, I I've got a tax that I didn't directly get from you, but they're all kind of stemming to you. And then like, I've talked to people that are like, you know, kind of in the field now and doing lots of work that are in the field now because of like blog posts and stuff that we wrote. So like your influence, like Tiwan is a good example of somebody who's like, you know, you've, you've indirectly more or less directly. Cause I don't do anything that doesn't parrot you. Um, kind of influence that whole line of like, you know, TLS attacks and stuff like that. Right. But. I, I I'm kind of obsessed with, I, I I'm, I'm imprinted on the idea of bug classes. Right. It's the way my brain was wired from being a teenager on, you know, pound hack IRC, and like the currency value of a new kind of exploit that's repeatable in other pieces of software, right? Like, you know, there's like the lowest level of people doing, you know, dumb hacking stuff where they're just trading scripts. And then like just one level above that is you understand how the script works. And if you had a source tree, you could find that same bug in something else and then have like a zero day bug. Right. So I'm kind of like that's, as far as I go intellectually to this whole thing and I'm obsessed with that stuff. Right? So like, I, I feel like you, you taught me. The CBC, you know, the CBC, you know, bit flip modification thing, which like we used on a project to, like there was a CBC encrypted stream and we were able to bit flip admin equals true into it. Um, which again, another high payoff attack. Right. Um, we did the, the, the, you're just talking about it just now the E three PKCS signature thing. So that's like Mozilla was shipping with, um, there, there, there's still tons of equals three RSA certs out there. And Mozilla is shipping with an implementation of, you know, certificate signature checking that doesn't check all the padding bits. It just decodes the padding, extracts the hash and then compares the hash and like. We wrote a whole series of blog posts about how exploitable that is, right. Essentially like you can build the signature you want and cube root it essentially. Um, and get like a valid signature. Right. So that's another example of like a bug class and I've, I've weirdly enough. I've also found that on some pretty high profile projects, um, like it's almost like the higher profile the cryptography is. Um, especially if it's embedded, um, you know, or in like some piece of software, that's impossible to get a spec for and very difficult to reverse. Like the more important it is, the less likely it is that somebody's actually done serious analysis on it. Um, you know, just, just basically compared it to the literature, the, the SRP one is another example. A lot of those attacks are like, you know, you can't have them so much today. Because we just don't use crypto primitives to have these problems anymore. So I, I am kind of curious, like how much of what you were doing at cryptography research or even in the 1990s carries over to like things you actually find in a modern system where they're using, you know, it's an authenticated key exchange with curve 25519 and you know, authenticated, cipher. And that's pretty much the end of it. Right? Like you were kind of doing this stuff a long, a long, long time before, you know, I was right. And, you know, I will not shut up about like the IATF mailing list stuff about IP sec and people talking about like how they're setting the IVs for things. And like, you know, Phil Rogaway coming in their waving his arms screaming. Don't do this recruiting every other cryptographer in the world to like, do open letters to the IETF and it's still happening. Um,

Deirdre:

Yeah

Thomas:

so I don't know if there are non obvious ways that cryptography is different now than it was.

Nate Lawson:

I think there are some, some clear ways. I mean, I was a big fan of the work that, um, that Dan Bernstein did to help eliminate certain bug classes from his, um, both his ciphers, as well as some of the ways he uses ciphers, you know, to, to do things like, um making the key identity part of the key, for example. So it's not just a UN type set of random bits that people did before. Um I, I compare it, it roughly to like type type enforcement becoming part of languages, um, and, and not, not using type safety in, in your programming, um, as being a problem. Um I mean, the, one of the reasons why I was so focused on design reviews and design from the early stage was because things were so bad, it was like, You know, there there's no money really in exploiting anything like the, the, the, the money to be made as consultant was on, on the design side. And there was the, the systems that were using cryptography were like banks doing pin derivations with really boring kind of janky protocols for that using DES and, and stuff like that. SSL itself was just there to convince your, your family to put their credit cards into the internet. And that's why it was created in the first place. So like, all these things are really boring, honestly, in terms of like the, even if you had an SSL break, you would scare people not to put their credit cards into webpages for a little while. I mean, it was like, what's the real impact on society from, from that kind of thing or hardening it so that it it's more secure. So there just wasn't much value any of that stuff, but but, or impact, but in terms of where crypto mattered, it was kind of the military communications or things like that. And I didn't wanna work for the government so being on the periphery of that, and then once the internet started taking off and started getting more mature in the early two thousands, it started getting more interesting to actually protect communications and devices more widely started adopting cryptography. You had, you know, early Palm pilots or, or things like that. And, um, for, for blackberries you know, all this stuff like that. There's devices game consoles started adding interesting copy protection to them And so there's just like crypto started creeping into so many different areas. Um, and it started actually getting interesting. So I think that like the difference between the late nineties and the early two thousands, the, the biggest difference was the crypto was super brittle back in the late nineties. It would fall apart if you, if you looked at it wrong and, and that was almost not interesting because there were so many ways it could fail. And then by the two thousands, the platforms were starting to get more secure and people were starting to rely on it for more interesting things And so they started coming with more interesting protocols. I mean, you know, you know, pairings and identity based encryption and all this stuff started appearing you know, in the mid two thousands. And maybe that itself didn't change the world, but nobody even cared about something like SRP back.

Deirdre:

We have, we have all these whizbang zero knowledge proof systems now, because we had pairings, we, we wouldn't have gotten to the places where we don't have, where we have them without pairings, without first having the pairings first to actually make them like, make my SNARK a little, you know, 500 byte blob that I can throw. I can throw it on a TLS connection now, cuz I can have zero knowledge, proof, enforcement, middle boxes and, and crap like that. Or I can put it on a blockchain. Um, you, you said that like the protocols, the cryptographic protocols that we had in the late nineties would fall apart. If you looked at them wrong and now we basically don't have that anymore. Like what parts of the designs of how we're putting together, I don't know, cipher modes or, you know, as asymmetric protocols makes it so they don't fall apart when you look at them wrong now?

Nate Lawson:

So people, I mean, are actually focused on doing proofs, uh, which at the time people just hand waved and said, Hey, I can't do proofs. I mean, SSLv3 has a clever hack to prevent downgrade attacks, to V2 where there's a, uh, the version of the SSL protocol gets stuffed in the padding for the key exchange Uh, and, and Paul came up with that as a clever way of just like, okay, I don't have any other bits free in this backwards compatible protocol. So I'll, I'll stick the message there. And hopefully, you know it's not malleable if someone can control RSA in various ways.

Deirdre:

And now that's like a well known tech. Well, you wouldn't put it in the padding, but you put it in the transcript and you hash in the transcript somewhere at the very end.

Nate Lawson:

And that's a much more solid design approach and I'm not criticizing that hack. It was necessary to make it backwards compatible with protocol that was already out there and fielded. So, yeah, it was clever. Um, but yeah, uh, people, um, are more careful about proofs about including all the meanings of the things they're, they're hashing together, not just the things themselves, like I hash three keys together and I get a value. It's like, no, I hash the intent of each key and the key usage bits and the, um maybe even the, the state of prior messages and, and you know, those, those kinds of things. Um, I mean, H Mac didn't exist in until 97 I believe. And so we were doing arbitrary hash constructions to try to approximate HMAC before realizing what we needed there. So like just, just simple things like that, but also side channel attacks. I mean, side, uh, the first timing attack, uh, on RSA, uh, Paul published in 96, I think. Um, and then differential power analysis in 98 or nine. Um, I don't remember exactly, but like side channel attacks, weren't really a thing. You know, people talk about Tempest, you know at the time and it's like, oh, well I can't see your screen by analyzing the emissions. Then I guess there's nothing more to be done or it's just all noise. But like nowadays you know, people design, um, hardware, they design protocols to be, um, side channel resistant, even the cryptographic primitives, um, making non-data dependent rotations or things like that. Uh, as, as a primitive for its block ciphers, you know, stream ciphers, there's new things, uh, like, uh, lattices and Latice based I was super skeptical about So my, my, my, yeah, sorry, go ahead. This is in your expertise now.

Deirdre:

well so we, we kind of, we kind of talked about how, like, you know, you would look at it wrong. It would fall apart. And, and Thomas was saying like, oh, all these like classes of attacks that either, you know, the ones that were happening in the nineties, aren't, uh, you don't have to worry about the anymore. But Thomas has done a lot on like classes of attacks against elliptic curve based protocols, like, you know, small subgroup attacks and things like that. We're coming up with a bunch of lattice based stuff Like there's lattice based, you know, key establishment, there's lattice based signatures, there's lattice based zero knowledge proofs. There's lot of there's fully homomorphic encryption this, and I wonder what the next class of, uh, attack

Thomas:

excited about this.

Deirdre:

and. I don't know what it is yet, but I, I know one of them and for all of these, um, key establishment exchange mechanisms in the NIST competition, they put them all into this KEM it's not a, a, you know, it's not key exchange. It's like key encapsulation. Um, and all of them, except maybe one. I don't know if it was all of them, but maybe, maybe all, but one, they, you have to do this transform this Fu Fuji Saki, Okamoto, uh, transform to turn it into a chem and all of the submissions to NIST did it wrong. There was a bug, there was a vulnerability in it, and everyone would just did it the same way. And so I'm just sort of like, that's not even a lattice thing, but that's like a whole new thing that everyone had to do and they all did it wrong and they were all vulnerable to the same leak or, you know, downgrade in security. Do you see like new classes of attacks coming because of this post quantum stuff? Or like, or there's sort of things that are like, I hope we don't forget the lessons that we learned in the nineties and the past two decades when we're doing all these new post quantum crypto systems

Nate Lawson:

Absolutely. Yeah. I mean, you're way beyond me in terms of post quantum I'm, I'm, I'm not, uh, up on the latest of any of that stuff, but I mean, back then at, you know, crypto 97, I think it was when NTRU first came out and my, my team and I were, were super suspicious of it. We're like, you know, lats are great for attacking things and they're they're super linear and all these, all these kinds of things, uh this is a shaky ground to build something on. This is, this is crazy, you know, and, you know, a lot's changed, but a lot hasn't changed in that. Um, and lats are still good for using useful for attacking, uh, various crypto systems. And they're usefulness as a cryptographic primitive is still not in my mind, still not completely proven. Um, and the, the meta thing that, that certainly no one should forget is anytime you shift between a a well known set of, of primitives that you build things on with, with well, understood limitations, you're gonna have big potholes that appear that you didn't know about. And sometimes those can be coded around or, or special case or whatever. And sometimes you can't. Um, so I'm speaking very generally, like, I don't know any, anything about, uh, post quantum systems, but um, but that shift, and of course, as you mentioned, the implementation problems and classes of implementation problems always appear whenever you have a big shift as well. Um I, I see a similar thing happening with like speculative execution and uh, those kinds of side channel attacks where it's like, okay, everyone's known micro architectural side channels have been an issue early two thousands, cache timing attacks, branch, target, buffer, et cetera. But they haven't really understood all the interactions of the micro architectural state. And you know, what, if you got something in branch target buffer, and in, uh, some LRU list for Return calculation or whatever, like, like processor is so complicated these days that there's gonna be emergent behavior of, of all kinds of these things. And there's gonna be emergent behavior that builds on emergent behavior and some brilliant person someday will, will find some attacks in that.

Thomas:

It's like a hell of a second act for Paul.

Nate Lawson:

Yeah, absolutely. Yeah. Yeah. Uh, he, he was always, uh, when we were working on these, these systems, a lot of our, our, his work and, and my work with him was, um, on smart cards and smart cards are a very constrained system. And I I'd argue, they were one of the first important mass market uses of cryptography, um besides software like browsers and things like that. You know, they were around since the late nineties, you have EMV for payments and, um, satellite TV with, um, access control to, to pay TV and, um pay per view and channel encryption. And those two uses of smart cards were sort of the first mass market consumer interesting crypto in my mind. So, so Paul was working on those things very early Paul and team there at cryptography research. But yeah, when you look at that today and people rebuilding from new primitives, it's like, uh, there's gonna be so many problems in this. And, and so many ways that that none of us have predicted it's gonna come.

David:

Yeah, like in the browser world, you mentioned, uh, you know, the SSL was built so that you could do e-commerce on the web and then, you know, you end up with PayPal and, and all that kind of stuff. Um, I, one of the like earlier memories of like anything related to safety on the internet, I remember like my mom or dad saying, like, if you ever buy anything online, like should probably use PayPal ,not that I had any money or a credit card cause I was like young. but like you have to look for the lock icon, um, is like one of the first things I learned about like safety on the internet, besides like, don't talk to strangers. This was before you ordered strangers to pick you up in your, uh, and drive you places on the internet. But it was, you know, really the exception instead of the norm. And then as, as things start to change, like you said, the problem of, you know, how do I encrypt a few things for eCommerce versus like, how do I make the web encrypted by default? And then like you don't. Training nowadays tells you not to look at the lock icon. Like the lock icon is not an indicator of, of, of a site's trustworthiness or safety, or does not mean you should put your credit card in. Um, you should just mostly ignore it as long as it doesn't say locks, uh, say, uh, like insecure HTTP. Um, and that whole trend has been, I don't know that I have anything to say on this other than like, that's where it started. And then the problems now, like now I argue about like TLS and root certs for living. Right. Um, and that's because we started with all the e-commerce stuff that you were talking about.

Thomas:

I have a good segue here am. Am I am my segue is we should find a way to talk about DRM.

Nate Lawson:

well I mean, I've done a lot of work on some, some DRM systems, like the Blu-ray, uh, crypto. Uh, or blueberry protection system called BD plus well could we talk about satellite TV

Thomas:

Sure.

Nate Lawson:

okay. Um, well so in, in terms of DRM, like the history of it, the earliest kind of DRM was in my mind was copy protection, uh, for floppy. Um, there was also signal encryption for HBO and that kind of thing pretty early on scrambling things, you know, um and that led to cable and satellite TV encryption. And because there was real money behind protecting stuff, and you had to give all of the give access to the data, to the, the consumer that meant there's a lot of innovations in endpoint protection that started early on with, with smart cards and satellite TV and that kind of thing. Um

Deirdre:

a very hard environment to do any computation when you're handing over some sort of way for the secret to decrypt or de scramble to the adversary quote unquote.

Nate Lawson:

Yeah. And, and it, it, it was interesting because a lot of the trends that we saw in software cryptography and things like that later were, um, foreshadowed in, in pay TV and, and, and, um, the smart card industry for that. So, yeah, early on, it was kind of like obscurity. So there would just be descrambling routines and hardware, and, and then eventually smart cards that computed at keen handed over to the unit to decrypt it. But um, it, it grew from there. And, you know, by the late nineties, there was a highly funded. Sort of gray market economy around this, where, um people would hack smart cards and then people would build emulators for them. And then the channel data that was coming down was encrypted video and audio, but also had code updates. And so you had your smart card running code constantly coming with little patches that were coming from the, the broadcaster. And so so you had people doing things of like hashing memory, looking for patches to the firmware of the smart card to see if someone was reusing the card to, to siphon off keys. And then there was kind of a cat and mouse game going on with that. And that was pretty amazing. When I first interviewed at cryptography research in 99, you know Paul and Ben, there were. They had a satellite dish bolted to a, a board and had it stuck out the eighth floor window on market street in San Francisco to like, get, get satellite access. And they were like analyzing as, as a consulting project analyzing this, the smart card and they were doing DPA on it. And, and, uh, as it was deriving channel keys and stuff like that in order to, to figure out how it was working. Yeah. So, so that was one of the first, I think hardware applications of DPA was, was, um, satellite TV cards. And, um, they, they, um, parlayed that into a consulting project or design project you should say to improve the security of smart cards because hackers were just breaking every single one as soon as it came out. But I think the latest one at the time, they were able to the, there was an ASIC on board that they weren't able to emulate perfectly. They didn't have the exact, um, gate layout of it, the attackers didn't, but what they would do is they'd completely compromise the software and then just use it as a peripheral. And so they'd run an emulator on a PC. And it, it would make calls into the smart card just to have it compute this extra little hash function, you know, that was unique to the ASIC on the side. And one of the most amazing things I saw them do was, and, and again, I, I can't take any credit for this. I just saw it happen. But, um, wasn't part of this one, but they they'd used, um, power analysis in order to reverse engineer custom instructions on a new ASIC that was being developed. So they, yeah, they actually were able to identify like the ALU and the, the shift operations and stuff like that, just by looking at the power signatures and were able to feed in different inputs of of encrypted instruction streams into this thing. And then, you know, it would, it would, um, use the signatures bill to say, okay, this is kind of how this instruction operates and then use that to fully reverse engineer and then emulate that chip. And uh that was all done privately for the company, but, uh, it was pretty amazing. They had this software emulator for this thing that hadn't even been released yet in hardware. They're like, okay, well that's completely broken. So what do we do next? And they came up with a really amazing system that I have never seen anybody else do anything like it. Um, they came up with software to design hardware and that's, that sounds like ed Right. But it was software to design hardware using a PRNG. And, um, so, so what it would do is they had a certain gate budget that was gonna be on the next ASIC. And they explicitly said, you know, no JTAG access to this part of the chip. Um, we're not gonna make it testable it's testable sort of as a, as a black box, but that's, it there, it has its own, um, EEPROM behind this cryptographic primitive. Um, but nobody else can access it directly. And then they seeded the PRNG by typing a bunch of garbage on a keyboard and the PRNG would go and, um, build incrementally, build up both a forward and a reverse function out of gates. And so just say, oh, let's just take an XR and then take these inputs and these outputs, and it would randomly mix together the connections of it. And you know, you build, you know, 10,000 gates, 30,000 gates, whatever. And the forward function, the reverse function were different. And these were used as a, uh, component in a block cipher as like in a, like a F network And so they designed the budget such that the most expensive FPGA you could buy on the market could just barely fit this, this whole thing. And it used up all the routing resources and it was, it was like $3,000 in FPGA for the encryption side of it on the head end. And then in the smart card had the decryption side of it. And so they run and just to, they worked on like characterizing this these networks to make sure that they were balanced with linear and differential, encrypt analysis, characteristics, and all these things, all these, it would analyze automatically analyze all this stuff. And then if it passed the test, it would say, okay, I've got a, a candidate here. And if it didn't, it would just start over with a new seed. And so what was amazing about this was it was designed such that, um they didn't actually know what went into the chip. Because they, the, the customer took this software, ran it on their side, put in their own seed. And it spit out in a net list that we we'd never seen. And they sent that into manufacturing. You know, they test it to make sure it worked functionally. And there were some power issues because about half the gates were switching on every clock cycle. So it used a ton of power, but, you know, they were able to work on the power issues and make that, make that all work. And that actually shipped in the early two thousands. And once that came out, the, the emulation attacks just stopped. Like the attackers were set up to like, do like amazing micro probing of Asics and be able to extract secrets from things and glitch stuff. And they were really, really good at all that. But I think the combination of this large, unable 30,000 iterations hash function with random network of gates that, you know, you have to kind of attack the whole thing at once. You can't. Partition out parts of it and just ground a line here, or pull the line high there, or glitch a single line and have it do anything useful. Cause it would just come up with garbage and not derive the correct key if you did any that

Deirdre:

Yeah

Nate Lawson:

But it was, it was an amazing thing to see them design that.

Deirdre:

and it wasn't designed by a human. It was, it wasn't like compartmentalized into pieces and like, you know, having some sort of, uh, you know, applied logic to how the information is flowing through the, the unit it's literally just like garbled the go until it passed all of these conformance tests. And then they're like, cool shit. so it's really hard to reverse engineer something that was not engineered in the first place. It was just like a randomized thing to find a conformant solution. And then if, yeah, it's

Nate Lawson:

And and, and it was used in a cryptographic way that they would encrypt channel keys with this and that the only cards could decrypt it, um, that they, they could have different random functions for different families of cards. So maybe every six months you could just output a new mask design and, you know, do some validation tests and then ship it again. And so you can do revocation based on that, or on key key trees that were used for specific cards programmed into their EEPROM and you could do smart stuff with like offline or partially online, um, pay review where you could do, like send a message to the card, say, okay, you can unlock this pay view event of some, some boxing thing or whatever. Um and only certain cards could unlock that using that cryptographic. And, you know, it would, it would hash all this stuff together, generate a key, compare that to the current state of say a counter in the EEPROM behind this thing, and then only allow the counter to be decremented if it matched. And then once it was decremented, there would be a new, completely random value, effectively random value, then you'd have to match for the next unlock. And so it, it was a really clever way of using cryptography to make it hard, to do point attacks. I, I kind of described this as like a mesh system where all the pieces hold together. Well, it's not like a long chain where breaking any link makes a chain fall apart Um each of these pieces was mutually reinforcing and it made it, so it was a, you'd have to have kind of a parallel attack, breaking a bunch of things all over to really make it useful.

Deirdre:

Yeah. Which is in theory, doable, but it's still harder and it makes the, the bar for successful attack, even higher.

David:

Is

Deirdre:

That's usually enough

David:

is that roughly how, like these systems work now, or have we gotten to a point where you can, like, you have something closer to like a actual network connection between something in space and the thing at your house and you just negotiate a secure channel and speak you know, separate data streams to everybody

Nate Lawson:

Yeah. I mean these days, I think that there still are some ongoing low level attacks where someone will compromise a single box and then just redistribute the channel keys. And so if you, those get repeatedly taken offline, cuz you just do trader tracing or whatever you find out what the box is and revoke that key. So there's things like that. Um, cuz they have to leak the channel keys to all their subscribers But honestly I think most of that's gone kind of into attacking streaming stuff like Netflix or whatever and, and you know, broadcast pay TV itself. Isn't quite a huge market anymore.

David:

Yeah I, I think, uh, satellite radio worked similar. Cause I remember at some point there was, um, uh, growing up, my dad had a radio that for some reason, just got free, serious satellite radio until one day. It didn't.

Nate Lawson:

Yeah, that's I mean, that whole market was where, for example, broadcast encryption was developed for that, um where you had a, a key tree and the ability to revoke subsets of that key tree at multiple levels. So you could say block out, knock out this entire group, or knock out just one person in, in that group with a specific key. And doing that efficiently with, with small messages was what, where broadcast encryption was invented. Um, but also zero knowledge proofs. Uh, this was sort of, I think the first commercial application of zero knowledge proofs. Um there were some, some things like that that were, were part of the early protocols. So yeah, it was interesting to me that was a very interesting industry. There was real value behind it. And, and there were very specific limitations of the systems. You know, it's mostly one way communication from broadcast from the, the, um, the head end to the actual consumers. And you could ship them updated smart cards in the mail that people would plug into their set top boxes, you know, when something got broken. So it's kind of renewable in that way. And so you had this creativity around, um, broadcast, encryptions, or knowledge, et cetera, to try to deal with the problem of people, cracking it and making, um, making money off of that. You just didn't have that in the internet software.

David:

It's interesting that they were doing like key trees back then, because I feel like trees of keys kind of became en vogue in like the Internet world around like 2014 ish with, uh, the work from Joe Bonneau whose name is escaping me and then Certificate Transparency. And then what you were describing for revocation is exactly how like Messaging Layer Security works now for, for group chats

Deirdre:

I was gonna say like the tree KEM stuff is like literally trying to pick this up to get the efficient, uh a key agreement or, uh, availability of keys amongst like thousands of parties who were in a group or whatever. Um, and this was apparently the, en vogue, in a completely different area almost 20 years ago or more than 20 years ago. Wild.

Nate Lawson:

I think the first one I saw was for DVB, uh, digital video broadcasting, uh was the first the first, one, I think, I think one of the IBM researchers was the first person to.

Thomas:

So you were, you were there for cryptography research, kind of doing, you know, the analysis of like the, you know, the satellite TV smart cards, but then you were like directly involved on the Blu-ray side of things. And I think like, nobody cares about Blu-ray discs anymore. So like, no, probably nobody thinks about BD

David:

I think a lot of boomers care about Blu-ray discs still.

Deirdre:

HBO just took down like half of its shit after it got bought. So I have a new invigoration to, to re-up my like Blu-ray collection.

Thomas:

but, but like the, the Blu-ray content protection system is kind of fascinating, right? Like how that actually works.

Nate Lawson:

It was an interesting story. Um, the history of that was that at cryptography research, we had had a lot of connections with both the engineering side of things on satellite TV, but also Hollywood, a little bit for the, um, video. I actually ended up building a, one of the first digital projection, um, systems um, the storage encryption for that. So there was a small company, it was all small companies, but there was a company that was going to like for digital projection and theaters was gonna do the distribution of movies for that. And they're like, okay, we're gonna use the internet for distribution. And you know, at the time that the bandwidth just wasn't there. So we're like, okay, we're gonna FedEx hard drives to theaters you know? And it's like, okay, well we wanna say we have the best security cuz this is like the highest quality content here. Um so we want cryptography research to design some crypto for that. So that was one of my first consulting projects at CR. Helping the small little startup company, we built a, a storage encryption thing that was based off of, uh, SCSI and you'd have a, a SCSI hard drive you'd plug in. It had hot plug, you know, so you'd like plug it in and it would detect that there's this hard drive. It'd be like, oh, I've got an encrypted movie here. Uh, I do a handshake with a smart card that we had programmed and just to like, show how cool it was. You could also in your, in your encryption, you could require a, an online handshake and it would dial up with a modem over a cell phone and do this like secure handshake with a server to get part of the key material to derive the key for that thing. So it was kind of interesting demo. I actually met Chris Coppola uh, who is the brother of Nick Cage. He was

Deirdre:

like, is that a cryptographer?

Nate Lawson:

Nope, he, he is a, he is a director of various movies. And the movie we, we had encrypted was a, a crazy like horror blood Fest kind of thing that he had that he had created. And so that was the first demo of this crypto system was, you know ultra secure encryption. Probably a movie that didn't see wide distribution. So, but uh, that was a fun story. Uh but yeah, through that, I, I think, um, you know, Paul was projecting that, you know, there's only gonna be a few more generations of optical disc, um, and hard drive capacity is growing. You know, there was Limewire and, and Bit Torrent and all this stuff, people sharing movies. And so, you know, Hollywood was as scared as, um, the sort of recording studios were in the late nineties. Um, and uh, so they wanted to figure out like, what are we gonna do next? And, um, there was probably gonna be one more disc standard after DVD. We didn't know what it was gonna be, but at the time it was the DVD forum that was trying to standardize something. So, you know we, we joined the DVD forum and started working on designing, like what kind of system would, would, would work for these kinds of things. And the general idea was to kind of take what we had learned in satellite TV and build something that's more standardized. to be able to have each disc or each title at least have its own protection scheme. That changed over time. The goal was always focused on let's preserve the release window. You know, you've got 30 days to make your money back on your DVD. And at that point, whoever is gonna buy Big Mama's House 18 has already bought it and you're not getting long residual sales. I mean, Disney was kind of a custom case there because they have things that last forever but like every other studio was like give us 30 days and we've made 90% of our money on that. And that's that's good enough. Everyone understood that you, you couldn't have perfect security forever.

Deirdre:

Which is great because there are some, there are some systems in some organizations where they're like, no, it is indefinitely has to be protected. And it's like, that is a lot of investment for not a guaranteed outcome. And like, so having the, having the clarity to be like, we just need it to be protected for a finite amount of time is great.

Nate Lawson:

Absolutely. I mean, when people got it, they, they would say that sometimes there were some, some studio people that wanted perfect security forever and, and we try to talk them about how that wasn't possible, um, and set expectations. But we started working on this, this design of a system, um, it was called self protecting digital content. And, um, the idea was each, each player would have a, a virtual machine that was standardized. And that was just an execution environment. You build your own copy protection and software. For that one disc that you're shipping and it would do whatever we needed to do to counter the known attacks at the time. So it was paired with like a, a key tree as well. It had, uh, the player had signature keys. It could sign stuff for, you had encryption key trees. So you could, could be revoked if this specific model or, or serial number was, was compromised and the keys were leaked. And then the software could also do some things to try to counter whatever the pirates were doing. And the thing that took a long time to convince people of, but, um, was, was how we wanted to sort of fight this battle was people would always come up with a one off attack. They'd say, well, what if I can, you know, use side channel analysis and get hardware keys out of a Sony player or whatever, you know? Um or what if I can reverse engineer the software player and get the keys out of it. And we. Yes, that's going to happen, but people have limited resources who are attacking the systems. They're going to pick their favorite thing. Maybe they're really good at Windows and reversing there, or maybe they've got, you know, hardware ability and, and they're constantly probing DVD player like hardware, DVD players. So for each attacker, they'll be their own specialties and they'll go for the weakest part that they can do, but that can also be targeted to slow down those attacks So, for example, let's say you extract keys. Well, you can do operations with the encryption keys, and if you're in an emulator, you'll be running on the same keys as. Uh like, meaning if you're running an emulator for like a hardware player, you'll have the, the key saying "Hey, I'm a model 1000 whatever", but the timing is different in the emulator or it's because you're running a software on a PC or things like that, or ripping software. The events that the users pressing button events are coming in at a different rate or different synchronization with various events happening within the, the computation environment. So all these things could be detected as differences between someone trying to attack you as an simulator and the actual real thing. And all you needed to do is you didn't need to anticipate every way someone could do this. You just needed to be reactive and a little bit proactive encountering what you think their next move might be. And so that's what we did. So we build a system that had these capabilities that we call it. Renewability that, uh, each time you had a new disc, you could do something different. Um, and it was really interesting when, when it came out because we had no idea which routes attackers would take. and sure enough, you know, ripping software came out and you know, first people sort of targeted software players by extracting keys from those, you know, and software players, because PCs had to be online. At least some of the time you could require more frequent updates. So, so of the player itself so you could just be like, you know, rev your keys, software player every month or whatever it is with a new update to it. And also patch a few ways that we think their, their reverse engineering software, uh, for hardware players, like once that was starting to get countered hardware players where the new target and people found a few models where they could extract the keys relatively easily from the hardware. And they started using those, but those were really constrained environments. And so it was really easy to characterize timing differences and implementation differences of servos and stuff like that. You seek here and suddenly you're just instantaneous seek. And one of our big updates we did that I had a lot of fun with was um, you know, there's a bunch of titles coming out for the holiday season and it's like, okay, that's where a lot of money's gonna be made. So we wanna do the best thing we can. So we built something a little bit similar. This was sort of my baby, which was a randomized hash function that was built from both the user. There there's a Java side that runs BD-J, which is the, um, like the menus and the animations and stuff. And then there was the, the BD+ VM, which is sort of the content protection and both of 'em are running at the same time. There's communication channels between them. So I was like, okay, I'll build a hash function that half of it's implemented Java and half of it's implemented in C and it's randomly generated by a code generator that, that each round of it and the interchange between rounds of this hash function, their, their values. And each one is hashing in just a ton of. And we reverse engineered a bunch of the software, hardware player, software players. We had gotten some of the characteristics and timings from the hardware players, and it would pick for each player, family who would pick a hash function to execute and decrypt it, using the keys for that device and just execute it and be like, okay, uh, that's the Java side. We like throw an exception of a particular kind and then walk the stack, trace of the exception and grab strings out of it and hash those and, you know add some numbers together and divide by zero and check exception, uh, out of the stack of that. And on the, on the sea side, it was, you know, analyzing timings of response times of the Java side and all, all the stuff was being fed into it. And there what we call chaff, where as well, which were just like garbage things, which weren't actually useful, we were checking and it would always be the same on a particular model player or whatever, or it wouldn't vary very. But there was just like, you know, a dozen of these checks in each side with custom hash function built around each of them. And then the value be used to decrypt next stream, chunk of stream in the audio, in, in the video. And so this system like really took them a long time to implement because they had to pull in a whole JVM. They had to like reimplement all the class libraries and all this, they had to get it right, and figure out what we were checking for. And then each title, we just roll out new fingerprints that were fingerprinting new aspects of the behavior of these players. And that, that took them a long time. I think it took them. I'm gonna, I don't know exactly. Maybe 30 to 60 days to crack that one And at the time we were, had some knowledge that they were getting early advanced copies of these discs with the protection on it, um, and were getting a head start on, on cracking them. So,

Deirdre:

so that does sound like it's a lot of work to fingerprint each new system slash title, to update the parameters of how to generate these bespoke hash functions that you need to do the key derivation. So where was the, the, the trade off the, the marginal trade off point between how much work it was to ref fingerprint the parameters to generate these hash functions versus how much it bought you against the, the crackers.

Nate Lawson:

W we had standardized the test disc that we'd play in a bunch of players, and it'd print hash values to the screen of various fingerprints. So each time players were being, um, even the hardware players would have an update and there was a way to do a firmware update from the disc as well. So over time sort of hardware players were, were staying up to date. So we, we could rerun the testis on new versions of it and characterize new things. So it, it was a little bit of work, but it wasn't terribly hard. The thing was, was that the attackers were getting much better at just writing a bunch of code for emulating something and run the, the protected disc in their player and try to guess what sort of what we were looking for. And so it, it worked pretty well for a while. I mean, one of the most the funniest, the highest bang for the buck efforts was--- And again, this, when you look at DRM, you're looking at the whole system, it's people, it's tools, it's techniques, it's money, resources, um, compute types, what operating systems people use, maybe you know, someone uses Vi or Emacs you can target them differently or whatever. But, um, you know, in this case we had some information that one of the developers had a big vacation planned of, of, of a ripping software. And so we had this inside tip and they're like, oh, this person's going on vacation. And we think that the junior developers who back up this person aren't actually any good. So we did a minor tweak of just shifting a few things around to an existing scheme that had been cracked already and shipped that on the titles that were coming out during those summer months, that this person was gonna be on gone vacation. And sure enough, their forums lit up with, like, I can't rip this. I can't rip that. And then the junior developers got on the master boards and they're like, oh, it's been a major change in the software. You know, we're working on it really hard, this, and I think we got, I think we got like 30 days out of that one and it was the tiniest easiest change, but they didn't know what they were doing. And we knew

Deirdre:

wild because I wouldn't,

Nate Lawson:

gonna get back to it.

Deirdre:

I wouldn't have imagined this sort of like counter intelligence, like tac to your attackers and then counter measures based on your intelligence incoming about like this extreme cat and mouse game, but in, in the Soviets versus the CIA style of like that's, that's wild

Nate Lawson:

that was the fun thing about Cryptography Research was everyone played for keeps. I mean, everybody was doing everything they could to, to be successful and we didn't leave any stone unturned. That. I mean, when you look at these, like I said, these are ecosystems, you're working with people and tools and techniques and, and resources, and, you know, it could be as simple as buying a PC for, you know, somebody who works on a, a, a wears firm or whatever like that. And, you know, they'll, they'll tell you stuff. And, you know, so there there's, there's lots of interesting ways if, if people, um, when people are dealing with fraud, for example, in the credit card industry, if they're not really sort of knowing the attacker environment and, and adopting to it, they're, they're leaving a lot of capabilities on the table.

David:

Do you think that this was, was this like a differentiator between like Blu-ray and HD-DVD, um, when that battle was happening or is this kind of independent of all that? Like, was this like, were studios coming, being like, oh, "we'll do Blu-ray because we think that their copy protection is better"? Or was that not even part of that discussion?

Nate Lawson:

It was very interesting. There were a couple studios that it mattered a lot too. There were others that it didn't seem to matter at all to, and it was all horse trading. It's like, you know, in fact, I think there was one executive in the studio who even had some IP in some kind of, some kind of, part of a laser system of part, some existing DVD red laser system or something like that. And so they were gonna make money regardless. And so, you know, there there's, there's things like that where the incentives weren't always aligned. We, we kind of approached it, I think a little bit naively in thinking that like studio, if you can offer something that's better, studios will all get behind it. Just be like, yeah, we want this to be better. But, um, I, a few people, it was like, you know, like, well, if there's any kind of cost to this at all, if it's not completely free, we're not gonna do it. Um, because we're about like the lowest margin possible discs and we wanna get the production costs lower. We don't wanna do any custom animations for our menus. We just wanna like ship this stuff constantly. And others that cared a bit. It offered value, but the value was sometimes hard to define, um because, you know, if, if you ha if you get 30 days of protection, but the attackers got the disc 30 days early, it looks like you had a zero day and, and you didn't offer any protection for the release window. So it's, it's one of those things where it, you have to get it right at all stages of production to actually show value. So I think this, it was, it was successful in particular instances, but overall, as a scheme, it was very comp complicated and unwieldy and hard to keep all people rowing the same direction in terms of the industry.

David:

Well, if I remember, right, I think Blu-ray was considered to be like the better technology. So this time around, I guess the better technology did win out shipping code on the discs to the VM though. That's very clever.

Nate Lawson:

Thanks. The, the actual, like HD-DVD versus Blu-ray from the inside, it looked very different from the where, how it looked on the forums in the mid two thousands. Uh, on the forums, it was like, oh yeah, Microsoft is pushing HD-DVD and this and that. But you know, Microsoft didn't really care that much about HD-DVD. It was to them, a stock horse to prevent Sony and mess with Sony's efforts on the PlayStation 3 which they really cared about. Cause Microsoft at the time really wanted to own the living room. And at the time there wasn't like the iPod was sort of going well, but there wasn't like no one had mobile devices as the centerpiece of people's digital lives. It was a home server and the home server was probably a game console for most people, or it may be a DVD player in this case. And so Microsoft was laser focused on pun, not intended, but, uh, focused on owning the living room. And all they cared about was we need to be in control of that. And so anything to slow down, prevent people from getting in the way of the Xbox 360, they were gonna do. So they actually pretended that they're like, we're gonna join Blu-ray. They kept making noises about that internally. And like, if you just tweak this change or that change we'll join, but really they're just trying to, to throw up discord and, and slow down the effort as a whole. Um, so I don't think anyone adopted Blu-ray because of the copy protection. Um, it was more about like more disk size, uh, storage for that storage capacity, the ability to scale, to more layers quicker. And the fact that HD-DVD was kind of a me too, uh, format originally, it was gonna be red laser, uh, dual layer, DVD discs. So it'd be really cheap. And so its like, oh nine gigabytes dual layer, uh, with a high quality codec you know, the, um, uh, AVC uh, H2.64. So the idea was you could do almost Blu-ray like things, but it wasn't as, as high quality. But then the studios were like, no, we want blue laser with whatever. So, so the DVD forms like, okay, we'll do blue laser too, but you know, and, and, and Sony was originally part of the DVD forum with, with the blue laser technology and then forked off Blu-ray because they weren't getting anywhere in the DVD forum. So all kinds of horse trading and

David:

I assume that's when like Microsoft decided they were just gonna play interference because that's the type of disc that the 360 used for games was the dual layer DVDs. And then, and that strategy seems to have worked cuz for the first like three quarters of that generation of consoles, the 360 dominated the PS, uh, three, and then they changed executives and absolutely pooched the next round. And then Phil Spencer has done, um, an amazing job with that division after the next round of executives got booted.

Thomas:

I, just remember by this time in our lives, right. Like I had already, I'd moved to San Francisco. We were actual friends by then. So I was talking to you like quite a bit while you were doing this work. And all I remember about this time period was your constant laments of being involved in the standards efforts.

Deirdre:

Oh

Nate Lawson:

was awful. Yeah, absolutely. There were, there were times when, um, people would call an emergency meeting that you had to get on a plane to go to Tokyo for. And the the whole purpose of the meeting was we're gonna vote on this one thing. And it was just to mess with people, to get them, to have to drop everything and go to this meeting. And if you didn't show up, you're gonna get voted out of the thing. Because you, you only had a narrow margin of, of votes for you. And they're like, we gotta get rid of this, you know, 10 person company in San Francisco. And uh, so if we do enough of these random meetings, you know, eventually they won't show up to one or they fall asleep or get to the wrong room or something and we'll, we'll, we'll be done with this. So

Deirdre:

And it was Tokyo because Sony and that's where all these devices were being manufactured, basically.

Nate Lawson:

it, it, it was all, it was all rotating cities. It would be like, oh, it's gonna be, I mean, my favorite part was when they had held at, as meeting in Honolulu and I was like, okay, free trip to Hawaii. That's not too bad.

Deirdre:

Honey. I, I have to go. I have an emergency trip to Hawaii.

Thomas:

For one 15 minute vote.

Deirdre:

yeah.

Nate Lawson:

That one was actually a more substantial meeting, but yeah,

David:

You, the NCAA did this during COVID they're like the only way that we can vote on who's in the college football playoffs is to have an in person meeting in Hawaii in November of 2020.

Deirdre:

it's an emergency

Thomas:

well, Nate, we have, uh, we have worked our way approximately halfway through your career career of war stories. And while I would love to do a four hour episode of this show, I think what we're gonna do is drag you back at some point. So

Nate Lawson:

happy to come back.

Thomas:

well, okay, Nate Lawson, you are one of my favorite people in the world, outside of my actual family members. You might be my favorite person in the world, so I'm, I'm thrilled to have been able to talk to you on this is awesome. So,

Deirdre:

Thank you so much.

Nate Lawson:

thank you all. I, I, I really wanna get to some of these other stories, which were really interesting

Thomas:

do we, we, so do we.

Nate Lawson:

okay.

Deirdre:

cool. All right.

Nate Lawson:

Well, take care, everyone.