Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: GnuPG: devel

secure memory for decryption buffer

 

 

GnuPG devel RSS feed   Index | Next | Previous | View Threaded


martin at gnutiken

Mar 16, 2012, 9:31 AM

Post #1 of 9 (533 views)
Permalink
secure memory for decryption buffer

Hello,

I sent a previous message (subject: gpgme not using secure memory?) to
the list but I assume it got lost in moderation (was not subscribed).

I'm writing a password manager and want it to use a gpg-encrypted file
for storing passwords. I figured that gpgme would be the right tool to
use to integrate gpg encryption/decryption in my application. However,
I'm unsure if gpgme stores decrypted data in secure memory. I don't want
passwords to be swapped to disk.

As far as I can tell from peeking at the gpgme source code, it reads
decrypted data using assuan_read_line, and I cannot find any mlock's
either in libassuan nor in gpgme.

I'm new to the gpg-related libraries so I might very well have missed
something, could someone please confirm if decrypted data can indeed be
swapped when using gpgme?

Thanks in advance!

/Martin


bjk at luxsci

Mar 16, 2012, 3:00 PM

Post #2 of 9 (522 views)
Permalink
Re: secure memory for decryption buffer [In reply to]

On Fri, Mar 16, 2012 at 05:31:26PM +0100, Martin Stenberg wrote:
> Hello,
>
> I sent a previous message (subject: gpgme not using secure memory?) to
> the list but I assume it got lost in moderation (was not subscribed).
>
> I'm writing a password manager and want it to use a gpg-encrypted file
> for storing passwords. I figured that gpgme would be the right tool to
> use to integrate gpg encryption/decryption in my application. However,
> I'm unsure if gpgme stores decrypted data in secure memory. I don't want
> passwords to be swapped to disk.

I have a project that does the same by using libassuan and gpg-agent.
Maybe you'd be interested in helping me with it? If so, the url is
http://pwmd.sourceforge.net/.

> As far as I can tell from peeking at the gpgme source code, it reads
> decrypted data using assuan_read_line, and I cannot find any mlock's
> either in libassuan nor in gpgme.
>
> I'm new to the gpg-related libraries so I might very well have missed
> something, could someone please confirm if decrypted data can indeed be
> swapped when using gpgme?

I use the custom memory allocators to create a linked list of
pointers which are zero'd before being freed.

--
Ben Kibbey
[XMPP: bjk AT jabber DOT org] - [IRC: (bjk) FreeNode/OFTC]

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


robbat2 at gentoo

Mar 16, 2012, 4:18 PM

Post #3 of 9 (523 views)
Permalink
Re: secure memory for decryption buffer [In reply to]

On Fri, Mar 16, 2012 at 05:31:26PM +0100, Martin Stenberg wrote:
> I'm writing a password manager and want it to use a gpg-encrypted file
> for storing passwords. I figured that gpgme would be the right tool to
> use to integrate gpg encryption/decryption in my application. However,
> I'm unsure if gpgme stores decrypted data in secure memory. I don't want
> passwords to be swapped to disk.
This sounds very similar to the Debian pwstore application.
https://github.com/formorer/pwstore

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2 [at] gentoo
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


wk at gnupg

Mar 18, 2012, 9:11 AM

Post #4 of 9 (510 views)
Permalink
Re: secure memory for decryption buffer [In reply to]

On Fri, 16 Mar 2012 17:31, martin [at] gnutiken said:

> use to integrate gpg encryption/decryption in my application. However,
> I'm unsure if gpgme stores decrypted data in secure memory. I don't want
> passwords to be swapped to disk.

There is no need for it. GnuPG manages its passphrases using the
gpg-agent daemon. GPGME does not need to care about passphrases. Well,
there is an API for passphrases, but it is only used by old GnuPG
versions; its use is not recommended.

The use of mlock is not trivial and more or less impossible for a
general purpose library like GPGME. Further, the protection this
"secure memory" provides is very questionable these days. You are
better off using an encrypted swap partition.

Using an mlocked memory area for arbitrary sizes of data is not a good
idea in any case.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


martin at gnutiken

Mar 18, 2012, 9:28 AM

Post #5 of 9 (509 views)
Permalink
Re: secure memory for decryption buffer [In reply to]

