Investigate implementing HMAC/signature integrity protection for ActivationDesc

[pfirmstone]

Problem

Phoenix Activation and JGDMS service activation rely on ActivationDesc objects to convey service configuration, codebase URIs, and initialization data from the activation daemon to spawned group JVMs. These descriptors are persisted in the activation daemon's store and transmitted over RMI connections. Currently, there is no documented integrity protection (HMAC, digital signature, or certificate-based verification) to detect or prevent tampering with stored or transmitted ActivationDesc objects.

A compromised activation daemon store, or an attacker with network access to the activation protocol, could modify ActivationDesc to:

• Change the service class to be instantiated
• Alter codebase URLs to point to malicious code
• Inject or modify initialization data
• Bypass permission checks by altering the descriptor before group JVM deserialization

This is a high-priority defense-in-depth gap identified in residual N-13 (activation deserialization authority trust boundary).

Investigation Scope

1. Current ActivationDesc Storage & Transmission

   • Identify all storage points where ActivationDesc is persisted (activation daemon filesystem, serialized state, etc.)
   • Document the current serialization and transmission protocol
   • Identify attack surfaces (file permissions, network interception, daemon compromise)

2. Integrity Protection Design Options

   • HMAC-based integrity: Compute HMAC-SHA256 keyed with a daemon-held secret; verify at group JVM deserialization
   • Digital signature: Sign ActivationDesc with an admin/daemon private key; verify with public key in group JVM
   • Certificate pinning: Bind signature verification to a certificate chain trusted by policy
   • Hybrid approach: Combine method with key derivation or rotation strategies

3. Integration Points

   • Where should signing occur? (admin tool, activation daemon registration, group instantiation)
   • Where should verification occur? (activation daemon, group JVM at instantiation, policy-controlled)
   • How should key/certificate management be handled? (per-daemon, per-realm, per-group-policy)
   • Impact on backward compatibility and deployment

4. Policy & Authority

   • Should descriptor integrity be policy-enforced (configurable on/off)?
   • How should verification failures be handled (reject descriptor, log warning, delegate to policy)?
   • Interaction with DirtyChai SerialObjectPermission and group JVM policy authority

Deliverables

• Detailed analysis of current ActivationDesc storage, serialization, and transmission paths
• Threat model with specific tampering attack scenarios
• Comparison and recommendation of integrity protection algorithms
• Design proposal including key/certificate management strategy
• Prototype implementation sketch or proof-of-concept
• Performance impact assessment
• Backward-compatibility migration strategy
• Documentation of policy integration points

Related Issues & Context

• DirtyChai N-13 (residual): Activation deserialization authority trust boundary gaps (SECURITY_ANALYSIS.md)
• DirtyChai#134: TLS subject authentication context propagation
• DirtyChai#137: SerialObjectPermission enforcement in activation
• DirtyChai#133 (WIP PR): PROCESS_ISOLATION.md N-13 analysis with hardening recommendations
• JGDMS#135: SerialObjectPermission enforcement boundaries in group JVM deserialization

[pfirmstone]

Investigate implementing HMAC/signature for ActivationDesc integrity protection #186