The Vault App - betrusted-io/betrusted-wiki GitHub Wiki
The Vault app can manage U2F/FIDO2, TOTP, and conventional passwords, all from a single UX, and in a plausibly deniable manner.
Use the F1-F3 hot keys below the screen to switch between Vault modes.
Connect Precursor to host PC via USB
FIDO2
F1 brings you to the FIDO2 mode.
Plug your Precursor into a host PC, and use it as a U2F or FIDO2 authentication token.
Unlike a typical security key, you can see a description of what you’re authenticating:
If you've registered your Precursor as a security key with a website but aren't seeing it in the FIDO view, it may have gotten added as a type that isn't currently presented in this view.
To view these you can switch to shellchat and then run pddb keylist opensk. The names aren't incredibly useful, but as you add new sites they will
Residential Keys
Private SSH keys can be stored on Precursor, allowing you to login using a less-trusted computer, without having to install a copy of your private keys on that machine.
Linux
-
openSSH version 8.3 or later is required. The openssh-sk-helper is also required and may be packaged separately on some platforms (ie Alpine/postmarketOS).
-
identify the FIDO device with
sudo dmesg | grep "Kosagi Precursor" -
confirm the FIDO device with
fido2-token -L -
set a PIN on the FIDO device with
fido2-token -S /dev/hidrawX -
generate a resident key with
ssh-keygen -t ed25519-sk -O resident -O application=ssh:optionalApplication -f keyFilename- The optional application allows you to generate multiple SSH keys for different identities (GitHub/et al only allow an SSH key to be used with a single account) and be able to tell them apart
- Keep in mind it is likely these are all linked to the same resident key unless you unmount a basis and create a new one before generating the next key, this means deleting one essentially invalidates all of them that shared the same key.
-
copy public key to server with
ssh-copy-id -i keyFilename.pub user@host
TOTP
F2 brings you to the TOTP mode.
F4 Autotype to send selected OTP to host via USB.
Password Manager
F3 brings you to the classic password manager.
F4 Autotype to send selected password to host via USB.
The password manager can help you create a strong password with the help of Precursor’s built-in TRNG. It has basic configuration options for things like the length of the password, and if the password should include symbols, numbers, and/or upper case characters.
Each password record has a descriptive name (“demo password”), the username (“bunnie”), the password itself, and a note field to keep track of any special characteristics for the password (“this line is for notes”).
Manage Vault entries
In any mode, F4 opens the Vault management menu. This screenshot currently doesn't show the Enable host readout which was added in v0.9.10 and has been substantially improved through v0.9.13. You should DEFINITELY check out this tool if you have a lot of secrets you want to import from another password manager (or your brain) in a faster manner than retyping them, especially if they have special characters which are harder to enter on the Precursor keyboard. It is named vaultbackup-rs but it can be used for both imports and exports, and it only reads the TOTP and passwords in the vault app that are in unlocked bases, so you can avoid accidentally exporting super secret values by unmounting those bases. vaultbackup-rs
Autotype
With your Precursor connected to your host via USB, it will appear as a keyboard when the Vault app is active. Precursor can then send virtual key-strokes to automatically fill in a password or OTP with the push of a button. This way, you never actually have to see or type any passwords yourself; so long as you have your Precursor plugged into the host machine, your passwords are just a couple button presses away.
Plausably Deniable
You can also see from this menu that “secret bases” (bases being the plural of basis) are explicitly supported by the Vault app, thanks to the Plausibly Deniable DataBase (PDDB) built into Xous. The structure of the PDDB is a subject for a whole other post, but in a nutshell secret bases are database overlays that can hide credentials in a plausibly deniable fashion. By keeping sensitive credentials in a secret basis, you can safely share only the credentials that are currently visible with friends, colleagues, or even law enforcement. The locked credentials are untraceable: even if a full forensic dump is made of the device’s contents without your permission, it is hard to prove the existence or non-existence of secrets beyond the ones you have chosen to reveal to the party in possession of your device. To this end, the "Unlock secret Basis" menu item is always present, even if there are no secret bases on the device.
FAQ
Q: Is the Vault App Certified with the FIDO Alliance?
A: No, the vault app is not certified with the FIDO Alliance. This means that the attestation keys embedded in it will not be considered to be valid. Thus, organizations that have a policy of only allowing certified U2F/FIDO tokens will not interoperate with Precursor. In particular, this will not work with DUO.
The U2F/FIDO2 functionality is implemented with a port of the Google OpenSK reference code. Because Xous diverges quite heavily from their reference Tock base, the code is vendored into Xous. The base commit is f2496a8e6d71a4e838884996a1c9b62121f87df2 off of https://github.com/google/OpenSK.
As of July 2022 the app is release as part of a default Xous v0.9.9 install.
Testing U2F/FIDO2 Functionality
Compliance testing is done on every build using the Google CTAP2 test suite and a "hardware in the loop" configuration. We have forked the test suite for debugging and better automation purposes.
Here is the test setup:
- Hardware DUT is loaded into the factory test jig
- Standard Xous release image is installed on the DUT, with the PDDB provisioned by the "extended tests" run by Jenkins.
- CTAP2 tool is installed and running on the Raspberry Pi. This does require a forked test and a patched Basel to make it run on this platform.
- An expect script runs on the Pi, which kicks off the CTAP2 test automation and also drives responses on the serial console to unlock the device and respond to push button events.
Here is the latest test report. As of xous v0.9.9, we are passing 74/74 compliance tests.