ULedgerNET Security Considerations
Overview
This document outlines the security model, threat mitigations, and best practices for ULedgerNET deployments.
Security Architecture
Defense in Depth
Threat Model
Byzantine Fault Tolerance
Threat Categories
| Category | Threat | Mitigation |
|---|
| Network | Man-in-the-Middle | TLS 1.3 / Noise Protocol |
| Network | Sybil Attack | Council membership validation |
| Consensus | Double Spend | BFT consensus with ⅔ threshold |
| Consensus | Long-Range Attack | Immediate finality (no reorg) |
| Crypto | Signature Forgery | Proven signature schemes |
| Crypto | Hash Collision | SHA3-256/512 resistance |
| Execution | Reentrancy | Atomic state transactions |
| Execution | Resource Exhaustion | Gas metering |
Network Security
Transport Layer Security
Peer Authentication
Every peer is authenticated using cryptographic identity:
Network-Level Protections
| Protection | Implementation |
|---|
| Encryption | All traffic encrypted (TLS 1.3/Noise) |
| Authentication | Peer ID verification |
| Rate Limiting | Per-peer message limits |
| Message Size | Maximum message size enforcement |
Consensus Security
Byzantine Fault Tolerance Properties
| Property | Guarantee |
|---|
| Safety | No two honest nodes finalize different blocks at same height |
| Liveness | If ≥ ⅔ nodes are honest, blocks continue to be produced |
| Finality | Once finalized, blocks cannot be reverted |
Equivocation Prevention
Leader Failure Handling
Cryptographic Security
Signature Security
| Algorithm | Security Level | Quantum Resistance |
|---|
| secp256k1 | 128-bit | ❌ Vulnerable |
| ED25519 | 128-bit | ❌ Vulnerable |
| BLS12-377 | 128-bit | ❌ Vulnerable |
| ML-DSA-87 | 256-bit | ✅ Resistant |
Zero-Knowledge Proof Security
Hash Function Security
| Function | Collision Resistance | Preimage Resistance |
|---|
| SHA3-256 | 128-bit | 256-bit |
| SHA3-512 | 256-bit | 512-bit |
| MiMC | ~128-bit | ~128-bit |
Smart Contract Security
Execution Isolation
Gas Metering Security
State Integrity
Transaction Security
Transaction Validation
Timestamp Security
| Check | Purpose |
|---|
| Median Calculation | Prevent time manipulation |
| Max Deviation | Reject outlier timestamps |
| Peer Consensus | Multiple timestamp sources |
Replay Protection
| Mechanism | Description |
|---|
| Transaction ID | Unique hash per transaction |
| Validity Window | Time-limited acceptance |
| Recent TX Cache | Track processed transactions |
Post-Quantum Considerations
Quantum Threat Timeline
Post-Quantum Migration
ULedgerNET is prepared for the quantum future:
- ✅ ML-DSA-87 (Dilithium) already supported
- ✅ Algorithm agility built into protocol
- ✅ Key derivation supports all algorithms
- ✅ Can migrate chains to quantum-safe crypto
Security Best Practices
Node Deployment
| Practice | Recommendation |
|---|
| Network | Deploy behind firewall, use VPN for council communication |
| Keys | Use HSM for production signing keys |
| Updates | Regular security updates and patches |
| Monitoring | Enable logging and alerting |
Council Operations
| Practice | Recommendation |
|---|
| Membership | Vet council members, require identity verification |
| Distribution | Geographic distribution of nodes |
| Communication | Secure out-of-band communication channel |
| Key Management | Regular key rotation schedule |
Smart Contract Development
| Practice | Recommendation |
|---|
| Auditing | Third-party security audit before deployment |
| Testing | Comprehensive test coverage |
| Gas Limits | Set appropriate gas limits |
| Upgradability | Plan for contract upgrades |
Wallet Hierarchy Management
| Practice | Recommendation |
|---|
| Root Wallet Protection | Store root wallet keys in HSM or secure vault |
| Least Privilege | Grant minimum required permissions to child wallets |
| Hierarchy Depth | Limit nesting depth for manageability |
| Regular Audits | Review wallet permissions and satellite lists |
| Offboarding Process | Disable parent wallet to cascade-revoke all children |
Wallet Security
Hierarchical Access Control
Cascading Disable Security
When a wallet is disabled, all descendant wallets are automatically disabled:
| Benefit | Description |
|---|
| Instant Revocation | Disable one parent, revoke all children |
| No Orphaned Access | Prevents leftover active child wallets |
| Audit Trail | All disable operations recorded on-chain |
| Reversible | Re-enable parent to restore hierarchy |
Permission Verification
Every transaction verifies:
- Wallet Exists - Target wallet must be registered
- Wallet Enabled - Disabled wallets cannot transact
- Key Type Match - Transaction must use wallet's key type
- Signature Valid - Cryptographic signature verification
- Parent Authorization - Child operations require parent approval
Incident Response
Response Process
Severity Levels
| Level | Description | Response Time |
|---|
| Critical | Consensus failure, fund loss risk | Immediate |
| High | Security vulnerability, service degradation | < 4 hours |
| Medium | Non-critical bug, performance issue | < 24 hours |
| Low | Minor issue, improvement opportunity | Next release |
For security-related inquiries or to report vulnerabilities:
- Follow responsible disclosure practices
- Provide detailed reproduction steps
- Allow reasonable time for remediation before public disclosure
Next: Wallet System