Explore Eclipse's plug-in signature mechanism

Learn how to create signed plug-ins in Eclipse and IBM Lotus Expeditor

Security is an important issue when installing a bundle of new features to software. Learn about signature technologies used by the Eclipse platform to determine the trustworthiness of plug-ins. Eclipse places each plug-in into one of five categories: unsigned or signed, trusted or untrusted, or expired. Learn how to create signed plug-ins in Eclipse and IBM® Lotus® Expeditor, an Eclipse-based product.

Share:

Xing Xing Li (lixx@cn.ibm.com), Software Engineer, IBM

Xing Xing LiXing Xing Li joined the IBM China Software Development Lab in Beijing China in 2004 as a software engineer for IBM Lotus. He focuses on software development and testing on Eclipse platform and Java technologies. He is also interested in user interface design, design pattern and algorithmic research. He received his master's degree in computer science from Chongqing University.



18 November 2008

Also available in Japanese Vietnamese

This article describes the Eclipse plug-in signature, its application, and the test strategy used by the IBM Lotus Expeditor client provisioning system, which is leveraged to control code access to local or remote Eclipse update sites.

Signature is an indispensable mechanism for Eclipse's security functions. While a plug-in is downloading, the Eclipse user has the opportunity to verify a JAR file's signature, which is posted on the update site. This allows the user to get reliable information about the code he is about to install. This function allows him to identify who published the code and verify that the software has not been altered since the time it was uploaded to the update site. IBM Lotus Expeditor/Lotus Notes® applies this security mechanism using its Update Manager component to deliver a signature check-up for users.

Prerequisites

To get the most out of this article, you need an Eclipse development environment and the sample code. If you don't have Eclipse already, download the following:

Java 2 Standard Edition
The Java® 2 Standard Edition V5 or greater is available from Sun Microsystems.
Eclipse
Find Eclipse platform at the Eclipse Foundation. To try another test platform, download IBM Lotus Expeditor V6.1.x, but this is optional

See Resources for Eclipse and the Java JDK. Find the sample code in the Download section.


Background

Eclipse plug-ins fall into one of five digital signature categories:

Unsigned plug-in
By default, all plug-ins generated by Eclipse are unsigned.
Signed plug-in
If an unsigned plug-in is signed, then it can be called a signed plug-in.
Trusted plug-in
If a signed plug-in is signed with a trusted signature, this plug-in will be trusted by the Eclipse runtime. Thus, it is a trusted plug-in.
Untrusted plug-in
This plug-in is signed with an untrusted signature.
Expired plug-in
All signed plug-ins have a period of validity. An expired plug-in is one encapsulated in a JAR file, which is signed, but the certificate used to sign the JAR file has expired.
Figure 1. Plug-in categories
Plug-in categories

Implementation and test scenario

Find out how to generate a plug-in with unsigned, untrusted, or expired signatures by Eclipse, Keytool, and Jarsigner, then verify them in Eclipse runtime and IBM Lotus Expeditor runtime. Let's begin with an unsigned plug-in.

Unsigned feature

By default, a plug-in generated by an IDE (such as Eclipse) is an unsigned plug-in. For example, we create an unsigned plug-in using the following steps:

  1. Click File > New > Project…> Plug-in Development > Plug-in project, and click Next.
  2. Input HelloWorld in the project name field, accept other defaults and click Next.
  3. Click the Next button in the subsequent wizard page for Plug-in Content.
  4. Select HelloWorld and click the Finish button in the Template wizard page.
  5. Click File > New > Project…> Plug-in Development > Feature project, then click Next.
  6. Input HelloWorld.feature in the Project name field, accept other defaults and click Next.
  7. Select the HelloWorld plug-in you just created in the Referenced Plug-ins and Fragments wizard page and click Finish.
  8. Click File > New > Project…> Plug-in Development > Update Site project and click Next.
  9. Input HelloWorld.updatesite in the Project name field, accept other defaults, and click Finish.
  10. Click the Add Feature… button, select HelloWorld.feature, and click OK.
  11. Click Build to generate the update site file in your local file system.
  12. Verify the expected update site has been created in your workspace.

