locked
Retail Driver Signing (Touchscreen driver has a ProblemCode 52) RRS feed

  • Question

  • I am building a custom Retail image of Windows 10 IoT Core, targeting the Dragonboard.  We are using a Goodix Touchscreen controller, and have a working driver in the Test image.

    Whenever I build the Retail image, the touchscreen is non-responsive.  Looking at the Devices tab of the device portal (enabling that feature for debugging purposes), I see this:

    >TouchDetectionDriver Device
                (ID:ACPI\KUK0003\1, Class:HIDClass, Manufacturer:KuK, StatusCode:25175040, ProblemCode:52)
    On my Test image, that same device is working:

    >TouchDetectionDriver Device
                (ID:ACPI\KUK0003\1, Class:HIDClass, Manufacturer:KuK, StatusCode:25175040, ProblemCode:52)>TouchDetectionDriver Device
                (ID:ACPI\KUK0003\1, Class:HIDClass, Manufacturer:KuK, StatusCode:25165834)
                >Touch Driver
                (ID:ACPI\KUK0004\1, Class:HIDClass, Manufacturer:Goodix, StatusCode:25174026)
                    >HID-compliant touch screen
                    (ID:HID\KUK0004&COL01\3&19522E47&0&0000, Class:HIDClass, Manufacturer:(Standard system devices), StatusCode:25174026)
                    >HID-compliant device
                    (ID:HID\KUK0004&COL02\3&19522E47&0&0001, Class:HIDClass, Manufacturer:(Standard system devices), StatusCode:25174026)
                    >HID-compliant device
                    (ID:HID\KUK0004&COL03\3&19522E47&0&0002, Class:HIDClass, Manufacturer:(Standard system devices), StatusCode:25174026)


    My steps to debug this have been extensive.  From documentation, ProblemCode appears to be a signature issue.  I have acquired a Kernel signing certificate from DigCert.  As shown here:

    Platform Microsoft Kernel-Mode Code
    Validity 12 Jun 2019 to 16 Jun 2022

    I have turned RetailSign on, I buildpkg all, and then buildimage <device> Retail.

    The resulting FFU is then flashed to my board, boots, but the above result occurs.  All other connected devices perform as expected.

    I have examined the .cab files in my pkg directory, and all of them are signed with my Code Signing certificate, not a Test certificate.  I have unpacked the TouchscreenDriver and Goodix CAB files, and the individual .SYS files inside are signed with my Code Signing certificate.  I have pulled the actual .sys files from the non-responsive system, and verified that they are indeed signed with our kernel-mode code-signing certificate.

    So, it's:

    1. The wrong certificate, and the documentation is either wrong or at least confusing.
    2. There is something else un-signed upstream that is causing the system to fail
    3. Something else I'm just not getting.

    -Dan


    -Dan

    Friday, July 5, 2019 9:48 PM

Answers

  • Rita,

    I have solved this issue, thank you for your help.  Below describes what was happening for anyone running into a similar issue.

    My problem was in the cross-signing certificate.  Despite signing the files with my code-signing certificate, and checking the files (and resulting cabs) with Test-IoTSignature retail and Test-IoTCabSignature retail - both returning true, the .sys files would not load in the kernel.

    I have an EV code-signing certificate, and a regular code-signing certificate, both from DigiCert.  The EV is required for submission of Apps to the Microsoft Store (and likely distributing drivers through Microsoft as well).  The documentation is not clear if an EV is required or not - using a regular code-signing certificate is preferable because EV requires.

    I have successfully EV-signed my driver (TouchScreenDriver and GoodixTouch driver .sys files), and then used that EV certificate, *AND* the DigiCert Cross-Signed Root certificate 

    DigiCert High Assurance EV Root CA 2f 25 13 af 39 92 db 0a 3f 79 70 9f f8 14 3b 3f 7b d2 d1 43

    And with that combination, I have been able to boot and have a working touchscreen.

    I am in the process of building an image that is using a REGULAR Code-sign certificate to sign my cabs, but use the EV certificate to sign the .sys files.  This is because the EV certificate needs 2-factor authentication during OS build, and would be impossible to reliably use in a cloud scenario.  It also creates a single point of failure for OS builds.

    My version of Windows 10 IoT Core is:

    • ADK_VERSION : 10.0.18362.1 (have also tried 17763 as well)
      IOTCORE_VER : 10.0.17763.253
      BSP_VERSION : 10.0.0.0
      ADDONKITVER : 6.0.190307.1402
      HostOS Info : Microsoft Windows 10 Pro - 10.0.18362 - en-US de-DE


    -Dan

    Monday, July 8, 2019 9:56 PM

