Какие типы криптосистем применяются в шифрованной файловой системе windows ef s

From Wikipedia, the free encyclopedia

From Wikipedia, the free encyclopedia

The Encrypting File System (EFS) on Microsoft Windows is a feature introduced in version 3.0 of NTFS[1] that provides filesystem-level encryption. The technology enables files to be transparently encrypted to protect confidential data from attackers with physical access to the computer.

EFS is available in all versions of Windows except the home versions (see Supported operating systems below) from Windows 2000 onwards.[2] By default, no files are encrypted, but encryption can be enabled by users on a per-file, per-directory, or per-drive basis. Some EFS settings can also be mandated via Group Policy in Windows domain environments.[3]

Cryptographic file system implementations for other operating systems are available, but the Microsoft EFS is not compatible with any of them.[4] See also the list of cryptographic file systems.

Basic ideas[edit]

When an operating system is running on a system without file encryption, access to files normally goes through OS-controlled user authentication and access control lists. However, if an attacker gains physical access to the computer, this barrier can be easily circumvented. One way, for example, would be to remove the disk and put it in another computer with an OS installed that can read the filesystem; another, would be to simply reboot the computer from a boot CD containing an OS that is suitable for accessing the local filesystem.

The most widely accepted solution to this is to store the files encrypted on the physical media (disks, USB pen drives, tapes, CDs and so on).

In the Microsoft Windows family of operating systems EFS enables this measure, although on NTFS drives only, and does so using a combination of public key cryptography and symmetric key cryptography to make decrypting the files extremely difficult without the correct key.

However, the cryptography keys for EFS are in practice protected by the user account password, and are therefore susceptible to most password attacks. In other words, the encryption of a file is only as strong as the password to unlock the decryption key.

Operation[edit]

Operation of Encrypting File System

EFS works by encrypting a file with a bulk symmetric key, also known as the File Encryption Key, or FEK. It uses a symmetric encryption algorithm because it takes less time to encrypt and decrypt large amounts of data than if an asymmetric key cipher is used. The symmetric encryption algorithm used will vary depending on the version and configuration of the operating system; see Algorithms used by Windows version below. The FEK (the symmetric key that is used to encrypt the file) is then encrypted with a public key that is associated with the user who encrypted the file, and this encrypted FEK is stored in the $EFS alternative data stream of the encrypted file.[5] To decrypt the file, the EFS component driver uses the private key that matches the EFS digital certificate (used to encrypt the file) to decrypt the symmetric key that is stored in the $EFS stream. The EFS component driver then uses the symmetric key to decrypt the file. Because the encryption & decryption operations are performed at a layer below NTFS, it is transparent to the user and all their applications.

Folders whose contents are to be encrypted by the file system are marked with an encryption attribute. The EFS component driver treats this encryption attribute in a way that is analogous to the inheritance of file permissions in NTFS: if a folder is marked for encryption, then by default all files and subfolders that are created under the folder are also encrypted. When encrypted files are moved within an NTFS volume, the files remain encrypted. However, there are a number of occasions in which the file could be decrypted without the user explicitly asking Windows to do so.

Files and folders are decrypted before being copied to a volume formatted with another file system, like FAT32. Finally, when encrypted files are copied over the network using the SMB/CIFS protocol, the files are decrypted before they are sent over the network.

The most significant way of preventing the decryption-on-copy is using backup applications that are aware of the «Raw» APIs. Backup applications that have implemented these Raw APIs will simply copy the encrypted file stream and the $EFS alternative data stream as a single file. In other words, the files are «copied» (e.g. into the backup file) in encrypted form, and are not decrypted during backup.

Starting with Windows Vista, a user’s private key can be stored on a smart card; Data Recovery Agent (DRA) keys can also be stored on a smart card.[6]

Security[edit]

Vulnerabilities[edit]

Two significant security vulnerabilities existed in Windows 2000 EFS, and have been variously targeted since.

In Windows 2000, the local administrator is the default Data Recovery Agent, capable of decrypting all files encrypted with EFS by any local user.
EFS in Windows 2000 cannot function without a recovery agent, so there is always someone who can decrypt encrypted files of the users. Any non-domain-joined Windows 2000 computer will be susceptible to unauthorized EFS decryption by anyone who can take over the local Administrator account, which is trivial given many tools available freely on the Internet.[7]

In Windows XP and later, there is no default local Data Recovery Agent and no requirement to have one. Setting SYSKEY to mode 2 or 3 (syskey typed in during bootup or stored on a floppy disk) will mitigate the risk of unauthorized decryption through the local Administrator account. This is because the local user’s password hashes, stored in the SAM file, are encrypted with the Syskey, and the Syskey value is not available to an offline attacker who does not possess the Syskey passphrase/floppy.

Accessing private key via password reset[edit]

In Windows 2000, the user’s RSA private key is not only stored in a truly encrypted form, but there is also a backup of the user’s RSA private key that is more weakly protected. If an attacker gains physical access to the Windows 2000 computer and resets a local user account’s password,[7] the attacker can log in as that user (or recovery agent) and gain access to the RSA private key which can decrypt all files. This is because the backup of the user’s RSA private key is encrypted with an LSA secret, which is accessible to any attacker who can elevate their login to LocalSystem (again, trivial given numerous tools on the Internet).

In Windows XP and beyond, the user’s RSA private key is backed up using an offline public key whose matching private key is stored in one of two places: the password reset disk (if Windows XP is not a member of a domain) or in the Active Directory (if Windows XP is a member of a domain). This means that an attacker who can authenticate to Windows XP as LocalSystem still does not have access to a decryption key stored on the PC’s hard drive.

In Windows 2000, XP or later, the user’s RSA private key is encrypted using a hash of the user’s NTLM password hash plus the user name – use of a salted hash makes it extremely difficult to reverse the process and recover the private key without knowing the user’s passphrase. Also, again, setting Syskey to mode 2 or 3 (Syskey typed in during bootup or stored on a floppy disk) will mitigate this attack, since the local user’s password hash will be stored encrypted in the SAM file.

Other issues[edit]

Once a user is logged on successfully, access to his own EFS encrypted data requires no additional authentication, decryption happens transparently. Thus, any compromise of the user’s password automatically leads to access to that data. Windows can store versions of user account passphrases with reversible encryption, though this is no longer default behaviour; it can also be configured to store (and will by default on the original version of Windows XP and lower) Lan Manager hashes of the local user account passphrases, which can be attacked and broken easily. It also stores local user account passphrases as NTLM hashes, which can be fairly easily attacked using «rainbow tables» if the passwords are weak (Windows Vista and later versions don’t allow weak passwords by default). To mitigate the threat of trivial brute-force attacks on local passphrases, older versions of Windows need to be configured (using the Security Settings portion of Group Policy) to never store LM hashes, and of course, to not enable Autologon (which stores plaintext passphrases in the registry). Further, using local user account passphrases over 14 characters long prevents Windows from storing an LM hash in the SAM – and has the added benefit of making brute-force attacks against the NTLM hash harder.

When encrypting files with EFS – when converting plaintext files to encrypted files – the plaintext files are not wiped, but simply deleted (i.e. data blocks flagged as «not in use» in the filesystem). This means that, unless they for example happen to be stored on an SSD with TRIM support, they can be easily recovered unless they are overwritten. To fully mitigate known, non-challenging technical attacks against EFS, encryption should be configured at the folder level (so that all temporary files like Word document backups which are created in these directories are also encrypted). When encrypting individual files, they should be copied to an encrypted folder or encrypted «in place», followed by securely wiping the disk volume. The Windows Cipher utility can be used (with the /W option) to wipe free space including that which still contains deleted plaintext files; various third-party utilities may work as well.[8]

Anyone who can gain Administrators access can overwrite, override or change the Data Recovery Agent configuration. This is a very serious issue, since an attacker can for example hack the Administrator account (using third-party tools), set whatever DRA certificate they want as the Data Recovery Agent and wait. This is sometimes referred to as a two-stage attack, which is a significantly different scenario than the risk due to a lost or stolen PC, but which highlights the risk due to malicious insiders.

When the user encrypts files after the first stage of such an attack, the FEKs are automatically encrypted with the designated DRA’s public key. The attacker only needs to access the computer once more as Administrator to gain full access to all those subsequently EFS-encrypted files. Even using Syskey mode 2 or 3 does not protect against this attack, because the attacker could back up the encrypted files offline, restore them elsewhere and use the DRA’s private key to decrypt the files. If such a malicious insider can gain physical access to the computer, all security features are to be considered irrelevant, because they could also install rootkits, software or even hardware keyloggers etc. on the computer – which is potentially much more interesting and effective than overwriting DRA policy.

Recovery[edit]

Files encrypted with EFS can only be decrypted by using the RSA private key(s) matching the previously used public key(s). The stored copy of the user’s private key is ultimately protected by the user’s logon password. Accessing encrypted files from outside Windows with other operating systems (Linux, for example) is not possible — not least of which because there is currently no third party EFS component driver. Further, using special tools to reset the user’s login password will render it impossible to decrypt the user’s private key and thus useless for gaining access to the user’s encrypted files. The significance of this is occasionally lost on users, resulting in data loss if a user forgets his or her password, or fails to back up the encryption key. This led to coining of the term «delayed recycle bin», to describe the seeming inevitability of data loss if an inexperienced user encrypts his or her files.

If EFS is configured to use keys issued by a Public Key Infrastructure and the PKI is configured to enable Key Archival and Recovery, encrypted files can be recovered by recovering the private key first.

Keys[edit]

  • user password (or smart card private key): used to generate a decryption key to decrypt the user’s DPAPI Master Key
  • DPAPI Master Key: used to decrypt the user’s RSA private key(s)
  • RSA private key: used to decrypt each file’s FEK
  • File Encryption Key (FEK): used to decrypt/encrypt each file’s data (in the primary NTFS stream)
  • SYSKEY: used to encrypt the cached domain verifier and the password hashes stored in the SAM

Supported operating systems[edit]

Windows[edit]

  • Windows 2000 Professional, Server, Advanced Server and Datacenter editions
  • Windows XP Professional, also in Tablet PC Edition, Media Center Edition and x64 Edition
  • Windows Server 2003 and Windows Server 2003 R2, in both x86 and x64 editions
  • Windows Vista Business, Enterprise and Ultimate editions[9]
  • Windows 7 Professional, Enterprise and Ultimate editions
  • Windows Server 2008 and Windows Server 2008 R2
  • Windows 8 and 8.1 Pro and Enterprise editions
  • Windows Server 2012 and Windows Server 2012 R2
  • Windows 10 Pro, Enterprise, and Education editions.
  • Windows 11 Pro, Enterprise, and Education editions.
  • Windows Server 2016
  • Windows Server 2019

Other operating systems[edit]

No other operating systems or file systems have native support for EFS.

New features available by Windows version[edit]

Windows XP
  • Encryption of the Client-Side Cache (Offline Files database)
  • Protection of DPAPI Master Key backup using domain-wide public key
  • Autoenrollment of user certificates (including EFS certificates)
  • Multiple-user (shared) access to encrypted files (on a file-by-file basis) and revocation checking on certificates used when sharing encrypted files
  • Encrypted files can be shown in an alternative color (green by default)
  • No requirement for mandatory Recovery Agent
  • Warning when files may be getting silently decrypted when moving to an unsupported file system
  • Password reset disk
  • EFS over WebDAV and remote encryption for servers delegated in Active Directory
