Explore Eclipse plug-in signature mechanism

Security is an important issue when installing plug-ins for software. This article explores the signature technology used on the eclipse platform to determine the reliability of the plug-in. Eclipse classifies plug-ins into five categories: signed, unsigned, trusted, untrusted, and expired. This article describes how to create a signature-based plug-in eclipse and IBM Lotus Expeditor.

This article introduces the Eclipse plug-in signature and its application. In addition, it introduces the test policies used by the IBM Lotus Expeditor client supply system to control code access to local or remote eclipse update sites.

Signature is an indispensable mechanism for eclipse security functions. During the download of the plug-in, eclipse users can verify the JAR file signature published to the Update site. This allows you to obtain reliable information about the code to be installed. This feature allows you to identify the code publisher and verify whether the code has been modified after it is uploaded to the Update site. IBM Lotus Expeditor/Lotus Notes uses this security mechanism through its update Manager component to provide users with a signature check.

Prerequisites

To maximize the benefits of this article, you need to use the eclipse development environment and sample code. If you do not have eclipse, download:

Java 2 Standard Edition

You can obtain Java 2 Standard Edition V5 or an updated version from Sun Microsystems.

Eclipse

You can find the eclipse platform on the eclipse Foundation. To use another test platform, download IBM Lotus Expeditor v6.1.x, which is optional.

See references to obtain eclipse and Java JDK. Obtain the sample code from the download section.

Background

Eclipse plug-ins are classified based on the following five types of digital signatures:

Unsigned plug-in

By default, all plug-ins generated by eclipse are unsigned.

Signature plug-in

After the unsigned plug-in is signed, it becomes a signature plug-in.

Trusted plugin

If a signature plug-in uses a trusted signature, the plug-in will be trusted during eclipse runtime. Therefore, it is a trusted plug-in.

Untrusted plug-in

This signature plug-in uses untrusted signatures.

Expired plug-ins

All signature plug-ins have a validity period. The plug-in is encapsulated in the jar file and has a signature, but the certificate used to sign the JAR file has expired. This plug-in is called an expiration plug-in.

Figure 1. Plug-in classification

Implementation and test scenarios

Learn how to use eclipse, keytool, and jarsigner to generate unsigned, untrusted, and expired plug-ins, and then verify them during eclipse runtime and IBM Lotus Expeditor runtime. Let's start with an unsigned plug-in.

Unsigned features

By default, plug-ins generated by IDE (such as Eclipse) are unsigned plug-ins. For example, follow these steps to create an unsigned plug-in:

1. Click File> New> project...> Plug-in development> plug-in project, and then click Next.
2. Enter helloworld in the Project Name field, select default settings for other options, and click Next.
3. Click Next in the subsequent plug-in content wizard.
4. Select helloworld and click Finish on the template Wizard Page.
5. Click File> New> project...> Plug-in development> feature project, and then click Next.
6. Enter helloworld. feature in the Project Name field, use the default settings for others, and click Next.
7. Select the helloworld plug-in created on the referenced plug-ins and fragments Wizard Page, and click Finish.
8. Click File> New> project...> Plug-in development> Update site project, and then click Next.
9. Enter helloworld. updatesite in the project name segment. Use the default settings for other items, and click Finish.
10. Click Add feature... Click, select helloworld. feature, and click OK.
11. Click build to generate an Update site file in the local file system.
12. Verify the Update site created in the workspace.

Through the above 12 steps, we have created a helloworld sample plug-in, a helloworld feature, and a helloworld Update site to encapsulate them.

Figure 2. Types of plug-ins

Use eclipse update manager to verify its identity through the following steps:

1. Click Help> Software Update> Find and install ....
2. Select search for new feature to install and click Next.
3. Click new local site... Click, navigate to helloworld to update the site, and click OK.
4. Click Finish.

We will receive an "unsigned feature" notification that this feature is not signed and cannot be verified by its provider.

Figure 3. Verify unsigned plug-ins in eclipse

If you use the same steps to install the plug-in, IBM Lotus Expeditor (a powerful eclipse-based platform) also displays a similar warning message. You can select to accept or reject the plug-in by clicking the single-choice button, as shown below.

Figure 4. test scenario for verifying unsigned plug-ins in IBM Lotus Expeditor

Unsigned features

The purpose of code integrity is to ensure that the Code is not modified before installation. To achieve this goal, we use two utilities: keytool and jarsigner.

