<re_irc>
<James Munns> It is stonkin fast. On the nRF52, I tend to use the HWRNG to generate entropy, then use ChaCha, since it's like several orders of magnitude faster.
<Lumpio->
Can you feed more entropy to it as it's available?
<Lumpio->
I don't have an ARM microcontroller with an actual HWRNG in my box...
<Lumpio->
(of parts)
<Lumpio->
Which means I just have like clock jitter and analog noise and it'd be best to add that over time
dreamcat4 has joined #rust-embedded
<re_irc>
<newam> Lumpio-: Sepending on the crypto you use and the security requirements this can be problematic.
<re_irc>
Sampling the noise on ADC pins / using timings can result in enough bias in the seed that someone can get your private key from signed messages.
<re_irc>
IIRC this is a problem for ECDSA (p256). Not as big of a problem for ED25519, and for things like AES-GCM bias doesn't matter at all, as long as each nonce is used exactly once.
<re_irc>
<newam> * Depending
tokomak has quit [Ping timeout: 268 seconds]
<Lumpio->
...how fast though, I can impose a severe rate limit
<Lumpio->
Also the RNG would be used for generating a nonce and will be used for challenge/response
<Lumpio->
Embedded device generates nonce, another device gets nonce, signs nonce, sends it back, embedded device checks signature, does stuff if it's ok
<Lumpio->
...at least that was the most reasonable thing I could think of for authenticating a device
<Lumpio->
I was going to use p256
<re_irc>
<dngrs (spookyvision@github)> why would I get "(HOST) WARN insufficient DWARF info; compile your program with "debug = 2" to enable location info" when "debug" is most definitely set to 2 already?
<re_irc>
<GrantM11235> I also get that warning
<re_irc>
<dngrs (spookyvision@github)> it only happens in some projects 🤔
<re_irc>
maybe some dependency messes thinsg up...?
starblue has quit [Ping timeout: 248 seconds]
<re_irc>
<dirbaio> iirc it's a bug, only happens with LTO
<re_irc>
<dngrs (spookyvision@github)> ah ok
<Lumpio->
Meh maybe I'll just avoid having to have an RNG to begin with and just store the nonce in flash
<Lumpio->
I'm not a crypto person so I'm just taking whatever Android has ("secp256r1" and "SHA256withECDSA") on the device side, and ring::signature::ECDSA_P256_SHA256_ASN1 on the Rust side
<Lumpio->
I have no idea what I'm doing of course
<Lumpio->
So I figured I can make a pretty good nonce by storing a power cycle count in flash, incrementing it on boot, and using that concatenated with a runtime counter as a nonce
<Lumpio->
Counters can be 64 bit for all I care, they'll never run out.
<Lumpio->
And sending the nonce to the device, signing it, sending the signature back, and verifying it
<re_irc>
<newam> yeah the flash will die before a 64-bit counter wraps
<Lumpio->
There only needs to be one active nonce at atime.
<Lumpio->
yah
<Lumpio->
Point being flash is only written once every boot, I'm expecting to boot maybe twice a year
<Lumpio->
Could even use wear levelling and write the counter all over the page until it's full
<re_irc>
<dirbaio> if you do this with a predictable nonce (like a counter) a MITM can steal a valid message and replay it much later
<re_irc>
<dirbaio> like
<Lumpio->
Doesn't matter, that nonce is already used
<Lumpio->
There's only one "active" nonce at a time
<re_irc>
<dirbaio> user does thing, MITM captures first valid message and simulates error.
<re_irc>
user tries thing again, MITM captures second valid message, replays the first so the user thinks it went OK
<re_irc>
now the MITM has a valid message stored that they can replay hours later
<Lumpio->
The entire point of a nonce is to prevent replay attacks
<Lumpio->
Sneaky
<re_irc>
<dirbaio> depends on what "thing" is, this can be an issue
<re_irc>
<dirbaio> like, if "thing" is unlocking a smart lock
<Lumpio->
It's all over HTTPS which I hope will somewhat mitigate that
<Lumpio->
That's exactly what it is heh
<re_irc>
<dirbaio> hehehe
<Lumpio->
The security by obscurity will be the best protection.
<Lumpio->
Not using an existing cloud service
<re_irc>
<newam> Lumpio-: There's replay then there's delayed replay.
<re_irc>
You can stop the TX of the message for 15 minutes, then play it back 15 minutes later. The nonce has still only been used once from the clients perspective, the message just came 15 minutes late.
<re_irc>
<dirbaio> maybe you can sign "(boot counter, time since boot)" instead, and have the device enforce messages can be at most a few seconds stale
<Lumpio->
If I get an error I'll try again though and that will increment the nonce
<Lumpio->
Invalidating the previously stored message
<re_irc>
<newam> I usually stick a u64 of milliseconds since unix epoch in the message to check freshness.
<Lumpio->
But yes if the user doesn't try again that can happen.
<re_irc>
<newam> but that's only if you have the luxgury of an RTC
<Lumpio->
I don't have a real time clock but using time since boot would work
<Lumpio->
At least you couldn't use a really old message.
<Lumpio->
And if the timeout is like 10 seconds... the user would probably notice.
<Lumpio->
If somebody replayed anything within that time window
<re_irc>
<dirbaio> Lumpio-: the attack is the MITM gets the client to sign two messages, with nonce=100 and nonce=101, then replay the message with nonce=100 and keep the one with nonce=101 for later
<re_irc>
<newam> Lumpio-: No user sees 10 seconds lag and thinks "huh, someone is trying to delayed replay attack me" though :D
<Lumpio->
oo
<Lumpio->
So set timeout for nonces
<Lumpio->
Everything starts by the client requesting a nonce, at which time the lock stores a timestamp along with the generated nonce
<Lumpio->
And it's only valid for x seconds
<re_irc>
<newam> yeah timeout all the things.
<re_irc>
<dirbaio> you can make the nonce itself be the time
<Lumpio->
newam: What I meant by that was, if somebody did a delayed replay attack within 10 seconds, I'd notice my door/bike/whatever unlocking randomly
<re_irc>
<newam> ah
<Lumpio->
And if there's a timeout you can't do it any later
<Lumpio->
I guess using the time itself makes more sense yes
<Lumpio->
Now that I've said all this on IRC I've made my security by obscurity pointless, damn it
<re_irc>
<dirbaio> "nonce = (boot_counter, time_since_boot)", to avoid reuse if the device reboots :)
<Lumpio->
...it's all right I still trust it to be more secure and reliable by some random cloud service, and I'm not going to sell it
<re_irc>
<dirbaio> do you need this if all goes over HTTPS though?
<re_irc>
<dirbaio> you don't want to trust the server?
<re_irc>
10s only really makes sense if you've got a 1kbps transmitter that takes a few seconds to send your data :P
<re_irc>
<newam> if you have fast data rates I would make the timeout shorted than 10s.
<re_irc>
<newam> * shorter
<Lumpio->
Yeah, it was just an example
<re_irc>
<newam> dirbaio: they mentioned android, I assume this is something wireless or otherwise open-to-the-world
<Lumpio->
dirbaio: I thought it'd be really cool if I didn't have to trust anything between whatever secure element a phone might have, and the microcontroller that controls the lock actuator
<Lumpio->
Just for fun
<re_irc>
<dirbaio> secure element, oh boi
<re_irc>
<dirbaio> I see, nice! :)
<Lumpio->
...my phone is so old it probably even doesn't have a secure element but it's the thought that counts!
<Lumpio->
Or whatever you call a hardware keystore
<Lumpio->
They're probably full of holes too!
<Lumpio->
But all this can easily be beaten with a crowbar, angle grinder or large screwdriver so it's all just for fun
<Lumpio->
And maybe to learn something. I'm not going to be making crypto systems for production any time soon lol
<re_irc>
<newam> That's the spirit :D
* re_irc
newam goes back to making a homebrew TLS client
<Lumpio->
very nice
starblue has joined #rust-embedded
<re_irc>
<lulf> newam: Let me know if drogue-TLS lacks something you need or if we can collaborate on something :)
<re_irc>
<newam> lulf: At the moment I'm just implementing to understand TLS, I have been reading a lot of drouge-TLS :D
<re_irc>
<lulf> (And thanks for the PR )
<re_irc>
<lulf> It’s… fun in a way :p
<re_irc>
<lulf> I would like to find time for cert validation without webpki and DTLS eventually, so let me know if you’re doing some of that
<re_irc>
<newam> huh, I did not know DTLS was a thing!
<re_irc>
<newam> moving away from webpki is on my wishlist too, but I don't know if I will get around to actually doing it.
<re_irc>
<newam> I'm not sure if this will even work in the end, I'm trying to add TLS to the W5500, which has very limited memory.
<re_irc>
so far it seems ok as long as the certificate chains are less than 4k long _shakes fist at RSA_
<re_irc>
<dirbaio> you can buffer more than 4k at the mcu side (?)
<re_irc>
<newam> Yeah. The original idea was to work out of the socket buffers since the W5500 is usually used for micros without lots of memory; but crypto is so painfully slow when paging memory over a 20MHz SPI bus that realistically I'll have to put this all in MCU RAM
<re_irc>
<dirbaio> oof :D
<cr1901>
>but crypto is so painfully slow when paging memory over a 20MHz SPI bus
<cr1901>
That's disappointing to hear :/
<re_irc>
<newam> A lot of the little micros often paired with a W5500 would be even slower than that too :D
<re_irc>
I think the Atmega328p with the Arduino Ethernet shield runs at 2MHz tops on the SPI bus.
<cr1901>
TLS has ruined a lot of cool things that used to be possible, like posting a tweet from a micro w/ 4kB of RAM :D
<re_irc>
<newam> These days the average certificate chain is 3.8k alone 🤣
<re_irc>
<lulf> If you control both sides you can use EC certs though which are a lot smaller
<re_irc>
<lulf> +(elliptic curve)
<cr1901>
Yea and the solution to that before TLS 1.3 was to repeatedly start and terminate the connection to stream in only the parts of the certificate chain you needed
<cr1901>
But nope, with TLS 1.3 that doesn't work anymore for reasons I forget.
<re_irc>
<newam> That sounds both amazing and scary.
<re_irc>
<newam> TLS 1.3 removed a lot of session resume and retry features, probably related to that.
<Lumpio->
TIL "ring" doesn't work directly on thumb targets
<Lumpio->
"The elliptic curve arithmetic contained in this crate has never been independently audited! USE AT YOUR OWN RISK!"