2

I'm trying out home automation using a Raspberry Pi Pico with Wifi. To connect to wifi I have to send SSID and password. Since the controller has no external interface other than the Wifi, how would most efficiently I protect the password? Including physical access.


I have thought of deleting traces of the password after use, but then I need to to re-flash should it disconnect.

5
  • 2
    My first thought is to make it so that it doesn't matter so much that the wifi password is compromised or use client certificates that you can revoke.
    – schroeder
    Dec 21, 2022 at 9:30
  • What makes the Raspberry Pi Pico different enough from any other device that measures used for other devices would not work?
    – schroeder
    Dec 21, 2022 at 9:30
  • @schroeder I'm rusty at IT sec, sorry. With Pico (IoT in general?) there are limited OS facilities, libraries (lwIP) and peripherals compared to what I'd expect from e.g. windows desktop. Figured there may be other conventions for handling it. Maybe not. "Client certs" is something I'll look into, thx. Come to think of it the debug ports probably aren't open unless I say so so that might be one less vector, or at least more cumbersome to exploit.
    – Andreas
    Dec 21, 2022 at 9:54
  • So this appears to require in-depth understanding of Raspberry Pi Pico to be able to know what options are even available? Should this be migrated to a Raspberry Pi site?
    – schroeder
    Dec 21, 2022 at 11:08
  • @schroeder Oh yeah, didn't even consider there'd be a rasp specific site. Migrating seems like a good idea.
    – Andreas
    Dec 21, 2022 at 11:19

1 Answer 1

1

Answering my own question here based on an idea I had just now.

RP Pico W has Bluetooth which allows for requesting the WiFi password wirelessly from a device in a more secure location. Examples of secure locations being a nearby server in a locked room, or a phone in your pocket.

"How is this any better" you may ask.

To acquire the password an attacker need not only have physical access to the Pico board itself to get the BT pin, but also be within BT range to request the pin, and the server sending the pin must accept the request. If server requests are acknowledged by user after verifying device integrity, i.e. no signs of any attacker, an attacker would need to put much more effort into getting the password compared to just reading device memory.

Normally requests should only ever be sent after a power outage or other cause for board reset. Operating effort should be minimal.

Additionally, having device unique BT pins means only compromised devices needs to be flashed with a new BT pin.

Overall I think above strategy should make an attack much less attractive to perform due to the additional effort, and much more risky as it must be performed on-site with the owner nearby, while not adding to much to operational effort or programming complexity.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.