I wonder if the same could happen to @Bitkey users wouldn't it only need something similar against bitkey and apple/google where the other keys are stored on their servers? 🤔

Assuming @Bitkey designed as advertised, of the 2-of-3 keys needed, Bitkey servers controls 1 key, the mobile app controls 1 key, and the hardware device itself controls 1 key. There is also an encrypted backup of the mobile app key stored in your cloud account - which requires the hardware device to decrypt it. In short, in addition to the key from Bitkey severs, the FBI would also need either your hardware device, or the key from your mobile app (which I suppose could potentially be lifted through some sort of spyware and/or malicious version of the app). *The key controlled by the hardware device isn't backed up anywhere (it's designed to not even be possiible). If the device is lost (or just stops working for whatever reason), the user's only recourse is to hope to still be able to get a new device and hope to still be able to coordinate with Bitkey to transfer funds (via the mobile app key and the Bitkey servers key) to an entirely new 2-of-3 keyset.

It looks like the hardware is not needed at all 🙈 If you lose your hardware, you can use your phone, together with the key on Bitkey’s server, to set up new hardware (after a Delay and Notify period expires, during which Bitkey pushes alerts to your app to alert you of a recovery attempt).

Bitkey: Self-custody bitcoin wallet

What do you mean, ‘There’s no seed phrase’?

Three routes to recovery are better than one high-value hide-a-key. You know that spare key your neighbor has, hidden under the mat or a fake rock...

Yeah, that's what I was trying to say with "coordinate with Bitkey to transfer funds (via the mobile app key and the Bitkey servers key) to an entirely new 2-of-3 keyset"

Phone is the hardware in theory

Apply says they don’t have the key

There is also a way bigger flaw beyond this, and that is this Device Encryption feature (and by extension BitLocker) has **no PIN or password**. The device will just decrypt itself by powering on as it only uses the PC's TPM. The only threat this kind of protects against is the hard disk being removed from the PC. It doesn't prevent someone exploiting the OS to extract data like you commonly see in mobile device forensic tools... This request for the recovery key is just to allow law enforcement to access the data while the hard disk is removed from the seized PC, because they insert hard disks into write blocked imaging kits to create a forensic clone of it's data to analyse with. Back before TPMs were widely embedded into CPU firmware it wasn't common to see them get sniffed to get the keys. Anyone could do it too:

Pulse Security

Extracting BitLocker keys from a TPM

Extracting BitLocker keys sealed with a TPM by sniffing the LPC bus

BitLocker has a TPM+PIN, TPM+Key and TPM+PIN+Key pre-boot authentication setting but you need to tinker on Group Policy to do that. You'd also need to enable other policies to make the PIN an alphanumeric password...

To confiscate the gov needs access to your phone, unlock code of phone and a warrant for Bitkey. Or somehow trick you in using the hardware with your finger print.

PS... Apparently, your recovery contact(s) would also have what's necessary to decrypt your app key stored in the cloud... so, potentially, if FBI compromises Bitkey server, your cloud provider, and also somehow a recovery contact, I suppose your wallet could be at risk without you necessarily ever even knowing it.

Now do LUKS. I'm genuinely curious. 1k sat bounty.

Yeah but it looks like the cloud key is not encrypted then with the bitkey. So in the end it's a setup with 2 hotkeys on someone else's computer. This make the hardware device itself more like a gimmick imo that leads to false sense of security. Would anyone here feel secure having their life savings in such a setup? 🤔

🙈

No, the cloud key IS encrypted with the bitkey device... but as long as you still have the unencrypted version of that key on your phone (in the app), you don't even have to bother with decrypting the cloud key in order to coordinate with bitkey to setup a new device (and new 2-of-3 keyset). The only purpose for the cloud key is in case you lose your phone (or delete the app), you can decrypt the key stored in your cloud (using your bitkey device) for use on a new phone. *there are also encrypted version(s) of your app key stored in YOUR cloud that your recovery contact(s) hold the decryption key for. In case you lose both your phone AND your bitkey device, installing a fresh app on a new phone will allow you to use the decryption key held by a recovery contact to recover your app key from YOUR cloud - which in turn can be used to coordinate with bitkey to setup a new device (and new 2-of-3 keyset). Of course, the app on your phone combined with the app on your recovery contact's phone handle the coordination of all this to make it reasonably painless. (minus the waiting period you mentioned earlier). Again, assuming designed as advertised (which I think is fair to question), I think it's pretty clever. My biggest problem with bitkey is that they advertise it as "self-custody"; but unlike virtually any other hardware wallet, if you lose the bitkey device, because it's designed to have nothing to backup (e.g. a seed phrase), self-recovery is not possible. In my book, reliance on a 3rd-party for recovery necessarily disqualifies it as self-custody.

... and no, personally, I would not feel secure having my life savings in something I don't consider to be self-custody (i.e. including self-recovery).

TLDR: Use a secure passphrase if you want the device protected against any resourceful actor When most distros provide encryption with LUKS they at least ask you to set up a credential. Almost all distros just ask for a password. They don't seamlessly allow setting up in other ways in a UI like BitLocker does or in the installer. You often need to read up on docs and such which can be tiresome. LUKS full disk encryption in how most users would know it would only be safe if they used a long, secure passphrase that would be impossible to brute force. A short 6 digit numeric PIN works for some phones because a secure element throttles unlock attempts but would be brute forced very quickly on LUKS, VeraCrypt and so on because they aren't using a TPM for throttling. Secureblue (hardened Linux distro we like) supports LUKS with TPM and also FIDO2.

I hear great things about secureblue but I still can't overcome my grudge over RPMhell back in the day. My LUKS pw is NOT 6 characters and for bonus points I have no idea what it is thanks to my onlykey. FIDO2 LUKS sounds even better for sure.

Not your keys? Not your privacy.

Every single US domiciled company can effectively under some legal pretexts be ordered to turn over any and all information they have about you to the government and to not even tell you that they did so. Think about that. It is one of many things that make it distasteful to me to start and operate a normal white market company in the US. You are effectively forced to be a tax collector, a snitch and to rat out your customers whenever the government wants.