aitbc/docs/SECURITY_VULNERABILITIES.md

AITBC Security Vulnerabilities

Date: April 13, 2026
Severity: CRITICAL
Status: OPEN

Database Manipulation Vulnerability

Issue: Direct database manipulation is possible to change account balances without cryptographic validation.

Current Implementation

Database Schema Issues:

CREATE TABLE account (
    chain_id VARCHAR NOT NULL,
    address VARCHAR NOT NULL,
    balance INTEGER NOT NULL,
    nonce INTEGER NOT NULL,
    updated_at DATETIME NOT NULL,
    PRIMARY KEY (chain_id, address)
);

Security Problems:

1. No Cryptographic Signatures: Account balances are stored as plain integers without signatures
2. No State Root Verification: No Merkle tree or state root to verify account state integrity
3. No Transaction Validation: Balance changes can be made directly without transaction processing
4. No Encryption at Rest: Database is accessible with standard file permissions
5. No Integrity Constraints: No foreign keys or constraints preventing manipulation
6. Mutable State: Account balances are stored as mutable state instead of derived from transaction history

Why This Should Not Be Possible

In a proper AI trust blockchain:

• Account balances should be derived from transaction history, not stored as mutable state
• State should be verified via Merkle trees/state roots in block headers
• Database should be encrypted or have strict access controls
• Balance changes should only happen through validated transactions with proper signatures
• Cryptographic signatures should protect all state changes
• State root verification should validate entire account state against block headers

Proof of Vulnerability

The following operations were successfully executed, demonstrating the vulnerability:

# Direct account creation without transaction validation
sqlite3 /var/lib/aitbc/data/chain.db "INSERT INTO account (chain_id, address, balance, nonce, updated_at) VALUES ('ait-testnet', 'ait10a252a31c79939c689bf392e960afc7861df5ee9', 1000, 0, datetime('now'))"

# Direct balance manipulation without transaction validation
sqlite3 /var/lib/aitbc/data/chain.db "UPDATE account SET balance = 10000000 WHERE address = 'aitbc1genesis'"

# Account deletion without transaction validation
sqlite3 /var/lib/aitbc/data/chain.db "DELETE FROM account WHERE address = 'ait10a252a31c79939c689bf392e960afc7861df5ee9'"

Impact:

• Anyone with database access can create arbitrary balances
• No cryptographic proof of balance ownership
• No audit trail of balance changes
• Violates fundamental blockchain security principles
• Compromises trust in the entire system

Missing Security Measures

1. Cryptographic Signatures

Missing: Account state changes should be signed by private keys Impact: Unauthorized balance modifications possible

2. State Root Verification

Missing: Merkle tree or state root to verify account state integrity Impact: No way to detect tampering with account balances

3. Transaction-Only State Changes

Missing: Balance changes should only occur through validated transactions Impact: Direct database manipulation bypasses consensus mechanism

4. Database Encryption

Missing: Database stored in plain text with file-system permissions only Impact: Physical access allows complete compromise

5. Integrity Constraints

Missing: No cryptographic integrity checks on database state Impact: Silent corruption or tampering undetectable

6. Derived State

Missing: Account balances should be computed from transaction history, not stored Impact: Mutable state can be manipulated without trace

Proposed Security Fixes

Immediate (Critical)

1. Implement State Root Verification

   • Add Merkle tree for account state
   • Include state root in block headers
   • Verify state root against account state on every block

2. Add Cryptographic Signatures

   • Sign all state changes with private keys
   • Verify signatures before applying changes
   • Reject unsigned or invalidly signed operations

3. Transaction-Only Balance Changes

   • Remove direct account balance updates
   • Only allow balance changes through validated transactions
   • Add transaction replay protection

Medium Term

4. Database Encryption

   • Encrypt database at rest
   • Use hardware security modules (HSM) for key storage
   • Implement secure key management

5. Access Controls

   • Restrict database access to blockchain node only
   • Add authentication for database connections
   • Implement audit logging for all database operations