Using the above 12 steps, we created a HelloWorld sample plug-in, a HelloWorld feature, and a HelloWorld update site to encapsulate them.

Figure 2. Plug-in categories
Plug-in categories

Let's verify its identity using the Eclipse Update Manager with the following steps:

  1. Click Help > Software Update > Find and Install ….
  2. Select Search for new feature to install and click Next.
  3. Click the New Local Site … button, navigate to the HelloWorld update site and click OK.
  4. Click Finish.

We will get an "unsigned feature" notification to warn us that the feature is not equipped with a signature and that its provider can not be verified.

Figure 3. Verifying an unsigned plug-in in Eclipse
Verifying an unsigned plug-in in Eclipse

IBM Lotus Expeditor, a powerful Eclipse-based platform, displays a similar warning message if we perform the same installation steps with the same plug-in. The user can choose to deny or accept such a plug-in by clicking the radio buttons, as shown below.

Figure 4. Test scenario of verifying a unsigned plug-in in IBM Lotus Expeditor
Test scenario of verifying a unsigned plug-in in IBM Lotus Expeditor

Unsigned feature

The aim of code integrity is to determine that a plug-in has not been modified before it is installed. To meet this goal, we will use two utilities: Keytool and Jarsigner.

Keytool is command-line tool used to manage keys and certificates. A certificate is a digitally signed statement from an entity (person, company, computer, program, etc.), saying that the public key (and some other information) of some other entity has a particular value. Keytool currently handles X.509 certificates. Elements in a X.509 certificates include Version, Validity Period, Subject Name (Common Name, Organizational Unit, Organization and Country), etc. The keys and certificates are stored in a so-called keystore, which is actually a file. It protects private keys with a password.

Jarsigner is another utility used to sign JAR files and verify such signatures. To verify the existing digital signature in a JAR file, Jarsigner will retrieve the certificate that comes with the subjected JAR file, then check whether the public key of that certificate is trustable based on the specified keystore. We will use the signing and verification functions of Jarsigner in this article.

First, we will use the Keytool to create a keystore, in which there will be a pair of keys (the public key and the private key). Issue the following command.

Listing 1. Create a keystore
keytool -genkey -dname "cn=Li Xing Xing, ou=CDL, o=IBM, c=CN" -alias business -keypass 
 key123 -keystore C:\keystore\mykeystore -storepass store123 -validity 180

This command does the following:

  • It creates a keystore file named mykeystore in C:\keystore directory and assigns the password store123 to the keystore. The keystore type is jks by default.
  • It generates a public/private key pair for the entity having the Distinguished Name values of "Li Xing Xing" for the common name, "CDL" for the organizational unit, "IBM" for the organization, and "CN" for the country. The password key123 is assigned to the private key. There will be one entry contained in keystore, which is named "business."
  • It uses the default DSA key-generation algorithm and creates two keys of 1024 bits, the default length.
  • It uses a default signature algorithm, SHA1 with DSA, to create a self-signed certificate valid for 180 days.

Accordingly, a file named mykeystore will be created in the target folder.

Figure 5. Mykeystore generated
Mykeystore generated

After we have created a self-signed certificate, we will sign the feature.jar and plugin.jar file with it by issuing the following Jarsigner commands, as shown in listings 2 and 3. Here, we leveraged the signing function of Jarsigner by the jarsigner [options] jar-file alias command format. In the options fields, we provided keystore file location, keystore password, and private key password.

Listing 2. Sign feature JAR file
jarsigner -keystore C:\keystore\mykeystore -storepass store123 -keypass key123
  C:\workspace\HelloWorld.update\features\HelloWorld.feature_1.0.0.jar business
