Loading your JAR executables

To extend the security of your VaultCode, client developed JAR executables should be allow-listed, either via a code signing certificate or via JAR hash.

Motivation for allowlisting

While developping locally, each developer can have their own JKS, that they do not share with other developers, similar to their own private keys. Once you begin integrating VautlCode into your CICD pipelines, the code signing certificate should be moved to the pipeline.

Lastly, once you are in production, the certificate should be strictly protected and access to it should be limited and maintained. For example, only Release Managers have access to the signing certificate, that is stored inside an HSM.

Allowlist via code signing certificate

To streamline the development process, but maintain security, clients can onboard a code signing certificate.

info

Multiple certificates can be onboarded to allow changes from different developers who each have their own certificate.

Create and use code signing certificates

1. Create a code signing key pair per environment or developer.

   keytool -genkeypair \
      -alias "VaultCode Dev Signing Certificate" \
      -keyalg "RSA" \
      -keysize "4096" \
      -validity "365" \                          # Valid for 365 days
      -keystore "vaultcode_keystore.jks" \
      -storepass "strong_keystore_password" \
      -keypass "strong_private_key_password" \
      -dname "CN=Developer Name VaultCode, OU=IT, O=Company, L=Zurich, ST=Zurich, C=CH"

2. Allow-list the signing certificate in the VaultCode configuration.

   vaultcode:
      certificates:
         whitelist:
            - |
               --BEGIN--
               DEV 1 PEM HERE
               --END--
            - |
               --BEGIN--
               DEV 2 PEM HERE
               --END--

3. Compile your code into a JAR.

4. Sign your JAR.

   jarsigner \
      -keystore vaultcode_keystore.jks \         # Which keystore to use
      -storepass strong_keystore_password \      # Keystore password
      -keypass strong_private_key_password \     # Private key password
      -signedjar ./executable_signed.jar \       # Name of signed JAR
      ./executable_unsigned.jar \                # Name of JAR to be signed
      "VaultCode Dev Signing Certificate"        # Alias of key in keystore

5. Upload your JAR to VaultCode

   JAR=/path/to/signed_executable.jar
   curl "https://demo-vaultcode.securosys.com/api/v1/upload_execution_code" \
      --form "file=@${JAR};type=application/java-archive"

6. Call VaultCode to run your JAR

   curl "https://demo-vaultcode.securosys.com/api/v1/execute"

Securosys Primus Tools

If you would like to utilize the Securosys HSM TRNG, you can use the Securosys Primus Tools.

Allowlist via hash

The configuration file for VaultCode also allows the option vaultcode.fingerprint to allow-list executable JARs. Note that this allows only a singular executable to be whitelisted and is recommended for initial testing and testing environments that change rarely. Also suitable for environments that are highly scripted and update of the hash can be automated.

vaultcode:
  fingerprint: 
    - |
       e7fd9dec16945df11753dfcac5f2993bac870991868d2ea59ee957e7f3053ad3 # Positive Approval Executable
       3adb6f0729d4bae2bd15d442d713949e45928a716aa692c97690d180cc6a3349 # Stateful Executable

info

Multiple fingerprints of JARs can be onboarded to allow different logic to be used.

Additionally, if both vaultcode.allowlist.certificates and vaultcode.fingerprint are blank, VaultCode will accept any JAR.

Allowlist with signing certificates or hash?

Both approach have the benefits and downsides. Below is a quick overview of the things to look out for when deciding which option is best for your use case.

	Certificate	Fingerprint
Pros	More flexibility Faster development (possible CI/CD pipelines) Reduced SO interaction	More security Guarantees only the intended executables are allowed (4-eye principle)
Cons	If certificate access is compromised, the wrong executable could be onboarded	Requires SO interaction for each new executable Cannot be integrated into CI/CD pipelines