boreas
February 24, 2024, 7:24pm
1
Hello!
While thinking about the problem that a user never knows about what data is signed or decrypted while using Split GPG the following things came to my mind:
Signing:
Why not sending the (untrusted) data from email qube to gpg vault.
Then we show the (untrusted) data in a dispvm launched out of gpg vault.
If the user continues, the data will get trusted.
Now the signing begins, gets send back to email qube and is sent off (can’t be changed afterwards as the signature will become invalid)
Decrypting:
Send (untrusted) data to vault
Decrypt (untrusted) data
show (untrusted) data in dispvm
If user continues, data gets trusted
trusted data is sent back
Trusted here of course also means that the user wants to decrypt the data.
1 Like
deeplow
February 24, 2024, 8:09pm
2
I have heard this proposal in the past, even from Qubes team members. But I guess it never ended up being implemented.
boreas
February 24, 2024, 9:46pm
3
@deeplow Interesting… I guess you don’t know why?
Nope. Try searching on github on qubes-issues and if you can’t find it, you can open an enhancement proposal.
1 Like
boreas
March 6, 2024, 7:24pm
6
If anyone interested, I finally found the time to make an issue:
opened 07:24PM - 06 Mar 24 UTC
T: enhancement
P: default
[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/)
#… ## The problem you're addressing (if any)
Currently, the Split GPG documentation [here](https://www.qubes-os.org/doc/split-gpg/) states that it is not possible to verify what actual data is being signed / decrypted before the process has happened. Furthermore, an attacker who infected an email qube can make a request for the signing of an malicious mail when the user would await such a request (e.g. after pressing the send button to send off a trusted mail).
The same thing can happen with decrypting files, when the attacker tricks the user into allowing a malicious request for decryption of the user's files.
### The solution you'd like
The short version is on the [forum](https://forum.qubes-os.org/t/proposal-for-split-gpg-improvement/24639).
My suggestion would be:
To sign anything: the request gets sent to the gpg vault as before. There, a disposable vm is launched out of the vault with the content in question (e.g. mail). The user now gets the opportunity to review what is actually being signed, as the attacker can't control what is going on in the vault. Any changes to the content to be signed should now be detected by the user.
If the user detects a change, 2 things are clear:
1) the mail qube has been hacked.
2) the content won't be signed and further analysis of the attack will follow.
If, however, the content is the same, the signing can go on and the signed message will be sent back to the mail qube and sent off. Even if an attacker is in the mail qube, again it's not possible to change the signed content as the signature would become invalid.
For decryption:
The content in question will be sent to the vault, decrypted and then sent to a disposable vm. There the user has again the opportunity to confirm that this is the data supposed to be decrypted. If it meets the expectations, the data is sent back to the requesting qube, otherwise it is also obvious that an attack took place.
### The value to a user, and who that user might be
This feature would help any user with Split GPG configuration in place. The benefit would be an increased certainty in the signed / decrypted data and therefore an security improvement regarding GPG actions in general. A further advantage is the (slightly) increased chance of detecting an attack, if the attacker still changes the content before signing / decrypting.
2 Likes