AW: Extraction of decryption session key without copying complete encrypted file

[Fiedler Roman]

> 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
> could
> > abuse your secret key on your localhost, especially when a GnuPG-card
> is
> > 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 ...

CAVEAT here!

> ... 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 [1] 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.

LG Roman

[1] https://lists.gnupg.org/pipermail/gnupg-users/2017-August/058821.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4814 bytes
Desc: not available
URL: </pipermail/attachments/20170804/37cb8707/attachment-0001.bin>