Cybersecurity Architecture

1. INTEGRITY
   Every decision is signed with Ed25519.
   Any tampering with any signed field is detectable.
   Verification requires only the public key.

2. DETERMINISM
   Forbidden non-deterministic APIs are blocked.
   Same inputs always produce same decision.
   Replay attacks are detected and rejected.

3. PROVENANCE
   Signal origins are recorded and hashable.
   Evidence is committed by hash before transformation.
   The full chain from evidence to decision is auditable.

Algorithm: Ed25519 (Edwards-curve Digital Signature Algorithm)
Key size:  256-bit private key, 256-bit public key
Security:  128-bit security level
Standard:  RFC 8032

Algorithm: SHA-256
Standard:  FIPS 180-4

Threat:    An attacker alters a decision after it is made.
           Example: change "reject" to "approve" in the database.

Protection: Ed25519 signature over all 17 attestation fields.
           Any field change breaks the signature.
           Detected by verifyAttestation().
           
Strength:  Cryptographic — breaking Ed25519 requires
           solving the discrete logarithm problem on
           Curve25519. Computationally infeasible.

Threat:    An attacker substitutes a different policy
           version to change decision outcomes.

Protection: bundleHash and manifestHash in every attestation.
           Policy bundle is content-addressed.
           A different policy produces a different hash.
           Verifier checks bundle_verified.

Strength:  SHA-256 collision resistance.
           A different policy cannot produce the same hash.

Threat:    An attacker replays a valid governance execution
           to trigger a second disbursement or action.

Protection: Two-phase commit replay store.
           executionId reserved before evaluation.
           Same executionId → INV-013 thrown immediately.
           confirmExecution uses separate replay key:
           "confirm:" + executionId.

Strength:  Cryptographic uniqueness of executionId (UUID v4).
           Stored in Redis with atomic operations.

Threat:    An attacker modifies the policy evaluation
           engine to change how rules are evaluated.

Protection: evaluatorHash in every attestation.
           hashEvaluator() computes hash of evaluator code.
           verifyAttestation() checks evaluator_verified.
           Any modification produces a different hash.

Strength:  SHA-256 — modified evaluator cannot
           produce the same hash as the original.

Threat:    An attacker modifies the governance runtime
           to bypass governance checks.

Protection: runtimeHash in every attestation.
           Signed into the release manifest.
           verifyAttestation() checks runtime_verified
           and release_verified.

Strength:  SHA-256 + Ed25519 trust chain.

Threat:    Non-deterministic code (Date.now, Math.random)
           inside governed paths produces inconsistent
           decisions that cannot be replayed or verified.

Protection: Sealed execution scope.
           FORBIDDEN_GLOBALS list enforced at runtime.
           InvariantViolation thrown on any violation.
           CI gate detects forbidden APIs statically.

Strength:  Runtime enforcement — violation throws
           before evaluation completes.

Threat:    An attacker injects invalid signals to
           manipulate the decision.

Protection: validateSignalsStrict() runs before evaluation.
           Signals not in signalsSchema → VAL-003.
           Wrong type → VAL-005 through VAL-009.
           Execution stops on any validation error.

Strength:  Schema enforcement — only declared signals
           in declared types are accepted.

Private key compromise
  If the signing private key is stolen:
  An attacker can forge attestations.
  Mitigation: secrets manager, key rotation, HSM.
  This is a key management problem, not a protocol problem.

Signal accuracy
  Parmana validates signal types and schema.
  It does not validate that signal values are true.
  Example: monthly_income: 200000 passes validation
  even if the actual income is 40000.
  Mitigation: signal provenance, AA verification.

Execution truthfulness
  confirmExecution records what was reported as executed.
  It cannot observe what the execution system actually did.
  Mitigation: independent reconciliation, TEE.

Database administrator access
  A DBA with direct PostgreSQL access could delete records.
  Mitigation: database access controls, audit logging,
  append-only table constraints.

Operating system compromise
  If the OS is compromised, the private key is at risk.
  Mitigation: HSM, secrets manager, TEE.

Risk level: CRITICAL
Location:   Secrets manager (production)
            Environment variable (development only)
Impact:     Private key compromise → forged attestations
Mitigations:
  - Never store in source code
  - Never store in plain environment variables in production
  - Use AWS Secrets Manager, HashiCorp Vault, or GCP Secret Manager
  - Rotate annually
  - Offline encrypted backup
  - Consider AWS KMS or CloudHSM for highest assurance

Risk level: HIGH
Location:   Redis instance
Impact:     Redis compromise → replay attacks possible
Mitigations:
  - Redis AUTH password required
  - Redis TLS in transit
  - Network isolation — Redis not publicly accessible
  - Monitor for INV-013 security events

Risk level: HIGH
Location:   PostgreSQL instance
Impact:     Database compromise → records could be deleted
            (signatures still prevent modification)
Mitigations:
  - PostgreSQL role with INSERT only (no UPDATE, no DELETE)
  - Database not publicly accessible
  - Encrypted at rest
  - Point-in-time recovery enabled
  - Backup to separate storage

Risk level: MEDIUM
Location:   policies/ directory or bundle storage
Impact:     Policy substitution → different decisions
            (bundleHash in attestation detects this)
Mitigations:
  - Policy files in version control
  - Deployment pipeline validates bundleHash
  - Attestation verification checks bundle_verified

