Q: NTFS Encryption

[Guest 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?

[Guest Daniel Petri]

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" <grk@usa.net> wrote in message

news:505d6fcc-0f3a-46b2-80c3-101920442467@c65g2000hsa.googlegroups.com...<span style="color:blue">

> 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? </span>

[Guest G. Ralph Kuntz, MD, MS]

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?

[Guest Daniel Petri]

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" <grk@usa.net> wrote in message

news:65bafb70-a0ce-4e3c-8af3-410894e6149d@l42g2000hsc.googlegroups.com...<span style="color:blue">

> What's to prevent someone from reading the private key from a user's

> profile and using that to decrypt the files? </span>

[Guest Daniel Petri]

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 <MVP>" <daniel@petri.co.il.removeme> wrote in message

news:eNsi7LctIHA.6096@TK2MSFTNGP06.phx.gbl...<span style="color:blue">

> 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" <grk@usa.net> wrote in message

> news:505d6fcc-0f3a-46b2-80c3-101920442467@c65g2000hsa.googlegroups.com...<span style="color:green">

>> 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?</span>

>

> </span>

[Guest G. Ralph Kuntz, MD, MS]

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.

[Guest Daniel Petri]

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" <grk@usa.net> wrote in message

news:d5ae841c-3a1e-4f53-941a-49d7998bcaad@2g2000hsn.googlegroups.com...<span style="color:blue">

>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. </span>

[Guest Kerry Brown]

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" <grk@usa.net> wrote in message

news:65bafb70-a0ce-4e3c-8af3-410894e6149d@l42g2000hsc.googlegroups.com...<span style="color:blue">

> What's to prevent someone from reading the private key from a user's

> profile and using that to decrypt the files? </span>

[Guest Anteaus]

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:

<span style="color:blue">

> 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.

> </span>

[Guest G. Ralph Kuntz, MD, MS]

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.

[Guest G. Ralph Kuntz, MD, MS]

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.

[Guest Stefan Kanthak]

"G. Ralph Kuntz, MD, MS" <grk@usa.net> wrote:

<span style="color:blue">

> 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.</span>

 

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?

<span style="color:blue">

> 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.</span>

 

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

[Guest Steve Riley [MSFT]]

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" <grk@usa.net> wrote in message

news:1d9d0ea3-9336-453a-aaf4-e34171143fad@x41g2000hsb.googlegroups.com...<span style="color:blue">

> 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. </span>

[Guest G. Ralph Kuntz, MD, MS]

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.

[Guest Daniel Petri]

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" <grk@usa.net> wrote in message

news:ccd50978-e5cc-40e3-a530-4d1618377ac5@x41g2000hsb.googlegroups.com...<span style="color:blue">

> 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. </span>