← Back to Main Documentation

Core Systems Index

HD Wallet Trust Boundaries

Created: Sun 27 Jul 2025 08:20:00 CEST
Document Version: 1.0 - Initial trust model analysis
Security Classification: Critical Security Documentation
Target Audience: Developers, Security Team, Architects, Product Managers
Author: Paul Wisén

Overview

The Plings HD wallet system enables multiple parties to derive private keys for any identifier through the master key hierarchy. While this provides operational flexibility, it creates critical trust implications that must be understood before implementing any private key operations.

Core Principle: Key Access ≠ Ownership Rights

The ability to derive a private key does not grant legitimate authority to perform all cryptographic operations with that key.

Trust Hierarchy

Current Key Access Model

Master Key (Plings)
    ├── Manufacturer Key Delegation
    │   ├── Plant/Facility Keys  
    │   └── Sub-contractor Keys
    └── Emergency Recovery Keys

Parties with Private Key Access:

• ✅ Plings (master key holder)
• ✅ Manufacturer (via key delegation, when implemented)
• ✅ Plant/Facility (via manufacturer delegation)
• ❌ End Users (never have access to private keys)

The Trust Problem

Post-Sale Key Access: Even after ownership transfer, supply chain participants retain the technical ability to derive private keys and perform cryptographic operations. This creates potential for:

• Unauthorized actions on behalf of the object
• False data attestation
• Malicious state changes
• Cryptographic authority abuse

Use Case Classification

✅ Safe Use Cases (Implement Immediately)

These use cases work within the current trust model because the parties with key access have legitimate ongoing authority:

1. Payment Recovery

• Scenario: PDA system fails, funds stuck at identifier address
• Who acts: Plings, Manufacturer, or Plant
• Trust rationale: All parties have legitimate interest in ensuring payment system functionality
• Risk level: LOW - Temporary custody for redistribution
• Implementation: ✅ APPROVED

// Safe: Payment recovery for failed PDA
pub fn recover_stuck_payment(ctx: Context<RecoverPayment>) -> Result<()> {
    // Verify payment is actually stuck
    require!(is_pda_failed(&ctx.accounts.pda), PaymentError::PDANotFailed);
    
    // Transfer to recovery address for redistribution
    transfer_from_identifier_to_recovery(&ctx)?;
    Ok(())
}

2. Warranty Claims

• Scenario: Object signs warranty claim with usage data
• Who acts: Manufacturer (warranty provider)
• Trust rationale: Manufacturer issued warranty, has right to validate claims
• Risk level: LOW - Limited to warranty period and scope
• Implementation: ✅ APPROVED

def sign_warranty_claim(identifier_path: str, usage_data: dict, claim_details: dict):
    # Manufacturer has legitimate authority during warranty period
    if not is_warranty_active(identifier_path):
        raise WarrantyExpiredError()
    
    # Sign claim with object's private key
    signature = derive_and_sign(identifier_path, claim_details)
    return create_warranty_claim(signature, usage_data, claim_details)

3. Supply Chain Verification

• Scenarios: Manufacturing proof, quality control signatures, shipping verification
• Who acts: Supply chain participants during production/distribution
• Trust rationale: Actions occur during manufacturing custody period
• Risk level: LOW - Limited to pre-sale period
• Implementation: ✅ APPROVED

def sign_manufacturing_proof(identifier_path: str, manufacturing_data: dict):
    # Valid only during pre-sale manufacturing period
    if object_is_sold(identifier_path):
        raise PostSaleOperationError("Cannot sign manufacturing proof after sale")
    
    # Plant has legitimate authority during production
    signature = derive_and_sign(identifier_path, manufacturing_data)
    return create_manufacturing_certificate(signature, manufacturing_data)

❌ Problematic Use Cases (Require New Architecture)

These use cases break the trust model because they allow supply chain participants to control objects after ownership transfer:

1. Object Retirement/Disposal

• Scenario: Object signs end-of-life transaction
• Problem: Manufacturer could “destroy” objects years after sale
• Trust issue: Owner bought a watch in Sweden; Chinese factory shouldn’t be able to “destruct” it 3 years later
• Risk level: HIGH - Potential for malicious destruction
• Implementation: ❌ BLOCKED - Requires owner-controlled keys

Example of Dangerous Implementation:

