Getting rid off SDcard after first boot

[aginies]

A pain point is the sdcard.

There is way to get this fixed:
just copy the content of the config.yml and services.yml files in the root FS after first boot. So You don't need them any more. You can also encrypt the services.yaml file with the pin code.

How to get this files updated?
You calculate an sha256sum of the files present on the system, if the files on the sdcard are different you can propose to use the new files on the sdcard.

This will increase a bit the security issue of the Sdcard. Of course there is always a way to get the services.yaml file, but if it is encrypted on the FS it will be hard to use it.

[AllanOricil]

I thought about reading the data from the SD card to fully decouple the board and the data. I can store them separately after booting, or boot N separate boards (home/office). I could add an optional settings option to let you store configs and services in the board upon first boot. What do you think?

Take a look
#36

There is an encryption branch that I was working that encrypt services based on a derived key. This key is derived from an input password and a salt. The input password isn't stored in the board, while the salt is stored in the config.yml. With the same salt and password, we can use the same SD card on a different board. What do you think of this strategy?

I believe that encryption + SD card is more secure than using the internal storage because I can store my storage in a different place (compartmentalize), and even if it is stolen it wouldn't be accessible unless someone knows the password. If the board gets stolen, people can dump the file system and get the encrypted secrets and salt, the only thing missing would be your password.

[aginies]

I thought about reading the data from the SD card to fully decouple the board and the data. I can store them separately after booting, or boot N separate boards (home/office). I could add an optional settings option to let you store configs and services in the board upon first boot. What do you think?

One of the interesting aspect of this board is not using the smart-phone. How to handle the the data and the system, separate or not clearly depends on the usage. At home, the risk to get the data stolen is ~= null. If I used the device while travelling, for sure I want a more secure stuff.

The approach of decoupling sounds good. Seems it address the issue of the config.yaml data, and with the password protection even if the board and the sdcard is stolen, no one can access that data without the password.

[AllanOricil]

@aginies

Would you guys use it if the board was used only for:

• Proof of presence
• display TOTP received from the server

?

I'm thinking about storing secrets in a self hosted vault, and then create a service to generate and push TOTPs for a registered device.

There will exist a Chrome Extension which the user will use to:

• install the firmware in the board
• register the board to his account
• register TOTPs secrets safely in a vault while binding it to domains
• request TOTPs

When requesting a TOTP for a service, the board is going to ask for PIN/fingerprint (Proof of Presence). The board won't ever have access to secrets since TOTPs are created and sent to the board from the server. Identity will be controlled by Keycloak server, while requesting PIN/Fingerprint in the board is only used for Proof of Presence. When a TOTP is requested by a client (eg. chrome extension, CLI), the origin is sent and validated by the server to solve the Phising problem. I think this model is pretty secure, and better than storing both passwords and secrets in the same password manager. I believe we could also use the vault to store passkeys in the future.