Archive for the ‘Code Signing’ Category

Code Signing: Best Practices

Friday, July 27th, 2012 | Bruce Morton

The biggest issue with code signing is the protection of the private signing key associated with the code signing certificate. If the key gets compromised, then your certificate is worthless. A compromised key may also jeopardizethe software that you have already signed.

Here are some best practices for code signing:

1. Minimize access to private keys

  • Computers with keys should have minimal connections
  • Keep the minimum numbers of users who have key access
  • Use physical security to minimize access

2. Protect private keys with cryptographic hardware products

  • Keys should be protected on a minimum FIPS 140-2 Level 2 certified product
  • Cryptographic hardware does not allow export of the private key to software where it could be attacked

3. Time-stamp your code

  • Time-stamping allows your code to be verified after the certificate has expired or been revoked

4. Test-signing versus release-signing

  • Test-signing certificates require less access to production code signing certificates
  • Test-signing certificates can be self-signed or come from an internal test CA
  • Establish a separate test code signing infrastructure to test-sign prerelease builds of their software
  • Test certificates must chain to a completely different root certificate than the root certificate that is used to sign publicly released products; this precaution helps ensure that test certificates are trusted only within the intended test environment

5. Authenticate code to be signed

  • Any code that is submitted for signing should be strongly authenticated, so you know that it permissible to sign
  • Implement a code signing submission and approval process to prevent the signing of unapproved or malicious code
  • Log all code signing activities for auditing purposes

6. Virus scan code before signing

  • Code signing does not confirm the safety or quality of the code; it confirms the publisher and whether or not the code has been changed
  • Virus-scanning will help to improve the quality of the released code

7. Minimize Use of Keys and Certificates

  • If code is found with a security flaw, then you might want create a trust dialogue when the code is installed in the future; this can be done by revoking the code signing certificate and a revoked prompt will occur
  • If the code with the security flaw was issued before more good code was issued, then revoking the certificate will impact the good code as well
  • Changing keys and certificates often will help to avoid this conflict

Microsoft has an extensive set of best practices, which can be found in this document.

This is the seventh post in our code-signing. Check out the full list to read past entries.

Tags: ,
Posted in Code Signing | Add Comment | No Comments »

Self-Signed Versus Trusted CA Certificates

Monday, July 23rd, 2012 | Bruce Morton

In most cases you have to sign your code in order to get it installed on the operating system. You can sign your code using a self-signed certificate or using a certificate issued by a publicly-trusted CA.

Due to the costs of buying a code signing certificate from a publicly-trusted CA, some users will decide to try a self-signed certificate. Here is what you need to consider.

Self-Signed Certificate:

  • Issued using software that the user has and controls
  • Signatures will provide a trust warning indicating that there was an un-verified publisher and will  display “Unknown Publisher”
  • Compromised certificates cannot be revoked and could harm the users of your software

Certificates Issued from a Publicly-Trusted CA:

  • CA performs identity verification which is displayed in the trust dialogue
  • Compromised certificates can be revoked and if time-stamping was used code signed before revocation will remain trusted

For user trust and the longevity of your code, it is recommended that you use a certificate issued from a publicly-trusted CA.

This is the seventh post in our code-signing. Check out the full list to read past entries and see what’s upcoming.

Tags: ,
Posted in Code Signing | Add Comment | No Comments »

What is Time-Stamping?

Wednesday, June 27th, 2012 | Bruce Morton

What happens to signed code when the code signing certificate expires? In many cases, an expired certificate means that the signature validation will fail and a trust warning will appear in the browser.

Time-stamping was designed to alleviate this problem. The idea is that at the time, at which the code is signed, the certificate was confirmed to be valid and, therefore, the signature is valid. This is much the same as a handwritten signature.

The main benefit is that it extends code trust beyond the validity period of the certificate. The code stays good as long as you can run it. Also, down the road the certificate may be revoked and the code will still be trusted.

Time-stamping the signature is implemented as follows:

  • The signature is sent to the time-stamping authority (TSA).
  • The TSA adds a time-stamp to the bundled information and computes a new hash.
  • The TSA signs the new hash with its private key creating a new bundle of information.
  • The time-stamped bundle, original bundle that was sent to the TSA and the time-stamp are re-bundled with the original code.

(more…)

Tags: ,
Posted in Code Signing | Add Comment | No Comments »

Code Installation Trust Decision

Thursday, June 21st, 2012 | Bruce Morton

The code has been signed, the user has started installation, and verification has taken place. How does the user know whether or not to accept the code?

Here is a typical code verification security warning:

The user must make their trust decision based on the above. The statement provides the following:

  1. File Name: In this case it is AdbeRdr1010_en_US.exe
  2. Publisher Name: Adobe Systems, Incorporated
  3. Code-Signing Certificate: The user would need to click on the publisher name

(more…)

Tags: ,
Posted in Code Signing | Add Comment | No Comments »

How to Digitally Sign Code

Monday, June 18th, 2012 | Bruce Morton

Various application platforms support code-signing and provide different tools to perform the signing. Here is a list of the more common code-signing types and references as to where you can find guides for the given application.

Adobe AIR

Apple

Authenticode

Firefox XPI

Java

Microsoft Windows Macro and Visual Basic Signing

Code-Signing Series

This is the fifth post in our code-signing. Check out the full list to read past entries and see what’s upcoming.

Tags: , , , , , , ,
Posted in Code Signing, Digital Signature | Add Comment | No Comments »

Verifying Code Authenticity

Thursday, August 11th, 2011 | Bruce Morton

