They say that they use a "fast" AES implementation; God knows what that
means (the encryption mode maybe, or a customized, probably weaker
implementation). In any case a full cryptanalysis is most probably
impractical.
They do install a routine in the master boot record. All seems to indicate
this is some sort of encryption/decryption routine that gets the original
boot sector and other information:
"How does Free CompuSecR work?
Answer
FREE CompuSecR intercepts all reads and writes to the hard disk. Just before
information is written to the hard disk, Free CompuSecR encrypts it.
Conversely, right after any data is read from the hard disk, FREE CompuSecR
immediately decrypts it. So the process of encryption and decryption is
transparent to the user. Note that first-time encryption takes a longer time
than the subsequent encryption and decryption process."
Since this is loaded before any operating system routines it shouldn't be
too difficult to analyse. The routines apparently work at low level.
>From this piece of code in the MBR, even if you are not able to locate any
obvious weaknesses, you should be able to identify:
* How it converts a typed user ID/password to the bit string of the key
* How the program verifies the password is (in)correct (stores hash of the
correct password maybe?)
With this information it shouldn't be difficult to create a program to brute
force the password; besides, the conversion routine should give you a clear
idea of the real key length. The FAQ claims they use 128 bit AES but it
really depends on how they convert the id and password for the effective key
length, which might be much smaller.
E.g. if they do something like key= the array of bytes formed by
ID+password, then the effective key length will be much smaller, probably
half of 128 bits or less, since you would only need to try values for each
byte of the key that correspond to valid single key character (typed) codes.
On the other hand, if they take the byte string formed by ID+password and
generate an MD5 hash from it to form the key, then things get interesting
because any byte within the key byte string would be in the range 0x00 to
0xFF (effectively forcing you to search through the whole 128 bit keyspace).
The tool also claims that it encrypts everything else within the disk since
you can't encrypt partitions separately, but it wouldn't hurt to actually
confirm this manually. Good encryption algorithms produce something very
similar to random noise, therefore, if you find patterns somewhere (even
sectors with just zeroes) then this means they don't actually encrypt the
whole disk and you might still have a chance of finding some unencrypted
information.
If the harddisk is huge, it wouldn't make sense for you to sit and watch for
hours each sector through a disk editor. I would suggest you to try the
first and last sectors of the disk first and then chose some random sectors
in the middle to verify that the tool actually encrypts everything.
I hope this helps.
Regards,
Omar Herrera
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
> Is there any feasible way of analising a disk that has the whole Operating
> System encrypted,
> using Compusec?
>
> http://www.ce-infosys.com.sg/CeiNews_FreeCompuSec.asp
>
> There is no USB token only a password, unless there is a backdoor and the
> company is
> willing to facilitate it, it seems unlikely any kind of forencisc analisis
> can be
> carried out...
>
> :(
>
