Background
I live in a high-risk region where phones and laptops can be seized and searched (often warrantless) by police, border control, or during administrative detention. There are credible reports of government-linked attacks that compromise Google accounts. Threat model includes:
Physical seizure of all devices
Coerced unlock (Phone PIN forced disclosure), or administrative detention
Remote compromise
No trusted individuals (secrets can be extracted under pressure)
Current Setup
Pixel 8 Pro (PIN + fingerprint only) – with Bitwarden logged in (biometrics-protected)
All important 2FA (TOTP + passkeys) registered only on YubiKeys → To prevent account be stolen due to phone or laptop compromised
GitHub GPG signing key stored on YubiKeys; private key GPG-encrypted and backed up
Anonymous Proton Drive (accessed only via Tails) contains:
Bitwarden encrypted JSON export (gpg -c further encrypted)
TOTP seeds / recovery codes (gpg -c encrypted)
GPG private key export (gpg -c encrypted)
Current Practices
Laptop LUKS2 unlocked via FIDO2 (systemd-cryptenroll)
Data USBs use passphrase only (not FIDO2) due to USB-C slot conflict — don’t want to carry/use hub constantly
All proton drive backups done exclusively in Tails
Questions
Should I store LUKS2 passphrases in Bitwarden?
Thinking of storing LUKS2 passphrases in Bitwarden (ask about both laptop and data USBs). Concern: If authorities get full phone access → they get Bitwarden → they get LUKS2 passphrases → physical seizure of USBs gives them full data. Alternative (FIDO2 on data USBs) is impractical due to slot conflict. Better approach under physical + compelled-unlock threat?
AWS remote server (Paperless-ng in Docker) authentication
How to best secure Linux login on this server? Storing root/user passwords in Bitwarden feels risky if phone/Bitwarden is compromised. Better options?
Phone is still the weak point despite YubiKey 2FA
Even with strong YubiKey-only 2FA, phone compromise breaks many accounts:
Discord QR login bypasses 2FA
Google auto-creates non-removable device-bound passkey on Android If government gets unlocked phone, they can access services directly.
Any realistic way to protect accounts even if phone is fully compromised/unlocked?
Stronger emergency recovery when all physical devices are confiscated
Current backup (GPG-encrypted files on anonymous Proton Drive via Tails) is still vulnerable. All hardware (YubiKeys, phone, laptop, USBs) can be taken at once → any recovery needing live 2FA/hardware at that moment is impossible. What are better strategies for getting back in when everything physical is gone? Willing to accept trade-offs (convenience, extra steps, etc.).
Final note
I understand nothing is 100% perfect in this threat model. If you have suggestions that involve limitations, sacrifices, or aren’t ideal but still meaningfully improve things — please share them. I will carefully consider every thoughtful reply. If you have better ideas (out of the questions) to enhance the security, please also feel free to share.
Okay, I have carefully read through this topic, but the threat model is not scoped specific enough, so I will address some of them:
Within your immediate possession and/or proximity?
Of your devices? If so, why would your adversaries bother to coerce you or others for secrets and/or seize your devices to begin with?
This is a difficult situation if interpreted literally, because that means no secrets can be safely held other than on tamper-resistant smartcards. The only other counter-measure within your control is your own tolerance against such pressure. Despite the threat of personal coercion, my previous post in this topic still stands, because Bitwarden increases your attack surface by being another critical point of failure against coercion or remote compromise.
Usually body search immediately then a house search while I’m being detained.
Compromising devices and online accounts. Specifically, in HK/China, they monitor basically everything including chat records. I don’t want to leak anything to them, as this may give them opportunities to charge me.
I am annoyed by having so many passwords. I believe the silverblue LUKS password is generally safe, since no keylogger works before boot. But for others data USBs’ LUKS password, they are entered in OS, so could be logged. Therefore, I tried to make all the passwords different, but they are hard to be memorized.
Hmmm, from your post I see some threats and your setup, but I cannot see your perceived risk assessment, esp. likelihood of you being targeted by the regime, and whether you/ your closed ones / your community, etc. will be in trouble if the regime have access to those information.
Your current setup seems quite robust, but you ignored the fact that for most of the times, autocratic regimes don’t need to break the devices, they only need to break YOU.
Also, in many cases, autocratic regimes don’t really need any information from you to convict you.
So, if you only want to protect yourself, IMO this setup is basically irrelevant, i.e. overkill in some aspects, but does nothing in other aspects.
Okay, that is plenty of context, and I see room for improvements:
This means that you can place devices outside of your adversaries’ search range, although I cannot necessarily provide suggestions within the country itself. However, I can recommend utilizing physical devices in different countries because they would be more costly for your adversaries to confiscate unless they are willing to internationally cooperate with other countries.
Okay, that changes the definition and interpretation of “remote compromise” a bit, because that heavily suggests that your adversaries require evidence to exercise seizure, not just the technical capability alone. This means there is room for you to maneuver if you utilize proxies that obfuscate your connection to remote servers, although I am only familiar with Tor pluggable transports, not Hysteria, Trojan, or other GFW-specific proxies. It is not clear from your workflow how you are able to utilize Tails, and specifically Tor, behind GFW, so my hard assumption is that you are already utilizing proxies and/or Tor pluggable transports.
Okay, password memorization can be improved by utilizing a wordlist, such as from the EFF, which is used in KeePassXC:
Define sufficient entropy bit against your adversaries’ capabilities, then embed these passphrases into muscle memory so you no longer need to recall them via cognition at all.
As for logging, hardware keyloggers can be used the moment the computer turns on, but if your adversaries do not use them, then we can refocus on software keyloggers instead.
Regarding the topic of “keylogger”, something occurs to me: couldn’t the OP just use a virtual keyboard like, for example, “onboard”?
I would never document the LUKS2 password for the notebook’s hard drive anywhere — I’d only keep it in my head.
I totally understand that the OP is trying to stack one security layer on top of another, but maybe a sensible (!) simplification would actually be better here?
It could look something like this:
Create a detailed threat model (there were already some helpful suggestions on that in this thread)
Derive the right measures from it
I know this is very generic advice, but I get the impression that the OP’s perfectly legitimate (!) technical security measures have grown over time in a kind of historical layering process and are now leading to unnecessary complexity.
