When you encrypt your data on your hard drive or in the cloud, the only way to access it is with the decryption key. Typically the decryption key is safely stored on your device, and made available when you unlock your device, or log in. But what if you can no longer do that? Where do you safely store a backup of this key (sometimes called a recovery key) in case something goes wrong?
Microsoft recommends that users of their BitLocker hard disk encryption system store the key on Microsoft servers, and use this as the default setting. While that might seem convenient for users that somehow loose access to their device, it also allowed the FBI to subpoena these keys in a criminal investigation. Others, like Apple, show the recovery key as a combination of numbers and letters and instruct you to save those somewhere safe. You could write them down, or store them on a USB thumb drive. Sometimes the recovery key can be shared with other devices linked to the same account, like a smartphone.
So which approach is better? That depends, actually.
Hard disk encryption protects against malicious access to data when the device is lost or stolen. So the only time you need the recovery key is when you forget the password that unlocks the device. (And your next of kin might need it if you pass away and they need access while not knowing your password.) Storing the recovery on a server protected by an account password (like Microsoft does) is clearly useless: if you knew the password you would never need the recovery key to begin with. Therefore, for hard disk encryption a better approach is to write the recovery key on a piece of paper, and store that safely (and tell your next of kin where you stored it). If there is a fire in your house that destroys your device(s), they disks are gone and the recovery keys are useless anyway. Storing it on a USB thumb drive is also an option, but do remember you need some other device to read from it: your own device may not boot if the disk encryption key is unknown. And make sure you do not loose it, or store it in the same bag as your laptop. (There are USB flash drives with biometric fingerprint authentication that prevent a data leak in such cases.) Because of this, I personally prefer the paper based approach.
For properly, end-to-end encrypted, cloud storage, the situation is very different. In fact, one of the reasons to use cloud storage is to still have access to your data even if all your devices are lost, stolen, or broken. If your house catches fire, and you are unable to take even your smartphone with you, you still want access to your data. You need the recovery key for that. If you wrote it on a piece of paper and stored it somewhere in the house, it’s gone. If you stored it in your wallet, it is also gone if you didn’t manage to take it with you while escaping. For this scenario, there is no easy answer to the question where to safely store the written recovery key. A safe box in a bank? At a trusted friend’s place, perhaps?
Therefore, in this setting, storing the key on a the cloud protected by an account password makes sense. However, not the way Microsoft does it! (And note, that this is not the encrypted hard drive case, anyway.) It should never be possible for the cloud provider to access the recovery key - because then it is no longer end-to-end encrypted. The approach used by many password managers is better: use an easy to remember but long enough passphrase to actually encrypt the recovery key. Logging in to your account would then use this passphrase to decrypt the recovery key stored there - preventing the cloud provider (like Microsoft) to ever get access to the recovery key (and hence your data) without your cooperation.
I am however not aware of any cloud provider offering this option. Apple for example, when using it’s (end-to-end encrypted) Advanced Data Protection cloud storage scheme, only shows the recovery key and instructs you to save it somewhere safe, similar to when enabling hard disk encryption.
If you know of other cloud storage providers doing it differently, do let me know!
Updates
Me neither. I don’t think any big tech would want to do E2EE cloud storage service in the first place. It’s just too much hassle for them when the only thing they care about is profit.
The secret ingredient is not relying on unauditable blackbox proprietary software like iCloud. I’m doing a write up on the idea of using dm-crypt/LUKS on iSCSI or NVME/tcp over VPN(Wireguard or, traditionally, IPSec). Tying them all together in the initd dependency tree(Systemd/openrc) was sort of a challenge, but it is doable and practical, I’d say.
We can always use security tokens like smartcard, FIDO2 and TPM, but you can’t beat the good old strong combo password hashed with exponential cost algo like bcrypt. As per the mud puddle problem, throw in a YubiKey. Why not? If both(your head cracked and your token burnt to a crisp) happens at the same time, well, sucks to be you. Just accept that God/universe hates you.