diff --git a/doc/design.rst b/doc/design.rst index 39f25c6c6..9ebe9e9b0 100644 --- a/doc/design.rst +++ b/doc/design.rst @@ -566,43 +566,100 @@ Threat Model ============ The design goals for restic include being able to securely store backups -in a location that is not completely trusted, e.g. a shared system where -others can potentially access the files or (in the case of the system -administrator) even modify or delete them. +in a location that is not completely trusted (e.g., a shared system where +others can potentially access the files) or even modify or delete them in +the case of the system administrator. General assumptions: - The host system a backup is created on is trusted. This is the most - basic requirement, and essential for creating trustworthy backups. + basic requirement, and it is essential for creating trustworthy backups. +- The user uses an authentic copy of restic. +- The user does not share the repository password with an attacker. +- The restic backup program is not designed to protect against attackers + deleting files at the storage location. There is nothing that can be + done about this. If this needs to be guaranteed, get a secure location + without any access from third parties. +- The whole repository is re-encrypted if a key is leaked. With the current + key management design, it is impossible to securely revoke a leaked key + without re-encrypting the whole repository. +- Advances in cryptography attacks against the cryptographic primitives used + by restic (i.e, AES-256-CTR-Poly1305-AES and SHA-256) have not occurred. Such + advances could render the confidentiality or integrity protections provided + by restic useless. +- Sufficient advances in computing have not occurred to make bruteforce + attacks against restic's cryptographic protections feasible. The restic backup program guarantees the following: -- Accessing the unencrypted content of stored files and metadata should - not be possible without a password for the repository. Everything - except the metadata included for informational purposes in the key - files is encrypted and authenticated. +- Unencrypted content of stored files and metadata cannot be accessed + without a password for the repository. Everything except the metadata + included for informational purposes in the key files is encrypted and + authenticated. The cache is also encrypted to prevent metadata + leaks. +- Modifications to data stored in the repository (due to bad RAM, broken + harddisk, etc.) can be detected. +- Data that has been tampered will not be decrypted. -- Modifications (intentional or unintentional) can be detected - automatically on several layers: +With the aforementioned assumptions and guarantees in mind, the following are +examples of things an adversary could achieve in various circumstances. - 1. For all accesses of data stored in the repository it is checked - whether the cryptographic hash of the contents matches the storage - ID (the file's name). This way, modifications (bad RAM, broken - harddisk) can be detected easily. +An adversary with read access to your backup storage location could: - 2. Before decrypting any data, the MAC on the encrypted data is - checked. If there has been a modification, the MAC check will - fail. This step happens even before the data is decrypted, so data - that has been tampered with is not decrypted at all. +- Attempt a brute force password guessing attack against a copy of the + repository (even more reason to use long, 30+ character passwords). +- Infer which packs probably contain trees via file access patterns. +- Infer the size of backups by using creation timestamps of repository objects. -However, the restic backup program is not designed to protect against -attackers deleting files at the storage location. There is nothing that -can be done about this. If this needs to be guaranteed, get a secure -location without any access from third parties. If you assume that -attackers have write access to your files at the storage location, -attackers are able to figure out (e.g. based on the timestamps of the -stored files) which files belong to what snapshot. When only these files -are deleted, the particular snapshot vanished and all snapshots -depending on data that has been added in the snapshot cannot be restored -completely. Restic is not designed to detect this attack. +An adversary with network access could: + +- Attempt to DoS the server storing the backup repository or the network + connection between client and server. +- Determine from where you create your backups (i.e., the location where the + requests originate). +- Determine where you store your backups (i.e., which provider/target system). +- Infer the size of backups by using creation timestamps of repository objects. + +The following are examples of the implications associated with violating some +of the aforementioned assumptions. + +An adversary who compromises (via malware, physical access, etc.) the host +system making backups could: + +- Render the entire backup process untrustworthy (e.g., intercept password, + copy files, manipulate data). +- Create snapshots (containing garbage data) which cover all modified files + and wait until a trusted host has used forget often enough to forget all + correct snapshots. +- Create a garbage snapshot for every existing snapshot with a slightly different + timestamp and wait until forget has run, thereby removing all correct + snapshots at once. + +An adversary with write access to your files at the storage location could: + +- Delete or manipulate your backups, thereby impairing your ability to restore + files from the compromised storage location. +- Determine which files belong to what snapshot (e.g., based on the timestamps + of the stored files). When only these files are deleted, the particular + snapshot vanishes and all snapshots depending on data that has been added in + the snapshot cannot be restored completely. Restic is not designed to detect + this attack. + +An adversary who compromises a host system with append-only access to the +backup repository could: + +- Render new backups untrustworthy *after* the host has been compromised + (due to having complete control over new backups). An attacker cannot delete + or manipulate old backups. As such, restoring old snapshots created *before* + a host compromise remains possible. + *Note: It is **not** recommended to ever run forget automatically for an + append-only backup to which a potentially compromised host has access + because an attacker using fake snapshots could cause forget to remove + correct snapshots.* + +An adversary who has a leaked key for a repository which has not been re-encrypted +could: + +- Decrypt existing and future backup data. If multiple hosts backup into the same + repository, an attacker will get access to the backup data of every host.