Listing 3. Sign plug-in JAR file
jarsigner -keystore C:\keystore\mykeystore -storepass store123 -keypass key123
 C:\workspace\HelloWorld.update\plugins\HelloWorld.feature_1.0.0.jar business

Because the validity is 180 days, you will get the response that the signer certificate will expire after six months, as shown by the last line echoed in figures 6 and 7.

Figure 6. Response to signing a feature JAR file
Response to signing a feature JAR file
Figure 7. Response to signing a plug-in JAR file
Response to signing a plugin JAR file

You might be curious what happened to your feature JAR and plug-in JAR files by running the above two commands. Open META-INF folders in both HelloWorld.feature_1.0.0.jar and HelloWorld_1.0.0.jar, and you will find two files added — namely BUSINESS.SF and BUSINESS.DSA — as shown in Figure 8.

Figure 8. BUSINESS.DSA and BUSINESS.SF in META-INF
BUSINESS.DSA and BUSINESS.SF in META-INF

As a matter of fact, the difference between an unsigned and a signed plug-in is these two files: .SF and .DSA. Let's explore the BUSINESS.SF file first. This is the signature file for the JAR file, in which information is represented as name-value pairs followed the RFC822 standard. Each signer is represented by a signature file with extension .SF. The main section entry, x-Digest-Manifest-Main-Attributes (where x is a digest algorithm, such as SHA1), contains the digest value for the main attributes of the manifest. Such embedded data is represented as Base64, a popular technology to encode and transport the 8-bit bytes using the Internet. Table 1 lists the sample content of BUSINESS.SF files in your feature and plug-in JAR files. The version, signature algorithm, JVM, and digest information are provided there.

Table 1. BUSINESS.SF files in feature JAR and plug-in JAR
Feature JAR Plug-in JAR
Signature-Version: 1.0
SHA1-Digest-Manifest-Main-Attributes: wo/L6RyS5cmXUyjSULsCmbi//pc=
Created-By: 1.5.0 (IBM Corporation)
SHA1-Digest-Manifest: Hw4sDi+lK9Lk+yxEsiIBU4k8fdQ=

Name: feature.xml
SHA1-Digest: OOwzec1mVb8PGpLLjSy52QfDiR4=
Signature-Version: 1.0
SHA1-Digest-Manifest-Main-Attributes: Njf5Vhqe3paGaU+YpcW3RRd+nCg=
Created-By: 1.5.0 (IBM Corporation)
SHA1-Digest-Manifest: 2I/i8WO/wARcxqiOcs1ukjmquhA=

Name: helloworld/Activator.class
SHA1-Digest: fHk5c6yYAWPNvgZYLAENX/00axE=

By contrast, BUSINESS.DSA file, a binary file of signature, might be more difficult to understand. This signature block file stores the digital signature of the corresponding signature file. As you found, the BUSINESS.DSA file and BUSINESS.SF files share the same base file name, with different extension names. Actually, .RSA and .PGP are other options for the extension name of a signature binary file, depending on different algorithms to be used. Figure 9 demonstrates the content encapsulated in a BUSINESS.DSA file, with some readable information translated by the word processor (we used UltraEdit). That means you can only crack a few literature strings, such as "CN," "IBM," "Lotus Expeditor," and "Li Xing Xing." But you can't reveal the whole picture. That's the magic of signature.

Figure 9. BUSINESS.DSA content
BUSINESS.DSA content

We can validate the signature in a signed plug-in JAR file with a command of jarsigner -verify before we install it into any product. Issue the following command against your signed plug-in JAR file and get your response, as shown in Figure 10. The -verbose and –certs options will display verbose output and the certificate during the verification.

Listing 4. Verify signed plug-in JAR file with Jarsigner command
jarsigner -keystore C:\keystore\mykeystore –storepass store123 –verify –verbose
–certs C:\workspace\HelloWorld.update\plugins\HelloWorld_1.0.0.jar
Figure 10. Verify plug-in signature by Jarsigner command
Verify plug-in signature by Jarsigner command

