On Feb 4, 9:41 am, John Doue <notw...@yahoo.com> wrote:
> Rod Speed wrote:
> > Vanguard <n...@mail.invalid> wrote
> >> Rod Speed <rod.speed....@gmail.com> wrote
> >>> John Doue <notw...@yahoo.com> wrote
> >>>> Vanguard wrote
> >>>>> Barry Watzman <WatzmanNOS...@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 fromhttp://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 athttp://www.pcguide.com/ref/hdd/bios/modesLBA-c.html. Then
> >> readhttp://www.pcguide.com/ref/hdd/bios/modesCaveats-c.htmlabout
> >> 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

Thanks for all the replys (and discussion)

To answer a few questions:
- the hardrive is a Seagate Momentus 7200.1
- the original laptop is an LG and uses Phoenix Bios
- the hardrive is locked using ATA Password locking and not encrypted

Any further thoughts on why the HP laptop doesn't recognise the
password are appreciated.

Prior to posting I had researched this quite a bit and have checked
most of the links for geting to the Master password and will probably
try this in due course if I can;t solve the user password issue.

Thanks again.

Jason