Windows XP SP1
  • Support for and default use of AES-256 symmetric encryption algorithm for all EFS-encrypted files
Windows XP SP2 + KB 912761
  • Prevent enrollment of self-signed EFS certificates
Windows Server 2003
  • Digital Identity Management Service
  • Enforcement of RSAKeyLength setting for enforcing a minimum key length when enrolling self-signed EFS certificates
Windows Vista[10] and Windows Server 2008[11][12]
  • Per-user encryption of Client-Side Cache (Offline Files)
  • Support for storing (user or DRA) RSA private keys on a PC/SC smart card
  • EFS Re-Key Wizard
  • EFS Key backup prompts
  • Support for deriving DPAPI Master Key from PC/SC smart card
  • Support for encryption of pagefile.sys
  • Protection of EFS-related secrets using BitLocker (Enterprise or Ultimate edition of Windows Vista)[13][14]
  • Group Policy controls to enforce
    • Encryption of Documents folder
    • Offline files encryption
    • Indexing of encrypted files
    • Requiring smart card for EFS
    • Creating a caching-capable user key from smart card
    • Displaying a key backup notification when a user key is created or changed
    • Specifying the certificate template used for enrolling EFS certificates automatically
Windows Server 2008[12]
  • EFS self-signed certificates enrolled on the Windows Server 2008 server will default to 2048-bit RSA key length
  • All EFS templates (user and data recovery agent certificates) default to 2048-bit RSA key length
Windows 7 and Windows Server 2008 R2[15]
  • Elliptic-curve cryptographic algorithms (ECC). Windows 7 supports a mixed mode operation of ECC and RSA algorithms for backward compatibility
  • EFS self-signed certificates, when using ECC, will use 256-bit key by default.
  • EFS can be configured to use 1K/2k/4k/8k/16k-bit keys when using self-signed RSA certificates, or 256/384/521-bit keys when using ECC certificates.
Windows 10 version 1607 and Windows Server 2016
  • Add EFS support on FAT and exFAT.[16]

Algorithms used by Windows version[edit]

Windows EFS supports a range of symmetric encryption algorithms, depending on the version of Windows in use when the files are encrypted:

Operating system Default algorithm Other algorithms
Windows 2000 DESX (none)
Windows XP RTM DESX Triple DES
Windows XP SP1 AES Triple DES, DESX
Windows Server 2003 AES Triple DES, DESX[17]
Windows Vista AES Triple DES, DESX
Windows Server 2008 AES Triple DES, DESX (?)
Windows 7
Windows Server 2008 R2
Mixed (AES, SHA, and ECC) Triple DES, DESX

See also[edit]

  • BitLocker
  • Data Protection API
  • Disk encryption
  • Disk encryption software
  • eCryptfs
  • EncFS
  • Filesystem-level encryption
  • Hardware-based full disk encryption

References[edit]

  1. ^ «File Encryption (Windows)». Microsoft. Retrieved 2010-01-11.
  2. ^ EFS is available on Windows 2000 Server and Workstation, on Windows XP Professional, on Windows Server 2003 and 2008, and on Windows Vista and Windows 7 Business, Enterprise and Ultimate.
    EFS is not available on Windows XP Home Edition, nor on the Starter, Basic, and Home Premium editions of Windows Vista and Windows 7. It could not be implemented in the Windows 9x series of operating systems, since they did not natively support NTFS, which is the foundation for EFS.
  3. ^ «Encrypting File System». Microsoft. 1 May 2008. Retrieved 24 August 2011.
  4. ^ «Cryptographic Filesystems, Part One: Design and Implementation». Security Focus. Retrieved 2010-01-11.
  5. ^ «Encrypting File System».
  6. ^ Chris Corio (May 2006). «First Look: New Security Features in Windows Vista». TechNet Magazine. Microsoft. Archived from the original on 2006-11-10. Retrieved 2006-11-06.
  7. ^ a b ntpasswd, available since 1997 Archived February 12, 2016, at the Wayback Machine
  8. ^ «The Encrypting File System». technet.microsoft.com.
  9. ^ «Windows — Official Site for Microsoft Windows 10 Home & Pro OS, laptops, PCs, tablets & more». www.microsoft.com. Archived from the original on 2007-02-03. Retrieved 2008-01-20.
  10. ^ Kim Mikkelsen (2006-09-05). «Windows Vista Session 31: Rights Management Services and Encrypting File System» (PDF). presentation. Microsoft. Retrieved 2007-10-02.[dead link]
  11. ^ «Encrypting File System». documentation. Microsoft. 2007-04-30. Archived from the original on 2014-01-20. Retrieved 2007-11-06.
  12. ^ a b «Changes in Functionality from Windows Server 2003 with SP1 to Windows Server 2008: Encrypting File System». documentation. Microsoft. 2007-09-01. Archived from the original on 2008-03-25. Retrieved 2007-11-06.
  13. ^ Scott Field (June 2006). «Microsoft Windows Vista Security Enhancements» (DOC). whitepaper. Microsoft. Retrieved 2007-06-14.
  14. ^ Microsoft Corporation (2006-11-30). «Data Communication Protocol». patent. Microsoft. Retrieved 2007-06-14.
  15. ^ «Changes in EFS». Microsoft TechNet. Retrieved 2009-05-02.
  16. ^ «[MS-FSCC]: Appendix B: Product Behavior». Microsoft. 2017-09-15. Retrieved 2017-10-02. Support for FAT and EXFAT was added in Windows 10 v1607 operating system and Windows Server 2016 and subsequent.
  17. ^ Muller, Randy (May 2006). «How IT Works: Encrypting File System». TechNet Magazine. Microsoft. Retrieved 2009-05-22.

Further reading[edit]

  • «Implementing the Encrypting File System in Windows 2000». Windows 2000 Evaluated Configuration Administrators Guide. Microsoft. Retrieved 20 December 2014.
  • Bragg, Roberta. «The Encrypting File System». TechNet. Microsoft.
  • «Encrypting File System (Windows Server 2008, Windows Vista)». TechNet. Microsoft. February 25, 2009.
  • «Encrypting File System in Windows XP and Windows Server 2003». TechNet. Microsoft. April 11, 2003.
  • Network Associates Laboratories. «How to Use the Encrypting File System (Windows Server 2003, Windows XP Professional)». MSDN. Microsoft.
  • «Using Encrypting File System». Windows XP Resource Kit. Microsoft. November 3, 2005.
  • «Encrypting File System». Windows 2000 Resource Kit. Microsoft.
  • «How EFS Works». Windows 2000 Resource Kit. Microsoft.

From Wikipedia, the free encyclopedia

The Encrypting File System (EFS) on Microsoft Windows is a feature introduced in version 3.0 of NTFS[1] that provides filesystem-level encryption. The technology enables files to be transparently encrypted to protect confidential data from attackers with physical access to the computer.

EFS is available in all versions of Windows except the home versions (see Supported operating systems below) from Windows 2000 onwards.[2] By default, no files are encrypted, but encryption can be enabled by users on a per-file, per-directory, or per-drive basis. Some EFS settings can also be mandated via Group Policy in Windows domain environments.[3]

Cryptographic file system implementations for other operating systems are available, but the Microsoft EFS is not compatible with any of them.[4] See also the list of cryptographic file systems.

Basic ideas[edit]

When an operating system is running on a system without file encryption, access to files normally goes through OS-controlled user authentication and access control lists. However, if an attacker gains physical access to the computer, this barrier can be easily circumvented. One way, for example, would be to remove the disk and put it in another computer with an OS installed that can read the filesystem; another, would be to simply reboot the computer from a boot CD containing an OS that is suitable for accessing the local filesystem.

The most widely accepted solution to this is to store the files encrypted on the physical media (disks, USB pen drives, tapes, CDs and so on).

In the Microsoft Windows family of operating systems EFS enables this measure, although on NTFS drives only, and does so using a combination of public key cryptography and symmetric key cryptography to make decrypting the files extremely difficult without the correct key.

However, the cryptography keys for EFS are in practice protected by the user account password, and are therefore susceptible to most password attacks. In other words, the encryption of a file is only as strong as the password to unlock the decryption key.

Operation[edit]

Operation of Encrypting File System

EFS works by encrypting a file with a bulk symmetric key, also known as the File Encryption Key, or FEK. It uses a symmetric encryption algorithm because it takes less time to encrypt and decrypt large amounts of data than if an asymmetric key cipher is used. The symmetric encryption algorithm used will vary depending on the version and configuration of the operating system; see Algorithms used by Windows version below. The FEK (the symmetric key that is used to encrypt the file) is then encrypted with a public key that is associated with the user who encrypted the file, and this encrypted FEK is stored in the $EFS alternative data stream of the encrypted file.[5] To decrypt the file, the EFS component driver uses the private key that matches the EFS digital certificate (used to encrypt the file) to decrypt the symmetric key that is stored in the $EFS stream. The EFS component driver then uses the symmetric key to decrypt the file. Because the encryption & decryption operations are performed at a layer below NTFS, it is transparent to the user and all their applications.

Folders whose contents are to be encrypted by the file system are marked with an encryption attribute. The EFS component driver treats this encryption attribute in a way that is analogous to the inheritance of file permissions in NTFS: if a folder is marked for encryption, then by default all files and subfolders that are created under the folder are also encrypted. When encrypted files are moved within an NTFS volume, the files remain encrypted. However, there are a number of occasions in which the file could be decrypted without the user explicitly asking Windows to do so.

Files and folders are decrypted before being copied to a volume formatted with another file system, like FAT32. Finally, when encrypted files are copied over the network using the SMB/CIFS protocol, the files are decrypted before they are sent over the network.

The most significant way of preventing the decryption-on-copy is using backup applications that are aware of the «Raw» APIs. Backup applications that have implemented these Raw APIs will simply copy the encrypted file stream and the $EFS alternative data stream as a single file. In other words, the files are «copied» (e.g. into the backup file) in encrypted form, and are not decrypted during backup.

Starting with Windows Vista, a user’s private key can be stored on a smart card; Data Recovery Agent (DRA) keys can also be stored on a smart card.[6]

Security[edit]

Vulnerabilities[edit]

Two significant security vulnerabilities existed in Windows 2000 EFS, and have been variously targeted since.

In Windows 2000, the local administrator is the default Data Recovery Agent, capable of decrypting all files encrypted with EFS by any local user.
EFS in Windows 2000 cannot function without a recovery agent, so there is always someone who can decrypt encrypted files of the users. Any non-domain-joined Windows 2000 computer will be susceptible to unauthorized EFS decryption by anyone who can take over the local Administrator account, which is trivial given many tools available freely on the Internet.[7]

In Windows XP and later, there is no default local Data Recovery Agent and no requirement to have one. Setting SYSKEY to mode 2 or 3 (syskey typed in during bootup or stored on a floppy disk) will mitigate the risk of unauthorized decryption through the local Administrator account. This is because the local user’s password hashes, stored in the SAM file, are encrypted with the Syskey, and the Syskey value is not available to an offline attacker who does not possess the Syskey passphrase/floppy.

Accessing private key via password reset[edit]

In Windows 2000, the user’s RSA private key is not only stored in a truly encrypted form, but there is also a backup of the user’s RSA private key that is more weakly protected. If an attacker gains physical access to the Windows 2000 computer and resets a local user account’s password,[7] the attacker can log in as that user (or recovery agent) and gain access to the RSA private key which can decrypt all files. This is because the backup of the user’s RSA private key is encrypted with an LSA secret, which is accessible to any attacker who can elevate their login to LocalSystem (again, trivial given numerous tools on the Internet).