The basic information and expiration information of the signature in HelloWorld_1.0.0.jar will be listed and verified when you use Jarsigner's command to verify the subject.

Now try to install the update site embedded with the signed plug-in. You will be notified that "You are about to install a signed feature" with details of the self-signed certificate presented, as shown in Figure 11.

Figure 11. Test scenario of verifying a signed plug-in in Eclipse
Test scenario of verifying a signed plug-in in Eclipse

Users tend to trust a signed plug-in more than an unsigned plug-in. When such a signed plug-in is being installed into IBM Lotus Expeditor, a similar warning dialog will pop up to remind the user that there are three responses to choose.

Figure 12. Test scenario of verifying a signed plug-in in IBM Lotus Expeditor
Test scenario of verifying a signed plug-in in IBM Lotus Expeditor

The certificate details — Version, Issued by, Issued to, and Signature Algorithm — will be listed if you click View Certificate Details…, as shown in Figure 13. We think IBM Lotus Expeditor provided more information to advocate the trust of the plug-in from the user.

Figure 13. Certificate details of the signature in a signed plug-in
Certificate details of the signature in a signed plug-in

Signed but expired feature

With the information in Figure 11, we know the self-signed certificate's validity is 02-13-2009. If we change the time in our operating system into 02-14-2009, as shown in Figure 14, the signed plug-in will become an expired plug-in because of its "EXPIRED CERTIFICATE."

Figure 14. Change your system time in your operating system
Change your system time in your operating system

Now we can use a Jarsigner command to verify the signature to find out the signed, but, unfortunately, expired result. Please pay attention to the last sentence in Figure 15.

Figure 15. Verify a expired signature in a plug-in by a Jarsigner command
Verify a expired signature in a plug-in by a Jarsigner command

When you try to install this plug-in into Eclipse runtime using update manager, Eclipse will tell you that the feature has been signed, but that it's out of date, as shown in Figure 16. That's because Eclipse detected that the current date in the operating system (02-14-2009) has beyond the validity scope (02-13-2009). Consequently, "EXPIRED CERTIFICATE" is highlighted, which alerts the user to possible risks. However, the user may still accept and install the plug-in by clicking the Install or Install All button, even though the plug-in's validity has expired. That's the user's choice.

Figure 16. Test scenario of verifying an expired plug-in in Eclipse
Test scenario of verifying an expired plug-in in Eclipse

Figure 17 demonstrates the similar notification of an expired certificate for a plug-in, which will be thrown out when you install such a plug-in into IBM Lotus Expeditor.

Figure 17. Test scenario of verifying expired plug-in in IBM Lotus Expeditor
Test scenario of verifying expired plug-in in IBM Lotus Expeditor

Conclusion

The Eclipse IDE and IBM Lotus Expeditor effectively apply signature security mechanisms in their provisioning subsystems by enhancing the code security level when it's deployed to end users' desktops. This article explored the essentials of the plug-in signature mechanism, including its categories, creation, and verification strategies. The sample plug-ins (unsigned, signed, and expired) introduced by this article could be moved to another Eclipsed-based product that requires security verification.


Downloads

DescriptionNameSize
Sample codeos-eclipse-pluginsigsSigned_HelloWorld.update.zip8KB
Sample codeos-eclipse-plugin-sigsUnsigned_HelloWorld.update.zip3KB

Resources

Learn

Get products and technologies

Discuss

  • The Eclipse Platform newsgroups should be your first stop to discuss questions regarding Eclipse. (Selecting this will launch your default Usenet news reader application and open eclipse.platform.)
  • The Eclipse newsgroups has many resources for people interested in using and extending Eclipse.
  • Participate in developerWorks blogs and get involved in the developerWorks community.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Open source on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Open source
ArticleID=351966
ArticleTitle=Explore Eclipse's plug-in signature mechanism
publish-date=11182008