Home Discussions Questions & Answers Signing EBS Jar Files With HSM (Hardware Security Module)

Signing EBS Jar Files With HSM (Hardware Security Module)

Avatar photoCustomer July 18, 2019 at 10:57 am

Our security policy mandates the use of a Hardware Security Module (HSM) for code signing all EBS Java Archives (Jar Files) to ensure integrity and authenticity. What are the key steps and complexities involved in Signing EBS Jar Files With HSM?

Viewing 10 reply threads
  • Author
    Replies
    • Support July 19, 2019 at 5:41 am  

      Implementing HSM for EBS Jar signing is complex. It involves configuring the Java environment (Java/Jarsigner utilities) to interface securely with the HSM device using PKCS#11 libraries, managing the necessary keystores, and executing the `jarsigner` command sequence for mass signing of the EBS Jar files.

    • Avatar photoCustomer July 19, 2019 at 4:13 pm  

      We understand this must be repeated after patching. What is the technical method for identifying precisely which Jar files were modified by an ADOP patch application, so we don’t unnecessarily re-sign everything?

    • Support July 21, 2019 at 7:20 am  

      A highly useful tip for optimizing this process post-patching is to locate the list of modified Jar files. This list can be found in one of the subdirectories created during the `adop phase=prepare & apply` process, typically within `$NE_BASE/EBSapps/log/adop/`.

    • Avatar photoCustomer July 23, 2019 at 3:26 am  

      If we are using a specific corporate HSM solution, like DigCert KeyLocker, is there documented feasibility or success stories for integrating this with EBS?

    • Support July 23, 2019 at 9:30 pm  

      Specific integration details for proprietary HSM solutions like DigCert KeyLocker with EBS are challenging to find, suggesting this is often a difficult implementation that requires specialized knowledge due to the complexity of integrating the HSM with Oracle’s existing code-signing process.

    • Avatar photoCustomer July 25, 2019 at 6:47 pm  

      During ADOP patching, the `fs_clone` phase sometimes gets stuck. If this happens mid-signing cycle, how does that impact the integrity checks?

    • Support July 27, 2019 at 4:12 pm  

      A stuck `adop fs_clone` is a critical issue that must be resolved immediately, potentially requiring deep debugging (checking `fnd_nodes` or OS logs). If this occurs during a critical signing process, the integrity of the target file system (e.g., the patch file system) may be compromised, requiring careful verification of all applied patches and file signatures afterward.

    • Avatar photoCustomer July 28, 2019 at 5:16 am  

      We need a rapid way to verify the patching status of critical security fixes before initiating the post-patch signing process.

    • Support July 28, 2019 at 9:48 pm  

      The most efficient way is through a custom Blitz Report leveraging the `AD_PATCH.IS_PATCH_APPLIED` function, run directly from the EBS Forms interface. This allows DBAs to quickly confirm the presence or absence of necessary security patches prior to the time-consuming HSM signing phase.

    • Avatar photoCustomer July 29, 2019 at 6:30 am  

      If we are deploying new custom reports using Blitz Report, do these reports also require custom code signing?

    • Support July 31, 2019 at 2:03 am  

      Blitz Report resides in Oracle Forms and leverages existing EBS infrastructure. While the underlying EBS Forms and Java framework components require signing (the JAR files) , the Blitz Report SQL definitions themselves are stored securely in the database with version control, managed by EBS application security (VPD and responsibility assignment).

Viewing 10 reply threads
  • You must be logged in to reply to this post.

Login with: