AW: Extraction of decryption session key without copying complete encrypted file
Roman.Fiedler at ait.ac.at
Fri Aug 4 16:22:20 CEST 2017
> Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von
> On 04/08/17 14:39, Matthias Apitz wrote:
> > But this implies that everyone with priv access on the remote host
> > abuse your secret key on your localhost, especially when a GnuPG-card
> > used and you entered the PIN to unlock the secret key. I'm wrong?
> Yes, someone with root on the remote machine can do whatever they want
> on that machine. The solution is not to perform *any* crypto on a
> machine whose admins you do not trust. There's nothing that software can
> do to protect you from rogue sysadmins.
> If you don't want the sysadmins on the remote machine to abuse your
> private key, then you have to download the data, perform your crypto
> locally and ...
> ... then upload the data again. Once you allow any software on
> the remote machine to access your local resources, the remote sysadmins
> can access them too.
> This applies to all sorts of other things BTW, such as client drives and
> printers shared over RDP.
So true, except for one minor thing: from risk perspective, the damage is the
same if you download and upload again: if the attacker/sysadmin has replaced
the file with something, you did not want to decrypt, you will decrypt the
wrong thing and upload it again. The only way to prevent that is to review the
unencrypted data before uploading it again.
The initial workflow in  does not include the review either, thus should be
of same security/risk level as the procedure you described. Currently I
believe, that in our workflow this additional protection would not be worth
it: if an attack can both replace an encrypted backup file on the main backup
storage with something more valuable, encrypted with the same key, and then
fetch the decrypted data from the system receiving the backup dump for
restore, then we are completely done anyway.
I just want to avoid to have an additional point of failure (except the
keystore itself), where compromise of a single machine will compromise
arbitrary backup data.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4814 bytes
Desc: not available
More information about the Gnupg-users