Safe decryption with GnuPG?

[Steve Revilak]

> I have a file that I encrypted for myself 
> and I want to read some information from it. 
> The file is a text file and I need to read several lines of it.
> 
> The following requirements must be met:

I was going to suggest

   gpg --decrypt file.gpg | grep "interesting stuff" | banner | less >/dev/null

but I'll try to be more serious. :)

Out of curiosity, what kind of a threat vector are you anticipating?
By reading your list of requirements, the ones I've extracted are

  * Access to sensitive data via system memory is a threat.

  * Access to sensitive data via the file system (i.e. by examining
    swap space) is a threat.

  * Access to sensitive data via the graphics system framebuffer is a
    threat.

  * Access to sensitive data via visual observation (someone sees the
    text on the screen, or takes a picture of the text on the screen)
    is a threat.

As someone else mentioned, this brings up a lot of issues in the area
of trusting the hardware, trusting the operating system and so fourth.
Granted, they are interesting issues, but my gut instinct tells me
that this problem might be easier to solve with physical security.

For example, the first three threats imply that the data has to leave
the system where it is being viewed.  Removing network access to that
system (unplug the ethernet cable, remove any wireless/bluetooth
hardware), would mitigate those threats, no?

As for threat #4, if you're viewing the data in a small, bare-walled,
locked room, you'd be able to tell (a) whether someone else was in the
room looking over your shoulder or (b) whether there was a camera
being pointed at your screen.

And if you don't trust the isolated computer in the small locked room,
you could even go as far as removing its hard drive -- you'd walk in
with a bootable CD that contained your encrypted file, boot up, read
what you needed, then halt.

Steve




> From: Philipp Gühring <pg at futureware.at>
> Date: Wed, 6 Feb 2008 02:22:09 +0100
> Subject: Re: Safe decryption with GnuPG?
> Message-ID: <200802060222.10599.pg at futureware.at>
> To: gnupg-users at gnupg.org
> Cc: Krzysztof Żelechowski <program.spe at home.pl>
> 
> Hi,
>
>> 1.
>> The decrypted information must not make it to any persistent medium
>> (I understand gpg '-d' already guarantees it
>> as long as it manages the decrypted text,
>>  but what happens after it leaves gpg?)
>
> Use a full-disc encryption system for all your persistent media.
>
>> 2.
>> The decrypted text must not be stored in volatile memory
>> any longer than it is needed.
>
> You can use TaintedBochs or TaintedQemu to investigate that.
>
>> In particular, it should be converted to a human-viewable bitmap
>> and the computer-readable representation must be immediately erased.
>
> Doesn´t help much to try that, I would say. But feel free to try ...
>
>> 3. Only the information I need should be displayed.
>
> You need a Do-What-I-Mean system for that.
>
>> 4.
>> The bitmap must not be updated automatically
>> (the containing window must not display it
>> when it is in the background, whatever it means).
>> (It would be best to forget the bitmap altogether
>> and regenerate it upon request,
>> but it seems to be a hard thing to do
>> because the gpg output stream is not scrollable backwards).
>
> Use Overlay mode to display it.
>
>>
>> 5.
>> The bitmap itself should not make it to any persistent medium
>> and it should be scrambled, if possible, in the volatile memory.
>
> Implement the viewer in the graphic card, with the CUDA SDK or something
> similar.
>
>> 6.
>> It should not be possible
>> to make a snapshot of the graphic in the window
>> with any programmatic means
>> (you can of course make a picture of the screen with a camera).
>
> Overlay mode does that.
>
>> 7.
>> If more information is requested,
>> it should be displayed in small chunks.
>> The program should be fully unaware
>> of the content of the chunks that are not being displayed.
>
>> (That probably means a garbage-collected language cannot be used).
>
> I don´t understand why you need that.
> I would suggest that you seperate the small chunks into seperated encrypted
> files, to ensure that the reader only gets those chunks that you actually
> decrypted.
>
>> 8.
>> The application should be as lightweight as possible
>> (for source code audit).
>
> Agreed.
>
>> Can you direct me to some implementation meeting these requirements?
>
> I think your specification isn´t complete yet. You forgot about half of the
> requirements.
>
> I guess that:
>
> * You want a machine that seperates code from data (to be secure against
> trojans, virii and other malware)
>
> * You want secure documents, that can´t change dynamically, or otherwise
> contain invisible contents
>
> * You want a secure path to the user
>
> (and some more requirements that I forgot at the moment)
>
> What´s your budget for this small project?
>
> Best regards,
> Philipp Gühring
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>