Extending Security Functions for Windows NT/2000/XP

Transcription

1 Abstract Extending Security Functions for Windows NT/2000/XP Ing. Martin Kákona S.ICZ a. s., J. Š. Baara 40, České Budějovice, Czech Republic The paper describes the possibilities of adding security extensions to operating systems based on the Windows NT technology. Some of the current security measures within these operating systems and their respective weak points are discussed. Possible improvements to the current architecture and methods of integrating new security mechanisms into the operating system are also outlined. Examples introduce solutions which strengthen the security of existing components of the operating system by adding proven cryptographic functions. Special attention is paid to the protection of key data and the indivisibility of cryptographic functions. Protection against information disclosure during malfunction of the operating system is stressed. The paper also focuses on hardware cryptographic devices, their support by the operating system and their importance from the viewpoint of the overall system security. Keywords: CryptoAPI - Cryptographic Application Programming Interface, CSP Cryptographic Service Provider, FSFD File system Filter Driver, EFS Encrypting File System, Chip Card, Smart Card, Key Container, Cryptographic Adapter, GINA, Secure Desktop. 1 Introduction This paper will discuss selected security subsystems of operating systems based on Windows NT, their advantages, weak points and possible improvements. For the purposes of this paper, no strict distinction will be made between Windows NT, Windows 2000 and Windows XP operating systems. This is based on the fact that the core of all of these OS's is identical as far as security is concerned. Individual differences of those systems are above the extent of this paper and will be discussed only where necessary. In the following text, we will mostly refer to Windows 2000, a version of the Windows NT OS containing the full range of security subsystems described here. When referring to Windows NT, we mean the entire operating system group of Windows NT/2000/XP. 2 Authentication User authentication under Windows NT uses a module called Winlogon.EXE. This module provides authentication for the LSA subsystem, which manages Access Control. See Figure 1 for a structure diagram. An important characteristic of the Windows NT authentication is the fact that the user undergoes authentication within a so called Secure Desktop. This represents an important security feature and solves the problem of uncontrolled infiltration of authentication data. Switching to the Secure Desktop uses SAS (Secure Attention Sequence), which is, in its correct implementation, unmonitorable by the operating system applications. The SAS must be knowingly initiated by the user. This involves the famous Ctrl+Alt+Del keyboard shortcut, or for example an insertion of a chip card into the reader unit. (The second possibility is not as simple as it sounds and will be discussed later in this paper in the chapter about Smart Cards). Security and Protection of Information

2 Figure 1: Authentication modules structure. Besides authentication using the Winlogon module, Windows NT also provides the possibility of direct authentication from applications, as shown on Figure 2. This option is not completely secure and applications using it should be avoided. The main problem with this type of authentication is the fact that it is not done in the Secure Desktop and thus may be infiltrated by an eventual malicious application. The entire interaction with the user is left to the client application and the user can not control it. Figure 2: Direct Application Authentication. Let us have a look at authentication from another perspective. Which protocols are used for the authentication process itself? In Windows NT-type systems, several authentication protocols are implemented. Native protocols include: LM, NTLM v.1, NTLM v.2 and Kerberos v.5. LM Authentication and NTLM v.1 protocols, which are provided in Windows systems for compatibility reasons only, should not be used. These protocols contain several significant errors and their use is unsafe. Let us concentrate on the comparison between the NTLM 2 and the Kerberos protocols. We will not quote details of the individual protocols because they have not been published by Microsoft. For our purposes, general information contained in platform documentation [2] and definitions in literature [1] will be sufficient. The NTLM protocol is known for being a challenge/response-type protocol and the fact the user password is not transferred when it is used. The strength of this protocol will therefore depend on the quality of the encryption used to encrypt the challenge and on the method of generating the key used for this purpose. Kerberos is basically a challenge/response-type protocol as well. The difference is that under NTLM, the authentication is a two-point type (client versus server), while three-point authentication is used for Kerberos (client versus KDC and then versus the server). Kerberos is therefore not so much of a security feature for Windows OS, as is commonly assumed, but rather a practical feature enabling effective secondary authentication of the user with more servers and services. Another difference between the protocols is their encryption algorithms. The NTLM v.2 protocol uses the HMAC_MD5 algorithm with a 128 bite key and Kerberos uses the RC-4 algorithm with a 128 bite key and/or 56 bite key for international versions. In both cases the cipher-keys are derived from 62 Security and Protection of Information 2003

