• caglararli@hotmail.com
  • 05386281520

Best Practice for Creating and Accessing an Encrypted Database with a Strong Threat Model

Çağlar Arlı      -    5 Views

Best Practice for Creating and Accessing an Encrypted Database with a Strong Threat Model

Goal:

I'm seeking feedback on the most secure setup for creating and accessing an encrypted database (KDBX4 format) that minimizes exposure to potential remote attacks. This database will contain highly sensitive information, and my primary focus is securing both the initial creation and subsequent access phases.

Threat Model:

The main concern is remote attacks (e.g., malware, zero-day vulnerabilities, network-based threats). Physical access threats are less of a concern as I control the physical security of my devices. My primary aim is to prevent any exposure of the database file or its encryption key to online threats. I am not concerned about brute-force attacks on the encrypted file itself, as I will use a strong KDF and a high-entropy password.

Distinct Processes: Database Creation vs. Access

Creation Process

The creation process involves setting up an isolated environment to install KeePassXC and generate the encrypted database file (KDBX4). My goal is to do this in an environment as isolated from network and remote threats as possible.

Access Process

The access process involves periodically opening the encrypted database to view or update information. My aim here is to balance security and convenience, ensuring that sensitive data can only be decrypted in a secure, preferably isolated, environment.

Setup Options for Creation

1. Airgapped Older Device (MacBook Pro)
  • Process: Reformat the old MacBook, install either the latest supported macOS or a secure Linux distro, and keep it permanently airgapped.
  • Database Creation: Install KeePassXC on this airgapped machine, create the encrypted database, and then transfer the database file to the intended storage location via USB.
  • Advantages: Complete isolation from the internet during creation, minimizing remote attack risks.
  • Concerns: Using an older device might expose it to local vulnerabilities that could theoretically compromise the database.
2. Linux Live USB Bootable Environment (Used on My Primary Online Machine)
  • Process: Boot into a secure, airgapped Linux OS from a USB stick on my everyday machine. The live environment is booted to avoid lasting changes and network exposure.
  • Database Creation: Install KeePassXC in the live environment, create the encrypted database, and transfer it via USB.
  • Advantages: Provides isolation from the primary macOS environment during creation, without needing a separate device.
  • Concerns: Booting from USB on a regularly-used online machine may expose the live environment to host-based risks.
3. Virtual Machine (VM) (Used on My Primary Online Machine)
  • Process: Set up an Linux VM on my primary MacBook Pro, isolate it from host (disable network, sharing, etc), and create the database in the VM.
  • Database Creation: Install KeePassXC in the VM, create the database, and transfer it to an isolated backup.
  • Advantages: Easy to set up, provides some isolation from the host OS.
  • Concerns: Potential risk from the macOS host if it’s compromised, as malware or vulnerabilities could affect the VM. The virtual disk where the database resides could theoretically be exposed to the host filesystem (encrypting the disk should mitigate risks).

Setup Options for Access

For access, I’d prefer a setup that allows for secure viewing and updating of the database while minimizing risk exposure. Here are the primary options I’m considering:

1. Airgapped Older Device
  • Access Process: Continue to access the encrypted database on the same airgapped MacBook Pro where it was created. Data could be transferred via USB for secure storage if needed.
  • Advantages: Keeps the database in a permanently offline, isolated environment for maximum security.
  • Concerns: This setup requires maintaining a second device, which is less convenient.
2. Different OS booted from internal or external drive
  • Access Process: Boot on a differente encrypted instances of macOS (or Linux distro), which remains offline and airgapped while accessing the database.
  • Advantages: Provides isolation from the primary macOS environment each time, while being convenient enough for ad hoc access.
  • Concerns: Requires rebooting the primary machine for access, which is less convenient if frequent access is needed.
3. Virtual Machine on My Primary Machine
  • Access Process: Run an airgapped Linux/macOS VM to open and interact with the database.
  • Advantages: Easy to open the VM when access is needed, and the VM can be isolated (the strength of the isolation is the big question here)
  • Concerns: Since it’s hosted on an online primary machine, any malware on the macOS host could theoretically impact the VM’s integrity.

Storing the Encrypted Database

For backup redundancy, I’m considering storing the encrypted database file in cloud storage. My plan is to only access it in an airgapped environment, benefiting from online backup redundancy without introducing significant risk.

Questions:

  1. For the initial database creation, I believe option 1 is the most secure. What will be the second best choice between option 2 (Linux live USB boot) and option 3 (VM)?
  2. To install KeePassXC, I need to briefly “break” the isolation via USB or network connection. I also need to transfer the KDBX4 file for backup purposes. What’s the safest way to handle these temporary exposures, and which is preferable: USB or network connection?
  3. Is my approach of storing an encrypted database online (for redundancy) and only accessing it in an isolated environment sound, or are there overlooked risks?
  4. For the isolated environment—whether for creation or access—is there a recommended OS choice between Linux and macOS? Any configurations to strengthen isolation are also welcome.
  5. What are the risks of using an airgapped older machine with outdated software (mainly if using macOS)?
  6. If I use the least secure option for access the database (and potentially update it), does it still make sense to use the most secure option for creation?

Any advice, critiques, or recommendations on securing both creation and access processes would be greatly appreciated. Thank you!