did you really expunge that key?

[John S. Denker]

1) This topic must be taken seriously.  A standard technique
for attacking a system is to request a bunch of memory or
disk space, leave it uninitialized, and see what you've got.

2) As regards the "volatile" keyword, I agree with Perry.
The two punchlines are:

 > if, for example, gcc did not honor [the "volatile" keyword],
 > the machine I am typing at right now would not work because
 > the device drivers would not work.

 > If they haven't implemented "volatile" right, why should
 > they implement the pragma correctly?

3) However, a discussion of compilers and keywords does not
complete the analysis.  A compiler is only part of a larger
system.  At the very least, we must pay attention to:
  -- compiler
  -- operating system
  -- hardware architecture
  -- hardware physics

At the OS and hardware-architecture levels, note that a
device driver accesses a "volatile" device register only
after beseeching the OS to map the register to a certain
address in the driver's logical address space. In contrast,
for some address that points to ordinary storage, the OS and
the hardware could (and probably do) make multiple copies:
Swap space, main memory, L2 cache, L1 cache, et cetera.
When you write to some address, you have no reason to assume
that it will "write through" all the layers.

Swap space is the extreme case: if you were swapped out
previously, there will be images of your process on the
swap device.  If you clear the copy in main memory somehow,
it is unlikely to have any effect on the images on the swap
device.  Even if you get swapped out again later (and there's
no guarantee of that), you may well get swapped out to a
different location on the swap device, so that the previous
images remain.

The analogy to device drivers is invalid unless you have
arranged to obtain a chunk of memory that is uncacheable and
unswappable.

To say the same thing in other words: a compiler can only do
so much.  It can generate instructions to be executed by the
hardware.  Whether that instruction affects the real
physical world in the way you desire is another question
entirely.

4) In the effort to prevent the just-mentioned attack, a
moderately-good operating system will expunge memory right
before giving it to a new owner.  It would be more secure
(but vastly less efficient) to expunge it right after the
previous owner is finished with it.

To see this in more detail, consider swap space again: a
piece of "used" swap space need not be expunged, unless you
are fastidious about security, because the operating system
knows that it will write there before it reads there.  Clearing
it immediately would be a waste of resources.  Leaving it
uncleared is potentially a security hole, because of the risk
that some agent unknown to the operating system will (sooner or
later) open the swap-space as a file and read everything.

5) We turn now to the hardware-physics layer.  Suppose
you really do manage to overwrite a disk file with zeros.
That does not really guarantee that the data will be
unrecoverable.  As Richard Nixon found out the hard way,
the recording head never follows exactly the same path, so
there could be little patches of magnetism just to the left
and/or just to the right of the track.  An adversary with
specialized equipment and specialized skills may be able
to recover your data.

6) To reduce the just-mentioned threat, a good strategy is
to overwrite the file with random numbers, not zeros.  Then
the adversary has a much harder time figuring out what is old
data and what is new gibberish.  (To do a really good job
requires writing your valuable data always in the middle,
and overwriting gibberish twice, once offset left and once
offset right.)

This is one of the reasons why you might need an industrial-
strength "stretched random symbol generator":
   http://www.monmouth.com/~jsd/turbid/paper/turbid.htm#sec-srandom

Note that the random-number trick can be used for main
memory (not just disks) to ensure that the compiler + OS +
hardware system doesn't optimize away a block of zeros.
This actually happened to me once: I was doing some timing
studies, and I wanted to force something out of cache by
making it too big, so I allocated a large chunk of memory
and set it to zero.  But no matter how big I made it, it fit
in cache.  The system was using the memory map to give me
unlimited copies of one small page of zeros (with the
copy-on-write bit set).

7) Terminology:  I use the word "expunge" to denote doing
whatever is necessary to utterly destroy all copies of
something.  Clearing a memory location is sometimes far
from sufficient.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com