Encrypt the disk of the models

#What disk encryption protects—and what it does not

Encryption at rest makes disk contents unreadable without the key: someone who steals the laptop, removes the SSD or seizes a powered-off workstation can recover only unusable data. That's the scenario it addresses, and it doesn't cover others: a powered-on, unlocked workstation, malware running under your session, or a weak password remain avenues of access. From a regulatory standpoint, Article 32 of the GDPR cites pseudonymization and encryption of personal data among the technical measures the controller must consider based on risk; it does not prescribe a specific tool, and the requirement depends on the context (healthcare, finance).

#What needs to be encrypted: the weights are not the secret

Models downloaded from Ollama or Hugging Face are public: an open-weight model's weights are not confidential unless you fine-tuned the model on private data. What is confidential is everything its use produces. Encrypting only the model directory therefore leaves the essential data exposed.

Conversation history

The Ollama terminal records input history in the .ollama directory of your profile (the Ollama code constructs the .ollama/history path); web interfaces such as Open WebUI keep their conversations in their own database.

Document index

A ChromaDB, Qdrant, or Weaviate database contains your document passages in readable form: it’s a duplicate of your files.

Source documents and exports

The PDFs placed in the RAG folder, the transcripts, and the saved outputs.

Swap and hibernation file

When memory is full, the system writes pages to disk: they may contain excerpts from your conversations. Arch Linux documentation notes that encrypted swap, reset at every startup, provides better protection because it prevents sensitive fragments from remaining unwritten over time.

Logs and temporary copies

Server logs, cache files, and editors that create copies.

Two strategies follow from this. The simplest and safest is to encrypt the entire system drive, covering everything in one operation. The second, when you cannot modify the system, is to encrypt a dedicated volume containing the data (indexes, documents, fine-tuned models) and move the folders that hold them there.

#macOS: FileVault

On a Mac with an Apple chip or a T2 security chip, Apple's documentation states that data is encrypted automatically: enabling FileVault adds another layer by making data access contingent on entering the login password. On an Intel Mac without a T2 chip, you must enable FileVault to encrypt data. The technical documentation describes FileVault as using the AES-XTS algorithm to protect entire volumes, relying on the hardware AES engine and the Secure Enclave in newer Macs.

1. 01
   Open settings

   Apple menu, System Settings, Privacy & Security, then FileVault.
2. 02
   Enable FileVault

   Click Activate; macOS offers two recovery methods.
3. 03
   Choose the retrieval method

   An iCloud account is convenient, with no separate key to keep track of; the recovery key is a string of characters that you should write down and store somewhere other than on the Mac. For sensitive data, prefer the recovery key.
4. 04
   Let the Mac work

   Encryption continues in the background; you can keep using the machine.

fdesetup status
# doit répondre : FileVault is On.

#Windows: BitLocker and device encryption

BitLocker is Windows' volume-encryption feature. According to Microsoft's documentation, it can be enabled on Windows Pro, Enterprise, Pro Education/SE, and Education. Windows Home does not provide access to it, but it does support device encryption, which automatically enables BitLocker on eligible machines; since Windows 11 24H2, the hardware requirements have been reduced, making more machines eligible.

A pitfall to know: automatic device encryption is enabled only after signing in with a Microsoft account or a work account, and the recovery key is then saved to that account (it can be found at aka.ms/myrecoverykey). With a local account, it isn’t enabled automatically, but you can enable BitLocker manually on an edition that supports it. For highly sensitive data, consciously decide where the key resides: an online account is convenient if the device is lost, but the key is no longer exclusively yours.

1. 01
   Open BitLocker

   Search for “Manage BitLocker” in the Start menu (Pro editions and above).
2. 02
   Enable on the system drive

   Choose TPM-based unlocking; add a PIN at startup to protect against direct booting of a stolen machine.
3. 03
   Save the recovery key

   Save it in a vault, or print it; avoid leaving it only on the machine.
4. 04
   Choose the scope

   On a new PC, encrypting the used space is sufficient; on a PC that has already been used, prefer full-disk encryption, which also covers free space where old data may remain.

#Linux: LUKS for the entire disk

LUKS is the disk encryption standard on Linux, managed by the cryptsetup tool. According to its manual page, the default format is LUKS2. The simplest approach is to choose it during installation: Ubuntu, Fedora, and others offer an “encrypt the new installation” checkbox that asks for a password. The entire system disk, including the swap file, is then protected. You can check afterward with cryptsetup status on the name of the open volume, or with lsblk -f, which indicates the crypto_LUKS type.

#Linux: encrypt only a data drive and place Ollama on it

The common case is an unencrypted system with a second SSD reserved for AI data. Encrypt this second drive with LUKS, then move the models and index directories there. The Ollama documentation states that the model location is configured with the OLLAMA_MODELS variable and that, with the standard Linux installer, the ollama user must have read and write access to the selected directory.

lsblk                                 # identifiez le bon disque ; ici /dev/sdb
sudo cryptsetup luksFormat /dev/sdb   # crée le volume LUKS et demande un mot de passe
sudo cryptsetup open /dev/sdb models   # ouvre : /dev/mapper/models
sudo mkfs.ext4 /dev/mapper/models
sudo mkdir -p /mnt/models
sudo mount /dev/mapper/models /mnt/models
sudo mkdir /mnt/models/ollama
sudo chown -R ollama:ollama /mnt/models/ollama

[Unit]
RequiresMountsFor=/mnt/models

[Service]
Environment="OLLAMA_MODELS=/mnt/models/ollama"

The RequiresMountsFor line tells systemd that the service must not start until the volume is mounted: without it, Ollama may start before unlocking, create an empty folder on the unencrypted disk, and redownload the models there. After making the change, run sudo systemctl restart ollama.

#Password or key file: the system-disk file trap

There are two approaches to opening the volume at startup. With a password, the system asks for it at every boot (a crypttab entry with the “none” key). With a key file, opening is automatic, but everything depends on where the file is stored. Placing the key in /root/ on an unencrypted system almost completely defeats the protection: anyone who steals the machine can read the key file on the system disk and then open the volume. A key file makes sense only if the disk containing it is itself encrypted. On a server without a screen, the usual compromise is an encrypted system unlocked remotely, or manual unlocking after every reboot.

models  /dev/sdb  none  luks

# /etc/fstab
/dev/mapper/models  /mnt/models  ext4  defaults  0  2

Encryption adds computational overhead to every read and write. For an LLM, weights are read mainly when the model loads: the effect is most noticeable in load time, not in generated tokens. Measure your processor's encryption throughput with cryptsetup benchmark, and compare a model's load time before and after; don't rely on a general figure.

#NAS and backups: don't undo encryption

NAS

Make sure shared folders containing models or backups are encrypted, and know where the key resides. A NAS that unlocks its volume automatically at startup protects against theft of the disk alone, but not theft of the entire device.

Backup drive

An unencrypted USB backup drive defeats workstation encryption: encrypt it with the same tool, or use backup software that encrypts before writing.

Cloud backup

Make sure encryption happens on your side, using a key that only you possess; otherwise, the provider could technically read your files.

Recovery key

Always separate the key from the backup it protects: two distinct locations.

#Frequently asked questions about model disk encryption

• Privacy checklist
• Air-gap the machine
• Local AI in the enterprise: GDPR, sovereignty, and deployment
• Legal advisor: analyze a contract without leaks
• Share Ollama on your local network

• Source: Apple, FileVault
• Source: Microsoft, BitLocker
• Source: cryptsetup manual page
• Source: Ollama FAQ, model location