How to use an EV Code Signing Certificate on a virtual machine to sign an MSI

Question

We recently purchased an EV Code Signing Certificate from DigiCert to sign our MSI to get around the Windows SmartScreen warning message. The problem is that the Certificate was delivered to a USB Token that does not allow the exporting of the private key. Our build environment is on a hosted VM so there is no way we can plug the USB Token into the host VM.

Does anyone have a solution for using an EV Code Signing Certificate on a hosted VM? Do all Certificate Vendors deliver this type of certificate to a hardware token? How do you code sign an MSI in a virtual environment using this type of Cert?

Answer 1

The crypto provider being shipped with the SafeNet client is accessing the USB-Token using the SmardCardAPI (winscard.dll). Because SmartCards are also used for authentication/login purposes, the RDP stack will always redirect any access to the RDP client computer.

https://learn.microsoft.com/en-us/windows/security/identity-protection/smart-cards/smart-card-and-remote-desktop-services

For scenarios like code signing this behavior can be quite cumbersome. We are using a dedicated virtual machine for signing purposes and each developer having access to this machine should be able to perform the signing process. With COVID-19 and all developers working at home the idea to use the local USB port is not feasible. Our USB-Token is attached to the dedicated machine. Each time you connect via RDP to this machine the dongle is no longer accessible, because the SmartCardAPI will redirect the access.

There is a solution to this problem however: The SmartCard stack uses the API-Calls

ProcessIdToSessionId

WinStationGetCurrentSessionCapabilities

to determine if the current process is running in a RDP session. By injecting a DLL into the signtool and using the Detours framework you can hook these API calls and report a local session, so the SmardCardAPI will access the dongle connected to the remote virtual machine.

https://github.com/microsoft/Detours

The detoured functions are quite simple (code reduced to important stuff, so you can get the idea)

DWORD WINAPI ProcessIdToSessionIdLocal(DWORD dwProcessId, DWORD *pSessionId)
{
  OutputDebugString("Detoured ProcessIdToSessionId\r\n");
  if (pSessionId)
     pSessionId = 0;
  return TRUE;
}

BOOL WINAPI WinStationGetCurrentSessionCapabilitiesLocal(DWORD flags, DWORD *pOutBuffer)
{
   BOOL bResult;
   
   OutputDebugString("Detoured WinStationGetCurrentSessionCapabilities\r\n");
   bResult = TrueGetCurStationCapabilities(flags,pOutBuffer);
   if (bResult)
      *pOutBuffer = 0;
   return bResult;
}

BOOL WINAPI DllMain (haDLL, dwReason, lpReserved)
    HANDLE haDLL;
    DWORD dwReason;
    LPVOID lpReserved;
{
    LONG error;
    TCHAR cBuffer[160];
    
    wsprintf(cBuffer,"DllMain Entry %08x\r\n",dwReason);
    OutputDebugString(cBuffer);
    if (DetourIsHelperProcess()) {
        return TRUE;
    }

    if (dwReason == DLL_PROCESS_ATTACH) {
        OutputDebugString("Starting Detour API Calls \r\n");
        hStaDLL = LoadLibrary("WINSTA.DLL");
        TrueGetCurStationCapabilities = GetProcAddress(hStaDLL,"WinStationGetCurrentSessionCapabilities");
        
        DetourRestoreAfterWith();
        DetourTransactionBegin();
        DetourUpdateThread(GetCurrentThread());
        DetourAttach((PVOID*)&TrueProcessIdToSessionId, ProcessIdToSessionIdLocal);
        DetourAttach((PVOID*)&TrueGetCurStationCapabilities, WinStationGetCurrentSessionCapabilitiesLocal);
        error = DetourTransactionCommit();

        if (error == NO_ERROR) {
        OutputDebugString("Successfully Detoured API Calls \r\n");

        }
        else {
            return FALSE;
        }
    }
    else if (dwReason == DLL_PROCESS_DETACH) {
        DetourTransactionBegin();
        DetourUpdateThread(GetCurrentThread());
        DetourDetach((PVOID*)&TrueProcessIdToSessionId, ProcessIdToSessionIdLocal);
        DetourDetach((PVOID*)&TrueGetCurStationCapabilities, WinStationGetCurrentSessionCapabilitiesLocal);
        error = DetourTransactionCommit();
        FreeLibrary(hStaDLL);
    }
    return TRUE;
}

Injecting a DLL into the signtool is also easy: just add a new entry to the IMPORTs section that will load the DLL with the detoured functions. This can be done using a tool named "Lord PE" (for 32bit executeables).

Answer 2

For anyone else who's had this problem, we used VNC Server to connect to the VM that had the token on it. It didn't work over RDP only VNC.

Apparently, VNC is like having console access to the box (as far as the EV Dongle is concerned).

Answer 3

I had absolutely no problem with ours. We switched from a PFX (file) backed standard code signing certificate to a USB token backed EV code signing certificate in less than 15 minutes.

I simply set the USB token device to connect to the client OS in VMWare (see icons at bottom right of client OS window for devices), installed the necessary device drivers, set the options to require a password to unlock only once per session, then were good to go.

As to HOW to sign, you sign just like you would with any other certificate. If no other applicable code signing certificate is in the OS's certificate store, then you don't even have to specify where the certificate is.

I worried we would have troubles, but didn't. So, I don't think you will, and don't know why you would have troubles.

Answer 4

EV code signing certificates are required to use special hardware to store the private key. That's part of what makes them more expensive and more secure than standard certificates. My suggestion would be to sign the executable on the host machine using signtool.exe as a post-build step.

Normal code signing certificates do not have the hardware requirement, but they're not as "SmartScreen Filter Friendly" as the EV certificates.

Answer 5

Some virtualization software including VMware allow USB devices to be redirected.