Long Term

6. Derived State Architecture

   • Redesign to compute balances from transaction history
   • Store immutable transaction log only
   • Compute account state on-demand from transaction history

7. Formal Verification

   • Add formal verification of consensus logic
   • Implement zero-knowledge proofs for state transitions
   • Add cryptographic proofs for all operations

Impact Assessment

Trust Impact: CRITICAL

• Compromises fundamental trust in the blockchain
• Users cannot trust that balances are accurate
• Undermines entire AI trust system premise

Security Impact: CRITICAL

• Allows unauthorized balance creation
• Enables double-spending attacks
• Bypasses all consensus mechanisms

Financial Impact: CRITICAL

• Can create arbitrary amounts of AIT coins
• Can steal funds from legitimate users
• Cannot guarantee asset ownership

Recommendations

1. IMMEDIATE: Disable direct database access
2. IMMEDIATE: Implement state root verification
3. IMMEDIATE: Add transaction-only balance changes
4. SHORT TERM: Implement database encryption
5. MEDIUM TERM: Redesign to derived state architecture
6. LONG TERM: Implement formal verification

Status

Discovery: April 13, 2026
Reported: April 13, 2026
Severity: CRITICAL
Priority: IMMEDIATE ACTION REQUIRED

This vulnerability represents a fundamental security flaw that must be addressed before any production deployment.

Implementation Progress

Phase 1 (Immediate Fixes) - COMPLETED April 13, 2026

✅ 1.1 Database Access Restrictions + Encryption

• Added DatabaseOperationValidator class for application-layer validation
• Implemented restrictive file permissions (600) on database file
• Added database encryption key environment variable support
• Restricted engine access through get_engine() function
• File: /opt/aitbc/apps/blockchain-node/src/aitbc_chain/database.py

✅ 1.2 State Root Verification

• Implemented Merkle Patricia Trie for account state
• Added StateManager class for state root computation
• Updated block creation to compute state root (consensus/poa.py)
• Added state root verification on block import (sync.py)
• Files:
  • /opt/aitbc/apps/blockchain-node/src/aitbc_chain/state/merkle_patricia_trie.py
  • /opt/aitbc/apps/blockchain-node/src/aitbc_chain/consensus/poa.py
  • /opt/aitbc/apps/blockchain-node/src/aitbc_chain/sync.py

✅ 1.3 Transaction-Only Balance Changes

• Created StateTransition class for validating all state changes
• Removed direct balance updates from sync.py
• Removed direct balance updates from consensus/poa.py
• Added transaction replay protection
• Added nonce validation for all transactions
• Files:
  • /opt/aitbc/apps/blockchain-node/src/aitbc_chain/state/state_transition.py
  • /opt/aitbc/apps/blockchain-node/src/aitbc_chain/sync.py
  • /opt/aitbc/apps/blockchain-node/src/aitbc_chain/consensus/poa.py

✅ Security Tests Added

• Database security tests (file permissions, operation validation)
• State transition tests (replay protection, nonce tracking)
• State root verification tests (Merkle Patricia Trie)
• Files:
  • /opt/aitbc/apps/blockchain-node/tests/security/test_database_security.py
  • /opt/aitbc/apps/blockchain-node/tests/security/test_state_transition.py
  • /opt/aitbc/apps/blockchain-node/tests/security/test_state_root.py

Phase 2 (Short-Term) - PENDING

• Database encryption with SQLCipher (integrated with Phase 1.1)

Phase 3 (Medium-Term) - PENDING

• Derived state architecture redesign

Phase 4 (Long-Term) - PENDING

• Formal verification

Notes

• Chain reset is required for full deployment of Phase 1 fixes
• Existing blocks do not have state roots (will be computed for new blocks)
• State root verification currently logs warnings but accepts blocks (to be enforced in production)
• Direct database manipulation is now prevented through application-layer validation
• File permissions restrict database access to owner only