Microsoft Windows 2000 Native File System
Design Goals and Features: From the start, NTFS was designed
to include features required of an enterprise-class file system. To minimize
data loss in the face of an unexpected system outage or crash, a file
system must ensure that the integrity of the file system's metadata be
guaranteed at all times, and to protect sensitive data from unauthorized
access, a file system must have an integrated security model. Finally,
a file system must allow for software-based data redundancy as a low-cost
alternative to hardware-redundant solutions for protecting user data.
In this section, you'll find out how NTFS implements each of these capabilities.
To address the requirement for reliable data storage and data access,
NTFS provides file system recovery based on the concept of an atomic transaction.
Atomic transactions are a technique for handling modifications to a database
so that system failures don't affect the correctness or integrity of the
database. The basic tenet of atomic transactions is that some database
operations, called transactions, are all-or-nothing propositions. (A transaction
is defined as an I/O operation that alters file system data or changes
the volume's directory structure.) The separate disk updates that make
up the transaction must be executed atomically; that is, once the transaction
begins to execute, all its disk updates must be completed. If a system
failure interrupts the transaction, the part that has been completed must
be undone, or rolled back. The rollback operation returns the database
to a previously known and consistent state, as if the transaction had
In addition, NTFS uses redundant storage for vital file system information
so that if a sector on the disk goes bad, NTFS can still access the volume's
critical file system data. This redundancy of file system data contrasts
with the on-disk structures of both the FAT file system and the HPFS file
system (OS/2's native file system format), which have single sectors containing
critical file system data. On these file systems, if a read error occurs
in one of those sectors an entire volume is lost.
Security in NTFS is derived directly from the Windows 2000 object model.
Files and directories are protected from being accessed by unauthorized
users. An open file is implemented as a file object with a security descriptor
stored on disk as a part of the file. Before a process can open a handle
to any object, including a file object, the Windows 2000 security system
verifies that the process has appropriate authorization to do so. The
security descriptor, combined with the requirement that a user log on
to the system and provide an identifying password, ensures that no process
can access a file unless given specific permission to do so by a system
administrator or by the file's owner.
Redundancy and Fault Tolerance: In addition to recoverability
of file system data, some customers require that their own data not be
endangered by a power outage or catastrophic disk failure. The NTFS recovery
capabilities do ensure that the file system on a volume remains accessible,
but they make no guarantees for complete recovery of user files. Protection
for applications that can't risk losing file data is provided through
Encryption: Corporate users often store sensitive information on their computers. Although data stored on company servers is usually safely protected with proper network security settings and physical access control, data stored on laptops can be exposed when a laptop is lost or stolen. NTFS file permissions don't offer protection because NTFS volumes can be fully accessed without regard to security by using NTFS file-reading software that doesn't require Windows 2000 to be running. Furthermore, NTFS file permissions are rendered useless when an alternate Windows 2000 installation is used to access files from an administrator account.
NTFS includes a facility called the Encrypting File System (EFS), which users can use to encrypt sensitive data. The operation of the EFS, as that of file compression, is completely transparent to applications, which means that file data is automatically decrypted when an application running in the account of a user authorized to view the data reads it and is automatically encrypted when an authorized application changes the data.
NTFS doesn't permit the encryption of files located in the system volume's root directory or under the \Winnt directory because many of the files in these locations are required during the boot process and the EFS isn't active during the boot process.
The EFS relies on cryptographic services supplied by Windows 2000 in user mode, and so it consists of both a kernel-mode device driver that tightly integrates with NTFS as well as user-mode DLLs that communicate with the Local Security Authority Subsystem (Lsass) and cryptographic DLLs.
Files that are encrypted can be accessed only by using the private key of an account's EFS private/public key pair, and private keys are locked using an account's password. Thus, EFS-encrypted files on lost or stolen laptops can't be accessed using any means (other than a brute-force cryptographic attack) without the password of an account that is authorized to view the data.
Applications can use the EncryptFile and DecryptFile Win32 API functions to encrypt and decrypt files, and FileEncryptionStatus to retrieve as file or directory's EFS-related attributes, like whether the file or directory is encrypted.