mirror of
https://github.com/octoleo/restic.git
synced 2024-11-11 15:51:02 +00:00
Merge pull request #2536 from MatthewVance/threat-model
Update threat model
This commit is contained in:
commit
84822d44d4
113
doc/design.rst
113
doc/design.rst
@ -566,43 +566,100 @@ Threat Model
|
|||||||
============
|
============
|
||||||
|
|
||||||
The design goals for restic include being able to securely store backups
|
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
|
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
|
others can potentially access the files) or even modify or delete them in
|
||||||
administrator) even modify or delete them.
|
the case of the system administrator.
|
||||||
|
|
||||||
General assumptions:
|
General assumptions:
|
||||||
|
|
||||||
- The host system a backup is created on is trusted. This is the most
|
- 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:
|
The restic backup program guarantees the following:
|
||||||
|
|
||||||
- Accessing the unencrypted content of stored files and metadata should
|
- Unencrypted content of stored files and metadata cannot be accessed
|
||||||
not be possible without a password for the repository. Everything
|
without a password for the repository. Everything except the metadata
|
||||||
except the metadata included for informational purposes in the key
|
included for informational purposes in the key files is encrypted and
|
||||||
files is encrypted and authenticated.
|
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
|
With the aforementioned assumptions and guarantees in mind, the following are
|
||||||
automatically on several layers:
|
examples of things an adversary could achieve in various circumstances.
|
||||||
|
|
||||||
1. For all accesses of data stored in the repository it is checked
|
An adversary with read access to your backup storage location could:
|
||||||
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.
|
|
||||||
|
|
||||||
2. Before decrypting any data, the MAC on the encrypted data is
|
- Attempt a brute force password guessing attack against a copy of the
|
||||||
checked. If there has been a modification, the MAC check will
|
repository (even more reason to use long, 30+ character passwords).
|
||||||
fail. This step happens even before the data is decrypted, so data
|
- Infer which packs probably contain trees via file access patterns.
|
||||||
that has been tampered with is not decrypted at all.
|
- Infer the size of backups by using creation timestamps of repository objects.
|
||||||
|
|
||||||
However, the restic backup program is not designed to protect against
|
An adversary with network access could:
|
||||||
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
|
- Attempt to DoS the server storing the backup repository or the network
|
||||||
location without any access from third parties. If you assume that
|
connection between client and server.
|
||||||
attackers have write access to your files at the storage location,
|
- Determine from where you create your backups (i.e., the location where the
|
||||||
attackers are able to figure out (e.g. based on the timestamps of the
|
requests originate).
|
||||||
stored files) which files belong to what snapshot. When only these files
|
- Determine where you store your backups (i.e., which provider/target system).
|
||||||
are deleted, the particular snapshot vanished and all snapshots
|
- Infer the size of backups by using creation timestamps of repository objects.
|
||||||
depending on data that has been added in the snapshot cannot be restored
|
|
||||||
completely. Restic is not designed to detect this attack.
|
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.
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user