# ❌ DANGEROUS - Don't implement this
def retire_object(identifier_path: str):
    # Manufacturer retains ability to "destroy" objects post-sale
    signature = derive_and_sign(identifier_path, {"action": "retire", "timestamp": now()})
    blockchain.mark_object_destroyed(signature)  # DANGEROUS!

Safe Alternative:

# ✅ SAFE - Owner-controlled retirement
def retire_object_by_owner(owner_signature: str, identifier_path: str):
    # Only object owner or authorized recycler can retire
    if not verify_owner_signature(owner_signature, identifier_path):
        raise UnauthorizedError("Only owner can retire object")
    
    blockchain.mark_object_retired(owner_signature)

2. Ownership Transfer via Private Keys

• Scenario: Object private key signs ownership transfer
• Problem: Manufacturer could still transfer object after sale
• Trust issue: Ownership should follow the object, not the identifier
• Risk level: HIGH - Potential ownership theft
• Implementation: ❌ BLOCKED - Use organization+NFT model instead

Existing Safe Solution: The organization + NFT ownership model already handles ownership transfer correctly. Private key transfer is redundant and dangerous.

3. IoT Autonomous Operations

• Scenarios: Autonomous payments, data attestation, embedded device operations
• Problem: Supply chain participants retain control even after sale
• Trust issue: Owner won’t trust actions that manufacturer/plant can still perform
• Risk level: HIGH - Ongoing unauthorized control
• Implementation: ❌ BLOCKED - Requires owner-controlled key derivation

Example Problem:

# ❌ DANGEROUS - Post-sale autonomous operations
def autonomous_parking_payment(identifier_path: str, parking_fee: int):
    # Manufacturer could potentially make unauthorized payments
    signature = derive_and_sign(identifier_path, {"payment": parking_fee, "service": "parking"})
    blockchain.make_payment(signature, parking_fee)  # DANGEROUS!

Core Trust Principles

1. Temporal Authority Boundaries

Principle: Private key operations must respect the temporal limits of legitimate authority.

• Pre-Sale: Manufacturers have full authority
• Post-Sale: Only recovery and warranty operations remain valid
• Post-Warranty: Only payment recovery remains valid

2. Purpose-Limited Operations

Principle: Private key operations must be limited to the specific purpose for which authority exists.

• Payment Recovery: Limited to redistribution, not arbitrary spending
• Warranty Claims: Limited to warranty-covered issues
• Supply Chain: Limited to manufacturing period

3. Owner Supremacy

Principle: Owner authority always supersedes supply chain authority.

• Owner decisions override manufacturer preferences
• Owner can revoke operations (when technically possible)
• Owner privacy and autonomy must be protected

Implementation Guidelines

Phase 1: Safe Implementation (Current)

Status: ✅ APPROVED FOR IMPLEMENTATION

• Implement payment recovery functionality
• Add supply chain verification features
• Document trust boundaries clearly
• DO NOT IMPLEMENT owner-dependent features

Required Safeguards:

class SafePrivateKeyOperation:
    def __init__(self, identifier_path: str, operation_type: str):
        self.identifier_path = identifier_path
        self.operation_type = operation_type
        
    def validate_authority(self) -> bool:
        """Validate that current party has authority for this operation"""
        if self.operation_type == "payment_recovery":
            return True  # Always valid for stuck payments
        elif self.operation_type == "warranty_claim":
            return is_warranty_active(self.identifier_path)
        elif self.operation_type == "supply_chain":
            return not object_is_sold(self.identifier_path)
        else:
            raise UnauthorizedOperationError(f"Operation {self.operation_type} not approved")

Phase 2: Enhanced Trust Model (Future)

Status: 🔄 RESEARCH REQUIRED

Requirements for safe owner-controlled operations:

• Key delegation termination mechanisms
• Owner-controlled key derivation
• Time-based key expiration
• Separate key spaces for different trust zones

Phase 3: Full Autonomy (Long-term)

Status: 📋 PLANNING PHASE

Vision for complete owner autonomy:

• Embedded secure elements with owner-controlled keys
• IoT device autonomy with proper trust boundaries
• Integration with ownership NFT system for key delegation

Security Warnings

⚠️ CRITICAL: Never Implement These Patterns

