Re: Encrypting passwords stored in memory

I wrote:
> > The constant key "must
> > not" be stored as a string (too easy to find with a "strings" command).

to which Dave Howe responded:
> This appears to me to be futile, however. You are actively advocating
STO, in
> the hope that an attacker sophisticated enough to be trawling swap for
> inadvertently written keydata will be unskilled enough to be unable to
read the
> public source (or decompile from binary) and discover your hidden constant
key -
> by (worst case) patching the util to reconstruct it to write it to screen
once
> it has it.

Futile, perhaps. But STO is about all you have when the attacker has all
the binary pieces in his hands.

> Given the key is only used for data currently held in memory, surely it
would
> be better to generate it randomly (pretty low grade prng will do) and
store the
> damned thing in a different memory block to the key?

Good point. However, given that it won't be swapped to disk, that is less
relevant. Encrypting in memory is done to protect from residual impressions
that can be left in memory. Data held in SRAM for extended periods of time
leaves an impression which can be retrieved even after the power has been
turned off (ie a stolen computer) by carefully varying the voltage of the
chip's power supply. So the random key is just as vulnerable as the
constant key.

I also wrote about zeroing out byte arrays... and Dave Howe responeded:

> This should not be required. if the key is unrecognisable in memory, then
it
> is going to be fine

The intent is to minimize the time when the keys are held in memory "in the
clear" so that there will not be a retrievable impression in the memory
chips.

Regardless, it is virtually impossible to protect secrets from someone who
has physical access to the machine. All you can do is throw multiple layers
of obstacles in their way.

Alan
Received on Thu Sep 29 21:57:25 2005