Q: NTFS Encryption

  • Thread starter Thread starter G. Ralph Kuntz, MD, MS
  • Start date Start date
G

G. Ralph Kuntz, MD, MS

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?
 
Re: NTFS Encryption

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



"G. Ralph Kuntz, MD, MS" wrote in message
news:505d6fcc-0f3a-46b2-80c3-101920442467@c65g2000hsa.googlegroups.com...
> 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?
 
Re: NTFS Encryption

What's to prevent someone from reading the private key from a user's
profile and using that to decrypt the files?
 
Re: NTFS Encryption

Can YOU do it?

BTW, the protected store in the user's profile is protected in such a way
that if you reset a user's password without asking him to back up his
private key in advance, you will most likely cause him not to be able to
access his encrypted files anymore. This is by design.

--
Daniel Petri
www.petri.co.il



"G. Ralph Kuntz, MD, MS" wrote in message
news:65bafb70-a0ce-4e3c-8af3-410894e6149d@l42g2000hsc.googlegroups.com...
> What's to prevent someone from reading the private key from a user's
> profile and using that to decrypt the files?
 
Re: NTFS Encryption

Reading my previous post I saw I made some typos. Here is the correct
syntax:

"As far as I know, the private key is not the one that decrypts the
files, but instead it is the key used to protect the encryption key, which
is a totally different thing. "

--
Daniel Petri
www.petri.co.il



"Daniel Petri " wrote in message
news:eNsi7LctIHA.6096@TK2MSFTNGP06.phx.gbl...
> 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
>
>
>
> "G. Ralph Kuntz, MD, MS" wrote in message
> news:505d6fcc-0f3a-46b2-80c3-101920442467@c65g2000hsa.googlegroups.com...
>> 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?
>
>
 
Re: NTFS Encryption

I don't claim to be a Windows/NTFS expert, but I am sure there are
those people who are and would know where the information is stored.

I believe this applies thought: "Kerckhoffs' principle [...]: a
cryptosystem should be secure even if everything about the system,
except the key, is public knowledge." -- from Wikipedia.

Since DB is not forced to enter the password, or surrogate, or
whatever reveals the encrypted file key on boot, it must be on the
system somewhere, otherwise it would not be possible to read the
files.
 
Re: NTFS Encryption

Ralph, I'm not saying that it's not there. Read my previous post, I think I
was clear enough. Since you obviously need me to spell out the details, here
goes:

Private keys reside in the user profile under RootDirectory \Documents and
Settings\< username >\Application Data\Microsoft\Crypto\RSA.

All files in the RSA folder are automatically encrypted with a random,
symmetric key called the user's master key. The user's master key is
generated by the RC4 algorithm in the Base or Enhanced CSP. RC4 generates a
128-bit key for computers with the Enhanced CSP (subject to cryptography
export restrictions) and a 56-bit key for computers with only the Base CSP.

The user's master key is itself encrypted automatically by the Protected
Storage service and stored in the user profile under RootDirectory
\Documents and Settings\< username >\Application Data\Microsoft\Protect.

The user's master key is encrypted twice, and each instance of encryption is
stored in one of two parts of the Protect file. The first part, the password
encryption key, is produced by the Hash-Based Message Authentication Code
(HMAC) and SHA1 message digest function and is a hash of:

. A symmetric encryption of the user's master key produced by 160-bit
RC4.

. The user's security identifier (SID).

. The user's logon password.


The second part is the backup/restore form of the master key. This is needed
if the user's password is changed on one computer but the keys are in the
user profile on another computer, or if the administrator resets the user's
password. In either case, the Protected Storage service, which cannot detect
password changes to update Part 1, uses Part 2 to recover the master key and
regenerate Part 1.


--
Daniel Petri
www.petri.co.il



"G. Ralph Kuntz, MD, MS" wrote in message
news:d5ae841c-3a1e-4f53-941a-49d7998bcaad@2g2000hsn.googlegroups.com...
>I don't claim to be a Windows/NTFS expert, but I am sure there are
> those people who are and would know where the information is stored.
>
> I believe this applies thought: "Kerckhoffs' principle [...]: a
> cryptosystem should be secure even if everything about the system,
> except the key, is public knowledge." -- from Wikipedia.
>
> Since DB is not forced to enter the password, or surrogate, or
> whatever reveals the encrypted file key on boot, it must be on the
> system somewhere, otherwise it would not be possible to read the
> files.
 
Re: NTFS Encryption

It is possible to do this if you have access to the user's profile. There
are commercially available programs that do this. The only way I know to
prevent this is to export the key to removable media then remove it from the
profile. To decrypt a file you would then need to import the key, then
remove it again after you are finished with the file. With all encryption
schemes I've seen, the key/password/pin/token or whatever has to be
protected in some way. The more you protect it, the more inconvenient
decrypting the files becomes.

--
Kerry Brown
MS-MVP - Windows Desktop Experience: Systems Administration
http://www.vistahelp.ca/phpBB2/



