"Rod Speed" <rod.speed.aaa@gmail.com> wrote in message
news:52kartF1nmg1sU1@mid.individual.net...
> John Doue <notwobe@yahoo.com> wrote:
>> Vanguard wrote:
>>> "Barry Watzman" <WatzmanNOSPAM@neo.rr.com> wrote in message
>>> news:45c4b406$0$9009$4c368faf@roadrunner.com...
>>>> Re: "The other half of the hash (to decode) was back in the
>>>> original
>>>> laptop. Preventing someone from getting at it, especially by
>>>> stealing the drive, is just what that security is for; i.e., unless
>>>> the drive is in the original laptop that hashed up the drive's
>>>> contents AND you know the password, you will never get at the
>>>> decoded contents of the drive."
>>>>
>>>> I don't think that's correct. This isn't windows,
>>>
>>> I don't care what OS is on the drive, encrypted or not. The
>>> whole-disk encryption is performed in hardware. Half of that
>>> support is on the hard drive, the other half is back in the mobo. If
>>> the drive wanders off from the mobo that hashed up the drive,
>>> that drive cannot be decoded. It is very similar to e-mail
>>> encryption: the source (owner of the certificate or the mobo) has
>>> the "private" portion and the target (recipient or hard drive) has
>>> the "public" portion. Without both, there's no decryption, and the
>>> source controls that.
>>>> this is an IDE
>>>
>>> Yep, as I said, this hardware encryption was first provided in ATA-3
>>> specification. It is NOT solely implemented on the hard drive
>>> alone.
>>> Unfortunately it costs to get copies of the ATA specs from
>>> http://www.t13.org/ and I really don't need them.
>>>
>>>> Otherwise, as has happened here, if the computer motherboard dies,
>>>> then the drive is lost, and that is beyond secure, it is "data
>>>> endangering".
>>>
>>> Yep, that is what happens. And that is why you MUST do data backups
>>> since they won't depend on the private key for the encryption that
>>> the mobo has. The backups can either be open in that anyone could
>>> restore from them or you would password-protect them, but that
>>> password protection is entirely within the backup file so you could
>>> use another computer running the same backup program to restore your
>>> data because the password was only used to encode the file (i.e.,
>>> there is no separation of private and public keys, there is just the
>>> one key used to encode the file).
>
>> I am curious to know what the final word is on that issue. Until
>> reading your post, I shared Barry's opinion. If you are correct, and
>> you seem to know your stuff,
>
> He doesnt, actually. Where the encryption is done is an entirely
> separate issue to whether the ATA password can be reentered
> for a drive that is moved from one system that supports ATA
> passwords to another that also does. http://www.ami.com/support/doc/AMIBI...D_Security.pdf
The user password is normally used to unlock the hard drive. The master
password, if one exists, can also be used to unlock the hard drive.
That is why I've seen some backdoor lists floating around of what some
mobo makers have been found to commonly use for a master password. The
master password is also why you can call the maker of your mobo as they
may be able to tell you what is the master password for you to unlock
the drive. Drive locking protection is obviously degraded if such
backdoor [master] passwords are common and maybe that's why
security-conscious users and corporations rely on whole-disk encryption
instead.
Ron is correct in that I was mixing hard drive locking with whole-disk
encryption. These are separate security mechanisms. From the OP's
post, perhaps just disk locking was employed and not encryption. Since
the OP gave absolutely no details on WHAT was the original computer in
which the drive was locked (and maybe encrypted, too), guesses is all
that can be profferred.
Since the OP already tried in another computer that prompted for the
password but it did not work then it sure seems that the BIOS makers can
customize how they support the drive lock feature. That is, just
because there is an ATA standard, it could be rather vague or the BIOS
makers may even deliberately tweak it so to be almost proprietary. As
Odie alluded, drive locking may not be compatible between different
BIOSes.
I'm wondering if a replacement of the PCB on the hard drive might
"repair" or unlock the drive. That is, get another exact same drive and
use its PCB on the problematic drive. Since the replacement PCB hasn't
been password enabled yet, maybe it would permit access to the drive. I
tried this once with an old drive (so getting an exact replacement was
pricey due to rarity) because a voltage regulator component blew which
rendered the drive useless (it wouldn't spin up). The replacement PCB
got the drive to spin up.
It could even be that the translation geometry for LBA mode of the
original computer doesn't match that used in the second computer. Start
at
http://www.pcguide.com/ref/hdd/bios/modesLBA-c.html. Then read
http://www.pcguide.com/ref/hdd/bios/modesCaveats-c.html about the hazard
(to data) of moving hard drives between computers, especially with
different BIOSes. I have ran into this when moving drives between hosts
really old hardware hosts to new hardware hosts.