In Windows XP and beyond, the user’s RSA private key is backed up using an offline public key whose matching private key is stored in one of two places: the password reset disk (if Windows XP is not a member of a domain) or in the Active Directory (if Windows XP is a member of a domain). This means that an attacker who can authenticate to Windows XP as LocalSystem still does not have access to a decryption key stored on the PC’s hard drive.

In Windows 2000, XP or later, the user’s RSA private key is encrypted using a hash of the user’s NTLM password hash plus the user name – use of a salted hash makes it extremely difficult to reverse the process and recover the private key without knowing the user’s passphrase. Also, again, setting Syskey to mode 2 or 3 (Syskey typed in during bootup or stored on a floppy disk) will mitigate this attack, since the local user’s password hash will be stored encrypted in the SAM file.

Other issues[edit]

Once a user is logged on successfully, access to his own EFS encrypted data requires no additional authentication, decryption happens transparently. Thus, any compromise of the user’s password automatically leads to access to that data. Windows can store versions of user account passphrases with reversible encryption, though this is no longer default behaviour; it can also be configured to store (and will by default on the original version of Windows XP and lower) Lan Manager hashes of the local user account passphrases, which can be attacked and broken easily. It also stores local user account passphrases as NTLM hashes, which can be fairly easily attacked using «rainbow tables» if the passwords are weak (Windows Vista and later versions don’t allow weak passwords by default). To mitigate the threat of trivial brute-force attacks on local passphrases, older versions of Windows need to be configured (using the Security Settings portion of Group Policy) to never store LM hashes, and of course, to not enable Autologon (which stores plaintext passphrases in the registry). Further, using local user account passphrases over 14 characters long prevents Windows from storing an LM hash in the SAM – and has the added benefit of making brute-force attacks against the NTLM hash harder.

When encrypting files with EFS – when converting plaintext files to encrypted files – the plaintext files are not wiped, but simply deleted (i.e. data blocks flagged as «not in use» in the filesystem). This means that, unless they for example happen to be stored on an SSD with TRIM support, they can be easily recovered unless they are overwritten. To fully mitigate known, non-challenging technical attacks against EFS, encryption should be configured at the folder level (so that all temporary files like Word document backups which are created in these directories are also encrypted). When encrypting individual files, they should be copied to an encrypted folder or encrypted «in place», followed by securely wiping the disk volume. The Windows Cipher utility can be used (with the /W option) to wipe free space including that which still contains deleted plaintext files; various third-party utilities may work as well.[8]

Anyone who can gain Administrators access can overwrite, override or change the Data Recovery Agent configuration. This is a very serious issue, since an attacker can for example hack the Administrator account (using third-party tools), set whatever DRA certificate they want as the Data Recovery Agent and wait. This is sometimes referred to as a two-stage attack, which is a significantly different scenario than the risk due to a lost or stolen PC, but which highlights the risk due to malicious insiders.

When the user encrypts files after the first stage of such an attack, the FEKs are automatically encrypted with the designated DRA’s public key. The attacker only needs to access the computer once more as Administrator to gain full access to all those subsequently EFS-encrypted files. Even using Syskey mode 2 or 3 does not protect against this attack, because the attacker could back up the encrypted files offline, restore them elsewhere and use the DRA’s private key to decrypt the files. If such a malicious insider can gain physical access to the computer, all security features are to be considered irrelevant, because they could also install rootkits, software or even hardware keyloggers etc. on the computer – which is potentially much more interesting and effective than overwriting DRA policy.

Recovery[edit]

Files encrypted with EFS can only be decrypted by using the RSA private key(s) matching the previously used public key(s). The stored copy of the user’s private key is ultimately protected by the user’s logon password. Accessing encrypted files from outside Windows with other operating systems (Linux, for example) is not possible — not least of which because there is currently no third party EFS component driver. Further, using special tools to reset the user’s login password will render it impossible to decrypt the user’s private key and thus useless for gaining access to the user’s encrypted files. The significance of this is occasionally lost on users, resulting in data loss if a user forgets his or her password, or fails to back up the encryption key. This led to coining of the term «delayed recycle bin», to describe the seeming inevitability of data loss if an inexperienced user encrypts his or her files.

If EFS is configured to use keys issued by a Public Key Infrastructure and the PKI is configured to enable Key Archival and Recovery, encrypted files can be recovered by recovering the private key first.

Keys[edit]

  • user password (or smart card private key): used to generate a decryption key to decrypt the user’s DPAPI Master Key
  • DPAPI Master Key: used to decrypt the user’s RSA private key(s)
  • RSA private key: used to decrypt each file’s FEK
  • File Encryption Key (FEK): used to decrypt/encrypt each file’s data (in the primary NTFS stream)
  • SYSKEY: used to encrypt the cached domain verifier and the password hashes stored in the SAM

Supported operating systems[edit]

Windows[edit]

  • Windows 2000 Professional, Server, Advanced Server and Datacenter editions
  • Windows XP Professional, also in Tablet PC Edition, Media Center Edition and x64 Edition
  • Windows Server 2003 and Windows Server 2003 R2, in both x86 and x64 editions
  • Windows Vista Business, Enterprise and Ultimate editions[9]
  • Windows 7 Professional, Enterprise and Ultimate editions
  • Windows Server 2008 and Windows Server 2008 R2
  • Windows 8 and 8.1 Pro and Enterprise editions
  • Windows Server 2012 and Windows Server 2012 R2
  • Windows 10 Pro, Enterprise, and Education editions.
  • Windows 11 Pro, Enterprise, and Education editions.
  • Windows Server 2016
  • Windows Server 2019

Other operating systems[edit]

No other operating systems or file systems have native support for EFS.

New features available by Windows version[edit]

Windows XP
  • Encryption of the Client-Side Cache (Offline Files database)
  • Protection of DPAPI Master Key backup using domain-wide public key
  • Autoenrollment of user certificates (including EFS certificates)
  • Multiple-user (shared) access to encrypted files (on a file-by-file basis) and revocation checking on certificates used when sharing encrypted files
  • Encrypted files can be shown in an alternative color (green by default)
  • No requirement for mandatory Recovery Agent
  • Warning when files may be getting silently decrypted when moving to an unsupported file system
  • Password reset disk
  • EFS over WebDAV and remote encryption for servers delegated in Active Directory
Windows XP SP1
  • Support for and default use of AES-256 symmetric encryption algorithm for all EFS-encrypted files
Windows XP SP2 + KB 912761
  • Prevent enrollment of self-signed EFS certificates
Windows Server 2003
  • Digital Identity Management Service
  • Enforcement of RSAKeyLength setting for enforcing a minimum key length when enrolling self-signed EFS certificates
Windows Vista[10] and Windows Server 2008[11][12]
  • Per-user encryption of Client-Side Cache (Offline Files)
  • Support for storing (user or DRA) RSA private keys on a PC/SC smart card
  • EFS Re-Key Wizard
  • EFS Key backup prompts
  • Support for deriving DPAPI Master Key from PC/SC smart card
  • Support for encryption of pagefile.sys
  • Protection of EFS-related secrets using BitLocker (Enterprise or Ultimate edition of Windows Vista)[13][14]
  • Group Policy controls to enforce
    • Encryption of Documents folder
    • Offline files encryption
    • Indexing of encrypted files
    • Requiring smart card for EFS
    • Creating a caching-capable user key from smart card
    • Displaying a key backup notification when a user key is created or changed
    • Specifying the certificate template used for enrolling EFS certificates automatically
Windows Server 2008[12]
  • EFS self-signed certificates enrolled on the Windows Server 2008 server will default to 2048-bit RSA key length
  • All EFS templates (user and data recovery agent certificates) default to 2048-bit RSA key length
Windows 7 and Windows Server 2008 R2[15]
  • Elliptic-curve cryptographic algorithms (ECC). Windows 7 supports a mixed mode operation of ECC and RSA algorithms for backward compatibility
  • EFS self-signed certificates, when using ECC, will use 256-bit key by default.
  • EFS can be configured to use 1K/2k/4k/8k/16k-bit keys when using self-signed RSA certificates, or 256/384/521-bit keys when using ECC certificates.
Windows 10 version 1607 and Windows Server 2016
  • Add EFS support on FAT and exFAT.[16]

Algorithms used by Windows version[edit]

Windows EFS supports a range of symmetric encryption algorithms, depending on the version of Windows in use when the files are encrypted:

Operating system Default algorithm Other algorithms
Windows 2000 DESX (none)
Windows XP RTM DESX Triple DES
Windows XP SP1 AES Triple DES, DESX
Windows Server 2003 AES Triple DES, DESX[17]
Windows Vista AES Triple DES, DESX
Windows Server 2008 AES Triple DES, DESX (?)
Windows 7
Windows Server 2008 R2
Mixed (AES, SHA, and ECC) Triple DES, DESX

See also[edit]

  • BitLocker
  • Data Protection API
  • Disk encryption
  • Disk encryption software
  • eCryptfs
  • EncFS
  • Filesystem-level encryption
  • Hardware-based full disk encryption

References[edit]

  1. ^ «File Encryption (Windows)». Microsoft. Retrieved 2010-01-11.
  2. ^ EFS is available on Windows 2000 Server and Workstation, on Windows XP Professional, on Windows Server 2003 and 2008, and on Windows Vista and Windows 7 Business, Enterprise and Ultimate.
    EFS is not available on Windows XP Home Edition, nor on the Starter, Basic, and Home Premium editions of Windows Vista and Windows 7. It could not be implemented in the Windows 9x series of operating systems, since they did not natively support NTFS, which is the foundation for EFS.
  3. ^ «Encrypting File System». Microsoft. 1 May 2008. Retrieved 24 August 2011.
  4. ^ «Cryptographic Filesystems, Part One: Design and Implementation». Security Focus. Retrieved 2010-01-11.
  5. ^ «Encrypting File System».
  6. ^ Chris Corio (May 2006). «First Look: New Security Features in Windows Vista». TechNet Magazine. Microsoft. Archived from the original on 2006-11-10. Retrieved 2006-11-06.
  7. ^ a b ntpasswd, available since 1997 Archived February 12, 2016, at the Wayback Machine
  8. ^ «The Encrypting File System». technet.microsoft.com.
  9. ^ «Windows — Official Site for Microsoft Windows 10 Home & Pro OS, laptops, PCs, tablets & more». www.microsoft.com. Archived from the original on 2007-02-03. Retrieved 2008-01-20.
  10. ^ Kim Mikkelsen (2006-09-05). «Windows Vista Session 31: Rights Management Services and Encrypting File System» (PDF). presentation. Microsoft. Retrieved 2007-10-02.[dead link]
  11. ^ «Encrypting File System». documentation. Microsoft. 2007-04-30. Archived from the original on 2014-01-20. Retrieved 2007-11-06.
  12. ^ a b «Changes in Functionality from Windows Server 2003 with SP1 to Windows Server 2008: Encrypting File System». documentation. Microsoft. 2007-09-01. Archived from the original on 2008-03-25. Retrieved 2007-11-06.
  13. ^ Scott Field (June 2006). «Microsoft Windows Vista Security Enhancements» (DOC). whitepaper. Microsoft. Retrieved 2007-06-14.
  14. ^ Microsoft Corporation (2006-11-30). «Data Communication Protocol». patent. Microsoft. Retrieved 2007-06-14.
  15. ^ «Changes in EFS». Microsoft TechNet. Retrieved 2009-05-02.
  16. ^ «[MS-FSCC]: Appendix B: Product Behavior». Microsoft. 2017-09-15. Retrieved 2017-10-02. Support for FAT and EXFAT was added in Windows 10 v1607 operating system and Windows Server 2016 and subsequent.
  17. ^ Muller, Randy (May 2006). «How IT Works: Encrypting File System». TechNet Magazine. Microsoft. Retrieved 2009-05-22.

