T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:145
- Finding
- Private Identity Keys Stored in Plaintext by Default<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 145–151 **Vulnerability Type**: Plaintext storage of cryptographic secrets **Risk Level**: High ### Vulnerable Snippet ```markdown ## Security **CRITICAL - Data Storage and Protection:** The directory `$HOME/.openclaw/billions` contains all sensitive identity data: - `kms.json` - **CRITICAL**: Contains private keys (encrypted if BILLIONS_NETWORK_MASTER_KMS_KEY is set, otherwise in plaintext) ``` ### Technical Analysis The documented storage design permits private identity keys to be written to `$HOME/.openclaw/billions/kms.json` without encryption whenever `BILLIONS_NETWORK_MASTER_KMS_KEY` is not configured. Encryption is therefore optional and the documented default or fallback behavior leaves long-lived cryptographic material exposed at rest. A private key is the security boundary for the associated decentralized identity. File-system permissions alone do not adequately protect it from compromised processes running under the same account, accidental backup exposure, overly broad permissions, diagnostic collection, or unauthorized local access. The artifact contains only `SKILL.md`; the referenced scripts are absent. Consequently, file permissions, key derivation, encryption parameters, and runtime safeguards could not be independently verified. ### Attack Path 1. A user creates an identity without first setting `BILLIONS_NETWORK_MASTER_KMS_KEY`. 2. The identity implementation follows the documented fallback behavior and stores the private key in plaintext in `$HOME/.openclaw/billions/kms.json`. 3. A malicious or compromised process with access to the user's files reads or copies `kms.json`. 4. The attacker extracts the private key. 5. The attacker uses that key outside the project to generate valid signatures and impersonate the affected agent identity. ### Impact Assessment Successful exploitation compromises the confidentiality and integrity of the affected decentralized ide ...[truncated 487 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Make encryption mandatory before creating or importing any identity; refuse the operation when a secure key-encryption mechanism is unavailable. 2. Store private keys in an operating-system credential vault, hardware-backed keystore, hardware security module, or equivalent protected secret store instead of a general JSON file. 3. If encrypted file storage must be supported: - Use a modern authenticated-encryption construction. - Derive encryption keys with a memory-hard KDF and unique salt. - Never store the master encryption key beside the encrypted key material. - Validate decryption and authentication before using a key. 4. Create identity directories and files with owner-only permissions and reject existing files with unsafe ownership, links, or permissions. 5. Prevent private keys from appearing in logs, exceptions, backups, telemetry, and diagnostic output. 6. Document secure key rotation, revocation, backup, and recovery procedures. 7. Add automated tests proving that identity creation cannot persist an unencrypted private key. ]]>
