none
EFS does not appear to be an actual implementation of PKI RRS feed

  • Question

  • There is something hinky in your implementation of of PKI in EFS. With PKI the Secret/Private Key is not to be used for data encryption and no password is required to encrypt data with the Public Key; therefor without a CAC inserted, I should still be able to drop a plain text file into an EFS encrypted folder and the file should automatically be encrypted to the Public key, which should be cached in the certificate manager after first use. Your implementation requires that my CAC to be inserted and that I provide a PIN/Password to save a file or to read a file. This tells me that the programmers for EFS did not follow standard practices for implementation of Public Key Encryption. Can you explain this? 

    1. if data is encrypted with the Public key then the encrypted files should be moveable to other folders or other computers with no loss of security. For locally generated keys (hash and userpassword) it is clear that there will be no way to unlock the Private key, so those files will not be mobile. But for those who have their Private Key on a removable media (CAC) they should be.

    2. With either type of PKI Key pair I should always be able to push a plain text file into an encrypted folder and the file should become encrypted. With no CAC inserted I should not be able to read any file that is in the encrypted folder. It should show the classic PKI one way door. No password and No Private Key should required to save and encrypt a file. 

    Monday, December 21, 2015 3:30 AM

Answers

  • Hi,

    First, EFS generates a File Encryption Key (FEK). It then employs a symmetric algorithm using the FEK to encrypt the file. The algorithm used depends on the version of the operating system. Next, EFS extracts the public key from the EFS certificate contained in the user’s profile. If no such certificate is present, Windows enrolls a Basic EFS certificate from an enterprise certificate authority (CA) in the domain. EFS encrypts the FEK with the user’s public EFS key and stores it in the Data Decryption Field (DDF) in the header of the file.
    Also in the header of each encrypted file is a Data Recovery Field (DRF). The DRF contains an encrypted key created using the recovery certificate from each recovery agent. Thus, there are two separate fields in each file—the DDF and the DRF. When a user opens an encrypted file, the user’s private key decrypts the FEK in the DDF; then the FEK decrypts the file. Only the private key from the user who encrypted the file can decrypt the FEK, ensuring the file remains secure. If necessary, a recovery agent can also decrypt the file using the encrypted FEK in the DRF. So only the user who encrypted the file and any designated recovery agents can access the file.

    For more detailed information, please read this blog:

    How It Works Encrypting File System

    https://technet.microsoft.com/en-us/magazine/2006.05.howitworks.aspx


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Tuesday, December 22, 2015 5:37 AM
    Moderator

All replies

  • Hi,

    First, EFS generates a File Encryption Key (FEK). It then employs a symmetric algorithm using the FEK to encrypt the file. The algorithm used depends on the version of the operating system. Next, EFS extracts the public key from the EFS certificate contained in the user’s profile. If no such certificate is present, Windows enrolls a Basic EFS certificate from an enterprise certificate authority (CA) in the domain. EFS encrypts the FEK with the user’s public EFS key and stores it in the Data Decryption Field (DDF) in the header of the file.
    Also in the header of each encrypted file is a Data Recovery Field (DRF). The DRF contains an encrypted key created using the recovery certificate from each recovery agent. Thus, there are two separate fields in each file—the DDF and the DRF. When a user opens an encrypted file, the user’s private key decrypts the FEK in the DDF; then the FEK decrypts the file. Only the private key from the user who encrypted the file can decrypt the FEK, ensuring the file remains secure. If necessary, a recovery agent can also decrypt the file using the encrypted FEK in the DRF. So only the user who encrypted the file and any designated recovery agents can access the file.

    For more detailed information, please read this blog:

    How It Works Encrypting File System

    https://technet.microsoft.com/en-us/magazine/2006.05.howitworks.aspx


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Tuesday, December 22, 2015 5:37 AM
    Moderator
  • Hi,

    Was your issue resolved?

    If you resolved it using our solution, please "mark it as answer" to help other community members find the helpful reply quickly.

    If you resolve it using your own solution, please share your experience and solution here. It will be very beneficial for other community members who have similar questions.

    If no, please reply and tell us the current situation in order to provide further help.


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Monday, December 28, 2015 8:16 AM
    Moderator