|
Posted by Daniel Petri on May 14, 2008, 9:03 am
If you were Registered and logged in, you could reply and use other advanced thread options
As I understand it, there is no "DB password". The private key used to
decrypt the EFS encryption is protected and stored as part of the user's
profile. As far as I know, the private key is not the one that decrypts the
files, but instead it is the ley used to protect the encryption file, which
is a totally different thing. The encryption key is placed as an attachment
(well, sort of,) to the encrypted file, and is encrypted by the user's
public key. In some cases (domain environment, so on), that same encryption
key is stored yet again, but this time encrypted by the Recovery Agent's
public key. Only the user's private key, or the RA's private key can be used
to decrypt that field, and from it the original encryption key is extracted,
and used to decrypt the entire file.
The password you're referring to is, and correct me if I'm wrong, the one
used to start the services as a user.
--
Daniel Petri
www.petri.co.il
> Suppose someone wanted to set up a database and the DB starts as a
> service when the computer is booted. The database directories are
> encrypted using NTFS encryption.
>
> As I understand it, the secret key for the encryption is "protected"
> using the password of the account who originally encrypted the files
> (the encryption key is itself encrypted with the user's password).
>
> When the DB service is created, the user enters the DB password so
> that the serrvice can start and can decrypt its files, without the
> user having to enter the password every time the machine is rebooted.
>
> That DB password MUST be stored somewhere on the hard drive, otherwise
> the encryption key could not be recovered and the files would be
> unreadable.
>
> Now I understand that if you removed the hard drive from the original
> computer and placed it in a new computer as a secondary drive, if the
> new computer is also running Windows, you will not be able to recover
> the DB password and so will not be able to read the DB encrypted
> files.
>
> But, support you placed that drive in a Linux machine. Could you not
> find the DB password (it MUST be some place on the drive), and with
> that, decrypt the DB encryption key and get access to the encrypted
> files?
>
> Where is the flaw in my logic?
| 
XML site map