Support hardware tokens to store the encryption secret

[nickcalyx]

I'd like to see a feature where instead of using the 12 words to save the user's encryption key, we could optionally use a 2FA token like a Yubikey ( over usb or NFC ) to store the key so that if a person lost their phone or wanted to move their data from one device to another, they wouldn't need to be bothered with the 12 words.. or safely storing the 12 words.

Maybe for security we could allow the use of the hardware token, but also have the 12 words as a backup in case the token is lost.

Also maybe we need to lock the token with a PIN code or key, so that if the token is lost (or stolen) and then found, that it can't be used to recover the encrypted backups

[grote]

Is this about storing the key on the token additionally or exclusively?

If it is additionally, then the use-case is making restore easier as the key could get imported instead of entering 12 words.

If it is exclusively, then this might provide better security, but the UX would suffer as the token would need to be present for encryption. So backups could not run automatically in the background, but would need to be run manually and the token could not be removed for the duration of the backup. Also, a USB token would it make impossible to use USB for storage and an NFC token could have the issue that it moves during backup and makes the backup fail as the key becomes unavailable.

[jtagcat]

While using exclusively, there's also risk in losing the hw device. Considering that the user would carry their hw token with or next to their phone, the chances of the hw device getting damaged is elevated.

From an usability standpoint, if you aren't a maniac (you need to touch the key (nfc) or touch the key (usb/bt, auth tap)), you'd have to store the key off-device anyway.

[beroal]

A user may want to have only one method of decryption (with a token) for security reasons. I bet that people spending money on security devices understand implications of losing them. :-) So this is not UX degradation.

[beroal]

Also, a USB token would it make impossible to use USB for storage

I think there are workarounds:

• write a backup to a microSD card while attaching a token to a USB connector,
• a USB hub.

[jtagcat]

Ignore what I wrote here, jump to the horizontal div, or if you prefer, the tldr at the bottom.

A user may want to have only one method of decryption (with a token) for security reasons. I bet that people spending money on security devices understand implications of losing them. :-) So this is not UX degradation.