Further reading[edit]

  • «Implementing the Encrypting File System in Windows 2000». Windows 2000 Evaluated Configuration Administrators Guide. Microsoft. Retrieved 20 December 2014.
  • Bragg, Roberta. «The Encrypting File System». TechNet. Microsoft.
  • «Encrypting File System (Windows Server 2008, Windows Vista)». TechNet. Microsoft. February 25, 2009.
  • «Encrypting File System in Windows XP and Windows Server 2003». TechNet. Microsoft. April 11, 2003.
  • Network Associates Laboratories. «How to Use the Encrypting File System (Windows Server 2003, Windows XP Professional)». MSDN. Microsoft.
  • «Using Encrypting File System». Windows XP Resource Kit. Microsoft. November 3, 2005.
  • «Encrypting File System». Windows 2000 Resource Kit. Microsoft.
  • «How EFS Works». Windows 2000 Resource Kit. Microsoft.

Encrypting file system

Шифрующая файловая система это тесно интегрированная с NTFS служба, располагающаяся в ядре Windows 2000. Ее назначение: защита данных, хранящихся на диске, от несанкционированного доступа путем их шифрования. Появление этой службы не случайно, и ожидалось давно. Дело в том, что существующие на сегодняшний день файловые системы не обеспечивают необходимую защиту данных от несанкционированного доступа.

Внимательный читатель может возразить мне: а как же Windows NT с ее NTFS? Ведь NTFS обеспечивает разграничение доступа и защиту данных от несанкционированного доступа! Да, это правда. Но как быть в том случае, когда доступ к разделу NTFS осуществляется не с помощью средств операционной системы Windows NT, а напрямую, на физическом уровне? Ведь это сравнительно легко реализовать, например, загрузившись с дискеты и запустив специальную программу: например, весьма распространенную ntfsdos. В качестве более изощренного примера можно указать продукт NTFS98. Конечно, можно предусмотреть такую возможность, и задать пароль на запуск системы, однако практика показывает, что такая защита малоэффективна, особенно в том случае, когда за одним компьютером работают сразу несколько пользователей. А если злоумышленник может извлечь жесткий диск из компьютера, то здесь уже не помогут никакие пароли. Подключив диск к другому компьютеру, его содержимое можно будет прочитать с такой же легкостью, что и эту статью. Таким образом, злоумышленник свободно может овладеть конфиденциальной информацией, которая хранится на жестком диске.

Единственный способ защиты от физического чтения данных это шифрование файлов. Простейший случай такого шифрования — архивирование файла с паролем. Однако здесь есть ряд серьезных недостатков. Во-первых, пользователю требуется каждый раз вручную шифровать и дешифровать (то есть, в нашем случае архивировать и разархивировать) данные перед началом и после окончания работы, что уже само по себе уменьшает защищенность данных. Пользователь может забыть зашифровать (заархивировать) файл после окончания работы, или (еще более банально) просто оставить на диске копию файла. Во-вторых, пароли, придуманные пользователем, как правило, легко угадываются. В любом случае, существует достаточное количество утилит, позволяющих распаковывать архивы, защищенные паролем. Как правило, такие утилиты осуществляют подбор пароля путем перебора слов, записанных в словаре.

Система EFS была разработана с целью преодоления этих недостатков. Ниже мы рассмотрим более подробно детали технологии шифрования, взаимодействие EFS с пользователем и способы восстановления данных, познакомимся с теорией и реализацией EFS в Windows 2000, а также рассмотрим пример шифрования каталога при помощи EFS.

Технология шифрования

EFS использует архитектуру Windows CryptoAPI. В ее основе лежит технология шифрования с открытым ключом. Для шифрования каждого файла случайным образом генерируется ключ шифрования файла. При этом для шифрования файла может применяться любой симметричный алгоритм шифрования. В настоящее же время в EFS используется один алгоритм, это DESX, являющийся специальной модификацией широко распространенного стандарта DES.

Ключи шифрования EFS хранятся в резидентном пуле памяти (сама EFS расположена в ядре Windows 2000), что исключает несанкционированный доступ к ним через файл подкачки.

Взаимодействие с пользователем

По умолчанию EFS сконфигурирована таким образом, что пользователь может сразу начать использовать шифрование файлов. Операция шифрования и обратная поддерживаются для файлов и каталогов. В том случае, если шифруется каталог, автоматически шифруются все файлы и подкаталоги этого каталога. Необходимо отметить, что если зашифрованный файл перемещается или переименовывается из зашифрованного каталога в незашифрованный, то он все равно остается зашифрованным. Операции шифрования/дешифрования можно выполнить двумя различными способами — используя Windows Explorer или консольную утилиту Cipher.

Для того чтобы зашифровать каталог из Windows Explorer, пользователю нужно просто выбрать один или несколько каталогов и установить флажок шифрования в окне расширенных свойств каталога. Все создаваемые позже файлы и подкаталоги в этом каталоге будут также зашифрованы. Таким образом, зашифровать файл можно, просто скопировав (или перенеся) его в «зашифрованный» каталог.

Зашифрованные файлы хранятся на диске в зашифрованном виде. При чтении файла данные автоматически расшифровываются, а при записи — автоматически шифруются. Пользователь может работать с зашифрованными файлами так же, как и с обычными файлами, то есть открывать и редактировать в текстовом редакторе Microsoft Word документы, редактировать рисунки в Adobe Photoshop или графическом редакторе Paint, и так далее.

Необходимо отметить, что ни в коем случае нельзя шифровать файлы, которые используются при запуске системы — в это время личный ключ пользователя, при помощи которого производится дешифровка, еще недоступен. Это может привести к невозможности запуска системы! В EFS предусмотрена простая защита от таких ситуаций: файлы с атрибутом «системный» не шифруются. Однако будьте внимательны: это может создать «дыру» в системе безопасности! Проверяйте, не установлен ли атрибут файла «системный» для того, чтобы убедиться, что файл действительно будет зашифрован.

Важно также помнить о том, что зашифрованные файлы не могут быть сжаты средствами Windows 2000 и наоборот. Иными словами, если каталог сжат, его содержимое не может быть зашифровано, а если содержимое каталога зашифровано, то он не может быть сжат.

В том случае, если потребуется дешифровка данных, необходимо просто снять флажки шифрования у выбранных каталогов в Windows Explorer, и файлы и подкаталоги автоматически будут дешифрованы. Следует отметить, что эта операция обычно не требуется, так как EFS обеспечивает «прозрачную» работу с зашифрованными данными для пользователя.

Восстановление данных

EFS обеспечивает встроенную поддержку восстановления данных на тот случай, если потребуется их расшифровать, но, по каким-либо причинам, это не может быть выполнено обычным. По умолчанию, EFS автоматически сгенерирует ключ восстановления, установит сертификат доступа в учетной записи администратора и сохранит его при первом входе в систему. Таким образом, администратор становится так называемым агентом восстановления, и сможет расшифровать любой файл в системе. Разумеется, политику восстановления данных можно изменить, и назначить в качестве агента восстановления специального человека, ответственного за безопасность данных, или даже несколько таких лиц.

Немного теории

EFS осуществляет шифрование данных, используя схему с общим ключом. Данные шифруются быстрым симметричным алгоритмом при помощи ключа шифрования файла FEK (file encryption key). FEK — это случайным образом сгенерированный ключ определенной длины. Длина ключа в североамериканской версии EFS 128 бит, в международной версии EFS используется уменьшенная длина ключа 40 или 56 бит.

FEK шифруется одним или несколькими общими ключами шифрования, в результате чего получается список зашифрованных ключей FEK. Список зашифрованных ключей FEK хранится в специальном атрибуте EFS, который называется DDF (data decryption field — поле дешифрования данных). Информация, при помощи которой производится шифрование данных, жестко связана с этим файлом. Общие ключи выделяются из пар пользовательских ключей сертификата X509 с дополнительной возможностью использования «File encryption». Личные ключи из этих пар используются при дешифровке данных и FEK. Личная часть ключей хранится либо на смарт-картах, либо в другом надежном месте (например, в памяти, безопасность которой обеспечивается при помощи CryptoAPI).

FEK также шифруется при помощи одного или нескольких ключей восстановления (полученных из сертификатов X509, записанных в политике восстановления зашифрованных данных для данного компьютера, с дополнительной возможностью «File recovery»).

Как и в предыдущем случае, общая часть ключа используется для шифрования списка FEK. Список зашифрованных ключей FEK также хранится вместе с файлом в специальной области EFS, которая называется DRF (data recovery field — поле восстановления данных). Для шифрования списка FEK в DRF используется только общая часть каждой пары ключей. Для нормального осуществления файловых операций необходимы только общие ключи восстановления. Агенты восстановления могут хранить свои личные ключи в безопасном месте вне системы (например, на смарт-картах). На рисунке приведены схемы процессов шифрования, дешифрования и восстановления данных.

Процесс шифрования

Незашифрованный файл пользователя шифруется при помощи случайно сгенерированного ключа FEK. Этот ключ записывается вместе с файлом, файл дешифруется при помощи общего ключа пользователя (записанного в DDF), а также при помощи общего ключа агента восстановления (записанного в DRF).

Процесс дешифрования

Сначала используется личный ключ пользователя для дешифрации FEK — для этого используется зашифрованная версия FEK, которая хранится в DDF. Расшифрованный FEK используется для поблочного дешифрования файла. Если в большом файле блоки считываются не последовательно, то дешифруются только считываемые блоки. Файл при этом остается зашифрованным.

Процесс восстановления

Этот процесс аналогичен дешифрованию с той разницей, что для дешифрования FEK используется личный ключ агента восстановления, а зашифрованная версия FEK берется из DRF.

Реализация в Windows 2000

На рисунке показана архитектура EFS:

EFS состоит из следующих компонентов:

Драйвер EFS

Этот компонент расположен логически на вершине NTFS. Он взаимодействует с сервисом EFS, получает ключи шифрования файлов, поля DDF, DRF и другие данные управления ключами. Драйвер передает эту информацию в FSRTL (file system runtime library, библиотека времени выполнения файловой системы) для прозрачного выполнения различных файловых системных операций (например, открытие файла, чтение, запись, добавление данных в конец файла).

Библиотека времени выполнения EFS (FSRTL)

FSRTL — это модуль внутри драйвера EFS, который осуществляет внешние вызовы NTFS для выполнения различных операций файловой системы, таких как чтение, запись, открытие зашифрованных файлов и каталогов, а также операций шифрования, дешифрования, восстановления данных при записи на диск и чтении с диска. Несмотря на то, что драйвер EFS и FSRTL реализованы в виде одного компонента, они никогда не взаимодействуют напрямую. Для обмена сообщениями между собой они используют механизм вызовов NTFS. Это гарантирует участие NTFS во всех файловых операциях. Операции, реализованные с использованием механизмов управления файлами, включают запись данных в файловые атрибуты EFS (DDF и DRF) и передачу вычисленных в EFS ключей FEK в библиотеку FSRTL, так как эти ключи должны устанавливаться в контексте открытия файла. Такой контекст открытия файла позволяет затем осуществлять незаметное шифрование и дешифрование файлов при записи и считывании файлов с диска.

