Added notes about ECC crypto

windows/security/threat-protection/windows-defender-application-control/event-tag-explanations.md

@@ -13,7 +13,7 @@ author: jsuther1974
 ms.reviewer: jogeurte
 ms.author: vinpa
 manager: aaroncz
-ms.date: 03/24/2023
+ms.date: 05/09/2023
 ms.technology: itpro-security
 ms.topic: article
 ---
@@ -62,35 +62,35 @@ Represents why verification failed, or if it succeeded.
 
 | VerificationError Value | Explanation |
 |---|----------|
-| 0 | Successfully verified signature |
+| 0 | Successfully verified signature. |
-| 1 | File has an invalid hash |
+| 1 | File has an invalid hash. |
-| 2 | File contains shared writable sections |
+| 2 | File contains shared writable sections. |
-| 3 | File isn't signed|
+| 3 | File isn't signed. |
-| 4 | Revoked signature |
+| 4 | Revoked signature. |
-| 5 | Expired signature |
+| 5 | Expired signature. |
-| 6 | File is signed using a weak hashing algorithm, which doesn't meet the minimum policy |
+| 6 | File is signed using a weak hashing algorithm, which doesn't meet the minimum policy. |
-| 7 | Invalid root certificate |
+| 7 | Invalid root certificate. |
-| 8 | Signature was unable to be validated; generic error |
+| 8 | Signature was unable to be validated; generic error. |
-| 9 | Signing time not trusted |
+| 9 | Signing time not trusted. |
-| 10 | The file must be signed using page hashes for this scenario |
+| 10 | The file must be signed using page hashes for this scenario. |
-| 11 | Page hash mismatch |
+| 11 | Page hash mismatch. |
-| 12 | Not valid for a PPL (Protected Process Light) |
+| 12 | Not valid for a PPL (Protected Process Light). |
-| 13 | Not valid for a PP (Protected Process) |
+| 13 | Not valid for a PP (Protected Process). |
-| 14 | The signature is missing the required ARM processor EKU |
+| 14 | The signature is missing the required ARM processor EKU. |
-| 15 | Failed WHQL check |
+| 15 | Failed WHQL check. |
-| 16 | Default policy signing level not met |
+| 16 | Default policy signing level not met. |
-| 17 | Custom policy signing level not met; returned when signature doesn't validate against an SBCP-defined set of certs |
+| 17 | Custom policy signing level not met; returned when signature doesn't validate against an SBCP-defined set of certs. |
-| 18 | Custom signing level not met; returned if signature fails to match `CISigners` in UMCI |
+| 18 | Custom signing level not met; returned if signature fails to match `CISigners` in UMCI. |
-| 19 | Binary is revoked based on its file hash |
+| 19 | Binary is revoked based on its file hash. |
-| 20 | SHA1 cert hash's timestamp is missing or after valid cutoff as defined by Weak Crypto Policy |
+| 20 | SHA1 cert hash's timestamp is missing or after valid cutoff as defined by Weak Crypto Policy. |
-| 21 | Failed to pass Windows Defender Application Control policy |
+| 21 | Failed to pass Windows Defender Application Control policy. |
-| 22 | Not Isolated User Mode (IUM)) signed; indicates an attempt to load a non-trustlet binary into a trustlet |
+| 22 | Not Isolated User Mode (IUM)) signed; indicates an attempt to load a standard Windows binary into a virtualization-based security (VBS) trustlet. |
-| 23 | Invalid image hash |
+| 23 | Invalid image hash. This error can indicate file corruption or a problem with the file's signature. Signatures using elliptic curve cryptography (ECC), such as ECDSA, return this VerificationError. |
-| 24 | Flight root not allowed; indicates trying to run flight-signed code on production OS |
+| 24 | Flight root not allowed; indicates trying to run flight-signed code on production OS. |
-| 25 | Anti-cheat policy violation |
+| 25 | Anti-cheat policy violation. |
-| 26 | Explicitly denied by WADC policy |
+| 26 | Explicitly denied by WADC policy. |
-| 27 | The signing chain appears to be tampered/invalid |
+| 27 | The signing chain appears to be tampered/invalid. |
-| 28 | Resource page hash mismatch |
+| 28 | Resource page hash mismatch. |
 
 ## Policy activation event Options
 

