Repository navigation
Onchain logs for KMS replication #114
Description
Summary
This is a discussion about whether KMS instances should be whitelisted on-chain before being allowed to onboard, for improved transparency and security.
Current Approach
- Device-ID (implemented as a hash of the PPID) is whitelisted
Proposed Enhancement
- Add on-chain whitelisting for each KMS instance before onboarding is permitted
- Create an on-chain trace/log of onboarding events when instances request KMS keys
Rationale
- Onboarding to KMS (sharing the secret) is considered a highly security-critical component
- On-chain logging would increase transparency and traceability
- Could potentially implement an interactive on-chain challenge to ensure up-to-date view of the chain
Benefits
- Improved visibility into KMS operations
- Public verification of legitimate KMS instances
- Transparent audit trail of key sharing events
Considerations
- Would require additional on-chain operations
- Need to balance transparency with performance and gas costs
Activity
h4x3rotab commentedon Jun 30, 2026
Maintainer triage update: this remains open intentionally and is listed separately from vulnerability reports in the security roadmap/hardening table: https://github.com/Dstack-TEE/dstack/blob/master/docs/security/public-security-reports.md#related-security-roadmap-and-hardening
Disposition: auditability roadmap. This tracks transparency for KMS onboarding and replication events.