11

I'm playing around with certificates and encryption on a Windows system, but either it isn't working or I don't know how it should works.

When I encrypt a file its name changes to green. But then, I can open it without any prompt or something. I thought "well... I'm logged with the same user that encrypted the file, let's transfer it to the phone", and so I did, and I can open the file without any problem on the phone as well.

Why?

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
The Illusive Man
  • 10,487
  • 16
  • 56
  • 88

5 Answers5

14

Windows built-in encryption is done transparently at the filesystem level. The encryption key is stored in your account profile encrypted with your login password (this is why there's the warning when you change your password). So logging in unlocks the key, which then makes your encrypted files available.

Since the encryption and decryption is done transparently by NTFS, you don't ever actually see the ciphertext. If NTFS doesn't have the decryption key, it simply won't let you read the file. You can get to the ciphertext by reading the partition data raw, but there's no real advantage to doing that. The file can only be decrypted using the key I mentioned, which you never actually see.

Windows lets you back up your encryption key, where you export the key encrypted with another chosen password. This is useful if you ever put the disk into a different computer or reinstall Windows. But not really useful otherwise.

Since the encryption is tied to the filesystem, it's not designed for sharing encrypted data. Instead, you're protecting the files where they sit against anyone else who gets their hands on your computer.

If you want to create an encrypted container for transferring files to someone else, I'd recommend a compression tool that supports strong encryption. 7-zip is a great choice.

tylerl
  • 82,225
  • 25
  • 148
  • 226
4

The encryption key is tied to your account and unlocked when you enter your account's password. As far as I know — but I'm not a Windows expert — what “unlocking” means depends on the version of Windows and whether a TPM is available, but the idea is that the encryption key cannot be retrieved without guessing your password (and, with a TPM, cannot be retrieved on a different machine even with your password).

Access to encrypted files is transparent in the operating system. When you try to read from an encrypted file, it is decrypted on the fly (and conversely encrypted when you write) by the operating system, so that applications don't need to be aware that some files are encrypted.

When you copy the file to another computer, the content of the file is copied. It would be pointless to copy the ciphertext.

You could observe the encryption by setting the file's permissions so that another account can read it, and trying to access it through the other account. You could observe the encryption by mounting the disk on another machine, or booting another operating system (e.g. a live Linux system). In these cases, the key would not be available, so you would not be able to access the data.

The security property brought by encryption is that if someone gets hold of your computer (or more precisely to your computer's disk) while you are not logged in, they won't be able to access your data (assuming they fail to guess your password).

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • You're mixing EFS and Bitlocker. Bitlocker is a full disk encryption system that can use TPM for storing the key. In any case, the bitlocker key is tied to the machine, not the user. EFS works on the file system level - NTFS - and in its standard incarnation, will tie the key to the user account. It doesn't use TPM but can use a compatible HSM (smartcard) to store the user encryption key. EFS uses the same type of certificate storage as the rest of the OS so how the key is stored depends on how the user account is setup (smartcard, local profile, AD profile, etc.) – Stephane Feb 14 '14 at 10:38
  • @Stephane Oh. Shows how much I know about Windows. I thought EFS leveraged Bitlocker since Vista or at least 7. Doesn't the TPM have a virtual smartcard interface in Windows 8? – Gilles 'SO- stop being evil' Feb 14 '14 at 13:58
  • I'm not sure what you mean by that. I'm no specialist of TPM but, AFAIK, it's a HSM that is accessible by the BIOS as well as the OS and used for disk encryption so I'm not sure how a smartcard would fit in there. You can, however, use a smartcard to store the private key for bitlocker encryption. – Stephane Feb 14 '14 at 14:09
  • I just made a test creating another account and trying to access the file, and yes, I couldn't. However, I still don't get why when I move the file to another device (physical or VM) I can open it, if the account on that system doesn't have the private key. – The Illusive Man Feb 14 '14 at 17:45
  • That is most likely because the destination file system isn't NTFS. EFS stores the actual encryption key in an alternate data stream along with the file (this key is encrypted once for each certificate allowed to unlock the file) so it really needs NTFS to work. Windows automatically decrypt the file when the target media isn't compatible with ADS. You actually get a warning about that when perform the copy. – Stephane Feb 18 '14 at 08:35
2

Some good answers here. But what might make this all simpler is to just say that the encryption is linked to the current account that you are logged into when you encrypted. Try creating a new account on that machine. (even an admin account) Log into the new account and now look at the file (in place, without moving it off the system). You can't read it now right ? In your phone example. The act of moving it off the system to a non NTFS drive will you move the unencrypted version to the phone. So of course now anyone can read it.

Menace
  • 121
  • 3
2

It is completely unintuitive. "Encrypt" implies that the files will become scrambled and a password will be required for every access, for every new application and with the implementation of timeout options. Something like logging in to your bank account with layers of security and which automatically logs you out after a while.

However this is not what happens. As others have said above the decryption key is tied to your login and used automatically when you log in, and at the system level, so that therefore as long as you are logged in, the files are as accessible as they were before, from any application and without any password prompts or timeouts. Basically if you leave your computer unlocked, or share it on the same account, they will be able to read your files.

Trying to access the folders/files from another account on the same machine is badly implemented. You cannot open and read any files but you can actually read through the directory tree and read all directory and file names. Eg "My secret bank accounts.txt" or "Secret letter to my lawer.doc". Therefore another user on the same machine will be able to see exactly what kind of items you have encrypted, by reading all the metadata associated with each file, eg is it a document, a picture, when it was created etc.

Andy Green
  • 21
  • 1
2

It's extremely useful for enterprise uses like "Roaming Profiles" where data is copied from a server to the local workstation when you log in. Every different user logging in would have their own profile directory with their own files.

The file level encryption means that even if somebody captures the disk from the machine, the contents of the profile directories of all the users who've logged on to that machine contain nothing but encrypted data.

The enterprise encryption scheme (with Active Directory) also has features like "Key Recovery" which allows management to read your files if you decide to not come back into work, or if you forget your password and need a new one set.

When you use this outside an enterprise, it's not a great system. The Windows SAM database still contains a hash of your password for logins. This is a weak point in that the password needs to be protected against offline attacks. I.e., brute forcing the SAM DB

There are ways around that by encrypting the SAM DB, but at this point, you're a lot better off using something like TrueCrypt, Bitlocker or some other whole disk encryption scheme. File level encryption is interesting in Windows, but I haven't found a use for it outside of enterprise environments.

mgjk
  • 7,535
  • 2
  • 20
  • 34