Ika Sdk

• Outcome: Review
• Latest audit: Sep 14, 2026 · 10:18 PM UTC
• Version: 1.0.0

Overview

The skill is documentation-only and purpose-aligned, but its wallet key-handling examples are risky enough that users should review them carefully before use.

Install only if you understand Ika/dWallet key management. Do not copy the placeholder seed examples into real code, do not log or store private keys, seeds, serialized key bytes, or secret shares in plaintext, and treat zero-trust-to-shared conversion as a deliberate security tradeoff.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:119

Finding

Predictable Cryptographic Seed in Primary Usage Example

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 119–122
Vulnerability Type: Predictable cryptographic key derivation caused by a hardcoded low-entropy seed
Risk Level: High

Vulnerable Code

typescript

const keys = await UserShareEncryptionKeys.fromRootSeedKey(
    new TextEncoder().encode('your-seed'),
    Curve.SECP256K1,
);

Technical Analysis

The example passes the fixed string your-seed directly into UserShareEncryptionKeys.fromRootSeedKey. Because this key-derivation operation is deterministic, every application that copies the example without replacing the placeholder will derive the same encryption and signing key material.

The documentation does not enforce minimum entropy, generate a random seed, or place an immediate warning beside the example. Although the value is presented as a placeholder, the surrounding code is directly executable, creating a realistic risk that developers will retain it during testing or deployment.

This constitutes an insecure cryptographic default. An attacker does not need to recover the seed through brute force because it is publicly documented.

Attack Path

1. A developer copies the shared-dWallet example into an application.
2. The developer runs or deploys it without replacing your-seed.
3. The application deterministically creates the documented UserShareEncryptionKeys.
4. An attacker independently derives the same keys using the public example.
5. The attacker uses the duplicated key identity and decryption material against associated protocol records and encrypted user shares where accessible.
6. Depending on the wallet mode, capabilities, and protocol state, this may permit impersonation, decryption of user-share material, or unauthorized participation in wallet operations.

Impact Assessment

The affected material includes the class-groups decryption key and the signing identity derived by UserShareEncryptionKeys ...[truncated 616 chars]

Remediation

View remediation

Remediation Suggestions

• Replace the fixed string with cryptographically secure random seed generation using at least 32 bytes:

  typescript

  import { randomBytes } from 'node:crypto';
  
  const rootSeed = new Uint8Array(randomBytes(32));
  const keys = await UserShareEncryptionKeys.fromRootSeedKey(
      rootSeed,
      Curve.SECP256K1,
  );
  

• Store the generated seed in a dedicated secret manager, hardware-backed keystore, or encrypted application vault.

• Never commit the seed to source control, logs, examples, browser storage, or configuration files.

• Add a prominent warning immediately above every seed-derivation example stating that placeholder and human-readable seeds must never be used.

• Validate seed length and provenance in surrounding application code, rejecting known placeholders and low-entropy inputs.

• Where deterministic recovery is required, use a documented password-based KDF with a unique salt and appropriate work factor rather than passing a human-readable password directly.

• Rotate any keys created from this documented placeholder and migrate affected dWallets according to the protocol’s secure recovery or transfer procedure.

T09 · Insecure Skill Coding Practices

Error

• Location: references/flows.md:30

Finding

Predictable Cryptographic Seed in End-to-End Shared dWallet Flow

Content

View full analysis

Vulnerability Details

File Location: references/flows.md, lines 30–33
Vulnerability Type: Predictable cryptographic key derivation caused by a hardcoded deterministic seed
Risk Level: High

Vulnerable Code

typescript

const keys = await UserShareEncryptionKeys.fromRootSeedKey(
    new TextEncoder().encode('your-deterministic-seed'),
    Curve.SECP256K1,
);

Technical Analysis

The full lifecycle flow derives sensitive encryption and signing keys from the public constant your-deterministic-seed. The document later explains that fromRootSeedKey is deterministic, confirming that the same input always produces the same keys.

Because this snippet appears as the first operational step in an otherwise complete workflow, it may be copied into functioning test or production integrations. Anyone with access to the public documentation can reproduce the derived key material. A descriptive placeholder remains unsafe when used as direct input to an executable cryptographic example without adjacent generation and storage guidance.

Attack Path

1. A developer follows the end-to-end shared-dWallet flow and copies the key-creation snippet.
2. The fixed seed remains unchanged during testing or deployment.
3. The application registers or uses keys deterministically derived from your-deterministic-seed.
4. An attacker runs the same derivation locally and obtains identical UserShareEncryptionKeys.
5. The attacker correlates the resulting public identity with accessible network records.
6. Where encrypted shares, relevant records, or complementary capabilities are available, the attacker attempts decryption, authorization impersonation, or participation in wallet operations.

Impact Assessment

The issue can expose the confidentiality of encrypted user-share material and compromise proof-of-ownership or authorization operations tied to the derived signing identity. The affected scope include ...[truncated 479 chars]

Remediation

View remediation

Remediation Suggestions

• Replace the public deterministic constant with secure random generation:

  typescript

  import { randomBytes } from 'node:crypto';
  
  const rootSeed = new Uint8Array(randomBytes(32));
  const keys = await UserShareEncryptionKeys.fromRootSeedKey(
      rootSeed,
      Curve.SECP256K1,
  );
  

• If deterministic derivation is a functional requirement, source the seed from a properly protected wallet signature, hardware-backed secret, WebAuthn PRF output, or suitably configured KDF—not a fixed or human-readable value.

• Explicitly distinguish illustrative placeholders from secure production code and make examples fail closed when a placeholder is detected.

• Document secure backup, recovery, rotation, and destruction procedures for root seeds.

• Add automated documentation tests or static checks that reject known placeholder seeds in executable examples.

• Treat all dWallet identities previously generated from this constant as compromised and rotate or migrate them safely.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (4)

Missing User Warnings

High

• Category: Not specified by scanner
• Confidence: 96% confidence

Finding

The imported key flow accepts a raw privateKey for import but does not clearly warn that handling plaintext private keys is one of the highest-risk operations in wallet software. In this skill's context, developers integrating cross-chain signing may normalize exposing private keys in app memory, logs, browser code, or transport paths, leading to irreversible theft of funds across chains.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 90% confidence

Finding

The skill explicitly documents creation, serialization, restoration, and direct access to sensitive key material such as encryption keys, decryption keys, and secret shares, but provides no security guidance on secure generation, storage, access control, or avoidance of logging/exfiltration. In a wallet and cross-chain signing context, mishandling this material could enable unauthorized signing, loss of confidentiality of user shares, or compromise of wallet control.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 88% confidence

Finding

The example derives encryption keys from a deterministic seed string without warning that the seed is highly sensitive and must be generated, stored, and transmitted securely. In a wallet and cross-chain signing context, readers may copy the pattern directly with weak, hardcoded, reusable, or user-derived material, which can enable key recovery or account compromise if the seed is exposed.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 91% confidence

Finding

The zero-trust to shared conversion example changes the security model by making user secret key shares public to the network, but it does not prominently state that this weakens the guarantees of zero-trust signing. Without that warning, operators may perform the conversion assuming it is operationally equivalent, increasing exposure of signing authority and reducing required user participation for future signatures.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.