Risk level: MEDIUM
Location:   @parmanasystems/server (Fastify)
Impact:     Unauthorized access to governance APIs
Mitigations:
  - PARMANA_API_KEY environment variable for auth
  - Network controls — not publicly accessible
  - Rate limiting
  - TLS termination at load balancer

Risk level: MEDIUM
Location:   Caller-supplied signals to executeFromSignals()
Impact:     Invalid or manipulated signals
            (validateSignalsStrict() catches type errors)
Mitigations:
  - signalsSchema enforces types
  - Signal provenance tracks origins
  - AA integration for verified financial data

Provides:
  Ed25519 signing of every attestation
  SHA-256 fingerprinting of inputs
  Replay protection via two-phase commit
  Non-determinism detection via sealed scope
  Signal validation before evaluation

Does not provide:
  Key storage (use secrets manager)
  Network security (use TLS)
  Database security (use access controls)

Provides:
  Ed25519 signature verification
  8-check attestation verification:
    signature_verified
    runtime_verified
    schema_compatible
    bundle_verified
    release_verified
    trust_root_verified
    evaluator_verified
    governed

Requires:
  Public key only (not private key)
  Can run in completely isolated environment
  Does not need network access to original system

Provides:
  Evidence hashing before transformation
  Provenance metadata for signal traceability
  Trust level assessment

Does not provide:
  Source signature verification (Phase 2 — not yet built)
  Source authentication

Provides:
  PostgreSQL storage of attestations
  Queryable audit trail
  Security event storage

Security notes:
  Use INSERT-only PostgreSQL role in production
  Enable encrypted at rest
  Enable point-in-time recovery

File:       trust/root.key (private)
            trust/root.pub (public)
            trust/trust-root.json (metadata)

Private key: NEVER commit to version control
             NEVER share
             Store in secrets manager
             Offline encrypted backup required

Public key:  Publish widely
             Provide to regulators in advance
             Store alongside every audit record
             Anyone with this key can verify any attestation

Frequency:  Annually minimum
            Immediately on suspected compromise

Process:
  1. Generate new Ed25519 keypair
  2. Sign new trust root with old trust root
     (establishes continuity)
  3. Update trust/trust-root.json with new key_id
  4. Update PARMANA_SIGNING_KEY in secrets manager
  5. Restart governance server
  6. Verify new attestations use new signerKeyId
  7. Keep old public key for verifying historical attestations

// AWS Secrets Manager
import { AwsKmsSigner } from "@parmanasystems/execution";

const signer = new AwsKmsSigner({
  keyId: process.env.AWS_KMS_KEY_ID,
  region: process.env.AWS_REGION,
});

// Or retrieve from Secrets Manager and use LocalSigner
const privateKey = await secretsManager.getSecretValue({
  SecretId: "parmana/signing-key",
});

const signer = new LocalSigner(privateKey.SecretString);

INV-013  Replay detected
  → Possible replay attack or double-submission bug
  → Investigate source of duplicate executionId
  → Alert: immediate

release_verified === false in verifyAttestation
  → Release manifest hash mismatch
  → Possible runtime tampering
  → Alert: immediate, escalate

evaluator_verified === false in verifyAttestation
  → Evaluator hash mismatch
  → Possible evaluator tampering
  → Alert: immediate, escalate

bundle_verified === false in verifyAttestation
  → Policy bundle hash mismatch
  → Possible policy tampering
  → Alert: immediate

signature_verified === false
  → Attestation signature invalid
  → Possible data tampering in audit store
  → Alert: immediate, escalate

// Run this daily in a separate process from the governance server
import { verifyAttestation } from "@parmanasystems/verifier";

const result = verifyAttestation(
  attestation,
  verifier,
  runtimeManifest,
  provenanceInput
);

if (!result.checks.release_verified) {
  // ALERT: runtime may have been tampered
}

if (!result.checks.evaluator_verified) {
  // ALERT: evaluator may have been tampered
}

if (!result.checks.signature_verified) {
  // ALERT: attestation record may have been altered
}

☐ Private key stored in secrets manager (not env var)
☐ Public key published and provided to relevant parties
☐ Redis requires AUTH password
☐ Redis accessible only from governance server subnet
☐ PostgreSQL uses INSERT-only role for audit-db
☐ PostgreSQL not publicly accessible
☐ TLS on all network connections
☐ API key configured (PARMANA_API_KEY)
☐ RedisReplayStore configured (not MemoryReplayStore)
☐ Key rotation schedule documented
☐ Offline backup of trust root key

☐ Alert configured for INV-013 events
☐ Alert configured for verifyAttestation failures
☐ Daily verification job running in isolated environment
☐ PostgreSQL backup tested monthly
☐ Key rotation performed annually
☐ Penetration test of governance server annually
☐ Policy changes reviewed before deployment
☐ bundleHash verified after policy deployment

✅ Verify any attestation signature
✅ Detect any tampered attestation field
✅ Verify policy bundle integrity
✅ Verify evaluator has not been modified
✅ Verify release manifest authenticity
✅ Verify trust chain from trust root to decision
✅ Detect replay of any governance execution
✅ Verify signal fingerprint consistency

❌ Forge a valid attestation
❌ Modify any signed field without detection
❌ Impersonate the governance signer
❌ Produce a valid confirmation of execution