Lecture 18 Windows – NT File System (NTFS) CE01000-3 Operating Systems Lecture 18 Windows – NT File System (NTFS)

Overview of lecture In this lecture we will look at: NT File System (NTFS) Encrypting File System (EFS)

Windows structure overview

File systems in Windows in Windows the file system is part of the I/O system. the I/O manager provides device independent I/O facilities, in our case Either the file manipulation facilities that are independent of the hardware of the physical device the file data is stored on or the type of the file system that is used to organise the way the file data is held on the physical device.

File systems in Windows (Cont.) to achieve this the software that controls the physical hardware and any file systems must be separate from the I/O manager physical devices which hold file data e.g. disks, DVDs, pen drives, etc. will have device drivers that form part of the I/O system

File systems in Windows (Cont.) the file system is implemented by a file system driver - in this case the file system driver will use the backing store device drivers when it wishes to access the physical devices. Windows processes can access files from different file systems provided an appropriate file system driver exists e.g. Dos FAT file system, NT File System, Posix (Unix) file system, etc.

Representation of files in Windows files in Windows are considered objects i.e. they are resources for which the object manager holds a representation that is an object a process that is accessing a file will have a file handle (as a data structure or an object, depending upon the language of the processes source code)

Representation of files in Windows the file handle will contain an index into the object handle table the object handle contains the reference to file object the file object contains a set of attributes and services

Representation of files in Windows Process Object handle table File object File handle File system specific data structures

Representation of files in Windows (Cont.) the attributes include file name, but also info on current location in file for next read/write operation, type of device file resides on, etc. the services include file creation, deletion, read, write, get file info, set file info, etc. file object also contains a reference to file system specific data structures that provide the mapping between the logical file object and the physical file data on the hardware device e.g. disk

Layered file system driver and disk device driver Environment subsystem or DLL User mode Kernel mode 1 Executive API 2 I/O manager File system driver 3 4 Device driver 5 disk

writing to disk via file system driver and disk driver 1. write data at specified byte offset within file 2. translate file-relative byte offset into disk relative byte offset and call next driver 3. call driver to write data at disk relative byte offset 4. translate disk relative byte offset into physical location 5. transfer data

Files, sectors, and clusters - reminder File data is held on disk is broken up into smaller units. Smallest unit of data on disk is the data held by 1 physically formatted sector (segment of a track) - often 512 bytes in size (but this can be Operating System specific). NTFS organise disk manipulation in terms of a consecutive sequence of sectors on a disk called a cluster (this is not true of all Operating Systems)

Files, sectors, and clusters (Cont.) File data is held on disk in 1 or more clusters. These clusters may not be consecutive but may be spread all over the disk. The problem for the file system is to be able to retrieve the sequence of file data from these scattered locations

Clusters and files - reminder Sectors sector = formatted segment of track typically 512 bytes per sector Cluster is sequence of sectors (often 4/8 sectors depending on disk size) File is sequence of clusters (not necessarily consecutive)

Logical Cluster Numbers NTFS refers to disk locations via a Logical Cluster Number (LCN) numbers are assigned to all clusters in disk volume from 0 to N (number of clusters in volume - 1) this number is LCN these LCNs are mapped onto physical cluster locations by storage media device driver

Virtual Cluster Numbers NTFS refers to locations within a file by a Virtual Cluster Number (VCN) numbers are assigned to all clusters that make up the file from 0 (file start) to M (number of clusters in file - 1) the clusters that make up the file may not be contiguous NTFS maps from VCN for a file onto LCN

Indexing of blocks in NTFS NTFS locates files on disks using index blocks (Unix uses a similar index block method) File object contains a reference to File Control Block (1 per file) and this in turn contains a file reference number file reference numbers identify a record (by providing an index) in the Master File Table Master File Table (MFT) is a file of file records - with usually 1 record per file in the file system

Master File Table (Cont.) Process object handle table File object File handle control block Master File Table

