Windows Code Integrity (CI.dll) skips Rivest-Shamir-Adleman (RSA) signature verification for kernel drivers signed under end-entity certificates issued before July 29, 2015 that chain to a supported cross-signed CA. The SignerInfo.EncryptedDigest field, the sole cryptographic proof binding a file to the private key holder, can be replaced with 256 zero bytes and the driver still loads. This holds true on Windows 10 and 11 with Secure Boot active, Hypervisor-Protected Code Integrity (HVCI) active, and test signing disabled. Every surrounding element passes real validation: WIN_CERTIFICATE structure fields, Public-Key Cryptography Standards #7 (PKCS#7) structural integrity, certificate chain trust, the authenticode hash, and the countersignature timestamp. The one element that constitutes actual cryptographic proof receives no check at all.

This article covers the grandfather date mechanism inside CI.dll, the layout of Portable Executable (PE) authenticode signatures, and the systematic mutation approach used to isolate what CI.dll enforces versus what it ignores. It then walks through the zero signature mutation itself and a cross binary signature transplant that independently confirms the finding. The final sections examine the likely root cause, the relevant internal functions, and the mitigation options available today.

The Grandfather Date Mechanism

CI.dll contains a hardcoded cutoff date that splits driver signature validation into two code paths. Drivers whose signing certificates predate this cutoff enter a legacy path with weaker enforcement. The date is July 29, 2015, encoded as a FILETIME:

FILETIME: 0x01D0C991830F4000 (July 29, 2015 00:00:00 UTC)
Little-endian bytes: 00 40 0F 83 91 C9 D0 01

Microsoft documentation describes the full set of checks that signature validation is supposed to perform: certificate chain verification, expiration enforcement, timestamp validation, RSA or Elliptic Curve Digital Signature Algorithm (ECDSA) correctness, authenticode hash comparison, and code signing Extended Key Usage (EKU) checks. The grandfather path implements most of these. The question is which one it omits.

PE Authenticode Signature Layout

A signed PE binary stores its signature in the Security Directory as a WIN_CERTIFICATE structure. This structure wraps a PKCS#7 blob that carries three payloads: the authenticode hash computed over the binary, a certificate chain establishing trust back to a root authority, and a SignerInfo block. The SignerInfo block contains the EncryptedDigest field, which holds the raw RSA signature bytes. Under correct verification, the verifier decrypts EncryptedDigest using the public key from the signing certificate and compares the recovered digest against the independently computed authenticode hash. If they match, the file has not been modified since signing. If the verifier never performs this decryption, the field is dead weight.

Systematic Mutation Approach

Static reverse engineering alone does not reveal enforcement gaps cleanly. A more direct method starts with a legitimately signed driver known to load, then systematically breaks one signature component at a time. Each mutation isolates a single field. The binary either loads or it does not. This produces a clear enforcement map for every element in the signature chain. Custom tooling parses the signature structures, applies targeted mutations, and reassembles the binary. All tests run on Windows 10 and 11 with Secure Boot and HVCI enabled and test signing disabled.

Mutation Outcomes

Nine mutations target individual signature components. Only one produces a driver that still loads.

Zeroing the RSA signature bytes in EncryptedDigest: the driver loads without error. Every other mutation causes a load failure. Zeroing certificate signatures fails. Truncating the PKCS#7 structure fails. Changing the WIN_CERTIFICATE revision field fails. Changing the certificate type field fails. Stripping the timestamp countersignature fails. Backdating the timestamp fails. Corrupting certificate data fails. Corrupting the authenticode hash fails.

The result is unambiguous. CI.dll enforces structural integrity, certificate chain validity, hash correctness, and timestamp presence for grandfathered drivers. It does not enforce RSA signature correctness.

The Zero Signature Mutation

The mutation code walks the PKCS#7 blob searching for Abstract Syntax Notation One (ASN.1) OCTET STRING tags (0x04) followed by long form length encoding (0x82), which signals a two byte length field. RSA signatures for driver certificates fall in the 128 to 512 byte range. Every matching content region gets zeroed:

