mirror of
https://github.com/octoleo/restic.git
synced 2024-11-05 21:07:52 +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
|
||||
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.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user