I understand the implications of losing them, as such I primarily have a pair. Although it will probably not burn with your house etc (talking of yubi here, but ex google's bluetooth thingy will melt right away), you can still be separated from it, or lose it, or it could be stolen. Stuff happens. When your house burns down, it's likely you won't find the hw token.

In a sense, this is the same as "I won't back up my full disk encrypted device bc security reasons."

As you can't really to challenge-response in an uLtiMATe sEcwUriTy perspective, I'd very much have backup codes say in keepass, or heck even in a safety deposit, on an encrypted device.

You need to use the token, as such you carry it with you. Keeping it with you at all times is a thing as well. If your device decides to note 7, and your token is in the same pocket, then what? Now you're without the primary data carrier, without usable backups.

Keep in mind, that not keep themselves logged in to 5 devices, and even so, do they login to the device with 2fa? Many people have only mobile devices available to them. Losing the primary data carrier and the backup key, that they, with a backup code, stored on paper, in a box, say buried in the woods (going quite extreme here), could've restored.

I go yet again, it's likely the primary hardware token is destroyed with the data carrier. I'm not even going in to 3rd world (oh they don't have hw tokens? yes they do) economics (whom are also more likely to use say, lineage on older devices, with seedvault).

---

Now I think nobody pointed it out so far. Hardware tokens are very much designed to be the second factor, with a challenge-response (chall can be the current time as well, for totp).

Yes, you can turn your yubikey in to a rubber ducky, but what's the point of that? You can password protect that rubber ducky, but it won't be much different.

There's no sensible way to do hardware tokening.

All right, let's actually try. Say you built your own device (no, crypto wallets won't work for this, they do one slow transaction).
You'd need to build a protocol between seedvault, and the device, you'd have to implement it on both sides, building the device to stay unlocked, and (d)encrypt any data. There needs to be communication between the app and device on a non-fs level as well (could be implemented everything-is-a-file style, app writes/reads from file etc, but what about android os formatting the device).
So you've spent many months of full-time work on this. Now, let me state this: You need to screen the majority of both cloud and local storage through there. Besides latency, there's (also) bandwidth (combine them two). Bluetooth won't cut it. All mobile phones, that I've encountered, with an USB-C port have it as USB 2.0. Ok, maybe the bandwidth is enough for smaller internal memory sizes.
Do you have enough power provided by the device (no) to do crypto, emulate a fs, and more, on your (already complex) embedded device, where it can do cryptographic operations quick enough (again, both latency and bandwidth)?

If somebody sees they have the time, knowledge, and will, to build something like this, I'd back it on kickstarter.

Rather, this issue, as it is, it's asking for "don't store the mnemonic, and ask it for all backups (store during the backup)" instead of hw token support.
But here, yet again there's a problem, doing crypto on the device defeats the point anyway. If you have access to the secret, you have access to the data being backed up. If the secret would be to not be stored on the device at idle time, the attacker would still have access to the device (defeating the point of protecting data), and if they'd wait it out, you'd just give them the key for the next backup one way or another .

---

tldr, until somebody really engineers something described above (at what point I'd argue, they have much more interesting stuff available to work on), bringing a new hw product to the market, at a reasonable price. ..and writing specs, implementations, and seedvault integrations; close as wontfix. Doing anything with current hardware token solutions is just security theatre.

[ros-cr]

Hello everyone, I'm a pentester from Radically Open Security and have done a short security evaluation of this project as part of the NLnet funding grant.

After looking at the question of hardware token support for Seedvault, my conclusion is similar to the second half of @jtagcat's analysis: it will be difficult to implement the desired feature properly given that commercial smartcards, hardware tokens and cryptocurrency hardware wallets are built for a different purpose and mostly do not natively offer the required functionality.

In simplified terms, what Seedvault would need is either

1. external hardware with an API for secure storage and direct retrieval of a 128+ bit symmetric key
2. delegating all encryption/decryption/signing operations to the external device

Option 2) is impractical due to the severely limited computational speed of the microcontroller systems that make up typical portable security devices. Pushing gigabytes of data through them for every backup cycle will be unreasonably slow, and so many devices don't even support an interface for this.

Option 1) is theoretically possible without a lot of computation power, but as @jtagcat has outlined, typical security devices do not offer this, so this needs specialized hardware. Common security hardware is usually based on generating or importing a master key once at initial setup (such as a PGP key or BIP39 secret) and then never revealing it to any outside party, authorized or not. Instead, all cryptographic operations happen locally within the security on externally provided data, so that the key is never revealed.

It may be possible to re-use some computation results from a typical U2F/FIDO2 2FA hardware token as a secret key and build a special scheme for this, but this is more of a hacky workaround and I would not recommend going down that route.

If one is willing to re-design the Seedvault backup file format, I can think of an approach to 1) through generic encryption/decryption functionality and without the storage requirement if OpenGPG smartcard support is available:

• an encrypted copy of the master key is stored within each backup
• during the recovery procedure, the Seedvault application ask the OpenPGP smartcard to decrypt the master key copy via symmetric cryptography with a specific PGP key in order to make the cleartext master key temporarily available to the Seedvault application on the smartphone
• the application can restore the backup through the master key

Note that this requires a special subset of hardware tokens with this specific smartcard protocol support, which excludes many 2FA tokens. There are also practical concerns due to the key management complexity, particularly when redundancy through multiple hardware tokens is desired. For example, the design would need to be extended to store multiple differently encrypted copies of the master key in the backup file header or assist the user to manage an identical OpenPGP key on multiple tokens, which brings a lot of usability challenges.

Given the complexity, risk of design errors and implementation errors, additional testing efforts and so on, I think it is valid to stay with the existing BIP39-only design at this point.

---

There is another area where I can see a potential use of hardware security devices, and that is in generating a cryptographic signature over some properties relating to an individual backup.

For example,

• the Seedvault user manually starts a backup
• at the end of the backup run a sha512sum value over the backup file data is created
• the sha512sum value and perhaps some other meta information is signed by the OpenPGP smartcard
• the meta information + signature is appended to the backup

This would give some guarantees about the integrity and authenticity of the backup that can be checked at some later point, for example before recovery.

However, this design is only viable for manual backup operations of expert users and fulfills a different role than what is asked for in this ticket originally. So this is a nice-to-have feature that will likely be used rarely, and can be approximated by regular software tools without specific Seedvault support for it.