windows/security/threat-protection/windows-defender-application-control/operations/known-issues.md

@@ -9,7 +9,7 @@ ms.reviewer: jogeurte
 ms.author: jogeurte
 ms.manager: jsuther
 manager: aaroncz
-ms.date: 04/04/2023
+ms.date: 05/09/2023
 ms.technology: itpro-security
 ms.topic: article
 ms.localizationpriority: medium
@@ -51,7 +51,7 @@ When the WDAC engine evaluates files against the active set of policies on the d
 
 1. Explicit deny rules - if any explicit deny rule exists for the file, it's blocked even if other rules are created to try to allow it. Deny rules can use any [rule level](/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create#windows-defender-application-control-file-rule-levels). Use the most specific rule level practical when creating deny rules to avoid blocking more than you intend.
 
-2. Explicit allow rules - if any explicit allow rul exists for the file, it's allowed by the policy.
+2. Explicit allow rules - if any explicit allow rule exists for the file, the file runs.
 
 3. WDAC then checks for the [Managed Installer extended attribute (EA)](/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer) or the [Intelligent Security Graph (ISG) EA](/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph) on the file. If either EA exists and the policy enables the corresponding option, then the file is allowed.
 
@@ -71,7 +71,11 @@ When Managed Installer and ISG are enabled, 3091 and 3092 events are logged when
 
 ### .NET native images may generate false positive block events
 
-In some cases, the code integrity logs where Windows Defender Application Control errors and warnings are written include error events for native images generated for .NET assemblies. Typically, native image blocks are functionally benign as a blocked native image falls back to its corresponding assembly and .NET will regenerate the native image at its next scheduled maintenance window.
+In some cases, the code integrity logs where Windows Defender Application Control errors and warnings are written include error events for native images generated for .NET assemblies. Typically, native image blocks are functionally benign as a blocked native image falls back to its corresponding assembly and .NET regenerates the native image at its next scheduled maintenance window.
+
+### Signatures using elliptical curve cryptography (ECC) aren't supported
+
+WDAC signer-based rules only work with RSA cryptography. ECC algorithms, such as ECDSA, aren't supported. If you try to allow files by signature based on ECC signatures, you'll see VerificationError = 23 on the corresponding 3089 signature information events. You can authorize the files instead by hash or file attribute rules, or using other signer rules if the file is also signed with signatures using RSA.
 
 ### MSI installers are treated as user writeable on Windows 10 when allowed by FilePath rule
 

windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md

@@ -13,7 +13,7 @@ author: jgeurten
 ms.reviewer: jsuther1974
 ms.author: vinpa
 manager: aaroncz
-ms.date: 04/05/2023
+ms.date: 05/09/2023
 ms.technology: itpro-security
 ms.topic: article
 ---
@@ -48,7 +48,7 @@ You can set several rule options within a WDAC policy. Table 1 describes each ru
 | **1 Enabled:Boot Menu Protection** | This option isn't currently supported. | No |
 | **2 Required:WHQL** | By default, kernel drivers that aren't Windows Hardware Quality Labs (WHQL) signed are allowed to run. Enabling this rule requires that every driver is WHQL signed and removes legacy driver support. Kernel drivers built for Windows 10 should be WHQL certified. | No |
 | **3 Enabled:Audit Mode (Default)** | Instructs WDAC to log information about applications, binaries, and scripts that would have been blocked, if the policy was enforced. You can use this option to identify the potential impact of your WDAC policy, and use the audit events to refine the policy before enforcement. To enforce a WDAC policy, delete this option. | No |
