The Encrypting File System (EFS) enables filesystem level transparent encryption on Microsoft Windows operating system. It was first introduced within NTFS. Folder encryption uses symmetric key which is then encrypted by a public key (asymmetric) pair. In our “SSH Public Key (/w RSA) Authentication and SSH Tunneling” post, we had briefly mentioned the hybrid cryptosystems that is driven by the usage of asymmetric and symmetric algorithms together. Now let’s check out how this hybrid process takes place in EFS;
Encryption and decryption processes for files, naturally for the weighty part of the data, are performed by a symmetric key which is more effective and efficient in this respect. This key is called File Encryption Key (FEK). FEK is encrypted by the asymmetric cryptosystem which needs more complicated mathematical calculations and for this reason which is more slower but secure one. This second encryption phrase of the hybrid process is achieved by the public key of the user performing the encryption. In reverse order, during the decryption period, the private key that matches the public key is needed.
The key pair that is used for encryption is bound to a user identity and it makes decryption available to the user who has possession of the user ID and password. As such, in practice, the protection is geared to password quality and strictness of the security policies where EFS is implemented. In accordance with its working principles, although there is a belief that this has to be accepted as a normal circumstance, it may be possible to consider it as a kind of vulnerability especially for the sensitive implementations. Because logically it would lose its importance whether the data was encrypted or not at the workstations where the intrusive physical access is gained, I believe the security being provided by EFS directly leans against the preservation of the private key itself.
For this reason, EFS started to make a sense with the opportunity of storing the private key on a smart card starting from Windows Vista. Using a smart card for storing EFS keys can prevent keeping these relevant keys on the hard disk, it increases the security level especially at middle and large scaled enterprises depending on this new feature and it makes key management simpler when it’s used within company CA infrastructure.
In this first part of the post, we’ll be analyzing the implementation of EFS independent from a company domain and a probable CA infrastructure, besides we’ll be emphasizing how it can be associated with the usage of a smart card on a Vista operating system.
Open Local Security Policy Snap-In by entering secpol.msc command in a CMD window. Select the Properties menu right clicking Encrypting File System after expanding Public Key Policies node. Enabling “Allow” below File encryption using Encrypting File System (EFS) section and enabling “Require a smart card for EFS” checkbox below Options section inside General tab menu window are two initiatory steps to enable EFS and force the usage of smart card for EFS. “Allow EFS to generate self-signed certificates when a certification authority is not available” option which is default enabled below Certificates section makes EFS generate its own certificates where we don’t fall under a domain and use an existing CA (Certification Authority) like in this exercise. A matter we have to pay attention concerning “Key size for self-signed certificates:” section is that the key size chosen here must match a size that our smart card supports.
Once EFS uses a certificate, both certificates and relevant keys are cached on the local system for performance reasons. Caching time depends on the amount that is specified in Cache timeout field inside Cache tab menu. Cache timeout will eleminate the need for asking smart card PIN code every time a user accesses the encrypted data. PIN code verification will again become mandatory upon the first access attempt to encrypted data after the expiration of time. If you enable “User locks workstation” option, PIN code will be required to access the encrypted data when you lock your workstation or restart your PC as the cache will be flushed consequently. Removing the smart card from the reader is also another physical caution in order to make sure that the cache is cleared.
It’s a very handy procedure to have any existing or newly created folders and underneath files encrypted by EFS. It is adequate to mark “Encrypt contents to secure data” checkbox at the bottom of Advanced Attributes window which you may open by using Advanced menu button that you’ll see at Attributes section beneath the folder properties.
As we have activated the usage of smart card at Local Security Policy Snap-In at previous step, we’ll be up against the following dialog screen when we try to bring in EFS via OK and then Apply buttons;
Click Create a new smart card certificate option after placing your smart card (or USB eToken device) into the reader. If you get an error message reporting “The card is being shared by another process. However, the card is not the one being requested, and cannot be used for the current operation.” such as you see below and cannot continue the operation, download and apply the appropriate patch by visiting http://support.microsoft.com/default.aspx?scid=kb;en-us;955548&sd=rss&spid=12925
If you don’t want to spend time with HotFix, it is however possible to carry on with an alternative way by using Manage your file encryption certificates menu that is located at the left side inside Control Panel -> User Accounts;
We keep going with Next after selecting Create a new certificate
When we continue with “A self-signed certificate stored on my smart card” option rule, thereupon comes the PIN code verification. When we enter the correct code, a new EFS certificate shall be installed on our smart card and subsequently we’ll encounter a new dialog screen entitled as “Update your previously encrypted files“. In this screen, we may manually pick the folders which contains encrypted files we like to associate with the new EFS certificate to have them immediately updated or we may delay this procedure with “I’ll update my encrypted files later” option.
PIN code interaction will be needed again when you mark one or more folders to request an update. You may display your new certificate by using View certificate button in the final screen where the certificate summary is seen.
After this moment, just like all the files inside folder(s) which you’ve enabled EFS via “Encrypt contents to secure data” option that we’ve mentioned above, any file you’ll subsequently move into these folder(s) shall also be automatically encrypted. You shall realise that the encryption is fulfilled through the font color of the object names which have turned into green. You may not only achieve this operation on a folder-by-folder basis but also severally on per-file basis if you wish. Consequently you will be able to define which files to be encrypted and which file to be left intact.
EFS isn’t designed to protect encrypted data while it’s transferred from its NTFS location to a different file system. For this reason, encrypted files and folders are decrypted prior to be copied to disk slices that are formatted with various file systems such as FAT32 or sent to another storage areas over the network using the SMB/CIFS protocol.
For example, while folders and whole underneath files are being transferred without loosing their encryption when you copy/paste those encrypted objects into an external USB hard disk that was again formatted as NTFS, however you are going to encounter the warning messages below that the operation will solely have to be completed without encryption when you try to move them to a USB Flash drive which was in FAT format;
Transfers will be done upon confirming these warnings. Folder and its contents will be placed on their new location after they’re decrypted.
In the second part of the post, we’ll emphasize backing up EFS certificates, creation of recovery certificates and rescue of the encrypted data in case of lost or damaged encryption keys.