: ONE OF THE LARGER QUESTIONS FACING THE SOFTWARE INDUSTRY IS THIS :

How can users trust code that is published on the Internet? Currently, most Web pages contain only Static Information, but soon they will be filled with controls and applications that are downloaded and run locally, on the user’s computer.

Packaged Software Uses Branding and Trusted sales outlets to assure Users of its Integrity, but these are not available when Code is transmitted on the Internet. Additionally, there is no guarantee that the Code hasn’t been altered while being downloaded. Browsers typically exhibit a warning message explaining the possible dangers of downloading data, but do nothing to actually see whether the Code is what it claims to be. A more active approach must be taken to make the Internet a reliable medium for distributing software.

1. Ensuring Integrity and Authenticity.

2. Digital Signatures.

3. Digital Certificates.

4. Certificate Store Technology.

5. Digital Certification.

6. Certification Authorities.

7. Duties of Certification Authorities.

8. Obtaining Certification.

9. Criteria for Commercial Certification.

10. Criteria for Individual Certification.

11. The Application Process.

: THERE ARE TWO ISSUES THAT MUST BE ADDRESSED TO MAKE THE INTERNET A RELIABLE SOURCE FOR SOFTWARE :

Microsoft’s solution to these issues is Microsoft Authenticode Coupled with an Infrastructure of Trusted Entities. A discussion of the Infrastructure is included in the explanation of Certification Authorities later in this section. Authenticode, which is based on industry standards, allows Developers to include information about themselves and their code with their programs through the use of Digital Signatures.

While Authenticode itself cannot guarantee that Signed Code is safe to run, Authenticode is the mechanism by which users can be informed of whether the software publisher is participating in the infrastructure of trusted entities. Thus, Authenticode serves the needs of both software publishers and users who rely upon the Internet for the downloading of software.

Authenticode is a Digital Signature Format that relies on the PKCS#7 standard to provide a way to sign the executable code for supported file formats like PE files.

It is useful here to make a distinction between Code Integrity and File Integrity. Code Integrity ensures that any modifications to executable code can be detected. This is different from File Integrity as not all the contents of a file may contain executable code and a file maybe modified without altering any of its executable code thus retaining its Code Integrity but not its File Integrity.

Authenticode is a means of Ensuring Code Integrity and not File Integrity. The Authenticode Signature digitally signs the original content including all the executable code of the file. The complete file is not signed in order to enable the modification of the file with the addition of one or more signatures and timestamps. An Authenticode Signature that passes the verification process indicates that none of the executable code that was signed has been tampered with.

: USE DIGITAL SIGNATURES WHEN YOU WANT TO :

Distribute Data, and You want to assure recipients that it does indeed come from You. Signing data does not alter it; it simply generates a digital signature string You can bundle with the data.

Digital Signatures are created using a Public-Key Signature algorithm such as the RSA public-key cipher. A Public-Key Algorithm actually uses two different keys: The Public Key and The Private Key (called a key pair). The Private Key is known only to its Owner, while the Public Key can be available to Anyone. Public-Key algorithms are designed so that if one key is used for encryption, the other is necessary for decryption. Furthermore, the decryption key cannot be reasonably calculated from the encryption key. In Digital Signatures, the private key generates the signature, and the corresponding public key validates it.

In practice, public-key algorithms are often too inefficient for signing long documents. To save time, digital signature protocols use a Cryptographic Digest, which is a one-way hash of the document. The hash is signed instead of the document itself. Both the hashing and digital signature algorithms are agreed upon beforehand. Here is a summary of the process:

1. A one-way hash of the document is produced.

2. The hash is encrypted with the private key, thereby signing the document.

3. The document and the signed hash are transmitted.

4. The recipient produces a one-way hash of the document.

5. Using the digital signature algorithm, the recipient decrypts the signed hash with the sender’s public key.

If the signed hash matches the recipient’s hash, the signature is valid and the document is intact.