bool mutZeroEncryptedDigest(BYTE* pkcs7, DWORD len) {
    int found = 0;
    for (DWORD i = 0; i < len - 4; i++) {
        if (pkcs7[i] == 0x04 && pkcs7[i+1] == 0x82) {
            DWORD sigLen = (pkcs7[i+2] << 8) | pkcs7[i+3];
            if (sigLen >= 128 && sigLen <= 512 && i + 4 + sigLen <= len) {
                memset(&pkcs7[i+4], 0, sigLen);
                found++;
            }
        }
    }
    return found > 0;
}

After this runs, 256 bytes of RSA signature data become 256 zero bytes. The modified driver loads on a fully configured system with no errors, no warnings, and no audit events.

Cross Binary Signature Transplant

A second technique independently confirms the finding. Signature transplantation takes a signed donor binary and an unsigned target binary, then moves the donor signature onto the target. The procedure works as follows: compute the authenticode hash of both files, extract the complete signature from the donor, locate the authenticode hash inside the extracted signature and replace it with the hash of the target binary, zero the RSA signature bytes since re-signing without the original private key is impossible, and attach the modified signature to the target.

The target driver loads. Three conclusions follow from this single result. First, the authenticode hash is validated, because the transplant only succeeds when the embedded hash matches the target binary. Second, the RSA signature is not validated, because the transplanted signature contains nothing but zeros in EncryptedDigest. Third, structural integrity is validated, because any malformation in the PKCS#7 wrapper causes an immediate load failure.

The Timestamp as Trust Anchor

The most likely explanation ties back to the timestamp countersignature. When a valid timestamp from a trusted Time Stamping Authority (TSA) exists and the signing certificate predates the grandfather cutoff, CI.dll appears to derive its trust decision from the timestamp signature rather than the primary RSA signature. The grandfather code path confirms that a signature is present but never verifies that it is cryptographically correct.

This behavior has a plausible performance rationale. RSA verification carries nontrivial computational cost. An optimization that skips full RSA decryption when a trusted timestamp already anchors the chain of trust would reduce driver load latency. The mutation data supports this interpretation directly: without a valid timestamp, nearly every mutation causes a failure. With one, the RSA bytes become irrelevant.

Internal Validation Pipeline

Four functions inside CI.dll form the core of the driver signature validation path. CiValidateImageHeader is the entry point, invoked indirectly via the SeCiCallbacks callback table from nt!SeValidateImageHeader. CiCheckSignedFile handles primary signature validation and PKCS#7 parsing. MinCryptVerifySignedDataLMode performs ASN.1 decoding and certificate chain construction. I_MinCryptVerifyTimeStampSignature handles timestamp validation and the grandfather date comparison.

Searching the CI.dll binary for the grandfather date bytes locates the branch point where the legacy and modern code paths diverge:

00 40 0F 83 91 C9 D0 01

Mitigation Landscape

Neither Secure Boot nor HVCI prevents a driver with zeroed RSA signature bytes from loading through the grandfather code path. Both security features remain active during successful loads of mutated drivers. The most effective countermeasure is the Vulnerable Driver Blocklist: if the signing certificate or the file hash appears on this list, the load fails regardless of which code path the signature takes. HVCI enforcement, certificate revocation, and out of band blocklist updates delivered through Windows Update provide additional layers.

Most Driver Signature Enforcement (DSE) bypass techniques require disabling Secure Boot or enabling test signing. The Bring Your Own Vulnerable Driver (BYOVD) attack class is one exception, working under full Secure Boot by exploiting legitimately signed but vulnerable drivers. The grandfather code path represents another: it operates within a normal, hardened security configuration with both Secure Boot and HVCI active. Microsoft is unlikely to remove the legacy code path because thousands of legitimate enterprise drivers depend on it. The mitigation strategy instead relies on blocklisting abused certificates and incrementally tightening signing requirements across Windows releases.

CI.dll validates WIN_CERTIFICATE structure fields, PKCS#7 structural integrity, certificate chains, authenticode hashes, and timestamp presence for drivers signed under the grandfather cutoff. It does not validate the RSA signature bytes in SignerInfo.EncryptedDigest. The timestamp countersignature serves as the de facto trust anchor for this code path. Without a valid timestamp, most mutations fail. With one and a pre-cutoff certificate chain, the cryptographic signature can consist entirely of zeros and the driver loads normally. The driver blocklist remains the most direct mitigation for this gap, supplemented by HVCI enforcement and certificate revocation.