Служба EFS

Служба EFS является частью подсистемы безопасности. Она использует существующий порт связи LPC между LSA (Local security authority, локальные средства защиты) и работающим в kernel-mode монитором безопасности для связи с драйвером EFS. В режиме пользователя служба EFS взаимодействует с программным интерфейсом CryptoAPI, предоставляя ключи шифрования файлов и обеспечивая генерацию DDF и DRF. Кроме этого, служба EFS осуществляет поддержку интерфейса Win32 API.

Win32 API

Обеспечивает интерфейс программирования для шифрования открытых файлов, дешифрования и восстановления закрытых файлов, приема и передачи закрытых файлов без их предварительной расшифровки. Реализован в виде стандартной системной библиотеки advapi32.dll.

Немного практики

Для того чтобы зашифровать файл или каталог, выполните следующие операции:

  1. Запустите Windows Explorer, нажмите правую кнопку мыши на каталоге, выберите пункт Properties (Свойства).
  2. На закладке General (Общие) нажмите кнопку Advanced.

  1. Отметьте галочкой пункт «Encrypt contents to secure data». Нажмите OK, затем нажмите Apply (применить) в диалоге Properties. Если Вы выбрали шифрование отдельного файла, то дополнительно появится диалоговое окно следующего вида:

Система предлагает зашифровать также и каталог, в котором находится выбранный файл, так как в противном случае шифрование будет автоматически отменено при первой модификации такого файла. Всегда имейте это в виду, когда шифруете отдельные файлы!

На этом процесс шифрования данных можно считать законченным.

Чтобы расшифровать каталоги, просто снимите выделение в пункте «Encrypt contents to secure data». При этом каталоги, а также все содержащиеся в них подкаталоги и файлы будут расшифрованы.

Выводы

  • Система EFS в Windows 2000 предоставляет пользователям возможность зашифровывать каталоги NTFS, используя устойчивую, основанную на общих ключах криптографическую схему, при этом все файлы в закрытых каталогах будут зашифрованы. Шифрование отдельных файлов поддерживается, но не рекомендуется из-за непредсказуемого поведения приложений.
  • Система EFS также поддерживает шифрование удаленных файлов, доступ к которым осуществляется как к совместно используемым ресурсам. Если имеют место пользовательские профили для подключения, используются ключи и сертификаты удаленных профилей. В других случаях генерируются локальные профили и используются локальные ключи.
  • Система EFS предоставляет установить политику восстановления данных таким образом, что зашифрованные данные могут быть восстановлены при помощи EFS, если это потребуется.
  • Политика восстановления данных встроена в общую политику безопасности Windows 2000. Контроль за соблюдением политики восстановления может быть делегирован уполномоченным на это лицам. Для каждого подразделения организации может быть сконфигурирована своя политика восстановления данных.
  • Восстановление данных в EFS — закрытая операция. В процессе восстановления расшифровываются данные, но не ключ пользователя, при помощи которого эти данные были зашифрованы.
  • Работа с зашифрованными файлами в EFS не требует от пользователя каких-либо специальных действий по шифрованию и дешифрованию данных. Дешифрование и шифрование происходят незаметно для пользователя в процессе считывания и записи данных на диск.
  • Система EFS поддерживает резервное копирование и восстановление зашифрованных файлов без их расшифровки. Программа NtBackup поддерживает резервное копирование зашифрованных файлов.
  • Система EFS встроена в операционную систему таким образом, что утечка информации через файлы подкачки невозможна, при этом гарантируется, что все создаваемые копии будут зашифрованы
  • Предусмотрены многочисленные меры предосторожности для обеспечения безопасности восстановления данных, а также защита от утечки и потери данных в случае фатальных сбоев системы.

Encrypting
File
System

Шифрующая
файловая система — это тесно интегрированная
с NTFS
служба, располагающаяся в ядре Windows
2000. Ее назначение: защита данных,
хранящихся на диске, от несанкционированного
доступа путем их шифрования. Появление
этой службы не случайно и ожидалось
давно. дело в том, что существующие на
сегодняшний день файловые системы не
обеспечивают необходимую защиту данных
от несанкционированного доступа.

Хотя
и NTFS
обеспечивает разграничение доступа и
защиту данных от несанкционированного
доступа, но как быть в том случае, когда
доступ к разделу NTFS
осуществляется не с помощью средств
операционной системы Windows
NТ,
а напрямую, на физическом уровне? Ведь
это сравнительно легко реализовать,
например, загрузившись с дискеты и
запустив специальную программу: например,
весьма распространенную Конечно, можно
предусмотреть такую возможность, и
задать пароль на запуск системы, однако
практика показывает, что такая защита
малоэффективна, особенно в том случае,
когда за одним компьютером работают
сразу несколько пользователей. А если
злоумышленник может извлечь жесткий
диск из компьютера, то здесь уже не
помогут никакие пароли. Подключив диск
к другому компьютеру, его содержимое
можно будет прочитать без особых проблем.
Таким образом, злоумышленник свободно
может овладеть конфиденциальной
информацией, которая хранится на жестком
диске. Единственный способ защиты от
физического чтения данных — это
шифрование файлов. Простейший случай
такого шифрования — архивирование
файла с паролем. Однако здесь есть ряд
серьезных недостатков. Во-первых,
пользователю требуется каждый раз
вручную шифровать и дешифровать (то
есть, в нашем случае архивировать и
разархивировать) данные перед началом
и после окончания работы, что уже само
по себе уменьшает защищенность данных.
Пользователь может забыть зашифровать
(заархивировать) файл после окончания
работы или (еще более банально) просто
оставить на диске копию файла. Во-вторых,
пароли, придуманные пользователем, как
правило, легко угадываются. В любом
случае, существует достаточное количество
утилит, позволяющих распаковывать
архивы, защищенные паролем. Как правило,
такие утилиты осуществляют подбор
пароля путем перебора слов, записанных
в словаре. Система EFS
была разработана с целью преодоления
этих недостатков.

2.1. Технология шифрования

ЕР$
использует архитектуру Windows
CryptoAPI.
В ее осноне лежит технология шифрования
с открытым ключом, для шифрования каждого
файла случайным образом генерируется
ключ шифрования файла. При этом для
шифрования файла может применяться
любой симметричный алгоритм шифрования.
В настоящее же время в EFS
используется один алгоритм — это DESX,
являющийся специальной модификацией
широко распространенного стандарта
DES.
Ключи шифрования EFS
хранятся в резидентном пуле памяти
(сама EFS
расположена в ядре Windows
2000), что исключает несанкционированный
доступ к ним через файл подкачки.

По
умолчанию EFS
сконфигурирована таким образом, что
пользователь может сразу начать
использовать шифрование файлов. Операция
шифрования и обратная поддерживаются
для файлов и каталогов. В том случае,
если шифруется каталог, автоматически
шифруются все файлы и подкаталоги этого
каталога. Необходимо отметить, что если
зашифрованный файл перемещается или
переименовывается из зашифрованного
каталога в незашифрованный, то он все
равно остается зашифрованным. Операции
шифрования/дешифрования можно выполнить
двумя различными способами — используя
Windows
Explorer
или консольную утилиту Cipher.
для того чтобы зашифровать каталог из
Windows
Explorer,
пользователю нужно просто выбрать один
или несколько каталогов и установить
флажок шифрования в окне расширенных
свойств каталога. Все создаваемые позже
файлы и подкаталоги в этом каталоге
будут также зашифрованы. Таким образом,
зашифровать файл можно, просто скопировав
(или перенеся) его в «зашифрованный»
каталог. Зашифрованные файлы хранятся
на диске в зашифрованном виде. При чтении
файла данные автоматически расшифровываются,
а при записи автоматически шифруются.
Пользователь может работать с
зашифрованными файлами так же, как и с
обычными файлами, то есть открывать и
редактировать в текстовом редакторе
Microsoft
Word
документы, редактировать рисунки в
Adobe
Photoshop
или графическом редакторе Paint,
и так далее.

Необходимо
отметить, что ни в коем случае нельзя
шифровать файлы, которые используются
при запуске системы в это время личный
ключ пользователя, при помощи которого
производится дешифровка, еще недоступен.
Это может привести к невозможности
запуска системы! B
EFS
предусмотрена простая защита от таких
ситуаций: файлы с атрибутом «системный»
не шифруются. Однако будьте внимательны:
это может создать «дыру» в системе
безопасности! Проверяйте, не установлен
ли атрибут файла <системный» для того,
чтобы убедиться, что файл действительно
будет зашифрован.

Важно
также помнить о том, что зашифрованные
файлы не могут быть сжаты средствами
Windows
2000 и наоборот. Иными словами, если каталог
сжат, его содержимое не может быть
зашифровано, а если содержимое каталога
зашифровано, то он не может быть сжат.

В
том случае, если потребуется дешифровка
данных, необходимо просто снять флажки
шифрования у выбранных каталогов в
Windows
Explorer,
и файлы и подкаталоги автоматически
будут дешифрованы. Следует отметить,
что эта операция обычно не требуется,
так как EFS
обеспечивает «прозрачную» работу с
зашифрованными данными для пользователя.

Соседние файлы в папке ПАЗИ 622231

  • #
  • #
  • #
  • #
  • #

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 22:34, 25 июня 2016.

EFS (англ. Encrypting File System — Шифрованная файловая система) — это компонент Windows, позволяющий сохранять сведения на жестком диске в зашифрованном формате. Шифрование — это самая сильная защита, которую предоставляет Windows для защиты данных[1].

Содержание

  • 1 Общее
  • 2 Описание работы
  • 3 Технология шифрования
  • 4 Теория
  • 5 Процесс шифрования
  • 6 Процесс дешифрования
  • 7 Примечания
  • 8 Ссылки

Общее

Файловая система EFS интегрирована в NTFS, отличается простотой управления и стойкостью к атакам. Пользователи могут выбирать файлы, которые требуется зашифровать, но расшифровывать файлы вручную перед использованием не требуется – можно просто открыть файл и изменить его, как обычно.
Зашифрованные файлы будут защищены даже в том случае, если злоумышленник получит физический доступ к компьютеру. Кроме того, даже пользователи, имеющие право на доступ к компьютеру (например, администраторы), не имеют доступа к файлам, зашифрованным с помощью файловой системы EFS другими пользователями. Тем не менее файловая система EFS поддерживает назначенные агенты восстановления. При их правильной настройке можно гарантировать восстановление данных при необходимости.

Некоторые ключевые свойства EFS:

  • Шифрование — простое действие; для его включения достаточно установить флажок в свойствах файла или папки.
  • Можно указать, кому именно разрешается читать эти файлы.
  • Файлы шифруются, когда они закрываются, но при открытии они автоматически готовы к использованию.
  • Если шифровать файл больше нет необходимости, снимите флажок в свойствах файла.

Описание работы

EFS работает, шифруя каждый файл с помощью алгоритма симметричного шифрования, зависящего от версии операционной системы и настроек (начиная с Windows XP доступна теоретическая возможность использования сторонних библиотек для шифрования данных). При этом используется случайно сгенерированный ключ для каждого файла, называемый File Encryption Key (FEK), выбор симметричного шифрования на данном этапе объясняется его скоростью по отношению к асимметричному шифрованию.

