<firefrommoonligh>
<mattnite[m]> "Hey everyone! James Munns told..." <- Hell yea! Would love to try Zig on microcontrollers. When I last checked it was immature, but rapidly improving
<JamesMunns[m]>
(often, hardware or "true" RNGs can be a little slow, it's not uncommon to use them to seed faster, but still cryptographically secure software pseudo random number generators)
<AdamHott[m]>
Thanks James, I'll try this!
<JamesMunns[m]>
s/see/seed/
IlPalazzo-ojiisa has joined #rust-embedded
mabez[m] has quit [Quit: Idle timeout reached: 172800s]
FreeKill[m] has joined #rust-embedded
<FreeKill[m]>
Hey all - this is not Rust specific but I'm bashing my head against secure area protection on the STM32H755. Does anyone have experience with it whose brain I could pick?
sparky[m] has quit [Quit: Idle timeout reached: 172800s]
<mameluc[m]>
<FreeKill[m]> "Hey all - this is not Rust..." <- for stm32wl I found a disable_security.bat that took inspiration from to unlock my chip, idk if at all applicable to your situation
<FreeKill[m]>
Afraid not :( My current board is fully bricked 😆
Guest7282 has left #rust-embedded [Error from remote client]
<FreeKill[m]>
I'm using the secure mem region which locks you completely out of debug after you enable it, so if you don't nail the recovery code first time... 🧱
<dirbaio[m]>
of
<dirbaio[m]>
* oof
<FreeKill[m]>
Mix that in with a little bit of the ol' ST-tier documentation
<FreeKill[m]>
and it's really fun
<dirbaio[m]>
there's no "remove protections and erase everything no matter what"?
<FreeKill[m]>
There is
<FreeKill[m]>
But not externally
<FreeKill[m]>
it has to be done by the M7
<FreeKill[m]>
So again you have to get that code exactly right the first time you flash it
<FreeKill[m]>
And I suppose I didn't (although I also have no idea where it's wrong)
Guest7282 has joined #rust-embedded
holo[m] has quit [Quit: Idle timeout reached: 172800s]
ryan-summers[m] has quit [Quit: Idle timeout reached: 172800s]
<mameluc[m]>
<FreeKill[m]> "So again you have to get that..." <- no magic boot0 pin to hold down or something?
<firefrommoonligh>
Tangent: What is the intent behind MCU security features? Is it for physical compromise of safety-critical etc equipment (sabotage) or is it if you are connecting MCUs to the Internet or other large network? Something else? Thx
<FreeKill[m]>
<mameluc[m]> "no magic boot0 pin to hold..." <- The secure area takes priority over the bootloader
<FreeKill[m]>
firefrommoonligh: It can be both. If you ship an unsecured MCU, then someone can just read out your code. If that code is proprietary or contains proprietary info, you're boned
<JamesMunns[m]>
The H5s also have tamper resistance too, for things like credit card machines that hold signing keys that you want to evaporate when tampered with
<JamesMunns[m]>
basically anything can be circumvented, but you want to make the effort as high as possible to motivate people to crack a different device instead.
<FreeKill[m]>
The specific use of this security feature is that once you have left the secure region, it is completely invisible to all other code. So even if we accidentally ship an application binary which has a security fault, that application binary still can't exfiltrate keys from the secure region.
<JamesMunns[m]>
if every device has unique keys, and you have to acid etch the device or use a scanning electron microscope per device, that's a pretty good deterrent for a couple of years.
<FreeKill[m]>
Whereas with most secure stuff (MPU, RDP, PCROP for example) you are not safe if the application binary contains an RCE bug for example
<FreeKill[m]>
Unfortunately its lovely security properties also make it extremely irrititating to develop
<JamesMunns[m]>
It's like low power modes
<JamesMunns[m]>
they are supposed to work good
<JamesMunns[m]>
but trying to debug low power modes is maddening
<FreeKill[m]>
yes :P
<JamesMunns[m]>
the worst is messing up code so it goes to deep sleep right after it boots, before the debugger can connect
<FreeKill[m]>
at least you can always connect-under-reset
<FreeKill[m]>
But yeah I have also had to recently wrangle STM32 low power modes, also very annoying. Especially when you're chasing microamps around trying to work out what's leeching power
pflanze__ is now known as pflanze
<mameluc[m]>
<FreeKill[m]> "But yeah I have also had to..." <- I gave up on debugging and just use defmt-serial with some defmt:info statements to see what is happening
<mameluc[m]>
ofc swd debugging works well to see that everything is right before going to low power mode
<mameluc[m]>
to be clear, I parse the hash at compile time to 4 bytes instead of 8 to save on bandwidth for lorawan. git chose 7 as short hash length for my current code base. I went with 8 to get the hex parser happy
<AdamHott[m]>
<JamesMunns[m]> "if every device has unique keys,..." <- what's this eFuse I heard about, it burns the memory? how do you evaporate signing keys?
<JamesMunns[m]>
fuse memory is usually referred to as "write once memory"
<JamesMunns[m]>
the idea is that you write a private key into a chunk of memory that can't be rewritten again, and in many cases, not even actually ever read
<AdamHott[m]>
does that memory have to be on a special component?
<JamesMunns[m]>
instead you use it with a cryptographic peripheral which does things with it, so it's not possible for the firmware to accidentally leak the private key, even if there is a software bug or vuln
<AdamHott[m]>
ah that makes sense, like an RSA key?
<JamesMunns[m]>
yeah, it's usually internal, it USED to be like a specific kind of silicon design, tho IIRC a lot of times nowadays it's just flash memory with hw limits
<JamesMunns[m]>
AdamHott[m]: yeah, like the private key
<AdamHott[m]>
ah cool, thanks so much for the explanation!
<JamesMunns[m]>
these usually have some kind of sensor or even a mesh on the PCB design, to detect if someone is trying to glitch/read/disassemble the credit card machine
dkhayes117[m] has quit [Quit: Idle timeout reached: 172800s]
<AdamHott[m]>
ah okay, that mesh sounds interesting, is there name for that mesh?
<AdamHott[m]>
Can you get that a PCB manufacturers?
<AdamHott[m]>
boards made of that?
<AdamHott[m]>
s/a/at/
<Ralph[m]>
<JamesMunns[m]> "these usually have some kind..." <- i wonder why people go through all that trouble... here they just dynamite the ATMs, there's enough cash in them 😅 (though i still don't know how they manage to get the money without it being coloured - usually there's colour exploding in the ATM safe if it's being opened forcefully to mark the money)
<AdamHott[m]>
haha true
<AdamHott[m]>
color exploding pods in an ATM safe are a fun topic too
<JamesMunns[m]>
It's usually something you do in the outer layer of your pcba
<AdamHott[m]>
Thanks James! I gotta run good night all!
cbjamo[m] has quit [Quit: Idle timeout reached: 172800s]
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
kenny has quit [Quit: WeeChat 4.2.1]
eldruin[m] has quit [Quit: Idle timeout reached: 172800s]
kenny has joined #rust-embedded
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
thalesfragoso[m] has quit [Quit: Idle timeout reached: 172800s]
ChristianHeussy[ has joined #rust-embedded
<ChristianHeussy[>
Does anyone have a preferred no_std rpc framework? I'm familiar with capnp but the rpc side of things looks a bit unloved and currently requires std.
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]