search

betrusted-io / betrusted-wiki

Looking for docs on Precursor/Betrusted? Start here.
https://github.com/betrusted-io/betrusted-wiki/wiki
Apache License 2.0
173 stars 6 forks source link

Is it possible that PINs starting with 0 don't work? #21

Closed bwhitman closed 2 years ago

bwhitman commented 2 years ago

Hi, I'm setting up my Precursor. I've run ./factory-reset.sh three times now, the first time set a pin starting with 4 (4 digits), which worked fine on future unlocks. I ran ./factory-reset again today after a git pull because I was getting a confusing message about the ecup version being old, not letting me get on wifi. So I did that and set the PIN to another four digit code -- 0101. It wouldn't accept it on future unlocks. I thought I had mistyped it, so did ./factory-reset a third time and this time turned on the "show password as I type" and ensured it was 0101, and it will not accept it again on future unlocks. Is there a chance something about this PIN is not working?

bwhitman commented 2 years ago

It's not the 0-led PIN, just any PIN. I can't seem to get it to remember the pin. My process:

(0) Pull the latest xous-core, cd into tools (1) Connect USB C cable (2) In ubuntu20, run sudo ./factory-reset.sh -s (3) When that finishes, hit the reset button (4) Unplug USB (5) On the device, type ecup auto (6) Plug in USB again to reboot the device (7) Menu-> initialize root keys (8) Type a pin of 0101 and then the more secure password (9) Reboot, try 0101, it does not accept it

bunnie commented 2 years ago

Ah right. When you say "it does not accept the PIN" on reboot, this is because it's popping up a box that's offering you to format the PDDB?

In which case, this is actually the "expected behavior" but poorly explained by the UX. Basically once you have provisioned the root keys, the device will try to mount its storage. However, the storage needs to be cryptographically wiped before use, which is a long process - about 10-15 minutes -- so we don't link it to the root key provisioning process. Since an unmountable PDDB is indistinguishable from a mountable one, we can't say for sure if it's because of a bad password or because of an unitiialized PDDB -- that's kind of a feature not a bug in that you can deny the existence your PDDB by just saying you never initialized it.

So I think what you're seeing here is that dialog box which is asking you to to provision the PDDB. It uses the less secure PIN just to tie the basic system storage down, but then you would layer more secure passwords onto deniable Bases that would contain data that truly needs securing. Once you've got the PDDB initialized, that dialog box won't pop up a failure, and instead, it'll just go away.

To wit, the only function of the PDDB at the moment is to store your wifi SSID and password -- we haven't put much user-friendly infrastructure in place to deal with new cryptographic Bases or other properties yet.

The only modulus that makes me a little bit worried is that when you do a factory reset, we do wipe the PDDB headers so it's actually blank and not cryptographically blank. There's supposed to be a catch at that point which detects that and then guides you toward a UX path of initializing the PDDB, I'm not sure why that is not showing up.

bunnie commented 2 years ago

Hm right, I just tried to reproduce it and I don't get a prompt to enter a PIN on reboot. Is it easy for you to take a photo of the prompt that's asking you for a PIN on reboot? It shouldn't ask for that until you've done something to the PDDB.

bunnie commented 2 years ago

Ah. I see one bug. A recent change to the factory reset script skipped the part where the PDDB is also wiped, so that would contribute to your confusion. I've gone and fixed that.

bwhitman commented 2 years ago

Aha! I think I understand it all now. And yep, I just pulled the latest and went through it all again and everything works as expected. Thanks so much !!