-| **4 Disabled:Flight Signing** | If enabled, binaries from Windows Insider builds aren't trusted. This option is useful for organizations that only want to run released binaries, not pre-release Windows builds. | No |
+| **4 Disabled:Flight Signing** | If enabled, binaries from Windows Insider builds aren't trusted. This option is useful for organizations that only want to run released binaries, not prerelease Windows builds. | No |
 | **5 Enabled:Inherit Default Policy** | This option is reserved for future use and currently has no effect. | Yes |
 | **6 Enabled:Unsigned System Integrity Policy (Default)** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed and any supplemental policies must also be signed. The certificates that are trusted for future policy updates must be identified in the UpdatePolicySigners section. Certificates that are trusted for supplemental policies must be identified in the SupplementalPolicySigners section. | Yes |
 | **7 Allowed:Debug Policy Augmented** | This option isn't currently supported. | Yes |
@@ -72,6 +72,9 @@ File rule levels allow administrators to specify the level at which they want to
 
 Each file rule level has advantages and disadvantages. Use Table 2 to select the appropriate protection level for your available administrative resources and WDAC deployment scenario.
 
+> [!NOTE]
+> WDAC signer-based rules only work with RSA cryptography. ECC algorithms, such as ECDSA, aren't supported. If you try to allow files by signature based on ECC signatures, you'll see VerificationError = 23 on the corresponding 3089 signature information events. Files can be allowed instead by hash or file attribute rules, or using other signer rules if the file is also signed with signatures using RSA.
+
 ### Table 2. Windows Defender Application Control policy - file rule levels
 
 | Rule level | Description |
@@ -82,7 +85,7 @@ Each file rule level has advantages and disadvantages. Use Table 2 to select the
 | **SignedVersion** | This level combines the publisher rule with a version number. It allows anything to run from the specified publisher with a version at or above the specified version number. |
 | **Publisher** | This level combines the PcaCertificate level (typically one certificate below the root) and the common name (CN) of the leaf certificate. You can use this rule level to trust a certificate issued by a particular CA and issued to a specific company you trust (such as Intel, for device drivers). |
 | **FilePublisher** | This level combines the "FileName" attribute of the signed file, plus "Publisher" (PCA certificate with CN of leaf), plus a minimum version number. This option trusts specific files from the specified publisher, with a version at or above the specified version number. |
-| **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product will have different hash values but typically the same signing certificate. When this level is used, no policy update would be needed to run the new version of the application. However, leaf certificates typically have shorter validity periods than other certificate levels, so the WDAC policy must be updated whenever these certificates change. |
+| **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product have different hash values but typically the same signing certificate. When this level is used, no policy update would be needed to run the new version of the application. However, leaf certificates typically have shorter validity periods than other certificate levels, so the WDAC policy must be updated whenever these certificates change. |
 | **PcaCertificate** | Adds the highest available certificate in the provided certificate chain to signers. This level is typically one certificate below the root because the scan doesn't resolve the complete certificate chain via the local root stores or with an online check. |
 | **RootCertificate** | Not supported. |
 | **WHQL** | Only trusts binaries that have been submitted to Microsoft and signed by the Windows Hardware Qualification Lab (WHQL). This level is primarily for kernel binaries. |
@@ -175,7 +178,7 @@ The Authenticode/PE image hash can be calculated for digitally signed and unsign
 The PowerShell cmdlet produces an Authenticode Sha1 Hash, Sha256 Hash, Sha1 Page Hash, Sha256 Page Hash.
 During validation, WDAC selects which hashes are calculated based on how the file is signed and the scenario in which the file is used.  For example, if the file is page-hash signed, WDAC validates each page of the file and avoids loading the entire file in memory to calculate the full sha256 authenticode hash.
 
-In the cmdlets, rather than try to predict which hash will be used, we pre-calculate and use the four hashes (sha1/sha2 authenticode, and sha1/sha2 of first page).  This method is also resilient to changes in how the file is signed since your WDAC policy has more than one hash available for the file already.
+In the cmdlets, rather than try to predict which hash will be used, we precalculate and use the four hashes (sha1/sha2 authenticode, and sha1/sha2 of first page).  This method is also resilient to changes in how the file is signed since your WDAC policy has more than one hash available for the file already.
 
 ### Why does scan create eight hash rules for certain XML files?