> >> 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.
> >
> >So you think that just adding specially crafted, random reads/writes
> >will have no significant positive impact on security of "hot" disks?
>
> No I don't think so, because I tried it and were able to see straight
> through it myself. The trouble is that normal disk activity is not
> random.
>
> Randomness sticks out like a sore thumb in any sort of analysis, this
> is why plausible denial of existence of encrypted data is so hard
> that it is almost impossible when faced with a good adversary.
The main goal of the idea was not to hide the encrypted slice (which
would be indeed extremely hard), but to help obscure the locations of
GBDE's sensitive sectors. It is true that, as you said, completely
random queries to the disk can be identified and filtered out by an
expert adversary, but it will be much more of a challenge (or at least
a significant difficulty) for him when researching the disk structure
(using snapshots, traffick analysis, etc) if the following example
points are implemented:
- randomized (but not completely random) rewrites of lock sectors;
perhaps a lock sector could be rewritten intermittently when a nearby
data sector is written, so that the attacker is either fooled into
thinking that it can't be a lock sector, or will know that statistical
analysis on the disk will not yield lock sectors' locations.
- randomized (user-configurable) and out-of-sequence reads and/or
writes of key sectors so that it will be harder to figure out
zone size and offset.
These are just an oversimplified approximation of the concept.
Hmm... Suddenly the idea doesn't seem so good anymore. Likely it will
cause more PITA to the developer than to the attacker. The attacker
would still be able to gather some info about the filesystem (superblock
locations, maybe even inode locations, etc), and this even bigger threat
can be prevented only by using journalling & sectorrenaming.
> >But you do not deny that providing strong protection for "hot" disks
> >is very important? After all, user protection is only available when
> >the disk is hot.
> It is very important, but it is also a task which is very formidable
> in comparison with protecting cold disks.
When done properly and right from the start - yes, but IMO there always
will be some for improvement which may be added with time, so protection
of "hot" disks should not be ignored. Seeing that you agree to this, now
I'm not worried that GBDE is not or will be not as strong as reasonably
possible, in all modes of operation.
> (Hint: attend BSDcan2005).
3.5 thousand km one way may be a bit too long a ride for me :)
this would be at least a 10-day trip...
> >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? See, for example:
> >http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html
>
> No I did not, because there is no reliable way to counter it from
> software.
>
> There may have been once upon a time when that paper was written
> 10 years ago (although I seriously doubt the actual efficiency of
> the proposed schedules), but these days with Giant Magnetoresitive head
> technology and Partial Response Maximum Likelyhood decoding you can
> write and write and write and you will have no idea if it works or
> not. Bad sector forwarding is another issue in this area.
>
> There are commercial companies who have specialized in recovering
> deleted data from trackfringes.
Still, you could just add a few hundred rewrites with random data. This
would decrease probability that the key can be recovered, just as the
crypto techniques used in GBDE increase the safety of the data (comparing
to CGD, for instance), but never guarantee it.
Also, one may even change (if needed) the way GBDE keeps masterkey, salt,
etc in memory: avoiding keeping this data at one place in RAM for a long
time will practically ruin the hopes to recover anything useful from
deenergized RAM.
Timestamp: 0x422CABCF
[SorAlx] http://cydem.org.ua/
ridin' VN1500-B2
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
