Merge pull request #2536 from MatthewVance/threat-model

Update threat model

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.