Mailing List Archive

Warning messages.
Hi,
I have small problem with warning messages. When ever I'm doing
something with GPG I get fallowing message"

gpg: Warning: using insecure memory!

The second thing is, that when I encrypt messages with my friends public
keys I get fallowing message:

It is NOT certain that the key belongs to its owner.
If you *really* know what you are doing, you may answer
the next question with yes

The problem is, that I'm sure, that this key belengs to its owner,
because I got it personally. I changed trust (with: gpg --edit-key) to I
trust fully, but it didn't help.

Could anyone tell me, how to get rid of this messages? I can live with
this, but it is a little bit annying.


--
--------------------------------------------------------------------
Marcin Okraszewski
mailto:okrasz@vlo.ids.gda.pl http://www.vlo.ids.gda.pl/~okrasz/
--------------------------------------------------------------------
PGP key: http://www.vlo.ids.gda.pl/~okrasz/pgp.txt
finger okrasz@vlo.ids.gda.pl
Re: Warning messages. [ In reply to ]
On Fri, Jun 25, 1999 at 04:09:19PM +0200, Marcin Okraszewski wrote:
> gpg: Warning: using insecure memory!

This is a serious warning that your secret keys could end up in a disk
swapfile or whatever. If you're happy to live with that risk (e.g. on a
standalone private workstation) then you can put

no-secmem-warning

in .gnupg/options to make it go away.

> It is NOT certain that the key belongs to its owner.
> If you *really* know what you are doing, you may answer
> the next question with yes

(I think) this means there was no signature path from your key to your
friend's key. If you are sure the key is legit, sign it, and the warning
message will go away.

Dave
--
Dave Holland -<>- Systems Administrator -<>- Incyte Genetics, Cambridge, UK
Re: Warning messages. [ In reply to ]
#define PARANOID

On Sat, Jun 26, 1999 at 12:21:44AM +0200, Michael Roth wrote:

> When you think about you will note that everone who is able to get access
> with privileges to read out the paging area of the disk is also able to
> manipulate the system in all possible ways including substituting the gpg
> binary with a manipulated one.

Think outside the box. An attacker can walk into your server
room and walk out with your box without breaking root. I can
encrypt my filesystems so that I need to enter a key from the
console to boot. I can't encrypt my swap.

(I wonder if there's a Linux or BSD patch to do that? You
"just" need to figure out how to find some entropy at system boot-
time, then keep your key in the kernel's data space. The swap
contents are worthless anyway if you lose the running system, so
the key need never go near permanent storage.)

One effect of mlock() is to protect, in software, against a
physical deficiency in security. I don't think there's an
instrument that can read SDRAM chips through the ceramic
housing, or at least not a portable unit, so RAM is one of damn
few things we can consider tamper-proof.

> In my view (and many others) their is absolutly no security improvement by
> protecting memory pages from writing them to disk. As noted by someone
> else you can switch off the warning message with --no-secmem-warning.

Let's say you use gpg today and I mount a big DoS attack on your
system that gets the critical page swapped out for just a second.
You get the correct results, but even so you notice the attack and
never fully trust the system again. But it's a system you can't
take down for whatever reason. Next month I get a hold of a root
exploit for your system just before you patch it. I sneak in,
take a snapshot of your swap space (and of course your files),
cover my tracks and get out, never to be seen again.

