I appreciate all the details they provide in the post. The $250k in lab gear is useful when initially discovering, exploiting and documenting attacks like this.
Definitely doable in a home lab for under $25k in equipment, likely under $10k.
Same as my replicating Colin O’Flynn’s BAM BAM attack on a MPC5566 chip, he used a ChipShouter ($5,000) and I used a PicoEMP ($50).
Nice, thanks. I had wondered whether the $250K in lab gear is something that a serious HW security lab would already have on hand, as opposed to specialized expenditure for just this attack. I mean I rode in a $250K(?) motor vehicle a few days ago (the #2 SF Muni bus towards the Marina) but I didn't have to spend a lot to ride it, since it was already deployed. Nobody had to go out and buy it.
I have an application on an SPC58 that I really want to know more about. But unfortunately; it’s a dual core with lockstep. So if it could be done; I think that automatically double-pluses the budget.
Don’t need lasers for that chip, it absolutely can be done with enough time and effort.
Don’t let fancy language like lock-step dissuade you from trying. The people who configured that chip also have to have done their job perfectly or it might still have a way in!
The RP2350's secure enclave made it particularly attractive for use as a Yubikey alternative.
There will always be an arms race between safe-crackers and safe-builders. Presumably the lessons learned will help make the next generation tougher to break into.
Well yeah, but I would like to be able to make my own safe that is at least very difficult to crack if someone steals it. Companies are seemingly hellbent on stopping me owning the stuff they want to sell to me regardless, I might as well benefit from the same tech.
There will always be an arms race between safe-crackers and safe-builders.
This is dismissive and glib. And it's the wrong lesson.
You wouldn't say this about symmetric cryptography. AES-encrypted ciphertexts from 25 years ago are still secure today, and nothing on the horizon is likely to change that. No arms race.
The "arms race" exists because the security model for trusted hardware is intrinsically flawed. If the attacker has physical posession of the device, your security is transient and at the mercy of the arms race. So stop doing this! Trusted hardware also has extremely negative externalities on the whole computing ecosystem.
(*) or 45 years, if you exclude cryptosystems (56bit single-DES) used only because of silly export laws.
I tend to agree that there are issues in the realm of hardware token based security but they largely lie in the failure modes, with substantially increased difficulty of recovery.
For the average user these approaches make data loss MUCH more likely simply because you need a corporate IT department level of competency to consistently avoid data loss with them.
The glib exaggeration of this is that in not being permitted to manage and back up your own keys you actually create the situation where you have to hire someone to extract your keys for you and break into the device you own because of the failings of the technology!
It's only the wrong lesson if you believe that making it more difficult for governments to seize and decrypt their own citizens' mobile phones with impunity is not a valid goal.
> the security model for trusted hardware is intrinsically flawed.
It's only intrinsically flawed if you expect absolute perfection.
The fact that some math-based protections may be theoretically better than physical protections does not obviate the utility of physical protections, whether we are discussing computers or phones, or houses or cars.
It has been accepted since before any of us were born that there is no such thing as perfect physical security. Even your putative perfect cryptographic security still relies on the physical security of the plant holding the keys.
> If you think trusted computing is a defense against nation-state attackers, we inhabit totally different realities.
I have no idea how or why you would think I think this, since what I wrote was exactly the opposite of this, e.g. "It's only intrinsically flawed if you expect absolute perfection" and "It has been accepted since before any of us were born that there is no such thing as perfect physical security."
In any case, if you think that every piece of information that ordinary humans want to protect is worth it for nation-states to waste their million-dollar attacks on, we inhabit totally different realities.
And yet, there are many pieces of information that ordinary humans want to protect that many nation states would easily throw thousands of dollars at.
In other words, the fundamentals behind security are the same as it ever was.
>> There will always be an arms race between safe-crackers and safe-builders.
> You wouldn't say this about symmetric cryptography. AES-encrypted ciphertexts from 25 years ago are still secure today, and nothing on the horizon is likely to change that. No arms race.
AES encrypted ciphertexts are not a safe. A safe is a physical object.
> If the attacker has physical posession of the device, your security is transient and at the mercy of the arms race.
That's what we're discussing, yes: a scenario in which physical access to a safe is already acquired. Given that context, don't you think changing the topic to 'non-safes' and 'avoiding physical access' is a little dismissive and glib?
I have a side question. I looked into the linked Raspberry Pi hacking challenge, and there's something very basic I couldn't figure out: It looks like the relevant script in the repo just writes 0xc0ff 0xffee a few times to the OTP as the "secret" to unlock. But given that $20000 was up for grabs, this can't possibly be the genuine secret being sought to claim the prize. (Indeed, I can't think of a secure way to install a secret from a public GitHub repo unless it involves running on-device code that encrypts something using some other, factory-installed secret key, which is just kicking the can down the road.) And given that the OTP on a brand new RP23550 is initialised to all zeros, it can't be that the genuine secret is programmed in at the factory either.
What am I missing? How does the genuine secret get installed on a person's RP2350?
> If you think you have found a break email us at doh@raspberrypi.com with details - we will ship you a Pico2 with a custom secret hidden in it. If you manage to extract it, you win the $20,000!
I'm confused by a number of comments here and the article seemingly taking a position that a $250k lab instrument is required.
For one a similar instrument can be constructed from surplus parts for far less. Secondly, it's a single bit flip required. Now knowing the the technique works, a harness could be built that attempts it scattershot without the precise targeting and just has to try a lot of times. Using a different stimulus, e.g. xray it might well be possible without deencapsulating the part.
That's reminiscent of when we first found out that if you opened up dram chips you could use them for imaging. Of course the scale at which this is done is extremely impressive.
I'm trying to date when we were first playing with this, but that was a messy period in my life and it is hard to put it all in chronological order. But I do know I had a driving license so it must have been around 87 or 88. The thing that I remember most clearly is that the images we made had a massive blank area where the chip was split into two halves with a bunch of stuff in the middle.
I’m curious whether this is truly the first, or whether classified aerospace projects had quietly developed digital imaging devices for reco a decade earlier.
The RP2350 is Raspberry Pi’s dual-core microcontroller: each processor socket can select either an Arm Cortex-M33 or a RISC-V Hazard3 core at boot.
Does that mean there are four cores on the die? Is there crazy amounts of MUXing going on? Does the extra, semi-unused area give the chip a premium price tag? Or did I misinterpret this?
Yes, four cores in the chip. And yes, there's additional muxing, but I think that adds a fairly small amount of chip area compared with the crossbar. In addition to the two core slots, there are a lot of peripherals contending for single cycle bus access.
Yup, four cores. No crazy muxing needed because only one kind is ever active at a time and the other kind kept in reset, so there's no need to do any runtime arbitration - basically just a dumb switch on few dozen signals.
The bonus RISC-V cores take up basically zero additional die space: for the RP2350 the lower size bound is the space needed at the periphery for connections to the outside world, and (unlike something like SRAM and analog IP blocks) logic is not too difficult to rearrange or even compress.
This is the kind of thing that tends to start as an engineer joking about having enough spare space to fit in their toy RISC-V core, and then actually doing it. Run out of space during development? Just delete it, it's only an unexpected bonus feature after all. It causes issues during testing? Permanently fuse it off and nobody will notice it was ever there.
High-end chips are filled with dozens of "chicken bits" to gate off functionality they might not be able to get to work properly, so in a small company like Raspberry Pi it probably wouldn't be too hard to convince management to take the tiny additional risk in return for a significant PR possibility.
250k is not a bad investment for a company doing "reverse engineering as a service" - say 1k a pop to extract the firmware. Naturally, a good business idea for somewhere in the world with less regulations...
Most attackers aren't nation states, and your security shouldn't rely on obscurity anyways. Having to attack each individual device and having to get specialized equipment to do a highly-skilled attack breaks the vast majority of attack scenarios.
This isn't Hollywood. What actually matters to companies is that some 15-year-old with a Flipper Zero can't trivially break your printer ink DRM scheme, and that your debit card can't be cloned without leaving plenty of evidence.
Worried about nation-state attacks? Then don't rely solely on sub-$1 hobbyist-level chips for your security!
> Sure, but if you’re defending against a nation state actor hopefully you aren’t expecting a raspberry pi to keep you secure.
Is there anything about these techniques that are raspberry pi specific? It seems like they're using lasers to identify and flip particular bits in registers.
There are HSMs that are effectively immune to this attack by way of their construction and packaging. You need an optical path to the secure device. The only way to get at this is to tamper with the tamperproof part of the system.
Some very high end HSMs must be actively powered at all times which makes disturbances in their local environments detectable at all times as well. Getting lucky and drilling through a part of the enclosure that isn't directly protected won't help you if a barometric pressure sensor is tripped as a consequence of breaking the hermetic seal.
It sounds like a more cleaner method to obtain the keys versus using solvents and a lot of trial and error hardware. As described by Chris Gerlinsky with "How Do I Crack Satellite and Cable Pay TV?" [0] [1]
> Getting lucky and drilling through a part of the enclosure that isn't directly protected won't help you if a barometric pressure sensor is tripped as a consequence of breaking the hermetic seal.
That's interesting. I suppose if that technology is in use, the attack would have to occur in a pressure-controlled chamber, so breaking the seal wouldn't cause a change in pressure.
A more likely measure, which I recall seeing years ago, is to measure the impedance of the enclosure of the thing you want to protect. If someone tampers with it, you would be alerted. It works at many scales, from a protective metal mesh over your IC to a PC case.
You can find the pressure through destructive trial-and-error if money is no object - which it isn't for governments when the target hardware is juicy.
Why would you make each device have the same pressure inside it? That's a bit like hardcoding the same password in each one. Any attacker is only going to have one shot on the actual device they care about no matter how much money they spend.
I expect typical smart cards like the one in your credit card are harder to crack than the raspberry pi was. Those cards are (or were) also used in TV set-top boxes and back in the day, there was a decades-long arms race between the chip makers and cable TV pirates. The TV pirates were also willing to make large expenditures to crack the chips so they could clone them and sell the clones. There's more about this in Ross Anderson's book "Security Engineering".
I've also heard that the Google Titan security enclave chip (used in Pixel phones) is very hard to crack. Apple has something similar for Iphones, I believe.
A Yubikey is basically a single chip and a bunch of plastic. At their $50 price point, there's plenty of room for some chip manufacturer to skim off a couple of dollars per chip to add an additional metal layer for a tamper protection mesh, and some other gizmos.
Your phone isn't going to have a "very high end HSM" any time soon. n
Not until you're paying mid range car prices or more for your very specialised secure phone (and then that phone will probably be factory backdoored AN0M-style).
>Why wouldn't a person build that into the heart of something important?
Because it's inexpensive and not designed to be tamper-resistant. If preventing this type of thing is your goal there are chips out there designed to break irrepairably if tampered with.
Rp2350s are advertised as having quite a few anti-tamper functions. They had a bounty when it launched to find similar vulnerabilities and they worked to patch the ones that were found. This is a lot more credible than a lot of advertised anti-tamper features.
Not really. The RP2350 just adds some bog-standard security features the ESP32 family and plenty of others have had for ages, that's all.
The goal of the bounty is to demonstrate that they aren't just a company making toys for hobbyists, and that they can be relied upon by the industry for basic IoT-level products. They are saying "it won't be completely trivial to extract your proprietary firmware", not "use this chip for your next HSM".
Depending on what sort of important you're talking, those ICs don't have the usual "something important" environmental specs, like an extended temperature range, or certification for automotive use or safety critical applications, for one thing.
It's a $1 MCU, which will get embedded into a $50 device. If you're a company selling a cloud-plus-device product, then that 250k tooling cost and not-exactly-trivial attack process will be quite effective at stopping Chinese clones: with a unique per-device key there's no way they'll sell enough units to make a profit before you will inevitably ban their cloned key.
In 5 years, either $400,000 or $50 and a hammer, depending on whether the core piece of the process aligns with the needs of some fast-growing consumer tech product like e.g. drones.
I was referencing my own realization earlier today, when I was wondering if I can DYI a ground-penetrating radar to scan the allotment garden for hidden "surprises". A ground-penetrating radar is something I learned about as a kid watching a popular science videotape, back then a stupidly expensive high-tech piece of professional equipment.
But it hit me that there are two main forces keeping such technologies stupidly expensive and inaccessible to general public over time: costs of knowledge that went into their design (protected by patents and trade secrets), and specialized parts made in unique way or from unique materials, that don't happen to have alternate applications.
Nowadays, knowledge is not an issue - 20+ years is enough for all the relevant patents to expire, and information to have seeped through to the Internet, available in a combination of Wikipedia articles, textbooks, scientific papers, and blogs, plus we have good LLMs more than happy to synthesize that and transform into a DIY tutorial for dummies.
Which leaves the parts. Whether or not you can DIY such a tech really hinges on whether you can find the critical components somewhere. If they're still unique, you're paying $$$ for procurement (and it makes more sense to try and score broken/used equipment off eBay or something). But there's a chance there's a close equivalent that's part of mass consumer or prosumer device, at which point you just buy it and strip it for parts.
(Which way it is with ground-penetrating radars? Don't know, didn't bother to prompt an LLM with that question yet.)
Radar is cheap now, thanks to semiconductors getting smaller and faster the analog front-end which used to be a long expensive chain of components is now much smaller, the ADC is now faster, more accurate, and cheaper, the processor is now fast enough to keep up with a higher bandwidth signal. You could probably drive a very rough radar system directly off a Pico's GPIO and ADC, maybe toss in a decently fast op-amp for a receive amplifier.
Where you will run into issues is processing radar signals into usable data. If you're happy with the results that radar was giving 30 years ago then it's fine and dandy, but the magic of modern radar is in the software, not the hardware.
Someone I know has developed radar hardware, specifically around signal processing, and while they couldn’t say much, my impression from them was that due the very large amount of data involved using off the shelf CPUs would be very limiting, which is why his job for a period of years was developing a design to be put on an ASIC which is significantly more effective at the task.
The more difficult part will be RF licensing. You'll probably need a ham radio license to get started that's somewhat near a band where you can acquire a commercial typerated license... but under no circumstances you can just go and try shit out unless you want to risk serious fines from your local authorities.
I thought it was a joke about inflation - the US is now trying to print its way out of debt as yields are soaring. This is the very beginning of how hyperinflation usually starts.
It needs to be updated. Modern evil planners don't even need a wrench since they already have most keys given to them in advance by everyone, including nerds
That's cynical, but without doubt true for some people.
I wouldn't want to be someone the NSA is "interested in".
I wouldn't even want to be someone that a customer of NSO Group is interested in. (Just ask Jamal Kashoggi's family or friends)
Hell, where I live they're about to give cops powers to let then hack your phone with a Cellebrite UFED at roadside stops. And it's not even just cops, fisheries enforcement officers Australia have been using UFEDs at least as far back as 2017 during illegal fishing investigations.
If you're doing things that might make someone rich or powerful enough unhappy, or someone in law enforcement - you pretty much need to stop using the internet. And the bar for "how powerful" your potential threat is keeps dropping lower and lower. Just look at all the stories about local cops abusing Flock cameras to stalk ex girlfriend or people critical of them, how could anyone possibly believe those same sort of cops aren't going to use roadside phone forced data extraction tools in exactly the same petty and personal ways, and with exactly the same lack of oversight and consequences?
Weird hill to die on. My understanding is they refused to 100% ban it just because it's AI, but quality standards still apply so there won't be much.
We need to differentiate "no AI because it's slop" and "no AI because fuck Sam Altman". The latter is never going to be practical because you won't reject a good change just because fuck Sam Altman. And the former is irrelevant because you wouldn't accept human slop either. A policy of "AI is probably slop, please don't carelessly submit any and we will ban you for submitting slop" makes sense and is what Graphene has. A policy of "fuck Sam Altman, we ban you if we think you're giving him money" does not make sense if you prioritize working software above ideology.
I appreciate all the details they provide in the post. The $250k in lab gear is useful when initially discovering, exploiting and documenting attacks like this.
Definitely doable in a home lab for under $25k in equipment, likely under $10k.
Same as my replicating Colin O’Flynn’s BAM BAM attack on a MPC5566 chip, he used a ChipShouter ($5,000) and I used a PicoEMP ($50).
https://youtu.be/URmI1VVilek
Nice, thanks. I had wondered whether the $250K in lab gear is something that a serious HW security lab would already have on hand, as opposed to specialized expenditure for just this attack. I mean I rode in a $250K(?) motor vehicle a few days ago (the #2 SF Muni bus towards the Marina) but I didn't have to spend a lot to ride it, since it was already deployed. Nobody had to go out and buy it.
Hah, our new ones are $1.3 million. https://www.sfmta.com/media/44081
Perhaps driven by restrictions on federal grants? https://media.api.sf.gov/documents/Briefing_Book_-_Muni_Fund...
Some cool tech. Wonder if we optioned the inductive charging system. https://www.gillig.com/buses/battery-electric/#1731934845437...
Wow. Equivalent ones built in England are around 1/3rd the price £350k = $470k.
https://www.bbc.com/news/articles/cjq45vw3n4go
Yeah but I bet the steering wheel is on the wrong side. ;)
I have an application on an SPC58 that I really want to know more about. But unfortunately; it’s a dual core with lockstep. So if it could be done; I think that automatically double-pluses the budget.
Don’t need lasers for that chip, it absolutely can be done with enough time and effort.
Don’t let fancy language like lock-step dissuade you from trying. The people who configured that chip also have to have done their job perfectly or it might still have a way in!
It’s two power supplies, two cores, lockstep, and an HSM they hype up… I’m pretty sure I would need two emps and a high precision rig at the minimum.
The RP2350's secure enclave made it particularly attractive for use as a Yubikey alternative.
There will always be an arms race between safe-crackers and safe-builders. Presumably the lessons learned will help make the next generation tougher to break into.
In this case the safe belongs to the person who's trying to crack it.
Well yeah, but I would like to be able to make my own safe that is at least very difficult to crack if someone steals it. Companies are seemingly hellbent on stopping me owning the stuff they want to sell to me regardless, I might as well benefit from the same tech.
There will always be an arms race between safe-crackers and safe-builders.
This is dismissive and glib. And it's the wrong lesson.
You wouldn't say this about symmetric cryptography. AES-encrypted ciphertexts from 25 years ago are still secure today, and nothing on the horizon is likely to change that. No arms race.
The "arms race" exists because the security model for trusted hardware is intrinsically flawed. If the attacker has physical posession of the device, your security is transient and at the mercy of the arms race. So stop doing this! Trusted hardware also has extremely negative externalities on the whole computing ecosystem.
(*) or 45 years, if you exclude cryptosystems (56bit single-DES) used only because of silly export laws.
I tend to agree that there are issues in the realm of hardware token based security but they largely lie in the failure modes, with substantially increased difficulty of recovery.
For the average user these approaches make data loss MUCH more likely simply because you need a corporate IT department level of competency to consistently avoid data loss with them.
The glib exaggeration of this is that in not being permitted to manage and back up your own keys you actually create the situation where you have to hire someone to extract your keys for you and break into the device you own because of the failings of the technology!
> This is dismissive and glib.
As is your comment.
> And it's the wrong lesson.
It's only the wrong lesson if you believe that making it more difficult for governments to seize and decrypt their own citizens' mobile phones with impunity is not a valid goal.
> the security model for trusted hardware is intrinsically flawed.
It's only intrinsically flawed if you expect absolute perfection.
The fact that some math-based protections may be theoretically better than physical protections does not obviate the utility of physical protections, whether we are discussing computers or phones, or houses or cars.
It has been accepted since before any of us were born that there is no such thing as perfect physical security. Even your putative perfect cryptographic security still relies on the physical security of the plant holding the keys.
If you think trusted computing is a defense against nation-state attackers, we inhabit totally different realities.
> If you think trusted computing is a defense against nation-state attackers, we inhabit totally different realities.
I have no idea how or why you would think I think this, since what I wrote was exactly the opposite of this, e.g. "It's only intrinsically flawed if you expect absolute perfection" and "It has been accepted since before any of us were born that there is no such thing as perfect physical security."
In any case, if you think that every piece of information that ordinary humans want to protect is worth it for nation-states to waste their million-dollar attacks on, we inhabit totally different realities.
And yet, there are many pieces of information that ordinary humans want to protect that many nation states would easily throw thousands of dollars at.
In other words, the fundamentals behind security are the same as it ever was.
>> There will always be an arms race between safe-crackers and safe-builders.
> You wouldn't say this about symmetric cryptography. AES-encrypted ciphertexts from 25 years ago are still secure today, and nothing on the horizon is likely to change that. No arms race.
AES encrypted ciphertexts are not a safe. A safe is a physical object.
> If the attacker has physical posession of the device, your security is transient and at the mercy of the arms race.
That's what we're discussing, yes: a scenario in which physical access to a safe is already acquired. Given that context, don't you think changing the topic to 'non-safes' and 'avoiding physical access' is a little dismissive and glib?
[dead]
Impressive work!
I have a side question. I looked into the linked Raspberry Pi hacking challenge, and there's something very basic I couldn't figure out: It looks like the relevant script in the repo just writes 0xc0ff 0xffee a few times to the OTP as the "secret" to unlock. But given that $20000 was up for grabs, this can't possibly be the genuine secret being sought to claim the prize. (Indeed, I can't think of a secure way to install a secret from a public GitHub repo unless it involves running on-device code that encrypts something using some other, factory-installed secret key, which is just kicking the can down the road.) And given that the OTP on a brand new RP23550 is initialised to all zeros, it can't be that the genuine secret is programmed in at the factory either.
What am I missing? How does the genuine secret get installed on a person's RP2350?
> If you think you have found a break email us at doh@raspberrypi.com with details - we will ship you a Pico2 with a custom secret hidden in it. If you manage to extract it, you win the $20,000!
Thank you, don't know how I missed that!
I'm confused by a number of comments here and the article seemingly taking a position that a $250k lab instrument is required.
For one a similar instrument can be constructed from surplus parts for far less. Secondly, it's a single bit flip required. Now knowing the the technique works, a harness could be built that attempts it scattershot without the precise targeting and just has to try a lot of times. Using a different stimulus, e.g. xray it might well be possible without deencapsulating the part.
That's reminiscent of when we first found out that if you opened up dram chips you could use them for imaging. Of course the scale at which this is done is extremely impressive.
For the curious: https://hackaday.com/2014/04/05/taking-pictures-with-a-dram-...
A lot earlier than that.
https://www.cs.uaf.edu/2007/fall/cs441/support/dram_sensor_1...
Even earlier than that. The cromemco camera and similar hobbyist projects dated from the mid-70s.
I'm trying to date when we were first playing with this, but that was a messy period in my life and it is hard to put it all in chronological order. But I do know I had a driving license so it must have been around 87 or 88. The thing that I remember most clearly is that the images we made had a massive blank area where the chip was split into two halves with a bunch of stuff in the middle.
Micron made one in the early eighties also and Steve Ciarcia promptly produced a DIY version for Byte.
I'm pretty sure Steve's article is where we got the idea. We used a 4164 and an old camera lens.
I’m curious whether this is truly the first, or whether classified aerospace projects had quietly developed digital imaging devices for reco a decade earlier.
I would guess that it's maybe not, because I've never heard of any IC DRAM before the commercially available Intel DRAM.
Other types of imaging devices, sure. But the trick of decapping a DRAM requires a DRAM chip.
The RP2350 is Raspberry Pi’s dual-core microcontroller: each processor socket can select either an Arm Cortex-M33 or a RISC-V Hazard3 core at boot.
Does that mean there are four cores on the die? Is there crazy amounts of MUXing going on? Does the extra, semi-unused area give the chip a premium price tag? Or did I misinterpret this?
Yes, four cores in the chip. And yes, there's additional muxing, but I think that adds a fairly small amount of chip area compared with the crossbar. In addition to the two core slots, there are a lot of peripherals contending for single cycle bus access.
> a premium price tag?
$0.80 in bulk. Around $1.25 for individual quantities, depending on who your reseller is.
AIUI, the CPU cores are a small fraction of the die area compared to all the peripherals on the chip.
Yup, four cores. No crazy muxing needed because only one kind is ever active at a time and the other kind kept in reset, so there's no need to do any runtime arbitration - basically just a dumb switch on few dozen signals.
The bonus RISC-V cores take up basically zero additional die space: for the RP2350 the lower size bound is the space needed at the periphery for connections to the outside world, and (unlike something like SRAM and analog IP blocks) logic is not too difficult to rearrange or even compress.
This is the kind of thing that tends to start as an engineer joking about having enough spare space to fit in their toy RISC-V core, and then actually doing it. Run out of space during development? Just delete it, it's only an unexpected bonus feature after all. It causes issues during testing? Permanently fuse it off and nobody will notice it was ever there.
High-end chips are filled with dozens of "chicken bits" to gate off functionality they might not be able to get to work properly, so in a small company like Raspberry Pi it probably wouldn't be too hard to convince management to take the tiny additional risk in return for a significant PR possibility.
> The attack requires physical access, destructive preparation, and approximately $250,000 of laboratory equipment.
Not super practical, but neat attack
250k is not a bad investment for a company doing "reverse engineering as a service" - say 1k a pop to extract the firmware. Naturally, a good business idea for somewhere in the world with less regulations...
That is peanuts for a nation-state actor.
Most attackers aren't nation states, and your security shouldn't rely on obscurity anyways. Having to attack each individual device and having to get specialized equipment to do a highly-skilled attack breaks the vast majority of attack scenarios.
This isn't Hollywood. What actually matters to companies is that some 15-year-old with a Flipper Zero can't trivially break your printer ink DRM scheme, and that your debit card can't be cloned without leaving plenty of evidence.
Worried about nation-state attacks? Then don't rely solely on sub-$1 hobbyist-level chips for your security!
Sure, but if you’re defending against a nation state actor hopefully you aren’t expecting a raspberry pi to keep you secure.
> Sure, but if you’re defending against a nation state actor hopefully you aren’t expecting a raspberry pi to keep you secure.
Is there anything about these techniques that are raspberry pi specific? It seems like they're using lasers to identify and flip particular bits in registers.
There are HSMs that are effectively immune to this attack by way of their construction and packaging. You need an optical path to the secure device. The only way to get at this is to tamper with the tamperproof part of the system.
Some very high end HSMs must be actively powered at all times which makes disturbances in their local environments detectable at all times as well. Getting lucky and drilling through a part of the enclosure that isn't directly protected won't help you if a barometric pressure sensor is tripped as a consequence of breaking the hermetic seal.
It sounds like a more cleaner method to obtain the keys versus using solvents and a lot of trial and error hardware. As described by Chris Gerlinsky with "How Do I Crack Satellite and Cable Pay TV?" [0] [1]
[0] https://simkl.com/tv/33956/chaos-communication-congress/seas...
[1] https://media.ccc.de/v/33c3-8127-how_do_i_crack_satellite_an...
> Getting lucky and drilling through a part of the enclosure that isn't directly protected won't help you if a barometric pressure sensor is tripped as a consequence of breaking the hermetic seal.
That's interesting. I suppose if that technology is in use, the attack would have to occur in a pressure-controlled chamber, so breaking the seal wouldn't cause a change in pressure.
A more likely measure, which I recall seeing years ago, is to measure the impedance of the enclosure of the thing you want to protect. If someone tampers with it, you would be alerted. It works at many scales, from a protective metal mesh over your IC to a PC case.
And you'd need to have a way to know what the pressure inside is beforehand.
You can find the pressure through destructive trial-and-error if money is no object - which it isn't for governments when the target hardware is juicy.
Why would you make each device have the same pressure inside it? That's a bit like hardcoding the same password in each one. Any attacker is only going to have one shot on the actual device they care about no matter how much money they spend.
Really sounds very very easy for any lab that can measure molecular levels of gas.
Even a very sensitive pressure checker in a temp controlled sealed box would do it.
Are any of these tamper-proof chips in my phone or laptop?
I expect typical smart cards like the one in your credit card are harder to crack than the raspberry pi was. Those cards are (or were) also used in TV set-top boxes and back in the day, there was a decades-long arms race between the chip makers and cable TV pirates. The TV pirates were also willing to make large expenditures to crack the chips so they could clone them and sell the clones. There's more about this in Ross Anderson's book "Security Engineering".
I’m actually curious now. Thanks, you’ve given me something to do this evening.
I've also heard that the Google Titan security enclave chip (used in Pixel phones) is very hard to crack. Apple has something similar for Iphones, I believe.
Same. I wonder if my Yubikeys have anything to mitigate this sort of attack. My gut feel says that at their pricepoint and form factor, probably not.
A Yubikey is basically a single chip and a bunch of plastic. At their $50 price point, there's plenty of room for some chip manufacturer to skim off a couple of dollars per chip to add an additional metal layer for a tamper protection mesh, and some other gizmos.
> You need an optical path to the secure device.
Any path can be made into an optical path with a bright enough light. >smile<
Your phone isn't going to have a "very high end HSM" any time soon. n Not until you're paying mid range car prices or more for your very specialised secure phone (and then that phone will probably be factory backdoored AN0M-style).
The RP2350 is an inexpensive microcontroller IC with reasonable performance and some very useful (and somewhat unusual) features in its PIO blocks.
Why wouldn't a person build that into the heart of something important?
"Important" and "tamper proof against a determined adversary" are very different goals.
Tamper proof against a determined adversary starts at 'call us' not at '$10'.
>Why wouldn't a person build that into the heart of something important?
Because it's inexpensive and not designed to be tamper-resistant. If preventing this type of thing is your goal there are chips out there designed to break irrepairably if tampered with.
Rp2350s are advertised as having quite a few anti-tamper functions. They had a bounty when it launched to find similar vulnerabilities and they worked to patch the ones that were found. This is a lot more credible than a lot of advertised anti-tamper features.
Not really. The RP2350 just adds some bog-standard security features the ESP32 family and plenty of others have had for ages, that's all.
The goal of the bounty is to demonstrate that they aren't just a company making toys for hobbyists, and that they can be relied upon by the industry for basic IoT-level products. They are saying "it won't be completely trivial to extract your proprietary firmware", not "use this chip for your next HSM".
Depending on what sort of important you're talking, those ICs don't have the usual "something important" environmental specs, like an extended temperature range, or certification for automotive use or safety critical applications, for one thing.
Some people have such and other toys just at work and can use it in spare time.
It reads as impressive defense. Meaning that it's presumably not possible to get root with physical access on a live 50$ device without 250k capital
This is for a $1 microcontroller. I'm assuming you're talking about the Raspberry Pi computers based on the $50 cost and root.
It's a $1 MCU, which will get embedded into a $50 device. If you're a company selling a cloud-plus-device product, then that 250k tooling cost and not-exactly-trivial attack process will be quite effective at stopping Chinese clones: with a unique per-device key there's no way they'll sell enough units to make a profit before you will inevitably ban their cloned key.
Well not chinese clones, those are well funded factories with state su subsidies, but it will definitely stop rogue individual hackers.
It's not even 250k cost, just 250k capital, it can be rented.
> $250,000 of laboratory equipment
*currently
$300,000 next year.
In 5 years, either $400,000 or $50 and a hammer, depending on whether the core piece of the process aligns with the needs of some fast-growing consumer tech product like e.g. drones.
I think GP was making a joke about RAM prices. Makes me wonder what is the effect of the RAMpocalypse on drone prices.
Maybe.
I was referencing my own realization earlier today, when I was wondering if I can DYI a ground-penetrating radar to scan the allotment garden for hidden "surprises". A ground-penetrating radar is something I learned about as a kid watching a popular science videotape, back then a stupidly expensive high-tech piece of professional equipment.
But it hit me that there are two main forces keeping such technologies stupidly expensive and inaccessible to general public over time: costs of knowledge that went into their design (protected by patents and trade secrets), and specialized parts made in unique way or from unique materials, that don't happen to have alternate applications.
Nowadays, knowledge is not an issue - 20+ years is enough for all the relevant patents to expire, and information to have seeped through to the Internet, available in a combination of Wikipedia articles, textbooks, scientific papers, and blogs, plus we have good LLMs more than happy to synthesize that and transform into a DIY tutorial for dummies.
Which leaves the parts. Whether or not you can DIY such a tech really hinges on whether you can find the critical components somewhere. If they're still unique, you're paying $$$ for procurement (and it makes more sense to try and score broken/used equipment off eBay or something). But there's a chance there's a close equivalent that's part of mass consumer or prosumer device, at which point you just buy it and strip it for parts.
(Which way it is with ground-penetrating radars? Don't know, didn't bother to prompt an LLM with that question yet.)
Radar is cheap now, thanks to semiconductors getting smaller and faster the analog front-end which used to be a long expensive chain of components is now much smaller, the ADC is now faster, more accurate, and cheaper, the processor is now fast enough to keep up with a higher bandwidth signal. You could probably drive a very rough radar system directly off a Pico's GPIO and ADC, maybe toss in a decently fast op-amp for a receive amplifier.
Where you will run into issues is processing radar signals into usable data. If you're happy with the results that radar was giving 30 years ago then it's fine and dandy, but the magic of modern radar is in the software, not the hardware.
Someone I know has developed radar hardware, specifically around signal processing, and while they couldn’t say much, my impression from them was that due the very large amount of data involved using off the shelf CPUs would be very limiting, which is why his job for a period of years was developing a design to be put on an ASIC which is significantly more effective at the task.
Can confirm, radar signal processing is very bandwidth heavy and not suited to a typical CPU.
Can also confirm that it is generally regarded as impolite to talk too much about it!
"impolite" is probably an understatement in the context of discussing details about the development of defense systems outside of work.
The more difficult part will be RF licensing. You'll probably need a ham radio license to get started that's somewhat near a band where you can acquire a commercial typerated license... but under no circumstances you can just go and try shit out unless you want to risk serious fines from your local authorities.
[dead]
I thought it was a joke about inflation - the US is now trying to print its way out of debt as yields are soaring. This is the very beginning of how hyperinflation usually starts.
I was, yep! Parts costs/general inflation.
We're already up to 400,000 just today.
Llms should make these cost even less im thinking $50 in 18 months?
There's always an XKCD... https://xkcd.com/538/
It needs to be updated. Modern evil planners don't even need a wrench since they already have most keys given to them in advance by everyone, including nerds
Care to expand?
Ever put your password into a website that used cloudflare? Ever registered an account with Gmail? Ever had an Android or iOS phone?
That's cynical, but without doubt true for some people.
I wouldn't want to be someone the NSA is "interested in".
I wouldn't even want to be someone that a customer of NSO Group is interested in. (Just ask Jamal Kashoggi's family or friends)
Hell, where I live they're about to give cops powers to let then hack your phone with a Cellebrite UFED at roadside stops. And it's not even just cops, fisheries enforcement officers Australia have been using UFEDs at least as far back as 2017 during illegal fishing investigations.
If you're doing things that might make someone rich or powerful enough unhappy, or someone in law enforcement - you pretty much need to stop using the internet. And the bar for "how powerful" your potential threat is keeps dropping lower and lower. Just look at all the stories about local cops abusing Flock cameras to stalk ex girlfriend or people critical of them, how could anyone possibly believe those same sort of cops aren't going to use roadside phone forced data extraction tools in exactly the same petty and personal ways, and with exactly the same lack of oversight and consequences?
FWIW, GrapheneOS is the only usable phone OS that is legal and Cellebrite can't hack. That's why law enforcement are so horny to ban it.
It's a pity GrapheneOS is allowing AI code contributions...
Weird hill to die on. My understanding is they refused to 100% ban it just because it's AI, but quality standards still apply so there won't be much.
We need to differentiate "no AI because it's slop" and "no AI because fuck Sam Altman". The latter is never going to be practical because you won't reject a good change just because fuck Sam Altman. And the former is irrelevant because you wouldn't accept human slop either. A policy of "AI is probably slop, please don't carelessly submit any and we will ban you for submitting slop" makes sense and is what Graphene has. A policy of "fuck Sam Altman, we ban you if we think you're giving him money" does not make sense if you prioritize working software above ideology.
That doesn't explain your point whatsoever.
Now it can be done for Apple iPhone. Apple is cooked.