[MUSIC]
 Okay.
 Hello everybody and welcome back to the Millie Way Stage here.
 We will have your presentation starting at two o'clock shortly.
 Just got some general announcements and information for you all.
 Don't forget to wash your hands, be healthy, be safe.
 Basic COVID precautions.
 Unfortunately, we haven't had zero incidences.
 There are masks and test kits available at the info desk,
 if anybody feels like they would like to make use of them.
 But just be safe and wonderful and excellent people and washing your hands goes a long way.
 Also general announcement,
 if anybody has any unused but still usable items that they're
 packing down and not going to be taking home,
 they are taking donations at the info desk as well.
 If you want to drop off things like extra tents or food,
 as long as it's non-perishable,
 they'll be taking collections there so you have a little bit less to pack in and take with you.
 One other thing, I hope anybody,
 have you all seen a talk here yet at Millie Way?
 Has anybody enjoyed the movie last night or see some good stuff?
 Well, hopefully you'll enjoy a couple more here. What was that?
 Oh, who was here for karaoke last night?
 Okay. Well, yeah, you weren't here this morning,
 but I could still hear you at 6 AM.
 So yeah, thanks for that.
 So speaking of, this stage is being put on by Millie Way's,
 which is the camp just behind us and also has the restaurant,
 of course, at the end of the universe.
 You're all welcome to join, hang out,
 have some food, always appreciate donations and things like that.
 But if you really want to chip in and be excellent and join us in
 the solidarity of not losing too much money doing all of this,
 we do still have some challenge coins available.
 So Millie Way's creates these cool coins every year.
 There's Millie Way's on one side and a 2023 on the flip.
 This is a pretty cool silver edition and there are a now limited edition black coin as well.
 So 30 euro or better donations are much appreciated.
 You can hit me up here or the info desk right behind us also has more coins,
 including ones from previous years.
 So if you are at say 2017 or 2019,
 Congress camps or otherwise and really miss one of those coins,
 you can get one for an extra special offering.
 So yeah, hope everybody enjoys their evening and we'll go ahead and get going here with what you all came for,
 which is to see Mark.
 Surpizer, that's not Mark.
 This is the unlock the door to my secrets,
 but don't forget to glitch.
 Unfortunately, Mark is recovering and not able to physically get themselves here,
 but has given Sylvan all the information and you fantastically offered to come and give it.
 So we don't have an empty stage.
 So with that, I would like to thank and welcome Sylvan to the stage,
 presenting Mark's talk on unlock the door to my secrets,
 but don't forget to glitch. The stage is yours.
 Thank you. Thank you.
 Okay, first of all, let's give a good recovery to Mark.
 He would have loved to be here,
 but I hope I can represent him well enough.
 First of all, about me slides, it's not about me, it's about Mark.
 We both work at Fraunhofer, so the first part is still the same.
 We do hardware security.
 Mark is focused on embedded system security and does fault and side channel analysis,
 but he's also an open source contributor to OpenOCD,
 the well-loved debugger, libjlink, and others.
 If you want to know more about Mark,
 if you don't know him yet, you can follow his blog.
 But about me very quickly,
 I also do fault and side channel analysis,
 but I'm more on the analysis side.
 So I hope I can answer your questions if you have any well enough,
 but my focus is not so much on the embedded part,
 but more on the analysis part after.
 But about the microcontrollers that we'll be looking at today.
 First of all, we have microcontrollers.
 We have one here, but they're omnipresent, they're everywhere.
 You have them in your tokens, in your crypto wallets.
 You have them also in your smart thermostats.
 You have them pretty much in all embedded devices.
 But they might contain some secrets in the tokens and crypto wallets.
 It's an easy thing.
 They have cryptographic keys, but also the others.
 They have some intellectual properties that you might want to use,
 that you might want to alter, that you might want to read out.
 But of course, the manufacturer,
 the producer of such a device doesn't want you to.
 So our research is trying to find new attack vectors for this,
 new hardware attacks.
 But our goal is not only just to break them,
 but to make things more secure.
 So we have a responsible disclosure process still running on
 about all these things in order for the manufacturers
 to make things better, hopefully.
 On this specific one, we have hardware faults that are there.
 So it's hard to improve on the already out there products.
 But we'll come to that later.
 First of all, what's this talk about is about debug protection.
 You have a device, you're programming, you're developing it.
 You have full debug access, of course.
 So you have access to everything and of course,
 are able to read out and write to the flash memory.
 Once you want to ship this product,
 you want to make it ready for release,
 you want to switch to limited debug access.
 So during this, in this phase, you
 have no access to the flash memory.
 You can't read or write to it.
 But you can still access some of the debug features
 in order for a device to see if it's still running,
 if there's some other problems with it
 that you could do some checks on the memory and stuff,
 if it's still working or if there's some hardware fault.
 Some devices also have a full debug lockdown,
 full debug disable, the full debug access.
 However, that's not very common.
 In most microcontrollers, they only
 have this limited debug access.
 And this is essentially the path that we're looking at today,
 how to get back from this limited debug access
 to full debug access without losing the content.
 So you have the limited debug accesses.
 You're able to, for example, use the SRAM
 to write a program to the device to run it,
 but you can't run the flash at the same time.
 But you can do a flash and unlock an erase function
 in order to get back.
 And that's actually the problem.
 If you go back, you erase all the memory content.
 And that's the goal of today's talk,
 was how to access this secret, how to unlock
 the secret with the glitch.
 So the glitch comes in exactly here,
 trying to glitch this mass erase function.
 How do we do that?
 We first of all looked at the timing of how this flash
 and erase function works.
 So you're able to access the debug access
 through the debug port.
 You're able to access the device.
 You're able to tell it, OK, I want to reset you.
 I want to flash and erase the whole device.
 Unlock it at the same time.
 And this process is a simple command you give to the chip.
 And it takes about 50 milliseconds.
 And what we have here, it's an activity profile of the chip.
 It's essentially over time how much power, how much activity
 we have on the chip, how much power consumption
 we have on the chip.
 So you see in the areas where there's lots of peaks,
 there's a lot of stuff happening.
 And at the end and front, you have nothing happening.
 And you have a small gap in between.
 And so we analyzed this and looked
 at what are the timings on this.
 We have first, at the beginning, we
 have a small part which we derived
 to be the part where essentially the erase function is triggered.
 So that's where the memory is actually erased.
 And then we have a larger block where there's
 something happening but that doesn't delete the memory
 further.
 We have another erase function part that's very similar.
 You see the two parts are very much alike.
 But it's just a little shorter.
 That's the part where the settings are deleted.
 So that's where the bit is deleted that essentially
 locks the device down.
 Then we have a similar large block doing some recovery parts.
 And then we have five write operations which we decluded.
 This is essentially where you write the five setting bytes
 again, setting the initial setting to the chip,
 writing what essentially this chip is from factory mode.
 So essentially open debug access,
 being able to read flash memory.
 So what is our goal?
 Our goal was to hinder the first operation,
 hinder this erase function with a glitch.
 So for this, we tested different devices.
 So I have one device with me here today.
 And on this device, I want to show you
 what we do for the simple setup.
 So we have a small developer board, an STM32 chip.
 And first of all, of course, we connect it to power.
 And then we want to be able to glitch the power supply.
 So the first thing is remove some capacitors,
 adjust the capacitance so you can actually
 adjust the power supply without completely killing the chip,
 but without all the capacitance just smoothing out
 your glitch signal.
 Then you want the chip to be more sensitive.
 So you lower the supply voltage to the lower end of the specs.
 So instead of 3.3 volts, you go down to 1.9 volts.
 And then, of course, we want the debug access.
 So we take out the debug ports.
 We also will feed out a trigger signal.
 So we will write a small command to the chip saying, OK,
 pull up the trigger signal.
 Do the flash and erase function.
 And then we have a perfect timing for our glitch
 to happen at the right time.
 So we will take the glitch, which is essentially
 just shortening the power supply for a very short time
 in a specific shape.
 For this, we use a device that just alters the power,
 just shortens this for a very short time.
 And that's essentially the setup for the demo I have here.
 Let's switch to the demo.
 Here we have the chip whisper board, which essentially
 alters--
 I hope you can see it--
 which essentially alters, which is my debug interface, which
 I have USB connection to.
 And here I have the STM32 board that I just showed you.
 I have all the wires connected, as I just showed you
 in the previous slide.
 And now you see the three LEDs.
 Let me go back.
 You have three LEDs on the chip here.
 And you see them here blinking.
 They should be blinking.
 So that's essentially the program that we're running on
 here right now.
 You have three blinking LEDs.
 And we want to read out the memory content of the flash
 that runs this program.
 So first, I will connect OpenOCD to the chip.
 And this should probably hold the program, because once
 you're in this limited debug access mode, you don't want
 any interaction of the debug port to the flash memory.
 So the chip has a direct--
 the chip is locked right now.
 So once I open the debug port, the chip holds program
 execution from flash.
 I can do my programming from the debug port, but the flash
 memory is not used anymore.
 So now we'll connect--
 here on the left side, it will connect to the OpenOCD
 debugger.
 And it will just try to read out the memory.
 So it will read out the flash memory here, 256 bytes, and it
 fails.
 The chip is locked right now, so I'm not able to read out
 the memory.
 And here, I already have the glitch set up.
 The glitch script, this script tells this debugger, this chip
 whisperer, to send the flash and erase, flash and unlock
 command to the chip.
 It will run it.
 And just at that time, I have here the glitch connection,
 which will trigger that glitch and interrupt the erase
 function.
 So let's try this.
 And it's unlocked.
 I can go back.
 [APPLAUSE]
 And I can read out the memory.
 And now, if there's any secrets--
 I mean, the secret code of how the Blinky lights are working.
 Let's reset the chip so it's running again.
 Now you see, even with the debug mode and debug access
 activated, the chip is running.
 So it's completely unlocked.
 OK.
 That's essentially the demo.
 That brings me to the end of the talk already.
 The glitch flash--
 so I'm able to glitch the flash erase function to gain full
 debug access.
 So switching back from this limited debug access mode,
 while glitching at the right time, I'm able to access all
 the flash memory content.
 I showed it to you on one specific microcontroller
 here, because this is easy to bring set up for here.
 We also tested-- or my colleague Mark tested multiple
 different microcontrollers from different manufacturers,
 which were all affected by a similar attack.
 The results are still in the process of being published.
 With responsible disclosure, everything in the paper right
 now is under review.
 So I can't show you the actual result.
 It now is under review, so I actually don't know all the
 details about which other ones, but there's multiple.
 And maybe the most important thing for you is how to
 protect yourself.
 Yeah, you can apply specific mitigations.
 For example, don't use the flash for very sensitive
 content.
 But the problem is you cannot really mitigate this attack
 because it's essentially a hardware attack.
 It's in the hardware of the device.
 Yeah, that's essentially the end of the talk already.
 If you have any questions--
 Anybody here with questions, if you'd go ahead and line up
 over here at the mic, and we'll take some questions.
 First, let's thank not Mark Sylvan for a
 fantastic talk today.
 [APPLAUSE]
 And we've got the first question for you.
 Yeah, you're sat at the race for the talk.
 You said that the erase function is prepended to the
 function where the bits which do the protection are reset.
 So what is your power supply timing to disable the erase
 function, but enable the--
 It's a very short glitch.
 And then it just jumps over the chip erase to resetting the
 bits where the flash is on.
 I think you see it again.
 You have the three parts, essentially.
 And in the first part--
 It's very difficult to see.
 That's the problem.
 Yeah.
 So we'll mention here in the audience, the screen is a bit
 difficult to see, but this is being recorded.
 So just keep in mind, you can go back to media.ccc.de and
 pull up the talk and get crystal clear HD on the slides
 that may or may not be washed out.
 OK.
 About your question, it's like essentially it's a 50
 millisecond time frame.
 Where did you go?
 It's a 50 millisecond time frame.
 And you just do the glitch at the very beginning where the
 memory content is erased.
 And you just drop the power supply for a very short time.
 That's essentially what this chip whisper is able to.
 You just set settings essentially this short and
 this very specific timing.
 And you just hinder the chip from erasing the memory.
 But essentially the bug here is that it still continues,
 even though it didn't erase.
 It says, OK, erase function didn't work.
 Anyways, let's just unlock anyways.
 So it should just--
 if the erase doesn't work, it shouldn't unlock.
 But unfortunately, it doesn't erase, but it still unlocks.
 So that's what it's--
 [INAUDIBLE]
 Yeah.
 It doesn't check that it's actually worked.
 Yeah.
 Are there not brownout detection circuits that will
 prevent this?
 Could the erase functionality detect a
 brownout and try again?
 It could.
 Yeah, it could.
 But it doesn't.
 How can we reproduce this attack ourselves?
 I don't know if the scripts are online or what the details
 in the paper are.
 But this chip whisper is ready, available.
 And then it's just trying to figure out the exact timings.
 But I guess you just have to wait for the paper which
 information we are able to publish here.
 Can you mention again which board is doing what here?
 This board here on the left, that's a chip whisperer.
 That's an off-the-shelf device for these kinds of hardware
 attacks.
 This essentially shapes the glitch.
 And this is just a voltage conversion, this small board,
 just to get this 1.9 volts.
 And that's just an STM32 developer board, just off-the-shelf
 developer board, which we removed and adjusted some of
 the capacitors to have the right power supply.
 So if you would have a product, you would maybe have to
 desolder or adjust the capacitance.
 But of course, as it's in the power supply, the capacitance,
 you could also adjust it with adding capacitors here, which
 we have one that's plugged in here.
 Sorry for moving.
 All right, and we'll say we've got a few
 more questions for you.
 Yeah, you said you've done this with multiple devices.
 I'm just curious, how difficult is it to find a level to sort
 of drop it out to that doesn't brown out the chip so it stops
 executing code?
 But still stops the flash erasing?
 How hard is it to find the right timing?
 It's like, is this an easy attack?
 I'm always outside of the lab, so Mark is doing the real
 work there.
 And it does take some time.
 So for example, we have the advantage to be able to
 record and analyze the chip very detailed.
 So we actually have a probe that we can set on top to
 measure the electromagnetic emanation of the chip and
 analyze what exactly is it doing or guess what it's doing.
 And so we were able to look at these traces and see what the
 timing is.
 We tried it with different data.
 We tried it with an empty chip, first of all, to
 understand what's actually happening there.
 And then once you know which operation is, then you can
 adjust these timings.
 And then, of course, you have a frame of--
 you try short, long, intense glitches, different shapes.
 And you just have a script run overnight, and it'll try
 everything.
 Do you have any idea which process you are
 exactly affecting?
 The erase function.
 But I mean, which part of the erase function?
 Is it maybe charging up power or something like this?
 Or is it already erasing?
 My guess, from the discussion with my colleague, it seems
 like essentially we're dropping the power.
 You know how a flash cell, in order to erase it, you need
 power to essentially get electrons out of this floating
 gate there.
 And that needs a lot of power.
 And essentially, when you take off the power at the time, it
 might not pull the electrons out, the charge out.
 And then you don't have an erase.
 I think that's the guess.
 But it's just an educated guess from a black box.
 How many dev boards did you need to figure out the right
 timing and all that?
 I don't know.
 Probably around 10, I would say.
 I don't think we have a big pile now.
 I don't know.
 And do we have any questions from the internet?
 And do we have any other questions?
 We've got just another minute or two here if there's a
 follow-up question.
 What should we do if, for example, such an
 error exists in a chip?
 Should we choose another chip to prevent this?
 Or is it just an error that's so difficult to reproduce that
 we can ignore it?
 It depends what you want to protect.
 If you have an open source project on this, there's not
 many assets.
 Unless you have an open source project without any keys on
 there, there's no asset that you're protecting.
 But if you have intellectual properties that you don't want
 to get distributed--
 for example, for the cryptocrafter keys, you can use
 a hardware chip, extra protected, secure chip.
 But for the others, the problem is we only
 have limited research.
 I don't know if there was any chip that they couldn't
 succeed.
 But of course, that just means, OK, they didn't find
 the glitch.
 So it's hard to say, OK, use this chip instead.
 All right.
 So what do you think about glitching?
 I imagine everybody here is somewhat familiar with glitch,
 but we're talking all kinds of things-- glitching,
 brownout, et cetera.
 If we're trying to talk to you, maybe doesn't have a chip
 whisper at home or whatever else, do you have a way to
 summarize what is glitching in a not too technical way?
 Glitching, it's essentially just like flickering the light
 while it's running.
 So just flickering with the power supply while the program
 runs and giving some faulty operation with this,
 essentially.
 And the idea is if you do this dozens of times, millions of
 times, eventually you'll get lucky.
 And flipping that switch, it'll think, oh, I totally got
 a valid command to do this other thing that I shouldn't
 have access to do, but I'm going to do it anyways because
 I don't know better.
 Yeah, exactly.
 Exactly.
 But when you have this specific timing, you don't have
 to get lucky.
 Like this essentially runs every time now, once we have
 the timing right.
 Gotcha.
 Very good.
 Well, thank you so much.
 And really appreciate the talk.
 So once again, I'll retitle this slightly.
 Sylvan and Mark's talk on Unlock the Door to My Secrets.
 Thank you so much.
 Thank you.
 [APPLAUSE]
 [MUSIC PLAYING]