CHAPTER 5

Security & Cryptographic Foundations

Essential cryptographic protocols, wallet security, key management, and security best practices for digital currency systems.

5.1 Cryptographic Foundations

Digital currencies rely fundamentally on cryptography to ensure security, authenticity, and integrity. Understanding these cryptographic primitives is essential for building secure systems.

5.1.1 Public-Key Cryptography

Digital currencies use asymmetric cryptography where each user has a pair of keys:

• Private Key: Secret key known only to the owner, used to sign transactions and prove ownership
• Public Key: Derived from private key, shared publicly, used to verify signatures and receive funds
• Address: Hash of public key, used as account identifier

Common algorithms:

• ECDSA (Elliptic Curve Digital Signature Algorithm): Used by Bitcoin, Ethereum
• EdDSA (Edwards-curve DSA): Used by newer cryptocurrencies, faster and more secure
• Schnorr Signatures: Bitcoin upgrade, enables multi-sig aggregation

5.1.2 Hash Functions

Cryptographic hash functions are one-way functions that produce fixed-size outputs from variable inputs:

• SHA-256: Bitcoin's primary hash function
• Keccak-256: Ethereum's hash function
• BLAKE2: Faster alternative used in newer blockchains

Properties required:

• Deterministic: Same input always produces same output
• Pre-image resistant: Computationally infeasible to reverse
• Collision resistant: Virtually impossible to find two inputs with same output
• Avalanche effect: Tiny input change drastically changes output

5.2 Wallet Security

5.2.1 Wallet Types

Hot Wallets (Online)

• Connected to internet, convenient for frequent transactions
• Web wallets, mobile apps, desktop software
• Higher risk of hacking, malware
• Suitable for small amounts and daily use

Cold Wallets (Offline)

• Not connected to internet, maximum security
• Hardware wallets (Ledger, Trezor), paper wallets
• Protected from online attacks
• Suitable for long-term storage, large amounts

Multi-Signature Wallets

• Require M of N signatures to authorize transactions
• Example: 2-of-3 requires any 2 of 3 key holders to approve
• Enhanced security, shared control
• Used by exchanges, institutions, joint accounts

5.2.2 Seed Phrases and Recovery

Modern wallets use BIP-39 standard for generating recovery phrases:

• 12 or 24 words from standardized dictionary
• Encodes the master seed from which all keys are derived
• Enables wallet recovery if device is lost or damaged
• Must be stored securely offline (never digital photos or cloud storage)

5.3 Transaction Security

5.3.1 Transaction Signing

All digital currency transactions must be cryptographically signed:

1. Create transaction:
   {from: Alice, to: Bob, amount: 10, nonce: 5}

2. Hash transaction:
   hash = SHA256(transaction_data)

3. Sign with private key:
   signature = ECDSA_sign(hash, alice_private_key)

4. Broadcast transaction + signature

5. Network verifies:
   ECDSA_verify(hash, signature, alice_public_key)

5.3.2 Replay Attack Protection

Mechanisms to prevent transaction replay:

• Nonces: Sequential number that must increment, prevents reusing transactions
• Chain ID: Includes blockchain identifier to prevent cross-chain replay
• Timestamps: Transactions expire after certain time
• Unique identifiers: One-time transaction IDs

5.4 Network Security

5.4.1 51% Attack Prevention

In Proof of Work blockchains, controlling majority of hash power allows transaction reversal:

Mitigation strategies:

• Large, distributed mining network
• High mining difficulty making attacks expensive
• Wait for multiple confirmations on high-value transactions
• Switch to Proof of Stake (no hash power concentration)

5.4.2 Double-Spend Prevention

Blockchain consensus prevents spending same coins twice:

• All nodes validate transactions against current state
• Conflicting transactions rejected
• Block confirmation provides finality
• Longer chains preferred in fork resolution

5.5 Smart Contract Security

5.5.1 Common Vulnerabilities

• Reentrancy: Recursive calls exploiting state changes (DAO hack)
• Integer Overflow/Underflow: Arithmetic errors causing unexpected values
• Access Control: Insufficient permission checks
• Front-Running: Miners/bots seeing transactions and executing first
• Gas Limit Issues: Transactions failing due to insufficient gas

5.5.2 Security Best Practices

• Use established, audited libraries (OpenZeppelin)
• Formal verification of critical contracts
• Multiple independent security audits
• Bug bounty programs
• Gradual rollout with testnet deployment
• Circuit breakers and pause mechanisms
• Time-locks on critical operations

5.6 Privacy Technologies

5.6.1 Zero-Knowledge Proofs

Prove knowledge of information without revealing it:

• zk-SNARKs: Succinct proofs, small size, used in Zcash
• zk-STARKs: Scalable, no trusted setup, quantum-resistant
• Bulletproofs: Short proofs for range proofs, no trusted setup

Applications:

• Private transactions (hide amounts, senders, recipients)
• Compliance proofs without revealing details
• Scalability (batch verification)
• Anonymous credentials

5.6.2 Ring Signatures

Used in Monero for sender anonymity:

• Transaction signed by one of a group
• Impossible to determine which group member signed
• Provides plausible deniability
• Combined with stealth addresses and RingCT for full privacy

5.7 WIA-FIN-004 Security Requirements

5.7.1 Minimum Security Standards

Systems complying with WIA-FIN-004 must implement:

• TLS 1.3 for all network communications
• AES-256 encryption for data at rest
• Multi-factor authentication for user access
• Hardware Security Modules (HSM) for key storage
• Regular security audits (at least annually)
• Penetration testing before production deployment
• Incident response plan and breach notification procedures
• Cold storage for majority of funds (80%+ for custodians)

5.7.2 Key Management Standards

{
  "keyManagement": {
    "generation": "HSM | SECURE_RANDOM",
    "storage": {
      "hot": "ENCRYPTED_DATABASE | HSM",
      "cold": "OFFLINE_HSM | PAPER_BACKUP",
      "multiSig": {
        "required": true,
        "threshold": "M_OF_N",
        "geographicDistribution": true
      }
    },
    "rotation": {
      "frequency": "QUARTERLY",
      "automated": false,
      "auditTrail": true
    },
    "backup": {
      "method": "SHAMIR_SECRET_SHARING",
      "locations": "MULTIPLE_SECURE_SITES",
      "tested": "ANNUALLY"
    }
  }
}

5.8 Emerging Security Technologies

5.8.1 Quantum Resistance

Preparing for quantum computers that could break current cryptography:

• Quantum-resistant algorithms: Lattice-based, hash-based signatures
• Hybrid approaches: Combine classical and quantum-resistant schemes
• NIST standards: Following NIST post-quantum cryptography standardization

5.8.2 Threshold Signatures

Advanced multi-signature schemes:

• Distributed key generation (no single entity knows full key)
• Non-interactive signing (no communication rounds)
• Used in enterprise custody solutions