The Eclipse Integrated Development Environment (IDE) is the most popular Java IDE.  Eclipse is also used in other programming languages such as C/C++.  Third party plugins for the Eclipse platform help to make it an incredibly powerful software development tool. 

Eclipse projects, like any software release, should be signed prior to publishing. Signing code is a critical step in the DevOps process as it allows users to authenticate the author and ensure the code has not been tampered with. Continuously evolving threats from malicious code (viruses, ransomware, Trojans, etc.) can disrupt and financially harm organizations and individuals making it imperative that software publishers deliver trusted code.

At the heart of code signing is the digital signature that uniquely identifies the publisher. To create this signature, the publisher must generate a cryptographic key pair (public and private) and certificate describing the publisher. In some cases, the certificate should be traceable to a universally trusted Certificate Authority (CA). Otherwise the publisher generates their own certificate (“self-signed”).

The actual code signing process consists of generating a hash on the code and encrypting the hash with the publisher’s public key.


To authenticate the code, the user verifies the signing certificate and decrypts the hash using the publisher’s public key. A new hash is then computed across the code and compared with the decrypted hash. If they match, the code is authenticated.

Generating Keys and Certificates with Eclipse

Publishers signing JAVA code from Eclipse use the Java Keystore to store and access cryptographic keys and certificates. Entries are protected by a Keystore password and different “debug” and “release” Keystore files can be created. Once the Keystore is setup, Jarsigner can be used to generate digital signatures for JAR files as needed.

Generating the public / private key pairs and certificates requires use of Java Keytool. Private keys are assigned a name and password. Keytool also supports the generation of a Certificate Signing Request (CSR) used by Certificate Authorities (CA) to create a trusted certificate. The resulting keys and certificates are imported into a Keystore file.

Challenges to Securing Private Keys with Eclipse

Security of private keys is highly important and can directly affect the reputation of a software publisher. If a third party gains access to the private key, they could use the publisher’s identity to sign and distribute malicious code that corrupts or steals user data or attacks other software in the system. In addition, without the key, releasing future versions of the same software to an installed base may not possible (depending on the application).

Many DevOps teams create and store private keys using the Keytool default configuration and store them in Keystore files located on the build or development server. There are numerous security concerns with this approach:

  • The Keystore file, and associated private key, is available to anyone with access to the server;
  • Random Number Seeding of Key Generation is software based with limited randomness;
  • Password protection may not be adequate to protect against key discovery (a simple key logger on the build machine could record the Keystore and private key passwords);
  • If code and Keystore are on the same server, an attack could net the software and private key, leading to a hacker inserting malicious code and impersonating the publisher;
  • Forgotten or lost private key passwords can impact releasing future sotware revisions;
  • Transferring signing configs to third party build environments can expose this information; 
  • Moving signing information from the Eclipse environment to a separate machine for “safekeeping” is another opportunity for loss, misplacement or theft of key information.

An additional significant concern is the inability to prevent publishing code without “sign-off” of the DevOps team (development, QA, product management, etc.). With Keystore and Keytool, software could be inadvertently published by just one employee, who may be disgruntled or just careless.

Best Practices Private Key Security and the BlackVault HSM

Cryptographic key best practices dictate that a “clear text” private key should never be exposed; and if transfered, it must be encrypted. This is not the case with server based code signing since “clear text” private keys are moved into common memory for signing operations by the OS. Even when not in use, private keys in Keystore are only as secure as the assigned passwords. Best practices also apply to the code signing process which should be documented, ensure private keys are in a known secure location, and have controls restricting code signing to authorized DevOps members.

Best practices can be achieved by introducing a highly secure and reliable Hardware Security Module (HSM), like the Engage BlackVault HSM, to the code signing process. An HSM is a specialized hardware device where keys are generated, stored, and used in a secure cryptographic boundary.

Historically, HSMs have been difficult to use and expensive. This is no longer the case, as the BlackVault HSM incorporates an easy to use touch screen color display, integrated smart card reader, and secure Ethernet / USB ports. The BlackVault HSM provides physical and logical barriers to attack that do not exist with a software only security solution; and unlike USB and smart card tokens, it provides multi-factor and Quorum authentication and supports network attached environments. It’s long battery life also allows for easy transport and offline storage in a secure room or safe.

The BlackVault HSM performs all cryptographic operations inside of a silicon-based FIPS Level 3 tamper reactive boundary, and private keys are never exposed. In addition, if there is an environmental, electrical, or physical breach; the cryptographic keys will be deleted (“zeroized”). Prior to back up, private keys are encrypted and the cryptographic material can be distributed across multiple smart cards for additional security.

The BlackVault HSM key generation and code signing capabilities are augmented with a powerful cryptographic engine that generates all the required RSA key types and sizes, a variety of hash algorithms (SHA2, SHA1, MD5/MD2, etc.) as well as elliptical cryptography. Hardware generated entropy ensures truly random numbers are used in cryptographic operations such as key generation.

The BlackVault HSM can also prevent code from being signed without approval from designated members of the DevOps team (QA, development, product management, etc.). Using the Quorum feature, each signatory is assigned a smart card and PIN. The code can’t be released (signed) until all required signatories are authenticated by inserting their smart card into the BlackVault HSM and entering their corresponding pin (multi-factor authentication).

NEW SMART CARD BV L angle with screen smCROPED


Integrating the BlackVault HSM into the Eclipse IDE is straight forward. Simply point the Java “SUN PKCS11 provider” to the BlackVault PKCS11 library and create a hardware Keystore (PKCS11 is a cryptographic library allowing Java and the BlackVault to communicate). Once the hardware Keystore is established, the BlackVault can be used to create keys and sign code. It’s also easy to transfer existing keys and certificates to the BlackVault

Using the BlackVault HSM with Eclipse ensures:

  • Publishers’ private signing keys are secured with best practices FIPS Level 3 HSM technology;
  • Code signing with the Private Key is performed within a FIPS Level 3 silicon based cryptographic boundary;
  • Code release signing requires “M of N” quorum approval;
  • Keys securely backed up on a BlackVault HSM clone or multiple smart cards;
  • The risk of theft or loss of Keystore files, passwords and keys is removed;
  • Installation, configuration and operation is easy with the BlackVault HSM’s touch screen display;
  • HSM authentication can’t be compromised from intermediary software or devices due to the BlackVault HSM's integrated multi-factor single trust path authentication.

*Hash: A numeric value of a fixed length that uniquely identifies data. It is much shorter than the code being signed and is therefore faster to encrypt / decrypt while using less compute power.

Engage logo 990000 rev 2.000
9565 Soquel Drive Dr,
Aptos, CA 95003
Telephone: +1-831-688-1021
Toll Free : +1-877-ENGAGE4
Designed, Fabricated, and Assembled
in America icon
Supported Worldwide