Keytool is a command line tool used to manage keys and certificates. A certificate is a digital signature statement from an entity (such as an individual, company, computer, or program). It indicates the public keys (or other information) of other entities) has a specific value. Keytool currently processes X.509 certificates. X.509 certificates include version, validity period, and subject name (common name, organization department, organization, and country. The key and certificate are stored in the keystore. It is actually a file. It uses a password to protect the private key.

Jarsigner is another utility used to sign the JAR file and verify the signature. To verify the digital signature in the jar file, jarsigner obtains the certificate attached to the JAR file and checks whether the public key of the certificate is trusted based on the specific keystore. We will use jarsigner's signature and verification functions in this article.

First, we use keytool to create a keystore, which contains a pair of keys (public keys and private keys ). Run the following command.

Listing 1. Creating 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 completes the following tasks:

• It creates a keystore file named mykeystore in the C:/keystore directory and assigns it a password store123. The default keystore type is jks.
• It generates public/private key pairs for an object. The Distinguished Name of the common name of the object is "Li Xing", the Organization Department is "CDL", the Organization is "IBM", and the country is "cn ". The password key123 is assigned to the private key. The keystore contains an entity named "business.
• It uses the default DSA key generation algorithm and creates two 1024-bit (default length) keys.
• It uses the default signature algorithm (sha1 and DSA) to create a self-signed certificate. The validity period is 180 days.

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

Figure 5. generated mykeystore

After creating a self-signed certificate, we use the following jarsigner command to sign feature. jar and plugin. jar, as shown in Listing 2 and 3. Here, we use the jarsigner signature function in the jarsigner [Options] jar-file alias command format. In the option field, we provide the location of the keystore file, the keystore password, and the private key password.

List 2. Sign the JAR file of the feature

jarsigner -keystore C:/keystore/mykeystore -storepass store123 -keypass key123 C:/workspace/HelloWorld.update/features/HelloWorld.feature_1.0.0.jar business

Listing 3. Signing the 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 it is valid for 180 days, you will receive a warning that the signature certificate will expire after 6 months. The last line in Figure 6 and Figure 7 is shown.

Figure 6. Warning received when signing the JAR file of the feature

Figure 7. Warning received when signing the plug-in JAR File

By running the preceding two commands, what changes will happen to the feature JAR file and the plug-in JAR file? Open the META-INF folder in helloworld. feature_1.0.0.jar and helloworld_1.0.0.jar and you will see two files added-business. SF and business. DSA, 8.

Figure 8. Business. DSA and business. SF in the META-INF folder

In fact, the difference between unsigned and signature plug-ins is that the two files are added:. SF and. DSA. We will first discuss the business. SF file. This is the signature file of the JAR file. Its internal information is displayed in the form of name-value pairs according to rfc822 standard. The signer is represented by a signature file with the extension. SF. The entry X-digest-manifest-Main-attributes (X is the Digest algorithm, such as sha1) in the main part contains the summary value of the main attribute of the list file. For example, the base64 representation of embedded data is a popular technology that uses the Internet to encrypt and transmit 8-bit bytes. Table 1 lists the sample content of the business. SF file in the feature JAR file and plug-in JAR file, including version, signature algorithm, JVM, and summary information.

Table 1. Business. SF files in the feature jar files and plug-in jar files

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: oowzec1mvb8pgplljsy521_dir4 =	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 =

The business. DSA file is the opposite. It is a more complex binary signature file. This signature block file stores the digital signature of the corresponding signature file. As you can see, the business. DSA file and business. SF file use the same base file name, but the extension is different. In fact, you can also select. RSA and. PGP as the extension of the binary signature file, depending on the algorithm used. Figure 9 shows the content in business. DSA and some readable information after conversion using a text processor (we use ultraedit. This means you can see some text strings, such as "cn", "IBM", "Lotus Expeditor", and "Li Xing ". However, you cannot see the complete information. This is the wonder of the signature.

Figure 9. Business. DSA content

Before installing the plug-in JAR file, we can use the jarsigner-Verify command to verify its signature. Run the following command for the signed plug-in JAR file and obtain the response. 10. -Verbose and-Certs options will display detailed output and certificates during verification.

Listing 4. Use the jarsigner command to verify the JAR file of the plug-in with the signature

jarsigner -keystore C:/keystore/mykeystore –storepass store123 –verify –verbose–certs C:/workspace/HelloWorld.update/plugins/HelloWorld_1.0.0.jar

Figure 10. Use the jarsigner command to verify the plug-in Signature

When you use the jarsigner command for verification, it lists and verifies the basic information and expiration information of the signature in the helloworld_1.0.0.jar file.

Now, try to install the embedded Update site through a signed plug-in. You will receive the notification "you are about to install a signed feature" and display the details of your self-signed certificate. 11.

Figure 11. Verify the test scenario with signature plug-in eclipse

Compared with unsigned plug-ins, users prefer to trust plug-ins with signatures. After such a signature plug-in is installed in IBM Lotus Expeditor, a similar warning window will pop up to remind users of three processing methods available.

Figure 12. Verify the test scenario with a signature plug-in IBM Lotus Expeditor

If you click View certificate details ..., The certificate details-version, issued by, issued to, and signature algorithm are listed, as shown in Figure 13. IBM Lotus Expeditor provides more information to encourage users to trust the plug-in.

Figure 13. Details of the signature certificate in the signature plug-in

Features with expired signatures

According to the information provided in figure 11, we know that the self-signed certificate is valid from 02 to 13-2009. If we change the operating system time to 02-14-2009 (14), the signature plug-in will expire due to "expired certificate.

Figure 14. Change the operating system time

Now, we can use a jarsigner command to verify the signature. The result is that the plug-in has a signature, but it has expired. Note the last sentence in Figure 15.

Figure 15. Use the jarsigner command to verify the expiration signature of the plug-in

If you use the update manager to install the plug-in to the eclipse runtime, eclipse notifies you that the plug-in has a signature but has expired, as shown in Figure 16. This is because eclipse detects that the operating system's current date (02-14-2009) has exceeded the valid period (02-13-2009). Therefore, the "expired certificate" is highlighted to warn users of potential risks. Although the signature of the plug-in has expired, you can click Install or install all to install the plug-in. This depends on the user.

Figure 16. test scenario for verifying expired plug-ins in eclipse

Figure 17 shows similar expiration certificate notifications for this plug-in. This notification will pop up when you install such a plug-in to IBM Lotus Expeditor.

Figure 17. test scenario for verifying expired plug-ins in IBM Lotus Expeditor

Conclusion

Eclipse IDE and IBM Lotus Expeditor effectively apply the signature Security Mechanism to their supply subsystems to enhance the security of plug-ins when deployed to end-user desktops. This article explores the key points of the plug-in signature mechanism, including plug-in classification, creation, and verification policies. The sample plug-in (unsigned, signed, and expired) described in this article applies to other eclipse-based products that require security verification. (

 

 

Remarks: This article Reprinted from: http://www.linuxeden.com/html/sysadmin/20081225/63260.html