"G. Ralph Kuntz, MD, MS" wrote in message
news:65bafb70-a0ce-4e3c-8af3-410894e6149d@l42g2000hsc.googlegroups.com...
> What's to prevent someone from reading the private key from a user's
> profile and using that to decrypt the files?
 
Think it might also be asked what advantage this has, and what pitfalls exist:

If the user can access the database once logged-on, so can any malware
running under the same account. Therefore, zero malware protection.

If the user leaves their computer logged-on, the database is accessible even
if the database-app wasn't left open, an interloper only neeeds to start the
program to gain access.

If something goes wrong with the userprofile you lose the lot. Backups may
not help either if it turns out they're also encrypted.

The database should be in a server share, and the share permissions set to
allow access to only authorised users. The database software should also ask
for a password to allow access, in addition to the user logon. Nothing is
perfect, but these two precautions will cover most eventualities.

"G. Ralph Kuntz, MD, MS" wrote:

> 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.
>
 
This is the scenario: I have a server with critical data on it (say
financial or medical information). Under Linux, I create an encrypted
file system and every time the machine is booted, a responsible party
enters the password. If the machine is stolen, the thief has nothing
because he/she would not know the password, and so, could not open the
encrypted file system. Not even root could this information, even with
a program to watch memory.

Under Windows, we have a different situation. Since no password is
required at boot time, the thief can use the information in the
database after booting.

Assuming the thief had enough time and resources (I don't mean NSA
resources either), the data seems like it would not be safe under
Windows NTFS. If the data were valuable enough, the thief might be
motivated.
 
Saying the the physical machine needs to be better protected is not
realistic. Doctors' offices are notoriously easy to get into and out
of without the person being challenged. Social engineering is
extremely easy in these circumstances. I could pose as a physician
(which I am) who is there on some official business. I guarantee that
I would be let in the "back" with minimal questioning.
 
"G. Ralph Kuntz, MD, MS" wrote:

> This is the scenario: I have a server with critical data on it (say
> financial or medical information). Under Linux, I create an encrypted
> file system and every time the machine is booted, a responsible party
> enters the password.

Why do you bring up Linux here? Or encrypted filesystems?
EFS encrypts per file, not per filesystem.
If you want the latter under Windows: switch to Vista and BitLocker,
or use a 3rd party product like TrueCrypt and PBA.

The problem is HOW you setup the database service: you created a
service account for it, provided the logon credentials and have them
stored with the service's configuration.

BTW: doesn't you database service provide any sort of "login" before
you can use it to retrieve data?

> Under Windows, we have a different situation. Since no password is
> required at boot time, the thief can use the information in the
> database after booting.

There's no password required at boot time because EFS encrypts files
(and due to its design), and because you stored the password for the
service account.

Stefan
 
You're describing a very specific threat scenario here: theft of a machine
and subsequent removal of its hard drive.

Immutable law #3
(http://www.microsoft.com/technet/archive/c...s/10imlaws.mspx)
of information security states that if a bad guy has physical access to your
machine, then it isn't your machine anymore.

Encryption is the only defense against such attacks. More specifically, a
implementation of encryption that is designed to protect against theft.
Windows EFS is _not_ designed for this.

Volume encryption is a much better approach, and is designed for the
scenario here. If you're running XP or Server 2003, several third-party
products can help you here. If you're running Windows Vista or Server 2008,
an included technology called BitLocker Drive Encryption will protect you
against the threat.

--
Steve Riley
steve.riley@microsoft.com
http://blogs.technet.com/steriley
http://www.protectyourwindowsnetwork.com



"G. Ralph Kuntz, MD, MS" wrote in message
news:1d9d0ea3-9336-453a-aaf4-e34171143fad@x41g2000hsb.googlegroups.com...
> This is the scenario: I have a server with critical data on it (say
> financial or medical information). Under Linux, I create an encrypted
> file system and every time the machine is booted, a responsible party
> enters the password. If the machine is stolen, the thief has nothing
> because he/she would not know the password, and so, could not open the
> encrypted file system. Not even root could this information, even with
> a program to watch memory.
>
> Under Windows, we have a different situation. Since no password is
> required at boot time, the thief can use the information in the
> database after booting.
>
> Assuming the thief had enough time and resources (I don't mean NSA
> resources either), the data seems like it would not be safe under
> Windows NTFS. If the data were valuable enough, the thief might be
> motivated.
 
The biggest problem in the doctor's office scenario that I described
is how to train the staff (and physician) that it is NOT ok to "post-
it" note the password for the encrypted file system to the machine.
They just don't get it.
 
Ralph, after all that's been said and written in this thread - could you
please tell us what "password for the encrypted file system to the machine"
are you talking about?


--
Daniel Petri
www.petri.co.il



"G. Ralph Kuntz, MD, MS" wrote in message
news:ccd50978-e5cc-40e3-a530-4d1618377ac5@x41g2000hsb.googlegroups.com...
> The biggest problem in the doctor's office scenario that I described
> is how to train the staff (and physician) that it is NOT ok to "post-
> it" note the password for the encrypted file system to the machine.
> They just don't get it.
 
Back
Top