I saw that you got a few responses to your question, but this has
been asked many times before yet never fully answered to
satisfaction. So here is the complete explanation, which will
probably be much more than you want to know about this subject.
Nonetheless, I thought it would be nice to set the record straight on
this.

The confusion here is that we are talking about two TOTALLY DIFFERENT
types of signatures: code signing (i.e., Authenticode) vs. WHQL
driver signing. The first one, code signing, is used to authenticate
the author of an executable. The second is to ensure that a
particular driver has been certified for use with Windows 2000 or
Windows XP.

With code signing, credentials are attached to a binary using an
individual's or organization's digital certificate. These credentials
can be verified by looking at the file properties and selecting the
Digital Signatures tab or using the chktrust.exe tool that is
included with the Platform SDK and the .NET Framework SDK. With code
signing, the signature credentials actually become part of the binary
file. If you open the file in a hex editor you will see the actual
signature near the end of the file.

WHQL driver signing, on the other hand, is when Microsoft verifies
that a driver has been tested to be compatible with Windows 2000 or
XP and that the files have not changed since testing. Driver
signatures are included in a catalog file (*.CAT) that is distributed
with the driver. When Windows checks a driver signature, it checks
the catalog file to make sure the drivers have not been altered. The
individual files are not signed, but the .CAT file itself is signed
with Microsoft's certificate (using the code signing method mentioned
above). Driver signing only verifies that those particular files have
been tested to be compatible with Windows 2000 or XP. Driver
signatures can be verified with the sigverif.exe tool or
driverquery.exe that comes with Windows XP.

The primary difference between the two is that code signing is done
on each binary file with the author's certificate whereas with driver
signing, only the catalog file is signed and that is done with
Microsoft's certificate. Code signing is to verify the authenticity
of a file while driver signing is more intended for system
reliability.

So when you get the message box saying that the driver files have not
been signed, it does not mean that the hotfix itself has not been
signed. If you look at the signature properties or use the
chktrust.exe tool, you will see that indeed, the file has been signed
and is valid.

However, when the hotfix installs it uses the SetupCopyOEMInf
function which triggers the checking of driver signatures. Windows
then looks at the hotfix.inf file to determine the name of the
catalog file. That catalog file name should appear in hotfix.inf
under the [Version] section like this:
[Version]
CatalogFile=sp3.cat

Windows then looks for that catalog file (in this case sp3.cat) to
verify the digital signature (which will be Microsoft's signature).
If that passes, it verifies the checksums (one MS document calls them
checksums, another MS document calls them hashes) of each hotfix file
against the checksums (or hashes) in the catalog file. Since
hotfixes do have the catalog file entry in the hotfix.inf and that
catalog file (sp3.cat) is included in the with the hotfix
distribution, you'd thing that it would pass driver signature
checking. But it doesn't.

There are two reasons why the driver signature checking is failing at
installation: either the drivers themselves are bad or it cannot find
the catalog file to verify the signatures. Once you install the
hotfix you can run the sigverif tool and see that the driver files
are indeed verified at that point so it isn't because the drivers are
bad. The only explanation is that it cannot find the catalog file
during installation.

I did quite a bit of research to find out exactly why this was
happening and found one possible reason that I have not verified
myself nor have I informed Microsoft before this e-mail. In the Code
Signing FAQ located at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2k
/html/win2ksignfaq.asp, it says that in addition to adding a
CatalogFile= entry in the .INF, you must also add the .CAT file in
the [SourceDiskFile] section. I noticed that hotfix.inf doesn't have
this entry, so perhaps that is why it is failing. Again, this has
not been verified.

Another issue is the KB article Q269651. This article suggests that
you should set unsigned driver behaviour to silently succeed. I
would NOT recommend this setting, but would suggest to have it warn
you instead. In my opinion, this KB article should be changed. In
Windows 2000, the default setting is to warn but still allow
installation.

And how is this setting changed? There are a number of ways:
1. From the Control Panel, open the System applet, select the
Hardware tab and click on the Driver Signing button.
2. From the Administrative Tools, select one of the Security Policy
snap-ins and change the Unsigned driver installation behaviour under
Local Policies/Security Options.
3. Create a Group Policy and change the setting under Local Computer
Policy\Computer Configuration\Windows Settings\Security
Settings\Local Settings\Security Options.
4. Create or modify the values for BehaviorONFailedVerify and Policy
under HKLM\Software\Policies\Microsoft\Windows NT\Driver Signing.
5. Create or modify the values for BehaviorONFailedVerify and Policy
under HKCU\Software\Policies\Microsoft\Windows NT\Driver Signing.
6. Create the policy in a security template.

So as you see, the message you get that says that the software you
are trying to install is not signed is misleading. First of all, it
has nothing to do with the validity of the hotfix file you
downloaded. Second, it turns out that the hotfix files actually are
signed but the hotfix installation is not recognizing this. I'd say
this is a bug that should be fixed.

Another important thing to note is that there is no automatic
checking of the hotfix's signature itself. If you download a
corrupted or malicious hotfix, there will be no warning when you run
it. You MUST manually verify every hotfix's signature before
installing. One interesting thing I just found while writing this is
that the Digital Signature tab in the file properties may not always
be correct. I opened up Q314147_W2K_SP3_X86_EN.exe in a hex editor
and randomly changed data in the binary file. I saved this and
looked at the signature properties. The Name of Signers field now
said "Not available" but when I looked at the certificate details it
said that the digital signature is OK, which was obviously incorrect.
 When I verified that same file with chktrust using the command
chktrust.exe -v -q Q314147_W2K_SP3_X86_EN.exe I got the following
message:
Q314147_W2K_SP3_X86_EN.exe: Failed: The subject is not trusted for
the specified action

So perhaps the you cannot trust the Digital Signatures tab in the
file properties.

Another thing to consider is what this all means when doing
unattended installs. When including hotfixes during unattended
installation, you may be forced to set the DriverSigningPolicy
setting to ignore in the unattend.txt file. Just be sure to properly
set the policy after installation.

So in summary:
 1. Hotfix signatures are not automatically verified, but can
manually be verified with chktrust.exe
 2. The Digital Signature tab in the file properties dialog may not
be trustworthy
 3. The invalid signature message during installation has nothing to
do with the hotfix download itself
 4. The invalid signature message is wrong, and you can verify the
signatures after installation with sigverif.exe
 5. Microsoft might be able to fix this error message by checking on
that SourceDiskFile thing
 6. Q269651 has a poor recommendation to set your system to silently
install unsigned drivers

And of course, previous recommendations to get the root certificates
update are also a good idea.

Mark Burnett
www.xato.net

On Thu, 21 Feb 2002 16:32:15 +0800, arsz.chn.tuv.com wrote:
>
>Hi,
>
>Recently, when I try to download patches from Microsoft I get the
>messages "Unknown Software Package", "The Software you are trying to
>install is not signed." "Microsoft cannot guarantee that this
>software will work with Windows." etc.
>
>Is this just temporary or is this the extension of the Mircrosoft
>"We-don't-test-our-software-and-don't-guarantee-it-is-working-and-if
>-
>you-use-it-you-have-to-blame-only-yourself-Policy"
>
>towards the patches?
>
>What is safer, install no patches or install unsigned patches?
>
>Cheers, Andreas
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]