When an end-user’s browser loads the code, it checks the authenticity of the software using the signer’s public key, signature and the hash of the file. If the signature is verified successfully, the browser accepts the code as valid. If the signature is not successfully verified, the browser will react by warning the user or rejecting the code, according to the level of security being used.

(more…)

Tags: , , ,
Posted in Code Signing, Digital Signature | Add Comment | 1 Comment »

What is Code Signing?

Friday, July 15th, 2011 | Bruce Morton

From Wikipedia, “Code signing is the process of digitally signing executables and scripts to confirm the software author and guarantee that the code has not been altered or corrupted since it was signed by use of a cryptographic hash.”

In order to sign the code, the publisher needs to generate a private-public key pair and submit the public key to a certification authority (CA) along with a request to issue a code-signing certificate. The CA verifies the identity of the publisher and authenticates the certificate request. The CA bundles the identity of the publisher with the public key and signs the bundle, creating the code-signing certificate.

Armed with the code-signing certificate, the publisher is ready to sign the code. When the code is signed, several pieces of information are added to the original file. This information is used by the recipient’s browser to authenticate the publisher and check for code tampering. The entire sequence takes place as follows:

  • A hash of the code is produced
    • Public-key algorithms are inefficient for signing large objects, so the code is passed through a hashing algorithm creating a fixed-length digest of the file
    • The hash is a cryptographically unique representation of the file
    • The hash is only reproducible using the unaltered file and the hashing algorithm that was used to create the hash
  • The hash is signed using the publisher’s private key
    • The hash is passed through a signing algorithm using the publisher’s private key as an input
    • Information about the publisher and the CA is drawn from the code-signing certificate and incorporated into the signature
  • The original code, signature and code-signing certificate are bundled together
    • The code-signing certificate key is added to the bundle as the public key is required to authenticate the code when it is verified

Following this process, the signed code is ready to be distributed and verified.

Tags: , , ,
Posted in Code Signing, Digital Signature | Add Comment | No Comments »

Why Code Sign?

Friday, June 24th, 2011 | Bruce Morton

Internet users constantly run into situations where they need to download software from websites. In many cases, the user was not planning to download software. However, to experience or use the functionality offered by the website, they need to make a spot decision: “Run” or “Don’t Run.”

In this case, “run/don’t run” questions whether or not to run the code that was downloaded. How does a user decide? How does a user or browser know whether or not to trust the software? The answer is code signing.

To assist in the trust decision process, the software publisher can digitally sign their code. The digital signature answers the questions of authentication and integrity, that is:

  • Who signed the code?
  • Has the code been tampered with since it was signed?

Armed with this information, the user can now make the “run/don’t run” decision.

Unfortunately, the digital signature does not answer the following questions:

  • Can I trust the software publisher?
  • Does the code contain malware?

Unsigned code, on the other hand, provides no evidence of authenticity or integrity. The publisher is not identified and, therefore, cannot be held accountable. In addition, the code is subject to tampering. Unsigned code cannot be trusted, except under special circumstances.

What is Code Signing will be covered in the next post of this series.

Tags:
Posted in Code Signing, Digital Signature | Add Comment | 1 Comment »

Code Signing

Friday, June 17th, 2011 | Bruce Morton

Although this is the Entrust Insight SSL Blog, Entrust Certificate Services issues other types of certificates such as Code Signing, Adobe CDS and Client S/MIME. The purpose of this post is to kick off a series on Code Signing. When the series is completed, this post can be used as an index to all other related posts.

Here is what we plan to cover:

  1. Why Code Sign?
  2. What is Code Signing?
  3. Verifying Code Authenticity
  4. How to Digitally Code Sign
  5. Code Installation Trust Decision
  6. What is Time-Stamping?
  7. Self-Signed Versus Trusted CA Certificates
  8. Code Signing: Best Practices
  9. Application Reputation

The above list may change as the articles are written. Reader feedback would be greatly appreciated to help refine the topics.

Entrust offers Code Signing certificates to sign and certify the following:

  • Authenticode (most Microsoft® Windows® platforms)
  • Java
  • Microsoft® Office® macros and Visual Basic script

Tags: , , , , , ,
Posted in Code Signing, Technical | Add Comment | No Comments »

Application Reputation

Tuesday, June 14th, 2011 | Bruce Morton

Social-engineering attacks are more common than attacks on security vulnerabilities. Traditional defense against malware is a URL-based filter to screen out known malware websites. Microsoft introduced a new defense called Application Reputation that is available in Internet Explorer 9 (IE9) through the SmartScreen Filter.

Application Reputation allows publishers and their applications to build a reputation over time through these principles:

  • Well known “good” applications have a better reputation than new applications
  • Well known “good” publishers have a better reputation than unknown publishers
  • New applications signed by known “good” publishers can have a relatively high reputation from first release

Reputation can be built for unsigned and signed applications. Signed applications can build reputation at twice the rate of those that are unsigned. Reputation based on signing relies on the identification of the publisher by a trusted certification authority and the issuance of a code-signing certificate. Reputation is built by signing ‘good’ applications, but can be easily lost if the certificate is used to sign malware.

Traditionally browsers have presented a trust dialogue box for each application download. IE9 with SmartScreen® Filter does not present a trust dialogue, if the application has built a good reputation. The benefit is that applications with good reputations will be installed without the user making a trust decision — they simply choose “Save” or “Run.” This means when IE9 does detect an application with an unknown reputation, the user is not de-sensitized to trust dialogues and will most likely make the right decision.

For more information on Application Reputation, see the following MSDN blog posts:

Tags: , ,
Posted in Code Signing, Secure Browsing | Add Comment | No Comments »