FEK (случайный для каждого файла ключ симметричного шифрования) защищается путём асимметричного шифрования, использующего открытый ключ пользователя, шифрующего файл, и алгоритм RSA (теоретически возможно использование других алгоритмов асимметричного шифрования). Зашифрованный таким образом ключ FEK сохраняется в альтернативном потоке $EFS файловой системы NTFS. Для расшифрования данных драйвер шифрованной файловой системы прозрачно для пользователя расшифровывает FEK, используя закрытый ключ пользователя, а затем и необходимый файл с помощью расшифрованного файлового ключа.

Поскольку шифрование/расшифрование файлов происходит с помощью драйвера файловой системы (по сути, надстройки над NTFS), оно происходит прозрачно для пользователя и приложений. Стоит заметить, что EFS не шифрует файлы, передаваемые по сети, поэтому для защиты передаваемых данных необходимо использовать другие протоколы защиты данных (IPSec или WebDAV).

Технология шифрования

EFS использует архитектуру Windows CryptoAPI. В ее основе лежит технология шифрования с открытым ключом. Для шифрования каждого файла случайным образом генерируется ключ шифрования файла. При этом для шифрования файла может применяться любой симметричный алгоритм шифрования. В настоящее же время в EFS используется один алгоритм, это DESX, являющийся специальной модификацией широко распространенного стандарта DES. Ключи шифрования EFS хранятся в резидентном пуле памяти (сама EFS расположена в ядре Windows 2000), что исключает несанкционированный доступ к ним через файл подкачки.

Теория

EFS осуществляет шифрование данных, используя схему с общим ключом. Данные шифруются быстрым симметричным алгоритмом при помощи ключа шифрования файла FEK (file encryption key). FEK — это случайным образом сгенерированный ключ определенной длины. Длина ключа в североамериканской версии EFS 128 бит, в международной версии EFS используется уменьшенная длина ключа 40 или 56 бит.

FEK шифруется одним или несколькими общими ключами шифрования, в результате чего получается список зашифрованных ключей FEK. Список зашифрованных ключей FEK хранится в специальном атрибуте EFS, который называется DDF (data decryption field — поле дешифрования данных). Информация, при помощи которой производится шифрование данных, жестко связана с этим файлом. Общие ключи выделяются из пар пользовательских ключей сертификата X509 с дополнительной возможностью использования «File encryption». Личные ключи из этих пар используются при дешифровке данных и FEK. Личная часть ключей хранится либо на смарт-картах, либо в другом надежном месте (например, в памяти, безопасность которой обеспечивается при помощи CryptoAPI).

FEK также шифруется при помощи одного или нескольких ключей восстановления (полученных из сертификатов X509, записанных в политике восстановления зашифрованных данных для данного компьютера, с дополнительной возможностью «File recovery»).

Как и в предыдущем случае, общая часть ключа используется для шифрования списка FEK. Список зашифрованных ключей FEK также хранится вместе с файлом в специальной области EFS, которая называется DRF (data recovery field — поле восстановления данных). Для шифрования списка FEK в DRF используется только общая часть каждой пары ключей. Для нормального осуществления файловых операций необходимы только общие ключи восстановления. Агенты восстановления могут хранить свои личные ключи в безопасном месте вне системы (например, на смарт-картах). На рисунке приведены схемы процессов шифрования, дешифрования и восстановления данных.

Процесс шифрования

Encrypt.gif

Незашифрованный файл пользователя шифруется при помощи случайно сгенерированного ключа FEK. Этот ключ записывается вместе с файлом, файл дешифруется при помощи общего ключа пользователя (записанного в DDF), а также при помощи общего ключа агента восстановления (записанного в DRF).

Процесс дешифрования

Decrypt.gif

Сначала используется личный ключ пользователя для дешифрации FEK — для этого используется зашифрованная версия FEK, которая хранится в DDF. Расшифрованный FEK используется для поблочного дешифрования файла. Если в большом файле блоки считываются не последовательно, то дешифруются только считываемые блоки. Файл при этом остается зашифрованным.

Примечания

  1. Оффциальая страница Microsoft http://windows.microsoft.com/ru-ru/windows/what-is-encrypting-file-system#1TC=windows-7

Ссылки

  • Wiki
  • iXBT
  • Оффциальая страница Microsoft

EFS

Когда вы стираете файл с жесткого диска, на самом деле вы не удаляете его, а просто сообщаете компьютеру о том, что часть диска, на которой находится файл, теперь доступна для использования. Файл исчезает только тогда, когда вы что-то записываете поверх него. Однако пока этого не произошло, файл продолжает существовать на диске и может быть легко восстановлен.

Использование файловой системы EFS (Encrypting File System — шифрованная файловая система) в Windows XP Professional позволяет защитить данные. При применении EFS сохраняемые на диске файлы шифруются, и их нельзя прочитать, пока к ним не будет корректного доступа.

Примечание. EFS можно применять только в NTFS-томе.

EFS представляет собой трехступенчатый процесс.

  1. Для шифрования и расшифровки данных применяется пара ключей: открытый/закрытый и ключ шифрования файлов. Когда пользователь в первый раз шифрует файл, EFS создает ключ шифрования файлов (FEK). FEK шифруется с помощью открытого ключа пользователя и в зашифрованном состоянии хранится вместе с файлом.
  2. Существует несколько способов пометить файл, предназначенный для шифрования:
    • вручную настроить EFS путем изменения расширенных свойств файла;
    • сохранить файл в папке, предназначенной для шифрования;
    • использовать команду CIPHER.EXE в командной строке.
  3. Для расшифровки файла пользователь должен открыть его и удалить шифрование, используя команду CIPHER.EXE. При дешифровке файла система EFS сначала декодирует FEK с помощью закрытого ключа пользователя, а затем расшифровывает данные, используя FEK.
EFS в Windows XP Professional

Система EFS известна со времени появления Windows 2000, но Windows XP Professional добавила в нее новые свойства, повысив ее функциональность. Эти новые качества включают в себя следующее.

  • Возможность шифровать файлы в режиме офлайн.
  • Наличие агентов восстановления данных (Data Recovery Agents).
  • Возможность использования алгоритма 3DES (triple-DES) вместо DESX (Data Encryption Standard XORed).
  • Дискета сброса пароля может быть использована для переустановки пароля пользователя.
  • Зашифрованные файлы можно хранить в веб-папках.

В Windows XP Professional система EFS включается по умолчанию. Однако тут надо соблюсти некоторые предварительные условия. Во-первых, пользователи должны иметь открытый и закрытый ключи и открытый сертификат шифрования. Однако EFS может использовать самоподписываемые сертификаты, которым для работы не нужна подпись администратора.

Шифрование и расшифровка

При работе с EFS лучше всего зашифровывать целую папку, а не отдельные файлы. Это ускоряет процесс и делает его более эффективным. Вместо шифрования разрозненных файлов вы сможете одним движением руки создать защиту множества файлов. Более того, при шифровании папки целиком все запасные копии файлов тоже шифруются.

Примечание. Разумеется, будут зашифрованы только те копии, которые хранятся в зашифрованной папке.

Для шифрования файла или папки проделайте следующие шаги.

  1. В My Computer (Мой компьютер) выберите файл или папку, которые нужно зашифровать.
  2. Щелкните правой кнопкой мыши на файле или папке и выберите Properties (Свойства).
  3. На вкладке General (Общие) щелкните на кнопке Advanced (Дополнительно). Появится экран, показанный на рис. 10.6.
  4. Отметьте флажок Encrypt contents to secure data (Шифровать содержимое для защиты данных) и затем нажмите ОК.

Если вы решили зашифровать только файл, то Windows XP Professional выдаст запрос, хотите ли вы зашифровать один этот файл или всю папку. Как упоминалось ранее, лучше зашифровать целую папку, но, тем не менее, можно зашифровать и отдельный файл. После шифрования имя файла будет показано зеленым цветом.

Шифрование файла или папки

Рис.
10.6.
Шифрование файла или папки

Примечание. Сжатые файлы представлены шрифтом синего цвета. Файл не может быть одновременно зашифрованным и сжатым.

Дешифрование файлов и папок проводится аналогичным образом. В данном случае вам потребуется очистить флажок Encrypt contents to secure data.

Команда CIPHER

По желанию для шифрования папок и файлов можно использовать инструмент командной строки CIPHER. Использование команды CIPHER в чистом виде просто показывает атрибуты файлов и папок, содержащихся в данной папке. Однако эту команду можно применять с набором ключей. Перечисленные ниже являются наиболее полезными.

  • /e Назначает файл или папку для шифрования.
  • /d Расшифровывает выбранный файл или папку.
  • /a Указывает, что действие будет применено ко всем файлам в папке.
  • /? Представляет список всех аргументов CIPHER.

Ниже показаны два файла, которые были предварительно зашифрованы с помощью Windows XP Professional GUI, каждый из которых содержит очень секретную информацию: Top Secret Plans For World Domination.txt и Aunt Barb’s Apple Brown Betty Recipe.txt. Воспользовавшись командой CIPHER, мы можем увидеть EFS-атрибуты файлов в этой папке. Оба файла были зашифрованы, о чем свидетельствует буква «E» рядом с именами файлов. Незашифрованные папки помечены буквой «U».

C:>cipher

	Listing C:Documents and SettingsRobert ElsenpeterMy Documents
	New files added to this directory will not be encrypted.

E Aunt Barb's Apple Brown Betty Recipe.txt
U My Music
U My Pictures
E Top Secret Plans For World Domination.txt

Для расшифровки этих файлов введите:

C:>cipher /d /a
	Decrypting files in C:Documents and SettingsRobert ElsenpeterMy Documents
Aunt Barb's Apple Brown Betty Recipe.txt [OK]
Top Secret Plans For World Domination.txt [OK]
2 file(s) [or directorie(s)] within 1 directorie(s) were decrypted.


Листинг
10.1.

Подробнее о плюсах и минусах EFS

EFS представляет собой лишь один из способов защиты информации в компьютерной системе. Таких способов Windows 2000 предлагает несколько, и наша задача в каждом конкретном случае выбрать наиболее подходящий. Естественно, требуемый уровень защиты должен определяться характером конфиденциальной информации, а также типом компьютерной системы. В данной статье рассматривается, прежде всего, проблема защиты локальных данных, т. е. файлов, хранящихся на жестком диске персонального компьютера.

Обезопасить локальные ресурсы в Windows 2000 средствами самой системы можно двумя способами: с помощью разрешений NTFS и с помощью EFS.

Вместе с первой версией операционной системы Windows NT, предшественницей Windows 2000, появилась и новая файловая система — NTFS. На сегодня NTFS закрепила за собой позиции надежной, эффективной файловой системы с развитыми функциями защиты. Средствами NTFS можно защитить свою информацию от несанкционированного доступа, независимо от того, работает пользователь в локальной сети предприятия или у себя дома. Пятая версия NTFS, реализованная в Windows 2000, обладает более широким набором специальных разрешений и усовершенствованным механизмом наследования. Действие разрешений на доступ, настроенных с помощью NTFS, распространяется как на сетевые подключения, так и на локально зарегистрировавшихся пользователей. Однако защита NTFS остается эффективной до тех пор, пока злоумышленник не добрался до компьютера физически. Иначе достаточно подключить винчестер к другой машине или даже просто загрузить другой экземпляр Windows 2000 на этом же компьютере. Как в такой ситуации уберечь свои данные?

