Rod Speed wrote:
> Vanguard <no@mail.invalid> wrote
>> Rod Speed <rod.speed.aaa@gmail.com> wrote
>>> John Doue <notwobe@yahoo.com> wrote
>>>> Vanguard wrote
>>>>> Barry Watzman <WatzmanNOSPAM@neo.rr.com> wrote
>
>>>>>> 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.
>
> No it wasnt.
>
>>>>> It is NOT solely implemented on the hard drive alone.
>
> There was no hardware encryption on the hard drive with the ATA spec.
>
>>>>> Unfortunately it costs to get copies of the ATA specs from http://www.t13.org/ and I really
>>>>> don't need them.
>
> The drafts are readily available for free and that detail didnt change.
>
>>>>>> 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.
>
> Yep, and it says absolutely NOTHING about any ATA spec encryption.
>
>> The master password, if one exists, can also be used to unlock the hard drive.
>
> Irrelevant to your pig ignorant claims about ENCRYPTION.
>
>> 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.
>
> Pity the user is welcome to change that and obviously should do so.
>
>> 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.
>
> Pity that only allows you to ERASE the drive, not access the DATA.
>
>> Drive locking protection is obviously degraded if such backdoor [master] passwords are common
>
> No it doesnt if you actually have a clue and change that master password.
>
>> and maybe that's why security-conscious users and corporations rely on whole-disk encryption
>> instead.
>
> Thats for a different reason entirely, because its actually possible to bypass
> that password protection when you have physical access to the drive.
>
>> 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.
>
> Anyone with a clue has noticed that you mangled the story completely.
>
>> 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.
>
> You dont even know that the OP is entering the password correctly.
>
>> That is, just because there is an ATA standard, it could be rather vague
>
> No it isnt.
>
>> or the BIOS makers may even deliberately tweak it so to be almost proprietary.
>
> No they dont.
>
>> As Odie alluded, drive locking may not be compatible between different BIOSes.
>
> He didnt say anything like that. The ATA standard makes it very clear how it works.
>
>> 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.
>
> VERY unlikely that it would be that pathetically implemented.
>
> Because that would defeat the whole point of the ATA security feature.
>
>> 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.
>
> Irrelevant to the ATA security feature.
>
>> It could even be that the translation geometry for LBA mode of the
>> original computer doesn't match that used in the second computer.
>
> Wrong again. You'd get a different result if that was the problem.
>
>> 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.
>
> Pity that is irrelevant when the AUTO drive type is used.
>
>> I have ran into this when moving drives between hosts really old hardware hosts to new hardware
>> hosts.
>
> Pity his isnt really old hardware.
>
>
Rod,

Those links are interesting but it would be nice to know when they were
written. They do not seem to relate to today's hard drive issues.

Regards

--
John Doue