Securely Erasing Memory

[JackC]

Hi,

Say i have:

secureclass *secure = new secureclass(); // has sensitive stuff in

Now i want to securely delete the instance and all the classes member
variables, I take it the 'delete' keyword will just deallocate it and
not overwrite it.

I have read that the 'volatile' keyword will guarantee that the memory
will be overwritten, my question is will it overwrite it at the point
where I call delete? (im not closing the program at the point of
securing the memory)

If not whats the easiest (portable) way of doing this? I thought about
overwriting the memory with null bytes before deleting it, sort of
sizeof(secureclass) raw bytes being written, is that any good?

Theres also the additional problem that the class could get swapped to
the disk paging file, I don't suppose theres a nice portable way of
preventing this as well?

Many Thanks,
JackC

 

[Chris M. Thomasson]

Hi,

Say i have:

secureclass *secure = new secureclass(); // has sensitive stuff in

Now i want to securely delete the instance and all the classes member
variables, I take it the 'delete' keyword will just deallocate it and
not overwrite it.

I have read that the 'volatile' keyword will guarantee that the memory
will be overwritten, my question is will it overwrite it at the point
where I call delete? (im not closing the program at the point of
securing the memory)

If not whats the easiest (portable) way of doing this? I thought about
overwriting the memory with null bytes before deleting it, sort of
sizeof(secureclass) raw bytes being written, is that any good?

Theres also the additional problem that the class could get swapped to
the disk paging file, I don't suppose theres a nice portable way of
preventing this as well?

What type of work are you doing? Basically, you need to replace all
representations of the file in the filesystem with random data. This
operation needs to be reliable; expect low-level platform specific code
indeed!

 

[JackC]

Thanks, basically the class in question has encryption keys and
related information stored within it that I would like to be able to
securely control when they are in memory and when they are not.

Keeping in mind im targeting multiple operating systems, is there
nothing I can easily do to keep a handle on things without getting low
level?

I basically want to prevent someone with physical access reading
unallocated memory, and figuring out the encryption key.

 

[red floyd]

Thanks, basically the class in question has encryption keys and
related information stored within it that I would like to be able to
securely control when they are in memory and when they are not.

Keeping in mind im targeting multiple operating systems, is there
nothing I can easily do to keep a handle on things without getting low
level?

I basically want to prevent someone with physical access reading
unallocated memory, and figuring out the encryption key.

Clobber the encryption keys as part of the destructor.

 

[Michael DOUBEZ]

Say i have:

secureclass *secure = new secureclass(); // has sensitive stuff in

Now i want to securely delete the instance and all the classes member
variables, I take it the 'delete' keyword will just deallocate it and
not overwrite it.

Right. The compiler won't do any necessary work if it can avoid it.

I have read that the 'volatile' keyword will guarantee that the memory
will be overwritten, my question is will it overwrite it at the point
where I call delete? (im not closing the program at the point of
securing the memory)

volatile doesn't mean that. It tells the compiler that the value may
changed concurrently with the processor execution (like for a driver or
in some multiple-core architecture). Technically, it just tells the
value should not be cached but fetched each time it is read.

If not whats the easiest (portable) way of doing this? I thought about
overwriting the memory with null bytes before deleting it, sort of
sizeof(secureclass) raw bytes being written, is that any good?

A fully secure solution is to overwrite it with random data, putting it
to null is often considered not enough for physical attack if the data
was put on swap.

Theres also the additional problem that the class could get swapped to
the disk paging file, I don't suppose theres a nice portable way of
preventing this as well?

No. This is OS specific (how would you prevent a laptop from hibernating).

Concerning your question, you might want restrict your secureclass in
heap (stack is easily accessed) and provide a custom new/delete operator
that overwrite all data upon deletion.

 

[Juha Nieminen]

Say i have:

secureclass *secure = new secureclass(); // has sensitive stuff in

Now i want to securely delete the instance and all the classes member
variables, I take it the 'delete' keyword will just deallocate it and
not overwrite it.

Is that "secureclass" written by you? Then implement a destructor for
it which overwrites all the sensitive variables with some values.

 

[James Kanze]

Right. The compiler won't do any necessary work if it can
avoid it.

But operator delete could overwrite the memory. And if the
default one doesn't, it's easy to install one that does. On the
other hand, that's probably overkill (although it's very useful
for debugging); he only has to overwrite the critical parts, not
everything that ever gets deleted.

volatile doesn't mean that. It tells the compiler that the
value may changed concurrently with the processor execution
(like for a driver or in some multiple-core architecture).
Technically, it just tells the value should not be cached but
fetched each time it is read.

Technically, it's implementation defined, and most
implementations don't even do that much.

A fully secure solution is to overwrite it with random data,
putting it to null is often considered not enough for physical
attack if the data was put on swap.

If the attacker can actually obtain the physical hard disk, you
need to overwrite the disk itself a certain number of times.
Which isn't really feasable for the swap, since you don't
control when and where the swap data will be written.
Practically speaking, security isn't possible if the attacker
has physical access to the machine.