# ❌ DANGEROUS PATTERN 1: Post-sale control
def control_object_after_sale(identifier_path: str, action: str):
    # Manufacturer retains control indefinitely
    signature = derive_and_sign(identifier_path, action)
    execute_action(signature)  # DANGEROUS!

# ❌ DANGEROUS PATTERN 2: Owner-equivalent operations
def act_as_owner(identifier_path: str, owner_action: str):
    # Supply chain participant acts with owner authority
    signature = derive_and_sign(identifier_path, owner_action)
    execute_owner_action(signature)  # DANGEROUS!

# ❌ DANGEROUS PATTERN 3: Unlimited scope operations
def perform_any_operation(identifier_path: str, operation: dict):
    # No validation of legitimate authority
    signature = derive_and_sign(identifier_path, operation)
    execute_operation(signature)  # DANGEROUS!

✅ SAFE: Implement These Patterns Instead

# ✅ SAFE PATTERN 1: Temporal validation
def supply_chain_operation(identifier_path: str, operation: dict):
    if object_is_sold(identifier_path):
        raise PostSaleOperationError("Operation not valid after sale")
    
    signature = derive_and_sign(identifier_path, operation)
    execute_operation(signature)

# ✅ SAFE PATTERN 2: Purpose validation
def warranty_operation(identifier_path: str, claim: dict):
    if not is_warranty_active(identifier_path):
        raise WarrantyExpiredError("Warranty period expired")
    
    if not is_warranty_covered_issue(claim):
        raise WarrantyExclusionError("Issue not covered by warranty")
    
    signature = derive_and_sign(identifier_path, claim)
    process_warranty_claim(signature, claim)

# ✅ SAFE PATTERN 3: Recovery validation
def payment_recovery_operation(identifier_path: str, recovery_address: str):
    if not is_payment_stuck(identifier_path):
        raise PaymentNotStuckError("Payment recovery not needed")
    
    signature = derive_and_sign(identifier_path, {"action": "recover", "to": recovery_address})
    recover_payment(signature, recovery_address)

Decision Framework

Evaluating New Use Cases

When considering any new private key operation, evaluate against these criteria:

1. Authority Analysis

• ❓ Does the party with key access have legitimate authority for this operation?
• ❓ Is this authority time-limited or perpetual?
• ❓ Would the object owner expect this party to have this capability?

2. Trust Boundary Check

• ❓ Does this operation remain valid after ownership transfer?
• ❓ Could this operation be abused if performed maliciously?
• ❓ Does the owner have recourse if they disagree with the operation?

3. Scope Validation

• ❓ Is the operation limited to specific, well-defined purposes?
• ❓ Are there clear technical safeguards preventing abuse?
• ❓ Is there an alternative approach using the ownership system?

4. Risk Assessment

• LOW RISK: Pre-sale operations, recovery operations, warranty operations
• MEDIUM RISK: Time-limited post-sale operations with clear scope
• HIGH RISK: Indefinite post-sale operations, owner-equivalent operations

Implementation Decision Matrix

Authority	Temporal Scope	Purpose Scope	Risk Level	Implementation
Legitimate	Pre-sale only	Well-defined	LOW	✅ Approved
Legitimate	Warranty period	Warranty-related	LOW	✅ Approved
Legitimate	Emergency only	Recovery only	LOW	✅ Approved
Questionable	Post-sale	Broad scope	MEDIUM	🔄 Research needed
Illegitimate	Indefinite	Unlimited	HIGH	❌ Blocked

Related Documentation

• Ownership Handling - Organization + NFT ownership model
• Wallet Management Architecture - HD wallet technical architecture
• Solana Payment Architecture - Payment flow and PDA system
• Private Key Use Cases Analysis - Detailed use case risk assessment

Summary

The HD wallet trust model enables powerful cryptographic operations but requires careful respect for trust boundaries. Phase 1 operations (payment recovery, warranty claims, supply chain verification) are safe to implement immediately. Owner-controlled operations require architectural changes to ensure proper trust boundaries.

Key Takeaway: Technical capability to derive private keys does not equal legitimate authority to use them. All private key operations must be evaluated against trust boundaries and implemented with appropriate safeguards.

---

Documentation Status: Foundational security document - complete
Next Phase: Implement safe Phase 1 operations with proper validation
Review Required: Security team approval before any private key feature implementation