Yes, in (#ifdef PARANOID\n#define theory fact\n#endif) theory
any root compromise forever taints a system. The problem with not
locking in the private key is that it can be compromised after gpg
terminates so that a root compromise can go back in time.

I personally just turn off the warning for my everyday use, but
not when it's protecting something worth enough that there are
parties who *will* attempt to steal it. So I counter the view of
"absolutely" no improvement. I'm happy with the current state of
affairs, although I wish my preferred OS allowed non-root mlock()
with an rlimit on it (which could default to 0).

#ifndef PARANOID
I'm just nitpicking.
#else
The warning is there for a reason.
#endif

Off-topic (but with obvious relevance): Linux 2.0 is widely
reported as unstable without any swap space. Is it stable with a
1M ramdisk as the only swap?

--
Rich Derr, sysadmin Have ssh, Will Telecommute
Web Design Group www.webdesigngroup.com TEL: +1 312 951 6688
Re: Warning messages. [ In reply to ]
Rich Derr <rhd-gpg@webdesigngroup.com> writes:

> Think outside the box. An attacker can walk into your server
> room and walk out with your box without breaking root. I can

Sure, but I would install a trojan horse which has the advantage that
nobody will notice it (in most cases). A missing machine (or disk)
should be detected very soon (in most cases).

--
Werner Koch at guug.de www.openIT.de keyid 621CC013
Re: Warning messages. [ In reply to ]
Michael Roth wrote:

> When you think about you will note that everone who is able to get access
> with privileges to read out the paging area of the disk is also able to
> manipulate the system in all possible ways including substituting the gpg
> binary with a manipulated one.

Isn't the problem that things written to the paging area can be read out
after the event? If I was raided by the secret police, there might be
something in my paging file that they could use. On the other hand, if
they gave me the machine back I would be unlikely to use it without
checking very carefully that the gpg binary (and kernel, etc.) had not
been interfered with.

What would be quite nice is a way of telling the kernel that a
particular page must be encrypted before being written to swap. If the
machine is powered off, the session key is lost and so the page is
unrecoverable. This would be better than locking a page in physical
memory because there would be no need to restrict its use. The CPU time
taken to encrypt and decrypt would be charged to the process concerned
so it would not introduce any scheduling "unfairness".

-----------------------------------------------------------------------
Pete Chown, email pc@skygate.co.uk, phone +44 (0) 181 680 8393,
fax +44 (0) 181 688 8013, mobile +44 (0) 468 765 645,
post 58 Foss Avenue, Croydon, CR0 4EU, England
Re: Warning messages. [ In reply to ]
On Mon, Jun 28, 1999 at 10:36:46AM +0200, Werner Koch wrote:
> Rich Derr <rhd-gpg@webdesigngroup.com> writes:
>
> > Think outside the box. An attacker can walk into your server
> > room and walk out with your box without breaking root. I can
>
> Sure, but I would install a trojan horse which has the advantage that
> nobody will notice it (in most cases). A missing machine (or disk)
> should be detected very soon (in most cases).

Which is why I have my high-value filesystem encrypted. I'm
talking about a case where tamper-evidence, while important,
ultimately still leaves the user bankrupt.

Until encrypted swap space is as availible as encrypted
filesystems are -- and both could obviously stand a big boost in
availibility -- the warning has meaning.

--
Rich Derr, sysadmin Have ssh, Will Telecommute
Web Design Group www.webdesigngroup.com TEL: +1 312 951 6688
Re: Warning messages. [ In reply to ]
>
> Michael Roth wrote:
>
> > When you think about you will note that everone who is able to get access
> > with privileges to read out the paging area of the disk is also able to
> > manipulate the system in all possible ways including substituting the gpg
> > binary with a manipulated one.
>
> Isn't the problem that things written to the paging area can be read out
> after the event? If I was raided by the secret police, there might be
> something in my paging file that they could use. On the other hand, if
> they gave me the machine back I would be unlikely to use it without
> checking very carefully that the gpg binary (and kernel, etc.) had not
> been interfered with.
>
> What would be quite nice is a way of telling the kernel that a
> particular page must be encrypted before being written to swap. If the
> machine is powered off, the session key is lost and so the page is
> unrecoverable. This would be better than locking a page in physical
> memory because there would be no need to restrict its use. The CPU time
> taken to encrypt and decrypt would be charged to the process concerned
> so it would not introduce any scheduling "unfairness".
>
What if all pages which are 'freed' are zero filled. I.e. when the memory
is no longer needed and/or the program is quit.

If this is done, the only time the machine is in risk, is the time the
software runs. After which the memory is clear from the text, and the
swap is cleared..

BTW. is there some kind of vi with encryption? meaning the plain-text is
never written to HD?

just my 2 cents.

--
Thomas Zander zander@microweb.nl
History repeats itself, it has to, nobody ever listens
Re: Warning messages. [ In reply to ]
Rich Derr <rhd-gpg@webdesigngroup.com> wrote:

> Think outside the box. An attacker can walk into your server
> room and walk out with your box without breaking root.

Werner Koch <wk@isil.d.shuttle.de> replied:

> Sure, but I would install a trojan horse which has the advantage that
> nobody will notice it (in most cases). A missing machine (or disk)
> should be detected very soon (in most cases).

Hmm... I'd expect it to be pretty expensive to hire a criminal with
sufficient computer skills for this. It would be much cheaper to equip
an ordinary burglar with an external tape drive and a diskette which
contains a simple program to dump the entire hard disk contents onto the
tape drive. The burglar's intructions would simply be "plug in tape
drive, insert diskette, switch power on, then wait until computer beeps
twice, then deliver the tape drive (leaving the office exactly like it
was before). The burglar wouldn't even need to switch the monitor on
(reducing his risk of being noticed).

The kind of set-up which Rich Derr suggested (encrypted filesystems for
all filesystems with the exception of swap partitions, and making
sure that no sensitive data ever goes to the swap area) seems pretty
good to me, in the sense that it would significantly increase the cost
of getting at the secret files. Any trojan horse installed (e.g. by
tampering with the boot loader) without breaking the encryption key used
for those encrypted filesystems would be easy to detect. Hence the
attacker would need to use a TEMPEST attack or a keyboard bug in order
to obtain the filesystem encryption key.

May blessings from the eternal God surprise and overtake you!
Norbert.

--
Norbert Bollow, Coach http://thinkcoach.com Backup email: nb@pobox.com
Re: Warning messages. [ In reply to ]
Thomas Zander <zander@microweb.nl> wrote:

> What if all pages which are 'freed' are zero filled. I.e. when the memory
> is no longer needed and/or the program is quit.

There is special data recovery hardware that allows to reliably
recover data from magnetic media even after it has been
overwritten several times. It is therefore much better to avoid
writing sensitive data to disk in the first place.

May blessings from the eternal God surprise and overtake you!
Norbert.

--
Norbert Bollow, Coach http://thinkcoach.com Backup email: nb@pobox.com
Re: Warning messages. [ In reply to ]
zander@microweb.nl wrote:

> What if all pages which are 'freed' are zero filled. I.e. when the memory
> is no longer needed and/or the program is quit.
>
> If this is done, the only time the machine is in risk, is the time the
> software runs. After which the memory is clear from the text, and the
> swap is cleared..

If there was a power failure at the wrong time you might have some left
over bits and pieces. I suppose you could alleviate this to a great
extent by having something like fsck for swap spaces which would zero
them on bootup if there had been a "disorderly shutdown".

If your information is so secret that this matters, though, you probably
shouldn't be swapping at all!

-----------------------------------------------------------------------
Pete Chown, email pc@skygate.co.uk, phone +44 (0) 181 680 8393,
fax +44 (0) 181 688 8013, mobile +44 (0) 468 765 645,
post 58 Foss Avenue, Croydon, CR0 4EU, England