Microsoft Windows NT File System (NTFS) “Providing a false sense of file security for Windows users since 1993”

Just the Facts of NTFS 5.0 NTFS 5.0 is more advanced than the Win9x/DOS File Allocation Table (FAT) System. It natively provides file and directory object security, compress, encryption, logging, and user quota capabilities, all of which FAT did not have the capabilities of providing (must use second or third level utilities such as STACKER or DriveSpace). NTFS 5.0 can address much larger partitions than FAT16 (2GB) and equivalent partition sizes as FAT32 (2TB) File names can consist of any UNICODE (multi-national) characters, while FAT only consists of ASCII (English/American) File sizes are limited only by volume size, and not 4GB (FAT32) and 2GB (FAT16) Despite popular rumor, NTFS, like FAT, gets fragmented over time.

Basic Implementation Fundamental Data Structure of NTFS is the Metafile. The Metafiles:

NTFS Security Features Availability and Integrity –$LOGFILE –$MFTMIRR –$BADCLUS Confidentiality –$MFT –Encrypting File System (added in NTFS 5.0) Authenticity –$MFT CREATOR_OWNER

Availability and Integrity $LOGFILE –At the same time files are modified, certain information about the changes are written in two different record types to $LOGFILE. Redo records are written with information about the modification that must be redone if a modify or delete process is interrupted. An undo record is written in order to facilitate the rollback of an append if the process fails between the time the file is extended and the data is actually written in the new free space created. –Example: CHKDSK uses the information in $LOGFILE to ensure data integrity and availability if a system is powered down without flushing the disk buffers.

Availability and Integrity $MTFMIRR –Metafile that is stored “in the middle” of the disk as a backup-copy of $MFT. –Used in case MFT is corrupted. –$BOOT (which can be stored at either the first or last sector of the disk) holds pointers to both the $MFT and $MTFMIRR

Availability and Integrity $BADCLUS –If an error occurs while reading data off of an NTFS formatted partition NT will assume that the cluster is a “bad cluster.” –The error recovery process will then enter the cluster into the $BADCLUS metafile –It will then recover what it can of the data and place it in another location. –This feature is enhanced greatly with fault-tolerant file system drivers.

Confidentiality and Security $MTF –Each file and folder has it’s own record in the $MFT. –Within that record is a pointer to an attribute record $SECURITY_DESCRIPTOR –The Security Descriptor holds information that allows NT to map permissions (Allow or Deny of: Read, Write, Execute, Modify, Full, etc) to Users (represented by their internal SID) S XXXXXXXXX-XXXXXXXXX-XXXXXXXXX-500 represents the local machine’s “Administrator” account. –If no SID exists in $SECURITY_DESCRIPTOR the permission is assumed to be an outright “deny” of all rights. –As demonstrated earlier, $SECURITY_DESCRIPTOR is read by the NT operating system, not by the hardware. Therefore, it can be bypassed and the data accessed directly on disk.

Confidentiality and Security Encrypting File System (EFS) –New in NTFS 5.0 (Windows 2000) –Uses Windows 2000 Cryptography Services. –Users can explicitly specify to encrypt a file, or Windows 2000 will automatically encrypt files that are within a folder that has been specified as encrypted. –Uses a stronger variant of DES that we learned in class, DESX. This process is symmetric and quicker than asymmetric technologies which is ideal when encrypting what can be huge (up to 2TB) files. –We known symmetric encryption uses a single key to both encrypt and decrypt information; how do we keep this key secure on disk?

Confidentiality and Security The EFS Process –The first time a user encrypts a file, Windows 2000 Cryptography services creates for the user a unique private and public key for use in File System Encryption. –When a file is encrypted, EFS generates a random number, the File Encryption Key (FEK), and uses that number as the key in the DESX encryption process. –For each user that is given permission to decrypt the file, EFS encrypts the FEK with that user’s public key and stores that encrypted FEK in a special location inside the encrypted file. –Therefore only the certain user(s) can decrypt the FEK with their private key and then decrypt the file.

Confidentiality and Security Is EFS Secure? (Read: Can we crack it?) –Can we ignore EFS in an alternative operating system like we can with NTFS File encryption? NO, the data is encrypted on disk. –Can we ignore EFS while booted into NT? NO, EFS is a device driver that runs in Win2K's kernel mode, in which EFS is tightly connected with the NTFS file-system driver. At that point, EFS software and the software that allows access to the NTFS should be thought of as equivalent. Ignore one and Ignore the other. –Can we get at user’s private keys? Yes, by default the private keys are stored on disk. If anything is stored on disk-unencrypted, anyone can gain access to it if they have physical access to the machine. (BOOTDRIVE:\ Documents and Settings\Administrator\Application Data\Microsoft\SystemCertificates\My\Certificates\{random hex string} ) No, Windows 2000 can be configured to store private keys on an external smart- card that is required to logon to the workstation.

Sources NTFS and Metafiles –Windows NT File System Internals A Developer’s Guide, Nagar, Rajeev., O’Reilly Publishing. –WinNT Magazine Online ueID=27&ArticleID=3455http:// ueID=27&ArticleID=3455 –Ars Technica 1.htmlhttp:// 1.html Encrypting File System –WinNT Magazine Online cleID=5387http:// cleID=5387 –ELCOMSOFT Advanced EFS Data Recovery System