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

[Fiedler Roman]

> Von: Matthias Apitz [mailto:guru at unixarea.de]
> 
> El día viernes, agosto 04, 2017 a las 01:59:57p. m. +0200, Werner Koch
> escribió:
> 
> > On Wed,  2 Aug 2017 15:52, Roman.Fiedler at ait.ac.at said:
> >
> > > How to decrypt large files, e.g. gpg-encrypted backups, without
> copying them to the machine with the GPG private key?
> >
> > With GnuPG 2.1 this is easy:  You use ssh's socket forwarding feature
> to
> > forward gpg-agent's restricted remote socket, for example
> >
> >   /run/user/1000/gnupg/S.gpg-agent.extra
> >
> > to the host and there you run gpg which will then connect back to the
> > agent on your desktop.  For details see
> >
> > https://wiki.gnupg.org/AgentForwarding
> 
> 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?

Of course, that is why, I want to get rid of the private keys after some time, probably using measures as depicted in [1].

>From the risk analysis view: If the attacker is already on the source machines, just monitoring admin behaviour, he is likely to learn how the session key exchange procedure will work and may manipulate the procedure in such a way, that I will decrypt messages for him anyway. So that first incident cannot be mitigated in any way - the drawback of performing just any operation on an untrusted computer system. The only difference would be:

a) using the agent-port might be more stealthy, especially when the agent does not display information, how many decryption request were processed. Hence [1] to perform a single decryption request at most before user interaction is needed.

b) interfacing the agent port might be easier than understanding a 25 line shell script and manipulating it in such a way, that it replaces the data to be decrypted before forwarding it.

After that first incident, risk of agent port is higher: with the port, attacker can continue to send more sign/decrypt requests. Without that, admin would notice, that the session key produced by the decryption procedure was not correct to decrypt the target file, thus some manipulation has occurred. If fast, he might even disconnect the VM network adapter of the affected machine before the attack could have decrypted and transferred the whole file (unless he did not transfer it beforehand and just stole the session key the moment it was provided).

LG Roman

[1] https://lists.gnupg.org/pipermail/gnupg-users/2017-August/058834.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/b0430ec9/attachment.bin>