3 the Logon Password using the hash function. A 128 bite cipher-key corresponds to an alphanumeric password with approximately 21 characters! The length of passwords should not be underestimated, for example a brute force attack against a 6-character password on a single processor computer takes less than 3 days. This is based on the presumption that DES and RC-4 algorithm weaknesses discovered to date can not be used, as they are eliminated by the password hash function. The above example shows that the quality of User Passwords is the key to Windows OS security and that passwords must be stored in Security Tokens, because high quality passwords can not be remembered by humans. The main possibility for improvement of authentication processes under Windows NT is the replacement of the GINA module providing interaction with the user. This would enable saving of the password on a suitable medium, for example a chip card, which ensures both its protection and required quality. The second possibility, also involving Smart Cards, is to use the PKINIT extension of the Kerberos protocol. In this case the encryption does not use a password image as in the classic Kerberos version, but the KDC sends a Session Key to the user encrypted by that user's Public Key. Thus the secret information does not leave the Smart Card. This process is described in detail in [6]. We will discuss Security Tokens more detail later. 3 Cryptography Windows NT OS contains the CryptoAPI cryptography subsystem, a robust implementation of a cryptography functions library based on Public Key Cryptography. CryptoAPI is described in detail in literature [3]. The original purpose of CryptoAPI, which Microsoft still strives to achieve, was to unify cryptography functions into an uniform API and thus enable their uniform implementation. This not only unifies the ciphering algorithms implementation, but also data formats and other implementation details. Figure 3: The CryptoAPI Architecture. The CryptoAPI subsystem may be extended to include other algorithm implementations using CSP modules via a CryptoSPI interface, as shown on Figure 3. Figure 4 shows three possible CSP implementations. User Mode CSP Interface Cryptography Core CSP Interface CSP Interface Kernel Mode Cryptography Core Inner Interface Hardware Equipment Cryptography Core Figure 4: Possible CSP Implementations. Security and Protection of Information

