Overview
Audit log signing creates a cryptographically signed record containing:- Transaction hash
- Simulation results (events, logs, traces)
- Timestamp
- Digital signature
- Public key for verification
- Optional hardware attestation
- Tamper evidence: Any modification invalidates the signature
- Non-repudiation: Proof that a specific key signed the data
- Compliance: Auditable trail for regulatory requirements
- Hardware attestation: Proof that signing keys are HSM-protected
Signing methods
Erst supports two signing methods:Software signing
Uses Ed25519 private keys stored in PEM format
- Fast and convenient
- Suitable for development
- Keys can be backed up
HSM signing
Uses hardware security modules via PKCS#11
- Production-grade security
- Keys never leave hardware
- Compliance-ready
Software signing
Sign audit logs using an Ed25519 private key.Generate a signing key
Create an Ed25519 key pair:Sign with environment variable
Provide the private key via environment variable:Sign with CLI flag
Provide the private key directly:The
audit:sign command is part of the TypeScript bindings. For Go CLI integration, see the implementation in internal/cmd/audit.go.HSM signing (PKCS#11)
Sign audit logs using a hardware security module.Prerequisites
Install PKCS#11 provider:Configure environment
Set required environment variables:Optional environment variables
Optional environment variables
Sign with HSM
Generate a signed audit log:Hardware attestation
HSM signing can include hardware attestation proving the signing key is hardware-protected.Attestation data
When signing with an HSM, the audit log includes:- Certificates: X.509 certificate chain (leaf to root)
- Token info: HSM device information
- Key non-exportable: Confirmation that the key cannot be extracted
- Retrieved timestamp: When attestation was captured
Verification
The attestation is included in the signature hash, so:- Removing attestation invalidates the signature
- Modifying attestation invalidates the signature
- Attestation proves the key is HSM-protected
Hardware attestation is optional but recommended for high-security environments where you need cryptographic proof that keys are hardware-protected.
Audit log structure
Version 1.1.0 schema
Hash computation
Thetrace_hash is computed as:
Verification
Verify an audit log’s integrity and signature:Programmatic verification
Manual verification
# Extract payload + attestation
jq '{payload: .payload, hardware_attestation: .hardware_attestation}' audit-log.json \
| openssl dgst -sha256 -hex
Verification results
- Valid: Hash matches and signature verifies
- Invalid: Payload was modified, signature is wrong, or key is incorrect
- Attestation removed: Hash won’t match if attestation was stripped
YubiKey PIV integration
Use YubiKey devices for HSM signing.PIV slots
YubiKey PIV supports multiple key slots:| Slot | Purpose | Use Case |
|---|---|---|
| 9a | PIV Authentication | General signing |
| 9c | Digital Signature | Document signing |
| 9d | Key Management | Encryption |
| 9e | Card Authentication | Low-security auth |
| 82-95 | Retired Slots | Key rotation |
| f9 | Attestation | Key attestation |
9c (Digital Signature)
Generate key on YubiKey
Configure for Erst
Common workflows
Generate audit log after debugging
# Using software key
export ERST_AUDIT_PRIVATE_KEY_PEM="$(cat ./key.pem)"
node dist/index.js audit:sign \
--payload "$(erst session export-payload)" \
> audit-log.json
Batch audit log generation
Generate audit logs for multiple transactions:Verify archived audit logs
Check integrity of stored logs:Security best practices
Protect private keys
Protect private keys
For software keys:
- Store with restricted permissions:
chmod 600 key.pem - Never commit to version control
- Use environment variables, not hardcoded paths
- Rotate keys periodically
- Back up securely (encrypted storage)
- Never export private keys
- Use strong PINs (not default PINs)
- Enable PIN retry limits
- Physical security for HSM devices
- Audit HSM access logs
Use HSM for production
Use HSM for production
Software keys are convenient for development, but production audit logs should use HSM:
- Keys cannot be extracted
- Tamper-evident hardware
- Compliance-ready (FIPS 140-2)
- Hardware attestation available
- Centralized key management
Include hardware attestation
Include hardware attestation
When using HSM, always include attestation:
- Proves keys are hardware-protected
- Cannot be forged
- Required for high-assurance compliance
- Covered by signature (tamper-evident)
Archive audit logs securely
Archive audit logs securely
- Store in append-only storage
- Use write-once media for immutability
- Encrypt at rest
- Replicate to multiple locations
- Test restoration procedures
- Document retention policies
Troubleshooting
Invalid signature
- Verify you’re using the correct public key
- Check audit log wasn’t modified
- Ensure payload format matches schema version
- Re-generate audit log if corrupted
HSM not detected
- Check PKCS#11 module path:
ls $ERST_PKCS11_MODULE - Install HSM drivers/software
- Verify HSM is connected:
yubico-piv-tool -a status - Check permissions:
sudo usermod -a -G plugdev $USER
PIN incorrect
- Verify PIN is correct
- Check PIN hasn’t been locked (retry limit)
- Reset PIN if needed (requires PUK)
- Use correct PIN for the token
Key not found in HSM
- List available keys:
yubico-piv-tool -a list - Verify key label or ID is correct
- Check you’re using the right slot
- Generate key if it doesn’t exist
Implementation details
Source files
Audit log signing is implemented in:internal/cmd/audit.go- Go implementationinternal/signer/- Signer interfaceinternal/signer/memory.go- Software signerinternal/signer/pkcs11.go- HSM signer
Key functions
Audit log generation:Generate()- Legacy function (software key)GenerateWithSigner()- Generic signer interfaceVerifyAuditLog()- Verify signature and hash
internal/cmd/audit.go:73, internal/cmd/audit.go:84, internal/cmd/audit.go:143
Signer interface
InMemorySigner- Ed25519 software signingPkcs11Signer- PKCS#11 HSM signing