commit 4e0415b62b1bcbe1f4502ee021f2d982219bc738
parent c15f26eef6dd1d50fdf47565eed55641d89a4964
Author: Daniel Barlow <dan@telent.net>
Date: Sun, 15 Feb 2026 17:13:24 +0000
notes
Diffstat:
| M | notes.md | | | 58 | +++++++++++++++++++++++++--------------------------------- |
1 file changed, 25 insertions(+), 33 deletions(-)
diff --git a/notes.md b/notes.md
@@ -172,47 +172,39 @@ O wifi provisioning over ble
---
-We don't think impersonation is a big threat, because it requires
-having physical access and the ignition key in order to power on the
-device
+BLE latest: remember we need physical access and the ignition key in
+order to power on the device.
-However, there is the problem that the wifi password is transmitted plaintext
-so an attacker could use this to get access to the wifi.
+But if we don't pair then the wifi password can be passively eavesdropped
-In the current hardware confiudation, BLE pairing won't help, as it is
-susceptible to MITM without a display and an input device. While it
-is conceivable that there is some input to the ECU we could could
-co-opt for saying "yes" or "no" to a displayed PIN, there is nowhere
-to display it.
+And if we can't pair with MITM protection then - even though the
+connection is encrypted - a balaclava-in-the-middle with $50 of
+micro:bits can get the wifi password.
-If we add an NFC transceiver we could use OOB pairing. the nfc chip
-could be stuck to the inside of the rear tail fairing just next to the
-ecu. The need for physical access makes it more secure but also a bit
-less convenient for pairing with a bluetooth in the shed when the bike
-is parked (e.g. to do ota updates)
+So, bottom line: we need authentication and encryption, and in accordance with
+"don't roll your own crypto" advice we will do this with https://nacl.cr.yp.to/box.html
+ / https://github.com/RustCrypto/nacl-compat/tree/master/crypto_box
-how about using the ed25519 key we have for ota/sessionm auth?
+Given which, we probably don't need to pair in the first place.
-1) the device generates a random 32 byte token, then encrypts it using the
-client's private ed25519 key and publishes the ciphertext using GATT
+....
-2) the client decrypts it and uses it as a key for aes-ccm encrypting the
-wifi password
+could/should we use the same infrastructure for the client signing
+session keys? there is no crypto_sign implementation in nacl-compat,
+and no shared highlevel code in the signature generation, which makes
+me think "no".
-3) the device decrypts that and, if successful, stores the secret
+.....
+(1) use pynacl at build time to make keypairs for device and client
+keys/client.{key,pub}
+keys/eculocate.{key,pub}
-https://docs.espressif.com/projects/rust/esp-hal/1.0.0-beta.0/esp32c3/esp_hal/aes/struct.Aes256.html
+let alice_public_key = PublicKey::from(alice_public_key_bytes);
+let bob_secret_key = SecretKey::from([...])
-this does not seem to expose any aes mode that has both encryption and
-message authenticity
-
-https://docs.rs/aes-ccm/latest/aes_ccm/
-
-this is software, but that's ok for what's probably quite a rare operation
-
-
-
-
-without a secon
+// Bob can compute the same `SalsaBox` as Alice by performing the
+// key agreement operation.
+let bob_box = SalsaBox::new(&alice_public_key, &bob_secret_key);
+bob_box.decrypt(&nonce, &ciphertext[..])?