If your only consideration is an attacker who has hacked the
machine, and can read the disk through the OS, you can typically
arrange to lock the pages with the critical data in memory (so
it never gets to disk), and overwrite it as soon as it isn't
needed, so that the attacker can't read it through /dev/kmem or
whatever. On the other hand, if an attacker has already gotten
this far, what's to stop him from installing a trojan horse
which acts like your application, but recovers the critical data
directly?

No. This is OS specific (how would you prevent a laptop from
hibernating).

Concerning your question, you might want restrict your
secureclass in heap (stack is easily accessed) and provide a
custom new/delete operator that overwrite all data upon
deletion.

Just overwriting it in the destructor should be sufficient. He
probably can't overwrite everything---things like the vptr
aren't accessible, but he should be able to overwrite all of the
critical data.

 

[red floyd]

Is that "secureclass" written by you? Then implement a destructor for
it which overwrites all the sensitive variables with some values.

I had the same comment as you, but then I thought about it some more.

There may be other copies in memory and on disk due to the use of
virtual memory. In a virtual-memory system, unless you can lock pages
in memory somehow, you cannot guarantee that you have clobbered all
copies.

So OP would have to use a system specific API to lock memory somehow,
before he stores the crypto keys, assuming such an API exists.

 

[jellybean stonerfish]

If the attacker can actually obtain the physical hard disk, you need to
overwrite the disk itself a certain number of times. Which isn't really
feasable for the swap, since you don't control when and where the swap
data will be written. Practically speaking, security isn't possible if
the attacker has physical access to the machine.

If the attacker only has remote access to the machine, the attacker can
still read the swap file, or swap partition, or any other data on the
disks.

 

[James Kanze]

If the attacker only has remote access to the machine, the
attacker can still read the swap file, or swap partition, or
any other data on the disks.

Not if it's been overwritten. Overwriting it once, even with
0's, is perfectly adequate protection against that. If the
attacker has physical access to the disk, on the other hand, and
can use special hardware to read it, you have to overwrite it a
number of times, with various patterns.

 

[Jorgen Grahn]

Your keys will get read if they are of sufficient value. All you can do
is make it hard enough that it isn't worth the trouble.

That's stating it a bit too pessimistic. Avoid having the key end up
in the swap file, and the attacker has to own the machine at the time
the key existed, instead of at any time in the future.

GnuPG is an example: on at least Linux it locks itself out of the swap
file to avoid having GPG secret keys ending up there. The way it does
this is not very portable, of course -- and IIRC it needs to run as
root to be able to do this.

/Jorgen

 

[Michael DOUBEZ]

That's stating it a bit too pessimistic.

I don't think so. That's why there are some levels of security (in
France) measured by the amount of ressource to break it that it can
resist. I don't remember very well (it was some year ago) but level 0
was resisting to an attack from a country, 1 from a multinational and so
on. Level 0 is reachable for some very small parts and a whole system
doesn't range much.

Avoid having the key end up
in the swap file, and the attacker has to own the machine at the time
the key existed, instead of at any time in the future.

A key stored in RAM can be easily recovered 10 minutes after poweroff.
Which is plenty of time if someone steals your notebook or sit at your
desk while you are in a meeting.

For data erased on a disk, it can be recovered for much longer.

GnuPG is an example: on at least Linux it locks itself out of the swap
file to avoid having GPG secret keys ending up there. The way it does
this is not very portable, of course -- and IIRC it needs to run as
root to be able to do this.

That's what Andy Champ wrote. If the key was in the swap, it would be
very easy to recover it and people would do it just for fun or when they
are bored. The only thing you can do is secure things such that it is
more trouble to break the system than not having the data it protects.

Even your keyboard is insecure:
http://lasecwww.epfl.ch/keyboard/

 

[Jorgen Grahn]

That's stating it a bit too pessimistic.

I don't think so. That's why there are some levels of security (in
France) measured by the amount of ressource to break it that it can
resist. [...]

I agree. It's just that your sentence could be (incorrectly)
interpreted as "do not bother trying".

....

GnuPG is an example: on at least Linux it locks itself out of the swap
file to avoid having GPG secret keys ending up there. The way it does
this is not very portable, of course -- and IIRC it needs to run as
root to be able to do this.

That's what Andy Champ wrote. [...]

Don't know if I read that. I just intended to give a pointer to give
the OP an example he could examine.

/Jorgen

 

[Michael Mol]

Not if it's been overwritten.  Overwriting it once, even with
0's, is perfectly adequate protection against that.  If the
attacker has physical access to the disk, on the other hand, and
can use special hardware to read it, you have to overwrite it a
number of times, with various patterns.

That's assuming that that piece of memory is going to be paged back to
disk after it's been zero'd, and that that page of memory will overlay
the same region of the swap file on the same region of the disk.
Assuming that's ensurable on the initial target system, it's still
depending on OS implementation details that may or may not remain
consistent over the lifetime of the code.

Perhaps some obfuscation is in order? Such as encrypting the key in
memory with a key derived from a variable runtime property of the
class, such as its location in the process address space? In such a
case, it might be wise to prevent stack-allocation of the class, to
reduce the predictability of the key.