BitLocker Windows Resume    Security Policy for FIPS 140‐2 Validation  BitLocker® Windows Resume (winresume) in Microsoft Windows 8.1 Enterprise Windows Server 2012 R2 Windows Storage Server 2012 R2 Surface Pro 2 Surface Pro Windows Embedded 8.1 Industry Enterprise StorSimple 8000 Series               DOCUMENT INFORMATION      Version Number  1.9  Updated On  April 13, 2015          © 2015 Microsoft. All Rights Reserved     Page 1 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume     The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. This work is licensed under the Creative Commons Attribution-NoDerivs- NonCommercial License (which allows redistribution of the work). To view a copy of this license, visit http://creativecommons.org/licenses/by-nd-nc/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. © 2015 Microsoft Corporation. All rights reserved. Microsoft, Windows, the Windows logo, Windows Server, and BitLocker are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.     © 2015 Microsoft. All Rights Reserved     Page 2 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume     CHANGE HISTORY  Date  Version  Updated By  Change  29 OCT 2013  0.1  Tim Myers  First Draft  7 MAY 2014  0.2  Tim Myers  Second Draft; FIPS 186‐4 and FIPS 180‐4 updates  1 JUL 2014  0.3  Tim Myers  Third Draft; added Security Levels Table and  cryptographic algorithm certificate numbers  11 JUL 2014  1.0  Tim Myers  First Release to Validators; includes all algorithm and  module certificate numbers  18 JUL 2014  1.1  Tim Myers  Update platforms; consolidate services  12 DEC 2014  1.2  Tim Myers  Address CMVP comments; update platform names  17 DEC 2014  1.3  Tim Myers  Update IG G.5 platforms; update binary versions; add  StorSimple  15 JAN 2015  1.4  Tim Myers  Address CMVP comments  29 JAN 2015  1.5  Tim Myers  Update Design Assurance  20 FEB 2015  1.6  Tim Myers  Add StorSimple to Validated Platforms  9 MAR 2015  1.7  Tim Myers  Prepare for publication  17 MAR 2015  1.8  Tim Myers  Reorder StorSimple 8100 OE description; fix typos in  Section 9  13 APR 2015  1.9  Tim Myers  Specify AES‐GCM decryption approved algorithm      © 2015 Microsoft. All Rights Reserved     Page 3 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume     TABLE OF CONTENTS  1  INTRODUCTION .................................................................................................................... 6  1.1  LIST OF CRYPTOGRAPHIC MODULE BINARY EXECUTABLES ................................................................... 6  1.2  BRIEF MODULE DESCRIPTION  ...................................................................................................... 6  . 1.3  VALIDATED PLATFORMS ............................................................................................................. 8  1.4  CRYPTOGRAPHIC BOUNDARY ....................................................................................................... 9  2  SECURITY POLICY ................................................................................................................ 10  2.1  FIPS 140‐2 APPROVED ALGORITHMS  ......................................................................................... 12  . 2.2  NON‐APPROVED ALGORITHMS .................................................................................................. 12  2.3  CRYPTOGRAPHIC BYPASS .......................................................................................................... 12  2.4  MACHINE CONFIGURATIONS ...................................................................................................... 12  3  OPERATIONAL ENVIRONMENT ............................................................................................ 12  4  INTEGRITY CHAIN OF TRUST ................................................................................................ 12  4.1  CONVENTIONAL BIOS AND UEFI WITHOUT SECURE BOOT ENABLED .................................................. 12  4.2  UEFI WITH SECURE BOOT ENABLED ............................................................................................ 12  5  PORTS AND INTERFACES ..................................................................................................... 13  5.1  CONTROL INPUT INTERFACE ....................................................................................................... 13  5.2  STATUS OUTPUT INTERFACE ...................................................................................................... 13  5.3  DATA OUTPUT INTERFACE ......................................................................................................... 13  5.4  DATA INPUT INTERFACE ............................................................................................................ 13  6  SPECIFICATION OF ROLES .................................................................................................... 13  6.1  MAINTENANCE ROLES .............................................................................................................. 13  6.2  MULTIPLE CONCURRENT INTERACTIVE OPERATORS ......................................................................... 14  7  SERVICES  ............................................................................................................................ 14  . 7.1  SHOW STATUS SERVICES ........................................................................................................... 14  7.2  SELF‐TEST SERVICES ................................................................................................................. 14  © 2015 Microsoft. All Rights Reserved     Page 4 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume     7.3  SERVICE INPUTS / OUTPUTS ...................................................................................................... 14  8  CRYPTOGRAPHIC KEY MANAGEMENT ................................................................................. 14  8.1  ACCESS CONTROL POLICY .......................................................................................................... 14  9  SELF‐TESTS .......................................................................................................................... 14  9.1  POWER‐ON SELF TESTS ............................................................................................................ 14  9.2  CONDITIONAL SELF‐TESTS ......................................................................................................... 15  10  DESIGN ASSURANCE  ........................................................................................................... 15  . 11  MITIGATION OF OTHER ATTACKS ........................................................................................ 16  12  SECURITY LEVELS................................................................................................................. 17  13  ADDITIONAL DETAILS .......................................................................................................... 17  14  APPENDIX A – HOW TO VERIFY WINDOWS VERSIONS AND DIGITAL SIGNATURES ............... 18  14.1  HOW TO VERIFY WINDOWS VERSIONS  ........................................................................................ 18  . 14.2  HOW TO VERIFY WINDOWS DIGITAL SIGNATURES .......................................................................... 18        © 2015 Microsoft. All Rights Reserved     Page 5 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume     1 Introduction BitLocker ® Windows Resume, WINRESUME.EXE, is an operating system loader which loads the  Microsoft Windows 8.1 Enterprise, Windows Server 2012 R2, Windows Storage Server 2012 R2, Surface  Pro 2, Surface Pro, Windows Embedded 8.1 Industry Enterprise, and StorSimple 8000 Series (herein  referred to as Windows 8.1 OEs) operating system kernel (ntoskrnl.exe) and other boot stage binary  image files, as well as previous operating system state information, when Windows has been previously  put into a sleep (S3) or hibernate (S4) power state. Throughout this document, BitLocker ® Windows  Resume may be called Windows Resume for short.  1.1 List of Cryptographic Module Binary Executables WINRESUME.EXE – Versions 6.3.9600 and 6.3.9600.17031 for Windows 8.1 OEs on systems using  conventional BIOS.  WINRESUME.EFI – Versions 6.3.9600 and 6.3.9600.17031 for Windows 8.1 OEs on systems using UEFI  firmware.  1.2 Brief Module Description Windows Resume is the binary executable that handles loading the Windows operating system when  resuming from hibernation. At resume time, if BitLocker is enabled, the encrypted hibernation data is  decrypted as it is paged back into memory.  © 2015 Microsoft. All Rights Reserved     Page 6 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume       Figure 1 - Logical Operation of Module (this cryptographic module is in orange, other BitLocker-related cryptographic modules are in blue)     © 2015 Microsoft. All Rights Reserved     Page 7 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume     1.3 Validated Platforms The Windows Resume components listed in Section 1.1 were validated using the following machine  configurations:  1. Microsoft Windows 8.1 Enterprise (x86) running on a Dell PowerEdge SC440 without AES‐NI;  2. Microsoft Windows Embedded 8.1 Industry Enterprise (x86) running on a Dell PowerEdge SC440  without AES‐NI;  3. Microsoft Windows 8.1 Enterprise (x86) running on a Dell Dimension E521 without AES‐NI;  4. Microsoft Windows Embedded 8.1 Industry Enterprise (x86) running on a Dell Dimension E521  without AES‐NI;  5. Microsoft Windows 8.1 Enterprise (x86) running on an Intel Core i7 with AES‐NI running on an  Intel Maho Bay;   6. Microsoft Windows Embedded 8.1 Industry Enterprise (x86) running on an Intel Core i7 with  AES‐NI running on an Intel Maho Bay;  7. Microsoft Windows 8.1 Enterprise (x86) running on an HP Compaq Pro 6305 with AES‐NI;  8. Microsoft Windows Embedded 8.1 Industry Enterprise (x86) running on an HP Compaq Pro 6305  with AES‐NI;  9. Microsoft Windows 8.1 Enterprise (x64) running on a Dell PowerEdge SC440 without AES‐NI;  10. Microsoft Windows Embedded 8.1 Industry Enterprise (x64) running on a Dell PowerEdge SC440  without AES‐NI;  11. Microsoft Windows Server 2012 R2 (x64) running on a Dell PowerEdge SC440 without AES‐NI;   12. Microsoft Windows Storage Server 2012 R2 (x64) running on a Dell PowerEdge SC440 without  AES‐NI;  13. Microsoft Windows 8.1 Enterprise (x64) running on a Dell Dimension E521 without AES‐NI;  14. Microsoft Windows Embedded 8.1 Industry Enterprise (x64) running on a Dell Dimension E521  without AES‐NI;  15. Microsoft Windows Server 2012 R2 (x64) running on a Dell Dimension E521 without AES‐NI;  16. Microsoft Windows Storage Server 2012 R2 (x64) running on a Dell Dimension E521 without  AES‐NI;  17. Microsoft Windows 8.1 Enterprise (x64) running on an Intel Core i7 with AES‐NI running on an  Intel Maho Bay;  18. Microsoft Windows Embedded 8.1 Industry Enterprise (x64) running on an Intel Core i7 with  AES‐NI running on an Intel Maho Bay;  19. Microsoft Windows Server 2012 R2 (x64) running on an Intel Core i7 with AES‐NI running on an  Intel Maho Bay;  20. Microsoft Windows Storage Server 2012 R2 (x64) running on an Intel Core i7 with AES‐NI  running on an Intel Maho Bay;  21. Microsoft Windows 8.1 Pro (x64) running on an Intel x64 Processor with AES‐NI running on a  Microsoft Surface Pro;   22. Microsoft Windows 8.1 Pro (x64) running on an Intel i5 with AES‐NI running on a Microsoft  Surface Pro 2;  23. Microsoft Windows 8.1 Enterprise (x64) running on an HP Compaq Pro 6305 with AES‐NI;  24. Microsoft Windows Embedded 8.1 Industry Enterprise (x64) running on an HP Compaq Pro 6305  with AES‐NI;  25. Microsoft Windows Server 2012 R2 (x64) running on an HP Compaq Pro 6305 with AES‐NI;   26. Microsoft Windows Storage Server 2012 R2 (x64) running on an HP Compaq Pro 6305 with AES‐ NI;  © 2015 Microsoft. All Rights Reserved     Page 8 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume     27. Microsoft Windows 8.1 Enterprise (x64) running on a Dell Inspiron 660s without AES‐NI and with  PCLMULQDQ and SSSE 3;  28. Microsoft Windows Embedded 8.1 Industry Enterprise (x64) running on a Dell Inspiron 660s  without AES‐NI and with PCLMULQDQ and SSSE 3;  29. Microsoft Windows Server 2012 R2 (x64) running on a Dell Inspiron 660s without AES‐NI and  with PCLMULQDQ and SSSE 3;  30. Microsoft Windows Storage Server 2012 R2 (x64) running on a Dell Inspiron 660s without AES‐NI  and with PCLMULQDQ and SSSE 3;  31. Microsoft Windows 8.1 Enterprise (x64) running on an Intel Core i5 with AES‐NI and with  PCLMULQDQ and SSSE 3 running on a Microsoft Surface Pro 2;  32. Microsoft Windows Embedded 8.1 Industry Enterprise (x64) running on an Intel Core i7 with  AES‐NI and with PCLMULQDQ and SSSE 3 running on an Intel Maho Bay;  33. Microsoft Windows Server 2012 R2 (x64) running on an Intel Core i7 with AES‐NI and with  PCLMULQDQ and SSSE 3 running on an Intel Maho Bay;  34. Microsoft Windows Storage Server 2012 R2 (x64) running on an Intel Core i7 with AES‐NI and  with PCLMULQDQ and SSSE 3 running on an Intel Maho Bay;  35. Microsoft Windows 8.1 Enterprise (x64) running on an HP Compaq Pro 6305 with AES‐NI and  with PCLMULQDQ and SSSE 3;  36. Microsoft Windows Embedded 8.1 Industry Enterprise (x64) running on an HP Compaq Pro 6305  with AES‐NI and with PCLMULQDQ and SSSE 3;  37. Microsoft Windows Server 2012 R2 (x64) running on an HP Compaq Pro 6305 with AES‐NI and  with PCLMULQDQ and SSSE 3;  38. Microsoft Windows Storage Server 2012 R2 (x64) running on an HP Compaq Pro 6305 with AES‐ NI and with PCLMULQDQ and SSSE 3;  39. Windows Server 2012 R2 (x64) running on a Microsoft StorSimple 8100 with an Intel Xeon E5‐ 2648L without AES‐NI;  40. Windows Server 2012 R2 (x64) running on a Microsoft StorSimple 8100 with an Intel Xeon E5‐ 2648L with AES‐NI   Windows Resume maintains FIPS 140‐2 validation compliance (according to FIPS 140‐2 PUB  Implementation Guidance G.5) on the following platforms:  x86 Microsoft Windows 8.1  x86 Microsoft Windows 8.1 Pro    x64 Microsoft Windows 8.1  x64 Microsoft Windows Server 2012 R2 Datacenter    x64‐AES‐NI Microsoft Windows 8.1  x64‐AES‐NI Microsoft Windows Server 2012 R2 Datacenter    1.4 Cryptographic Boundary The software cryptographic boundary for Windows Resume is defined as the binaries WINRESUME.EXE  and WINRESUME.EFI.   © 2015 Microsoft. All Rights Reserved     Page 9 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume     2 Security Policy  Windows Resume operates under several rules that encapsulate its security policy.    Windows Resume is validated on Windows 8.1 Enterprise and Microsoft Windows Embedded  8.1 Industry Enterprise running on x86 and x64.   Windows Resume is validated on Windows Server 2012 R2 and Windows Storage Server 2012 R2  running on x64.   Windows Resume operates in FIPS mode of operation only when used with the FIPS validated  version of Windows 8.1 OEs Boot Manager (bootmgr) validated to FIPS 140‐2 under Cert. #2351  operating in FIPS mode.   Windows 8.1 OEs are operating systems supporting a “single user” mode where there is only  one interactive user during a logon session.    Windows Resume is only in its Approved mode of operation when Windows is booted normally,  meaning Debug mode is disabled and Driver Signing enforcement is enabled.   The Debug mode status and Driver Signing enforcement status can be viewed by using the  bcdedit tool.      The following diagram illustrates the master components of the Windows Resume module:        © 2015 Microsoft. All Rights Reserved     Page 10 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume     The following diagram illustrates Windows Resume module interaction with other cryptographic  modules:  Winresume.exe Code Integrity verifies module integrity prior to execution File IO Code Integrity (Loads file from disk (verifies cryptographic into memory) module integrity) Loads module into memory Cryptographic Module (Implements cryptographic algorithms)      Windows Resume’s main service is to load the Windows 8.1 OEs operating system kernel  (ntoskrnl.exe) and other boot stage binary image files, including Code Integrity cryptographic  module (ci.dll), after it validates their integrity using its cryptographic algorithm  implementations using the FIPS 140‐2 approved algorithms mentioned below. After the verified  kernel and boot stage binary image files, including Code Integrity, are loaded, Windows Resume  passes the execution control to the kernel and it terminates its own execution. In addition to  this service, Windows Resume also provides status and self‐test services. The Crypto officer and  User have access to all services WINRESUME supports.   If the integrity of the kernel or Code Integrity is not verified, Windows Resume does not transfer  the execution to the kernel.    The module provides a power‐up self‐tests service that is automatically executed when the  module is loaded into memory. The module also provides a show status service that is  automatically executed by the module to provide the status response of the module either via  output to the GPC monitor or to log files.   Windows Resume verifies the integrity of multiple kernel mode crypto modules. This verification  relies on RSA 2048‐bit signature verification using SHA‐256. If the verification fails, the modules  are not loaded into memory, and this will prevent Windows from booting. The following binaries  are verified in this manner:  o CI.DLL   o CNG.SYS    © 2015 Microsoft. All Rights Reserved     Page 11 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume     2.1 FIPS 140‐2 Approved Algorithms Windows Resume implements the following FIPS‐140‐2 Approved algorithms:   FIPS 186‐4 RSA PKCS#1 (v1.5) digital signature verification (Cert. #1494)  o RSA signature verification with 1024‐bit keys and SHA‐1 message digest  o RSA signature verification with 2048‐bit keys and SHA‐256 message digest   FIPS 180‐4 SHS (SHA‐1, SHA‐256, SHA‐384, SHA‐512) (Certs. #2373 and #2396)   AES GCM decryption (Cert. #2832)  2.2 Non‐Approved Algorithms Windows Resume also includes a legacy implementation of MD5.  2.3 Cryptographic Bypass Cryptographic bypass is not supported by Windows Resume.  2.4 Machine Configurations BitLocker Windows Resume was tested using the machine configurations listed in Section 1.3 ‐ Validated  Platforms.  3 Operational Environment The operational environment for Windows Resume is Windows 8.1 OEs running on the software and  hardware configurations listed in Section 1.3 ‐ Validated Platforms. Windows Resume services are only  available before the startup of the operating system. This is done inside the Trusted Computing Base  (TCB).   4 Integrity Chain of Trust 4.1 Conventional BIOS and UEFI without Secure Boot Enabled Boot Manager is the start of the chain of trust. It cryptographically checks its own integrity during its  startup. It then cryptographically checks the integrity of Windows Resume (if resuming from  hibernation) before starting it. Windows Resume then checks the integrity of the Code Integrity crypto  module, the operating system kernel, and other boot stage binary images. An RSA signature with a  2048‐bit key and SHA‐256 message digest are used.  4.2 UEFI with Secure Boot Enabled On UEFI systems with Secure Boot enabled, Boot Manager is still the OS binary from which the integrity  of all other OS binaries is rooted, and it does cryptographically check its own integrity.  However, Boot  Manager’s integrity is also checked and verified by the UEFI firmware, which is the root of trust on  Secure Boot enabled systems. An RSA signature with a 2048‐bit key and SHA‐256 message digest are  used.  © 2015 Microsoft. All Rights Reserved     Page 12 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume     5 Ports and Interfaces 5.1 Control Input Interface The Windows Resume Control Input Interface is the set of internal functions responsible for intercepting  control input. These functions are:   BlBdInitialize – Reads the system status to determine if a boot debugger is attached.   OslMain – This function receives and parses the Boot Application parameters, which are passed  to the module when execution is passed from Boot Manager.   BlInitializeLibrary – Performs the parsing Boot Application parameters.   BlXmiRead – Reads the operator selection from the Winload user interface.  5.2 Status Output Interface The Status Output Interface is the BlXmiWrite function that is responsible for displaying the integrity  verification errors to the screen. The Status Output Interface is also defined as the BlLogData  responsible for writing the name of the corrupt driver to the bootlog.  5.3 Data Output Interface The Data Output Interface is represented by the OslArchTransferToKernel function and the  AhCreateLoadOptionsString function. OslArchTransferToKernel is responsible for transferring the  execution from Winresume to the initial execution point of the Windows 8.1 OEs kernel. Data exits the  module in the form of the initial instruction address of the Windows 8.1 OEs kernel.  Data exits the module from the AhCreateLoadOptionsString function in the form of boot application  parameters passed to the Windows 8.1 OEs kernel.  5.4 Data Input Interface The Data Input Interface is represented by the BlFileReadEx function and the BlDeviceRead function.  BlFileReadEx is responsible for reading the binary data of unverified components from the computer  hard drive. In addition the BitLocker Full Volume Encryption Key (FVEK) can also be entered into the  module over the module’s data input interface. BlDeviceRead is responsible for reading data directly  from devices.  6 Specification of Roles Windows Resume supports both User and Cryptographic Officer roles (as defined in FIPS‐140‐2). Both  roles have access to all services implemented in Windows Resume. The module does not implement any  authentication services. Therefore, roles are assumed implicitly by booting the Windows 8.1 OEs  operating systems.  6.1 Maintenance Roles Maintenance roles are not supported.  © 2015 Microsoft. All Rights Reserved     Page 13 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume     6.2 Multiple Concurrent Interactive Operators There is only one interactive operator in Single User Mode. When run in this configuration, multiple  concurrent interactive operators are not supported.  7 Services 7.1 Show Status Services The User and Cryptographic Officer roles have the same Show Status functionality, which is, for each  function, the status information is returned to the caller as the return value from the function.  7.2 Self‐Test Services The User and Cryptographic Officer roles have the same Self‐Test functionality, which is described in  Section 9 Self‐Tests.  7.3 Service Inputs / Outputs The User and Cryptographic Officer roles have service inputs and outputs as specified in Section 5 Ports  and Interfaces.  8 Cryptographic Key Management Windows Resume does not store any secret or private cryptographic keys across power‐cycles.  However, it does use an AES key in support of the BitLocker feature. This key is:   Full Volume Encryption Key (FVEK) ‐ 128 or 256‐bit AES key that is used to decrypt data on disk  sectors of the hard drive.  This key is stored in memory and is zeroized by power‐cycling the OS.  Windows Resume also uses the Microsoft root CA public key certificate stored on the computer hard  disk to verify digital signatures using its implementation of RSA PKCS#1 (v1.5) verify. This public key is  available to both roles. Zeroization is performed by deleting the Winresume module.  8.1 Access Control Policy All the keys (mentioned above) are accessed only by the Windows Resume service that loads the  operating system kernel (ntoskrnl.exe) and other boot stage binary image files, including Code Integrity.  This service only has execute access to the keys mentioned above. Due to such simplicity, an access  control policy table is not included in this document.  9 Self‐Tests 9.1 Power‐On Self Tests Windows Resume performs the following power‐on (startup) self‐tests:  © 2015 Microsoft. All Rights Reserved     Page 14 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume      SHS (SHA‐1) Known Answer Test   SHS (SHA‐256) Known Answer Test   SHS (SHA‐512) Known Answer Test   RSA PKCS#1 (v1.5) verify with public key  o RSA signature with 1024‐bit key and SHA‐1 message digest  o RSA signature with 2048‐bit key and SHA‐256 message digest   AES‐CBC ‐ Encrypt/Decrypt Known Answer Tests   AES‐CCM ‐ Encrypt/Decrypt Known Answer Tests      If the self‐test fails, the module will not load and status will be returned. If the status is not  STATUS_SUCCESS, then that is the indicator a self‐test failed.  9.2 Conditional Self‐Tests Windows OS Loader does not perform conditional self‐tests.  10 Design Assurance The secure installation, generation, and startup procedures of this cryptographic module are part of the  overall operating system secure installation, configuration, and startup procedures for the Windows 8.1  OEs. The various methods of delivery and installation for each product are listed in the following table.  Product  Delivery and Installation Method   Windows 8.1  DVD   Pre‐installed on the computer by OEM   Download that updates Windows 8   Windows Server 2012 R2  DVD   Pre‐installed on the computer by OEM   Download that updates Windows Server 2012   Windows Storage Server 2012 R2  Pre‐installed by the OEM (Third party)   Surface Pro 2, Surface Pro  Pre‐installed by the OEM (Microsoft)   Windows Embedded 8.1 Industry  Pre‐installed by the OEM (Third party)  Enterprise   StorSimple 8000 Series  Pre‐installed by the OEM (Third party)    After the operating system has been installed, it must be configured by enabling the "System  cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" policy setting  followed by restarting the system. This procedure is all the crypto officer and user behavior necessary  for the secure operation of this cryptographic module.  © 2015 Microsoft. All Rights Reserved     Page 15 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume     An inspection of authenticity of the physical medium can be made by following the guidance at this  Microsoft web site:  http://www.microsoft.com/en‐us/howtotell/default.aspx  The installed version of Windows 8.1 OEs must be verified to match the version that was validated. See  Appendix A for details on how to do this.  For Windows Updates, the client only accepts binaries signed by Microsoft certificates. The Windows  Update client only accepts content whose SHA‐2 hash matches the SHA‐2 hash specified in the  metadata. All metadata communication is done over a Secure Sockets Layer (SSL) port. Using SSL  ensures that the client is communicating with the real server and so prevents a spoof server from  sending the client harmful requests. The version and digital signature of new cryptographic module  releases must be verified to match the version that was validated. See Appendix A for details on how to  do this.  11 Mitigation of Other Attacks The following table lists the mitigations of other attacks for this cryptographic module:  Algorithm  Protected  Mitigation  Comments  Against  SHA1  Timing  Constant Time Implementation     Analysis  Attack     Cache Attack  Memory Access pattern is     independent of any  confidential data  SHA2  Timing  Constant Time Implementation     Analysis  Attack     Cache Attack  Memory Access pattern is     independent of any  confidential data  AES  Timing  Constant Time Implementation     Analysis  Attack     Cache Attack  Memory Access pattern is  Protected Against Cache  independent of any  attacks only when used with  confidential data  AES NI  © 2015 Microsoft. All Rights Reserved     Page 16 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume     12 Security Levels The security level for each FIPS 140‐2 security requirement is given in the following table.  Security Requirement  Security Level  Cryptographic Module Specification  1  Cryptographic Module Ports and Interfaces  1  Roles, Services, and Authentication  1  Finite State Model  1  Physical Security  NA  Operational Environment  1  Cryptographic Key Management  1  EMI/EMC  1  Self‐Tests  1  Design Assurance  2  Mitigation of Other Attacks  1    13 Additional Details For the latest information on Microsoft Windows, check out the Microsoft web site at:  http://windows.microsoft.com    For more information about FIPS 140 evaluations of Microsoft products, please see:  http://technet.microsoft.com/en‐us/library/cc750357.aspx    © 2015 Microsoft. All Rights Reserved     Page 17 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  BitLocker Windows Resume     14 Appendix A – How to Verify Windows Versions and Digital Signatures 14.1 How to Verify Windows Versions The installed version of Windows 8.1 OEs must be verified to match the version that was validated using  one of the following methods:  1. The ver command  a. From Start, open the Search charm.  b. In the search field type "cmd" and press the Enter key.  c. The command window will open with a "C:\>" prompt.  d. At the prompt, type "ver" and press the Enter key.  e. You should see the answer "Microsoft Windows [Version 6.3.9600]".  2. The systeminfo command  a. From Start, open the Search charm.  b. In the search field type "cmd" and press the Enter key.  c. The command window will open with a "C:\>" prompt.  d. At the prompt, type "systeminfo" and press the Enter key.  e. Wait for the information to be loaded by the tool.  f. Near the top of the output, you should see:  OS Name: Microsoft Windows 8.1 Enterprise OS Version: 6.3.9600 N/A Build 9600 OS Manufacturer: Microsoft Corporation If the version number reported by the utility matches the expected output, then the installed version  has been validated to be correct.  14.2 How to Verify Windows Digital Signatures After performing a Windows Update that includes changes to a cryptographic module, the digital  signature and file version of the binary executable file must be verified. This is done like so:  1. Open a new window in Windows Explorer.  2. Type “C:\Windows\” in the file path field at the top of the window.  3. Type the cryptographic module binary executable file name (for example, “CNG.SYS”) in the  search field at the top right of the window, then press the Enter key.  4. The file will appear in the window.  5. Right click on the file’s icon.  6. Select Properties from the menu and the Properties window opens.  7. Select the Details tab.  8. Note the File version Property and its value, which has a number in this format: x.x.xxxx.xxxxx.  9. If the file version number matches one of the version numbers that appear at the start of this  security policy document, then the version number has been verified.  10. Select the Digital Signatures tab.  11. In the Signature list, select the Microsoft Windows signer.  12. Click the Details button.  13. Under the Digital Signature Information, you should see: “This digital signature is OK.” If that  condition is true then the digital signature has been verified.  © 2015 Microsoft. All Rights Reserved     Page 18 of 18  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).