Master File Table (Cont.) Record in Master File Table (MFT) contains: standard file information such as time stamps, whether read-only, etc. Filename security descriptor - file ownership and access permissions file data attribute field (for data files) or file indexing attribute field (for directories) data is treated as just another attribute of a file

Master File Table (Cont.) For very small files data is actually contained in data attribute field of MFT record file info file name security info DATA SMALL FILE

Master File Table (Cont.) LARGE FILE file info file name security info file data run references DATA VCN 0 LCN 134 VCN 1 LCN 135 VCN 2 LCN 213

Master File Table (Cont.) For larger files (most files) data attribute field contains a series of references to file data runs a file data run is a cluster that contains the actual file data For even larger files the MFT record will contain a reference to another MFT record entry that contains further file data run references in its data attribute field i.e. the MFT records can become chained together to represent massive files

Directory file indexes in NTFS directories are represented by entries in MFT MFT contains an entry for the root directory of the NTFS file system volume for directories files are identified by file indexes file indexes contain file reference numbers (effectively an index into MFT), plus file name, time stamp info and file size for file

Directories SMALL DIRECTORY in a directory record in MFT then instead of data attribute field there are indexing attribute fields For small directories files within directory are identified by a series of file indexes held in indexing attribute field file info file name security info file-index1.... file-indexN SMALL DIRECTORY

Directories (Cont.) LARGE DIRECTORY file info file name security info file index buffer references file-indexN+M+1.... file-indexZ file-indexN+1.... file-indexN+M file-index1.... file-indexN LARGE DIRECTORY

Directories (Cont.) For larger directories indexing attribute field contains a series of references to file index buffers a file index buffer is a cluster that contains the series of file indexes for the files within that directory

Encryption – simple explanation Encryption is a mechanism by which you can transform the content of a file into something that appears meaningless by applying an algorithm to change the data (decryption restores original meaningful file content) The precise way in which the data is changed can be made to depend upon a key value (which is a parameter to the encryption algorithm) if the encryption algorithm is a good one you can only decrypt the file (get the original content back) if you have the key. Hence important to have a key that is kept secure and is hard to guess

Encrypting File System To provide additional levels of security the NTFS provides an encryption & decryption service known as the Encrypting File System (EFS) Using this a user can encrypt/decrypt specific individual files or whole directories (and sub-directories) EFS was a separate file system driver in Windows 2000, but in XP onwards has been integrated into NTFS itself

Encryption process When encrypting a file Windows generates a random key FEK (File Encryption Key) Windows uses an industry standard encryption algorithm AES (Advanced Encryption Standard) or 3DES (Triple Data Encryption Standard) These are symmetric key encryption algorithms that are suitable for encrypting large amounts of data

Encryption keys Windows stores the FEK as part of the file it has encrypted – so how to stop someone decrypting the file by using the FEK that is held as part of the file? Windows encrypts the FEK itself using RSA an asymmetric key algorithm – these are only suitable for encrypting small amounts of data (which the FEK is) RSA uses a public key in its encryption/and a separate private key in decryption

Encryption keys (Cont.) Anyone who has the private key can decrypt the FEK – so Windows needs to keep that private key safe Windows stores the private key that is used for decryption in a subdirectory of the user profile directory and encrypts all the keys and files in that subdirectory using a AES/3DES using a master key But how do we keep the master key safe?

Encryption keys (Cont.) Master key is also stored with the user profile information and encrypted in turn by a key that is based on the user password This key is constructed at logon and held in the OS address space (i.e. in main memory) – ready to be used – but not written to the disk

Encryption keys (Cont.) Problem is – master key is only as good as the user password i.e. you might be able to guess the password (based on information you know about the person) or try out different keys (a key search) but rather than trying all possible keys (takes too long) you try likely keys (based on likely passwords, e.g. dictionary words/names, etc) So maybe not as secure as it seems

References Operating System Concepts. Chapter 22.