Hard Drive Password Problems
in [Storage]
|
From: Vanguard on 3 Feb 2007 13:44 "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).
From: John Doue on 3 Feb 2007 14:23 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, then I would look twice before passwording a hard-drive. Regards -- John Doue
From: Rod Speed on 3 Feb 2007 15:50 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. > then I would look twice before passwording a hard-drive. That should always be done, if only because you need to be sure that you wont lose the password.
From: Odie Ferrous on 3 Feb 2007 16:32 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.) -- Retrodata www.retrodata.co.uk Globally Local Data Recovery Experts
From: Barry Watzman on 3 Feb 2007 16:32
Re: "The whole-disk encryption is performed in hardware." We are not talking about encryption at all. IDE drive passwords are not encryption. The way that this works is that on startup, the drive will one and only one command over the IDE port ... the password command. Until that command is issued, with the correct password, the drive will simply not respond to ANY other valid IDE commands, including the "identify drive" command. Thus, until the password command is issued and the drive activates itself, it's not even seen by the bios. The system will act as if there is simply no drive installed at all. It has nothing to do with encryption or keys. I think that we are talking about two different things. 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). > |