On Fri, Mar 16, 2012 at 06:00:05PM -0400, Ben Kibbey wrote:
> I have a project that does the same by using libassuan and gpg-agent.
> Maybe you'd be interested in helping me with it? If so, the url is
> http://pwmd.sourceforge.net/.

Thanks for the invite. I am however looking for a very small command
line tool, something like https://github.com/AlexBio/Safely. Safely is
pretty much exactly what I'm writing, minus jansson depenency and some
extra feautres. I'm mostly doing this to improve my skills in C and play
with encryption :)

> I use the custom memory allocators to create a linked list of
> pointers which are zero'd before being freed.

I've been leaning towards walking that path but am now considering using
mlockall instead. I don't know if this is a bad idea or not though.

/Martin


martin at gnutiken

Mar 18, 2012, 9:33 AM

Post #6 of 9 (512 views)
Permalink
Re: secure memory for decryption buffer [In reply to]

On Fri, Mar 16, 2012 at 11:18:14PM +0000, Robin H. Johnson wrote:
> This sounds very similar to the Debian pwstore application.
> https://github.com/formorer/pwstore

It is indeed. It is also very similar to Safely
(https://github.com/AlexBio/Safely), pwman
(http://pwman.sourceforge.net/) and probably a hundred others :)

I'm mostly doing this out of educationaly interests.


martin at gnutiken

Mar 18, 2012, 9:44 AM

Post #7 of 9 (513 views)
Permalink
Re: secure memory for decryption buffer [In reply to]

On Sun, Mar 18, 2012 at 05:11:30PM +0100, Werner Koch wrote:
> There is no need for it. GnuPG manages its passphrases using the
> gpg-agent daemon. GPGME does not need to care about passphrases. Well,
> there is an API for passphrases, but it is only used by old GnuPG
> versions; its use is not recommended.

It is not the passphrases I'm concerned about in this case, but the
content of the encrypted file (which in my case is a big list of
passwords).

> The use of mlock is not trivial and more or less impossible for a
> general purpose library like GPGME. Further, the protection this
> "secure memory" provides is very questionable these days. You are
> better off using an encrypted swap partition.
>
> Using an mlocked memory area for arbitrary sizes of data is not a good
> idea in any case.

Could gpgme not have memory allocator callbacks though, like assuans
assuan_malloc_hooks? But perhaps this is pointless if mlocks are a bad
idea anyways.

I'm very interested in knowing more about why keeping things in ram as a
protection are a questionable defence these days. Could you please
elaborate on this?

Cheers!


beebe at math

Mar 18, 2012, 11:29 AM

Post #8 of 9 (511 views)
Permalink
Re: secure memory for decryption buffer [In reply to]

Martin Stenberg <martin [at] gnutiken> asks on Sun, 18 Mar 2012 17:44:22 +0100

>> ...
>> I'm very interested in knowing more about why keeping things in ram as
>> a protection are a questionable defence these days. Could you please
>> elaborate on this?
>> ...

Take a look at this article:

J. Alex Halderman and eight others
Lest we remember: cold-boot attacks on encryption keys
Communications of the ACM 52(5) 91--98 May 2009
http://doi.acm.org/10.1145/1506409.1506429

-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe [at] math -
- 155 S 1400 E RM 233 beebe [at] acm beebe [at] computer -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


wk at gnupg

Mar 19, 2012, 12:38 AM

Post #9 of 9 (511 views)
Permalink
Re: secure memory for decryption buffer [In reply to]

On Sun, 18 Mar 2012 17:44, martin [at] gnutiken said:

> I'm very interested in knowing more about why keeping things in ram as a
> protection are a questionable defence these days. Could you please
> elaborate on this?

The reason you use mlock is to make sure that sensitive data does not
end up in the swap space. This is a valid concern and I implemented
this whole secure memory stuff 15 years ago as a defense against this
threat. However there is a much easier defense: Encrypt the swap space
using a random key. There is no need for any kind of key management;
the system just creates a one time key and holds this in non-pageable
kernel memory. Swapping is mostly I/O bound thus there are enough free
cycles to encrypt/decrypt the pages.

Another problem is that mlock does not help against hibernation -
eventually the content of the RAM will end up on the disk.

Yet another one is that I don't buy the arguments that it is possible to
protect a standard box against an attacker with physical access. There
is a wide range of possible attacks, the simplest one being a key logger
device.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

GnuPG devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.