Code Integrity (ci.dll) Security Policy Windows 7 Code Integrity (ci.dll) Security Policy For FIPS 140-2 Validation v 4.1 06/1/10 1 INTRODUCTION .................................................................................................................. 2 1.1 Cryptographic Boundary for CI.DLL ............................................................................................ 2 2 SECURITY POLICY .............................................................................................................. 2 2.1 CI.DLL Security Policy Elements .................................................................................................. 2 2.2 Code Integrity security policy ...................................................................................................... 4 3 CI.DLL PORTS AND INTERFACES ..................................................................................... 5 3.1 CI.DLL export functions ................................................................................................................ 5 3.1.1 CiInitialize() ................................................................................................................................. 5 3.1.2 CiValidateImageHeader() ............................................................................................................ 5 3.1.3 CiValidateImageData() ................................................................................................................ 6 3.2 CI.DLL Data Input Interface......................................................................................................... 6 3.3 CI.DLL Data Output Interface ...................................................................................................... 6 3.4 CI.DLL Control Input Interface .................................................................................................... 6 3.5 CI.DLL Status Output Interface ................................................................................................... 6 4 SPECIFICATION OF ROLES ............................................................................................... 6 4.1 Maintenance Roles ......................................................................................................................... 7 4.2 Multiple Concurrent Interactive Operators ............................................................................... 7 5 CRYPTOGRAPHIC KEY MANAGEMENT ............................................................................ 7 6 CI.DLL SELF TESTS ............................................................................................................. 7 7 ADDITIONAL DETAILS ....................................................................................................... 7 This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision) 1 Introduction Code Integrity (CI.DLL) is a Windows 7 feature that verifies the integrity of some key Windows 7 binary image files as they are loaded into memory from the disk. CI.DLL is not a general purpose cryptographic module. It is validated under FIPS 140-2 because it implements cryptographic algorithms and provides the integrity checks of the Windows 7 general purpose cryptographic modules. 1.1 Cryptographic Boundary for CI.DLL The Windows 7 CI.DLL consists of a dynamically-linked library (CI.DLL, version 6.1.7600.16385). The cryptographic boundary for CI.DLL is defined as the enclosure of the computer system, on which CI.DLL is to be executed. The physical configuration of CI.DLL, as defined in FIPS 140-2, is multi-chip standalone. 2 Security Policy 2.1 CI.DLL Security Policy Elements CI.DLL is considered to be in a FIPS mode of operation when the following rules are followed. · CI.DLL is supported on Windows 7. · Windows 7 is an operating system supporting a "single user" mode where there is only one interactive user during a logon session. · CI.DLL is only in the "Approved mode of operation" when Windows is booted normally, meaning Debug mode has not been enabled and Driver Signing enforcement has not been disabled. · CI.DLL operates in FIPS mode of operation only when used with the FIPS approved version of Windows 7 Winload OS Loader (winload.exe) validated to FIPS 140-2 Cert. #1326 operating in FIPS mode The following diagram illustrates the master components of the CI.DLL module This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision) 2 The following diagram illustrates the interaction of CI.DLL with cryptographic modules This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision) 3 NTOSKRNL.EXE Memory Manager CI.DLL (passes module to CI.dll (verifies cryptographic for verification) module integrity using signed hashes prior to execution) I/O Manager (loads module from disk) Loads cryptographic module into memory Crypto Module (implements cryptographic algorithm) 2.2 Code Integrity security policy · CI.DLL's main service is to verify the integrity of digitally signed drivers and components within the computer (such as bcryptprimitives.dll, rsaenh.dll, dssenh.dll). In addition to this service, CI.DLL also provides status services. These status services indicate whether the aforementioned integrity checks passed. · All services implemented within CI.DLL are available to the User and Crypto officer roles. The User and Crypto officer roles are assumed by the operating system or application processes that will invoke binary image verification in CI.dll. The Window Memory Manager is an example. · CI.DLL implements the following FIPS-140-2 Approved algorithms. o RSA PKCS#1 (v1.5) digital signature verification (Cert. #557) o SHA-1 hash (Cert. #1081) o SHA-256 hash (Cert. #1081) o SHA-384 hash (Cert. #1081) o SHA-512 hash (Cert. #1081) · CI.DLL performs the following power-on (start up) self-tests. o SHS (SHA-1) Known Answer Test o SHS (SHA-256) Known Answer Test o SHS (SHA-512) Known Answer Test o RSA verify using a verify test with a Known Signature of the PKCS#1 v1.5 format · CI.DLL verifies the integrity of the Windows 7 general purpose cryptographic modules using the following FIPS-140-2 Approved algorithms. o RSA PKCS#1 (v1.5) verify with public key o SHA-1 hash This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision) 4 o SHA-256 hash o SHA-384 hash o SHA-512 hash Cryptographic bypass is not supported by CI.DLL. CI.DLL was tested using the following machine configurations: x86 Windows 7 Ultimate ­ HP Compaq dc7600 x64 Windows 7 Ultimate ­ HP Compaq dc7600 3 CI.DLL Ports and Interfaces 3.1 CI.DLL export functions The following list contains all the functions exported by CI.DLL to its callers. Note that CI.DLL is not callable outside the kernel. They are explained further in the subsequent subsections. · CiInitialize() · CiValidateImageHeader() · CiValidateImageData() CiInitialize() is directly callable by a kernel mode caller. However, the other two are not. 3.1.1 CiInitialize() CiInitialize() is the function exported by CI.DLL for initializing the image file integrity validation capability of CI.DLL. As the power-on (start up) function of CI.DLL, CiInitialize() conducts the following power-on (start up) self-tests. · SHS (SHA-1) Known Answer Test · SHS (SHA-256) Known Answer Test · SHS (SHA-512) Known Answer Test · RSA verify using a verify test with a Known Signatures of the PKCS#1 v1.5 format: o RSA signature with 1024-bit key and SHA-1 message digest o RSA signature with 2048-bit key and SHA-256 message digest If a self test fails, CiInitialize() returns STATUS_UNSUCCESSFUL. On the other hand, after the successful initialization, CiInitialize() returns a callback structure consisting of the following two functions. A caller subsequently can use these two functions to obtain the image file integrity validation service from CI.DLL. · CiValidateImageHeader() · CiValidateImageData() 3.1.2 CiValidateImageHeader() When a caller (such as the Memory Manager) wants to obtain the set of trusted per-page hashes of an image file, it calls CiValidateImageHeader(). Trusted per-page hashes can use the following algorithms: · SHS (SHA-1) · SHS (SHA-256) · SHS (SHA-384) · SHS (SHA-512) In the case of a Windows 7 general purpose cryptographic module (namely, bcryptprimitives.dll, rsaenh.dll, or dssenh.dll), if CiValidateImageHeader() does not find the set of trusted per-page hashes for the cryptographic module, then CiValidateImageHeader() verifies the full cryptographic module image by verifying a trusted file hash. The trusted file hash may be: This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision) 5 · SHS (SHA-1) · SHS (SHA-256) · SHS (SHA-384) · SHS (SHA-512) If this validation process fails, the cryptographic module is not valid. Subsequently, the Windows 7 Memory Manager does not load any page of the cryptographic module. Both the trusted file image hash and trusted page hashes are signed using the RSA signature algorithm with PKCS#1 v1.5 padding. CI.DLL has a different verification procedure for kernel mode crypto modules that are loaded into memory all at once (not in a per-page fashion as the other user mode general purpose crypto modules). As a result, when CiValidateImageHeader() is called by the memory manager, the CI_VALIDATE_DRIVER_IMAGE flag is set, and the entire image is validated by verifying a trusted image hash. This is similar to the user mode module verification when page hashes are not present. 3.1.3 CiValidateImageData() After calling CiValidateImageHeader() to obtain the set of trusted per-page hashes of an image file, a caller (such as the Memory Manager) would want to know the integrity of a page of the image file. The caller uses CiValidateImageData() to check the page integrity. If the computed hash matches the identified trusted hash, then CiValidateImageData confirms the integrity of the page. Otherwise, CiValidateImageData() returns STATUS_INVALID_IMAGE_HASH. The Windows 7 Memory Manager does not load invalid pages. 3.2 CI.DLL Data Input Interface The Data Input Interface for CI.DLL consists of the three CI export functions. Data and options are passed to the interface as input parameters to the CI export functions. Data Input is kept separate from Control Input by passing Data Input in separate parameters from Control Input. 3.3 CI.DLL Data Output Interface The Data Output Interface for CI.DLL also consists of the three CI export functions. For CiInitialize(), data is returned to its caller as the Callbacks output parameter. For CiValidateImageHeader(), data is returned to its caller as the SePool output parameter. 3.4 CI.DLL Control Input Interface The Control Input Interface for CI.DLL also consists of the three CI export functions. Options for control operations are passed as input parameters to the CI export functions. The SecureRequired parameter in CiValidateImageHeader() is the only control option provided by CI.DLL in the Control Input Interface. 3.5 CI.DLL Status Output Interface The Status Output Interface for CI.DLL also consists of the three CI export functions. For each function, the status information is returned to the caller as the return value (e.g. STATUS_SUCCESS, STATUS_UNSUCCESSFUL, STATUS_INVALID_IMAGE_HASH) from the function. 4 Specification of Roles CI.DLL supports both User and Cryptographic Officer roles (as defined in FIPS-140-2). Both roles have access to all services implemented in CI.DLL through a caller component running in the kernel mode. The This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision) 6 module does not provide authentication, as such both roles are implicitly assumed when the services exported by the module are invoked. 4.1 Maintenance Roles Maintenance roles are not supported by CI.DLL. 4.2 Multiple Concurrent Interactive Operators There is only one interactive operator during a logon session. Multiple concurrent interactive operators sharing a logon session are not supported. 5 Cryptographic Key Management CI.DLL does not handle security-relevant information such as secret and private cryptographic key, authentication data or any other protected information. Hence, there is no operation related to any of the below. · Key generation · Key output · Key storage The only CSPs the module supports are the RSA PKCS#1 public keys used to verify integrity. These CSPs are accessible by both approved roles. The CSPs are stored on the hard-drive. Zeroization is performed by deleting the CI.DLL module, ntph.cat, and ntpe.cat files. 6 CI.DLL Self Tests CI.DLL performs the following power-on (start up) self-tests when a caller calls its CiInitialize(). · SHS (SHA-1) Known Answer Test · SHS (SHA-256) Known Answer Test · SHS (SHA-512) Known Answer Test RSA verify using a verify test with Known Signatures of the PKCS#1 v1.5 format with both 1024-bit keys with SHA1 digest and 2048-bit keys with SHA-256 digest. The integrity of CI.DLL itself is protected by an RSA signature with a 2048-bit key and SHA-256 message digest, which is verified by Winload.exe before CI.DLL is loaded into memory. 7 Additional details For the latest information on Windows 7, check out the Microsoft web site at http://www.microsoft.com. CHANGE HISTORY AUTHOR DATE VERSION COMMENT Ben Nick 5/22/2009 4.0 Updated for Windows 7 RTM 6/1/2010 4.1 Updates based on CMVP comments This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision) 7