Kernel Mode Cryptographic Primitives Library        Security Policy for FIPS 140‐2 Validation Kernel Mode Cryptographic Primitives Library (cng.sys) in Microsoft Windows 8.1 Enterprise Windows Server 2012 R2 Windows Storage Server 2012 R2 Surface Pro 2 Surface Pro Surface 2 Surface Windows RT 8.1 Windows Phone 8.1 Windows Embedded 8.1 Industry Enterprise StorSimple 8000 Series     DOCUMENT INFORMATION      Version Number  1.10  Updated On  April 3, 2015            © 2015 Microsoft. All Rights Reserved    Page 1 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library        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 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      CHANGE HISTORY  Date  Version  Updated By  Change  31 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;  processor name updates  1 JUL 2014  0.3  Tim Myers  Third Draft; added Security Levels Table and  cryptographic algorithm certificate numbers  10 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  Updates based on CMVP comments  17 DEC 2014  1.3  Tim Myers  Update IG G.5 platforms; update binary versions; add  StorSimple  22 JAN 2015  1.4  Tim Myers  Updates based on CMVP comments  29 JAN 2015  1.5  Tim Myers  Update Design Assurance  20 FEB 2015  1.6  Tim Myers  Add StorSimple to Validated Platforms  3 MAR 2015  1.7  Tim Myers  Add GCM note  9 MAR 2015  1.8  Tim Myers  Prepare for publication  18 MAR 2015  1.9  Tim Myers  Reorder StorSimple 8100 OE description; fix typos in  Section 10; adjust KAS – SP 800‐56A in Section 2.1;  add footnote for DH 80 bits  3 APR 2015  1.10  Tim Myers  Modify AES‐GCM encryption        © 2015 Microsoft. All Rights Reserved    Page 3 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      TABLE OF CONTENTS  1  INTRODUCTION .................................................................................................................... 8  1.1  LIST OF CRYPTOGRAPHIC MODULE BINARY EXECUTABLES ................................................................... 9  1.2  BRIEF MODULE DESCRIPTION  ...................................................................................................... 9  . 1.3  VALIDATED PLATFORMS ............................................................................................................. 9  1.4  CRYPTOGRAPHIC BOUNDARY ..................................................................................................... 11  2  SECURITY POLICY ................................................................................................................ 12  2.1  FIPS 140‐2 APPROVED ALGORITHMS  ......................................................................................... 14  . 2.2  NON‐APPROVED ALGORITHMS .................................................................................................. 14  2.3  CRYPTOGRAPHIC BYPASS .......................................................................................................... 15  2.4  MACHINE CONFIGURATIONS ...................................................................................................... 15  3  OPERATIONAL ENVIRONMENT ............................................................................................ 15  4  INTEGRITY CHAIN OF TRUST ................................................................................................ 15  5  PORTS AND INTERFACES ..................................................................................................... 15  5.1  CONTROL INPUT INTERFACE ....................................................................................................... 17  5.2  STATUS OUTPUT INTERFACE ...................................................................................................... 17  5.3  DATA OUTPUT INTERFACE ......................................................................................................... 17  5.4  DATA INPUT INTERFACE ............................................................................................................ 17  5.5  NON‐SECURITY RELEVANT INTERFACES ........................................................................................ 18  5.5.1  CONFIGURATION ............................................................................................................................. 18  5.5.2  NON‐APPROVED APIS ...................................................................................................................... 18  6  SPECIFICATION OF ROLES .................................................................................................... 19  6.1  MAINTENANCE ROLES .............................................................................................................. 19  6.2  MULTIPLE CONCURRENT INTERACTIVE OPERATORS ......................................................................... 19  6.3  OPERATOR AUTHENTICATION .................................................................................................... 19  7  SERVICES  ............................................................................................................................ 19  . 7.1  CRYPTOGRAPHIC MODULE POWER UP AND POWER DOWN .............................................................. 19  © 2015 Microsoft. All Rights Reserved    Page 4 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      7.1.1  DRIVERENTRY ................................................................................................................................. 19  7.1.2  DRIVERUNLOAD .............................................................................................................................. 20  7.2  ALGORITHM PROVIDERS AND PROPERTIES .................................................................................... 20  7.2.1  BCRYPTOPENALGORITHMPROVIDER ................................................................................................... 20  7.2.2  BCRYPTCLOSEALGORITHMPROVIDER .................................................................................................. 20  7.2.3  BCRYPTSETPROPERTY ...................................................................................................................... 20  7.2.4  BCRYPTGETPROPERTY ...................................................................................................................... 21  7.2.5  BCRYPTFREEBUFFER ........................................................................................................................ 21  7.3  RANDOM NUMBER GENERATION  ............................................................................................... 21  . 7.3.1  BCRYPTGENRANDOM ...................................................................................................................... 21  7.3.2  SYSTEMPRNG .................................................................................................................................. 21  7.3.3  ENTROPYREGISTERSOURCE ............................................................................................................... 22  7.3.4  ENTROPYUNREGISTERSOURCE ........................................................................................................... 22  7.3.5  ENTROPYPROVIDEDATA  ................................................................................................................... 22  . 7.4  KEY AND KEY‐PAIR GENERATION ................................................................................................ 23  7.4.1  BCRYPTGENERATESYMMETRICKEY ..................................................................................................... 23  7.4.2  BCRYPTGENERATEKEYPAIR ............................................................................................................... 23  7.4.3  BCRYPTFINALIZEKEYPAIR .................................................................................................................. 23  7.4.4  BCRYPTDUPLICATEKEY ..................................................................................................................... 23  7.4.5  BCRYPTDESTROYKEY ........................................................................................................................ 24  7.5  KEY ENTRY AND OUTPUT .......................................................................................................... 24  7.5.1  BCRYPTIMPORTKEY ......................................................................................................................... 24  7.5.2  BCRYPTIMPORTKEYPAIR ................................................................................................................... 25  7.5.3  BCRYPTEXPORTKEY ......................................................................................................................... 26  7.6  ENCRYPTION AND DECRYPTION .................................................................................................. 26  7.6.1  BCRYPTENCRYPT ............................................................................................................................. 26  7.6.2  BCRYPTDECRYPT ............................................................................................................................. 28  7.7  HASHING AND MESSAGE AUTHENTICATION .................................................................................. 29  7.7.1  BCRYPTCREATEHASH ....................................................................................................................... 29  7.7.2  BCRYPTHASHDATA .......................................................................................................................... 30  7.7.3  BCRYPTDUPLICATEHASH .................................................................................................................. 30  7.7.4  BCRYPTFINISHHASH  ........................................................................................................................ 30  . 7.7.5  BCRYPTDESTROYHASH ..................................................................................................................... 31  7.8  SIGNING AND VERIFICATION ...................................................................................................... 31  7.8.1  BCRYPTSIGNHASH ........................................................................................................................... 31  7.8.2  BCRYPTVERIFYSIGNATURE ................................................................................................................ 32  7.9  SECRET AGREEMENT AND KEY DERIVATION ................................................................................... 32  7.9.1  BCRYPTSECRETAGREEMENT .............................................................................................................. 32  7.9.2  BCRYPTDERIVEKEY .......................................................................................................................... 33  7.9.3  BCRYPTDESTROYSECRET ................................................................................................................... 34  7.9.4  BCRYPTKEYDERIVATION ................................................................................................................... 34  © 2015 Microsoft. All Rights Reserved    Page 5 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      7.10  LEGACY COMPATIBILITY INTERFACES ............................................................................................ 35  7.10.1  KEY FORMATTING ............................................................................................................................ 35  7.10.1.1  FipsDesKey .............................................................................................................................. 35  7.10.1.2  Fips3Des3Key .......................................................................................................................... 36  7.10.2  DATA ENCRYPTION AND DECRYPTION ................................................................................................. 36  7.10.2.1  FipsDes .................................................................................................................................... 36  7.10.2.2  Fips3Des .................................................................................................................................. 36  7.10.2.3  FipsCBC .................................................................................................................................... 36  7.10.2.4  FipsBlockCBC ........................................................................................................................... 37  7.10.3  HASHING  ....................................................................................................................................... 38  . 7.10.3.1  FipsSHAInit .............................................................................................................................. 38  7.10.3.2  FipsSHAUpdate ....................................................................................................................... 38  7.10.3.3  FipsSHAFinal ............................................................................................................................ 38  7.10.3.4  FipsHmacSHAInit ..................................................................................................................... 38  7.10.3.5  FipsHmacSHAUpdate .............................................................................................................. 39  7.10.3.6  FipsHmacSHAFinal  .................................................................................................................. 39  . 7.10.3.7  HmacMD5Init .......................................................................................................................... 39  7.10.3.8  HmacMD5Update ................................................................................................................... 40  7.10.3.9  HmacMD5Final ........................................................................................................................ 40  7.11  DEPRECATION ........................................................................................................................ 40  7.11.1  BIT STRENGTHS OF DH AND ECDH  .................................................................................................... 40  . 7.11.2  SHA‐1 ........................................................................................................................................... 41  7.12  SHOW STATUS SERVICES ........................................................................................................... 41  7.13  SELF‐TEST SERVICES ................................................................................................................. 41  7.14  SERVICE INPUTS / OUTPUTS ...................................................................................................... 41  8  AUTHENTICATION ............................................................................................................... 41  9  SECURITY RELEVANT DATA ITEMS ....................................................................................... 42  9.1  ACCESS CONTROL POLICY ......................................................................................................... 42  9.2  KEY MATERIAL ....................................................................................................................... 43  9.3  KEY GENERATION .................................................................................................................... 43  9.4  KEY ESTABLISHMENT ................................................................................................................ 44  9.4.1  NIST SP 800‐132 PASSWORD BASED KEY DERIVATION FUNCTION (PBKDF) ........................................... 44  9.5  KEY ENTRY AND OUTPUT .......................................................................................................... 45  9.6  KEY STORAGE ......................................................................................................................... 45  9.7  KEY ARCHIVAL ........................................................................................................................ 46  9.8  KEY ZEROIZATION .................................................................................................................... 46  © 2015 Microsoft. All Rights Reserved    Page 6 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      10  SELF‐TESTS .......................................................................................................................... 46  10.1  POWER‐ON SELF‐TESTS ............................................................................................................ 46  10.2  CONDITIONAL SELF‐TESTS ......................................................................................................... 47  11  DESIGN ASSURANCE  ........................................................................................................... 47  . 12  MITIGATION OF OTHER ATTACKS ........................................................................................ 48  13  SECURITY LEVELS................................................................................................................. 49  14  ADDITIONAL DETAILS .......................................................................................................... 50  15  APPENDIX A – HOW TO VERIFY WINDOWS VERSIONS AND DIGITAL SIGNATURES ............... 51  15.1  HOW TO VERIFY WINDOWS VERSIONS  ........................................................................................ 51  . 15.2  HOW TO VERIFY WINDOWS DIGITAL SIGNATURES .......................................................................... 51        © 2015 Microsoft. All Rights Reserved    Page 7 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      1 Introduction This document specifies the security policy for the Microsoft Kernel Mode Cryptographic Primitives  Library (CNG.SYS) as described in FIPS PUB 140‐2.  Microsoft Kernel Mode Cryptographic Primitives Library is a FIPS 140‐2 Level 1 compliant, general  purpose, software‐based, cryptographic module residing at kernel mode level of the Microsoft Windows  8.1 Enterprise, Windows Server 2012 R2, Windows Storage Server 2012 R2, Surface Pro 2, Surface Pro,  Surface 2, Surface, Windows RT 8.1, Windows Phone 8.1, Windows Embedded 8.1 Industry Enterprise,  and StorSimple 8000 Series (herein referred to as Windows 8.1 OEs) operating system. Kernel Mode  Cryptographic Primitives Library runs as a kernel mode export driver, and provides cryptographic  services, through their documented interfaces, to Windows 8.1 OEs kernel components.   The Kernel Mode Cryptographic Primitives Library encapsulates several different cryptographic  algorithms in an easy‐to‐use cryptographic module accessible via the Microsoft CNG (Cryptography,  Next Generation) API. It also supports several cryptographic algorithms accessible via a Fips function  table request IRP (I/O request packet). Windows 8.1 OEs kernel mode components can use general‐ purpose FIPS 140‐2 Level 1 compliant cryptography in Kernel Mode Cryptographic Primitives Library.  BitLocker and BitLocker to Go are a good example of usage of the Microsoft Kernel Mode Cryptographic  Primitives Library (CNG.SYS). In Figure 1 below, BitLocker functionality is contained in the Full Volume  Encryption module (FVEVOL.SYS), which calls CNG.SYS for the actual cryptographic operations.  FVEVOL.SYS does not implement any cryptographic operations in and of itself. BitLocker uses  FVEVOL.SYS to encrypt/decrypt physical hard drives that are accessed via the MiniPort driver and  Partition Manager. Similarly, Bitlocker to Go uses FVEVOL.SYS to encrypt/decrypt USB storage devices  that are accessed via the USBStor driver and Partition Manager. The FVEVOL.SYS usage of CNG.SYS  cryptographic operations is the same for both BitLocker and BitLocker to Go encrypted volumes.    © 2015 Microsoft. All Rights Reserved    Page 8 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      I/O Manager File System Kernel Mode  Full Volume Encryption  Cryptographic  (FVEVOL.SYS) Primitives Library  (CNG.SYS) Partition Manager MiniPort USBStor Physical  USB  HD device   Figure 1 The BitLocker Stack and Microsoft Kernel Mode Cryptographic Primitives Library   1.1 List of Cryptographic Module Binary Executables CNG.SYS – Versions 6.3.9600 and 6.3.9600.17042 for Windows 8.1 OEs   1.2 Brief Module Description Kernel Mode Cryptographic Primitives Library is the kernel mode export driver for the Cryptography,  Next Generation (CNG) API.  1.3 Validated Platforms The Kernel Mode Cryptographic Primitives Library component listed in Section 1.1 was 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;  © 2015 Microsoft. All Rights Reserved    Page 9 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      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;  27. Microsoft Windows RT 8.1 (ARMv7 Thumb‐2) running on an NVIDIA Tegra 3 Tablet;   28. Microsoft Windows RT 8.1 (ARMv7 Thumb‐2) running on a Microsoft Surface RT;  29. Microsoft Windows RT 8.1 (ARMv7 Thumb‐2) running on a Microsoft Surface 2;  30. Microsoft Windows RT 8.1 (ARMv7 Thumb‐2) running on a Qualcomm Tablet;   31. Microsoft Windows Phone 8.1 (ARMv7 Thumb‐2) running on a Qualcomm Snapdragon S4  running on a Windows Phone 8.1;  32. Microsoft Windows Phone 8.1 (ARMv7 Thumb‐2) running on a Qualcomm Snapdragon 400  running on a Windows Phone 8.1;  33. Microsoft Windows Phone 8.1 (ARMv7 Thumb‐2) running on a Qualcomm Snapdragon 800  running on a Windows Phone 8.1;  34. Microsoft Windows 8.1 Enterprise (x64) running on a Dell Inspiron 660s without AES‐NI and with  PCLMULQDQ and SSSE 3;  35. Microsoft Windows Embedded 8.1 Industry Enterprise (x64) running on a Dell Inspiron 660s  without AES‐NI and with PCLMULQDQ and SSSE 3;  36. Microsoft Windows Server 2012 R2 (x64) running on a Dell Inspiron 660s without AES‐NI and  with PCLMULQDQ and SSSE 3;  37. Microsoft Windows Storage Server 2012 R2 (x64) running on a Dell Inspiron 660s without AES‐NI  and with PCLMULQDQ and SSSE 3;  © 2015 Microsoft. All Rights Reserved    Page 10 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      38. 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;  39. 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;  40. 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;  41. 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;  42. Microsoft Windows 8.1 Enterprise (x64) running on an HP Compaq Pro 6305 with AES‐NI and  with PCLMULQDQ and SSSE 3;  43. Microsoft Windows Embedded 8.1 Industry Enterprise (x64) running on an HP Compaq Pro 6305  with AES‐NI and with PCLMULQDQ and SSSE 3;  44. Microsoft Windows Server 2012 R2 (x64) running on an HP Compaq Pro 6305 with AES‐NI and  with PCLMULQDQ and SSSE 3;  45. Microsoft Windows Storage Server 2012 R2 (x64) running on an HP Compaq Pro 6305 with AES‐ NI and with PCLMULQDQ and SSSE 3;  46. Windows Server 2012 R2 (x64) running on a Microsoft StorSimple 8100 with an Intel Xeon E5‐ 2648L without AES‐NI;  47. Windows Server 2012 R2 (x64) running on a Microsoft StorSimple 8100 with an Intel Xeon E5‐ 2648L with AES‐NI   The Kernel Mode Cryptographic Primitives Library 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 binary that comprises the cryptographic boundary for Kernel Mode Cryptographic  Primitives Library is CNG.SYS.  The crypto boundary is also defined by the enclosure of the computer  system, on which Kernel Mode Cryptographic Primitives Library is to be executed. The physical  configuration of Kernel Mode Cryptographic Primitives Library, as defined in FIPS‐140‐2, is multi‐chip  standalone.    © 2015 Microsoft. All Rights Reserved    Page 11 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      2 Security Policy Kernel Mode Cryptographic Primitives Library operates under several rules that encapsulate its security  policy.   Kernel Mode Cryptographic Primitives Library is supported on Windows 8.1 OEs .   Kernel Mode Cryptographic Primitives Library operates in FIPS mode of operation only when  used with the FIPS approved version of Windows 8.1 OEs Winload OS Loader (winload.exe)  validated to FIPS 140‐2 under Cert. #2352 for Windows 8.1 OEs operating in FIPS mode.   Windows 8.1, Windows Server 2012 R2, Windows Storage Server 2012 R2, Windows RT 8.1,  Windows Phone 8.1, and Windows Embedded 8.1 Industry are operating systems supporting a  “single user” mode where there is only one interactive user during a logon session.    Kernel Mode Cryptographic Primitives Library is only in its Approved mode of operation when  Windows is booted normally, meaning Debug mode is disabled and Driver Signing enforcement  is enabled.   Kernel Mode Cryptographic Primitives Library operates in its FIPS mode of operation only when  one of the following DWORD registry values is set to 1:  o HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled  o HKLM\SYSTEM\CurrentControlSet\Policies\Microsoft\Cryptography\Configuration\SelfT estAlgorithms   The registry security policy settings can be observed with the regedit tool to determine whether  the module is in FIPS mode.   All users assume either the User or Cryptographic Officer roles.   Kernel Mode Cryptographic Primitives Library provides no authentication of users. Roles are  assumed implicitly. The authentication provided by the Windows 8.1 OEs operating system is  not in the scope of the validation.   All cryptographic services implemented within Kernel Mode Cryptographic Primitives Library are  available to the User and Cryptographic Officer roles.   In order to invoke the approved mode of operation, the user must call FIPS approved functions.        © 2015 Microsoft. All Rights Reserved    Page 12 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      The following diagram illustrates the master components of the module:    Figure 2 Master components of cng.sys crypto module       © 2015 Microsoft. All Rights Reserved    Page 13 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library        2.1 FIPS 140‐2 Approved Algorithms Kernel Mode Cryptographic Primitives Library implements the following FIPS‐140‐2 Approved  algorithms.        FIPS 180‐4 SHS (SHA‐256, SHA‐384, SHA‐512) (Cert. #2373)   FIPS 180‐4 SHA‐1, SHA‐256, SHA‐384, SHA‐512 HMAC (Cert. #1773)   Triple‐DES (2 key1 and 3 key) in ECB, CBC, CFB8 and CFB64 modes (Cert. #1692)   AES‐128, AES‐192, and AES‐256 in ECB, CBC, CFB8, CFB128, and CTR modes (Cert. #2832)   AES‐128, AES‐192, and AES‐256 in CCM, CMAC, and GMAC modes (Cert. #2832)   AES‐128, AES‐192, and AES‐256 GCM decryption (Cert. #2832)   FIPS 186‐4 RSA (RSASSA‐PKCS1‐v1_5 and RSASSA‐PSS) digital signatures (Certs. #1493 and  #1519) and FIPS 186‐4 RSA key‐pair generation (Cert. #1487)   FIPS 186‐4 ECDSA with the following NIST curves: P‐256, P‐384, P‐521 (Cert. #505)   KAS – SP 800‐56A (Cert. #47) Diffie‐Hellman Key Agreement; key establishment methodology  provides 80 bits2 and 112 bits of encryption strength   KAS – SP 800‐56A (Cert. #47) EC Diffie‐Hellman Key Agreement; key establishment methodology  provides between 128 and 256‐bits of encryption strength   SP 800‐90 AES‐256 counter mode DRBG (Cert. #489)   SP 800‐90 Dual‐EC DRBG (Cert. #523)   SP 800‐108 Key Derivation Function (KDF) (Cert. #30)   SP 800‐132 KDF (also known as PBKDF) (vendor affirmed)   SP 800‐135 IKEv1, IKEv2, and TLS KDF primitives (Cert. #323)  2.2 Non‐Approved Algorithms  Kernel Mode Cryptographic Primitives Library implements the SHA‐1 hash, which is disallowed  for use in digital signature generation after December 31, 2013. It can be used for digital  signature verification legacy‐use. Its use is Acceptable for non‐digital signature generation  applications.   Kernel Mode Cryptographic Primitives Library implements RSA 1024‐bits for digital signature  generation, which is disallowed after December 31, 2013. RSA 2048‐bits and 3072‐bits are also  supported, which are Acceptable.   Kernel Mode Cryptographic Primitives Library supports SP 800‐56A Key Agreement using Finite  Field Cryptography (FFC) with parameter FA (p=1024, q=160), which is disallowed after  December 31, 2013. FB (p=2048, q=224) and FC (p=2048, q=256) are Acceptable.   Kernel Mode Cryptographic Primitives Library supports the following non‐Approved algorithms  allowed for use in FIPS mode.  o AES Key Wrap (AES Cert. #2832; key wrapping; key establishment methodology provides  between 128 and 256 bits of encryption strength)                                                               1 Two-key Triple-DES is restricted and legacy-use according to NIST SP 800-131A. Users should start transitioning away from this algorithm to better, stronger choices. 2 DH with 80 bits of encryption strength is no longer allowed in FIPS mode. The minimum requirement has increased to 112 bits effective January 1, 2014. © 2015 Microsoft. All Rights Reserved    Page 14 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library       Kernel Mode Cryptographic Primitives Library has a non‐approved algorithm implementation of  AES GCM encryption.   Kernel Mode Cryptographic Primitives Library implements Continuous Random Number  Generator Tests (CRNGT) for the AES‐CTR DRBG, Dual‐EC DRBG, and the non‐Approved RNG  (entropy pool).   Kernel Mode Cryptographic Primitives Library also supports the following non FIPS 140‐2  approved algorithms, though these algorithms may not be used when operating the modules in  a FIPS compliant manner.  o RSA encrypt/decrypt  o RC2, RC4, MD2, MD4, MD5, HMAC MD53.  o DES in ECB, CBC, CFB8 and CFB64 modes  o Legacy CAPI KDF (proprietary)  o NDRNG  2.3 Cryptographic Bypass Cryptographic bypass is not supported by Kernel Mode Cryptographic Primitives Library. 2.4 Machine Configurations Kernel Mode Cryptographic Primitives Library was tested using the machine configurations listed in  Section 1.3 ‐ Validated Platforms.  3 Operational Environment The operational environment for Kernel Mode Cryptographic Primitives Library is Windows 8.1 OEs  running on the software and hardware configurations listed in Section 1.3 ‐ Validated Platforms. Kernel  Mode Cryptographic Primitives Library services are available to all kernel mode components, which are  part of the Trusted Computing Base (TCB).   4 Integrity Chain of Trust The Windows OS Loader checks the integrity of Kernel Mode Cryptographic Primitives Library before  starting it. This integrity check is based on the verification of an RSA signature over the binary using a  2048‐bit key and a SHA‐256 hash (Cert. #2373), and verifying that the signing certificate chains up to a  known root authority.  5 Ports and Interfaces As shown in Figure 3, the Kernel Mode Cryptographic Primitives Library module is accessed through one  of four logical interfaces. Kernel applications requiring cryptographic services use the BCrypt or legacy  Fips APIs detailed in Section 0. Entropy sources supply random bits to the random number generator                                                               3 Applications may not use any of these non-FIPS algorithms if they need to be FIPS compliant. To operate the module in a FIPS compliant manner, applications must only use FIPS-approved algorithms. © 2015 Microsoft. All Rights Reserved    Page 15 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      through the entropy APIs. Finally, both kernel mode and user mode random number generators use the  SystemPrng interface to obtain seed material for their PRNGs.  Kernel mode application  Kernel or user mode  CNG BCrypt  SystemPrng  and legacy  interface  Fips APIs  Cng.sys  Entropy API  Entropy source  Entropy source    Figure 3 Relationship of cng.sys to other system components – cryptographic boundary   shown in gold The following functions are used by Kernel Mode Cryptographic Primitives Library to expose  cryptographic functionality to its callers.   BCryptCloseAlgorithmProvider    BCryptCreateHash    BCryptDecrypt    BCryptDeriveKey    BCryptDestroyHash    BCryptDestroyKey    BCryptDestroySecret    BCryptDuplicateHash    BCryptDuplicateKey    BCryptEncrypt    BCryptExportKey    BCryptFinalizeKeyPair    BCryptFinishHash    BCryptFreeBuffer    BCryptGenerateKeyPair    BCryptGenerateSymmetricKey    BCryptGenRandom   © 2015 Microsoft. All Rights Reserved    Page 16 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library       BCryptGetProperty    BCryptHashData    BCryptImportKey    BCryptImportKeyPair    BCryptKeyDerivation   BCryptOpenAlgorithmProvider    BCryptSecretAgreement    BCryptSetProperty    BCryptSignHash    BCryptVerifySignature    SystemPrng    The following functions are exposed to entropy sources:   EntropyRegisterSource   EntropyUnregisterSource   EntropyProvideData    Kernel Mode Cryptographic Primitives Library has additional export functions described in subsequent  sections.  5.1 Control Input Interface The Control Input Interface for Kernel Mode Cryptographic Primitives Library consists of the Kernel  Mode Cryptographic Primitives Library cryptographic export functions enumerated above. Options for  control operations are passed as input parameters to these functions.  5.2 Status Output Interface The Status Output Interface for Kernel Mode Cryptographic Primitives Library consists of the Kernel  Mode Cryptographic Primitives Library export functions. For each function, the status information is  returned to the caller as the return value from the function.  5.3 Data Output Interface The Data Output Interface for Kernel Mode Cryptographic Primitives Library consists of the Kernel Mode  Cryptographic Primitives Library export functions.  5.4 Data Input Interface The Data Input Interface for Kernel Mode Cryptographic Primitives Library consists of the Kernel Mode  Cryptographic Primitives Library export functions. Data and options are passed to the interface as input  parameters to the Kernel Mode Cryptographic Primitives Library export functions. Data Input is kept  separate from Control Input by passing Data Input in separate parameters from Control Input.   © 2015 Microsoft. All Rights Reserved    Page 17 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      5.5 Non‐Security Relevant Interfaces 5.5.1 Configuration These are not cryptographic functions. They are used to configure cryptographic providers on the  system, and are provided for informational purposes. Please see http://msdn.microsoft.com for details.    Function Name  Description  BCryptEnumAlgorithms  Enumerates the algorithms for a given set of  operations.  BCryptEnumProviders  Returns a list of providers for a given algorithm.  BCryptRegisterConfigChangeNotify  This API differs slightly between User‐Mode and  Kernel‐Mode.  BCryptResolveProviders  This is the main API in Crypto configuration. It  resolves queries against the set of providers  currently registered on the local system and the  configuration information specified in the machine  and domain configuration tables, returning an  ordered list of references to one or more providers  matching the specified criteria.  BCryptUnregisterConfigChangeNotify  This API differs slightly between User‐Mode and  Kernel‐Mode.  BCryptGetFipsAlgorithmMode  Used by applications to determine whether Kernel  Mode Cryptographic Primitives Library is operating  in FIPS mode. Some applications use the value  returned by this API to alter their own behavior,  such as blocking the use of some SSL versions.  5.5.2 Non‐approved APIs The following table lists other non‐security relevant or non‐approved APIs exported from the crypto  module.   Function Name  Description  BCryptDeriveKeyCapi    BCryptDeriveKeyPBKDF2        SslDecryptPacket    SslEncryptPacket    SslExportKey    SslFreeObject    SslImportKey    SslLookupCipherLengths    SslLookupCipherSuiteInfo    SslOpenProvider    SslIncrementProviderReferenceCount    © 2015 Microsoft. All Rights Reserved    Page 18 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      SslDecrementProviderReferenceCount          AppHashComputeFileAttributes    6 Specification of Roles Kernel Mode Cryptographic Primitives Library provides User and Cryptographic Officer roles (as defined  in FIPS 140‐2). These roles share all the services implemented in the cryptographic module.  When a kernel mode component requests the crypto module to generate keys, the keys are generated,  used, and deleted as requested. There are no implicit keys associated with a kernel component. Each  kernel component may have numerous keys.  6.1 Maintenance Roles Maintenance roles are not supported.  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.  6.3 Operator Authentication The module does not provide authentication. Roles are implicitly assumed based on the services that are  executed.  7 Services The following list contains all services available to an operator. All services are accessible to both the  User and Crypto Officer roles.  7.1 Cryptographic Module Power Up and Power Down 7.1.1 DriverEntry Each Windows 8.1 OEs driver must have a standard initialization routine DriverEntry in order to  be loaded. The Windows 8.1 OEs Loader is responsible to call the DriverEntry routine. The DriverEntry  routine must have the following prototype.  NTSTATUS (*PDRIVER_INITIALIZE) (  IN   PDRIVER_OBJECT   DriverObject,   IN  PUNICODE_STRING   RegistryPath);  The input DriverObject represents the driver within the Windows 8.1 OEs system. Its pointer allows the  DriverEntry routine to set an appropriate entry point for its DriverUnload routine in the driver object.   The RegistryPath input to the DriverEntry routine points to a counted Unicode string that specifies a  path to the driver's registry key \Registry\Machine\System\CurrentControlSet\Services\CNG.  © 2015 Microsoft. All Rights Reserved    Page 19 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      7.1.2 DriverUnload It is the entry point for the driver's unload routine. The pointer to the routine is set by the DriverEntry  routine in the DriverUnload field of the DriverObject when the driver initializes. An Unload routine is  declared as follows:  VOID (*PDRIVER_UNLOAD) (  IN   PDRIVER_OBJECT   DriverObject);  When the driver is no longer needed, the Windows 8.1 OEs Kernel is responsible to call the DriverUnload  routine of the associated DriverObject.  7.2 Algorithm Providers and Properties   7.2.1 BCryptOpenAlgorithmProvider NTSTATUS WINAPI BCryptOpenAlgorithmProvider(  BCRYPT_ALG_HANDLE   *phAlgorithm,  LPCWSTR pszAlgId,  LPCWSTR pszImplementation,  ULONG   dwFlags);  The BCryptOpenAlgorithmProvider() function has four parameters: algorithm handle output to the  opened algorithm provider, desired algorithm ID input, an optional specific provider name input, and  optional flags. This function loads and initializes a CNG provider for a given algorithm, and returns a  handle to the opened algorithm provider on success.  Unless the calling function specifies the name of the provider, the default provider is used.  The calling function must pass the BCRYPT_ALG_HANDLE_HMAC_FLAG flag in order to use an HMAC  function with a hash algorithm.  7.2.2 BCryptCloseAlgorithmProvider NTSTATUS WINAPI BCryptCloseAlgorithmProvider(  BCRYPT_ALG_HANDLE   hAlgorithm,  ULONG   dwFlags);  This function closes an algorithm provider handle opened by a call to BCryptOpenAlgorithmProvider()  function.  7.2.3 BCryptSetProperty NTSTATUS WINAPI BCryptSetProperty(  BCRYPT_HANDLE   hObject,  LPCWSTR pszProperty,  PUCHAR   pbInput,  ULONG   cbInput,  ULONG   dwFlags);  © 2015 Microsoft. All Rights Reserved    Page 20 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      The BCryptSetProperty() function sets the value of a named property for a CNG object. The CNG object  is a handle, the property name is a NULL terminated string, and the value of the property is a length‐ specified byte string.    7.2.4 BCryptGetProperty NTSTATUS WINAPI BCryptGetProperty(  BCRYPT_HANDLE   hObject,  LPCWSTR pszProperty,  PUCHAR   pbOutput,  ULONG   cbOutput,  ULONG   *pcbResult,  ULONG   dwFlags);  The BCryptGetProperty() function retrieves the value of a named property for a CNG object. The CNG  object is a handle, the property name is a NULL terminated string, and the value of the property is a  length‐specified byte string.  7.2.5 BCryptFreeBuffer VOID WINAPI BCryptFreeBuffer(  PVOID   pvBuffer);  Some of the CNG functions allocate memory on caller’s behalf. The BCryptFreeBuffer() function frees  memory that was allocated by such a CNG function.  7.3 Random Number Generation 7.3.1 BCryptGenRandom NTSTATUS WINAPI BCryptGenRandom(  BCRYPT_ALG_HANDLE   hAlgorithm,  PUCHAR  pbBuffer,  ULONG   cbBuffer,  ULONG   dwFlags);  The BCryptGenRandom() function fills a buffer with random bytes. There are two random number  generation algorithms:    BCRYPT_RNG_ALGORITHM. This is the AES‐256 counter mode based random generator as  defined in SP800‐90.   BCRYPT_RNG_DUAL_EC_ALGORITHM. This is the Dual‐EC DRBG based random generator as  defined in SP800‐90.      During the function initialization, a seed is obtained from the output of the SystemPrng function. This  provides the necessary entropy for the RNGs available through this function.   7.3.2 SystemPrng BOOL SystemPrng(  © 2015 Microsoft. All Rights Reserved    Page 21 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      unsigned char   *pbRandomData,  size_t          cbRandomData );  The SystemPrng() function fills a buffer with random bytes. It generates these bytes by taking the output  of a cascade of two SP800‐90 AES‐256 counter mode based DRBGs in kernel‐mode and four cascaded SP  800‐90 AES‐256 DRBGs in user‐mode; all are seeded from the Windows entropy pool. The Windows  entropy pool is populated from the following sources:   An initial entropy value provided by the Windows OS Loader at boot time.   The values of the high‐resolution CPU cycle counter at times when hardware interrupts are  received.   Random values gathered from the Trusted Platform Module (TPM), if one is available on the  system.   Random values gathered by calling the RDRAND CPU instruction, if supported by the CPU.  The Windows RNG infrastructure located in cng.sys continues to gather entropy from these sources  during normal operation, and the DRBG cascade is periodically reseeded with new entropy.  7.3.3 EntropyRegisterSource NTSTATUS EntropyRegisterSource(  ENTROPY_SOURCE_HANDLE * phEntropySource,  ENTROPY_SOURCE_TYPE     entropySourceType,  PCWSTR                  entropySourceName );  This function is used to obtain a handle that can be used to contribute randomness to the Windows  entropy pool. The handle is returned in the phEntropySource parameter. For this function,  entropySource must be set to ENTROPY_SOURCE_TYPE_HIGH_PUSH, and entropySourceName must be  a Unicode string describing the entropy source.   7.3.4 EntropyUnregisterSource NTSTATUS EntropyRegisterSource(  ENTROPY_SOURCE_HANDLE hEntropySource);  This function is used to destroy a handle created with EntropyRegisterSource().    7.3.5 EntropyProvideData NTSTATUS EntropyProvideData(  ENTROPY_SOURCE_HANDLE   hEntropySource,  PCBYTE                  pbData,  SIZE_T                  cbData,  ULONG                   entropyEstimateInMilliBits );  This function is used to contribute entropy to the Windows entropy pool. hEntropySource must be  a  handle returned by an earlier call to EntropyRegisterSource. The caller provides cbData bytes in the  © 2015 Microsoft. All Rights Reserved    Page 22 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      buffer pointed to by pbData, as well as an estimate (in the entropyEstimateInMilliBits parameter) of how  many millibits of entropy are contained in these bytes.    7.4 Key and Key‐Pair Generation 7.4.1 BCryptGenerateSymmetricKey NTSTATUS WINAPI BCryptGenerateSymmetricKey(  BCRYPT_ALG_HANDLE   hAlgorithm,  BCRYPT_KEY_HANDLE   *phKey,  PUCHAR   pbKeyObject,  ULONG   cbKeyObject,  PUCHAR   pbSecret,  ULONG   cbSecret,  ULONG   dwFlags);  The BCryptGenerateSymmetricKey() function generates a symmetric key object for use with a symmetric  encryption or key derivation algorithm from a supplied key value. The calling application must specify a  handle to the algorithm provider created with the BCryptOpenAlgorithmProvider() function. The  algorithm specified when the provider was created must support symmetric key encryption or key  derivation.  7.4.2 BCryptGenerateKeyPair NTSTATUS WINAPI BCryptGenerateKeyPair(  BCRYPT_ALG_HANDLE   hAlgorithm,  BCRYPT_KEY_HANDLE   *phKey,  ULONG   dwLength,  ULONG   dwFlags);  The BCryptGenerateKeyPair() function creates an empty public/private key pair. After creating a key  using this function, call the BCryptSetProperty() function to set its properties. The key pair can be used  only after BCryptFinalizeKeyPair() function is called.    7.4.3 BCryptFinalizeKeyPair NTSTATUS WINAPI BCryptFinalizeKeyPair(  BCRYPT_KEY_HANDLE   hKey,  ULONG   dwFlags);  The BCryptFinalizeKeyPair() function completes a public/private key pair import or generation. The key  pair cannot be used until this function has been called. After this function has been called, the  BCryptSetProperty() function can no longer be used for this key.  7.4.4 BCryptDuplicateKey NTSTATUS WINAPI BCryptDuplicateKey(  BCRYPT_KEY_HANDLE   hKey,  © 2015 Microsoft. All Rights Reserved    Page 23 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      BCRYPT_KEY_HANDLE   *phNewKey,  PUCHAR   pbKeyObject,  ULONG   cbKeyObject,  ULONG   dwFlags);  The BCryptDuplicateKey() function creates a duplicate of a symmetric key.  7.4.5 BCryptDestroyKey NTSTATUS WINAPI BCryptDestroyKey(  BCRYPT_KEY_HANDLE   hKey);  The BCryptDestroyKey() function destroys a key.  7.5 Key Entry and Output 7.5.1 BCryptImportKey NTSTATUS WINAPI BCryptImportKey(  BCRYPT_ALG_HANDLE hAlgorithm,  BCRYPT_KEY_HANDLE hImportKey,  LPCWSTR pszBlobType,  BCRYPT_KEY_HANDLE *phKey,  PUCHAR   pbKeyObject,  ULONG   cbKeyObject,  PUCHAR   pbInput,  ULONG   cbInput,  ULONG   dwFlags);  The BCryptImportKey() function imports a symmetric key from a key blob.    hAlgorithm [in] is the handle of the algorithm provider to import the key. This handle is obtained by  calling the BCryptOpenAlgorithmProvider function.  hImportKey [in, out] is not currently used and should be NULL.  pszBlobType [in] is a null‐terminated Unicode string that contains an identifier that specifies the type of  BLOB that is contained in the pbInput buffer. pszBlobType can be one of BCRYPT_AES_WRAP_KEY_BLOB,  BCRYPT_KEY_DATA_BLOB and BCRYPT_OPAQUE_KEY_BLOB.  phKey [out] is a pointer to a BCRYPT_KEY_HANDLE that receives the handle of the imported key that is  used in subsequent functions that require a key, such as BCryptEncrypt. This handle must be released  when it is no longer needed by passing it to the BCryptDestroyKey function.   pbKeyObject [out] is a pointer to a buffer that receives the imported key object. The cbKeyObject  parameter contains the size of this buffer. The required size of this buffer can be obtained by calling the  BCryptGetProperty function to get the BCRYPT_OBJECT_LENGTH property. This will provide the size of  the key object for the specified algorithm. This memory can only be freed after the phKey key handle is  destroyed.  © 2015 Microsoft. All Rights Reserved    Page 24 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      cbKeyObject [in] is the size, in bytes, of the pbKeyObject buffer.   pbInput [in] is the address of a buffer that contains the key BLOB to import.  The cbInput parameter contains the size of this buffer.  The pszBlobType parameter specifies the type of key BLOB this buffer contains.   cbInput [in] is the size, in bytes, of the pbInput buffer.   dwFlags [in] is a set of flags that modify the behavior of this function. No flags are currently defined, so  this parameter should be zero..  Triple DES keys can be imported into KSECDD.SYS via Fips3Des3Key(). DES3Table struct can be exported  out of KSECDD.SYS via Fips3Des3Key().  DES3Table struct can be imported into KSECDD.SYS via  Fips3Des() or FipsCBC().  HMAC keys can be imported into KSECDD.SYS via FipsHmacSHAInit and FipsHmacSHAFinal.  7.5.2 BCryptImportKeyPair NTSTATUS WINAPI BCryptImportKeyPair(  BCRYPT_ALG_HANDLE hAlgorithm,  BCRYPT_KEY_HANDLE hImportKey,  LPCWSTR pszBlobType,  BCRYPT_KEY_HANDLE *phKey,  PUCHAR   pbInput,  ULONG   cbInput,  ULONG   dwFlags);  The BCryptImportKeyPair() function is used to import a public/private key pair from a key blob.  hAlgorithm [in] is the handle of the algorithm provider to import the key. This handle is obtained by  calling the BCryptOpenAlgorithmProvider function.   hImportKey [in, out] is not currently used and should be NULL.   pszBlobType [in] is a null‐terminated Unicode string that contains an identifier that specifies the type of  BLOB that is contained in the pbInput buffer. This can be one of the following values:  BCRYPT_DH_PRIVATE_BLOB, BCRYPT_DH_PUBLIC_BLOB, BCRYPT_ECCPRIVATE_BLOB,  BCRYPT_ECCPUBLIC_BLOB, BCRYPT_PUBLIC_KEY_BLOB, BCRYPT_PRIVATE_KEY_BLOB,  BCRYPT_RSAPRIVATE_BLOB, BCRYPT_RSAPUBLIC_BLOB, LEGACY_DH_PUBLIC_BLOB,  LEGACY_DH_PRIVATE_BLOB, LEGACY_RSAPRIVATE_BLOB, LEGACY_RSAPUBLIC_BLOB.  phKey [out] is a pointer to a BCRYPT_KEY_HANDLE that receives the handle of the imported key. This  handle is used in subsequent functions that require a key, such as BCryptSignHash. This handle must be  released when it is no longer needed by passing it to the BCryptDestroyKey function.   © 2015 Microsoft. All Rights Reserved    Page 25 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      pbInput [in] is the address of a buffer that contains the key BLOB to import. The cbInput parameter  contains the size of this buffer. The pszBlobType parameter specifies the type of key BLOB this buffer  contains.   cbInput [in] contains the size, in bytes, of the pbInput buffer.   dwFlags [in] is a set of flags that modify the behavior of this function. This can be zero or the following  value: BCRYPT_NO_KEY_VALIDATION.  7.5.3 BCryptExportKey NTSTATUS WINAPI BCryptExportKey(  BCRYPT_KEY_HANDLE   hKey,  BCRYPT_KEY_HANDLE   hExportKey,  LPCWSTR pszBlobType,  PUCHAR   pbOutput,  ULONG   cbOutput,  ULONG   *pcbResult,  ULONG   dwFlags);  The BCryptExportKey() function exports a key to a memory blob that can be persisted for later use.  hExportKey [in, out] is not currently used and should be set to NULL.   pszBlobType [in] is a null‐terminated Unicode string that contains an identifier that specifies the type of  BLOB to export. This can be one of the following values: BCRYPT_AES_WRAP_KEY_BLOB,  BCRYPT_DH_PRIVATE_BLOB, BCRYPT_DH_PUBLIC_BLOB, BCRYPT_ECCPRIVATE_BLOB,  BCRYPT_ECCPUBLIC_BLOB, BCRYPT_KEY_DATA_BLOB, BCRYPT_OPAQUE_KEY_BLOB,  BCRYPT_PUBLIC_KEY_BLOB, BCRYPT_PRIVATE_KEY_BLOB, BCRYPT_RSAPUBLIC_BLOB,  LEGACY_DH_PRIVATE_BLOB, LEGACY_DH_PUBLIC_BLOB, LEGACY_RSAPUBLIC_BLOB.  pbOutput is the address of a buffer that receives the key BLOB. The cbOutput parameter contains the  size of this buffer. If this parameter is NULL, this function will place the required size, in bytes, in the  ULONG pointed to by the pcbResult parameter.   cbOutput [in] contains the size, in bytes, of the pbOutput buffer.   pcbResult [out] is a pointer to a ULONG that receives the number of bytes that were copied to the  pbOutput buffer. If the pbOutput parameter is NULL, this function will place the required size, in bytes,  in the ULONG pointed to by this parameter.   dwFlags [in] is a set of flags that modify the behavior of this function. No flags are defined for this  function.  7.6 Encryption and Decryption 7.6.1 BCryptEncrypt NTSTATUS WINAPI BCryptEncrypt(  © 2015 Microsoft. All Rights Reserved    Page 26 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      BCRYPT_KEY_HANDLE hKey,  PUCHAR   pbInput,  ULONG   cbInput,  VOID    *pPaddingInfo,  PUCHAR   pbIV,  ULONG   cbIV,  PUCHAR   pbOutput,  ULONG   cbOutput,  ULONG   *pcbResult,  ULONG   dwFlags);  The BCryptEncrypt() function encrypts a block of data of given length.  hKey [in, out] is the handle of the key to use to encrypt the data. This handle is obtained from one of the  key creation functions, such as BCryptGenerateSymmetricKey, BCryptGenerateKeyPair, or  BCryptImportKey.   pbInput [in] is the address of a buffer that contains the plaintext to be encrypted. The cbInput  parameter contains the size of the plaintext to encrypt. For more information, see Remarks.   cbInput [in] is the number of bytes in the pbInput buffer to encrypt.   pPaddingInfo [in, optional] is a pointer to a structure that contains padding information. The actual type  of structure this parameter points to depends on the value of the dwFlags parameter. This parameter is  only used with asymmetric keys and authenticated encryption modes (i.e. AES‐CCM and AES‐GCM). It  must be NULL otherwise.   pbIV [in, out, optional] is the address of a buffer that contains the initialization vector (IV)4 to use during  encryption. The cbIV parameter contains the size of this buffer. This function will modify the contents of  this buffer. If you need to reuse the IV later, make sure you make a copy of this buffer before calling this  function. This parameter is optional and can be NULL if no IV is used. The required size of the IV can be  obtained by calling the BCryptGetProperty function to get the BCRYPT_BLOCK_LENGTH property. This  will provide the size of a block for the algorithm, which is also the size of the IV.  cbIV [in] contains the size, in bytes, of the pbIV buffer.   pbOutput [out, optional] is the address of a buffer that will receive the ciphertext produced by this  function. The cbOutput parameter contains the size of this buffer. For more information, see Remarks.  If this parameter is NULL, this function will calculate the size needed for the ciphertext and return the  size in the location pointed to by the pcbResult parameter.                                                               4  The IV being passed into the BCryptEncrypt() API needs to be generated by a validated cryptographic  module or an approved DRBG.  © 2015 Microsoft. All Rights Reserved    Page 27 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      cbOutput [in] contains the size, in bytes, of the pbOutput buffer. This parameter is ignored if the  pbOutput parameter is NULL.   pcbResult [out] is a pointer to a ULONG variable that receives the number of bytes copied to the  pbOutput buffer. If pbOutput is NULL, this receives the size, in bytes, required for the ciphertext.   dwFlags [in] is a set of flags that modify the behavior of this function. The allowed set of flags depends  on the type of key specified by the hKey parameter. If the key is a symmetric key, this can be zero or the  following value: BCRYPT_BLOCK_PADDING. If the key is an asymmetric key, this can be one of the  following values: BCRYPT_PAD_NONE, BCRYPT_PAD_OAEP, BCRYPT_PAD_PKCS1.  7.6.2 BCryptDecrypt NTSTATUS WINAPI BCryptDecrypt(  BCRYPT_KEY_HANDLE   hKey,  PUCHAR   pbInput,  ULONG   cbInput,  VOID    *pPaddingInfo,  PUCHAR   pbIV,  ULONG   cbIV,  PUCHAR   pbOutput,  ULONG   cbOutput,  ULONG   *pcbResult,  ULONG   dwFlags);  The BCryptDecrypt() function decrypts a block of data of given length.  hKey [in, out] is the handle of the key to use to decrypt the data. This handle is obtained from one of the  key creation functions, such as BCryptGenerateSymmetricKey, BCryptGenerateKeyPair, or  BCryptImportKey.   pbInput [in] is the address of a buffer that contains the ciphertext to be decrypted. The cbInput  parameter contains the size of the ciphertext to decrypt. For more information, see Remarks.   cbInput [in] is the number of bytes in the pbInput buffer to decrypt.   pPaddingInfo [in, optional] is a pointer to a structure that contains padding information. The actual type  of structure this parameter points to depends on the value of the dwFlags parameter. This parameter is  only used with asymmetric keys and authenticated encryption modes (i.e. AES‐CCM and AES‐GCM). It  must be NULL otherwise.   pbIV [in, out, optional] is the address of a buffer that contains the initialization vector (IV) to use during  decryption. The cbIV parameter contains the size of this buffer. This function will modify the contents of  this buffer. If you need to reuse the IV later, make sure you make a copy of this buffer before calling this  function. This parameter is optional and can be NULL if no IV is used. The required size of the IV can be  © 2015 Microsoft. All Rights Reserved    Page 28 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      obtained by calling the BCryptGetProperty function to get the BCRYPT_BLOCK_LENGTH property. This  will provide the size of a block for the algorithm, which is also the size of the IV.  cbIV [in] contains the size, in bytes, of the pbIV buffer.   pbOutput [out, optional] is the address of a buffer to receive the plaintext produced by this function.  The cbOutput parameter contains the size of this buffer. For more information, see Remarks.  If this parameter is NULL, this function will calculate the size required for the plaintext and return the  size in the location pointed to by the pcbResult parameter.  cbOutput [in] is the size, in bytes, of the pbOutput buffer. This parameter is ignored if the pbOutput  parameter is NULL.   pcbResult [out] is a pointer to a ULONG variable to receive the number of bytes copied to the pbOutput  buffer. If pbOutput is NULL, this receives the size, in bytes, required for the plaintext.   dwFlags [in] is a set of flags that modify the behavior of this function. The allowed set of flags depends  on the type of key specified by the hKey parameter. If the key is a symmetric key, this can be zero or the  following value: BCRYPT_BLOCK_PADDING. If the key is an asymmetric key, this can be one of the  following values: BCRYPT_PAD_NONE, BCRYPT_PAD_OAEP, BCRYPT_PAD_PKCS1.  7.7 Hashing and Message Authentication 7.7.1 BCryptCreateHash NTSTATUS WINAPI BCryptCreateHash(  BCRYPT_ALG_HANDLE   hAlgorithm,  BCRYPT_HASH_HANDLE  *phHash,  PUCHAR   pbHashObject,  ULONG   cbHashObject,  PUCHAR   pbSecret,  ULONG   cbSecret,  ULONG   dwFlags);  The BCryptCreateHash() function creates a hash object with an optional key. The optional key is used for  HMAC, AES GMAC and AES CMAC.  hAlgorithm [in, out] is the handle of an algorithm provider created by using the  BCryptOpenAlgorithmProvider function. The algorithm that was specified when the provider was  created must support the hash interface.   phHash [out] is a pointer to a BCRYPT_HASH_HANDLE value that receives a handle that represents the  hash object. This handle is used in subsequent hashing functions, such as the BCryptHashData function.  When you have finished using this handle, release it by passing it to the BCryptDestroyHash function.   pbHashObject [out] is a pointer to a buffer that receives the hash object. The cbHashObject parameter  contains the size of this buffer. The required size of this buffer can be obtained by calling the  © 2015 Microsoft. All Rights Reserved    Page 29 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      BCryptGetProperty function to get the BCRYPT_OBJECT_LENGTH property. This will provide the size of  the hash object for the specified algorithm. This memory can only be freed after the hash handle is  destroyed.  cbHashObject [in] contains the size, in bytes, of the pbHashObject buffer.   pbSecret [in, optional] is a pointer to a buffer that contains the key to use for the hash. The cbSecret  parameter contains the size of this buffer. If no key should be used with the hash, set this parameter to  NULL. This key only applies to the HMAC, AES GMAC and AES CMAC algorithms.   cbSecret [in, optional] contains the size, in bytes, of the pbSecret buffer. If no key should be used with  the hash, set this parameter to zero.   dwFlags [in] is not currently used and must be zero.  7.7.2 BCryptHashData NTSTATUS WINAPI BCryptHashData(  BCRYPT_HASH_HANDLE  hHash,  PUCHAR   pbInput,  ULONG   cbInput,  ULONG   dwFlags);  The BCryptHashData() function performs a one way hash on a data buffer. Call the BCryptFinishHash()  function to finalize the hashing operation to get the hash result.  7.7.3 BCryptDuplicateHash NTSTATUS WINAPI BCryptDuplicateHash(  BCRYPT_HASH_HANDLE  hHash,  BCRYPT_HASH_HANDLE  *phNewHash,  PUCHAR   pbHashObject,  ULONG   cbHashObject,  ULONG   dwFlags);  The BCryptDuplicateHash()function duplicates an existing hash object. The duplicate hash object  contains all state and data that was hashed to the point of duplication.  7.7.4 BCryptFinishHash NTSTATUS WINAPI BCryptFinishHash(  BCRYPT_HASH_HANDLE hHash,  PUCHAR   pbOutput,  ULONG   cbOutput,  ULONG   dwFlags);  The BCryptFinishHash() function retrieves the hash value for the data accumulated from prior calls to  BCryptHashData() function.  © 2015 Microsoft. All Rights Reserved    Page 30 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      7.7.5 BCryptDestroyHash NTSTATUS WINAPI BCryptDestroyHash(  BCRYPT_HASH_HANDLE  hHash);  The BCryptDestroyHash() function destroys a hash object.  7.8 Signing and Verification 7.8.1 BCryptSignHash NTSTATUS WINAPI BCryptSignHash(  BCRYPT_KEY_HANDLE   hKey,  VOID    *pPaddingInfo,  PUCHAR   pbInput,  ULONG   cbInput,  PUCHAR   pbOutput,  ULONG   cbOutput,  ULONG   *pcbResult,  ULONG   dwFlags);  The BCryptSignHash() function creates a signature of a hash value.  hKey [in] is the handle of the key to use to sign the hash.   pPaddingInfo [in, optional] is a pointer to a structure that contains padding information. The actual type  of structure this parameter points to depends on the value of the dwFlags parameter. This parameter is  only used with asymmetric keys and must be NULL otherwise.   pbInput [in] is a pointer to a buffer that contains the hash value to sign. The cbInput parameter contains  the size of this buffer.   cbInput [in] is the number of bytes in the pbInput buffer to sign.   pbOutput [out] is the address of a buffer to receive the signature produced by this function. The  cbOutput parameter contains the size of this buffer. If this parameter is NULL, this function will calculate  the size required for the signature and return the size in the location pointed to by the pcbResult  parameter.  cbOutput [in] is the size, in bytes, of the pbOutput buffer. This parameter is ignored if the pbOutput  parameter is NULL.   pcbResult [out] is a pointer to a ULONG variable that receives the number of bytes copied to the  pbOutput buffer. If pbOutput is NULL, this receives the size, in bytes, required for the signature.  dwFlags [in] is a set of flags that modify the behavior of this function. The allowed set of flags depends  on the type of key specified by the hKey parameter. If the key is a symmetric key, this parameter is not  used and should be set to zero. If the key is an asymmetric key, this can be one of the following values:  BCRYPT_PAD_PKCS1, BCRYPT_PAD_PSS.  © 2015 Microsoft. All Rights Reserved    Page 31 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      Note: this function accepts SHA‐1 hashes, which according to NIST SP 800‐131A is currently deprecated  for digital signature generation and will be disallowed after the end of 2013. SHA‐1 is currently legacy‐ use for digital signature verification.    7.8.2 BCryptVerifySignature NTSTATUS WINAPI BCryptVerifySignature(  BCRYPT_KEY_HANDLE   hKey,  VOID    *pPaddingInfo,  PUCHAR   pbHash,  ULONG   cbHash,  PUCHAR   pbSignature,  ULONG   cbSignature,  ULONG   dwFlags);  The BCryptVerifySignature() function verifies that the specified signature matches the specified hash.  hKey [in] is the handle of the key to use to decrypt the signature. This must be an identical key or the  public key portion of the key pair used to sign the data with the BCryptSignHash function.   pPaddingInfo [in, optional] is a pointer to a structure that contains padding information. The actual type  of structure this parameter points to depends on the value of the dwFlags parameter. This parameter is  only used with asymmetric keys and must be NULL otherwise.   pbHash [in] is the address of a buffer that contains the hash of the data. The cbHash parameter contains  the size of this buffer.   cbHash [in] is the size, in bytes, of the pbHash buffer.   pbSignature [in] is the address of a buffer that contains the signed hash of the data. The BCryptSignHash  function is used to create the signature. The cbSignature parameter contains the size of this buffer.  cbSignature [in] is the size, in bytes, of the pbSignature buffer. The BCryptSignHash function is used to  create the signature.  Note: this function accepts SHA‐1 hashes, which according to NIST SP 800‐131A is currently deprecated  for digital signature generation and will be disallowed after the end of 2013. SHA‐1 is currently legacy‐ use for digital signature verification.  7.9 Secret Agreement and Key Derivation 7.9.1 BCryptSecretAgreement NTSTATUS WINAPI BCryptSecretAgreement(  BCRYPT_KEY_HANDLE       hPrivKey,  BCRYPT_KEY_HANDLE       hPubKey,  BCRYPT_SECRET_HANDLE    *phAgreedSecret,  © 2015 Microsoft. All Rights Reserved    Page 32 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      ULONG                   dwFlags);  The BCryptSecretAgreement() function creates a secret agreement value from a private and a public  key. This function is used with Diffie‐Hellman (DH) and Elliptic Curve Diffie‐Hellman (ECDH) algorithms.  hPrivKey [in] The handle of the private key to use to create the secret agreement value.   hPubKey [in] The handle of the public key to use to create the secret agreement value.   phSecret [out] A pointer to a BCRYPT_SECRET_HANDLE that receives a handle that represents the secret  agreement value. This handle must be released by passing it to the BCryptDestroySecret function when  it is no longer needed.   dwFlags [in] A set of flags that modify the behavior of this function. This must be zero.  7.9.2 BCryptDeriveKey NTSTATUS WINAPI BCryptDeriveKey(  BCRYPT_SECRET_HANDLE hSharedSecret,  LPCWSTR              pwszKDF,  BCryptBufferDesc     *pParameterList,  PUCHAR pbDerivedKey,  ULONG                cbDerivedKey,  ULONG                *pcbResult,  ULONG                dwFlags);  The BCryptDeriveKey() function derives a key from a secret agreement value.  hSharedSecret [in, optional] is the secret agreement handle to create the key from. This handle is  obtained from the BCryptSecretAgreement function.   pwszKDF [in] is a pointer to a null‐terminated Unicode string that contains an object identifier (OID) that  identifies the key derivation function (KDF) to use to derive the key. This can be one of the following  strings: BCRYPT_KDF_HASH (parameters in pParameterList: KDF_HASH_ALGORITHM,  KDF_SECRET_PREPEND, KDF_SECRET_APPEND), BCRYPT_KDF_HMAC (parameters in pParameterList:  KDF_HASH_ALGORITHM, KDF_HMAC_KEY, KDF_SECRET_PREPEND, KDF_SECRET_APPEND),  BCRYPT_KDF_TLS_PRF (parameters in pParameterList: KDF_TLS_PRF_LABEL, KDF_TLS_PRF_SEED) ,  BCRYPT_KDF_SP80056A_CONCAT (parameters in pParameterList: KDF_ALGORITHMID,  KDF_PARTYUINFO, KDF_PARTYVINFO, KDF_SUPPPUBINFO, KDF_SUPPPRIVINFO).  pParameterList [in, optional] is the address of a BCryptBufferDesc structure that contains the KDF  parameters. This parameter is optional and can be NULL if it is not needed.   Note: When supporting a key agreement scheme that requires a nonce, BCryptDeriveKey  uses  whichever nonce is supplied by the caller in the BCryptBufferDesc. Examples of the nonce types are  found in Section 5.4 of http://csrc.nist.gov/publications/nistpubs/800‐56A/SP800‐ 56A_Revision1_Mar08‐2007.pdf   © 2015 Microsoft. All Rights Reserved    Page 33 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      When using a nonce, a random nonce should be used. And then if the random nonce is used, the  entropy (amount of randomness) of the nonce and the security strength of the DRBG has to be at least  one half of the minimum required bit length of the subgroup order.  For example:   for KAS FFC, entropy of nonce must be 80 bits for FA, 112 bits for FB, 128 bits for FC.   for KAS ECC, entropy of the nonce must be 128 bits for EC, 182 for ED, 256 for EF.    pbDerivedKey [out, optional] is the address of a buffer that receives the key. The cbDerivedKey  parameter contains the size of this buffer. If this parameter is NULL, this function will place the required  size, in bytes, in the ULONG pointed to by the pcbResult parameter.   cbDerivedKey [in] contains the size, in bytes, of the pbDerivedKey buffer.   pcbResult [out] is a pointer to a ULONG that receives the number of bytes that were copied to the  pbDerivedKey buffer. If the pbDerivedKey parameter is NULL, this function will place the required size,  in bytes, in the ULONG pointed to by this parameter.   dwFlags [in] is a set of flags that modify the behavior of this function. This can be zero or  KDF_USE_SECRET_AS_HMAC_KEY_FLAG. The KDF_USE_SECRET_AS_HMAC_KEY_FLAG value must only  be used when pwszKDF is equal to BCRYPT_KDF_HMAC. It indicates that the secret will also be used as  the HMAC key. If this flag is used, the KDF_HMAC_KEY parameter must not be specified in  pParameterList.  7.9.3 BCryptDestroySecret NTSTATUS WINAPI BCryptDestroySecret(  BCRYPT_SECRET_HANDLE   hSecret);  The BCryptDestroySecret() function destroys a secret agreement handle that was created by using the  BCryptSecretAgreement() function.  7.9.4 BCryptKeyDerivation NTSTATUS WINAPI BCryptKeyDerivation(      _In_        BCRYPT_KEY_HANDLE hKey,      _In_opt_    BCryptBufferDesc     *pParameterList,      _Out_writes_bytes_to_(cbDerivedKey, *pcbResult) PUCHAR pbDerivedKey,      _In_        ULONG                cbDerivedKey,      _Out_       ULONG                *pcbResult,      _In_        ULONG                dwFlags);    © 2015 Microsoft. All Rights Reserved    Page 34 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      The BCryptKeyDerivation() function executes a Key Derivation Function (KDF) on a key generated with  BCryptGenerateSymmetricKey() function. It differs from the BCryptDeriveKey() function in that it does  not require a secret agreement step to create a shared secret.    hKey [in] is a handle to a key created with the BCryptGenerateSymmetricKey function.    pParameterList [in] is the algorithm‐specific parameter list for the selected KDF.    pbDerivedKey [out] is the address of a buffer that receives the key. The cbDerivedKey parameter  contains the size of this buffer.   cbDerivedKey [in] contains the size, in bytes, of the pbDerivedKey buffer.   pcbResult [out] is a pointer to a ULONG that receives the number of bytes that were copied to the  pbDerivedKey buffer. If the pbDerivedKey parameter is NULL, this function will place the required size,  in bytes, in the ULONG pointed to by this parameter.   dwFlags [in] is a set of flags that modify the behavior of this function. This must be zero.  7.10 Legacy Compatibility Interfaces The Kernel Mode Cryptographic Primitives Library driver provides an additional set of interfaces for  compatibility with legacy software written for previous versions of Windows. These interfaces are  described in this section.  These legacy interfaces are not exported by the Kernel Mode Cryptographic Primitives Library driver. A  kernel mode user of the Kernel Mode Cryptographic Primitives Library driver must be able to reference  these functions before using them. The user needs to acquire the table of pointers to the legacy  functions from the Kernel Mode Cryptographic Primitives Library driver. The user accomplishes the table  acquisition by building a Fips function table request IRP (I/O request packet) and then sending the IRP to  the Kernel Mode Cryptographic Primitives Library diver via the IoCallDriver function.  Further  information on IRP and IoCallDriver can be found on the Windows 8.1 Driver Development Kit.  7.10.1 Key Formatting The following functions provide interfaces to the Kernel Mode Cryptographic Primitives Library module’s  key formatting functions.  7.10.1.1 FipsDesKey VOID FipsDesKey(  DESTable *  pDesTable,   UCHAR *  pbKey)  Note that DES cannot be used in FIPS mode. Nevertheless, this interface is documented here for  completeness. The FipsDesKey function formats a DES cryptographic session key into the form of a  DESTable struct. It fills in the DESTable struct with the decrypt and encrypt key expansions. Its second  © 2015 Microsoft. All Rights Reserved    Page 35 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      parameter points to the DES key of DES_BLOCKLEN (8) bytes. FipsDesKey zeroizes its copy of the key  before returning to the caller.  7.10.1.2 Fips3Des3Key VOID Fips3Des3Key(  DES3TABLE *   pDES3Table,   UCHAR *  pbKey)  The Fips3Des3Key function formats a Triple DES cryptographic session key into the form of a DES3Table  struct. It fills in the DES3Table struct with the decrypt and encrypt key expansions. Its second parameter  points to the Triple DES key of 3 * DES_BLOCKLEN (24) bytes.  Fips3Des3Key zeroizes its copy of the key  before returning to the caller.    7.10.2 Data Encryption and Decryption The following functions provide interfaces to the Kernel Mode Cryptographic Primitives Library module’s  data encryption and decryption functions.    7.10.2.1 FipsDes VOID FipsDes(  UCHAR *  pbOut,   UCHAR *  pbIn,   void *    pKey,   int     iOp)  Note that DES cannot be used in FIPS mode. Nevertheless, this interface is documented here for  completeness. The FipsDes function encrypts or decrypts the input buffer pbIn using DES, putting the  result into the output buffer pbOut. The operation (encryption or decryption) is specified with the iOp  parameter.  The pKey is a DESTable struct pointer returned by the FipsDesKey function. FipsDes zeroizes  its copy of the DESTable struct before returning to the caller.  7.10.2.2 Fips3Des VOID Fips3Des(  UCHAR *  pbIn,   UCHAR *  pbOut,   void *    pKey,   int     op)  The Fips3Des function encrypts or decrypts the input buffer pbIn using Triple DES, putting the result into  the output buffer pbOut. The operation (encryption or decryption) is specified with the op parameter.   The pkey is a DES3Table struct returned by the Fips3Des3Key function. Fips3Des zeroizes its copy of the  DES3Table struct before returning to the caller.    7.10.2.3 FipsCBC BOOL FipsCBC(  © 2015 Microsoft. All Rights Reserved    Page 36 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      ULONG  EncryptionType,  BYTE   * output,  BYTE   * input,  void   *    keyTable,  int        op,  BYTE   * feedback)  Note that DES cannot be used in FIPS mode. Nevertheless, the DES encryption type is documented here  for completeness. The FipsCBC function encrypts or decrypts the input buffer input using CBC mode,  putting the result into the output buffer output.  The encryption algorithm (DES or Triple DES) to be  used is specified with the EncryptionType parameter. The operation (encryption or decryption) is  specified with the op parameter.   If the EncryptionType parameter specifies Triple DES, the keyTable is a DES3Table struct returned by the  Fips3Des3Key function. If the EncryptionType parameter specifies DES, the keyTable is a DESTable struct  returned by the FipsDesKey function.  This function encrypts just one block at a time and assumes that the caller knows the algorithm block  length and the buffers are of the correct length. Every time when the function is called, it zeroizes its  copy of the DES3Table or DESTable struct before returning to the caller.  7.10.2.4 FipsBlockCBC BOOL FipsBlockCBC(  ULONG  EncryptionType,  BYTE   * output,  BYTE   * input,  ULONG    length,  void   *    keyTable,  int        op,  BYTE   * feedback)  Note that DES cannot be used in FIPS mode. Nevertheless, the DES encryption type is documented here  for completeness. Same as FipsCBC, the FipsBlockCBC function encrypts or decrypts the input buffer  input using CBC mode, putting the result into the output buffer output.  The encryption algorithm (DES  or Triple DES) to be used is specified with the EncryptionType parameter. The operation (encryption or  decryption) is specified with the op parameter.   If the EncryptionType parameter specifies Triple DES, the keyTable is a DES3Table struct returned by the  Fips3Des3Key function. If the EncryptionType parameter specifies DES, the keyTable is a DESTable struct  returned by the FipsDesKey function.   This function can encrypt/decrypt more than one block at a time.  The caller specifies the length in bytes  of the input buffer in the “length” parameter.   So the input/output buffer length is the arithmetic  product of the number of blocks in the input/output buffer and the block length (8 bytes).  When the  length is 8 (i.e. one block of input buffer), FipsBlockCBC is the same as FipsCBC.    © 2015 Microsoft. All Rights Reserved    Page 37 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      Every time when the function is called, it zeroizes its copy of the DES3Table or DESTable struct before  returning to the caller.  7.10.3 Hashing The following functions provide interfaces to the Kernel Mode Cryptographic Primitives Library module’s  hashing functions.  7.10.3.1 FipsSHAInit void FipsSHAInit(  A_SHA_CTX *   hash_context)  The FipsSHAInit function initiates the hashing of a stream of data.  The output hash_context is used in  subsequent hash functions.  7.10.3.2 FipsSHAUpdate void FipsSHAUpdate(  A_SHA_CTX *  hash_context,   UCHAR *  pb,  unsigned int   cb)  The FipsSHAUpdate function adds data pb of size cb to a specified hash object associated with the  context hash_context. This function can be called multiple times to compute the hash on long data  streams or discontinuous data streams. The FipsSHAFinal function must be called before retrieving the  hash value.  7.10.3.3 FipsSHAFinal void FipsSHAFinal (  A_SHA_CTX *        hash_context,   unsigned char [A_SHA_DIGEST_LEN]  hash)  The FipsSHAFinal function computes the final hash of the data entered by the FipsSHAUpdate function.   The hash is an array char of size A_SHA_DIGEST_LEN (20 bytes).  7.10.3.4 FipsHmacSHAInit void FipsSHAInit(  A_SHA_CTX *   pShaCtx  UCHAR *  pKey,  unsigned int   cbKey)  The FipsHmacSHAInit function initiates the HMAC hashing of a stream of data, with an input key  provided via the pKey parameter.  The size of the input key is specified in the cbKey parameter.  If the  key size is greater than 64 bytes, the key is hashed to a new key of size 20 bytes using SHA‐1.  The input  key is EOR’ed with the ipad as required in the HMAC FIPS.  The output pShaCtx is used in subsequent  HMAC hashing functions.  Every time when the function is called, it zeroizes its copy of the pKey before  returning to the caller.    © 2015 Microsoft. All Rights Reserved    Page 38 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library          7.10.3.5 FipsHmacSHAUpdate void FipsSHAUpdate(  A_SHA_CTX *  pShaCtx,   UCHAR *  pb,  unsigned int   cb)  The FipsHmacSHAUpdate function adds data pb of size cb to a specified HMAC hashing object associated  with the context pShaCtx. This function can be called multiple times to compute the HMAC hash on long  data streams or discontinuous data streams. The FipsHmacSHAFinal function must be called before  retrieving the final HMAC hash value.  7.10.3.6 FipsHmacSHAFinal void FipsHmacSHAFinal (  A_SHA_CTX *  pShaCtx,   UCHAR *  pKey,  unsigned int   cbKey,  UCHAR  *  hash)  The FipsHmacSHAFinal function computes the final HMAC hash of the data entered by the  FipsHmacSHAUpdate function, with an input key provided via the pKey parameter.  The size of the input  key is specified in the cbKey parameter.  If the key size is greater than 64 bytes, the key is hashed to a  new key of size 20 bytes using SHA‐1.  The input key is EOR’ed with the opad as required in the HMAC  FIPS. It is the caller’s responsibility to make sure that the input key used in FipsHmacSHAFinal is the  same as the input key used in FipsHmacSHAInit.   The final HMAC hash is an array char of size  A_SHA_DIGEST_LEN (20 bytes).  Every time when the function is called, it zeroizes its copy of the pKey  before returning to the caller.  7.10.3.7 HmacMD5Init void HmacMD5Init(  MD5_CTX *  pMD5Ctx,  UCHAR *  pKey,  unsigned int   cbKey)  Note that HMAC‐MD5 cannot be used in FIPS mode. Nevertheless, this interface is documented here for  completeness. The HmacMD5Init function initiates the HMAC hashing of a stream of data, with an input  key provided via the pKey parameter.  The size of the input key is specified in the cbKey parameter.  If  the key size is greater than 64 bytes, the key is hashed to a new key of size 16 bytes using MD5 as  required in the HMAC FIPS.  The input key is EOR’ed with the ipad.  The output pMD5Ctx is used in  subsequent HMAC hashing functions.  Every time when the function is called, it zeroizes its copy of the  pKey before returning to the caller.      © 2015 Microsoft. All Rights Reserved    Page 39 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library        7.10.3.8 HmacMD5Update void HmacMD5Update(  MD5_CTX *  pMD5Ctx,  UCHAR *  pb,  unsigned int   cb)  Note that HMAC‐MD5 cannot be used in FIPS mode. Nevertheless, this interface is documented here for  completeness. The HmacMD5Update function adds data pb of size cb to a specified HMAC hashing  object associated with the context pMD5Ctx. This function can be called multiple times to compute the  HMAC hash on long data streams or discontinuous data streams. The HmacMD5Update function must  be called before retrieving the final HMAC hash value.  7.10.3.9 HmacMD5Final void HmacMD5Final(  MD5_CTX *pMD5Ctx,  UCHAR *pKey,  unsigned int cbKey,  UCHAR *pHash)  Note that HMAC‐MD5 cannot be used in FIPS mode. Nevertheless, this interface is documented here for  completeness. The HmacMD5Final function computes the final HMAC hash of the data entered by the  HmacMD5Update function, with an input key provided via the pKey parameter.  The size of the input  key is specified in the cbKey parameter.  If the key size is greater than 64 bytes, the key is hashed to a  new key of size 16 bytes using MD5.  The input key is EOR’ed with the opad as required in the HMAC  FIPS.  It is the caller’s responsibility to make sure that the input key used in HmacMD5Final is the same  as the input key used in HmacMD5Init.   The final HMAC hash is an array char of size A_ MD5DIGESTLEN  (16 bytes).  Every time when the function is called, it zeroises its copy of the pKey before returning to  the caller.  7.11 Deprecation 7.11.1 Bit Strengths of DH and ECDH Through the year 2010, implementations of DH and ECDH were allowed to have an acceptable bit  strength of at least 80 bits of security (for DH at least 1024 bits and for ECDH at least 160 bits). From  2011 through 2013, 80 bits of security strength is considered deprecated, and will be disallowed starting  January 1, 2014. On that date, only security strength of at least 112 bits will be acceptable. ECDH uses  curve sizes of at least 256 bits (that means it has at least 128 bits of security strength), so that is  acceptable. However, DH has a range of 1024 to 4096 and that will change to 2048 to 4096 after 2013.  © 2015 Microsoft. All Rights Reserved    Page 40 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      7.11.2 SHA‐1 From 2011 through 2013, SHA‐1 can be used in a deprecated mode for use in digital signature  generation. On Jan. 1, 2014, SHA‐1 will no longer be allowed for digital signature generation, and it will  be allowed for legacy use only for digital signature verification.  7.12 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.13 Self‐Test Services The User and Cryptographic Officer roles have the same Self‐Test functionality, which is described in  Section 10 Self‐Tests.  7.14 Service Inputs / Outputs The User and Cryptographic Officer roles have service inputs and outputs as specified in Section 5 Ports  and Interfaces and as described in detail above.  8 Authentication See Section 6.3 Operator Authentication.        © 2015 Microsoft. All Rights Reserved    Page 41 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      9 Security Relevant Data Items The Kernel Mode Cryptographic Primitives Library crypto module manages the following security  relevant data items.  Security Relevant Data Item  Description   Symmetric encryption/decryption keys  Keys used for AES or TDEA encryption/decryption. Key sizes  for AES are 128, 192, and 256 bits, and key sizes for TDES  are 168 and 112 bits.  HMAC keys  Keys used for HMAC‐SHA1, HMAC‐SHA256, HMAC‐SHA384,  and HMAC‐SHA512  Asymmetric ECDSA Public Keys  Keys used for the verification of ECDSA digital signatures.  Curve sizes are P‐256, P‐384, and P‐521.  Asymmetric ECDSA Private Keys  Keys used for the calculation of ECDSA digital signatures.  Curve sizes are P‐256, P‐384, and P‐521.  Asymmetric RSA Public Keys  Keys used for the verification of RSA digital signatures. Key  sizes are 2048 and 3072 bits.  Asymmetric RSA Private Keys  Keys used for the calculation of RSA digital signatures. Key  sizes are 2048 and 3072 bits.  AES‐CTR DRBG Seed  A secret value maintained internal to the module that  provides the seed material for AES‐CTR DRBG output  AES‐CTR DRBG Entropy Input  A secret value maintained internal to the module that  provides the entropy material for AES‐CTR DRBG output  AES‐CTR DRBG V  A secret value maintained internal to the module that  provides the entropy material for AES‐CTR DRBG output   AES‐CTR DRBG key  A secret value maintained internal to the module that  provides the entropy material for AES‐CTR DRBG output  DUAL EC DRBG Seed  A secret value maintained internal to the module that  provides the seed material for DUAL EC DRBG output  DUAL EC DRBG Entropy Input  A secret value maintained internal to the module that  provides the entropy material for DUAL EC DRBG output  DUAL EC DRBG V  A secret value maintained internal to the module that  provides the entropy material for DUAL EC DRBG output  DUAL EC DRBG key  A secret value maintained internal to the module that  provides the entropy material for DUAL EC DRBG output  DH Private and Public values  Private and public values used for Diffie‐Hellman key  establishment. Key sizes are 2048 to 4096 bits.  ECDH Private and Public values  Private and public values used for EC Diffie‐Hellman key  establishment. Curve sizes are P‐256, P‐384, and P‐521.  9.1 Access Control Policy The Kernel Mode Cryptographic Primitives Library crypto module allows controlled access to the security  relevant data items contained within it.  The following table defines the access that a service has to  each.  The permissions are categorized as a set of four separate permissions: read (r), write (w), execute  (x), delete (d).  If no permission is listed, the service has no access to the item. The User and  Cryptographic Officer roles have the same access to keys so roles are not distinguished in the table.  © 2015 Microsoft. All Rights Reserved    Page 42 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      ECDH Public and Private values RNG & DRBG Seeds/Seed Keys Kernel Mode Cryptographic Primitives DH Public and Private values encryption/decryption keys Library crypto module Service Access Policy ECDSA Private keys ECDSA public keys RSA Private Keys RSA Public Keys HMAC keys Symmetric Cryptographic Module Power Up and Power Down Key Formatting w Random Number Generation x Data Encryption and Decryption x Hashing wx Acquiring a Table of Pointers to FipsXXX Functions Algorithm Providers and Properties Key and Key-Pair Generation wd wd wd wd wd wd wd wd x Key Entry and Output rw rw rw rw rw rw rw rw Signing and Verification x x x x x Secret Agreement and Key Derivation x x x   9.2 Key Material When Kernel Mode Cryptographic Primitives Library is loaded in the Windows 8.1 OEs Operating System  kernel, no keys exist within it. A kernel module is responsible for importing keys into Kernel Mode  Cryptographic Primitives Library or using Kernel Mode Cryptographic Primitives Library’s functions to  generate keys.  9.3 Key Generation Kernel Mode Cryptographic Primitives Library can create and use keys for the following algorithms: RSA,  DH, ECDH, ECDSA, RC2, RC4, DES, Triple‐DES, AES, and HMAC. However, RC2, RC4, and DES cannot be  used in FIPS mode.  Random keys can be generated by calling the BCryptGenerateSymmetricKey() and  BCryptGenerateKeyPair() functions. Random data generated by the BCryptGenRandom() function is  provided to BCryptGenerateSymmetricKey() function to generate symmetric keys. DES, Triple‐DES, AES,  © 2015 Microsoft. All Rights Reserved    Page 43 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      RSA, ECDSA, DH, and ECDH keys and key‐pairs are generated following the techniques given in SP 800‐ 56A (Section 5.8.1).  The module generates cryptographic keys whose strengths are modified by available entropy.  9.4 Key Establishment Kernel Mode Cryptographic Primitives Library can use FIPS approved Diffie‐Hellman key agreement (DH),  Elliptic Curve Diffie‐Hellman key agreement (ECDH), RSA key transport and manual methods to establish  keys. Alternatively, the module can also use Approved KDFs to derive key material from a specified  secret value or password.  Kernel Mode Cryptographic Primitives Library can use the following FIPS approved key derivation  functions (KDF) from the common secret that is established during the execution of DH and ECDH key  agreement algorithms:   BCRYPT_KDF_SP80056A_CONCAT. This KDF supports the Concatenation KDF as specified in SP  800‐56A (Section 5.8.1).   BCRYPT_KDF_HASH. This KDF supports FIPS approved SP800‐56A (Section 5.8), X9.63, and X9.42  key derivation.   BCRYPT_KDF_HMAC. This KDF supports the IPsec IKEv1 key derivation that is non‐Approved but  is an allowed legacy implementation in FIPS mode when used to establish keys for IKEv1 as per  scenario 4 of IG D.8.   BCRYPT_KDF_TLS_PRF. This KDF supports the SSLv3.1 and TLSv1.0 key derivation that is non‐ Approved but is an allowed legacy implementation in FIPS mode when used to establish keys for  SSLv3.1 or TLSv1.0 as specified in as per scenario 4 of IG D.8.    Kernel Mode Cryptographic Primitives Library can use the following FIPS approved key derivation  functions (KDF) from a key handle created from a specified secret or password:   BCRYPT_SP800108_CTR_HMAC_ALGORITHM. This KDF supports the counter‐mode variant of  the KDF specified in SP 800‐108 (Section 5.1) with HMAC as the underlying PRF.   BCRYPT_SP80056A_CONCAT_ALGORITHM. This KDF supports the Concatenation KDF as  specified in SP 800‐56A (Section 5.8.1).   BCRYPT_PBKDF2_ALGORITHM. This KDF supports the Password Based Key Derivation Function  specified in SP 800‐132 (Section 5.3).   BCRYPT_CAPI_KDF_ALGORITHM. This KDF supports the proprietary KDF described at  http://msdn.microsoft.com/library/windows/desktop/aa379916.aspx  Note that this KDF cannot be used in FIPS mode.  9.4.1 NIST SP 800‐132 Password Based Key Derivation Function (PBKDF) There are two (2) options presented in NIST SP 800‐132, pages 8 – 10, that are used to derive the Data   Protection Key (DPK) from the Master Key. With the Kernel Mode Cryptographic Primitives Library, it is  up to the caller to select the option to generate/protect the DPK.  For example, DPAPI uses option  2a.  Kernel Mode Cryptographic Primitives Library provides all the building blocks for the caller to select  the desired option.     © 2015 Microsoft. All Rights Reserved    Page 44 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      The Kernel Mode Cryptographic Primitives Library supports the following HMAC hash functions as  parameters for PBKDF:   SHA‐1 HMAC   SHA‐256 HMAC   SHA‐384 HMAC   SHA‐512 HMAC    Keys derived from passwords, as shown in SP 800‐132, may only be used in storage applications. In  order to run in a FIPS approved manner, it is up to the user and application to pick strong passwords and  use them only for storage applications. The password/passphrase length is enforced by the caller of the  PBKDF interfaces and not the cryptographic module. In order to run in a FIPS approved manner, the  password must be chosen in accordance with the guidelines in NIST SP 800‐63 Electronic Authentication  Guideline and SP 800‐118 DRAFT Guide to Enterprise Password Management.  The upper bound for the  probability of having the password guessed at random is to be computed following the SP 800‐63 and SP  800‐118 guidelines. The decision for the minimum length of a password used for key derivation is to be  based on the SP 800‐63 and SP 800‐118 guidelines.    9.5 Key Entry and Output Keys can be both exported and imported out of and into Kernel Mode Cryptographic Primitives Library  via BCryptExportKey(), BCryptImportKey(), and BCryptImportKeyPair() functions.  Symmetric key entry and output can also be done by exchanging keys using the recipient’s asymmetric  public key via BCryptSecretAgreement() and BCryptDeriveKey() functions.  Triple DES keys can be imported into Kernel Mode Cryptographic Primitives Library via Fips3Des3Key().  DES3Table struct can be exported out of Kernel Mode Cryptographic Primitives Library via  Fips3Des3Key().  DES3Table struct can be imported into Kernel Mode Cryptographic Primitives Library  via Fips3Des() or FipsCBC().  HMAC keys can be imported into Kernel Mode Cryptographic Primitives Library via FipsHmacSHAInit and  FipsHmacSHAFinal.   Exporting the RSA private key by supplying a blob type of BCRYPT_PRIVATE_KEY_BLOB,  BCRYPT_RSAFULLPRIVATE_BLOB, or BCRYPT_RSAPRIVATE_BLOB to BCryptExportKey() is not allowed in  FIPS mode.  9.6 Key Storage Kernel Mode Cryptographic Primitives Library does not provide persistent storage of keys.   © 2015 Microsoft. All Rights Reserved    Page 45 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      9.7 Key Archival Kernel Mode Cryptographic Primitives Library does not directly archive cryptographic keys. A user may  choose to export a cryptographic key (cf. “Key Entry and Output” above), but management of the secure  archival of that key is the responsibility of the user. All key copies inside Kernel Mode Cryptographic  Primitives Library are destroyed and their memory location zeroized after used. It is the caller’s  responsibility to maintain the security of Triple DES and HMAC keys when the keys are outside Kernel  Mode Cryptographic Primitives Library.   9.8 Key Zeroization All keys are destroyed and their memory location zeroized when the operator calls BCryptDestroyKey()  or BCryptDestroySecret() on that key handle.  All  Triple DES key copies, their associated DESTable and DES3Table struct copies, and HMAC key copies  inside Kernel Mode Cryptographic Primitives Library are destroyed and their memory location zeroized  after they have been used in Fips3Des or FipsCBC.  10 Self‐Tests 10.1 Power‐On Self‐Tests Kernel Mode Cryptographic Primitives Library automatically performs the following power‐on (startup)  self‐tests upon loading of the CNG.SYS driver through its default entry point (DriverEntry).   HMAC‐SHA‐1 Known Answer Test   HMAC‐SHA‐256 and HMAC‐SHA‐512 Known Answer Tests   Triple‐DES encrypt/decrypt ECB Known Answer Tests   AES‐128 encrypt/decrypt EBC Known Answer Tests   AES‐128 encrypt/decrypt CBC Known Answer Tests   AES‐128 CMAC Known Answer Test   AES‐128 encrypt/decrypt CCM Known Answer Tests   AES‐128 encrypt/decrypt GCM Known Answer Tests   SP 800‐108 KDF Known Answer Test   SP 800‐132 PBKDF Known Answer Test   RSA sign/verify Known Answer Tests   ECDSA sign/verify Known Answer Tests on P256 curve   ECDH secret agreement Known Answer Test on P256 curve   SP800‐56A concatenation KDF Known Answer Tests (same as Diffie‐Hellman KAT)   SP800‐90 AES‐256 counter mode DRBG Known Answer Tests (instantiate, generate and reseed)   SP800‐90 Dual‐EC DRBG Known Answer Tests (instantiate, generate and reseed)    In all cases for any failure of a power‐on (startup) self‐test, the Kernel Mode Cryptographic Primitives  Library module will not load and status will be returned. The only way to recover from the failure of a  © 2015 Microsoft. All Rights Reserved    Page 46 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      power‐on (startup) self‐test is for the kernel to attempt to invoke DriverEntry, which will rerun the self‐ tests, and will only succeed if the self‐tests pass.  10.2 Conditional Self‐Tests Kernel Mode Cryptographic Primitives Library performs pair‐wise consistency checks upon each  invocation of RSA, ECDH, and ECDSA key‐pair generation and import as defined in FIPS 140‐2. A  continuous RNG test (CRNGT) is used for the random number generators of this cryptographic module.  All approved and non‐approved RNGs have a CRNGT. If the conditional 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  conditional self‐test failed.   CRNGTs for SP800‐90 AES‐CTR DRBG, SP800‐90 Dual‐EC DRBG, and non‐Approved RNG (entropy  pool)   Pairwise consistency test for RSA   Pairwise consistency test for ECDSA key generation   Pairwise consistency tests for Diffie‐Hellman and EC Diffie‐Hellman prime value generation   Assurances for SP800‐56A (According to sections 5.5.2, 5.6.2, and 5.6.3 of the standard)   DRBG health test for SP800‐90 AES‐CTR   DRBG health test for Dual‐EC DRBGs  11 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, Surface 2,  Pre‐installed by the OEM (Microsoft)  Surface   Windows RT 8.1  Pre‐installed on the device by OEM   Download that updates Windows RT   Windows Phone 8.1  Pre‐installed on the device by OEM or mobile  network operator   Download that updates Windows 8  © 2015 Microsoft. All Rights Reserved    Page 47 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library       Windows Embedded 8.1 Industry Enterprise  Pre‐installed by the OEM (Third party)   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.  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.  12 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  © 2015 Microsoft. All Rights Reserved    Page 48 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      confidential data  3DES  Timing  Constant Time Implementation     Analysis  Attack  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  13 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      © 2015 Microsoft. All Rights Reserved    Page 49 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      14 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 50 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).  Kernel Mode Cryptographic Primitives Library      15 Appendix A – How to Verify Windows Versions and Digital Signatures 15.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.  15.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 51 of 51  This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision).