Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 1 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
Microsoft Windows
FIPS 140 Validation
Microsoft Windows 10 (May 2019 Update, November 2019
Update and May 2020 Update)
Microsoft Windows Server (versions 1903, 1909, and 2004)
Non-Proprietary
Security Policy Document
Version Number 1.2
Updated On April 19, 2023
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 2 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
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.
© 2023 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.
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 3 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
Version History
Version Date Summary of changes
1.0 November 4, 2020 Draft sent to NIST CMVP
1.1 October 28, 2022 Updates in response to NIST comments
1.2 April 19, 2023 Added CMVP certificate numbers for bounded modules
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 4 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
TABLE OF CONTENTS
SECURITY POLICY DOCUMENT.....................................................................................................1
VERSION HISTORY..............................................................................................................................3
1 INTRODUCTION...................................................................................................................6
1.1 LIST OF CRYPTOGRAPHIC MODULE BINARY EXECUTABLES..................................................................6
1.2 VALIDATED PLATFORMS............................................................................................................7
2 CRYPTOGRAPHIC MODULE SPECIFICATION.........................................................................12
2.1 CRYPTOGRAPHIC BOUNDARY....................................................................................................12
2.2 FIPS 140-2 APPROVED ALGORITHMS ........................................................................................13
2.3 NON-APPROVED ALGORITHMS .................................................................................................13
2.4 FIPS 140-2 APPROVED ALGORITHMS FROM BOUNDED MODULES ....................................................13
2.5 CRYPTOGRAPHIC BYPASS.........................................................................................................14
2.6 HARDWARE COMPONENTS OF THE CRYPTOGRAPHIC MODULE..........................................................14
3 CRYPTOGRAPHIC MODULE PORTS AND INTERFACES ..........................................................15
3.1 SKCI EXPORT FUNCTIONS........................................................................................................15
3.1.1 SKCIINITIALIZE.................................................................................................................................15
3.1.2 SKCICREATECODECATALOG...............................................................................................................16
3.1.3 SKCICREATESECUREIMAGE................................................................................................................16
3.1.4 SKCIVALIDATEIMAGEDATA................................................................................................................16
3.1.5 SKCIVALIDATEDYNAMICCODEPAGES...................................................................................................16
3.1.6 SKCIFINALIZESECUREIMAGEHASH.......................................................................................................16
3.1.7 SKCIFINISHIMAGEVALIDATION ...........................................................................................................16
3.1.8 SKCIFREEIMAGECONTEXT .................................................................................................................16
3.1.9 SKCITRANSFERVERSIONRESOURCE .....................................................................................................16
3.1.10 SKCIMATCHHOTPATCH ....................................................................................................................17
3.2 CONTROL INPUT INTERFACE .....................................................................................................17
3.3 STATUS OUTPUT INTERFACE.....................................................................................................17
3.4 DATA INPUT INTERFACE ..........................................................................................................17
3.5 DATA OUTPUT INTERFACE .......................................................................................................17
4 ROLES, SERVICES AND AUTHENTICATION...........................................................................17
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 5 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
4.1 ROLES.................................................................................................................................17
4.2 SERVICES.............................................................................................................................17
4.3 AUTHENTICATION..................................................................................................................19
5 FINITE STATE MODEL.........................................................................................................20
5.1 SPECIFICATION......................................................................................................................20
6 OPERATIONAL ENVIRONMENT...........................................................................................20
6.1 SINGLE OPERATOR.................................................................................................................21
6.2 CRYPTOGRAPHIC ISOLATION.....................................................................................................21
6.3 INTEGRITY CHAIN OF TRUST .....................................................................................................21
7 CRYPTOGRAPHIC KEY MANAGEMENT ................................................................................23
8 SELF-TESTS........................................................................................................................23
9 DESIGN ASSURANCE..........................................................................................................23
10 MITIGATION OF OTHER ATTACKS.......................................................................................24
11 SECURITY LEVELS...............................................................................................................25
12 ADDITIONAL DETAILS ........................................................................................................25
13 APPENDIX A – HOW TO VERIFY WINDOWS VERSIONS AND DIGITAL SIGNATURES ...............26
13.1 HOW TO VERIFY WINDOWS VERSIONS .......................................................................................26
13.2 HOW TO VERIFY WINDOWS DIGITAL SIGNATURES .........................................................................26
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 6 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
1 Introduction
Secure Kernel Code Integrity (SKCI) is a code integrity mechanism that runs in the Virtual Secure Mode
(VSM) of the Windows Hyper-V hypervisor. SKCI is implemented in a Dynamic Link Library (DLL) file,
SKCI.DLL.
Code Integrity and Secure Kernel Code Integrity are closely related modules that are used, depending on
configuration of Windows, to validate system and application binaries.
Two Windows configuration options dictate whether Code Integrity or Secure Kernel Code Integrity are
used to verify a binary image:
• Virtual Secure Mode (VSM), also known as Core Isolation: Windows can use the Hypervisor to
start an execution environment, called the Secure Kernel, that can enforce additional security
rules. When VSM is configured, Secure Kernel Code Integrity verifies the integrity of critical user-
mode modules such as BCRYPTPRIMITIVES.DLL instead of the Code Integrity module.
• Hypervisor Code Integrity (HVCI) , also known as Memory Integrity: This feature depends on
VSM. When enabled, all drivers loaded into the Windows kernel are integrity verified by Secure
Kernel Code Integrity.
This Security Policy Document assumes that the following hardware prerequisites are available:
• UEFI Secure Boot is available and enabled
• Trusted Platform Module (TPM)
• Hardware virtualization support (VT-x or AMD-V)
Additionally, VSM must be configured for SKCI.DLL to be loaded and used.
1.1 List of Cryptographic Module Binary Executables
Secure Kernel Code Integrity cryptographic module contains the following binary. Each binary has a
distinct implementation per build for each instruction set (x86, x64, ARM64).
• skci.dll
The Windows builds and instruction sets covered by this validation are:
• Windows 10 and Windows Server version 1903, build 10.0.18362
o x86
o x64
• Windows 10 and Windows Server version 1909, build 10.0.18363
o x86
o x64
• Windows 10 and Windows Server version 2004, build 10.0.19041
o x86
o x64
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 7 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
o ARM64
Tables 1-3 below present the matrix of hardware platforms, Windows builds, and Windows editions
validated.
1.2 Validated Platforms
The Windows editions covered by this validation are:
• Microsoft Windows 10 Home Edition (32-bit version)
• Microsoft Windows 10 Pro Edition (64-bit version)
• Microsoft Windows 10 Enterprise Edition (64-bit version)
• Microsoft Windows 10 Education Edition (64-bit version)
• Windows Server Core Standard
• Windows Server Core Datacenter
SKCI was validated using the combination of computers and Windows operating system editions
specified in the table below.
All the computers for Windows 10 and Windows Server listed in the table below are all 64-bit Intel
architecture and implement the AES-NI instruction set but not the SHA Extensions. The exceptions are:
• Dell Inspiron 660s - Intel Core i3 without AES-NI and SHA Extensions
• HP Slimline Desktop - Intel Pentium with AES-NI and SHA Extensions
• Dell PowerEdge 7425 - AMD EPYC 7251 with AES-NI and SHA Extensions
• Microsoft Surface Pro X - Microsoft SQ1 with Arm Neon
Table 1 Validated Platforms for Windows 10 and Windows Server version 1903
Computer Windows
10 Home
Windows
10 Pro
Windows 10
Enterprise
Windows
10
Education
Windows
Server
Core
Windows
Serve Core
Datacenter
Microsoft
Surface Go -
Intel Pentium
√
Microsoft
Surface Book 2 -
Intel Core i7
√ √
Microsoft
Surface Pro 6 -
Intel Core i5
√ √
Microsoft
Surface Laptop 2
- Intel Core i5
√ √ √
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 8 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
Microsoft
Surface Studio 2
- Intel Core i7
√
Microsoft
Windows Server
2019 Hyper-V1
√ √
Microsoft
Windows Server
2016 Hyper-V2
√
Dell Latitude 12
Rugged Tablet -
Intel Core i5
√
Dell Latitude
5290 - Intel Core
i7
√
Dell PowerEdge
R740 - Intel
Xeon Gold
√
Dell PowerEdge
R7425 - AMD
EPYC 7251
√
Dell Inspiron
660s [with x86
Windows] - Intel
Core i3
√
HP Slimline
Desktop - Intel
Pentium
√
HP ZBook15 G5 -
Intel Core i5 √
HP EliteBook
x360 830 G5 -
Intel Core i5
√
Samsung Galaxy
Book 10.6” -
Intel Core m3
√
Samsung Galaxy
Book 12” - Intel
Core i5
√
Panasonic
Toughbook -
Intel Core i5
√
1
Hardware Platform: Dell PowerEdge R740 Server - Intel Xeon Gold
2
Hardware Platform: Dell PowerEdge R7425 Server - AMD EPYC 7251
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 9 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
Table 2 Validated Platforms for Windows 10 and Windows Server version 1909
Computer Windows
10 Home
Windows
10 Pro
Windows 10
Enterprise
Windows
10
Education
Windows
Server
Core
Windows
Server Core
Datacenter
Microsoft
Surface Go -
Intel Pentium
√
Microsoft
Surface Go LTE -
Intel Pentium
√
Microsoft
Surface Book 2 -
Intel Core i7
√
Microsoft
Surface Pro LTE -
Intel Core i5
√
Microsoft
Surface Pro 6 -
Intel Core i5
√
Microsoft
Surface Laptop 2
- Intel Core i5
√
Microsoft
Surface Studio 2
- Intel Core i7
√
Microsoft
Windows Server
2019 Hyper-V3
√
Microsoft
Windows Server
2016 Hyper-V4
√
Dell Latitude
7200 2-in-1 -
Intel Core i7
√
Dell Latitude
5300 2-in-1 -
Intel Core i7
√
3
Hardware Platform: Dell PowerEdge R740 Server - Intel Xeon Platinum
4
Hardware Platform: Dell PowerEdge R7425 Server - AMD EPYC 7251
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 10 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
Dell PowerEdge
R740 - Intel
Xeon Platinum
√
Dell PowerEdge
R7425 - AMD
EPYC 7251
√
Dell Inspiron
660s [with x86
Windows] - Intel
Core i3
√
HP ProBook 650
G5 - Intel Core i7 √
HP EliteBook
x360 830 G6 -
Intel Core i7
√
HP Slimline
Desktop - Intel
Pentium
√
Panasonic
Toughbook CF-
33 - Intel Core i5
√
Samsung Galaxy
Book 10.6” -
Intel Core m3
√
Samsung Galaxy
Book 12” - Intel
Core i5
√
Microsoft
Surface Pro 7 -
Intel Core m3
√
Microsoft
Surface Laptop 3
- Intel Core i5
√
Table 3 Validated Platforms for Windows 10 and Windows Server version 2004
Computer Windows
10 Home
Windows
10 Pro
Windows 10
Enterprise
Windows
10
Education
Windows
Server
Core
Windows
Server Core
Datacenter
Microsoft
Surface Pro LTE -
Intel Core i5
√
Microsoft
Surface Pro 7 -
Intel Core i3
√
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 11 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
Microsoft
Surface Pro 6 -
Intel Core i7
√
Microsoft
Surface Pro X -
Microsoft SQ1
√
Microsoft
Surface Go -
Intel Pentium
√
Microsoft
Surface Go LTE -
Intel Core i7
√
Microsoft
Surface Go 2 -
Intel Core m3
√
Microsoft
Surface Go 2 LTE
- Intel Pentium
√
Microsoft
Surface Laptop 2
- Intel Core i5
√
Microsoft
Surface Laptop 3
- Intel Core i5
√
Microsoft
Surface Book 2 -
Intel Core i7
√
Microsoft
Surface Studio 2
- Intel Core i7
√
Microsoft
Windows Server
2019 Hyper-V5
√ √
Microsoft
Windows Server
2016 Hyper-V6
√
Dell Latitude
7200 2-in-1 -
Intel Core i7
√
Dell Latitude
5300 2-in-1 -
Intel Core i7
√
5
Hardware Platform: Dell Precision 5810 - Intel Xeon E5
6
Hardware Platform: Dell PowerEdge R740 - Intel Xeon Platinum
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 12 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
Dell PowerEdge
R640 - Intel
Xeon Gold
√
Dell PowerEdge
R740 - Intel
Xeon Platinum
√
Dell Inspiron
660s [with x86
Windows] - Intel
Core i3
√
Dynabook
TECRA-X50-F -
Intel Core i7
√
HP Slimline
Desktop - Intel
Pentium
√
HP ZBook 15G6 -
Intel Core i7 √
HP EliteBook
x360 830 G6 -
Intel Core i7
√
HP ProBook 650
G5 - Intel Core i7 √
Panasonic
Toughbook FZ-
55 - Intel Core i5
√
Dell PowerEdge
R7515 - AMD
EPYC 7702P
√
2 Cryptographic Module Specification
Secure Kernel Code Integrity is a multi-chip standalone module that operates in FIPS-approved mode
during normal operation of the computer and Windows operating system.
The following configurations and modes of operation will cause Secure Kernel Code Integrity to operate
in a non-approved mode of operation:
• Boot Windows in Debug mode
• Boot Windows with Driver Signing disabled
• Windows enters the ACPI S4 power state
2.1 Cryptographic Boundary
The software binary that comprises the cryptographic boundary for Secure Kernel Code Integrity is
SKCI.DLL.
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 13 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
2.2 FIPS 140-2 Approved Algorithms
Table 4 - SKCI implements the following FIPS 140-2 Approved algorithms:7
2.3 Non-Approved Algorithms
Secure Kernel Code Integrity only implements approved algorithms.
2.4 FIPS 140-2 Approved Algorithms from Bounded Modules
A bounded module is a FIPS 140 module which provides cryptographic functionality that is relied on by a
downstream module. As described in the Integrity Chain of Trust section, Secure Kernel Code Integrity
depends on the following modules and algorithms:
The Windows OS Loader module for Windows 10 version 1903 (module certificate #4339) provides:
• CAVP certificates #C795 (Windows 10 and Windows Server) for FIPS 186-4 RSA PKCS#1 (v1.5)
digital signature verification with 2048 moduli; supporting SHA-256
• CAVP certificates #C785 (Windows 10 and Windows Server) for FIPS 180-4 SHS SHA-256
The Windows OS Loader module for Windows 10 version 1909 (module certificate #4339) provides:
• CAVP certificates #C1367 (Windows 10 and Windows Server) for FIPS 186-4 RSA PKCS#1 (v1.5)
digital signature verification with 2048 moduli; supporting SHA-256
• CAVP certificates #C1363 (Windows 10 and Windows Server) for FIPS 180-4 SHS SHA-256
The Windows OS Loader module for Windows 10 version 2004 (module certificate #4339) provides:
• CAVP certificates #C1947 (Windows 10 and Windows Server) for FIPS 186-4 RSA PKCS#1 (v1.5)
digital signature verification with 2048 moduli; supporting SHA-256
• CAVP certificates #C1897 (Windows 10 and Windows Server) for FIPS 180-4 SHS SHA-256
7
This module may not use some of the capabilities described in each CAVP certificate.
Algorithm Windows 10 and
Windows Server
version 1903
Windows 10 and
Windows Server
version 1909
Windows 10
and Windows
Server version
2004
FIPS 186-4 RSA PKCS#1 (v1.5) digital
signature verification with 1024,
2048, and 3072 moduli; supporting
SHA-1, SHA-256, SHA-384, and SHA-
512
#C785 #C1363 #C1897
FIPS 180-4 SHS SHA-1, SHA-256, SHA-
384, and SHA-512
#C785 #C1363 #C1897
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 14 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
Windows Resume decrypts and restores the encrypted memory state during a boot from hibernation,
which acts to preserve the module’s integrity (established by the Windows OS Loader) across
hibernations. The Windows Resume module for Windows 10 version 1903 (module certificate #4348)
provides:
• CAVP certificates #C785 (Windows 10 and Windows Server) for NIST SP 800-38E AES XTS 128
and 256, and for FIPS 197 AES CBC 128 and 256
The Windows Resume module for Windows 10 version 1909 (module certificate #4348) provides:
• CAVP certificates #C1363 (Windows 10 and Windows Server) for NIST SP 800-38E AES XTS 128
and 256, and for FIPS 197 AES CBC 128 and 256
The Windows Resume module for Windows 10 version 2004 (module certificate #4348) provides:
CAVP certificates #C1897 (Windows 10 and Windows Server) for NIST SP 800-38E AES XTS 128
and 256, and for FIPS 197 AES CBC 128 and 256
TCB Launcher verifies the integrity of Code Integrity if Secure Launch is enabled. The TCB Launcher
module for Windows 10 version 1909 (module certificate #4457) provides:
• CAVP certificates #C 1367 (Windows 10 and Windows Server) for FIPS 186-4 RSA PKCS#1 (v1.5)
digital signature verification with 2048 moduli; supporting SHA-256
• CAVP certificates #C 1363 (Windows 10 and Windows Server) for FIPS 180-4 SHS SHA-256
The TCB Launcher module for Windows 10 version 2004 (module certificate #4457) provides:
• CAVP certificates #C1947 (Windows 10 and Windows Server) for FIPS 186-4 RSA PKCS#1 (v1.5)
digital signature verification with 2048 moduli; supporting SHA-256
• CAVP certificates #C1897 (Windows 10 and Windows Server) for FIPS 180-4 SHS SHA-256
Note that the validated platforms listed in section 1.2 include processors that support AES-NI. This
module does not implement AES, but the bounded modules may implement AES and, therefore, use
AES-NI.
2.5 Cryptographic Bypass
Cryptographic bypass is not supported by SKCI.
2.6 Hardware Components of the Cryptographic Module
The physical boundary of the module is the physical boundary of the computer that contains the
module. The following diagram illustrates the hardware components used by the Secure Kernel Code
Integrity module:
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 15 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
3 Cryptographic Module Ports and Interfaces
3.1 SKCI Export Functions
The following list contains all the functions exported by SKCI that are imported by the Secure Kernel.
Note that SKCI is not callable outside the Secure Kernel. These functions are also explained in the
subsequent subsections.
• SkciInitialize
• SkciCreateCodeCatalog
• SkciCreateSecureImage
• SkciValidateImageData
• SkciValidateDynamicCodePages
• SkciFinalizeSecureImageHash
• SkciFinishImageValidation
• SkciFreeImageContext
• SkciTransferVersionResource
• SkciMatchHotPatch
3.1.1 SkciInitialize
SkciInitialize is the function exported by SKCI for initializing the Secure Kernel version of Code Integrity.
During this call, SKCI will get its configuration data from the Secure Kernel loader.
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 16 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
See Self-Tests for information regarding cryptographic self-tests.
If a self-test fails, SkciInitialize returns STATUS_INVALID_IMAGE_HASH.
3.1.2 SkciCreateCodeCatalog
This function is called to create a code catalog object. The specified address range corresponds to a
secure allocation object. It returns a catalog object. The secure allocation must be freed by SKCI when
the catalog object is deleted.
3.1.3 SkciCreateSecureImage
This function is called when a new secure image section is created. It creates a context for validating an
image. The caller specifies the type of hash algorithm that should be used to validate the image. It
returns a pointer to the validation context, which is a state block.
3.1.4 SkciValidateImageData
This function is called to validate image data. When called for a file-hashed file that is still in the loading
state, it is expected to generate the contents of page hashes. When in this mode, it will return
STATUS_SUCCESS upon success. When page hashes are no-longer being generated and instead, page
hashes have been used to verify the supplied pages, STATUS_VALID_IMAGE_HASH will be returned upon
success.
3.1.5 SkciValidateDynamicCodePages
This function is called to validate dynamic code pages that were not part of a signed image.
3.1.6 SkciFinalizeSecureImageHash
This function is called to finalize (complete) the hash of a secure image. It returns the file or page hash of
the image.
3.1.7 SkciFinishImageValidation
This function is called when initial validation of the image is complete. It completes the image validation
process. The function is responsible to verify that the contents of the image header and/or file hash are
correct, and, if successful, should update the image state to enable subsequent validation using page
hashes. It is responsible for verifying that the data is verified by the page hashes for the resource section
only. It returns information about the signing level; how the image is signed; the catalog ID used to
validate the image; the algorithm with which a hash must be recalculated, if necessary; and the type of
image the pages may be mapped into.
3.1.8 SkciFreeImageContext
This function is called when a secure image is unloaded and the context is to be freed.
3.1.9 SkciTransferVersionResource
This function is called to process the supplied version resource for an image, so that version data can be
used during SkciFinishImageValidation.
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 17 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
3.1.10 SkciMatchHotPatch
This routine compares an image hash with the CI data embedded in a hot patch to determine whether
the image matches the expected hash.
3.2 Control Input Interface
The Control Input Interface for SKCI consists of the export functions. Options for control operations are
passed as input parameters to the CI export functions.
3.3 Status Output Interface
The Status Output Interface for SKCI consists of the exported functions listed in SKCI Export Functions.
The status information is returned to the caller as the return value of each function (e.g.
STATUS_SUCCESS, STATUS_UNSUCCESSFUL, STATUS_INVALID_IMAGE_HASH).
3.4 Data Input Interface
The Data Input Interface for SKCI consists of the exported functions listed in SKCI Export Functions. Data
and options are passed to the interface as input parameters to the export functions. Data Input is kept
separate from Control Input by passing Data Input in separate parameters from Control Input.
3.5 Data Output Interface
The Data Output Interface for SKCI also consists of the export functions listed in SKCI Export Functions
with the exception of the initialization and status functions. Data is returned to the function’s caller via
output parameters.
4 Roles, Services and Authentication
4.1 Roles
Secure Kernel Code Integrity is a library used solely by the Windows Secure Kernel and does not interact
with the user through any service. The module’s functions are fully automatic and not configurable. FIPS
140 validations define formal “User” and “Cryptographic Officer” roles. Both roles can use any Secure
Kernel Code Integrity service.
4.2 Services
Secure Kernel Code Integrity’s services are:
1. Verify the integrity of binary executable code – This service is called by Secure Windows
Kernel to verify the integrity of digitally signed drivers and other critical binary components
of the operating system.
2. Show Status – The module does not provide an explicit status interface. Operational status
is indicated by successfully initializing the module using SkciInitialize and success status
messages using the binary integrity verification functions.
3. Self-Tests - The module provides a power-up self-tests service that is automatically
executed when the module is loaded into memory.
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 18 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 19 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
The following table maps the services to their corresponding algorithms, critical security parameters
(CSPs), and how they are invoked.
Table 5 Services
Service / Function Algorithms CSPs Invocation
Verify the integrity
of binary executable
code
FIPS 186-4 RSA PKCS#1
(v1.5) verify with public key
FIPS 180-4 SHS:
SHA-1 hash
SHA-256 hash
SHA-384 hash
SHA-512 hash
RSA public
key
This service is fully automatic.
This service is executed
whenever a binary executable is
loaded.
Show Status None None This service is fully automatic.
This service is executed upon
completion of an integrity check
function.
Self-Tests FIPS 186-4 RSA PKCS#1
(v1.5) verify with public key
and known signature
FIPS 180-4 SHS:
SHA-1 KAT
SHA-256 KAT
SHA-512 KAT
None This service is fully automatic.
The following table maps SKCI services and export functions.
Service Export Functions
Verify the integrity of binary executable
code
SkciCreateCodeCatalog
SkciCreateSecureImage
SkciValidateImageDataSkciValidateDynamicCodePages
SkciFinalizeSecureImageHash
SkciFinishImageValidation
SkciFreeImageContext
SkciTransferVersionResource
SkciMatchHotPatch
Show Status SkciInitialize
All exported functions
Self-Tests SkciInitialize
4.3 Authentication
The module does not provide authentication. Roles are implicitly assumed based on the services that are
executed.
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 20 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
5 Finite State Model
5.1 Specification
The following diagram shows the finite state model for Secure Kernel Code Integrity:
6 Operational Environment
The operational environment for SKCI is the Windows 10 operating system running on a supported
hardware platform.
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 21 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
6.1 Single Operator
Secure Kernel Code Integrity is invoked by the Windows Secure Kernel as a fully automatic service with
no user interaction.
6.2 Cryptographic Isolation
In the Windows operating system, all secure kernel-mode modules, including SKCI.DLL, are loaded into
the Windows Secure Kernel which executes as a single process. The Windows operating system
environment enforces process isolation from user-mode processes including memory and processor
scheduling between the kernel and user-mode processes.
6.3 Integrity Chain of Trust
Windows uses several mechanisms to provide integrity verification depending on the stage in the boot
sequence and also on the hardware and configuration. The following diagram describes the Integrity
Chain of trust for each supported configuration for the following versions:
• Windows 10 and Windows Server version 1909 build 10.0.18363
• Windows 10 and Windows Server version 2004 build 10.0.19041
For the supported configurations of the following Windows version, TCB Launcher is excluded, but the
remainder of the Integrity Chain of Trust diagram applies.
• Windows 10 and Windows Server version 1903 build 10.0.18362
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 22 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 23 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
Note that TCB Launcher was not tested for Windows 10 and Windows Server version 1903 (build
10.0.18362). The scope of this validation only includes TCB Launcher in the Integrity Chain of Trust for
the applicable tested configurations for Windows 10 and Windows Server version 1909 (build
10.0.18363) and Windows 10 and Windows Server version 2004 (build 10.0.19041).
The integrity of the Secure Kernel Code Integrity module is checked by the Windows OS Loader,
Windows Resume, or TCB Launcher. If VSM is enabled, then the Secure Kernel Code Integrity module is
then invoked by the Code Integrity module to check the integrity of user mode binaries (including
BCRYPTPRIMITIVES.DLL) as they are loaded. If HVCI is enabled, the Secure Kernel Code Integrity module
is then invoked by the Code Integrity module to check the integrity of kernel mode binaries (including
DUMPFVE.SYS) as they are loaded.
Refer to the Introduction for information on the relationship between Code Integrity and Secure Kernel
Code Integrity.
7 Cryptographic Key Management
Secure Kernel Code Integrity does not generate or store any persistent cryptographic keys; and uses RSA
public keys for validating file integrity.
8 Self-Tests
The Secure Kernel Code Integrity module implements Known Answer Test (KAT) functions each time the
module is loaded by the Windows kernel.
Secure Kernel Code Integrity performs the following power-on (startup) self-tests:
• SHS (SHA-1) Known Answer Test
• SHS (SHA-256) Known Answer Test
• SHS (SHA-512) Known Answer Test
• RSA verify using a verify test with a Known Signature of the PKCS#1 v1.5 format with both 1024-
bit keys with SHA1 digest and 2048-bit keys with SHA-256 digest.
If the self-test fails, the module will not load and status will be returned. If the status is
STATUS_INVALID_IMAGE_HASH, then a self-test failed. Otherwise, STATUS_SUCCESS is returned.
9 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 Windows 10
operating system.
The Windows 10 operating system must be pre-installed on a computer by an OEM, installed by the
end-user, by an organization’s IT administrator, or updated from a previous Windows 10 version
downloaded from Windows Update.
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 24 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
An inspection of authenticity of the physical medium can be made by following the guidance at this
Microsoft web site: https://www.microsoft.com/en-us/howtotell/default.aspx
The installed version of Windows 10 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.
10 Mitigation of Other Attacks
The following table lists the mitigations of other attacks for this cryptographic module:
Table 6
Algorithm Protected Against Mitigation
SHA1 Timing Analysis Attack Constant time implementation
Cache Attack Memory access pattern is independent of any confidential
data
SHA2 Timing Analysis Attack Constant time implementation
Cache Attack Memory access pattern is independent of any confidential
data
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 25 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
11 Security Levels
The security level for each FIPS 140-2 security requirement is given in the following table.
Table 7
Security Requirement Security Level
Overall 1
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
12 Additional Details
For the latest information on Microsoft Windows, check out the Microsoft web site at:
https://www.microsoft.com/en-us/windows
For more information about FIPS 140 validations of Microsoft products, please see:
https://docs.microsoft.com/en-us/windows/security/threat-protection/fips-140-validation
Secure Kernel Code Integrity Security Policy Document
© 2023 Microsoft Corporation. All Rights Reserved Page 26 of 26
This Security Policy is non-proprietary and may be reproduced only in its original entirety (without revision).
13 Appendix A – How to Verify Windows Versions and Digital Signatures
13.1 How to Verify Windows Versions
The installed version of Windows 10 OEs must be verified to match the version that was validated using
the following method:
1. In the Search box type "cmd" and open the Command Prompt desktop app.
2. The command window will open.
3. At the prompt, enter "ver”.
4. The version information will be displayed in a format like this:
Microsoft Windows [Version 10.0.xxxxx]
If the version number reported by the utility matches the expected output, then the installed version
has been validated to be correct.
13.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: xx.x.xxxxx.xxxx.
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.