4 The left-hand side shows a standard implementation. All CSP's which are native part of NT and most commercially available CSP's are implemented in this way. The central part shows a compromise where the CSP itself is implemented as a Wrapper only and the cryptography functions are implemented by a driver at the core level of the operating system, which provides a better division of cryptography from applications. The solution shown on the right-hand side implements cryptographic functions on another piece of hardware from that on which the operating system is running. Such solution is very resistant to operating system errors. When the OS generates an error the cryptography module is not in immediate danger. It is for example ensured that the key is not compromised during an OS malfunction, because on correct implementation the key never leaves the cryptographic hardware. Such a situation could only occur as a result of faulty firmware on the cryptographic hardware. This firmware, however, is much less complicated than the host OS and may be programmed as more robust and it can be tested extensively. A combination of complete implementation of cryptography functions in a specialized hardware with the previous method, that is implementation of cryptography functions in to the kernel mode driver, is also possible. In such case it is advisable that only key derivates leave the cryptography hardware. This ensures that during an OS malfunction only the keys used to decrypt/encrypt data processed by the OS at that moment and that data may be compromised. I would also like to call attention to and aspect concerning the use of CryptoAPI. Unfortunately, some applications do not use CryptoAPI in the way it designed. They may expect a certain concrete implementation of the encryption mode, or require outdated data formats, or algorithms against which attacks have been published. The fact that applications are not universally programmed makes the CSP programmers retort to tricks which then make their CSP's incompatible with other implementations. But this is justifiable when a securityprioritised solution is needed. The use of CryptoAPI also concerns PKI. Because CryptoAPI is based on asymmetric cryptography, we must build and operate an entire infrastructure to be able to use it. Description of individual measures and rules is above the scope of this paper, I would just like to point out that in certain cases the use of symmetric cryptography is more effective. The main is the protection of private keys must always be a priority. 4 Directory Services & IPSec Directory Services in the Windows 2000 OS are implemented in the Active Directory (AD). I mention Active Directories here to call attention to security risks associated with their use. From the security point of view, there are two interesting aspects: AD s may be used to store user password images, secret and public keys, certificates, and other sensitive data. AD s are replicated between servers. From the above it is clear that AD's contain private information belonging to different users. During replication and protection of the replicating channel using IPSec (the only built-in replication protection measure) the data is transferred over a point-to-point channel and one shared key is used to protect the transfer of different data. I see this as a potential security risk, because the minimum resulting security of all secure systems dependent on information stored in AD's is only as good as the AD replication protection we use. In a network environment using AD's, it is advisable to store users' private secret information in tokens, even if that means losing the advantage of central administration and distribution of this data. 5 File Encryption File encryption in Windows NT OS is implemented using the EFS. This extension of the NTFS file system is described in detail in [4] and its possibilities and weak points have been described in the NSA Report [5]. EFS is more a method for encryption a local drive than a real implementation of file encryption. Unlike Disk Encryption, the EFS offers the separation of locally stored data (on one drive) belonging to different users at the level of individual files. On the other hand sharing of encrypted data between several users is practically impossible when using the EFS, because the GUI can not be used to specify storing of several DDF s (Data Decryption Fields) for files in one directory. 64 Security and Protection of Information 2003

5 The practical value of such a system is questionable as it does not enable transfer of encrypted files to another medium (for example a CD-ROM or a network server). Removal of the residual information, for example in the Page File, is also not satisfactorily solved by Windows. The only practical use is protection of data from being stolen with the use of physical access to the disk. But when using EFS, we must still control physical access to the disc because of the residual information. When we assume that the attacker does not have physical access to the disc, the need to encrypt files is redundant, because a regularly operating OS is capable of controlling access rights to the files. Another big disadvantage of the EFS is the fact that it does not provide the possibility to select or modify the cryptography used in it. EFS is a typical example of a Windows subsystem which does not use CryptoAPI. CryptoAPI is used with EFS to implement key sharing, but it is reduced to the use of a single CSP, which can not be changed. A single Key Container is also used for all files. A workstation may not be operated in several modes, only in the reserved mode where the access to classified data remains the same level for the entire logon period of one user. The Key Container can not be saved to a Smart Card or another token. The DESX symmetrical encryption algorithm can not be changed either, because for implementation reasons it is not part of CryptoAPI but is implemented directly in EFS. The Windows could therefore be extended to include File Encryption independent on the file system and ensuring transfer of encrypted files over the network and other mediums. The file encryption is only effective if we transfer complete files over the network. Should partial transfers be used and should an attacker be capable of monitoring such partial transfers, in other words should the attacker gain access to different versions of the same file, he would be capable of identifying the location of the modified data in the file with the accuracy the size of a cipher block size, or the size of a chaining block. Such identification could compromise the information dependent on location of the file. The same applies to EFS, because EFS implements chaining by 512 bytes. Let us imagine that an attacker gains access to a computer hard disc two times in a row and does not know the cipher-key. He is not capable to decrypt the data, but the position of changed sectors could give him some information, especially if he has the file which the change was made to in an open form. An example we could have a map available for the general public on which someone have marked a certain location of secret object and information concerning that location are secret. From the changed ciphered data in this example we can determine that location without the knowledge of cipher-key (with an accuracy given by the map scale and the size of the data block over which chaining is done). Correct implementation of file encryption therefore also includes ensuring of correct application operation. Two approaches are possible, either a new file is created every time a file is changed, or the changes must be saved at the end of the file. In the former case, new encryption for the new file is initialised, because two identical files must never have the same encrypted image. In the later case, diversification of the encrypted image of identical and repeating data sequences in the file must be ensured. Correct application operation and correct encryption implementation results in the changed file only offering information about the size of the realized changes. 6 Smart Card Support The following problems are usually encountered when using Smart Cards: A secure authentication of the user to the chip card must be ensured. Secret information transferred by a chip card to the OS mustn t be compromised. The user must have control of when and for what purpose the secret information stored on the chip card is used. Windows NT OS includes an universal subsystem supporting chip cards PC/SC. Figure 5 shows its structure. The figure shows that interface is provided by group of Dynamic Loadable Libraries (DDL), which applications call from the User Mode. The level of security of communication with a chip card therefore depends on the application communicating with the card, because the DLL's run in the context of that application. Security and Protection of Information