All replies

  • For more context, I have read an applied the documentation from this:

    http://www.annabooks.com/Articles/Articles_IoT10Core/Windows-10-IoT-Core-Sign-and-Build-Retail-Images-Rev1.3.pdf

    I have also verified that the signatures I have been using have passed with Set-IoTSignature and then Test-IoTSignature <file.sys> Retail for the files I have signed.  They have all indicated passed.

    The Cab files themselves also pass with Test-IotCabSignature <cabfile> Retail


    -Dan

    Friday, July 5, 2019 10:50 PM
  • Hello Dan Richardson (Revelar),

    There are some things I want to confirm with you:

    # Add driver
    Add-IoTProductFeature ProductA Retail DRIVERS_HELLOBLINKY -OEM

    "Building Windows 10 IoT Core retail image or image with Secure Boot enabled requires that all kernel drivers (including all drivers in the BSP that's included in the retail image) are signed with a code signing certificate with Cross Signed root."

    • What's the version of your Windows 10 IoT Core?

    Best regards,

    Rita


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, July 8, 2019 2:26 AM
  • Rita,

    I have solved this issue, thank you for your help.  Below describes what was happening for anyone running into a similar issue.

    My problem was in the cross-signing certificate.  Despite signing the files with my code-signing certificate, and checking the files (and resulting cabs) with Test-IoTSignature retail and Test-IoTCabSignature retail - both returning true, the .sys files would not load in the kernel.

    I have an EV code-signing certificate, and a regular code-signing certificate, both from DigiCert.  The EV is required for submission of Apps to the Microsoft Store (and likely distributing drivers through Microsoft as well).  The documentation is not clear if an EV is required or not - using a regular code-signing certificate is preferable because EV requires.

    I have successfully EV-signed my driver (TouchScreenDriver and GoodixTouch driver .sys files), and then used that EV certificate, *AND* the DigiCert Cross-Signed Root certificate 

    DigiCert High Assurance EV Root CA 2f 25 13 af 39 92 db 0a 3f 79 70 9f f8 14 3b 3f 7b d2 d1 43

    And with that combination, I have been able to boot and have a working touchscreen.

    I am in the process of building an image that is using a REGULAR Code-sign certificate to sign my cabs, but use the EV certificate to sign the .sys files.  This is because the EV certificate needs 2-factor authentication during OS build, and would be impossible to reliably use in a cloud scenario.  It also creates a single point of failure for OS builds.

    My version of Windows 10 IoT Core is:

    • ADK_VERSION : 10.0.18362.1 (have also tried 17763 as well)
      IOTCORE_VER : 10.0.17763.253
      BSP_VERSION : 10.0.0.0
      ADDONKITVER : 6.0.190307.1402
      HostOS Info : Microsoft Windows 10 Pro - 10.0.18362 - en-US de-DE


    -Dan

    Monday, July 8, 2019 9:56 PM
  • This a follow-up request to make the documentation clearer on how to manage these certificates for those unfamiliar with the details of cross-signing.

    The way I read the documentation is: *I* sign my files, and my cert vendor vouches for me in my code-signing cert.  The cross-signing is *Microsoft* vouching for the cert vendor (which is why if you look at the root certs found here:  https://docs.microsoft.com/en-us/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing you will see the Certification Path points nowhere "The issuer of this certificate could not be found."  This is because Microsoft has issued the cert itself).

    The problem, for me, is determining which Root certificate to use, and when.  The documentation on the above link has step 5 being:

    • Find the Issuer and Thumbprint for this certificate. Then locate the corresponding entry for this CA in the list below.

    For me, I am using an EV code-signing certificate.  The Issuer is DigiCert.  I am using the DigiCert High Assurance EV Root CA certificate to cross-sign (set in my RetailSignToolParam block of IoTWorkspace.xml).  This works, which is great.

    However, it is unclear what the Thumbprint is used for - nowhere in my EV certificate is a 2f 25 13 af 39 92 db 0a 3f 79 70 9f f8 14 3b 3f 7b d2 d1 43 thumbprint present, in any of the certs in the chain.

    There has to be some correlation, as I can't use the EV cross-cert with my regular code-signing certificate.  While it may be possible to use the DigiCert Assured ID Root CA or DigiCert Global Root CA root certificates, in order to test it, I have to sign files, and spend about 30-40 minutes making a fresh .FFU before I can see if I am successful or not.

    By requiring an EV certificate, I can not reliably have a cloud-based FFU build server running, as it requires a USB dongle as 2-factor authentication during the build process.

    Clearing up these details would go a long way towards making this process more approachable.


    -Dan



    Monday, July 8, 2019 10:09 PM
  • Hello Dan Richardson (Revelar),

    Good to know you get it working. Thanks for your feedback about the document issue. I'll feedback this internally.

    Best regards,

    Rita


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, July 9, 2019 5:54 AM