When software (code) is associated with a publisher’s unique signature, distributing software on the Internet is no longer an anonymous activity. Digital signatures ensure accountability, just as a manufacturer’s brand name does on packaged software. If an organization or individual wants to use the Internet to distribute software, they should be willing to take responsibility for that software. This is based on the premise that accountability is a deterrent to the distribution of harmful code.

Digital Signatures are based on Microsoft Public Key Infrastructure Technology, which is based on Microsoft Authenticode combined with an Infrastructure of trusted Certification Authorities (CAs). Authenticode, which is based on industry standards, allows vendors, or software publishers, to sign either a file or a collection of files (such as a driver package) by using a code-signing digital certificate that is issued by a CA.

Windows uses a Valid Digital Signature to verify the following:

1)  The file, or the collection of files, is signed.

2)  The signer is trusted.

3)  The certification authority that authenticated the signer is trusted.

4)  The collection of files was not altered after it was published.

For example, this signing process for a driver package involves the following:

1)  A publisher obtains an X.509 digital certificate from a CA. An Authenticode certificate is also referred to as a signing certificate. A signing certificate is a set of data that identifies a publisher, and is issued by a CA only after the CA has verified the identity of the publisher. A CA can be a Microsoft CA, a third-party commercial CA, or an Enterprise CA.

2)  The signing certificate is used to sign the catalog file of a driver package or to embed a signature in a driver file. Certificates that identify trusted publishers and trusted CAs are installed in certificate stores that are maintained by Windows.

3)  The signing certificate includes a private key and a public key, which is known as the key pair. The private key is used to sign the catalog file of a driver package or to embed a signature in a driver file. The public key is used to verify the signature of a driver package’s catalog file or a signature that is embedded in a driver file.

4)  To sign a catalog file or to embed a signature in a file, the signing process first generates a cryptographic hash, or thumbprint, of the file. The signing process then encrypts the file thumbprint with a private key and adds the thumbprint to the file.

5)  The signing process also adds information about the publisher and the CA that issued the signing certificate. The digital signature is added to the file in a section of the file that is not processed when the file thumbprint is generated.

To verify the digital signature of a file, Windows extracts the information about the publisher and the CA and uses the public key to decrypt the encrypted file thumbprint.

Windows accepts the integrity of the file and the authenticity of the publisher only if the following are true:

1)  The decrypted thumbprint matches the thumbprint of the file.

2)  The certificate of the publisher is installed in the Trusted Publishers certificate store.

3)  The root certificate of the CA that issued the publisher’s certificate is installed in the Trusted Root Certification Authorities certificate store.

A driver package consists of all the software components that you must supply in order for your device to be supported under Windows.

Installing a device or driver involves system-supplied and vendor-supplied components. The system provides generic installation software for all device classes. Vendors must supply one or more device-specific components within the driver package.

DRIVER SIGNING ASSOCIATES A DIGITAL SIGNATURE WITH A DRIVER PACKAGE

Windows device installation uses digital signatures to verify the integrity of driver packages and to verify the identity of the vendor (software publisher) who provides the driver packages. In addition, the kernel-mode code signing policy for 64-bit versions of Windows Vista and later versions of Windows specifies that a kernel-mode driver must be signed for the driver to load.

Note  Windows 10 for desktop editions (Home, Pro, Enterprise, and Education) and Windows Server 2016 kernel-mode drivers must be signed by the Windows Hardware Dev Center Dashboard, which requires an EV certificate.

All drivers for Windows 10 (starting with version 1507, Threshold 1) signed by the Hardware Dev Center are SHA2 signed. For details specific to operating system versions.

Kernel-mode driver binaries embed signed with dual (SHA1 and SHA2) certificates from a third party certificate vendor for operating systems earlier than Windows 10 may not load, or may cause a system crash on Windows 10. To fix this problem, install KB 3081436.