6 Figure 5: PC/SC Structure. The main usage of Smart Cards in the system is under CryptoAPI. As explained above, the safest implementation of a CryptoAPI is on the right hand-side of Figure 4. From this the configuration shown on Figure 6 follows. The CryptoAPI concept is based on the principle of secret keys not leaving the CSP. In this case the use of the PC/SC subsystem which has its interface in the User Mode is not advisable for communication with the chip card. It is also not advisable for the user interaction with the chip card (PIN entering, secret key use report) to be implemented in the User Desktop. As we know, a Secure Desktop is provided for such interactions in Windows NT. For example the insertion of a chip card into the reader unit should not be communicated to the user's desktop so that it can not be infiltrated by applications running under that desktop. Application 1 Application k User Interface GINA CryptoAPI CSP 1 CSP n Key containers HW Driver Key containers Smart Card Figure 6: Correct Integration of Smart Cards into Windows NT. The correct implementation of a chip card is to include it into the OS core under the CSP module and into the GINA module, which is capable of processing the SAS from the insertion of the chip card into the reader unit. 66 Security and Protection of Information 2003

7 And last a note about generation of private keys. The above example shows that it would be beneficial for the private key not to leave the data medium (Smart Card) and be generated directly on it. But that would require the Smart Card to include a Random Generator capable of generating random numbers from which the secret key may be derived. Smart Cards available at the present time do not include generators with sufficient reliability. To be more exact the functionality is usually not documented and tested extensively. For these reasons it is advisable to leave this function to the cryptographic adapter in hardware CSP implementation. 7 OS Integrity Checks The Windows NT OS is capable of ensuring its integrity using Access Control as long as OS is installed on the NTFS and the installation meets the security requirements. Problems start when the operation system is not running. It is therefore necessary to ensure safe OS start and prevent its modification while it is not running. Disabling of modification during power off is easy to ensure using seals. The station's BIOS is then responsible for the time between power on and start of the OS loader. It is also possible for this control function to be provided by the Extended BIOS of the encryption hardware (implemented as a firmware extension). This option should be preferred as the encryption adaptor code may be easily verified and is certified, unlike BIOS on individual stations. 8 Conclusion We have shown possible improvements of security functions of Windows NT-based operating systems. Note that most of these solutions are based on additional hardware and/or firmware. This is a result of the complexity of Windows NT OS and the resulting difficult verification of its source code. The solutions described here are all based on minimization of the code necessary to ensure the system's security functions. At the same time the code must be located so that an eventual error in the operating system does not corrupt the security subsystem. References [1] J. Kohl, C. Neuman: RFC1510. Network Working Group, [2] Platform SDK documentation: Logon Authentication. Microsoft, [3] Platform SDK documentation: Cryptography. Microsoft, [4] Mark Russinovich: Inside Encrypting File System. Windows NT Magazine, Duke Communications, [5] G. Bucholz, H. Parkes: Guide to Securing Microsoft Windows 2000 Encrypting File System. NSA, SNAC, [6] White paper: Windows 2000 Kerberos Authentication. Microsoft, Security and Protection of Information