Hard Drive Password Problems
in [Storage]
|
From: Vanguard on 4 Feb 2007 01:02 "Rod Speed" <rod.speed.aaa(a)gmail.com> wrote in message news:52kartF1nmg1sU1(a)mid.individual.net... > John Doue <notwobe(a)yahoo.com> wrote: >> Vanguard wrote: >>> "Barry Watzman" <WatzmanNOSPAM(a)neo.rr.com> wrote in message >>> news:45c4b406$0$9009$4c368faf(a)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/AMIBIOS8_HDD_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.
From: Arno Wagner on 4 Feb 2007 01:18 In comp.sys.ibm.pc.hardware.storage Odie Ferrous <odie_ferrous(a)hotmail.com> wrote: > Vanguard wrote: >> >> "Barry Watzman" <WatzmanNOSPAM(a)neo.rr.com> wrote in message >> news:45c4b406$0$9009$4c368faf(a)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. > > Vanguard, > All the drive manufacturers have their own method of enforcing password > protection at this level. > Some of them can be overcome quite easily (for instance, a typical > resurrection for Western Digital drives is to enter, as the password, > WDC repetitively for 32 characters) whereas others (most) require > hardware intervention. > We can recover / obliterate passwords for almost all drives - using > specialist equipment - but for the lucky user of a WD-type drive, it's > fairly straightforward. > The password is rarely stored on multiple media - as far as I can tell > with up-to-date information and experience. (i.e. it's never stored as a > combination of platter-based info (system area) and hardware (BIOS / ROM > / NVRAM.) So basically a HDD password is only protection angainst amateurs and even they can get it removed for a few thousand EUR/USD? Hmmm. If this were crypto, it would fall into the ''ridiculous'' security level class... Arno
From: Rod Speed on 4 Feb 2007 04:35 Vanguard <no(a)mail.invalid> wrote > Rod Speed <rod.speed.aaa(a)gmail.com> wrote >> John Doue <notwobe(a)yahoo.com> wrote >>> Vanguard wrote >>>> Barry Watzman <WatzmanNOSPAM(a)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/AMIBIOS8_HDD_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.
From: John Doue on 4 Feb 2007 04:41 Rod Speed wrote: > Vanguard <no(a)mail.invalid> wrote >> Rod Speed <rod.speed.aaa(a)gmail.com> wrote >>> John Doue <notwobe(a)yahoo.com> wrote >>>> Vanguard wrote >>>>> Barry Watzman <WatzmanNOSPAM(a)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/AMIBIOS8_HDD_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
From: JHEM on 4 Feb 2007 08:48
groupware(a)rocketmail.com wrote: > > Question 1 - Is there any way to enter a HDD passowrd via a USB/IDE > connection No, it must be connected directly to an IDE port. If your laptop has a removable media bay whereby you can remove the optical drive and replace it with a second HD adapter then the locked HD will be correctly accessed on BOOT and prompt you for the password. > Question 2 - The computer that the Hard Drive comes from uses a US > layout keyboard and the one i am trying to use it in now is a UK > layout. I use a ~ (tilde) in my password which is in a different spot > on these keyboards (although I have tried the various corresponding > key locations) but it continually rejcts my password. > > Could this cause a problem ? Yes. -- James Visit the Thinkpad Forums http://forum.thinkpads.com |