Понятно, что абсолютной защиты не существует. Но если нельзя полностью избежать потери информации, можно хотя бы воспрепятствовать ее прочтению и разглашению. Один из наиболее распространенных подходов к решению этой проблемы предусматривает применение различных криптографических методов или попросту шифрование.

Средства поддержки шифрования на программном уровне появились еще в Windows NT 4.0 (после выхода Service Pack 4) и получили дальнейшее развитие в Windows 2000/XP. Я начну с архитектуры EFS.

Архитектура EFS

Существует немало публикаций, подробно описывающих архитектуру EFS. Весьма удачно и емко, на мой взгляд, данная тема изложена в [1]. Мне же хочется обратить внимание читателей на некоторые детали реализации EFS, повлиявшие на развертывание и использование этого механизма. Структурно EFS выполнена в виде драйвера устройства, работающего в режиме ядра и тесно связанного с драйвером NTFS. Всякий раз, когда NTFS встречает шифрованный файл, она вызывает функции из драйвера EFS, зарегистрированные им в NTFS при инициализации EFS. Поэтому средства шифрования доступны только на разделах NTFS.

С криптографической точки зрения разработчики выбрали стандартный на сегодняшний день подход к шифрованию данных, объем которых может варьироваться в широких пределах. Стандартность его заключается в сочетании симметричного и асимметричного методов шифрования. Для каждого шифруемого файла операционная система на основе генератора случайных чисел создает криптографический ключ, называемый шифровальным ключом файла (file encryption key, FEK). Тело файла шифруется блоками по 512 байт с помощью полученного FEK и симметричного алгоритма DESX. Затем FEK шифруется посредством асимметричного алгоритма RSA и открытого ключа пользователя, инициировавшего операцию шифрования. Использование симметричного блочного шифра снижает вычислительную нагрузку на центральный процессор.

В среднем, симметричные алгоритмы работают в 100-1000 быстрее асимметричных. В свою очередь, применение асимметричных методов криптографии позволяет надежно защитить FEK и упростить управление ключами.

Рассмотрим вкратце криптоаналитические аспекты EFS. Многие читатели, наверное, знакомы с широко распространенным блочным шифром Data Encryption Standard (DES). Те же, кому требуется развернутая информация по данному вопросу, могут обратиться к замечательной книге Вильяма Столлингса [2]. Исходный вариант DES использует ключи длиной 56 разрядов. За время, прошедшее после создания DES, компьютерная техника развилась настолько, что при данной длине ключа удается в приемлемые сроки осуществлять полный перебор пространства ключей. В 1984 г. Рон Ривест предложил усовершенствованный вариант алгоритма, названный DES eXtended (DESX) и определяемый как

