Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-08-06 13:44:22 -04:00
Code Issues Projects Releases Packages Wiki Activity

Various formatting fixes

Browse source
This commit is contained in:
Marek Marczykowski-Górecki 2024-05-21 16:36:00 +02:00
parent bf13e5866c
commit 7598bbe156
No known key found for this signature in database
GPG key ID: F32894BE9684938A
7 changed files with 11 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

4
user/security-in-qubes/split-gpg.md
View file

@ -361,10 +361,10 @@ Once the master secret key is in the `work-email` VM, the attacker could simply
In the alternative setup described in this section (i.e., the subkey setup), even an attacker who manages to gain access to the `work-gpg` VM will not be able to obtain the user's master secret key since it is simply not there.
Rather, the master secret key remains in the `vault` VM, which is extremely unlikely to be compromised, since nothing is ever copied or transferred into it.
<sup>\*</sup> The attacker might nonetheless be able to leak the secret subkeys from the `work-gpg` VM in the manner described above, but even if this is successful, the secure master secret key can simply be used to revoke the compromised subkeys and to issue new subkeys in their place.
[^a-note] The attacker might nonetheless be able to leak the secret subkeys from the `work-gpg` VM in the manner described above, but even if this is successful, the secure master secret key can simply be used to revoke the compromised subkeys and to issue new subkeys in their place.
(This is significantly less devastating than having to create a new *master* keypair.)
<sup>\*</sup>In order to gain access to the `vault` VM, the attacker would require the use of, e.g., a general Xen VM escape exploit or a [signed, compromised package which is already installed in the template](/doc/templates/#trusting-your-templates) upon which the `vault` VM is based.
[^a-note]: In order to gain access to the `vault` VM, the attacker would require the use of, e.g., a general Xen VM escape exploit or a [signed, compromised package which is already installed in the template](/doc/templates/#trusting-your-templates) upon which the `vault` VM is based.
### Subkey Tutorials and Discussions