FUD about CGD and GBDE

[ALeine]

soralx at cydem.org wrote:

> > >I agree. I would also add random reads (or specially designed, combined
> > >random reads and writes) to make traffic analysis and differential attacks
> > >a real PITA for the hacker (although this idea may not be very effective
> > >against a highly motivated and determined attacker, such as some
> > > government, for instance).
> >
> > If you want to do something like this, you want to do sectorrenaming
> > and journaling since that means you can only see that something
> > was written but not what it was that was written.

Hot disk protection is something that should not to be implemented as an
afterthought, it should be a known and well understood and analyzed
requirement before any design can take place.

I believe there is no need to use journaling to obscure the write pattern
in order to better protect the lock sectors. An attacker who can regularly
copy and analyze the disk for sectors which have been written could, over
time, use that knowledge to locate the lock sectors basing the analysis on
the assumption that lock sectors are not rewritten. That is why I believe
adding such rewriting would be beneficial, but under the assumption that it
would be done carefully, meaning that one would never rewrite just the lock
sector but a much larger randomly sized block which would be picked in such
a way that the lock sector would be at a random offset inside that block.
One would also not rewrite the block if there were no disk writing taking
place within a certain sector range in order not to reveal the location of
a lock sector located on some remote part of the disk that does not get any
write activity at all. For this reason I believe that lock sector rewrites
should tag along with write operations occuring near lock sectors. If one
were to then employ this mechanism to randomly rewrite other parts of the
disk one could prevent an attacker from assuming that rewritten but unchanged
blocks contain at least one of the lock sectors. These rewrites would not
pose a threat to data integrity since the same data would be written to the
same locations, but they would cause a slight performance drop. I say slight
because the random rewrites of sectors other than lock sectors could be done
at times of low disk activity and their frequency could be set by the user.

> Speaking of user protection, how did you implement the procedure of
> erasing keys? Did you account for the properties of magnetic media
> and RAM that make data recovery possible?

You already got the short answer: no. You can find the reasoning behind
that decision in the section 4.1 of PHK's paper, but to summarize: this
approach is mainly based on the assumptions that one would need to be able
to destroy the keys quickly and that one would be able to provide positive
proof that the keys had been destroyed.

There are currently two destruction operations available:

- destroy: destroys one lock sector by blanking the following
  fields with zeros:
    - sector0: byte offset of the 1st byte used
    - sectorN: byte offset of the 1st byte not used
    - keyoffset: byte offset by which the image is skewed
    - flags
    - the master key itself

  The fields containing offsets (lsector[G_BDE_MAXKEYS]) of all the
  other lock sectors are overwritten with ones (bitwise). Everything
  else (the salt, etc.) is left intact. Only one write takes place.

- nuke: destroys all copies of the master key by completely
  overwriting all lock sectors with zeros. One write per lock
  sector takes place.

The last time I checked the gbde(8) man page appeared to be missing info
on the nuke operation. Should this be updated or will the update be done
after the changes are finalized (I see some mention of the blast operation
in the source code)?

I also believe it would be a good idea to scrub the lock sector(s) with
random garbage first and then as the last step perform the kind of
blanking described above. Perhaps there could be an option for regular
and emergency destruction. In an emergency you cannot afford to do
the random garbage rewriting, but otherwise one could choose to scrub
the lock sectors first in a series of larger randomly sized block
rewrites as described above.

ALeine
___________________________________________________________________
WebMail FREE http://mail.austrosearch.net