= k2 ( (k1 ( x)

Ключ DESX K = k, k1, k2 состоит из 56 + 64 + 64 = 184 разрядов и содержит три различных подключа: ключ DES k, предварительный «зашумляющий» ключ k1 и завершающий «зашумляющий» k2. При шифровании блок сообщения x складывается поразрядно по модулю 2 с k1, затем шифруется по алгоритму DES и вновь поразрядно складывается по модулю 2 с k2. Таким образом, затраты DESX на шифрование блока всего на две операции сложения по модулю 2 больше, чем затраты исходного алгоритма. Однако эти две операции делают шифр гораздо менее уязвимым по отношению к перебору ключей. Согласно же [3], DESX также повышает стойкость к дифференциальному и линейному криптоанализу, увеличивая необходимое количество проб с выбранным текстом до значения, превышающего 260. Следовательно, можно считать, что криптоаналитическая стойкость предлагаемого решения не вызывает серьезных нареканий.

Остается надежно защитить FEK, для чего используется алгоритм RSA. И если FEK генерируется случайным образом для каждого файла, то сам FEK шифруется с помощью открытого ключа пользователя. Криптографическую пару открытый (public)/закрытый (private) ключ Windows 2000 генерирует для конкретного пользователя, когда тот впервые шифрует папку или файл на NTFS. Открытый ключ оформляется в виде цифрового сертификата. В корпоративных сетях выпуском цифровых сертификатов занимается служба Certificate Service, входящая в поставку серверных продуктов семейства Windows 2000. В отсутствии этой службы, например, в рабочей группе или на домашнем компьютере NTFS сама выпускает сертификаты, но только для использования в операциях с EFS. И цифровой сертификат, и закрытый ключ хранятся в профиле пользователя.

На программном уровне допустимо нескольким людям работать с одним и тем же файлом. Однако в пользовательском интерфейсе Windows 2000 обращаться к зашифрованному файлу может только тот, кто его зашифровал, и агенты восстановления (Data Recovery Agents, DRA). Формат заголовка шифрованного файла представлен на Рисунке 1.


Рисунок 1. Формат заголовка шифрованного файла.

Основную часть заголовка составляют два поля: поле расшифровки данных (Data Decryption Field, DDF) и поле восстановления данных (Data Recovery Field, DRF). Если с файлом работают несколько человек, то DDF состоит из соответствующего количества элементов, совокупность которых образует так называемую связку ключей (key ring). Каждый элемент зашифрован открытым ключом одного из пользователей. Но заметьте, что во всех элементах хранится один и тот же FEK, уникальный для данного файла.

В целом, процесс шифрования файла состоит из следующих шагов.

  1. В каталоге System Volume Information создается файл журнала с именем Efsx.log, где x — уникальное целое положительное число. По мере выполнения следующих этапов в журнал заносятся записи, позволяющие восстановить файл после сбоя системы в процессе шифрования. System Volume Information существует на любом разделе NTFS, доступ к соответствующему каталогу имеет только учетная запись SYSTEM, т. е. сама операционная система.
  2. Windows 2000 генерирует FEK.
  3. Генерируется или считывается из профиля пара открытый/закрытый ключ.
  4. Для файла создается связка ключей DDF с элементом для данного пользователя. В элемент помещается FEK и шифруется открытым ключом.
  5. файла создается связка ключей DRF с элементами для каждого DRA. FEK сохраняется во всех элементах, но каждый элемент шифруется открытым ключом соответствующего DRA.
  6. Создается резервный файл с именем вида Efs0.tmp в том каталоге, где находится шифруемый файл.
  7. В резервный файл копируется содержимое исходного файла.
  8. Содержимое исходного файла уничтожается, в него копируется содержимое резервного файла, которое при выполнении этой операции шифруется поблочно.
  9. Удаляется резервный файл.
  10. Удаляется файл журнала.

Размер блока специально выбран равным размеру сектора жесткого диска.

Дешифрование представляет собой обратный процесс. Как только пользователь обращается к зашифрованному файлу, происходит следующее.

  1. проверяет, имеется ли у пользователя закрытый ключ. Если ключ отсутствует или не подходит ни к одному из элементов связки ключей, доступ к файлу не предоставляется.
  2. Расшифровывается FEK из элемента DDF или DRF.
  3. С помощью FEK дешифруются данные файла.

Для повышения производительности NTFS кэширует FEK в невыгружаемой области памяти. Нужно иметь в виду, что присутствие EFS несколько изменяет поведение системы при проверке прав доступа к файлу и папке. Если пользователь пытается выполнить операцию, требующую расшифровки данных, и не может предоставить нужный закрытый ключ (т. е. файл зашифровал не он), система запрещает доступ к объекту. Например, пользователь, обладающий правом Full Control на файл, не будучи DRA, может файл удалить (что не требует его расшифровки), но не в состоянии прочитать или изменить данные файла. По тем же причинам система не позволит такому человеку снять атрибут шифрования (см. Экран 1). С другой стороны, если у пользователя есть право Write на незашифрованный объект, он может его зашифровать и, тем самым, лишить владельца возможности работать с собственным файлом.


Экран 1. Ошибка при попытке изменения атрибута шифрования.

Использование EFS

В предыдущем разделе уже было показано, что предложенная Microsoft архитектура EFS порождает ряд особенностей в использовании шифрования. Еще одной такой особенностью является полная прозрачность операций шифрования/дешифрации для конечного пользователя. Как известно, для того чтобы зашифровать файл или папку, достаточно с помощью Windows Explorer установить флажок Encrypt contents to secure data в свойствах объекта или использовать утилиту командной строки cipher.exe. Столь же просто файл или папку расшифровать. Прозрачность операций достигается за счет хранения криптографической пары ключей в профиле пользователя. Действительно, когда пользователь пытается выполнить какие-либо действия, связанные с EFS, операционная система всегда может идентифицировать его (по SID), определить расположение профиля и загрузить оттуда необходимые ключи. С другой стороны, неосторожные действия администратора с профилем пользователя могут привести к потере ключей и отказу в доступе к данным. Рассмотрим подробнее вопросы хранения открытого/закрытого ключей.

Как уже упоминалось, открытый ключ хранится в виде структуры данных, называемой цифровым сертификатом. Все сертификаты пользователя записываются в папку Documents and SettingsApplicationDataMicrosoft SystemCertificatesMy Certificates. Дополнительно их можно опубликовать в Active Directory. Поскольку информация в цифровом сертификате открытая, ее хранение не требует особых усилий.

Гораздо сложнее обстоит дело с закрытыми ключами. Они располагаются в папке Documents and SettingsApplication DataMicrosoftCryptoRSA. Эта папка не может быть переименована или перенесена в другое место. Для надежной защиты закрытых ключей в Windows 2000 применяется многоуровневое шифрование.

Все ключи в папке RSA автоматически шифруются с помощью сгенерированного случайным образом симметричного ключа, называемого основным ключом пользователя (user?s master key). Основной ключ, в свою очередь, автоматически шифруется службой Protected Storage и сохраняется в Documents and SettingsApplication DataMicrosoftProtect. Для пользователей с перемещаемыми профилями основной ключ хранится на контроллере домена и загружается на компьютер пользователя только на время сеанса работы. Длина основного ключа 56 или 128 разрядов. Как обычно, 128-разрядные ключи разрешены для применения только в США и Канаде.

Наконец, служба Protected Storage шифрует все основные ключи пользователей компьютера, а также другие ключи, применяемые операционной системой, с помощью системного ключа (system key). Системный ключ для каждого компьютера с Windows 2000 уникален. По умолчанию, как указано в [4], он хранится непосредственно на компьютере и размещен в реестре с использованием сложного алгоритма. Однако подобный подход все же снижает уровень защиты системы, особенно в тех ситуациях, когда злоумышленник завладел жестким диском. Поэтому с помощью программы syskey.exe системный ключ можно удалить с компьютера и сохранить на дискете. В этом случае при запуске Windows 2000 потребуется вставить дискету либо ввести пароль, на основе которого будет сгенерирован ключ. Причем диалоговое окно с просьбой вставить дискету или ввести пароль появляется еще до традиционного окна регистрации в системе. Хранение системного ключа на внешнем носителе требует особой осторожности, ибо потеря этого ключа при отсутствии резервной копии сделает невозможной дальнейшую работу с данным экземпляром Windows 2000.

С учетом сказанного выше можно отметить следующие особенности использования EFS.

Во-первых, необходимо иметь в виду, что по сети данные всегда передаются в открытом виде. Почему? Ключи хранятся на том компьютере, на котором выполнялось шифрование, например на компьютере A. Если теперь передать файл на компьютер B, операционная система этой машины не сможет выполнить дешифрацию, поскольку не знает пользовательского закрытого ключа, оставшегося на A. Почему же не передавать и закрытый ключ? Очевидно, передавать его открытым текстом нельзя. Тогда необходимо предложить эффективный алгоритм обмена закрытыми ключами между компьютерами, что может существенно повысить сложность EFS в целом и отрицательно сказаться на производительности. Более того, если закрытых ключей несколько — а при нынешнем положении дел Windows 2000 генерирует криптографическую пару на каждом компьютере, где пользователь выполняет шифрование, — общий уровень защиты системы повышается. Таким образом, при копировании файла система компьютера A дешифрует файл и передает его в открытом виде по сети. Получив файл, система B шифрует содержимое файла с помощью своей пары открытый/закрытый ключ и сохраняет его на диске. Если необходимо, чтобы передаваемые по сети данные были защищены, следует воспользоваться дополнительными средствами Windows 2000, например протоколом IPSec.

Во-вторых, компьютер, на который копируются или переносятся шифрованные файлы, должен быть доверенным для делегирования. Это позволит операционной системе удаленного компьютера запросить пару ключей в контексте учетной записи пользователя, выполняющего операцию. Причем доверенной для делегирования должна быть именно учетная запись компьютера, так как EFS работает от имени записи SYSTEM.


Экран 2. Профиль пользователя, созданный для выполнения операций EFS.

В-третьих, если на том компьютере, куда копируются файлы, нет пользовательского профиля, а стало быть, нет и пары ключей, Windows 2000 создаст такой профиль. Правда, выглядеть он будет несколько иначе (см. Экран 2).

Тем не менее способ перенести информацию на другой компьютер в зашифрованном виде существует — с помощью утилиты Backup. При создании резервной копии Backup может сохранять на носителе файлы без расшифровки их содержимого. Для этого используются функции нового EFS API, такие, как OpenEncryptedFileRaw, ReadEncryptedFileRaw, WriteEncryptedFileRaw и CloseEncryptedFileRaw.

Однако нельзя применять эти функции в обход Backup, т. е. в обыкновенной WIN32-программе обратиться к ним и переписать зашифрованный файл в другое место не удастся. Если бы это было возможно, атакующий мог бы воспользоваться криптоанализом c избранным открытым текстом. По тем же причинам Backup не позволит восстановить зашифрованные данные из резервной копии на раздел, отформатированный файловой системой, отличной от NTFS (точнее говоря, не поддерживающей EFS). Но даже если все сделано правильно и компьютер-получатель содержит NTFS-раздел, после восстановления информации получить доступ к данным не удастся — отсутствуют закрытые ключи. Проблема решается двумя способами. Нужно либо с помощью оснастки Certificates экспортировать закрытый ключ, либо задействовать перемещаемый (roaming) профиль. В последнем случае криптографическая пара пользователя будет доступна на любой машине.

Политика агентов восстановления

Эта тема вызывает наибольшее количество вопросов. Для начала напомню, что при EFS-операциях FEK сохраняется еще и в поле DRF. Это означает, что помимо человека, выполнившего шифрование, расшифровать файл может любой пользователь, назначенный агентом восстановления (DRA). Иными словами, всегда есть некто, способный прочитать или даже изменить ваши конфиденциальные данные. Является ли наличие DRA сильной или слабой стороной EFS? Ответы могут быть прямо противоположными.

С одной стороны, не надо забывать, что Microsoft позиционирует Windows 2000 для рынка крупных корпоративных сетей, а здесь проблема возможной потери данных стоит особенно остро. Теперь представим себе ситуацию: некий пользователь, например менеджер, зашифровал свои данные, а администратор по неосторожности удалил его профиль вместе с закрытым ключом. В отсутствии DRA доступ к данным будет невозможен. Конечно, у грамотного администратора наверняка имеется резервная копия файлов менеджера, но… всем известно, как это обычно бывает.

Другой пример. Одного из сотрудников увольняют, администратор удаляет соответствующую учетную запись, но потом выясняется, что перед уходом этот человек зашифровал папку на файловом сервере. Все закрытые ключи на местах, но как ими воспользоваться? Опять же Backup? Но если в резервную копию файлы попали уже зашифрованными? Можно предложить массу других не менее сложных сценариев.

Понимая остроту перечисленных проблем, разработчики Microsoft вводят DRA. Не для того, чтобы подсматривать чужие данные, а для того, чтобы можно было их восстановить. Но вот сюрприз, DRA является обязательным составляющим EFS. Если удалить последнего агента восстановления в системе, EFS отключается. Действительно, любые попытки зашифровать данные после этого приводят к ошибке (см. Экран 3). Вернув хотя бы одного DRA, мы снова активизируем EFS, подробности на эту тему можно найти в [5].


Экран 3. Попытка зашифровать файл при отсутствии DRA.

Такая ситуация может не устроить множество пользователей, работающих на компьютерах, не подключенных к сети. Зачем мне на домашней машине с Windows 2000 этот DRA? Почему я не могу отказаться от него, пусть даже на свой страх и риск? Мне кажется, что такая возможность должна быть предоставлена.

Более того, по умолчанию роль DRA на автономных машинах играет встроенная запись Administrator, в домене — Administrator домена. И если в рамках домена можно назначить новых DRA, опираясь на GPO и службу цифровых сертификатов, и не вменять это в обязанность администратору, то на компьютерах вне домена такой возможности нет.

Данная ситуация послужила поводом для атак на EFS. Специалисты в области защиты информации летом 1999 г. опубликовали на сайте www.ntsecurity.net сенсационный документ. По их мнению, для того чтобы получить доступ к зашифрованным документам, достаточно сделать следующее.

  1. Установить на компьютер вторую систему Windows 2000. Допустим, первая стоит в каталоге winnt. Тогда вторую установим в winnt2.
  2. Загрузить вторую систему. Открыть каталог winntsystem32config и создать его резервную копию. Удалить файлы SAM и SAM.LOG.
  3. Загрузить компьютер в первой системе.
  4. Зарегистрироваться под именем Administrator с пустым паролем.
  5. С этого момента вы получаете доступ ко всей зашифрованной информации на дисках.

Разумеется, такой ситуации можно избежать, если в политике домена назначить другого DRA и удалить локальных. Но в рабочих группах проблема остается и фактически сводит на нет преимущества использования EFS.

Существует два основных подхода к применению DRA. Оба предполагают, что открытый/закрытый ключи агента хранятся на внешнем носителе. Для этого при экспорте ключей отмечается параметр, заставляющий систему удалить ключи с жесткого диска (см. Экран 4). При первом подходе для восстановления файлов, пользователь-агент восстановления садится за компьютер пользователя, где имеются подлежащие расшифровке данные, импортирует ключи и выполняет восстановление информации. Ключи затем удаляются. При втором, более надежном, пользователь пересылает файлы агенту в защищенном виде (IPSec, MIME/S). DRA расшифровывает информацию и таким же способом пересылает обратно.

Выводы

  1. Криптографическая стойкость EFS сомнений не вызывает. Применяемые алгоритмы защищают информацию достаточно надежно.
  2. В отличие от многих других продуктов данного класса, EFS действует прозрачно для пользователей.
  3. Особенности реализации политики восстановления в Windows 2000 делают EFS пригодной для применения только в корпоративной сети, где есть возможность развернуть центр сертификации и избавиться от локального администратора в роли DRA.
  4. Использование EFS в Windows 2000 на компьютерах вне домена небезопасно в силу подверженности атакам. Оптимальным решением, пожалуй, будет использование криптографических продуктов независимых производителей.
  5. В случае применения EFS данные по сети передаются в открытом виде, для защиты сетевого трафика следует использовать дополнительные средства.
Литература

  1. Соломон Д., Русинович М. Внутреннее устройство Microsoft Windows 2000. Мастер-класс / Пер. с англ. — СПб.: Питер; М.: Издательско-торговый дом «Русская Редакция», 2001.
  2. Столлингс В. Криптография и защита сетей: принципы и практика (2-е изд.) / Пер. с англ. — М.: Издательский дом «Вильямс», 2001.
  3. Баричев С. Г., Гончаров В. В., Серов Р. Е. Основы современной криптографии. — М.: Горячая линия — Телеком, 2001.
  4. Распределенные системы. Ресурсы Microsoft Windows 2000 Server / Пер. с англ. — М.: Издательско-торговый дом «Русская Редакция», 2001.
  5. Microsoft Knowledge Base. Q243035. How to Disable/Enable EFS on a Standalone Windows 2000 Computer.

Александр Шаповал — преподаватель, имеет сертификаты MCSE, MCDBA, MCT. С ним можно связаться по адресу: shu@softjoys.ru.

Шифрующая файловая система

Преимущества шифрующей файловой системы (EFS) заключается в том, что шифрование данных происходит на уровне файловых операций NTFS, свободный доступ к зашифрованным данным из приложенийи и возможность восстановления зашифрованных данных (Emergency Data Recovery Policy).

Особенности EFS заключаются в том, что эта система работает только при наличии хотя бы одного агента восстановления. Так же нельзя зашифровать системные файлы и сжатые файлы. За пределы области работы EFS файл передается в открытом виде (то есть в локальные сети и на другие носители и файловые системы, исключение: Windows 2000 Backup).

EFS использует архитектуру Windows CryptoAPI, в основе которой технология шифрования с открытым ключом. Для шифрования файла, случайным образом генерируется ключ шифрования. При этом для шифрования может применяться любой симметричный алгоритм шифрования. Сейчас в EFS используется DESX, являющийся модификацией стандарта DES. Ключи шифрования EFS хранятся в резидентном пуле памяти, что исключает несанкционированный доступ к ним через файл подкачки.

EFS сконфигурирована так, что пользователь может сразу использовать шифрование файлов. Для файлов и каталогов поддерживается шифрования и расшифрование. В случае, если шифруется каталог, автоматически шифруются все файлы и подкаталоги этого каталога. Если зашифрованный файл перемещается или переименовывается из зашифрованного каталога в незашифрованный, то он все равно остается зашифрованным. Шифрование и расшифрование можно выполнить используя Windows Explorer или консольную утилиту Cipher.

EFS использует шифрование с общим ключом. Данные шифруются симметричным алгоритмом при помощи ключа шифрования файла FEK (file encryption key — случайным образом сгенерированный ключ определенной длины). Длина ключа EFS в зависимости от версии может составлять 128 бит, 40 или 56 бит.

Процесс шифрования и расшифрования.

Незашифрованный файл зашифровывается при помощи сгенерированного ключа. Этот ключ записывается вместе с файлом, и расшифровывается при помощи общего ключа пользователя находящегося Data Decryption Field — поле дешифрования данных, а также при помощи общего ключа агента восстановления находящегося в Data Recovery Field — поле восстановления данных.

Для расшифрования используется личный ключ пользователя. Для этого используется зашифрованная версия FEK, находящаяся в поле дешифрования данных. Расшифрованный ключ используется для поблочного расшифрования файла.

Процесс восстановления аналогичен дешифрованию за исключением того, что для дешифрования используется личный ключ агента восстановления, а зашифрованная версия берется из поля восстановления данных.

Понравилась статья? Поделить с друзьями:
  • Какие файлы удаляются при переустановке windows 10
  • Какие типы зон dns поддерживаются службой dns систем семейства windows server
  • Какие файлы удалить чтобы windows 10 не загрузилась
  • Какие текстовые редакторы встроены в windows 7 по умолчанию
  • Какие файлы сохраняются при сбросе windows 10